Pinto-Gerencia de Proyectos 3ra Ed

Descargar como pdf o txt
Descargar como pdf o txt
Está en la página 1de 564

Jeffrey K.

Pinto

GERENCIA de
PROYECTOS
Tercera edición
Cómo lograr
la ventaja
competitiva
Jeffrey K. Pinto
Pennsylvania State University

TRADUCCIÓN

Juan Manuel Cubillos Avellaneda


Universidad EAN
Mauricio Díez Silva
Universidad EAN
Mauricio Soler Ávila
Universidad EAN
Hugo Fernando Castro Silva
Universidad Tecnológica y Pedagógica de Colombia (UPTC)
Leonardo Fabio Quijano Brand
Universidad Tecnológica y Pedagógica de Colombia (UPTC)

REVISIÓN TÉCNICA

Juan Manuel Cubillos Avellaneda


Universidad EAN
Nicolay Sánchez Abello
Universidad EAN
Nelson Sánchez Torres
Universidad EAN
Mauricio Soler Ávila
Universidad EAN
Hugo Fernando Castro Silva
Universidad Tecnológica y Pedagógica de Colombia (UPTC)
Leonardo Fabio Quijano Brand
Universidad Tecnológica y Pedagógica de Colombia (UPTC)
Datos de catalogación bibliográfica

PINTO, JEFFREY K.
Gerencia de proyectos
Tercera edición
PEARSON, Colombia, 2015
ISBN: 978-958-699-297-8
Área: administración y economía
Formato: 21,5 × 27,5 cm Páginas: 560

Todos los derechos reservados


Director General Región Andina: Eduardo Guzmán
Director Educación Superior Región Andina: Camilo Pinzón
Director Editorial Región Andina: Dante Antonioli
Gerente Educación Superior y Profesional Colombia: Fernando Gómez
Editor: Orlando Fernández
e-mail: [email protected]

Microsoft y/o sus proveedores no hacen declaración alguna sobre la idoneidad de la información contenida en los documentos y gráficas rela-
cionados y publicados, como parte de los servicios para cualquier propósito. Todos los documentos y gráficas relacionados se proporcionan
“en el estado en que se encuentran” sin garantía de ningún tipo. Microsoft y/o sus proveedores por medio del presente documento no otorgan
garantías ni aseguran condiciones con respecto a esta información, incluyendo todas las garantías y condiciones de comercialización, sean expre-
sas, implícitas o legales, garantía de aptitud para un propósito particular, propiedad y no infracción de derechos de terceros. Microsoft y/o sus
proveedores no serán responsables de ningún evento por perjuicios especiales, indirectos o consecuenciales, ni por cualesquiera otros perjuicios
resultantes de la pérdida de uso, información o utilidades, sea por acción, omisión, u otro acto o hecho constitutivo de responsabilidad extracon-
tractual, derivado o relacionado con el uso o desempeño de información resultante de los servicios.

Los documentos y gráficas que se relacionan y contiene este libro podrían incluir inexactitudes técnicas y errores tipográficos. Periódicamente se
agregan cambios a la información de este libro. En cualquier momento, Microsoft y/o sus proveedores podrán realizar mejoras y/o cambios en el
(los) producto(s) y/o el (los) programa(s) descritos en este libro. Las capturas de pantalla parciales podrán verse en su totalidad en la versión de
software especificada.

Microsoft® y Windows® son marcas comerciales registradas de Microsoft Corporation en EE.UU. y otros países. Este libro no está patrocinado
ni avalado o afiliado a Microsoft Corporation.

Authorized translation from the English language edition, entitled Project Management: Achieving Competitive Advantage, 3 th edition, by Jefferey
K. Pinto, published by Pearson Education, Inc., publishing as Prentice Hall, copyright © 2013. All rights reserved. ISBN 978-0-13-266415-8

Electronic spanish language edition published by Pearson Educación de Colombia Ltda., Copyright ©2015.

Traducción autorizada de la edición en idioma inglés titulada Project Management: Achieving Competitive Advantage, 3 th edition, by Jefferey K.
Pinto, published by Pearson Education, Inc., publicada como Prentice Hall, copyright © 2015 Todos los derechos reservados.

Esta edición en español es la única autorizada.

TERCERA EDICIÓN, 2015

D.R. © 2015 por Pearson Educación de Colombia Ltda.


North Point III, Carrera 7a. 156-68, pisos 26, Bogotá. Colombia

Cámara Colombiana del Libro. Radicación núm. 170943

Reservados todos los derechos. Ni la totalidad ni parte de esta publicación puede reproducirse, registrarse o transmitirse, por un sistema de
recuperación de información, en ninguna forma ni por ningún medio, sea electrónico, mecánico, fotoquímico, magnético o electroóptico, por
fotocopia, grabación o cualquier otro, sin permiso previo por escrito del editor.

El préstamo, alquiler o cualquier otra forma de cesión de uso de este ejemplar requerirá también la
autorización del editor o de sus representantes.

ISBN VERSIÓN IMPRESA: 978-958-699-297-8


ISBN E-BOOK: 978-958-699-298-5

Impreso en Colombia. Printed in Colombia.

www.pearsonenespañol.com
Para Mary Beth, mi esposa, con el más profundo agradecimiento y amor por su apoyo
incondicional. Y para nuestros hijos, Emily, AJ, y Joseph:
tres “proyectos” que, sin duda, están por encima del presupuesto,
¡pero que se han realizado mucho mejor de lo que podía haber esperado!
CONTENIDO BREVE

Prefacio xv

Capítulo 1 Introducción. ¿Por qué la gerencia de proyectos? 1

Capítulo 2 El contexto organizacional. Estrategia, estructura y


cultura 34

Capítulo 3 Selección de proyectos y gerencia del portafolio 75

Capítulo 4 Liderazgo y el gerente de proyectos 114

Capítulo 5 Gerencia del alcance 145

Capítulo 6 Conformación del equipo del proyecto, conflicto y


negociación 186

Capítulo 7 Gerencia del riesgo 225

Capítulo 8 Estimación de costos y presupuesto 257

Capítulo 9 Programación del proyecto. Redes, estimación de la


duración y ruta crítica 295

Capítulo 10 Programación del proyecto. Retraso, compresión y


redes de actividades 330

Capítulo 11 Programación de proyectos con cadena crítica 367

Capítulo 12 Gerencia de recursos 399

Capítulo 13 Evaluación y control de proyectos 430

Capítulo 14 Cierre y terminación del proyecto 470

Apéndice A 501
Apéndice B 503
Glosario 513
Índice de compañías 527
Índice de nombres 529
Índice analítico 533

iv
CONTENIDO
Prefacio xv

Capítulo 1 Introducción. ¿Por qué la gerencia de proyectos? 1


PERFIL DE PROYECTO: Caso—Rescate de los mineros chilenos 2
Introducción 4
1.1  ¿Qué es un proyecto? 5
Características generales de un proyecto 6
1.2  ¿Por qué son importantes los proyectos? 9
PERFIL DE PROYECTO: Caso —Proyectos en China: motivación del entorno innovador 10
1.3  El ciclo de vida de un proyecto 12
■■GERENTES DE PROYECTOS EN LA PRÁCTICA: Stephanie Smith, Westinghouse Electric
Company 14
1.4  Factores determinantes en el éxito de un proyecto 16
■■INVESTIGACIÓN DE GERENCIA DE PROYECTOS EN SÍNTESIS: evaluación del éxito de los
proyectos de tecnología de la información (IT) 18
1.5  Modelos de madurez de la gerencia de proyectos 19
1.6  Elementos del proyecto y organización del libro 23
Resumen 26
Términos clave 27
Preguntas para discusión 28
Estudio de caso 1.1 MegaTech, Inc. 28
Estudio de caso 1.2 El Departamento de IT de Hamelin Hospital 29
Estudio de caso 1.3 Expedición al Everest de Disney 30
Ejercicios en internet 31
Preguntas de ejemplo del examen para la certificación PMP® 31
Notas 32

Capítulo 2 El contexto organizacional. Estrategia, estructura y cultura 34


PERFIL DE PROYECTO: Caso—El Ejército de Estados Unidos regresa a la era de los dirigibles
no rígidos 35
Introducción 36
2.1  Proyectos y estrategia organizacional 37
2.2  Gerencia de los interesados (stakeholders) 40
Identificación de los interesados del proyecto 41
Gestión de los interesados 44
2.3  Estructura organizacional 46
2.4  Formas de estructura organizacional 47
Organizaciones funcionales 48
Organizaciones basadas en proyectos 50
Organizaciones matriciales 52
Moverse hacia una organización basada en proyectos pesos pesados 54
■■INVESTIGACIÓN DE GERENCIA DE PROYECTOS EN SÍNTESIS: el efecto de la estructura
organizacional en los resultados de los proyectos 55
2.5  Oficinas de gerencia de proyectos 56
2.6  Cultura organizacional 59
¿Cómo se forman las culturas? 61
Cultura organizacional y gerencia de proyectos 62
v
vi Contenido

PERFIL DE PROYECTO: una cultura de la atención —Sanofi-Aventis y su compromiso con


la asistencia médica mundial 64
Resumen 65
Términos clave 66
Preguntas para discusión 67
Estudio de caso 2.1 Rolls-Royce Corporation 67
Estudio de caso 2.2 Caso clásico: el paraíso perdido — Xerox Alto 68
Estudio de caso 2.3 Estimación de tareas del proyecto y de la cultura
“¡Te atrapé!” 69
Estudio de caso 2.4 Widgets ’R Us 70
Ejercicios en internet 70
Preguntas de ejemplo del examen para la certificación PMP® 70
Proyecto integrado. Construya su plan de proyecto 71
Notas 73

Capítulo 3 Selección de proyectos y gerencia del portafolio 75


PERFIL DE PROYECTO: los procedimientos de selección de proyectos en varias
industrias 76
Introducción 77
3.1  Selección de proyectos 77
3.2  Enfoques para el screening y selección de proyectos 79
Método uno: modelo lista de verificación 79
Método dos: modelo de puntuación simplificado 81
Limitaciones de los modelos de puntuación 83
Método tres: el proceso de jerarquía analítica 84
Método cuatro: modelos de perfil 87
3.3  Modelos financieros 89
Periodo de recuperación 90
Valor presente neto 92
Periodo de recuperación descontado 93
Tasa interna de retorno 94
Modelo de opciones 96
La elección de un enfoque de selección de proyectos 96
PERFIL DE PROYECTO: screening y selección de proyectos en GE —El proceso Tollgate 97
3.4  Gerencia del portafolio de proyectos 98
Objetivos e iniciativas 99
El desarrollo de un portafolio proactivo 100
Claves para la gerencia exitosa de portafolios de proyectos 102
Problemas en la implementación de la gerencia del portafolio 102
Resumen 103
Términos clave 105
Problemas resueltos 105
Preguntas para discusión 106
Estudio de caso 3.1 Keflavik Paper Company 109
Estudio de caso 3.2 Selección de proyectos en Nova Western, Inc. 110
Ejercicios en internet 112
Notas 112

Capítulo 4 Liderazgo y el gerente de proyectos 114


PERFIL DE PROYECTO: Aziza Chaouni y su proyecto para salvar un río 115
Introducción 116
Contenido vii

4.1  Líderes versus gerentes 117


4.2  Cómo lidera un gerente de proyecto s 118
Adquisición de recursos del proyecto 118
Motivación y creación de equipos 119
Tener visión y luchar contra los incendios 119
Comunicación 120
■■INVESTIGACIÓN DE GERENCIA DE PROYECTOS EN SÍNTESIS: liderazgo e inteligencia
emocional 122
4.3  Características de los líderes efectivos de proyectos 123
Conclusiones acerca de los líderes de proyectos 124
PERFIL DE PROYECTO: Dr. Elattuvalapil Sreedharan, gerencia de proyecto de estrella del
rock en India 124
Liderazgo y orientación temporal 126
4.4  Campeones de proyectos 127
Campeones: ¿quiénes son? 128
¿Qué hacen los campeones? 129
Cómo hacer un campeón 130
■■GERENTES DE PROYECTOS EN LA PRÁCTICA: Bill Mowery, CSC 131
4.5  El nuevo liderazgo de proyectos 132
PERFIL DE PROYECTO: el reto de la gerencia internacional 133
4.6  Profesionalismo en la gerencia de proyectos 134
Resumen 136
Términos clave 137
Preguntas para discusión 137
Estudio de caso 4.1 En busca de gerentes de proyectos efectivos 138
Estudio de caso 4.2 Encontrar la inteligencia emocional
para ser un verdadero líder 138
Estudio de caso 4.3 Problemas con John 139
Ejercicios en internet 142
Preguntas de ejemplo del examen para la certificación PMP® 142
Notas 143

Capítulo 5 Gerencia del alcance 145


PERFIL DE PROYECTO: Caso—El vehículo expedicionario de combate 146
Introducción 148
5.1  Desarrollo conceptual 149
Declaración del trabajo 151
5.2  Declaración del alcance 153
Estructura de desglose del trabajo 154
Propósitos de la estructura de desglose del trabajo 155
Estructura de desglose de la organización 160
Matriz de asignación de responsabilidades 162
PERFIL DE PROYECTO: definición de un paquete de trabajo del proyecto 164
5.3  Autorización de trabajo 164
5.4  Reporte del alcance 165

■INVESTIGACIÓN DE GERENCIA DE PROYECTOS EN SÍNTESIS: tecnología
de la información (IT) en el proyecto “Marchas de la muerte”: ¿qué está pasando
aquí? 166
5.5  Sistemas de control 168
Gerencia de la configuración 168
viii Contenido

5.6  Cierre del proyecto 170


Resumen 171
Términos clave 172
Preguntas para discusión 173
Problemas 173
Estudio de caso 5.1 Frontera virtual de Boeing 173
Estudio de caso 5.2 Proyecto del tren de alta velocidad de California 175
Estudio de caso 5.3 Gerencia de proyectos en Dotcom.com 177
Estudio de caso 5.4 Caso clásico: el Ford Edsel 177
Ejercicios en internet 181
Preguntas de ejemplo del examen para la certificación PMP® 181
Ejercicios con MS Project 181
Proyecto integrado. Desarrollo de la estructura de desglose del
trabajo (EDT) 182
Notas 184

Capítulo 6 Conformación del equipo del proyecto, conflicto y negociación 186


PERFIL DE PROYECTO: control de la fuga de un pozo de petróleo—Respuesta al desastre
de la BP 187
Introducción 190
6.1  Conformación del equipo del proyecto 190
Identificar el conjunto de habilidades necesarias 190
Identificar a las personas que cuentan con las habilidades 191
Hablar con los miembros poteciales del equipo y negociar con los jefes
funcionales 192
Crear planes alternativos 192
Conformar el equipo 193
6.2  Características de los equipos efectivos de proyectos 193
Claro sentido de la misión 193
Interdependencia productiva 194
Cohesión 194
Confianza 194
Entusiasmo 195
Orientación a los resultados 195
6.3  Razones por las cuales los equipos fracasan 195
Metas poco desarrolladas o poco claras 196
Funciones e interdependencias del equipo del proyecto mal definidas 196
Falta de motivación del equipo del proyecto 196
Comunicación deficiente 197
Liderazgo deficiente 197
Rotación de los miembros del equipo del proyecto 197
Comportamiento disfuncional 198
6.4  Etapas en el desarrollo del grupo 198
Etapa uno: formación 199
Etapa dos: adaptación 199
Etapa tres: asimilación 199
Etapa cuatro: desempeño 199
Etapa cinco: terminación 199
Equilibrio intermitente 200
Contenido ix

6.5  Lograr la cooperación interfuncional 201


Metas de orden superior 201
Normas y procedimientos 202
Proximidad física 202
Accesibilidad 202
Resultados de la cooperación: tarea y resultados psicosociales 203
6.6  Equipos de proyectos virtuales 203
PERFIL DE PROYECTO: la tecnología de teleinmersión facilita la utilización de equipos
virtuales 205
6.7  Gerencia del conflicto 206
¿Qué es conflicto? 206
Fuentes de conflicto 207
Métodos para resolver conflictos 209
6.8  Negociación 210
Preguntas que se deben formular antes de negociar 211
Negociación basada en principios 211
Búsqueda de opciones de ganancia mutua 213
Insistencia en el uso de criterios objetivos 214
Resumen 215
Términos clave 216
Preguntas para discusión 216
Estudio de caso 6.1 Columbus Instruments 217
Estudio de caso 6.2 El contador y los vaqueros 218
Estudio de caso 6.3 Johnson & Rogers Software Engineering, Inc. 219
Ejercicios de negociación 220
Ejercicios en internet 222
Preguntas de ejemplo del examen para la certificación PMP® 222
Notas 223

Capítulo 7 Gerencia del riesgo 225


PERFIL DE PROYECTO: Caso—Ayuda en el terremoto de Haití 226
Introducción 228

■GERENTES DE PROYECTOS EN LA PRÁCTICA: Mohammed Al-Sadiq, de Saudi
Aramco Oil Company 229
7.1  Gerencia del riesgo: un proceso de cuatro etapas 231
Identificación del riesgo 231
Análisis de probabilidad y de consecuencias 233
Estrategias de mitigación de riesgo 236
Uso de reservas para las contingencias 238
Otras estrategias de mitigación 239
Control y documentación 239
PERFIL DE PROYECTO: Caso—Colapso de un edificio de apartamentos en Shanghái 241
7.2  Gerencia de los riesgos del proyecto: un enfoque integrado 243
Resumen 245
Términos clave 246
Problema resuelto 246
Preguntas para discusión 246
Problemas 246
Estudio de caso 7.1 Caso clásico: la caída del Comet de Havilland 247
Estudio de caso 7.2 Caso clásico: el puente colgante de Tacoma Narrows 250
Ejercicios en internet 252
x Contenido

Preguntas de ejemplo del examen para la certificación PMP® 252


Proyecto integrado. Evaluación de los riesgos del proyecto 254
Notas 256

Capítulo 8 Estimación de costos y presupuesto 257


PERFIL DE PROYECTO: los sobrecostos persiguen a los proyectos importantes 258
8.1  Gerencia de costos 260
Costos directos versus costos indirectos 261
Costos recurrentes versus costos no recurrentes 263
Costos fijos versus costos variables 263
Costos normales versus costos acelerados 263
8.2  Estimación de costos 264
Curvas de aprendizaje en la estimación de costos 267

■INVESTIGACIÓN DE GERENCIA DE PROYECTOS EN SÍNTESIS: estimación de
costos de desarrollo de software 271
Estimación de proyectos de software—Puntos de función 271
Problemas en la estimación de costos 273

■INVESTIGACIÓN DE GERENCIA DE PROYECTOS EN SÍNTESIS: ”Engaños y
decepciones” en los grandes proyectos de infraestructura 275
8.3  Creación de presupuesto de un proyecto 276
Presupuestación arriba abajo (top-down) 276
Presupuestación abajo arriba (bottom-down) 277
Costeo basado en actividades 277
8.4  Contingencias en el desarrollo del presupuesto 279
Resumen 281
Términos clave 283
Problemas resueltos 283
Preguntas para discusión 285
Estudio de caso 8.1 La central eléctrica de Dulhasti 287
Estudio de caso 8.2 Proyecto Central Artery/Tunnel de Boston 288
Ejercicios en internet 290
Preguntas de ejemplo del examen para la certificación PMP® 290
Proyecto integrado. Desarrollo de las estimaciones de costos y
presupuesto 292
Notas 294

Capítulo 9 Programación del proyecto. Redes, estimación de la duración y ruta


crítica 295
PERFIL DE PROYECTO: Sudáfrica tiene los estadios listos para la Copa Mundo 2010 296
Introducción 298
9.1  Programación del proyecto 298
9.2  Terminología clave en la programación del proyecto 300
9.3  Desarrollo de una red 301
Etiquetado de nodos 302
Actividades en serie 303
Actividades concurrentes 303
Actividades convergentes 304
Actividades divergentes 304
9.4  Estimación de la duración 307
9.5  Construcción de la ruta crítica 311
Cálculo de la red 311
Contenido xi

Recorrido hacia adelante 312


Recorrido hacia atrás 314
Probabilidad de terminación del proyecto 316
Actividades de escalamiento 318
Actividades resumen 319
Opciones para reducir la ruta crítica 320

■INVESTIGACIÓN DE GERENCIA DE PROYECTOS EN SÍNTESIS: retrasos y
soluciones en el desarrollo de software 321
Resumen 321
Términos clave 323
Problemas resueltos 323
Preguntas para discusión 324
Problemas 325
Ejercicios en internet 326
Ejercicios con MS Project 327
Preguntas de ejemplo del examen para la certificación PMP® 327
Notas 328

Capítulo 10 Programación del proyecto. Retraso, compresión y redes de


actividades 330
PERFIL DE PROYECTO: Dreamliner 787 de Boeing: problemas en su lanzamiento 331
Introducción 333
10.1  Retraso en las relaciones de precedencia 333
Final a inicio 333
Final a final 334
Inicio a inicio 334
Inicio a final 335
10.2 Diagramas de Gantt 336
Adición de recursos a los diagramas de Gantt 337
Incorporación de retrasos en los diagramas de Gantt 338

■GERENTES DE PROYECTOS EN LA PRÁCTICA: Mayor Julia Sweet, Ejército de
Estados Unidos 339
10.3  Análisis de comprensión del proyecto 340
Opciones para acelerar los proyectos 340
Efectos en el presupuesto de comprimir el proyecto 347
10.4  Redes de actividad en la flecha 348
¿Qué tan diferentes son? 349
Actividades dummy 351
Pasos hacia adelante y hacia atrás en redes AOA 352
AOA versus AON 353
10.5 Controversias en el uso de las redes 354
Conclusiones 356
Resumen 356
Términos clave 357
Problemas resueltos 357
Preguntas para discusión 358
Problemas 358
Estudio de caso 10.1 Programación de proyectos en Blanque Cheque
Construction (A) 359
xii Contenido

Estudio de caso 10.2 Programación de proyectos en Blanque Cheque


Construction (B) 360
Ejercicios con MS Project 361
Preguntas de ejemplo del examen para la certificación PMP® 361
Proyecto integrado. Desarrollo del cronograma del proyecto 363
Notas 366

Capítulo 11 Programación de proyectos con cadena crítica 367


PERFIL DE PROYECTO: Suiza celebra la finalización del túnel más largo del mundo 368
Introducción 370
11.1 La teoría de las restricciones y la programación de proyectos con cadena
crítica 370
Teoría de las restricciones 370
Causas comunes y especiales de la variación 371
11.2  CCPM Y LAS CAUSAS DE RETRASOS DEL PROYECTO 374
Método uno: sobreestimación de la duración de las actividades
individuales 374
Método dos: margen de seguridad del gerente de proyectos 374
Método tres: anticiparse a los recortes esperados de la alta gerencia 375
11.3  Cómo los equipos de proyectos desperdician la seguridad extra adquirida 375
Método uno: síndrome del estudiante 375
Método dos: falla al omitir la variación positiva 376
Método tres: consecuencias negativas de la multitarea 376
Método cuatro: demora por caminos con actividades convergentes 377
11.4 Cadena crítica: una solución para la programación del proyecto 378
Desarrollo de la red de actividades de cadena crítica 380
Soluciones de cadena crítica versus soluciones de ruta crítica 382
PERFIL DE PROYECTO: Eli Lilly Pharmaceuticals y su compromiso con la gerencia de
proyectos con cadena crítica 384
11.5  Soluciones de cadena crítica a los conflictos de recursos385
11.6  Gerencia del portafolio de proyectos con cadena crítica 386

■INVESTIGACIÓN DE GERENCIA DE PROYECTOS EN SÍNTESIS: ventajas de la
programación con cadena crítica 389
11.7  Críticas a la CCPM 390
Resumen 390
Términos clave 392
Problemas resueltos 392
Preguntas para discusión 393
Problemas 393
Estudio de caso 11.1 Judy, a la caza de la honestidad 396
Estudio de caso 11.2 Ramstein Products, Inc. 396
Ejercicios en internet 397
Notas 397

Capítulo 12 Gerencia de recursos 399


PERFIL DE PROYECTO: Nissan LEAF —Nuevo campeón en economía de combustible 400
Introducción 401
12.1 Las bases de las restricciones de recursos 402
La escasez de tiempo y de recursos 402
12.2 Carga de recursos 404
Contenido xiii

12.3 Nivelación de recursos 406


Paso uno: desarrollar el cuadro de carga de recursos 410
Paso dos: determinar los finales tardíos de las actividades 411
Paso tres: identificar sobreasignación de recursos 412
Paso cuatro: nivelar el cuadro de carga de recursos 412
12.4 Diagramas de carga de recursos 415

■GERENTES DE PROYECTOS EN LA PRÁCTICA: Capitán Kevin O’Donnell,
U.S. Marine Corps 418
12.5 Gerencia de recursos en entornos multiproyecto 420
Retrasos en el cumplimiento del cronograma 420
Utilización de recursos 420
Inventario en proceso 420
Decisiones de recursos en entornos multiproyecto 421
Resumen 423
Términos clave 424
Problemas resueltos 424
Preguntas para discusión 424
Problemas 425
Estudio de caso 12.1 Los problemas de la multitarea 426
Ejercicios con MS Project 427
Preguntas de ejemplo del examen para la certificación PMP® 427
Proyecto integrado. Gerencia de los recursos de su proyecto 429
Notas 429

Capítulo 13 Evaluación y control de proyectos 430


PERFIL DE PROYECTO: Caso—New Zeland’s Te Apiti Wind Farm— Éxito bajo presión 431
Introducción 432
13.1 Ciclos de control: un modelo general 433
13.2 Monitorear el desempeño del proyecto 434
Curva S del proyecto: una herramienta básica 434
Inconvenientes de la curva S 435
Análisis de hitos 436
Problemas con los hitos 437
Diagrama de Gantt de seguimiento 438
Ventajas y desventajas de los diagramas Gantt de seguimiento 438
13.3 Gerencia del valor ganado 439
Terminología del valor ganado 440
Creación de las líneas de base del proyecto 440
¿Por qué utilizar el valor ganado? 441
Pasos en la gerencia del valor ganado 443
Evaluación del valor ganado del proyecto 444
13.4 Aplicación del valor ganado a la gerencia del portafolio de proyectos 447
PERFIL DE PROYECTO: valor ganado en Northrop Grumman 448
13.5 Problemas del uso efectivo de la gerencia del valor ganado 449
13.6 Factores humanos en la evaluación y el control de proyectos 451
Definición de los factores claves de éxito 453
Conclusiones 454
Resumen 455
xiv Contenido

Términos clave 456


Problema resuelto 456
Preguntas para discusión 457
Problemas 458
Estudio de caso 13.1 El Departamento de IT de la Kimble College 459
Estudio de caso 13.2 El superconductor Supercollider 460
Ejercicios en internet 462
Ejercicios con MS Project 462
Preguntas de ejemplo del examen para la certificación PMP® 463
Apéndice 13.1 Cronograma ganado 464
Notas 469

Capítulo 14 Cierre y terminación del proyecto 470


PERFIL DE PROYECTO: Caso—New Jersey cancela el proyecto Hudson River Tunnnel 471
Introducción 472
14.1  Tipos de terminación del proyecto 473

■GERENTES DE PROYECTO EN LA PRÁCTICA: Mike Brown, de Rolls-Royce Plc 473
14.2  Terminación natural—El proceso de cierre 475
Finalizar el trabajo 475
Entregar el proyecto 476
Obtener la aceptación del proyecto 476
Cosechar los beneficios 476
Revisar cómo fue todo 477
Archivar registros y documentos 478
Disolver el equipo 479
¿Qué impide los cierres efectivos de proyectos? 479
14.3 Terminación anticipada de proyectos 484
Tomar la decisión de terminación anticipada 486
PERFIL DE PROYECTO: Caso—El cierre de la Zion Nuclear Plant 487
Terminación del proyecto 488

■INVESTIGACIÓN DE GERENCIA DE PROYECTOS EN SÍNTESIS: terminación de
proyectos en la industria IT 490
Permitir reclamaciones y disputas 491
14.4 Preparación del informe final del proyecto 492
Conclusión 494
Resumen 494
Términos clave 495
Preguntas para discusión 495
Estudio de caso 14.1 Proyecto Libra: terminar o no terminar 495
Estudio de caso 14.2 El proyecto que no podía morir 496
Estudio de caso 14.3 La Armada cancela el desarrollo de su buque de
guerra estrella 497
Ejercicios en internet 498
Preguntas de ejemplo del examen para la certificación PMP® 498
Notas 499
Apéndice A 501
Apéndice B 503
Glosario 513
Índice de compañías 527
Índice de nombres 529
Índice analítico 533
PREFACIO

La gerencia de proyectos se ha convertido en el centro de operaciones en industrias tan diversas como la cons-
trucción, tecnologías de la información, la arquitectura, la hotelería, la ingeniería y el desarrollo de nuevos pro-
ductos. Por esta razón, este libro incluye al mismo tiempo los principios generales de la gerencia de proyectos y
sus ejemplos específicos, mediante una gran variedad de aplicaciones. Además, desarrolla cada capítulo desde
lo más general para todas las disciplinas y tipos de proyectos hasta lo más específico en formas alternativas de
proyectos. Esto se logra a través de ejemplos concretos, basados en disciplinas del conocimiento para ilustrar
los principios generales, así como en la inclusión de casos y perfiles de proyectos que se centran en temas más
específicos (por ejemplo, el tratamiento del capítulo 5 sobre proyectos de IT “Marchas de la muerte”).
En las clases de gerencia de proyectos, los estudiantes proceden de diversas carreras universitarias
y currículos. Escuelas de salud, negocios, arquitectura, ingeniería, sistemas de información y hotelería
agregan cursos de gerencia de proyectos a sus catálogos, en respuesta a las demandas de las organizaciones
y los grupos profesionales que ven su valor en las carreras y desempeños futuros de los estudiantes. ¿Por
qué la gerencia de proyectos se ha convertido en una disciplina de tanto interés y aplicación? La verdad
es que vivimos en un mundo “orientado a los proyectos”. Dondequiera que miremos, muchas personas
participan en gerencia de proyectos. De hecho, la gerencia de proyectos forma parte integral del modelo
de negocio de la empresa.
Con su enfoque holístico e integrado en gerencia de proyectos, la exploración de desafíos técnicos y de
gestión, este libro no solo hace hincapié en la ejecución de proyectos individuales, sino que también propor-
ciona una perspectiva estratégica, pues describe los medios con los cuales se pueden gerenciar programas de
proyectos y de portafolios.
En un tiempo, la gerencia de proyectos era casi exclusivamente propiedad de los programas de ingeniería
civil y de construcción, en los que se enseñaba de una manera altamente cuantitativa y técnica. Una vez argu-
mentamos: “Domine la ciencia de la gerencia de proyectos”, una vez discutimos, “y el ‘arte’ de la gerencia de
proyectos será igualmente claro para usted”. La gerencia de proyectos es hoy un desafío complejo y de “geren-
cia”, que requiere no solo conocimientos técnicos sino también un amplio conjunto de habilidades basadas en
competencias. La gerencia de proyectos se ha convertido en la gerencia de la tecnología, de las personas, de la
cultura, de los interesados (stakeholders) y de otros elementos necesarios para completar con éxito un proyecto.
Requiere conocimiento de liderazgo, trabajo en equipo, resolución de conflictos, negociación e influencia, en
la misma medida que el conjunto de habilidades técnicas tradicionales. Por tanto, este libro amplía nuestro
enfoque más allá de las actividades de gerencia de proyectos tradicionales de planeación, programación, control
de proyectos y su terminación a una perspectiva más general, incluso, más valiosa del proceso de gerencia de
proyectos.

¿QUÉ ES LO NUEVO EN LA TERCERA EDICIÓN?


Nuevas características
• Proyecto “Marchas de la muerte”
• Cronograma ganado
• Tutoriales paso a paso de MS Project 2010
• Programación de proyectos en condiciones de incertidumbre, probabilidad de terminación del proyecto
• Nuevos gerentes de proyecto en los perfiles de práctica
• Estimación de costos de proyectos de IT por puntos funcionales
• Seguimiento rápido y otras opciones para acelerar proyectos
• Problemas actualizados en los diferentes capítulos
• Cuatro casos “clásicos” de proyectos
• Nuevo en investigación de gerencia de proyectos en síntesis: “engaños y decepciones” en los grandes
proyectos de infraestructura
• Todos los ejemplos de MS Project y capturas de pantalla actualizados a MS Project 2010
• Actualizaciones trimestrales para todos los usuarios del libro sobre los últimos casos y ejemplos en
gerencia de proyectos

xv
xvi Prefacio

Perfiles de proyectos actualizados


• Capítulo 1 Introducción. ¿Por qué la gerencia de proyectos?
• Rescate de los mineros chilenos
• Proyectos en China: motivación del entorno innovador
• Capítulo 2 El contexto organizacional. Estrategia, estructura y cultura 
• El Ejército de Estados Unidos regresa a la era de los dirigibles no rígidos
• Una cultura de servicio: Sanofi-Aventis y su compromiso con la asistencia médica mundial
• Capítulo 3 Selección de proyectos y gerencia del portafolio 
• Los procedimientos de selección de proyectos en varias industrias
• Capítulo 4 Liderazgo y el gerente de proyectos
• Aziza Chaouni y su proyecto para salvar un río
• Dr. Elattuvalapil Sreedharan, gerencia de proyecto de estrella del rock en India
• Capítulo 5 Gerencia del alcance 
• El vehículo expedicionario de combate
• Frontera virtual de Boeing
• Proyecto del tren de alta velocidad de California
• Capítulo 6 Conformación del equipo del proyecto, conflicto y negociación 
• Control de la fuga de un pozo de petróleo—Respuesta al desastre de la BP
• Capítulo 7 Gerencia del riesgo 
• Ayuda en el terremoto de Haití
• Colapso de un edificio de apartamentos en Shanghái
• Capítulo 8 Estimación de costos y presupuesto 
• Los sobrecostos persiguen a los proyectos importantes
• Capítulo 9 Programación del proyecto. Redes, estimación de la duración y ruta crítica 
• Sudáfrica tiene los estadios listos para la Copa Mundo 2010
• Capítulo 10 Programación del proyecto. Retraso, compresión y redes de actividades  
• Dreamliner 787 de Boeing: problemas en su lanzamiento
• Capítulo 11 Programación de proyectos con cadena crítica 
• Suiza celebra la finalización del túnel más largo del mundo
• Eli Lilly Pharmaceuticals y su compromiso con la gerencia de la cadena crítica del proyecto
• Capítulo 12 Gerencia de recursos 
• Nissan LEAF: —Nuevo campeón en economía de combustible
• Capítulo 13 Evaluación y control de proyectos 
• New Zeland’s Te Apiti Wind Farm—Éxito bajo presión
• Capítulo 14 Cierre y terminación del proyecto 
• New Jersey cancela proyecto Hudson River Tunnel
• El cierre de la Zion Nuclear Plant

NUESTRO ENFOQUE
El enfoque de gerencia del libro se dirige a los negocios orientados a la gerencia de proyectos. Por tanto,
hemos integrado perfiles de proyecto en el libro.
• Perfiles de proyecto—Cada capítulo contiene uno o más perfiles de proyectos que ponen de relieve
ejemplos actuales de la gerencia de proyectos en acción. Algunos de los perfiles reflexionan sobre logros
significativos; otros detallan ejemplos famosos (y no tan famosos) de fracasos de proyectos. Debido a
que estos cubren diversos terrenos (proyectos de IT, construcción, desarrollo de nuevos productos, y
así sucesivamente), debe haber al menos un perfil significativo por capítulo para el enfoque de la clase.
El libro combina la gerencia de proyectos en el contexto de las operaciones de cualquier organización exitosa, ya
sea del sector público, privado o sin ánimo de lucro. Esto se ilustra mediante el uso de casos al final del capítulo.
Prefacio xvii

• Casos—Al final de cada capítulo hay casos con ejemplos específicos del contenido del capítulo y se
aplican en el formato alternativo de estudio de caso. Algunos son ficticios, pero la mayoría de ellos se
basan en situaciones reales, incluso cuando los alias enmascaran los verdaderos nombres de las organi-
zaciones. Estos casos incluyen preguntas para discusión que pueden utilizarse para hacer la tarea o para
facilitar los debates en clase.
Además, se exploran los retos en la gerencia de los proyectos individuales, así como la ampliación de este
contexto para incluir conceptos estratégicos en el portafolio. Para ello, les pedimos a los estudiantes desarro-
llar un plan de proyecto con MS Project 2010.

• Ejercicios de proyecto integrado—Muchos de los capítulos incluyen, al final, una característica única
en este libro: la oportunidad de desarrollar un plan detallado de proyecto. Un ejercicio muy beneficioso
en las clases de gerencia de proyectos es exigirles a los estudiantes, ya sea en equipos o individualmente,
aprender la mecánica del desarrollo de un plan de proyecto detallado y comprensivo, la cual involucra
el alcance, la programación, la evaluación de riesgos, la presupuestación y la estimación de costos, y
así sucesivamente. Los ejercicios de proyecto integrado les ofrecen a los estudiantes la oportunidad de
desarrollar un plan de este tipo mediante la asignación de estas actividades y proporcionar un ejemplo
detallado y completo en cada capítulo. Por tanto, a los estudiantes se les asignan sus actividades de
planeación de proyecto y cuentan con una plantilla que ayuda a completar estos ejercicios.

Por último, hemos integrado las normas establecidas por el órgano de gobierno más importante del mundo
para la gerencia de proyectos. El Project Management Institute (PMI) creó el Cuerpo de conocimientos de la
gerencia de proyectos (Project Management Body of Knowledge: PMBOK), el cual se considera uno de los
marcos más amplios para la identificación de las áreas críticas de conocimiento que los gerentes de proyec-
tos deben entender para dominar su disciplina. El PMBOK se ha convertido en la base para la certificación
Project Management Professional (PMP) ofrecida por el PMI para gerentes de proyectos profesionales.

• Integración con el PMBOK —Como un medio para demostrar la cobertura de los elementos críticos
del PMBOK, los lectores encontrarán en los capítulos referencias a las áreas de conocimiento corres-
pondientes del PMBOK. Además, todos los términos (incluidos en el glosario) se toman directamente
de la edición más reciente del PMBOK.
• Inclusión de preguntas de ejemplo del examen de certificación PMP—La certificación Project
Management Professional (PMP) representa el más alto nivel de cualificación profesional de un gerente
de proyectos en ejercicio, y es administrado por el PMI. A principios de 2012, había más de 400,000 PMP
en todo el mundo. Con el fin de obtener la certificación PMP, se requiere que los candidatos se sometan a
un examen que pone a prueba su conocimiento de todos los componentes del PMBOK. Este libro incluye
una serie de preguntas del examen de certificación PMP al final de la mayoría de los capítulos, con el fin
de darles a los lectores una idea de los tipos de preguntas que normalmente se formulan en el examen y
cómo se tratan estos temas en este libro.

OTROS PUNTOS SOBRESALIENTES


El libro hace énfasis en la mezcla de teoría actual, práctica, investigación y los estudios de casos, para sumi-
nistrarles a los lectores una perspectiva múltiple del proceso de gerencia de proyectos. En los capítulos, las
siguientes características mejoran el aprendizaje del estudiante:

• Ejercicios con MS Project—Al final de cada capítulo, algunos ejemplos de problemas o actividades
requieren generar archivos MS Project. Por ejemplo, en el capítulo dedicado a la programación, los
estudiantes deben crear un diagrama de Gantt y un diagrama de red con MS Project. Del mismo modo,
otros informes pueden asignarse para ayudar a los estudiantes a ser mínimamente hábiles para inte-
ractuar con este programa. El propósito de este libro no es desarrollar plenamente estas competencias,
sino más bien sembrar las semillas para futuras aplicaciones.
• Investigación de gerencia de proyectos en síntesis—Los breves recuadros de texto (generalmente de
una página) destacan los resultados deinvestigaciones actuales sobre los temas de interés. Los estu-
diantes a menudo encuentran útil leer acerca de estudios reales que ponen de relieve el material del
libro y proporcionan información adicional que amplía su aprendizaje. Aunque no todos los capítulos
incluyen un recuadro de “Investigación de gerencia de proyectos en síntesis”, la mayoría tiene uno y,
en algunos casos, dos ejemplos de este recurso.
xviii Prefacio

• Gerentes de proyectos en la práctica—Se incluyen varios perfiles reales de la práctica de los gerentes
de proyectos a partir de una variedad de entornos empresariales y de proyectos. Estos perfiles se aña-
dieron para darles a los estudiantes una idea de los tipos de desafíos del mundo real que enfrentan los
gerentes de proyectos de manera rutinaria, la amplia gama de proyectos que aquellos están llamados a
gerenciar y las satisfacciones y oportunidades de carrera disponibles para los estudiantes interesados
en seguir la gerencia de proyectos como carrera.
• Ejercicios en internet—Cada capítulo contiene una serie de ejercicios en internet que les exige a los
estudiantes ingresar en la web para obtener información clave, acceder a las lecturas del curso en el
sitio web del libro y realizar otras actividades que les permiten a los estudiantes aprender fuera del
salón de clases. Los ejercicios en internet son un complemento útil, particularmente en el área de
gerencia de proyectos, ya que gran parte de la información relacionada con proyectos está disponible
en la web, incluyendo casos, noticias y herramientas basadas en internet para el análisis de actividades
de proyectos.

PARA LOS DOCENTES


Los siguientes suplementos están disponibles para los profesores que tomen este libro como texto guía:

Centro de recursos del docente


Register.Redeem.Login, www.pearsonhighered.com/irc, donde los profesores pueden acceder a una varie-
dad de recursos impresos, mediáticos y presentaciones que están disponibles con este libro en formato digital
para descargar. En la mayoría de los textos, los recursos también están disponibles para las plataformas de
administración de cursos como Blackboard, WebCT, y Course Compass.

¿Necesita ayuda?
Nuestro dedicado equipo de asistencia técnica está listo para ayudar a los docentes y resolver preguntas
acerca de los suplementos que acompañan a este libro. Visite http://247pearsoned.custhelp.com/ y marque
los números gratuitos de teléfono de soporte al usuario para obtener respuestas a las preguntas más fre-
cuentes. Los siguientes suplementos están disponibles para los docentes. Las descripciones detalladas de los
siguientes suplementos se proporcionan en el Instructor’s Resource Center:

Instructor’s Solutions Manual—Preparado por Jeffrey K. Pinto, de la Pennsylvania State University, el


Instructor’s Solutions Manual del docente contiene resúmenes de los capítulos y las respuestas sugeridas
a todas las preguntas de final de capítulo. Está disponible para descargar en www.pearsonhighered.com/
pinto.
Test Item File—Preparado por el profesor Geoff Willis de la University of Central Oklahoma. El
Test Item File contiene preguntas tipo verdadero/falso, preguntas de tipo llenar espacios en blanco,
preguntas de opción múltiple y preguntas de respuesta corta/ensayo. Está disponible para descargar en
www.pearsonhighered.com/pinto.
TestGen—Software de generación de pruebas de Pearson Educación está disponible en www.pearson-
highered.com/irc. El software es compatible con PC/MAC y está precargado con todo el Test Item File
Cuestions. Las preguntas de prueba se pueden ver de forma manual o al azar, además, se pueden arras­
trar y soltar para crear una prueba. Se pueden añadir o modificar preguntas del banco de pruebas, según
se requiera.
Learning Management Systems—Nuestros TestGens se pueden convertir para usar en Blackboard y
WebCT. Estas conversiones están disponibles en el Instructor’s Resource Center. Las conversiones a
D2L o Angel se pueden solicitar a través del representante de ventas local de Pearson.
Presentaciones de PowerPoint—Preparadas por Dana Johnson, de la Michigan Technological University,
las presentaciones de PowerPoint proporcionan al docente esquemas de clases para acompañar el libro. En
las presentaciones se incluyen muchas de las figuras y cuadros del libro. Estos esquemas se pue­den utilizar
como están o los docentes pueden modificarlas fácilmente, de acuerdo con sus necesidades específicas de
presentación. Están disponibles para su descarga en www.pearsonhighered.com/pinto.
Project Management Simulation Games—Creado por Ken Klassen (Brock University) y Keith Willoughby
(consultor), está disponible para su descarga en www.pearsonhighered.com/pinto. Se utiliza para
Prefacio xix

proporcionar una introducción amena y didáctica al tema de la gerencia de proyectos. También se


puede utilizar como un ejercicio independiente para enseñar sobre incertidumbre. Además de las
notas para los estudiantes y las notas para el docente (ambas en Word) para el juego, se proporciona
una hoja de cálculo de Excel para seguir el progreso de los equipos. Esto facilita la administración del
juego en clase y mejora la experiencia de los estudiantes.

AGRADECIMIENTOS
Al reconocer las contribuciones de colegas del pasado y presente en la creación de este libro, primero debo
expresar mi profundo agradecimiento y reconocimiento por los 30 años de asociación con mi mentor inicial,
el doctor Dennis Slevin, de la Pittsburgh University, Katz Graduate School of Business. Mi colaboración con
Denny en numerosos proyectos ha sido fructífera y muy gratificante, tanto profesional como personal. Además,
la amistad y la colaboración del doctor David Cleland en varias empresas ha sido una gran fuente de satisfacción
a través de los años. Mentores adicionales y colegas que han influenciado fuertemente mi pensamiento incluyen
Samuel Mantel, Jr., Peter W. G. Morris, Rodney Turner, Erik Larson, David Frame, Francis Hartman, Jonas
Soderlund, Young Kwak, Rolf Lundin, Lynn Crawford, Graham Winch, Terry Williams, Francis Webster,
Terry Cooke -Davies, Hans Thamhain y Karlos Artto. Cada uno de ellos ha tenido un profundo impacto en la
manera en que yo veo, estudio y escribo sobre gerencia de proyectos.
Con los años, he tenido la suerte de desarrollar amistades con algunos gerentes de proyectos profe-
sionales cuyo trabajo admiro enormemente. Son ejemplos genuinos del mejor tipo de gerente de proyectos:
uno que hace que todo parezca fácil mientras se realizan constantemente pequeños milagros. En particular,
quiero dar las gracias a Mike Brown, de Rolls-Royce, por su amistad y ejemplo. También me gustaría dar
las gracias a los amigos y colegas de Project Management Institute (PMI), incluidos Lew Gedansky, Harry
Stephanou y Eva Goldman, por su apoyo e incidencia en este trabajo.
Estoy en deuda con los revisores de este libro cuyas sugerencias y críticas numerosas han sido una ayuda
inestimable en el desarrollo de su contenido. Entre ellos, me gustaría agradecer especialmente a los siguientes:
Ravi Behara—George Mason University
Jeffrey L. Brewer—Purdue University
Dennis Cioffi—George Washington University
David Clapp—Florida Institute of Technology
Bruce DeRuntz—Southern Illinois University at Carbondale
Ike Ehie—Kansas State University
Michael H. Ensby—Clarkson University
Lynn Fish—Canisius College
Linda Fried—University of Colorado, Denver
Mario Guimaraes—Kennesaw State University
Richard Gunther—California State University, Northridge
Kwasi-Amoako Gyampah—University of North Carolina, Greensboro
Gary Hackbarth—Iowa State University
Mamoon M. Hammad—George Washington University
Scott Robert Homan—Purdue University
John Hoxmeier—Colorado State University
Alex Hutchins—ITT Technical Institute
Robert Key—University of Phoenix
Homayoun Khamooshi—George Washington University
Dennis Krumwiede—Idaho State University
George Mechling—Western Carolina University
Julia Miyaoka—San Francisco State University
LaWanda Morant—ITT Technical Institute
Robert Morris—Florida State College at Jacksonville
xx Prefacio

Kenneth E. Murphy—Willamette University


John Nazemetz—Oklahoma State University
Patrick Penfield—Syracuse University
Ronald Price—ITT Techincal Institute
Ronny Richardson—Southern Polytechnic State University
John Sherlock—Iona College
Gregory Shreve—Kent State University
Randall G. Sleeth—Virginia Commonwealth University
Kimberlee Snyder—Winona State University
Jeff Trailer—California State University, Chico
Leo Trudel—University of Maine
Oya Tukel—Cleveland State University
Darien Unger—Howard University
Stephen Whitehead—Hilbert College
También me gustaría dar las gracias a mis colegas en la Samuel Black School of Business de la Penn State
University, The Behrend School. Además, Christie Quick ayudó a preparar el manual de soluciones del
docente y las ayudas para el estudiante, por lo cual le doy las gracias. Gracias especiales a Jeanette Case por
su ayuda en la preparación del documento final. Estoy especialmente en deuda con Ray Venkataraman,
quien comprobó la precisión del manual de soluciones del docente. Estoy muy agradecido por su tiempo y
esfuerzo, y cualquier error es de mi entera responsabilidad.
En el desarrollo de los casos de esta edición, tuve la suerte de establecer vínculos profesionales mara-
villosos con un gran número de personas. Andrea Finger y Kathleen Prihoda de Disney fueron maravi-
llosamente serviciales y me incluyeron en sus apretadas agendas para ayudarme en el desarrollo del caso
Expedition Everest de este libro. Stephanie Smith, Mohammed Al-Sadiq, Bill Mowery, Mike Brown, Julia
Dulce y Kevin O’Donnell me proporcionaron información muy valiosa sobre sus responsabilidades en sus
trabajos y lo que se necesita para ser un gerente de proyectos exitoso.
Por último, deseo expresar mi sincero agradecimiento a la gente de Prentice Hall por su apoyo al libro
durante su desarrollo, incluido Chuck Synovec, editor, y Mary Kate Murray, gerente del proyecto. Reservo
mi más profundo agradecimiento a Trish Nealon y Annie Puciloski por sus esfuerzos, cuyos desarrollos
y críticas a esta edición fueron honestos y dieron justo en el blanco (“Fieles son las heridas del que ama”,
Proverbios 27:6). También me gustaría dar las gracias a los demás miembros de Prentice Hall, al personal de
producción y marketing, incluidos Jami Minard, Clara Bartunek y Anand Natarajan.
Prefacio xxi

COMENTARIOS
El equipo a cargo del libro y yo apreciaríamos escucharlo. Háganos saber lo que piensa acerca de este libro
escribiendo a [email protected]. Por favor, incluya “Feedback about Pinto” en el asunto.
Si usted tiene preguntas relacionadas con este producto, por favor póngase en contacto con nuestro
departamento de servicio al cliente en línea en http://247pearsoned.custhelp.com.
Por último, es importante reflexionar sobre un asunto sobresaliente adicional al comenzar su estudio
de gerencia de proyectos: la mayoría de ustedes va a ejecutar un proyecto mucho antes de que se les den respon-
sabilidades de gerencia más amplias en sus organizaciones. Los gerentes de proyectos exitosos son el alma de
las organizaciones y les imprimen el sello de la eficiencia. ¡Le deseo muchos éxitos!

Jeffrey K. Pinto, Ph.D


Andrew Morrow and Elizabeth Lee Black Chair
Management of Technology
Samuel Black School of Business
Penn State, the Behrend College
[email protected]
CAPÍTULO

1
Introducción
¿Por qué la gerencia de proyectos?

Contenido del capítulo


PERFIL DE PROYECTO 1.5 MODELOS DE MADUREZ DE LA GERENCIA DE
Rescate de los mineros chilenos PROYECTOS
INTRODUCCIÓN 1.6 ELEMENTOS DEL PROYECTO Y ORGANIZACIÓN
1.1 ¿QUÉ ES UN PROYECTO? DEL LIBRO
Características generales de un proyecto Resumen
1.2 ¿POR QUÉ SON IMPORTANTES LOS PROYECTOS? Términos clave
Preguntas para discusión
PERFIL DE PROYECTO
Estudio de caso 1.1 Mega Tech Inc.
Proyectos en China: motivación del entorno innovador
Estudio de caso 1.2 El Departamento de IT de Hamelin
1.3 EL CICLO DE VIDA DE UN PROYECTO  Hospital
GERENTES DE PROYECTOS EN LA PRÁCTICA Estudio de caso 1.3 Expedición al Everest de Disney
Stephanie Smith, Westinghouse Electric Company Ejercicios en internet
1.4 FACTORES DETERMINANTES EN EL ÉXITO Preguntas de ejemplo del examen para la certificación PMP®
DE UN PROYECTO Notas
INVESTIGACIÓN DE GERENCIA DE PROYECTOS
EN SÍNTESIS
Evaluación del éxito de los proyectos de tecnología de la
información (IT)

Objetivos de aprendizaje
Al finalizar el capítulo el estudiante estará en capacidad de:
1. Comprender por qué la gerencia de proyectos está convirtiéndose en una práctica tan poderosa y
popular en los negocios.
2. Identificar las propiedades básicas de los proyectos, incluida su definición.
3. Comprender por qué la gerencia de proyectos eficaz es un reto.
4. Diferenciar entre las prácticas de la gerencia de proyectos y las más tradicionales, orientadas a las áreas
funcionales de los negocios.
5. Reconocer las motivaciones clave que inducen a las empresas a adoptar prácticas de gerencia de proyectos.
6. Comprender y explicar el ciclo de vida del proyecto, sus fases, y las actividades que normalmente
ocurren en cada fase del proyecto.
7. Entender el concepto éxito, incluidos varios modelos alternativos y diferentes definiciones de éxito.
1
2 Capítulo 1  • Introducción

8. Entender el propósito de los modelos de madurez en gerencia de proyectos y el proceso de evaluación


comparativa de las organizaciones.
9. Conocer las etapas relevantes de madurez, a través de las cuales las organizaciones evolucionan para
alcanzar la competencia en el uso de las técnicas de gerencia de proyectos.

CONCEPTOS BÁSICOS DE LOS FUNDAMENTOS PARA LA GERENCIA DE PROYECTOS


(PROJECT MANAGEMENT BODY OF KNOWLEDGE,PMBOK® GUIDE 5A. EDICIÓN)
CUBIERTOS EN ESTE CAPÍTULO
1. Definición de proyecto (PMBOK® Guide, 5a. edición , sección 1.2)
2. Definición de gerencia de proyectos (PMBOK® Guide, 5a. edición, sección 1.3)
3. Valor del negocio (PMBOK® Guide, 5a. edición, sección 1.6)
4. El papel del gerente de proyectos (PMBOK® Guide, 5a. edición, sección 1.6)
5. Éxito del proyecto (PMBOK® Guide, 5a. edición, sección 2.2.3)

El mundo adquiere valor únicamente por sus opuestos y perdura solo a través de la moderación; los extremis-
tas hacen el mundo fantástico, los moderados lo estabilizan.1

PERFIL DE PROYECTO

Caso – Rescate de los mineros chilenos


El 13 de octubre de 2011, el capataz Luis Urzúa descendió de la cápsula de rescate bajo atronadores aplausos y gritos de
“¡Viva Chile!”; él fue el último de 33 mineros rescatados después de 70 días atrapados bajo 2,000 pies de tierra y roca.
Después de que la mina colapsara, los mineros quedaron atrapados en los pozos más profundos: inicialmente perdieron
todo contacto con la superficie y dejaron al mundo en suspenso en cuanto a su suerte. Su descubrimiento y posterior
rescate es una historia de coraje, ingenio y, en definitiva, de uno de los proyectos más exitosos de los últimos tiempos.
El equipo de trabajo de la Minera de Oro y Cobre de San José, cercana a Copiapo al norte de Chile, laboraba
en su turno cuando de repente, el 5 de agosto de 2011, la tierra tembló y ocasionó que gran parte de los túneles
se derrumbaran y atraparan a los 33 mineros en uno de los talleres localizado en una galería inferior de la mina.
No obstante estar temporalmente seguros a media milla bajo tierra, solo tenían energía y comida para dos días.
Peor aún, no tenían medio alguno de comunicación con la superficie, por lo que su destino era un misterio para
la compañía y sus familiares. En estas condiciones, su objetivo principal era la simple supervivencia y hacer rendir
los escasos suministros de alimentos durante 17 días, hasta que la primera sonda de perforación llegó, después
de hacer un agujero en el techo del pozo en el que se hallaban atrapados. Una vez establecido el contacto con la
superficie y se dieron detalles de su condición, se organizó y realizó una gran operación de rescate.
El primer desafío fue mantener vivos a los mineros. Las primeras entregas de suministros se hicieron vía el angosto
conducto por medio del cual se había establecido comunicación con el pozo en el que se refugiaban los mineros. Estos
suministros incluían comida y agua, oxígeno, medicamentos, ropa y artículos de primera necesidad para la superviven-
cia, así como diversos elementos para ayudarles a los mineros a pasar al tiempo. Paralelamente, otros equipos de per-
sonas trabajaban para mantener alta la moral de los mineros por medio de la comunicación diaria y la entrega de los
mensajes de sus familias, entre tanto se formaron otros equipos para desarrollar un plan de rescate.
Los desafíos eran grandes. Los asuntos que debían resolverse de manera inmediata eran:

1. ¿Cómo localizar a los mineros?


2. ¿Con qué rapidez se puede perforar un túnel de evacuación hasta el lugar donde permanecían los mineros?
3. ¿Cómo hacer este túnel de forma segura?

Las galerías de la mina habían sufrido muchos daños en el temblor, por lo que cavar a través de estas hasta
llegar a los mineros habría tomado varios meses. Una operación de rescate a gran escala se concibió con el objetivo
de sacar a los mineros lo más rápido posible.
La compañía chilenoestadounidense Geotec Boyles Brothers, subsidiaria de Layne Christensen Company, identi-
ficó y coordinó los recursos críticos alrededor de todo el mundo. Dos empresas localizadas en el oeste de Pennsylvania,
con experiencia previa en derrumbes de minas en Suramérica se incorporaron al proyecto. Estas enviaron a través
de UPS, sin costo alguno, un taladro capaz de perforar túneles con el diámetro suficientemente grande para que los
Perfil de proyecto 3

mineros pudieran pasar. El taladro llegó a la mina en Chile en 48 horas. En total, UPS transportó hasta el sitio del res-
cate más de 50,000 libras de equipos especializados para la perforación. El diseño de la cápsula de rescate fue realizado
por Clinton Cragg, ingeniero de la NASA y ex capitán de submarino de la Marina de Guerra, quien dirigió un equipo de
20 personas para concebir y desarrollar un medio para llevar a los mineros uno por uno a salvo, a la superficie.
Médicos de la NASA y expertos norteamericanos en submarinos llegaron al lugar de la mina a mediados de
agosto para evaluar el estado psicológico de los mineros. Utilizando su experiencia en las presiones físicas y mentales
de enfrentar a aislamiento prolongado, trabajaron con los funcionarios locales para desarrollar una rutina de ejerci-
cios y la ejecución de tareas con el fin de darles a los mineros un sentido de estructura y responsabilidad. Los mineros
sabían que la ayuda estaba en camino, pero no tenían idea de los desafíos técnicos que se debían enfrentar en cada
etapa del plan de salvamento para lograr que este fuera éxito. Sin embargo, el contacto permanente establecido
entre el sitio en el que estaban los mineros y la superficie a través del túnel taladrado originalmente, les permitía a los
mineros recibir noticias y una variedad de objetos para aliviar el tedio de la espera.
Estados Unidos también facilitó un experto perforador, Jeff Hart, quien fue llamado de Afganistán, donde ayu-
daba a las fuerzas estadounidenses a encontrar agua en las bases de operaciones avanzadas. Este hombre, con 40 años
de experiencia, perforó durante 33 días consecutivos, en condiciones difíciles, para llegar a los mineros atrapados en
el fondo de la mina. Adicionalmente, se levantaron tres plataformas de perforación para perforar tres túneles auxi-
liares desde diferentes puntos de partida y en distintas direcciones. El 17 de septiembre, el taladro manejado por Hart
(correspondiente al “Plan B”) llegó hasta donde se encontraban los mineros, aunque el diámetro de este túnel era
apenas de 5 pulgadas. Se requeriría un par de semanas adicionales para ampliar progresivamente el túnel con brocas
de mayor diámetro hasta alcanzar los 25 pulgadas necesarios para que las cápsulas de rescate que se estaban constru-
yendo pudieran pasar. No obstante, el equipo de rescate estaba exultante por la velocidad con la que el taladro había
llegado hasta los mineros atrapados. “Este éxito requería el conocimiento especial adicional y las habilidades que solo
nuestro equipo tenía”, dijo Dave Singleton, presidente de la División de Recursos de Agua de Layne Christensen. “De
no ser por Layne y Geotec, probablemente la perforación habría tomado hasta la Navidad de acuerdo con ‘Plan A’ o al
‘Plan C’”, señaló Singleton. “Nos ahorramos más de dos meses respecto a la estimación inicial”.
La primera cápsula de rescate, llamada Phoenix, llegó al lugar el 23 de septiembre; su construcción tomó dos sema-
nas y dos más para el transporte. El diseño especial de la cápsula Phoenix tenía forma de un cilindro. Phoenix tenía 13
pies de largo y pesaba 924 libras, con una anchura interior de 22 pulgadas. La cápsula estaba equipada con oxígeno y un
arnés para mantener al ocupante de pie, además de equipo de comunicaciones y ruedas retráctiles. La cápsula debía ser
suficientemente estrecha para que pudiera bajarse por el túnel de rescate, pero suficientemente amplia para que cupiera
una persona. Para asegurarse de que cada uno de los 33 mineros pudiera izarse en la Phoenix, estos se sometieron a dieta
de líquidos y se les dio una rutina de ejercicios que debían seguir en tanto se ultimaban los detalles del rescate.

Hugo Infante/Chilean Government/UPI/Newscom

FIGURA 1.1  Cápsula de escape Phoenix para el rescate de los mineros chilenos
Fuente: www.geekologie.com/2010/10/cramped_the_chilean_mine_rescu.php
(continúa)
4 Capítulo 1  • Introducción

Finalmente, después de numerosas pruebas, el equipo de superficie decidió que el túnel era suficientemente
seguro para soportar los esfuerzos de rescate y procedió a bajar por primera vez la cápsula Phoenix por el túnel de
rescate. En los dos primeros viajes, la cápsula bajo a un paramédico y experto en rescates voluntarios que coordina-
ron los procedimientos para subir a los mineros a la superficie. El primer minero rescatado salió a la superficie poco
después de la medianoche del 13 de octubre, después de un trayecto de 15 minutos en la cápsula. Más de 22 horas
después, el jefe de turno, Urzúa fue sacado de la mina, y se puso fin a un proyecto de rescate tenso y estresante.
La operación de rescate de los mineros chilenos fue uno de los proyectos de rescate ejecutados de mayor
éxito de los últimos tiempos. Puso de manifiesto la capacidad de las personas para trabajar en equipo, manejar
recursos, conseguir apoyo y utilizar tecnologías innovadoras en un esfuerzo humanitario que capturó la imagina-
ción del mundo. Los retos que hubo que superar fueron significativos: (1) los problemas técnicos asociados a hallar
y hacer contacto con los sobrevivientes; (2) la elaboración de un medio para recuperar a los hombres de manera
segura; (3) tomar medidas especiales para garantizar la salud física y mental de los mineros, (4) requerir a todas las
partes el desarrollo y uso de tecnologías radicales que nunca antes se había utilizado. En todos estos desafíos, el
equipo de rescate realizó maravillas para la recuperación y entrega a sus familias de los 33 mineros atrapados. El 7
de noviembre, justo un mes después del rescate, Edison Peña, uno de los mineros rescatados, cumplió uno de sus
sueños: correr y terminar el maratón de Nueva York. ¡Todo un logro para un hombre que acababa de pasar más de
dos meses enterrado a más de media milla bajo la superficie de la tierra!2

INTRODUCCIÓN
Los proyectos son uno de los medios principales a través de los cuales podemos cambiar el mundo. Si el objetivo
es dividir el átomo, hacer un túnel bajo el canal Inglés, introducir Windows 7 o planear los Juegos Olímpicos de
Londres, el medio a través del cual se logran estos retos sigue siendo el mismo: la gerencia de proyectos. La gerencia
de proyectos se ha convertido en una de las herramientas más populares para las organizaciones, tanto públicas como
privadas, para mejorar las operaciones internas, responder rápidamente a las oportunidades externas, lograr avan-
ces tecnológicos, agilizar el desarrollo de nuevos productos y la forma más robusta de gestionar los retos derivados
del entorno empresarial. Considere lo que Tom Peters, autor de best-sellers y consultor de gestión dice acerca de la
gerencia del proyecto y su lugar en los negocios: “Los proyectos, en lugar de tareas repetitivas, son ahora la base para la
mayor parte de valor agregado en los negocios.”3 La gerencia de proyectos se ha convertido en un componente crítico
de las operaciones empresariales exitosas en las organizaciones en todo el mundo.
Una de las características claves de los negocios modernos es la naturaleza de las oportunidades y amenazas
que presentan los acontecimientos externos. Como nunca antes, las empresas se enfrentan con la competencia
internacional y la necesidad de aprovechar rápidamente las oportunidades comerciales. Ellos deben modificar e
introducir nuevos productos constantemente, responder a los clientes tan rápido como les sea posible y mantener
la competitividad de sus costos y el nivel de operación. ¿Llevar a cabo todas estas tareas parece imposible? Hubo
un tiempo en que lo era. La sabiduría popular afirma que una empresa puede competir con una estrategia de bajo
costo o con un producto innovador o con un enfoque de servicio al cliente. En resumen, las empresas tuvieron
que ceder sus nichos de mercados a sus competidores que reclamaban su cuota de mercado. En la década de 1990,
sin embargo, todo cambió. Compañías como General Electric, Apple, Ericsson, Boeing y Oracle se volvieron cada
vez más eficaces en la consecución de todos estos objetivos, en lugar de simplemente conformarse con uno solo.
Estas empresas parecen tener éxito en todos los aspectos del modelo competitivo: fueron rápidas en el mercado y
eficientes, conscientes de los costos y enfocadas en el cliente. ¿Cómo lograron estas empresas lo imposible?
Obviamente, no hay una sola respuesta a esta compleja cuestión. No hay duda, sin embargo, de que
estas empresas comparten al menos una característica: desarrollaron y se comprometieron con la gerencia de
proyectos como herramienta competitiva. Los antiguos mandos medios, dice la revista Fortune,

son dinosaurios, [y] una nueva clase de gerente mamífero evoluciona para llenar el nicho que
alguna vez gobernaron los dinosaurios: los gerentes de proyectos. A diferencia de su contraparte
biológica, el gerente de proyectos es más ágil y adaptable que la bestia que está desplazando, tiene
más probabilidades de vivir por su ingenio que por mover su peso.4

Los gerentes de proyectos efectivos serán indispensables para las organizaciones de éxito en los próxi-
mos años. Cada vez, más empresas llegan a esta conclusión y adoptan la gerencia de proyectos como una
forma de vida. En efecto, empresas en sectores tan diversos como la construcción, la industria pesada, los
seguros, la atención de la salud, las finanzas, los servicios públicos y el software están convirtiéndose en
expertas en la gerencia de proyectos y esperan de sus empleados lo mismo.
1.1  ¿Qué es un proyecto? 5

1.1  ¿QUÉ ES UN PROYECTO?


Aunque hay varias definiciones generales del término proyecto, se debe reconocer, en primer lugar, que los
proyectos son distintos a otros procesos organizacionales. En general, un proceso se refiere a las actividades
en curso, el día tras día en que una organización opera, como puede ser la producción de bienes o servicios.
Los procesos utilizan los sistemas existentes, los activos y las capacidades de manera continua.5 Los proyec-
tos, por el contrario, normalmente ocurren por fuera del mundo de las empresas orientadas a los procesos.
Ciertamente, en algunas industrias como la de la construcción el día tras día de los procesos se centra en
la creación y el desarrollo de proyectos. Sin embargo, para la mayoría de las empresas, las actividades de la
gerencia de proyectos siguen siendo únicas y separadas de la rutina del trabajo basado en procesos. El trabajo
en los proyectos es dinámico, establece sus propias reglas y es la antítesis de la repetición. Como resultado de
esto, representa una alternativa de negocios para muchas empresas. Los desafíos son grandes, pero también
las recompensas del éxito.
En primer lugar, se requiere una comprensión clara de las propiedades que hacen únicos a los proyec-
tos y a la gerencia de proyectos. Considérense las siguientes definiciones de proyectos:

Un proyecto es una iniciativa única con un principio y un final, llevada a cabo por personas para
alcanzar las metas establecidas dentro de los parámetros de costo, plazo y calidad.6
Los proyectos [están] orientados a los objetivos implican un compromiso coordinado de actividades
relacionadas entre sí, con duración limitada, y son todas, hasta cierto punto, únicas.7
Un proyecto puede considerarse una serie de actividades y tareas que:
• Tienen un objetivo específico que se completará con determinadas especificaciones.
• Tienen definida la fecha de inicio y de terminación.
• Tienen fondos limitados (si aplica).
• Consume recursos humanos y no humanos (es decir, dinero, personas, equipos).
• Es multifuncional (es decir, afecta varias líneas funcionales).8
[Un proyecto es un] trabajo organizado para lograr una meta predefinida u objetivo que requiere recur-
sos y esfuerzo; es un emprendimiento único (y por tanto arriesgado) que tiene un presupuesto y un
cronograma.9

Probablemente la definición más simple se encuentra en los Fundamentos para la Gerencia de Proyectos
(Project Management Body of Knowledge,PMBOK® Guide) del Instituto para la Gerencia de Proyectos, (Project
Management Institute: PMI). El PMI es la mayor asociación profesional de gerencia de proyectos en el mundo,
con más de 380,000 miembros en todo el mundo en 2012. En el PMBOK® Guide, un proyecto se define como “un
esfuerzo temporal emprendido para crear un producto o servicio único” (p. 4).10
Con base en las definiciones anteriores, a continuación se describen los distintos elementos de un proyecto.

• Los proyectos son complejos y únicos que se realizan solo una vez.  Un proyecto se plantea para un
propósito específico o para cumplir un objetivo declarado. Es complejo porque requiere normalmente
aportes coordinados de numerosos miembros de la organización. Los miembros del proyecto pueden
pertenecer a diferentes departamentos u a otras unidades organizacionales o de una misma área fun-
cional. Por ejemplo, un proyecto para desarrollar una nueva aplicación de software en una empresa de
comercialización de productos, puede requerir solamente la salida de miembros del equipo de sistemas
de información para trabajar con personal de marketing. Por otro lado, en algunos proyectos, como el
lanzamiento de nuevos productos, la mejor forma de trabajo es contar con representación de muchas
áreas funcionales, incluidas marketing, ingeniería, producción y diseño. Debido a que un proyecto
tiene el propósito de cumplir un objetivo declarado, en un tiempo específico, aquel existe solamente
hasta cuando el objetivo se cumple, y en este momento se disuelve.
• Los proyectos están limitados por presupuesto, cronograma y recursos.  El trabajo del proyecto
requiere que el equipo labore con recursos financieros y humanos limitados durante un periodo espe-
cífico. No dispone de estos ilimitadamente. Una vez las asignaciones se ejecutan, el equipo del proyecto
se disuelve. Hasta ese punto, todas las actividades del proyecto se restringen por limitaciones de presu-
puesto y disponibilidad de personal. Los proyectos son “actividades restringidas por recursos”.
• Los proyectos se desarrollan para resolver un objetivo claro o un conjunto de objetivos.  No existe un
equipo de proyecto que marche sin un propósito específico. Los objetivos del proyecto o los entregables
definen su naturaleza y la del equipo. Los proyectos se diseñan para producir un resultado tangible, ya
6 Capítulo 1  • Introducción

sea un nuevo producto o servicio. Si el objetivo es construir un puente, implementar un nuevo sistema
de cuentas por cobrar o ganar una elección presidencial, aquel debe especificarse y el proyecto organi-
zarse para lograr ese objetivo declarado.
• Los proyectos están enfocados en el cliente.  Sea que el proyecto responda a las necesidades de una uni-
dad interna de la organización (por ejemplo, contabilidad) o tenga la intención de explotar una oportuni-
dad del mercado, el propósito fundamental de cualquier proyecto es satisfacer las necesidades del cliente.
En el pasado, algunas veces esta meta se ha pasado por alto. Los proyectos son exitosos si alcanzan sus
objetivos técnicos, presupuestarios y de programación. Sin embargo, cada vez más, las empresas se dado
cuenta de que el objetivo principal de un proyecto es la satisfacción del cliente. Si se descuida esta meta, la
empresa corre el riesgo de “no hacer las cosas bien”, es decir, desarrolla proyectos que pueden ejecutarse
eficientemente pero que ignoran las necesidades del cliente o fracasan comercialmente.

Características generales de los proyectos


Con las definiciones anteriores, se puede formar una idea de los atributos clave que comparten todos los
proyectos. Estas características no solo son útiles para una mejor comprensión de los proyectos, sino que
también ofrecen la base para ver cómo el trabajo basado en proyectos se diferencia de otras actividades que
la mayoría de las organizaciones realizan. Los proyectos representan un tipo especial de iniciativa para cual-
quier organización. No sorprende que los retos en desarrollarlos llegan a ser, en ocasiones, desalentadores.
No obstante, dada la manera en que los negocios continúan evolucionando en el mundo, convertirse en
“experto en proyectos” ya no se considera un lujo sino en una necesidad.
Los proyectos se caracterizan por: 11

1. Los proyectos son esfuerzos ad hoc con un ciclo de vida definido.  No son tradicionales, sus activi-
dades se inician cuando se requiere, operan durante un periodo específico con un ciclo de desarrollo
conocido y luego se disuelven. Son operaciones temporales.
2. Los proyectos son bloques constructivos para el diseño y ejecución de las estrategias organizacionales. Los
proyectos les permiten a las organizaciones implementar sus estrategias generales. Son la principal forma en
que las empresas operacionalizan sus objetivos corporativos. De hecho, los proyectos son los vehículos para
la realización de objetivos empresariales. Por ejemplo, la estrategia de Intel para la penetración en el mercado
con chips de computador cada vez más innovadores, pequeños y rápidos, se realiza a través de su compromiso
con un flujo permanente de proyectos de investigación y desarrollo que le permite explorar continuamente los
límites tecnológicos de la ingeniería electrónica y de computación.
3. Los proyectos son responsables de los productos, servicios y procesos organizacionales novedosos y
mejorados.  Los proyectos son herramientas para la innovación. Debido a que complementan (y a
veces transforman) las actividades tradicionales orientadas a procesos, muchas empresas se basan en
proyectos como vehículos para ir más allá de sus actividades convencionales. Los proyectos son los
peldaños por los que se escala hacia el progreso.
4. Los proyectos ofrecen una filosofía y una estrategia para la gerencia del cambio.  “El cambio” es un con-
cepto abstracto hasta que se establecen medios por los cuales se pueden realizar modificaciones reales en lo
que se hace y se produce. A veces llamados “cimientos de la estrategia”, los proyectos les permiten a las orga-
nizaciones ir más allá de simples declaraciones de intenciones y lograr una innovación real en sus productos
o servicios. Por ejemplo, en el automóvil eléctrico Volt de Chevrolet o la más reciente actualización para
el iPhone de Apple, las organizaciones exitosas habitualmente indagan los requerimientos del cliente y se
retroalimentan para conocer mejor sus gustos y disgustos. Como vehículo del cambio, la manera en que una
empresa desarrolla sus proyectos dice mucho de su capacidad de innovación y compromiso con el cambio.
5. La gerencia de proyectos implica traspasar fronteras funcionales y organizacionales. Los proyectos reflejan la
colaboración interna de una empresa, pues reúnen a personas de diferentes áreas funcionales de toda la organiza-
ción. Un proyecto para desarrollar un nuevo producto puede requerir el trabajo conjunto de ingeniería, finanzas,
marketing, diseño, etc. Del mismo modo, en un entorno empresarial globalizado, muchas empresas han cruzado
las fronteras organizacionales asociándose a largo plazo con otras empresas, con el fin de maximizar las oportuni-
dades mientras se focalizan en la eficiencia y en mantener los costos. Los proyectos son los vehículos más comunes
para promover el trabajo colaborativo, tanto entre áreas funcionales como entre organizaciones.
6. Las funciones tradicionales de gestión como planeación, organización, motivación, dirección y control
se aplican a la gerencia de proyectos.  Los gerentes de proyecto deben estar preparados técnicamente,
ser competentes en funciones administrativas, estar dispuestos y ser capaces de desempeñar papeles de
1.1  ¿Qué es un proyecto? 7

liderazgo y, sobre todo, orientarse al logro de objetivos. El director del proyecto es la persona responsable
de mantener una visión general. La esencia de las responsabilidades de la gerencia del proyecto nunca debe
subestimarse, porque estas son diversas y a la vez fundamentales para el éxito del proyecto.
7. El principal resultado de un proyecto es la satisfacción de las necesidades del cliente, según las limita-
ciones técnicas, de costos y de planeación de los objetivos.   Los proyectos se definen de acuerdo con sus
limitaciones, tienen presupuestos limitados, cronogramas definidos y especificaciones cuidadosamente
establecidas para su conclusión. Por ejemplo, un artículo de fin de curso en una clase de la universidad
podría incluir detalles respecto a la forma, la longitud, el número de fuentes primarias y secundarias por
citar, entre otras. Del mismo modo, en el caso Expedición al Everest de Disney, al final de este capítulo, el
ejecutivo que lidera el proceso de cambio establece directrices claras respecto a las expectativas de desem-
peño. Todas estas restricciones limitan y definen el enfoque del proyecto, así como las opciones para con-
formar el equipo del proyecto. El trabajo de gerenciar exitosamente un proyecto consiste en desarrollarlo
dentro de limitaciones específicas, lo cual lo convierte en un asunto muy desafiante.
8. Los proyectos finalizan después de la culminación exitosa de sus objetivos de desempeño —o antes de
su ciclo de vida, si los resultados ya no prometen una ventaja operativa o estratégica. Como se ha visto,
los proyectos difieren de los procesos convencionales en que se definen por los ciclos de vida limitados:
se inician, finalizan y luego se disuelven. Como una alternativa importante a las actividades de organi-
zación convencionales, a veces se les llama “organizaciones temporales.”12
Los proyectos, entonces, se diferencian de las bien conocidas actividades organizacionales que a menudo
implican procesos repetitivos. El modelo tradicional de la mayoría de las empresas considera a las actividades
organizacionales como un conjunto discreto de actividades de desempeño consistente. Por ejemplo, un estable-
cimiento de comercialización de ropa mantiene un ciclo continuo de comprar, almacenar y vender prendas de
vestir; una planta de acero, ordena materia prima, fabrica el acero y distribuye los productos terminados, siem-
pre en un ciclo recurrente. La naturaleza de estas operaciones centra su atención en una “orientación a proce-
sos”, es decir, en la necesidad de realizar un trabajo tan eficientemente como sea posible de manera permanente.
Cuando estos procesos se conocen bien, la organización siempre busca las mejores y más eficientes formas de
realizar estas mismas tareas esenciales. Los proyectos, debido a que son actividades discretas, no cumplen la
condición de repetición. Son actividades temporales que operan por fuera de los canales formales. Ellos pueden
reunir en un equipo un conjunto de miembros dispares con diferentes tipos de experiencia funcional. Los pro-
yectos se ejecutan en condiciones de incertidumbre y, por lo general, generan el efecto “remezón” las activida-
des empresariales normales. Debido a sus características únicas, que no se ajustan a las normas estándares de las
operaciones, los proyectos realizan las cosas de manera diferente y a menudo revelan nuevas y mejores formas
de hacerlas. El cuadro 1.1 muestra algunas otras diferencias entre el trabajo basado en proyectos y las activi-
dades normales basadas en procesos. Tenga en cuenta un aspecto recurrente: los proyectos operan de manera
radical, de tal forma que consistentemente violan la visión estándar de las organizaciones basada en procesos.

CUADRO 1.1  Diferencias entre procesos y gerencia de proyectos 13

Proceso Proyecto
Repite el proceso o producto Proceso o producto nuevo
Varios objetivos Un objetivo
Permanente Temporal
Personal homogéneo Personal heterogéneo
Sistemas bien establecidos para integrar esfuerzos Sistemas creados para integrar esfuerzos
Mayor certidumbre en el desempeño, costo y Mayor incertidumbre en el desempeño, costo y
cronograma cronograma
Parte de la organización de línea Fuera de la organización de línea
Bastión de la práctica establecida Viola la práctica establecida
Apoya el status quo Altera el status quo
Fuente: R. J. Graham. (1992). “ A Survival Guide for the Accidental Project Manager,” Proceedings of the Annual Project
Management Institute Symposium. “, Drexel Hill, PA: Project Management Institute, pp. 355-61. Todos los derechos reservados. El
material de esta publicación ha sido reproducido con permiso del PMI.
8 Capítulo 1  • Introducción

Considere el desarrollo del iPod de Apple, un reproductor portátil de MP3 que puede integrarse con
el popular sitio iTunes de Apple para grabar y reproducir las descargas de música. Apple, dirigida por su
presidente Steven Jobs, reconoció el potencial en el mercado de MP3, dada la enorme popularidad (algunos
dirían, notoriedad) del intercambio y la descarga de archivos de música a través de internet. La compañía
esperaba sacar provecho de la necesidad de un reproductor de MP3 amigable con el usuario, al tiempo que
ofrecía una alternativa legítima a la descarga ilegal de música. Desde su introducción en 2003, los consumi-
dores han comprado más de 278 millones de iPods y más de 10,000 millones de canciones a través de iTunes,
la tienda online de Apple. De hecho, la división de iTunes de Apple es ahora el mayor mercado para la venta
de música en Estados Unidos, representan 25% de toda la música vendida en Estados Unidos.
En una entrevista, Jobs reconoció que el negocio de Apple necesitaba un remezón, dado el crecimiento
constante pero poco espectacular de las ventas de su computador personal insignia, el Macintosh, que mante-
nía todavía aproximadamente 11% del mercado total de PC. En su segundo año de existencia, el iPod, como
un proyecto único dentro de Apple, se convirtió en un negocio de miles de millones de dólares para la compa-
ñía. Tan popular ha llegado a ser el negocio del iPod para Apple que la empresa creó una unidad de negocio
independiente, y trasladó el producto y su personal de soporte fuera del grupo Mac. “Ni qué decir del iPod que
increíblemente ha llegado a ser muy popular, incluso entre personas que no son fanáticos de Apple”, expresó
el analista del sector Paolo Pescatore a NewsFactor, al señalar que Apple presentó recientemente una versión
más pequeña del producto con gran éxito. “En pocas palabras, han tenido mucho éxito hasta ahora, y me
imagino que están viendo este relanzamiento como una manera de garantizar que el éxito va a continuar.”14
Un conjunto similar de eventos está presentándose en la introducción y las actualizaciones sucesivas
de su tableta iPad de Apple. Entre las numerosas funciones que ofrece el iPad se encuentra la capacidad para
descargar libros (incluidos libros de texto universitarios) directamente de las editoriales, eliminando del
proceso las tradicionales librerías. Tan radicales han sido las implicaciones del iPad que los competidores se
apresuran a presentar sus propios modelos con el fin de captar una parte de este nuevo mercado. Mientras
tanto, las grandes librerías esperan adaptar sus modelos de negocio a la nueva realidad electrónica de la com-
pra de libros, ofreciendo sus propios lectores (Kindle de Amazon y el Nook de Barnes and Noble). Algunos
expertos sugieren que dentro de una década, las tabletas y lectores electrónicos harán que los libros tradicio-
nales sean obsoletos, capturando la mayor parte del mercado editorial. Estos son solo algunos ejemplos de
la forma en que un proyecto impulsado por el cambio tecnológico, como el de Apple, está transformando el
panorama competitivo.
Dado el entusiasmo con el que la gerencia de proyectos (GP) se adopta por muchas organizaciones,
se podría señalar que los mismos factores que la hacen una labor única también son unas de las principales
razones por las que la gerencia exitosa de proyectos es tan difícil. El recorrido de la GP no está lleno de éxitos
interrumpidos, en parte debido a que muchas empresas se encuentran con la arraigada aversión al cambio
que necesitan para darle cabida a una “filosofía del proyecto”. De hecho, investigaciones recientes relaciona-
das con la tasa de éxito de los proyectos registran algunas conclusiones sombrías, como las siguientes:

• Un estudio en más de 300 empresas grandes, llevado a cabo por la firma de consultoría Peat Marwick,
encontró que proyectos de desarrollo de software o hardware tienen una tasa de fracaso de 65%. De las
empresas estudiadas, 65% informó que sus proyectos sobrepasaron ampliamente el presupuesto, no se
culminaron a tiempo, no se desarrollaron según lo esperado, o todo lo anterior. La mitad de los direc-
tivos que respondieron indicaron que estos hallazgos se considerar “normales.”15
• Un estudio realizado por META Group encontró que “más de la mitad de todos los proyectos de tec-
nología de la información (Information Technology: IT) rebasan sus presupuestos y cronogramas ade-
más de no cumplir plenamente sus objetivos.”16
• Joe Harley, jefe de información del Departamento de Trabajo y Pensiones del Gobierno del Reino
Unido, declaró que “solo 30%” de los proyectos y programas de base tecnológica son un éxito, al
tiempo que los impuestos financian un presupuesto anual de 14,000 millones de libras esterlinas (más
de 22,000 millones de dólares estadounidenses ) en IT para el sector público, lo que equivale a la cons-
trucción de 7,000 nuevas escuelas primarias o 75 hospitales en un año.17
• De acuerdo con la Encuesta de 2004 de la Price Waterhouse Coopers, de 10,640 proyectos por valor
de 7,200 millones de dólares, en una amplia gama de industrias, grandes y pequeñas, solo 2.5% de las
empresas mundiales lograron conseguir 100% del éxito del proyecto y más de 50% de los proyectos
empresariales globales fracasaron. La encuesta Chaos Summary 2009 del Standish Group reportó hallaz-
gos similares: la mayor parte de los proyectos fueron “cuestionados” (debido a la demora en la entrega,
por sobrepasar el presupuesto o por entregar menos de las características requeridas) o “fracasaron” y se
1.2  ¿Por qué son importantes los proyectos? 9

cancelaron antes de su terminación o el producto que desarrollaron nunca se utilizó. Los investigadores
han concluido que la tasa media de éxito de los proyectos de desarrollo de aplicaciones críticas para la
empresa es de 32%. Estas estadísticas se han mantenido muy estables desde 1994.18
• El Inspector General Especial para la Reconstrucción de Iraq (Special Inspector General for Iraq
Reconstruction: SIGIR) informó que el Pentágono gastó cerca de 600 millones de dólares en más de
1,200 proyectos de reconstrucción en Iraq que fueron finalmente cancelados, 42% debido a una mala
gestión o a la mala calidad de la construcción.19

Estos resultados ponen de relieve un punto importante: si bien la gerencia de proyectos es popular, no
se asimila fácilmente a los procesos convencionales de la mayoría de empresas. Para cada empresa, descubrir
los beneficios de los proyectos mucho más que subestimar los problemas que implican, la llevará a conside-
rarse “conocedora de proyectos”.
Estos estudios también apuntan a una verdad central sobre la gerencia de proyectos: no se deben sobre-
estimar los beneficios derivados de la gerencia de proyectos, al tiempo que se subestima el compromiso que
se requiere para realizar el trabajo de un proyecto. No hay soluciones mágicas ni rápidas en esta disciplina. Al
igual que cualquier otra actividad valiosa, la gerencia de proyectos requiere preparación, conocimiento, entre-
namiento y compromiso como principios. Las organizaciones que desean implementar el trabajo basado en
proyectos deben reconocer, tal como se describe en el cuadro 1.1, que su misma intensidad causa a menudo que
opere en contradicción directa con las prácticas empresariales estándares, orientadas a los procesos.

1.2  ¿POR QUÉ SON IMPORTANTES LOS PROYECTOS?


Hay una serie de razones por las cuales los proyectos y la gerencia de proyectos son cruciales para ayudar
a una organización a alcanzar sus objetivos estratégicos. David Cleland, un reconocido investigador de la
gerencia de proyectos, sugiere que muchas de estas razones se derivan de las mismas presiones que las orga-
nizaciones enfrentan.20

1. Los ciclos de vida de los productos son más cortos.   Los días en que una empresa podía ofrecer un nuevo
producto y depender de tener años de dominación competitiva se han ido. Cada vez más, el ciclo de vida de
los nuevos productos se mide en términos de meses o incluso semanas, en lugar de años. Solo basta mirar
los nuevos productos electrónicos o de hardware y software para evidenciar esta tendencia. Curiosamente,
se ven signos similares en empresas del sector de servicios tradicionales, que también han reconocido la
necesidad de agilidad en la oferta y mejora de nuevos servicios, a un ritmo cada vez más acelerado.
2. Lapsos más reducidos para el lanzamiento de productos.  Otro aspecto relacionado con el tiempo se
refiere a la naturaleza de las oportunidades. Las organizaciones son conscientes del peligro de perder el
punto óptimo para presentar un nuevo producto y deben adoptar una visión proactiva hacia el momento
de la introducción de productos. Por ejemplo, mientras que se cosechan los beneficios de la venta exitosa
de un producto A, las empresas inteligentes planean el mejor punto para el lanzamiento del producto B,
ya sea como una actualización del producto o como una nueva oferta. Debido a la fuerte competencia,
estas oportunidades óptimas de presentación se miden en términos de meses. Al perder el momento
óptimo de lanzamiento, incluso por cuestión de semanas, se corre el riesgo de salir de competencia.
3. Productos cada vez más técnicos y complejos.  El mundo de hoy es muy complejo. Los productos son
complicados, técnicamente sofisticados y difíciles de producir de manera eficiente. El apetito del público
por “la próxima gran cosa” no ha disminuido sustancialmente y se encuentra permanentemente insa-
tisfecho. Desean que los nuevos modelos de sus bienes de consumo sean mejores, más grandes (o más
pequeños), más rápidos y más complejos que los anteriores. Como respuesta, las empresas actualizan
constantemente las líneas de productos y servicios para alimentar esta demanda. Esto ocasiona múlti-
ples problemas en el diseño y la producción, pues continuamente se busca desafiar los límites técnicos.
Además, para pronosticar la demanda futura, muchas empresas emprenden costosos programas de
investigación y desarrollo con el fin de descifrar los gustos del consumidor. El efecto puede ser realizar
erróneamente proyectos costosos y técnicamente sofisticados para suponer lo que el cliente deseará. Por
ejemplo, Rauma Corporation de Finlandia desarrolló un moderno “cargador” de la industria maderera.
Los ingenieros de Rauma cargaron el producto con lo último en aparatos computarizados y tecnología
que dieron como resultado una máquina con sensación de la era espacial. Infortunadamente, para el
cliente principal que se trabajó el producto, en regiones remotas de Indonesia, los problemas de logís-
tica hicieron impráctica la concreción de los servicios de mantenimiento y reparación. Las máquinas
10 Capítulo 1  • Introducción

descompuestas tuvieron que trasladarse en helicóptero a más de 1,000 millas con destino a centros de ser-
vicio. Desde el inicio de este proyecto, los registros de ventas de las máquinas decepcionaron. El proyecto
fue un costoso fracaso para Rauma y sirve para ilustrar un punto importante: a menos que las empresas
encuentren una forma de mantener bajo control el proceso, una mentalidad de la “ingeniería para el bien
de la ingeniería” puede quedar rápidamente fuera de control .21

PERFIL DE PROYECTO

Caso — Proyectos en China: motivación del entorno innovador


Como una de las economías más pujantes en el mundo de hoy, China está invirtiendo miles de millones de dólares
cada año en modernizar su infraestructura, en mejorar las condiciones de vida y de trabajo para trasladar los benefi-
cios de la renovación económica a los habitantes en todas partes del país. El volumen y la diversidad de proyectos que
se realizan hoy día en China son impresionantes y dan una idea de la forma en que el Gobierno está tratando de sacar
adelante al país. Una lista parcial de recientes iniciativas de proyectos importantes en China incluye:
1. Rascacielos urbanos y desarrollo de espacios para oficinas y vivienda—Varios factores presionan al Gobierno
chino para invertir fuertemente en nuevas oficinas y torres de apartamentos en todo el país. Detrás del compro-
miso de mejorar la calidad de vida en China existe un auténtico deseo por traspasar los límites de la arquitectura.
Estos proyectos están fuertemente soportados en materiales de construcción más baratos, una demanda dada
por la densidad urbana, en los edificios verdes y en la búsqueda de reconocimiento internacional. De hecho, un
reciente informe de la empresa de consultoría McKinsey Group predice que en el 2025 China tendrá 221 ciudades
con más de un millón de habitantes, en comparación con las 35 en Europa de hoy. Además de la necesidad de
Aurora Photos / Alamy

FIGURA1.2  El edificio más alto de China, Shanghai World Financial Center


1.2  ¿Por qué son importantes los proyectos? 11

una gran inversión en infraestructura, McKinsey pronostica que China va a construir entre 20,000 y 50,000 rasca-
cielos, muchos de ellos en las provincias menos desarrolladas del interior, lejos de Pekín y Shanghái.
2. Proyectos de trenes de alta velocidad—China anunció recientemente el desarrollo de una línea ferroviaria de
alta velocidad entre Pekín y Shanghái, el corredor más poblado y económicamente importante del país. Más
de una cuarta parte de la población del país vive cerca de la línea, lo que representaría 10% del transporte
de pasajeros y 7% de carga. Esta nueva línea de alta velocidad está siendo diseñada para que el tren opere a
una velocidad de 300 km/h (186 mph), lo cual reducirá el tiempo de viaje entre Pekín y Shanghái de 14 horas
a solo cinco. Se estima que unos 220,000 pasajeros al día utilizarán los trenes. Según los estimativos actuales,
se espera que el proyecto se finalice a mediados de la década y a un costo aproximado de 12,000 millones de
dólares. Esta línea es solo el último de una serie de enlaces ferroviarios de alta velocidad desarrollados para
conectar los principales centros de población del país. La línea del tren de alta velocidad Pekín-Tianjin se ter-
minó hace tres años y también forma parte de un gran esfuerzo del país para vincular mejor a su pueblo y los
centros económicos. A medida que el progreso avanza y la tecnología ferroviaria continúa mejorando, China
estudiará otras opciones para utilizar el tren de alta velocidad.
3. Construcción de plantas de energía—La capacidad de generación eléctrica de China se ha incrementado en los
últimos cinco años, debido a un gran aumento en la construcción de centrales eléctricas. Al mismo tiempo,
explora todas las vías posibles para la producción de energía. Se están construyendo centrales nucleares y
plantas hidroeléctricas en todo el país, para aprovechar los grandes proyectos de construcción de represas
en ríos, como la famosa presa de las Tres Gargantas. Además, China ha duplicado su capacidad de energía
eólica en cada uno de los últimos cuatro años, y a finales de 2012 se esperaba que pasara a Estados Unidos
como el mayor mercado del mundo para los equipos de energía y de energía eólica. A pesar de estas fuentes
alternativas de energía, el carbón sigue siendo la opción más popular para la generación de electricidad,
ya que China posee la tercera reserva de carbón del mundo, solo por detrás de Estados Unidos y Rusia. Es
tal el compromiso del Gobierno chino en la construcción de centrales eléctricas de carbón que tales plantas
están construyéndose a un ritmo de uno por mes en todo el país. China ya consume más carbón que Estados
Unidos, Europa y Japón juntos, convirtiéndose en el mayor emisor mundial de gases de efecto de inverna-
dero. Al mismo tiempo, sin embargo, lo que no se conoce tanto es que China se ha convertido en los últimos
tres años en el mayor constructor mundial de centrales eléctricas de carbón más eficientes y menos contami-
nantes. De hecho, en un momento en que la tecnología pierde fortaleza en Estados Unidos, en razón de
que las regulaciones gubernamentales tienden a desacelerar su desarrollo, China aumenta rápidamente la
construcción de estas plantas, mejorando su tecnología y reduciendo costos.
El frenético giro de China hacia la industrialización y la mejora de su infraestructura no está exento de riesgos.
Emprender esta ambiciosa meta nacional es un proceso muy complejo, ya que implica inversiones anuales de cientos
de miles de millones de dólares, el compromiso de las personas y mantener la economía en óptimos niveles para
apoyar estos planes. Sin embargo, en un momento en que el desarrollo se ha reducido en la mayor parte del planeta
debido a la recesión económica mundial, refresca ver que en China la filosofía sigue siendo ¡a toda máquina!22

4. Surgimiento de mercados globales.  Los primeros años del siglo xxi han sido testigo de la aparición
de mercados nuevos inmensos en casi todo tipo de productos y servicios. Sociedades cerradas o ex
socialistas, así como economías en rápido desarrollo como Rusia, China e India, han agregado un gran
número de consumidores y de competidores al escenario de los negocios globales. La creciente globa-
lización de la economía, junto a métodos mejorados para interactuar rápidamente con clientes y pro-
veedores, ha generado unos nuevos desafíos para las empresas. Pero estos retos se convierten también
en una oportunidad única para que las empresas se adapten rápidamente a esta nueva realidad. En el
ámbito mundial, las técnicas de gerencia de proyectos les proporcionan a las empresas la capacidad de
conectarse con sus socios y de atender rápidamente la demanda del mercado y las necesidades de los
proveedores, sin dejar de ser suficientemente ágiles para anticiparse y responder a los rápidos cambios
en los gustos de los consumidores. Con la gerencia de proyectos, las organizaciones exitosas podrán
reconocer y aprender a explotar rápidamente las perspectivas que ofrece un entorno económico global.
5. 5. Un periodo económico marcado por la baja inflación.  Uno de los indicadores clave de la salud
económica es el hecho de que la inflación se ha mantenido bajo control. En la mayoría de las econo-
mías occidentales desarrolladas, la baja inflación ha contribuido a desencadenar un largo periodo de
expansión económica; asimismo, ha proporcionado un impulso a economías emergentes, como las
de India y China, para expandirse rápidamente. Infortunadamente, la baja inflación también limita
la capacidad de las empresas para mantener la rentabilidad compartiendo un aumento de costos. Las
empresas no pueden continuar aumentando los márgenes de rentabilidad simplemente elevando los
12 Capítulo 1  • Introducción

precios de sus productos o servicios. Las empresas exitosas en el futuro serán aquellas que aumentan
los beneficios mediante la racionalización de sus procesos internos: aquellas que ahorran dinero al
“hacerlo mejor” que la competencia. Como herramienta diseñada para alcanzar metas como la eficien-
cia interna, la gerencia de proyectos es un medio para reforzar las utilidades.
Estos son solo algunos de los retos que enfrentan las empresas hoy día. Un punto importante es que no
es probable que las fuerzas que generaron estos problemas disminuyan en un futuro próximo. Para enfrentar
estos desafíos, grandes empresas de éxito como General Electric, 3M, Apple, Sony, Bechtel y Microsoft han
hecho de la gerencia de proyectos un aspecto fundamental de su filosofía de operación.
La gerencia de proyectos también sirve como un campo de entrenamiento adecuado para futuros ejecu-
tivos de alto nivel en la mayoría de las organizaciones. Un aspecto único de los proyectos es la forma en que se
entremezclan los desafíos técnicos y de comportamiento. La parte técnica de la gerencia de proyectos requiere
que los gerentes sean expertos en la selección de proyectos, elaboración de presupuestos, gerencia de recursos,
planeación y la programación y seguimiento de los proyectos. Sin embargo, al mismo tiempo, los gerentes de
proyectos se enfrentan igualmente con el gran reto de la gestión del comportamiento o de las “personas”. Los
proyectos, al ser esfuerzos temporales requieren administradores capaces de reunir individuos de toda la orga-
nización, conformar rápidamente un equipo de trabajo efectivo, manejar el conflicto, generar liderazgo, parti-
cipar en negociación y tener un comportamiento político adecuado, todo en pro del éxito del proyecto. Algo
conocido es: gerentes de proyectos que haga énfasis en un solo problema e ignore el resto, por ejemplo decidir
centrarse solo en el aspecto técnico o el de comportamiento de la GP, no son tan exitosos como los que buscan
ser expertos en los dos. ¿Por qué la gerencia de proyectos es un campo de entrenamiento tan útil para los altos
ejecutivos? Porque proporciona la primera prueba verdadera de su capacidad para dominar los retos técnicos
y los humanos que caracterizan a los líderes efectivos en los negocios de hoy. Los gerentes de proyecto y sus
proyectos generan el tipo de valor que las organizaciones necesitan para sobrevivir y prosperar.

1.3  EL CICLO DE VIDA DE UN PROYECTO


Imagine que le asignan como tarea el trabajo de fin de curso en una clase de la universidad. El primer paso sería
generar una idea clara de la tarea—lo que el profesor está buscando, qué tan extenso debería ser el informe, el
número necesario de referencias, los requerimientos de estilo, etc. Una vez que se ha familiarizado con la tarea,
el siguiente paso sería la elaboración de un plan de cómo continuar con el proyecto, a fin de completarlo antes
de la fecha de vencimiento. Se realiza un cálculo aproximado de cuánto tiempo será necesario para la investiga-
ción, la redacción del primer borrador, el documento de prueba y completar el informe final. Esta información
se utiliza para crear algunos ítems provisionales de los diversos componentes de la tarea. Luego, se comienza
a ejecutar el plan, se investiga en la biblioteca o en la red, se elabora un esquema, se escribe un borrador, y así
sucesivamente. El objetivo es completar la tarea a tiempo, aplicando en el trabajo las habilidades de la mejor
forma posible. Finalmente, después finalizar el trabajo, se archivan o desechan los materiales de referencia, se
devuelven los libros a la biblioteca, se respira con alivio y se espera el día de grado.

Horas-hombre

Conceptualización Planeación Ejecución Terminación

FIGURA 1.3  Etapas del ciclo de vida del proyecto


1.3  El ciclo de vida de un proyecto 13

Este es un ejemplo simplificado, pero útil para ilustrar el ciclo de vida de un proyecto. En este caso, el pro-
yecto consistió en la realización del trabajo final según estándares establecidos por el instructor y en un tiempo
permitido. El ciclo de vida de un proyecto incluye las etapas necesarias para el desarrollo de este. Estos ciclos
de vida demuestran la lógica que rige un proyecto. También ayudan a desarrollar los planes para llevar a cabo el
proyecto, por decidir, por ejemplo, cuándo hay que utilizar los recursos del proyecto, cómo se debe evaluar su
progreso, y así sucesivamente. Considérese el modelo simplificado del ciclo de vida del proyecto dividido en cuatro
etapas diferenciadas: conceptualización, planeación, ejecución y terminación, tal como se muestra en la figura 1.3.

• Conceptualización se refiere al desarrollo del objetivo inicial y de las especificaciones técnicas de un pro-
yecto. Se determina el alcance del trabajo, se identifican los recursos necesarios (personas, dinero, planta
física) y los involucrados más importantes de la organización o los interesados (stakeholders) del proyecto.
• La planeación es la etapa en la que se desarrollan todas las especificaciones detalladas, esquemas, pro-
gramas y otros planes. Las partes del proyecto, a menudo denominadas paquetes de trabajo, se des-
componen, se asignan trabajos individuales y el proceso de ejecución queda claramente definido. Por
ejemplo, en la planeación de nuestro método para realizar el trabajo fin de curso, se determinan todas
las etapas necesarias para el proceso (investigación, proyectos, edición, etc.).
• Durante la ejecución, se ejecuta el “trabajo” real del proyecto, el sistema de información se desarrolla, o se crea y
fabrica el producto ideado. Durante esta fase, el equipo del proyecto lleva a cabo la mayor parte de sus labores.
Como muestra la figura 1.3, los costos del proyecto (en horas-hombre) crecen durante esta etapa.
• La terminación ocurre cuando el proyecto finalizado se entrega al cliente, sus recursos reasignan y se
cierra formalmente el proyecto. A medida que se completan subactividades específicas, se reduce el
alcance del proyecto y los costos disminuyen rápidamente.

Estas etapas son los puntos de referencia en los que el equipo del proyecto puede evaluar tanto el desempeño como
el estado general del proyecto. Sin embargo, es importante tener presente que el ciclo de vida es relevante solo
después de que el proyecto ha comenzado en realidad. El ciclo de vida se señala como el punto de partida real para
el desarrollo del proyecto, la elaboración de planes y programas, la realización de los trabajos necesarios, la termi-
nación del proyecto y la reasignación del personal. Cuando los proyectos se evalúan según este modelo de ciclo
de vida, se detectan indicios sobre las necesidades posteriores de recursos, es decir, empezamos a preguntarnos si
tenemos suficiente personal, materiales y equipos para soportar el proyecto. Por ejemplo, al empezar a trabajar en
el proyecto final de curso, se puede descubrir que es necesario comprar un PC o contratar a alguien para ayudar
con la investigación del tema. Por tanto, al planear el ciclo de vida del proyecto, se recopila información impor-
tante respecto a los recursos que se van a necesitar. El modelo de ciclo de vida, entonces, contribuye a dos aspectos
del proyecto: la oportunidad (cronograma) y los requisitos (recursos), que les permiten a los miembros del equipo
centrarse mejor en qué y cuándo necesitan los recursos.
El ciclo de vida del proyecto también es un medio útil para visualizar las actividades necesarias y los
retos que se enfrentan durante la vida de un proyecto. La figura 1.4 indica algunas de estas características y

Interés
del cliente

Participación
del proyecto

Nivel de Recursos
intensidad
Creatividad

Incertidumbre

Concep-
Planeación Ejecución Terminación
tualización

Tiempo

FIGURA 1.4  Ciclo de vida del proyecto y sus efectos


Fuente: Victor Sohmen. (2002, julio). “Project Termination: Why the Delay” Paper presentado en
la Conferencia de Investigación del PMI, Seattle, WA.
14 Capítulo 1  • Introducción

cómo evolucionan durante el curso de la realización de un proyecto.23 Como se aprecia, los cinco componen-
tes de un proyecto que pueden cambiar a lo largo de su ciclo de vida son:

• El interés del cliente:  el nivel de entusiasmo o de preocupación expresada por el cliente del proyecto.
Los clientes pueden ser internos o externos a la organización.
• Participación del proyecto:  el valor de la inversión corporativa en el proyecto. Cuanto más larga sea
la duración del proyecto, mayor será la inversión.
• Recursos:  el compromiso de recursos financieros, humanos y técnicos durante la vida del proyecto.
• Creatividad:  el grado de innovación que requiere el proyecto, especialmente durante determinadas
fases de desarrollo.
• Incertidumbre:  el grado de riesgo asociado con el proyecto. El grado de riesgo aquí refleja el número
de incógnitas, que es probable que enfrente el proyecto, incluidos los problemas técnicos. La incerti-
dumbre es mayor al principio, porque muchos desafíos aún no se han identificado, y mucho menos
abordados.

Cada uno de estos factores tiene su propia dinámica. El interés del cliente, por ejemplo, sigue una curva
en forma de “U”, la cual refleja el entusiasmo inicial, los niveles más bajos de interés que se presentan durante
las fases de desarrollo, y luego el interés renovado cuando se acerca la terminación del proyecto. La inversión
del proyecto aumenta a medida que el proyecto avanza, debido a que se requiere un compromiso de recursos
cada vez mayor para soportar las actividades en curso. La creatividad, a menudo vista como un pensamiento
innovador y la aplicación de una perspectiva única, es alta al inicio de un proyecto, pues el equipo y el cliente
comienzan a desarrollar una visión compartida del proyecto. A medida que el proyecto avanza y la incerti-
dumbre sigue siendo alta, la creatividad también sigue siendo una característica determinante. De hecho,
solo cuando el proyecto se encuentra en su fase de ejecución, con metas definidas, la creatividad se torna
menos importante. Volviendo al ejemplo del proyecto de trabajo final de curso, en muchos casos, es necesa-
rio inicialmente contar con la “creatividad” necesaria para visualizar un enfoque único o válido, para desa-
rrollar el proyecto, identificar sus objetivos y planificar el proceso para alcanzarlos. Una vez identificados, la
fase de ejecución, o de escritura del trabajo final, requiere menos énfasis en la creatividad misma y más en las
medidas concretas que se necesitan para terminar el proyecto.
La información resumida de la figura 1.4 da una idea de los problemas y desafíos que un equipo pro-
bablemente pueda enfrentar durante el ciclo de vida de un proyecto. Con el tiempo, mientras determinadas
características (creatividad, recursos e incertidumbre) comienzan a disminuir, otros elementos (interés del
cliente y participación en el proyecto) ganan importancia. Balancear los requerimientos de estos elementos a
lo largo del ciclo de vida es solo una de las numerosas demandas que enfrenta un equipo de proyecto.

RECUADRO 1.1

GERENTES DE PROYECTOS EN LA PRÁCTICA


Stephanie Smith, Westinghouse Electric Company
Stephanie Smith, una gerente de proyectos en la industria nuclear, trabaja para Westinghouse Electric Company
en Pittsburgh, Pennsylvania. Obtuvo su licenciatura en Ciencias Biológicas de la University of Pittsburgh y
luego el grado de maestría en pedagogía. Después de enseñar Ciencias de la Biología y del Medio Ambiente
durante cuatro años, Stephanie decidió dar un cambio a su carrera y fue contratada como software librarian
en Westinghouse. Su trabajo consistía en administrar el software creado por varios equipos de ingenieros para
utilizarlo en las plantas de energía nuclear, al tiempo que administraba la documentación, incluidos programas
y planes de calidad, procedimientos para creación de documentos y para la edición de la documentación de
ingeniería. Después de un año de apoyo a estos programas operativos, ella ganó más experiencia trabajando en
grandes proyectos en materia de protección nuclear y control de seguridad, donde, además de sus otras funcio-
nes, interactuó con miembros de la Comisión de Regulación Nuclear.
Como gerente de proyectos en la industria nuclear, Stephanie ha trabajado en la mayoría de los pro-
yectos orientados a realizar la ingeniería de primera clase, desarrollando productos para utilizarlos en plantas
de energía nuclear, lo cual requiere una gran cantidad de habilidades técnicas. Sin embargo, Stephanie se
1.3  El ciclo de vida de un proyecto 15

apresura a señalar que tener las habilidades técnicas no te preparan para la gerencia de proyectos ni te capa-
citan para realizar el mejor trabajo. “Aparte de la naturaleza técnica de este trabajo, la mayor parte de mi
esfuerzo se dedica a la utilización de habilidades de gerencia de proyectos para elaborar y ejecutar proyectos
de acuerdo con los requerimientos de los clientes, normas internas de calidad y requisitos legales”. Las habili-
dades de comunicación son esenciales, afirma Stephanie, porque “me relaciono regularmente con mi equipo
de trabajo, la alta dirección y los clientes para realizar seguimiento al progreso del proyecto según el crono-
grama, presupuesto y calidad”.
Stephanie es responsable de asegurar que los problemas técnicos se resuelvan de la manera más efi-
ciente posible, uno de sus mayores retos, dado el tipo de industria y la necesidad de pensar a fondo en los
problemas, gestionar eficazmente los riesgos y tomar decisiones respecto a la seguridad del producto, todo
ello con la mirada puesta en satisfacer a los clientes y a las agencias reguladoras. “Los riesgos deben geren-
ciarse con eficacia, sobre todo en la industria nuclear, por razones de costo y seguridad; por tanto, siempre
soy consciente de que las decisiones que tomamos deben estar dentro de los estándares de las normas de
seguridad”. Ella también es responsable de la gestión de contratos dentro de sus proyectos. Esto le implica
a Stephanie trabajar con los clientes y la alta gerencia, con el fin de establecer un mejor lenguaje para que
tanto el contrato como el trabajo se puedan realizar de acuerdo con sus expectativas. Estas reuniones tam-
bién son fundamentales para definir el alcance y el control del proyecto, habilidades de uso diario para los
gerentes de proyectos.
“Sin una base sólida en los fundamentos de gerencia de proyectos, simplemente no podía hacer mi
trabajo”, afirma Stephanie. “Mi trabajo diario se centra en implementar eficazmente tanto las habilidades
técnicas como las de gerencia de proyectos (es decir, la técnica y los comportamientos de las personas).
Fuertes habilidades de liderazgo y de comunicación son muy importantes en mi trabajo diario. No pasa un
día sin que reciba y transmita información entre la alta dirección, mi equipo y el cliente. Mi trabajo es diná-
mico; independiente de cuánta planeación se realice, se presentan eventos inesperados, y aquí la necesidad
de flexibilidad entra en juego. La resolución de estos problemas requiere habilidades de comunicación y
paciencia”.
La mayor oportunidad que Stephanie ve en su trabajo es que apoya el desarrollo de energía limpia en
todo el mundo. La industria nuclear se ha despojado de sus antiguas imágenes y ha surgido en esta era como
una de las formas más limpias y seguras de energía. La energía nuclear y la gerencia de proyectos son campos
que crecen a un ritmo acelerado, lo cual demanda personas interesadas en adaptarse a los desafíos únicos que
ofrecen. El trabajo es exigente, pero, definitivamente, muy gratificante. “Al apoyar el esfuerzo mundial por
una energía limpia, tengo la oportunidad de trabajar con gente muy brillante y llena de energía, y realmente
aprendo algo nuevo cada día. Aliento al novato o al estudiante a identificar sus puntos fuertes y a tratar de
desarrollar una visión de cómo aplicar esas fortalezas para alcanzar el estilo de vida que desea. ¿Te ves en
una oficina? ¿Te ves trabajando en campo? Una de las grandes ventajas de profesiones como la gerencia de
proyectos es que ofrecen un nivel de flexibilidad y libertad que no es común encontrar en otras disciplinas. La
gerencia de proyectos es difícil, pero la recompensa puede llegar como dinero y satisfacción al ver los resulta-
dos de sus esfuerzos”.

FIGURA 1.5  Stephanie Smith de Westinghouse Electric


16 Capítulo 1  • Introducción

1.4  FACTORES DETERMINANTES EN EL ÉXITO DE UN PROYECTO


Las definiciones de los proyectos exitosos pueden ser sorprendentemente vagas.24 ¿Cómo se sabe cuándo un
proyecto es exitoso? ¿Cuándo es rentable? ¿Sí está dentro del presupuesto? ¿Sobre el tiempo? ¿Cuándo el
producto desarrollado funciona o se vende? ¿Cuándo se alcanzan los objetivos a largo plazo de recuperación
de la inversión? En términos generales, cualquier definición de éxito del proyecto debe tomar en considera-
ción los elementos que definen la naturaleza del mismo: es decir, el tiempo (cronograma), el presupuesto,
la funcionalidad, la calidad y la satisfacción del cliente. Al mismo tiempo, los gerentes normalmente aplican
tres criterios para el éxito de un proyecto:
• Tiempo.  Los proyectos están limitados por un periodo determinado durante el cual se deben ejecutar.
No se supone que continúen indefinidamente. Así, la primera restricción que rige la gerencia del pro-
yecto implica el requisito básico: el proyecto debe culminarse en la fecha programada o antes de esta.
• Presupuesto.  La segunda restricción fundamental de todos los proyectos es su presupuesto limitado. Se
deben cumplir las asignaciones presupuestales con el fin de utilizar los recursos tan eficientemente como sea
posible. Las empresas no giran cheques en blanco y esperar el mejor resultado. Así, la segunda limitación de
un proyecto plantea la siguiente pregunta: ¿El proyecto se terminará con el presupuesto asignado?
• Desempeño.  Todos los proyectos se desarrollan con el fin de cumplir algunas especificaciones téc-
nicas determinadas inicialmente. Se supone que al iniciar un proyecto se sabe qué hace o cómo debe
funcionar el producto final. Por tanto, la medición del desempeño significa determinar si el producto
terminado opera de acuerdo con las especificaciones. Los clientes naturalmente esperan que el pro-
yecto que está desarrollándose en su nombre, funcione como ellos esperan. La aplicación de este tercer
criterio a menudo se refiere a cómo realizar el control de la “calidad”.
Esta es la denominada triple restricción que ha sido la norma estándar con la cual se ha evaluado sis-
temáticamente el desempeño de un proyecto. Hoy día, un cuarto criterio se ha añadido a estos tres (véase la
figura 1.6).
• Aceptación del cliente.  El principio de aceptación del cliente argumenta que los proyectos se desa-
rrollan con los clientes, o pensando en los clientes y su finalidad es satisfacer sus necesidades. Si la acep-
tación del cliente es una variable clave, entonces, se debe preguntar también: ¿el proyecto terminado es
aceptable para el cliente que se diseñó? Las empresas que evalúan el éxito del proyecto estrictamente de
acuerdo con la “triple restricción” original, pueden dejar de aplicar la prueba más importante de todas:
la satisfacción del cliente con el proyecto terminado.

También se puede pensar en criterios para el éxito del proyecto en términos de condiciones “internas”
o “externas”. Cuando la gerencia de proyectos se realizó principalmente en empresas de construcción y otras
industrias pesadas, su valor principal era mantener el control interno de la organización sobre el gasto de
dinero y tiempo. Así, el modelo de la triple restricción tradicional tenía sentido, centrándose en la eficiencia
interna y en medidas de productividad, porque estas proporcionan una medida cuantificable de la evaluación
del personal y además les permiten a los contadores controlar los gastos.

Aceptación
Presupuesto
del cliente

Éxito

Tiempo Desempeño

FIGURA 1.6  La nueva cuádruple


restricción
1.4  Factores determinantes en el éxito de un proyecto 17

Sin embargo, recientemente, el modelo tradicional de la triple restricción, como medida de éxito del pro-
yecto, ha sido objeto de críticas cada vez mayores. El producto final, por ejemplo, podría tener fallas, pero si se
ha entregado a tiempo y dentro del presupuesto y satisface sus especificaciones originales (aunque imperfecto),
el proyecto todavía puede declararse un éxito. Incluir el criterio externo de aceptación del cliente corrige estas
deficiencias del proceso de evaluación. En primer lugar, vuelve a enfocar la atención corporativa fuera de la
organización, hacia el cliente, quien probablemente no se encuentre satisfecho con un producto final que ha
presentado fallas o está defectuoso. Asimismo, reconoce que el juez final del éxito del proyecto no es el contador
de la empresa, sino más bien el mercado. Un proyecto tiene éxito solo en la medida en que beneficia al cliente
que lo encargó. Por último, el criterio de aceptación del cliente requiere que los gerentes de proyectos y sus equi-
pos creen una atmósfera abierta y de comunicación durante el desarrollo del proyecto.
Considérese un ejemplo. El fabricante de automóviles Volvo ha estado motivado en aumentar su visibi-
lidad y en atraer clientes femeninos, un segmento de mercado que se ha vuelto significativamente fuerte en los
últimos años. Una investigación de mercado desarrollada por la compañía mostró que las mujeres quieren en
un automóvil todo lo que los hombres quieren, “y mucho más que los compradores de automóviles varones
nunca pensaron pedir”, según Hans-Olov Olsson, ex presidente y CEO de Volvo. De hecho, Volvo descubrió,
en palabras de Olsson: “Si se cumplen las expectativas de las mujeres, se excederán las de los hombres”. La
solución de Volvo fue permitir que cientos de sus empleadas, incluido todo el personal femenino de diseño
e ingeniería, desarrollaran un concepto de automóvil de última generación. El grupo estudió una variedad de
aspectos del vehículo, la cual incluía la ergonomía, el estilo, almacenamiento y mantenimiento, sin perder de
vista el tema común: ¿qué quieren las mujeres? Identificado con el código YCC (Your Concept Car), el carro
se diseñó para ser casi libre de mantenimiento, con un eficiente motor híbrido gas-eléctrico, estilo deportivo y
almacenamiento amplio. Los esfuerzos de Volvo en el desarrollo del proyecto YCC demuestran su compromiso
con la aceptación y satisfacción del cliente, un motivador clave en su proceso de gerencia de proyectos, y rem-
plazó el modelo tradicional de la triple restricción para el éxito del proyecto.25
Un enfoque adicional para la evaluación del proyecto sostiene que debe tomarse siempre en consideración
otro factor: la promesa de que el producto entregado pueda generar oportunidades futuras para la organización, ya
sea en el ámbito comercial o técnico.26 En otras palabras, no es suficiente evaluar un proyecto de acuerdo con su éxito
inmediato, sino también hay que evaluarlo en términos de su éxito comercial, así como de su potencial para generar
nuevos negocios y oportunidades. La figura 1.7 ilustra un esquema que propone cuatro dimensiones claves de éxito:

• La eficiencia del proyecto:  cumplir las expectativas de presupuesto y de programación.


• Impacto sobre el cliente:  cumplir las especificaciones técnicas, de acuerdo con los requerimientos del
cliente y con el diseño de un proyecto que satisfaga sus necesidades.
• Éxito del negocio:  determinar si el proyecto logró un éxito comercial significativo.
• Preparación para el futuro:  determinar si el proyecto abrió nuevos mercados, nuevas líneas de pro-
ductos o contribuyó a desarrollar nuevas tecnologías.
Importancia

4
Preparación
para el futuro

3
Éxito del
negocio
2
Impacto sobre
1 el cliente
Eficiencia
del proyecto

Terminación Tiempo
del proyecto
FIGURA 1.7  Cuatro dimensiones claves en el éxito del proyecto
Fuente: A. J. Shenhar, O. Levy, and D. Dvir. (1997). “Mapping the Dimensions of Project
Success,” Project Management Journal, 28(2): 12. Todos los derechos reservados. El material
de esta publicación ha sido reproducido con permiso del PMI.
18 Capítulo 1  • Introducción

Este enfoque cuestiona el principio convencional de la triple restricción para evaluar el éxito de un proyecto.
Las empresas esperan que los proyectos no solo se ejecuten de manera eficiente (por lo menos), sino también que
se desarrollen para satisfacer las necesidades del cliente, lograr el éxito comercial y servir de conducto a nuevas
oportunidades de negocio. Incluso en el caso de un proyecto netamente interno (por ejemplo, la actualización
del software para el sistema de registro de pedidos de la empresa), los equipos de proyectos deben centrarse en las
necesidades del cliente y en la evaluación de posibles oportunidades comerciales o técnicas derivadas de su trabajo.

RECUADRO 1.2

INVESTIGACIÓN DE GERENCIA DE PROYECTOS EN SÍNTESIS


Evaluación del éxito de los proyectos de tecnología de la información (IT)
Como se señaló al principio de este capítulo, los proyectos de IT tienen un historial colmado de altibajos
cuando se trata de su implementación. Una parte del problema ha sido la incapacidad para definir en términos
concretos las características de éxito en un proyecto de IT. Los criterios para el éxito de los proyectos de IT a
menudo son bastante vagos y sin directrices claras, por lo que no sorprende que muchos de estos proyectos
no llenen las expectativas previas a su desarrollo. En 1992 y nuevamente en 2003, dos investigadores, W.
DeLone y E. McLean, analizaron varios estudios previos en proyectos de IT para identificar los indicadores críti-
cos de éxito. Sus conclusiones, sintetizadas de investigaciones previas, sugieren que los proyectos de IT deben
evaluarse al menos, de acuerdo con seis criterios:
• La calidad del sistema.  El equipo de proyecto debe suministrar un sistema capaz de asegurarle al
cliente que una vez implantado su desempeño será según se esperaba. Todos los sistemas deben satis-
facer unos criterios; por ejemplo, deben ser fáciles de usar y proporcionar información de calidad.
• Calidad de la información.  La información generada por la implementación de IT debe ser la reque-
rida por los usuarios y de calidad suficiente, es decir, “procesable”. En otras palabras, la información
generada no debería requerir esfuerzos adicionales para filtrar y clasificar los datos. Los usuarios del
sistema deben percibir la calidad de la información que ellos generan.
• Uso.  Una vez instalado, el sistema de IT debe usarse. Obviamente, la razón de cualquier sistema
informático es su utilidad para resolver problemas, la ayuda en la toma de decisiones y el mecanismo de
trabajo en red. El criterio de “uso” evalúa la utilidad real de un sistema mediante la determinación del
grado en el que, una vez implementado, es utilizado por el cliente.
• Satisfacción de los usuarios.  Una vez que el sistema se haya finalizado, el equipo del proyecto debe
determinar la satisfacción del usuario. Uno de los asuntos más controvertidos al evaluar el éxito del
proyecto tiene que ver con determinar de forma precisa la satisfacción del usuario. Considerando que
el usuario es el cliente y en última instancia es el juez de si el proyecto ha sido eficaz, es esencial que se
alcance un cierto grado de satisfacción del cliente con el sistema y sus resultados.
• Impacto individual.  Todos los sistemas deben ser fáciles de utilizar y suministrar información de cali-
dad. Pero más allá de satisfacer estas necesidades, ¿hay un criterio específico para determinar la utilidad
de un sistema para el cliente que lo encargó? ¿Es la toma de decisiones más rápida o más precisa? ¿La
información se recupera con mayor facilidad, es más accesible, o asimilada más fácilmente? En pocas
palabras, ¿el sistema beneficia a los usuarios en los aspectos más importantes para ellos?
• Impacto organizacional.  Finalmente, el proveedor del sistema debe ser capaz de determinar si este
impacta positivamente la organización del cliente. ¿Hay, por ejemplo, un efecto colectivo o sinérgico
sobre la corporación cliente? ¿Hay una sensación de bienestar o hay indicadores financieros y operacio-
nales que demuestren la eficacia y calidad del sistema?
El trabajo de DeLone y de McLean establece un marco de referencia para el éxito de los proyectos de IT.
Las empresas que diseñan e implementan sistemas de IT deben prestar inicialmente atención a cada uno de
estos criterios y tomar las medidas necesarias para garantizar su cumplimiento.27

Un modelo final, presentado recientemente, también argumenta en contra del modelo de la triple res-
tricción como medida del éxito de un proyecto. Según Atkinson,28 todos los interesados afectados por un pro-
yecto (stakeholders) deben tener cabida en la evaluación de su éxito. El contexto y el tipo de proyecto también
pueden ser relevantes en la determinación de los criterios que definirán más claramente su éxito o fracaso. El
cuadro 1.2 muestra el modelo de Atkinson, que considera el tradicional “triángulo de hierro” de costo, calidad
y tiempo como simplemente un subconjunto de componentes en un exhaustivo conjunto de medidas. Por
1.5  Modelos de madurez de la gerencia de proyectos 19

CUADRO 1.2  Criterios de éxito

Triángulo de Sistema de Beneficios Beneficios (interesados)


hierro información (organización)
Costo Mantenimiento Mejora de la eficiencia Usuarios satisfechos
Calidad Fiabilidad Mejora de la efectividad Mejora del impacto social y ambiental
Tiempo Validez Aumento de las ganancias Desarrollo de personal
Calidad de la Metas estratégicas Aprendizaje profesional, beneficios de
información los contratistas
Uso Aprendizaje organizacional Proveedores de capital, contenido
Disminución de residuos Equipo del proyecto, impacto económico
sobre la comunidad (entorno)

supuesto, los medios por los que un proyecto se va a medir deben decidirse antes de emprender el proyecto.
Un axioma empresarial, “Lo que se mide, se controla”, sugiere que cuando los equipos entienden los estándares
según los cuales se lleva a cabo un proyecto, pondrán más énfasis en los diversos aspectos claves de desempeño
del mismo. Considérese, por ejemplo, la implantación de un sistema de información. Si los criterios de éxito son
mejorar la eficiencia operativa y satisfacer a los usuarios, y si se identifica claramente la calidad como un benefi-
cio clave del producto terminado, el equipo va a centrar sus esfuerzos en estos aspectos del proyecto.

1.5  MODELOS DE MADUREZ DE LA GERENCIA DE PROYECTOS


Con el incremento de las prácticas de gerencia de proyectos en organizaciones globales, un fenómeno reciente es
el surgimiento de los modelos de madurez de la gerencia de proyectos. Estos modelos les permiten a las orga-
nizaciones realizar benchmarking de las mejores prácticas de gerencia de proyectos. En los modelos de madurez
de gerencia de proyectos se considera que actualmente las empresas se encuentran en diferentes niveles de com-
plejidad, respecto a las mejores prácticas para gestionar sus proyectos. Por ejemplo, sería razonable esperar que
compañías como Boeing (sistemas de defensa y aeronáutica) o Fluor-Daniel (construcción industrial) estén más
avanzadas en cómo gestionar proyectos, dada su amplia trayectoria en iniciativas de proyectos, en comparación
con una empresa que apenas esté haciendo énfasis en un enfoque de trabajo basado en proyectos.
El propósito del benchmarking es gestionar sistemáticamente el proceso de mejora en la ejecución de proyectos
por una organización durante un tiempo.29Debido a que hay muchas dimensiones en la práctica de la gerencia de
proyectos (GP), es común, en una nueva empresa al integrar la gerencia de proyectos en sus operaciones, preguntarse
“¿Por dónde debemos empezar?” Es decir, ¿cuáles de los procesos de GP debemos investigar, modelar y aplicar a nues-
tra organización? Los modelos de madurez proporcionan el marco de referencia para, primero, analizar y evaluar críti-
camente lo relacionado con la GP las prácticas actuales; segundo, para comparar estas prácticas con sus competidores
o algún estándar general de la industria; y tercero, para definir una forma sistemática a fin de mejorar esas prácticas.
Si se acepta el hecho de que el desarrollo de mejores prácticas de gerencia de proyectos es un proceso evolu-
tivo que no implica un salto repentino hacia un desempeño superior, sino más bien un compromiso sistemático
con la mejora continua, los modelos de madurez ofrecen un marco para definir y lograr esa mejora progresiva.30
En consecuencia, la mayoría de los modelos efectivos de madurez de proyectos comprenden tanto un conjunto de
estándares aceptados como el estado del arte actual, así como un proceso para lograr un movimiento significativo
hacia estos puntos de referencia. La figura 1.8 ilustra un método para definir las prácticas actuales de GP utilizadas en
una empresa.31 En ella se emplea una metodología de “telaraña” en la cual se identifica primero un grupo de prácticas
de GP significativas para organizaciones que pertenecen a un sector específico. En este ejemplo, una empresa puede
identificar ocho componentes de la GP que son claves para el éxito, basadas en el análisis de las necesidades propias de
la empresa, así como en puntos de comparación con firmas competidoras dentro de su sector. Se debe tener en cuenta
que cada uno de los anillos en la figura representa una evaluación crítica de la manera en que cada organización
alcanza los estándares del sector. Supóngase que las calificaciones tienen los siguientes significados:

Nivel del anillo Significado


0 No definida o pobre
1 Definida pero deficientemente
2 Estandarizada
3 Líder de la industria o vanguardista
20 Capítulo 1  • Introducción

Programación de proyectos

Desarrollo de personal Apoyo organizacional para


2
de proyectos la gerencia de proyectos

Trabajo en red
Gerencia de portafolio
entre proyectos

Gerencia de los Coaching, auditoría y


interesados del proyecto evaluación de proyectos

Prácticas de control
FIGURA 1.8  Diagrama de telaraña (radial) para la medición de la madurez del proyecto
Fuente: R. Gareis. (2001). “Competencies in the Project-Oriented Organization,” in D. Slevin,
D. Cleland, and J. Pinto, The Frontiers of Project Management Research. Newtown Square, PA:
Project Management Institute, pp. 213–24, figura en la p. 216. Todos los derechos reservados. El
material de esta publicación ha sido reproducido con permiso del PMI.

Continuando con el ejemplo, si en términos del desarrollo del personal del equipo del proyecto o de los
sistemas de control, nuestras prácticas son relativamente pobres en comparación con los competidores, podemos
decidir una calificación de 0 para estas habilidades. Por otro lado, si nuestros procesos de programación son de
primera categoría podemos calificarlos con 3. La figura 1.9 muestra un ejemplo del mismo diagrama de telaraña
(radial) con nuestros niveles de habilidad relativos a los ocho elementos clave de GP que hemos definido. Este ejer-
cicio nos ayuda a identificar en dónde nos encontramos actualmente en relación con la complejidad de GP, como
etapa clave en cualquier modelo de madurez, en el que buscamos pasar a un nivel superior.

Programación de proyectos
3

Desarrollo de personal Apoyo organizacional para


2
de proyectos la gerencia de proyectos

Trabajo en red
Gerencia de portafolio
entre proyectos

Gerencia de los Coaching, auditoría y


interesados del proyecto evaluación de proyectos

Prácticas de control
FIGURA 1.9  Diagrama de telaraña para evaluación de la organización
Fuente: R. Gareis. (2001). “Competencies in the Project-Oriented Organization,” in D. Slevin,
D. Cleland, and J. Pinto, The Frontiers of Project Management Research. Newtown Square, PA:
Project Management Institute, pp. 213–24, figura en la p. 216. Todos los derechos reservados. El
material de esta publicación ha sido reproducido con permiso del PMI.

CUADRO 1.3  Una comparación de los modelos de madurez del proyecto y sus etapas incrementales

Centro de prácticas comerciales


Nivel 1: proceso inicial Nivel 2: estructura, procesos y Nivel 3: gerencia de proyectos Nivel 4: gerenciado Nivel 5: optimización
• Procesos ad hoc normas institucionalizada • Las prácticas de gerencia de • Procesos para medir la
• Conocimiento de la • Procesos básicos, no estanda- • Todos los procesos del proyectos integrados con los eficiencia de los proyectos
gestión rizados en todos los proyectos proyecto son repetibles procesos corporativos • Procedimientos implantados
• La administración apoya el uso • Los estimativos, programa- • Análisis sólido del desempeño para mejorar el desempeño
• Estimativos, programaciones ciones basadas en estánda- del proyecto del proyecto
basadas en el conocimiento res de la industria • Estimativos, horarios basados en • La empresa se centra en la
experto especificaciones corporativas mejora continua
Modelo de madurez de gerencia de proyectos de Kerzner
Nivel 1: lenguaje común Nivel 2: procesos comunes Nivel 3: metodología propia Nivel 4: benchmarking Nivel 5: mejora continua
• Uso esporádico de la • Beneficios tangibles • Procesos integrados • Análisis y evaluación de las • Lecciones aprendidas,
gerencia de proyectos evidentes • Soporte cultural y de prácticas archivos creados
• Pequeños focos de • Apoyo a la GP en toda la gerencial • Oficina del proyecto establecida • Transferencia de conoci-
interés en la empresa empresa • Beneficio económico por la mientos entre los equipos
• Ninguna inversión en for- • Desarrollo de un plan de formación en GP • Programa de tutoría
mación en GP estudios en GP
Marco de proyectos de ESI International
Nivel 1: ad hoc Nivel 2: consistente Nivel 3: integrado Nivel 4: integral Nivel 5: optimización
• Procesos mal definidos • La organización tiene • Los procesos están diseña- • GP aplicada plenamente en toda • Esfuerzo continuo para
porque se aplican de buenas intenciones en sus dos para mejorar todos los la empresa mejorar e innovar la capaci-
forma individual métodos aspectos de GP • La información se utiliza para evaluar dad de proyecto
• Poco apoyo de la • No hay procesos de control • Uso común y comprensión los procesos y reducir la variación • Las fallas comunes se
organización de proyectos o lecciones de los métodos a través de • Se elaboran herramientas y eliminan
aprendidas la empresa técnicas avanzadas de GP
Modelo de integración de capacidad y madurez del SEI
Nivel 1: inicial Nivel 2: gestionado Nivel 3: definido Nivel 4: gerencia cuantitativa Nivel 5: optimización
• Ad hoc, procesos • Requerimientos de la geren- • Desarrollo de requeri- • Se mide el desempeño del • Innovación acentuada
caóticos cia, planeación y control de mientos e integración de proceso • Se realiza análisis y
proyectos productos • GP cuantitativa resolución de causalidad
• Se realiza control de calidad • Se enfatiza en verifica-
de proceso ción y validación de los
• Se utiliza la gerencia de procesos
configuración • Se enfatiza la gerencia del
1.5  Modelos de madurez de la gerencia de proyectos

riesgo

21
21
22 Capítulo 1  • Introducción

Una vez establecidas nuestras capacidades actuales en GP, así como nuestras deficiencias, el siguiente
paso en el proceso del modelo de madurez es trazar un camino incremental paso a paso hacia nuestra meta
deseada. El cuadro 1.3 de la página 21 muestra algunos de los modelos de madurez de proyectos más comu-
nes y los niveles intermedios que estos han identificado en ruta al más alto grado de experticia en proyectos
para una organización. Algunos de esos modelos fueron desarrollados por empresas privadas de consultoría
en GP o por empresas profesionales en proyectos.
Es interesante comparar y contrastar cuatro de los modelos de madurez identificados en el cuadro 1.3. Estos
ejemplos son tomados de los más conocidos en el ámbito, incluido el modelo de integración de capacidad y madu-
rez de Carnegie Mellon University’s Software Engineering Institute’s (SEI), el modelo de madurez de gerencia de
proyectos de Harold Kerzner, el modelo marco de proyectos de ESI International y el modelo de madurez desa-
rrollado por el Center for Business Practices.32 Al ilustrar estas dimensiones en forma de pirámide, podemos ver la
progresión hacia la madurez en GP (véase figura 1.10). A pesar de algunas diferencias en terminología, se presenta
un claro patrón entre estos modelos. Por lo general empiezan con el supuesto de que las prácticas de GP dentro de
la empresa no son planeadas ni empleadas colectivamente; de hecho, es posible que no se cuente con un lenguaje
común o método para llevar a cabo la GP. A medida que una empresa progresa en la madurez de GP, empieza a
adoptar prácticas comunes, inicia programas para capacitar a sus profesionales en GP, establece procesos y pro-
cedimientos para iniciar y controlar sus proyectos, y así sucesivamente. Finalmente, en la última fase, una organi-
zación no solamente se considera “inteligente en proyectos” sino también que ha progresado más allá de la simple
aplicación de GP a sus procesos y se encuentra explorando activamente formas para mejorar continuamente sus
técnicas y procedimientos de GP. Durante la etapa final, una organización puede considerarse verdaderamente
“madura en proyectos”, porque ha interiorizado todos los principios de GP necesarios y busca sobrepasarlos acti-
vamente mediante la aplicación de estrategias innovadoras.
Los modelos de madurez en gerencia de proyectos han sido muy útiles en años recientes, precisamente
porque reflejan el creciente interés en la GP; además, porque destacan uno de los problemas más recurren-
tes: la falta de una guía clara para las empresas en la adopción, adaptación y mejoramiento de estos procesos
para uso óptimo. La característica principal de estos modelos es el reconocimiento de que el cambio general-
mente no ocurre abruptamente; es decir, las empresas que desean convertirse en expertas en los métodos de
GP no pueden progresar simplemente implementando medidas inmediatas y pasar de la falta de compren-
sión de la GP a las prácticas óptimas en proyectos. Por el contrario, los modelos de madurez demuestran que
la “madurez” es un proceso progresivo, basado en la mejora continua con pasos graduales identificables. Una
vez tenemos una idea exacta de dónde nos encontramos dentro del proceso de madurez, podemos deter-
minar un plan de acción razonable para progresar al nivel deseado. De esta manera, cualquier empresa, sin
importar inicialmente cuán inexperta sea en GP, puede plantear un camino hacia el tipo de organización de
proyectos que quiere llegar a ser.

Nivel de
madurez alto
institucionalizado,
se busca la
mejora continua

Nivel de madurez moderado


Prácticas definidas, programas de
entrenamiento, apoyo organizacional

Nivel de madurez bajo


Proceso ad hoc, no hay un lenguaje común, poco apoyo

FIGURA 1.10  Madurez en gerencia de proyectos - Modelo genérico


22
1.6  Elementos del proyecto y organización del libro 23

1.6  ELEMENTOS DEL PROYECTO Y ORGANIZACIÓN DEL LIBRO


Este libro fue escrito para proveer un enfoque holístico basado en gestión para la gerencia de proyectos.
Es holístico porque entreteje una amplia variedad de tareas, responsabilidades y conocimiento útiles que
los gerentes de proyectos deben adquirir. La gerencia de proyectos es una tarea amplia y emocionante, que
obliga a entender aspectos de la ciencia de la administración en la generación de programaciones, asignación
de recursos, seguimiento y control de proyectos, etc. Al mismo tiempo, los gerentes exitosos de proyectos
deben integrar asuntos fundamentales de la ciencia del comportamiento, los cuales implican el conocimiento
de los seres humanos, las prácticas de liderazgo, el desarrollo de la motivación y del equipo, resolución de
conflictos y habilidades de negociación. En verdad, un enfoque de “ciencia dura” hará que las futuras respon-
sabilidades de gerencia de proyectos tengan más éxito del que se obtendría al mantenerse enfocados en una
perspectiva “basada en las personas” exclusivamente. La gerencia de proyectos es una mezcla emocionante y
desafiante de ciencia y arte de gestión.
La figura 1.11 ofrece un modelo para la organización de este libro. La figura es un diagrama de Gantt, para
la programación de un proyecto y su sistema de control. Sin embargo, por ahora, se puede aplicar a la estruc-
tura de este libro, centrándose en algunas de sus características más sencillas. En primer lugar, tenga en cuenta
que todos los capítulos del libro se enumeran en la columna de la izquierda. Al otro lado de la parte inferior
y de izquierda a derecha hay una línea de tiempo que ilustra el punto en el que se presentará cada uno de los
temas de los capítulos. Por razones de simplicidad, la línea de tiempo del eje X se ha dividido en las cuatro
fases del proyecto siguiendo más o menos su ciclo de vida discutido anteriormente en este capítulo: (1) concep-
tualización, (2) planeación, (3) ejecución y (4) terminación. Nótese que algunos de los temas que se tratarán en
el libro son relevantes solamente durante ciertas fases del proyecto; otros, como el liderazgo, son importantes
en gran parte del ciclo de vida del proyecto. Entre los beneficios de la creación de un libro para esta secuencia
están: primero, mostrar la importancia de la combinación de los temas humanos (liderazgo y formación de
equipos) directamente con elementos científicos y analíticos de la gerencia de proyectos. No podemos seccionar
nuestro enfoque de gerencia de proyectos como algo exclusivamente técnico o de comportamiento, pues las dos
son las caras de la moneda y deben apreciarse conjuntamente; segundo, la estructura provee una simple lógica
de ordenamiento de los capítulos y el estado del proyecto en el cual estamos más probablemente interesados
dentro de ese tema. Algunos conceptos, como se ilustra en la figura 1.11, están más orientados a la planeación
del proyecto, mientras que otros comienzan a ser más críticos en fases posteriores del proyecto. Si se aprecian
los componentes de la gerencia de proyectos y su secuencia apropiada, es una guía de aprendizaje importante.
Finalmente, la figura 1.11 ofrece un intuitivo y atractivo método para destacar la estructura y el flujo que segui-
remos a través de los temas en el libro.
En la etapa de conceptualización, hay que centrarse necesariamente en el entorno de la organización
dentro de la cual se crean, seleccionan y desarrollan los proyectos. Algunos de los aspectos críticos que pue-
den afectar la manera en que los proyectos se ejecutan con éxito se relacionan con el contexto de la estrategia,
estructura y cultura organizacional. Cualquiera de estos elementos puede prepararse para apoyar el trabajo
basado en proyectos o puede no estarlo. En el primer caso, es más fácil de ejecutar proyectos y lograr resul-
tados positivos para la organización. Como resultado, es útil entender con claridad el papel que el entorno o
contexto organizacional desempeña en la gerencia de proyectos.


&DS ž3RUTXp*3"

&DS (VWUDWHJLDHVWUXFWXUD\FXOWXUD

&DS 6HOHFFLyQGHOSUR\HFWR

&DS (OOLGHUD]JRGHOSUR\HFWR

&DS *HUHQFLDGHODOFDQFH

&DS )RUPDFLyQGHHTXLSRV\FRQIOLFWRV

&DS *HUHQFLDGHOULHVJR

&DS (VWLPDFLyQGHFRVWRV\SUHVXSXHVWR

&DS 3URJUDPDFLyQ,

&DS3URJUDPDFLyQ,,

&DS3URJUDPDUODFDGHQDFUtWLFD

&DS*HUHQFLDGHUHFXUVRV

&DS(YDOXDFLyQ\FRQWUROGHSUR\HFWRV

&DS7HUPLQDFLyQGHOSUR\HFWR

Conceptualización Planeación Ejecución Terminación


FIGURA 1.11  Organización del libro
24 Capítulo 1  • Introducción

En el capítulo 3 exploramos el proceso de filtrado y selección de proyectos. La manera en que una


empresa selecciona los proyectos que decide emprender es a menudo crítica para sus posibilidades de desa-
rrollo exitoso y su rentabilidad comercial. El capítulo 4 introduce el desafío de la gerencia de proyectos desde
la perspectiva del líder del proyecto. La gerencia proyectos es un emprendimiento extremadamente “inten-
sivo para el líder”. El gerente del proyecto es el punto focal del proyecto y a menudo funciona como un CEO
en miniatura. En la medida que más gerentes de proyectos entiendan sobre el liderazgo del proyecto y las
competencias requeridas para ser eficaces, las compañías podrán iniciar la formación de gerentes de proyec-
tos dentro de sus propias filas.
La segunda fase se relaciona con los problemas anticipados de la planeación de proyectos. Una vez tomada la
decisión, la organización debe seleccionar primero un gerente de proyectos adecuado para supervisar el desarrollo
del proceso. Inmediatamente, el gerente del proyecto se enfrenta con una serie de responsabilidades, entre ellas:
1. Seleccionar el equipo—La conformación de equipos y la gestión de conflictos son los primeros retos
con los que se enfrentan los gerentes de proyectos.
2. Determinar los objetivos del proyecto y un plan de ejecución—La identificación de los requisitos del
proyecto y un plan lógico para su desarrollo son cruciales.
3. Realizar actividades de gerencia de riesgos—Los proyectos no se desarrollan sin un sentido claro de
los riesgos involucrados en la planeación e implementación.
4. Estimar los costos y elaborar el presupuesto—Dado que los proyectos son actividades con recursos
limitados, elaborar y estimar cuidadosamente los presupuestos son aspectos críticos.
5. Programar—El corazón de la planeación del proyecto se centra en el proceso de creación de cronogramas
claros, agresivos, pero razonables que tracen el camino más eficiente hasta la terminación del proyecto.
6. Gestionar los recursos—El último paso en la planeación de proyectos es la administración cuidadosa de los
recursos del proyecto, incluido el personal del equipo, para llevar a cabo las tareas de manera más eficiente.
El capítulo 5, en el cual se analiza la gestión del alcance del proyecto, examina las características claves
del plan general. “La gestión del alcance del proyecto” es una expresión que engloba un número de elementos
en el proceso general de planeación del proyecto. En este capítulo se desarrollan diferentes técnicas de pla-
neación y los pasos para conseguir que un proyecto inicie con el pie derecho.
El capítulo 6 aborda algunos de los desafíos de comportamiento que enfrentan los gerentes de proyectos en
términos de efectividad en la formación de equipos y gestión de conflictos. Otro componente clave de una gerencia
eficaz de los recursos humanos es la necesidad de crear y mantener equipos de alto rendimiento. Efectivamente, la
conformación del equipo y el cuidado de sus integrantes, a menudo personas de muy diferentes orígenes, es un reto
constante que requiere considerarse seriamente. El conflicto ocurre en una serie de niveles, no solo entre los miem-
bros del equipo, sino entre el equipo y los interesados del proyecto, incluidos la alta gerencia y los clientes. En este
capítulo se identifican algunas de las principales causas de los conflictos y se explican varios métodos para resolverlos.
El capítulo 7 analiza la gestión de riesgos del proyecto. En años recientes, esta área de la gestión de proyectos
se ha convertido cada vez en algo más importante para las empresas que quieren garantizar, en lo posible, que las
decisiones de selección de proyectos sean acertadas, que todos los riesgos y el potencial negativo sea considerado y,
dado el caso, se desarrollen planes de contingencia apropiados. El capítulo 8 cubre la estimación de costos y presu-
puestos. Debido a que los gerentes y equipos de proyectos mantienen los estándares de rendimiento y control de
costos, también es importante entender las características claves de estimación de costos y presupuestos.
Los capítulos 9 y 10 se enfocan en las metodologías de programación, las cuales son un aspecto clave de la
gerencia de proyectos. Estos capítulos analizan en profundidad varias herramientas de programación, softwares
para hacer programación de proyectos y explica algunos avances recientes en programación de proyectos. El capí-
tulo 11 describe un reciente desarrollo en programación de proyectos, el desarrollo y aplicación de la cadena crítica
en programación de proyectos. El capítulo 12 considera los desafíos de asignación de recursos. Una vez varias activi-
dades del proyecto se han identificado, debemos asegurar la asignación de recursos necesarios para llevarlas a cabo.
El tercer proceso de gerencia de proyectos, ejecución, se entiende más fácilmente como la etapa en la
que el “trabajo” real del proyecto, está realizándose. Por ejemplo, los ingenieros y otros expertos técnicos
determinan el conjunto de tareas necesarias para completar el proyecto en su conjunto, incluidas sus respon-
sabilidades de tareas individuales, y cada una de las tareas se gestiona activamente por el equipo para ase-
gurarse de que no haya retrasos significativos que puedan generar que el proyecto exceda su programación.
El capítulo 13 trata sobre los retos de la evaluación y control de proyectos. Durante la fase de ejecución, es
posible que se presente una alta ambigüedad respecto al estado del proyecto, a menos que se tomen medidas
prácticas y concretas para establecer un método claro para el seguimiento y control del proyecto.
Por último, los procesos de terminación del proyecto reflejan el hecho de que un proyecto es un esfuerzo
organizacional único, marcado por un inicio y final específicos. El proceso de cierre de un proyecto, ya sea
1.6  Elementos del proyecto y organización del libro 25

debido a la necesidad de “liquidarlo” porque no es viable o a través de los pasos planeados para su terminación,
tiene sus propios desafíos. Una serie de procedimientos se han desarrollado para hacer este proceso lo más
fluido y lógico posible. El capítulo 14 analiza los elementos del cierre del proyecto, la fase en la cual el proyecto
está concluido y los recursos (tanto monetarios como humanos) se reasignan.
Este libro fue escrito para ayudar a crear una nueva generación de gerentes de proyectos efectivos.
Explorando los diferentes roles de los gerentes de proyectos y abordando los desafíos y oportunidades que
ellos constantemente enfrentan, ofrecemos un enfoque comprensivo e integral para entender de mejor forma
las tareas de los gerentes de proyectos, un enfoque que explora un rango de desafíos estratégicos, técnicos, de
comportamiento y deberes de los gerentes de proyectos.
Este libro también incluye, al final de los capítulos más importantes, una serie de actividades diseñadas para
ayudar a los estudiantes a desarrollar planes de proyectos exhaustivos. Es esencial que las personas que realizan un
curso de gerencia de proyectos se entusiasmen con el conocimiento práctico sobre los pasos necesarios para crear
un proyecto, planear su desarrollo y supervisar su trabajo. Los gerentes del futuro requieren desarrollar habilidades
para convertir la teoría de la gerencia de proyectos en el arte de la práctica exitosa. Con esta meta en mente, el libro
contiene una serie de ejercicios diseñados para ayudar a los profesores y estudiantes a construir planes completos
de proyectos. Las actividades involucran el desarrollo, de comienzo a fin, del plan del proyecto, análisis de riesgos,
estructura de descomposición de trabajo, estimación de actividades y diagrama de red, nivelación de recursos,
presupuestación del proyecto, y así sucesivamente. Para darle sentido real al proceso, los capítulos finales también
incluyen una serie de problemas hipotéticos. Al final del curso, el estudiante debería haber creado un documento
de proyecto completo que detalle los pasos necesarios para convertir los planes del proyecto en logros prácticos.
Como una plantilla para suministrar ejemplos, el libro emplea una compañía hipotética llamada
ABCups Inc., la cual está a punto de iniciar un proyecto importante. Las actividades de los capítulos finales,
que incluyen ejercicios de programación, presupuesto, gestión de riesgos, etcétera, frecuentemente presentan
ejemplos del proyecto de ABCups para que los estudiantes los usen como modelo para sus propios trabajos.
De este modo, a los estudiantes se les presentan ejemplos para que generen sus propios entregables en la
medida en que ellos construyen gradualmente sus planes de proyecto.
Una característica adicional de este libro es la articulación entre los conceptos discutidos a lo largo y
ancho del mismo y el Cuerpo de Conocimiento de la Dirección de Proyectos (Project Management Body of
Knowledge: PMBOK) el cual fue desarrollado por el Project Management Institute (PMI). Como organización
profesional en la gerencia de proyectos líder en el mundo, el PMI ha estado a la vanguardia de los esfuerzos por
normalizar las prácticas de gerencia de proyectos y la codificación de las habilidades necesarias para tener éxito
en este campo. El PMBOK identifica diez áreas de conocimiento sobre habilidades y actividades de gerencia de
proyectos que todos los practicantes requieren dominar. Estas áreas de conocimiento, las cuales se muestran en
la figura 1.12, abarcan una visión general de los procesos de la gerencia de proyectos. Aunque no es mi inten-
ción crear un libro que sirva como texto fundamental para tomar un examen de certificación profesional, es
importante para nosotros reconocer que las habilidades que nosotros desarrollamos a través de la lectura de este
material son directamente aplicables a las áreas de conocimiento de la gerencia de proyectos.
Los estudiantes encontrarán varios enlaces al PMBOK en este texto. Primero, las palabras claves y sus
definiciones están diseñadas para seguir el glosario del PMBOK (incluidas como un apéndice al final del
libro). Segundo, el capítulo introductorio también destaca referencias al PMBOK. Podemos ver como cada
capítulo no solamente adiciona nuestro conocimiento en gerencia de proyectos sino también directamente
enlaza a elementos dentro del PMBOK. Finalmente, muchos ejercicios al final de cada capítulo y referencias
a internet requieren interacción directa con el PMI a través de su website.
Como un enlace adicional al PMI y al PMBOK, este libro incluye preguntas de ejemplo al final de los capítu-
los relevantes para permitir al estudiante probar su conocimiento en aspectos del PMBOK. Cerca de 20 años atrás,
el PMI creó la certificación Profesional en Gerencia de Proyectos (Project Management Professional: PMP) como
medio para reconocer aquellos con un conocimiento de experto en la práctica de la gerencia de proyectos. La cer-
tificación PMP es la más alta designación profesional para confirmar experiencia en gerencia de proyectos a nivel
mundial. Requiere conocimiento profundo en las diez áreas del PMBOK. La inclusión de preguntas al final de los
capítulos ofrece al estudiante una forma de evaluar qué tan bien ha aprendido los temas del curso, la naturaleza de
las preguntas PMP y reconocer las áreas que pueden requerir estudio adicional.
Este libro ofrece una oportunidad a los estudiantes para convertirse en expertos en un nuevo arte,
un conjunto de habilidades que cada vez se valoran más en empresas modernas alrededor del mundo. Los
gerentes de proyectos representan la nueva élite corporativa: un cuerpo de individuos calificados que rutina-
riamente ponen en orden el caos, mejoran la razón fundamental de la organización y refinan su propio valor
en el proceso. Con esta meta en mente, comencemos.33
26 Capítulo 1  • Introducción

Gerencia de proyectos

4. Gerencia de la integración 5. Gerencia del alcance 6. Gerencia del tiempo 7. Gerencia de los
del proyecto del proyecto del proyecto costos del proyecto
4.1 Desarrollar el acta del proyecto 5.1 Planear la gerencia del alcance 6.1 Planear la gerencia del 7.1 Planear la gerencia de
4.2 Desarrollar el plan de gerencia 5.2 Recolectar requerimientos cronograma los costos
del proyecto 5.3 Definir el alcance 6.2 Definir las actividades 7.2 Estimar los costos
4.3 Dirigir y gestionar el trabajo 5.4 Crear la EDT 6.3 Secuenciar las actividades 7.3 Determinar el presupuesto
del proyecto 5.5 Validar el alcance 6.4 Estimar los recursos 7.4 Controlar los costos
4.4 Monitorear y controlar el trabajo 5.6 Controlar el alcance 6.5 Estimar la duración de las
del proyecto actividades
4.5 Ejecutar el control integrado 6.6 Desarrollar el cronograma
de cambios 6.7 Controlar el cronograma
4.6 Cerrar el proyecto o fase

8. Gerencia de la 9. Gerencia de los recursos 10. Gerencia de las 11. Gerencia del riesgo
calidad del proyecto humanos del proyecto comunicaciones del proyecto del proyecto
8.1 Planear la gestión de la calidad 9.1 Planear la gerencia de recursos 10.1 Planear la gerencia de las 11.1 Planear la gerencia de riesgos
8.2 Realizar el aseguramiento de humanos comunicaciones 11.2 Identificar los riesgos
la calidad 9.2 Adquirir el equipo del proyecto 10.2 Gestionar las comunicaciones 11.3 Realizar el análisis cualitativo
8.3 Controlar la calidad 9.3 Desarrollar el equipo del proyecto 10.3 Controlar las comunicaciones de riesgos
9.4 Gerenciar el equipo del proyecto 11.4 Realizar el análisis cuantitativo
de riesgos
11.5 Planear la respuesta a
12. Gerencia de las 13. Gerencia de los interesados los riesgos
adquisiciones del proyecto (stakeholders) del proyecto 11.6 Controlar los riesgos
12.1 Planear las adquisiciones 13.1 Identificar a los interesados
12.2 Efectuar las adquisiciones 13.2 Planear la gerencia de
12.3 Controlar las adquisiciones los interesados
12.4 Cerrar las adquisiciones 13.3 Gestionar la participación
de los interesados
13.4 Controlar la participación
de los interesados

FIGURA 1.12  Descripción general de las áreas de conocimiento del PMBOK del Project Management Institute
Fuente: Project Management Institute. (2013). A Guide to the Project Management Body of Knowledge (PMBOK Guide), 5th
ed. Project Management Institute, Inc. Derechos de autor y todos los derechos reservados. El material de esta publicación ha
sido reproducido con permiso del PMI.

Resumen
1. Entender por qué la gerencia de proyectos se está con- con un ciclo de vida claro. Se utilizan como cimientos en
virtiendo en una práctica tan poderosa y popular en los el diseño y ejecución de estrategias organizacionales, pro-
negocios.  La gerencia de proyectos ofrece a las empre- porcionan una filosofía y una estrategia para la gestión del
sas una serie de ventajas competitivas concretas, inclui- cambio. Otras razones por las que son un reto incluyen el
das la capacidad de ser a la vez eficaces en el mercado y hecho de que la gerencia del proyecto requiere traspasar
eficientes con el uso de recursos de la organización y la fronteras funcionales y empresariales, con el fin de tratar
posibilidad de lograr avances tecnológicos para simplifi- de satisfacer las múltiples restricciones de tiempo, presu-
car el desarrollo de nuevos productos y para enfrentar los puesto, funcionalidad y satisfacción del cliente.
desafíos que surgen del entorno empresarial. 4. Distinguir entre las prácticas de gerencia de proyec-
2. Reconocer las propiedades básicas de los proyectos, tos y las funciones empresariales más tradicionales
incluida su definición.  Los proyectos se definen como orientadas a los procesos.  Los proyectos involucran
un esfuerzo temporal emprendido para crear un pro- un nuevo proceso o ideas de nuevos productos, por
ducto o servicio único. Entre sus principales propiedades lo general con un objetivo o un conjunto limitado de
están: los proyectos son complejos, son un proceso tem- objetivos. Son actividades realizadas una sola vez con
poral con presupuesto, cronograma y recursos limitados, un comienzo y un final definidos, que emplean a un
se desarrollan para resolver un objetivo claro o un con- grupo heterogéneo de miembros de la organización
junto de objetivos y están enfocados en los clientes. como equipo del proyecto. Operan en circunstancias
3. Entender por qué la gerencia eficaz de los proyectos es de cambio y de incertidumbre, fuera de los canales
un desafío.  Los proyectos operan fuera de los procesos normales de la organización, y tienen por objeto alte-
normales de la organización caracterizados por el trabajo rar el status quo y quebrantar la práctica establecida, si
realizado por las unidades funcionales. Debido a que son es necesario, con el fin de lograr los objetivos del pro-
únicos, requieren un esquema mental diferente: es tem- yecto. Las funciones orientadas a procesos se ajustan
poral y dirigido a lograr un objetivo concreto dentro de mejor a reglas rígidas, canales de comunicación y pro-
un tiempo limitado. Los proyectos son esfuerzos ad hoc cedimientos de la organización. Las personas dentro
Términos clave 27

de los departamentos funcionales son homogéneas, cliente con el producto terminado. Otros modelos de
participan en las actividades en curso, con los sistemas éxito del proyecto para proyectos de IT emplean medi-
y procedimientos bien definidos. Ellos representan das como: (1) la calidad del sistema, (2) la calidad de la
bastiones de la práctica establecida con el objetivo de información, (3) el uso, (4) la satisfacción del usuario, (5)
reforzar el status quo de la empresa. el impacto individual y (6) el impacto organizacional.
5. Reconocer los aspectos clave que motivan a las 8. Entender el propósito de los modelos de madurez de
empresas a adoptar prácticas de gerencia de proyec- gerencia de proyectos y el proceso de evaluación com-
tos.   Entre los motivadores clave en el impulso a las parativa (benchmarking) de las organizaciones. Los
organizaciones para adoptar la gerencia de proyectos se modelos de madurez de gerencia de proyectos se uti-
encuentran: (1) ciclos de vida de los productos más cor- lizan para permitir a las organizaciones comparar las
tos, (2) estrechos lapsos para el lanzamiento de produc- mejores prácticas de gerencia de proyectos en empresas
tos, (3) productos cada vez más complejos y técnicos, (4) exitosas. Los modelos de madurez del proyecto reco-
mercados globales emergentes y (5) un periodo econó- nocen que diferentes organizaciones se encuentran en
mico marcado por una baja inflación. diversos niveles de complejidad en sus mejores prácticas
6. Comprender y explicar el ciclo de vida del proyecto, sus de gerencia de proyectos. El propósito de la evaluación
fases y las actividades que normalmente se producen en comparativa es gestionar de forma sistemática las mejo-
cada etapa del proyecto.  El ciclo de vida del proyecto ras en los procesos de ejecución de los proyectos por una
es un mecanismo que vincula el tiempo a las actividades sola organización durante un periodo. A medida que una
del proyecto y se refiere a las etapas del desarrollo de un empresa se compromete a implementar las prácticas de
proyecto. Las etapas comunes que se utilizan para descri- gerencia de proyectos, los modelos de madurez le ofrecen
bir el ciclo de vida de un proyecto son: (1) conceptuali- un proceso útil, de múltiples etapas para avanzar a través
zación, (2) planeación, (3) ejecución y (4) terminación. de los crecientes niveles de complejidad en la experticia
Un conjunto amplio y diverso de actividades se realiza de proyectos.
durante las diferentes etapas del ciclo de vida; por ejem- 9. Identificar los estados más importantes de madurez
plo, durante la fase de conceptualización se desarrolla la que las organizaciones atraviesan para convertirse en
misión básica y el alcance del proyecto y se identifican las expertas en el uso de técnicas de gerencia de proyec-
principales partes interesadas para apoyar el desarrollo tos.  Aunque existe un número de modelos de madu-
del proyecto. Durante la planeación, se crean numerosos rez del proyecto, varios de los más comunes comparten
planes y programas para guiar el proceso de desarrollo. algunas características básicas. Por ejemplo, la mayoría
Durante la ejecución se requiere que el trabajo principal toman como punto de partida el supuesto de que las
del proyecto se lleva a cabo, y por último, en la fase de ter- organizaciones poco complejas, inician sus proyectos
minación, el proyecto está completo, el trabajo está finali- de una manera ad hoc, con poco conocimiento o pro-
zado y el proyecto se transfiere al cliente. cedimientos compartidos a nivel general. A medida
7. Comprender el concepto de “éxito” del proyecto con la que la empresa se mueve a través de pasos interme-
incorporación de diversas definiciones de éxito y tam- dios, comenzará a iniciar procesos y procedimientos
bién de modelos alternativos de éxito. Originalmente, de gerencia de proyectos que difunden un conjunto
el éxito del proyecto se basa simplemente en un modelo básico de técnicas de gerencia de proyectos y actitu-
de triple restricción que recompensa los proyectos si han des culturales en toda la organización. Finalmente, la
sido realizados cumpliendo el cronograma, el presupuesto última etapa en los modelos tradicionales de madurez
y la funcionalidad. Sin embargo, este modelo ignora el se reconoce que en este punto la empresa ha ido más
énfasis que tiene que hacerse en los clientes del proyecto. allá de simplemente aprender las técnicas de gerencia
En términos más precisos, el éxito del proyecto implica de proyectos y se encuentra trabajando en procesos
una “ cuádruple restricción”, vinculando los indicadores de mejora continua con el propósito de perfeccionar,
básicos de calendario, cumplimiento del presupuesto, la mejorar y consolidar la filosofía de gerencia de proyec-
calidad del proyecto (funcionalidad) y la satisfacción del tos entre sus empleados y departamentos.

Términos clave
Aceptación del cliente Clientes (p. 14) Modelos de madurez en Proyecto (p. 5)
(p. 16) Desempeño (p. 16) gerencia de proyectos Interesados (stakeholders)
Benchmarking (p. 19) Entregables (p. 5) (p. 19) (p. 13)
Ciclo de vida del proyecto Éxito del proyecto (p. 16) Presupuesto (p. 16) Tiempo (p. 16)
(p. 12) Gerencia de proyectos (p. 8) Proceso (p. 5) Triple restricción (p. 15)
28 Capítulo 1  • Introducción

Preguntas para discusión


1. ¿Cuáles son algunas de las principales razones por las que la temáticos le resultan particularmente impresionantes? ¿Cómo
gerencia de proyectos se ha convertido en una herramienta de puede una empresa como Disney equilibrar la necesidad de efi-
negocios muy popular en los últimos años? ciencia y el buen desarrollo de sus proyectos con el deseo de
2. ¿Cuáles son los principales desafíos para la introducción de una ser innovadora y creativa? Basado en este caso, ¿qué principios
filosofía de gerencia de proyectos en la mayoría de las orga- parecen guiar su proceso de desarrollo?
nizaciones? Es decir, ¿por qué es difícil cambiar a un enfoque 8. Tenga en cuenta los seis criterios para el éxito de los proyec-
basado en proyectos en muchas empresas? tos de IT. ¿Por qué a menudo es tan difícil de evaluar el éxito
3. ¿Cuáles son las ventajas y desventajas del uso de la gerencia de del proyecto? Explique por qué algunos de los factores son más
proyectos? importantes que otros.
4. ¿Qué características fundamentales tienen todos los proyectos? 9. A medida que las organizaciones buscan mejorar en la gerencia
5. Describa los elementos básicos del ciclo de vida del proyecto. de proyectos, con frecuencia se involucran en el benchmarking
¿Por qué la comprensión del ciclo de vida es importante para la con otras compañías de sectores similares. Discuta el concepto
comprensión de los proyectos? de benchmarking. ¿Cuáles son sus objetivos? ¿Cómo funciona
6. Piense en un proyecto no exitoso y en uno exitoso con los que la evaluación comparativa?
esté familiarizado. ¿Qué distingue a los dos, tanto en términos 10. Explique el concepto de modelo de madurez de gerencia de
de los procedimientos utilizados para desarrollarlos como en proyectos. ¿Para qué sirve?
sus resultados? 11. Compare y contraste los cuatro modelos de madurez en geren-
7. Considere el caso Expedición al Everest de Disney: ¿qué ele- cia de proyectos que se muestran en el cuadro 1.3. ¿Qué fortale-
mentos del enfoque de Disney para el desarrollo de sus paseos zas y debilidades percibe en cada uno de los modelos?

Estudio de caso 1.1


MegaTech, Inc.
MegaTech, Inc., diseña y fabrica componentes de auto- meta significa rediseños anuales y nuevas tecnologías,
motores. Durante años, la empresa disfrutó de un mer- lo cual, a su vez, significaba hacer cambios innovado-
cado estable, un pequeño pero leal grupo de clientes y un res en las operaciones de la empresa. Para hacer estos
ambiente relativamente predecible. Aunque lentamente, ajustes, se conformaron equipos de proyectos especiales
hasta hace poco las ventas anuales continuaron creciendo en torno de cada una de las líneas de productos de la
y llegaron a 300 millones de dólares. Los productos de compañía y se les dio la orden de mantener la competi-
MegaTech eran populares porque requerían poca actua- tividad en el mercado.
lización o rediseño cada año. La estabilidad de su mer- Sin embargo, al mismo tiempo, MegaTech quería
cado, junto a la consistencia de su producto, permitió a mantener sus eficiencias operativas internas. Así, a todos
MegaTech pronosticar con exactitud la demanda anual, los equipos de proyecto se les asignó un costo estricto y
depender de una producción con plazos de entrega largos unas directrices de programación para la introducción de
y concentrarse en la eficiencia interna. nuevos productos. Por último, la empresa creó un sofisti-
Luego, con la entrada del Acuerdo Norteamericano de cado equipo de investigación y desarrollo, responsable de
Libre Comercio (North American Free Trade Agreement: encontrar nuevas formas para el cambio tecnológico en el
NAFTA) y otros acuerdos comerciales internacionales, trayecto de entre 5 y 10 años. Hoy día, MegaTech opera
MegaTech se encontró compitiendo con proveedores de par- equipos de proyectos no solo para la gerencia de sus líneas
tes de automóviles con sede en países de todo el mundo. La actuales de productos, sino también para la búsqueda de
compañía fue empujada a una posición poco familiar: Tenía recuperación de la inversión a largo plazo a través de la
que llegar enfocarse en el cliente y rápidamente comercializar investigación aplicada.
con productos innovadores. Frente a estos enormes desafíos MegaTech ha encontrado la forma de moverse hacia
comerciales, la alta dirección de MegaTech decidió transfor- la desafiante gerencia de proyectos. Por un lado, los emplea-
mar la empresa a una organización basada en proyectos. dos siguen replanteando la forma en que distribuyen su
La transición, a pesar de los problemas, ha pagado tiempo y recursos. Además, la tasa de éxito de nuevos pro-
grandes dividendos. Los altos ejecutivos determina- yectos en la empresa sigue siendo menor a lo que la admi-
ron, por ejemplo, que las actualizaciones de productos nistración había esperado. No obstante, los altos directivos
tenían que ser mucho más frecuentes. Alcanzar esta sienten que, en general, el cambio a la gerencia de proyectos
Estudio de caso 1.2 29

le ha dado a la compañía la ventaja operativa que necesitaba Preguntas


para mantener la delantera sobre sus rivales en esta indus-
1. ¿Qué hay en la gerencia de proyectos para ofrecerle a
tria tan competitiva a nivel mundial. “La gerencia de pro- MegaTech una ventaja competitiva en su industria?
yectos ciertamente no es una píldora mágica para el éxito, 2. ¿Qué elementos del mercado en el que opera MegaTech
pero ha puesto en marcha nuestro pensamiento de cómo llevaron a la empresa a creer que la gerencia de proyec-
operamos; como resultado, estamos haciendo las cosas más tos mejoraría sus operaciones?
inteligentemente y de un modo más rápido por todo lado”,
admite uno de los ejecutivos de MegaTech.

Estudio de caso 1.2


El Departamento de IT de Hamelin Hospital
Hamelin Hospital es un hospital regional grande (700 IT termina una tarea y luego es trasladado a una nueva.
camas), en el noreste de Estados Unidos. La IT emplea Un empleado típico del departamento de IT participa
a 75 personas y cuenta con un presupuesto de más de en siete proyectos, cada uno en una etapa diferente de
35 millones de dólares. El departamento es responsa- realización.
ble de la gerencia de 30 a 40 proyectos, que van desde El sistema de gerencia de proyectos implantado en
pequeños (rediseño de la pantalla del computador) Hamelin es bien valorado. Ha sido la punta de lanza en
hasta muy grandes como proyectos de desarrollo de la tremenda expansión de las capacidades de IT del hos-
sistemas multimillonarios, que se pueden ejecutar en
pital y de esta forma lo ayuda a obtener una ventaja com-
más de un año. El Departamento de IT de Hamelin
petitiva respecto a otros hospitales regionales. De hecho,
ha venido creciendo constantemente, lo que refleja el
compromiso del hospital para ampliar su capacidad recientemente, Hamelin comenzó “comercializar hacia
de procesamiento y almacenamiento de información. afuera” sus servicios de IT sobre una base de pago por
Las dos funciones principales del departamento de servicio para los hospitales de la competencia que nece-
IT comprenden el desarrollo de nuevas aplicaciones sitan ayuda con sus registros, administración, sistemas
de software y el mantenimiento del sistema actual de de ingreso de órdenes, entre otros. Como era de esperar,
información. La gerencia de proyectos se convierte en los resultados han contribuido a mejorar los resultados
un estilo vida para el departamento. finales del hospital, en un momento en que más y más
Los puestos de trabajo del departamento de IT se organizaciones de la salud están sintiendo los efectos de
dividen en cinco categorías: (1) técnico de soporte, (2) la espiral de costos. El departamento de IT de Hamelin
programador, (3) programador sénior (4) analista de sis- ha ayudado al hospital a aumentar sostenidamente su
temas y (5) gerente de proyecto. Los técnicos de soporte presupuesto, personal adicional, un catálogo de proyec-
atienden consultas de los usuarios de los sistemas infor- tos más amplio y una trayectoria de éxito.
máticos y resuelven una amplia gama de problemas en
campo. La mayoría de los empleados recién contratados
comienzan en soporte, donde pueden familiarizarse con Preguntas
el sistema, aprenden sobre las áreas problemáticas, se
1. ¿Cuáles son las ventajas y las desventajas de que la
vuelven sensibles a las frustraciones y preocupaciones
mayoría de los empleados recién contratados inicien
de los usuarios y entienden cómo el departamento de
IT afecta a todas las operaciones del hospital. A medida en la función de técnicos de soporte?
que los individuos ascienden, se unen a los equipos de 2. ¿Cuáles son los problemas potenciales con que se
proyectos ya sea como programadores o como analis- enfrentan los miembros del equipo del proyecto al
tas de sistemas. Por último, cinco gerentes de proyec- participar en varios proyectos a la vez? ¿Cuáles son
tos supervisan el catálogo de proyectos constantemente las ventajas potenciales?
actualizado. Además, la carga de trabajo siempre se está 3. ¿Qué señales indican que ser “gerente de proyecto” es
complementando con nuevos proyectos. El personal de la posición más alta en el departamento?
30 Capítulo 1  • Introducción

Estudio de caso 1.3


Expedición al Everest de Disney
El último paseo de la emoción por abrir en el Walt Disney La construcción de una atracción no es fácil ni rápida
World Resort puede ser el más impresionante de todos. A para los creativos de Disney. Expedición al Everest duró
medida que Disney se acerca a su quincuagésimo aniversa- varios años en desarrollo con diferentes equipos de Disney,
rio, la compañía ha querido celebrar de una manera muy incluido el ejecutivo creativo de Walt Disney, Joe Rohde,
especial: servir de enlace entre el increíble pasado de Disney y quien realizó múltiples viajes a la cordillera del Himalaya
su futuro prometedor. en Nepal para estudiar las tierras, la arquitectura, los colo-
En 2006, Walt Disney Company presentó la res, la ecología y la cultura, con el fin de crear un ambiente
Expedición al Everest en Disney Animal Kingdom en más auténtico para esta nueva atracción. Los esfuerzos de
Lake Buena Vista, Florida. La Expedición al Everest es Disney reflejan el deseo de hacer mucho más que ofrecer
algo más que una montaña rusa, es la encarnación del una experiencia de viaje de clase mundial; demostraron
espíritu Disney: un viaje que combina la emoción caracte- el entusiasmo de los ingenieros de la imaginación por
rística de las marcas registradas de Disney, giros y vueltas relatar cuento por cuento, que combinaran la mitología
inesperados, increíble atención a los detalles e impresio- de la figura del Yeti con la historia única de los nepaleses
nantes habilidades de gerencia de proyectos. nepaleses, que viven a la sombra de la montaña más alta
En primer lugar, vamos a considerar algunos de los del mundo. Finalmente, la atracción con todos sus antece-
detalles técnicos de la Expedición al Everest: dentes y elementos temáticos tomó cerca de cinco años en
realizarse completamente.
• Con un pico de casi 200 pies, el paseo se encuentra
Quienes viajan en la Expedición al Everest obtienen
dentro de la más alta de 18 montañas creadas por
una sensación real de la atmósfera que Disney creó tra-
los ingenieros creativos de Disney en los parques de
bajando tan duro. La aventura de los invitados se inicia
Disney en todo el mundo.
ingresando en el edificio de la agencia de viajes “Escape
• El trayecto contiene más de un kilómetro de la pista,
del Himalaya”, a la oficina de reservas de Norbu y Bob para
con giros, curvas cerradas y caídas repentinas.
obtener los permisos de viaje. En lo alto aletean auténti-
• El equipo de Disney creó un Yeti: un enorme mons-
cas banderas de los monasterios de Nepal. Enseguida, los
truo audioanimatrónico alimentado por una serie
visitantes pasan a la tienda Tashi General Store and Bar
de cilindros hidráulicos cuyo empuje combinado es
para abastecerse de los suministros para su viaje a la cima
igual a la de un avión Boeing 747. A través de una
de la montaña. Por último, pasan a un antiguo almacén
serie de bocetos, dibujos animados por computa-
de té que contiene un extraordinario museo de artefactos
dor, esculturas y pruebas que llevaron más de dos
que reflejan la cultura de Nepal, la historia del Himalaya
años para perfeccionarlo, Disney creó y programó
y cuentos del Yeti que se dice habita en las laderas del
su abominable hombre de las nieves que parado
monte Everest. Solo hasta este momento se les permite a
mide más de 10 pies de altura y sirve como el punto
los visitantes abordar el servicio del tren Anandapur para
focal del paseo.
su viaje a la cima. Cada tren sigue el modelo de una vieja
• Más de 900 plantas de bambú, 10 especies de árboles
máquina de vapor, con capacidad para 34 personas.
y 110 especies de arbustos se plantaron para recrear
Durante los siguientes minutos, los huéspedes son
el ambiente de las tierras bajas del Himalaya que
transportados hasta la pista de la montaña rusa, a través
rodean al monte Everest.
de una serie de curvas sinuosas, hasta su encuentro con el
• Se usaron más de 1,800 toneladas de acero para la
Yeti. En este punto, se presenta otra característica única
construcción de la montaña. La cubierta de la estruc-
de la atracción: el tren comienza a correr por la pista hacia
tura se realizó utilizando más de 3,000 prefabricados
atrás, como si estuviera fuera de control. Tras el balan-
“chips” creados a partir de 25,000 piezas de acero
ceo en la pista, los huéspedes disfrutan de un paisaje con
moldeadas individualmente por computador.
imágenes y sonidos que culmina en una carrera final de
• Para crear los esquemas de colores originales,
50 mph por la montaña hasta volver a la seguridad de la
2,000 galones de tintura y pintura fueron utiliza-
aldea nepalí.
dos en roca tallada y en todo el pueblo Disney dise-
El método de Disney para la gerencia de proyectos
ñado para servir como un telón de fondo para el
como la Expedición al Everest es una combinación de una
trayecto.
planeación cuidadosa, incluidas la programación y elabo-
• Más de 2,000 artículos de artesanía de Asia se uti-
ración del presupuesto, con las bien conocidas imagina-
lizan como accesorios, gabinetes y ornamentación
ción y visión de empresa. La creatividad es el elemento
arquitectónica.
Ejercicios en internet 31

crítico en el desarrollo de nuevos proyectos en Disney. Preguntas


Dentro de los imaginadores de la compañía se incluyen
1. Suponga que usted es gerente de proyectos para
algunos de los artistas más hábiles y expertos de anima-
Disney. Basándose en la información de este caso,
ción por computador del mundo. Aunque es fácil sentirse
¿qué parámetros críticos de éxito cree usted que la
impresionado por los conocimientos técnicos del perso-
empresa utiliza cuando diseña un nuevo paseo? Es
nal de Disney, es importante recordar que cada nuevo
decir, ¿cómo podría priorizar las necesidades para
proyecto se aborda con una comprensión de los negocios
hacer frente a los costos del proyecto, cronograma,
subyacentes de la empresa y atendiendo las proyecciones
calidad y aceptación del cliente? ¿Qué evidencia
de mercado, el control de costos y gran disciplina en la
apoya su respuesta?
gerencia de proyectos. Las nuevas propuestas de atrac-
2. ¿Por qué la atención al detalle de Disney en sus paseos
ciones son cuidadosamente investigadas y seleccionadas.
es única? ¿Cómo hace la compañía para utilizar la
El resultado es la creación de algunos de los juegos más
atmósfera discutida en el caso para maximizar la expe-
innovadores y divertidos del mundo. Disney no agrega
riencia mientras minimiza las quejas por largas esperas
nuevos atractivos a sus parques temáticos con frecuencia,
para tomar el viaje?
pero cuando lo hace, ¡lo hace con estilo!

Ejercicios en internet
1. La mayor organización profesional de gerencia de proyec- Preguntas de ejemplo del examen para la certificación
tos en el mundo es el Project Management Institute (PMI). PMP®
Ingrese en su sitio web, www.pmi.org, y examine los víncu-
los que encuentre. ¿Qué vínculos sugieren que la gerencia de 1. La mayor parte del presupuesto del proyecto se gasta en:
proyectos se ha convertido en un elemento complejo y vital a. Desarrollo del plan de proyecto.
para el éxito de las empresas? Seleccione al menos tres de los b. Ejecución del plan del proyecto.
enlaces relacionados e informe brevemente sobre el contenido c. Terminación del proyecto.
de estos enlaces. d. Comunicación del proyecto.
2. Ingrese en el sitio web del PMI y examine el vínculo “Membresía 2. ¿Cuál de los siguientes es el componente más crítico de la
global y comunidades”. ¿Qué descubre cuando comienza la na- triple restricción?
vegación entre los diferentes capítulos y las organizaciones coo- a. Tiempo, a continuación, costo, después calidad.
perativas asociadas al PMI? ¿De qué manera esta información b. Calidad, a continuación, presupuesto, después el tiempo.
lo lleva a repensar la gerencia de proyectos como una opción de c. Ámbito de aplicación.
carrera? d. Todos ellos son de igual importancia a menos que se
3. Ingrese en www.pmi.org/Business-Solutions/OPM3-Case- indique lo contrario.
Study- Library.aspx y examine algunos de los casos incluidos
en la página web. ¿Qué sugieren acerca de los retos de la ge- 3. ¿Cuál de las siguientes opciones describe mejor a los inte-
rencia exitosa de proyectos? ¿Sobre la complejidad de mu- resados del proyecto?
chos de los proyectos de hoy en día? ¿Sobre los interesantes a. Un miembro del equipo.
avances y las oportunidades que los proyectos nos permiten b. El director del proyecto.
explotar? c. Una persona que trabaja en un área afectada por el
4. Utilizando su motor de búsqueda favorito (Google, Yahoo, etc), proyecto.
digite las palabras clave “proyecto” y “ gerencia de proyectos”. d. Todos los anteriores son los interesados del proyecto.
Aleatoriamente, seleccione tres de los enlaces que se presentan 4. Todos los siguientes son los elementos de la definición de
en la pantalla. Resuma lo que encuentre. un proyecto, con excepción de:
5. Visite el sitio web del Software Engineering Institute de a. Un proyecto es limitado en el tiempo.
Carnegie Mellon en www.sei.cmu.edu/pub/documents/94.re- b. Un proyecto es único.
ports/pdf/sr07.94.pdf y acceda al cuestionario de los procesos c. El proyecto está compuesto por actividades no
de madurez de software. ¿Cuáles son algunas de las preguntas relacionadas.
que las empresas de IT deben tener en cuenta al evaluar su nivel d. Un proyecto se lleva a cabo con un propósito.
de madurez de gerencia de proyectos?
6. Ingrese en el sitio web Prentice Hall Companion que apoya este 5. Todos los siguientes distinguen la gerencia de proyectos de
libro, www.prenhall.com/pinto. Lectura en internet: Morris, P. otras actividades de proceso, excepto:
W. G. (1998). “Why project management doesn’t always make a. No existen diferencias fundamentales entre la geren-
business sense,” Project Management, 4 (1): 12-16. cia de proyectos y procesos.
7. Ingrese en el sitio web de Prentice Hall que apoya este libro, www. b. La gerencia de proyectos a menudo implica una
prenhall.com/pinto. Lectura en internet: Cook, CR, y Pritchard, mayor seguridad de desempeño, costo y cronograma.
CL (1998). “Why project management?” in D. I. Cleland (Ed.), c. La gerencia de procesos opera fuera de las orga-
The Project Management Field Guide.”, 4 (1): 12-16., pp. 22-33. nizaciones de la línea.
32 Capítulo 1  • Introducción

d. Ninguna de las anteriores distingue correctamente modelo de triple restricción son igualmente críticos; 3 d—
proyecto de gerencia de procesos. Todos los ejemplos mencionados son tipos de interesados del
proyecto; 4 c—Un proyecto se compone de actividades “relacio-
Respuestas: 1 b—La mayor parte de un presupuesto se gasta nadas entre sí”; 5 d—Ninguna de las respuestas dadas distingue
durante la fase de ejecución del plan de un proyecto; 2 d—A correctamente “proceso” de la gerencia del “proyecto”.
menos que se indique lo contrario, todos los elementos en el

Notas

1. Valery, Paul, citado en “Extreme chaos” (2001). Standish 16. Kapur, G. K. (1998). “Don’t look back to create the fu-
Group International. ture.” Presentation at the Frontiers of Project Management
2. www.cnn.com/2010/WORLD/americas/10/15/chile.mine. Conference, Boston, MA.
rescue.recap/index.html;ww.cnn.com/2010/OPINION/10/12/ 17. www.computerweekly.com/blogs/public-sector/2007/05/
gergen.miners/index.html; www.thenewamerican.com/index. public-sector-it-projects-have.html.
php/opinion/sam-blumenfeld/5140-how-americansengi- 18. “How to establish an organizational culture that pro-
neered-the-rescue-of-the-chilean-miners. motes projects,” www.bia.ca/articles/HowToEstablish a
3. Peters, Thomas. (1994). Liberation Management: Necessary ProjectManagementCulture.htm; Standish Group. (2006).
Disorganization for the Nanosecond Nineties. New York: The Trends in IT Value report; Standish Group. (2009).
Fawcett Books. Chaos Summary 2009. Boston, MA.
19. Kelley, M. (2008). “$600M spent on canceled contracts,”
4. Stewart, Thomas H. (1995). “The corporate jungle spawns a
USA Today, 18 de noviembre, p. 1.
new species,” Fortune, 10 de julio, pp. 179–80.
20. Cleland, D. I. (1994). Project Management: Strategic Design
5. Gilbreath, Robert D. (1988). “Working with pulses not
and Implementation. New York: McGraw-Hill; Pinto, J. K.,
streams: Using projects to capture opportunity,” in Cleland,
and Rouhiainen, P. (2001). Building Customer-Based Project
D., and King, W. (Eds.), Project Management Handbook. Organizations. New York: Wiley; Gray, C. F., and Larson,
New York: Van Nostrand Reinhold, pp. 3–15. E. W. (2003). Project Management, 2nd ed. Burr Ridge, IL:
6. Buchanan, D. A., and Boddy, D. (1992). The Expertise of the McGraw-Hill.
Change Agent: Public Performance and Backstage Activity. 21. Petroski, H. (1985). To Engineer Is Human—The Role of
London: Prentice Hall. Failure in Successful Design. London: St. Martin’s Press.
7. Frame, J. D. (1995). Managing Projects in Organizations, 22. http://aftermathnews.wordpress.com/2008/08/28/chine-
2nd ed. San Francisco, CA: Jossey-Bass. See also Frame, J. D. seskyscraper- builders-to-put-up-equivalent-of-10-new-
(2002). The New Project Management, 2nd ed. San Francisco, yorkssays- rio-tinto/; www.railway-technology.com/
CA: Jossey-Bass. projects/beijing/; www.nytimes.com/2009/05/11/world/
8. Kerzner, H. (2003). Project Management, 8th ed. New York: asia/11coal.html.
Wiley. 23. Sohmen, Victor. (2002, julio). “Project termination: Whythe
9. Field, M., and Keller, L. (1998). Project Management. delay?” Paper presentado en la PMI Research Conference,
London: The Open University. Seattle, WA.
10. Project Management Institute. (2000). A Guide to the Project 24. Freeman, M., and Beale, P. (1992). “Measuring project suc-
Management Body of Knowledge. Newtown Square, PA: cess,” Project Management Journal, 23(1): 8–17.
PMI. 25. Morris, P. W. G. (1997). The Management of Projects.
11. Cleland, D. I. (2001). “The discipline of project manage- Thomas Telford: London; “Women design concept car for
ment,” in Knutson, J. (Ed.), Project Management for Business Volvo,” www.usatoday.com/money/autos/2004-03-02; “This
Volvo is not a guy thing.” (2004, 15 de marzo). www.busi-
Professionals. New York: Wiley, pp. 3–22.
nessweek.com/magazine/04_11; http://en.wikipedia.org/
12. Lundin, R. A., and Soderholm, A. (1995). “A theory of
wiki/Volvo_YCC.
the temporary organization,” Scandinavian Journal of
26. Shenhar, A. J., Levy, O., and Dvir, D. (1997). “Mapping the
Management, 11(4): 437–55.
dimensions of project success,” Project Management Journal,
13. Graham, R. J. (1992). “A survival guide for the acciden- 28(2): 5–13.
tal project manager.” Proceedings of the Annual Project 27. DeLone, W. H., and McLean, E. R. (1992). “Information
Management Institute Symposium. Drexel Hill, PA: Project systems success: The quest for the dependent variable,”
Management Institute, pp. 355–61. Information Systems Research, 3(1): 60–95; Seddon, P. B.
14. Sources: http://macs.about.com/b/a/087641.htm; Mossberg, (1997). “A respecification and extension of the DeLone and
W. S. (2004). “The music man,” Wall Street Journal, 14 de McLean model of IS success,” Information Systems Research,
junio, p. B1. 8(3): 249–53; DeLone, W. H., and McLean, E. R. (2003). “The
15. Pinto, J. K., and Millet, I. (1999). Successful Information DeLone and McLean model of information system success:
Systems Implementation: The Human Side, 2nd ed. Newtown A ten-year update,” Journal of Management Information
Square, PA: PMI. Systems, 19(4): 9–30.
Notas 33

28. Atkinson, R. (1999). “Project management: Cost, time and in Slevin, D., Cleland, D., and Pinto, J. (Eds.), The Frontiers of
quality, two best guesses and a phenomenon, it’s time to ac- Project Management Research. Newtown Square, PA: Project
cept other success criteria,” International Journal of Project Management Institute, pp. 213–24; Gareis, R., and Huemann,
Management, 17(6): 337–42; Cooke-Davies, T. (2002). “The M. (2000). “Project management competencies in the proj-
‘real’ success factors on projects,” International Journal of ect- oriented organization,” in Turner, J. R., and Simister, S. J.
Project Management, 20(3): 185–90; Olson, D. L. (2001). (Eds.), The Gower Handbook of Project Management, 3rd ed.
Introduction to Information Systems Project Management. Aldershot, UK: Gower, pp. 709–22; Ibbs, C. W., and Kwak, Y.
Burr Ridge, IL: Irwin/McGraw-Hill. H. (2000). “Assessing project management maturity,” Project
29. Pennypacker, J. S., and Grant, K. P. (2003). “Project man- Management Journal, 31(1): 32–43.
agement maturity: An industry benchmark,” Project 32. Humphrey, W. S. (1988). “Characterizing the software pro-
Management Journal, 34(1): 4–11; Ibbs, C. W., and Kwak, cess: A maturity framework,” IEEE Software, 5(3): 73–79;
Y. H. (1998). “Benchmarking project management organiza- Carnegie Mellon University. (1995). The Capability Maturity
tions,” PMNetwork, 12(2): 49–53. Model: Guidelines for Improving the Software Process. Boston,
30. Reginato, P. E., and Ibbs, C. W. (2002). “Project manage- MA: Addison-Wesley; Kerzner, H. (2001). Strategic Planning
ment as a core competency,” Proceedings of PMI Research for Project Management Using a Project Management Maturity
Conference 2002, Slevin, D., Pinto, J., and Cleland, D. (Eds.), Model. New York: Wiley; Crawford, J. K. (2002). Project
The Frontiers of Project Management Research. Newtown Management Maturity Model. New York: Marcel Dekker;
Square, PA: Project Management Institute, pp. 445–50. Pritchard, C. (1999). How to Build a Work Breakdown
31. Crawford, K. (2002). Project Management Maturity Model: Structure: The Cornerstone of Project Management.
Providing a Proven Path to Project Management Excellence. Arlington, VA: ESI International.
New York: Marcel Dekker; Foti, R. (2002). “Implementing 33. Jenkins, Robert N. (2005). “A new peak for Disney,” St.
maturity models,” PMNetwork, 16(9): 39–43; Gareis, R. Petersburg Times Online, www.sptimes.com/2005/12/11/
(2001). “Competencies in the project-oriented organization,” news_pf/travel/A_new_peak_for_Disney.
CAPÍTULO

2
El contexto organizacional.
Estrategia, estructura y cultura

Contenido del capítulo


PERFIL DE PROYECTO 2.5 OFICINAS DE GERENCIA DE PROYECTOS
El Ejército de Estados unidos regresa a la era de los 2.6 CULTURA ORGANIZACIONAL
dirigibles no rígidos ¿Cómo se forman las culturas?
INTRODUCCIÓN Cultura organizacional y gerencia de proyectos
2.1 PROYECTOS Y ESTRATEGIA ORGANIZACIONAL PERFIL DE PROYECTO
2.2 GERENCIA DE LOS INTERESADOS Una cultura de servicio: Sanofi-Aventis y su compromiso
(STAKEHOLDERS) con la asistencia médica mundial
Identificación de los interesados del proyecto Resumen
Gestión de los interesados Términos clave
2.3 ESTRUCTURA ORGANIZACIONAL Preguntas para discusión
2.4 FORMAS DE ESTRUCTURA ORGANIZACIONAL Estudio de caso 2.1 Rolls-Royce Corporation
Organizaciones funcionales Estudio de caso 2.2 Caso clásico: el paraíso perdido—El
Organizaciones basadas en proyectos Xerox Alto
Organizaciones matriciales Estudio de caso 2.3 Estimación de tareas del proyecto y de la
Moverse hacia una organización basada en proyectos cultura “¡Te atrapé!”
pesos pesados Estudio de caso 2.4 Widgets’R Us
INVESTIGACIÓN EN GERENCIA DE PROYECTOS Ejercicios en internet
EN SÍNTESIS Preguntas de ejemplo del examen para la certificación PMP®
El efecto de la estructura organizacional en los resultados Proyecto integrado: construya su plan de proyecto
de los proyectos Notas

Objetivos de aprendizaje
Al finalizar el capítulo, el estudiante estará en capacidad de:
1. Entender cómo la gerencia eficaz de proyectos contribuye al logro de los objetivos estratégicos.
2. Reconocer los tres componentes del modelo de estrategia empresarial: formulación, implementación y
evaluación.
3. Valorar la importancia de identificar el grupo de los interesados del proyecto (stakeholders) y su gestión
en el desarrollo del proyecto.
4. Reconocer las fortalezas y debilidades de las tres formas básicas de la estructura organizacional y sus
implicaciones en la gerencia de proyectos.
34
Perfil de proyecto 35

5. Entender cómo las empresas pueden cambiar su estructura a una “organización de proyectos pesos
pesados”, estructura que facilita las prácticas eficaces de gerencia de proyectos.
6. Identificar las características de las tres formas de la oficina de gerencia de proyectos (PMO).
7. Comprender los conceptos claves de la cultura organizacional y cómo se forman las culturas.
8. Reconocer, en las prácticas de gerencia de proyectos, los efectos positivos de una cultura organizacional
de apoyo frente a los de una cultura que va en contra de la gerencia de proyectos.

CONCEPTOS BÁSICOS DE LOS FUNDAMENTOS PARA LA GERENCIA DE PROYECTOS


(PROJECT MANAGEMENT BODY OF KNOWLEDGE, PMBOK® GUIDE 5A. EDICIÓN)
CUBIERTOS EN ESTE CAPÍTLO
1. Proyectos y planeación estratégica (PMBOK® Guide, 5a. edición, sección 1.4.3)
2. Interesados del proyecto (PMBOK® Guide, 5a. edición, sección 13)
3. Estructura organizacional (PMBOK® Guide, 5a. edición, sección 2.1.3)
4. Oficina de dirección de proyectos (PMBOK® Guide, 5a. edición, sección 1.4.4)
5. Culturas y estilos de organización (PMBOK® Guide, 5a. edición, sección. 2.1.1)

PERFIL DE PROYECTO

Caso - El Ejército de Estados Unidos regresa a la era de los dirigibles no rígidos


En tiempos modernos, cuando pensamos en dirigibles, solemos asociar la imagen a los eventos deportivos, en donde estos
vehículos más ligeros que el aire circulan por estadios o campos de golf para proporcionar ocasionalmente fotografías
aéreas y así aumentar el disfrute del juego. ¿Cuántos de nosotros podríamos ver un dirigible como el último eslabón hacia
la mejora de nuestra capacidad militar? Tal como se llevan a cabo estos avances, la realidad es más extraña que la ficción.
Con un contrato de 517 millones de dólares otorgado por el Ejército de Estados Unidos a Northrop Grumman,
en junio del 2010, se inició la construcción de tres vehículos dirigibles multi-inteligentes de larga resistencia (Multi-
Intelligence Vehicle: LEMV), con la intención de desplegarlos sobre Afganistán en el 2012. Estos LEMV representan el
único replanteamiento de la tecnología de los dirigibles, la cual se remonta a más de 100 años. Con el incremento del
terrorismo mundial, los crecientes costos de contratación, capacitación y retención de soldados profesionales y las cues-
tiones de seguridad en general, han surgido dos exigencias fundamentales para los ejércitos modernos. La primera, la
vigilancia: los militares necesitan ser competentes para observar amplias zonas durante periodos muy largos (cuanto más
prolongados mejor). El análisis de las zonas de amenaza por varios días impide otorgar oportunidades a los enemigos
para reunir y movilizar tropas sin ser detectados. La segunda, en el apoyo a esta capacidad de observación persistente, es
muy importante no sobrepasar el presupuesto, por tanto, la búsqueda de medios de bajo costo para observar e informar
es de suma importancia. Lo que se necesita para resolver estos problemas fundamentales es la creación de una nueva
generación de aerotransportados: una plataforma con bajo costo de operación y muy larga resistencia, tal como el LEMV.
Estrictamente hablando, el LEMV no es realmente un dirigible, porque es más pesado que el aire: solo 80%
de la elevación del LEMV proviene de la flotabilidad; el otro 20% proviene de seis propulsores alimentados indi-
vidualmente por turbodiésel para el despegue y ascenso. En su configuración actual, el LEMV está diseñado para
ser piloteado a distancia, aunque conserva la opción de tripulación aérea real. En una sección de 40 x 15 pies,
detrás de la cabina tripulada ocasionalmente, se dispone de una gran variedad de sistemas inteligentes de inspec-
ción, como el radar y sensores de movimiento de área amplia. La información será entonces enviada de vuelta, en
tiempo real a los comandantes en tierra. Los LEMV son enormes: más grandes que un campo de fútbol, más altos
que un edificio de siete pisos, y pueden flotar a 20,000 pies durante 21 días cada vez. En condiciones adecuadas, sus
propulsores les permitirán viajar a velocidades de hasta 80 nudos.
Además, los LEMV son una opción muy económica para la vigilancia aérea prolongada. El Director de
Programas de Northrop Airship, Alan Metzger, comenta al respecto:

Cuando se hacen las cuentas de las que usted está hablando, 20,000 dólares para mantener el vehículo en el
aire durante tres semanas. Es mucho más barato de operar que muchos aviones convencional de hoy día…
Algunas de las características de nuestro vehículo le permiten balancear el tiempo que se desea permanecer
(Continúa)
36 Capítulo 2  •  El contexto organizacional. Estrategia, estructura y cultura

en el aire y la cantidad de carga por transportar. Tenemos la capacidad de negociar 23 días para recorrer 1,000
millas y transportar 15, 20, 30,000 libras. . . . Estamos protegiendo el medio ambiente, usamos una cuarta
parte del combustible para la misma capacidad de carga de los aviones de carga. . . al tener menos partes
móviles, hay menos mantenimiento.

Entonces, ¿en dónde encajan los LEMV dentro de la misión del Ejército? La respuesta es que están destinados
a hacer lo que mejor saben hacer. Pueden ser desplegados para operar desde pequeñas bases de avanzada, como
los helicópteros. Al pasar sobre las zonas de alta amenaza, pueden escanearlas con una óptica avanzada e infra-
rrojos para detectar los movimientos de tropas en el terreno. También pueden servir como relés de comunicación
constante, asegurando que los grupos de soldados en zonas montañosas no pierdan el contacto con los demás,
incluso sin tener línea de visión directa. Pueden seguir convoyes importantes, carreteras principales u otras infraes-
tructuras claves, o como escolta semipermanente con un “ojo en el cielo”, y vigilar un área urbana de interés para
la preparación de grandes batallas o para reforzar la seguridad, o para centrarse en puntos de control fronterizos.
El programa de Northrop Grumman no es el único que el Ejército está financiando actualmente. Una
donación de 400 millones de dólares a Lockheed Martin en 2009 se está utilizando para desarrollar una idea
aún más ambiciosa: una nueva aeronave prototipo diseñada para permanecer en la estratosfera durante años
a la vez. La aeronave usaría un radar de 6,000 metros cuadrados para monitorear todo, desde misiles de cru-
cero a los vehículos pequeños escondidos en la maleza a 300 kilómetros de distancia. La superficie y la altura
de un dirigible estratosférico permiten una apertura muy grande de radar. A medida que la apertura del radar
se hace más grande, el rendimiento del sistema de seguimiento aumenta sustancialmente.
El programa LEMV es un punto de partida para muchos otros programas de adquisiciones del Departamento
de Defensa, centrados en maximizar las capacidades para misiones específicas. En otras palabras, el Ejército no está
buscando comprar la tecnología aeronáutica “más nueva y atractiva” sino, en cambio, centrarse en abordar dos
objetivos aparentemente contradictorios: la búsqueda de un medio que permita la mejor capacidad de vigilancia
a un precio accesible. El LEMV, que aparentemente es incongruente con los dirigibles de las décadas anteriores, es
un excelente ejemplo para alcanzar estos dos objetivos.1

INTRODUCCIÓN
Dentro de cualquier organización, la gerencia exitosa de proyectos es contextual. Esto significa que la organización
sí importa: su cultura, estructura y su estrategia son una parte integral y juntos crean el ambiente en el que un pro-
yecto florecerá o se instaurará. Por ejemplo, la conexión de un proyecto a la estrategia global de la organización,
el bienestar del equipo del proyecto y los objetivos establecidos pueden ser cruciales para el proyecto. Del mismo
modo, las políticas de la organización, su estructura, su cultura y sus sistemas de operación pueden ser un apoyo
y promover la gerencia de proyectos o, por el contrario, ir en contra de la posibilidad de ejecutarlos eficazmente.
Los elementos del contexto proporcionan el telón de fondo alrededor del cual deben operar las actividades del pro-
yecto; por tanto, entender lo que subyace en estas cuestiones, realmente contribuye a la comprensión de la forma
de gestionar proyectos. Los factores que afectan a un proyecto varían mucho de una compañía a otra.
Antes de comenzar un proyecto, el gerente del proyecto y su equipo deben estar seguros de la pertinencia
de la estructura organizacional en lo referente a su proyecto y a las tareas que pretenden realizar. Con la mayor
claridad posible, se deben especificar todas las relaciones de subordinación, establecer las reglas y los procedi-
mientos que gobernarán el proyecto e identificar cualquier otro factor relacionado con el equipo del proyecto.
Antes del inicio de la Operación Tormenta del Desierto en 1991, Estados Unidos y sus países aliados dedicaron
una enorme cantidad de tiempo y esfuerzo para desarrollar una relación de trabajo entre todos los miembros de
la coalición, para asegurar que cada grupo tuviera claras sus tareas, entendiera su trabajo y conociera cuál era
el proceder esperado de la estructura general y de la coalición. Tormenta del Desierto ilustró la importancia de
establecer claramente una estructura organizacional, antes del inicio de las operaciones conjuntas.
Para muchas organizaciones, la norma de funcionamiento no son los proyectos ni las prácticas de gerencia
de proyectos. De hecho, como se discutió en el capítulo 1, los proyectos existen fuera de las actividades forma-
les orientadas a procesos en muchas organizaciones. Como resultado, muchas empresas simplemente no están
estructuradas para permitir la realización exitosa de proyectos en conjunto con las actividades empresariales en
curso. El punto clave está en descubrir cómo se puede implementar la gerencia de proyectos de la mejor manera,
independientemente de la estructura que la compañía ha adoptado. ¿Cuáles son las fortalezas y debilidades de las
2.1  Proyectos y estrategia organizacional 37

diversas formas estructurales y cuáles son sus implicaciones para nuestra capacidad de gestionar proyectos? En
este capítulo se analizará el concepto de cultura organizacional, sus raíces e implicaciones en la gerencia eficaz
de los proyectos. Al tratar de cerca los tres temas contextuales más importantes para la gerencia de proyectos —
estrategia, estructura y cultura organizacional — usted verá cómo puede afectar la variedad de opciones estructu-
rales, ya sea positiva o negativamente, la capacidad de la empresa para gestionar proyectos.

2.1  PROYECTOS Y ESTRATEGIA ORGANIZACIONAL


La gestión estratégica es la ciencia de la formulación, implementación y evaluación de las decisiones funcio-
nales transversales que le permiten a una organización lograr sus objetivos.2 En esta sección vamos a consi-
derar los componentes relevantes de esta definición y cómo se aplican a la gerencia de proyectos. La gestión
estratégica consta de los siguientes elementos:

1. Definición de la visión y de la misión.  Las declaraciones de la visión y de la misión establecen un sen-


tido de lo que la organización realiza o de lo que los altos directivos esperan que se convierta en algún
momento futuro. La visión de la empresa sirve como un punto focal para los miembros de la organi-
zación que pueden aplicar en múltiples direcciones, debido a las demandas competitivas. En razón de
las múltiples expectativas e, incluso, muchos esfuerzos contradictorios, una visión fundamental puede
servir como una “opción”, lo cual es altamente beneficioso en el establecimiento de prioridades. El
significado de la visión es también una fuente muy importante de motivación e intención. Como señala
el libro de Proverbios, “donde no hay visión, el pueblo perece” (Prov. 29:18). Muchas empresas apli-
can, como primer filtro, su visión o misión a la evaluación de nuevas oportunidades de proyectos. Por
ejemplo, Fluor-Daniel Corporation, una gran empresa de construcción, incluye en su visión la meta de
ser “el líder supremo en la construcción global y en servicios de mercado mediante la entrega de solu-
ciones de clase mundial”. Aquellos proyectos que no soporten esta visión, no se realizan.
2. Formulación, implementación y evaluación.  Los proyectos, como ingredientes claves en la imple-
mentación de estrategias, desempeñan un papel crucial en el modelo básico de procesos de la gerencia
estratégica. Las empresas dedican mucho tiempo y recursos para evaluar sus oportunidades de negocio
mediante el desarrollo de una visión y de una misión, evaluando sus puntos fuertes y débiles, así como las
oportunidades y amenazas externas, estableciendo objetivos a largo plazo y generando y seleccionando
entre varias alternativas estratégicas. Todos estos componentes se refieren a la etapa de formulación de
la estrategia. En este contexto, los proyectos sirven como vehículos que les permiten a las empresas apro-
vechar las oportunidades, capitalizar sus puntos fuertes e implementar los objetivos corporativos genera-
les. El desarrollo de nuevos productos, por ejemplo, encaja perfectamente en este marco. Se desarrollan
nuevos productos y se introducen en el mercado como una respuesta de la empresa a oportunidades de
negocio. La gerencia eficaz de proyectos les permite a las empresas responder con eficacia y rapidez.
3. Toma de decisiones funcionales transversales.  La estrategia corporativa conlleva un riesgo en toda la
empresa, lo cual requiere compromiso y compartir recursos por todas las áreas funcionales, con el fin
de cumplir los objetivos generales. La toma de decisiones funcionales transversales es una característica
fundamental de la gerencia de proyectos, en donde expertos de diversos grupos funcionales se unen a
un equipo con diversas personalidades y experiencia. El trabajo de gerencia de proyectos es el entorno
natural en el que se operacionalizan los planes estratégicos.
4. Logro de objetivos.  Si la organización busca el liderazgo en el mercado, a través de productos innovadores
de bajo costo, calidad superior, u otros medios, los proyectos son las herramientas más eficaces para permi-
tir que los objetivos se alcancen. Una característica importante de la gerencia de proyectos es que puede per-
mitir potencialmente a las empresas ser efectivas en el mercado externo, así como eficaces en las operaciones
internas, es decir, se trata de un gran vehículo para la optimización de objetivos organizacionales, ya sea que
se inclinen hacia la eficiencia de la producción o hacia la efectividad del producto o del proceso.

Los proyectos se han llamado los “escalones” de la estrategia corporativa3 Esta idea implica que la
visión estratégica global de una organización es la fuerza impulsora detrás del desarrollo de sus proyectos.
Por ejemplo, el deseo de 3M por ser un líder innovador en el negocio da lugar a la creación y gerencia de
cientos de nuevos proyectos de desarrollo de productos dentro de esa organización multinacional, cada
año. Del mismo modo, Rubbermaid Corporation se destaca por la búsqueda constante de desarrollo de nue-
vos productos y su introducción en el mercado. La forma en que las estrategias organizacionales afectan la
introducción de nuevos proyectos se abordará con mayor detalle en el capítulo 3, que trata la selección de
38 Capítulo 2  •  El contexto organizacional. Estrategia, estructura y cultura

CUADRO 2.1  Los proyectos reflejan la estrategia

Estrategias Proyectos
Iniciativas técnicas u operativas (como nuevas estrategias de distribu- Construcción de nuevas plantas o
ción u operaciones en plantas descentralizadas) modernización de instalaciones
Redesarrollo de productos o mayor aceptación en el mercado Proyectos de reingeniería
Nuevos procesos de negocio para una mayor racionalización y eficiencia Proyectos de reingeniería
Cambios en la dirección estratégica o reconfiguración del portafolio Nuevas líneas de productos
de productos
Creación de nuevas alianzas estratégicas Negociación con los miembros de la
cadena de suministro (incluidos
proveedores y distribuidores)
Coincidencia o mejora de los productos y servicios de la competencia Proyectos de ingeniería inversa
Mejorar la comunicación de toda la organización y las relaciones con Esfuerzos de las empresas de IT
la cadena de suministro
Promocionar la interacción entre funciones, dinamizar la introducción de Proyectos de ingeniería concurrente
nuevos productos o servicios y mejorar la coordinación departamental

proyectos. Los proyectos son cimientos de las estrategias, que ponen una cara orientada a la acción en el edi-
ficio estratégico. Algunos ejemplos de cómo los proyectos operan como componentes básicos estratégicos, se
muestran en el cuadro 2.1. Cada uno de los ejemplos ilustra el tema de fondo: los proyectos son la “realidad
operativa” detrás de la visión estratégica. En otras palabras, sirven como componentes básicos para crear la
realidad en la cual solamente puede articularse una estrategia.
Otra manera de visualizar cómo los proyectos se conectan a la estrategia de organización se muestra en
la figura 2.1.4 Este modelo contempla una jerarquía en la que la misión es de suma importancia, los objetivos
definen la misión de manera más formal y la estrategia, las metas y los programas son la base de los objetivos.
La figura sugiere que los diversos elementos estratégicos deben coexistir en armonía unos con otros, es decir,
la misión, los objetivos, las estrategias, las metas y los programas deben permanecer alineados.5 Tendría poco
sentido, por ejemplo, crear una visión de “una organización consciente del medio ambiente”, si los objetivos
y estrategias se orientan a políticas ecológicamente poco amigables.

Misión

Objetivos

Estrategia Metas Programas

FIGURA 2.1  Relación entre los elementos estratégicos


Fuente: Adaptado de W. R. King. (1988). “ The Role of
Projects in the Implementation of Business Strategy “, en D.I.
Cleland y W.R. King (Eds.), Project Management Handbook,
2nd ed. New York: Van Nostrand Reinhold, pp. 129-39.
Reproducido con permiso de John Wiley & Sons, Inc.
2.1  Proyectos y estrategia organizacional 39

Misión
"... el negocio de suministro de
componentes para sistemas de
aire acondicionado no residencial
en un mercado mundial."

Objetivos

a. 14.5% de ROI
b. Dividendos no decrecientes
c. Imagen con conciencia social

Estrategias Metas Programas


a. Productos existentes en Año 1: 8% de ROI, 1. Mejora de costos del producto
mercados existentes con $1 de dividendos, mantener (Product Cost Improvement
mantenimiento de la imagen imagen, reducir costo por Program: PCIP)
unidad en 5% 2. Programa de evaluación de
b. Productos existentes en Año 2: 9% de ROI, $1 de imagen (Image Assessment
nuevos mercados (extranjeros, dividendos, mejorar la imagen Program: IAP)
restringidos) 3. Programa de rediseño de
Año 3: 12% de ROI, $1 de
c. Nuevos productos en los producto (Product Redesign
dividendos, mejorar la imagen Program: PRP)
mercados existentes (mejorar
significativamente la imagen) Año 4: 14% de ROI, $1.10 4. Programa de desarrollo de
de dividendos producto (Product Development
Program: PDP)

FIGURA 2.2  Ilustración de la alineación entre elementos estratégicos y proyectos


Fuente: Adaptado de W. R. King. (1988). “ The Role of Projects in the Implementation of Business Strategy,” in D. I. Cleland
and W. R. King (Eds.), Project Management Handbook, 2nd ed. New York: Van Nostrand Reinhold, pp. 129-39. Reproducido
con permiso de John Wiley & Sons, Inc.

La figura 2.2 proporciona ejemplos concretos para ilustrar la alineación estratégica entre proyectos de
una empresa y su visión, objetivos, estrategias y metas.6 Si, por ejemplo, un fabricante de equipos de refri-
geración crea una declaración de visión que dice, en parte, que la empresa se encuentra en “el negocio de
suministro de componentes para sistemas de aire acondicionado no residencial en el mercado mundial”, esta
visión se aclara con los objetivos estratégicos específicos: retorno sobre la inversión (ROI), mantenimiento de
dividendos y responsabilidad social. Soportando la base de la jerarquía están las estrategias, metas y progra-
mas. Aquí las estrategias de la empresa se expresan en un enfoque de tres fases: (1) concentrarse en el logro
de objetivos a través de los mercados existentes y líneas de productos, (2) enfocarse en nuevas oportunidades
de mercado en mercados extranjeros o restringidos y (3) buscar nuevos productos en los mercados existen-
tes. La organización intenta, en primera instancia, mantener las líneas de productos existentes y luego buscar
el desarrollo de nuevos productos y la innovación.
Las metas, que se muestran en el centro de la base de la jerarquía en la figura 2.2, reflejan un plan de cuatro
años basado en las estrategias antes mencionadas. Supóngase que para el primer año las metas de una empresa
apuntan a un retorno de 8% de la inversión, mantener estables los dividendos, disminuir los costos unitarios de
producción y mantener una imagen sólida. Las metas para los años 2 a 4 son cada vez más ambiciosas, todas
ellas basadas en el apoyo a la estrategia de tres fases. Por último, los programas indicados en el lado derecho de la
jerarquía son las fuentes para los proyectos de la compañía. Cada programa suele ser una colección de proyectos
de apoyo, por lo que incluso las actividades más básicas de la empresa se llevan a cabo soportando los elementos
estratégicos de la empresa. Para demostrar cómo se dividen estos programas, el programa de evaluación de la
imagen (Image Assessment Program: IAP) consta de varios proyectos de apoyo, que incluyen:
1. Encuesta al cliente
2. Filantropía corporativa
40 Capítulo 2  •  El contexto organizacional. Estrategia, estructura y cultura

3. Evaluación de la calidad
4. Relaciones laborales
Todos estos proyectos promueven la evaluación de imagen, que a su vez es solo uno dentro una serie
de programas de apoyo, diseñado para alcanzar los objetivos estratégicos. En este modelo, probablemente,
varios proyectos en realidad soporten múltiples programas. Por ejemplo, el proyecto encuesta al cliente puede
proporcionar información valiosa para el programa rediseño del producto (Product Redesign Program: PRP),
así como también los datos de satisfacción del cliente retroalimentan al departamento de diseño. Los proyectos,
como cimientos de la estrategia, se inician normalmente a través de los propósitos estratégicos de la corpora-
ción, que se derivan de una secuencia clara y lógica de la visión, los objetivos, estrategias y metas.
La gestión estratégica de una organización es el primer elemento contextual importante en el enfoque de
gerencia de proyectos. Dado que los proyectos forman los bloques básicos que permiten implementar los planes
estratégicos, es vital que exista un claro sentido de armonía, o de complementariedad, entre la estrategia y los pro-
yectos seleccionados para su desarrollo. En una sección posterior, se analizará la importancia de crear el contexto
adecuado para los proyectos mediante la adición de una variable adicional a la mezcla: la estructura organizacional.

2.2  GERENCIA DE LOS INTERESADOS (STAKEHOLDERS)


La investigación de organizaciones y la experiencia directa indican que las empresas y los equipos de proyectos
no pueden operar haciendo caso omiso de los efectos externos de sus decisiones. Una manera de entender la
relación de los gerentes de proyectoss y sus proyectos con el resto de la organización es mediante la utilización
del análisis de los interesados. El análisis de los interesados es una herramienta útil para identificar algunos
de los conflictos aparentemente irresolubles que se producen con la creación y la introducción de cualquier
proyecto nuevo. Los interesados del proyecto se definen como todos los individuos o grupos que tienen una
participación activa en el proyecto y potencialmente pueden afectar positiva o negativamente su desarrollo.7 El
análisis de interesados del proyecto, entonces, consiste en la formulación de estrategias para identificar y, en su
caso, gestionar los resultados positivos del impacto de los interesados del proyecto.
Los interesados pueden afectar y afectarse en diversos grados por las acciones de la organización.8 En
algunos casos, la empresa debe tomar en serio la influencia potencial que algunos interesados son capaces de
ejercer. En otras situaciones, un grupo de interesados puede tener relativamente poco poder para influir en
las actividades de una empresa, pero su presencia requiere atención; en contraste, por ejemplo, el efecto que
el Gobierno tiene sobre la regulación de las actividades de la industria tabacalera con la relativa debilidad de
un pequeño subcontratista de trabajo para Oracle, en el desarrollo de un nuevo software. En el primer caso,
el gobierno federal, en los últimos años, ha limitado fuertemente las actividades y estrategias de ventas de las
compañías de tabaco por la amenaza de regulaciones y litigios. Por el otro lado, Oracle, una organización
grande, puede sustituir fácilmente a un pequeño subcontratista con otro.
El análisis de los interesados es útil en la medida en que obliga a las empresas a admitir los posibles
efectos de amplio rango, tanto intencionales como no intencionales, que sus acciones pueden tener en los
diferentes interesados9. Por ejemplo, la decisión estratégica de cerrar una planta de fabricación improductiva
puede ser un buen negocio en términos de costos frente a los beneficios que la empresa deriva de la planta.
Sin embargo, la decisión de cerrar la planta tiene el potencial de desatar un torrente de quejas de los interesa-
dos en forma de protestas y desafíos por los sindicatos locales, trabajadores, líderes comunitarios de la ciudad
afectadas por el cierre, grupos políticos, jurídicos, ambientales y demás. Los altos gerentes deberán tener en
cuenta el efecto de la reacción de los interesados, porque estos evalúan los posibles efectos de sus decisiones
estratégicas.
Al igual que el análisis de los interesados es relevante para comprender el efecto de las decisiones estra-
tégicas, el análisis de los interesados es de suma importancia cuando se trata de la gerencia de proyectos. El
propio proceso de desarrollo del proyecto puede afectarse directamente por los interesados. Esta relación es
esencialmente recíproca debido a que las actividades del equipo del proyecto también pueden afectar a los
interesados externos.10 Algunas formas comunes del efecto que tiene el grupo de interesados cliente, en las
operaciones del equipo del proyecto, incluyen la campaña a favor de un desarrollo más rápido, trabajando en
estrecha colaboración con el equipo para aliviar los problemas de transferencia de proyectos que influyen en
la alta dirección de la organización para seguir apoyando el proyecto. El equipo del proyecto puede corres-
ponder a este apoyo mediante acciones que muestran disposición a cooperar estrechamente con el cliente en
el desarrollo y en la transición a los grupos de usuarios.
2.2  Gerencia de los interesados (stakeholders) 41

La naturaleza de diversas demandas puede colocarlos aparentemente en conflicto directo. Es decir, en


respuesta a las inquietudes de una parte interesada, los gerentes de proyectoss, a menudo sin saberlo, han
ofendido o enojado a otro interesado que tiene una agenda y un conjunto de expectativas diferente. Por
ejemplo, un equipo de proyecto que trabaja para instalar una nueva aplicación de software en la organización
puede llegar a tales niveles para garantizar la satisfacción del cliente, en la cual se involucran un sinnúmero
de revisiones del paquete hasta que, al parecer, sus clientes estén felices. Sin embargo, al hacerlo, el crono-
grama general del proyecto puede haber caído hasta el punto de que la alta dirección se moleste por el costo
y los retrasos de la programación. En la gerencia de proyectos, se presenta el desafío de hallar formas para
equilibrar una serie de demandas y seguir manteniendo relaciones de apoyo y constructivas con cada grupo
de interesados.

Identificación de los interesados del proyecto


Los interesados internos son un componente vital en cualquier análisis de interesados; por lo general, su efecto
se siente en forma relativamente positiva. Es decir, a pesar de que unos actúan como influencias de control y
seguimiento (el contador de la empresa), más interesados internos quieren ver el proyecto desarrollado con
éxito. Por otro lado, algunos interesados externos influyen de manera hostil en el desarrollo del proyecto.
Consideremos la reciente serie de alzas en el precio del petróleo. Con los precios del petróleo relativamente
inestables y amenazando llegar o incluso sobrepasar los 100 dólares por barril durante el 2010, el efecto en la
economía mundial fue muy grave. En Estados Unidos, muchos grupos han defendido la adopción de medidas
para reducir la dependencia del país del petróleo extranjero, incluida la exploración en alta mar y el desarrollo
de una nueva generación de centrales nucleares. Los grupos ecologistas, sin embargo, siguen oponiéndose a
estas medidas y prometieron demandas, presiones políticas y otras medidas para resistirse al desarrollo de
estas fuentes de energías alternativas. Como un ejemplo reciente del peligro, esos grupos citaron el desastre de
Deepwater Horizon, en el que hubo un escape de miles de barriles de petróleo en el golfo de México. Cleland
se refiere a estos agentes externos como grupos interventores, definidos como interesados externos en el pro-
yecto que poseen la facultad de intervenir efectivamente y perturbar el desarrollo del proyecto.11
Entre el conjunto de interesados que los gerentes de proyectoss deben tomar en cuenta se encuentran:
Internos:
• Alta dirección
• Contabilidad
• Otros gerentes funcionales
• Miembros del equipo del proyecto

Externos:
• Clientes
• Competidores
• Proveedores
• Grupos interventores: ambientalistas, políticos, consumidores, entre otros

CLIENTES  El enfoque a lo largo de todo este libro será el mantenimiento y mejora de las relaciones con
los clientes. En la mayoría de los casos, para los clientes externos e internos, un proyecto es una inversión.
Los clientes están interesados en recibir, del equipo, el proyecto lo más rápido posible, porque cuanto más
tiempo dure la ejecución del proyecto, mayor será el dinero invertido sin generar beneficios. Siempre y
cuando no se pase el valor que deben pagar, los clientes rara vez se interesan demasiado en la cantidad de
gastos involucrados en el desarrollo de un proyecto. Sin embargo, generalmente ocurre lo contrario: los
costos normalmente deben trasladarse a los clientes y ellos están ávidamente interesados en conseguir lo que
pagaron. También muchos proyectos comienzan antes de que las necesidades del cliente se definan comple-
tamente. La proyección del concepto del producto y su aclaración, a menudo forman parte del alcance del
proyecto (véase el capítulo 5). Estos factores—los costos y las necesidades de los clientes—son dos razones
de peso por las que muchos clientes adquieren el derecho de hacer sugerencias y solicitar modificaciones
en los componentes del proyecto, las características de funcionamiento y en el cronograma. Los clientes
sienten, con razón, que un proyecto solo es bueno como aceptable y útil sea; esto establece un requisito de
flexibilidad y requiere voluntad del equipo del proyecto para efectuar cambios en las especificaciones.
42 Capítulo 2  •  El contexto organizacional. Estrategia, estructura y cultura

Organización
principal

Otros gerentes Entorno


funcionales externo

Gerente de Alta
Clientes
proyectos dirección

Contador Equipo del


proyecto

FIGURA 2.3  Relaciones entre los interesados del proyecto

Otro hecho importante para recordar sobre cómo tratar con los grupos de clientes es el siguiente:
el término cliente no se refiere, en todos los casos, a la totalidad de la organización del cliente. La realidad
suele ser más compleja: una empresa cliente se compone de un número de grupos internos de interesados,
en muchos casos con agendas diferentes. Por ejemplo, una compañía probablemente puede identificar fácil-
mente un número de clientes diferentes dentro de la empresa cliente, incluido el equipo de alta dirección,
grupos de ingeniería, equipos de ventas, equipos de trabajo de campo, grupos de fabricación o montaje, entre
otros. En circunstancias normales, se evidencia que el proceso de formular un análisis de los interesados de
una empresa cliente puede ser una tarea compleja.
El problema se complica aún más con la necesidad de comunicarse, tal vez usando un lenguaje de
negocios diferente, con los diferentes interesados del cliente (véase figura 2.3). Preparar una presentación
para tratar con el personal de ingeniería del cliente requiere el dominio de la información técnica y detalles
sólidos de las especificaciones. Por otro lado, la gente de finanzas y de contratación buscan cifras claras.
Formular estrategias para los interesados requiere primero reconocer la existencia de los diferentes actores
del cliente y luego formular un plan coordinado para descubrir y abordar las preocupaciones específicas de
cada grupo, a fin de aprender cómo llegar a ellos.

COMPETIDORES  Los competidores pueden ser un elemento importante dentro de las partes interesadas,
pues estos se afectan por la ejecución exitosa del proyecto. Del mismo modo, si una compañía rival introduce
un nuevo producto en el mercado, la organización principal del equipo del proyecto podría verse obligada a
modificar, retrasar o incluso abandonar su proyecto. En la evaluación de la competencia como un grupo de
interesados, los gerentes de proyectoss deben tratar de descubrir cualquier información disponible sobre la
situación de los proyectos de un competidor. Además, siempre que sea posible, las lecciones que un compe-
tidor pueda haber aprendido suelen ser una fuente de información útil para el gerente de proyecto que inicia
un proyecto similar. Si se presentaron problemas graves durante el desarrollo del proyecto de la competencia,
esta información podría ofrecer lecciones valiosas para evitarlos.

PROVEEDORES  Los proveedores son cualquier grupo que proporcione materias primas u otros recursos
que el equipo del proyecto necesite para la ejecución de este. Cuando un proyecto requiere un suministro
numeroso de componentes adquiridos externamente, el gerente del proyecto debe tomar todas las medidas
posibles para garantizar las entregas estables. En la mayoría de los casos se trata de una vía de doble sentido.
En primer lugar, el gerente del proyecto tiene que asegurarse de que cada proveedor recibe la información de
entrada necesaria para ejecutar su parte del proyecto de forma oportuna. En segundo lugar, se deben moni-
torear las entregas para que se cumplan de acuerdo con el plan. En el caso ideal, la cadena de suministro se
convierte en una máquina bien engrasada que automáticamente atrae la información de entrada del equipo
de proyecto y entrega los productos sin la intervención excesiva del gerente del proyecto. Por ejemplo, en
proyectos de construcción a gran escala los equipos de proyecto diariamente deben enfrentarse con satis-
facer una enorme cantidad de demandas de los proveedores. Toda la disciplina de la gestión de la cadena de
2.2  Gerencia de los interesados (stakeholders) 43

suministro se basa en la capacidad de coordinar los procesos logísticos mediante la gestión eficaz de la cadena
de suministro del proyecto. Cuando este proceso falla, como en el caso del Boeing 787 Dreamliner, el resul-
tado puede ser problemático para la organización, y genera retrasos serios en el proyecto y multas potenciales
o sanciones (véase el caso Dreamliner en el capítulo 9).

GRUPOS INTERVENTORES   Los grupos ambientales, políticos, sociales, activista-comunitarios o consumi-


dores que pueden tener un efecto positivo o negativo en el lanzamiento y desarrollo exitoso del proyecto, se
conocen como grupos interventores.12 Es decir, tienen la capacidad de intervenir en el desarrollo del pro-
yecto, lo cual obliga a incluir sus preocupaciones en la ecuación para la ejecución del proyecto. Hay algunos
ejemplos clásicos de grupos interventores que restringen grandes proyectos de construcción, especialmente
en el sector de plantas de energía nuclear. Cuando reguladores federales, estatales e incluso locales deciden
involucrarse en estos proyectos de construcción, los interventores tienen a su disposición el sistema legal
como un método para atar o incluso frenar proyectos. Recientemente, los proyectos de energía alternativa
“granjas eólicas”, que se proponen para los sitios de la costa de Cabo Cod, Massachusetts, han encontrado
una fuerte resistencia por grupos locales que se oponen a la amenaza de que estas granjas arruinen el paisaje
marino local. Los gerentes de proyectoss deben ser prudentes y hacer una evaluación realista de la naturaleza
de sus proyectos para determinar la posibilidad de que un grupo interventor u de otro tipo, se esfuerce para
imponer su voluntad sobre el proceso de desarrollo.

ALTA DIRECCIÓN   En la mayoría de las organizaciones, la alta dirección tiene gran control sobre los geren-
tes de proyectoss y está en la posición de regular su accionar. La alta dirección es, después de todo, el orga-
nismo que autoriza el desarrollo del proyecto, al tomar la decisión inicial “adelante”, transfiere los recursos
adicionales que el equipo del proyecto necesita y apoya y protege a los gerentes de proyectoss y a sus equi-
pos de otras presiones organizacionales. La alta dirección requiere que el proyecto sea oportuno (lo quieren
entregar rápidamente), eficiente en costo (no quieren pagar más por lo que tienen que hacer) y mínima-
mente perjudicial para el resto de la organización.

CONTABILIDAD   La razón de ser del contador de la organización es mantener la eficiencia de los costos en
los equipos de proyecto. Los contadores apoyan y controlan activamente los presupuestos de los proyectos
y, por tanto, a veces son percibidos como el enemigo por parte del gerente del proyecto. Esta percepción
es equivocada. Para gestionar el proyecto, para tomar las decisiones necesarias y para comunicarse con el
cliente, el gerente del proyecto tiene que estar, en todo momento, al tanto de los costos del proyecto. Los
mecanismos eficientes de control y la información de costos son vitales. Los contadores prestan un servicio
administrativo importante al gerente del proyecto.

GERENTES FUNCIONALES  Los gerentes funcionales que ocupan posiciones de línea dentro de la cadena
tradicional de mando son un importante grupo de interesados por identificar. La mayoría de los proyectos
son atendidos por personas que están esencialmente en calidad de préstamo de sus departamentos fun-
cionales. De hecho, en muchos casos, los miembros del equipo del proyecto solo podrán trabajar tiempo
parcial para el equipo; sus gerentes funcionales aún pueden esperar de ellos una gran cantidad de tareas
por semana, en el ejercicio de sus responsabilidades funcionales. Esta situación puede crear gran parte de la
confusión, el conflicto y la necesidad de negociación entre los gerentes de proyectoss y supervisores funcio-
nales y generar serias lealtades divididas entre los miembros del equipo, sobre todo cuando las evaluaciones
de desempeño las realizan los gerentes funcionales en lugar del gerente de proyecto. En términos de la
simple autosupervivencia, los miembros del equipo a menudo mantienen más lealtad a su grupo funcional
que al equipo del proyecto.
Los gerentes de proyectos tienen que valorar el poder de los gerentes funcionales de la organización
como los interesados. Los gerentes funcionales, por lo general, no desalientan el desarrollo del proyecto, más
bien, son leales a sus papeles funcionales y actúan y usan sus recursos en consecuencia, dentro de los límites
de la estructura empresarial. Por tanto, como un grupo de interesados importante, los gerentes funcionales
tienen que ser tratados con la debida consideración por los gerentes de proyectos.

MIEMBROS DEL EQUIPO DEL PROYECTO   El equipo del proyecto, obviamente, tiene un gran interés en el
resultado del proyecto. Aunque algunos pueden tener lealtad dividida entre el proyecto y su grupo funcio-
nal, en muchas empresas los miembros del equipo son voluntarios para formar parte de los proyectos y, con
44 Capítulo 2  •  El contexto organizacional. Estrategia, estructura y cultura

suerte, recibir el tipo de asignaciones y oportunidades de trabajo desafiantes de crecimiento que los motivan
a desempeñarse eficazmente. Los gerentes de proyectos deben entender que el éxito de su proyecto depende
del compromiso y la productividad de cada miembro de su equipo. Por tanto, el efecto de los miembros del
equipo del proyecto es, en muchos sentidos, más profundo que el de cualquier otro grupo de interesados.

Gestión de los interesados


Los gerentes de proyectos y sus empresas necesitan reconocer la importancia de los interesados y gestionar-
los proactivamente. Block ofrece un marco útil del proceso político que tiene aplicación en la gerencia de las
partes interesadas.13 En su marco, Block sugiere seis pasos:
1. Evaluar el entorno
2. Identificar los objetivos de los actores principales
3. Evaluar sus propias capacidades
4. Definir el problema
5. Desarrollar soluciones
6. Probar y perfeccionar las soluciones

EVALUAR EL ENTORNO  ¿El proyecto es relativamente discreto o potencialmente tan importante que pro-
bablemente genere gran atención? Por ejemplo, cuando EMC Corporation, una importante empresa de com-
putadores, comenzó el desarrollo de una nueva línea de minicomputadores y unidades de almacenamiento
con potencial, ya sea para grandes ganancias o serias pérdidas, tuvo mucho cuidado en determinar la nece-
sidad de este tipo de productos, acudiendo directamente a la población de consumidores a través de una
investigación de mercados, la cual resultó clave para evaluar el ambiente externo. Del mismo modo, una de
las razones de la popularidad de la Ford Escape fue que Ford estuvo dispuesto a crear, antes del desarrollo del
proyecto, equipos de proyectos que incluían a los consumidores con el fin de evaluar con mayor precisión sus
necesidades. Además, el reconocimiento de los consumidores conscientes del medio ambiente y sus necesi-
dades obligó a Ford a crear una opción de los SUV con un motor híbrido de gasolina-eléctrico.

IDENTIFICAR LOS OBJETIVOS DE LOS ACTORES PRINCIPALES   Como primer paso para la configuración
de una estrategia para neutralizar la reacción negativa, un gerente de proyecto debe dibujar un retrato exacto
de las preocupaciones de las partes interesadas. Fisher y Ury14 señalan que las distintas posiciones de las
partes se basan casi siempre en sus necesidades. Entonces, ¿cuáles son las necesidades de cada grupo signi-
ficativo de interesados respecto al proyecto? Un ejemplo ilustrará este punto. Una pequeña empresa de IT
especializada en soluciones de redes y desarrollo de software fue contratada recientemente por una gran casa
editorial para desarrollar una simulación para uso académico universitario. La empresa de software estuvo
dispuesta a negociar un precio más bajo de lo normal por el trabajo, porque la editorial sugirió que un exce-
lente rendimiento en este proyecto daría lugar a futuros negocios. La organización de software, interesada
en hacer crecer su negocio, aceptó el pago más bajo, considerando que sus necesidades más inmediatas eran
entrar en el sector de la edición y desarrollar relaciones a largo plazo con los clientes. La editorial necesitaba
un precio bajo, el desarrollador de software necesitaba nuevas oportunidades de mercado.
Los equipos de proyectos deben buscar agendas ocultas en la evaluación de metas. Es común que los depar-
tamentos e interesados expresen unas metas explícitas relevantes, pero a menudo ilusorias.15 Al precipitarse a
satisfacer estas metas manifiestas o adoptadas, un error común es aceptarlas en su valor superficial, sin mirar
dentro las necesidades que puedan generar otras o crear metas más atractivas. Consideremos, por ejemplo, un
proyecto en una gran empresa de fabricación basada en proyectos, para desarrollar un sistema integral de gestión
de programación para proyectos. El gerente del proyecto a cargo de la instalación se acercó a cada jefe de departa-
mento y creyó que había asegurado su voluntad de participar en la creación del sistema de programación a cargo
de la división de gerencia de proyectos. Sin embargo, los problemas se presentaron rápidamente, porque los
miembros del departamento de IT, a pesar de sus intenciones públicas de apoyo, comenzaron a utilizar todos los
medios posibles para sabotear encubiertamente la implementación del sistema, retrasando la terminación de las
tareas y negándose a responder a las peticiones de los usuarios. ¿Cuál era su problema? Ellos creían que la coloca-
ción de una fuente de información generada por computador en cualquier lugar, diferente del departamento de
IT amenazaba su posición como el único difusor de información. Además de sondear las metas y preocupaciones
de los diferentes interesados, los gerentes de proyectoss deben buscar agendas ocultas y otras fuentes que puedan
restringir el éxito de la implementación.
2.2  Gerencia de los interesados (stakeholders) 45

EVALUAR SUS PROPIAS CAPACIDADES  Como dijo Robert Burns, “oh y algún poder de pequeño regalo
danos/Vernos a nosotros mismos como nos ven los demás!”, las organizaciones deben tomar en cuenta
lo que hacen bien. Del mismo modo, ¿cuáles son sus puntos débiles? ¿El gerente del proyecto y su equipo
tienen la habilidad política y la posición de negociación suficientemente fuertes para obtener el apoyo de
cada uno de los interesados? Si no, ¿tienen conexiones con alguien que pueda hacerlo? Cada una de estas
preguntas es un ejemplo de la importancia para el equipo del proyecto, así como comprender sus propias
capacidades y habilidades. Por ejemplo, no todo el mundo tiene los contactos necesarios con la alta geren-
cia, para asegurar un flujo constante de apoyo y recursos. Si determina de forma realista que la perspicacia
política no es su punto fuerte, la solución puede ser encontrar a alguien que tenga estas habilidades para
ayudarle.

DEFINIR EL PROBLEMA  Se debe tratar de definir los problemas, en términos de nuestra propia perspec-
tiva y tomando en cuenta las preocupaciones legítimas de la otra parte. La clave para desarrollar y mantener
relaciones fuertes con los interesados radica en el reconocimiento de que las diferentes partes pueden tener
muy diferentes pero igualmente legítimas perspectivas sobre un problema. Cuando se definen los proble-
mas no solo desde nuestro punto de vista, sino tratando de entender cómo el mismo problema se percibe
por los interesados, estamos operando de modo “gana-gana”. Además, se debe ser lo más precisos posible,
manteniendo la concentración en los aspectos específicos del problema, no en sus generalidades. Cuanto
más precisa y honestamente se pueda definir el problema, mayor será la capacidad para generar opciones
significativas de solución.

DESARROLLAR SOLUCIONES  Hay dos puntos importantes para tomar en cuenta en este paso. En
primer lugar, el desarrollo de soluciones significa precisamente eso: la creación de un plan de acción
para hacerle frente, en la medida de lo posible, a las necesidades de los distintos interesados en relación
con los otros interesados. Este paso constituye la etapa en que el gerente del proyecto, junto al equipo,
busca administrar el proceso político. ¿Qué va a funcionar para hacerle frente a la alta gerencia? En
la aplicación de esta estrategia, ¿cuál sería la reacción más probable del contador? ¿Del cliente? ¿Del
equipo del proyecto? Formular estas preguntas ayuda al gerente del proyecto a desarrollar soluciones
que reconozcan las interrelaciones de cada uno de los interesados relevantes. Los temas de poder, el
comportamiento político, la influencia y negociación se discutirán con mayor detalle en el capítulo 6.
Como segundo punto, hay que realizar la tarea política previa al desarrollo de las soluciones.16 Tenga
en cuenta la siguiente etapa en la que se introduce este paso. Los gerentes de proyectos pueden caer en una
trampa si intentan gestionar un proceso solamente con información fragmentada o inadecuada. La filosofía
“preparados, apunten, fuego” a veces es común en la gestión de los interesados. El resultado es una etapa de
lucha perpetua contra el fuego, en el que el gerente del proyecto es un péndulo virtual, que se balancea de
una crisis a otra. Los péndulos y los gerentes de proyectoss comparten una característica: nunca alcanzan una
meta. El proceso de apagar el fuego siempre parece crear un nuevo incendio.

PROBAR Y PERFECCIONAR LAS SOLUCIONES   La implementación de las soluciones implica reconocer


que el gerente del proyecto y el equipo están operando con información imperfecta. Se puede suponer que los
actores reaccionarán a ciertas iniciativas de forma predecible, pero tales supuestos pueden ser erróneos. Al
probar y refinar las soluciones, el gerente del proyecto y el equipo deben darse cuenta de que la implementa-
ción de soluciones es un proceso iterativo. Usted hace sus mejores estimativos, prueba las reacciones de los
interesados y en consecuencia reforma sus estrategias. En el camino, muchas de sus nociones preconcebidas
acerca de las necesidades y sesgos de los distintos interesados deben perfeccionarse. En algunos casos, se
podrán realizar evaluaciones precisas. En otras ocasiones, sus supuestos serán peligrosamente ingenuos o
falsos. No obstante, este último paso en el proceso de gerencia de los interesados obliga al gerente del pro-
yecto a llevar a cabo una autoevaluación crítica. Se requiere la flexibilidad necesaria para realizar diagnósticos
precisos y correcciones apropiadas a medio camino.
Cuando se dan bien, estos seis pasos constituyen un método determinante para reconocer el papel que
desempeñan los interesados en la implementación exitosa del proyecto. Esto permite a los gerentes de pro-
yectoss acercarse a “la gestión política de los interesados” tanto como lo harían con cualquier otra forma de
resolución de problemas, reconociéndolo como un problema con tantos factores como interesados interac-
túen en el proyecto y entre sí. Las soluciones para la gestión política de los interesados pueden ser, entonces,
más fértiles, más exhaustivas y más exactas.
46 Capítulo 2  •  El contexto organizacional. Estrategia, estructura y cultura

1. Identificar a los
interesados
(stakeholders)

7. Implementar la 2. Recopilar
estrategia de información
gestión de sobre los
de los interesados
interesados

6. Predecir el 3. Identificar la
comportamiento misión de los
de los interesados
interesados

5. Identificar 4. Determinar las


estrategias de fortalezas y
los interesados debilidades de
los interesados

FIGURA 2.4  Ciclo de gestión de los interesados del proyecto


Fuente: D. I. Cleland. (1988). “ Project Stakeholder Management,” in D. I. Cleland and W. R. King
(Eds.), Project Management Handbook, 2nd ed. New York: Van Nostrand Reinhold, pp 275-301.
Reproducido con permiso de John Wiley & Sons, Inc.

Una alternativa simplificada en el proceso de gestión de los interesados consiste en planificar, orga-
nizar, dirigir, motivar y controlar los recursos necesarios para tratar con los diversos interesados internos
y externos. La figura 2.4 muestra un modelo sugerido por Cleland17 que ilustra el proceso de gestión en
el análisis y gerencia de los interesados. Cleland afirma que las diversas funciones de gestión de las partes
interesadas están entrelazadas y son repetitivas, es decir, conforman un ciclo recurrente. Además de iden-
tificar y adaptarse a las amenazas de las partes interesadas, se deben desarrollar planes para manejar, de la
mejor manera, los desafíos que ellas plantean. En el proceso de elaboración y aplicación de estos planes,
probablemente se descubrirán nuevos actores cuyas demandas también deben tenerse en cuenta. Además,
como el ambiente cambia o como el proyecto entra en una nueva etapa de su ciclo de vida, es posible que se
requiera recorrer nuevamente el modelo de gestión de los interesados, con el fin de verificar que las viejas
estrategias de gestión siguen siendo eficaces. Si, por el contrario, se considera que las nuevas circunstancias
exigen modificar las estrategias, hay que trabajar con este modelo de gestión de los interesados de nuevo para
actualizar la información pertinente.

2.3  ESTRUCTURA ORGANIZACIONAL


La palabra estructura implica organización. Las personas que trabajan en una organización se agrupan de
manera tal que sus esfuerzos puedan canalizarse para lograr su máxima eficiencia. La estructura de la orga-
nización consta de tres elementos claves.18
1. La estructura organizacional establece las relaciones formales de comunicación, incluido el número
de niveles jerárquicos y el alcance del control para gerentes y supervisores.  ¿Quién reporta a quién
en la jerarquía estructural? Este es un componente clave de la estructura de la empresa. El ámbito
de control determina el número de subordinados que dependen directamente de cada supervisor.
En algunas estructuras, un gerente puede tener un amplio ámbito de control, lo que sugiere un gran
número de subordinados; otras, exigen tramos estrechos de control de pocos y pocas personas que
reportan directamente a cualquier supervisor. En algunas empresas, la relación de subordinación
2.4  Formas de estructura organizacional 47

puede ser rígida y burocrática; otras empresas requieren flexibilidad e informalidad a través de los
niveles jerárquicos.
2. La estructura organizacional identifica la agrupación de las personas en departamentos y de departa-
mentos en la organización.  ¿Cómo están reunidas las personas en grupos más grandes? Empezando
por lo más pequeño, las unidades de una estructura continuamente se recombinan con otras unidades
para crear grupos más grandes, u organizaciones de personas. Estos grupos, referidos como departa-
mentos, pueden agruparse según diferentes patrones lógicos. Por ejemplo, los criterios más comunes
en la creación de departamentos incluyen: (1) funciones, que agrupan personas que realizan actividades
similares en un mismo departamento; (2) productos, que agrupan personas que trabajan en líneas de
productos similares en departamentos; (3) geografía, que agrupan personas dentro de regiones geo-
gráficas similares o lugares físicos en un mismo departamento; (4) proyectos, que agrupan personas
involucradas en el mismo proyecto en un departamento. Más adelante, en este capítulo, se analizarán
algunos de los arreglos departamentales más comunes.
3. La estructura organizacional incluye el diseño de sistemas para asegurar la comunicación efectiva y la
coordinación e integración de esfuerzos entre los departamentos.   Esta característica de la estructura
organizacional se refiere a los mecanismos de apoyo que la empresa realiza para reforzar y fomentar su
estructura. Estos mecanismos de soporte pueden ser simples o complejos. En algunas empresas, un método
para asegurar la comunicación efectiva es simplemente ordenar, a través de normas y procedimientos, la
forma en que los miembros del equipo del proyecto deben comunicarse entre sí y los tipos de información
que deben compartir de forma rutinaria. Otras compañías utilizan métodos más sofisticados o complejos
para la promoción de la coordinación, como la creación de oficinas de proyectos especiales, aparte del resto
de la empresa en donde los miembros del equipo trabajan durante el desarrollo del proyecto. La idea clave
detrás de este tercer elemento en la estructura organizacional implica que la simple creación de un orden
lógico o jerarquía de personal no es suficiente para una organización, a menos que se soporten en sistemas
que aseguren la comunicación y la coordinación clara entre todos los departamentos.
También es importante tomar en cuenta que en el contexto de gerencia de proyectos operan simultá-
neamente dos estructuras distintas y ambas afectan la manera en que se lleva a cabo el proyecto. La primera
es la estructura general de la organización que desarrolla el proyecto: dispone de todas las unidades o intere-
sados que participan en el desarrollo del proyecto e incluye el equipo del proyecto, el cliente, la alta gerencia,
los departamentos funcionales y otros interesados. La segunda estructura, la estructura interna del equipo del
proyecto, especifica la relación entre los miembros del equipo del proyecto, sus papeles, responsabilidades y
su interacción con el gerente del proyecto. En la mayor parte de este capítulo se examina la estructura gene-
ral de toda la organización y la forma en que se refiere a la gerencia de proyectos. Las implicaciones de la
estructura interna del equipo del proyecto se abordarán aquí, pero se exploran más a fondo en el capítulo 6.

2.4  FORMAS DE ESTRUCTURA ORGANIZACIONAL


Las organizaciones pueden estructurarse en una variedad infinita de formas, que van desde muy complejas
a extremadamente simples. Vale la pena entender que, por lo general, la estructura de una organización no
sucede por casualidad, sino que es el resultado de una respuesta razonada a las fuerzas que actúan sobre la
empresa. Un número de factores afectan de forma rutinaria las razones por las que una empresa se estructura
de la manera que lo hace. El entorno en que opera es uno de los determinantes o factores más importantes
que influyen en la estructura de una organización. El ambiente externo de una organización se compone de
todas las fuerzas o grupos fuera de la organización que potencialmente la afectan. Entre los elementos del
entorno externo de la empresa que desempeñan un papel en las actividades de una empresa se destacan los
competidores, los clientes, el gobierno y otros cuerpos legales o reglamentarios, las condiciones económicas
generales, el conjunto de recursos humanos y financieros disponibles, los proveedores, así como tendencias
tecnológicas. A su vez, estas estructuras organizacionales, a menudo creadas por razones muy sólidas en
relación con el medio externo, tienen un fuerte efecto en la manera en que los proyectos se gestionan dentro
de la organización. Como veremos, cada tipo de organización ofrece sus propias ventajas y desventajas como
contexto en la creación de proyectos.
Algunas estructuras comunes que agrupan a la mayoría de las empresas son las siguientes:
1. Organizaciones funcionales—Empresas que se estructuran en departamentos mediante la agrupación
de las personas que realizan actividades similares.
48 Capítulo 2  •  El contexto organizacional. Estrategia, estructura y cultura

2. Organizaciones basadas en proyectos—Empresas estructuradas según la agrupación de las personas


en los equipos de proyecto, con asignaciones temporales.
3. Organizaciones matriciales—Empresas que se estructuran mediante la creación de una jerarquía dual,
en las que las funciones y los proyectos tienen la misma importancia.

Organizaciones funcionales
La estructura funcional es probablemente el tipo de organización más común en los negocios de hoy día. La lógica
de la estructura funcional es agrupar en unidades a personas y departamentos que realizan actividades similares.
En esta estructura, es común crear departamentos como contabilidad, marketing o investigación y desarrollo. La
división del trabajo en la estructura funcional no se basa en el tipo de producto o proyecto subvencionado, sino
más bien acorde con el tipo de trabajo realizado. En una organización con una estructura funcional, los miembros
trabajan de forma rutinaria en varios proyectos o apoyan múltiples líneas de producto simultáneamente.
La figura 2.5 muestra un ejemplo de una estructura funcional. Entre las ventajas claras de la organización
funcional está la eficiencia. Cuando cada contador es un miembro del departamento de contabilidad, es posible
asignar de manera más eficiente los servicios del grupo para toda la organización; el departamento da cuenta de
las asignaciones de trabajo de cada contador asegurándose de que no haya duplicación de esfuerzos o recursos
no utilizados. Otra ventaja: es más fácil mantener el valioso capital intelectual cuando toda la experiencia se
consolida en un departamento funcional. Cuando se necesite un experto en asuntos fiscales en el extranjero
para los proyectos tercerizados a nivel mundial, no se tiene que hacer una de búsqueda en toda la empresa sino
acudir directamente al departamento de contabilidad para encontrar un experto.
La debilidad más común en una estructura funcional, desde la perspectiva de la gerencia del proyecto,
está relacionada con la tendencia de los trabajadores organizados de esta manera a centrarse en sus propios
asuntos y trabajo asignado, sin interesarse por las necesidades de los otros departamentos. Esta idea ha sido
etiquetada como siloing, en relación con los silos que se encuentran en granjas (véase la figura 2.6). El siloing se
produce cuando las personas similares en un grupo de trabajo no están dispuestas a considerar puntos de vista
alternativos, colaborar con otros grupos o trabajar de manera multifuncional. Por ejemplo, en Data General
Corporation, antes de su adquisición por EMC, las disputas entre ingeniería y ventas fueron constantes. El
departamento de ventas se quejó de que sus aportes al desarrollo de nuevos productos se minimizaban cuando
el departamento de ingeniería tomaba rutinariamente el liderazgo en la innovación, sin consultar de forma
significativa con los otros departamentos. Del mismo modo, Robert Lutz, expresidente de Chrysler, sostuvo que
una debilidad de la industria automotriz era la incapacidad de los distintos departamentos funcionales a coope-
rar y a reconocer las contribuciones de los demás. Generalmente, otra debilidad de las estructuras funcionales
es la pobre capacidad de respuesta a las oportunidades y amenazas externas. Los canales de comunicación tien-
den a correr de arriba abajo de la jerarquía, en lugar de a través de fronteras funcionales. Esta jerarquía vertical
puede sobrecargarse, y la toma de decisiones lleva tiempo. Las estructuras funcionales también pueden no ser

Junta directiva

Director ejecutivo

Vice presidente Vice presidente Vice presidente Vice presidente


de marketing de producción de finanzas de investigación
Desarrollo de
Investigación de Servicios de nuevos productos
mercados Logística
contabilidad
Ventas Pruebas
Subcontratación
Contratación
Soporte mercado laboratorios
Distribución
de posventa Inversiones de Investigación
Almacenamiento Calidad
Publicidad Beneficios para
Fabricación los empleados

FIGURA 2.5  Ejemplo de una estructura organizacional funcional


2.4  Formas de estructura organizacional 49

Junta directiva

Director ejecutivo

Vice presidente Vice presidente Vice presidente Vice presidente


de marketing de producción de finanzas de investigación
Desarrollo
Investigación de Servicios de de nuevos
mercados Logística
contabilidad productos
Ventas Subcontratación Pruebas
Contratación
Soporte mercado Distribución laboratorios
de postventa Inversiones de Investigación
Almacenamiento Calidad
Publicidad Beneficios
Fabricación para los
empleados

FIGURA 2.6  Efecto siloing en estructuras funcionales

muy innovadoras debido a los problemas inherentes al diseño. Los grupos funcionales en silos suelen tener una
visión restringida de la organización en general y de sus metas; por tanto, es difícil lograr la coordinación entre
funciones necesarias para innovar o responder rápidamente a las oportunidades de mercado.
Para la gerencia de proyectos, una debilidad adicional de la estructura funcional es que no propor-
ciona ninguna ubicación lógica para una función central de gerencia de proyectos. La alta gerencia puede
asignar un proyecto y delegar diversos componentes de ese proyecto a especialistas dentro de los diferentes
grupos funcionales. La coordinación general del proyecto, incluida la combinación de los esfuerzos de las
diferentes funciones asignadas para realizar las tareas del proyecto, debe producirse en un nivel directivo
superior. En este entorno operativo, un serio inconveniente para el funcionamiento de los proyectos es que
a menudo deben estar estratificados o superpuestos a las tareas en curso de los miembros de grupos funcio-
nales. El efecto práctico es que las personas cuyas tareas principales permanecen dentro de su grupo funcio-
nal se asignan al personal del proyecto, y cuando los empleados le deben lealtad a su propio departamento,
su marco de referencia puede seguir funcionando. En este sentido, los proyectos pueden ser distracciones
temporales, y toman tiempo fuera del “trabajo real”. Esto explica algunos de los problemas de conducta, que
se producen durante la ejecución de los proyectos, como la baja motivación de los miembros del equipo o
la necesidad de largas negociaciones entre los gerentes de proyectos y los supervisores de departamento del
personal asignado al equipo de proyecto.
Otro problema de la organización funcional, relacionado con el proyecto, es su fácil suboptimización
del desarrollo.19 Cuando el proyecto se desarrolla como la creación de un departamento, los esfuerzos de ese
grupo pueden considerarse buenos y eficaces. Por el contrario, los departamentos no tan directamente vin-
culados o interesados del proyecto pueden ejercer sus funciones en el nivel mínimo posible. El éxito de un
producto o servicio basado en proyectos requiere los esfuerzos plenamente coordinados de todos los grupos
funcionales que participan y contribuyen al desarrollo del proyecto.
Otro problema es que los clientes no son el foco principal de todos dentro de una organización
estructurada funcionalmente. En este ambiente, el cliente puede verse como un problema ajeno, sobre
todo entre el personal cuyas funciones tienden a ser de apoyo. Los requisitos del cliente se deben cumplir,
y los proyectos se deben crear con el cliente en mente. Cualquier representante departamental del equipo
del proyecto que no haya adoptado una mentalidad “centrada en el cliente” suma a la posibilidad de que
el proyecto se quede corto.
En resumen, la estructura funcional (véase el cuadro 2.2), puesto que se relaciona con el ambiente
externo, se adapta bien a empresas con niveles relativamente bajos de incertidumbre externa, debido a que
entornos estables no requieren una adaptación o capacidad de respuesta rápida. Cuando el ambiente es relati-
vamente predecible, la estructura funcional opera bien porque hace énfasis en la eficiencia. Infortunadamente,
las actividades de gerencia de proyectos dentro de una empresa organizada funcionalmente a menudo pueden
50 Capítulo 2  •  El contexto organizacional. Estrategia, estructura y cultura

CUADRO 2.2  Fortalezas y debilidades de las estructuras funcionales en la gerencia de proyectos

Fortalezas para la gerencia de proyectos Debilidades para la gerencia de proyectos


1. Los proyectos se desarrollan dentro de la 1. El siloing dificulta la cooperación multifuncional.
estructura funcional básica de la organi-
zación, sin necesidad de interrumpir ni
alterar el diseño de la empresa.
2. Permite el desarrollo de un profundo co- 2. Falta de orientación al cliente.
nocimiento y el capital intelectual.
3. Permite carreras estándares. Los miembros 3. Los proyectos suelen tomar más tiempo para completarse,
del equipo solo ejercen sus funciones debido a problemas estructurales, comunicación más lenta,
según sea necesario, manteniendo la la falta de participación directa del proyecto y prioridades
máxima relación con su grupo funcional. que compiten entre los departamentos funcionales.
4. Los proyectos pueden suboptimizarse debido a la variación
de intereses o compromiso, a través de fronteras funcionales.

ser un problema, sobre todo cuando se aplican en entornos en los que los puntos fuertes de esta estructura no
estén bien adaptados. Como indica la discusión anterior, aunque hay algunas formas en las que la estructura
funcional puede presentar ventajas para la gerencia de proyectos, en general, es quizás la forma de estructura
más pobre cuando se trata de obtener el máximo rendimiento de las tareas de gerencia de proyectos.20

Organizaciones basadas en proyectos


Organizaciones basadas en proyectos son aquellas creadas con un enfoque exclusivo destinado a la ejecución
de proyectos. Las empresas de construcción, grandes fabricantes como Boeing o Airbus, empresas farmacéu-
ticas y muchas organizaciones de investigación y desarrollo de software y de consultoría están estructuradas
como organizaciones basadas en proyectos puras. Dentro de una organización basada en proyectos, cada
proyecto es una unidad de negocio independiente con un equipo dedicado al proyecto. La empresa asigna
los recursos de grupos funcionales directamente al proyecto, durante el tiempo que sea necesario; además, el
gerente del proyecto tiene el control exclusivo de los recursos que utiliza la unidad. El papel principal de los
directores de los departamentos funcionales es coordinar con los gerentes de proyectos y asegurarse de que
haya suficientes recursos disponibles, como ellos necesiten.
La figura 2.7 ilustra una forma simple de estructura basada en proyectos pura. Los proyectos Alfa y
Beta están conformados y son atendidos por miembros del equipo de proyectos de los grupos funcionales

Junta directiva

Director ejecutivo

Vice presidente Vice presidente Vice presidente Vice presidente Vice presidente
de proyectos de marketing de producción de finanzas de investigación

Proyecto
Alfa

Proyecto
Beta

FIGURA 2.7  Ejemplo de una estructura organizacional basada en proyectos


2.4  Formas de estructura organizacional 51

de la empresa. El gerente del proyecto es el líder y todo el personal debe reportarle a él. Las decisiones de
personal y la duración de la tenencia de los empleados en el proyecto se dejan a la discreción del gerente
del proyecto, quien es el punto principal de autoridad en el proyecto. Como sugiere la figura, hay varias
ventajas al utilizar una estructura basada en proyectos pura:
• Primera, el gerente del proyecto no desempeña un papel secundario en esta estructura. Todas las deci-
siones y la autoridad permanecen bajo su control.
• Segunda, la estructura funcional y su potencial para que se presente el siloing o problemas de comu-
nicación se anulan. Como resultado, se mejora la comunicación a través de la organización y dentro
del equipo de proyecto. Debido a que la autoridad recae en el gerente del proyecto y el en equipo del
proyecto, la toma de decisiones se acelera. Como los grupos funcionales no son consultados ni se les
permite vetar las decisiones del equipo del proyecto, las decisiones del proyecto pueden ocurrir rápida-
mente, sin tanta demora.
• Tercera, este tipo de organización promueve la experiencia de un puesto de trabajo para los profesio-
nales en gerencia de proyectos. Debido a que el enfoque de las operaciones de la organización se basa
en proyectos, todos en la organización entienden y operan con el mismo enfoque, asegurando que la
organización mantenga recursos de gerencia de proyectos altamente competentes.
• Por último, una estructura de proyectos pura estimula la flexibilidad y la respuesta rápida a las opor-
tunidades ambientales. Los proyectos se crean, gestionan y se disuelven de forma rutinaria, por tanto,
la capacidad de generar nuevos equipos de proyecto, según sea necesario, es común y la formación del
equipo puede llevarse a cabo rápidamente.

Aunque hay una serie de ventajas en la creación dedicada a los equipos de proyectos que utilizan una
estructura de proyecto (véase el cuadro 2.3), este diseño tiene algunas desventajas que deben considerarse:

• Primera, el proceso de creación y mantenimiento de una serie de equipos de trabajo autónomos puede
ser costoso. Los diferentes grupos funcionales, en vez de controlar sus recursos, deben proveerlos con
base en tiempo completo los diferentes proyectos que se están llevando a cabo en cualquier punto. Esto
puede forzar la organización de proyectos a contratar a más especialistas (por ejemplo, ingenieros)
para el proyecto, con la consiguiente pérdida de economías de escala.
• Segunda, el potencial por el uso ineficiente de recursos es una desventaja clave de la organización
basada en proyectos pura. El personal organizacional puede fluctuar hacia arriba y hacia abajo tanto
como el número de proyectos, aumente o disminuya, en la empresa. Por tanto, es posible pasar de
un estado en el que muchos de los proyectos están en ejecución y los recursos de la organización se
emplean plenamente a uno en el que solo unos pocos proyectos están en camino, con muchos recursos
subutilizados. En resumen, las necesidades de fuerza laboral en toda la organización pueden aumentar
o disminuir rápidamente, lo cual genera graves problemas de personal.
• Tercera, es difícil mantener un suministro de capital técnico o intelectual, una de las ventajas de la estructura
funcional. Dado que los recursos no suelen residir dentro de la estructura funcional por mucho tiempo, es
común que pasen de un proyecto a otro, e impidan el desarrollo de una base conjunta de conocimientos.

CUADRO 2.3  Fortalezas y debilidades de las estructuras basadas en proyectos

Fortalezas para la gerencia de proyectos Debilidades para la gerencia de proyectos


1.  Asigna autoridad únicamente al jefe de proyecto. 1. La creación y el mantenimiento de los equipos
pueden ser costosos.
2. Conduce a una mejor comunicación en toda la 2. Potencial de los miembros del equipo del pro-
organización y entre los grupos funcionales. yecto para desarrollar la lealtad al proyecto y no a
la organización en general.
3.  Promueve una eficaz y rápida toma de decisiones. 3. Difícil de mantener un suministro combinado de
capital intelectual.
4. Promueve la creación de cuadros de expertos en 4. Preocupación entre los miembros del equipo del pro-
gerencia de proyectos. yecto sobre su futuro una vez finalice este.
5. Alienta la respuesta rápida a las oportunidades
del mercado.
52 Capítulo 2  •  El contexto organizacional. Estrategia, estructura y cultura

Por ejemplo, muchas organizaciones basadas en proyectos contratan empleados técnicamente competentes
para diversas tareas del proyecto. Estos empleados pueden realizar su trabajo y una vez finalizado, su con-
trato se termina y dejan la organización, llevándose su experiencia con ellos. Así, la experiencia no reside
dentro de la organización, sino diferencialmente en los miembros funcionales asignados a los proyectos.
Por tanto, algunos miembros del equipo pueden ser altamente competentes, mientras que otros no están
suficientemente capacitados ni entrenados.
• La cuarta desventaja de la estructura basadas en proyectos pura, tiene que ver con las preocupaciones legíti-
mas de los miembros del equipo del proyecto, ya que anticipan la terminación del proyecto, preguntándose:
¿cuál será el futuro una vez se haya finalizado su proyecto? Como se señaló, el personal puede ser inconsis-
tente, y a menudo los miembros del equipo del proyecto terminan un proyecto para descubrir que no son
necesarios para las nuevas asignaciones. En las organizaciones basadas en proyectos, los especialistas no
tienen algo así como un “hogar” permanente, que tendrían en una organización funcional, por lo que sus
preocupaciones están justificadas. De manera similar, en las organizaciones basadas en proyectos puras, es
común para los miembros del equipo identificarse con el proyecto como su única fuente de lealtad, su énfa-
sis se basa en el proyecto y sus intereses no residen en la organización más grande, sino dentro de su propio
proyecto. Cuando se termina un proyecto, pueden comenzar a buscar nuevos retos, e incluso pueden dejar
la empresa para recurrir a nuevas asignaciones.

Organizaciones matriciales
Uno de los más innovadores diseños organizacionales surgido en los últimos 30 años ha sido la estructura
matricial. La organización matricial, una combinación de estructura funcional y basada en proyectos, busca
un equilibrio entre estas dos. Este equilibrio se logra enfatizando la función y el proyecto al mismo tiempo. En
términos prácticos, la estructura matricial crea una jerarquía dual en la que hay un equilibrio de autoridad entre
el énfasis basado en proyectos y la departamentalización funcional de la empresa. La figura 2.8 ilustra cómo se
conforma una organización matricial. Téngase en cuenta que el vice presidente de proyectos ocupa una relación
informativa de carácter único en donde la posición no es formalmente parte de la estructura del departamento
funcional de la organización. El vice presidente jefe de la división de proyectos ocupa una parte de la jerarquía
dual, una posición compartida con el director ejecutivo y los jefes de los departamentos funcionales.
La figura 2.8 también ilustra cómo se conforman los equipos de proyecto en la empresa. El vice presidente
de proyectos controla las actividades de los gerentes de proyectoss bajo su autoridad. Ellos, sin embargo, deben
trabajar en estrecha colaboración con los departamentos funcionales para dotar de personal a sus equipos de
proyectos a través de préstamos. Mientras en las organizaciones funcionales el personal del equipo del proyecto
sigue estando, casi exclusivamente bajo el control de los departamentos funcionales y hasta cierto punto actúan

Junta directiva

Director ejecutivo

Vice presidente Vice presidente Vice presidente Vice presidente Vice presidente
de proyectos de marketing de producción de finanzas de investigación

Proyecto
2 recursos 1.5 recursos 1 recurso 3 recursos
Alfa

Proyecto
1 recurso 2 recursos 2 recursos 2.5 recursos
Beta

FIGURA 2.8  Ejemplo de estructura organizacional matricial


2.4  Formas de estructura organizacional 53

bajo las órdenes de su jefe funcional, en la estructura organizacional matricial este personal se comparte entre
ambos, sus departamentos y el proyecto al cual están asignados. Ellos permanecen bajo la autoridad del gerente
del proyecto y del supervisor del departamento funcional. Nótese, por ejemplo, que el gerente para el Proyecto
Alfa negocia el uso de dos recursos (personal) de la vice presidencia de marketing, 1.5 recursos de producción,
y así sucesivamente. Cada gerente de proyecto es responsable de trabajar con los gerentes funcionales para
determinar las necesidades óptimas de personal, cuántas personas se requieren y cuándo estarán disponibles
para realizar las actividades del proyecto. Preguntas como “¿Qué tareas deben llevarse a cabo en este proyecto?”
se responden mejor por el gerente del proyecto. Sin embargo, otros cuestionamientos igualmente importantes,
como “¿Quién va a realizar las tareas?” y “¿Cuánto tiempo deben tomar las tareas?” son asuntos que deben
negociarse en forma conjunta entre el gerente del proyecto y el jefe del departamento funcional.
Vale la pena distinguir las dos formas comunes de la estructura matricial: la matriz débil (a veces lla-
mada la matriz funcional) y la matriz fuerte (a veces referida como una matriz de proyectos). En una matriz
débil, los departamentos funcionales mantienen el control sobre sus recursos y son responsables de la ges-
tión de sus componentes del proyecto. El papel del gerente de proyecto es coordinar las actividades de los
departamentos funcionales, por lo general como un administrador. De ella se espera preparar cronogramas,
actualizar el estado del proyecto y servir de enlace entre los departamentos con sus diferentes entregables del
proyecto, pero no tiene autoridad directa para el control de los recursos o tomar decisiones importantes por
sí misma. En la matriz fuerte, el equilibrio de poder se desplaza a favor del gerente del proyecto. Ella ahora
controla la mayor parte de las actividades y funciones, incluidas la asignación y el control de los recursos
del proyecto y tiene la autoridad para la toma de decisiones. Aunque los gerentes funcionales tienen alguna
injerencia en la asignación de personal de sus departamentos, su papel es principalmente de consulta. La
matriz fuerte es probablemente lo más cercano a una “organización de proyectos”, mentalidad que se puede
conseguir mientras se trabaja en un entorno matricial.
La creación de una estructura organizativa con dos jefes puede parecer extraña, pero hay algunas ven-
tajas importantes de este enfoque, siempre que se cumplan ciertas condiciones. Las estructuras matriciales
son útiles en circunstancias en las que:21
1. Existe una presión para compartir los escasos recursos a través de las oportunidades del producto o del
proyecto.  Cuando una organización tiene recursos humanos escasos y una serie de oportunidades de pro-
yectos, se enfrenta con reto de la utilización de sus recursos humanos y materiales tan eficientemente como
sea posible para apoyar el número máximo de proyectos. Una estructura matricial proporciona un entorno
en el que la empresa puede enfatizar el uso eficiente de los recursos para el número máximo de proyectos.
2. Hay una necesidad de enfatizar en dos o más tipos diferentes de resultados.  Por ejemplo, la firma
puede necesitar promover su competencia técnica (utilizando una estructura funcional), mientras con-
tinúan creando una serie de nuevos productos (que requieren una estructura de proyecto). Con esta
doble presión para el funcionamiento, hay un equilibrio natural en una organización matricial entre la
importancia funcional de la competencia y eficiencia técnica y el proyecto enfocado en el rápido desa-
rrollo de nuevos productos.
3. El entorno de la organización es compleja y dinámica.   Cuando las empresas se enfrentan con el
doble reto de la complejidad y las presiones ambientales cambian rápidamente, la estructura matricial
promueve el intercambio de información y la coordinación a través de fronteras funcionales.
En la estructura matricial, el objetivo es crear un enfoque simultáneo en razón de la necesidad de
responder rápidamente a las oportunidades externas y a las eficiencias de funcionamiento interno. Con el
fin de lograr este doble enfoque, la misma autoridad debe residir en el proyecto y en los grupos funcionales.
Una ventaja de la estructura matricial para la gerencia de proyectos es poner su autoridad paralela a la de los
departamentos funcionales. Esta ventaja se destaca y mejora la condición de gerente del proyecto; en esta
estructura se espera que se mantenga al mismo nivel de poder y control sobre los recursos que los jefes de
departamento. Otra ventaja es que la matriz está diseñada específicamente para fomentar la estrecha coor-
dinación entre los departamentos con énfasis en proyectos de producción, de manera rápida y eficiente al
compartir los recursos entre los proyectos a medida que se necesitan. A diferencia de la estructura funcio-
nal, en el que los proyectos son, en efecto, estratificados sobre una estructura que no necesariamente apoya
sus procesos, la estructura matricial equilibra las demandas individuales de respuesta externa y la eficiencia
interna, y crea un entorno en el que los proyectos pueden llevarse a cabo de forma expedita. Finalmente,
dado que los recursos son compartidos y “móviles”, entre varios proyectos, hay una mayor probabilidad de
que la experiencia no se atesorará o centrará en un conjunto limitado de personal, como ocurre en la organi-
zación basada en proyectos,si no que se difunde más ampliamente a través de la empresa.
54 Capítulo 2  •  El contexto organizacional. Estrategia, estructura y cultura

Una de las desventajas de la doble jerarquía de la estructura matricial es el efecto potencialmente nega-
tivo que la creación de múltiples puntos de la autoridad tiene en las operaciones. Cuando dos partes de la
organización comparten autoridad, los trabajadores atrapados entre ellas pueden experimentar una gran
frustración, pues reciben mensajes contradictorios o conflictivos entre el gerente del equipo de proyecto y el
jefe de su departamento funcional. Supóngase que el vice presidente de proyectos señaló la necesidad de que
los trabajadores concentren sus esfuerzos en un proyecto crítico con una fecha límite del 1 de mayo. Si, al
mismo tiempo, el jefe de finanzas le dijera a su personal que con la temporada inminente de impuestos, que
debían hacer caso omiso de los proyectos mientras finaliza el trabajo relacionado con impuestos, ¿que podría
pasar? Desde la perspectiva de los miembros del equipo, esta jerarquía dual puede ser muy frustrante. Los
trabajadores diariamente experimentan una sensación de estar siendo empujados en múltiples direcciones,
ya que reciben instrucciones contradictorias de sus jefes tanto en los proyectos como en sus departamentos:
—el trabajo ordinario a menudo se convierte en un acto de equilibrio basado en las demandas que compiten
por su tiempo.
Otra desventaja es la cantidad de tiempo y energía requerida por los gerentes de proyectoss para reu-
niones, negociaciones y otras funciones coordinadoras para obtener decisiones tomadas en varios grupos, a
menudo con diferentes agendas. El cuadro 2.4 resume las fortalezas y debilidades de la estructura matricial.
Las estructuras matriciales, aunque parecen una buena solución para la gerencia de proyectos, requie-
ren una gran cantidad de tiempo para coordinar el uso de los recursos humanos. Muchos gerentes de pro-
yectos comentan que como parte de la matriz, dedican gran parte de su tiempo a reuniones, para resolver o
negociar compromisos de recursos y para encontrar maneras de compartir el poder con los jefes de departa-
mento. La estructura matricial ofrece algunos beneficios e inconvenientes desde la perspectiva de la gerencia
de proyectos. Coloca la gerencia de proyectos en pie de igualdad con la eficiencia funcional y promueve la
coordinación entre funciones. Sin embargo, al mismo tiempo, la jerarquía dual genera algunos desafíos sig-
nificativos en el comportamiento, dado que la autoridad y el control están en un constante estado de cambio,
dentro de la organización.22 Una queja común de los gerentes de proyectoss que operan en organizaciones
matriciales es que una gran cantidad de su tiempo está dedicado a “hacer política” y en sesiones de negocia-
ción con los gerentes funcionales para obtener los recursos y la ayuda que necesitan. En una matriz, las habi-
lidades de negociación, experiencia política y redes se convierten en herramientas vitales para los gerentes de
proyectoss que quieren tener éxito.

Moverse hacia una organización basada en proyectos pesos pesados


La expresión organización basada en proyectos pesos pesados se refiere a la creencia de que a veces las
organizaciones pueden obtener enormes beneficios de la creación de una estructura totalmente dedicada
a proyectos.23 Este concepto se basa en la idea de que las organizaciones basadas en proyectos exitosas no
ocurren por casualidad o suerte. Se necesitan pasos medidos en el diseño y la filosofía de funcionamiento
para llegar a la cima y permanecer allí. Tomando su formulación del modelo de “Skunkworks”, el nombre
de los famosos programas de Lockheed Corporation, los equipos de proyectos autónomos representan el
reconocimiento final por la empresa de la prioridad del trabajo basado en proyectos. En estas organiza-
ciones, al gerente del proyecto se le da plena autoridad, estatus y la responsabilidad de asegurar el éxito
del proyecto. Los departamentos funcionales se subordinan totalmente a los proyectos, y a los equipos de
proyecto se les concede una base de recursos independiente con qué llevar a cabo sus tareas.

CUADRO 2.4  Fortalezas y debilidades de la estructura matricial en la gerencia de proyectos

Fortalezas para la gerencia de proyectos Debilidades para la gerencia de proyectos


1. Adecuado para entornos dinámicos. 1. Jerarquías duales significa dos jefes.
2. Pone de relieve la doble importancia de la geren- 2. Requiere mucho tiempo en negociar el reparto de los
cia de proyectos y la eficiencia funcional. recursos entre los proyectos críticos y departamentos.
3. Promueve la coordinación entre las unidades 3. Puede ser frustrante para los trabajadores atra-
funcionales. pados entre las competencias del proyecto y las
demandas funcionales.
4. Maximiza los escasos recursos entre los proyectos
que compiten y las responsabilidades funcionales.
2.4  Formas de estructura organizacional 55

Con el fin de alcanzar la flexibilidad y capacidad de respuesta que la organización basada en proyectos pesos
pesados puede ofrecer, vale la pena recordar algunos puntos claves. En primer lugar, nadie va directamente a la
fase de equipo autónomo en lo que respecta a proyectos en ejecución. Esta forma de organización basada en pro-
yectos representa la última etapa de transición en un cambio planeado de manera sistemática en el pensamiento
empresarial. En cambio, los directivos se mueven poco a poco a este paso a través de la toma de decisiones cons-
cientes acerca de cómo van a mejorar la forma en que se ejecutan los proyectos. Empresas de proyectos exitosos
trabajan para ampliar la autoridad del gerente del proyecto, a menudo frente a la fuerte resistencia de los jefes de
departamentos funcionales a quienes les gusta la forma de equilibrio que actualmente existe. Una parte del proceso
de redirigir el equilibrio de poder consiste en darles a los gerentes de proyectoss alto estatus, autoridad para llevar
a cabo las evaluaciones de desempeño de los miembros del equipo, autoridad sobre los recursos del proyecto y
enlaces directos con los clientes. Los gerentes de proyectos que están constantemente obligados a depender de la
buena voluntad de los gerentes funcionales para el personal de su equipo, coordinación y recursos financieros y de
otro tipo, operan con las manos atadas a la espalda.
Segundo, las organizaciones basadas en proyectos pesos pesados han reajustado sus prioridades lejos del
mantenimiento funcional al oportunismo de mercado, un reajuste que puede ocurrir solo cuando los recursos
necesarios para responder rápidamente a las oportunidades de mercado reposan en el equipo del proyecto, en
lugar de ser controlados por las burocracias de nivel superior dentro de una empresa. Por último, como se observa
a lo largo de este libro, el cambio de enfoque de muchas empresas hacia el trabajo basado en proyectos afecta pro-
fundamente la manera en que la organización basada en proyectos, el gerente y el equipo operan. El nuevo enfo-
que en el cliente externo se convierte en la fuerza motriz para las operaciones, no simplemente una de las varias
demandas que el equipo del proyecto deben satisfacer, lo mejor que puedan.
En última instancia, la decisión de que la estructura organizativa es adecuada para utilizarse puede
simplemente reducirse a una conveniencia; aunque puede, de hecho, ser conveniente llevar a cabo proyec-
tos dentro de una estructura que ofrece la máxima flexibilidad y autoridad para el gerente del proyecto (la
estructura de proyectos pura), lo cierto es que para muchos gerentes de proyectoss será imposible influir
significativamente en las decisiones para alterar la estructura general de la organización en apoyo a su pro-
yecto. Como resultado de ello, tal vez la pregunta más apropiada que se debe hacer es la siguiente: ¿qué temas
debería tener en cuenta, dada la estructura de la organización en la que se realizará la gerencia de proyectos?
La discusión anterior de este capítulo ha desarrollado este enfoque como asunto principal. Dada la naturaleza
de la estructura dentro de la cual deben operarse y gestionarse nuestros proyectos, ¿cuáles son las fortalezas
y debilidades en lo referente a nuestra capacidad para hacer nuestro trabajo de la mejor manera posible? Al
formular una respuesta reflexiva a esta pregunta, estaremos quizás mejor posicionados para comprender y
adaptarnos con mayor eficacia a la búsqueda de la relación entre la estructura y la gerencia de proyectos
exitosos en nuestra organización.

RECUADRO 2.1

INVESTIGACIÓN DE GERENCIA DE PROYECTOS EN SÍNTESIS


El efecto de la estructura organizacional en los resultados de los proyectos
Es natural suponer que los proyectos se ejecuten más fluidamente en algunos tipos de estructura organizacional que
en otros. Cada vez más, la evidencia científica sugiere que, dependiendo del tipo de proyecto que esté en marcha,
algunas formas estructurales, de hecho, ofrecen mayores ventajas en promover la exitosa terminación del proyecto,
que otras. En el trabajo de Gobeli y Larson, por ejemplo, es importante resaltar el hecho de que el tipo de estructura
la empresa, cuando ejecuta proyectos, tendrá un efecto beneficioso o perjudicial sobre la viabilidad de los proyectos.
Larson y Gobeli compararon proyectos que habían sido gerenciados en una variedad de tipos estructurales,
incluidos funcional, matricial y basado en proyecto puro. Ellos diferencian tres subgrupos para la estructura matri-
cial, etiquetadas como matriz funcional, matriz equilibrada y matriz de proyecto, basados en su percepción de si la
estructura matricial de la empresa se inclinó más fuertemente hacia un enfoque funcional, un estilo uniformemente
equilibrado, o más favorablemente hacia proyectos. Después de recoger los datos de una muestra de más de 1,600
gerentes de proyectos, se identificaron aquellos que estaban ejecutando proyectos en cada uno de los cinco tipos
de organización y les pidió que evaluaran la efectividad de esa estructura en particular en la promoción o la inhibi-
ción de las prácticas de gerencia de proyectos efectivas. Sus resultados se muestran en la figura 2.9, destacando el
hecho de que, en general, las organizaciones de proyectos hacen la promoción de un ambiente más favorable para
la gerencia exitosa de proyectos.
56 Capítulo 2  •  El contexto organizacional. Estrategia, estructura y cultura

Curiosamente, cuando Gobeli y Larson filtraron su muestra a proyectos de desarrollo de nuevos produc-
tos y los relacionados con la construcción, sus resultados fueron muy similares, con la excepción de que los
proyectos de construcción fueron marginalmente más efectivos en las organizaciones matriciales. Esto sugiere
que la estructura desempeña un papel importante en la creación de proyectos exitosos.24

Muy
eficaz
Desarrollo de nuevos productos
Construcción

Eficaz

Ineficaz

Muy
ineficaz

Organización Matriz Matriz Matriz basada Organización basada


funcional funcional balanceada en proyectos en proyectos
FIGURA 2.9  Percepciones de gerentes sobre la eficacia de las diversas estructuras en el éxito del proyecto
Fuente: D. H. Gobeli and E. W. Larson. (1987). “Relative Effectiveness of Different Project Management
Structures,” Project Management Journal, 18(2): 81–85, figura en la página 83. Derechos de autor y todos
los derechos reservados. El material de esta publicación ha sido reproducido con permiso del PMI.

2.5  OFICINAS DE GERENCIA DE PROYECTOS


Una oficina de gerencia de proyectos (Project Management Office: PMO) se define como una unidad cen-
tralizada o departamento dentro de una organización que supervisa y mejora la gerencia de los proyectos.25
Esta se ve como un centro de excelencia en la gerencia de proyectos en muchas organizaciones, y existe como
una entidad o subunidad orgánica separada que ayuda al gerente del proyecto en el logro de los objetivos del
proyecto, pues aporta su experiencia directa en tareas vitales de gerencia de proyectos, como programación,
asignación de recursos, seguimiento y control. Las PMO se desarrollaron originalmente en reconocimiento a
los pobres antecedentes que muchas organizaciones han demostrado en la gerencia de sus proyectos. Citamos
como ejemplo en el capítulo 1 algunas estadísticas alarmantes sobre las tasas de fracaso de los proyectos de
IT, lo que indica que la mayoría de estos proyectos son propensos a fallar.
Las PMO fueron creadas en reconocimiento del hecho de que un centro de recursos para la gerencia de
proyectos dentro de una empresa puede ofrecer enormes ventajas. En primer lugar, como ya se señaló, los gerentes
de proyectoss están llamados a participar en una amplia gama de funciones, incluidas desde la atención a la parte
humana de la gerencia de proyectos hasta el manejo de importantes detalles técnicos. En muchos casos, estas perso-
nas pueden no tener el tiempo o la capacidad para manejar todos los procesos de información, la programación de
actividades, la asignación de recursos, el seguimiento y control técnico y demás. El uso de una PMO como un centro
de recursos para transferir parte de la carga de esas actividades desde el gestor del proyecto al personal de apoyo
proporciona esta ayuda. En segundo lugar, si bien la gerencia de proyectos se está convirtiendo en una profesión en
sí misma, todavía hay una gran brecha entre el conocimiento y las expectativas puestas en los gerentes de proyectoss
y sus equipos. En pocas palabras, es posible que no se cuente con los conocimientos o habilidades para el manejo de
una serie de actividades de apoyo al proyecto, como la redistribución de recursos o de información. Tener profesio-
nales de gerencia de proyectos capacitados disponibles a través de una PMO crea un efecto de “cámara de compen-
sación” que les permite a los equipos de proyecto aprovechar esta experiencia cuando lo necesiten.
2.5  Oficinas de gerencia de proyectos 57

'LUHFWRUGH
RSHUDFLRQHV

8QLGDGGH $SR\R
QHJRFLR HPSUHVDULDO

32 Nivel 3
Ventas Entrega Apoyo
PO Nivel 2

Proyecto A
PO

Proyecto B
PO Nivel 1

Proyecto C
PO

FIGURA 2.10  Niveles alternativos de oficinas de proyectos


Fuente: W. Casey and W. Peck. (2001). “Choosing the Right PMO Setup,” PMNetwork,
15(2): 40–47, figura en la página 44. Derechos de autor y todos los derechos reserva-
dos. El material de esta publicación ha sido reproducido con permiso del PMI.

Otro de los beneficios de la PMO es servir como un depósito central de todas las lecciones aprendidas, la
documentación del proyecto y el registro pertinente para mantener los proyectos en curso, así como para los pro-
yectos anteriores. Esta función provee a todos los gerentes de proyectos de una central de acceso a los registros de
proyectos anteriores y materiales de lecciones aprendidas, en lugar de tener que participar en una búsqueda desor-
denada de estos documentos en toda la organización. El cuarto beneficio de la PMO es que sirve como centro de
excelencia dedicado a la gerencia de proyectos en la empresa. Como tal, se convierte en el foco de todas las mejoras
en los procesos de gerencia de proyectos que luego son difundidos a otras unidades organizativas. Así, la PMO
se convierte en el lugar en el que las nuevas mejoras de gerencia de proyectos se identifican, prueban, refinan y,
finalmente, pasan a lo largo del resto de la organización Cada gerente de proyectos puede utilizar la PMO como
un recurso, confiando en que se responsabilizarán de todas las innovaciones de la gerencia de proyectos.
Una PMO puede colocarse en cualquiera de las múltiples ubicaciones dentro de una empresa.26 Como
muestra la figura 2.10, la PMO puede situarse a nivel corporativo (nivel 3), donde cumple una función general de
apoyo a la empresa. Se puede ubicar en un nivel funcional más bajo (nivel 2), en el que responde a las necesidades
dentro de una unidad de negocio específica. Por último, la PMO puede descentralizarse del proyecto (nivel 1) en
el que ofrece soporte directo para cada proyecto. La clave para entender la función de la PMO es reconocer que
está diseñada para apoyar las actividades del gerente del proyecto y de su equipo y no para sustituirlo o asumir la
responsabilidad del proyecto. En estas circunstancias, la PMO puede tener mucha presión del gerente del pro-
yecto, al manejar las tareas de administración, dejándolo libre para centrarse en los aspectos de igual importancia
relacionados con el personal, como liderazgo, negociación, construcción de relaciones con los clientes, entre otros.
Aunque la figura 2.10 nos da una idea de dónde se puede ubicar la PMO dentro de la organización y,
por extensión, pistas de su papel de apoyo en función de cómo estén estructuradas, también es útil tener en
cuenta algunos de los modelos de PMO. Las PMO han sido descritas como operativos en una de tres formas
alternativas y propósitos de las empresas: (1) estación meteorológica, (2) torre de control y (3) fuente de
recursos.27 Cada uno de estos modelos tiene un papel alternativo en la PMO.
1. Estación meteorológica—Según el modelo de estación meteorológica, la PMO normalmente se utiliza solo
como un dispositivo de seguimiento y vigilancia. En este enfoque, el supuesto es que la alta gerencia a menudo
se siente nerviosa acerca de comprometer dinero a una amplia gama de proyectos, y desea una estación meteo-
rológica como un dispositivo de seguimiento, para mantener un ojo sobre el estado de los proyectos sin influir
58 Capítulo 2  •  El contexto organizacional. Estrategia, estructura y cultura

directamente sobre ellos o controlarlos. La estación meteorológica PMO está destinada a albergar a observa-
dores independientes que se centran casi exclusivamente en algunas cuestiones claves, como:
• ¿Cuál es nuestro progreso? ¿Cómo avanza el proyecto respecto al plan original? ¿Qué hitos hemos
logrado?
• ¿Cuánto hemos pagado por el proyecto hasta ahora? ¿Cómo se ven las proyecciones del valor ganado?
¿Hay señales de advertencias presupuestarias?
• ¿Cuál es el estado de los principales riesgos del proyecto? ¿Hemos actualizado nuestra planeación de
contingencia según sea necesario?
2. Torre de control—El modelo de torre de control trata la gerencia de proyectos como una habilidad para
los negocios a ser protegida y apoyada. Se centra en los métodos para la mejora continua de la gerencia
de proyectos mediante la identificación de lo que está funcionando, dónde se presentan desfases y cómo
resolver los problemas en curso. Lo más importante, a diferencia del modelo de estación meteoroló-
gica, es que supervisa las actividades de gerencia de proyectos solo para informar los resultados a la
alta gerencia; es un modelo que se pretende trabajar directamente con el gerente del proyecto y con su
equipo para apoyar sus actividades. Al hacerlo, realiza cuatro funciones:
• Establece las normas para la gerencia de proyectos—El modelo de la torre de control de la PMO
está diseñado para crear una metodología uniforme en todas las actividades de gerencia de proyec-
tos, incluidos la estimación de la duración, presupuestos, gerencia de riesgos, el desarrollo de su
alcance, y así sucesivamente.
• Consulta sobre la manera de seguir estas normas—Además de determinar las normas adecuadas
para los proyectos en ejecución, la PMO se instala para ayudar a los gerentes de proyectoss a cumplir
esas normas mediante la prestación de consultores internos o expertos en gerencia de proyectos, en
todo el ciclo de desarrollo cuando se necesite su experiencia.
• Hace cumplir las normas—A menos que haya algún proceso que le permita a la organización hacer
cumplir las normas de gerencia de proyectos que ha desarrollado y difundido, no se tomarán en
serio. La torre de control PMO tiene la autoridad para hacer cumplir las normas que ha estable-
cido, a través de premios por el excelente desempeño o sanciones por negarse a acatar los principios
estándares de gerencia de proyectos. Por ejemplo, la PMO para el Accident Fund Insurance Co. of
America tiene plena autoridad para detener los proyectos que estén violando las prácticas aceptadas
o dejan de agregar valor a la empresa.
• Mejora las normas—La PMO está siempre motivada a buscar la manera de mejorar el estado actual
de los procedimientos de gerencia de proyectos. Una vez que un nuevo nivel de rendimiento del pro-
yecto se ha creado, según una política de mejora continua, la PMO ya debería estar estudiando cómo
hacer mejor las buenas prácticas.
3. Fuente de recursos—El objetivo de la fuente recursos de la PMO es mantener y proporcionar un cuadro
de profesionales capacitados y calificados de proyectos cuando se necesiten. En esencia, se convierte en
una cámara de compensación para la continua mejora de las habilidades de los gerentes de proyectoss
de la empresa. A medida que la empresa inicia nuevos proyectos, los departamentos afectados acuden
al fondo de recursos de la PMO para los activos requeridos y así dotar al equipo del proyecto. La fuente
de recursos de la PMO es responsable del suministro de los gerentes de proyectoss y otros profesionales
cualificados a los proyectos de la compañía. Para que este modelo pueda aplicarse con éxito, es impor-
tante concederle al grupo de recursos un estatus suficientemente alto dentro de la organización para
que puedan negociar en pie de igualdad con otros altos directivos lo que necesitan los gerentes de pro-
yectoss para sus proyectos. Volviendo a la figura 2.10, el modelo de fuente de recursos parece funcionar
mejor cuando la PMO se ve como una estructura de soporte de nivel 3, dando a la cabeza de la PMO
el estatus para mantener el control del grupo de gerentes de proyectoss capacitados y la autoridad para
asignarlos como se considere apropiado.
El concepto de PMO está asimilándose rápidamente en un gran número de empresas. Sin embargo,
tiene algunos críticos. Por ejemplo, algunos de ellos sostienen que se trata de un error con las PMO “poner
todos los huevos en una sola canasta”, concentrando todos los profesionales del proyecto en un solo lugar.
Este argumento sugiere que en realidad la PMO inhibe la difusión natural de las habilidades de los proyec-
tos a través de las unidades organizacionales para mantenerlas en un lugar central. Otro escollo potencial es
que si filosofía de la PMO no se explica con cuidado, puede ser simplemente otro nivel de supervisión y la
burocracia dentro de la organización; en efecto, en lugar de liberar al equipo del proyecto mediante la rea-
lización de funciones de apoyo, pueden en realidad actuar como esposas del proyecto y generar un control
2.6  Cultura organizacional 59

administrativo adicional. Otro peligro potencial asociado con la implementación de las PMO es que pueden
convertirse en un cuello de botella para el flujo de las comunicaciones en toda la organización28, particular-
mente entre la organización principal y los clientes del proyecto.
Aunque algunas de las críticas de las PMO contienen un elemento de verdad, no se deben utilizar para evitar
la adopción de una oficina de proyectos en las circunstancias correctas. La PMO es, en esencia, el reconocimiento
de que el desarrollo de habilidades de gerencia de proyectos debe alentarse y reforzarse, de que muchas organi-
zaciones tienen una gran necesidad de prácticas normalizadas para los proyectos y de que una función central de
apoyo puede servir como una fuente importante para la mejora continua de las habilidades en proyectos. Visto
desde esta perspectiva, el concepto de PMO probablemente gane popularidad en los próximos años.

2.6  CULTURA ORGANIZACIONAL


La tercera variable contextual clave en cómo gestionar los proyectos es efectivamente la cultura organiza-
cional. Hasta ahora, hemos examinado la forma en que la estrategia de una empresa afecta su gerencia de
proyectos y cómo los proyectos y portafolios están totalmente ligados a la visión de una empresa y sirven
para poner en práctica las decisiones estratégicas. La estructura constituye la segunda pieza del rompecabe-
zas contextual y hemos demostrado cómo diversos diseños organizacionales pueden ayudar u obstaculizar el
proceso de gerencia de proyectos. Ahora pasamos a la tercera variable contextual: la cultura de la organiza-
ción y su efecto en la gerencia de proyectos.
Una de las características de las organizaciones es la manera en que cada una desarrolla su perspectiva,
sus políticas y procedimientos de operación, patrones de pensamiento, actitudes y normas de comporta-
miento. Estas características son a menudo como las huellas digitales, la firma o el ADN de una persona;
por tanto, no hay dos organizaciones, por muy similares en tamaño, productos, entorno operativo o ren-
tabilidad, que sean iguales. Cada uno ha desarrollado su propio método para adoctrinar a sus empleados,
responder a las amenazas y oportunidades ambientales y para apoyar o desalentar conductas operativas. En
otros contextos, por ejemplo la antropología, la cultura se percibe como el aprendizaje colectivo compartido
por un grupo y cómo este influye en el grupo y cómo este probablemente responda a diferentes situaciones.
Estas ideas están arraigadas en el concepto de cultura organizacional. Uno de los escritores originales sobre
cultura la define como “la solución a los problemas externos e internos que consistentemente ha trabajado
un grupo, por lo que se enseña a los nuevos miembros como la manera correcta de percibir, pensar y sentir
estos problemas”.29
Viaje por Europa y pronto se habrá sumergido en una variedad de culturas. Va a discernir las carac-
terísticas culturales únicas que distinguen nacionalidades, como Finlandia y Suecia. Las diferencias en el
lenguaje, el comportamiento social, la organización de la familia y las creencias religiosas demuestran clara-
mente las diferencias culturales. Incluso dentro de un país, las actitudes y los valores culturales varían dramá-
ticamente. Las normas, actitudes y comportamientos comunes de los italianos del norte y del sur dan lugar a
diferencias en el vestir, los patrones del habla e incluso en los tiempos de la cena. Uno de los elementos claves
en los cursos de negocios internacionales es identificar las diferencias culturales como los patrones únicos
de comportamiento; así, los viajeros de negocios o los que viven en otros países serán capaces de reconocer
normas “apropiadas” de conducta y actitudes culturales, a pesar de que estos patrones culturales puedan ser
muy diferentes de las del país de origen del viajero.
Para los miembros del equipo del proyecto que están llamados a trabajar en proyectos en el extranjero
o que están vinculados a través de internet y correo electrónico a otros miembros del equipo de proyecto en
diferentes países, el desarrollo de una apreciación por las diferencias culturales transfronterizas es funda-
mental. Los valores y las actitudes expresadas por estas diversas culturas son fuertes reguladores de la con-
ducta individual y definen nuestro sistema de creencias y la dedicación al trabajo, así como nuestra capacidad
para funcionar en equipos de proyectos interculturales.
Una investigación ha comenzado a explorar activamente el efecto que las culturas del lugar de trabajo
tienen sobre el desempeño de los proyectos y la forma en que los distintos miembros del equipo del proyecto
deciden si van o no a comprometerse con sus metas. Considérense dos ejemplos contrastantes en que el
autor ha sido testigo. En una empresa Fortune 500, los jefes de departamento funcional durante años han
respondido a todas las peticiones de recursos de los gerentes de proyectoss mediante la asignación de los
peores, los más nuevos, o de más bajo rendimiento personal para estos equipos. En efecto, los proyectos se
han tratado como vertederos de descontentos o ejecutantes pobres. En esta organización, los equipos de pro-
yecto se conocen comúnmente como “colonias de leprosos”. ¡Es fácil imaginar la respuesta de un miembro
de la firma, a la noticia de que ¡acaba de ser asignado a un nuevo proyecto! Por otra parte, he trabajado con
60 Capítulo 2  •  El contexto organizacional. Estrategia, estructura y cultura

una organización de IT, donde la regla no escrita es que todo el personal de los departamentos debe estar
disponible, como recurso especializado, cuando su ayuda es solicitada por un gerente de proyecto. La priori-
dad más alta en la empresa es la ejecución de proyectos y todas las demás actividades están subordinadas a la
consecución de esta expectativa. Es común, especialmente durante los periodos agitados, para los miembros
de IT trabajar más de 12 horas por día, asistiendo a más de 10 proyectos en cualquier momento. Un gerente
dijo: “Cuando estamos en la hora de la verdad, los títulos y descripciones de trabajo no significan nada. Si se
tiene que hacer, todos somos responsables—conjuntamente—para asegurarse de que se hace”.
Las diferencias en la gerencia de proyectos en las empresas ilustradas en estas historias son sorpren-
dentes, ya que la cultura permea el entorno de trabajo y el enfoque de ejecución de proyectos. Nuestra defi-
nición de cultura se puede aplicar directamente en ambos casos para referirse a las reglas no escritas de
comportamiento o normas que se utilizan para dar forma y guiar el comportamiento, que son compartidas
por un subconjunto de miembros de la organización y que se les enseña a todos los nuevos miembros de la
empresa. Esta definición tiene algunos elementos importantes que deben examinarse con más detalle:
• No escrita—Las normas culturales guían el comportamiento de cada miembro de la organización,
pero a menudo no están escritas. Así, puede existir una gran diferencia entre los eslóganes o carteles de
inspiración que se pegan en las paredes de la empresa y la cultura real, claramente entendida la cultura
establece normas de comportamiento y las hace cumplir a todos los nuevos miembros de la empresa.
Por ejemplo, Erie Insurance, anualmente elegida como una de las mejores empresas para trabajar, tiene
una cultura fuerte y de apoyo que enfatiza y recompensa la colaboración positiva entre grupos funcio-
nales. Aunque la política no está escrita, es ampliamente aceptada, comprendida por todos, y enseñada
a los nuevos miembros de la organización. Cuando los proyectos requieren la colaboración del perso-
nal de diferentes departamentos, se espera que el el apoyo este disponible.
• Normas de conducta—Las normas culturales guían el comportamiento mediante un lenguaje común que
nos permite comprender, definir y explicar los fenómenos, lo cual nos proporciona directrices acerca de la
mejor manera de reaccionar ante estos hechos. Estas reglas de conducta pueden ser poderosas y llevarse a
cabo habitualmente: de la misma manera, se aplican a la alta dirección como a los operarios en una planta. Sin
embargo, debido a que no están escritas, podemos aprenderlas de la manera difícil. Por ejemplo, si usted fue
recientemente contratado como ingeniero de proyectos y está trabajando considerablemente más lento o más
rápido que sus compañeros de trabajo, es probable que alguno de ellos le dé rápidamente una pista sobre un
nivel aceptable de velocidad que no haga que usted o cualquier otra persona quede mal al compararse.
• En poder de algún subconjunto de la organización—Las normas culturales pueden o no ser de toda la compa-
ñía. De hecho, es muy común encontrar actitudes culturales que difieren ampliamente dentro de una organi-
zación. Por ejemplo, los obreros pueden tener una actitud antagónica hacia la alta gerencia, los miembros del
departamento de finanzas pueden ver la función de marketing con hostilidad y viceversa, y así sucesivamente.
Estas “subculturas” reflejan el hecho de que una organización puede contener un número de diferentes culturas,
que operan en diferentes lugares o en diferentes niveles. Pitney-Bowes, por ejemplo, es un fabricante de sellos
de correo y otros equipos de oficina, su sede central refleja una imagen de estabilidad, orden y prestigio. Sin
embargo, una de sus divisiones, Pitney Bowes-Credit Corporation (PBCC), con sede en Shelton, Connecticut,
se ha hecho un nombre de sí misma mediante la adopción de una actitud a propósito de informalidad, aper-
tura y diversión. Su decoración, con lámparas de gas falsas, una cafetería francesa y cabinas de navegación por
internet, ha sido descrita como parecida a un “parque temático cubierto”. PBCC ha creado deliberadamente
una subcultura que refleja su propio enfoque de negocio, en lugar de adoptar la visión general de la empresa.30
Otro ejemplo es el enfoque del equipo de proyecto de Macintosh para la creación de una cultura distinta de
la de Apple, mientras desarrollaban este sistema revolucionario, ¡hasta el punto de ser alojados en diferentes
establecimientos del resto de la compañía y que enarbolan un pabellón pirata en el asta de la bandera!
• Enseñanza a todos los miembros nuevos—Las actitudes culturales, porque a menudo no están escritas, no
pueden enseñarse a los recién llegados de manera formal. Los nuevos miembros de la organización reco-
gen las conductas que observan a los demás. Sin embargo, en algunas organizaciones, todos los empleados
nuevos deben estar inmersos en un programa de adoctrinamiento oficial para asegurarse de que entienden
y aprecian la cultura de la organización. Los infantes de marina de Estados Unidos, por ejemplo, en el pro-
ceso de adoctrinamiento se sienten orgullosos de su formación como reclutas para desarrollar una actitud
colectiva de compromiso hacia el Cuerpo de Infantería de Marina. IBM realiza seriamente sus nuevos pro-
cedimientos de adoctrinamiento, gastando semanas en el entrenamiento de nuevos empleados en la filoso-
fía, actitudes de trabajo y cultura de IBM. General Electric (GE) también envía afuera a los nuevos para su
orientación, para ser “tatuados con la albóndiga”, como miembros de la empresa se refieren al logo de GE.
2.6  Cultura organizacional 61

¿Cómo se forman las culturas?


¿Cómo es posible ver dos organizaciones que fabrican productos similares, en un contexto de culturas muy
individualistas y diferentes? La cuestión de cómo se forman las culturas se pone particularmente intere-
sante. Jet Engine, la división de Motores de General Electric, y Rolls-Royce, comparten muchas caracterís-
ticas, incluidas las líneas de productos. Ambos producen motores de reacción para las industrias de aviones
comerciales y de defensa. Sin embargo, GE se enorgullece de su cultura competitiva, de alta presión que
premia la agresividad y el alto grado de compromiso, pero también tiene una alta tasa de “agotamiento” entre
los ingenieros y gerentes de nivel medio. Rolls-Royce, por el contrario, representa un ejemplo de una cultura
más paternalista que premia la lealtad y con larga permanencia en el empleo.
Investigadores han examinado algunas de las poderosas fuerzas que pueden influir en cómo surge la
cultura de una empresa. Entre los factores claves que afectan el desarrollo de una cultura están la tecnolo-
gía, el medio ambiente, la ubicación geográfica, los sistemas de recompensa, normas y procedimientos, los
miembros claves de la organización y los incidentes críticos.31

TECNOLOGÍA La tecnología de una organización se refiere a su proceso de conversión mediante el cual


se transforman insumos en productos terminados. Por ejemplo, la tecnología en muchas organizaciones de
proyectos es el proceso de desarrollo del proyecto en el que se ejecutan los proyectos para cubrir una nece-
sidad actual o anticipar una oportunidad futura. Los medios técnicos para la creación de proyectos pueden
ser muy complejos y automatizados o relativamente simples y directos. Además, los proyectos pueden estar
en la forma de productos o servicios. La investigación sugiere que el tipo de tecnología utilizada dentro de
una organización de proyectos puede influir en la cultura que promueve. Organizaciones de “alta tecnología”
representan un ejemplo de cómo una cultura acelerada, basada en la tecnología, puede penetrar a través de
una organización.

AMBIENTE  Las organizaciones operan bajo presiones ambientales distintas. El entorno de una empresa
puede ser complejo y cambiar rápidamente, o puede permanecer relativamente simple y estable. Algunas
empresas son globales, ya que su competencia es, literalmente, todo el mundo; otras empresas se centran en
la competencia regional. Independientemente de las circunstancias específicas, el medio ambiente de una
empresa afecta su cultura. Por ejemplo, las empresas con entornos sencillos y cambio lento pueden desarro-
llar culturas que refuerzan la asunción baja de riesgos, la estabilidad y la eficiencia. Las empresas en entornos
altamente complejos a menudo desarrollan culturas orientadas a promover una respuesta rápida, monitoreo
externo de oportunidades y amenazas y la asunción de riesgos. De esta manera, el entorno operativo de la
empresa afecta la formación de la cultura y los comportamientos que se consideran aceptables dentro de
ella. Por ejemplo, una pequeña empresa regional de construcción, especializada en el desarrollo de bienes
raíces comerciales, probablemente tenga problemas ambientales más estables comparada con Fluor-Daniel y
Bechtel, que compiten por una variedad de proyectos de construcción en todo el mundo.

LOCALIZACIÓN GEOGRÁFICA  Las diferentes regiones geográficas desarrollan sus propias costumbres y
actitudes culturales. Cuanto más al sur de Europa se viaja, más tarde se come la cena; por ejemplo, normal-
mente, en España, la cena puede comenzar después de las 9:00 p.m. Del mismo modo, en el mundo de los
negocios, las actitudes basadas en la cultura a menudo están coordinadas con las ubicaciones geográficas
de empresas o filiales. Hasta puede ocurrir que dentro de los países: Xerox Corporation, por ejemplo, tuvo
enormes dificultades para tratar de casarse con las culturas de su sede corporativa en Connecticut con la
mentalidad más informal y bien puesta sobre la tierra del personal de su Centro de Investigación de Palo
Alto (Palo Alto Research Center: PARC). Los proyectos de un sitio se hicieron muy diferentes de los llevados
a cabo en otro lugar. Es importante no exagerar el efecto que la geografía puede desempeñar, pero sin duda
puede resultar en desconexiones culturales, en particular en los casos en que las organizaciones cuentan con
una serie de ubicaciones dispersas, tanto dentro como fuera de su país de origen.

SISTEMA DE RECOMPENSAS  Los tipos de recompensas que una empresa ofrece a los empleados, recorren
un largo camino hacia la demostración de las creencias y acciones que su cúpula directiva realmente valora,
independientemente de lo que las políticas oficiales de la compañía podrían ser. Los sistemas de recompensa
apoyan la opinión de que, en efecto, una empresa obtiene lo que ha pagado. Una organización que defiende
públicamente la conciencia ambiental y el servicio al cliente, pero que promueve sistemáticamente a los
gerentes de proyectoss que violen estos principios, envía un mensaje claro acerca de sus verdaderos intereses.
62 Capítulo 2  •  El contexto organizacional. Estrategia, estructura y cultura

Como resultado, la cultura se forma rápidamente alrededor de obras que conducen a la contaminación, falta
de honradez u ofuscación. Uno solo tiene que mirar los últimos titulares de negocios respecto a delitos cor-
porativos en Enron, WorldCom o Adelphia Cable Company para ver cómo la cultura de las organizaciones
premiaban el tipo de comportamiento que finalmente condujo al fraude contable, la exposición pública y
millones de dólares en multas.

NORMAS Y PROCEDIMIENTOS   Uno de los métodos para influir en la cultura de gerencia de proyectos es la
creación de un reglamento o un sistema de procedimientos para los empleados, con el fin de aclarar los compor-
tamientos aceptables. La idea más allá de las normas y los procedimientos es señalar a los nuevos empleados, las
normas de comportamiento en toda la compañía. El problema obvio surge cuando las normas públicas o for-
males riñen con las reglas informales de comportamiento. En la sede de Texas Instruments en Dallas Texas, una
regla formal es que todo el personal de gestión trabaja una semana laboral estándar de 40 horas. Sin embargo,
la regla informal es que cada miembro de la empresa en realidad espera que el trabajo de la semana sea de 45
horas, como mínimo, o como un alto directivo le explicó a un nuevo empleado: “Aquí se trabaja nueve horas
cada día: ocho para usted y una para IT “. A pesar de la posibilidad de los desacuerdos entre las reglas forma-
les e informales, la mayoría de los programas en la creación de organizaciones de apoyo basadas en proyectos
argumentan que el primer paso hacia la mejora de los patrones de comportamiento es codificar formalmente las
expectativas para alterar las culturas disfuncionales de proyectos. Las normas y los procedimientos, entonces,
representan un buen punto de partida para el desarrollo de una fuerte cultura de proyectos.

MIEMBROS CLAVES DE LA ORGANIZACIÓN  Los miembros importantes de las organizaciones, incluido


su fundador, tienen un efecto enorme en la cultura que emerge dentro de la empresa. Cuando el fundador
es un empresario tradicional que promueve la libertad de expresión o la flexibilidad, esta actitud se arraiga
en la cultura de la organización de una manera poderosa. Los fundadores de Ben y Jerry Ice Cream, dos
orgullosos ex jipis, crearon una cultura corporativa que era única y expresaron su deseo por desarrollar una
alternativa “divertida” al capitalismo básico. Una cultura corporativa en la que los altos ejecutivos ostentan
rutinariamente las reglas o actúan en contra de las políticas establecidas, demuestra una cultura en la que hay
una regla para la gente de la dirección y otra para los demás.

INCIDENTES CRÍTICOS  Expresan la cultura, ya que demuestran para todos los trabajadores exactamente
lo que se necesita para tener éxito en una organización. En otras palabras, los incidentes críticos son una
expresión pública de cuáles son las normas que realmente funcionan, independientemente de lo que la
empresa propugna formalmente. Los incidentes críticos suelen adoptar la forma de historias relatadas a
otros, incluidos los nuevos empleados, ilustrando los tipos de acciones que se valoran. Se convierten en parte
de la tradición de la compañía, ya sea para bien o para mal. Recientemente, en un año, la General Electric’s
Transportation Systems acumuló pedidos de locomotoras. La compañía impulsó a sus instalaciones de pro-
ducción a trabajar horas extras para completar esta acumulación de trabajo. Así, se refirió un miembro del
sindicato: “Cuando ves que el vice presidente de la unidad aparece el sábado, se pone su traje de trabajo y
trabaja en la línea de aerosoles pintando locomotoras con el resto de los trabajadores, te das cuenta de lo
comprometida que esta la empresa para terminar a tiempo el pedido.“

Cultura organizacional y gerencia de proyectos


¿Cuáles son las implicaciones de la cultura organizacional en el proceso de gerencia de proyectos? La cultura
puede afectar a la gerencia de proyectos en al menos cuatro maneras. Primera, cómo se espera que los depar-
tamentos interactúen y se apoyen unos a otros en la búsqueda de las metas del proyecto. Segunda, la cultura
influye en el nivel de compromiso de los empleados con los objetivos del proyecto en conjunto con otros
con objetivos que potencialmente compiten. Tercera, la cultura influye en los procesos de planeación de
proyectos de la organización, como la forma en que se estima el trabajo o cómo se asignan los recursos a los
proyectos. Finalmente, la cultura afecta cómo los gerentes evalúan el desempeño de los equipos de proyectos.

• Interacción de los departamentos—Varios de los ejemplos citados en este capítulo se han centrado
en la importancia de desarrollar y mantener una relación sólida y de apoyo entre los departamentos
funcionales y los equipos de proyecto. En las organizaciones funcionales y matriciales, el poder reside
ya sea directamente en los jefes de departamento o se comparte con los gerentes de proyectoss. En cual-
quier caso, la forma en que estos jefes de departamento enfocan su voluntad de apoyar los proyectos
2.6  Cultura organizacional 63

desempeña un papel muy importante en el éxito o fracaso de las nuevas iniciativas de proyectos. No
sorprende que las culturas que favorecen la cooperación activa entre los grupos funcionales y nuevos
proyectos son más exitosas que aquellas que adoptan una relación desinteresada e incluso adversaria.
• Compromiso de los empleados con las metas—Los proyectos dependen del compromiso y la motivación del
personal asignado a sus actividades. Una cultura que promueve el compromiso de los empleados y, cuando
sea necesario, el sacrificio por horas extras de trabajo o en tareas múltiples es mucho más exitosa que una
cultura en la que las reglas no escritas parecen dar a entender que, siempre y cuando no sea atrapado, no hay
nada malo en simplemente continuar. AMEC Corporation, por ejemplo, toma muy en serio la formación
de sus empleados cuando se trata de inculcarles un compromiso con la seguridad. AMEC, una empresa de
construcción industrial multinacional con sede en Canadá, con ingresos anuales de más de 4,000 millones
de dólares y 20,000 empleados, y una de las más grandes en el mundo, toma su compromiso con los valores
fundamentales extremadamente en serio, inculcándoles a todos los empleados sus responsabilidades para
con los clientes, socios comerciales, la empresa y el entorno social más amplio. Desde el momento en que
nuevas personas entran en la organización, son conscientes de la necesidad de comprometerse con los prin-
cipios rectores de la conducta ética, la justicia, el compromiso con la calidad y la seguridad32.
• La planeación del proyecto—Vamos a explorar el proceso de estimación de duración de la actividad
en un capítulo posterior, sin embargo, por ahora es importante solo para señalar que la forma en que
los empleados deciden apoyar los procesos de planeación de proyectos es fundamental. Debido a que
la estimación de la actividad es a menudo un proceso impreciso, algunos miembros del equipo del
proyecto tienden a “acolchonar” sus estimaciones para darse el mayor tiempo posible. Estas personas
a menudo responden a una cultura que refuerza la idea de que es mejor abordar una pobre estimación
y planeación del proyecto, que retrasarse con los resultados finales. Por el contrario, cuando hay una
cultura de la confianza entre los miembros del equipo del proyecto, estamos más inclinados a hacer
evaluaciones honestas, sin temor de que si estamos mal, seremos castigados por nuestros errores.
• La evaluación del desempeño—Las culturas de apoyo animan a los miembros del equipo del proyecto
a tomar la iniciativa, incluso si esto significa tomar riesgos para aumentar el rendimiento. Cuando
una cultura envía la señal de que el objetivo de la empresa es la creación de productos innovadores,
refuerza una cultura de gerencia de proyectos agresiva, y potencialmente ofrece grandes beneficios (¡y
la pérdida ocasional significativa!). Como señalamos anteriormente, las organizaciones obtienen lo
que pagan. Si los sistemas de recompensa son positivos y refuerzan una mentalidad fuerte de proyec-
tos, van a cosechar un torbellino de oportunidades. Por otro lado, si se apoyan tácitamente la precau-
ción y jugar a lo seguro, los métodos de gerencia de proyectos reflejarán igualmente este principio.

Una cultura puede afectar poderosamente la forma en que los departamentos dentro de la organización
ven el proceso de gerencia de proyectos. La cultura también influye en la manera en que los empleados se com-
prometan con las metas de sus proyectos y no con otras, metas potencialmente en conflicto. A través de símbo-
los, historias y otros signos, las empresas señalan su compromiso con la gerencia de proyectos. Este mensaje no
se pierde en los miembros de los equipos de proyectos que siguen el ejemplo respecto al rendimiento esperado
por los supervisores y otros artefactos culturales. Símbolos visibles de una cultura que promueve la cooperación
entre funciones crearán empleados preparados y motivados para trabajar en armonía con otros grupos en pro
de las metas del proyecto. Del mismo modo, cuando un departamento de IT eleva algunos de sus miembros a la
condición de héroe porque rutinariamente realizan un esfuerzo adicional para manejar las quejas o problemas
de los usuarios del sistema, la compañía envía el mensaje de que todos están trabajando hacia las mismas metas
y que todos agregan valor a la las operaciones de la organización, independientemente de su origen funcional.
Para imaginar cómo la cultura puede influir en los procesos de planeación y seguimiento de proyectos,
supongamos que en su organización se evidencia que las personas involucradas en los proyectos retrasados
son severamente castigadas por el incumplimiento del cronograma. Usted y sus compañeros miembros del
equipo del proyecto aprenderían rápidamente que es fundamental evitar el extremo de prometer fechas de
terminación más temprano para las tareas. Es mucho más seguro que sobrestimar enormemente la cantidad
de tiempo necesario para completar una tarea con el fin de protegerse. La cultura organizacional, en este
caso, genera engaño. Del mismo modo, puede ser más seguro en algunas organizaciones de ocultar delibe-
radamente información, en casos en que un proyecto se ejecuta fuera de lo planeado o confundir a la alta
gerencia con estimaciones de los avances del proyecto, más optimistas y falsas. En esencia, la cuestión es la
siguiente: ¿la cultura corporativa fomenta la información auténtica y las interacciones verdaderas, o se evi-
dencia que el camino más seguro es protegerse primero a sí mismo, sin importar el efecto que este compor-
tamiento pueda tener en el éxito de un proyecto?
64 Capítulo 2  •  El contexto organizacional. Estrategia, estructura y cultura

¿Cuáles son algunos ejemplos de cultura organizacional que influyen en la manera en que los equipos
de proyecto en realidad funcionen y cómo se perciben los resultados? Una situación común es el fenómeno
conocido como escalada de compromiso. No es raro ver este proceso en acción en las organizaciones de pro-
yectos. La escalada de compromiso se produce cuando, a pesar de la evidencia que identifica un proyecto como
fallido, ya no necesario, o acosado por enormes dificultades técnicas o de otro tipo, las organizaciones siguen
apoyándolo a pesar de que un punto de vista objetivo sugeriría que debería darse por concluido.34 Aunque hay
una serie de razones para la escalada de compromiso con una decisión fallida, una razón importante es la falta
de voluntad de la organización a reconocer el fracaso o el trabajo de su cultura hacia el cegamiento del tomador
clave de decisiones sobre la necesidad de tomar medidas correctivas.
Lo contrario también es cierto: en muchas organizaciones, los proyectos se gestionan en un entorno
en el que la cultura apoya firmemente la cooperación multifuncional, asignan los recursos suficientes para
los gerentes de proyectoss, programan agresivamente y crean una atmósfera que hace posible el desarrollo
óptimo de proyectos. Es importante reconocer que la cultura de una organización puede ser un firme defen-
sor (así como un inhibidor) de la capacidad de la empresa para gestionar proyectos eficaces. Debido a este
efecto, la cultura organizacional debe gestionarse, evaluarse constantemente, y, en caso necesario, cambiarse
a formas que promuevan la gerencia de proyectos en lugar de desalentar su práctica eficiente.
El contexto en que gerenciamos nuestros proyectos es un factor determinante en la probabilidad de su
éxito o fracaso. Los tres factores contextuales críticos de la organización son la estrategia, la estructura y la
cultura. La estrategia conduce proyectos; los proyectos operacionalizan la estrategia. Los dos deben trabajar
juntos en armonía. La clave es mantener una clara vinculación entre la estrategia global y el portafolio de

PERFIL DE PROYECTO

Una cultura de la atención: Sanofi-Aventis y su compromiso con la asistencia médica mundial


Los residentes de los países en desarrollo se enfrentan con enormes desafíos económicos y sociales en sus vidas
cotidianas. Un problema persistente radica en su falta de acceso a los medicamentos y el tratamiento médico de las
enfermedades, muchas de las cuales son tratables con la pronta aplicación de las vacunas. De hecho, se estima que
80% de la población del mundo no tiene acceso a los medicamentos y, por tanto, sufre los efectos de una variedad
de enfermedades, como la malaria, la tuberculosis, la enfermedad del sueño y la epilepsia, entre otras. El reto para
las organizaciones en el mundo desarrollado es encontrar un compromiso y los medios necesarios para resolver
estos problemas.
Sanofil-Aventis, con sede en París, Francia, es una compañía líder en investigación farmacéutica con el com-
promiso de hacerles frente a los retos de la asistencia médica global. Un departamento dentro de su empresa,
llamado “Acceso a los medicamentos”, tiene el objetivo de proporcionar a los pacientes pobres medicamentos de
bajo costo para combatir sus enfermedades. Este equipo dentro de Sanofi tiene un foco central, orientarse a temas
médicos, cuyo e portafolio de productos de la compañía y el know how puedan marcar una diferencia. Como parte
de ese esfuerzo, se cubren tres áreas principales: la mejora de los medicamentos existentes, las políticas de fijación
de precios preferenciales para entregar medicamentos a un escenario de “no ganancias-no pérdidas” y un pro-
grama de información, educación y comunicación.
La cultura “Acceso a los medicamentos”, dentro Sanofi-Aventis, promueve una orientación a la acción diseñada
para buscar oportunidades donde puedan ayudar a otras organizaciones internacionales en estos emprendimientos.
Los problemas que enfrentan generalmente están relacionados con pobres infraestructuras de salud pública, la falta
de personal de salud, diagnósticos insuficientes y la falta de estructuras de distribución. En estas áreas, la industria
farmacéutica está a menudo limitada en su función, a menos que pueda crear alianzas “en el terreno” con otras
organizaciones. Una de estas alianzas ha sido formada entre “Acceso a los medicamentos” y el Instituto de OneWorld
Health, con el propósito de promover un proyecto global de la malaria. OneWorld Health es una organización sin
fines de lucro con el objetivo de llevar ayuda médica a los pobres en el planeta que no tienen acceso a otra ayuda.
Las dos organizaciones creen que la clave para que esta iniciativa de proyecto sea éxitosa es su relación de
trabajo. Kay Monroe, gerente de proyectos para el proyecto de la malaria de OneWorld Health, señala que cuando
se trata de encontrar los socios adecuados, no es simplemente una cuestión de elegir a las empresas con el mejor
portafolio de productos y con capacidades de producción. También se reduce a la adaptación a la cultura. “Al elegir
los socios, no se puede negar la parte blanda“, dice. “Es un placer trabajar con el equipo Sanofi-Aventis y eso es
grandioso. A veces no es fácil para la gente [quienes] son nuevos en este tipo de proyecto, manejar el estrés, pero
Sanofi-Aventis lo ha hecho suficientes veces y no se sienten frustrados.”33
Resumen 65

proyectos de la empresa, asegurando de alguna forma que exista un alineamiento entre todos los elemen-
tos claves: visión, objetivos, estrategias, metas y programas. Además, las empresas están reconociendo que
cuando adoptan una estructura soportada en proyectos, obtienen mejores resultados. Del mismo modo,
cuando el ambiente cultural de la organización favorece los enfoques de gerencia de proyectos, ellos esta-
rán mucho más propensos a tener éxito. Algunos de estos métodos de gerencia de proyectos consisten en
la voluntad de asumir riesgos, pensar creativamente, trabajar en estrecha colaboración con otros departa-
mentos funcionales, y así sucesivamente. Cada vez más estamos viendo organizaciones exitosas basadas en
proyectos que reconocen la simple verdad de que el contexto en el que están tratando de crear proyectos es
un elemento crítico para llevar sus proyectos a través del éxito comercial y técnico.

Resumen
1. Entender cómo la gerencia eficaz de los proyectos agencias gubernamentales y los organismos reguladores
contribuye a la consecución de los objetivos estraté- y clientes). Cada uno de estos interesados debe gestio-
gicos.  En este capítulo se vinculan los proyectos con narse de manera sistemática; el proceso se mueve desde
la estrategia corporativa. Los proyectos son los “blo- la identificación y evaluación de necesidades, la elección
ques básicos” de la estrategia, ya que sirven como las de la estrategia, la evaluación de rutina y el ajuste. La
herramientas más fundamentales mediante las cuales gestión de los interesados, en conjunto con la gestión
las empresas pueden poner en práctica los objetivos y estratégica, constituye el contexto en que los proyectos
las estrategias formuladas anteriormente. se evalúan primero y luego se gestionan.
2. Reconocer los tres componentes del modelo de estra-
tegia empresarial: formulación, implementación y 4. Reconocer las fortalezas y debilidades de tres formas
evaluación. El capítulo explora un modelo genérico de básicas de la estructura de la organización y sus impli-
la gestión estratégica empresarial, distinguiendo entre caciones para la gerencia de proyectos.  Se examina-
los tres componentes de la formulación, implementa- ron los puntos fuertes y débiles de los tres principales
ción y evaluación de las estrategias. Cada uno de estos tipos de estructuras organizacionales, como la funcional,
componentes incorpora un número de subdimensiones. basadas en proyectos y matricial. Se abordó la naturaleza
Por ejemplo, la formulación de la estrategia incluye las de cada uno de los tres tipos estructurales y su relación
siguientes etapas : con la gerencia de proyectos. La estructura funcional, el
tipo más común de forma de organización, es quizás el
• Desarrollar una visión y misión.
tipo menos eficaz para la gerencia de proyectos, debido
• Realizar un diagnóstico interno (evaluación de forta-
a una variedad de limitaciones. La estructura basada en
lezas y debilidades).
proyectos, en que la organización utiliza sus proyectos
• Desarrollar un diagnóstico externo (evaluación de
como la principal forma de agrupación, tiene varias ven-
oportunidades y amenazas).
tajas para la gerencia de proyectos, aunque también con
• Establecer objetivos a largo plazo.
algunas desventajas generales. Por último, la estructura
• Generar, evaluar y seleccionar estrategias.
matricial, la cual busca el equilibrio entre la autoridad
La implementación de la estrategia requiere la y las actividades entre los proyectos y las funciones
coordinación de los activos empresariales, tecnológi- mediante un sistema de doble jerarquía, demuestra su
cos, financieros y funcionales para reforzar y apoyar las propio conjunto de fortalezas y debilidades para la prác-
estrategias. Los proyectos sirven a menudo como los tica de gerencia de proyectos.
medios por los cuales la implementación de la estrategia 5. Entender cómo las empresas pueden cambiar su
se realiza en la práctica. Por último, la evaluación de la estructura en una “organización basada en proyec-
estrategia requiere la capacidad de medir los resultados y tos pesos pesados” facilita las prácticas eficaces de
proporcionar información a todas las partes interesadas. gerencia de proyectos.  Los movimientos dentro de
3. Ver la importancia de identificar los actores críti- muchas organizaciones con un fuerte enfoque en el
cos del proyecto y su gestión en el desarrollo del cliente, en sus operaciones de gerencia de proyectos,
proyecto.  El capítulo aborda una última pregunta han llevado a la creación de una organización basada
estratégica: la relación entre la empresa y sus interesa- en proyectos pesos pesados, en las que al gerente del
dos. Los interesados del proyecto pueden ser internos proyecto se le da un alto nivel de autoridad con el fin
a la empresa (alta gerencia, otros departamentos fun- de promover las metas del proyecto. Debido a que la
cionales, personal de apoyo, los clientes internos) o satisfacción del cliente es la meta de estas organizacio-
externos (proveedores, distribuidores, interventores, las nes, confían en sus gerentes de proyectos para trabajar
66 Capítulo 2  •  El contexto organizacional. Estrategia, estructura y cultura

hacia el éxito del proyecto en el marco de un mayor con- compartidos por los miembros de la organización, lo cual,
trol de los recursos y el contacto directo con los clientes. a su vez, afecta su compromiso con la gerencia y las prác-
6. Identificar las características de las tres formas de la ticas de proyectos. La cultura se define como las reglas de
oficina de gerencia de proyectos (PMO).   Las ofici- comportamiento no escritas, o las normas que se utilizan
nas de gerencia de proyectos (PMO) son unidades cen- para dar forma y guiar la conducta, compartidas por
tralizadas dentro de una organización o departamento algún subconjunto de miembros de la organización y se
que supervisan o mejoran la gerencia de los proyectos. les enseña a todos los nuevos miembros de la empresa.
Hay tres tipos predominantes de PMO en las organiza- Cuando la empresa tiene una cultura fuerte, que apoya
ciones. La estación meteorológica se suele utilizar como las metas del proyecto, los miembros de la organización
un dispositivo de seguimiento y vigilancia. En este enfo- tienen más probabilidades de trabajar en colaboración, se
que, el papel de la PMO es vigilar el estado de los proyec- minimizan lealtades departamentales que podrían preva-
tos sin tratar directamente de influirlos o controlarlos. lecer sobre las metas del proyecto y cuentan con los recur-
La segunda forma de PMO es la torre de control, que sos necesarios para alcanzar los objetivos del proyecto.
trata la gerencia de proyectos como una habilidad los Las culturas organizacionales se forman como
negocios para proteger y apoyar. Se centra en los méto- resultado de una variedad de factores, incluidos la tec-
dos para la mejora continua de la gerencia de proyectos nología, el medio ambiente, la ubicación geográfica,
mediante la identificación de lo que está funcionando, los sistemas de recompensa, normas y procedimientos,
dónde se encuentran las deficiencias en desarrollo y los miembros claves de la organización y los incidentes
métodos para resolver los problemas que están presen- críticos. Cada uno de estos factores puede desempe-
tándose. Lo más importante, a diferencia del modelo de ñar un papel en la determinación de si la cultura de la
estación meteorológica, que solo controla las actividades organización es fuerte, de colaboración, centrada en el
de gerencia de proyectos para informar los resultados a cliente, orientado a proyectos o de ritmo rápido.
la alta gerencia, la torre de control pretende trabajar 8. Reconocer los efectos positivos de una cultura orga-
directamente con el gerente y el equipo del proyecto, nizacional de apoyo a las prácticas de gerencia de
apoyando sus actividades. Por último, la fuente de proyectos frente a los de una cultura que va en contra
recursos es una PMO que tiene la intención de mantener de la gerencia de proyectos.   Por último, este capí-
y proporcionar un cuadro de profesionales de proyec- tulo examina la forma en que las culturas de apoyo
tos capacitados y calificados para cuando se necesiten. pueden trabajar a favor de la gerencia de proyectos y
Sirve como un centro de intercambio de mejora conti- las formas en que la cultura puede inhibir el éxito del
nua de las habilidades de los gerentes de proyectoss de proyecto. Un aspecto común de una cultura “enferma”
la empresa. A medida que la empresa inicia nuevos pro- es el escalamiento de un problema de compromiso, en
yectos, los departamentos afectados aplican a la PMO la que los miembros claves de la organización siguen
fuente de recursos, en busca de los activos para poblar el aumentando su apoyo a acciones claramente fallidas
equipo del proyecto. o en proyectos problemáticos. Las razones de escala-
7. Comprender los conceptos claves de la cultura cor- miento son numerosas, incluyendo que nuestro presti-
porativa y cómo se forman las culturas.   Otro factor gio está en juego, la convicción de que estamos cerca de
contextual, la cultura organizacional, desempeña un tener éxito, el miedo al ridículo si se admite el fracaso y
papel importante para influir en las actitudes y los valores la cultura de la organización en la que operamos.

Términos clave
Ambiente externo (p. 47) Estructura funcional (p. 48) Objetivos (pág. 37) Organizaciones basadas en
Análisis de los Estructura matricial (p. 52) Oficina de gerencia de proyectos (p. 50 )
interesados (p. 40) Estructura organizacional proyectos (p. 56) Programa (p. 40)
Cultura (p. 60) (p. 46) Organización basada en Recursos (p. 53 )
Cultura organizacional Gestión estratégica (p. 37) proyectos pesos pesados Tecnología (p. 61)
(p. 59) Interesados (p. 41) (p. 54 )
Escalamiento de compro- Interesados del proyecto Organización matricial
miso (p. 64) (p. 41) (p. 52)
Estructura basada en Matriz débil (p. 53)
proyectos (p. 50) Matriz fuerte (p. 53)
Estudio de caso 2.1 67

Preguntas para discusión


1. El capítulo sugiere que una definición de dirección estratégica cultura organizacional de apoyo? Como consultor, ¿qué con-
incluye cuatro componentes: sejo le daría a una organización funcional que pretende pasar
a. El desarrollo de una visión estratégica y sentido de misión de una vieja cultura controversial, donde los distintos departa-
b. La formulación, implementación y evaluación mentos se resisten activamente a ayudarse unos a otros, a uno
c. La toma de decisiones funcionales transversales que alienta el “pensamiento de proyectos” y la cooperación
d. El logro de los objetivos entre funciones?
Discuta cómo cada uno de estos cuatro elementos es importante 6. Usted es un miembro del personal de alta gerencia en la empresa
para entender el reto de la gerencia de proyectos estratégicos. XYZ. Usted históricamente ha estado utilizando una configura-
¿Cómo los proyectos sirven para permitir a una organización reali- ción de estructura funcional con cinco departamentos: finanzas,
zar cada uno de estos cuatro componentes de la gestión estratégica? recursos humanos, marketing, producción e ingeniería.
2. Discuta la diferencia entre los objetivos y estrategias de la a. Elabore un dibujo simplificado de su estructura funcional,
organización. identificando los cinco departamentos.
3. Su empresa tiene la intención de construir una planta de energía b. Suponga que usted ha decidido pasar a una estructura
nuclear en Oregón. ¿Por qué es importante el análisis de los inte- basada en proyectos. ¿Cuáles podrían ser algunas de las
resados como una condición previa para la decisión de si debe o presiones ambientales que contribuyen a su creencia de que
no seguir adelante con este plan? Realice un análisis de los intere- es necesario modificar la estructura?
sados para una actualización planeada de un producto exitoso de c. Con la estructura basada en proyectos, tiene cuatro pro-
software. ¿Quiénes son los interesados claves? yectos en curso: equipo de música, instrumentos y equipos
4. Considere la posibilidad de una empresa de tamaño medio que de prueba, escáneres ópticos y comunicaciones de defensa.
ha decidido comenzar a utilizar la gerencia de proyectos en una Dibuje la nueva estructura que crea estos cuatro proyectos
amplia variedad de sus operaciones. Como parte de su cambio como parte del organigrama.
operacional, se va a adoptar una oficina de gerencia de proyec- 7. Suponga que ahora quiere convertir la estructura de la pregunta
tos en algún lugar dentro de la organización. Analice el tipo 6 en una estructura matricial, haciendo hincapié en los compro-
de PMO que debe adoptarse (estación meteorológica, torre de misos duales de la función y del proyecto.
control o fuente de recursos). ¿Cuáles son algunos de los crite- a. Vuelva a crear el diseño estructural para mostrar cómo
rios claves de decisión que le ayudarán a determinar cuál es el sería la matriz.
modelo que tiene más sentido? b. ¿Qué problemas de comportamiento se podrían anticipar a
5. ¿Cuáles son algunos de los elementos claves de la organiza- través de este diseño? Es decir, ¿puede ver puntos posibles
ción que pueden afectar el desarrollo y mantenimiento de una de fricción en la configuración de doble jerarquía?

Estudio de caso 2.1


Rolls-Royce Corporation
Aunque el nombre de Rolls-Royce está indisolublemente Airbus, un consorcio privado de varias empresas europeas
ligado a sus automóviles de gran lujo, el moderno Rolls-Royce asociadas, ha empatado con Boeing en ventas en los últimos
opera en un entorno competitivo muy diferente. Un fabri- años. Debido a que el costo de un solo motor de reacción,
cante líder de sistemas de energía para el sector aeroespacial, incluidas piezas de repuesto, se puede vender por varios
marina y empresas de energía, el mercado de Rolls se centra millones de dólares, ganar grandes pedidos, ya sea del sector
en el desarrollo de motores de reacción para una variedad defensa o del de construcción de aviones comerciales, repre-
de usos, tanto comerciales como de defensa. En este mer- senta un reto permanente para cada uno de los “tres grandes”
cado, la empresa cuenta con dos competidores principales, fabricantes de motores de aviones.
General Electric y Pratt & Whitney (propiedad de United Las líneas aéreas de los países en desarrollo a menudo
Technologies). Hay un número limitado de pequeños juga- puede ser un mercado lucrativo pero peligroso para estas
dores en este nicho de mercado de los motores de reacción, empresas. Debido a que estos países no mantienen altos
pero su impacto desde una perspectiva técnica y comercial es niveles de tipo de cambio, no es desconocido, por ejemplo,
pequeño. Rolls, GE y Pratt & Whitney habitualmente parti- para Rolls (o para sus competidores) tomar un pago parcial
cipan en una feroz competencia por las ventas a contratistas en efectivo y luego aceptar productos variados para pagar el
de la defensa y la industria de la aviación comercial. Los dos saldo. Por tanto, un contrato con la compañía aérea nacional
principales fabricantes de aviones, Boeing y Airbus, toman de Turquía puede dar lugar a un pago monetario para Rolls,
continuamente decisiones de compra de millones de dólares, ¡junto a varias toneladas de pistachos y otros bienes comercia-
que son vitales para el éxito de los fabricantes de motores. les! Para mantener sus objetivos de ventas y de servicio, estos
(continúa)
68 Capítulo 2  •  El contexto organizacional. Estrategia, estructura y cultura

fabricantes de motores de reacción recurren habitualmente de gran tamaño. El proyecto refleja la visión estratégica
a la financiación creativa, contratos a largo plazo o a ofertas compartida por Airbus y Rolls-Royce que el mercado
comerciales basados en activos. En general, sin embargo, se comercial de pasajeros se triplicará en los próximos 20
prevé que el mercado de los reactores continuará creciendo años. Como resultado, las oportunidades futuras implica-
a tasas enormes. Rolls-Royce proyecta para un periodo de 20 rán aviones más grandes, económicamente más viables.
años una demanda potencial de mercado de 70,000 moto- Desde 2007, Airbus ha entregado un total de 40 aviones
res, valorados en más de 400,000 millones de dólares sola- A380 a sus clientes, 17 en 2010. Su cartera de pedidos
mente en el sector aeroespacial civil. Cuando los contratos de actual se sitúa en 234 aviones. Colectivamente, Airbus y
defensa se incluyen, las proyecciones de ingresos por ventas Rolls-Royce han hecho una gran apuesta financiera a que
de motores de reacción tienden a ser enormes. Como Rolls su visión estratégica del futuro es la correcta.
ve el futuro, la principal oportunidad de crecimiento del mer-
cado se presenta en los motores de empuje más grandes, dise- Preguntas
ñados para ser instalados en aviones más grandes. 1. ¿Quiénes son los principales interesados en la geren-
Rolls-Royce está llevando a cabo una decisión estra- cia de proyectos de Rolls? ¿Cómo diseñar estrategias
tégica que ofrece un potencial para grandes ganancias o de gestión de interesados para hacerles frente a sus
pérdidas significativas, que acopla su última tecnología de preocupaciones?
motores, la serie “Trent”, con la decisión de Airbus para 2. Teniendo en cuenta los riesgos financieros inherentes
desarrollar un avión comercial ultragrande para viajes de al desarrollo de un motor de jet, argumente, ya sea a
larga distancia. El nuevo diseño de Airbus, el modelo 380, favor o en contra de Rolls, para desarrollar alianzas
tiene sillas para más de 550 personas, y vuelan rutas de estratégicas con otros fabricantes de motores de reac-
larga distancia (más de 8,000 millas). El Trent 900, con un ción, de una manera similar a la disposición del con-
índice de 70,000 libras de empuje por motor, se ha creado sorcio Airbus. ¿Cuáles son las ventajas y desventajas
a alto costo para estar en el servicio de mercado de aviones de este tipo de convenio?

Estudio de caso 2.2


Caso clásico: El paraíso perdido: el Xerox Alto35
Imagine las curvas de valor del mercado tecnológico en colección de genios de la informática con sede en el Centro
la informática personal. ¿Cuánto costaría una ventana de Investigación de Palo Alto de Xerox (Palo Alto Research
de cinco años de ventaja competitiva para una empresa, Center: PARC), el Alto fue impresionante en su atractivo
en la actualidad? Esto podría significar fácilmente miles innovador. Fue la respuesta de PARC para que la alta direc-
de millones de dólares en ingresos, una reputación este- ción de Xerox pudiera “batear un jonrón”. Xerox ya se había
lar en la industria, ingresos futuros asegurados y una beneficiado anteriormente de un jonrón, con el Modelo 914
lista de beneficios continua. Para Xerox Corporation, sin de fotocopiadoras, una innovación tecnológica que propor-
embargo, algo extraño sucedió en el camino hacia el lide- cionó el impulso para convertir a Xerox en una empresa de
razgo del sector. En 1970, Xerox tuvo una posición única mil millones de dólares en la década de los años 1960. Alto
para aprovechar los enormes saltos hacia adelante que representaba un logro similar.
había hecho en la tecnología de automatización de ofici- ¿Qué salió mal? ¿Qué fuerzas se combinaron para
nas. Sin embargo, la empresa se tambaleó negativamente asegurarse de que no más de 2,000 Altos fueran produci-
debido a su propia miopía estratégica, falta de coraje, dos y que ninguno fuera llevado al mercado? (Fueron uti-
deficiencias estructurales y malas decisiones. Esta es la lizados solo dentro de la empresa y en algunos sitios de la
historia de Xerox Alto, el primer ordenador personal del universidad). La respuesta podría estar en el pensamiento
mundo y uno de los grandes relatos “¿qué pasaría si..?” de estratégico confuso que tuvo lugar en el Xerox Alto, mien-
la historia empresarial. tras que estaba en desarrollo.
El Alto no era solo un paso adelante sino más bien era La historia de Xerox durante este periodo muestra
un salto cuántico. Estar en sitio y en funcionamiento a finales una empresa que se apartó de liderazgo tecnológico en
de 1973, fue el primer computador personal independiente forma incremental, haciendo que IBM tomara el liderazgo
para combinar gráficos de mapas de bits, un ratón, panta- de la ofimática. Incrementalismo se refiere a la adopción
llas de menú, iconos, conexión Ethernet, una impresora de un enfoque gradual que juega a lo seguro, evitando sal-
láser y software de procesamiento de textos. Como resul- tos tecnológicos, grandes riesgos y, por consiguiente, la
tado de los esfuerzos combinados de una impresionante posibilidad de grandes ganancias. En 1974, Xerox decidió
Estudio de caso 2.1 69

lanzar la cinta magnética Modelo 800 con procesador de eléctrica, Xerox respondió de la misma manera gradual. La
textos en lugar del Alto, debido a que el modelo 800 fue estructura orgánica de la Xerox no permitía a cualquier divi-
percibido como la apuesta más segura. Durante los próxi- sión o director clave llegar a convertirse en el campeón de las
mos cinco años, una serie de adquisiciones inoportunas, nuevas tecnologías, como el Alto.
demandas y reorganizaciones dictaminaron al Alto como En 1979 Steven Jobs, presidente de Apple Computer,
una víctima de la falta de atención. ¿Cuál sería la división recorrió el complejo PARC y vio a un Alto en uso. Quedó
que debería supervisar su desarrollo y puesta en marcha? tan impresionado con las características de la máquina y las
¿El presupuesto de quién debería apoyarlo, y a PARC capacidades operativas que preguntó cuándo se había sido
en general? Al dejar tales decisiones difíciles sin tomar, lanzado al mercado. Cuando se le dijo que gran parte de
Xerox desperdició tiempo valioso y despilfarró su ventana esta tecnología se había desarrollado en 1973, Jobs se sintió
tecnológica de oportunidades. Incluso cuando hay claros “físicamente enfermo,” más tarde, contó que había sido por
indicios que muestran que la competencia Wang estuvo pensar en la oportunidad a la que Xerox había renunciado.
preparada para introducir su propia línea de sistemas de
Preguntas
oficina, Xerox no pudo dar el paso para que el Alto lle-
gara al mercado. En 1979, Xerox perdió esta oportunidad 1. ¿Ve una contradicción lógica en la disposición de
única. Ya el Alto no era la única tecnología en su clase y la Xerox para dedicar millones de dólares a apoyar
compañía silenciosamente dejó a un lado los planes para los centros de investigación puros como PARC y su
su introducción comercial. negativa a introducir en el mercado los productos
Tal vez la ironía final es la siguiente: aquí había una desarrollados?
empresa que había hecho su nombre por el fenomenal éxito 2. ¿Cómo funcionaba la visión estratégica de Xerox a
de un producto altamente innovador, el Modelo 914 de favor o en contra del desarrollo de nuevas tecnologías
fotocopiadoras, pero no sabía cómo manejar las oportuni- radicales, como el Alto?
dades que presenta el siguiente fenómeno. El Alto fue tan 3. ¿Qué otros acontecimientos imprevisibles contribu-
avanzado que la compañía parecía incapaz de comprender yeron a que los ejecutivos de Xerox no estuvieran dis-
sus posibilidades. Los ejecutivos no tenían un enfoque estra- puestos a asumir nuevos riesgos, precisamente en el
tégico que enfatizara una progresión continua de la inno- momento en que el Alto estaba listo para ser lanzado?
vación. En su lugar, se dirigieron hacia un cabeza-cabeza 4. “La innovación radical no puede ser demasiado radical
con la competencia en un enfoque incremental. Cuando si queremos que sea un éxito comercial.” Argumente
el competidor IBM lanzó una nueva máquina de escribir ya sea a favor o en contra de esta afirmación.

Estudio de caso 2.3


Estimación de tareas del proyecto y de la cultura “¡Te atrapé!”
Recientemente trabajé con una organización que ha Jefe:  “ Eso es demasiado tiempo. Solo le puedo dar
adoptado una mentalidad en la que se suponía que la 80 horas, como mucho.”
mejor manera de mantener a los miembros del equipo Usted (suspiro teatral):  “Bueno, si usted lo dice,
trabajando duro era recortando unilateralmente sus esti- pero realmente no sé
maciones de duración de las tarea en 20%. Suponga que cómo pueda sacar esto
se le pide estimar el tiempo necesario para escribir el adelante.”
código fuente para un producto de software en particu-
lar y ha determinado que esto debe tomar alrededor de Una vez que usted sale de la oficina y cierra la
80 horas. Al saber que estaba a punto de presentar esta puerta, sonríe y susurra, “¡Te atrapé!”
información a su supervisor y que él va recortar de inme-
diato la estimación en 20%, ¿cuál sería su curso de acción? Preguntas
Probablemente añadiría primero un “factor de seguridad”
a la estimación con el fin de protegerse. La conversación 1. ¿De qué manera la cultura de la organización apoya
con el jefe podría ser algo como esto: este tipo de comportamiento? ¿Qué presiones enfrenta
el gerente? ¿Qué presiones enfrenta el subalterno?
Jefe:  “ ¿Ha tenido la oportunidad de estimar la 2. Discuta la afirmación: “¡Si usted no toma en serio mis
secuencia de codificación?” estimaciones , yo no le voy a dar estimaciones serias!”
Usted:   “Sí, debe llevarme 100 horas.” ¿Cómo aplica esta afirmación a este ejemplo?
70 Capítulo 2  •  El contexto organizacional. Estrategia, estructura y cultura

Estudio de caso 2.4


Widgets ’R Us
Widgets ’R Us (WRU) es una empresa mediana especiali- problemas: los productos son lentos para el mercado; muchas
zada en el diseño y la fabricación de aparatos pequeños de innovaciones se les han pasado a WRU porque la compa-
calidad. El mercado de widgets se ha mantenido estable. ñía tardó en recoger las señales que venían del mercado; la
Históricamente, WRU ha tenido un diseño de organiza- comunicación interna es muy pobre; gran cantidad de infor-
ción funcional con cuatro departamentos: contabilidad, mación es emitida “desde arriba” y nadie parece saber lo que
ventas, producción e ingeniería. Este diseño ha servido le sucede. Los jefes de departamento constantemente culpan
bien a la compañía y ha sido capaz de competir por ser la a otros jefes de departamento por los problemas.
compañía con menor costo de la industria.
En los últimos tres años, la demanda de aparatos se ha Preguntas
disparado. Nuevos widgets se están desarrollando constan- 1. Se le ha llamado como consultor para analizar las
temente para alimentar la demanda insaciable del público. operaciones en WRU. ¿Qué le aconsejaría?
El ciclo de vida promedio de un widget recién lanzado es de 2. ¿Qué cambios de diseño estructural podrían llevarse
12-15 meses. Infortunadamente, WRU no ha podido encon- a cabo para mejorar las operaciones de la empresa?
trar la forma de competir exitosamente en este nuevo y diná- 3. ¿Cuáles son las fortalezas y debilidades de las alterna-
mico mercado. El gerente general ha señalado una serie de tivas de solución que la empresa podría emplear?

Ejercicios en internet
1. Wegmans ha sido votado consistentemente como una de las 100 b. Gestionar el proyecto cuando el gerente del proyecto
mejores empresas para trabajar en Estados Unidos por la revista no está disponible
Fortune. De hecho, en 2005, ocupó el puesto número 1 y en 2012 c. Definir los procesos de negocio
ocupó el puesto número 4. Vaya a su sitio web, www.wegmans. d. Gestionar el gerente del proyecto
com, y haga clic en “About Us.” ¿Qué mensajes, formales e in-
formales, se envían sobre Wegmans través de su sitio web? ¿Qué 2. ¿Cuál es la función típica de la alta gerencia en un
dice el sitio web acerca la cultura de la organización? proyecto?
2. Ingrese en el sitio web www.projectstakeholder.com y analice a. Apoyar el proyecto
algunos de los estudios de casos que se encuentran en este sitio. b. Pagar por ello
¿Qué hacen estos casos para sugerir la importancia de la eva- c. Apoyar el proyecto y resolver recursos y otros
luación de las expectativas del partícipe de un proyecto antes conflictos
de que haya comenzado su proceso de desarrollo? En otras pa- d. Resolver recursos y otros conflictos
labras, ¿cuáles son los riesgos que implica esperar para abordar
preocupaciones de los interesados hasta después de que el pro- 3. ¿Cuál es la organización que controla a los gerentes de
yecto haya comenzado? proyectos, la documentación y las políticas?
3. Ingrese en un sitio web corporativo de su elección que tenga a. PMO
acceso al organigrama. ¿Qué forma de organización representa: b. Matriz fuerte
este cuadro funcional, basada en proyectos, matricial o alguna c. Funcional
otra forma? Basado en la discusión de este capítulo, ¿cuáles se- d. Basada en proyecto puro
rían las posibles fortalezas y debilidades de las actividades de
gerencia de proyectos en esta organización? 4. Una analista de negocios tiene una carrera que ha sido
4. Acceda al sitio web corporativo de Fluor-Daniel Corporation y muy importante para ella a lo largo de 10 años. Ella ha
examine la sección “Compliance and Ethics” en www.fluor.com sido asignada a un proyecto con una fuerte estructura
/sustainability/ethics_compliance/Pages/default.aspx. ¿Qué su- organizacional matricial. ¿Cuál de los siguientes aspec-
giere el “Código Flúor de Conducta y Ética” acerca de la forma tos es probable que sea visto como negativo al estar en el
en que la empresa hace negocios? ¿Cuáles son las metas y orien- proyecto?
taciones estratégicas que fluyen naturalmente desde el código a. Estar lejos del grupo y en un proyecto que podría
ético? En su opinión, ¿cómo puede influir la declaración ética en hacer más difícil conseguir un ascenso
la manera en que la empresa gestiona sus proyectos? b. Trabajar con personas que tienen habilidades similares
c. Trabajar muchas horas porque el proyecto es de alta
Preguntas de ejemplo del examen para la certificación PMP® prioridad
1. ¿Cuál es la función principal de un gerente funcional? d. No poder tomar sus propias pruebas de certificación
a. Controlar recursos porque está muy ocupada
Proyecto integrado 71

5. Un gerente funcional está planeando el proyecto de susti- Respuestas: 1 a—El gerente funcional ejecuta las operaciones
tución del sistema de facturación con el gerente de proyec- del día tras día de su departamento y controla los recursos; 2 c—
tos más nuevo de la compañía. Al hablar de este proyecto, Porque los altos directivos por lo general superan al gerente del
el gerente funcional se centra en los costos asociados al proyecto, que puede ayudar a resolver cualquier recurso u otros
funcionamiento del sistema después de su creación y al conflictos que puedan surgir; 3 a—La PMO por lo general tiene
número de años que el sistema va a durar. antes de que todas estas responsabilidades; 4 a—Estar lejos de su grupo fun-
deba sustituirse. ¿Qué describe mejor en lo que está cen- cional puede provocar que sienta que sus esfuerzos en favor del
trado el gerente funcional? proyecto no están siendo reconocidos por su gerente funcional, ya
a. Ciclo de vida del proyecto que el proyecto emplea una estructura de matricial sólida; 5 b—El
b. Ciclo de vida del producto gerente funcional se centra en el ciclo de vida del producto, que se
c. Ciclo de vida de la gerencia de proyectos desarrolla con base en un ejemplo de un proyecto exitoso y abarca
d. Ciclo de vida de la gerencia del programa el rango de uso del producto.

PROYECTO INTEGRADO
Construya su plan de proyecto

EJERCICIO 1—DESARROLLO DE LA DESCRIPCIÓN Y LAS METAS


DEL PROYECTO
Se le ha asignado a un equipo de proyecto para desarrollar un nuevo producto o servicio para su organización. Su
desafío es decidir primero el tipo de producto o servicio que desea desarrollar. Las opciones para el proyecto pue-
den ser flexibles, que consiste en opciones tan diversas como la construcción, el desarrollo de nuevos productos, la
implementación de IT, etcétera.
Elabore por escrito el alcance del proyecto que ha seleccionado. Se espera que su equipo cree la historia del pro-
yecto, compleméntela con una visión general del proyecto, una meta o metas (incluidas metas del proyecto) identifi-
cables, el enfoque general de la gerencia de proyectos y las limitaciones o los posibles efectos limitantes significativos
del proyecto. Adicionalmente, en su caso, determine las necesidades de recursos básicos (es decir, personal o equipo
especializado) necesarios para llevar a cabo el proyecto. Lo más importante en esta etapa es la creación de una historia
o descripción del proyecto en el que se incluya una declaración específica del propósito o intención (es decir, por qué
se desarrolla el proyecto, qué es, en qué lugar y la oportunidad que se pretende abordar).
El escrito deberá explicar el concepto del proyecto, limitaciones y expectativas. No es necesario entrar
en detalle sobre las diferentes subactividades o subcomponentes del proyecto, sino que es más importante
concentrarse en un cuadro general por ahora.

EJEMPLO DE ANÁLISIS DE ANTECEDENTES Y DESCRIPCIÓN DEL


PROYECTO PARA ABCUPS, INC.
Fundada en 1990, ABCups, Inc. es propietaria y operadora de 10 máquinas de moldeo por inyección para producir
vasos de plástico. La línea de productos de ABCups se compone de tazas de viaje, las tazas, los steins (tazas ornamentales
para cerveza), termos y vasos deportivos. Las tazas de viaje, las tazas térmicas y los steins vienen en dos tamaños: 14 y
22 oz. Los vasos deportivos se ofrecen solo en el tamaño de 32 oz. Todos los productos, excepto los steins tienen tapa.
Se ofrecen en 15 colores y cualquier combinación de colores puede ser utilizada. Las tazas de viaje y térmicas tienen un
revestimiento que necesita ser soldado al cuerpo exterior, subcontratistas y serigrafistas soldan las piezas juntas. ABCups
no hace ninguna soldadura, pero se sujeta la tapa a la taza. La base de clientes de ABCups se compone principalmente
por los distribuidores y las organizaciones de promoción. El crecimiento anual de las ventas se ha mantenido estable, con
un promedio de 2%‒3% cada año. Los ingresos del año pasado de las ventas fueron de 70 millones de dólares.

PROCESO ACTUAL
El método actual de ABCups para la fabricación de su producto es el siguiente:
1. Presupuesto de trabajo.
2. Recibir/procesar la orden.
72 Capítulo 2  •  El contexto organizacional. Estrategia, estructura y cultura

3. Programar la producción.
4. Moldear las partes.
5. Realizar la orden de compra para la serigrafía, según las especificaciones del producto.
6. Enviar piezas a la impresora para la soldadura y trabajo de arte.
7. Recibir productos de la impresora para el montaje final y control de calidad.
8. Enviar el producto a los clientes.
Con los niveles actuales de procesamiento, todo el proceso puede tomar de dos a cuatro semanas,
dependiendo del tamaño de la orden, la complejidad y la naturaleza de la actividad de producción actual.

PANORAMA DEL PROYECTO


Debido a las numerosas quejas y el rechazo de la calidad por los clientes, ABCups ha determinado resolver
proactivamente los problemas de calidad más sobresalientes. La empresa ha determinado que al traer “a
casa” las funciones de soldadura e impresión, será capaz de hacer frente a los problemas actuales de calidad,
ampliar su mercado, mantener un mejor control sobre la entrega y salida de la orden y responder mejor a los
clientes. El proyecto consiste en la adición de tres nuevos procesos (soldadura, serigrafía y mejor control de
calidad) de las operaciones de la empresa.
ABCups no tiene experiencia ni equipo para soldadura y serigrafía. La organización tiene que formarse
por sí misma, investigar el arrendamiento o la compra de espacio y equipo, contratar a trabajadores capaci-
tados y crear una transición de los subcontratistas a los operadores de la empresa. El proyecto necesita una
fecha determinada de terminación para que la transición de la externalización de producción de la empresa
sea suave y los productos puedan entregarse a los clientes con el menor trastorno posible en el transporte.
La estrategia de gestión es integrar verticalmente la organización para reducir costos, aumentar la par-
ticipación en el mercado y mejorar la calidad del producto. ABCups está experimentando problemas con
su base de proveedores, que van desde la mala calidad hasta la programación ineficaz, lo que conduce a que
ABCups incumpla casi 20% de las fechas de envío acordadas con sus clientes. Mantener el control completo
sobre el ciclo de desarrollo del producto debe de mejorar la calidad y la entrega a tiempo de la línea de pro-
ductos de ABCups.

Objetivos
Metas Escala

1. Cumplir todos los plazos del proyecto sin poner en peligro Excelente = 0 incumplimiento de plazos
la satisfacción de los clientes dentro de un marco de tiempo Buena = 1–5 incumplimientos de plazos
de un año. Aceptable = <8 incumplimientos de plazos
2. Agotar la dependencia de la serigrafía subcontratada Excelente = 100% de independencia
100% en seis meses, sin aumentar el precio al cliente o Bueno = 80–99% de independencia
disminuir de la calidad del producto. Aceptable = 60–79% de independencia
3. Realizar todos los cambios de proceso sin afectar los ho- Excelente = 0% demoras en la entrega
rarios actuales de entrega al cliente dentro de un marco Bueno = <5% de retrasos en la entrega
de tiempo de un año. Aceptable = 5–10% de retrasos en la entrega
4. Disminuir el tiempo de espera del cliente respecto al Excelente = 2/3 de disminución en el tiempo
tiempo de espera actual dentro de un marco de tiempo de espera
de un año, sin que disminuya la calidad o aumento en Bueno = 1/2 de disminución en el tiempo
los precios. de espera
Aceptable = 1/3 de disminución en el tiempo
de espera
5. Mantenerse dentro de 10% del presupuesto de capital Excelente = 1% de variación
sin exceder de 20% dentro de la fecha límite del crono- Bueno = 5% de variación
grama de proyecto. Aceptable = 10% de variación
6. Disminuir los rechazos de clientes en 25% dentro de un Excelente = reducción de 45%
marco de tiempo de un año. Bueno = reducción de 35%
Aceptable = reducción de 25%
Notas 73

Enfoque general
1. Enfoque de gestión—El equipo se comprará a proveedores externos, sin embargo, los empleados de
ABCups realizarán los trabajos de montaje. Dado el tipo de equipo que se requiere, no serán necesarios
los contratistas externos, porque las instalaciones de la empresa cuentan con el personal de manteni-
miento necesario para configurar el equipo y resolver problemas según sea necesario, una vez que el
vendedor proporcione el entrenamiento.
2. Enfoque técnico—Los fabricantes de equipos utilizarán CAD para el diseño. Inicialmente, la empresa requiere
un banco de piezas que estará disponible una vez que el equipo ponga a punto la maquinaria. Los accesorios se
diseñarán según sea necesario, pero serán suministrados por el fabricante de la máquina.

Restricciones
1. Presupuesto—Este proyecto debe, en última instancia, aumentar la rentabilidad de la empresa.
Además, el proyecto contará con un presupuesto restringido. Se debe demostrar que cualquier gasto
adicional, tanto para la conversión y como para la producción de tazas terminadas en el lugar, se tradu-
cirá en mayor rentabilidad.
2. Espacio de la planta limitado—ABCups supone que esta conversión no requiere la construcción de
una nueva planta o aumentar significativamente el tamaño de las instalaciones. El espacio para la nueva
maquinaria, nuevos empleados y el almacenamiento de los colorantes y el inventario deben obtenerse
a través de la conversión de espacio existente. Si se necesita espacio adicional, el arrendamiento o la
compra son opciones que tendrán que investigarse.
3. Tiempo—Dado que este proyecto requerirá que la empresa cancele los contratos existentes con los
proveedores, los hitos perdidos u otros retrasos provocarán incumplimientos que no aceptarán los
clientes. Debe implementarse un plan de respaldo para evitar perder clientes con los competidores,
en el caso de que el plazo no se cumpla estrictamente. La conversión debe llevarse a cabo mediante el
desarrollo de un sistema integral de programación de proyectos y ceñirse a este.
4. Normas de seguridad—Las actividades de construcción y transformación deben estar en concordancia con
las especificaciones de diferentes agencias, incluyendo pero no limitándose a las directrices de la Occupational
Safety and Health Administration (OSHA), la compañía de seguros y la agencia de financiamiento.
5. Los pedidos actuales deben entregarse a tiempo—Todas las actividades deben estar diseñadas para
evitar cualquier retraso de los pedidos en curso. La transición debe ser transparente para el cliente, a fin
de evitar que se pierda parte de la base de clientes existente.

Notas
1. Pearson, D. (2010). “Airships receive life from new techno- (Eds.), Project Management Handbook, 2nd ed. New York:
logy,” Wall Street Journal, http://online.wsj.com/article/SB100 Van Nostrand Reinhold, pp. 129–39.
01424052748703959704575453391253582542.html; Excell, J. 5. Grundy, T. (2000). “Strategic project management and strategic
(2010, 12 de julio). “Meet LEMV: The first of a new generation behavior,” International Journal of Project Management, 18(2):
of advanced military airship,” The Engineer, www.theengineer. 93–104; Van der Merwe, A. P. (2002). “Project management and
co.uk/in-depth/the-big-story/meet-lemv-the-first-of-a-new- business development: Integrating strategy, structure, processes
generation-of-advanced-military-airship/1003418.article; and projects,” International Journal of Project Management, 20:
“Rise of the blimps.” (2010). www.defenseindustrydaily. com/ 401–11; Van der Merwe, A. P. (1997). “Multi-project mana-
Rise-of-the-Blimps-The-US-Armys-LEMV-06438/; “Northrop gement—organizational structure and control,” International
Grummans’ LEMV program completes three major miles- Journal of Project Management, 15: 223–33.
tones.” (2010, 5 de noviembre). www.spacewar.com/reports/ 6. King, W. R. (1988). “The role of projects in the implementa-
Northrop_Grumman_LEMV_Program_Completes_Three_ tion of business strategy,” in Cleland, D. I., and King, W. R.
Major_Milestones_999.html. (Eds.), Project Management Handbook, 2nd ed. New York:
2. David, F. R. (2001). Strategic Management, 8th ed. Upper Van Nostrand Reinhold, pp. 129–39.
Saddle River, NJ: Prentice Hall. 7. Wheelen, T. L., and Hunger, J. D. (1992). Strategic Management
3. Cleland, D. I. (1998). “Strategic project management,” and Business Policy, 4th ed. Reading, MA: Addison-Wesley.
in Pinto, J. K. (Ed.), Project Management Handbook. San 8. Wiener, E., and Brown, A. (1986). “Stakeholder analysis for
Francisco, CA: Jossey-Bass, pp. 27–40. effective issues management,” Planning Review, 36: 27–31.
4. King, W. R. (1988). “The role of projects in the implementa- 9. Mendelow, A. (1986). “Stakeholder analysis for strategic planning
tion of business strategy,” in Cleland, D. I., and King, W. R. and implementation,” in King, W. R., and Cleland, D. I. (Eds.),
74 Capítulo 2  •  El contexto organizacional. Estrategia, estructura y cultura

Strategic Planning and Management Handbook. New York: Van Management Journal, 18(2): 81–85; Gray, C., Dworatschek,
Nostrand Reinhold, pp. 67–81; Winch, G. M. (2002). Managing S., Gobeli, D. H., Knoepfel, H., and Larson, E. W. (1990).
Construction Projects. Oxford: Blackwell; Winch, G. M., and “International comparison of project organization structu-
Bonke, S. (2001). “Project stakeholder mapping: Analyzing the in- res,” International Journal of Project Management, 8: 26–32.
terest of project stakeholders,” in Slevin, D. P., Cleland, D. I., and 25. Gray, C. F., and Larson, E. W. (2003). Project Management,
Pinto, J. K. (Eds.), The Frontiers of Project Management Research. 2nd ed. Burr Ridge, IL: McGraw-Hill; Dai, C. (2000). The
Newtown Square, PA: PMI, pp. 385–404.
Role of the Project Management Office in Achieving Project
10. Wideman, R. M. (1998). “How to motivate all stakeholders to
Success. Phd Dissertation, George Washington University.
work together,” in Cleland, D. I. (Ed.), Project Management
26. Block, T. (1998). “The project office phenomenon,”
Field Guide. New York: Van Nostrand Reinhold, pp. 212–
26; Hartman, F. T. (2000). Don’t Park Your Brain Outside. PMNetwork, 12(3): 25–32; Block, T. (1999). “The seven
Newtown Square, PA: PMI. secrets of a successful project office,” PMNetwork, 13(4):
11. Cleland, D. I. (1988). “Project stakeholder management,” in Cleland, 43–48; Block, T., and Frame, J. D. (1998). The Project Office.
D. I., and King, W. R. (Eds.), Project Management Handbook, 2nd Menlo Park, CA: Crisp Publications; Eidsmoe, N. (2000).
ed. New York: Van Nostrand Reinhold, pp. 275–301. “The strategic project management office,” PMNetwork,
12. Ibid. 14(12): 39–46; Kerzner, H. (2003). “Strategic planning for
13. Block, R. (1983). The Politics of Projects. New York: Yourdon the project office,” Project Management Journal, 34(2): 13–
Press. 25; Dai, C. X., and Wells, W. G. (2004). “An exploration of
14. Fisher, R., and Ury, W. (1981). Getting to Yes: Negotiating project management office features and their relationship
Agreement Without Giving In. New York: Houghton Mifflin. to project performance,” International Journal of Project
15. Frame, J. D. (1987). Managing Projects in Organizations. San Management, 22: 523–32; Aubry, M., Müller, R., Hobbs, B.,
Francisco, CA: Jossey-Bass.
and Blomquist, T. (2010). “Project management offices in
16. Grundy, T. (1998). “Strategy implementation and project
transition,” International Journal of Project Management,
management,” International Journal of Project Management,
28(8): 766–78.
16(1): 43–50.
17. Cleland, D. I. (1988). “Project stakeholder management,” in Cleland, 27. Casey, W., and Peck, W. (2001). “Choosing the right PMO
D. I., and King, W. R. (Eds.), Project Management Handbook, 2nd setup,” PMNetwork, 15(2): 40–47; Gale, S. (2009). “Delivering
ed. New York: Van Nostrand Reinhold, pp. 275–301. the goods,” PMNetwork, 23(7): 34–39.
18. Daft, R. L. (2001). Organization Theory and Design, 7 th 28. Kerzner, H. (2003). Project Management, 8th ed. New York:
ed. Mason, OH: Southwestern; Moore, D. (2002). Project Wiley; Englund, R. L., and Graham, R. J. (2001). “Implementing
Management: Designing Effective Organizational Structures a project office for organizational change,” PMNetwork, 15(2):
in Construction. Oxford: Blackwell; Yourker, R. (1977). 48–52; Fleming, Q., and Koppelman, J. (1998). “Project teams:
“Organizational alternatives for project management,” The role of the project office,” Cost Engineering, 40: 33–36.
Project Management Quarterly, 8(1): 24–33. 29. Schein, E. (1985). Organizational Culture and Leadership: A
19. Meredith, J. R., and Mantel, Jr., S. J. (2003). Project Dynamic View. San Francisco, CA: Jossey-Bass, pp. 19–21;
Management, 5th ed. New York: Wiley. Schein, E. H. (1985). “How culture forms, develops and chan-
20. Larson, E. W., and Gobeli, D. H. (1987). “Matrix manage-
ges,” in Kilmann, R. H., Saxton, M. J., and Serpa, R. (Eds.),
ment: Contradictions and insights,” California Management
Gaining Control of the Corporate Culture. San Francisco, CA:
Review, 29(4): 126–37; Larson, E. W., and Gobeli, D. H.
Jossey-Bass, pp. 17–43; Elmes, M., and Wilemon, D. (1989).
(1988). “Organizing for product development projects,”
Journal of Product Innovation Management, 5: 180–90. “Organizational culture and project leader effectiveness,” Project
21. Daft, R. L. (2001). Organization Theory and Design, 7th ed. Management Journal, 19(4): 54–63.
Mason, OH: Southwestern; Anderson, C. C., and Fleming, M. 30. Kirsner, S. (1998, noviembre). “Designed for innovation,”
M. K. (1990). “Management control in an engineering matrix Fast Company, pp. 54, 56; Daft, R. L. (2001). Organization
organization: A project engineer’s perspective,” Industrial Theory and Design, 7th ed. Mason, OH: Southwestern.
Management, 32(2): 8–13; Ford, R. C., and Randolph, W. 31. Kilmann, R. H., Saxton, M. J., and Serpa, R. (1985). Gaining
A. (1992). “Cross-functional structures: A review and inte- Control of the Corporate Culture. San Francisco, CA: Jossey-Bass.
gration of matrix organization and project management,” 32. “The US must do as GM has done.” (1989). Fortune, 124(2):
Journal of Management, 18: 267–94. 70–79.
22. Larson, E. W., and Gobeli, D. H. (1987). “Matrix management: 33. Gale, S. (2009). “A closer look: Sanofil-Aventis & the Institute
Contradictions and insights,” California Management Review, for OneWorld Health,” PMNetwork, 23(8): 34–37; Access to
29(4): 126–37; Larson, E. W., and Gobeli, D. H. (1988). “Organizing
Medicines, http://en.sanofi-aventis.com/binaries/brochure_
for product development projects,” Journal of Product Innovation
aam_en_tcm28-18133.pdf.
Management, 5: 180–90; Engwall, M., and Kallqvist, A. S. (2000).
34. Staw, B. M., and Ross, J. (1987, marzo, abril). “Knowing when
“Dynamics of a multiproject matrix: Conflicts and coordination,”
Working paper, Chalmers University, www.fenix.chalmers.se/ to pull the plug,” Harvard Business Review, 65: 68–74.
publications/2001/pdf/WP%202001-07.pdf. 35. Smith,D.K., and Alexander, R. C. (1988). Fumbling the
23. Wheelwright, S. C., and Clark, K. (1992). “Creating project plans to Future: How Xerox Invented, Then Ignored, The First Personal
focus product development,” Harvard Business Review, 70(2): 70–82. Computer. New York: Macmillan; Kharbanda, O.P., and Pinto,
24. Gobeli, D. H., and Larson, E. W. (1987). “Relative effecti- J.K. (1996). What made Gertie Galdop? New York: Vand
veness of different project management structures,” Project Nostrand Reinhold.
CAPÍTULO

3
Selección de proyectos y
gerencia del portafolio

Contenido del capítulo


PERFIL DE PROYECTO La elección de un enfoque de selección de proyectos
Los procedimientos de selección de proyectos en varias PERFIL DEL PROYECTO
industrias Screening y selección de proyectos en GE: el proceso
INTRODUCCIÓN Tollgate
3.1 SELECCIÓN DE PROYECTOS 3.4 GERENCIA DEL PORTAFOLIO DE PROYECTOS
3.2 ENFOQUES PARA EL SCREENING Y SELECCIÓN Objetivos e iniciativas
DE PROYECTOS El desarrollo de un portafolio proactivo
Método uno: modelo lista de verificación Claves para la gerencia exitosa del portafolio de proyectos
Método dos: modelo de puntuación simplificado Resumen
Limitaciones de los modelos de puntuación Términos clave
Método tres: el proceso de jerarquía analítica Problemas resueltos
Metodo cuatro: modelos de perfil Preguntas para discusión
3.3 MODELOS FINANCIEROS Problemas
Periodo de recuperación Estudio de caso 3.1 Keflavik Paper Company
Valor presente neto Estudio de caso 3.2 Selección de proyectos en Nova Western, Inc.
Periodo de recuperación descontado Ejercicios en internet
Tasa interna de retorno Notas
Modelos de opciones

Objetivos de aprendizaje
Al finalizar el capítulo, el estudiante estará en capacidad de:
1. Explicar los seis criterios para un modelo de selección/screening de proyectos.
2. Entender cómo emplear listas de verificación y modelos simples de puntuación para seleccionar proyectos.
3. Usar modelos de puntuación más sofisticados, como el proceso de jerarquía analítica.
4. Aprender a utilizar los conceptos financieros, como la frontera eficiente y el modelo riesgo/retorno.
5. Emplear los análisis financieros y análisis de opciones para evaluar el potencial de las nuevas inversio-
nes en proyectos.
6. Reconocer los desafíos del mantenimiento de un portafolio óptimo de proyectos en una organización.
7. Comprender las tres claves para una gerencia exitosa de portafolios de proyectos.
75
76 Capítulo 3  •  Selección de proyectyos y gerencia del portafolio

PERFIL DE PROYECTO

Los procedimientos de selección de proyectos en varias industrias


El arte y la ciencia de la selección de proyectos son tomadas muy en serio por las organizaciones. Las empresas,
en una variedad de industrias, han desarrollado métodos altamente sofisticados para screening y selección
de proyectos, con el fin de asegurar que los proyectos que optan por financiarse correspondan a la mejor
promesa de éxito. Como una parte de este proceso de screening, las organizaciones suelen desarrollar sus
propios métodos particulares, sobre la base de sus condiciones técnicas, datos disponibles, cultura corporativa
y preferencias. La siguiente lista da una idea de los extremos a los que algunas organizaciones llegan con la
selección de proyectos:
• Hoechst AG, una empresa farmacéutica, utiliza un modelo de puntuación para el portafolio con 19 preguntas
en cinco categorías principales para calificar las oportunidades de proyectos. Las cinco categorías incluyen la
probabilidad de éxito técnico, la probabilidad de éxito comercial, beneficios para la compañía, ajuste con la es-
trategia de negocios y el apalancamiento estratégico (capacidad del proyecto para emplear y elevar los recursos
y habilidades de la empresa). Dentro de cada uno de estos factores hay una serie de preguntas específicas, que
se puntúan en una escala del 1 al 10 por la gerencia.
• En el gigante industrial alemán Siemens, cada unidad de negocio en cada uno de los 190 países en los que opera
la compañía utiliza un sistema denominado “PM @ Siemens” para categorizar los proyectos que emplea un có-
digo de dos dígitos. Cada proyecto recibe una letra de la A a la F, lo que indica su importancia para la empresa
y un número de 0 a 3, lo que indica su nivel de riesgo general. Los proyectos más grandes o con mayor riesgo
(por ejemplo, un “A0”) requieren la aprobación del consejo principal de Siemens en Alemania, pero muchos
de los proyectos menores (por ejemplo, un “F3”) pueden ser aprobados por las unidades de negocio locales.
Demasiados A0 en el portafolio pueden indicar riesgos cada vez más reducidos, mientras que demasiados pro-
yectos F3 pueden significar falta de valor económico total.
• El Royal Bank of Canada ha desarrollado un modelo de puntuación para valorar sus oportunidades de proyec-
tos. Los criterios para la puntuación del portafolio incluyen la importancia del proyecto (importancia estraté-
gica, la magnitud del impacto y los beneficios económicos) y la facilidad de desarrollarlo (costo de desarrollo,
la complejidad del proyecto y la disponibilidad de recursos). El gasto anual previsto y el gasto total del pro-
yecto se agregan a esta lista ordenada por rango de prioridad a las opciones del proyecto. Se utilizan reglas
de decisión (por ejemplo, los proyectos de poca importancia que son difíciles de ejecutar pueden obtener una
calificación “no continúa”).
• El programa de investigación y desarrollo (I+D) de Weyerhaeuser Corporate ha puesto en marcha procesos
para alinear y priorizar los proyectos de (I+D). El programa tiene tres tipos de actividades: evaluación de la tec-
nología (cambios en el ambiente externo y su efecto en la empresa), la investigación (bases y competencias en
áreas técnicas básicas de construcción de conocimiento) y el desarrollo (desarrollo de oportunidades comerciales
específicas). Cuatro entradas principales se consideran al establecer prioridades: cambios significativos en el en-
torno externo, las necesidades futuras a largo plazo de los clientes principales, las estrategias empresariales, las
prioridades y las necesidades de tecnología y la dirección estratégica de la corporación.
• Mobil Chemical utiliza seis categorías de proyectos para determinar el equilibrio adecuado de los proyectos que
entrarán en su portafolio: (1) reducción de costos y mejoras de procesos; (2) mejora de productos, modificacio-
nes al producto y satisfacción del cliente; (3) nuevos productos; (4) nuevos proyectos de plataformas y proyectos
de investigación básica/avance; (5) soporte central; y (6) soporte técnico para los clientes. La alta dirección revisa
todas las propuestas de proyectos y determina el reparto de la financiación de capital entre estos seis tipos de
proyectos. Una de las variables claves de decisión implica una comparación de “lo que es” con “lo que debería
ser”.
• En la División de Materiales de Control de Tráfico de 3M, durante el screening y selección de proyectos, la
gerencia utiliza una tabla de viabilidad del proyecto para calificar las alternativas del proyecto. Como una
parte del perfil y del ejercicio de puntuación, el personal debe abordar cómo el proyecto cumple los obje-
tivos de proyecto estratégico y de negocio críticos que afectan a un grupo específico dentro del mercado
objetivo. Retorno de la inversión proyectada del proyecto siempre se compensa con el riesgo de la opción
de proyecto.
• La gerencia de Exxon Chemical comienza evaluando todas las nuevas propuestas de proyectos a la luz de la es-
trategia de la unidad de negocio y de las prioridades estratégicas. El destino del gasto se decide de acuerdo con
la mezcla total de proyectos en el portafolio. A medida que avanza el año, todos los proyectos se repriorizan
utilizando un modelo de calificación. Al encontrar diferencias significativas entre el gasto previsto y el real, el
grupo de alta gerencia realiza ajustes en portafolio del próximo año.1
Introducción 77

INTRODUCCIÓN
Todas las organizaciones deben seleccionar, entre numerosas opciones, los proyectos que deciden seguir.
¿Qué criterios determinan los proyectos que deben apoyarse? Obviamente, esta no es una decisión sencilla.
Las consecuencias de las malas decisiones pueden ser costosas. Las investigaciones recientes sugieren que, en
el ámbito de la tecnología de la información (information technology: IT), las empresas derrochan más de
50,000 millones de dólares al año en proyectos creados, pero nunca utilizados por sus clientes potenciales.
¿Cómo tomamos las decisiones más razonables para la selección de proyectos? ¿Qué tipo de información
debemos recopilar? ¿Las decisiones se basan estrictamente en el análisis financiero o deben considerarse
otros criterios? En este capítulo, vamos a tratar de responder a estas preguntas a medida que analizamos más
de cerca el proceso de selección de proyectos.
Vamos a examinar una serie de enfoques diferentes para la evaluación y selección de proyectos poten-
ciales. Los diferentes métodos de selección de los proyectos son muy diversos y van desde enfoques altamente
cualitativos, basados en juicios, hasta los que utilizan el análisis cuantitativo. Por supuesto, cada método tiene
ventajas e inconvenientes que deben tomarse en cuenta.
También vamos a discutir una serie de cuestiones relacionadas con la gerencia del portafolio de pro-
yectos, es decir, el conjunto de proyectos que la organización lleva a cabo en un momento determinado. Por
ejemplo, Rubbermaid, Inc. se compromete de forma rutinaria con cientos de nuevos proyectos de desarro-
llo de productos a la vez, siempre en busca de oportunidades con perspectivas comerciales prometedoras.
Cuando una empresa ejecuta múltiples proyectos, los retos en la toma de decisiones estratégicas, gestión de
recursos, programación y control de las operaciones, se magnifican.

3.1  SELECCIÓN DE PROYECTOS


Las empresas están literalmente bombardeadas con opciones, pero ninguna organización goza de infini-
tos recursos con los que pueda aprovechar todas las oportunidades que se le presenten. Se debe hacer una
selección y para asegurarse mejor de que seleccionan los proyectos más viables, muchos gerentes desarro-
llan sistemas-directrices de prioridad, con el fin de equilibrar las oportunidades y los costos que conllevan
cada alternativa. El objetivo es equilibrar las demandas de tiempo y oportunidad.2 Las presiones de tiempo
y de dinero afectan a la mayoría de decisiones y las decisiones suelen ser más exitosas cuando se realizan de
manera oportuna y eficiente. Por ejemplo, si el departamento de ventas de su empresa reconoce una oportu-
nidad comercial que puede explotar, se requiere, con rapidez, generar enfoques alternativos para el proyecto
con el objetivo de capitalizar este prospecto. El tiempo desperdiciado es una oportunidad perdida. Por otro
lado, hay que ser precavido: usted quiere estar seguro de que, al menos en lo posible, se está haciendo la
mejor elección entre las opciones. Por tanto, los tomadores de decisiones organizacionales deben elaborar
directrices —modelos de selección— que les permitan ahorrar tiempo y dinero mientras maximizan la proba-
bilidad de éxito.
Una serie de modelos de decisión se encuentran disponibles para los gerentes responsables de la eva-
luación y selección de proyectos potenciales. Como se puede ver, van desde cualitativos y simples hasta cuan-
titativos y complejos. Sin embargo, todas las empresas tratan de desarrollar un modelo de screening (o
conjunto de modelos) que les permita tomar las mejores opciones dentro de las limitaciones habituales de
tiempo y dinero.
Suponga que usted estuviera interesado en el desarrollo de un modelo que le permitiera filtrar efecti-
vamente proyectos alternativos. ¿Cómo puede asegurarse de que el modelo fuera capaz de captar los posibles
“ganadores” dentro de una numerosa serie de posibles opciones de proyectos? Después de pensarlo mucho,
usted decide reducir el enfoque de su modelo de screening para crear uno que le permitirá seleccionar solo
los proyectos que tengan grandes beneficios potenciales. Todas las demás cuestiones se ignoran, en favor del
único criterio de rentabilidad comercial. La pregunta es: ¿el modelo de screening es útil? Souder3 identifica
cinco aspectos importantes que los gerentes deben tener en cuenta al evaluar los modelos de screening?
1. Realismo: un modelo eficaz debe reflejar los objetivos de la organización, incluidos los objetivos estra-
tégicos y la misión de una empresa. Los criterios deben ser razonables a la luz de limitaciones en los
recursos, como dinero y personal. Por último, el modelo debe tener en cuenta tanto los riesgos comercia-
les como los técnicos, incluyendo rendimiento, costo y tiempo. Es decir: ¿el proyecto funcionará según
lo previsto? ¿Se puede mantener con el presupuesto original o hay un alto potencial de aumento de los
costos? ¿Hay un fuerte riesgo significativo de incumplimiento de la programación?
78 Capítulo 3  •  Selección de proyectos y gerencia del portafolio

2. Capacidad: el modelo debe ser suficientemente flexible para responder a los cambios en las condiciones
en que se llevan a cabo los proyectos. Por ejemplo, el modelo debe permitirle a la empresa comparar los dife-
rentes tipos de proyectos (proyectos a largo plazo frente a corto plazo, proyectos de diferentes tecnologías o
capacidades, proyectos con diferentes objetivos comerciales). Debe ser suficientemente robusto como para
darles cabida a nuevos criterios y limitaciones, lo cual sugiere que el modelo de screening debe permitirle a
la empresa utilizarlo tan ampliamente como sea posible a fin de cubrir el mayor número de proyectos.
3. Flexibilidad: el modelo debería modificarse fácilmente si las aplicaciones de prueba requieren cam-
bios. Hay, por ejemplo, que permitir ajustes por modificación en los tipos de cambio, las leyes de
impuestos, códigos de construcción, etcétera.
4. Facilidad de uso: un modelo debe ser suficientemente simple para que puedan utilizarlo personas de
todas las áreas de la organización: de proyectos específicos de posiciones funcionales relacionados. Además,
el modelo de screening que se aplica, las decisiones tomadas en la selección de proyectos y las razones de esas
decisiones deben ser claras y fáciles de entender por los miembros de la organización. El modelo también
debe ser oportuno: debe generar la información de screening rápidamente y la gente debe ser capaz de asi-
milar esta información sin ningún tipo de formación o habilidades especiales.
5. Costo: el modelo de screening debe ser de bajo costo. Un enfoque de selección costoso en su uso, en
términos de tiempo o dinero, tiene alta probabilidad de generar el peor efecto posible: haciendo que
miembros de la organización eviten utilizarlo por el costo excesivo de emplearlo. El costo de obtener la
selección puede disminuir su aplicabilidad.
Vamos a añadir el sexto criterio para la selección de un modelo de éxito:
6. Comparabilidad: El modelo debe ser suficientemente amplio que pueda aplicarse a múltiples pro-
yectos. Si un modelo está estrechamente enfocado, puede ser inútil en la comparación de los posibles
proyectos o fomentar los prejuicios de unos sobre otros. Un modelo de utilidad debe ser compatible
con las comparaciones generales de las alternativas del proyecto.
Los modelos de selección de los proyectos se dividen en dos clases generales: numéricos y no numéricos.4 Los
modelos numéricos tratan de utilizar valores cuantificables como insumos para el proceso de decisión involucrado
en la selección de proyectos. Estos valores se pueden obtener ya sea objetiva o subjetivamente, es decir, podemos
emplear valores externos objetivos (“Para la construcción del puente se requieren 800 metros cúbicos de cemento”)
o valores internos subjetivos (“Tendremos que contratar a dos inspectores de código para terminar el desarrollo de
software dentro de ocho semanas”). Ninguna de estas dos opciones de entrada es necesariamente errada: la opinión
de un experto en un tema puede ser subjetiva, pero muy precisa. Por otro lado, un nivel mal calibrado de un topógrafo
puede dar datos objetivos, pero errados. La clave es recordar que la mayoría de los procesos de screening aplicados a
proyectos implican una combinación de datos de evaluación subjetiva y objetiva en la toma de decisiones. Los modelos
no numéricos, por otra parte, no emplean números como entradas de decisión, y se basan, en cambio, en otros datos.
Las empresas gastan grandes cantidades de tiempo y esfuerzo tratando de tomar las mejores decisiones de
selección de proyectos. Estas decisiones se hacen típicamente respecto a los objetivos generales que el personal de la
alta gerencia de la compañía ha desarrollado y promovido con base en su plan estratégico. Tales objetivos pueden ser
complejos y reflejar un número de factores externos que potencialmente afectan las operaciones de una empresa. Por
ejemplo, supongamos que el nuevo jefe de la División de Iluminación de Sylvania ordenó que el objetivo estratégico
de la organización fuera el crecimiento de las ventas a toda costa. Cualquier nueva opción de proyecto se evalúa con
este imperativo estratégico. Por tanto, un proyecto que ofrece la posibilidad de abrir nuevos mercados podría con-
siderarse más favorable que un proyecto en competencia que promete una tasa potencial de rendimiento más alta.
La lista de factores que pueden considerarse en la evaluación de alternativas del proyecto es enorme. El
cuadro 3.1 proporciona una lista parcial de los diversos elementos que la empresa debe enfrentar, organizados
en categorías generales, factores de riesgo y comerciales, cuestiones de funcionamiento interno y otros factores.
Aunque esta lista puede ser larga, en realidad, la gerencia estratégica enfatiza unos criterios sobre otros. De hecho,
si aplicamos el principio de Pareto 80/20, que establece que algunos problemas (20%) son de vital importancia y
muchos (80%) son triviales, se puede argumentar que, para muchos proyectos, menos de 20% de todos los posibles
criterios de decisión representan más de 80% de la decisión sobre si se debe continuar con el proyecto.
Anotado esto, debemos reflexionar sobre dos puntos finales respecto a la utilización de cualquier método
de toma de decisiones en la selección de proyectos. En primer lugar, el modelo más completo en el mundo sigue
siendo solo un reflejo parcial de la realidad organizacional. La lista de posibles entradas en la decisión de selección
de proyectos es literalmente ilimitada. De hecho, hay que reconocer esta verdad antes de explorar la selección de
proyectos para no equivocarse, al suponer que es posible, con el tiempo y el esfuerzo suficientes, identificar toda la
3.2  Enfoques para el screening y selección de proyectos 79

CUADRO 3.1  Problemas de screening y selección de proyectos

1. Riesgo: factores que reflejan elementos de incertidumbre en la empresa, e incluyen:


a. Riesgos técnicos: ocasionados por el desarrollo de tecnologías nuevas o no probadas
b. Riesgos financieros: producidos por la exposición financiera causada por la inversión en el proyecto
c. Riesgos de seguridad: ocasionados por el bienestar de los usuarios o desarrolladores del proyecto
d. Riesgos de calidad: producidos por el buen nombre o reputación de la empresa en razón de la calidad
del proyecto terminado
e. Riesgos legales: exposición potencial a demandas u obligaciones legales por cumplir
2. Comercial: factores que reflejan el potencial de mercado del proyecto, e incluyen:
a. Rendimiento esperado de la inversión
b. Retorno de la inversión
c. Cuota de mercado potencial
d. Dominio del mercado a largo plazo
e. Desembolso inicial
f. Capacidad de generar futuros negocios/nuevos mercados
3. Aspectos de funcionamiento interno: factores que tienen un efecto en las operaciones internas de la em-
presa, e incluyen:
a. Necesidad de desarrollar/capacitar a los empleados
b. Cambio en el tamaño o la composición de la fuerza laboral
c. Cambio en el entorno físico
d. Cambio en las operaciones de manufactura o servicio resultante del proyecto
4. Otros factores, que incluyen:
a. Protección de patentes
b. Impacto en la imagen de la empresa
c. Ajuste estratégico

información pertinente que desempeña un papel importante. En segundo lugar, hay que integrar en todo modelo
de decisión factores objetivos y subjetivos. Podemos formarnos opiniones basadas en datos objetivos pero también
podemos obtener modelos de decisión complejos basados en consideraciones subjetivas. Vale la pena reconocer
que hay lugar para ambas entradas, subjetivas y objetivas, en cualquier modelo de screening.

3.2  ENFOQUES PARA EL SCREENING Y SELECCIÓN DE PROYECTOS


Un modelo screening de proyectos que genera información útil para opciones de proyectos de manera
oportuna, útil y a un costo aceptable puede ser una herramienta valiosa en una organización para tomar
decisiones óptimas entre numerosas alternativas.5 Con estos criterios en mente, vamos a considerar algunas
de las técnicas más comunes de selección de proyectos.

Método uno: modelo lista de verificación


El método más sencillo para la selección y screening de los proyectos es el desarrollo de una lista de verifi-
cación, o una lista de criterios pertinentes a nuestra selección de los proyectos, y luego aplicarlos a distintos
proyectos posibles. Por ejemplo, supongamos que ,en nuestra compañía, los principales criterios de selección
son el costo y la velocidad del mercado. Debido a nuestro modelo estratégico competitivo y a la industria en
que nos encontramos, estamos a favor de proyectos de bajo costo que pueden llevarse al mercado dentro de
un año. Queremos evaluar cada proyecto posible respecto a estos dos criterios y seleccionar el proyecto que
más les satisfaga. Sin embargo, dependiendo del tipo y tamaño de nuestros proyectos potenciales, es posible
que tengamos que considerar literalmente docenas de criterios pertinentes. Al decidir entre varias opciones
de desarrollo de nuevos productos, la empresa debe sopesar una serie de asuntos, entre ellos los siguientes:
• El costo de ejecución: ¿cuál es el presupuesto razonable?
• Retorno potencial de la inversión: ¿qué tipo de rendimiento se puede esperar? ¿Cuál es el periodo pro-
bable de retorno?
80 Capítulo 3  •  Selección de proyectos y gerencia del portafolio

• Grado de riesgo del nuevo emprendimiento: ¿el proyecto implica la necesidad de crear una tecnología
de nueva generación? ¿Qué tan arriesgado es el proyecto, en términos de alcanzar las especificaciones
previstas?
• Estabilidad del proceso de desarrollo: ¿son estables la organización y el equipo del proyecto? ¿Podemos
esperar que este proyecto enfrente recortes de fondos o pérdida de personal clave, como patrocinado-
res de la alta gerencia?
• Gobierno o interferencia de los interesados: ¿el proyecto es objeto de supervisión gubernamental que
podrían interferir con su desarrollo? ¿Es posible que otros interesados se opongan al proyecto e inten-
ten bloquear su terminación? Por ejemplo, grupos ecologistas o uno de los interesados “interventores”,
pueden tener una larga historia de oposición a los proyectos de desarrollo de recursos naturales y tra-
bajar en contra de los objetivos del proyecto.6
• Durabilidad del producto y del futuro potencial de mercado: ¿este proyecto representa una oportuni-
dad para una sola vez o podría ser el precursor de las futuras oportunidades? Una empresa de desarro-
llo de software podría, por ejemplo, desarrollar una aplicación para un cliente con la esperanza de que
el desempeño exitoso en este proyecto daría lugar a futuros negocios. Por otro lado, el proyecto podría
ser simplemente una oportunidad única con poco potencial para el trabajo futuro con el cliente.
Esta es solo una lista parcial de criterios relevantes cuando estamos seleccionando entre las alternativas
del proyecto. Una lista de verificación para la evaluación de las oportunidades de proyectos es un mecanismo
bastante simple para registrar las opiniones y fomentar el debate. Por tanto, listas de verificación pueden uti-
lizarse mejor en un ambiente de consenso grupal, como un método para iniciar una conversación, estimular
el debate y el intercambio de opiniones y poner de relieve las prioridades del grupo.

EJEMPLO 3.1 Lista de verificación

Supongamos que SAP Corporation, una empresa líder en la industria de aplicaciones de software empre-
sarial, está interesada en el desarrollo de un nuevo paquete de aplicaciones para la gestión de inventario
y control de embarque. Se está tratando de decidir qué proyecto seleccionar entre un conjunto de cuatro
opciones. Con base en experiencias comerciales pasadas, la compañía considera que los criterios de selección
más importantes para su elección son el costo, potencial de ganancias, tiempo en el mercado y los riesgos de
desarrollo. El cuadro 3.2 muestra un modelo de una lista simple de verificación con solo cuatro opciones de

CUADRO 3.2  Modelo simplificado de lista de verificación para selección de proyectos

Calificación del criterio

Proyecto Criterio Alta Media Baja

Alfa Costo X
Potencial de ganancias X
Tiempo en el mercado X
Riesgos de desarrollo X
Beta Costo X
Potencial de ganancias X
Tiempo en el mercado X
Riesgos de desarrollo X
Gamma Costo X
Potencial de ganancias X
Tiempo en el mercado X
Riesgos de desarrollo X
Delta Costo X
Potencial de ganancias X
Tiempo en el mercado X
Riesgos de desarrollo X
3.2  Enfoques para el screening y selección de proyectos 81

proyectos y los cuatro criterios de decisión. Evaluamos cada criterio (en categorías alta, media o baja) con el
fin de ver qué proyecto acumula los mayores criterios y, por tanto, considerarse como la mejor opción.
SOLUCIÓN
Con base en este análisis, el proyecto Gamma es la mejor alternativa, pues maximiza los criterios claves de
costo, potencial de ganancias, tiempo en el mercado y los riesgos de desarrollo.

Las fallas de un modelo como el que se muestra en el cuadro 3.2, incluyen la naturaleza subjetiva de
las calificaciones alta, media y baja. Estos términos no son exactos y están sujetos a interpretaciones erróneas
o malentendidos. Los modelos de lista de verificación también fallan en resolver temas de relación de inter-
cambio o trade-off. ¿Qué pasa si nuestros criterios están diferencialmente ponderados? ¿Qué pasaría si algu-
nos criterios son más importantes que otros? ¿Cómo, relativa o ponderada, la importancia afectará nuestra
decisión final? Por ejemplo, consideremos el tiempo en el mercado como criterio primordial. ¿El proyecto
Gamma, que está clasificado según este criterio, resultará “mejor” que los proyectos Beta y Delta, los cuales
están clasificados con calificación alta en tiempo en el mercado, aunque con calificación más baja en otros
criterios, menos importantes? ¿Estamos dispuestos a hacer un trade-off, aceptando bajo el tiempo en el mer-
cado con el fin de obtener mayores beneficios en el costo, potencial de ganancias y riesgos de desarrollo?
Debido a que el modelo de lista simple de verificación no responde satisfactoriamente estas pregun-
tas, a continuación veremos un modelo de screening más complejo en el que se distinguen los criterios más
importantes de los menos importantes y se le asigna a cada uno un peso simple.

Método dos: modelo de puntuación simplificado


En el modelo de puntuación simplificado, cada criterio se clasifica en función de su importancia relativa. Por
tanto, nuestra selección de proyectos será reflejo de nuestro deseo por maximizar el efecto de ciertos criterios
en la decisión. En nuestra lista simplificada se le asigna un peso específico a cada uno de los cuatro criterios:

Criterio Importancia relativa


Tiempo en el mercado 3
Potencial de ganancias 2
Riesgos de desarrollo 2
Costo 1

Ahora vamos a reconsiderar la decisión que tomamos con la lista básica de control que se ilustra en el cuadro 3.2.

EJEMPLO 3.2 Modelos de puntuación

SAP Corporation trata de determinar el proyecto óptimo para financiar, usando los valores ponderados
desarrollados anteriormente. Como se puede ver en el cuadro 3.3, aunque adicionar un componente a nues-
tra lista de verificación simplificada complica nuestra decisión, nos proporciona un modelo más preciso de
screening que refleja más nuestro deseo de enfatizar unos criterios y no otros.

SOLUCIÓN
En el cuadro 3.3, los números en la columna titulada importancia relativa especifican los valores numéricos
que le hemos asignado a cada criterio: el tiempo en el mercado siempre recibe un valor de 3, el potencial de
ganancias un valor de 2, el riesgo de desarrollo un valor de 2 y el costo un valor de 1. A continuación, asigna-
mos valores relativos a cada una de nuestras cuatro dimensiones.
Los números de la columna titulada Puntaje, remplazan las X del cuadro 3.2 con los valores de las
puntuaciones asignadas:

Alto = 3
Medio = 2
Bajo = 1
82 Capítulo 3  •  Selección de proyectos y gerencia del portafolio

CUADRO 3.3  Modelo de puntación simplificado

(A) (B) (A) × (B)


Importancia Puntaje
Proyecto Criterio relativa Puntaje relativo
Alfa
Costo 1 3  3
Potencial de ganancias 2 1  2
Riesgos de desarrollo 2 1  2
Tiempo en el mercado 3 2  6
  Puntaje total 13
Beta
Costo 1 2  2
Potencial de ganancias 2 2  4
Riesgos de desarrollo 2 2  4
Tiempo en el mercado 3 3  9
  Puntaje total 19
Gamma
Costo 1 3  3
Potencial de ganancias 2 3  6
Riesgos de desarrollo 2 3  6
Tiempo en el mercado 3 1  3
  Puntaje total 18
Delta
Costo 1 1  1
Potencial de ganancias 2 1  2
Riesgos de desarrollo 2 2  4
Tiempo en el mercado 3 3  9
  Puntaje total 16

En el proyecto Alfa, por ejemplo, la calificación alto dada al costo se convierte en un 3 en el cuadro 3.3,
porque aquí alto está valorado en 3. Del mismo modo, la calificación media dada a tiempo en el mercado en
el cuadro 3.2 se convierte en un 2. Pero note lo que sucede cuando calculamos los números en la columna
denominada Puntaje relativo. Cuando multiplicamos el valor numérico de Costo (1) por su calificación de
Alto (3), se obtiene una puntuación ponderada de 3. Pero cuando se multiplica el valor numérico de Tiempo
en el mercado (3) por su calificación de Medio (2), se obtiene un Puntaje relativo de 6. Una vez le sumamos
los números en la columna de Puntaje relativo para cada proyecto en el cuadro 3.3 y examinamos los totales,
el Proyecto Beta (con un total de 19) es la mejor alternativa, en comparación con las otras opciones: proyecto
Alfa (con un total de 13), proyecto Gamma (con un total de 18), y proyecto Delta (con un total de 16).

Por tanto, el modelo de puntuación simple consta de los siguientes pasos:

• Asignar pesos de importancia a cada criterio: el primer paso es el desarrollo de la lógica de la dife-
renciación entre los distintos niveles de importancia y crear un sistema para determinar las ponde-
raciones correspondientes a cada criterio. Basarse en un juicio colectivo puede ayudar a validar las
razones de la determinación de los niveles de importancia. El equipo también puede designar algunos
criterios como elementos obligatorios “debe”. Las preocupaciones de seguridad, por ejemplo, pueden
estipularse como no negociables. En otras palabras, todos los proyectos tienen que lograr un nivel de
seguridad aceptable o no seguirán considerándose.
3.2  Enfoques para el screening y selección de proyectos 83

• Asignar valores de puntuación para cada criterio, en función de su calificación (Alto = 3,


Medio = 2, Bajo= 1): la lógica para la asignación de valores de puntuación es a menudo
un aspecto sensible, al crear diferencias dentro de las distintas puntuaciones. Algunos equi-
pos, por ejemplo, prefieren ampliar la gama de posibles valores, es decir, mediante el uso de
una escala de 1 a 7 en lugar de una escala de 1 a 3, con el fin de asegurar una distinción más
clara entre las puntuaciones y, por tanto, entre las opciones de proyectos. Tales decisiones
variarán de acuerdo con el número de criterios que se aplican y, tal vez, con la experiencia
de los miembros del equipo en la exactitud de los resultados producidos por un enfoque
dado de screening y selección.
• Multiplicar pesos de importancia con los resultados para obtener una puntuación pon-
derada en cada criterio: El puntaje ponderado refleja tanto el valor que el equipo le
asigna a cada criterio como las calificaciones dadas a cada criterio del proyecto.
• Sumar las puntuaciones ponderadas para llegar a una puntuación global del proyecto:
La puntuación final para cada proyecto representa la suma de todos sus criterios ponderados.

La compañía farmacéutica Hoechst Marion Roussel utiliza un modelo de puntuación en la


selección de proyectos que identifica no solamente cinco criterios principales ­—utilidad, ajuste
con la estrategia empresarial, el apalancamiento estratégico, la probabilidad de éxito comercial y
la probabilidad de éxito técnico­— sino también una serie de subcriterios más específicos. Cada
uno de estos 19 subcriterios se califica en una escala de 1 a 10. La puntuación correspondiente a
cada categoría se calcula mediante el promedio de las puntuaciones de cada criterio. El puntaje
final del proyecto se determina sumando la puntuación media de cada una de las cinco subcate-
gorías. Hoechst ha tenido un gran éxito con este modelo de calificación, en el establecimiento de
prioridades de los proyectos como en la toma de decisiones go/no go.7
El modelo de puntuación simple, como mecanismo de selección de proyectos, tiene
algunas ventajas. Primera, es fácil de usar para encadenar las metas estratégicas críticas para la
empresa a las varias alternativas del proyecto. En el caso de la compañía farmacéutica Hoechst, la
empresa ha asignado varias categorías a las metas estratégicas críticas para las opciones de pro-
yectos, incluidos ajuste con la estrategia de negocio y el apalancamiento estratégico. Estas metas
estratégicas críticas llegan a ser un obstáculo crítico para todos los nuevos proyectos alternativos.
Segunda, el modelo simple de puntuación es fácil de comprender y utilizar. Con una lista de
criterios claves, opciones de evaluación (alto, medio y bajo) y los puntajes asociados, los altos
directivos pueden comprender rápidamente cómo emplear esta técnica.

Limitaciones de los modelos de puntuación


El modelo puntuación simple ilustrado aquí es una versión abreviada y sencilla del enfoque pon-
derado de puntuación. En general, los modelos de puntuación tratan de imponer alguna estruc-
tura en el proceso de toma de decisiones mientras, al mismo tiempo, se combinan múltiples
criterios.
Sin embargo, la mayoría de los modelos de puntuación comparten algunas limitaciones.
Una escala de 1 a 3 puede ser intuitivamente atractiva y fácil de aplicar y comprender, pero no es
muy precisa. Desde la perspectiva de una escala matemática, es simplemente erróneo tratar las
evaluaciones sobre una escala de números reales que se pueden multiplicar y sumar. Si 3 significa
alto y 2 medio, sabemos que 3 es mejor que 2, pero no por cuánto. Por otra parte, no podemos
suponer que la diferencia entre 3 y 2 sea la misma que la diferencia entre 2 y 1. Así, en en el
cuadro 3.3, si la puntuación para el proyecto Alfa es 13 y para el proyecto Beta es 19, ¿podemos
suponer que Beta es 46% mejor que Alfa? Infortunadamente, no. Los críticos de los modelos de
puntuación argumentan que su facilidad de uso puede enceguecer a los usuarios novatos de los
falsos supuestos que a veces subyacen.
Desde una perspectiva de gestión, otro inconveniente de los modelos de puntuación es el
hecho de que dependen de la pertinencia de los criterios de selección y de la exactitud del peso
asignado. En otras palabras, ellos no aseguran que exista una relación razonable entre los crite-
rios y los objetivos de negocio que impulsaron el proyecto, inicialmente.
He aquí un ejemplo. Como una forma de selección de proyectos, el comité de dirección
de sistemas de información de un gran banco adoptó tres criterios: contribución a la calidad,
84 Capítulo 3  •  Selección de proyectos y gerencia del portafolio

desempeño financiero y servicio. La estrategia del banco se centra en la retención de clientes, pero los criterios
seleccionados por el comité no reflejan este hecho. Como resultado, un proyecto destinado a mejorar el servi-
cio a nuevos mercados potenciales podría puntuar alto en servicio a pesar de que no serviría para los clientes
existentes (personas que el banco quiere retener). Téngase en cuenta, también, que los criterios de calidad y
servicio pueden solaparse, lo que lleva a los gerentes a tenerlos en cuenta dos veces y sobreestimar el valor
de algunos factores.8 Por tanto, el banco ha empleado un enfoque de selección de proyectos que no logra los
fines deseados ni coincide con sus metas estratégicas generales.

Método tres: el proceso de jerarquía analítica


El proceso de jerarquía analítica (Analytical Hierarchy Process: AHP) fue desarrollado por el doctor
Thomas Saaty9 para abordar muchos de los problemas técnicos y de gestión con frecuencia asociados a la
toma de decisiones, a través de los modelos de puntuación. El AHP, un método cada vez más popular en la
selección eficaz de proyectos, es un proceso que consta de cuatro pasos:

ESTRUCTURACIÓN DE LA JERARQUÍA DE CRITERIOS  El primer paso consiste en construir una jerarquía de


criterios y subcriterios. Supongamos, por ejemplo, que el comité directivo de IT de una empresa ha seleccio-
nado tres criterios para la evaluación de proyectos alternativos: (1) beneficios financieros, (2) contribución a la
estrategia; (3) contribución a la infraestructura de IT. El criterio beneficios financieros, centrado en los beneficios
tangibles del proyecto, se subdivide a su vez en beneficios a largo plazo y a corto plazo. Contribución a la estrate-
gia, un factor intangible, se subdivide en tres subcriterios: (a) aumento de la participación en el mercado para el
producto X; (b) retención de los clientes existentes de producto Y; (c) mejora en la gestión de costos.
En el cuadro 3.4 se desglosan todos estos criterios. Tenga en cuenta que la subdivisión de criterios
pertinentes, en una jerarquía significativa, les ofrece a los gerentes un método racional para la selección y
clasificación de prioridades. Los criterios de orden superior, como contribución a la estrategia, se pueden
dividir en grupos discretos de necesidades de apoyo, como participación en el mercado, retención de clientes
y gestión de costos, y constituye así una jerarquía de alternativas que simplifica las cosas. Además que la jerar-
quía puede reflejar la estructura de la estrategia de la organización y sus factores críticos de éxito, también
proporciona una forma de seleccionar y justificar los proyectos en función de su coherencia con los objetivos
de negocio.10 Esto ilustra cómo se pueden utilizar los aspectos estratégicos significativos y factores críticos
para establecer de forma lógica los criterios de selección y su ponderación relativa.
Recientemente, una gran empresa en Estados Unidos. utilizó el AHP para clasificar más de un centenar
de propuestas de proyectos de varios millones de dólares. Debido a que el primer paso en el uso del AHP es
establecer criterios claros para la selección, diez gerentes de disciplinas variadas, incluidas finanzas, marketing,
sistemas de información de gestión y operaciones, permanecieron un día entero estableciendo la jerarquía de
criterios. Su reto fue determinar los criterios claves de éxito que debían utilizarse para guiar la selección de pro-
yectos, en particular cómo estos diversos criterios se relacionan entre sí (peso relativo). Ellos encontraron que,
además de definir y desarrollar claramente los criterios para la evaluación de proyectos, el proceso también
producía una visión más coherente y unificada de la estrategia organizacional.

ASIGNACIÓN DE PESOS A LOS CRITERIOS  El segundo paso en la aplicación de AHP consiste en asignar
pesos a los criterios previamente definidos y, cuando sea necesario, dividir el peso total del criterio entre los

CUADRO 3.4  Jerarquía de criterios de selección

Primer nivel Segundo nivel


1. Beneficios financieros 1A: corto plazo
1B: largo plazo
2. Contribución a la estrategia 2A: aumento de la participación en el
mercado del producto X
2B: retención de los clientes existentes de
producto Y
2C: mejora en la gestión de costos
3. Contribución a la infraestructura de IT
3.2  Enfoques para el screening y selección de proyectos 85

Sistemas de información de
puntuación para propuestas de proyectos
FIGURA 3.1  Ejemplo de AHP con
puntuación para los criterios de selección Objetivo
(1.000)
más destacados
Financieros Estrategia Tecnología
Fuente: J. K. Pinto and I. Millet. de información
(0.520) (0.340) (0.140)
(1999). Successful Information System
Implementation: The Human Side, 2nd ed., A corto plazo Retención Pobre
figura en la página 76. Newtown Square, A largo plazo Participación Mediocre
PA: Project Management Institute. Derechos en el mercado
Bueno
de autor y todos los derechos reservados. El Gestión
Muy bueno
de costos
material de esta publicación ha sido reprodu- Excelente
cido con permiso del PMI.

subcriterios. Mian y Dai11 y otros han recomendado el llamado enfoque de comparación por pares para pon-
deración, en el que cada criterio se compara con cada uno de los demás. Este procedimiento, argumentan los
investigadores, facilita una ponderación más precisa, ya que les permite a los gerentes centrarse en una serie
de intercambios relativamente simples, es decir, dos criterios a la vez.
La jerarquía simplificada en la figura 3.1 muestra la distribución de los pesos de los criterios en los mismos
tres criterios principales que utilizamos en el cuadro 3.4. Como muestra la figura 3.1, financieros (es decir, bene-
ficios financieros) recibieron un valor de ponderación de 52%, que se divide entre los beneficios a corto plazo
(30%) y los beneficios a largo plazo (70%). Esta configuración significa que los beneficios financieros a largo plazo
reciben una ponderación global de (0.52)  (0.7) = 36.4%
La asignación jerárquica de criterios y la división de los pesos resuelve el problema de la doble contabili-
dad en los modelos de puntuación. En esos modelos, criterios como el servicio, la calidad y la satisfacción de los
clientes pueden ser factores separados o que se superponen, dependiendo de los objetivos de la organización.
Como resultado, muy poco o demasiado peso puede asignársele a un criterio dado. Con AHP, sin embargo,
estos factores se agrupan como subcriterios y comparten el peso de un criterio de nivel superior común.

ASIGNACIÓN DE VALORES NUMÉRICOS PARA LAS DIMENSIONES DE EVALUACIÓN  En nuestro tercer


paso, una vez establecida la jerarquía, se puede utilizar el enfoque de comparación por pares para asignar
valores numéricos a las dimensiones de nuestra escala de evaluación. La figura 3.2 es una escala de evaluación
con cinco dimensiones: Pobre, Mediocre, Bueno, Muy Bueno y Excelente. En esta figura, para los propósitos
de la ilustración, hemos asignado los valores de 0,0; 0,10; 0,30; 0,60 y 1,00, respectivamente. Naturalmente,
podemos cambiar estos valores según se requiera. Por ejemplo, si una empresa quiere indicar una mayor
discrepancia entre Mediocre, los gerentes pueden aumentar el rango entre estas dos dimensiones. Mediante
el ajuste de los valores para adaptarse a propósitos específicos, los gerentes evitan asumir que las diferencias
entre números en una escala de, por ejemplo, 1 a 5 son iguales, suponiendo que la diferencia entre 4 y 5 es la
misma que la diferencia entre los 3 y 4. Con el enfoque de AHP, el “mejor” resultado recibe una puntuación
perfecta de 1.00 y todos los demás valores representan alguna proporción de esta.
Cuando sea necesario, se les recomienda a los gerentes de proyectos aplicar diferentes escalas para cada
criterio. Tenga en cuenta, por ejemplo, que en la figura 3.2 se utilizan puntos en una escala que va desde
Pobre a Excelente. Supongamos, sin embargo, que entrevistamos a un candidato para el equipo del proyecto

Nominal Prioridad Gráfica de barras


Pobre 0.00000 0.000
Mediocre 0.10000 0.050
Bueno 0.30000 0.150
Muy bueno 0.60000 0.300
Excelente 1.00000 0.500
Total 2.00000 1.000

FIGURA 3.2  Asignación de valores numéricos a las etiquetas


Fuente: J. K. Pinto and I. Millet. (1999). Successful Information System
Implementation: The Human Side, 2nd ed., figura en la página 77. Newtown
Square, PA: Project Management Institute. Derechos de autor y todos los
derechos reservados. El material de esta publicación ha sido reproducido con
permiso del PMI.
86 Capítulo 3  •  Selección de proyectos y gerencia del portafolio

y uno de los elementos es “Nivel de educación”. Evidentemente, el uso de una escala que va de Pobre a
Excelente no tiene sentido, por lo que sería ajustar la escala para que sea significativa; por ejemplo, usar nive-
les como “Educación media”, “Estudios universitarios”, “Graduado de la universidad”, y así sucesivamente.
La asignación de pesos a través de las dimensiones dadas nos da una comprensión sólida de nuestros méto-
dos y metas por los cuales estamos comparando oportunidades para alcanzarlos.

EVALUACIÓN DE PROPUESTAS DE PROYECTOS  En nuestro último paso, multiplicamos la evaluación


numérica del proyecto por los pesos asignados a los criterios de evaluación y luego sumamos los resultados
de todos los criterios. La figura 3.3 muestra cómo cinco proyectos potenciales podrían evaluarse por un pro-
grama de AHP ofrecido por Expert Choice, un software de soporte para las decisiones.12 He aquí cómo leer
las características claves de la hoja de cálculo:
• La segunda línea especifica el valor asignado a cada una de las cinco calificaciones posibles (desde
Pobre = 1 = .000 hasta Excelente 5 = 1.000).
• La cuarta fila especifica los cinco criterios de decisión y sus pesos relativos (Finanzas/Corto plazo =
.1560, Estrategia/Gestión de costos = .0816, y así sucesivamente). (Tenga en cuenta que los tres criterios
se han dividido en seis subcriterios).
• La segunda columna muestra los cinco proyectos (Proyecto perfecto, Alineado, etcétera).
• La tercera columna titulada “Total” da un valor para cada alternativa. Este número se obtiene multipli-
cando cada evaluación por el peso del criterio y sumando los resultados en todos los criterios de evaluación.
Para ilustrar cómo se han obtenido los cálculos, tomemos el proyecto Alineado como ejemplo.
Recuerde que cada calificación (Excelente, Muy bueno, Bueno, etc.) lleva consigo una puntuación numérica.
Estos resultados, cuando se multiplican por la evaluación del criterio y se suman, se obtiene:

^ .1560 h^ .3 h + ^ .3640 h^ 1.0 h + ^.1020 h^.3 h + ^ .1564 h^ 1.0 h + ^.0816 h^.3 h + ^ .1400 h^ 1.0 h = .762

El Proyecto perfecto, como otro ejemplo, fue calificado Excelente en las seis dimensiones y por ello recibió
una puntuación total de 1.000. Además, compara las evaluaciones de las opciones de proyectos Alineado y
No alineado. Aunque ambos proyectos recibieron igual calificación, Excelente y Bueno, el proyecto Alineado
era claramente preferible porque estaba clasificado más alto en criterios vistos como más importante y, por
tanto, más ponderados.
A diferencia de los resultados de los modelos típicos de puntuación, las puntuaciones de AHP son signi-
ficativas. El proyecto Alineado, por ejemplo, calificado con 0.762, es casi tres veces mejor que el proyecto Mixto,
con su puntaje de 0.284. Esta característica—la capacidad de cuantificar proyectos alternativos superiores— per-
mite que gerentes de proyectos utilicen las puntuaciones de AHP como entrada para otros cálculos. Podríamos,
por ejemplo, ordenar los proyectos de acuerdo con los coeficientes de total de sus costos de desarrollo, según

A corto
Finanzas
plazo

Pobre Mediocre Bueno Muy bueno Excelente


1 (.000) 2 (.100) 3 (.300) 4 (.600) 5 (1.000)

Finanzas Estrategia Tecnología


A corto A largo Participación Retención Gestión
Alternativas Total plazo plazo en el mercado de costos

.1560 .3640 .1020 .1564 .0816 .1400


1 Proyecto perfecto 1.000 Excelente Excelente Excelente Excelente Excelente Excelente
2 Alineado 0.762 Bueno Excelente Bueno Excelente Bueno Excelente
3 No alineado 0.538 Excelente Bueno Excelente Bueno Excelente Bueno
4 Todo muy bien 0.600 Muy bueno Muy bueno Muy bueno Muy bueno Muy bueno Muy bueno
5 Mixto 0.284 Pobre Mediocre Bueno Muy bueno Excelente Bueno
6
7
8
9
10

FIGURA 3.3  Hoja de cálculo para evaluación de proyectos


Fuente: J. K. Pinto and I. Millet. (1999). Successful Information System
Implementation: The Human Side, 2nd ed., figura en la página 78. Newtown
Square, PA: Project Management Institute. Derechos de autor y todos los
derechos reservados. El material de esta publicación ha sido reproducido con
permiso del PMI.
3.2  Enfoques para el screening y selección de proyectos 87

las puntuaciones de AHP. Digamos que, con base en esta relación, encontramos que el proyecto No alineado es
más barato que el proyecto Alineado. Este hallazgo podría sugerir que, desde una perspectiva de costo/benefi-
cio, el proyecto No alineado ofrece una mejor alternativa que el proyecto Alineado.
La metodología AHP puede mejorar sustancialmente el proceso de elaboración de propuestas de pro-
yectos. En las empresas que han incorporado el análisis AHP, las nuevas propuestas de proyectos deben
contener, como parte de su información básica, una sofisticada lista AHP para el proyecto propuesto, las
alternativas y los resultados esperados. El proceso de jerarquía analítica ofrece una verdadera ventaja sobre
los modelos tradicionales de puntuación, principalmente porque reduce muchos de los problemas técnicos y
de gestión que afectan a estos enfoques.
Sin embargo, el AHP tiene algunas limitaciones. Primera, la investigación actual sugiere que el modelo
no tiene en cuenta adecuadamente “utilidad negativa”; es decir, ciertas opciones de elección no contribu-
yen positivamente a los objetivos de la decisión, sino a resultados negativos. Por ejemplo, suponga que su
compañía identificó una gran opción de proyecto, pero es muy costosa. Como resultado, la selección de este
proyecto no es realmente una opción, ya que la inversión sería demasiado alta. Sin embargo, utilizando el
AHP, primero tendría que sopesar todos los elementos positivos, desarrollar su puntaje de screening y luego
comparar este resultado contra los aspectos negativos, como el costo. El resultado puede conducir a sesgos
en los cálculos de puntuación del proyecto.13 Segunda limitación: el AHP requiere que todos los criterios
sean totalmente identificados y contabilizados al comienzo del proceso de selección. Miembros poderosos
de la organización con agendas políticas o que desean que ciertos proyectos continúen pueden resistirse a un
proceso de selección tan abierto.

Método cuatro: modelos de perfil


Los modelos de perfil les permiten a los gerentes determinar opciones de riesgo/rentabilidad para las distin-
tas alternativas y seleccionar el proyecto que maximiza el rendimiento mientras se encuentre dentro de un
rango de riesgo mínimo aceptable. “Riesgo”, por supuesto, es una apreciación subjetiva: puede ser difícil lle-
gar a un acuerdo global sobre el nivel de riesgo asociado a un proyecto determinado. No obstante, el modelo
de perfil ofrece otra forma de evaluación, screening y comparación de proyectos.14
Volvamos a nuestro ejemplo de screening de proyectos en SAP Corporation. Supongamos que, en
lugar de las cuatro alternativas para el nuevo proyecto de software, que comentamos anteriormente, la firma
había identificado seis candidatos para el desarrollo. Para simplificar, los gerentes decidieron centrarse en
dos criterios, riesgo y utilidad.
En la figura 3.4 se ilustran las seis alternativas de proyecto mostrando el potencial de Retorno sobre
el eje x y la percepción del Riesgo en el eje y. Según el costo de capital de la empresa, vamos a especificar
alguna tasa deseada de rentabilidad mínima. A todos los proyectos se le asigna un valor factor de riesgo y

X6
Riesgo
máximo deseado

X2
Riesgo

X4 X5

Frontera
eficiente
X3
X1

Retorno Retorno
mínimo deseado deseado

FIGURA 3.4  Modelo de perfil


88 Capítulo 3  •  Selección de proyectos y gerencia del portafolio

se grafica en relación con el riesgo máximo que la empresa está dispuesta a asumir. La figura 3.4, por tanto,
representa gráficamente, en un modelo de perfil, cada una de nuestras seis alternativas. (Los valores de riesgo
se han creado simplemente con fines ilustrativos). En nuestro ejemplo, SAP puede emplear una variedad de
medidas para evaluar el posible retorno ofrecido por este proyecto, incluido el análisis de flujo de efectivo
descontado y la de tasa interna de retorno. Asimismo, es cada vez más común para las empresas cuantificar y
evaluar los riesgos de los distintos proyectos, lo que nos permite trasladarnos a lo largo del eje y. La clave está
en el empleo de criterios de evaluación y métodos de cuantificación idénticos para todos los proyectos que se
perfilan en el gráfico. Cuando los riesgos del proyecto son únicos o no tenemos ninguna manera de comparar
los riesgos relativos proyecto a proyecto, es imposible graficar con precisión las alternativas del proyecto.
En la figura 3.4, vemos que los proyecto X2 y X3 tienen similares tasas esperadas de retorno. Sin embargo,
el proyecto X3 representa una mejor opción. ¿Por qué? Porque SAP puede lograr la misma tasa de retorno del
proyecto X3 con el proyecto X2, pero con menos riesgo. Asimismo, el proyecto X5 es una opción superior a X4:
a pesar de que tienen niveles de riesgo similares, X5 ofrece mayor rentabilidad sobre la inversión. Por último,
mientras el proyecto X6 ofrece la mayor rentabilidad posible, lo hace en el más alto nivel de riesgo.
El modelo de perfil se basa en un concepto ampliamente asociado con la gestión financiera y el análisis de
inversión: la frontera eficiente. En la gerencia de proyectos, la frontera eficiente es el conjunto de opciones de por-
tafolio de proyectos que ofrece un retorno máximo para cada nivel de riesgo o riesgo mínimo para todos los niveles
de rentabilidad.15 Cuando nos fijamos en el modelo de perfil de la figura 3.4, observamos que ciertas opciones (X1,
X3, X5, X6) se encuentran a lo largo de una línea imaginaria equilibrando el riesgo óptimo con las combinaciones
de retorno. Otras (X2 y X4), sin embargo, son alternativas menos deseables y serían, por tanto, consideradas opcio-
nes inferiores. La frontera eficiente es una guía para la toma de decisiones mediante el establecimiento del nivel de
umbral de la relación riesgo/retorno, contra el cual todas las opciones futuras de proyectos deben evaluarse.
Una de las ventajas del modelo de perfil es que ofrece otra forma para comparar las alternativas del pro-
yecto, esta vez en términos de la relación riesgo/trade-off. A veces es difícil de evaluar y comparar proyec-
tos sobre la base de modelos de calificación u otros enfoques cualitativos. El modelo de perfil, sin embargo,
les ofrece a los gerentes la oportunidad de graficar los rendimientos potenciales, mientras toman en cuenta el
riesgo que acompaña a cada alternativa. Por tanto, los modelos de perfil nos dan otra opción para la eliminación
de las alternativas que o bien sean una amenaza por su demasiado riesgo o prometan muy poco a cambio.
Por otro lado, los modelos de perfil también tienen desventajas:
1. Limitan los criterios de decisión a solo dos: riesgo y rentabilidad. A pesar de que una serie de factores,
incluidos seguridad, calidad y confiabilidad, puede venir bajo el título de “riesgo”, el enfoque necesa-
riamente limita a quien toma la decisión a un pequeño conjunto de criterios.
2. Con el fin de ser evaluados en términos de una frontera eficiente, algún valor debe asignársele al riesgo.
El rendimiento esperado es una medida que se da naturalmente mediante un estimativo numérico.
Pero debido a que el riesgo no se puede cuantificar fácilmente, resulta engañoso designar artificial-
mente un valor al “riesgo” para la comparación entre las opciones de proyecto.

EJEMPLO 3.3 Modelo de perfil

Veamos un ejemplo sencillo. Supongamos que nuestra empresa ha identificado dos nuevas alternativas de
proyecto y queremos utilizar el análisis de riesgo/retorno, para determinar cuál de los dos proyectos encaja
mejor con nuestro actual portafolio de proyectos. Evaluamos la rentabilidad en términos del margen de
beneficio que esperamos lograr en los proyectos. El riesgo se evalúa en nuestra compañía según cuatro ele-
mentos: (1) riesgo técnico: el desafío técnico del proyecto; (2) riesgo de capital: monto invertido en el pro-
yecto; (3) riesgo de seguridad: fracaso del proyecto; (4) riesgo de buen nombre: perder clientes o disminuir la
imagen de nuestra empresa. La magnitud de cada uno de estos riesgos se determina aplicando una escala de
riesgo “ alto, medio y bajo” en la que 1 = bajo, 2 = medio y 3 = alto.
Después de revisar la rentabilidad probable y la evaluación de su grado de riesgo, para ambos proyectos
se concluye lo siguiente:

Riesgo Potencial de retorno


Proyecto Saturno 10 23%
Proyecto Mercurio  6 16%
3.3  Modelos financieros 89

12
Riesgo
10 Saturno
máximo
X4
permitido
8 Frontera eficiente
X3
Riesgo
6 Mercurio
X2

4
X1

6% 8% 10% 12% 16% 20% 24% 28% 32%


Retorno Retorno
mínimo
deseado
FIGURA 3.5  Frontera eficiente de nuestra empresa

La figura 3.5 muestra la frontera eficiente de nuestra empresa para el portafolio actual de proyectos.
¿Cómo podemos evaluar el atractivo del proyecto Saturno o del proyecto Mercurio?
SOLUCIÓN
Cuando consideramos las dos opciones, proyectos Saturno y Mercurio, en términos de su riesgo proyectado
y retorno, podemos ubicarlos en nuestro modelo de perfil en relación con otros proyectos que estamos lle-
vando a cabo. La figura 3.5 ilustra la colocación de las dos nuevas opciones de proyecto. Tenga en cuenta que
el proyecto Saturno, incluso dentro de nuestro límite máximo de riesgo, no funciona tan bien como el resto
de proyectos de nuestro portafolio actual (tiene una calificación de riesgo más alta para el retorno proyectado
que otros proyectos comparables). Por otro lado, el proyecto Mercurio nos ofrece una tasa de rentabilidad
de 16% y un menor nivel de riesgo que la actual frontera eficiente, lo que sugiere que este proyecto es una
opción atractiva y mejor que el proyecto Saturno.

3.3  MODELOS FINANCIEROS


Otra serie importante de los modelos se basa en el análisis financiero para tomar decisiones de selección de
proyectos. En esta sección, vamos a examinar tres modelos financieros comunes: análisis de flujos de efectivo
descontado, valor presente neto y tasa interna de retorno. Estos no son los únicos métodos financieros para la
evaluación de las alternativas del proyecto, pero son los más populares.
Los modelos financieros se basan en el principio valor del dinero en el tiempo. Este valor sugiere que
el dinero ganado hoy vale más que el dinero que se espera ganar en el futuro. En otras palabras, $100 que
recibo dentro de cuatro años vale mucho menos para mí que si fuera a recibir ese dinero hoy. En el ejemplo
más sencillo, poner $100 en una cuenta de banco a un interés de 3% crecerá el dinero a una tasa compuesta
cada año. Por tanto, al final del año 1, la inversión inicial será de un valor de $103. Después de dos años, se
habrá aumentado a $106.09, y así sucesivamente. El principio también funciona a la inversa: para calcular el
valor presente de $100 que espero tener en el banco en un plazo de cuatro años, primero tengo que descontar
el importe por el mismo tipo de interés. Por tanto, suponiendo una tasa de interés de 3%, necesito invertir
solo $88.85 hoy para obtener $100 en cuatro años.
Esperamos que el dinero futuro tenga menor valor por dos razones: (1) el efecto de la inflación, y (2) la
incapacidad de invertir el dinero. La inflación, como se sabe, hace que los precios suban y por tanto erosiona
el poder adquisitivo de los consumidores. En 1900, por ejemplo, construir una casa promedio pudo haber
costado unos cuantos miles de dólares. Los costos de la vivienda hoy se han disparado. Como resultado,
90 Capítulo 3  •  Selección de proyectos y gerencia del portafolio

si voy a recibir $100 en cuatro años, su valor ha disminuido debido a los efectos negativos de la inflación.
Además, no tener esos $100 hoy significa que no puedo invertir y ganar una rentabilidad de mi dinero en los
próximos cuatro años. El dinero que no se puede invertir es dinero que no gana intereses. En términos reales,
por tanto, el valor presente del dinero debe descontarse por algún factor hasta el futuro que espero recibirlo.
Al decidir entre proyectos alternativos casi idénticos, si con el proyecto A nuestra firma ganará $50,000 en
dos años y con el proyecto B $50,000 en cuatro años, el proyecto A es la mejor opción, porque vamos a recibir
el dinero antes.

Periodo de recuperación
El periodo de recuperación del proyecto es la cantidad estimada de tiempo que será necesaria para recuperar
la inversión de un proyecto, es decir, cuánto tiempo tomará para que el proyecto pague el presupuesto inicial
y comience a generar flujo de efectivo positivo para la compañía. Para determinar el periodo de recuperación
de un proyecto, hay que emplear un análisis de flujo de efectivo descontado, basado en el principio del valor
temporal del dinero. El objetivo del método de flujo de efectivo descontado (discounted cash flow: DCF)
es el estimativo de los gastos en efectivo y las entradas de efectivo esperados de la inversión en un proyecto.
Todos los costos potenciales de desarrollo (la mayoría de ellos están incluidos en el presupuesto del pro-
yecto) son evaluados y proyectados antes de la decisión de iniciar el proyecto. A continuación, se comparan
con todas las fuentes de ingresos esperados del proyecto. Por ejemplo, si el proyecto es una nueva fábrica de
productos químicos, los flujos de ingresos proyectados se basan en la capacidad prevista, los niveles de pro-
ducción, volumen de ventas, etcétera.
Entonces, se aplica a este cálculo una tasa de descuento basada en el costo de capital de la empresa. El
valor de esa tasa se pondera a través de cada fuente de capital a la que la empresa tiene acceso (por lo gene-
ral, los mercados de deuda y de capital). De esta manera, el peso del costo de capital se puede calcular de la
siguiente manera:

K firm = (w d) (k d) (1 - t) + (w e) (k e)

El costo ponderado de capital es el porcentaje de capital derivado de cualquier deuda (wd) o de capital
(we) multiplicado por los costos porcentuales de la deuda y de capital (kd y ke, respectivamente). (El valor de
t se refiere a la tasa marginal de impuestos de la compañía. Como los pagos de intereses son deducibles de
impuestos, se calcula el costo de la deuda después de impuestos).

Hay una fórmula estándar para los cálculos de recuperación:

Periodo de recuperación = inversion/ahorro anual en efectivo

El recíproco de esta fórmula se puede utilizar para calcular la tasa media de rentabilidad del proyecto. Sin
embargo, tenga en cuenta que la fórmula solo funciona en casos simples cuando los flujos de efectivo (o aho-
rros anuales en efectivo) son los mismos para cada año. Así, por ejemplo, si hemos invertido $150,000 y se
recibirán $30,000 al año en ahorros, el periodo de recuperación es muy sencillo:

Periodo de recuperación = $150, 000/$30, 000 = 5 años

Por otro lado, cuando los flujos de efectivo proyectados de ahorros anuales no son iguales, se debe determi-
nar en qué momento el flujo de efectivo acumulado se convierte en positivo. Así:

Flujo de efectivo acumulado (FC) = (inversión inicial) + FC (año 1) + FC (año 2) + ...

Una vez que el costo de capital se ha calculado, se puede establecer una tabla de costos e ingresos proyecta-
dos que se descuentan a la tasa calculada. La clave está en determinar el tiempo que le tomará a la empresa
alcanzar el nuevo punto de equilibrio en un proyecto. El punto de equilibrio representa la cantidad de tiempo
necesario para recuperar la inversión inicial de capital en el proyecto. Periodos de recuperación cortos son
más deseables que frente a los más largos, sobre todo porque cuanto más tenemos que proyectar la recupera-
ción en el futuro, mayor será el potencial de riesgo adicional.
3.3  Modelos financieros 91

EJEMPLO 3.4 Periodo de recuperación

Nuestra empresa quiere determinar cuál de las dos alternativas del proyecto es la oportunidad de inversión
más atractiva, mediante el uso del método de periodo de recuperación. Hemos calculado el costo de la inver-
sión inicial de los dos proyectos y los ingresos esperados que deben generar para nosotros (véase el cuadro
3.5). ¿En qué proyecto debemos invertir?
SOLUCIÓN
Para nuestro ejemplo, el retorno de la inversión para los dos proyectos se puede calcular según el cuadro 3.6.
Estos resultados sugieren que el proyecto A es una opción superior al proyecto B, sobre la base de un periodo
de recuperación proyectado más corto (2.857 en comparación con 4.028 años) y una tasa de retorno más alta
(35% versus 24.8%).

CUADRO 3.5  Desembolso inicial e ingresos proyectados para dos


opciones de proyecto

Proyecto A Proyecto B

Ingresos Egresos Ingresos Egresos


Año 0 $500,000 $500,000
Año 1 $ 50,000 $75,000
Año 2 150,000 100,000
Año 3 350,000 150,000
Año 4 600,000 150,000
Año 5 500,000 900,000

CUADRO 3.6  Comparación de la recuperación de la inversión para los


proyectos A y B

Flujo de Acumulado
Proyecto A Año fondos flujo de fondos
0 ($500,000) ($500,000)
1 50,000 (450,000)
2 150,000 (300,000)
3 350,000 50,000
4 600,000 650,000
5 500,000 1,150,000
Periodo de recuperación = 2.857 años
Tasa de retorno = 35%

Proyecto B Año Flujo de Acumulado


fondos flujo de fondos
0 ($500,000) ($500,000)
1 75,000 (425,000)
2 100,000 (325,000)
3 150,000 (175,000)
4 150,000 (25,000)
5 900,000 875,000
Periodo de recuperación = 4.028 años
Tasa de retorno = 24.8%
92 Capítulo 3  •  Selección de proyectos y gerencia del portafolio

Valor presente neto


El enfoque de la toma de decisiones financieras más popular en la selección de proyectos es el valor presente neto
(VPN), que prevé el cambio en el valor de la empresa, si se lleva a cabo un proyecto. Así, un VPN positivo indica que la
empresa va a ganar dinero y su valor se elevará, como resultado del proyecto. El valor presente neto emplea el análisis
de flujo de efectivo descontado, al descontar los flujos futuros de ingresos para calcular el valor actual del dinero.
La fórmula simplificada para el VPN es la siguiente:

VPN (proyecto) = I 0 + / Ft / (1 + r + p t) t
n=1

Donde
Ft = flujo neto de efectivo para el periodo t
  r = tasa de rendimiento requerida
  I = inversión inicial en efectivo (desembolso en efectivo en el momento 0)
 pt = tasa de inflación durante el periodo t
El procedimiento óptimo para el cálculo del VPN consiste en varios pasos, incluidos la construcción
de un cuadro con las salidas, entradas, tasa de descuento y los flujos de efectivo descontados a través de los
plazos pertinentes. Construimos un cuadro en el ejemplo 3.5 (véase el cuadro 3.7).

EJEMPLO 3.5 Valor presente neto

Suponga que usted está considerando si debe o no invertir en un proyecto que tendrá un costo de $100,000
en la inversión inicial. Su empresa necesita una tasa de retorno de 10% y se espera que la inflación se man-
tenga relativamente constante de 4%. Usted prevé una vida útil de cuatro años para el proyecto y ha proyec-
tado los flujos de efectivo futuros de la siguiente manera:

Año 1: $20,000
Año 2: $50,000
Año 3: $50,000
Año 4: $25,000

SOLUCIÓN
Sabemos que la fórmula para determinar el VPN es:

VPN = I 0 + / Ft / (1 + r + p) t
n=1

Ahora podemos construir un cuadro sencillo para registrar los datos de los flujos de efectivo descontado
(entradas y salidas) para ver si vale la pena su inversión inicial del proyecto. Ya sabemos que vamos a necesi-
tar las siguientes categorías: Año, Entradas, Salidas y VPN. También necesitaremos dos categorías más:

Flujos netos: la diferencia entre las entradas y salidas


Factor de descuento: el recíproco de la tasa de descuento (1/(1 + r + p)t)

En el cuadro 3.7, si llenamos en la columna el Factor del descuento suponiendo que r = 10% y p = 4%,
se puede comenzar a trabajar en el VPN. Tenga en cuenta que el año 0 significa el momento actual y el año 1
el primer año de operación.
¿Cómo llegamos al factor de descuento para el año 3? Utilizando la fórmula que propusimos anterior-
mente y calculamos:

Factor de descuento = (1/ (1 + .10 + .04) 3) = .6749


3.3  Modelos financieros 93

CUADRO 3.7  Puntuación de flujos de efectivo descontado

Año Entradas Salidas Flujo neto Factor de descuento VPN


0 $100,000 $(100,000) 1.0000
1 $20,000 20,000 0.8772
2 50,000 50,000 0.7695
3 50,000 50,000 0.6749
4 25,000 25,000 0.5921

CUADRO 3.8  Flujos de efectivo descontado y VPN (I)

Año Entradas Salidas Flujo neto Factor de descuento VPN


0 $100,000 $(100,000)  1.0000 $(100,000)
1 $20,000  20,000  0.8772 17,544
2 50,000  50,000  0.7695 38,475
3 50,000  50,000  0.6749 33,745
4 25,000  25,000  0.5921 14,803
Total $4,567

Ahora podemos suministrar los datos correspondientes a las columnas Entradas, Salidas y Flujo neto.
Finalmente, completamos el cuadro multiplicando el Flujo neto por el Factor de descuento. Los resulta-
dos nos dan los datos de la columna de VPN de nuestro cuadro. La suma de los flujos de efectivo descontado
(valor presente neto) que se muestran en el cuadro 3.8 nos da el VPN del proyecto. El total es un número
positivo, lo cual indica que la inversión vale la pena y debe llevarse a cabo.
El valor presente neto es uno de los métodos de selección de proyectos más comunes hoy día. Su prin-
cipal ventaja es que les permite a las empresas vincular proyectos alternativos a los resultados financieros, ase-
gurando que los proyectos en que una empresa decida invertir sus recursos probablemente generen beneficios.
Entre sus desventajas está la dificultad para hacer predicciones exactas a largo plazo en el uso del VPN. Por
ejemplo, supongamos que consideramos invertir en un proyecto con la expectativa de que seguirá generando
rendimientos durante los próximos 10 años. Para decidir si invertir o no en el proyecto, tenemos que hacer
algunas suposiciones acerca de las tasas de interés futuras, la inflación y nuestra tasa de retorno requerida
(TRR) para los próximos 10 años. En los tiempos financieros o económicos inciertos, puede ser arriesgado
tomar decisiones de inversión a largo plazo debido a que las tasas de descuento pueden fluctuar.

Periodo de recuperación descontado


Ahora que hemos considerado el valor temporal del dinero, como se muestra en el método VPN, podemos
aplicar esta lógica al modelo de recuperación simple para crear un modelo de screening y selección, un poco
más poderoso. Recuerde que con el VPN utilizamos el flujo de efectivo descontado como nuestro medio
de decidir si invertir o no en una oportunidad del proyecto. Ahora, vamos a aplicar el mismo principio al
método periodo de recuperación descontado. Con este método, el periodo que nos interesa es la cantidad
de tiempo hasta que la suma de los flujos de efectivo descontado sea igual a la inversión inicial.
Un simple ejemplo ilustra la diferencia entre la recuperación directa de la inversión y el método de periodo
de recuperación descontado. Supongamos que se requiere un retorno de 12.5% para las nuevas inversiones y
tenemos una oportunidad de proyecto que costará la inversión inicial $30,000, con un rendimiento prometido
por año de $10,000. Con el modelo de recuperación simple, la inversión inicial puede pagarse en solo tres años.
Sin embargo, como muestra el cuadro 3.9, cuando descontamos los flujos de efectivo al 12.5% y los sumamos,
realmente se tienen cuatro años para amortizar la inversión inicial del proyecto.
La ventaja del método periodo de recuperación descontado es que nos permite hacer una determinación
más “inteligente” de la cantidad de tiempo que se necesita para satisfacer la inversión inicial del proyecto. Es decir,
mientras la recuperación simple es útil para efectos contables, la recuperación descontada en realidad es más
representativa de la realidad financiera que todas las organizaciones deben tener en cuenta al evaluar proyectos.
Los efectos de la inflación y las oportunidades influyen en las decisiones individuales de inversión, por lo que estos
factores también deberían tomarse en cuenta en la evaluación de oportunidades de proyectos.
94 Capítulo 3  •  Selección de proyectos y gerencia del portafolio

CUADRO 3.9  Método periodo de recuperación descontado

Proyecto flujo de efectivo*


Año Descontado No descontado
1 $8,900 $10,000
2  7,900  10,000
3  7,000  10,000
4  6,200  10,000
5  5,500  10,000
Periodo de recuperación 4 años   3 años
*Flujos de efectivo redondeados lo más cerca de $100.

Tasa interna de retorno


La tasa interna de retorno (TIR) es un método alternativo para la evaluación de los gastos y los ingresos pre-
vistos asociados a una nueva oportunidad de inversión. El método TIR responde una simple pregunta: ¿qué
tasa de retorno podrá ganar el proyecto? Con este modelo, el proyecto debe cumplir alguna tasa requerida
“atractiva” que se aplica a todos los proyectos considerados. Sin detallar las matemáticas del proceso, vamos
a decir que la TIR es la tasa de descuento que iguala el valor presente de los ingresos y de los gastos de un
proyecto. Si un proyecto tiene una duración de tiempo t, la TIR se define así:
t
ACF t
IO = / (1 + IRR) t
n=1

Dónde:
ACFt = flujo de efectivo anual después de impuestos para el periodo t
   IO = desembolso inicial
   n = vida esperada del proyecto
  IRR = tasa interna de retorno del proyecto
La TIR se obtiene mediante un proceso sencillo, aunque requiere tablas que representan el valor pre-
sente de una anualidad, con el fin de determinar la tasa de retorno del proyecto. Alternativamente, muchas
calculadoras de bolsillo pueden determinar la TIR rápidamente. Sin tablas o el acceso a una calculadora, es
necesario emplear un proceso iterativo para identificar la TIR aproximada para el proyecto.

EJEMPLO 3.6 Tasa interna de retorno

Tomemos un ejemplo sencillo. Supongamos que un proyecto requiere una inversión inicial en efectivo de
$5,000 y se espera que genere ingresos de $2,500, $2,000 y $2,000 para los próximos tres años. Además, se
supone que la tasa de rendimiento requerida para los nuevos proyectos de la empresa es de 10%. La pregunta
es: ¿vale la pena financiar este proyecto?
SOLUCIÓN
Responder a esta pregunta requiere cuatro pasos:
1.
Elija un tipo de descuento arbitrario y utilícelo para determinar el valor presente neto del flujo de entra-
das de efectivo.
2.
Compare el valor presente de los flujos con la inversión inicial; si son iguales, se ha hallado la TIR.
3.
Si el valor actual es mayor (o menor) que la inversión inicial, seleccione una tasa de descuento mayor (o
menor) para el cálculo.
4.
Determine el valor actual de los flujos y compárelo con la inversión inicial. Continúe repitiendo los
pasos 2-4 hasta que haya determinado la TIR.
Usando nuestro ejemplo, sabemos que:
Inversión en efectivo = $5,000
3.3  Modelos financieros 95

Año 1 entrada = $2,500


Año 2 entrada = $2,000
Año 3 entrada = $2,000
Tasa de rendimiento requerida = 10%
Primer paso: pruebe con 12%.

Factor de descuento
Año Ingresos al 12% VPN
1 $2,500 .893 $2,233
2 2,000 .797 1,594
3 2,000 .712 1,424
Valor presente de los flujos 5,251
Inversión en efectivo - 5,000
Diferencia $251

Decisión: la diferencia de valor presente al 12% es $250.50, que es demasiado alto. Pruebe con un tipo de descuento más
alto.
Segundo paso: pruebe con 15%.

Factor de descuento

Año Ingresos al 15% VPN


1 $2,500 .870 $2,175
2 2,000 .756 1,512
3 2,000 .658 1,316
Valor presente de los flujos 5,003
Inversión en efectivo 5,000
Diferencia $  3

Decisión: la diferencia de valor presente al 15% es $3, lo cual sugiere que 15% es una buena aproximación de la TIR.

Si la TIR es mayor o igual que la tasa de retorno requerida de la compañía, vale la pena la financiación del proyecto. En el
ejemplo 3.6, se encontró que la TIR es de 15% para el proyecto, es más alta que la tasa de corte de 10% y un buen candidato
para la inversión. La ventaja de la utilización de análisis de la TIR se encuentra en su capacidad de comparar proyectos alter-
nativos desde la perspectiva de la tasa de retorno sobre la inversión (return on investment: ROI). Los proyectos que tienen
mayor TIR son generalmente superiores a los que tienen menor TIR.
El método TIR, sin embargo, tiene algunas desventajas. Primera, no es la tasa de retorno de un proyecto. De hecho,
la TIR es igual a la tasa de retorno del proyecto solo cuando los flujos de efectivo generados por las entradas de efectivo
pueden reinvertirse en nuevos proyectos a tasas similares de rendimiento. Si la empresa puede reinvertir los ingresos
solo en proyectos de bajo retorno, la rentabilidad “real” del proyecto es algo menor que la TIR calculada. Otros proble-
mas con el método de la TIR hacen al VPN un determinante de la viabilidad del proyecto más robusto:16
• Por lo general, Los cálculos del VPN y la TIR coinciden solo cuando los proyectos son independientes (es decir,
hacer las mismas recomendaciones de inversión). Si los proyectos no son mutuamente excluyentes, la TIR y el
VPN pueden resultar contradictorios. La razón es que el VPN emplea un costo de capital promedio ponderado
descontado que refleja el potencial de reinversión mientras que la TIR no. Debido a esta distinción, el VPN se pre-
fiere en general como una medida más realista de la oportunidad de inversión.
• Si los flujos de efectivo no son normales, la TIR puede llegar a múltiples soluciones. Por ejemplo, si las salidas
netas de efectivo siguen un periodo de flujos netos de efectivo, la TIR puede dar resultados contradictorios. Si,
tras la terminación de la construcción de la planta, es necesario invertir en la recuperación de tierras u otros
gastos incidentales, pero significativos, el cálculo de la TIR puede dar lugar a múltiples tasas de retorno, donde
solo una de ellas es correcta.
96 Capítulo 3  •  Selección de proyectos y gerencia del portafolio

Modelo de opciones
Supongamos que una empresa tiene la oportunidad de construir una planta de energía en un país en desarro-
llo. La inversión es especialmente arriesgada: la empresa, en última instancia, puede dejar de tener un retorno
positivo para su inversión y puede no encontrar un comprador para la planta si se opta por abandonar el
proyecto. Tanto los métodos VPN y TIR no tienen en cuenta esta posibilidad muy real, es decir, una empresa
no puede recuperar el dinero que se invierte en un proyecto. Sin embargo, es evidente que muchas empresas
deben tener en cuenta esta opción al tomar decisiones de inversión. Una organización, frente a esta posibili-
dad, debe determinar dos cosas.17
1. Si tiene flexibilidad para posponer el proyecto
2. Si la información futura le ayudará a tomar la decisión

EJEMPLO 3.7 Modelo de opciones

Una empresa de construcción está considerando si actualiza o no una planta química existente. El costo
inicial de la actualización es $5,000,000, y la empresa requiere 10% de retorno sobre su inversión. La
planta puede ser mejorada en un año y empezar a generar ingresos al año siguiente. El mejor pronóstico
promete flujos de efectivo de $1 millón por año, pero si prevalecen las condiciones económicas y políticas
adversas, la probabilidad de realización de esta cantidad se reduce a 40%, con una probabilidad de 60%
que la inversión producirá solo $200,000 por año.
SOLUCIÓN
En primer lugar, podemos calcular el VPN de la inversión propuesta de la siguiente manera:
Flujo de efectivo = .4 ($1 millón) + .6 ($200, 000) = $520, 000
VPN = - $5, 000, 000 + / $520, 000/ (1.1) t
= - $5, 000, 000 + ($520, 000/ (.1)
= - $5, 000, 000 + $5, 200, 000
= $200, 000
Debido a que $520,000 es una perpetuidad que se inicia en el año 1, lo dividimos por la tasa de des-
cuento de 10% para determinar el valor de la perpetuidad. Según este cálculo, la empresa debe llevar a cabo el
proyecto. Sin embargo, esta recomendación, pasa por alto la posibilidad de que al esperar un año, la empresa
puede tener una mejor idea de la situación política/económica del país de acogida. Así, la empresa está omi-
tiendo una información importante que podría ser útil en la toma de su decisión.
Supongamos que si espera un año, la empresa determina que su inversión tendrá una probabilidad de
50% (en comparación con la proyección original de 40%) de pagar el mayor valor de $1 millón por año. No
obstante, debido a que la empresa elige esperar un año, el importe de la inversión inicial ($5,000,000) tam-
bién debe descontarse a 10% por un año, es decir, la empresa está invirtiendo el dinero no inmediatamente
(tiempo 0), sino en el año 1. El VPN del proyecto sería ahora:
VPN = - $5, 000, 000/1.1 + 0.5 ($1, 000, 000/0.1)
VPN = - $4, 545, 454 + $5, 000, 000
VPN = $454, 546

La elección de un enfoque de selección de proyectos


¿Qué podemos concluir de nuestra discusión de los métodos para selección de los proyectos? En primer
lugar, y ante todo, hemos aprendido a enfocarnos en el método por utilizar en la toma de decisiones de selec-
ción. ¿Han sido consistentes y objetivos para considerar nuestras alternativas? El autor ha trabajado en una
empresa de consultoría y entrenamiento en un gran número de empresas que han experimentado problemas
recurrentes en la selección de sus proyectos (con tendencia a elegir perdedores). ¿Por qué? Una razón fue
su incapacidad para siquiera intentar ser objetivos en sus métodos de selección. Los proyectos propues-
tos, a menudo, son “vacas sagradas” o ideas favoritas de los altos directivos, por lo que son empujados a la
cabeza de la línea o, peor aún, financieramente “ajustados” hasta que arrojan conclusiones satisfactorias. Los
3.3  Modelos financieros 97

miembros del equipo sabían de antemano que tales proyectos fracasarían, porque se habían maquillado hasta
el punto que aparentemente optimizaban los criterios de selección. La clave para la selección de proyectos
radica en ser objetivo en el proceso. Si usted opera de acuerdo con el principio “GIGO” (garbage in/garbage
out: basura entra/ basura sale) pronto estará con la basura hasta las rodillas.
Una segunda conclusión que podemos sacar es: si bien existe una gran variedad de métodos de selección,
algunos que pueden ser más apropiados para determinadas empresas y circunstancias del proyecto. Algunos pro-
yectos requieren evidencias financieras sofisticadas de su viabilidad. Otros solo pueden necesitar demostrar nada
más que un perfil aceptable en comparación con otras opciones. En otras palabras, cualquiera de los métodos de
selección descritos anteriormente pueden ser apropiados en ciertas situaciones. Algunos expertos, por ejemplo,
están a favor de los modelos de puntuación ponderada, porque ofrecen una visión más precisa de los objetivos
estratégicos de una empresa, sin sacrificar la eficacia a largo plazo para obtener ganancias financieras a corto
plazo.18 Argumentan que estos criterios importantes no financieros, no deben excluirse del proceso de toma de
decisiones. Tal vez la clave está en elegir un algoritmo de selección suficientemente amplio como para abarcar
los aspectos financieros y no financieros. Independientemente del enfoque que la empresa elija, podemos estar
seguros de una cosa: tomar buenas decisiones de proyectos es un paso crucial para asegurar posteriormente una
buena gerencia de proyectos.

PERFIL DE PROYECTO

Screening y selección de proyectos en GE: el Proceso/Tollgate


General Electric (GE) ha desarrollado un enfoque muy sofisticado para el screening y selección de proyectos, que la compa-
ñía llama el Proceso Tollgate. Como se puede ver en la figura 3.6, Tollgate implica un procedimiento formal de una serie de
siete puntos de control (etiquetados 100-700), establecidos a lo largo de la línea de tiempo de desarrollo del proyecto. Así,
Tollgate, más que una metodología de selección de proyectos, implica el control en la selección y desarrollo del proyecto a
medida que avanza en su ciclo de vida. Cada etapa en este proceso de control se monitorea cuidadosamente.
Cada una de las siete etapas del modelo Tollgate puede desglosarse en un llamado mapa de procesos que
guía a los gerentes y equipos para hacerles frente a los elementos específicos necesarios para la realización de una
etapa. Estos elementos son los pasos secundarios que guían el screening del proyecto con el fin de garantizar que
todos los proyectos se ajustan al mismo conjunto de normas internas de GE.

Introducción de nuevos productos


Proceso de siete etapas

Identificar Negociación
los reque - Diseño de Diseño Sistema de Producción
Propuesta /Recurso
rimientos de sistemas detallado verificación /Lanza -
miento
del cliente planeación

100 200 300 400 500 600 700

FIGURA 3.6  Proceso Tollgate de GE


Fuente: usado con permiso de General Electric Company. (continúa)
98 Capítulo 3  •  Selección de proyectos y gerencia del portafolio

La figura 3.7 presenta el mapa de flujo de procesos que se utiliza para evaluar el progreso de cada proyecto
durante las diversas etapas, hasta su terminación. Téngase en cuenta que los equipos deben completar todos los
pasos de acción secundarios en cada etapa del modelo. Una vez que hayan completado una fase determinada, un
equipo de gestión multifuncional supervisa. La aprobación de esta etapa le permite al equipo pasar a la siguiente.
El rechazo significa que el equipo debe realizar copias de seguridad y hacerles frente a las cuestiones que el equipo
de revisión considera que no se han abordado adecuadamente. Por ejemplo, supongamos que el proyecto no
aprueba la conformidad técnica durante las pruebas de campo en la etapa de verificación del sistema. La falla
técnica requeriría al equipo retomar el punto adecuado para analizar la causa de la falla en la prueba de campo
y tomar medidas correctivas. Después de que el equipo de proyecto ha sido aprobado por el equipo de revisión,
se necesita la aprobación de la alta gerencia antes de pasar a la siguiente etapa del modelo. El rechazo por la alta
gerencia, en este punto, a menudo elimina efectivamente el proyecto.

Rechazo Parar el trabajo


Revisión, costo, e informar al cliente
cronograma, acciones Revisión de la
Equipo de liderazgo de riesgo y planes alta gerencia o
directivo (ELD) anulación Aprobación
del CEO Aprobación para
Acciones, comentarios, continuar el proceso
orientación sobre cuestiones Equipo del Tollgate a la siguiente
de riesgo, estado, acciones proyecto etapa, con la mitigación
correctivas para mantener Aprobación de riesgos y planes
Equipo interfuncional la integridad del proceso Revisión de acción
e intersecciones de Tollgate
revisión gerencial Rechazo
Planes de gestión
de riesgos, con El equipo del proyecto
cálculo de riesgos Equipo del trabaja sobre las cuestiones
y la hoja de resumen proyecto planteadas durante la revisión.
Después de tres rechazos del
Etapa equipo del proyecto, debe
Equipo del proyecto ir a la alta gerencia
Tollgate
Hojas completadas para aprobación
o aspectos de riesgo para
ítems incompletos

FIGURA 3.7  Mapa de flujo de los procesos del modelo Tollgate de GE


Fuente: usado con permiso de General Electric Company.

Algunos críticos sostienen que procesos de revisión formalizados y sofisticados como el Tollgate agregan nive-
les excesivos de supervisión burocrática para el proceso de screening del proyecto. De hecho, el gran número de
acciones, pasos, listas de verificación y las revisiones gerenciales estipuladas por el proceso Tollgate pueden generar
retrasos significativos a los proyectos, una preocupación fundamental si se necesita un proyecto para hacerle frente a
un problema inmediato. Por otro lado, los defensores de estas técnicas argumentan que los beneficios de la norma-
lización, a través de unidades de negocio, el análisis integral del riesgo y los vínculos claros con la alta dirección, más
que compensan los posibles problemas. En GE, la compañía atribuye a Tollgate la promoción de mejoras significativas
en el descubrimiento temprano de problemas y en la gestión del riesgo “en tiempo real”.

3.4  GERENCIA DEL PORTAFOLIO DE PROYECTOS


La gerencia del portafolio de proyectos es el proceso sistemático de selección, apoyo y gerencia de los pro-
yectos de una empresa. Los proyectos se gestionan conjuntamente según una misma estructura y pueden
estar relacionados entre sí o ser independientes. La clave para la gerencia del portafolio es tener presente que
los proyectos de una empresa comparten un objetivo estratégico común y los mismos recursos limitados.19
Por ejemplo, Pratt & Whitney Jet Engines, una subsidiaria de United Technologies Corporation, es similar
a otros grandes fabricantes de motores de reacción en lo relacionado con la creación de una amplia gama de
tipos de motores, desde los desarrollados para los helicópteros hasta los de aviones de reacción, de uso civil
o militar. Aunque los productos tienen características comunes, los desafíos técnicos están en que la línea de
productos es muy diversa. El concepto de gerencia de portafolios de proyectos sostiene que las empresas no
deben gestionar los proyectos como entidades independientes, sino que deben considerarse activos de porta-
folios unificados. Puede haber múltiples objetivos, pero compartidos.20
3.3  Modelos financieros 99

Artto21 resalta que en una empresa orientada a proyectos, la gerencia del portafolio plantea un desafío
constante para equilibrar los objetivos estratégicos a largo plazo con las necesidades y limitaciones a corto
plazo. Rutinariamente, los gerentes se plantean preguntas como las siguientes:
• ¿Qué proyectos debe financiar la empresa?
• ¿La empresa cuenta con recursos para apoyarlos?
• ¿Estos proyectos refuerzan objetivos estratégicos futuros?
• ¿Tiene este proyecto un buen potencial de negocio?
• ¿Es este proyecto complementario de otros que tiene la empresa?

Objetivos e iniciativas
Cada una de las preguntas de la lista anterior tiene implicaciones a corto y a largo plazo y, en conjunto,
constituyen la base tanto para la gerencia de proyectos estratégicos como para la gestión eficaz del riesgo. La
gerencia del portafolio, por tanto, implica toma de decisiones, priorización, revisión, reorganización y reasig-
nación de prioridades de los proyectos de una empresa. Veamos cada una de estas tareas con mayor detalle.

TOMA DE DECISIONES La decisión sobre si debe o no continuar en direcciones estratégicas específicas


es a menudo influida por las condiciones del mercado, la disponibilidad de capital, oportunidad percibida
y el riesgo aceptable. Una variedad de proyectos alternativos pueden considerarse alternativas razonables
durante el desarrollo del portafolio.

PRIORIZACIÓN  Como las empresas cuentan con recursos limitados, por lo general no pueden financiar todas
las oportunidades de proyecto. Por tanto, se deben priorizar. Para esta tarea, se pueden utilizar algunos criterios:
• Costo: proyectos con menores costos de desarrollo son más favorables, ya que cuentan con menor
riesgo inicial.
• Oportunidad: la posibilidad de un gran premio es un fuerte incentivo para la financiación.
• Presión de la alta gerencia: la presión política de la alta gerencia (por ejemplo, gerentes de proyectos
especiales) puede influir en las decisiones.
• Riesgo: el rendimiento del proyecto debe justificar un cierto nivel de riesgo; los demasiado arriesga-
dos se descartan.
• “Ajuste” estratégico: si una empresa tiene una política de búsqueda de una familia de productos, todas
las oportunidades se evalúan en términos de su complementariedad, es decir, ya sea su encaje estratégico
con las líneas de productos existentes o su capacidad para aumentar la familia actual de productos.
• Deseo de un portafolio balanceado: una empresa puede querer compensar iniciativas arriesgadas
mediante la financiación de otros proyectos. La matriz de producto del Boston Consulting Group, por
ejemplo, equilibra las líneas de productos de la empresa en términos de participación relativa de mer-
cado y el crecimiento del producto, lo cual sugiere que las empresas pueden mantener un equilibrio
estratégico entre productos con diferentes perfiles, dentro de sus portafolios. Una empresa debería usar
sus productos rentables de bajo crecimiento para financiar inversiones en proyectos con perspectivas
de alto crecimiento. El balance del portafolio apoya el desarrollo de una estrategia que permite a las
compañias la habilidad de balancear o contrarrestar el riesgo, explorar oportunidades de mercado,
alternativas y financiar innovación en otras líneas de productos.

REVISIÓN  Todas las alternativas del proyecto se evalúan de acuerdo con el esquema de prioridades de la
empresa. Los proyectos seleccionados para el portafolio de la empresa son los que, basados en las prioridades,
ofrecen el máximo rendimiento. Por ejemplo, al inicio de la actual crisis económica, DHL Express inició la
evaluación de su portafolio de proyectos, a través de un nuevo lente. La junta de revisión del portafolio de la
organización decidió que todos los proyectos en curso tenían que cumplir los siguientes requisitos: ofrecer
retorno sobre la inversión (ROI) en 2009, ser “misión crítica” para el manejo del negocio y aspectos reglamen-
tarios necesarios para mantener el negocio operacional. Después de una extensa revisión del portafolio, una
serie de proyectos fue suspendida temporalmente.

REALINEACIÓN  Cuando los portafolios son modificados por la adición de nuevos proyectos, los gerentes
deben reexaminar las prioridades de la empresa. A raíz de las nuevas incorporaciones de proyectos, se debe
considerar una serie de preguntas importantes. ¿El nuevo proyecto se ajusta a los objetivos estratégicos carac-
terizados según el portafolio de proyectos, o representa una nueva dirección estratégica para la empresa? ¿El
100 Capítulo 3  •  Selección de proyectos y gerencia del portafolio

nuevo proyecto altera significativamente los objetivos estratégicos de la empresa? ¿El portafolio requiere un
reajuste adicional? La decisión de cambiar un portafolio mediante la adición de nuevos proyectos reanuda el
ciclo de análisis en el que debemos reexaminar el portafolio en busca de signos de desequilibrio o actualización.

REPRIORIZACIÓN  Si realineación estratégica significa cambiar el enfoque de la empresa (es decir, la creación
de nuevas orientaciones estratégicas), entonces los gerentes también deben cambiar la prioridad de las metas
y los objetivos corporativos. Por tanto, la gerencia de portafolio significa gestionar la estrategia global de la
empresa. Por ejemplo, Bayer Corporation, el gigante farmacéutico mundial, ha encontrado su identidad corpo-
rativa cada vez menos clara, debido a la gran variedad de adquisiciones y otras marcas bajo las que comercializa
sus productos. La compañía anunció recientemente su intención de eliminar gradualmente muchas de las otras
marcas que posee bajo el “paraguas de productos Bayer” para enfatizar la etiqueta Bayer. “Hemos analizado
mucho nuestro portafolio de marcas y encontramos que la diversidad de las marcas del Grupo Bayer ha diluido
la marca original”, explicó Marijn Dekkers, presidente del Consejo de Dirección. Esta nueva estrategia de marca
está diseñada para mejorar el reconocimiento y la percepción de los productos de Bayer.22

El desarrollo de un portafolio proactivo


La gerencia del portafolio, por tanto, es un componente importante en la gerencia de proyectos estratégicos.
Además de la gerencia de proyectos específicos, las organizaciones rutinariamente se planifican estratégica-
mente para la rentabilidad, y el camino a la rentabilidad a menudo se recorre a través del área de la gerencia
de proyectos estratégicos. Uno de los métodos más eficaces para la alineación de los objetivos financieros
con los planes estratégicos es el desarrollo de un portafolio proactivo de proyectos, o una familia integrada
de proyectos, por lo general con una meta estratégica común. Ese portafolio apoya la integración estratégica
general, en lugar de un enfoque de simplemente moverse de oportunidad en oportunidad.
Consideremos el ejemplo de la gran empresa farmacéutica Pfizer.23 Pfizer y sus competidores manejan
normalmente, de manera integrada, grandes familias de proyectos. La integración global de las actividades de
gerencia de proyectos ayuda a los gerentes de la compañía a tratar ciertas realidades de la industria farmacéu-
tica, como los costos de desarrollo extremadamente altos y los largos plazos para los nuevos productos. De
hecho, como muestra el cuadro 3.10, tiempo necesario para llevar un nuevo medicamento en el mercado se

CUADRO 3.10  Fases de desarrollo de nuevos medicamentos

Fase Duración % de éxito Contenido


Descubrimiento 4–7 años 1% Investigar un grupo seleccionado de moléculas en
modelos informáticos y laboratorio.
Investigación Poner a prueba en animales y laboratorio para
 preclínica investigar la seguridad, posibles indicaciones, toxi-
cología y metabolismo de la molécula.
Fase I 1 año 70%–75% Estudios clínicos pequeños en voluntarios sanos
para estudiar la seguridad y las características
ADME de la molécula.
Fase II 2 años 50% Estudios pequeños en pacientes con la enferme-
dad objetivo para estudiar la eficacia, dosis y for-
mulación del medicamento.
Fase III 3 años en 75%–85% Amplios estudios clínicos en pacientes para con-
adelante firmar los resultados de la fase II. La fase más
costosa del proyecto.
Aplicación de la 1.5–3 años 75%–80% Compilar la aplicación y autorización para la co-
 comercialización mercialización (MAA) y enviar a las autoridades.
  ( MA) Después de la autorización, el medicamento
puede ser vendido y comercializado.
Total 12–16 años < 0.002%

Fuente: M. Lehtonen (2001). “Resource allocation and project portfolio management in pharmaceutical R&D,” in Artto,
Martinsuo, and Aalto (Eds.), Project Portfolio Management: Strategic Management through Projects, pp. 107–140, figura de la pá-
gina 112. Helsinki, Finland: Project Management Association.
3.3  Modelos financieros 101

puede prolongar fácilmente a más de 15 años y la tasa de éxito de un medicamento que está siendo desarro-
llado comercialmente, se estima en menos de 0.002%.
Por tanto, en un punto determinado en el tiempo, Pfizer cuenta con numerosos proyectos en fase de
investigación y desarrollo, un menor número de proyectos que entran en las diversas etapas de ensayos clínicos
y, por último, una línea aún más reducida de proyectos que ya están en el mercado. Cada paso en el ciclo está
lleno de riesgos e incertidumbres. ¿Un medicamento llegará a funcionar en los ensayos clínicos? ¿Va a tener
efectos secundarios negativos mínimos? ¿Puede ser producido de una manera efectiva en costos? ¿Su lanza-
miento es sensible al tiempo (hay, por ejemplo, una oportunidad de mercado limitada por aprovechar)? A
menudo, las respuestas a estas preguntas reducirán el portafolio actual de proyectos en desarrollo para Pfizer.
Dadas las circunstancias de riesgo de esta industria, en la que el tiempo de desarrollo es largo, las
repercusiones financieras de incumplimiento son enormes y el éxito nunca es seguro, las empresas farma-
céuticas deben practicar una gerencia de portafolios de proyectos muy sofisticada. Debido a las tasas de
fracaso tan altas y a constantes fracasos, la necesidad de aprovechar las nuevas oportunidades de produc-
tos es fundamental. Solo de esta manera la empresa puede asegurar un suministro constante de nuevos
productos en el mercado.
Los peligros y posibilidades del proceso de desarrollo de productos farmacéuticos se ilustran en la
figura 3.8. Las compañías farmacéuticas deben compensar los largos tiempos necesarios para obtener la
aprobación final de los nuevos productos con la financiación y gestión literalmente simultánea, de decenas
de iniciativas de desarrollo. Infortunadamente, solo una pequeña proporción del portafolio de (I+D) se mos-
trará suficientemente prometedora para avanzar a la fase de ensayo clínico. Muchos proyectos son elimina-
dos después de esta fase y muy pocos llegarán a la fase de lanzamiento comercial.
Pfizer utiliza la gerencia de portafolio para administrar el flujo de nuevos proyectos de desarrollo de
fármacos, tanto como Nokia y Erickson lo utilizan para realizar un seguimiento de productos que pueden
influir en los teléfonos móviles, módems de banda y sistemas de cortafuegos. Los portafolios de proyectos se
necesitan porque un cierto porcentaje de los proyectos se cancela antes de su financiación total, los demás
serán eliminados durante el desarrollo y otros fracasarán en el mercado. Este ciclo deja solo unos pocos
proyectos que generaran retorno sobre la inversión total de la empresa. En definitiva, cualquier empresa que
pone todos sus huevos de (I+D) en una sola canasta, corre enormes riesgos si ese proyecto fracasa durante
el desarrollo o decepciona en el mercado. Como regla, por tanto, las empresas se garantizan ellas mismas
opciones de reserva, mayor estabilidad financiera y la posibilidad de responder a múltiples oportunidades
mediante la creación y actualización constante de los portafolios de proyectos.

Selección de Inicio Prueba de


la molécula Fase I concepto MAA MA

Tiempo de lanzamiento
al mercado
Negocios
miento
Lanza-
Descubrimiento

Tiempo para aprobación

Nombre de la fase
Planeación Soporte de producto
III
II
I
Implementación
Pre

Tiempo

FIGURA 3.8  Flujo en el tiempo del desarrollo de nuevos medicamentos


Fuente: M. Lehtonen. (2001). “Resource allocation and project portfolio management in
pharmaceutical R&D,” in Artto, Martinsuo, and Aalto (Eds.), Project Portfolio Management:
Strategic Management through Projects, pp. 107–140, figura en la página 120. Helsinki, Finland:
Project Management Association.
102 Capítulo 3  •  Selección de proyectos y gerencia del portafolio

Claves para la gerencia exitosa de portafolios de proyectos


Aunque abundan los ejemplos de portafolios gestionados con éxito, pocos investigadores han estudiado las
razones claves por las que algunas empresas son mejores que otras. Brown y Eisenhardt24 estudiaron recien-
temente seis empresas de la industria informática, todas involucradas en múltiples actividades de desarrollo
de proyectos. Ellos determinaron que los portafolios de proyectos gestionados con éxito por lo general refle-
jan estos tres factores:

ESTRUCTURA FLEXIBLE Y LIBERTAD DE COMUNICACIÓN  Entornos de múltiples proyectos no pueden


funcionar con eficacia cuando se limitan por niveles restrictivos de burocracia, canales de comunicación estre-
chos y procesos de desarrollo rígidos. Portafolios exitosos emergen de entornos que fomentan la flexibilidad
y la comunicación abierta. Cuando se permite que los equipos de proyecto puedan improvisar y experimentar
con las líneas de productos existentes, las ideas innovadoras de nuevos productos son más propensas a surgir.

BAJO COSTO DEL MONITOREO AMBIENTAL  Muchas empresas dedican cantidad de tiempo y dinero a
esfuerzos para encontrar productos “jonrones”. Ellos ponen su fe (y la financiación) en un proyecto prome-
tedor con el ánimo de tomar al mercado por sorpresa, a menudo sin suficiente análisis de las oportunidades
alternativas o futuras tendencias comerciales. Por norma, las estrategias de portafolios exitosos de proyec-
tos requieren el lanzamiento, al futuro, de una serie de sondeos de bajo costo, la idea detrás del monitoreo
ambiental: desarrollo y pruebas de mercado de una serie de prototipos experimentales de productos; algunas
veces la conformación de alianzas estratégicas con socios potenciales. Las empresas exitosas no dependen de
jonrones ni de esfuerzos poco concentrados. Ellas constantemente están construyéndose y probando nuevos
proyectos antes de producirlos a gran escala. Rubbermaid, por ejemplo, rutinariamente coloca decenas de
ideas de nuevos productos en el mercado, y obtiene muestras de respuestas comerciales y utiliza esta infor-
mación para mejorar los posibles productos ganadores y desechar los que no están a la altura.

TRANSICIÓN REGULADA EN TIEMPO  La gerencia exitosa del portafolio requiere un sentido de la opor-
tunidad, especialmente cuando las empresas hacen transiciones de un producto al siguiente. Las empresas
exitosas utilizan la planeación del portafolio de proyectos para desarrollar largos plazos de desarrollo y pla-
nificar el futuro, con el fin de que la transición de un producto a otro sea lo más fluida posible, sobre todo
cuando hay diversas líneas de productos o son parte de una actualización. Gillette, por ejemplo, ha hecho del
desarrollo y venta de nuevos modelos de máquinas de afeitar un negocio lucrativo. La planeación del ciclo de
vida de productos de Gillette es altamente sofisticada, pues permite hacer predicciones exactas del ciclo de
vida de los productos actuales y de los plazos necesarios para el inicio de nuevos proyectos para mantener un
flujo continuo de productos al consumidor.

Problemas en la implementación de la gerencia del portafolio


¿Cuáles son algunos de los problemas comunes en la implementación de un sistema eficaz de gerencia del
portafolio? Aunque muchos factores pueden afectar negativamente la práctica de la gerencia del portafolio, la
investigación reciente parece sugerir que las siguientes son algunas de las áreas problemáticas más comunes.25

COMUNIDADES TÉCNICAS CONSERVADORAS.  En muchas organizaciones, hay un núcleo de profesiona-


les técnicos —ingenieros, científicos investigadores y otros— que desarrollan prototipos para los proyectos.
Un fenómeno común es la falta de voluntad de este grupo, ya sea por orgullo, la inercia organizativa o debido
a los argumentos que apoyan la investigación pura, a renunciar a las ideas de proyectos demasiado arries-
gados, costosos o fuera de sintonía con las metas estratégicas. A menudo, cuando la alta gerencia intenta
recortar el portafolio de proyectos en curso, por razones estratégicas, ingenieros y científicos se resisten a
aceptar su razonamiento. Data General Corporation, un fabricante de computadores y productos de IT, se
vio cada vez más bajo el dominio de su departamento de ingeniería de hardware, el grupo intentó perseguir
sus propias metas de nuevos productos y el fomento de su propia visión de la organización. A mediados de la
década de los años 1990, con un producto tras otro, generando importantes pérdidas, la empresa no podría
seguir funcionando de manera independiente y fue adquirida por EMC Corporation.

PROYECTOS Y PORTAFOLIOS FUERA DE SINCRONIZACIÓN  A veces, después de que una firma ha comen-
zado la realineación y fijación de nuevas prioridades de su visión estratégica, continúa desarrollando proyec-
tos o invirtiendo en un portafolio que ya no refleja su nuevo enfoque estratégico. La estrategia y la gerencia
Resumen 103

del portafolio deben reflejar con precisión un punto de vista similar. Cuando la estrategia y la gerencia del
portafolio no se encuentran alineados, una o las dos cosas probablemente sucederán: el portafolio dirigirá a
la empresa hacia metas obsoletas o la estrategia de la empresa regresa a sus viejos objetivos.

PROYECTOS POCO PROMETEDORES  En el peor de los casos se encuentra una empresa en búsqueda de pro-
yectos de baja calidad o innecesarios. Una reciente batalla en el consumo de la electrónica de video enfrentó la
tecnología del disco de video digital (DVD) de alta definición de Blu-ray de Sony, contra la oferta de Toshiba, del
(Digital Versatile Disc: HD-DVD). Aunque el producto de Sony requiere una máquina relativamente costosa para
reproducir los discos, la empresa convenció a la mayoría del público de que su formato era el mejor. Los principales
fabricantes de contenido y minoristas habían estado retirando progresivamente su apoyo a la tecnología HD-DVD,
dejando solo a Toshiba para continuar por su cuenta el desarrollo. Después de seguir con la tecnología HD-DVD
durante varios años a un alto costo, Toshiba anunció a principios de 2008 que abandonaba su incursión.
Cuando la gerencia del portafolio se orienta a las líneas de productos, los gerentes deben continua-
mente rebalancear el portafolio asegurándose de que hay un número suficiente de productos de diferentes
tipos para compensar a los que tienen puntos débiles. Los ingresos de las “vacas lecheras”, por ejemplo,
pueden financiar nuevos productos innovadores. A veces, el análisis crítico de un portafolio requiere tomar
decisiones difíciles, cancelar proyectos y reasignar recursos. Precisamente, esta atención permanente al por-
tafolio previene irse al traste con proyectos poco prometedores.

RECURSOS ESCASOS  Un recurso clave para todos los proyectos es el capital humano. De hecho, los costos de
personal constituyen una de las mayores fuentes de gasto del proyecto. Otros recursos incluyen las materias pri-
mas, los recursos financieros o materiales que son fundamentales para completar con éxito el proyecto. Antes de
gastar grandes cantidades de tiempo creando un portafolio de proyectos, las organizaciones deben garantizar que
los recursos necesarios estarán disponibles cuando se requieran . Una causa principal para el bajo rendimiento del
portafolio es la falta de recursos adecuados, especialmente de personal, para soportar el desarrollo requerido.
La gerencia del portafolio es el proceso de armonizar las prácticas de gerencia de proyectos de la orga-
nización con su estrategia global de la empresa. Con la complementariedad en su portafolio de proyectos, una
empresa puede garantizar que los equipos de gerencia de proyectos trabajen en conjunto y no en propósitos
cruzados. La gerencia del portafolio es también un símbolo visible de la gerencia estratégica y de las metas
comerciales de una empresa. En conjunto, los proyectos que la empresa opta por promover y desarrollar envían
una señal clara al resto de la organización acerca de las prioridades, el compromiso de los recursos y las orien-
taciones futuras. Por último, la gerencia de portafolio es un método alternativo para la gestión del riesgo global
del proyecto, mediante la búsqueda de un equilibrio continuo entre las diferentes familias de proyectos, entre
riesgos y rentabilidades y entre los proyectos ejecutados de manera eficiente y los proyectos por desarrollar. A
medida que más organizaciones se basan en la gerencia de proyectos para lograr estos fines, probablemente
darán el siguiente paso lógico: organizar sus proyectos por medio de la gerencia del portafolio.

Resumen
1. Explicar seis criterios para un proyecto útil selección/ de screening son: (1) realismo: un modelo eficaz debe
modelo screening.  Ninguna organización puede reflejar los objetivos de la organización, ser razonable a
aprovechar toda oportunidad que se presente. Se debe la luz de las limitaciones de los recursos, como dinero y
realizar una selección y para asegurarse de que se selec- personal, y debe tener en cuenta tanto los riesgos comer-
cionan los proyectos más viables, las empresas desarro- ciales como los técnicos; (2) capacidad: el modelo debe
llan sistemas o directrices de prioridades— modelos ser suficientemente flexible para responder a los cam-
selección/modelos screening (o un conjunto de modelos) bios en las condiciones según las cuales se llevan a cabo
que le ayudarán a tomar las mejores decisiones dentro los proyectos y suficientemente robusto como para darles
de las limitaciones habituales de tiempo y dinero; es cabida a nuevos criterios y restricciones; (3) flexibilidad:
decir, ayudan a ahorrar tiempo y dinero mientras que el modelo debería modificarse fácilmente si las aplicacio-
maximizan la probabilidad de éxito. nes de prueba demuestran que se requieren cambios; (4)
Una serie de modelos de decisión están disponibles facilidad de uso: un modelo debe ser lo suficientemente
para los gerentes responsables de la evaluación y selección simple para que puedan utilizarlo personas de todas las
de proyectos potenciales. Cinco temas importantes que áreas de la organización, debe ser oportuno y generar
los gerentes deben tener en cuenta al evaluar los modelos información rápidamente y permitirles a las personas
104 Capítulo 3  •  Selección de proyectos y gerencia del portafolio

asimilar esa información sin ningún tipo de formación de jerarquía analítica (Analytical Hierarchy Process:
o habilidades especiales; (5) costo: el costo de la recolec- AHP) es un proceso de cuatro pasos que les permite
ción, almacenamiento y organización de la información a los tomadores de decisiones entender la naturaleza
en forma de informes o propuestas debe ser relativamente de la selección de proyectos alternativos. Usando los
bajo en relación con los costos asociados a la implementa- AHP, los decisores deben: (a) definir la estructura de la
ción de un proyecto (es decir, el costo de los modelos debe jerarquía de los criterios que se utilizarán en el proceso
ser suficientemente bajo para fomentar su uso en lugar de decisión; (b) asignar ponderaciones a estos criterios;
de disminuir su aplicabilidad). A esta lista se ha añadido (c) asignar valores numéricos a todas las dimensiones
un criterio más: (6) comparabilidad: “el” modelo debe ser de evaluación; y (d) evaluar las alternativas utilizando
suficientemente amplio para que pueda aplicarse a múlti- los resultados. El AHP ha demostrado crear alterna-
ples proyectos y apoyar las comparaciones generales entre tivas de decisión más precisas y dar lugar a decisiones
proyectos alternativos. con mayor conocimiento, siempre que los tomadores
2. Entender cómo emplear listas de verificación y de decisiones de la organización desarrollen crite-
modelos simples de puntuación para seleccionar los rios de selección precisos y ponderen y evalúen con
proyectos.  Las listas de control les exigen a los toma- honestidad.
dores de decisiones desarrollar una lista de los criterios 4. Aprender a utilizar los conceptos financieros, como
que se consideran importantes al considerar proyectos la frontera eficiente y los modelos riesgo/retorno. 
alternativos. Por ejemplo, una empresa puede decidir Muchos proyectos se seleccionan como resultado de la
que todos los proyectos alternativos deben ser acep- relación potencial riesgo/retorno percibido. Es decir, todos
tables en criterios como rentabilidad de la inversión, los proyectos conllevan riesgo (incertidumbre), por lo que
seguridad, costo de desarrollo, oportunidades comer- las organizaciones de los proyectos tratan de equilibrar el
ciales y aceptabilidad de los interesados. Una vez creada riesgo más alto con expectativas relativamente altas de
la lista de criterios, todos los proyectos alternativos se rendimiento cuando consideran financiar proyectos. El
evalúan contra esta y se les asigna una calificación alta, concepto de frontera eficiente permite que los proyectos
media o baja dependiendo de lo bien que cumplan cada se evalúen entre sí mediante la comparación de los bene-
criterio de la lista de verificación. Los proyetos que pun- ficios potenciales de cada alternativa frente al riesgo espe-
túan más alto mediante criterios relevantes se seleccio- rado para llevar a cabo el proyecto. La frontera eficiente es
nan. Las listas de verificación son útiles porque son sim- el conjunto de opciones de portafolios de proyectos que
ples y requieren que la empresa haga trade-offs entre los ofrece un retorno máximo para cada nivel de riesgo o un
criterios de decisión para determinar qué factores son riesgo mínimo para todos los niveles de retorno.
los más importantes en la selección de nuevos proyec- 5. Emplear los análisis financieros y análisis de opcio-
tos. Una de sus desventajas es la naturaleza subjetiva del nes para evaluar el potencial de las nuevas inversio-
proceso de calificación y otra, el hecho de que asumen nes en proyectos.  El análisis financiero, al utilizar
el mismo peso en la toma de la decisión final para todos flujos de efectivo descontados y tasas internas de rendi-
los criterios, cuando unos pueden ser más importantes miento, nos permiten aplicar el concepto del valor del
que otros. dinero en el tiempo a cualquier decisión que debemos
Los modelos simples de puntuación son simi- tomar respecto a lo atractivo de varios proyectos alter-
lares a listas de verificación, salvo que emplean pesos nativos. El valor temporal del dinero sugiere que los
relativos para cada uno de los criterios de decisión. Por flujos futuros de retorno de un proyecto de inversión
tanto, todos los proyectos alternativos se ponderan deben, al menos, compensar la inversión inicial del
primero, de acuerdo con la puntuación de importan- proyecto, además de proporcionar una cierta tasa de
cia para el criterio y luego se evalúan las puntuaciones retorno requerida, impuesta por la empresa. El análisis
finales uno contra el otro. La ventaja de este método de opciones lleva este proceso un paso más allá y con-
es que se reconoce que los criterios de decisión pue- sidera alternativas en las que una inversión se hace o se
den ponderarse de manera diferente, lo que conduce sacrifica, dependiendo de las inversiones alternativas
a mejores elecciones entre proyectos alternativos. Las razonables que la compañía pueda hacer en el futuro.
desventajas del método surgen de la dificultad en la Cada uno de estos modelos financieros sostiene que el
asignación de valores significativos a los rangos de determinante principal de una inversión atractiva debe
puntuación como “Alta = 3, Media = 2, Baja = 1”. Así, ser el dinero que promete volver. Por tanto, se requiere
existe cierta incertidumbre en la interpretación de los un estimativo razonablemente preciso de los flujos
resultados de los modelos simples de puntuación que futuros de los ingresos para que los modelos financie-
utilizan clasificaciones ponderadas. La utilidad de estos ros puedan generar resultados significativos.
modelos depende de la pertinencia de los criterios de 6. Reconocer los desafíos que se plantean en el manteni-
selección y la exactitud del peso que se les dé. miento de un portafolio óptimo de proyectos para una
3. Usar modelos de puntuación más sofisticadas, organización.  Una serie de desafíos relacionados con
como el proceso de jerarquía analítica.  El proceso la gerencia de un portafolio de proyectos incluyen: (a)
Problemas resueltos 105

las comunidades técnicas conservadoras que se niegan supervisión administrativa para que el equipo de geren-
a apoyar nuevas iniciativas de proyectos; (b) proyectos cia del portafolio tenga la máxima flexibilidad en la bús-
y portafolios de proyectos fuera de sincronización en queda e inversión en proyectos. En segundo lugar, el uso
las que los proyectos no se alinean con la planeación de estrategias de gerencia exitosa de portafolios permite
estratégica general; (c) proyectos no prometedores que la exploración del entorno a bajo costo, y pone en mar-
desequilibran el portafolio; y (d) los recursos escasos que cha una serie de “sondeos” económicos, al futuro, para
hacen imposible apoyar nuevos proyectos. desarrollar y probar en el mercado proyectos alternativos.
7. Comprender los tres elementos claves para una geren- Por último, la gerencia exitosa de portafolios requiere una
cia exitosa de portafolios de proyectos.  Hay tres cla- estrategia de transición regulada en el tiempo, basada en
ves para la gerencia de portafolios de proyectos de éxito. un sentido de la oportunidad necesaria para una transi-
En primer lugar, las empresas necesitan crear o poner ción exitosa de un producto a otro; si el siguiente pro-
a disposición una estructura flexible, con libertad de ducto es un apéndice directo del original o un producto
comunicación, reduciendo el exceso de burocracia y de innovador adicional para el portafolio de la empresa.

Términos clave
Enfoque de comparación Método del valor presente Portafolio de proyectos Valor presente del dinero
por pares (p. 85 ) neto (VPN) (p. 92 ) (p. 98) (p. 90 )
Frontera eficiente (p. 88 ) Modelo de puntuación Proceso de jerarquía Valor temporal del dinero
Gerencia del portafolio de simplificado (p. 81) analítica (AHP) (p. 84 ) (p. 89)
proyectos (p. 98, 77) Modelo screening de Retorno sobre la inversión
Lista de verificación (p. 79) proyectos (p. 79 ) (ROI) (p. 95 )
Método de flujo de efectivo Modelos de perfil (p. 87 ) Riesgo/retorno (p. 87)
descontado (DCF) (p. 90 ) Modelos no numéricos Tasa de rendimiento
Método de periodo de (p. 78 ) requerida (TRR) (p. 93)
recuperación descontado Modelos numéricos (p. 78 ) Tasa interna de retorno
(p. 93 ) Plazo de ejecución (p. 90 ) (TIR) (p. 94 )

Problemas resueltos
3.1 Valor presente neto SOLUCIÓN

Su empresa está tratando de decidir si invertir en una nueva opor- Para responder a esta pregunta, tenemos que organizar los datos
siguientes en un cuadro, así:
tunidad de proyecto, con base en la siguiente información. El de-
sembolso inicial será de $250,000 durante dos años. La firma espera Egreso total = $250,000
Ingreso total = $400,000
invertir $200,000 de inmediato y los últimos $50,000 en el plazo de
Tasa de retorno (r) = 12%
un año. La compañía prevé que el proyecto generará un flujo de in- Tasa de inflación (p) = 3%
gresos de $50,000, $100,000, $200,000 y $75,000 por año, respectiva- Factor de descuento = 1/(1 + r + p)t
mente, a partir del año 2. La tasa de retorno es de 12% y se prevé que
El resultado se muestra en el cuadro 3.11. Debido a que el
la tasa de inflación esperada durante la vida del proyecto se man- flujo de ingresos descontados es positivo ($11,725), el proyecto sería
tenga estable en 3%. ¿En este caso se debe invertir en este proyecto? una buena inversión y debe perseguirse.

CUADRO 3.11  Flujo de efectivo descontado y VPN (II)

Factor de
Año Entradas Salidas Flujo neto descuento VPN
0 $0 $200,000 $(200,000)  1.0000 $(200,000)
1 0 50,000 (50,000)  .8696 (43,480)
2 50,000 0 50,000  .7561 37,805
3 100,000 0 100,000  .6575 65,750
4 200,000 0 200,000  .5718 114,360
5 75,000 0 75,000  .4972 37,290
Total $11,725
106 Capítulo 3  •  Selección de proyectos y gerencia del portafolio

3.2 Periodo de recuperación descontado Inversión en efectivo = $24,000


Ingreso año 1 = $10,000
Su empresa tiene la oportunidad de invertir $75,000 en una nueva
Ingreso año 2 = $10,000
oportunidad de proyecto, pero debido a problemas de flujo de efecti-
Ingreso año 3 = $10,000
vo, su jefe quiere saber cuándo se puede recuperar la inversión inicial.
Tasa de retorno requerida = 12%
Utilizando el método de recuperación descontado, usted determina
que el proyecto debe generar ingresos de $30,000, $30,000, $25,000,
$20,000 y $20,000, respectivamente, para una expectativa de cinco SOLUCIÓN
años después de la terminación del proyecto. La tasa requerida de re-
Primer paso: pruebe con 10%.
torno de su firma es de 10%. Calcule cuánto tiempo debe tomar para
recuperar la inversión inicial del proyecto.
Factor de descuento
SOLUCIÓN Año Ingresos Al 10% VPN
Para responder a esta pregunta, es útil organizar la información en
1 $10,000 .909 $  9,090
un cuadro. Recuerde que:
2 10,000 .826 8,260
Flujo total saliente = $75,000 3 10,000 .751  7,510
Tasa de retorno requerida = 10%
Valor presente de 24,860
Factor de descuento = 1/(1 + .10)t
los flujos entrantes
Inversiones en – 24,000
efectivo
Flujo de Factor de Flujo Diferencia $   860
Año efectivo descuento neto
0 $ 1.00 $ Decisión: la diferencia de valor presente en 10% es $860, que es de-
($75,000) ($75,000) masiado alto. Pruebe con un tipo de descuento más alto.
1 30,000  .91 27,300 Segundo paso: pruebe con 12%.
2 30,000  .83 24,900
3 25,000  .75 18,750 Factor de descuento
4 20,000  .68 13,600
5 20,000  .62 12,400 Año Ingresos Al 12% VPN
Periodo de 1 $10,000 .893 $8,930
recuperación 2 10,000 .797 7,970
  = 3.3 años 3 10,000 .712  7,120
Valor presente de 24,020
3.3 Tasa interna de retorno los flujos entrantes
Supongamos que un proyecto requiere una inversión inicial en efec- Inversiones en – 24,000
tivo de $24,000 y se espera que genere ingresos por $10,000, $10,000 efectivo
y $10,000 para los próximos tres años. Además, se supone que la tasa Diferencia $20
de retorno requerida para los nuevos proyectos de la empresa es de
12%. ¿Vale la pena la financiación del proyecto? ¿Sería una buena Decision: la diferencia de valor presente en 12% es de $20, lo cual
inversión si la tasa de retorno requerida de la compañía fuera de sugiere que 12% es una buena aproximación de la TIR. Este proyecto
15%? Utilice los siguientes datos para determinar las respuestas a sería una buena inversión en 12%, pero no sería aceptable si la tasa
estas preguntas: de retorno requerida de la empresa fuera de 15%.

Preguntas para discusión


1. Si se va a dar prioridad a los criterios de un modelo de scree- 4. ¿Cuáles son las ventajas y desventajas del modelo de perfil para
ning, ¿qué criterios ubicaría usted en la parte superior de su lista el screening de proyectos? Sea específico en los problemas que
de prioridades? ¿Por qué? puedan surgir en la identificación de la frontera eficiente.
2. ¿Cuáles son las ventajas y desventajas de las listas de verifica- 5. ¿Los modelos financieros son superiores a otros modelos de
ción, como método de screening de proyectos alternativos? screening? ¿Son inferiores?
3. ¿Cómo utilizar el proceso de jerarquía analítica (AHP) como 6. ¿Cómo funciona el modelo de opciones al abordar el problema
ayuda en el screening de proyectos? En particular, ¿qué aspectos de la inversión no recuperable en un proyecto?
parece abordar y mejorar directamente el proceso de selección 7. ¿Qué ventajas ve usted en el criterio de screening Tollgate de
AHP? GE? ¿Qué desventajas percibe ? ¿Cómo cambiar esto?
Problemas 107

8. ¿Por qué la gerencia de portafolios de proyectos es particular- 10. ¿Cuáles son algunas de las principales dificultades en la imple-
mente difícil en la industria farmacéutica? mentación exitosa de prácticas de gerencia del portafolio de
9. Cuáles son las claves para una gerencia exitosa de portafolios de proyectos?
proyectos?

Problemas
1. Lista de verificación. Suponga que está tratando de elegir cuál Construya un modelo de lista de verificación del proyecto para
de los dos proyectos de IT a aceptar. Su empresa cuenta con screening de estas cuatro alternativas. Basado en su modelo,
tres criterios principales de selección para la evaluación de ¿qué proyecto es la mejor opción? ¿Por qué? ¿Cuál es el peor?
todos los proyectos de IT: (1) tecnología probada; (2) facilidad ¿Por qué?
de la transición; (3) de ahorro de costos. 3. Modelo de puntuación. Supongamos que la información del
Una opción, el proyecto Demeter se evalúa como: problema 2 se complementó con pesos de importancia relativa
Tecnología Alta para cada uno de los cuatro criterios de evaluación, en la que
Facilidad de transición Baja 1 = poca importancia y 4 = mucha importancia:
Ahorro de costos proyectados Alta
La segunda opción, el proyecto El Cairo se evalúa como: Criterios de evaluación Pesos de importancia
Tecnología Media
1. Potencial de ganancias 4
Facilidad de transición Alta
Ahorro de costos proyectados Alta 2. Ausencia de riesgo 3
3. Seguridad 1
Construya un cuadro para la identificación de los proyectos,
4. Ventaja competitiva 3
sus criterios de evaluación y calificación.
De acuerdo con su análisis, ¿qué proyecto argumentaría a favor Suponga, también, que la evaluación Alta recibe una puntua-
de adoptar? ¿Por qué? ción de 3; Media, 2 y Baja 1. Vuelva a crear el modelo de califi-
2. Lista de verificación. Tenga en cuenta la siguiente informa- cación del proyecto y evaluar de nuevo las cuatro opciones del
ción en la elección entre los cuatro proyectos alternativos que a proyecto (A, B, C y D). Ahora, ¿qué alternativa de proyecto es
continuación se han etiquetado como A, B, C y D. Cada uno se la mejor? ¿Por qué?
ha evaluado en función de cuatro criterios: 4. Modelo de puntuación. Ahora se supone que para el problema
• Potencial de ganancias 3, los pesos de importancia se alteran como sigue:
• Ausencia de riesgo Criterios de evaluación Pesos de importancia
• Seguridad
• Ventaja competitiva 1. Potencial de ganancias 1
2. Ausencia de riesgo 1
Proyecto A tiene: 3. Seguridad 4
4. Ventaja competitiva 2
Potencial de Alto Seguridad Alta
ganancias
Ausencia de riesgo Baja Ventaja Media 5. Modelo de screening. Suponga que los siguientes criterios per-
competitiva tinentes para el proceso de screening de diversas oportunidades
de proyectos se ponderan según su importancia como sigue:
Proyecto B tiene:
Calidad (7)
Potencial de Bajo Seguridad Media
Costo (3)
ganancias
Acelerar el mercado (5)
Ausencia de riesgo Media Ventaja Media Visibilidad (1)
competitiva Confiabilidad (7)
Proyecto C tiene: Nuestra empresa cuenta con cuatro proyectos alternativos que
Potencial de Medio Seguridad Baja cumplen estas características claves de la siguiente manera:
ganancias
Ausencia de riesgo Media Ventaja Baja Alfa Beta Gamma Delta
competitiva Calidad 1 3 3 5
Proyecto D tiene: Costo 7 7 5 3
Velocidad 5 5 3 5
Potencial de Alto Seguridad Media
Visibilidad 3 1 5 1
ganancias
Confiabilidad 5 5 7 7
Ausencia de riesgo Alta Ventaja Media
competitiva
108 Capítulo 3  •  Selección de proyectos y gerencia del portafolio

Construya una matriz de screening del proyecto para identi- 20% y se prevé que la inflación se mantenga en 3% en el futuro
ficar entre estos cuatro proyectos el candidato más probable previsible. La información pertinente sobre cada alternativa se
para implementarse. muestra en el cuadro de la página 109.
6. Modelo de perfil. Suponga el modelo de perfil de proyecto ¿Qué proyecto debería ser la primera prioridad para la
que se muestra en la figura 3.9. Defina la frontera eficiente. empresa? ¿Por qué? Si la empresa pudiera invertir en más
Las líneas punteadas representan el rendimiento mínimo y el de un proyecto, indique el orden en el que se debería darles
riesgo máximo que la empresa acepta. ¿Qué proyectos sería prioridad a los proyectos alternativos.
adecuado conservar y cuáles deben eliminarse del portafolio de 12. Modelo de opciones. Una empresa manufacturera está decidiendo
la compañía? ¿Por qué? si va a iniciar un nuevo proyecto. El éxito del proyecto depende
en gran medida del estado de la economía, que tiene un 50/50 de
oportunidad de ser suficientemente fuerte para soportar el riesgo.
D El proyecto requerirá una inversión inicial de $1 millón, y la com-
E
pañía espera ganar $500,000 en ingresos anuales del proyecto, a
C menos que la economía entre en recesión, en cuyo caso el proyecto
retornará solo $100,000 por año. La empresa requiere una retorno
F de 12% sobre sus inversiones. ¿Se debe desarrollar el proyecto? Si
Riesgo
B la empresa decide esperar un año, la economía tiene una oportu-
nidad de 75% de mejorar lo suficiente para garantizar $500,000 en
ingresos anuales. ¿Tiene sentido que esperar un año antes de hacer
A la inversión? Utilice el modelo de opciones para la evaluación del
proyecto y así responder a estas dos preguntas.
Retorno 13. Modelo de opciones. Massivesoft Corporation trata de decidir
si invertir en un nuevo proyecto de software. La inversión ini-
FIGURA 3.9  Modelo de perfil de proyecto (problema 6) cial será de $5 millones. El proyecto tiene una probabilidad de
40% de un retorno de $1 millón por año en el futuro y una pro-
babilidad de 60% de que la generación de ingresos sea de solo
$100,000 . Suponiendo que Massivesoft requiere 15% de retorno
7. Modelo de perfil. Usando la información del modelo de perfil sobre las inversiones de capital, ¿este es un proyecto viable? Si
del problema 6, argumente por qué el proyecto B es preferible Massivesoft decide esperar un año antes de invertir en el pro-
al proyecto C. yecto, sus probabilidades de retornar $1 millón por año mejoran
8. Periodo de recuperación descontado. Su compañía considera 70%. ¿Debe Massivesoft esperar un año para iniciar el proyecto?
seriamente invertir en una nueva oportunidad de proyecto, pero Utilice el modelo de opciones para la evaluación de proyectos y
el flujo de efectivo es ajustado. La alta gerencia está preocupada así responder a estas dos preguntas.
por cuánto tiempo tomará para que este nuevo proyecto pueda 14. Gerencia del portafolio. Crown Corporation está interesada en
recuperar la inversión inicial de $50,000. Se ha determinado que ampliar su portafolio de proyectos. Esta empresa se especializa
el proyecto debe generar ingresos de $30,000, $30,000, $40,000, en proyectos de recuperación de tierras y conservación del agua;
$25,000, y $15,000 para los próximos cinco años. La tasa de se anticipa un gran aumento en la demanda de pilas como una
retorno requerida por su empresa es de 15%. ¿Cuánto tiempo se alternativa a los métodos actuales de generación de energía y su
tarda en recuperar la inversión inicial? uso en casa. Aunque los proyectos de pila de combustible impli-
9. Valor presente neto. Suponga que su empresa quiere elegir can utilizar tecnologías diferentes a aquellas en los proyectos que
entre dos opciones de proyecto: Crown se especializa en la actualidad, el potencial de ganancias
• Proyecto A: $500,000 hoy invertido producirá un flujo espe- es muy grande. Elabore una lista de ventajas y desventajas aso-
rado de ingresos de $150,000 por año durante cinco años, a ciadas a este potencial de expansión del portafolio de proyectos
partir del año 1. de Crown. Según su opinión, ¿son mayores los riesgos que las
• Proyecto B: se prevé una inversión inicial de $400,000 para pro- ventajas de esta medida? Justifique su respuesta.
ducir este flujo de ingresos: año 1 = 0; año 2 = $50,000; año 3 = 15. Screening de proyectos. Suponga que usted es el administrador de
$200,000; año 4 = $300,000; año 5 = $200,000. la información para un gran sistema de salud urbano. Últimamente
se le ha bombardeado con solicitudes de nuevos proyectos, inclui-
Suponga una tasa de retorno requerida para su empresa de 10% dos actualizaciones del sistema, servicios de apoyo, mantenimiento
y se espera que la inflación se mantenga estable en 3% durante la de registros automatizados, facturación, etc. Con un promedio
vida del proyecto. ¿Cuál es la mejor inversión? ¿Por qué? de 50 proyectos de software y hardware en curso en cualquier
10. Valor presente neto. El vicepresidente de Sistemas de Gestión de momento, usted decide que es necesario crear un sistema para
la Información le informa que se está investigando la posibilidad el screening de nuevas solicitudes de proyectos de los diferentes
de automatizar el sistema de registro de pedidos de la empresa. Se departamentos dentro del sistema de atención de salud. Desarrolle
ha proyectado que el nuevo sistema reducirá los costos laborales una identificación de proyectos y un sistema de screening similar al
en $30,000 cada año durante los próximos cinco años. El precio de proceso Tollgate de GE. ¿Qué elementos incluiría en este sistema?
compra (incluidas la instalación y las pruebas) del nuevo sistema ¿Cuántos pasos recomendaría? ¿En qué puntos del proceso debe-
es de $110,000. ¿Cuál es el valor presente neto de esta inversión si rían instalarse “controles de decisión”? ¿Cómo puede un sistema
la tasa de descuento es de 10% anual? como Tollgate, para una empresa de desarrollo de software, diferir
1 1. Valor presente neto. La empresa cuenta con cuatro alterna- frente a uno usado por una empresa de arquitectura especializada
tivas de inversión. La tasa de retorno de los proyectos es de en el desarrollo de edificios de oficinas comerciales?
Estudio de caso 3.1 109

Proyecto Carol Año Inversión Flujos de ingresos


0 $500,000 $ 0
1 50,000
2 250,000
3 350,000
Proyecto George Año Inversión Flujos de ingresos
0 $250,000 $ 0
1 75,000
2 75,000
3 75,000
4 50,000
Proyecto Thomas Año Inversión Flujos de ingresos
0 $1,000,000 $ 0
1 200,000
2 200,000
3 200,000
4 200,000
5 200,000
6 200,000
Proyecto Anna Año Inversión Flujos de ingresos
0 $75,000 $ 0
1 15,000
2 25,000
3 50,000
4 50,000
5 150,000

Estudio de caso 3.1


Keflavik Paper Company
En los últimos años, Keflavik Paper Company ha tenido ventas mediante el desarrollo de nuevos productos comer-
problemas con su proceso de gerencia de proyectos. Por ciales de forma rápida y con una mejor orientación a las
ejemplo, una serie de proyectos comerciales han llegado necesidades específicas del cliente. Hasta ahora, los resul-
tarde, con presupuesto excedido y el rendimiento del pro- tados no han sido alentadores. El registro de desarrollo de
ducto ha sido inconsistente. Un análisis exhaustivo del pro- proyectos de la empresa es irregular. Algunos proyectos se
ceso ha rastreado muchos de los problemas relacionados han entregado a tiempo, pero otros tarde, los presupues-
con los métodos defectuosos de selección de proyectos. tos se han excedido de forma rutinaria y el rendimiento del
Keflavik es una empresa de tamaño mediano que producto ha sido inconsistente, con algunos proyectos que
fabrica una variedad de productos de papel, como papeles generan buena rentabilidad y otros que pierden dinero.
especiales y papeles estucados utilizados en las industrias La alta gerencia contrató a un consultor para anali-
de la fotografía y la impresión. A pesar de las coyunturas zar los procesos de la empresa y determinar la forma más
desfavorables, debido a las condiciones económicas genera- eficaz de corregir sus procedimientos de gerencia de pro-
les, las ventas anuales de la empresa han crecido de manera yectos. La consultora atribuyó los problemas principales
constante, aunque lentamente. Hace unos cinco años, no a los procesos de gerencia de proyectos en sí, sino a la
Keflavik se embarcó en un enfoque basado en proyectos manera en la que se añaden los proyectos al portafolio de la
para nuevas oportunidades de productos. El objetivo era compañía. El mecanismo principal para la nueva selección
mejorar la rentabilidad y generar un volumen adicional de de proyectos se centró casi exclusivamente en modelos de

(continúa)
110 Capítulo 3  •  Selección de proyectos y gerencia del portafolio

flujo de efectivo descontado, como el análisis del valor pre- tuvieron que evaluarse en términos de los objetivos estra-
sente neto. Esencialmente, si un proyecto promete flujos de tégicos de la compañía y estaban obligados a demostrar la
ingresos rentables, es aprobado por la alta gerencia. complementariedad con su portafolio actual. Además, él
Un resultado de esta práctica fue el desarrollo de una recomendó analizar las habilidades actuales de los geren-
“familia” de proyectos casi sin relación alguna. Al parecer a tes de proyectos, con el fin de ajustarlas a los tipos de pro-
nadie, nunca se le preguntó si los proyectos que se han aña- yectos que la empresa está ejecutando. Aunque Keflavik
dido al portafolio se ajustaban con otros proyectos en curso. ha iniciado la implementación de estas y otras recomen-
Keflavik intentó expandirse en papeles revestidos, produc- daciones, el progreso hasta ahora ha sido lento. En par-
tos fotográficos, material de envío y embalaje y otras líneas ticular, los altos gerentes han encontrado difícil rechazar
que se apartaron lejos de nicho original de la empresa. Los las oportunidades que ofrecen flujo de efectivo positivo.
nuevos proyectos rara vez se midieron respecto a la misión También han tenido que volver a aprender la importancia
estratégica de la empresa y se hizo poco esfuerzo para su eva- de la priorización de proyectos. Sin embargo, un nuevo
luación de acuerdo con los recursos técnicos disponibles. esquema de prioridades está en marcha y parece estar
Por ejemplo, algunos de los nuevos proyectos no pudie- mejorando tanto en la selección de nuevas oportunidades
ron adaptarse porque requerían aprendizaje organizacional de proyectos como la capacidad de la empresa para gestio-
significativo, nuevos conocimientos técnicos y entrenamiento nar los proyectos una vez que se financian.
(todo lo cual era costoso y lento). El resultado fue un portafolio
de proyectos diversos, que fue difícil de manejar. Además, la Preguntas para discusión
diversidad de la nueva línea de productos y procesos de desa-
1. Keflavik Paper representa un buen ejemplo de los
rrollo disminuyó el aprendizaje organizacional y hacía impo-
peligros de la excesiva dependencia de una técnica
sible que los gerentes de proyectos de Keflavik se movieran
de selección (en este caso, el flujo de efectivo descon-
fácilmente de una asignación a la siguiente. La mezcolanza
tado). ¿Cómo podría conducir a problemas similares
de proyectos hace difícil para los gerentes aplicar las lecciones
la dependencia excesiva o exclusiva de otros métodos
aprendidas de un proyecto a otro.
de screening discutidos en este capítulo?
Debido a que los conocimientos adquiridos en un
2. Suponga que usted es responsable de mantener el
proyecto eran en gran parte intransferibles, los equipos de
portafolio de proyectos de Keflavik. Mencione algu-
proyectos habitualmente tenían que volver a aprender los
nos criterios claves que se deben utilizar en la evalua-
procesos cuando se trasladaban a un nuevo proyecto.
ción de todos los nuevos proyectos antes de que se
El consultor le sugirió a Keflavik reconsiderar su
agreguen al portafolio actual.
proceso de screening y selección de proyectos. Con el
3. ¿Cómo demuestra este caso el efecto de los métodos
fin de prestar un poco de coherencia a su portafolio, la
pobres de screening de proyectos sobre la capacidad de
empresa tenía que incluir mecanismos alternativos de una empresa para gestionar sus proyectos de manera
screening. Todos los nuevos proyectos, por ejemplo, efectiva?

Estudio de caso 3.2


Selección de proyectos en Nova Western, Inc.
Phyllis Henry, vice presidente de desarrollo de nuevos pro- por dos grupos independientes dentro del nuevo depar-
ductos, se sentó en su escritorio tratando de hallarles sentido tamento de desarrollo de productos. Después de varias
a las últimas propuestas de nuevos proyectos que acababa de semanas de análisis, se constató que dos principales can-
recibir de su personal. Nova Western, Inc. es un gran desa- didatos habían surgido como nuevas oportunidades ópti-
rrollador de software empresarial y programas de aplicación, mas de proyectos. Un proyecto, cuyo nombre en código es
que ha experimentado un descenso en sus ingresos operacio- Janus, fue promovido por el jefe de desarrollo de software.
nales en los últimos tres trimestres. El equipo directivo estaba La otra idea de proyecto, Gemini, contó con el apoyo
sintiendo la presión de la junta directiva para tomar medi- de la división de aplicaciones empresariales. La tarea de
das para corregir esta tendencia a la baja en los ingresos y la Phyllis para su personal era preparar una evaluación de
rentabilidad. La opinión de consenso es que Nova Western ambos proyectos, con el fin de decidir cuál debe apoyar
necesitaba rápidamente nuevas ideas de productos. Nova Western. Debido a las restricciones presupuestarias,
El informe que Phyllis estaba leyendo contenía los no había manera de que ambos proyectos pudieran ser
resultados de un proyecto de screening llevado a cabo financiados.
(continued)
Estudio de caso 3.1 111

El primer equipo de evaluación utilizó un modelo


Proyecto Janus
de puntuación para evaluar los dos proyectos, basado en
las categorías estratégicas clave para Nova Western. Las Inversión inicial = $250,000
categorías que emplearon fueron: (1) ajuste estratégico; Vida del proyecto = 5 años
(2) probabilidad de éxito técnico; (3) riesgo financiero; Flujos futuros previstos de efectivo:
(4) potencial de ganancias; (5) apalancamiento estraté- Año 1 = $50,000
gico (capacidad del proyecto para emplear y mejorar los
Año 2 = 100,000
recursos y capacidades técnicas de la empresa). El equipo
evaluó los dos proyectos utilizando estas categorías, como Año 3 = 100,000
se muestra. Las puntuaciones se basan en: 1 = bajo, 2 = Año 4 = 200,000
medio y 3 = alto. Año 5 = 75,000
Proyecto Janus
VPN calculado = $60,995
Puntaje
Categoría Importancia Puntaje ponderado Proyecto Gemini
1. Ajuste 3 2 6
Inversión inicial = $400,000
estratégico
2. Probabilidad de 2 2 4 Vida del proyecto = 3 años
éxito técnico Flujos futuros previstos de efectivo:
3. Riesgo 2 1 2 Año 1 = $75,000
financiero Año 2 = 250,000
4. Potencial de 3 3 9 Año 3 = 300,000
ganancias
VPN calculado = $25,695
5. Apalancamiento 1 1 1
estratégico
De acuerdo con este análisis, el proyecto Janus sería
Puntaje = 22
el elegido.
El análisis de los dos proyectos por diferentes
Proyecto Gemini medios obtuvo distintas conclusiones. El modelo de pun-
Puntaje tuación indica que el proyecto Gemini es la mejor alter-
Categoría Importancia Puntaje ponderado nativa y el screening financiero a favor del mayor VPN
del proyecto Janus. Phyllis, quien debía presentar su reco-
1. Ajuste 3 3 9
mendación al equipo de alta gerencia en la tarde, todavía
estratégico
no estaba seguro de qué proyecto sugerir. Las evaluacio-
2. Probabilidad de 2 2 4
nes parecían generar más preguntas que respuestas.
éxito técnico
3. Riesgo 2 2 4
Preguntas para discusión
financiero
4. Potencial de 3 3 9 1. Phyllis lo ha llamado a su oficina para ayudarle a dar
ganancias sentido a las contradicciones presentadas en la eva-
5. Apalancamiento 1 2 2 luación de los dos proyectos. ¿Cómo explica las razo-
estratégico nes de la divergencia de opiniones de una técnica a
Puntaje = 28 otra? ¿Cuáles son las fortalezas y debilidades de cada
método de screening?
Los resultados obtenidos por este primer equipo 2. Con base en los dos análisis, seleccione el proyecto
sugirieron que el proyecto Gemini sería la mejor opción que usted piensa que debe seleccionar Nova Western.
para el próximo nuevo proyecto. Justifique su elección.
El segundo equipo de evaluadores presentó un análisis 3. ¿Qué le sugiere este caso del uso de métodos de selec-
de VPN de los dos proyectos de Phyllis. En ese análisis, los ción de proyectos en las organizaciones? ¿Cómo
evaluadores asumieron una tasa de rendimiento de 15% y resolvería las contradicciones que se encuentran en
una tasa de inflación esperada de 3% durante la vida del pro- este ejemplo?
yecto. Los hallazgos de este equipo han sido los siguientes:
112 Capítulo 3  •  Selección de proyectos y gerencia del portafolio

Ejercicios en internet
1. Ingrese a los sitios web de las siguientes organizaciones: de mantener una alineación estratégica con su portafolio de
proyectos, ¿qué opciones de proyecto propondría usted?
a. Farmacia Merck & Company: www.merck.com/
2. Acceda al sitio web www-01.ibm.com/software/awdtools/portfolio
about /
/. ¿Cuál es la filosofía de IBM en relación con la gerencia del porta-
b. Boeing Corporation: www.boeing.com/companyoffices/
folio de proyectos, según lo demuestran sus productos de software?
aboutus/index.html c. Rolls-Royce, Pl.
¿Qué quieren decir al afirmar que su objetivo es ayudar a los clien-
c. Rolls-Royce, Plc.: www.rolls-royce.com
tes a “superar la influencia de la voz más fuerte en la habitación y
d. ExxonMobil, Inc.: www.exxonmobil.com/Corporate/
utilizar la información objetiva para apoyar la toma de decisiones”?
about.aspx
3. Lectura en internet: Pellegrinelli, S. (1997). Programme man-
Basado en la revisión de la misión y los objetivos estratégicos agement: Organizing project-based change,” International
de las empresas, ¿qué tipos de proyectos se puede esperar que Journal of Project Management, 15: 141–49. Este artículo se
persigan? Si usted trabajara para una de estas empresas y tratara puede encontrar en el sitio web Prentice Hall Companion.

Notas
1. Foti, R. (2002). “Priority decisions,” PMNetwork, 16(4): 24– 10. Millet, I. (1994, 15 de febrero). “Who’s on first?” CIO
29; Crawford, J. K. (2001). “Portfolio management: Overview Magazine, pp. 24–27.
and best practices,” in J. Knutson (Ed.), Project Management 11. Mian, S. A., and Dai, C. X. (1999). “Decision-making over the
for Business Professionals. New York: Wiley, pp. 33–48; project life cycle: An analytical hierarchy approach,” Project
Wheatley, M. (2009). “Making the cut,” PMNetwork, 23(6): Management Journal, 30(1): 40–52.
44–48. 12. Foreman, E. H., Saaty, T. L., Selly, M., and Waldron, R.
2. Pascale, S., Carland, J. W., and Carland, J. C. (1997). “A (1996). Expert Choice. McLean, VA: Decision Support
comparative analysis of two concept evaluation methods for Software.
new product development projects,” Project Management 13. Millet, I., and Schoner, B. (2005). “Incorporating negative
Journal, 28(4): 47–52; Wheelwright, S. C., and Clark, K. B. values into the Analytical Hierarchy Process,” Computers
(1992, marzo-abril). “Creating project plans to focus product and Operations Research, 12(3): 163–73.
development,” Harvard Business Review, 70(2): 70–82. 14. Evans, D. A., and Souder, W. E. (1998). “Methods for selecting
3. Souder, W. E., and Sherman, J. D. (1994). Managing New and evaluating projects,” in Pinto, J. K. (Ed.), The Project
Technology Development. New York: McGraw-Hill; Souder, Management Institute Project Management Handbook. San
W. E. (1983). Project Selection and Economic Appraisal. New Francisco, CA: Jossey-Bass.
York: Van Nostrand Reinhold. 15. Reilly, F. K. (1985). Investment Analysis and Portfolio
4. Meredith, J. R., and Mantel, Jr., S. J. (2003). Project Management, 2nd ed. Chicago, IL: The Dryden Press.
Management, 5th ed. New York: Wiley. 16. Keown, A. J., Scott, Jr., D. F., Martin, J. D., and Petty, J. W.
5. Khorramshahgol, R., Azani, H., and Gousty, Y. (1988). “An (1996). Basic Financial Management, 7th ed. Upper Saddle
integrated approach to project evaluation and selection,” River, NJ: Prentice Hall; Evans, D. A., and Souder, W. E.
IEEE Transactions on Engineering Management, EM-35(4): (1998). “Methods for selecting and evaluating projects,” in
265–70; Raz, T. (1997). “An iterative screening methodology Pinto, J. K. (Ed.), The Project Management Institute Project
for selecting project alternatives,” Project Management Management Handbook. San Francisco, CA: Jossey-Bass.
Journal, 28(4): 34–39. 17. Dixit, A. K., and Pindyck, R. S. (1994). Investment under
6. Cleland, D. I. (1988). “Project stakeholder management,” in Uncertainty. Princeton, NJ: Princeton University Press;
Cleland, D. I., and King, W. R. (Eds.), Project Management Huchzermeier, W., and Loch, C. H. (2001). “Project
Handbook, 2nd ed. New York: Van Nostrand Reinhold, pp. management under risk: Using the real options approach to
275–301. evaluate flexibility in R&D,” Management Science, 47(1): 85–
7. Artto, K. A., Martinsuo, M., and Aalto, T. (Eds.) (2001). 101; Chan, T., Zhang, J., and Lai, K-K. (2009). “An integrated
Project Portfolio Management: Strategic Management real options evaluating model for information technology
Through Projects. Helsinki: Project Management projects under multiple risks,” International Journal of
Association; Artto, K. A. (2001). “Management of project- Project Management, 27(8): 776–86; Yeo, K. T., and Qiu, F.
oriented organization— Conceptual analysis,” in Artto, K. (2003). “The value of management flexibility: A real option
A., Martinsuo, M., and Aalto, T. (Eds.), Project Portfolio approach to investment evaluation,” International Journal of
Management: Strategic Management Through Projects. Project Management, 21(4): 243–50.
Helsinki: Project Management Association. 18. Meredith, J. R., and Mantel, S. J. (2003). Project Management,
8. Pinto, J. K., and Millet, I. (1999). Successful Information 5th ed. New York: Wiley.
System Implementation: The Human Side, 2nd ed. Newtown 19. Dye, L. D., and Pennypacker, J. S. (Eds.) (1999). Project
Square, PA: Project Management Institute. Portfolio Management: Selecting and Prioritizing Projects
9. Saaty, T. L. (1996). The Analytical Hierarchy Process. for Competitive Advantage. West Chester, PA: Center for
Pittsburgh, PA: RWS Publications. Business Practices.
Notas 113

20. Elton, J., and Roe, J. (1998, marzo-abril). “Bringing discipline Portfolio Management: Strategic Management Through
to project management,” Harvard Business Review, 76(2): Projects. Helsinki: Project Management Association, pp.
153–59. 107–140.
21. Artto, K. A. (2001). “Management of project-oriented 24. Brown, S. L., and Eisenhardt, K. M. (1997). “The art
organization— Conceptual analysis,” in Artto, K. A., of continuous change: Linking complexity theory and
Martinsuo, M., and Aalto, T. (Eds.), Project Portfolio time-paced evolution in relentlessly shifting organizations,”
Management: Strategic Management Through Projects. Administrative Science Quarterly, 42(1): 1–34.
Helsinki: Project Management Association. 25. Cooper, R., and Edgett, S. (1997). “Portfolio management
22. “Strategic realignment of brand portfolio,” (2010, 8 de in new product development: Less from the leaders I,”
noviembre), http://www.evaluatepharma.com/Universal/ Research Technology Management, 40(5): 16–28; Longman,
View. aspx?type=Story&id=228881. A., Sandahl, D., and Speir, W. (1999). “Preventing project
23. Lehtonen, M. (2001). “Resource allocation and project proliferation,” PMNetwork, 13(7): 39–41; Dobson, M. (1999).
portfolio management in pharmaceutical R&D,” in Artto, The Juggler’s Guide to Managing Multiple Projects. Newtown
K. A., Marinsuo, M., and Aalto, T. (Eds.). (2001). Project Square, PA: Project Management Institute.
CAPÍTULO

4
Liderazgo y el gerente de proyectos

Contenido del capítulo


PERFIL DE PROYECTO ¿Qué hacen los campeones?
Aziza Chaouni y su proyecto para salvar un río Cómo hacer un campeón
INTRODUCCIÓN GERENTES DE PROYECTOS EN LA PRÁCTICA
4.1 LÍDERES VERSUS GERENTES Bill Mowery, CSC
4.2 CÓMO LIDERA UN GERENTE DE PROYECTOS 4.5 EL NUEVO LIDERAZGO DE PROYECTOS
Adquisición de recursos del proyecto PERFIL DE PROYECTO
Motivación y creación de equipos El reto de la gerencia internacional
Tener visión y luchar contra los incendios 4.6 PROFESIONALISMO EN LA GERENCIA DE
Comunicación PROYECTOS
INVESTIGACIÓN DE GERENCIA DE PROYECTOS EN Resumen
SÍNTESIS Términos clave
Liderazgo e inteligencia emocional Preguntas para discusión
4.3 CARACTERÍSTICAS DE LOS LÍDERES EFECTIVOS Estudio de caso 4.1 En busca de gerentes de proyectos efectivos
DE PROYECTOS Estudio de caso 4.2 Encontrar la inteligencia emocional para
Conclusiones acerca de los líderes de proyectos ser un verdadero líder
PERFIL DE PROYECTO Estudio de caso 4.3 Problemas con John
Dr. Elattuvalapil Sreedharan, gerencia de proyecto de Ejercicios en internet
estrella del rock en India Preguntas de ejemplo del examen para la certificación PMP®
Líderazgo y orientación temporal Notas
4.4 CAMPEONES DE PROYECTOS
Campeones: ¿quiénes son?

Objetivos de aprendizaje
Al finalizar el capítulo, el estudiante estará en capacidad de:
1. Comprender cómo la gerencia de proyectos es una profesión “basada en el líder”.
2. Distinguir entre el papel de un gerente y las características de un líder.
3. Entender el concepto de inteligencia emocional y su relación con la forma en que lideran los gerentes de proyectos.
4. Reconocer los rasgos más importantes e influyentes en el liderazgo efectivo en los proyectos.
5. Reconocer las implicaciones de la orientación temporal en la gerencia de proyectos.
6. Identificar los principales papeles que desempeña el campeón en el éxito del proyecto.
7. Reconocer los principios que caracterizan el nuevo liderazgo en proyectos.
8. Comprender el desarrollo de la profesionalización de la disciplina gerencia de proyectos.
114
 115

CONCEPTOS BÁSICOS DE LOS FUNDAMENTOS PARA LA GERENCIA DE PROYECTOS


(PROJECT MANAGEMENT BODY OF KNOWLEDGE, PMBOK® GUIDE 5A. EDICIÓN)
CUBIERTOS EN ESTE CAPÍTULO
1. Rol del gerente del proyecto (PMBOK, sección 1.7)
2. Dirigir y gestionar el trabajo del proyecto (PMBOK, sección 4.3)
3. Desarrollar el equipo del proyecto (PMBOK, sección 9.3)
4. Dirigir el equipo del proyecto (PMBOK, sección 9.4)
5. Gerencia de las comunicaciones del proyecto (PMBOK, sección10)

PERFIL DE PROYECTO

Aziza Chaouni y su proyecto para salvar un río


Construida en el siglo ix, la ciudad marroquí de Fez es una fascinante mezcla de antiguos palacios, calles estrechas y
sinuosas, bazares y mezquitas, centradas en “La Medina”, el casco antiguo de la ciudad. El río que da nombre a la ciudad
ha servido durante siglos como el elemento vital para la población, pero, por desgracia, esos días de gloria ya pasaron.
Desde la década de 1950, el río Fez ha venido contaminándose por vertidos no regulados y su proximidad a las curtiem-
bres. En los últimos años, los lugareños lo han rebautizado como el “Río de la basura” y durante gran parte de su paso
por la ciudad, se canaliza en una serie de vertederos, pasajes y cubiertas de hormigón para sofocar el peor de los olores
químicos. Como una monstruosidad y un peligro para la salud, el río de la basura requiere revitalización.
Un equipo de trabajo encabezado por un antiguo residente de Fez, Aziza Chaouni, decidió revivir el río y devol-
verle su antigua gloria. La propuesta original de Chaouni para revitalizar el río y la zona de La Medina recibió el
primer premio de 300,000 dólares del concurso de la Holcim Foundation for Sustainable Construction la Construcción
Sostenible. Los autores del proyecto formaron la organización no gubernamental (ONG) Sauvons Oued Fez (Save the
Fez River), una red para promover los subproyectos de la recuperación y fomentar la participación de la comunidad.
Trabajando con las autoridades de la ciudad de Fez, Chaouni y su equipo de 20 miembros se propuso un ambicioso plan
para mejorar el río y el espacio de vida dentro de La Medina, un lugar estrecho y lleno de gente que alberga a más de
200,000 personas. La Medina es también el hogar de decenas de pozos de teñido para la industria del cuero, por lo que
el sitio es ruidoso, abarrotado y de mal olor. El proyecto incluye una serie de elementos: la creación de espacios verdes
en las zonas más pobres; la reubicación de las curtiembres altamente contaminantes a los sitios fuera de la ciudad y
lejos del río; la revitalización del suelo muy contaminado por debajo de los pozos de teñido; y el derribamiento de las
construcciones ilegales y la creación de un gran espacio público con un paseo fluvial, cafeterías, jardines y mercados.
Además, el plan incluye el desarrollo de plantas de tratamiento de aguas residuales en las afueras de la ciudad para
impedir el vertido directo al río.
David Cayless / Alamy

FIGURA 4.1  Pozos de teñido en La Medina, Fez (continúa)


116 Capítulo 4  •  Liderazgo y el gerente de proyectos

Los problemas técnicos son enormes. Las curtiembres, aunque importantes para la vida económica de la ciu-
dad, son una fuente de enfermedad para los recién nacidos y de patologías a largo plazo, tanto para los curtidores
como para los residentes de la zona. No es suficiente con la simple reubicación en lugares alternativos, los sistemas
solares utilizados durante siglos deben ponerse en consonancia con tecnologías más modernas que ofrezcan bene-
ficios para la salud, así como incentivos económicos.
El proyecto no ha estado exento de retos y opositores. Chaouni señala que ella y su equipo han tenido
que trabajar con numerosas partes interesadas, entre ellas la Unesco, que declaró a la ciudad Patrimonio de la
Humanidad en 1981 y desconfía de los grandes esfuerzos de cambio. “Algunos colegas dijeron que era simple-
mente ingenua cuando empecé este proyecto “, reconoce Chaouni. No obstante, con su visión de lo que Fez y su
río podrían llegar a ser, ha trabajado constantemente con arquitectos, urbanistas, políticos y grupos empresariales
locales para garantizar su apoyo al proyecto. El proyecto no va a finalizar rápidamente, de hecho, se prevé que se
tome cerca de veinte 20 años para revitalizar y remodelar completamente La Medina. No obstante, constituye un
objetivo valioso en las manos de alguien con la visión y el compromiso de mejorar la situación de la población local.
Chaouni dice: “[L]a fuerza impulsora detrás de este proyecto es la creencia de que el alma de Fez es su gente y su
vivacidad, que a través de los siglos ha estado en evolución permanente y adaptación a los contextos. Por tanto,
creo que en un proceso de conservación adaptativo, por un lado, se adapte y, por el otro, beneficie a la población
sin congelarla en el tiempo, sino más bien proyectándola manteniendo intacta el alma de la ciudad.”1

INTRODUCCIÓN
El liderazgo se reconoce frecuentemente por sus logros. Cuando Alan Mulally dejó Boeing en el otoño de
2006 para hacerse cargo de la Ford Motor Company, muchos de sus colegas alicaídos y desmoralizados pen-
saron que estaba loco. Después de una carrera de 35 años en Boeing, Mulally supervisó con éxito el desarrollo
de los aviones 777 y fue considerado un obvio candidato para desempeñarse en una alta posición ejecutiva.
En cambio, aceptó el desafío más grande de su carrera: tratar de darle la vuelta a uno de los íconos de la
empresa automotriz de Estados Unidos, actualmente en medio de una recesión de dos años y un desangre de
efectivo sin perspectivas de alivio a la vista.
En Ford, Mulally desde el principio hizo una serie de movimientos inteligentes, incluso recuperando el
modelo Taurus, la negociación de pedir prestado la enorme suma de 23,600 millones de dólares al hipotecar
los activos de Ford, con el fin de financiar una reforma importante y separando divisiones de bajo rendimiento,
incluidas Jaguar, Aston Martin, Land Rover y Volvo. Sus esfuerzos para revitalizar la empresa dieron sus frutos.
Durante la crisis económica de 2008, Ford fue la única empresa automotriz de Estados Unidos en rechazar el
dinero de rescate del Gobierno y evitar la quiebra. Muchos analistas de la industria predicen que Ford, bajo el
liderazgo de Mulally, está posicionándose para convertirse en el fabricante estadounidense líder de automóviles .
La situación que Jack Welch enfrentó cuando asumió el cargo de consejero delegado de General Electric
(GE) era muy diferente: heredó una empresa considerada una potencia corporativa, tenía las finanzas fuer-
tes y era un nombre familiar en todo el mundo. En un par de años, se despertó la burocracia moribunda en
GE, al vender despiadadamente las divisiones de bajo rendimiento y reducir empleos hasta el punto que sus
subordinados lo apodaron “Jack Neutron”, después de la bomba de neutrones. Los empleados dijeron que,
como un arma, se deshizo de las personas y dejó el edificio en pie. Su actitud enérgica, la voluntad para pre-
dicar con el ejemplo personal y la atención al detalle pagaron dividendos extraordinarios al llevar a GE a su
mayor nivel de rentabilidad corporativo. Cuando se retiró en 2001, Welch había supervisado la transforma-
ción de GE en una empresa con la mayor capitalización bursátil en el mundo, según el precio de las acciones.
El liderazgo es un concepto difícil de estudiar porque todos tenemos nuestra propia definición de aquel,
nuestros propios ejemplos de actuaciones de líderes y nuestras propias creencias acerca de lo que hace que los líde-
res de trabajo. El tema del liderazgo ha generado más de 30,000 artículos y cientos de libros. Aunque hay muchas
definiciones de liderazgo, la que vamos a utilizar en este capítulo es: liderazgo es la capacidad de inspirar confianza
y apoyo entre las personas que se necesitan para alcanzar las metas organizacionales.2 Para el gerente de proyectos,
el liderazgo es el proceso por medio del cual ¡se influye en el equipo del proyecto para hacer el trabajo!
El verdadero liderazgo del gerente de proyectos ha demostrado ser una y otra vez una de las carac-
terísticas más importantes de la gerencia exitosa de proyectos. El efecto de un buen liderazgo se siente en
el equipo e influye en otros gerentes funcionales y los interesados del proyecto.3 De hecho, la gerencia de
proyectos se ha visto como uno de los emprendimientos “basados en el líder” dentro de una organización.4
4.1  Líderes versus gerentes 117

4.1  LÍDERES VERSUS GERENTES


La mayoría de los líderes se apresuran a rechazar la idea de que eran, por ellos mismos, responsables de los
logros alcanzados o de los cambios importantes realizados dentro de sus organizaciones. Para ellos, el lide-
razgo implica una toma de conciencia de una sociedad, de colaboración activa entre el líder y el equipo. En
la gerencia de proyectos, los líderes de equipos exitosos son a menudo quienes están en mejores condiciones
para crear una actitud de colaboración entre ellos y sus equipos. Así, Peter Block5 afirma que la idea de lide-
razgo como alianza es fundamental para la gerencia de proyectos, ya que pone de relieve que todos los líderes
dependen en última instancia de su equipo para lograr los objetivos del proyecto. Hay cuatro cosas que son
necesarias para promover la idea de colaboración entre el gerente del proyecto y su equipo:
1. Intercambio de propósitos: las asociaciones exigen que cada trabajador sea responsable de definir la
visión y los objetivos del proyecto. Un diálogo constante entre el gerente del proyecto y los miembros
del equipo puede crear una visión consistente y ampliamente compartida.
2. El derecho a decir no: es muy importante que todos los miembros del equipo del proyecto sientan que
tienen la capacidad de estar en desacuerdo y presentar posiciones contrarias. Apoyar el derecho de las
personas a expresar sus desacuerdos es la piedra angular de una sociedad. Perder argumentos es acep-
table, perder el derecho a estar en desacuerdo no lo es.
3. Responsabilidad conjunta: en una sociedad, cada miembro del equipo del proyecto es responsable de
los resultados del proyecto y de la situación actual, ya sea positiva o problemática. El proyecto se com-
parte entre varios participantes y los resultados del mismo también lo son.
4. Absoluta honestidad: las asociaciones demandan autenticidad. Un ambiente auténtico promueve la
rectitud y la honestidad entre todos sus participantes. Al respetar el papel de cada miembro del equipo
del proyecto, se pacta implícitamente que toda la información, buena y mala, se convierte en infor-
mación de la comunidad. Al igual que la honestidad es la piedra angular de los matrimonios exitosos,
aquella es fundamental para las relaciones del equipo de proyecto.
El liderazgo se distingue de otros papeles de la gerencia por muchos aspectos. Por un lado, un gerente es
una persona que ha recibido un título dentro de una organización que le permite planear, organizar, dirigir y
controlar el comportamiento de otras personas dentro de su departamento o área de supervisión. Aunque el
liderazgo puede ser parte del trabajo del gerente, las otras funciones de gerencia son más administrativas. Por
otro lado, el liderazgo trata menos administración y más de relaciones interpersonales. El liderazgo implica ins-
piración, motivación, influencia y cambio en las conductas de los demás, en la búsqueda de un objetivo común.
Los líderes aceptan el cambio, los gerentes apoyan el status quo. Los líderes buscan la efectividad, los gerentes, la
eficiencia. La figura 4.2 ilustra algunas de las diferencias entre el comportamiento típico de gerencia y los tipos
de procesos a los que se dedican los líderes. Aunque los líderes deben reconocer la importancia de las funciones

hacen lo correcto dirigen con respeto

desarrollan nuevos procesos centrados en las personas

innovan LÍDERES inspiran confianza


son originales centrados en el potencial
se ganan su posición tienen objetivos a largo plazo

hacen las cosas bien demandan respeto


mantienen el status quo centrados en los sistemas

administran GERENTES centrados en el control

imitan centrados en el resultado final


expresan su posición visión a corto plazo

FIGURA 4.2  Diferencias entre gerentes y líderes


118 Capítulo 4  •  Liderazgo y el gerente de proyectos

de gerencia, a menudo es difícil para los gerentes reconocer la naturaleza interpersonal no estándar del lide-
razgo. Sin embargo, esto no quiere decir que el liderazgo no sea más que una característica innata que algunos
de nosotros tenemos y otros no. La mayoría de las investigaciones y la experiencia común parecen indicar que
los comportamientos de liderazgo pueden enseñarse. Esa es la buena noticia: el liderazgo puede aprenderse. Y
una serie de propiedades y modelos de liderazgo son muy relevantes para los gerentes de proyectos.
Aunque vamos a utilizar el término de gerente de proyectos a lo largo de todo el capítulo, lo hacemos
solo porque se ha convertido en una denominación común para el gerente o líder de un equipo de proyecto.
Una mejor descripción sería “líder del proyectos.” Los gerentes exitosos de proyectos son líderes exitosos de
proyectos.
En este capítulo se analizarán el concepto general del liderazgo organizacional y las condiciones espe-
ciales en las que se espera que opere el gerente de proyectos. ¿Qué pasa con los proyectos que se tornan un
reto único para la gestión? ¿Por qué el liderazgo toma un papel integral en la gestión exitosa de proyectos?
Cuanto más seamos capaces de entender la dinámica de este concepto, más capaces seremos de gerenciar o
implementar eficazmente nuestros proyectos y de entrenar una futura generación de gerentes en las tareas y
competencias necesarias para que esta pueda desempeñar su trabajo.

4.2  CÓMO LIDERA UN GERENTE DE PROYECTOS


La amplia variedad de funciones que se espera que un gerente de proyectos desempeñe abarca todo, desde
la supervisión directa hasta la influencia indirecta, desde la gerencia de detalles técnicos “duros” hasta el
control de problemas “blandos” de las personas, desde el desarrollo de planes y presupuestos detallados hasta
solucionar querellas entre los miembros del equipo y paliar las preocupaciones de los interesados. En resu-
men, el trabajo del gerente de proyectos engloba muchos aspectos: tiene el papel de un mini-CEO, alguien de
quien se espera que gestione de manera integral, centrado en el proceso completo de la gerencia de proyectos
de principio a fin. En esta sección, examinaremos una variedad de deberes y funciones que los gerentes de
proyectos deben asumir en su trabajo para gerenciar con éxito sus proyectos.

Adquisición de recursos del proyecto


Los recursos del proyecto se refieren a todo el personal y recursos materiales necesarios para cumplir con
éxito los objetivos del proyecto. Muchos proyectos no tienen fondos suficientes en la fase de concepción, y
esta falta de recursos puede ocurrir por varias razones, entre estas:
1. Las metas del proyecto son deliberadamente vagas.  A veces un proyecto se inicia con metas genera-
les algo “fluidas”. Tal vez el proyecto sea un esfuerzo de investigación pura en laboratorio o un proyecto
de tecnología de la información diseñado para explorar nuevas posibilidades en el diseño de chips o
computadores veloces. En circunstancias como estas, las empresas patrocinan proyectos con un man-
dato deliberadamente “difuso”, con el fin de permitir la máxima flexibilidad al equipo del proyecto.
2. El proyecto carece de patrocinador en la alta gerencia.  Como aprenderemos, tener un campeón
del proyecto en la alta gerencia de la organización puede ser muy útil para el desarrollo de proyectos,
sobre todo en la obtención de apoyo con recursos suficientes para el proyecto. Pero, cuando no surge
un patrocinador poderoso para el proyecto, este se puede enfrentar con una insuficiente financiación
en comparación con otros proyectos que compiten por los recursos escasos de la empresa.
3. Los requisitos del proyecto fueron deliberadamente subestimados.  No es raro que las necesidades
de recursos del proyecto se subestimen deliberadamente desde el principio, con el propósito de que la
organización los acepte.
4. Muchos proyectos pueden estar en fase de desarrollo y simplemente no hay suficiente dinero para
todos.  Una razón común por la cual faltan recursos de apoyo en un proyecto es que la empresa está
desarrollando constantemente tantos proyectos que no puede financiarlos todos adecuadamente. A
cambio, la compañía adopta la actitud “tómalo o déjalo”, lo cual les plantea a los gerentes de proyectos
la opción de aceptar los fondos insuficientes o no recibir nada.
5. Una actitud de desconfianza entre la alta gerencia y gerentes de proyectos.  A veces, los proyectos
reciben escasa financiación debido a que la alta gerencia está convencida de que los gerentes de pro-
yectos inflan deliberadamente sus estimativos para obtener una financiación excesiva. Esta actitud la
discutiremos en el capítulo 11, “Programación de proyectos con cadena crítica”.
Independientemente de las razones de la falta de recursos de los proyectos, no hay duda de que muchos pro-
yectos se enfrentan con presupuestos muy ajustados y con la insuficiencia de recursos humanos.
4.2  Cómo lidera un gerente de proyectos 119

Los gerentes de proyectos, sin embargo, tienen algunas opciones en su intento de complementar los
recursos de apoyo de su proyecto. Si el problema de los recursos es un asunto personal, pueden buscar vías
alternativas para resolver la dificultad. Por ejemplo, suponga que usted es el gerente del proyecto para la actuali-
zación de un paquete de software que su empresa utiliza para controlar el flujo de materiales y almacenamiento
en una industria manufacturera. Si los programadores capacitados simplemente no están disponibles para tra-
bajar en su proyecto de actualización, usted puede contratar empleados con contratos temporales. Las personas
con habilidades especializadas, como la programación, a menudo pueden contratarse a corto plazo para llenar
los vacíos en la disponibilidad de personal propio, para realizar las mismas tareas. El punto clave para recordar
es que reconocer y responder a las necesidades de recursos es una función crítica de la gerencia del proyecto.
Otro aspecto táctico común para los gerentes de proyectos, de cara al déficit de recursos, es confiar en
la negociación o tacto político para influir en la alta gerencia para proporcionar apoyo adicional. Dado que
los recursos a menudo tienen que negociarse con la alta gerencia, la capacidad de negociar e influenciar, en
la que el gerente del proyecto no tiene autoridad directa, es una habilidad clave. Una vez más, el liderazgo se
demuestra mejor en las habilidades utilizadas por el gerente de proyectos para mantener su viabilidad, ya sea
tratando con la alta gerencia, los clientes, el equipo del proyecto o con otros interesados.

Motivación y creación de equipos


El proceso de moldear un grupo diverso de expertos funcionales en un equipo cohesionado y de colaboración
no es un desafío que haya que tomar a la ligera. Constituir y motivar un equipo presentan obstáculos complejos
y hacerles frente cómodamente a los procesos humanos no forma parte de los antecedentes de cada gerente. Por
ejemplo, es común dentro de la ingeniería y otros trabajos técnicos que empleados exitosos sean ascendidos a
gerentes de proyectos. Ellos suelen convertirse rápidamente en expertos para enfrentar los retos técnicos de la
gerencia de proyectos, pero tienen dificultades para comprender y dominar los aspectos humanos. Su forma-
ción, capacitación, educación y experiencia los han preparado bien para resolver problemas técnicos, pero han
descuidado los elementos de comportamiento igualmente cruciales en la gerencia exitosa de proyectos.
Al considerar cómo motivar a las personas en nuestros equipos de proyectos, hay que reconocer que la moti-
vación en última instancia proviene de dentro de cada uno de nosotros, no puede estimularse únicamente por un
factor externo. Cada uno de nosotros decide, con base en las características de nuestro trabajo, el ambiente de trabajo,
las oportunidades de ascenso, los compañeros de trabajo y otros factores, si estaremos motivados a hacer el trabajo
que se nos han asignado. ¿Eso implica que la motivación está fuera de la influencia de los gerentes de proyectos? Sí y
no. Sí, porque la motivación es una decisión individual, y no podemos hacer que alguien llegue a motivarse. Por otro
lado, como dice un oficial de carrera del ejército: “En el ejército no podemos obligar a la gente a hacer cualquier cosa,
¡pero seguro que podemos hacer que quieran haberla hecho!” La motivación fundamental es algo que los miembros
del equipo quieren, ya sea que provenga de un trabajo desafiante asignado, la oportunidad para el reconocimiento y
la promoción o simplemente el deseo de mantenerse sin problemas. Los gerentes de proyectos exitosos deben aceptar
que un elemento vital en su descripción de trabajo es la capacidad de reconocer el talento, reclutarlo para el equipo,
moldear un equipo de trabajadores interactivos y colaboradores y aplicar técnicas de motivación, según se requiera.

Tener visión y luchar contra los incendios


Los gerentes exitosos de proyectos deben operar en los límites. La frontera que divide los problemas técnicos
y de comportamiento es un ejemplo, y los gerentes de proyectos necesitan sentirse cómodos en ambas tareas.
Otro límite es la diferencia entre ser un visionario estratégico y un bombero del día tras día. Los gerentes de
proyectos trabajan con los planes conceptuales, desarrollan el alcance del proyecto de acuerdo con las direc-
tivas de la organización y entienden cómo se espera que su proyecto encaje en el portafolio de proyectos de
la compañía. Además, se espera que mantengan los ojos fijos en el premio mayor: el proyecto finalizado. En
pocas palabras, los gerentes de proyectos deben ser capaces de pensar de manera estratégica y considerar la
“idea general” para sus proyectos. Al mismo tiempo, sin embargo, las crisis y otros desafíos cotidianos de los
proyectos, por lo general, requieren gerentes de proyectos para tomar decisiones tácticas inmediatas orien-
tadas a resolver los problemas actuales. Los líderes están capacitados para, sin perder de vista el panorama
general, enfrentar los problemas inmediatos más pequeños que ocurren de forma regular y diaria.
Un ejecutivo de una organización de proyectos distinguió muy bien esta situación: “Buscamos gente
que pueda ver el bosque a través de los árboles, pero, al mismo tiempo, estar muy familiarizada con las
especies de cada variedad de árbol que crece. Si uno de esos árboles se enferma, esta gente tiene que conocer
la mejor fórmula para arreglar el problema rápidamente”. Su punto era que un visionario que adopta una
120 Capítulo 4  •  Liderazgo y el gerente de proyectos

visión exclusivamente estratégica del proyecto descubrirá que no puede lidiar con el día tras día y los “fue-
gos” que sigan encendiéndose. Al mismo tiempo, alguien que esté exclusivamente centrado en enfrentar los
desafíos diarios puede perder la perspectiva final y olvidar el panorama general o las metas que definen el
proyecto. El equilibrio entre la visión estratégica y la lucha contra el fuego representa una frontera clave en el
que los gerentes exitosos de proyectos deben moverse cómodamente.

Comunicación
El ex presidente Ronald Reagan fue llamado “El gran comunicador”, porque mostró una capacidad apa-
rentemente natural y fluida para proyectar sus ideas con claridad, identificar a su audiencia y darles forma
a sus mensajes y para no vacilar ni contradecir sus asuntos básicos. Los gerentes de proyectos requieren la
misma facilidad de comunicación. En el capítulo 2 se analizó el papel de la gerencia de los interesados en los
proyectos exitosos y se anotó que estos pueden tener una influencia determinante en la probabilidad de que
un proyecto tenga éxito o no y, en consecuencia, es clave mantener un estrecho contacto con todos los inte-
resados durante el desarrollo del proyecto. Hay un dicho común en la gerencia de proyectos en relación con
la importancia de la comunicación con la alta gerencia de la empresa: “Si ellos no saben nada de lo que usted
está haciendo, asumen que usted está haciendo nada”. El mensaje es claro: hay que tomar medidas serias
para identificar los interesados, establecer y mantener la comunicación con ellos, no esporádicamente, sino
continuamente, durante el desarrollo del proyecto.
La comunicación también sirve para otros fines valiosos. Los gerentes de proyectos se han descrito como
“minianuncios”, la evidencia más visible de la situación de su proyecto. Las formas en que los gerentes de pro-
yectos se comunican, los mensajes que envían (intencionalmente o no) y la manera en que discuten sus proyec-
tos envían señales potentes a otros interesados del proyecto. Ya sea mediante el desarrollo de buenas reuniones
y de habilidades de presentación, una facilidad para escribir y hablar, o través de redes informales, los gerentes
de proyectos deben reconocer la importancia de la comunicación y llegar a ser unos adeptos de esta.
Uno de los medios más críticos a través de los cuales los gerentes de proyectos pueden comunicarse es
su capacidad para dirigir reuniones productivas. Las habilidades para reuniones son importantes porque los
gerentes de proyectos pasan una gran cantidad de tiempo en estas: reuniones con los miembros del equipo,
con la alta gerencia, con clientes y otros interesados claves para el proyecto. Las reuniones sirven para varios
propósitos al equipo del proyecto, incluidos los siguientes:6
1. Definen el proyecto y los principales jugadores del equipo.
2. Ofrecen la oportunidad de revisar, actualizar y agregar a la base de conocimiento de todos los partici-
pantes, los hechos, percepciones, experiencias, juicios y otros datos pertinentes al proyecto.
3. Ayudan a los miembros del equipo en la comprensión de cómo sus esfuerzos individuales encajan en el
conjunto global del proyecto, así como la forma en que cada uno puede contribuir al éxito del proyecto.
4. Ayudan a todos los interesados a aumentar su compromiso con el proyecto a través de la participación
en el proceso de gerencia.
5. Proporcionan una oportunidad colectiva para discutir el proyecto y decidir sobre las asignaciones de
trabajos individuales.
6. Proveen visibilidad para el papel del gerente de proyectos en la gerencia del proyecto.
Como resultado de la amplia variedad del uso de las reuniones, la capacidad de los gerentes de proyectos para
convertirse en expertos en su funcionamiento eficiente y productivo es clave. Las reuniones son un método
determinante a la hora de comunicar el estado del proyecto, colectivizar las contribuciones de los miembros del
equipo, desarrollar un sentido de unidad de cuerpo y espíritu y mantener todos los interesados del proyecto al
día sobre el estado de este.7
Dos formas de comportamientos de liderazgo son fundamentales para el funcionamiento eficaz de las reu-
niones del proyecto. La primera está orientada a las tareas, es decir, hacer hincapié en los comportamientos que
contribuyen a completar las tareas del proyecto, la planeación y la programación de actividades y recursos, y pro-
porcionar el apoyo y la asistencia técnica necesarios. El comportamiento orientado a las tareas pretende que se
haga el trabajo. Al mismo tiempo, y es la segunda, los líderes efectivos de proyectos se preocupan por mantener el
comportamiento del grupo. Mantener el grupo sugiere que un gerente de proyectos no puede actuar en detrimento
de los intereses del equipo. Los comportamientos para mantener el grupo consisten en actividades de apoyo, como
demostrar confianza y honestidad, actuar amable y solidariamente, colaborar con los subordinados para entender
sus problemas y reconocer sus logros. Estos comportamientos aumentan la cohesión, la confianza y el compro-
miso y satisfacen las necesidades de reconocimiento y aceptación de todos los miembros del equipo.
4.2  Cómo lidera un gerente de proyectos 121

CUADRO 4.1  Comportamientos orientados a las tareas y mantenimiento del grupo en


reuniones de proyectos9

Orientados a las tareas Resultado específico


1. Estructuración de procesos Guía y ordena la discusión
2. Fomento de la comunicación Aumenta el intercambio de información
3. Aclaración de la comunicación Aumenta la comprensión
4. Resumen Descubre la comprensión y evalúa el progreso
5. Prueba de consenso Revisa los acuerdos

Mantenimiento del comportamiento del grupo Resultado específico


1. Moderación Incrementa y regula la participación
2. Armonización Reduce la tensión y la hostilidad
3. Apoyo Impide la retirada y fomenta el intercambio
4. Establecimiento de normas Regula el comportamiento
5. Análisis de procesos Descubre y resuelve problemas en el proceso
Fuente: Gary A. Yukl. Leadership in Organizations, 5 th edition, p. 329. Copyright © 2002. Adaptado con permiso de
Pearson Education, Inc., Upper Saddle River, Nueva Jersey.

El cuadro 4.1 recoge algunas de las tareas claves de mantenimiento y los comportamientos de grupo que
se producen en reuniones de proyectos productivos. Entre los comportamientos importantes orientados a las
tareas están: estructurar el flujo de la discusión para asegurar que la agenda de la reunión se siga adecuada-
mente, estimular la conversación entre todos los participantes de la reunión, aclarar y resumir las decisiones y
percepciones, así como hacer pruebas de consenso para identificar puntos de acuerdo y desacuerdo. El gerente
de proyectos es clave en el logro de los comportamientos efectivos de tareas, sobre todo a través de un claro
sentido del tiempo y de la oportunidad.8 Por ejemplo, presionar un consenso muy rápido o limitar la conversa-
ción y la libre circulación de las ideas será perjudicial para el desarrollo del equipo del proyecto y los resultados
de las reuniones. Del mismo modo, estimular la conversación continua, incluso después de haber llegado a un
acuerdo, solo sirve para prolongar la reunión más allá del punto productivo.
Entre los comportamientos de mantenimiento del grupo que los líderes de proyectos efectivos deben
tener en cuenta para el manejo de las reuniones están: moderación para garantizar la igualdad de participa-
ción; la armonización para reducir la tensión y promover el desarrollo de los equipos; el apoyo para fomentar
el intercambio de puntos de vista; regulación del comportamiento a través del establecimiento de normas; y la
identificación y resolución de cualquier “proceso” problema que cause incomodidad, apresuramiento o actitud
defensiva de los participantes en la reunión. Los comportamientos de mantenimiento de grupo son tan claves
como los relacionados con las tareas y deben implementarse como una parte de una estrategia de éxito de la
reunión. Tomados en conjunto, los comportamientos orientados a las tareas y al mantenimiento del grupo le
permiten al gerente de proyectos obtener el máximo beneficio de las reuniones, las cuales son muy importantes
para la comunicación del proyecto y se convierten en demanda de tiempo constante del gerente de proyectos.
El cuadro 4.2 muestra los papeles que desempeñan los líderes en el éxito del proyecto y clasifica en
nueve características a los gerentes de proyectos efectivos, en orden de importancia. Los datos se basan en un

CUADRO 4.2  Características de los gerentes de proyectos que lideran

Puesto Características de un gerente de proyectos efectivo


1 Lidera con el ejemplo
2 Visionario
3 Técnicamente competente
4 Decisivo
5 Buen comunicador
6 Buen motivador
7 Enfrenta a la alta gerencia cuando se requiere
8 Apoya a los miembros del equipo
9 Alienta nuevas ideas
122 Capítulo 4  •  Liderazgo y el gerente de proyectos

RECUADRO 4.1

INVESTIGACIÓN DE GERENCIA DE PROYECTOS EN SÍNTESIS


Liderazgo e inteligencia emocional
En los últimos años ha surgido una nueva perspectiva sobre el liderazgo, producto de investigaciones que han
examinado las características y habilidades relacionadas con el liderazgo efectivo de los proyectos. Mientras
características como la habilidad técnica, la capacidad analítica y la inteligencia se consideran rasgos determi­
nantes en los gerentes de proyectos, un concepto adicional, la idea de la inteligencia emocional, se ha suge­
rido como una medida más significativa de la efectividad del liderazgo. La inteligencia emocional se refiere a
la capacidad de los líderes para entender que el liderazgo efectivo es una parte de la transacción emocional y
relacional entre los subordinados y aquellos. Cinco elementos caracterizan la inteligencia emocional: (1) auto­
conciencia, (2) autorregulación, (3) motivación, (4) empatía y (5) habilidades sociales. Con estas características,
un gerente de proyectos puede desarrollar el tipo de relaciones directas y de apoyo con los miembros del
equipo que son esenciales para crear y dirigir un equipo efectivo.

Autoconciencia.  Conciencia de uno mismo implica tener un profundo conocimiento de sus propias for­
talezas y debilidades, necesidades de ego, impulsos y motivaciones. Ser autoconsciente significa tener una
perspectiva clara de uno mismo; no significa ser excesivamente egoísta o egocéntrico. Cuando soy autoconsci­
ente soy capaz de interactuar mejor con los demás porque entiendo que mis sentimientos y actitudes afectan
mi comportamiento.

Autorregulación.  Una característica clave de los líderes exitosos es su voluntad de mantenerse bajo control.
Una de las formas en que se practica el autocontrol es pensar antes de actuar o de emitir juicios. Los líderes
efectivos son aquellas personas que han desarrollado la autorregulación, es decir, su capacidad de refle­
xionar sobre los acontecimientos, responder a estos después de una cuidadosa reflexión y evitar el error de
caer en un comportamiento impulsivo.

Motivación.  Los líderes efectivos de proyectos son siempre individuos altamente motivados. Ellos se obligan
a alcanzar su mejor potencial, y reconocen que para tener éxito deben trabajar con los miembros del equipo
del proyecto para generar el máximo rendimiento de cada uno de estos. Hay dos características importantes
de los gerentes efectivos respecto a la motivación: primera, siempre están buscando la manera de llevar la
cuenta, es decir, necesitan indicadores concretos o claros que demuestren el progreso. Segunda, los gerentes
efectivos de proyectos se esfuerzan constantemente por superar desafíos cada vez mayores.

Empatía.  Un rasgo importante de los gerentes de proyectos exitosos es su capacidad de reconocer las dife­
rencias de cada uno de sus subordinados, hacer concesiones a esas diferencias y tratar de la manera apropiada
a cada miembro del equipo para obtener su compromiso máximo. Empatía significa disposición a considerar
los sentimientos de otros miembros del equipo al tomar una decisión.

Habilidades sociales.  El último rasgo de la inteligencia emocional, habilidades sociales, se refiere a la capa­
cidad de una persona para manejar las relaciones con los demás. La habilidad social es más que una simple
amistad, es amistad con un propósito. Las habilidades sociales son nuestra capacidad de hacer mover a la
gente hacia una dirección que creemos conveniente. Dentro de las habilidades sociales están la forma en que
se demuestra la persuasión, el entendimiento y la construcción de redes.

La inteligencia emocional es un concepto que refleja un punto importante: muchas de las habilidades
claves de la gerencia de proyectos que definen el liderazgo efectivo no se relacionan con habilidades técnicas,
capacidad de análisis o coeficiente intelectual (intelligence quotient:IQ). Más importantes son las habilidades
de autogestión, reflejadas en la autoconciencia, autorregulación, motivación y habilidades de manejo de rela­
ciones, mostradas a través de nuestras empatía y habilidades sociales. Recuerde: la gerencia de proyectos es,
ante todo, un desafío de gerencia de personas. Una vez que entendemos el papel que desempeñan los com­
portamientos de liderazgo en la gerencia efectiva de los proyectos, podemos identificar mejor las formas en
que podemos utilizarlo para promover nuestros proyectos.11

estudio de gerentes de proyectos exitosos de Norteamérica, según la percepción de los miembros de equipos
de proyectos.10 Se puede observar que lo más importante es la voluntad del gerente de proyectos de predicar
con el ejemplo, destacar las metas del proyecto y comprometerse con la tarea, antes de exigirles un compro-
miso similar a los demás.
4.3  Características de los líderes efectivos de proyectos 123

CUADRO 4.3  Características de los gerentes de proyectos que no son líderes

Fallas personales Porcentaje Factores organizacionales Porcentaje


Da mal ejemplo 26.3% Falta de apoyo de la gerencia 31.5%
Inseguro consigo mismo 23.7 Resistencia al cambio 18.4
Incompetente técnicamente 19.7 Sistema de recompensas inconsistente 13.2
Mal comunicador 11.8 Organización más reactiva que proactiva  9.2
Poco motivador  6.6 Falta de recursos  7.9

Igualmente interesantes son los resultados relacionados con las razones por las cuales un gerente de
proyectos puede verse como inefectivo. Estas razones incluyen fallas personales y factores organizacionales.
El cuadro 4.3 relaciona los defectos personales y los factores organizacionales que hacen inefectivos a los
gerentes de proyectos. Estos factores están ordenados por rangos de acuerdo con el porcentaje de las respues-
tas de los encuestados.

4.3  CARACTERÍSTICAS DE LOS LÍDERES EFECTIVOS DE PROYECTOS


Una gran cantidad de investigaciones sobre liderazgo organizacional se han orientado a descubrir los rasgos
específicos de los líderes, porque ser líder no es lo mismo ser gerente; los gerentes se encuentran en todos
los ámbitos de la vida y ocupan todos los niveles de las jerarquías organizacionales. Un estudio que trató de
descubrir los rasgos que la mayoría de los gerentes creen que los líderes deben tener es particularmente escla-
recedor. Se realizó una gran encuesta a una muestra de 2,615 gerentes en las empresas estadounidenses, en la
que se indagaba por las características que consideraban más importantes en los líderes efectivos.12
Los resultados de esta encuesta intrigan. La mayoría de gerentes considera que la característica más
importante de los líderes superiores es la honestidad básica. Ellos buscan líderes que dijeran lo que querían
decir y cumplieran sus promesas. Además, buscaban competencia, inteligencia, visión, inspiración, equidad,
imaginación y fiabilidad, al enumerar algunas de las características más importantes. Estas características
ofrecen un punto de partida importante para una mejor comprensión de cómo funcionan los líderes y, más
importante aún, cómo los otros miembros del equipo o de la organización del proyecto esperan que operen.
Claramente, los factores más importantes que buscamos en los líderes son confianza, fuerza de carácter, inte-
ligencia y competencia para tener éxito. La expectativa de éxito también es importante, porque la mayoría de
seguidores no acompañan por mucho tiempo a gerentes de proyectos que fracasan.
Se han realizado investigaciones relacionadas específicamente con los rasgos de liderazgo que deben tener
los gerentes de proyectos para tener éxito en este campo tan especializado. En particular, tres estudios arrojan
una luz valiosa sobre la naturaleza de las demandas especiales que enfrentan los gerentes de proyectos y el factor
concomitante de las características de liderazgo que deben desarrollar. Un estudio analizó datos de varias fuen-
tes y sintetizó un conjunto de factores que los líderes de proyectos más efectivos comparten.13 Identificó cinco
características importantes para la gerencia efectiva de proyectos: habilidades de comunicación oral; habilida-
des de influencia; capacidades intelectuales; capacidad para manejar el estrés; y diversas habilidades de gerencia,
incluidas planeación, delegación y toma de decisiones. Estos hallazgos se correlacionan con el hecho de que la
mayoría de los gerentes de proyectos no tienen la capacidad de ejercer el poder derivado de una posición de
autoridad formal, y, por tanto, se ven obligados a desarrollar habilidades efectivas para influir en los demás.
El segundo estudio identificó cinco características estrechamente asociadas con los líderes efectivos de
equipos de proyectos:14
• Credibilidad: ¿el gerente de proyectos es fiable y tomado en serio tanto por el equipo del proyecto
como por la organización?
• Creativo-solucionador de problemas: ¿el gerente de proyectos es experto en identificación y análisis de
problemas?
• Tolerancia a la ambigüedad: ¿el gerente de proyectos se afecta adversamente por situaciones comple-
jas o ambiguas (inciertas)?
• Estilo de gerencia flexible: ¿el gerente de proyectos es capaz de manejar con rapidez las situaciones cambiantes?
• Habilidades de comunicación efectiva: ¿el gerente de proyectos es capaz de servir como centro de
coordinación para la comunicación entre una variedad de interesados?
124 Capítulo 4  •  Liderazgo y el gerente de proyectos

El último estudio relacionado con las habilidades necesarias para gerentes de proyectos efectivos recopiló datos
de 58 empresas sobre sus prácticas de gerencia de proyectos y las habilidades más importantes en los gerentes de
proyecto15 Los investigadores encontraron siete habilidades esenciales en un gerente de proyecto:
1. Dirigir bajo conflicto: los gerentes de proyectos requieren capacidad de delegar, administrar su tiempo
y manejar el conflicto y la crítica.
2. Experiencia: tener conocimiento de gerencia de proyectos y otros procedimientos de la organización y
tener experiencia en aspectos técnicos y como líder son útiles.
3. Toma de decisiones: los gerentes de proyectos requieren buen juicio, capacidad de análisis sistemático
y habilidades para la toma de decisiones.
4. Creatividad productiva: esta habilidad se refiere a la necesidad de que los gerentes de proyectos
demuestren creatividad, desarrollen y pongan en práctica ideas innovadoras y desafíen el viejo orden
establecido.
5. Generar cooperación: los gerentes de proyectos deben estar dispuestos a crear un ambiente positivo en
el equipo, demostrar su voluntad de aprender y participar en el contacto interpersonal positivo.
6. Liderazgo cooperativo: esta habilidad se refiere a la capacidad del gerente del proyecto para motivar a
los demás, cooperar y expresar ideas con claridad.
7. Liderazgo cooperativo: los gerentes de proyectos deben ser capaces de pensar analíticamente y de
involucrar a otros en el proceso de toma de decisiones.

Conclusiones acerca de los líderes de proyectos


Según los puntos de vista de gran alcance, hay que tener en cuenta los elementos en común en estos estudios
y extraer algunas conclusiones generales acerca de la naturaleza de la gerencia del proyecto. Las conclusiones
específicas de relevancia práctica en la selección y formación de líderes de proyectos efectivos sugieren varios
asuntos, entre estos:
• Los gerentes efectivos de proyectos deben ser buenos comunicadores.
• Los líderes del proyecto deben tener la flexibilidad necesaria para responder con un mínimo de estrés a
situaciones de incertidumbre o ambigüedad.
• Los líderes de proyectos fuertes trabajan bien con su equipo de proyecto y dentro de este.
• Los buenos líderes de proyectos son expertos en diversas tácticas de influencia.
Aunque el examen de los rasgos de los líderes exitosos y específicamente de los líderes de proyecto es
valioso, presenta solo una parte del cuadro. Una de las claves para entender el comportamiento del liderazgo
es centrarse en lo que los líderes hacen más que en lo que estos son.

PERFIL DE PROYECTO

Dr. Elattuvalapil Sreedharan, gerencia de proyecto de estrella del rock en India


La capital de India, Delhi, es una ciudad de contrastes. Es hogar de 17 millones de personas, muchas de ellas
viviendo en la pobreza extrema; la ciudad cuenta con algunos de los principales centros de alta tecnología del país
para la industria y la educación superior. El tráfico colapsado y los altos niveles de contaminación, son notorios:
7,500 autobuses de la ciudad recorren lentamente por calles atestadas. Al igual que otros centros urbanos de India,
Delhi requiere desesperadamente una mejor infraestructura y un sistema de trenes suburbanos. Por desgracia,
el historial de India en proyectos de grandes capitales es pobre; no obstante, hay muchos ejemplos de proyectos
ejecutados muy por encima del presupuesto y fuera de cronograma (ver los casos Dulhasti Power en este texto).
Un ejemplo reciente destaca los continuos problemas con la gerencia de proyectos de infraestructura en India.
Delhi puso en marcha un proyecto de varios años para albergar los Juegos de la Commonwealth en el otoño de
2010, un evento deportivo que reúne a atletas de 71 territorios y países asociados con el antiguo Imperio britá-
nico. Lamentablemente, los problemas con el saneamiento, la construcción inadecuada, numerosos retrasos y mala
planeación dejaron al país con una mala imagen muy visible y reforzaron la idea popular de que los proyectos de
infraestructura a gran escala en India son, como mucho, un emprendimiento arriesgado.
La buena noticia es que no todo es tan malo como parece. Recientemente, Delhi completó la primera fase
de un gran proyecto, los 2,300 millones de dólares del metro de Delhi. La línea de tren prevista para esta fase, que
abarca cerca de 40 millas, fue finalizado tres años antes de lo previsto. Tan inesperada fue esta circunstancia, que
4.3  Características de los líderes efectivos de proyectos 125

la revista BusinessWeek etiquetó al líder del proyecto, Elattuvalapil Sreedharan, como “un hacedor de milagros”.
Entonces, ¿cuál ha sido el secreto del éxito de Sreedharan, especialmente en un país donde muchos antes que él
habían fracasado en empresas similares?
En primer lugar, dice, es la importancia de la responsabilidad. “Uno de los mayores impedimentos para la
terminación oportuna de proyectos de infraestructura en India hoy es la falta de atención y responsabilidad”.
Malos ejecutantes no son responsables por no alcanzar sus objetivos, así que ¿dónde está el incentivo para llegar
a tiempo? Según Sreedharan, la organización adoptó un enfoque diferente: “La misión y la cultura de la orga-
nización incluyen objetivos claramente definidos y una visión, la cual era finalizar el proyecto a tiempo y dentro
del presupuesto, sin causarle molestias a la población”. Sreedharan también tiene una obsesión por los plazos.
Todo empleado del proyecto Metro mantiene un tablero digital que muestra el número de días que quedan para
cumplir la próxima meta. Otro elemento crítico de su éxito ha sido la meticulosa planeación previa. Shreeharan
dijo: “Todas las ofertas (licitaciones) de los contratistas se deciden muy rápido, a veces en 18 o 19 días. [E]s esencial
establecer claramente de antemano los criterios para la adjudicación de las licitaciones.”
Por último, Sreedharan se mantiene firme en la transparencia y comunicación permanente con todos los inte-
resados del proyecto. Bajo su supervisión, el proyecto mantiene una comunicación abierta con todos los contratis-
tas, actualizándolos sobre los planes y realizando frecuentemente reuniones y talleres. Una característica única del
proyecto del metro de Delhi es e mantener cerca de un centenar de “programas de interacción con la comunidad”
(PIC), unos foros abiertos en los que a los residentes locales se les da la oportunidad de discutir aspectos de la cons-
trucción que pudieran afectarles. Las reuniones de los PIC se diseñaron para permitir que los grupos de defensa,
organizaciones vecinales y otros interesados compartan ideas y formulen sus quejas y preguntas a medida que el
proyecto avanza. En cuanto a las preguntas en los PIC, Sreedharan, comenta: “La mayoría de estas se resuelven en
el acto; para las restantes se toman las medidas y acciones correctivas”. El equipo de Sreedharan ha utilizado este
enfoque de transparencia y comunicación abierta para disipar las preocupaciones de los interesados e impulsar su
cooperación con el proyecto en lugar de su antagonismo.
Todo el proyecto se diseña para desplegarse en cuatro fases, con una longitud total de 152 millas cuando se
haya finalizado. La fase final debe finalizarse en el 2020. El proyecto del Metro se encuentra actualmente en la
mitad de su fase dos. Sreedharan, con más de 70 años de edad, no está seguro cuánto tiempo más va a supervisar
personalmente el proyecto, pero no tiene dudas acerca de los secretos para el éxito como gerente de proyectos.
“Yo creo que hay tres cualidades básicas para una vida exitosa”, señala, “la puntualidad, la integridad y la moral,
y la competencia profesional. El futuro de India estará en buenas manos si estas cualidades se nutren asiduamente
por los jóvenes de nuestra nación”.16

PRAKASH SINGH/AFP/Getty Images/Newscom

FIGURA 4.3  Dr. E. Sreedharan en uno de los túneles del metro de Delhi
126 Capítulo 4  •  Liderazgo y el gerente de proyectos

Liderazgo y orientación temporal


Los últimos estudios sobre la orientación temporal tienen algunas implicaciones en el comportamiento de
liderazgo en los proyectos. La orientación temporal se refiere al contexto temporal y espacial en el que un
individuo se orienta. En concreto, los investigadores han argumentado desde hace tiempo que cada uno de
nosotros tiene una tendencia natural a centrarse en una de las tres orientaciones temporales: pasado, pre-
sente o futuro. Esta alineación temporal tiene el efecto de influir en nuestro comportamiento y causa que
cada uno de nosotros pueda realizar bien algunas tareas, y otras se dificulten. Por ejemplo, si su orientación
temporal está dirigida al futuro, es más fácil participar en la planeación. Además, puede que le resulte más
difícil hacer tareas como la evaluación del rendimiento, ya que requieren que usted recupere eventos pasa-
dos. La capacidad de los gerentes de proyectos para alinear su orientación temporal con las tareas que realiza
es una habilidad que necesita desarrollarse.
El cuadro 4.4 identifica algunos conceptos y habilidades de la orientación temporal que tienen impli-
caciones significantes para los gerentes de proyectos. La alineación temporal incluye cinco elementos: línea
temporal de orientación, perspectiva del tiempo futuro, lapso, preferencia policrónica/monocrónica y la con-
cepción del tiempo. Las destrezas y habilidades temporales necesarias para llevar a cabo determinadas tareas
incluyen la distorsión de tiempo, la creación de una visión de futuro, la fragmentación de tiempo, la predic-
ción y la recaptura del pasado.
La orientación temporal es un concepto útil para tener en cuenta en el desarrollo de habilidades de
gerencia de proyectos, ya que pone de relieve algunos hechos sobresalientes: (1) cada uno de nosotros pre-
fiere ciertas orientaciones de tiempo, ya sea pasado, presente o futuro; (2) la orientación preferida presenta
algunas ventajas e inconvenientes cuando se trata de la gerencia de proyectos; y (3) tenemos que reconocer
que la gerencia efectiva de proyectos a menudo nos obliga a estar a gusto con otras orientaciones de tiempo
no preferidas. Analicemos cada uno de estos hechos.
1. Cada uno tenemos preferencias de orientación temporal, ya sea hacia el pasado, presente o futuro.
La investigación en psicología ha establecido que las personalidades individuales difieren en
cuanto a la orientación temporal.17 Algunos de nosotros preferimos adoptar una perspectiva a futuro,
y otros mantienen una preferencia de tiempo presente o pasado. Tener una preferencia nos predispone
a realizar bien algunas actividades o se evitan o se hace lo mínimo en otras áreas.
2. Cada orientación temporal tiene asociadas fortalezas y debilidades para la gerencia de proyectos.
La investigación sugiere que la orientación temporal preferida que cada uno de nosotros posee
naturalmente nos inclina a realizar bien algunas actividades de gerencia de proyectos y con mayor difi-
cultad o con renuencia, otras. El cuadro 4.5 ilustra esta idea. Tenga en cuenta que algunas de las acti-
vidades relacionadas con la orientación al tiempo pasado, como la solución de problemas del proyecto

CUADRO 4.4  Alineación temporal y habilidades temporales

Alineación temporal
• Línea temporal de orientación—El contexto temporal o espacio en el tiempo (pasado, presente o futuro)
en el que un individuo se ve con mayor frecuencia.
• Perspectiva de tiempo futuro—La medida en que el futuro impulsa el comportamiento actual de un
individuo.
• Lapso—El tiempo futuro es capaz de capturarse en la mente de uno.
• Preferencia policrónica/monocrónica—El deseo de hacer más de una cosa a la vez, o solo una cosa a la vez.
• Concepción del tiempo—Conjunto de creencias sobre la naturaleza del tiempo y de la vida, la vida cíclica
(se repite) o lineal (la vida procede en una línea recta, siempre hacia adelante).
Habilidades temporales
• Distorsión del tiempo—Cognitivamente lo que está más cercano al presente, el pasado o el futuro.
• Creación de una visión de futuro—Creación de una imagen proyectada del futuro.
• Fragmentación de tiempo—Creación de unidades de tiempo futuro que se utilizarán para la
programación.
• Predicción—Estimativos de lo que ocurrirá en el futuro.
• Recaptura del pasado—Recuerdo y uso de la información del pasado.
4.4  Campeones de proyectos 127

CUADRO 4.5  Funciones del líder del proyecto y su relación con el tiempo

Actividad del líder del proyecto Habilidad temporal requerida


A. Tareas orientadas Resolución de problemas del proyecto Recaptura del pasado
al pasado
Evaluación de miembros del equipo Recaptura del pasado
Recolección de lecciones aprendidas Recaptura del pasado
B. Tareas orientadas Programación Deformación del tiempo
al presente
Gerencia de múltiples problemas del proyecto Policrónica
C. Tareas orientadas Planeación de contingencias Distorsión del tiempo
al futuro
Predicción
Creación de una visión del proyecto Creación de una visión de futuro

o la evaluación a los miembros del equipo, inciden directamente en nuestra capacidad de recuperar el
pasado. Piense en la recolección de lecciones aprendidas del proyecto durante su fase de terminación.
Precisamente en momentos como este, la capacidad de recuperar los eventos pasados, por lo general
asociados con la orientación al tiempo pasado, es tan valiosa. Por el contrario, la orientación al tiempo
futuro requiere habilidades, como la distorsión del tiempo o predicción, cruciales en nuestra capacidad
de gestionar la planeación de contingencias.
3. La gerencia efectiva del proyecto requiere que desarrollemos habilidades en otros modos de orienta-
ción temporal.
Como el cuadro 4.5 muestra, aunque cada uno tiene una orientación temporal preferida que hace que
ciertas tareas sean más fáciles o más difíciles de realizar, como líderes necesitamos desarrollar toda la varie-
dad de nuestras habilidades, lo cual sugiere que, al menos, debemos desarrollar una pericia básica en todas
las habilidades temporales. El primer paso de este proceso se encuentra a menudo en el desarrollo de una
idea más clara de nuestras fortalezas y debilidades respecto a la orientación temporal. Entonces podemos
empezar a perfeccionar nuestras habilidades en la orientación que sea particularmente difícil para nosotros.
Los gerentes exitosos de proyectos reconocen la importancia de operar según una perspectiva que incluye
orientaciones hacia el pasado, el presente y el futuro.

4.4  CAMPEONES DE PROYECTOS


El doctor Thomas Simpson (no es su nombre real) regresó entusiasta de una reciente conferencia médica,
después conocer una técnica innovadora que estaba seguro de que era justo la apropiada para su hospital.
Había sido testigo de la utilización de una tecnología de sistemas de información que les permite a los médi-
cos conectarse inalámbricamente con los registros de pacientes, recuperar documentos y órdenes de consulta
y hacer prescripciones en línea. Con este sistema, el médico podría ingresar los síntomas y los protocolos de
tratamiento directamente en un computador portátil en la habitación del paciente. Con el nuevo sistema, se
mejora significativamente el método de archivar la historia clínica del paciente al hospital, al tiempo que le
proporciona al médico una mayor flexibilidad en las opciones de tratamiento inmediato.
Como jefe del equipo médico, el doctor Simpson tenía alguna influencia en el Grace Hospital, pero
no podía simplemente pedirle al hospital que adoptara la tecnología. En cambio, durante un periodo de seis
meses trabajó incansablemente para promover el sistema, realizando seminarios de información con los
diseñadores de software y sesiones de preguntas y respuestas con la administración del hospital y otros inte-
resados. Con el tiempo, su perseverancia dio sus frutos. El hospital adoptó la tecnología y la ha estado usando
durante los últimos dos años. A pesar de algunos problemas iniciales derivados de la necesidad de transferir
los registros en papel al sistema, Grace Hospital ahora se jacta de que tiene el “récord de papel” gratis, y todo
esto debido a los esfuerzos del doctor Simpson.
En este ejemplo, el doctor Simpson muestra todas las cualidades de un campeón de proyectos. Los cam-
peones, a veces referidos como patrocinadores del proyecto, son bien conocidos en la bibliografía de la teoría
organizacional y dentro de las propias organizaciones. Un campeón es un individuo que “se identifica con
un nuevo desarrollo (o no lo hace), utilizando todas las armas a su disposición, en contra de la resistencia a
128 Capítulo 4  •  Liderazgo y el gerente de proyectos

la financiación por la organización; trabaja como un emprendedor dentro de la organización y puesto que no
tiene autoridad oficial para tomar riesgos innecesarios ... pone su trabajo en la organización (y muchas veces su
reputación) . . . Él (tiene) una gran energía y capacidad para invitar y soportar la desaprobación.”18
Los campeones poseen algunas características notables. Primera, se supone (de hecho, casi se espera)
que los campeones funcionarán sin la aprobación formal de sus organizaciones. A menudo se ponen direc-
tamente en contradicción con el orden establecido o con la forma popular de pensar. Los procedimientos
operativos estándar son un sacrilegio para los campeones y, por lo general, no le temen a la desaprobación
oficial. Segunda, los campeones tienen un verdadero talento empresarial para reconocer el valor de las ideas
o productos innovadores, que ven las cosas que otros miembros tradicionales de la organización no ven.
Tercera, son tomadores de riesgo en todo el sentido de la palabra. Su inquebrantable búsqueda de la verdad
en cualquier forma innovadora, con frecuencia los pone en conflicto con los burócratas arraigados y con los
que no comparten su entusiasmo por un nuevo producto o idea.
Capturar el entusiasmo y el fervor que los campeones tienen para sus ideas es difícil. Tom Peters, autor
de éxito, describe a los campeones como “fanáticos” en la búsqueda decidida de sus ideas favoritas. Él dice:
“Las personas que son tenaces, campeones comprometidos, suelen ser un dolor insoportable en la nuca . . .
Ellos deben ser promovidos y nutridos, aunque hieran.”19 Esta declaración refleja la esencia de la persona-
lidad y el impacto del campeón, quien es, al mismo tiempo, un crítico organizacional y de vital importancia
para el éxito del proyecto y de la organización.

Campeones: ¿quiénes son?


Los campeones no ocupan constantemente las mismas posiciones en las organizaciones. A pesar de que
los altos gerentes con frecuencia sirven como campeones, muchos miembros de la organización pueden
de­sempeñar el papel de campeón de la implementación de diferentes sistemas o en momentos diferentes del
mismo proyecto de implementación del sistema. Entre los tipos más comunes de campeones están el gestor
creativo, emprendedor, padrino o patrocinador y gerente de proyectos.20

GESTOR CREATIVO El gestor creativo suele ser un ingeniero, científico, o similar, que es la fuente y la
fuerza impulsora detrás de la idea. El hecho de que la persona que estaba detrás del desarrollo original de la
idea o la tecnología pueda funcionar como el promotor del proyecto no sorprende. Nadie en la organización
cuenta con más experiencia o sentido de la visión cuando al nuevo sistema de información se refiere. Pocos
otros poseen la capacidad técnica y creativa para desarrollar el esfuerzo de implementación y obtener frutos.
En consecuencia, muchas organizaciones permiten y fomentan activamente la participación continua del
científico o ingeniero que desarrolló originalmente la idea en que se basa el proyecto.

EMPRENDEDOR Un emprendedor es aquella persona que adopta la idea o la tecnología y trabaja activa-
mente para vender el sistema en toda la organización, empujándolo eventualmente hacia el éxito. En muchas
organizaciones no es posible, por muchas razones, que el gestor creativo o defensor del proyecto original
pueda desempeñar el papel de campeón. A menudo, los científicos, técnicos e ingenieros están limitados por
la necesidad de realizar las tareas específicamente demarcadas en sus posiciones y, por tanto, son excluidos
del equipo de ejecución del proyecto. En tales situaciones, el individuo que da un paso adelante como el
campeón de la implementación se conoce como emprendedor organizacional. El emprendedor es un miem-
bro de la organización que reconoce el valor de la idea o de la tecnología original y la convierte en una meta
personal para ganar la aceptación en las unidades organizacionales relevantes que la utilizaría. Campeones
empresariales suelen ser gerentes de mediano o alto nivel que pueden o no tener experiencia técnica. Además
de realizar sus funciones dentro de la organización, están en la búsqueda constante de ideas innovadoras y
útiles por desarrollar.

PATROCINADOR O PADRINO   El campeón del proyecto como patrocinador es un gerente de alto nivel
que hace todo lo posible para promover el proyecto, incluida la obtención de los recursos necesarios, entrena
al equipo del proyecto en caso de problemas, calma las aguas políticas y protege el proyecto cuando sea nece-
sario. Un patrocinador decide apoyar activamente la adquisición y aplicación de nuevas tecnologías y hace
todo lo posible para facilitar este proceso. Una de las funciones más importantes de los patrocinadores es dar
a conocer a toda la organización que el proyecto está bajo su guía o protección personal. Además de proveer
esta “protección”, el patrocinador se dedica a una variedad de actividades de carácter más sustancial para
ayudar que el esfuerzo de implementación tenga éxito. Los patrocinadores también utilizan su influencia
4.4  Campeones de proyectos 129

para dirigir al equipo en caso de que se presenten problemas, con el fin de disminuir la probabilidad de que
los problemas políticos descarrilen el proyecto.

GERENTE DE PROYECTOS  Otro miembro de la organización que puede desempeñar el papel de campeón
es el gerente de proyectos. En un momento u otro, casi todos los gerentes de proyectos han desempeñado el
papel de campeón. Cuando se tiene en cuenta la definición de un campeón del proyecto y la amplia variedad
de funciones que ha desempeñado en ese papel, queda claro por qué el gerente de proyectos toma com-
portamientos de campeón. Ciertamente, los gerentes de proyectos están fuertemente identificados con sus
proyectos, y hasta cierto punto sus carreras están directamente vinculadas a la terminación exitosa de sus
proyectos. Los gerentes de proyectos, sin embargo, pueden tener una efectividad limitada como campeones,
si no poseen un estatus alto, en la organización, que les posibilite servir como defensores del proyecto frente
a la alta gerencia. Por ejemplo, un gerente de proyectos no puede tener la autoridad para obtener recursos
adicionales para el proyecto o para conseguir el apoyo de toda la organización.

¿Qué hacen los campeones?


¿Qué es exactamente lo que hacen los campeones para ayudar al proceso de implementación? El cuadro 4.6
muestra dos grupos de actividades de campeones que fueron identificadas por un estudio a través de una
encuesta realizada a una muestra de gerentes de proyectos.
El primer grupo de actividades se llaman comúnmente funciones “tradicionales” de gerentes. El campeón
ayuda activamente en el proceso de desarrollo del proyecto mediante la interpretación de detalles técnicos, con
un fuerte liderazgo, ayuda en la coordinación y control del proyecto, así como en el suministro de ayuda admi-
nistrativa para el equipo. Es importante que el campeón esté familiarizado con los aspectos técnicos del proyecto.
Otra actividad tradicional importante del campeón de proyectos es la obtención de los recursos necesarios para
que los miembros del equipo puedan llevar a cabo sus tareas. Los campeones están a menudo en una posición
privilegiada para poner a disposición un suministro continuo de apoyo logístico para el proyecto.
El segundo grupo de actividades en las que se involucran los campeones se conoce como el lado “no
tradicional” de la gerencia, lo cual implica que estas actividades no son parte de las funciones habituales iden-
tificadas en la bibliografía tradicional sobre gerencia. Sin embargo, esto no significa que estas actividades sean
de alguna manera innecesarias o excéntricas. De hecho, varios campeones han argumentado que estas tareas
son tan importantes para el éxito del proyecto como las identificadas con frecuencia, por ejemplo, los requisi-
tos para una gerencia exitosa. Desempeñar funciones como animador, visionario, político, tomador de riesgo
y embajador es importante para la mayoría de los gerentes de proyectos; sin embargo, estos papeles tienden a
menospreciarse en la bibliografía, especificaciones de trabajo y programas de formación. Como un campeón

CUADRO 4.6  Funciones tradicionales y no tradicionales de los campeones de proyectos

Funciones tradicionales
Conocimientos técnico Comprensión de los aspectos técnicos involucrados en el desarrollo del proyecto
Liderazgo Capacidad para proveer liderazgo al equipo del proyecto
Coordinación y control Dirección y control de las actividades del equipo
Obtención de recursos Ganancia en acceso a los recursos necesarios para garantizar un proceso de
desarrollo sin contratiempos
Administrativo Manejo de la parte administrativa importante del proyecto

Funciones no tradicionales
Animador Proporciona el entusiasmo necesario (fuerza motriz espiritual) para el equipo
Visionario Mantiene un claro sentido del propósito y una idea firme de lo que está invo­
lucrado en la creación del proyecto
Político Emplea tácticas políticas necesarias y redes para asegurar una amplia acep­
tación y cooperación con el proyecto
Tomador de riesgo Esta dispuesto a correr riesgos personales o profesionales para apoyar el proyecto
Embajador Mantiene buenas relaciones con todos los interesados del proyecto
Fuente: J. K. Pinto and D. P. Slevin. (1988). “The project champion: Key to implementation success,” Project Management Journal,
20(4): 15–20. Copyright © 1988 by Project Management Institute Publications. Derechos de autor y todos los derechos reservados.
El material de esta publicación ha sido reproducido con permiso del PMI.
130 Capítulo 4  •  Liderazgo y el gerente de proyectos

dijo: “Podemos enseñarles a las personas las habilidades (tradicionales) con bastante facilidad, pero la experien-
cia es el mejor maestro para las demás actividades (no tradicionales). Nadie te prepara para el lado irracional de
este trabajo. Hay que apropiárselo sobre la marcha.”
En muchas organizaciones, la mayor parte del tiempo de un campeón no se dedica a la realización de la
parte tradicional de las funciones de gerencia de proyectos, sino que se utiliza en las actividades “no tradicio-
nales”. El campeón es a menudo la persona visionaria, animadora o la fuerza impulsora detrás del proyecto.
Adicionalmente, se espera que el campeón desempeñe papeles políticos claves, haga los contactos adecuados
y cree la red de personas, todo lo anterior para garantizar un suministro constante de los recursos necesarios
para que el proyecto tenga éxito. Finalmente, debido a que los campeones, por definición, se identifican
fuertemente con el proyecto, gran parte de su tiempo se dedica a la creación de redes con otras unidades de
la organización, la alta gerencia y los posibles clientes (usuarios) del proyecto. En esta tarea, desempeñan un
papel importante como embajadores/defensores en toda la organización. En muchos casos, los campeones
dedican su carrera para apoyar y lograr la aceptación del nuevo sistema y, como consecuencia, se compro-
meten a ayudar al proyecto en todo lo posible, tanto a través de las actividades tradicionales como de las no
tradicionales.
Una pregunta que surge es: ¿este tipo de comportamiento realmente desempeña un papel importante
en la gerencia exitosa de proyectos? La respuesta es un rotundo “sí”. Aparte de información anecdótica y
estudios de casos, algunos estudios de investigación convincentes ayudan a comprender mejor no solamente
lo que hacen los campeones, sino lo importante que son los campeones para adquirir y lograr la aceptación
de nuevos proyectos en la organización.21 Por ejemplo, un estudio examinó una serie de desarrollos y crea-
ciones de nuevos productos en una variedad de organizaciones.22 Se estudió la relación entre la presencia o
ausencia de un campeón identificable en la organización y el éxito del proyecto para 45 nuevas iniciativas de
desarrollo de productos. De los 17 nuevos desarrollos de productos exitosos, todos menos uno, o 94%, tuvo
un campeón fácilmente identificable; estos emprendimientos fueron encabezados por un individuo que la
mayoría de los interesados del proyecto pudo señalar e identificar como el patrocinador o el campeón de
ese proyectos. Por otro lado, de los 28 proyectos que fracasaron, solo uno fue asociado con un campeón de
proyectos identificable. Evidentemente, los resultados de este estudio apuntan a la enorme importancia que
un campeón puede desempeñar en el desarrollo de nuevos productos.

Cómo hacer un campeón


Todas las organizaciones difieren en cuanto a la disponibilidad de personal para desempeñar el papel de cam-
peón de proyectos. Aunque algunas organizaciones tienen un suministro de personal entusiasta en todos sus
niveles dispuestos a servir como campeones, la realidad en la mayoría de las organizaciones no es tan optimista.
La culpa, en este caso, no es que estas organizaciones tengan personas inadecuadas o no calificadas. A menudo,
el problema es que las organizaciones no han reconocido los beneficios que se derivan de los campeones. Los
campeones y el clima en el que puedan existir deben desarrollarse y mantenerse por la organización.
Algunos principios y opciones importantes en las organizaciones para reconocer el desarrollo y uso
de los campeones de proyectos incluyen identificar y animar el surgimiento de los campeones, alentar y
recompensar a los tomadores de riesgo, recordar que los campeones se conectan emocionalmente con sus
proyectos y evitar atar demasiado a los campeones a las actividades tradicionales de gerencia de proyectos.23

IDENTIFICAR Y ANIMAR EL SURGIMIENTO DE LOS CAMPEONES  En muchas compañías, hay personas


que demuestran entusiasmo e impulso para ser campeones de nuevas ideas de proyectos. Es importante
que estas organizaciones desarrollen una cultura que no solo tolere sino que promueva activamente a los
campeones. En muchas organizaciones, un gestor creativo que acosa continuamente a la alta gerencia con
una nueva idea de proyecto probablemente ofenderá a algunos miembros claves del equipo directivo. Sin
embargo, para que una empresa pueda aprovechar todo el potencial de sus campeones internos debe crear
una cultura de apoyo en la que los campeones sientan que pueden trabajar sin crítica o supervisión excesiva.

ALENTAR Y RECOMPENSAR A LOS TOMADORES DE RIESGO   Jack Welch, ex CEO de General Electric,
hizo una cruzada personal para alentar activamente a los altos, medios e incluso bajos directivos a tomar
riesgos. Su argumento era que la innovación no estuviera exenta de riesgos y si no se puede llegar a tomar
riesgos, no se puede innovar. El corolario de fomentar la toma de riesgos es evitar la respuesta instintiva de
buscar culpables y castigarlos por sus errores en los proyectos. Las innovaciones son, por definición, empren-
dimientos arriesgados, pueden dar lugar a enormes pagos, pero también tienen una posibilidad muy alta de
4.4  Campeones de proyectos 131

fracaso. Las organizaciones tienen que ser más conscientes de los efectos positivos de alentar a las personas a
tomar riesgos y a desempeñar funciones como campeones en proyectos innovadores. Un proyecto exitoso a
menudo equivale a diez proyectos fracasados.

RECORDAR QUE LOS CAMPEONES SE CONECTAN EMOCIONALMENTE CON SUS PROYECTOS   Los cam-
peones tienen una gran cantidad de energía y compromiso emocional con sus ideas de proyecto; sin embargo,
una desventaja potencial del uso de campeones de proyectos es el hecho de que a menudo se niegan a darse por
vencidos, incluso de cara a un fracaso inminente del proyecto. Como resultado, muchas empresas siguen persi-
guiendo “perros” mucho después de que la esperanza de finalizar con éxito o de lograr la aceptación comercial
ha pasado. Por ejemplo, Microsoft presentó su teléfono celular “Kin” en 2010 y lo comercializó particularmente
en adolescentes y fanáticos de las redes sociales. El Kin no era un “teléfono inteligente”, no tenía aplicacio-
nes ni juegos, y sin embargo su operación era costosa. A pesar de los mejores esfuerzos de Microsoft, fracasó
rápidamente en el mercado y fue abandonado tan solo dos meses después de su introducción. El ejecutivo de
Microsoft, Robbie Bach, autor intelectual del dispositivo Kin, dejó la compañía poco después.

EVITAR ATAR DEMASIADO A LOS CAMPEONES A LAS ACTIVIDADES TRADICIONALES DE GERENCIA


DE PROYECTOS   Los campeones y gerentes de proyectos pueden ser las mismas personas, pero a menudo
no lo son. Muchas veces los campeones clásicos, como lo muestra el cuadro 4.6 de la página 129, se sienten
más cómodos apoyando un proyecto a través de actividades no tradicionales, debido a que tienden a ser

RECUADRO 4.2

GERENTES DE PROYECTOS EN LA PRÁCTICA


Bill Mowery, CSC
“La gerencia de proyectos, como disciplina, ofrece oportunidades ilimitadas a través de casi infinitas combina­
ciones de industrias, habilidades y alternativas, pues genera una carrera que sigue siendo desafiante y gratifi­
cante”. Esta afirmación proviene de Bill Mowery, quien trabaja como gerente sénior en el Financial Services
Group (FSG) de Computer Sciences Corporation (CSC).

FIGURA 4.4  Bill Mowery, CSC


(continúa)
132 Capítulo 4  •  Liderazgo y el gerente de proyectos

El trabajo actual de Mowery es una combinación de gobierno de proyectos, trabajando Project


Management Office (PMO) de la empresa y proyectos especiales de apoyo a los objetivos estratégicos. Las
funciones de gobierno de proyectos consisten en el monitoreo y reporte del estado del portafolio de proyectos
de una de las divisiones de la FSG mientras proporciona orientación sobre las mejores prácticas y métodos
de gerencia de proyectos. Una parte importante del actual papel de Mowery es “arquitecto de negocios”,
pues soporta el sistema de monitoreo y reporte de los proyectos de propiedad de FSG. Este sistema fue desar­
rollado para proporcionar capacidades avanzadas en la recolección y difusión automatizada de indicadores
de desempeño del proyecto. Mowery argumenta: “Tal vez la parte más difícil de mi trabajo se refiere a los
proyectos especiales ad hoc que apoyan las metas conjuntas de FSG y los corporativas de CSC. La oportunidad
de colaborar globalmente con mis colegas en una amplia diversidad de esfuerzos de tecnologías y negocios
proporciona tanto reto como variedad a mi carrera”.
La trayectoria profesional de Mowery en el área de gerencia de proyectos parece haber sido algo inten­
cional. Después de haber sido entrenado en electrónica y tecnología informática y ganar un título de asociado,
mientras servía en el Ejército de Estados Unidos, comenzó su carrera civil en ingeniería de software, buscando
titularse en la universidad en ciencias de la computación y matemáticas. Como programador, tuvo su primera
experiencia de trabajo en gerencia de proyectos, simplemente porque era el contratista de software de mayor
antigüedad. Esta entrada fortuita a este tipo de trabajo le llevó a una carrera que lo ha fascinado y comprometido
en los últimos 25 años. Durante este tiempo, Mowery ha trabajado en muchas de industrias, incluido el desarrollo
de productos electrónicos, procesamiento de combustible nuclear, servicios financieros y sistemas de manejo de
materiales. Una de las cosas que ha aprendido durante su polifacética carrera es que los principios de gerencia de
proyectos son esenciales, independientemente del sector. Como él señala: “Mientras la industria y la tecnología
pueden cambiar, los principios de gerencia de proyectos que conducen al éxito siguen siendo una constante”.
Debido a la riqueza de la experiencia con la ejecución de proyectos en tantos sectores durante un
periodo tan prolongado, Mowery tiene la responsabilidad agregada de servir como mentor para los jóvenes
gerentes de proyectos en su organización, un papel que él disfruta. “El aspecto de mi trabajo que me parece
más gratificante es la oportunidad de colaborar y aconsejar a un gran número de personal de gerencia de
proyectos. Cuando un gerente de proyectos se enfrenta con un desafío único en su trabajo y yo estoy en
capacidad de ofrecer información y asesoría para ayudarle a resolver el problema, esto me proporciona una
sensación de satisfacción al saber que otra persona no tiene que aprender algo ‘por las malas’”.
Cuando se le preguntó qué consejo les puede ofrecer a las personas interesadas en seguir una carrera en
gerencia de proyectos, Mowery respondió: “El mejor consejo que puedo ofrecer a cualquiera que esté conside­
rando una carrera en la gerencia de proyectos es tener la paciencia de una roca, una personalidad empática y
amor por el aprendizaje. La gerencia de proyectos puede ser un campo complejo, y yo a menudo le digo a la
gente que cuanto más aprendo, menos sé. Esto puede confundir a la gente, pero en pocas palabras, cuanto
más aprendo, más entiendo que hay que saber y descubrir más en una profesión fascinante y compleja”.

visionarios, animadores y tomadores de riesgos, que se acercan a sus metas con una fuerza inquebrantable y
un sentido del diseño global. Más que apoyar los aspectos rutinarios de la gerencia de proyectos, como la pla-
neación, programación, asignación de recursos y el manejo de los detalles administrativos, la experticia de los
campeones y su valor real en el proceso de implementación puede estar en sus conexiones y contribuciones
políticas, es decir, en emplear sus habilidades de gerencia no tradicionales.

4.5  EL NUEVO LIDERAZGO DE PROYECTOS


La gerencia de proyectos requiere que aprovechemos nuestras habilidades para guiar a otros. Estas habili-
dades pueden o (más probable) no pueden ser innatas; es decir, para la mayoría de nosotros, el liderazgo no
es algo con lo que nacimos. Sin embargo, sabemos suficiente sobre el desafío del liderazgo para reconocer
que líderes son como líderes se hacen.24 Cuando empezamos a reconocer y ejercer papeles de liderazgo, la
forma más natural de estas actividades vendrán a nosotros. Un artículo de uno de los mejores escritores de
dirección de organizaciones, el doctor Warren Bennis, resume cuatro competencias que determinan nuestro
éxito como líderes de proyectos:25
1. El nuevo líder entiende y practica el poder de reconocimiento. Los líderes de proyectos son conoce-
dores del talento, más conservadores que creadores.  El reconocimiento se deriva de nuestra capaci-
dad para reconocer y recompensar el talento de los demás. Los líderes pueden no ser los mejores o los
más valiosos, o más inteligentes de los equipos de proyectos. Su papel no es para eclipsar a los demás,
sino para permitirles a otros desarrollar su mejor potencial.
4.5  El nuevo liderazgo de proyectos 133

2. El nuevo líder mantiene recordándole a la gente lo que es importante.  Esta simple declaración lleva
un mensaje poderoso para los gerentes de proyectos. Tenemos que recordar que en la consecución de
un proyecto, probablemente surjan una serie de problemas, dificultades, molestias y desafíos técnicos
y humanos. Con frecuencia, durante los proyectos se descubren numerosos problemas que no eran
evidentes antes de que se iniciara el trabajo serio. Los gerentes de proyectos deben tener presente que
una de sus contribuciones más importantes es mantener a las personas con sus ojos fijos en el premio
final, recordándoles continuamente lo que es importante.
3. El nuevo líder genera y mantiene la confianza.  La investigación de Kouzes y Posner citada al prin-
cipio de este capítulo contiene un potente mensaje: la característica más importante buscada en los
líderes es la honestidad.26 Los líderes que generan confianza y se comportan con autenticidad, justicia,
honestidad y atención tendrán éxito en la creación de un entorno en el que los miembros del equipo
se esfuerzan por hacer lo mejor. La confianza desempeña un papel clave en el desarrollo de las rela-
ciones productivas líder/miembros.27 Solo mediante el reconocimiento y la aplicación de la confianza
demuestran la lealtad y el compromiso con los miembros del equipo como individuos que darán lo
mejor de ellos mismos.
4. El nuevo líder y el liderado son aliados íntimos.  Al principio de este capítulo examinamos el concepto
de la asociación entre el líder y sus seguidores. Este punto es importante y debe hacerse hincapié en los
comportamientos del liderazgo efectivo. El liderazgo en la gerencia de proyectos no se plantea con el fin
de controlar y dominar al equipo del proyecto, sino como un método natural para apoyar los esfuerzos
del equipo. A medida que trabajamos para desarrollar habilidades de liderazgo, es importante recono-
cer primero las razones por las que es necesario el liderazgo para el éxito del proyecto y luego tomar las
medidas concretas necesarias para hacer realidad la visión del proyecto, algo que podemos realizar mejor
cuando nosotros, como líderes, trabajamos en estrecha armonía con nuestros equipos.

PERFIL DE PROYECTO

El reto de la gerencia internacional


Como la gerencia de proyectos se convierte en un fenómeno internacionalizado, es fundamental para los líde-
res exitosos reconocer su estilo de gerencia y hacer las adaptaciones necesarias cuando se trate de miembros del
equipo procedentes de otros países. La actual generación de gerentes de proyectos está descubriendo que el tra-
bajo internacional no es un acontecimiento misterioso o poco frecuente; de hecho, es la realidad cotidiana para
los gerentes de proyectos en muchas organizaciones basadas en proyectos. ¿Cuáles son algunas de las lecciones
importantes para tomar en serio por todos los gerentes de proyectos cuando trabajan en el extranjero? Una lista
la ofrece un gerente exitoso de proyectos, Giancarlo Duranti. Nacido en Italia, Duranti tiene experiencia liderando
equipos en Brasil, Cuba y Gambia. Entre sus sugerencias para tomar las decisiones correctas de liderazgo en entor-
nos internacionales están:
1. Conozca al detalle el medio ambiente.  Infórmese sobre el entorno en el que va a trabajar por medio de docu-
mentales de televisión y lecturas de guías de viaje, libros de turismo, e incluso periódicos locales. La historia es
igual de importante: cuanto mejor conozca el pasado de una cultura particular, más pronto podrá comenzar a
entender las actitudes y percepciones del equipo.
2. No elabore estereotipos.  Es fácil acercarse a un entorno exterior con nociones preconcebidas acerca de su
gente, la cultura, el clima y los alimentos. Si no nos permitimos experimentar un escenario de la “primera vez”,
es difícil evitar la formación de opiniones superficiales y, en última instancia, inútiles.
3. Interésese genuinamente en las diferencias culturales.  La gente está ansiosa por compartir las tradiciones
locales y nacionales y, a su vez, tienen una curiosidad por las suyas. Demostrando un interés real en su cul-
tura y compartiendo la propia, ayuda a ambas partes a apreciar estas diferencias en lugar de estar separados
por ellas.
4. No suponga que hay una forma (la suya) para comunicarse.  Las diferencias de comunicación entre las cultu-
ras son profundas. Recuerde, por ejemplo, que el uso del humor y maneras de dar retroalimentación, incluida
la corrección, difieren mucho entre culturas. Se debe aprender a apreciar otros medios de intercambio de in-
formación y a reconocer lo que “realmente” se dice en varios intercambios.
5. Escuche activa y empáticamente.  Evite los juicios al escuchar y tratar de ver cada situación con cierta distan-
cia y perspectiva.28
134 Capítulo 4  •  Liderazgo y el gerente de proyectos

4.6  PROFESIONALISMO EN LA GERENCIA DE PROYECTOS


A principios de 2003, el U. S. Department of Energy dio vía libre a una iniciativa interna para crear una
carrera de gerencia de proyectos dentro de su organización. Este lanzamiento fue seguido por medidas
similares en muchas organizaciones, desde empresas tan diversas como Ernest & Young (consultoría)
hasta la NASA. Bruce Carnes, del Departament of Energy, explicó las razones para este movimiento:

Gran parte de nuestro trabajo se lleva a cabo a través de proyectos. De hecho, nuestros gerentes
de proyectos son actualmente responsables de más de 100 proyectos por un valor total de más
de 20,000 millones de dólares, más otros 150,000 millones de dólares en trabajos de restauración
del medio ambiente para las próximas décadas. Es importante para nosotros asegurarnos de que
nuestros gerentes de proyectos tienen las mejores competencias posibles, y que cada persona es
tratada como un activo crítico. Por tanto, necesitamos un plan cohesivo de gerencia de la carrera
para desarrollarlo, haciendo coincidir sus habilidades con las tareas, siguiendo su rendimiento y
recompensándolos cuando proceda.29

Integrados a esta explicación hay varios puntos importantes que ilustran la creciente profesionaliza-
ción de la disciplina gerencia de proyectos. Vamos a considerarlos en seguida.30
Primero, cada vez para más organizaciones, el trabajo de proyectos está convirtiéndose en la norma.
Los proyectos ya no son simplemente componentes adicionales no rutinarios de la vida organizacional, pues
en muchas firmas están convirtiéndose en los principales medios por los cuales estas logran sus metas. Junto
al mayor reconocimiento de la importancia del uso de las técnicas de gerencia de proyectos surge la necesi-
dad concomitante de adquirir, entrenar y mantener un cuadro de profesionales de gerencia de proyectos que
se dediquen a estas tareas.
Segundo, hay una necesidad crítica de mejorar los conocimientos de los que realizan el trabajo de
proyectos. Sería un error asignar continuamente recursos de la organización, recursos humanos, en parti-
cular a los proyectos, sin asegurarse de que están aprendiendo, desarrollando sus habilidades de proyectos
y acercándose a estas tareas con una base sólida de conocimientos. En resumen, uno de los aspectos de la
profesionalización es reconocer que los profesionales de gerencia de proyectos no son un recurso ad hoc de la
organización, sino un recurso fundamental que se debe desarrollar y mantener. Por tanto, vale la pena apoyar
a estas personas como un recurso que requiere formación continua y desarrollo de habilidades.
Tercero, la profesionalización de la gerencia de proyectos reconoce la necesidad de crear un plan de
carrera claro para aquellos que sirven como gerentes de proyectos y para el personal de apoyo. Históricamente,
las organizaciones “encuentran” a sus gerentes de proyectos entre el personal de gerencia de línea y les asigna
la responsabilidad de ejecutar el proyecto, siempre con el supuesto de que una vez que el proyecto se haya
finalizado, los gerentes podrían volver a sus deberes funcionales, normales. En resumen, la gerencia de pro-
yectos es una asignación temporal, y una vez que se ha completado, el gerente se devuelve a sus actividades
“reales”. En el nuevo modelo de profesionalización, el personal de gerencia de proyectos consideran el tra-
bajo del proyecto como una asignación permanente de carrera, con gerentes moviéndose de un proyecto a
otro, pero siempre dedicados a esta carrera. Cada vez, más empresas están diferenciando oficialmente entre
su personal funcional y sus profesionales de gerencia de proyectos, resistiendo la tentación de mover a la
gente entre las asignaciones del proyecto y los deberes funcionales.
Esta nueva mentalidad de profesionalización se caracteriza por las experiencias de la NASA, sobre
todo a raíz del desastre del transbordador Challenger en 1986. Después de las lecciones aprendidas a partir
de ese terrible suceso, la NASA determinó que había la necesidad permanente de un grupo de profesio-
nales en gerencia de proyectos dedicados e integrados dentro de la organización. Ed Hoffman, quien se
desempeña como director de la Academia de Programas y Proyectos de Liderazgo de la NASA, enfatiza
este punto: “La mentalidad de la NASA considera el enfoque de proyectos como la única forma de hacer
negocios. Estamos constantemente obligados responder a los desafíos de costos y plazos, lo cual requiere
la cooperación de una variedad de disciplinas. Francamente, nuestra gente podría confundirse en un
enfoque funcional.”31
¿Qué medidas prácticas pueden tomar las organizaciones para comenzar a desarrollar un núcleo de
profesionales en gerencia de proyectos? Algunas de las estrategias son las siguientes:

• Comenzar a coincidir tipos de personalidad para trabajar el proyecto.  Las investigaciones sugieren
que algunos tipos de personalidad pueden ser más tolerantes al trabajo de proyectos que otros.32 Por
4.6  Profesionalismo en la gerencia de proyectos 135

ejemplo, los individuos orientados a las personas tienen una mejor probabilidad de buen desempeño
en los proyectos frente a las personas más silenciosas o introvertidas. Del mismo modo, las personas
con mayor capacidad para trabajar en un entorno no estructurado y dinámico están más sintonizadas
con el trabajo de proyectos que las que requieren una estructura formal y reglas de trabajo. Como
punto de partida, puede ser útil realizar algunas evaluaciones básicas de personalidad a los recursos
potenciales del proyecto, a fin de determinar su receptividad psicológica con el trabajo.
• Formalizar el compromiso de la organización para el trabajo de proyectos con programas de for-
mación.  No hay duda de que los miembros de la organización pueden reconocer el compromiso de
la empresa con los proyectos auspiciados por esta para apoyar la formación y el desarrollo habilida-
des necesarias de su personal. Sin embargo, para que la capacitación sea efectiva, se requieren varios
elementos. Primero, debe llevarse a cabo una auditoría para determinar qué habilidades claves son
necesarias para desarrollar los proyectos. Segundo, la auditoría debe determinar el grado en que los
miembros de la organización poseen esas habilidades. Tercero, donde hay claras diferencias entre el
conjunto de habilidades necesarias y los conocimientos disponibles, la formación de gerencia de pro-
yectos debe dirigirse primero a reducir las brechas, es decir, la formación y las necesidades de gestión
de proyectos deben estar alineadas.
• Desarrollar un sistema de recompensas para la gerencia de proyectos diferente del programa fun-
cional normal de recompensas.  Los tipos de recompensas, ya sean promociones, bonos u otras
formas de reconocimiento, disponibles para el personal de gerencia de proyectos deben reflejar las
diferencias en los tipos de trabajo que ellos efectúan y no en comparación con el trabajo realizado
por los miembros regulares de la organización. Del mismo modo, los aumentos o promociones de
las empresas de proyectos a menudo se basan directamente en los resultados del proyecto en que los
miembros del equipo han trabajado. Así, dentro de la misma organización, los miembros funcionales
pueden promoverse por la cantidad de tiempo que han estado a un nivel de gerencia, mientras que
sus contrapartes profesionales de proyectos son promovidos exclusivamente por su desempeño acu-
mulado en múltiples proyectos.
• Identificar una carrera diferente para los profesionales del proyecto.  Un gerente de proyectos con
cinismo le dijo una vez a este autor: “En nuestra organización hay dos escalas profesionales. Por des-
gracia, ¡solo una de ellas tiene peldaños!” Su punto era que un excelente rendimiento en los proyectos
no les generaba a las personas algún tipo de recompensa, sobre todo en lo relacionado con las promo-
ciones. En su empresa, los proyectos eran “un lugar donde los gerentes mediocres iban a morir”. En
contraste con este ejemplo, en Bechtel Corporation la gerencia de proyectos se considera un recurso
clave, el personal de gerencia de proyectos es evaluado cuidadosamente y su rendimiento superior se
recompensa. Particularmente, Bechtel tiene una trayectoria profesional de dos vías que les permite a
los gerentes de proyectos exitosos tener las mismas oportunidades de otros gerentes funcionales para
promoverse en la compañía.
La profesión en proyectos reconoce que el aumento de interés en la gerencia de proyectos como
disciplina ha dado lugar a la necesidad de crear un fondo de recursos de personas capacitadas para que
la organización utilice. En resumen, vemos un ejemplo de la oferta y la demanda de trabajo. A medida
que más organizaciones comienzan a aplicar técnicas de proyectos en sus operaciones, se aumentará la
necesidad de personas suficientemente capacitadas para realizar estas tareas. Una de las mejores fuen-
tes de experticia en gerencia de proyectos proviene de estas organizaciones, siempre y cuando tomen las
medidas necesarias para cultivar y fomentar una actitud de profesionalismo en su personal de gerencia de
proyectos.
Este capítulo comenzó con la proposición de que la gerencia de proyectos es una labor “basada en
liderazgo intensivo”, es decir, pocas actividades de las organizaciones de hoy dependen más de la actuación
y el compromiso de un líder fuerte que la de ejecutar proyectos. A través de la exploración de los tipos de
actividades que los gerentes de proyectos deben realizar, las características de los líderes de proyectos efecti-
vos, el papel de la inteligencia emocional en la gerencia de proyectos, los conceptos de comportamiento de
campeones de proyectos y la esencia de la nueva gerencia de proyectos, este capítulo dibujó un cuadro de las
diversas y desafiantes funciones que se espera que los gerentes de proyectos realicen cuando buscan el éxito
de un proyecto. Cuando nos esforzamos en desarrollar nuestras habilidades de liderazgo a su máximo poten-
cial, el desafío es significativo, pero las recompensas son enormes.
136 Capítulo 4  •  Liderazgo y el gerente de proyectos

Resumen
1. Comprender cómo la gerencia de proyectos es una temporal sugiere que cada uno de nosotros tiene una
profesión “basada en el líder”.  La gerencia de pro- orientación temporal preferida, ya sea la perspectiva
yectos es una labor “basada en el líder” porque el del pasado, presente o futuro. Esta orientación hace
gerente del proyecto, como líder, desempeña un papel que algunos de los deberes de los gerentes de proyec-
central en el desarrollo del proyecto. El gerente del pro- tos sean más fáciles de realizar, mientras que otros se
yecto es el conducto por el cual fluye la información hacen más difíciles. Cuanto mejor comprendamos
y la comunicación, principal planificador, pionero del nuestra propia perspectiva temporal, incluidas sus
objetivo, desarrollador del equipo, motivador, solucio- fortalezas y debilidades, tanto más seremos capaces de
nador de conflictos, etc. Sin el compromiso de un líder reconocer los papeles del proyecto que probablemente
de proyectos enérgico, es muy poco probable que el realizaremos bien y en los que necesitaremos atención
proyecto se realice exitosamente. extra para conseguir desempeñarlos correctamente.
2. Distinguir entre el papel de un gerente y las caracterís- 6. Identificar los papeles principales que desempeña
ticas de un líder.  El papel del gerente en una organiza- el campeón en el éxito del proyecto.  Los campeo-
ción se caracteriza por su autoridad posicional. Los geren- nes son individuos dentro de una organización que se
tes reciben títulos que les dan el derecho a ejercer control identifican con un nuevo proyecto, utilizando todos
sobre el comportamiento de los demás, se centran más en los recursos a su disposición para apoyarlo, incluso de
la administración y organización del proyecto y buscan cara a la resistencia organizacional. Los campeones son
la eficiencia y el mantenimiento del statu quo. Los líderes tomadores de riesgos, pues están dispuestos a trabajar
se centran en las relaciones interpersonales, desarrollan e constantemente de cara a la resistencia o a la hostili-
inspiran a otros con su visión del proyecto y del futuro. dad, de otros miembros de la compañía, a la idea. La
Ellos abrazan al cambio, motivan a otros, se comunican investigación apoya fuertemente el argumento de que
con palabras y con obras, se centran en la efectividad de los proyectos con un campeón identificable tienen más
los resultados y toman riesgos a largo plazo. probabilidades de éxito que con uno que no lo tiene.
3. Entender el concepto de inteligencia emocional y su Entre los papeles tradicionales que desempeñan los
relación con la forma en que lideran los gerentes campeones están: entendimiento técnico, liderazgo,
de proyectos.  Cinco dimensiones de la inteligencia coordinación y control, obtención de recursos y admi-
emocional se relacionan con el liderazgo del proyecto: nistración. De naturaleza no tradicional en el compor-
(1) autoconciencia, es decir, la comprensión de las tamiento del campeón se incluyen la participación en
fortalezas y debilidades que uno proyecta; (2) auto- actividades como animador, visionario del proyecto,
rregulación, o sea, la capacidad de mantenerse bajo político, tomador de riesgo y embajador, todo ello para
control pensando antes de actuar y evitando emitir apoyar el proyecto.
juicios apresurados; (3) motivación, es decir,todos 7. Reconocer los principios que caracterizan el nuevo
los líderes exitosos demuestran primero su propio liderazgo en proyectos.  La idea de la nueva gerencia
grado de motivación antes de inspirar a los demás; del proyecto de Warren Bennis se basa en gran medida
(4) empatía, o sea, la habilidad de reconocer las dife- en la gestión de las relaciones a través de la creación y
rencias de cada subordinado y tratar a cada miembro el mantenimiento de un compromiso mutuo con cada
del equipo de forma que pueda obtener su máximo miembro del equipo del proyecto. Los cuatro principios
compromiso; y (5) habilidad social, es decir, amistad de la nueva gerencia de proyectos incluyen: (1) entender
con el propósito de mover a la gente en la dirección y practicar el poder del reconocimiento en la relación
deseable. con cada miembro del equipo del proyecto; (2) conti-
4. Reconocer los rasgos más importantes e influyentes nuamente recordarles a las personas que es importante
en el liderazgo efectivo de proyectos.  Una serie de mantenerse centrado en el “cuadro grande”; (3) generar
rasgos de liderazgo están estrechamente vinculados y mantener la confianza con cada miembro del equipo
con el liderazgo efectivo de proyectos, e incluyen: (1) del proyecto; y (4) el reconocimiento de que el líder y el
credibilidad y honestidad; (2) capacidad para la reso- liderado son aliados naturales, no adversarios.
lución de problemas; (3) tolerancia a la complejidad y 8. Comprender el desarrollo de la profesionalización de
ambigüedad; (4) flexibilidad en la gestión de los subor- la disciplina gerencia de proyectos.  Como la geren-
dinados; (5) habilidades de comunicación; (6) creativi- cia de proyectos cada vez es más popular, su éxito ha
dad; (7) capacidad para tomar decisiones; (8) experien- llevado al desarrollo de un núcleo de gerentes de pro-
cia; (9) capacidad para trabajar bien en el equipo del yectos profesionales en muchas organizaciones. Al
proyecto; y (10) fuerte capacidad de influencia. reconocer la ley de la oferta y la demanda, a medida que
5. Entender las implicaciones de la orientación tem- la demanda de conocimientos de gerencia de proyec-
poral en la gerencia de proyectos.  La orientación tos sigue creciendo, la oferta debe mantener el mismo
Preguntas para discusión 137

ritmo. La profesionalización reconoce la “instituciona- privadas. La proliferación de sociedades profesionales


lización” de los proyectos y de la gerencia de proyec- de apoyo a la gerencia de proyectos es otro indicador
tos dentro de las organizaciones, tanto públicas como del interés en la disciplina.

Términos clave
Alineación temporal Emprendedor (p. 128) Orientación al futuro Orientación temporal
(p. 126) Fragmentación del tiempo (p. 126) (p. 126)
Autorregulación (p. 122) (p. 126) Orientación al pasado Patrocinador (p.128 )
Campeón (p. 127) Gestor creativo (p. 128) (p. 126) Predecir (p. 126)
Distorsión del tiempo (p. 126) Liderazgo (p. 116) Orientación al presente Profesionalismo (p.134)
Empatía (p. 122) Motivación (p.122) (p.126 )

Preguntas para discusión


1. Este capítulo destaca la idea de que la gerencia de proyectos es 6. Complete la escala de preferencia temporal al futuro. Después
una labor “basada en el líder”. Analice en qué sentido esta afir- de completarla, determine si tiene una perspectiva temporal
mación es cierta. al futuro, presente o pasado. ¿Cuáles son las implicaciones
2. ¿De qué manera las actividades de los gerentes de proyectos para los tipos de tareas que le gusta realizar? ¿Cómo genera
refuerzan el papel de liderazgo? su preferencia fortalezas y debilidades para la gerencia de
3. ¿Cuáles son las principales diferencias entre líderes y gerentes? proyectos?
4. Analice el concepto inteligencia emocional y su relación con 7. ¿Por qué se dice que los campeones de proyectos están mejor
las actividades de los gerentes de proyectos. ¿Por qué son tan equipados para manejar los aspectos “no tradicionales” de
importantes los cinco elementos de la inteligencia emocional liderazgo?
para la gerencia exitosa de proyectos? 8. Considere el análisis del “nuevo liderazgo en proyectos”. Si se le
5. Considere los estudios sobre las teorías de rasgos de liderazgo. pidiera formular un principio que pudiera aplicarse al liderazgo
De las las características claves para el liderazgo efectivo, ¿cuá- en proyectos, ¿cuál formularía? Justifique su respuesta.
les le parecen más importantes para los gerentes de proyectos?
¿Por qué?

Escala de preferencia temporal al futuro33


Lea cada frase y decida hasta qué grado es cierta para usted. En cada declaración, señale el número que
mejor se ajusta a sus sentimientos, según la escala de abajo.

1 2 3 4 5
Muy en En Ni de acuerdo ni Muy de
desacuerdo desacuerdo en desacuerdo De acuerdo acuerdo
(MD) (D) (N) (A) (MA)

MD D N A MA
1. Nunca siento como si el tiempo se quedara quieto. 1 2 3 4 5
2. Vivir para el futuro es importante en mi vida. 1 2 3 4 5
3. Yo siempre pienso las cosas antes de actuar. 1 2 3 4 5
4. Cuando trato de pensar en cosas que pueden suceder en el 1 2 3 4 5
futuro, veo una imagen clara.
5. Cuando pienso en mi futuro, una sensación de paz y tranquili­ 1 2 3 4 5
dad se apodera de mí.
6. El tiempo se mueve rápidamente. 1 2 3 4 5
7. No hay suficientes minutos en un día para listar todo lo que es­ 1 2 3 4 5
pero hacer en el futuro.
8. El ritmo de mi vida es rápido. 1 2 3 4 5
9. Veo el futuro como si estuviera lleno de un sinfín de posibilidades. 1 2 3 4 5
10. Siento que enfrento mi futuro con confianza. 1 2 3 4 5
138 Capítulo 4  •  Liderazgo y el gerente de proyectos

Escala de preferencia temporal al futuro

Agregue las puntuaciones de cada ítem y divida por 10. Esto le proporcionará una medida de la prefe­
rencia temporal al futuro. Después de realizar la prueba, ponga una X en la siguiente escala para indicar
el nivel de la preferencia temporal al futuro.

Preferencia temporal al futuro:

1 2 3 4 5
Baja Media Alta
Fuente: Peg Thoms, Driven by the Future: Time Orientation and Leadership, p. 25. Copyright © 2004. New York: Praeger.
Reproducido con permiso de Greenwood Publishing Group, Inc., Westport, CT.

Estudio de caso 4.1


En busca de gerentes de proyectos efectivos
Pureswing Golf, Inc. fabrica y comercializa una línea com- suficiente. La tasa de fracaso de estos voluntarios geren-
pleta de equipos de golf, incluidos palos de golf, pelotas de tes de proyectos es superior al 40%, muy alto para una
golf, ropa deportiva y equipos auxiliares (bolsas, ropa de llu- empresa del tamaño de Pureswing. Con estos indicado-
via, toallas, etc.). La empresa hace presencia en una industria res constantes entre los voluntarios, los gerentes exitosos
altamente competitiva y de ritmo rápido contra competi- tienen que tomar las riendas, muchas veces, de cinco o
dores conocidos, como Nike, Taylor Made, Titleist, PING, seis proyectos simultáneamente. La alta gerencia, pre-
Calloway y Cleveland. Entre las claves de éxito en esta indus- ocupada por el agotamiento entre los gerentes de pro-
tria están la continua introducción de nuevos modelos de yectos de alto rendimiento, decidió que la empresa debe
palos de golf, la ingeniería, el diseño innovador y la velocidad desarrollar un programa coordinado para la búsqueda
del mercado. Como una pequeña empresa tratando de man- de nuevos gerentes de proyectos, incluida la creación de
tenerse al tanto de los competidores más fuertes, Pureswing una carrera profesional en gerencia de proyectos dentro
pone énfasis en el proceso de gerencia de proyectos, con el fin de la organización.
de seguir siendo rentable. En cualquier momento, la empresa
cuenta con más de 35 equipos de proyectos de desarrollo de Preguntas
nuevas ideas a través de toda la diversidad de productos.
1. Imagine que usted es un profesional de recursos
Pureswing prefiere encontrar ingenieros prome-
humanos de Pureswing que ha sido asignado para
tedores dentro de la organización y los promueve a
desarrollar un programa de reclutamiento de nuevos
gerentes de proyectos; además, cree que estas personas,
gerentes de proyectos. Elabore una descripción de
después de haber aprendido la filosofía de éxito compe-
trabajo para el cargo.
titivo de la empresa, están mejor preparadas para eje-
2. ¿Qué cualidades y características personales dan
cutar nuevos proyectos de introducción de productos.
una mayor probabilidad de éxito como gerente de
Durante años, Pureswing se basó en voluntarios para
proyectos?
avanzar en la gerencia de proyectos, pero últimamente
3. ¿Qué cualidades y características personales podrían
se ha dado cuenta de que este método ad hoc para la bús-
dificultar ser un gerente de proyectos exitoso?
queda y el fomento de los gerentes de proyectos no es

Estudio de caso 4.2


Encontrar la inteligencia emocional para ser un verdadero líder
Recientemente, Kathy Smith, gerente de proyectos en de Asia. Kathy había ganado esta asignación después
una gran organización de la construcción industrial, fue de completar una serie de tareas de construcción más
asignada para supervisar el proyecto de construcción de pequeñas en América del Norte durante los últimos tres
una planta química de millones de dólares, en el sudeste años. Esta era su primera misión en el extranjero y estaba
(continúa)
Estudio de caso 4.3 139

dispuesta a dar una buena impresión, especialmente directamente, los miembros del equipo comenzaron una
teniendo en cuenta el tamaño y el alcance del proyecto. campaña de resistencia pasiva a su liderazgo. Ellos deli-
Completar con éxito este proyecto aumentaría su visi- beradamente empezaron a arrastrar sus pies en las tareas
bilidad dentro de la organización y la mostraría como importantes o a citar problemas insuperables cuando de
una candidata para la alta gerencia. Kathy tenía buenas hecho ninguno existía. La respuesta de Kathy era empujar
habilidades en gerencia de proyectos, en particular era a su equipo a trabajar más duro, presionando a sus subor-
organizada y altamente automotivada. Los miembros del dinados con comunicaciones cada vez más urgentes que
equipo de sus dos últimos trabajos de proyecto expresa- demandaban un rendimiento más rápido. Para su asom-
ban, en broma, que simplemente tratar de mantenerse al bro, nada parecía funcionar.
día con ella era un trabajo de tiempo completo. El proyecto rápidamente se estancó debido al bajo
Kathy no perdió el tiempo en prepararse ni super- rendimiento del equipo y terminó costándole a la orga-
visar el desarrollo de la planta química. Operando con un nización grandes sanciones por retraso en la entrega del
enfoque normal de trabajo, Kathy requirió a su personal proyecto. Aunque Kathy tenía muchas cualidades a su
y a miembros sénior del equipo del proyecto para trabajar favor, fue muy deficiente al tener en consideración los
largas horas, haciendo caso omiso a los fines de semana sentimientos y expectativas de los demás.
si se acercaban hitos importantes y, en general, la adop-
ción de un enfoque de veinticuatro horas de trabajo todo Preguntas
el año para el proyecto. Infortunadamente, al esperar 1. Analice por qué a Kathy le faltó suficiente inteligencia
que su equipo, formado por residentes locales, cambiara emocional para ser efectiva en su nueva asignación
sus hábitos de trabajo para darles cabida a sus expectati- como gerente del proyecto.
vas, Kathy leyó mal a las personas de su equipo. Ellos se 2. ¿De las diversas dimensiones de la inteligencia emo-
resintieron duramente por su estilo autoritario, falta de cional, de cuál (es) dimensión e(s) carece Kathy,
voluntad para consultarles sobre cuestiones claves y su en mayor medida? ¿Qué evidencia(s) apoya(n) su
naturaleza distante. Sin embargo, en lugar de enfrentarla respuesta?

Estudio de caso 4.3


Problemas con John
John James ha trabajado en una de las más grandes empre- particular. La queja empeoró. John comenzó a mostrar
sas aeroespaciales del mundo durante más de quince años. cambios de humor. Él podía ser muy productivo a veces
Fue contratado en la división durante la “Era Clinton”, (aunque todavía quejándose) y luego cambiar en periodos
cuando muchas personas ingresaron en la nómina. John de productividad cercana a cero. Durante estos tiempos,
no había completado su grado de ingeniería, por lo que John abiertamente navegaba por internet buscando sumi-
fue contratado como dibujante. La mayoría de las otras nistros para el nuevo proyecto de reparación de su casa o
personas en su departamento que fueron contratados en por el cómic más reciente de Dilbert. Sus compañeros de
ese momento habían completado sus estudios, por lo que trabajo estuvieron reacios a acusarlo a la gerencia cuando
comenzaron una carrera como ingenieros asociados. A lo ocurrieron estos episodios. La mayoría de los miembros
largo de los años, John progresó en la clasificación de inge- del equipo habían estado trabajando juntos durante los
niero. Muchos de los empleados contratados al mismo 15 años, y se habían convertido en amigos cercanos. Por
tiempo que John avanzaron más rápidamente debido a que ello, estos episodios no productivos de John eran un pro-
la empresa reconoció su título de ingeniería como requisito blema: nadie en el equipo se sintió cómodo para comuni-
previo para su promoción. Años de servicio pueden ser sus- car el problema a la alta gerencia. Como pasaba el tiempo,
tituidos, pero se requiere un número considerable de años los amigos de John se convertían en sus jefes, mientras
para compensar la falta de un grado. este se mantenía en los niveles salariales más bajos, y los
John comenzó a mostrar signos de insatisfac- cambios de humor de John se hicieron más dramáticos y
ción con la empresa en general, varios años atrás. prolongados.
Abiertamente, él ventilaba sus sentimientos en contra de Durante el proceso más reciente de evaluación del
casi todo lo que la empresa estaba haciendo o tratando desempeño, el gerente de John (un amigo suyo) incluyó
de hacer. Sin embargo, él no se quejaba de su situación un párrafo sobre la “falta de concentración”. Esto fue
140 Capítulo 4  •  Liderazgo y el gerente de proyectos

incluido debido a las numerosas observaciones formula- y capacidad significaba recompensas y ascensos para los
das por los compañeros de John. El asunto ya no se podía involucrados. Sin embargo, debido a que John todavía no
esconder bajo la alfombra. John se puso furioso por la había completado sus estudios como lo había planeado,
información de la revisión y se negó a acusar recibo de sus promociones eran más difíciles de conseguir y no se
su evaluación de desempeño. Su actitud hacia sus compa- producían tan rápidamente como las de sus amigos. Las
ñeros de equipo se hizo muy negativa. Exigió saber quién diferencias salariales y la responsabilidad comenzaron su
había hablado mal de él, y su rendimiento en el trabajo expansión a un ritmo rápido. John empezó a estar menos
disminuyó a prácticamente nada. satisfecho.
Esta gran empresa se estructuró como una organiza-
Análisis del problema ción funcional. Todos los ingenieros mecánicos le repor-
taban a un gerente de departamento funcional. El gerente
Es evidente que John no ha sido feliz. Para entender por
era consciente de la situación y convenció a John para vol-
qué, la historia de su empleo en esta compañía necesita
ver por su título durante la noche. Aunque John tenía bue-
examinarse con mayor detalle. Del grupo de compañeros
nas intenciones, nunca había tenido el tiempo suficiente
de trabajo que se inició con él hace 15 años, todos tenían
para completar su grado. Como los amigos de John avan-
antecedentes y capacidades similares. Un grupo de ocho
zaron rápidamente en la corporación, sus coches y casas
personas que tenían todos unos 22 años y acababan de
también se hicieron más grandes y mejores. La esposa de
salir de la universidad, John fue la única excepción a este John lo presionó para mantenerse al día con los demás, y
patrón, ya que aún necesitaba dos años más de estudio también compró una casa más grande. Este movimiento
para finalizar su carrera de ingeniería. Todos eran solteros ocasionó que John estuviera viviendo por encima de sus
y hacían buen dinero en sus puestos de trabajo. La dife- medios y su seguridad financiera se amenazó.
rencia en los niveles salariales entre un ingeniero asociado Hasta este punto, John había justificado en su mente
y un dibujante era pequeña. La figura 4.5 muestra la clasi- que las políticas de la corporación y su gerente funcional
ficación de grado salarial en esta corporación. eran la fuente de todos sus problemas. John abiertamente
Este grupo jugaba sóftbol todos los miércoles, pes- daría rienda suelta a su ira contra este gerente. A conti-
caban juntos los fines de semana y cazaban alces durante nuación, ocurrió un cambio drástico en la corporación. La
una semana cada invierno. Se formaron lazos y amista- compañía cambió a un entorno de equipo de proyectos y
des para toda la vida. Uno por uno del grupo comenzó a se eliminó el manejo funcional. Esto significaba que John
casarse y formar familia. Incluso se turnaban para ponerse reportaba ahora directamente a sus amigos.
de pie el uno al otro en las bodas. Las esposas y los hijos A pesar de que John ahora trabajaba para sus ami-
se convirtieron en grandes amigos, y los viajes de pesca gos, la política de la compañía era todavía restrictiva y las
fueron sustituidos por asados familiares. promociones no llegaban tan rápido como él esperaba. El
Mientras tanto, las cosas en el trabajo iban muy líder del equipo le dio a John frecuentes premios en efec-
bien. Todos estos amigos y compañeros de trabajo tenían tivo y un reconocimiento en un intento por motivarlo. El
una muy fuerte ética de trabajo y habilidades superiores al ego de John se calmó por un corto tiempo, pero esto no
promedio. A todos les gustaba su trabajo y no les impor- resolvía el problema real. John quería dinero, poder y res-
taba trabajar horas extras. Esta combinación de esfuerzos peto, y no estaba satisfecho porque los que lo rodeaban

Vice presidente
Director
G 26 Gerente de ingeniería
Empleados G 24 Ingeniero de staff sénior
asalariados Brecha
G 22 Ingeniero de staff
salarial
G 20 Ingeniero sénior grande
G 18 Ingeniero
G 16 Ingeniero asociado
G 14 Dibujante sénior Brecha salarial pequeña
Empleados
por hora G 12 Dibujante
G 10 Dibujante asociado

FIGURA 4.5  Clasificaciones de salario en esta corporación


(continúa)
Estudio de caso 4.3 141

tenían más. A pesar de que era bueno en lo que hacía, no La opción de no hacer nada sería la salida más fácil
era mucho para él. No parecía tener la capacidad innata para el líder del equipo, pero esto no resolvería ningún
para convertirse en un líder a través del conocimiento problema. Esta decisión equivaldría a enterrar la cabeza
experto o de los rasgos de personalidad. Además, debido en la arena y esperar a que el problema desapareciera
a la falta de un título de ingeniero, no podía alcanzar el por sí solo. Sorprendentemente, esta fue una sugerencia
poder a lo largo del tiempo desde el grado. Por ahora, la común de los miembros del equipo. No parecía haber una
actitud de John se había deteriorado hasta el punto que esperanza de que el problema se pasara por alto, como lo
era perjudicial para el equipo y algo había que hacer. El había sido en el pasado, y que John pudiera simplemente
líder del equipo tenía que ayudar a John, pero él también aceptar la situación. Con esta opción, la única persona que
tenía que cuidar del bienestar del equipo. tendría que comprometerse era John.
Esta historia detallada es relevante porque ayuda a La segunda opción de pasar por alto la política de la
explicar cómo la actitud de John se deterioró lentamente empresa y promocionar a John a un nivel superior sería
durante un tiempo. Al inicio de su carrera, John era capaz muy difícil de vendérsela a la gerencia. John fue promo-
de sentirse a la par de sus compañeros. Cuando todo el vido recientemente a un grado de sueldo 18 (sus amigos
mundo era joven y básicamente igual, sabía que tenía el eran ahora 24 y 26). Esta promoción se logró gracias a los
respeto de sus amigos y compañeros de trabajo. Esto le esfuerzos concertados de sus amigos y el líder del equipo.
permitió a John disfrutar de su autoestima. Con el paso Las posibilidades de convencer a la gerencia para aprobar
del tiempo se dio por vencido en su intento de obtener un nuevo ascenso tan rápido eran extremadamente bajas.
el título universitario y perdió algo de su autoestima. A Por otra parte, si el líder del equipo tuviera un éxito en
medida que la brecha creció entre las posiciones en la convencer a la gerencia sobre la promoción de John, ¿cuá-
empresa de sus amigos y la suya, se dio cuenta de que les serían los beneficios a largo plazo? John aún no estaría
había perdido la estima de los demás. Por último, cuando en el mismo nivel que sus amigos y no estaría satisfecho
se excedió con la casa más grande, incluso su seguridad por mucho tiempo. Lo bueno era que era probable que esto
básica fue amenazada. Es difícil mantener un buen nivel fuera solo una solución temporal al problema. Después de
de satisfacción en esta situación. El problema ahora era que el brillo de la promoción desapareciera, John volvería
molesto para el equipo y comenzó a disminuir sus esfuer- a creer que sus esfuerzos exceden sus recompensas. Sería
zos y resultados. Una presión excesiva se colocó sobre el bueno para creer que esta solución sería eliminar el pro-
equipo, y las amistades trataron de proteger a John de las blema, pero la historia parece indicar lo contrario.
consecuencias de sus acciones. La tercera opción, hablar con John para volver a la
El líder del equipo tenía que tratar de resolver este universidad y terminar su carrera de ingeniería sería la
problema. El reto era importante: el líder tenía que tratar mejor solución al problema, pero probablemente la menos
de satisfacer las necesidades del individuo, las necesidades probable que se produjera. Si John pudiera completar sus
del grupo y las necesidades de la tarea. Cuando las nece- estudios, no habría políticas de la empresa que obstruyeran
sidades individuales de John no podían satisfacerse, el el paso. Él entonces podría competir en igualdad de condi-
ambiente del grupo y la realización de tareas se afectaban. ciones. Esto le permitiría recibir justificadamente su avance
Era hora de que el líder del equipo actuara con decisión y y recuperar su autoestima. Si no recibe la recompensa que
se acercara a la alta gerencia con una solución al problema. él siente que se merece, tendría que mirar su rendimiento y
mejorar sus debilidades, sin caer de nuevo en la misma vieja
Posibles líneas de acción excusa. Esta solución parece colocar a John de nuevo en el
El líder del equipo pensó mucho en sus opciones. Debido camino hacia la satisfacción en el trabajo, pero el problema
a las amistades y relaciones personales, sabía que no podía radica en que se había intentado varias veces antes, sin
tomar esta decisión a la ligera. Decidió hablar individual- éxito. ¿Por qué sería diferente esta vez? ¿Debería la empresa
mente con los miembros del equipo que eran amigos cer- seguir intentando este enfoque sabiendo que él no volvería
canos de John y luego determinar la mejor solución para a estar satisfecho y producir un efecto negativo grave en el
presentársela a la alta gerencia. equipo? Aunque esta tercera solución podría producir el
Después de hablar con los miembros del equipo, el final feliz que todo el mundo quiere ver en una película, no
líder se decidió por la siguiente lista de opciones: tendría una muy alta probabilidad de éxito.
La cuarta opción, reubicar a John en un equipo dife-
1.
No hacer nada.
rente sería un intento por romper los lazos de competencia
2.
Pasar por alto la política de la empresa y promocio-
que John sentía con sus amigos y compañeros de equipo. Si
nar a John.
se tomara esta opción, John podría comenzar con borrón
3.
Hablar con John para volver a la universidad.
y cuenta nueva en un equipo diferente, y se le permitiría
4.
Reubicar a John en un equipo de proyecto dife-
guardar las apariencias con sus amigos. Podría hablarles
rente.
de sus muchos logros y el gran trabajo que está haciendo,
5.
Terminar el contrato de John.
142 Capítulo 4  •  Liderazgo y el gerente de proyectos

mientras se queja de que su “nuevo” jefe está frenándolo. tan severa. Además, dado que esta opción cortaría las rela-
Aunque esto podría considerarse una “cortina de humo”, ciones sociales para todos los involucrados y generaría culpa
podría darle a John la oportunidad de mirarse desde una en todos los miembros restantes del equipo, lo cual produ-
nueva perspectiva. Si él explota sus capacidades, estaría en ciría aún mayor deterioro del equipo, esta opción se toma-
condiciones de lograr la estima de los demás y, finalmente, ría solamente en caso de que las demás hubieran fallado y la
su autoestima. El equipo lo consideraría una victoria, ya situación se tornara insegura para los involucrados.
que les permitiría a todos mantener una buena relación
social mientras se lavan las manos con los problemas pro- Preguntas
fesionales. Esta opción hace impersonal la situación. Debe
1. Como líder del equipo, usted ha sopesado los pros y
quedar claro, sin embargo, que esta solución no haría nada
los contras de las cinco opciones y ha preparado una
por resolver el verdadero problema. A pesar de que le per-
mitiría a John centrar su insatisfacción en alguien diferente presentación ante la gerencia sobre la forma de abor-
de sus amigos y darle un nuevo comienzo para impresionar dar este problema. ¿Cuál es su propuesta?
a sus nuevos compañeros de trabajo, ¿quién puede afirmar 2. Considere cada una de las opciones y argumente la
que el problema no podría resurgir? defensa de cada opción.
La quinta opción, terminar el contrato de John, sería 3. ¿Qué comportamientos específicos de liderazgo,
desagradable para todos los involucrados. No hay nada mencionados en este capítulo, son los más relevantes
hasta este punto que haga que John mereciera una acción para abordar y resolver los problemas con John?

Ejercicios en internet
1. Seleccione a una persona que se dice líder de negocios. Busque d. Jefes de grupos funcionales
en la web información sobre este individuo. ¿Qué elementos de e. Todos son interesados del proyecto
información llevan a considerar a esta persona como un líder?
2. El liderazgo efectivo implica todo lo siguiente, excepto:
2. Ingrese en el sitio web www.debian.org/devel/leader y evalúe el
papel del líder del proyecto Debian. ¿Qué pasa con los deberes a. Gerencia de sí mismo a través de la gerencia de
y los antecedentes del responsable del proyecto que nos permite tiempo personal, manejo del estrés y otras actividades
verlo como el líder de este proyecto? b. Gerencia de los miembros del equipo a través de la mo-
3. Knut Yrvin actúa como el líder del equipo para sustituir los sis- tivación, delegación, supervisión y desarrollo de equipos
temas operativos comerciales con tecnología basada en Linux en c. Mantenimiento de un estricto control de todos los re-
las escuelas de Noruega (el proyecto se denomina “Skolelinux”). cursos del proyecto y suministro de información a los
Lea su entrevista en http://lwn.net/Articles/47510/. ¿Qué pistas miembros del equipo solo cuando sea necesario
encuentra en esta entrevista sobre su visión de la tarea de líder d. El empleo y la utilización de campeones de proyectos
del proyecto y cómo lidera el proyecto? donde ellos puedan beneficiar al proyecto
4. Los campeones de proyectos pueden mejorar sustancialmente 3. Un gerente de proyectos se reunirá con su equipo por
las posibilidades de éxito de este, pero también pueden tener primera vez y quiere crear el entorno adecuado en el que
efectos negativos. Por ejemplo, los proyectos defendidos por un se desarrollen positivamente las relaciones. ¿Cuál de las
miembro bien conocido de la organización son muy difíciles siguientes pautas debe utilizar para crear una asociación
de descartar, incluso cuando están fracasando. Lea el artículo efectiva con su equipo?
publicado en www.computerworld.com/s/article/78274/Blind_ a. El derecho a decir no
Faith?taxonomyId=073 en “Blind Faith. ¿Cuáles son algunos b. Responsabilidad conjunta
de los peligros de la defensa excesiva por los miembros de alto c. Intercambio de propósito
rango de una organización, según el artículo? d. Honestidad absoluta
e. Todas son necesarias para crear una asociación
Preguntas de ejemplo del examen para la certificación
PMP 4. Joan está muy motivada para crear una experiencia positiva
del proyecto para todos los miembros de su equipo y refle­
1. El gerente de proyectos pasa mucho tiempo en la comu- xiona sobre algunos de los enfoques que puede tomar para
nicación con los interesados del proyecto. ¿Cuál de las emplear el liderazgo, en lugar de simplemente gerenciar el
siguientes es un ejemplo de interesados del proyecto? proceso. ¿Cuál de los siguientes es un ejemplo de una prác-
a. Alta gerencia tica de liderazgo que ella pueda utilizar?
b. Clientes a. Centrarse en los planes y presupuestos
c. Miembros del equipo del proyecto b. Tratar de mantener el status quo y promover el orden
Notas 143

c. Animar a la gente a superar los obstáculos y mostrar Respuestas: 1 e—Recuerde que los interesados se definen como
iniciativas personales cualquier grupo, ya sea interno o externo, que puede afectar
d. Mantener un marco de tiempo a corto plazo y evitar la ejecución del proyecto; 2 c—El liderazgo requiere permitir
riesgos innecesarios que los trabajadores tengan flexibilidad, proporcionándoles
toda la información pertinente y comunicándoles el estado del
5. Frank ha estado aprendiendo sobre el efecto de la in-
proyecto y otra información pertinente; 3 e—Todas son carac-
teligencia emocional en su capacitación para liderar su
terísticas necesarias para crear una asociación entre el gerente
proyecto con efectividad. ¿Cuál de los siguientes no es
de proyectos y el equipo; 4 c—Animar a la gente para superar
un ejemplo del tipo de inteligencia emocional que puede
los obstáculos es un componente clave del liderazgo, en lugar de
ayudarle a obtener mejores resultados?
una filosofía de gerencia; 5 d—Aunque una orientación hacia
a. Autoconciencia y autorregulación
los resultados puede ser un elemento útil en el conjunto de ha-
b. Motivación
bilidades de un líder de proyectos, no es un ejemplo de la in-
c. Habilidades sociales
teligencia emocional, que a menudo se manifiesta a través de la
d. Orientación hacia los resultados (trabajar para hacer
construcción de relaciones con los demás.
el trabajo)

Notas
1. “Saving the river in Fes.” (2009, 8 de mayo). http://moroc- and key project manager competences,” Project Management
candesign.com/saving-the-river-in-fes; Danko, J. (2010). Journal, 41(2): 5–20.
“Mysticriver,” PMNetwork, 24(7): 56–59; http://riadzany. 12. Kouzes, J. M., and Posner, B. Z. (1995). The Leadership
blogspot.com/2008/12/fez-tanneries-aziza-chaouni-re- Challenge. San Francisco, CA: Jossey-Bass.
sponds.html. 13. Pettersen, N. (1991). “What do we know about the effectiv­e­­
2. Kim, W. C., and Mauborgne, R. A. (1992, julio-agosto). project manager?” International Journal of ProjectManagement,
“Parables of leadership,” Harvard Business Review, p. 123. 9: 99–104. Véase también Javidan, M., andDastmachian, A.
3. Posner, B. Z. (1987). “What it takes to be a good project (1993). “Assessing senior executives:The impact of context
manager,”Project Management Journal, 18(1): 51–54; Pinto, J. on their roles,” Journal of AppliedBehavioral Science, 29, 328–
K.,Thoms, P., Trailer, J., Palmer, T., and Govekar, M. (1998). 42; DiMarco, N., Goodson, J.R., and Houser, H. F. (1989).
Project Leadership: From Theory to Practice. NewtownSquare, “Situational leadership in theproject / matrix environment,”
PA: Project Management Institute; Slevin, D. P., andPinto, J. Project Management Journal,20(1): 11–18; Müller, R., and
K. (1988). “Leadership, motivation, and the projectmanager,” Turner, J. R. (2007). “Matching the project manager’s lead-
in Cleland, D. I., and King, W. R. (Eds.), ProjectManagement ership style to project type,”International Journal of Project
Handbook, 2nd ed. New York: Van NostrandReinhold, pp. Management, 25: 21–32;Turner, J. R., and Müller, R. (2005).
739–70; Geoghegan, L., and Dulewicz, V.(2008). “Do project “The project manager’s leadership style as a success factor on
managers’ competencies contribute toproject success?” Project projects: A literature review,” Project Management Journal,
Management Journal, 39(4): 58–67. 36(2): 49–61.
4. Pinto, J. K., and Kharbanda, O. P. (1997). Successful Project 14. Einsiedel, A. A. (1987). “Profile of effective project manag-
Managers. New York: Van Nostrand Reinhold. ers,” Project Management Journal, 18(5): 51–56.
5. Block, P. (1993). Stewardship: Choosing Service over Self- 15. Medcof, J. W., Hauschildt, J., and Keim, G. (2000). “Realistic
Interest. San Francisco, CA: Berrett-Koehler Publishers. criteria for project manager selection and development,”
6. Verma, V. K. (1996). Human Resource Skills for the Project Project Management Journal, 31(3): 23–32.
Manager. Newtown Square, PA: Project Management 16. Hannon, E. (2010, 27 de septiembre). “Problems fuel doubts
Institute. about Commonwealth Games.” www.npr.org/templates/story/
7. Yukl, G. (2002). Leadership in Organizations, 5th ed. story.php?storyId=13014949; Swanson, S. (2008).“Worldview:
UpperSaddle River, NJ: Prentice Hall; Daft, R. L. (1999). New Delhi,” PMNetwork, 22(12): 58–64;Lakshman, N. (2007,
LeadershipTheory and Practice. Orlando, FL: Harcourt; March 14). “The miracle-worker of theDelhi Metro.” www.
Kouzes, J. M.,and Posner, B. Z. (1995). The Leadership rediff.com/money/2007/mar/14bspec.htm; www.muraleed-
Challenge. SanFrancisco, CA: Jossey-Bass. haran.com/legends_sreedharan.html.
8. Slevin, D. P. (1989). The Whole Manager. New York: 17. Thoms, P., and Pinto, J. K. (1999). “Project leadership:A
AMACOM. question of timing,” Project Management Journal, 30(1):19–
9. Yukl, G. (2002). Leadership in Organizations, 5th ed. Upper 26. See also Das, T. K. (1986). The Subjective Side of Strategy
Saddle River, NJ: Prentice Hall. Making: Future Orientations and Perceptions of Executives.
10. Zimmerer, T. W., and Yasin, M. M. (1998). “A leadership- New York: Praeger; Das, T. K. (1991). “Time: The hidden
profile of American project managers,” Project Management dimension in strategic planning,” Long Range Planning, 24:
Journal, 29(1): 31–38. 49–57; Thoms, P., and Greenberger, D. B.(1995). “The rela-
11. Goleman, D. (1998). “What makes a leader?” Harvard Business tionship between leadership and time orientation,”Journal of
Review, 76(6): 92–102; Clarke, N. (2010). “Emotional intel- Management Inquiry, 4: 272–92.
ligence and its relationship to transformational leadership
144 Capítulo 4  •  Liderazgo y el gerente de proyectos

18. Schon, D. A. (1967). Technology and Change. New York:Delacorte; 27. Hartman, F. (2000). Don’t Park Your Brain Outside.
Maidique, M. A. (1980, Winter). “Entrepreneurs, champions, and Newtown Square, PA: Project Management Institute.
technological innovation,” Sloan Management Review, 21: 59–76. 28. Silver, D. (2009). “Abroad spectrum,” PM Network, 23(1):
19. Peters, T. A. (1985, 13 de mayo). “A passion for excellence,” 62–68.
Fortune, pp. 47–50. 29. Ayas, K. (1996). “Professional project management:
20. Meredith, J. A. (1986). “Strategic planning for factory automa- A shift towards learning and a knowledge creating
tionby the championing process,” IEEE Transactions onEngi- structure,”International Journal of Project Management, 14:
neering Management, EM-33(4): 229–32; Pinto, J. K., and Slevin, 131–36;Statement of Bruce Carnes, Chief Financial Officer,
D. P. (1988). “The project champion: Key to implementation United States Department of Energy, Before the Committee
success,” Project Management Journal, 20(4): 15–20;Bryde, on Science—U.S. House of Representatives—on the FY
D. (2008). “Perceptions of the impact of project sponsorship 2003 Budget Request for the U.S. Department of Energy.
practices on project success,” International Journal of Project (2002, 13 de febrero). Véase también www.nap.edu/open-
Management, 26: 800–809; Wright, J. N. (1997).“Time and bud- book/0309089093/html/82-91.htm.
get: The twin imperatives of a project sponsor,”International 30. Ayas, K. (1996), ibid.
Journal of Project Management, 15: 181–86. 31. Hoffman, E. J., Kinlaw, C. S., and Kinlaw, D. C.
21. Onsrud, H. J., and Pinto, J. K. (1993). “Evaluating correlates (2002).“Developing superior project teams: A study of
of GIS adoption success and the decision process of GIS the characteristics of high performance in project teams,”
acquisition,”Journal of the Urban and Regional Information in Slevin, D. P., Cleland, D. I., and Pinto, J. K. (Eds.), The
Systems Association, 5: 18–39. Frontiers of Project Management Research. Newtown Square,
22. Chakrabarti, A. K. (1974). “The role of champion in product PA: PMI, pp. 237–47; Kezbom, D. (1994). “Self-directed team
innovation,” California Management Review, xvii(2):58–62. and thechanging role of the project manager.” Proceedings
23. Royer, I. (2003). “Why bad projects are so hard to kill,” of the Internet 12th World Congress on Project Management,
Harvard Business Review, 81(2): 48–56; Pinto, J. K., and Slevin, Oslo, pp. 589–93.
D. P. (1988). “The project champion: Key to implementation 32. Wideman, R. M., and Shenhar, A. J. (2001). “Professional and
success,” Project Management Journal, 20(4): 15–20. personal development management: A practical approach
24. Thamhain, H. J. (1991). “Developing project management to education and training,” in J. Knutson (Ed.), Project
skills,” Project Management Journal, 22(3): 39–44; Pressman, Management for Business Professionals: A Comprehensive
R. (1998, enero-febrero). “Fear of trying: The plight ofrookie Guide. New York: Wiley, pp. 353–83; Wideman, R. M.(1998).
project managers,” IEEE Software, pp. 50–54. “Project teamwork, personality profiles and the population
25. Bennis, W. (2001). “The end of leadership: Exemplary leader- at large: Do we have enough of the right kind of people?”
ship is impossible without full inclusion, initiatives, and co- Presentation at the Project Management Institute’s Annual
operation of followers,” Organizational Dynamics, 28. Seminar/Symposium, Long Beach, CA.
26. Kouzes, J. M., and Posner, B. Z. (1995). The Leadership 33. Thoms, P. (2004). Driven by the Future: Time Orientation in
Challenge. San Francisco, CA: Jossey-Bass. Leadership. New York: Praeger.
CAPÍTULO

5
Gerencia del alcance

Contenido del capítulo


PERFIL DE PROYECTO 5.5 SISTEMAS DE CONTROL
El vehículo expedicionario de combate Gerencia de la configuración
INTRODUCCIÓN 5.6 CIERRE DEL PROYECTO
5.1 DESARROLLO CONCEPTUAL Resumen
Declaración del trabajo Términos clave
5.2 DECLARACIÓN DEL ALCANCE Preguntas para discusión
Estructura de desglose del trabajo Problemas
Propósitos de la estructura de desglose del trabajo Estudio de caso 5.1 Frontera virtual de Boeing
Estructura de desglose de la organización Estudio de caso 5.2 Proyecto del tren de alta velocidad de
Matriz de asignación de responsabilidades California
PERFIL DE PROYECTO Estudio de caso 5.3 Gerencia de proyectos en Dotcom.com
Definición de un paquete de trabajo del proyecto Estudio de caso 5.4 Caso clásico: el Ford Edsel
Ejercicios en internet
5.3 AUTORIZACIÓN DE TRABAJO
Preguntas de ejemplo del examen para la Certificación PMP®
5.4 REPORTES DEL ALCANCE Ejercicios con MS Project
INVESTIGACIÓN DE GERENCIA DE PROYECTOS EN Proyecto integrado. Desarrollo de la estructura de desglose del
SÍNTESIS trabajo (EDT)
Tecnología de la información (IT) en el proyecto Notas
“Marchas de la muerte”: ¿qué está pasando aquí?

Objetivos de aprendizaje
Al finalizar el capítulo, el estudiante estará en capacidad de:
1. Comprender la importancia de la gerencia del alcance para el éxito del proyecto.
2. Comprender la importancia de desarrollar la declaración del alcance.
3. Elaborar una estructura de desglose del proyecto.
4. Desarrollar una matriz de asignación de responsabilidades en un proyecto.
5. Describir los papeles de la gerencia de configuración y cambios, para evaluar el alcance del proyecto.

145
146 Capítulo 5  •  Gerencia del alcance

CONCEPTOS BÁSICOS DE LOS FUNDAMENTOS PARA LA GERENCIA DE PROYECTOS


(PROJECT MANAGEMENT BODY OF KNOWLEDGE, PMBOK® GUIDE, 5A. EDICIÓN)
CUBIERTOS EN ESTE CAPÍTULO
1. Planeación del alcance (PMBOK sección 5.1)
2. Recopilar requisitos (PMBOK sección 5.2)
3. Definir el alcance (PMBOK sección 5.3)
4. Crear la EDT (PMBOK sección 5.4)
5. Validar el alcance (PMBOK sección 5.5)
6. Controlar el alcance (PMBOK sección 5.6)

PERFIL DE PROYECTO

Caso—El vehículo expedicionario de combate


Una de las decisiones presupuestarias del congreso más complejas y difíciles en años, finalmente se dio debido a: la
determinación del destino del vehículo expedicionario de combate (Expeditionary Fighting Vehicle: EFV) del Cuerpo de
Infantes de Marina. En razón de los numerosos retrasos, pruebas, aprobaciones condicionales y repetición de pruebas,
el EFV no había sido ajeno a la controversia. Aunque el EFV fue fuertemente defendido por funcionarios de alto nivel
en el Pentágono, un ejército de críticos citó el pobre desempeño del vehículo en las pruebas y que sus costos continua­
ban incrementándose. Como señaló un periodista: “Después de 10 años y una inversión de 1,700 millones de dólares, el
Cuerpo de Infantes de Marina tiene un nuevo vehículo anfibio: una nave que se descompone en promedio una vez cada
4 horas y media, tiene fugas y a veces se desvía de su curso.” La gran pregunta es: ¿cómo se llegó a ese punto con lo que
se vio, durante muchos años, como uno de los mayores programas prioritarios de adquisición de la Marina?
El programa EFV se inició hace más de 20 años cuando este vehículo anfibio blindado fue diseñado para
reemplazar el vehículo anfibio de asalto de la década de 1970. La finalidad de los vehículos como el EFV es pro­
porcionar apoyo blindado en las primeras etapas de asalto anfibio a costas enemigas. El EFV fue diseñado para
saltar desde un buque de asalto de la Armada, y se mueve por sus propios medios a 20 millas por hora (mph) en la
superficie del agua en distancias de hasta 25 millas, mientras transporta un pelotón de rifle de hasta 17 infantes
de marina, atraviesa playas hostiles y opera en tierra. El EFV fue armado moderadamente y llevaba un cañón de 30
mm en una torreta de poder ofensivo. El EFV a menudo fue descrito como una variante del vehículo de combate
Bradley de la Infantería de Marina.
El EFV comenzó como un programa de adquisición de tecnología de última generación para el Departamento
de Defensa (DoD). Después de una fase de exploración de concepto para determinar la viabilidad del proyecto
que se inició en 1988, el proyecto entró en una fase de definición del programa y de reducción del riesgo en la
que se consideró como “un programa modelo de adquisición de defensa “, y ganó dos premios del Departamento
de Defensa por su gerencia exitosa en tecnología y costo. El contrato inicial fue adjudicado a General Dynamics
Corporation en junio de 1996, para servicios completos de diseño e ingeniería y esta empresa obtuvo un segundo
contrato para la fase de demostración y desarrollo del sistema (system development and demonstration: DDS) del
programa, en julio de 2001. Durante esta etapa crítica, todo el complejo de ingeniería, desarrollo de sistemas y
funcionalidad del programa deben demostrarse con éxito. Tal vez insensatamente, General Dynamics presupuestó
solo 27 meses para la verificación del sistema y las pruebas.
Por demasiado ambicioso, este calendario pronto se convirtió en un problema para General Dynamics y el EFV,
pues una serie de problemas técnicos comenzaron a salir a flote. Se añadieron dos años a la fase de DDS, cuando se evi­
denció que el concepto del EFV estaba acosado con numerosos problemas imprevistos. En diciembre de 2004, las prue­
bas del prototipo EFV mostraron más problemas. Las pruebas detectaron una falla grave en el sistema computarizado
principal del vehículo, la cual producía que la dirección del vehículo se congelara. Los sistemas hidráulicos que acciona­
ban los alerones de la proa del vehículo, instalados para que el EFV se desempeñaran mejor en el mar, comenzaron a
fallar. El EFV fue pensado originalmente para funcionar durante un promedio de 70 horas entre fallas de la misión, pero
a causa de los numerosos problemas de fiabilidad, los infantes de marina redujeron esta cifra a 43.5 horas. A raíz de
estas pruebas del prototipo, se añadieron otros dos años al cronograma de desarrollo del programa.
El 2006 no fue un buen año para el EFV, porque fue sometido a un proceso de evaluación operativa clave, el
cual constaba de una serie de pruebas para demostrar que podría satisfacer los requisitos de rendimiento y estaba
listo para su producción. El desempeño del EFV fue desastroso, porque experimentó numerosos problemas del sis­
tema, avería y fallas en su evaluación de fiabilidad. Durante las pruebas, los vehículos eran capaces de operar en
promedio sólo 4.5 horas entre fallas, y tomaron casi 3.5 horas de mantenimiento correctivo por cada hora de funcio­
namiento. Poca fiabilidad arrojó en 117 misiones fallidas y 645 actos de mantenimiento no programado durante las
Perfil de proyecto 147

Stocktrek Images, Inc. / Alamy

FIGURA 5.1  El vehículo expedicionario de combate (EFV)

pruebas. La fiabilidad del EFV fue tan pobre que completó con éxito solo 2 de 11 pruebas de intentos anfibios, 1 de
10 pruebas de tiro, y ninguna de las 3 pruebas de movilidad en tierra. Otros problemas incluían: los prototipos tenían
un sobrepeso de casi una tonelada; la visibilidad era limitada y eran tan ruidosos que se aconsejaba al conductor el
uso de tapones para los oídos, mientras estuviera en su sillar, a pesar de que al tenerlos puestos se hacía casi impo­
sible comunicarse con el comandante del EFV. De hecho, tan pobremente se comportó el EFV durante la evaluación
operativa que la Infantería de Marina anunció que iban a regresar el diseño a la mesa de dibujo, con el objetivo de
completar una nueva fase de SDD en 2011, ocho años retrasados respecto a la programación original.
Mientras tanto, los costos del programa seguían subiendo. Cuando el EFV se concibió, la Infantería de Marina pla­
neaba comprar 1,025 de ellos a un costo total de 8,500 millones de dólares. Posteriormente, el Departamento de Defensa
estimó el costo del programa en más de 14,000 millones de dólares, mientras que los infantes de marina habían recortado
su orden a 573 vehículos. En efecto, aun suponiendo que las cifras finales se mantuvieran, el costo del EFV había aumen­
tado de 8.3 millones de dólares por vehículo a un poco más de 23 millones de dólares. En general, el Pentágono estimó que
había gastado 2,900 millones en el programa de (I+D) y los costos de prueba antes de comprar un solo vehículo.

¿Arma incorrecta para la guerra equivocada?


La letanía constante de fallas asociadas con el desarrollo del EFV dio lugar a algunas de las preguntas fundamen­
tales sobre el propósito detrás del desarrollo del vehículo. Los críticos argumentaron que el EFV simplemente no
(continúa)
148 Capítulo 5  •  Gerencia del alcance

tenía un papel significativo en la moderna misión del Cuerpo de Infantes de Marina. Entre sus preocupaciones
estaban los siguientes puntos:
• La guerra moderna no ofrece opciones para “asaltar las playas,” como prevé el viejo modelo de Infantería de
Marina. Conflictos de bajo nivel, regionales o urbanos hacen de la necesidad de asalto anfibio un anacronismo.
Como Laura Peterson, una defensora de Contribuyentes por el Sentido Común (Taxpayers for Common Sense),
sugirió: “Esto no es solo pelear la última guerra, es pelear las guerras del siglo pasado.”
• El avance en la tecnología de misiles de crucero vuelve obsoletos los modelos “25 millas mar adentro.”
Cuando el EFV se concibió, se creía que la Marina podría proteger sus buques al permanecer en el horizonte
y desembarcar EFV desde esa distancia para asaltar las costas enemigas. Los críticos sostuvieron que los nuevos
misiles tienen un alcance de más de 100 millas, lo cual los vuelve vulnerables a los ataques a los EFV o a los
buques de la Armada, si fuesen a seguir el modelo original.
• El fondo plano del EFV, necesario para el transporte de buque a tierra, lo hace extremadamente vulnerable a las car­
gas en forma de artefactos explosivos improvisados (AEI), que se utilizaron con eficacia en Iraq y Afganistán. General
Dynamics argumentó que el rediseño de la parte inferior del vehículo podría alterar sus características anfibias.

Varios funcionarios de alto nivel del Pentágono, incluido el comandante de la Infantería de Marina, respecto
al EFV, argumentaban que la misión “expedicionaria” de la Marina permanecería viva y vigente en el futuro previ­
sible. Creían que el EFV era un elemento clave en el despliegue y capacidad de sorpresa de la Infantería de Marina.
Sin embargo, otros funcionarios gubernamentales de alto rango, entre ellos el secretario de Defensa, dieron solo
un apoyo tibio para continuar con el desarrollo y despliegue del EFV.
Las rondas finales de financiación comenzaron a limitar el dinero adicional para el EFV y a atar la capacidad de
General Dynamics y de los infantes de marina para demostrar una gran mejora en la fiabilidad y efectividad general
del sistema. Por ejemplo, en 2010 el Comité de Apropiaciones del Senado autorizó 38 millones de dólares para una
ronda más de pruebas y dejar a un lado 184 millones de dólares para cerrar el programa, en caso de que el vehículo,
otra vez, no pasara las pruebas. El hacha cayó finalmente a principios de 2011, cuando el secretario Gates envió su
anteproyecto de presupuesto al Congreso. Entre las víctimas de la cuchilla de reducción de costos estaba el programa
EFV. El programa siempre se había tambaleado en el borde, por lo que en el mundo de pequeños presupuestos del
Pentágono y con un incisivo programa de supervisión, tal vez era inevitable que el EFV finalmente cayera del borde. 1

INTRODUCCIÓN
El alcance de un proyecto es todo acerca de este, incluido el contenido del trabajo y los resultados esperados.
El alcance de un proyecto consiste en nombrar todas las actividades por realizar, los recursos consumidos y los
productos finales, incluidas las normas de calidad.2 El alcance incluye las metas, restricciones y limitaciones
de un proyecto. La gerencia del alcance es la función de control de un proyecto en términos de sus metas y
objetivos a través de los procesos de desarrollo conceptual, definición completa, ejecución y terminación; pro-
porciona los fundamentos sobre los que se basa todo el trabajo del proyecto y, por tanto, la culminación de la
planeación antes de su desarrollo. El proceso de gerencia del alcance consta de varias actividades distintas, todas
ellas basadas en la creación de un conjunto sistemático de planes para el proyecto que está por iniciar.
Emmitt Smith, ex corredor All-Pro de los Dallas Cowboy y miembro del Pro Football Hall of Fame,
atribuye su notable éxito a su compromiso con el desarrollo y trabajo para lograr una serie de metas perso-
nales. Le gusta contar la historia de sus días de escuela secundaria y cómo estos afectaron su éxito futuro.
Cuando Smith era un estudiante en la Escambia High en Pensacola, Florida, su entrenador de fútbol solía
decirle: “Es un sueño hasta que lo escribes. Entonces pasa a ser una meta.”
Para el éxito de un proyecto, la planeación integral puede marcar la diferencia. Hasta que un conjunto
detallado de las especificaciones se enumera y registra y un plan de control se desarrolla, un proyecto es solo un
sueño. En el sentido más general, la planeación del proyecto busca definir lo que hay que hacer, por quién y en qué
fecha, a fin de cumplir la responsabilidad asignada.3 Los proyectos se ejecutan a nivel operativo, en el que pueden
comenzar a desarrollarse, solo después de que una planeación sistemática — la gerencia del alcance — se produce.
Las seis actividades principales son: (1) desarrollo conceptual; (2) declaración del alcance; (3) autorización del tra-
bajo; (4) reporte del alcance; (5) sistemas de control; y (6) cierre del proyecto.4 Cada uno de estos pasos es clave en
la planeación integral y en el desarrollo del proyecto (véase el cuadro 5.1).
5.1  Desarrollo conceptual 149

CUADRO 5.1  Elementos de la gerencia del alcance del proyecto

1.  Desarrollo conceptual


Declaración del problema
Recopilación de información
Restricciones
Análisis de alternativas
Objetivos del proyecto
Declaración del trabajo
2.  Declaración del alcance
Criterios meta
Plan de gerencia
Estructura de desglose del trabajo
Línea base del alcance
Matriz de asignación de responsabilidades
3.  Autorización del trabajo
Requisitos contractuales
Consideración válida
Términos contratados
4.  Reporte del alcance
Costo, cronograma, estado de desempeño técnico
Curvas S
Valor ganado
Informes de varianza o excepción
5.  Sistemas de control
Control de la configuración
Control de diseño
Monitoreo de tendencias
Control de documentos
Control de adquisiciones
Control de especificaciones
6.  Cierre del proyecto
Registros históricos
Análisis posproyecto
Cierre financiero

En este capítulo se detallarán los componentes claves en la gerencia del alcance del proyecto. La meta
de la gerencia del alcance es maximizar la eficiencia a través de la formación y ejecución de planes o sistemas
que dejan lo mínimo posible al azar.

5.1  DESARROLLO CONCEPTUAL


El desarrollo conceptual es el proceso que se ocupa de los objetivos del proyecto mediante la búsqueda de
las mejores formas de cumplirlos.5 Para crear un sentido exacto del desarrollo conceptual de un proyecto, el
equipo de gerencia del proyecto debe recopilar datos y desarrollar varias piezas de información. Los pasos
clave de este proceso son:
• Declaración del problema o necesidad: la gerencia del alcance de un proyecto comienza con la declaración
de las metas: ¿por qué es la solución a una necesidad?, ¿cuál es el problema de fondo? y ¿qué se pretende
hacer con el proyecto? Por ejemplo, considere la siguiente declaración de necesidad de un estado ficticio:
150 Capítulo 5  •  Gerencia del alcance

Un informe de 2009 del Departamento de Salud del Estado de Maryland mostró que el municipio de
Freefield estaba clasificado entre los peores del estado, en mortalidad infantil (promedio de cinco años de
edad), bajo peso al nacer y nacimientos prematuros, rezago en la atención prenatal, padres solteros, emba-
razos de adolescentes y pobreza. Un informe de un grupo focal de salud del condado de Clarion identificó
patrones de mala comunicación entre las familias y los médicos del condado. Se requiere la recopilación y
difusión de información sobre las oportunidades de educación, apoyo y disponibilidad del servicio de partos,
así como la preparación de los nuevos bebés y la depresión posparto. El grupo focal indica que la Biblioteca
Pública Freefield podría ser un importante centro para la recolección esta información y la asignación de
recursos y materiales a los nuevos padres. Para responder adecuadamente a esta necesidad, la biblioteca
propone un programa de donaciones para financiar la ampliación de sus colecciones y programas, además
de la vinculación de la biblioteca con los proveedores locales de atención primaria de salud y con el Freefield
Memorial Hospital para atender a las mujeres en su embarazo y posparto y a sus hijos.
• Recopilación de información: el siguiente paso es la investigación para reunir todos los datos relevantes
para el proyecto. Un proyecto puede iniciarse efectivamente solo cuando el gerente del proyecto tiene una
clara la situación actual: fechas específicas objetivo, opciones de proveedores alternativos, grado de apoyo
de la gerencia del proyecto, y demás. En cualquier paso en el camino, los gerentes de proyectos deben evi-
tar la limitación de su búsqueda de información. Continuando con el ejemplo anterior, supongamos que,
como parte de nuestra recopilación de información, se identifican cinco fuentes potenciales de finan-
ciamiento en el Departamento de Salud de Maryland, las cuales serían una buena fuente de acceso a las
subvenciones. Además, la búsqueda de información nos dice que estas subvenciones son competitivas y
se deben presentar antes del final del año calendario en curso; podemos contar con el apoyo de figuras
políticas locales, como nuestro representante estatal y el comisionado del condado, entre otros. Toda esta
información debe tenerse en cuenta en la propuesta del programa y utilizarse para darle forma.
• Restricciones: a la luz de la declaración de metas, los gerentes de proyectos deben comprender las restricciones
que pudieran afectar el desarrollo del proyecto. Limitantes de tiempo, mermas de presupuesto y las demandas
del cliente pueden convertirse en graves obstáculos para el desarrollo del proyecto. Volviendo al ejemplo de
la subvención para la salud, algunas limitaciones que podrían afectar nuestra capacidad para desarrollar la
solicitud de donaciones en el tiempo serían la necesidad de encontrar un profesional médico para oficiar como
el principal autor del programa, la apropiación de los presupuestos estatales, el retiro de apoyo a iniciativas de
la comunidad como esta y la necesidad de una persona con conocimientos en la biblioteca dispuesta a servir
como colector principal de la información de atención de la salud prenatal y posnatal.
• Análisis de alternativas: los problemas, por lo general, ofrecen métodos alternativos para su solución.
En la gerencia de proyectos, el análisis de alternativas consiste primero en entender la naturaleza de la
declaración del problema y después trabajar para generar alternativas de solución. Este proceso tiene
dos funciones: proporcionarle al equipo una mejor comprensión de las características del proyecto y
ofrecer una variedad de enfoques para saber cómo debe llevarse a cabo el proyecto. Como resultado del
análisis de alternativas, una alternativa de desarrollo del proyecto puede resultar innovadora o novedosa.
Mediante el análisis de alternativas se le impide a una empresa iniciar un proyecto sin antes conocer sufi-
cientemente las opciones más eficientes o efectivas.
• Objetivos del proyecto: el desarrollo conceptual concluye con una declaración clara de los objetivos
finales del proyecto en términos de resultados, recursos necesarios y tiempo. Todos los pasos del pro-
ceso de desarrollo conceptual trabajan juntos como un sistema para, finalmente, afectar el resultado.
Cuando cada paso está bien realizado, los objetivos del proyecto se derivan lógicamente del análisis. En
nuestro ejemplo, los objetivos finales pueden incluir expectativas específicas, como la recepción de una
subvención de 100,000 dólares para apoyar los servicios, los costos de impresión y la celebración de
sesiones informativas y seminarios, con profesionales de la salud. Estos seminarios se iniciarán dentro
de 90 días por la administración de la subvención. Las colecciones de la biblioteca y suscripciones de
esta área deben mejorarse 25%. De este modo, el planteamiento del problema o necesidad es el catali-
zador que desencadena una serie de pasos en cascada para llevar el proyecto a sus efectos deseados.
El desarrollo conceptual comienza con el proceso de reducción de la complejidad general del proyecto a un
nivel más básico. Los gerentes de proyectos deben sentar las bases para sus proyectos de la forma más com-
pleta posible mediante la formulación de enunciados de los problemas en los que las metas y los objetivos
estén claramente definidos y sean fáciles de entender por todos los miembros del equipo.
Muchos de los proyectos que se inician con un entendimiento poco claro del problema que el proyecto
pretende abordar, exceden sus presupuestos y calendarios iniciales. En el nivel básico, este problema se debe a
5.1  Desarrollo conceptual 151

la vaga comprensión entre los miembros del equipo en cuanto a lo que el proyecto trata de lograr exactamente.
Por ejemplo, un reciente proyecto de tecnología de información (information technology: IT) se ha desarro-
llado con la meta vaga de “mejorar la facturación y las operaciones de almacenamiento de registros” en una gran
compañía de seguros. El departamento de IT interpretó que la meta para desarrollar el proyecto era proporcio-
nar una solución compleja que requiera varias pantallas interactivas, costoso reentrenamiento para los usuarios
y la generación de informes voluminosos. De hecho, la organización simplemente quería un enlace simplificado
entre las funciones de facturación y de reportes mensuales. Debido a que el problema fue articulado vagamente,
el departamento de IT creó un sistema costoso que era innecesariamente complejo. En realidad, la solución
óptima de un proyecto comienza con la creación de una declaración razonable y completa del problema, para
establecer la naturaleza del proyecto, su objetivo y un conjunto de metas concretas.
Una comprensión completa del problema se debe generar para que los proyectos tengan éxito, de
acuerdo con la finalidad para la cual fueron creados. Una parte fundamental de la declaración del problema
es el análisis de varias alternativas. Bloquearse muy temprano con “el mejor” enfoque para resolver un pro-
blema en un proyecto puede conducir a fallas más adelante.
Además, para ser efectivos, las declaraciones de los problemas deben ser simples y basarse en buscar
soluciones a necesidades claramente entendidas. Por ejemplo, una meta de proyecto claro, como “mejorar
la velocidad de procesamiento del computador en 20%” es mejor que la meta “aumentar significativamente
el rendimiento del computador.” Un conjunto de metas simples proporciona un punto de referencia que
el equipo puede consultar cuando ocurran los inevitables problemas a lo largo del desarrollo del proyecto.
Por otra parte, las metas vagas o excesivamente optimistas, como “mejorar la rentabilidad de las empresas,
manteniendo la calidad y la eficiencia de los recursos,” pueden sonar bien, pero no proporcionan puntos de
referencia claros para la resolución de problemas.

Declaración del trabajo


El impulso para comenzar un proyecto es a menudo el resultado de una declaración de trabajo. La declaración
de trabajo (statemente of work: SOW) es una narración detallada del trabajo requerido para un proyecto.6 Las
SOW contienen: la información sobre los objetivos claves del proyecto; una descripción breve y general de los
trabajos por realizar; los resultados esperados del proyecto y las financiaciones o limitaciones del cronograma.
Normalmente, en este último caso, es difícil presentar los requisitos de programación pasado un determinado
nivel “grave” que solo pueda incluir las fechas de inicio y terminación, así como los hitos principales.
Una SOW puede ser muy descriptiva, como una solicitud de propuesta (request for proposal: RFP ) del
Departamento de Defensa, para un nuevo dispositivo de comunicación de campo para el Ejército que “no
mida más de 15 pulgadas de largo por 15 pulgadas de ancho por 9 pulgadas de profundidad, no pese más de
12 libras, con un alcance de transmisión y recepción de 60 millas, que debe seguir funcionando después de
haber sido completamente sumergido en agua durante 30 minutos y no sufrir daños por caídas de alturas de
hasta 25 pies.” O puede ser relativamente general, simplemente especificando los requisitos finales de rendi-
miento sin especificaciones. El propósito de la declaración de trabajo es darle a la organización y al gerente de
proyectos una orientación específica tanto en los requisitos de trabajo, como en los tipos de resultados finales
solicitados una vez completado el proyecto.
Una declaración de trabajo es un componente importante del desarrollo conceptual, porque identifica
la necesidad dentro de la empresa o la oportunidad de una fuente externa, por ejemplo, el mercado comer-
cial. Algunos elementos de una SOW efectiva incluyen:
1. Introducción y antecedentes—una breve historia de la organización o la introducción a las necesidades
fundamentales que identifican la necesidad que da inicio al proyecto. La declaración del problema debe
ser parte de la introducción.
2. Descripción técnica del proyecto—un análisis, en términos claros, de las capacidades técnicas previstas
para el proyecto o de los problemas técnicos del proyecto que se pretenden resolver.
3. Línea temporal e hitos—un debate sobre el plazo previsto para la terminación y los entregables claves
del proyecto (resultados).
Una declaración de trabajo debe detallar las expectativas del cliente del proyecto, los problemas que el pro-
yecto pretende corregir o tratar y el trabajo necesario para completar el proyecto.
Por ejemplo, el Federal Geographic Data Committee ha desarrollado recientemente una declaración de
trabajo para la compra de servicios comerciales al gobierno o a la industria privada como contratista inde-
pendiente. La declaración de trabajo contiene lo siguiente:
152 Capítulo 5  •  Gerencia del alcance

1. Antecedentes—describen el proyecto en términos muy generales, explica por qué el proyecto se lleva a
cabo y cómo se relaciona con otros proyectos. Incluye, según se requiera, un resumen de los aspectos
legales o normativos aplicables y copias de materiales de apoyo en apéndices o referencias.
2. Objetivos—proporcionan un panorama general del proyecto y cómo se utilizarán los resultados o pro-
ductos finales.
3. Ámbito de aplicación—cubre el alcance general del trabajo que ejecutará el contratista.
4. Las tareas o requisitos—describen el trabajo detallado y los requisitos de gerencia; también explican
con mayor precisión lo que se espera del contratista en la ejecución de la obra.
5. Criterios de selección—identifican los estándares objetivos de rendimiento aceptable que proveerá el
contratista.
6. Entregables o programación de las entregas—describen lo que el contratista debe proveer; identifican
responsabilidades del contratista; identifican cualquier experticia especializada, servicios, capacita-
ción y documentación necesarios. Además, establecen claramente los entregables requeridos, el crono-
grama de las entregas, las cantidades y a quien se deben entregar. Finalmente, describe el programa de
entrega en días calendario desde la fecha de adjudicación.
7. Seguridad—establece los requisitos adecuados de seguridad, si es necesario, para el trabajo por realizar.
8. Lugar de ejecución—especifica si el trabajo se va a realizar del lado del cliente o en las instalaciones del
contratista.
9. Plazo de ejecución —especifica el periodo de ejecución para la realización del proyecto contratado.
Observe cómo la declaración del trabajo va de lo general a lo específico: primero articula los antecedentes del pro-
yecto, con una breve historia de las razones por las que se necesita el proyecto; luego identifica las tareas que com-
ponen este, antes de pasar a un análisis más detallado de cada tarea objetivo y del enfoque necesario para lograrlo.7
Un ejemplo más detallado de una declaración de trabajo genérica se muestra en el cuadro 5.2. La SOW
cubre los elementos claves en una propuesta de proyecto, incluidos la descripción, los entregables, las nece-
sidades de recursos, los riesgos, los resultados esperados, el tiempo y costo estimados, y otros aspectos pen-
dientes. El cuadro 5.2 puede servir de plantilla estándar para la construcción de una SOW razonablemente
detallada en la mayoría de los proyectos.

CUADRO 5.2  Elementos de una declaración de trabajo general

Fecha de presentación
Número de revisión
Nombre del proyecto
Número de identificación del
proyecto
SOW preparada por:

1. Descripción y alcance
a. Resumen del trabajo requerido
b. Antecedentes
c. Descripción de los principales elementos (entregables) del proyecto terminado
d. Beneficios esperados
e. Productos no incluidos en el alcance
f. Prioridades asignadas a cada elemento del proyecto
2. Enfoque
a. Principales hitos/eventos claves anticipados

Fecha Hito/evento

b. Normas especiales o metodologías que se deben considerar


5.2  Declaración del alcance 153

c. Efecto en los sistemas o proyectos existentes


d. Supuestos claves del proyecto
e. Planes para informes de las actualizaciones de estado
f. Procedimientos para cambios del alcance o del esfuerzo de trabajo
3. Recursos necesarios
a. Plan detallado/justificación de las necesidades y asignaciones de recursos

Persona Papel y justificación

b. Otras necesidades de recursos materiales (hardware, software, materiales, dinero, etc.)


c. Compromisos que se espera de otros departamentos de apoyo
d. Inquietudes o alternativas relacionadas con el plan de personal
4. Riesgos y preocupaciones
a. Riesgos ambientales
b. Riesgos de las expectativas del cliente
c. Riesgos competitivos
d. Riesgos en el desarrollo de proyectos (técnicos)
e. Limitaciones del proyecto
f. Evaluación general de riesgos
g. Mitigación del riesgo o estrategias de atenuación
5. Criterios de aceptación
a. Proceso y criterios detallados de aceptación
b. Pruebas/método de cualificación
c. Terminación del proyecto

6. Tiempo y costos estimados


a. Tiempo estimado para completar el trabajo del proyecto
b. Costo estimado para completar el trabajo del proyecto
c. Gastos corrientes previstos

7. Aspectos pendientes

La declaración del trabajo es importante, porque normalmente sirve como resumen de la fase de
desarrollo conceptual del plan del proyecto. Una vez armado con la SOW, el gerente del proyectos puede
pasar de lo general a lo más específico, identificando las medidas necesarias para responder adecuada-
mente a la declaración del trabajo detallada.

5.2  DECLARACIÓN DEL ALCANCE


La declaración del alcance es el corazón de la gerencia del alcance, pues refleja los mejores esfuerzos de un
equipo de proyecto para crear la documentación y aprobar todos los parámetros importantes del proyecto
antes de proceder a la fase de desarrollo.8 Los pasos claves en el proceso de declaración del alcance incluyen:

• Establecimiento de los criterios de las metas del proyecto.  Los criterios de las metas incluyen costo,
cronograma, rendimiento y entregables, la revisión fundamental y los “filtros” de aprobación con los
interesados de los proyectos (particularmente los clientes). Los entregables se definen formalmente
154 Capítulo 5  •  Gerencia del alcance

como “todo resultado o elemento, tangible, medible, verificable, que debe producirse para completar
un proyecto o una parte de este.” Los criterios de las metas del proyecto sirven como limitaciones y
puntos claves alrededor de los cuales el equipo del proyecto debe realizar su labor.
• Desarrollo del plan de gerencia del proyecto.  El plan de gerencia se compone de la estructura orga-
nizacional para el equipo del proyecto; las políticas y los procedimientos según los cuales se espera que
los miembros del equipo operen; las descripciones adecuadas de puestos de trabajo y una estructura de
información bien entendida por cada miembro del equipo. El plan de gerencia es esencialmente el paso
burocrático del proyecto que crea sistemas de control para asegurar que todos los miembros del equipo
conozcan sus funciones, responsabilidades y relaciones profesionales.
• Establecimiento de una estructura de desglose del trabajo.  Uno de los mecanismos de planeación más
importantes es la estructura de desglose de trabajo (EDT), conocida también como (work breakdown struc-
ture: WBS), que divide el proyecto en subetapas con el fin de comenzar a establecer relaciones claves entre las
actividades. Solo cuando un proyecto haya pasado por la EDT, es posible determinar las relaciones entre las
distintas actividades (qué pasos deben preceder a otros, cuáles son independientes de las tareas anteriores, y así
sucesivamente). Como veremos, la programación exacta puede comenzar solo con una precisa y significativa
estructura de desglose del trabajo.
• Creación de la línea base del alcance. La línea base del alcance es un documento que describe bre-
vemente cada componente de las metas del proyecto, incluidos el presupuesto básico y la información
de la programación para cada actividad. La creación de la línea base del alcance es el paso final en el
proceso de sistematización de toda la información previa, en la cual se identifica cada subrutina del
proyecto y se determinan los parámetros de control de costo y el cronograma de esta.

Estructura de desglose del trabajo


Cuando se nos da por primera vez un proyecto para ejecutar, la tarea puede parecer intimidante. ¿Cómo
empezamos? ¿A dónde debemos dirigir primero nuestros esfuerzos? Una de las mejores maneras de comen-
zar es reconocer que ningún proyecto es una mera colección de una serie de pasos discretos, o actividades,
que en conjunto suman la entrega total. No existe una fórmula mágica, los proyectos se completan un paso a
la vez, actividad por actividad.
De acuerdo con el Cuerpo de Conocimientos de la Gerencia de Proyectos (Project Management Body of
Knowledge: PMBOK), una estructura de desglose del trabajo (work breakdown structure :WBS) es “una agru-
pación orientada a la entrega de los elementos del proyecto que organiza y define el alcance total del proyecto.
Cada nivel descendente representa una definición cada vez más detallada de un componente del proyecto. Los
componentes del proyecto pueden ser productos o servicios.” Para reformular esta definición del PMBOK, la
EDT establece el alcance de un proyecto dividiendo su misión general en un conjunto cohesivo de tareas sin-
cronizadas cada vez más específicas.9 El resultado es un amplio documento que refleja este cuidadoso trabajo.
La EDT delinea los bloques básicos individuales que construirán el proyecto. Visualice la EDT imaginán-
dosela como un método para romper un proyecto en pedazos “en bocados”; cada uno de ellos representa un paso
necesario para completar el plan general del proyecto. Al inicio del proyecto, puede ser difícil visualizar todos
los elementos o tareas que son componentes necesarios para alcanzar el éxito del proyecto, pero el esfuerzo por
“profundizar” en las diversas actividades de tarea realmente puede reforzar la imagen global del proyecto.
Consideremos el caso de un equipo de estudiantes que trabajan juntos en un trabajo final y una pre-
sentación para un curso de la universidad. Uno de los primeros pasos en el proceso de completar el trabajo
consiste en dividir el proyecto en una serie de tareas, cada una de ellas se le puede asignar a un miembro o
miembros del equipo. El proyecto en general constituido por dos productos específicos —el trabajo y la pre-
sentación— se hace más fácil de manejar al reducirlo a una serie de niveles más simples, como:

Tarea uno: refinar el tema


Tarea dos: asignar las responsabilidades de investigación en la biblioteca
Tarea tres: desarrollar un esquema preliminar para el trabajo y la presentación
Tarea cuatro: asignar a cada miembro del equipo para empezar a elaborar la presentación
Tarea cinco: comenzar la producción de los borradores del trabajo
Tarea seis: revisar y corregir los borradores
Tarea siete: refinar la presentación de la clase
Tarea ocho: entregar el trabajo y hacer la presentación en clase
5.2  Declaración del alcance 155

A. Establecimiento de metas usando EDT

Inicio del Terminación


A B C D
proyecto del proyecto

Meta 1 Meta 2 Meta 3 Meta 4

B. Establecimiento de metas sin EDT

Inicio del Terminación


?
proyecto del proyecto

FIGURA 5.2  Ajuste de la meta con EDT y sin esta

Una EDT podría ir mucho más lejos en la definición de los pasos de un proyecto, este ejemplo solo pretende
dar una idea de la lógica empleada para reducir un proyecto global a una serie de pasos significativos por
seguir. Como se verá en los siguientes capítulos, esos mismos pasos que se deben seguir se evalúan posterior-
mente con el fin de estimar la cantidad de tiempo necesario para su realización.
La lógica de la EDT se muestra en la figura 5.2. En lugar de dar una fecha de inicio y una meta final,
el diagrama proporciona una serie de puntos de control a lo largo del camino. Estos puntos de control
abordan los pasos específicos que conducen naturalmente desde el principio hasta la conclusión lógica
del proyecto. La EDT le permite ver tanto los árboles como el bosque, por lo que pueden reconocerse los
muchos niveles que se necesitan para lograr el proyecto terminado.

Propósitos de la estructura de desglose del trabajo


La EDT tiene seis propósitos principales:10

1. Hace eco de los objetivos del proyecto.  Teniendo en cuenta la misión del proyecto, una EDT identi-
fica las principales actividades de trabajo que se necesitan para lograr esta meta o conjunto de metas.
Lo que se menciona en la EDT es lo que se hace en el proyecto.
2. Es el organigrama del proyecto.  Los organigramas suelen proporcionar una manera de entender la
estructura de la empresa (quién informa a quién, cómo evolucionan los flujos de comunicación, quién
tiene la responsabilidad de cuál departamento, y así sucesivamente). La EDT ofrece una estructura
lógica similar para un proyecto, identificando los elementos claves (tareas) que necesitan atención, las
diferentes subtareas y el flujo lógico de una actividad a otra.
3. Crea la lógica de seguimiento de costos, cronograma y especificaciones de rendimiento para cada
elemento en el proyecto.  A todas las actividades del proyecto identificadas en la EDT se les puede
asignar sus propios presupuestos y expectativas de desempeño. Este es el primer paso para establecer
un método integral en el control del proyecto.
4. Se puede utilizar para comunicar el estado del proyecto.  Una vez que las tareas se han identificado y
se establecen responsabilidades para el logro de los objetivos de la tarea, se puede determinar qué tareas
están en camino, cuáles son claves y cuáles están pendientes, y quién es responsable de su estado.
5. Se puede utilizar para mejorar la comunicación global del proyecto.  La EDT no solo dicta la manera
de dividir el proyecto en paquetes identificables, sino también muestra cómo estos encajan en el
esquema general de desarrollo. Como resultado, los miembros del equipo se dan cuenta de cómo su
componente encaja en el proyecto, quién es responsable, aguas arriba, de proporcionarles trabajo y
cómo sus actividades afectan el trabajo posterior. Esta estructura mejora la motivación para la comuni-
cación dentro del equipo del proyecto, como miembros que desean hacer transiciones de actividades lo
más fácil posible.
6. Demuestra cómo se controlará el proyecto.  La estructura general del proyecto demuestra el enfoque
clave que se implementará para controlar el proyecto. Por ejemplo, ¿el proyecto se basa en la creación
156 Capítulo 5  •  Gerencia del alcance

de un entregable (nuevo producto) o en la mejora de un proceso o servicio (eficiencia funcional) den-


tro de la empresa? En cualquier caso, la EDT ofrece la lógica del método de control más apropiado.

Vamos a ilustrar la EDT con un ejemplo sencillo. Considere el caso de un gran hospital urbano que ha
tomado la decisión de introducir un sistema IT en toda la organización para facturación, registro de cuen-
tas por cobrar, tratamiento de los pacientes, supervisión de personal y control de los procesos médicos. El
primer paso en el lanzamiento de este gran proyecto de implantación consiste en identificar los elementos
importantes en la introducción de la tecnología. Este es un enfoque básico en la identificación de los entre-
gables de un proyecto de implantación de un nuevo sistema de información en una organización (véase la
figura 5.3).
1. Comparar la IT con las tareas y los problemas de organización.
2. Identificar las necesidades de los usuarios de IT.
3. Preparar una propuesta informal para la alta dirección (u otros tomadores de decisiones) para la adqui-
sición de IT.
4. Buscar y contratar a un consultor de IT.
5. Buscar el apoyo de personal del departamento de IT.
6. Identificar la localización más adecuada de IT dentro de la organización para ubicar el hardware.
7. Preparar una propuesta formal para la introducción de IT.
8. Solicitar propuestas (RFP) a los proveedores de IT.
9. Elaborar un proyecto piloto (o serie de proyectos piloto con diferentes opciones de IT).
10. Elaborar un contrato de compra.
11. Adoptar y utilizar la tecnología IT.
Para simplificar, esta lista solo identifica las tareas de primer nivel que participan en la realización de este
proyecto. Claramente, cada uno de los 11 pasos anteriores y en el diagrama de flujo de la figura 5.3 tiene
diversas subtareas de apoyo asociadas con ella. Por ejemplo, el paso 2, identificar las necesidades de los usua-
rios de IT, podría tener tres subtareas:

Comparar Identificar las Preparar la


la IT con necesidades propuesta
problemas de los usuarios

Identificar la Buscar el Buscar y


localización apoyo del contratar
de IT personal consultores

Solicitar RFP
Propuesta a los Proyecto
formal proveedores piloto

Adoptar y Contrato
utilizar la IT de compra

FIGURA 5.3  Diagrama de flujo para la implantación


5.2  Declaración del alcance 157

1.0

1.2 1.3 1.4 1.5

1.2.1 1.3.1 1.4.1

1.2.2 1.3.2 1.4.2

1.2.3 1.4.3

FIGURA 5.4  Estructura de desglose de trabajo parcial

1. Entrevistar a los usuarios potenciales.


2. Desarrollar una presentación de los beneficios de IT.
3. Obtener usuarios para el sistema propuesto.
La figura 5.4 ilustra una EDT parcial, que muestra algunas de las tareas y subtareas. La lógica a través de todas
las tareas identificadas que deben llevarse a cabo para el proyecto es similar.
No nos detenemos aquí, sino que seguimos para darle cuerpo a la EDT con información adicional. La figura
5.5 representa una EDT más completa para demostrar la lógica de dividir el proyecto en las piezas que lo componen.
El nivel 1.0 que se muestra en la figura 5.5 identifica el proyecto en general. Debajo de este nivel están los principales
productos entregables (por ejemplo, 1.2, 1.3, etc.) que sustentan la ejecución del proyecto. Debajo de los entregables
están los diversos “paquetes de trabajo” que se deben completar para concluir los entregables del proyecto.
Los paquetes de trabajo se definen como elementos de la EDT del proyecto que se aíslan para asig-
narse a “centros de trabajo” para su realización.11 Al igual que los átomos, la unidad indivisible más pequeña
de la materia en física, los paquetes de trabajo son los componentes indivisibles más pequeños de una EDT.
Es decir, los paquetes de trabajo son el nivel más bajo de la EDT, compuesto por las tareas de corta duración
que tienen un inicio y un final definidos, con sus costos asignados y consumen algunos recursos. Por ejem-
plo, en el nivel 1.2 de identificación de necesidades de los usuarios de IT (un entregable), tenemos que llevar
a cabo tres actividades de apoyo: (1) entrevistar a los usuarios potenciales; (2) desarrollar una presentación
de los beneficios de IT; y (3) obtener usuarios para el sistema. El siguiente nivel hacia abajo (1.2.1, 1.2.2, etc.)
representa los paquetes de trabajo necesarios para completar el entregable.
A veces surge la confusión en cuanto a la distinción que se hace entre “paquete de trabajo” y “tarea,” en
lo que respecta a los proyectos y al desarrollo de la EDT. En realidad, en muchas organizaciones, la diferencia
entre los términos y su significado es pequeña; a menudo se utilizan indistintamente por la organización de la
gerencia de proyectos. La clave es ser consistente en la aplicación de la terminología, pues significa la misma
cosa en diferentes partes de la organización, en lo que respecta a los recursos tanto técnicos como de gerencia.
En general, en un proyecto genérico, la lógica de la jerarquía para la EDT sigue este formato:

Nivel Término de EDT Descripción


Nivel 1 (más alto) Proyecto El proyecto en su conjunto en fase de desarrollo
Nivel 2 Entregables Los principales componentes del proyecto
Nivel 3 Subentregables Entregables de apoyo
Nivel 4 (bajo) Paquete de trabajo Actividades individuales del proyecto
158 Capítulo 5  •  Gerencia del alcance

El cuadro 5.3 da un ejemplo de cómo se descomponen las actividades del proyecto e identifica el entre-
gable y los niveles de paquetes de trabajo, así como una breve descripción de cada una de estas actividades.
La EDT en esa figura también muestra un código numérico asignado a cada actividad. El departamento de
contabilidad de la empresa asigna los códigos EDT de cada actividad para imputar los costos con mayor
precisión, para realizar un seguimiento de las actividades que están por encima o por debajo del presupuesto
y para mantener el control financiero del proceso de desarrollo.
A veces es necesario diferenciar entre un subentregable, como se identifica en la descomposición jerár-
quica superior, y los paquetes de trabajo que se utilizan para apoyar y completar los subentregables. Por lo
general, pensamos en subentregables como resúmenes “acumulados” de los resultados de dos o más paquetes

Desglose Descripción EDT Código


Implantación del 1.0
proyecto de IT
Entregable 1 Comparar la IT con las tareas y problemas de la 1.1
organización
PT 1 Desarrollar análisis de problemas 1.1.1
PT 2 Desarrollar información sobre tecnología IT 1.1.2

Entregable 2 Identificar las necesidades de los usuarios de IT 1.2


PT 1 Entrevistar a los usuarios potenciales 1.2.1
PT 2 Desarrollar la presentación de los beneficios de IT 1.2.2
PT 3 Ganar la aceptación de los usuarios de IT 1.2.3
Entregable 3 Preparar una propuesta informal 1.3
PT 1 Desarrollar la información en términos de costo/beneficio 1.3.1
PT 2 Ganar el apoyo de la alta gerencia 1.3.2
Entregable 4 Buscar y contratar a un consultor de IT 1.4
PT 1 Conformar el comité de búsqueda 1.4.1
PT 2 Desarrollar los criterios de selección 1.4.2
PT 3 Entrevistar y seleccionar consultores 1.4.3
Entregable 5 Buscar el apoyo del personal del departamento de IT 1.5
Entregable 6 Identificar la localización más adecuada de IT 1.6
PT 1 Consultar con los ingenieros de la planta física 1.6.1
PT 2 Identificar posibles sitios alternativos 1.6.2
PT 3 Asegurar la aprobación del sitio 1.6.3
Entregable 7 Preparar una propuesta formal para la introducción de IT 1.7

Entregable 8 Solicitar las RFP a los proveedores de IT 1.8


PT 1 Desarrollar criterios para la toma de decisiones 1.8.1
PT 2 Contactar a los proveedores adecuados 1.8.2
PT 3 Seleccionar ganador(es) e informar a los perdedores 1.8.3
Entregable 9 Elaborar un proyecto piloto (o serie de proyectos 1.9
piloto con diferentes opciones de IT)
Entregable 10 Elaborar un contrato de compra 1.10
Entregable 11 Adoptar y utilizar la tecnología IT 1.11
PT 1 Iniciar sesiones de formación para los empleados 1.11.1
PT 2 Desarrollar un sistema de seguimiento para problemas 1.11.2
técnicos

CUADRO 5.3  Ejemplo de EDT de un proyecto


5.2  Declaración del alcance 159

de trabajo. A diferencia de los paquetes de trabajo, los subentregables no tienen una duración propia ni con-
sumen recursos, ni tienen costos directos asignados. Todos los recursos o los costos asociados a un subentre-
gables son simplemente el resumen de todos los paquetes de trabajo que lo soportan.
La mayoría de organizaciones exige que cada entregable (y por lo general cada una de las tareas o paque-
tes de trabajo contenidas) cuente con documentación descriptiva que apoye los objetivos del proyecto y pueda
examinarse como una base para permitir la aprobación y programación de los compromisos de recursos. El
cuadro 5.4 es una página de ejemplo del documento de descripción de la tarea destinada a apoyar la EDT del
proyecto que se indica en el cuadro 5.3. Usando el paquete de trabajo (PT) 1.4.1, “Conformar el comité de
búsqueda,” se puede elaborar un documento exhaustivo de control. Cuando un documento de apoyo funciona
como dispositivo de control del proyecto a lo largo de su desarrollo, no se prepara por adelantado, y una vez la
etapa de proyecto se ha completado se deja de utilizar, es decir, es un documento dinámico. Este documento
especifica las reuniones de revisión para el paquete de trabajo a medida que el proyecto avanza; el documento de
descripción de la tarea debe completarse, presentarse y revisarse con la frecuencia necesaria para garantizar que
toda la información relevante esté disponible.

Formulario de descripción de tareas del proyecto


Identificación de tareas
Nombre del proyecto: IT implantación Código del proyecto: IS02 Gerente de proyectos: Williams
Nombre del PT: conformar el comité de búsqueda
Código PT: PT 1.4.1 Propietaria: Susan Wilson
Entregable: asignación de personal para IT al comité de búsqueda de proveedores
No. de revisión: 3 Fecha: 10/22/12 Revisión anterior: 2 (en archivo)

Recursos necesarios
Trabajo Otros recursos
Tipo Días de trabajo Tipo Cantidad Costo
Gerente de sistemas 5 Software A 1 $15,000
Programador sénior 3 Instalaciones N/A
Técnico de hardware 2 Equipo 1 $500
Jefe de compras 3 Otro N/A
Ingeniero de sistemas 5
Requisitos previos necesarios: entregables 1.1, 1.2 y 1.3 (en archivo)
Pruebas de aceptación: no se requieren
Número de días de trabajo necesarios para completar la tarea: 5
Posibles eventos de riesgo que pueden afectar el éxito de la tarea: __________________

PARA COMPLETAR DESPUÉS PROGRAMAR EL PROYECTO:


Inicio temprano de la tarea: 15/01/13 Fin temprano de la tarea: 15/02/13

Reunión de revisión de acuerdo con los hitos:


Nombre del hito Entregables Fecha de la reunión Participantes
Identificar las necesidades Requerimientos de 8/31/12 Wilson, Boyd, Shaw
de los usuarios de IT trabajo de IT
_______________________ ____________________ ____________________ ____________________
_______________________ ____________________ ____________________ ____________________

Aprobación del diseño de la tarea:


Propietario de la tarea: Sue Wilson Firma: _________________________ Fecha: _______
Contacto con el cliente: Stu Barnes Firma: _________________________ Fecha: _______
Gerente de proyectos: Bob Williams Firma: _________________________ Fecha: _______

CUADRO 5.4  Descripción de las tareas del proyecto


160 Capítulo 5  •  Gerencia del alcance

PANTALLA 5.1  Muestra de desarrollo de EDT con MS Project 2010

MS Project permite crear la EDT para un proyecto. Como entrada de cada tarea del proyecto, podemos
asignar un código EDT a esta mediante la opción EDT bajo el encabezado del proyecto. La pantalla 5.1 ofrece
una muestra de capturas de algunas de las actividades identificadas en el ejemplo de proyecto de IT para el
hospital. Observe que hemos creado una EDT parcial para el proyecto de IT mediante la opción MS Project
EDT, que también nos permite distinguir entre los encabezados Nivel de proyecto, Entregables y Paquetes
de trabajo.

Estructura de desglose de la organización


Un beneficio adicional al crear una EDT integral de un proyecto es la capacidad para organizar el trabajo
necesario para desarrollar las cuentas de control de costos que se asignan a las distintas unidades dentro
de la empresa, las cuales participan en las actividades del proyecto. El resultado de organizar este material
es la estructura de desglose de la organización (EDO), conocida también como (organization breakdown
structure: OBS). En resumen, la EDO les permite a las empresas definir el trabajo por realizar y asignar los
responsables de los paquetes de trabajo.12 Los presupuestos de estas actividades se asignan directamente a las
cuentas de los departamentos responsables del trabajo del proyecto.
Supongamos, que nuestro proyecto de IT del ejemplo, requiere los recursos comprometidos de tres
departamentos: tecnología de la información, adquisiciones y recursos humanos. Queremos asegurarnos
de que los diferentes paquetes de trabajo y sus costos se asignan correctamente a la persona y departamento
responsable de su realización, con el fin de garantizar que nuestro control de costos del proyecto pueda
mantener precisión y actualización. La figura 5.5 muestra un ejemplo visual de la intersección de nuestra
EDT parcial con una EDO para nuestro proyecto de implantación de IT. Los tres departamentos dentro de
la organización se muestran horizontalmente y los paquetes de trabajo, debajo de uno de los entregables, se
muestran verticalmente. Observe que solo algunas de las cajas utilizadas para ilustrar la intersección se afec-
tan, lo cual sugiere que para algunos paquetes de trabajo pueden estar implicados múltiples departamentos,
cada uno con sus propias cuentas de costos, mientras que otros paquetes de trabajo pueden tener un solo
responsable directo.
La ventaja de utilizar una EDO radica en que permite una mejor vinculación inicial de las actividades
del proyecto con sus presupuestos, ya sea a nivel departamental o, más directamente, sobre una base indivi-
dual—por persona—, como se muestra en el cuadro 5.5. En este caso, el costo directo para cada paquete de
trabajo se asigna a un individuo específico responsable de su terminación. La figura 5.5 reconfigura la EDO
para mostrar los resúmenes de cuenta de costos que pueden hacerse para cada departamento responsable de
un paquete de trabajo específico o entregable del proyecto.
5.2  Declaración del alcance 161

1.0

Implantación
Proyecto
de IT

1.3 1.4 1.5

Preparar Buscar y Buscar


propuesta contratar apoyo Entregables
consultor para IT
de IT

1.4.1 1.4.2 1.4.3

Conformar Desarrollar Seleccionar Paquetes


comité de criterios consultor de trabajo
búsqueda

Departamentos

Sistemas de Contabilidad Contabilidad Contabilidad


información de costos de costos de costos

Recursos Contabilidad Contabilidad


humanos de costos de costos

Contabilidad
Compras
de costos

FIGURA 5.5  La intersección de EDT y EDO

Código EDT Presupuesto Responsable


1.0 $700,000 Bob Williams, IT Manager
  1.1 5,000 Sharon Thomas
    1.1.1    2,500 Sharon Thomas
    1.1.2    2,500 Dave Barr
  1.2 2,750 David LaCouture
    1.2.1    1,000 David LaCouture
    1.2.2    1,000 Kent Salfi
    1.2.3     750 Ken Garrett
  1.3 2,000 James Montgomery
    1.3.1    2,000 James Montgomery
    1.3.2    -0- Bob Williams
  1.4 2,500 Susan Wilson
    1.4.1    -0- Susan Wilson
    1.4.2    1,500 Susan Wilson
    1.4.3    1,000 Cynthia Thibodeau
  1.5    -0- Ralph Spence
  1.6 1,500 Terry Kaplan
    1.6.1     -0- Kandra Ayotte
(continúa)
162 Capítulo 5  •  Gerencia del alcance

Código EDT Presupuesto Responsable


    1.6.2     750 Terry Kaplan
    1.6.3     750 Kandra Ayotte
  1.7 2,000 Bob Williams
  1.8 250 Beth Deppe
    1.8.1     -0- Kent Salfi
    1.8.2     250 James Montgomery
    1.8.3     -0- Bob Williams
  1.9 30,000 Debbie Morford
  1.10 600,000 Bob Williams
  1.11 54,000 David LaCouture
    1.11.1    30,000 David LaCouture
    1.11.2    24,000 Kandra Ayotte

CUADRO 5.5  Asignaciones de responsables y costo

En la gerencia de proyectos, el punto principal por tener en cuenta acerca de la declaración del alcance
es la necesidad de dedicar suficiente tiempo por adelantado en la preparación de programas y presupuestos,
basados en una estimación precisa y razonable. Este estimativo puede realizarse adecuadamente solo si los
gerentes de proyectos han trabajado según la EDT y las declaraciones de las metas del proyecto. Hay pocas
maneras más seguras para crear un ambiente de fracaso del proyecto que la de hacer una EDT superficial e
incompleta. Cuando los pasos se dejan a un lado, ignoran o subestiman durante la fase de creación de la EDT,
entonces se presupuestan por debajo o se subestiman en la programación. El resultado es un proyecto que
seguramente tendrá programaciones desfasadas, presupuestos inflados y confusiones durante el desarrollo.
Gran parte de este caos se puede evitar si el gerente de proyectos dedica suficiente tiempo a la declaración del
alcance para asegurarse de que no faltan elementos.

Matriz de asignación de responsabilidades


Para identificar al personal del equipo que será directamente responsable de cada tarea en la ejecución del
proyecto, se desarrolló la matriz de asignación de responsabilidades (responsibility assignment matrix:
RAM). (La RAM se refiere a veces como un gráfico lineal de responsabilidad). Aunque se considera un docu-
mento separado, la RAM se elabora frecuentemente en conjunto con la EDT. La figura 5.6 ilustra una matriz
de asignación de responsabilidades para el proyecto de ejemplo de este capítulo. Tenga en cuenta que la
matriz enumera no solo al miembro del equipo del proyecto responsable de cada actividad, sino también a
los otros miembros importantes del equipo en cada etapa, organizados de acuerdo con la forma en que la
actividad requiere su apoyo. La RAM identifica a dónde debe ir cada persona para ayudar a la ejecución de las
tareas, quién debe ser notificado del estado de ejecución de las tareas en cada etapa y de todos los requisitos
de cierre. Esta herramienta proporciona un vínculo entre todos los miembros del equipo del proyecto y com-
bate el peligro de un posible vacío de comunicación en el que unos miembros del equipo realizan sus tareas
sin actualizar a los otros miembros de este.
Trabajar con una RAM le permite al gerente de proyectos determinar la mejor manera de asignar
el equipo de proyectos para lograr una máxima eficiencia. En la elaboración del documento, un gerente
de proyectos tiene la oportunidad de evaluar las fortalezas, debilidades, compromisos y disponibilidad
de trabajo de los miembros del equipo. Muchas empresas gastan una cantidad significativa de dinero en
el desarrollo y uso de software para el seguimiento preciso de las actividades del proyecto, pero casi no
dedican tiempo al seguimiento de la interacción entre los miembros del equipo del proyecto. La RAM
les permite a los gerentes de proyectos establecer un método para coordinar las actividades laborales de
los miembros del equipo, para así obtener las eficiencias que se producen cuando todos los miembros
del equipo proporcionan apoyo, notificación y aprobación a las responsabilidades de los demás.
5.2  Declaración del alcance 163

1.0

Implantación
Proyecto
de IT

1.3 1.4 1.5

Preparar Buscar y Buscar


Entregables
propuesta contratar apoyo
consultor para IT
de IT

1.4.1 1.4.2 1.4.3

Conformar Desarrollar Seleccionar Paquetes


comité de criterios consultor de trabajo
búsqueda

Departamentos

Sistemas de $0 $500 $1,000


información

Recursos $0
humanos $500

Compras $500

Totales $0 $1,500 $1,000

FIGURA 5.6  Contabilización de costos con la EDO


Gerencia de proyecto personal

Bob David Susan Beth James Terry


Tarea IT IT RH Compras Ingeniería Jurídica
Entregable
y código
Comparar la IT Desarrollar
con las tareas y análisis de
los problemas de problemas
la organización— –1.1.1
1.1
Desarrollar
información
sobre la
tecnología IT
–1.1.2
Identificar Entrevistar a
necesidades los usuarios
de los usuarios potenciales
de IT— –1.2.1
1.2
Desarrollar
presentación
–1.2.2

Ganar el apoyo
de la alta
gerencia
–1.2.3

Preparar una Desarrollar la


propuesta información en
informal— términos de
1.3 costo/beneficio
–1.3.1

Responsable Soporte

Notificación Aprobación

FIGURA 5.7  Matriz de asignación de responsabilidades


164 Capítulo 5  •  Gerencia del alcance

PERFIL DE PROYECTO

Definición de un paquete de trabajo del proyecto


Recuerde estos siete puntos importantes acerca de la definición de un paquete de trabajo del proyecto:13
1. El paquete de trabajo conforma generalmente el nivel más bajo de la EDT. Aunque algunos proyectos pueden
emplear el término subtarea, la mayoría deja las actividades del nivel de paquete de trabajo como el paso más
básico de la EDT.
2. Un paquete de trabajo tiene un resultado entregable. Cada paquete de trabajo debe tener su propio resul­
tado. Un paquete de trabajo no resume ni modifica a otro. Juntos, los paquetes de trabajo identifican todo el
trabajo que debe contribuir a completar el proyecto.
3. Un paquete de trabajo tiene asignado un responsable, un miembro del equipo del proyecto, que tendrá a
cargo la terminación de ese paquete. Aunque otros miembros del equipo pueden proporcionar el apoyo nece­
sario, solo una persona debería ser directamente responsable del paquete de trabajo.
4. Un paquete de trabajo puede considerarse por su responsable como un proyecto en sí mismo. Si adoptamos la
noción de que todos los paquetes de trabajo tienen longitud y presupuesto finito y una entrega específica, se
pueden considerar proyectos en miniatura, y cada responsable del paquete puede ver sus actividades como un
microproyecto.
5. Un paquete de trabajo puede incluir varios hitos. Un hito se define como un acontecimiento importante en el
proyecto. Dependiendo del tamaño y la complejidad de un paquete de trabajo, puede contener una serie de
puntos de control o hitos que determinan su progreso hacia el cumplimiento.
6. Un paquete de trabajo debe ajustarse a los procedimientos y a la cultura organizacional. Las tareas llevadas
a cabo para apoyar los resultados del proyecto deben estar de acuerdo con las normas culturales generales
de la organización del proyecto. La realización de un paquete de trabajo no debe conducir a un miembro del
equipo a violar la política de la empresa (ya sea explícita o implícitamente), es decir, las actividades asignadas
deben ser coherentes con las normas legales pertinentes al comportamiento ético y a los procedimientos acep­
tados por la organización.
7. El tamaño óptimo de un paquete de trabajo se puede expresar en términos de horas de trabajo, tiempo calen­
dario, costo, periodo de reportes y riesgos. A todos los paquetes de trabajo debe hacérseles seguimiento, lo
cual significa que deben estar estructurados para permitirle al gerente de proyectos monitorear su progreso.
El progreso es, por lo general, un concepto medible, delineado por métricas como el tiempo y el costo.
En el desarrollo de la RAM de un proyecto, los gerentes deben considerar las relaciones entre el equipo del
proyecto y el resto de la organización, así como las relaciones internas del equipo del proyecto. Dentro de una
organización, y fuera de ella, las acciones de los jefes de departamento y gerentes funcionales externos pueden
afectar la forma como los miembros de un equipo de trabajo desempeñan su labor. Por tanto, una RAM detallada
puede ayudar a los gerentes de proyectos a negociar con los gerentes funcionales de los recursos, particularmente
detallando la necesidad de incluir a varios miembros del equipo en el proyecto.

5.3  AUTORIZACIÓN DE TRABAJO


Esta etapa en la gerencia del alcance sigue naturalmente a las dos anteriores. Una vez que la definición del
alcance, los documentos de planeación, los planes de gerencia y otros documentos contractuales se han ela-
borado y aprobado, la autorización de trabajo da “luz verde” formal para comenzar el proyecto. Muchas
veces, la autorización de trabajo consiste en la aprobación formal de los planes del proyecto, incluidas las
especificaciones detalladas para la ejecución. En los casos de proyectos desarrollados para clientes externos,
la autorización de trabajo se enfoca en las obligaciones contractuales; para clientes internos, significa esta-
blecer una auditoría de prueba vinculando todos los requerimientos de recursos con el sistema formal de
contabilidad de costos de la organización. En las obligaciones contractuales entre las organizaciones y los
clientes del proyecto, pueden existir numerosos componentes, pero la mayoría de la documentación contrac-
tual posee algunas características identificables claves:14
• Requisitos contractuales.  Todos los proyectos prometen que cumplirán una funcionalidad especí-
fica, o unos criterios de desempeño. Esto sugiere estas preguntas: ¿cuál es la definición aceptada por
las dos partes de “desempeño específico”? ¿Los términos de desempeño están claramente entendidos e
identificados por ambas partes?
5.4  Reporte del alcance 165

• Consideración válida.  ¿Qué elementos se comprometieron voluntariamente a cambio de un com-


promiso recíproco por la otra parte? ¿El contrato de autorización de trabajo deja en claro los compro-
misos acordados por ambas partes?
• Términos contratados.  ¿Cuáles son las demoras excusables, costos permisibles, las declaraciones de daños
y perjuicios en caso de incumplimiento? ¿Cuáles son los criterios para la inspección? ¿Quién es responsable
de la corrección de defectos? ¿Qué pasos son necesarios para resolver conflictos? Los términos contratados
generalmente tienen significados legales claros para alentar a ambas partes a comunicarse de forma eficaz.
Una serie de arreglos contractuales pueden servir para codificar la relación entre la organización del
proyecto y el cliente. Está más allá del alcance de este capítulo explorar con detalle las diversas formas de
contratos y recursos legales, pero algunos arreglos contractuales tipo deben considerarse en la gerencia del
alcance del proyecto. Desde el punto de vista de la organización del proyecto, la gama más común va desde
contratos de valor global o llave en mano, en los que la organización del proyecto asume toda la responsabi-
lidad por el desempeño exitoso, hasta contratos de costo incrementado, que fijan con antelación las ganan-
cias de la empresa para el proyecto. Vamos a discutir primero este último.
A veces es casi imposible determinar con antelación el costo probable de un proyecto. Por ejemplo, los
inmensos desafíos técnicos involucrados en poner un hombre en la Luna, la perforación de un túnel bajo el
canal inglés, o el desarrollo de una iniciativa estratégica de defensa, hacen el proceso de estimación de costos
del proyecto extremadamente difícil. En estos casos, las compañías de proyectos celebran un contrato de costo
incrementado, que les garantiza cierto beneficio, independientemente de los costos excesivos en que puedan
incurrirse durante el desarrollo del proyecto. Los contratos de costo incrementado pueden generar abusos; de
hecho, ha habido ejemplos notorios de enormes sobrecostos en contratos gubernamentales, debido a la falta de
control que resulta en violaciones sistemáticas. Sin embargo, este tipo de contratos pueden minimizar el riesgo
que una compañía tendría que enfrentar si tratara de llevar a cabo un proyecto muy técnico con resultados
potencialmente inciertos. Siempre que ambas partes comprendan los términos del acuerdo, la organización del
proyecto actúa con la debida diligencia y hay una auditoría final a los libros del proyecto.
En el extremo opuesto están los contratos de valor global (a veces se denomina llave en mano) en los que
se requiere al contratista llevar a cabo todo el trabajo a un precio negociado inicialmente. Este tipo de contra-
tación funciona mejor cuando los parámetros del proyecto están claramente entendidos por ambas partes (por
ejemplo, un proyecto de construcción de viviendas) y los gastos concomitantes del proyecto puede estimarse
con cierto nivel de complejidad. En los contratos de valor global, la estimación inicial de costos es clave: si la
estimación inicial es muy baja y el contratista se encuentra con problemas imprevistos, los beneficios del pro-
yecto pueden reducirse o incluso desaparecer. La ventaja del contrato de valor global para el cliente es que el
contratista seleccionado haya aceptado la mayor parte del riesgo del proyecto. Por otro lado, debido a que la
estimación de costos es tan crucial, comúnmente los estimativos iniciales de los contratos de valor global tien-
dan a ser bastante altos, y requieren negociación y relicitación entre los contratistas y el cliente.
El punto clave de autorización de trabajo se basa en la naturaleza de los términos establecidos para el
desarrollo del proyecto. El gerente debe elaborar contratos que estipulen claramente el trabajo de acuerdo
con la naturaleza del proceso de desarrollo del proyecto, los pasos para resolver conflictos y demás criterios
claramente identificados para completar con éxito el proyecto. Esta especificidad puede ser especialmente
importante cuando se trata de los interesados externos, incluidos proveedores y clientes. Una autorización de
trabajo redactada con terminología precisa ayuda al desarrollo del proyecto aguas abajo. Por otro lado, una
declaración en términos ambiguos o hitos colocados incorrectamente pueden provocar el efecto contrario:
desacuerdos, negociaciones y potencialmente acciones legales: todos garantizan frenar el desarrollo del pro-
yecto y añaden enormes costos a la fase final de los proyectos “terminados.”

5.4  REPORTE DEL ALCANCE


En el inicio del proyecto, el equipo del proyecto y los clientes claves deben tomar decisiones acerca de la
necesidad de actualizaciones en el proyecto: ¿cuántas serán necesarias y con qué frecuencia? Los reportes
del alcance cumplen esta función determinando los tipos de información que se reportará con regularidad,
quiénes recibirán copias y cómo se adquiere y se difunde esta información.
¿Qué tipos de información están disponibles y qué se puede informar adecuadamente? Claramente,
hay una gran variedad de informes que se pueden utilizar para hacerle seguimiento al proyecto. Aunque los
conceptos se desarrollarán con más detalle en los siguientes capítulos, entre los tipos de información de pará-
metros del proyecto que se incluyen con más frecuencia en estos informes están los siguientes:15
166 Capítulo 5  •  Gerencia del alcance

• Estado del costo: actualización de desempeño del presupuesto


Curvas S: gráfica de los costos (incluidos las horas de mano de obra y otros costos) contra el cronograma
Valor ganado: reporta el estado del proyecto en términos de costo y tiempo (el valor presupuestado
del trabajo realizado, independientemente de los costos reales incurridos)
Reportes de diferencia o excepción: documentan las posibles desviaciones de tiempo, el rendimiento
o costo contra las medidas planeadas
• Estado del cronograma: cambios en la fecha prevista de cumplimiento
• Estado de desempeño técnico: actualizaciones sobre los problemas técnicos y sus soluciones
La comunicación sólida entre todas las partes interesadas en un proyecto es uno de los aspectos más
importantes para el reporte efectivo del alcance. Hay que evitar la tentación de limitar la información del
estado del proyecto a solo un puñado de personas. A menudo, con la excusa de la “necesidad de conocer,”
muchos equipos de proyecto mantienen el estado de su proyecto en secreto, incluso más allá del punto en
que hayan encontrado serios problemas (consulte la sección “Investigación de gerencia de proyectos en sín-
tesis.” Los gerentes de proyectos deben tener en cuenta quiénes se beneficiaran de recibir actualizaciones
periódicas de los proyectos y planear una estructura de información adecuada. Algunos interesados que
podrían incluirse en la presentación periódica del estado del proyecto son:
• Miembros del equipo del proyecto
• Clientes de proyecto
• Alta gerencia
• Otros grupos de la organización afectada por el proyecto
• Todos las partes externas que tienen interés en el desarrollo del proyecto, como proveedores y contratistas
Todos estos grupos tienen un interés en el desarrollo del proyecto o se afectarán por el proceso de implemen-
tación. Limitar la información puede parecer eficiente o ahorrar tiempo a corto plazo, pero puede alimentar
posibles malentendidos, rumores y la resistencia de la organización al proyecto a largo plazo.

RECUADRO 5.1

INVESTIGACIÓN DE GERENCIA DE PROYECTOS EN SÍNTESIS


Tecnología de la información (IT) en el proyecto “Marchas de la muerte”: ¿qué está
pasando aquí?
Cada año, miles de millones de dólares se gastan en miles de proyectos de tecnología de la información (infor-
mation technology: IT) a nivel mundial. Con el enorme énfasis en los productos de IT y los avances en los sistemas
de software y hardware, no extraña que el interés en este campo esté expandiéndose. En estas circunstancias,
esperamos naturalmente que, dada la importancia de los proyectos de IT, tanto en nuestra vida cotidiana como
en la empresarial, estemos haciendo un trabajo de implementación razonablemente bueno de estos proyectos,
¿cierto? Infortunadamente, la respuesta es un rotundo “no.” De hecho, numerosos estudios demuestran que
los proyectos de IT tienen un historial de entrega terrible. ¿Qué tan grave? En promedio, es probable que los pro-
yectos de IT se retrasen entre 6 a 12 meses, y 50% a 100% estén por encima del presupuesto. Por supuesto, las
cifras varían en función del tamaño del proyecto, pero los resultados todavía sugieren que las empresas podrían
esperar que sus proyectos de IT conduzcan a esfuerzos inútiles, enormes retrasos, agotamiento y muchos fines
de semana perdidos mientras se trabajaba para el éxito, con las cartas apiladas en sentido contrario.
Estamos refiriéndonos aquí a proyectos de la “Marcha de la muerte.” Un proyecto de este tipo suele ser
aquel que está predispuesto al fracaso a través de las demandas o expectativas que la compañía pone en él, con
la perspectiva de que el equipo de proyecto pueda hacer un milagro. La expresión marcha de la muerte evoca
imágenes de los miembros del equipo cansados y caminando penosamente a lo largo de kilómetros y kilómetros,
sin final o posibilidad de conclusión exitosa a la vista. Marcha de la muerte se define como proyectos “cuyos
parámetros son superiores a lo normal en al menos 50%.” En términos prácticos, eso puede significar:
• Que el cronograma se ha comprimido a menos de la mitad de la cantidad estimada por un proceso de
estimación racional (por ejemplo, la programación sugiere que debería tomar un año completar el pro-
yecto, pero la alta gerencia la reduce a seis meses).
• Que el personal del equipo de proyecto se ha reducido a la mitad del número que normalmente se
asigna a proyectos de este tamaño y alcance (por ejemplo, el gerente de proyectos necesita que se le
asignen 10 personas, y en su lugar se le dan solo 5).
5.4  Reporte del alcance 167

• Que el presupuesto y otros recursos necesarios se recortan a la mitad (por ejemplo, como resultado de
la reducción de personal y otros ejercicios de reducción de costos en la empresa, todos esperan “hacer
más con menos,” o para obtener el contrato se requirió hacer una oferta competitiva que cuando el
humo se disipó, la empresa que ganó el proyecto lo hizo a un precio tan bajo que no puede contratar
suficiente personal para realizar el trabajo).
El resultado de cualquiera o todas estas condiciones de partida es prácticamente una garantía de que el pro-
yecto fracasará. La prevalencia de los proyectos de marcha de la muerte lleva a formularse esta pregunta: ¿por
qué los proyectos de marcha de la muerte son tan comunes y por qué siguen ocurriendo? De acuerdo con la
investigación, hay una serie de razones:
1. Políticas—el proyecto puede ser el resultado de una lucha de poder entre dos ambiciosos ejecutivos, o
puede haber sido creado para fallar como una forma de vengarse de algún directivo. En estos casos, el
gerente de proyectos se ve atrapado en la zona de guerra.
2. Promesas ingenuas hechas por ejecutivos de marketing o gerentes de proyectos sin experiencia—la falta
de experiencia puede dar lugar a todo tipo de promesas, incluidas las que son imposibles de cumplir.
Con el fin de impresionar al jefe, un nuevo gerente de proyectos puede prometer más de lo que puede
cumplir. Los gerentes de marketing que se ocupan de las ventas y la forma de mejorarlas pueden pensar:
“¿Qué es un poco de promesa exagerada, si se cierra el trato?”
3. Ingenuo optimismo de la juventud—un técnico que sea ambicioso y un día se sienta particularmente
arrogante puede hacer promesas exageradas que resultan metiéndose rápidamente en la cabeza de los
miembros del equipo del proyecto. El optimismo no sustituye la planeación cuidadosa.
4. La mentalidad de “puesta en marcha” de empresas emprendedoras incipientes—las empresas
en arranque vienen cargadas con la energía, el entusiasmo y una actitud agresiva de ponerse en
marcha. Cuando esa mentalidad se traduce en proyectos, sin embargo, pueden surgir problemas.
Planteamientos emprendedores para la gerencia de proyectos pueden ignorar la planeación clave y la
preparación detallada previa que ningún gerente de proyectos con experiencia sacrificaría.
5. La mentalidad “Infantes de Marina”: programadores verdaderos no necesitan dormir—esta actitud
hace hincapié en la bravuconada como un sustituto para la evaluación. El horario o el presupuesto hipe-
roptimista no es un accidente, sino una manifestación deliberada de esta actitud agresiva: si no puede
manejarlo, usted no pertenece aquí.
6. La fuerte competencia provocada por la globalización—la aparición de nuevos competidores internacionales
a menudo viene como una sorpresa muy desagradable cuando se experimenta por primera vez. Muchas
empresas responden con movimientos radicales que empujan a rápidos avances técnicos o a “ponerse al
día” en los comportamientos, lo que resulta en numerosos nuevos proyectos de marcha de la muerte.
7. Fuerte competencia provocada por la aparición de nuevas tecnologías—como nuevas oportunidades
emergen de las nuevas tecnologías, algunas empresas saltan a ellas con entusiasmo, sin compren-
der primero sus capacidades, escalabilidad para grandes proyectos y limitaciones. El resultado es un
juego sin fin de aprovechar las “oportunidades,” sin comprenderlas plenamente, o sin considerar la
curva de aprendizaje para el uso de las nuevas tecnologías.
8. La intensa presión causada por las regulaciones gubernamentales inesperadas—se producen proyectos
marcha de la muerte impuestos por el gobierno a través de un fallo de la alta gerencia para anticipar
nuevas normas o mandatos o, peor aún, se reconoce que están por llegar, pero se posterga cualquier
esfuerzo para cumplir con ellos hasta que ya se han establecido plazos. Por ejemplo, nuevas leyes de
control ambiental pueden dar lugar a enormes proyectos con plazos inminentes, pero la empresa deja
los esfuerzos para autorregularse para el último momento.
9. Crisis inesperadas o no planificadas—cualquier número de crisis se puede prever con suficiente pla-
neación anticipada. Ejemplos de crisis que pueden afectar gravemente la ejecución del proyecto son
la pérdida de personal clave del equipo de proyecto a mitad de camino del proyecto o la quiebra de
un proveedor clave. Algunas crisis, por supuesto, son impredecibles por definición, pero con mucha
frecuencia la crisis que destruye todo el trabajo realizado en un proyecto se podría anticipar con un
poco de previsión. El largo camino de vuelta de estos desastres dará lugar a muchas marchas de la
muerte.
Los proyectos marcha de la muerte no se limitan a la industria de IT. En efecto, al considerar la lista de
razones por las que ocurren las marchas de la muerte, podemos ver efectos similares en numerosos proyectos
en diferentes industrias. El resultado final suele ser el mismo: una pérdida de esfuerzos masivamente inverti-
dos en proyectos creados para fallar. Las implicaciones son claras: para evitar el establecimiento de las bases
para futuros proyectos de marcha de la muerte, tenemos que comenzar con el final en mente y preguntarnos:
¿los objetivos y las condiciones (presupuesto, personal asignado y cronograma) son propicios para el éxito del
proyecto o estamos simplemente sembrando las semillas de una catástrofe inevitable?16
168 Capítulo 5  •  Gerencia del alcance

5.5  SISTEMAS DE CONTROL


Una pregunta que cabe hacerse es: “¿Cómo puede un proyecto llegar a retrasarse un año?” La respuesta es:
“Un día a la vez.” Cuando no prestamos mucha atención al desarrollo de un proyecto, cualquier cosa puede
(y por lo general) sucederá. Este es un aspecto clave del control del proyecto en la gerencia del alcance. Los
sistemas de control son vitales para asegurar que cualquier cambio en la línea de base del proyecto se lleve
a cabo de manera sistemática y exhaustiva. Los gerentes de proyectos pueden utilizar una serie de tipos de
sistemas de control de proyectos para realizar un seguimiento del estado de sus proyectos, entre ellos los
siguientes:17
• Control de la configuración  incluye procedimientos que controlan alcances emergentes del proyecto
contra la línea base inicial del alcance. ¿El proyecto está siguiendo sus metas iniciales, o está deján-
dolas a la deriva con cambios de estado o nuevas circunstancias que alteran la intención original del
proyecto?
• Control de diseño  que se refiere a sistemas de control del alcance, cronograma y los costos durante la
fase de diseño del proyecto. Chrysler desarrolló una plataforma de equipos de diseño (platform design
teams: PDT), integrada por miembros de los departamentos funcionales, para asegurarse de que los
nuevos diseños de automóviles puedan evaluarse inmediatamente por expertos en ingeniería, produc-
ción y marketing. Se encontró que esta retroalimentación instantánea elimina el tiempo que se había
perdido cuando los diseños se consideraban inviables por ingeniería en algún momento más adelante,
durante el desarrollo del automóvil.
• Monitoreo de tendencias  es el proceso de seguimiento de los costos, cronogramas y recursos necesa-
rios estimados contra los planeados. El seguimiento de tendencias muestra desviaciones significativas
de las normas de cualquiera de estos parámetros importantes del proyecto.
• Control de documentos  asegura que los documentos importantes se compilan y difunden de manera
ordenada y oportuna. El control de documentos es una forma de asegurarse de que cualquier aspecto
contractual o legal se documenta y distribuye. Por ejemplo, el control de documentos aseguraría que
las actas de las deliberaciones de un comité de construcción en relación con un proyecto de un nuevo
edificio se reproducen y se envían a los grupos de supervisión adecuados.
• Control de adquisiciones  son sistemas de monitoreo utilizados para adquirir el equipo, materiales o
servicios necesarios para el desarrollo y ejecución del proyecto.
• Control de especificaciones  garantiza que las especificaciones del proyecto se preparan con claridad,
se comunican a todas las partes interesadas y se cambian solo con la debida autorización.
Una de las funciones más importantes del consejo de gerentes y de los equipos de proyectos es establecer y
mantener un nivel razonable de control (incluidas las líneas claras de autoridad) en el inicio de un proyecto. Quizá,
sorprendentemente, razonable aquí significa evitar la tentación de sobredesarrollar y sobrecontrolar los proyec-
tos. La capacidad de los gerentes de proyectos para gerenciar las actividades del día tras día puede obstaculizarse
por tener que manejar los excesivos informes del sistema de control, los cuales simplemente pueden ser dema-
siado papeleo. Por otro lado, es igualmente importante no devaluar los sistemas de control por ocupar demasiado
tiempo. Conocer los sistemas de control de proyectos adecuados para usar y la frecuencia para emplearlos puede
eliminar gran parte de estas conjeturas, cuando de retrasos o sobrecostos en los proyectos se trata. Por ejemplo,
un proyecto de un gran edificio de oficinas recientemente reunió a un equipo de proyecto integrado por grupos
y contratistas relacionados con el diseño arquitectónico, calefacción, ventilación y aire acondicionado (CVAC),
trabajo eléctrico y de plomería, concreto y acero y gerencia de las instalaciones. Durante las primeras reuniones, el
equipo del proyecto de construcción combinado llegó a un alcance claro, un sistema de control simplificado para
el proyecto que incluía un proceso de reportes, control de tendencias, de configuración y de especificaciones como
elementos claves en el ciclo de revisión del proyecto. Debido a que varios de los contratistas independientes tenían
una larga historia de trabajar juntos y habían construido un nivel de confianza mutuo, ellos definieron que los
procesos de control poco estrictos serían preferibles. En este ejemplo, el equipo buscó un equilibrio en los procesos
de control de proyectos entre los errores individuales, por excesivo o inexistente control.

Gerencia de la configuración
El PMBOK define la gerencia de la configuración como “un sistema de procedimientos que monitorea alcan-
ces emergentes del proyecto contra la línea base del alcance. Se requieren documentación y aprobación de la
gerencia de cualquier cambio en la línea base.” La línea base se define como el alcance del proyecto fijado en
un punto específico en el tiempo, por ejemplo, la fecha de inicio programada para el proyecto. La línea base,
5.5  Sistemas de control 169

por tanto, se ve como la configuración del proyecto. Recuerde que la línea base del alcance es simplemente
una descripción resumida del contenido original del proyecto y del producto final, incluidos los datos de
limitaciones de tiempo y presupuesto. Como resultado, en términos simples, la gerencia de la configuración
se refiere al hecho de que los proyectos por lo general constan de componentes, los cuales contribuyen a la
funcionalidad del proyecto. Estas piezas deben desarrollarse individualmente y ensambladas o configuradas
finalmente, para producir el producto final o servicio. El papel del diseño, fabricación y montaje de estos
componentes pertenece a la gerencia de la configuración. Sin embargo, debido a que este proceso a menudo
requiere varias iteraciones, ajustes y correcciones para conseguir el proyecto correcto, en la práctica, la geren-
cia de la configuración es la gerencia y el control del cambio sistemático del proyecto.18
La gerencia de los cambios del proyecto se lleva a cabo eficazmente al comienzo del proyecto, cuando
los planes y el alcance del proyecto se articulan por primera vez. ¿Por qué se desearía comenzar a gerenciar el
cambio en el punto donde se define cuidadosamente un proyecto? La respuesta es que la necesidad de hacer
cambios significativos en los proyectos suele ser una parte reconocida del proceso de planeación. Algunos cam-
bios se realizan como resultado de una necesidad cuidadosamente reconocida; otros surgen casi por accidente
durante el desarrollo del proyecto. Por ejemplo, podemos descubrir en algún momento durante la ejecución del
proyecto que determinadas especificaciones técnicas que hemos diseñado en el prototipo original pueden no
funcionar en determinadas condiciones (por ejemplo, en altas altitudes, en condiciones de humedad), que nos
obliga a hacer cambios en mitad del camino en razón de la funcionalidad requerida por el proyecto.
La gerencia de la configuración trabaja para formalizar el proceso de cambio tanto y lo antes posible en
la vida del proyecto, en lugar de dejar para después la realización de cambios de forma descoordinada. Se ha
sugerido que la necesidad de hacer cambios o ajustes en las especificaciones del proyecto se produce por una de
varias razones:19
• Errores de planeación inicial, ya sean tecnológicos o humanos.  Muchos proyectos implican riesgos tec-
nológicos. A menudo es imposible determinar con precisión todos los problemas o barreras tecnológicas.
Por ejemplo, la Marina de Estados Unidos y la unidad del Cuerpo de Marines impulsó la creación del
Osprey, un avión de hélice con despegue vertical, el cual dio lugar a una serie de problemas técnicos ines-
perados, incluidos algunos accidentes trágicos durante las pruebas de prototipo. La ingeniería inicial no
predijo (y tal vez no habría podido predecir) los problemas que surgirían con esta nueva tecnología. Por
tanto, muchos proyectos requieren cambios sobre la marcha a las especificaciones técnicas, en el momento
que presenten problemas, u otras dificultades inesperadas, que no se pueden resolver con los recursos
existentes. Los errores de planeación también pueden ser errores humanos o la falta de conocimiento del
proceso de desarrollo. En el caso de causas no técnicas para el cambio, la reconfiguración puede ser un
simple ajuste de los planes originales para darles cabida a las nuevas realidades de los proyectos.
• Conocimiento adicional del proyecto o de las condiciones ambientales.  El equipo de proyecto o un
grupo de interesados clave, como el cliente, pueden entrar en un proyecto solamente para descubrir
que las características específicas del proyecto o de la empresa, el entorno económico o natural, requie-
ren cambios en mitad del camino. Por ejemplo, el diseño técnico de un equipo de perforación de petró-
leo en aguas profundas puede tener que modificarse de manera significativa por el descubrimiento de
las características de la naturaleza, de las corrientes de agua, de las tormentas, de las formaciones del
terreno bajo el agua, u otras características ambientales imprevistas.
• Mandatos incontrolables.  En algunas circunstancias, los acontecimientos ocurren fuera del control
del equipo del proyecto y deben tenerse en cuenta a medida que avanza el proyecto. Por ejemplo, una
directiva gubernamental para la seguridad de los pasajeros establecidos por la Unión Europea en 2001
obligó a Boeing Corporation a rediseñar las funciones de salida de su nuevo avión 777, lo que retrasó
temporalmente su introducción y venta del proyecto a aerolíneas extranjeras.
• Solicitudes del cliente.  Cuando los clientes de un proyecto intentan hacer frente a nuevas necesidades
con alteraciones significativas, a medida que el proyecto evoluciona, es una situación muy común. En el
desarrollo de software, por ejemplo, un cliente al tomar el papel de usuario potencial podría enumerar
varias quejas, solicitudes, nuevas características y funciones, y así sucesivamente, cuando se expone a una
actualización prevista de software. A menudo, los proyectos de IT se ejecutan fuera del cronograma, por-
que los usuarios continúan presentando listas de nuevos requerimientos o solicitudes de cambio.
La gerencia de la configuración probablemente se remonta a las técnicas de control de cambios ini-
ciados por la comunidad de defensa de Estados Unidos en la década de 1950. Los contratistas de defensa
cambiaban rutinariamente la configuración de varios sistemas de armas, a petición de los grupos guber-
namentales, especialmente las Fuerzas Armadas. Sin embargo, al efectuar estos cambios, poco del proceso
170 Capítulo 5  •  Gerencia del alcance

Paso Acción
1. Identificación de la configuración 1. Desarrollar un desglose del proyecto hasta el nivel necesario de la
definición.
2. Identificar las características de los componentes de la descom-
posición y del total del proyecto.
2. Revisión de la configuración Reunirse con todos los interesados del proyecto de acuerdo con la
definición actual del proyecto.
3. Control de la configuración 1. Si se logra un acuerdo, repetir los tres primeros pasos, desarrollando
la descomposición y la especificación adicional, hasta que se defina
el proyecto.
2. Si no se llega a un acuerdo:
  • Volver a la configuración como se acordó en el comentario ante-
rior y repetir los pasos 1, 2 y 3 hasta llegar a un acuerdo; o
  •  Cambiar la última especificación obtenida por un proceso de control de
cambios para que coincida con lo que la gente piensa que debe ser.
4. Determinación del estado La memoria de las configuraciones actuales y de todas las anteriores se
debe mantener por si no se llega a un acuerdo en algún momento; el
equipo puede pasar de nuevo a una configuración anterior y reanudar
desde allí. También, se debe mantener la memoria de la configuración
de todos los prototipos.

CUADRO 5.6  Las cuatro etapas de la gerencia de la configuración


Fuente: © Turner, R. (2000), “Managing scope-configuration and work methods,” en Turner, R. (Ed.), Gower Hand-
book of Project Management, 3rd ed. Aldershot, UK: Gower.

sería documentado o trazable, por lo que, cuando se introdujeron nuevos sistemas de armas, las Fuerzas
Armadas encontraron difícil repararlos y mantenerlos. El pobre mantenimiento de registros condujo a cana-
les de comunicación deficientes con los contratistas relevantes cuando se presentaban problemas o solici-
tudes de modificación. Como resultado, el Departamento de Defensa rutinariamente consideró necesario
emitir órdenes de solicitud de cambio generales que retrasaron su capacidad para efectuar las correcciones
oportunamente. A mediados de la década, después de mucha frustración (y gastos), el Departamento de
Defensa finalmente emitió una orden que obligaba a todas las organizaciones que suministran los sistemas al
Gobierno a demostrar un control integral de cambios y documentación del proceso.20
El cuadro 5.6 presenta las cuatro etapas en la gerencia de configuración, incluidas las tareas por realizar
en cada una de ellas.21

5.6  CIERRE DEL PROYECTO


La gerencia efectiva de alcance también incluye la planeación adecuada para la terminación de un proyecto.
Aunque el proceso efectivo de terminación de los proyectos se analizará en el capítulo 14, es útil reflexionar
sobre el hecho de que, incluso desde cuando se planea un proyecto, se debe prever la conclusión del pro-
yecto. La etapa de cierre del proyecto requiere que los gerentes de proyectos consideren los tipos de regis-
tros e informes que ellos y sus clientes necesitan en la terminación del proyecto.22 Cuanto más temprano
se tomen estas decisiones, será más útil la recolección de la información durante el desarrollo del proyecto.
La información de cierre puede ser importante: (1) en caso de controversias contractuales después de que
el proyecto se ha completado, ya que con registros completos del proyecto es menos probable que la orga-
nización se responsabilice por presuntas violaciones; (2) como una herramienta de entrenamiento útil para
el análisis posproyecto, ya sea éxito o fracaso; y (3) para facilitar las tareas de auditoría del proyecto porque
muestra el flujo de entrada y salida de las diversas cuentas del proyecto.
Un líder de proyectos puede decidir incluir lo siguiente en la documentación de cierre:

• Registros históricos documentación del proyecto que pueda utilizarse en la predicción de tenden-
cias, análisis de viabilidad y resaltar las áreas problemáticas para futuros proyectos similares.
Resumen 171

• Análisis posproyecto documentación del proyecto que pueda utilizarse en la predicción de tenden-
cias, análisis de viabilidad y resaltar las áreas problemáticas para futuros proyectos similares.
• Cierre financiero análisis contable de cómo se emplearon los fondos en el proyecto.

Una de las lecciones más importantes para los gerentes de proyectos exitosos es “comenzar con el final en
mente.” Metas claras al comienzo de un proyecto harán la conclusión clara. El cierre del proyecto requiere
que los gerentes consideren a priori los tipos y cantidades de información que se deben recopilar continua-
mente durante el desarrollo del proyecto, basándose en un sólido sistema de seguimiento y archivo. De esta
manera, cuando el proyecto está en su cierre, no se desperdicia tiempo luchando por obtener los registros
viejos y demás información que se necesita pero que falta.
Las metas de un proyecto son solo un sueño hasta que se escriben. Hasta que los planes del proyecto
se presentan, sus fines especificados, sus limitaciones y sus resultados anticipados, un proyecto no es más
que la esperanza de éxito de una organización. La gerencia del alcance es el proceso sistemático de convertir
estos sueños en realidad desarrollando formalmente los objetivos del proyecto. Como un faro, un docu-
mento de alcance exhaustivo ilumina el camino hacia la conclusión del proyecto, incluso mientras el equipo
pudiera lanzarse sobre las olas de las numerosas crisis y preocupaciones. Tanto como la luz siga brillando,
el gerente de proyectos trabajará para desarrollar y mantener los diversos elementos del alcance del pro-
yecto, y la probabilidad de una conclusión exitosa del proyecto será fuerte.

Resumen
1. Comprender la importancia de la gerencia del en capacidad de comenzar a moverse más allá del pro-
alcance para el éxito del proyecto.  En este capítulo yecto como concepto y abordarlo como un conjunto
se examinó el papel de la gerencia del alcance del pro- de actividades determinadas, con personal responsa-
yecto como una técnica de planeación. La gerencia del ble asignado.
alcance del proyecto es la elaboración detallada del plan La autorización de trabajo, el tercer elemento de
del proyecto para especificar el contenido del trabajo, la gerencia del alcance del proyecto, se refiere al proceso
los resultados del proyecto, las actividades que se deben de sanción de todo el trabajo del proyecto. Este paso
realizar, los recursos utilizados y los estándares de cali- puede implicar la formulación de las obligaciones con-
dad que deben mantenerse. Los seis pasos en la crea- tractuales con los vendedores, proveedores y clientes.
ción de un procedimiento de gerencia del alcance del El reporte del alcance del proyecto se refiere a
proyecto son el desarrollo conceptual, la declaración cualquier sistema de control y documentación que se
del alcance, la autorización de trabajo, los reportes del utilizará para evaluar el estado general del proyecto.
alcance, sistemas de control y el cierre del proyecto. Ejemplos de reportes del alcance incluyen la creación
El desarrollo conceptual es el proceso de elegir de documentos de control y el seguimiento del presu-
el mejor método para lograr las metas del proyecto. El puesto y del cronograma.
desarrollo conceptual del proyecto le permite al gerente Los sistemas de control, incluida la gerencia de la
de proyectos iniciar el proceso de transición del proyecto configuración, se refieren a procesos establecidos para el
como un sueño al proyecto como una meta o conjunto seguimiento del estado actual del proyecto, comparando
de objetivos específicos. Enunciación de los problemas, lo real con las líneas base proyectadas y ofrecer medidas
recopilación de la información, limitaciones identifica- correctivas para poner el proyecto de nuevo en marcha.
das, alternativas de análisis y objetivos finales del proyecto Por último, la fase de cierre del proyecto repre-
se crean durante el desarrollo conceptual. senta la mejor voluntad del equipo de proyectos en
La declaración del alcance es una definición cuanto a los materiales e información necesarios
completa de todos los parámetros necesarios para que para garantizar una transferencia, sin problemas, del
el proyecto tenga éxito. En el desarrollo efectivo de la proyecto a sus clientes.
declaración del alcance, debe considerarse un número 2. Comprender la importancia de desarrollar la decla-
de elementos, pero tal vez el fundamental es la EDT. El ración del alcance.  El enunciado del alcance del
proceso de división del trabajo le da al equipo del pro- proyecto refleja los mejores esfuerzos del equipo de
yecto la posibilidad de crear una jerarquía de priorida- proyectos para crear la documentación y aprobación
des de las actividades basadas en la creación de paque- de todos los parámetros del proyecto antes de iniciar
tes de trabajo, tareas y subtareas como bloques básicos la fase de desarrollo. Esta declaración es una oportu-
para completar el proyecto. Cuando esto se combina nidad clara para “concretar” los elementos del pro-
con una matriz de asignación de responsabilidades yecto y lo que se pretende llevar a cabo, así como para
(RAM) clara, el gerente de proyectos y el equipo están identificar las características claves del proyecto. Los
172 Capítulo 5  •  Gerencia del alcance

elementos de la declaración del alcance incluyen: (1) el asignárselo a los responsables de los paquetes de tra-
establecimiento de los criterios de meta: la definición de bajo. Los presupuestos de estas actividades se asignan
lo que va a demostrar el éxito del proyecto y los filtros directamente a las cuentas de los departamentos encar-
de decisión para evaluar los entregables; (2) el desarro- gados del trabajo del proyecto.
llo del plan de gerencia del proyecto: determinación de 4. Desarrollar una matriz de asignación de responsabi-
la estructura para el equipo del proyecto, las normas y lidades para un proyecto.  La matriz de asignación
los procedimientos fundamentales que se mantendrán, de responsabilidades (RAM), a veces conocida como
y los sistemas de control para monitorear el esfuerzo; (3) un gráfico lineal de responsabilidad, identifica el per-
el establecimiento de la EDT: división del proyecto en sonal del equipo del proyecto directamente responsa-
subetapas de componentes, con el fin de establecer las ble de cada tarea en el desarrollo del proyecto. La RAM
relaciones críticas entre las actividades del proyecto; y identifica a donde pueden dirigirse los miembros del
(4) la creación de la línea base del alcance: proporcionar equipo responsables, en busca de apoyo para la realiza-
una breve descripción de cada componente de la meta ción de las tareas, quien debe notificarse del estado de
del proyecto, incluidos el presupuesto y la información ejecución de las tareas y de todos los requisitos de cie-
de la programación de cada actividad. rre de sesión. La meta de la RAM es facilitar la comu-
3. Elaborar una estructura de desglose del trabajo para nicación entre el personal del equipo del proyecto para
un proyecto.  La EDT es un proceso que define el minimizar las interrupciones de transición, a medida
alcance de un proyecto al descomponer su misión que el proyecto se realiza. Un beneficio adicional de la
general en un conjunto coherente de tareas sincro- RAM es hacer que la coordinación entre los gerentes
nizadas, cada vez más específicas. Definida como una de proyectos y los jefes de departamentos funciona-
“agrupación de elementos orientada a los entregables les sea más fácil, cuando trabajan para hacer el mejor
del proyecto que organiza y define el alcance total del uso del personal que puede asignarse al proyecto por
proyecto,” la EDT se convierte en la herramienta de periodos.
organización más importante para que el equipo pueda 5. Describir los papeles de la gerencia de la configura-
preparar sus tareas. ción y de los cambios, para evaluar el alcance del pro-
La EDT sirve a propósitos principales: (1) hace eco yecto.  Se producen cambios significativos del proyecto
de los objetivos del proyecto; (2) es el organigrama para por una serie de razones, que incluyen: (1) errores inicia-
el proyecto; (3) crea la lógica para el seguimiento de cos- les de planeación, ya sean tecnológicos o humanos; (2)
tos, cronograma y de las especificaciones de desempeño conocimiento adicional de las condiciones ambientales
para cada elemento del proyecto; (4) se puede utilizar del proyecto; o (3) mandatos incontrolables; y (4) solici-
para comunicar el estado del proyecto; (5) se puede uti- tudes de cliente.
lizar para mejorar la comunicación global del proyecto; Las cuatro etapas de la gerencia de la configuración
y (6) demuestra cómo se controlará el proyecto. La lógica son: (1) identificación de la configuración, es decir, des-
de la EDT es subdividir los entregables del proyecto en glose del proyecto e identificación de las especificaciones
subniveles cada vez más específicos para identificar todas de sus componentes; (2) revisión de la configuración, o
las actividades. La terminología común es identificar pri- sea, reuniones con los interesados de acuerdo con la defi-
mero la totalidad del proyecto, a continuación, los prin- nición del proyecto; (3) control de la configuración, es
cipales entregables y, finalmente, los paquetes de trabajo decir, seguir el acuerdo con los interesados y desarrollar
que se deben conformar para completar cada entregable. aún más la descomposición y las especificaciones; y (4)
En estrecha relación con la EDT está la estruc- determinación del estado, o sea, el mantenimiento de la
tura de desglose de la organización (EDO), que les memoria de todas las configuraciones actuales y anterio-
permite a las empresas definir el trabajo por realizar y res como referencia.

Términos clave
Alcance del proyecto (p. 148) Cuentas de control de Estructura de desglose de Línea base (p. 168)
Autorización de trabajo costos (p. 160) la organización (EDO) Línea base del alcance
(p. 164) Declaración del alcance (p. 160) (p. 154 )
Cierre del proyecto (p. 170) (p. 153) Estructura de desglose del Matriz de asignación
Códigos EDT (p. 158) Declaración de trabajo trabajo (EDT) (p. 155 ) de responsabilidades
Contratos de costo (DDT) (p. 151) Gerencia de la (RAM) (p. 162)
incrementado (p. 165 ) Desarrollo conceptual configuración (p. 168) Paquetes de trabajo (p. 157)
Contratos llave en mano (p. 149) Gerencia del alcance (p. 148) Reporte del alcance (p. 165)
(p. 165) Entregables (p. 153 ) Hitos (p. 164 ) Sistemas de control (p. 168)
Estudio de caso 5.1 173

Preguntas para discusión


1. ¿Cuáles son los principales beneficios de desarrollar un análisis 5. Argumente a favor de los mecanismos de información del alcance.
exhaustivo del alcance del proyecto? Como mínimo, ¿qué tipos de informes considera usted necesarios
2. ¿Cuáles son las características claves de un paquete de trabajo? para el control de la documentación de un proyecto? ¿Por qué?
3. Elabore una estructura de desglose de trabajo para un proyecto 6. ¿Cuál es el propósito principal de la gerencia de la configuración?
de trabajo final o de otro proyecto relacionado con la universi- Según su opinión, ¿por qué esta se ha vuelto cada vez más popu-
dad en la que estudia. ¿Cuáles son los pasos de la EDT? ¿Puede lar en los últimos años como parte del proceso de gerencia de
identificar tareas secundarias en cada tarea? proyectos?
4. ¿Cuáles son los beneficios del desarrollo de una matriz de asig- 7. ¿Cuál es la lógica de desarrollo de un plan de cierre del pro-
nación de responsabilidades (RAM) para un proyecto? yecto, incluso antes de comenzar el proyecto?

Problemas
1. Prepare un proyecto para la clase. Use como modelo uno de los EDT para el proyecto. ¿Cuáles son los pasos claves, incluidos
siguientes: los paquetes de trabajo, las tareas y las subtareas relacionados
a. Proyecto de construcción con el proyecto?
b. Proyecto de desarrollo de software 2. Con el proyecto del problema 1, elabore una matriz de asig-
c. Eventos de gerencia de proyectos (por ejemplo, un banquete nación de responsabilidades (RAM); para ello, identifique al
de premiación) menos seis miembros ficticios del equipo del proyecto.
d. Un proyecto de desarrollo de nuevos productos 3. Investigue un proyecto real a través de recursos de la biblioteca
Desarrolle una declaración de trabajo (DDT) para el proyecto, o de internet y desarrolle una breve declaración sobre el alcance
utilizando un formato con (1) antecedentes, (2) tareas, (3) obje- del proyecto, una EDT general y cualquier otra información
tivos, (4) enfoque, (5) fuente de entrada. Luego, elabore una relacionada con la gerencia del alcance de este proyecto.

Estudio de caso 5.1


Frontera virtual de Boeing
El 14 de enero de 2011, la secretaria de Homeland Security, en las proximidades de Canadá. El problema se complica
Janet Napolitano hizo este pronunciamiento: “El proyecto por los tamaños de las fronteras involucradas. La frontera
frontera virtual se cancelará oficialmente.” En su declara- México/Estados Unidos tiene cerca de 2,000 millas, en
ción, al explicar la decisión, Napolitano mencionó la difi- gran parte de terrenos baldíos desérticos y zonas inhós-
cultad de crear un sistema de seguridad unificado y total- pitas y remotas. El establecimiento de cualquier tipo de
mente integrado y se comprometió a “seguir un nuevo seguridad en la frontera, a raíz de los ataques del 9/11, es
camino hacia adelante.” Lo que no expresó fueron las una necesidad nacional, una tarea difícil y de enormes
razones que llevaron a la decisión final: lucharon contra proporciones.
un sistema técnico muy complicado que no funcionaba y El Departamento de Homeland Security (Depart­
generaba costos excesivos. ment of Homeland Security: DHS), organizado después
El cruce ilegal a Estados Unidos a lo largo de la fron- de los atentados contra las torres del World Trade Center,
tera con México ha alcanzado proporciones epidémicas carga con la responsabilidad de la seguridad en todas las
en los últimos años. El temor del contrabando de drogas, fronteras y puntos de entrada ilegal en Estados Unidos,
los inmigrantes ilegales y posibles incursiones terroristas en cooperación con la Aduana y Protección Fronteriza.
han hecho de la seguridad nacional uno de los “puntos Como una parte de su mandato, el DHS ha desarro-
sensibles” del ámbito político, tanto en Washington, DC, llado planes para la creación de una frontera más segura
como en los estados ubicados en la frontera sur, así como y estable con México, para impedir el flujo continuo de
(continúa)
174 Capítulo 5  •  Gerencia del alcance

inmigrantes indocumentados, drogas y posibles terroris- de hecho, el muro virtual falló en una serie de pruebas
tas. En la primera etapa de este proceso, el DHS propuso iniciales, lo cual retrasó significativamente el despliegue
un proyecto de sellar física y electrónicamente el tramo completo del Project 28.
de desierto entre Estados Unidos y México con un con- Infortunadamente, nunca se resolvieron estos pro-
trato multimillonario llamado Secure Border Initiative blemas técnicos y de coordinación. Casi tres años después
Net (SBInet). En mayo de 2006, el presidente Bush llamó de la prueba inicial, en una sección del muro, SBInet le
al SBInet “la iniciativa de seguridad fronteriza tecnoló- había costado al Gobierno 672 millones de dólares, sin final
gicamente más avanzada en la historia estadounidense.” a la vista. Aunque se preveía que el costo total del proyecto
Un tramo de 28 millas de desierto, centrado en Nogales, era 1,100 millones, los grupos de vigilancia del Congreso
Texas, iba a ser la fase piloto de un proyecto que even- argumentaron que el costo final del proyecto podría ele-
tualmente se utilizaría para vigilar y controlar unas 6,000 varse a más de 30,000 millones. Los costos, de hecho, eran
millas de frontera con México y Canadá. un punto delicado en el proyecto desde el momento en que
A finales de 2006, Boeing fue seleccionado como se negociaba. Originalmente se prometió completar SBInet
el principal contratista del proyecto SBInet. Aunque por 1,100 millones, los estimativos revisados de Boeing fue-
más conocida por sus sistemas de armas militares, la ron 2,500 millones y luego, tan solo unos meses más tarde,
Unidad Integrada de Sistemas de Defensa de Boeing se 8,000 millones. Este rápido escalamiento de los costos pro-
hizo responsable de la coordinación general de un sis- yectados finalmente provocó una audiencia del Comité de
tema masivo de torres, dispositivos de escucha, sensores Supervisión del Congreso, en la que el congresista William
de movimiento, cámaras y radares para detectar y ayudar LacyClay, un demócrata de Misuri, le pidió información
a detener a los ilegales que crucen la frontera. De hecho, a un ejecutivo de Boeing sobre los excesivos costos y la
el gobierno de Estados Unidos decidió subcontratar todo ampliación de la duración del contrato, diciendo: “Usted
el proyecto con empresas privadas. El único papel del hace una oferta en estos contratos y luego regresa y dice,
Gobierno iba a ser como la fuerza responsable de la deten- ‘Oh, necesitamos más tiempo. Cuesta más del doble’. ¿Está
ción de las personas detectadas inicialmente por el SBInet. usted jugando con los contribuyentes? ¿O jugando con la
“Prácticamente, el Gobierno está subcontratando todos DHS?“Mientras tanto, acosado por problemas continuos,
los detalles con contratistas privados,” dijo el congresista Boeing también había revisado sus estimativos para una
demócrata por California Henry Waxman. “El Gobierno fecha de terminación en 2016, más de siete años después de
les confía a contratistas privados el diseño y construcción la fecha del plan original.
de los programas, e incluso la supervisión de estos.” Una de las principales preocupaciones era la estruc-
En pocas palabras, el sistema utiliza una cadena de tura de gerencia piramidal que los críticos dijeron con-
torres de 100 metros de altura, cada una escanea un radio dujo a sobrecostos y mala calidad en otros grandes pro-
de 360 grados en una distancia de 10 millas. Sensores de yectos. Los críticos señalaron que los múltiples niveles de
radar en tierra también intentan detectar huellas, bicicle- subcontratación permitidos a Boeing en cada fase habían
tas y vehículos. La primera fase de 20 millones de dólares, creado un conflicto de intereses debido a que la compañía
llamada Project 28 por la longitud de la parte del desierto también tenía a cargo la supervisión. “La última vez que
que se supone cubriría, debía estar terminada a mediados vi este tipo de modelo para la gerencia de un proyecto fue
de junio de 2007. Boeing seleccionó más 100 subcontra- en el ´Big Dig´de Boston,” dijo el congresista demócrata
tistas para construir diversos componentes del sistema y de Massachusetts, Steven Lynch, refiriéndose al mega-
con sus gerentes de proyectos mantenía control total del proyecto de la carretera que incluía un túnel subterráneo
proceso de desarrollo. Infortunadamente, la estructura de 3.5 kilómetros en Boston. “Esto es exactamente lo que
era difícil de manejar, y el proyecto se veía comprometido hicieron. Ellos fusionaron las funciones de supervisión
por el gran número de elementos y sistemas técnicos dife- con las de ingeniería y construcción. Todos estaban en la
rentes que Boeing estaba tratando de integrar. El desafío misma tienda. Nadie estaba mirando hacia el propietario,
técnico para la integración de sistemas, incluidos torres de que en este caso es el contribuyente estadounidense. Este
vigilancia, sensores, radares y cámaras especializadas iba es un modelo terrible y veo un montón de ellos. En gene-
más allá de lo que Boeing había intentado antes. Como ral, cuando este modelo se pone en práctica, vemos fraca-
lo señaló un artículo: “La integración exitosa de compo- sos colosales y enormes excesos de costos.”
nentes complejos es un riesgo sustancial en cualquier pro- Es cierto que los problemas que hundieron el pro-
yecto que contiene múltiples subsistemas complicados. yecto SBInet se complicaron y llegaron de varias fuen-
Los riesgos de integración son especialmente pronuncia- tes. Además de los retos técnicos de la gerencia de 100
dos en situaciones en las que la integración define esen- subcontratistas, todos obligados a proporcionar compo-
cialmente el proyecto, como este caso. El riesgo aumenta nentes críticos que Boeing debería integrar, el proyecto
aún más cuando los propios subsistemas consisten en tec- había sido rechazado efectivamente por la mayoría de
nología nueva o no probada.” Así, el reto era complicado; las agencias federales y grupos de vigilancia. Fue difícil
Estudio de caso 5.2 175

obtener información precisa del estado del proyecto dada la complejidad de la construcción del sistema. Asimismo,
la decisión del Gobierno de “subcontratar” la seguridad los agentes de la Border Patrol —las personas que estarían
fronteriza con contratistas privados. Como resultado, los implementando y confiando en el sistema todos los días—
investigadores del Congreso encontraron que los funcio- no fueron consultados sobre cuáles eran sus necesidades
narios de seguridad estaban simplemente parados, mien- reales.” Lieberman llegó a esta conclusión: “Desde cual-
tras Boeing proporcionaba información que estaba “llena quier perspectiva, SBInet ha sido un fracaso, un ejemplo
de anomalías no explicadas, con datos no aptos para la clásico de un programa que se sobrevendió groseramente y
gerencia de contratistas y la supervisión efectiva.” Por otra se gerenció muy mal.”23
parte, muchos críticos cuestionaron la viabilidad de la
intención original del proyecto en sí, pues se preguntaban Preguntas
sobre la posibilidad de sellar efectivamente una frontera
que pasa por algunos de los terrenos más inhóspitos de 1. ¿Qué problemas ve usted que surgen de un proyecto
América del Norte. como SBInet en el que el Gobierno les permite a los
El senador Joe Lieberman, presidente del Senate contratistas determinar el alcance, gerenciar todas las
Homeland Security and Governmental Affairs Committe, relaciones con los contratistas y decidir cómo com-
criticó mordazmente al proyecto, en razón del testimonio partir información sobre el estado del proyecto con
de Janet Napolitano, secretaria de Homeland Security, así: los órganos de control?
“U. S. Custom and Border Protection parece haber visto 2. Considere los siguientes dos argumentos: “El fracaso
la eficacia de Boeing —el contratista— como ‘Siga ade- de SBInet se debió a la mala gerencia del alcance”;
lante y haga lo que usted pueda hacer tan pronto como “SBInet fracasó por falta de vigilancia y control del
sea posible.’” Y añadió: “Sin metas y expectativas claras, proyecto.” Tome posición a favor de uno u otro y justi-
Aduanas y Protección Fronteriza y Boeing subestimaron fique su respuesta.

Estudio de caso 5.2


Proyecto del tren de alta velocidad de California
Con el anuncio de que California destinaría 4,300 millones Uno de los estados que más se beneficiaba de esta
de dólares para la construcción de un enlace ferroviario de 65 redistribución de dinero federal era California, con su
kilómetros entre las localidades de Borden y Corcoran, en el ambiciosa y para muchos imprudentes decisiones de apo-
valle central del estado, la búsqueda durante 20 años de una yar un proyecto de transporte masivo para unir sus ciuda-
línea de tren de alta velocidad finalmente está convirtiéndose des con un tren de alta velocidad. La historia de la unidad
en una realidad. La California High-Speed Rail Authority de CHSRA para crear trenes de alta velocidad es fascinante,
(CHSRA), establecida a mediados de la década de 1990, había con partidarios y críticos por igual. Como una parte del
perseguido siempre el objetivo de vincular el área metropoli- lanzamiento inicial del proyecto, CHSRA argumentó que el
tana de San Francisco Bay en el norte, a las ciudades de Los sistema daría lugar a múltiples beneficios. Por un tiquete de
Ángeles y San Diego en el sur. Bajo la administración del ida de 55 dólares, los pasajeros de Los Ángeles podrían via-
presidente Obama, el gobierno federal destina dinero para jar a la zona de la bahía en menos de 3 horas o llegar a San
un paquete de estímulo que busca financiar iniciativas de tre- Diego en 80 minutos. Al estimar que 94 millones de pasa-
nes de alta velocidad en varios estados, includos Wisconsin, jeros podrían utilizar el sistema ferroviario cada año y que
Florida, Ohio, Illinois y California. La elección de gober- su desarrollo podría generar cientos de miles de puestos de
nadores republicanos en Ohio y Wisconsin condujo a un trabajo permanentes, CHSRA utilizó estas proyecciones
replanteamiento de los proyectos en esos estados, los cuales para ayudar a convencer a los votantes del estado, a fin de
rechazaron las subvenciones de capital inicial de Washington, aprobar una emisión de bonos por cerca de 10,000 millones
sospechosos de que los proyectos ferroviarios eran innecesa- y apoyar el proyecto de referéndum en 2008. Otras venta-
rios y probablemente estarían sujetos a enormes sobrecos- jas citadas por la organización incluían la reducción de la
tos, por lo cual los contribuyentes del estado finalmente se contaminación y del uso de combustibles fósiles mediante
harían responsables. Como resultado de ello, el secretario de la desviación de millones de personas a la línea del tren,
Transporte Ray La Hood recuperó 1,200 millones de dólares que de otra manera utilizarían el automóvil o el transporte
de estos estados para dirigirlos a otros 13 estados. aéreo para viajar entre las ciudades.
(continúa)
176 Capítulo 5  •  Gerencia del alcance

Con un costo estimado de al menos 43,000 millo- se encuentran cerca de la realidad (aunque son disputa-
nes de dólares, el proyecto global en primer lugar operaría dos por CHSRA), apuntan a un proyecto que no puede
trenes de hasta 220 millas por hora (mph) en un recorrido tener la esperanza de pagarse por sí mismo y pondría al
de 520 millas entre Anaheim y San Francisco. Extensiones estado, ya con problemas de liquidez, en un agujero finan-
a San Diego y Sacramento se construirían más tarde. Un ciero aún más grande. El estado, que evitó recientemente
total de 3,180 millones de dólares en fondos federales se una crisis presupuestaria al acordar un recorte de 15,000
han aprobado hasta el momento para la propuesta de tren millones de dólares en el gasto público, para emparejar
bala del estado, la mayor cantidad para cualquier proyecto el gasto federal, espera asegurar la inversión del sector
ferroviario pendiente en el país. Con los fondos estatales privado. Sin embargo, con el desempleo en California
de contrapartida, la cantidad disponible para la construc- pasando (recientemente a 12%), estas afirmaciones siguen
ción es de aproximadamente 5,500 millones, de acuerdo cuestionándose.
con CHSRA. Un estudio reciente realizado por tres economis-
Desde su aprobación, una serie de acontecimientos tas encontró el modelo de negocio CHSRA profunda-
han llevado a reconsiderar la conveniencia de proseguir mente defectuoso, y concluyeron que se basa demasiado
el proyecto ferroviario. Primero, basada en otros proyec- en subvenciones federales y no aborda adecuadamente
tos de alta velocidad ferroviaria, CHSRA ha revisado sus los riesgos que plantea la fluctuación del precio de los
proyecciones a la baja para el número de usuarios, lo cual tiquetes. “Cuando un inversionista analiza la afirma-
sugiere que el proyecto servirá a 39 millones de pasajeros ción de la CHSRA que dice que usted va a obtener un
en su décimo año de operación, que es alrededor de 40% excedente de 370 millones de dólares en el primer año
de su estimación original antes de obtener la aprobación de operaciones y 1,500 millones de dólares de beneficio
del financiamiento. Segundo, otro cambio en el modelo en el tercer año, mueve la cabeza y sonríe,” dijo William
de negocio original es que los precios de tiquetes proyec- Grindley, ex analista del Banco Mundial. “No pasa la
tados se han elevado a 105 dólares para un viaje de un solo prueba.” Este nuevo estudio califica los ingresos estima-
trayecto, aunque los críticos sugieren que los precios rea- dos por CHSRA de “irracionalmente optimistas.” Por
les, basados en datos del costo por milla comparables con ejemplo, un eje clave para lograr la sostenibilidad es la
Europa y Japón, probablemente sean de hasta 190 dólares. capacidad de CHRSA para asegurar miles de millones de
El tercero se refiere a la decisión de iniciar el proyecto con dólares en fondos adicionales del gobierno federal. Por
un enlace de 65 kilómetros entre dos comunidades peque- su parte, CHSRA reconoce la dependencia del proyecto
ñas del Valle Central, es decir, si el proyecto de tren de en el financiamiento adicional proveniente del gobierno
alta velocidad se ha diseñado específicamente para unir federal, pero cree que haciendo un esfuerzo de buena fe
las principales áreas metropolitanas, la primera etapa para producir una red ferroviaria viable es fundamental
piloto que se construirá a lo largo de la ruta comprende el para asegurar el dinero adicional.
segmento menos poblado de la línea. Esta decisión se per- A partir de ahora, se podría argumentar que el futuro
cibe mal no solo entre los críticos del tren, sino también del proyecto no es más que un “duelo” entre los economis-
entre los partidarios del tren, que reconocen la necesidad tas; sin embargo, no hay duda de que el futuro del tren de
de hacer una declaración más significativa, con el fin de alta velocidad de California es incierto. ¿El resultado será
responder a otras objeciones. “Es un desafío a la lógica un caso de las mejores intenciones por conocer las realida-
y al sentido común que el tren arranque y pare en zonas des económicas? Solamente el tiempo lo dirá.24
remotas que no tienen ninguna esperanza de alcanzar la
cantidad de pasajeros necesaria para justificar el costo
Preguntas
del proyecto,” escribió el representante Dennis Cardoza
(demócrata por California), en una carta dirigida al secre- 1. Evalúe las ventajas y desventajas del proyecto del tren
tario de Transporte, RayLaHood. de alta velocidad. Según su opinión, ¿los beneficios
El cuarto elemento muy cuestionado en el pro- son mayores que los inconvenientes, o viceversa?
yecto es el precio final proyectado. Aunque CHSRA y ¿Por qué? Justifique su respuesta.
funcionarios estatales siguen manteniendo la etiqueta de 2. ¿Cuáles son las implicaciones de iniciar un proyecto
un precio de 43,000 millones de dólares, otros, inclui- basado en proyecciones tenues que pueden o no
dos los consultores de transporte del Grupo de Gerencia hacerse realidad dentro de 10 años?
de Infraestructura, han sugerido que esta cifra, basada 3. ¿Podría justificarse el proyecto del tren de alta velo-
en datos históricos, subestima el costo final, al inflar el cidad de California, desde la perspectiva de una ini-
número probable de pasajeros. Economistas sugieren que ciativa masiva de obras públicas? En otras palabras,
un rango más probable para el costo final del proyecto ¿qué otros factores influyen en la decisión de seguir
estaría entre 62,000 y 213,000 millones de dólares, y una con el proyecto del tren de alta velocidad? ¿Por qué
estimación más razonable del tráfico anual de pasajeros son importantes?
es del orden de 5 millones de dólares. Si estos números
Estudio de caso 5.4 177

Estudio de caso 5.3


Gerencia de proyectos en Dotcom.com

Dotcom.com, una firma de ingeniería de software y consul- dedicarle a mi equipo para desarrollar el sistema para ellos.
toría en desarrollo de sistemas, vende una amplia variedad de Es un círculo vicioso: si quiero hacer las cosas bien, tengo que
soluciones de internet para la planeación y administración sonsacarles información a ellos. ¡Cuánto mejor hago por lle-
de recursos y redes de contabilidad a organizaciones de pres- gar a conocer sus problemas, menos tiempo tengo para desa-
tación de servicios de salud, servicios financieros y gerencia rrollar y ejecutar el proyecto!”
hotelera. Normalmente, un proveedor de servicios como Jim Crenshaw, otro gerente de proyectos, tomó la pala-
Dotcom.com lista los problemas y plantea algunos objetivos bra y dijo: “Por desgracia esto no se detiene allí. Mis mayores
de mejora organizativa. Dado que la mayoría de los clientes problemas siempre se presentan en la parte final del proyecto.
de Dotcom no son expertos en temas informáticos, tienden Trabajamos como burros para llegar a un sistema que corres-
a depender en gran medida de Dotcom para diagnosticar ponda a las exigencias del cliente, solo para que cuando lo vean
correctamente los problemas, proponer soluciones para y accionen unos pocos botones, comiencen a decirnos que
corregir estos problemas y aplicar las nuevas tecnologías. El ¡esto no es nada parecido a lo que tenían en mente! ¿Cómo se
sector en el que opera Dotcom es extremadamente compe- supone que voy a desarrollar un sistema que les resuelva sus
titivo y fuerza a las organizaciones de éxito a hacer ofertas problemas cuando no saben cuáles son? Mejor aún, ¿qué hace-
bajas para ganar contratos de consultoría. En este entorno, mos cuando ‘piensan’ que saben lo que quieren y cuando lo
la gerencia de proyectos es vital para el éxito de Dotcom por- creamos se dan la vuelta y rechazan nuestras soluciones?”
que los proyectos mal manejados rápidamente “consumen” Después de dos horas de escuchar mensajes similares
el margen de beneficio de cualquier trabajo. de los otros gerentes de proyectos, la alta gerencia eviden-
Infortunadamente, el equipo directivo de Dotcom ha ció que los problemas de gerencia de proyectos no eran ais-
notado un reciente aumento en los costos de operación del lados, sino estaban incorporándose en las operaciones de la
proyecto y una baja relacionada con la rentabilidad. En par- empresa. Algo había que hacer en torno a los procesos.
ticular, los ejecutivos de Dotcom están preocupados porque
Preguntas
los últimos siete contratos de consultoría se han traducido en
casi ningún margen de utilidad debido a que los sistemas de 1. ¿Cómo empezaría usted a rediseñar los procesos de
software se entregaron tarde y requirieron varias rondas de gerencia de proyectos de Dotcom para reducir al
trabajo para corregir errores o deficiencias en el software. La mínimo los problemas que experimenta con la mala
empresa decidió celebrar un retiro de fin de semana fuera de gerencia del alcance?
las instalaciones con los gerentes responsables de estos pro- 2. ¿Cómo contribuyen los clientes de consultoría de la
yectos concluidos recientemente, con el fin de saber por qué se empresa a los problemas con la expansión o cambio
está realizando de manera deficiente la gerencia de proyectos. del alcance? Si se va a celebrar una reunión con un
Para una persona, los gerentes de proyectos responsa- cliente potencial, ¿qué mensaje quiere que el cliente
bilizaron de sus problemas a los clientes. Una respuesta típica entienda con claridad?
la dio Susan Kiley, una gerente de proyectos con experiencia 3. ¿Cómo equilibrar la necesidad de involucrar a los
de más de cinco años, quien declaró: “Aquí estamos en una clientes con la necesidad igualmente importante para
posición muy difícil. La mayoría de los clientes no saben lo congelar el alcance del proyecto, a fin de completar el
que realmente quieren; tenemos que pasar horas trabajando proyecto a tiempo?
con ellos para conseguir una declaración de trabajo razona- 4. ¿Por qué la gerencia de configuración y control de
ble alrededor de la cual podamos desarrollar el alcance del cambios del proyecto es tan difícil de llevar a cabo en
proyecto. Esto toma tiempo. De hecho, cuanto más tiempo medio de un proyecto de desarrollo de software com-
paso con el cliente desde el inicio, menos tiempo tengo para plejo, como los realizados por Dotcom.com?

Estudio de caso 5.4


Caso clásico: el Ford Edsel
Pocos nombres evocan una imagen de fracaso empresa- importante separar el mito de la realidad del Ford Edsel.
rial monumental más rápido que el Ford Edsel. Debido Contrariamente a la creencia popular, el Edsel no fue el
a la popularidad de la mentalidad “Edsel = desastre,” es proyecto de absoluto fracaso que se ha dado a conocer. Por
(continúa)
178 Capítulo 5  •  Gerencia del alcance

el contrario, Ford realmente hizo varios movimientos de bajo precio, solo 26% se quedó con los productos
positivos y apropiados en la introducción del vehículo. de Ford (el Mercury) durante la negociación. Clara-
Por otro lado, el Edsel ilustra errores fundamentales en la mente, esto indica un problema con lo que simboliza
gerencia de los supuestos y otras acciones de Ford mien- la marca.
tras realizaba este proyecto. Los proyectos exitosos no El Edsel estaba dirigido a parejas jóvenes, en
se aplauden solamente por los logros técnicos. El mejor ascenso en la escala corporativa y listos para adqui-
desarrollo de proyectos en el mundo es inútil sin un fuerte rir un automóvil de gama superior. Como parte de
seguimiento comercial. Y el seguimiento comercial repre- la investigación directa para tantear el terreno de
sentó una deficiencia clave en la breve pero colorida histo- ese automóvil (apodado en Ford el “E-car” porque
ria del Ford Edsel. no había sido seleccionado un nombre oficial), los
investigadores recolectaron más de 2,000 nombres
Desarrollo del Edsel alternativos en pruebas de comercialización con
grupos focales y entrevistas en la calle para deter-
Después de la década de 1920, cuando Ford cedió su liderato
minar cuál encajaba en la creación de una imagen
de participación en el mercado a General Motors (GM), la
que atrajera al mercado objetivo joven, profesional.
empresa llegó a conocerse principalmente por los carros
El nombre de Edsel fue finalmente elegido por un
de bajo precio producidos en serie. La división Lincoln
comité interno de Ford, y este ni siquiera estaba en
se dedicó a los automóviles de gama alta, posicionando el
la lista de los diez candidatos finales, pero surgió
nombre de Ford en el nicho de mercado de vehículos menos
debido a la incapacidad para llegar a un consenso
costosos. A mediados de la década de 1950, Ford trató de
sobre alguna de las otras opciones.
cambiar para siempre su imagen de fabricante de automó-
2.
Diseño—El objetivo de Ford era difícil: la compañía
viles “de gama baja” al hacer una entrada espectacular en el
quería hacer una declaración contundente del estilo
segmento de precio medio, compitiendo directamente con
del automóvil separando al Edsel de la competencia,
Pontiac, Oldsmobile y Buick de General Motors, y Dodge
pero al mismo tiempo permaneciendo dentro de los
y DeSoto de Chrysler. No solo el tiempo parecía estar bien,
límites de gusto y atractivo. El trabajo de diseño se
sino la economía general de Estados Unidos parecía estar a
inició en 1954 y desde el principio su enfoque era
punto para explotar el segmento de precio medio. Desde el
poco convencional. Más de 800 diseñadores traba-
final de la Segunda Guerra Mundial en la década anterior,
jaron en el proyecto en un momento u otro. Se hi-
y, en menor medida, la guerra de Corea tres años antes, la
cieron cientos de bocetos, alterados, modificados y
población estadounidense había disfrutado de un periodo
rechazados antes de que la versión final obtuviera la
de expansión feliz. Nuevas ideas, productos innovadores
aprobación. Algunas de las características conocidas
y mercados más grandes y para estos productos parecían
del Edsel incluyeron la famosa parrilla vertical que
haberse convertido en un elemento permanente del pano-
tenía la intención de recordar a los compradores, los
rama económico estadounidense. El GI Bill había creado
automóviles de lujo de una generación anterior: los
una clase media en crecimiento, el pleno empleo garanti-
Packards, Pierce Arrows y LaSalles. Esto le dio al Ed-
zaba una alta renta disponible y el optimismo general de la
sel una silueta frontal trasera única que se reconocía
época predecía mayores y mejores cosas por venir.
al instante. Entre las otras características distintivas
En el desarrollo del Edsel, Ford se dedicó a cuatro esfuer-
del automóvil estaban sus grandes aletas traseras,
zos diferentes para apoyar el proyecto: investigación de
sus lujos de cromo y cristal y la tecnología de “botón
mercados, diseño, creación de una división separada y
pulsador.” La transmisión automática, las cerradu-
promoción.
ras frontales y posteriores y el freno de mano eran
1.
Investigación de mercados—Un estudio a media- accionados por un botón pulsador. El efecto global
dos de la década de 1950 encontró que cada año más estaba destinado a ser uno de alta tecnología y facili-
de 20% de los propietarios de automóviles de mode- dad de uso.
lo de bajo precio pasarían a un automóvil de precio Ford decidió también que el Edsel debía tener
medio; sin embargo, la lealtad de marca difiere enor- un motor poderoso para ir con su estilo distintivo.
memente entre los fabricantes de automóviles riva- Un gran motor V-8 venía estándar con el coche,
les. Por ejemplo, los que poseían vehículos de GM capaz de entregar 345 caballos de fuerza. Tomados
de bajo precio, como Chevrolet, tendían a negociar en conjunto, el diseño y la potencia del tren del Edsel
hasta un automóvil de precio medio —Oldsmobile, pretendía hacer una declaración con la esperanza de
Buick, o Pontiac 87% del tiempo. Los propietarios atraer a los prometedores clientes más jóvenes.
de automóviles Chrysler de gama baja (Plymouth) 3.
División de automóviles Edsel—Ford tomó otra
negocian a un precio medio Dodge o DeSoto 47% decisión importante en un esfuerzo por separar el
del tiempo. Por otra parte, los propietarios de Fords Edsel del resto de la línea de productos Ford, y creó
Estudio de caso 5.4 179

una división Edsel completamente independiente. corporativa de Estados Unidos. Después de la preparación
Su razonamiento parecía tener sentido: si realmente para su lanzamiento, el público había esperado ansiosamente
la intención era ofrecer el Edsel no solo como un algo extraordinario, un salto revolucionario hacia adelante
automóvil, sino como el primero de una serie de au- en la tecnología del automóvil. Al ver el Edsel, por primera
tomóviles de precio medio, sintieron la necesidad vez, el público se sintió “defraudado.” Ford había previsto
de crear un personaje completo alrededor del au- pedidos para el primer año por un total de al menos 200,000
tomóvil. El resultado fue una búsqueda complicada vehículos. Aunque se recibieron pedidos de 6,500 en el pri-
de una red de distribuidores que estaría dispuesta a mer día, acto seguido las órdenes de venta se redujeron drás-
ofrecer el Edsel de forma exclusiva. Al final se acer- ticamente. Durante los primeros diez días de octubre, menos
caron a cerca de 5,000 posibles distribuidores antes de un mes después de la introducción, el Edsel alcanzó un
de recortar la lista a unos 1,200 distribuidores inde- volumen de ventas de solo 2,750 vehículos, cerca de dos ter-
pendientes, la mayoría de los cuales podría vender cios de su nivel esperado. Peor aún, el impulso se volvió en
solo Edsels en las salas de exposición. Además, las contra del automóvil cuando las noticias de sus bajas ventas
decisiones acerca de dónde ubicar los concesiona- comenzaron a filtrarse. La conclusión obvia en gran parte del
rios se tomaron basadas en datos demográficos, público: debe haber algo malo en el automóvil para que no se
características metropolitanas, transporte y otros venda. Como resultado, las malas noticias continuaron para
servicios logísticos y reputación del distribuidor. Al producir más malas noticias.
final, Ford estaba convencido de que había sentado El año 1958 fue desastroso para las ventas del Edsel.
las bases para una introducción del nuevo automó- Con la esperanza de vender un cuarto de millón de auto-
viles sin problemas y con éxito. móviles, Ford terminó vendiendo solo 34,481 en todo el
Promoción del Edsel—Ford estaba decidido a ha-
4. año. Incluso cuando se presentó una nueva versión del
cer de la introducción del Edsel un “evento.” Con el Edsel a finales de 1957 con un diseño de carrocería más
fin de financiarla adecuadamente, la empresa asignó corta y el precio más barato, las nuevas ventas apenas
50 millones de dólares para la publicidad y promo- respondieron.
ción iniciales, una enorme cantidad de dinero para En 1959, menos de dos años después de su intro-
el lanzamiento de un nuevo vehículo. La publicidad ducción, la división de Edsel fue formalmente cerrada y
para el Edsel comenzó el 22 de julio de 1957, con el automóvil se fusionó con la línea Mercury y Lincoln,
un anuncio de dos páginas en la revista Life. Estos en una división Lincoln-Mercury-Edsel. Fue una estra-
anuncios estaban destinados a provocar al público y tegia de reducción de costos diseñada para recortar los
a promover la curiosidad, ya que ellos no mostraban costos fijos hasta que Ford pudiera averiguar qué hacer
el automóvil en sí mismo. Este enfoque no fue una con el automóvil. En otoño de ese año, el tercer modelo
casualidad: desde el principio, los ejecutivos de Ford (y último) de Edsel se introdujo con menos fanfarria de
estaban decididos a generar una expectativa para el la que había ocurrido dos años antes. Las ventas fueron
Edsel por mantenerlo (literalmente) en secreto. Los flojas y la producción del Edsel se suspendió oficialmente
automóviles fueron cubiertos durante el envío a los el 19 de noviembre de 1959.
distribuidores y no se permitieron fotos publicitarias En sus dos años de vida, el Edsel había logrado
preliminares del Edsel. De hecho, solo fue hasta fi- generar ventas de solo 109,466 vehículos, un total triste
nales de agosto que las imágenes reales de los auto- cuando se compara con las proyecciones iniciales de más
móviles se liberaron a la publicidad. de seis veces ese nivel. En el cierre de libros del Edsel, Ford
Ford tomó una decisión más que iba a tener tuvo una pérdida de 200 millones de dólares, que repre-
graves consecuencias para el Edsel: la compañía senta su inversión inicial más la publicidad y las pérdidas
decidió saltarse el tiempo de lanzamiento acostum- de operación.
brado, a finales del otoño (por lo general alrededor
de noviembre) e introducir el Edsel anticipada-
mente. Querían asegurarse de que no había ninguna ¿Por qué fracasó el Edsel?
competencia de GM o Chrysler con la cual tener En el papel, el Edsel debería haber tenido éxito. La com-
que compartir el protagonismo. El otoño de 1957 pañía había pasado un largo periodo planeando su intro-
iba a pertenecer al Edsel exclusivamente. ducción, se habían empleado a cientos de personas para
asegurarse de que los diseños eran de última generación,
y se había abordado la promoción y distribución con
El Edsel llega cuidado y creatividad. En resumen, desde una perspec-
La introducción real del Edsel, el 4 de septiembre de 1957, tiva de gerencia del proyecto, el Edsel debería haber sido
resultó ser uno de los grandes “eventos nulos” en la historia un éxito. ¿Qué salió mal?
(continúa)
180 Capítulo 5  •  Gerencia del alcance

• Mala sincronización—La introducción del Edsel coin- mercado en septiembre de 1957. Este movimiento
cidió con la primera recesión económica en Estados tuvo dos efectos imprevistos. Primero, el auto-
Unidos en más de una década. Después del colapso móvil no estaba listo para su lanzamiento antici-
del mercado de valores a finales de 1957, la recesión pado. Varios propietarios se quejaron de pérdidas
de 1958 fue un poderoso lastre para la economía en de aceite, ruidos y frenos defectuosos. Segundo, el
general y para las ventas de automóviles en particular. tiempo pensado inicialmente para trabajar en bene-
En 1958, el volumen de ventas de toda la industria del ficio de Ford, en realidad trabajó en su contra. Los
automóvil fue inferior a 70% del total del año anterior. distribuidores en todo el país suelen utilizar el otoño
De hecho, solo hasta 1960 las cifras del volumen de como un tiempo para descargar los modelos del año
ventas volvieron a los niveles previos a la recesión. anterior, con el fin despejar sus salas de exhibición
• Cambio en los gustos del consumidor—Con la rece- para los modelos del siguiente año. Ford se encon-
sión de 1958 como catalizador, el consumidor esta- tró compitiendo con 1,957 modelos de automóviles
dounidense promedio comenzó a buscar automóvi- que los distribuidores estaban fuertemente motiva-
les, más económicos y más pequeños. Por ejemplo, dos a vender a precios más bajos.
mientras que 1958 fue un año negativo para las ven- • Efectos de la estructura divisional—Ford deci-
tas del Edsel, era el comienzo de un periodo de auge dió no incluir la organización Edsel en la estruc-
del Volkswagen, eficiente en combustible y distin- tura corporativa ya existente. Con la entrada de
tivo, “Beetle.” Las ventas de automóviles importados la compañía en el mercado de automóviles de
en general se había más que cuadruplicado desde precio medio, el Edsel fue pensado para generar
1956 a más de 430,000 unidades. varias marcas y estilos alternativos, lo que exigía
• Los factores de seguridad afectaron las actitudes— una estructura operativa totalmente diferente para
La imagen del Edsel como un automóvil potente apoyar su crecimiento. En la creación de una orga-
y elegante efectivamente trabajó en su contra en nización separada para apoyar una nueva empresa,
ese momento, cuando el Consejo Nacional de inexperta, Ford añadió millones en costos fijos y
Seguridad estaba empujando a los fabricantes a res- gastos generales en la línea inferior.
tarles importancia a la velocidad y a la potencia en • Errores de investigación de mercados—Aunque la
su publicidad. En 1957, la Asociación de Fabricantes investigación de mercados de Ford era extensiva,
de Automóviles, de la cual Ford era miembro, firmó finalmente condujo a algunos errores profundos.
un acuerdo que establecía que específicamente la Ford había comenzado a investigar el mercado
potencia y el rendimiento se descontinuaban de la diez años antes del desarrollo e introducción del
publicidad. El efecto fue eliminar la posibilidad de Edsel. Como resultado, algunos de los supuestos
promover dos de las características más destacadas de las decisiones iniciales resultaron in- válidos
del Edsel. Irónicamente, el Edsel fue pensado para cuando el automóvil llegó al mercado: varias de
evocar imágenes de poder y manejo en momentos las decisiones de estilo (por ejemplo, las enormes
en que la industria estaba alejándose de esos mismos aletas de la cola) fueron ridiculizadas como cosa
conceptos. del pasado, mientras que el empuje para un motor
• Una imagen sobrevalorada—En su esfuerzo por grande de gran alcance iba en contra de una ten-
ofrecer un automóvil que Ford no solo consideraba dencia de cuatro años atrás, hacia automóviles
nuevo, sino revolucionario, la empresa había inflado más pequeños y económicos, como los produci-
las expectativas de los consumidores a un punto que dos en Europa.25
no podría satisfacer. Este punto quedó claro cuando
los clientes potenciales vieron el automóvil por pri- Preguntas
mera vez y notaron solo unas innovaciones y mejoras
marginales. El cuerpo, aunque distintivo, no ofreció 1. ¿Qué dice la historia del Ford Edsel acerca de la
funciones “revolucionarias,” a pesar de las aletas de la importancia de considerar tanto el rendimiento téc-
cola prominentes y los botones pulsadores. El motor nico como el comercial para el éxito del proyecto?
era grande, pero no excesivamente. El automóvil 2. Qué opina de esta declaración: “A través de estudios
estaba bien equipado, pero de ninguna manera lujoso de viabilidad y estudios de mercado pobres, los direc-
para el precio. En resumen, el automóvil había sido tivos de Ford se convencieron de que habían dise-
promocionado para estar en un nuevo nivel, pero, ñado un automóvil para llenar un nicho que, en 1957,
por el contrario, los clientes vieron más de lo mismo ya no estaba allí.”
a que estaban acostumbrados con GM y Chrysler. 3. “Ford Edsel debería haber tenido éxito. Fue sim-
• Apresuramiento del mercado—Con el fin de superar plemente una víctima de la mala suerte.” ¿Está de
(continued)
a su competencia, el Edsel fue llevado de urgencia al acuerdo o en desacuerdo con esta opinión? ¿Por qué?
Ejercicios con MS Project 181

Ejercicios en internet
1. Ingrese en www.4pm.com/arITcles/work_breakdown_struc- a. Comience con la estructura de desglose del trabajo
ture.htm y conozca un breve tutorial sobre el desarrollo de una (EDT)
estructura de desglose de trabajo efectivo. ¿Por qué este sitio b. Comience con una clara declaración del alcance
advierte específicamente contra la creación de una larga lista de c. Comience con una declaración del problema y decla-
actividades del proyecto? ¿Cuáles son algunos de los peligros en ración de trabajo (SOW)
la creación de pobres estructuras de desglose del trabajo y las d. Comience con una clara autorización de trabajo
ventajas de hacerlo de manera efectiva?
2. Ingrese en www.oet.state.mn.us/mastercontract/statements/ 4. El gerente de proyectos quiere asegurarse de que está lle-
1863.pdf para que conozca un proceso de descripción y crea- vando a cabo el orden correcto mientras avanza para desa-
ción de una declaración de trabajo para el proyecto de actua- rrollar un alcance claro del proyecto. Durante la definición
lización Bolsa de Trabajo de Minnesota. Según su opinión, del alcance, ¿qué debería estar haciendo?
¿cuáles son algunos de los elementos claves en esta declaración a. Involucrando a los interesados y verificando que
de trabajo? ¿Por qué? El sitio también contiene un “Contrato todos ellos provean sus aportes al proceso
maestro de órdenes de trabajo de servicios profesionales de IT.” b. Desarrollando la EDT y OBS
¿Por qué esta orden de trabajo es tan detallada? c. Moviéndose tan rápidamente como sea posible para
3. Ingrese en www.nccommunitycolleges.edu/IT_Projects/docs/ determinar los métodos de reporte del alcance
Data%20Warehouse/Phase%20I/dw_project_scope_statemen. d. Identificando todos los proveedores necesarios para
pdf. y analice la declaración completa del alcance del proyecto cualquier subcontratación que se deba hacer
de almacenamiento de datos. ¿Qué problema aborda este pro- 5. Se prevé la ampliación de un hospital para una comunidad.
yecto? ¿Cuál es la solución que se propone? Como parte del alcance de este proyecto, será necesario cerrar
las vías de acceso a la sala de emergencias para una remode-
Preguntas de ejemplo del examen para la certificación larlo; sin embargo, como este es el único hospital para casos
PMP® de traumas en un radio de 50 kilómetros, no es posible sus-
1. ¿Cómo se denomina el nivel más bajo de la descomposi- pender completamente la sala de emergencias. El equipo de
ción de la estructura del proyecto? proyectos tendrá que encontrar un medio para remodelar la
a. Paquete de trabajo sala de emergencias al tiempo que permita el funcionamiento
b. Entregable continuo de la unidad. Este es un ejemplo de:
c. Subentregable a. Puntos de negociación con el propietario
d. Proyecto b. Restricciones
c. Supuestos iniciales
2. Todo lo siguiente define un paquete de trabajo, EXCEPTO: d. Desarrollo de hitos
a. Un paquete de trabajo tiene un resultado entregable
b. Puede considerarse por su responsable como un pro- Respuestas: 1. a—El paquete de trabajo es el nivel más bajo
yecto en sí mismo de la estructura de la EDT 2. d—Un paquete de trabajo debe
c. Un paquete de trabajo puede incluir varios hitos ajustarse a los procedimientos y cultura organizacional; 3. c—El
d. Un paquete de trabajo puede crearse y dirigirse inde- proyecto debe iniciar con una declaración clara del problema y
pendientemente de otros procedimientos y conside- entendido en la SOW; 4. a—Es muy importante que todos los
raciones culturales de la organización interesados tengan la oportunidad de contribuir con sus aportes
3. George ha sido asignado como el nuevo gerente para al proyecto durante la fase de definición del alcance; 5. b—La
nuestro proyecto. Tiene muchas ganas de tener un buen necesidad de mantener la sala de emergencias abierta durante la
comienzo y quiere indicar las actividades en que primero remodelación es un ejemplo de trabajo en torno a las limitacio-
debe participar ¿Cómo le aconsejaría que empiece? nes de los proyectos existentes.

Ejercicios con MS Project


Con base en la información proporcionada a continuación, constru- B. Desarrolle los datos de grupo focal
ya una tabla EDT simple para el proyecto de ejemplo. C. Realice encuestas telefónicas
D. Identifique las mejoras en las especificaciones pertinentes
Esquema del proyecto—Rediseño de un producto II. Fase de diseño y de ingeniería
A. Realice interfaz con el personal de marketing
I. Fase de investigación B. Y así sucesivamente
A. Prepare la propuesta de desarrollo de producto III. Fase de prueba
1. Lleve a cabo el análisis de la competencia IV. Fase de fabricación
2. Revise los informes de campo de ventas   V. Fase de ventas
3. Lleve a cabo la evaluación de las capacidades tecnológicas
182 Capítulo 5  •  Gerencia del alcance

PROYECTO INTEGRADO

Desarrollo de la estructura de desglose del trabajo (EDT)


Desarrolle una estructura de desglose del trabajo para su proyecto basado en las metas identificadas en la pri-
mera asignación. Evalúe detalladamente los distintos componentes del proyecto, dividiéndolos en paquetes de
trabajo, tareas y subtareas (en caso de ser apropiado). Luego evalúe las necesidades de personal para el proyecto.
¿Cuántos miembros del equipo serán necesarios para alcanzar las metas del proyecto? Recuerde que debe uti-
lizar el alcance del proyecto como base para la determinación de todos los elementos del proyecto, el personal
responsable de cada componente y el presupuesto asociado a cada tarea.
Además de identificar las tareas y necesidades de personal clave para el proyecto, construya una matriz de
asignación de responsabilidades (RAM), que demuestre la interrelación entre los miembros del equipo de proyectos.

EJEMPLO DE LA ESTRUCTURA DE DESGLOSE DEL TRABAJO —ABCups, INC.


Cuadro de personal

Nombre Departamento Título/cargo


Carol Johnson Seguridad Ingeniero de seguridad
Bob Hoskins Ingeniería Ingeniero industrial
Sheila Thomas Gerencia Administrador de proyectos
Randy Egan Gerencia Administrador de planta
Stu Hall Industrial Supervisor de mantenimiento
Susan Berg Contabilidad Contador de costos
Marty Green Industrial Supervisor de compras
John Pittman Calidad Ingeniero de calidad
Sally Reid Calidad Ingeniero de calidad Jr.
Lanny Adams Ventas Gerente de marketing
Kristin Abele Compras Agente de compras

ESTRUCTURA DE DESGLOSE DEL TRABAJO—MODIFICACIÓN DE


PROCESO—ABCups
Proyecto Modificación de proceso 1000
Entregable 1 Estudio de factibilidad 1010
Paquete de trabajo 1 Realizar estudio de factibilidad 1011
Paquete de trabajo 2 Recibir aprobación técnica 1012
Paquete de trabajo 3 Obtener aprobación administrativa 1013
Entregable 2 Selección de proveedores 1020
Paquete de trabajo 1 Equipo de investigación 1021
Paquete de trabajo 2 Calificar proveedores 1022
Paquete de trabajo 3 Solicitar cotizaciones de proveedores 1023
Paquete de trabajo 4 Negociar precio y términos 1024
Paquete de trabajo 5 Aprobación y contratos 1025
Entregable 3 Diseño 1030
Paquete de trabajo 1 Diseño del nuevo proceso 1031
Paquete de trabajo 2 Dibujos-planos 1032
Proyecto integrado 183

Paquete de trabajo 3 Proceso de aprobación del rediseño 1033


Entregable 4 Ingeniería 1040
Paquete de trabajo 1 Evaluación del flujo del proceso 1041
Paquete de trabajo 2 Determinación del sitio para el equipo 1042
Paquete de trabajo 3 Reconfiguración 1043
Paquete de trabajo 4 Aprobación del diseño final 1044
Entregable 5 Pruebas del prototipo 1050
Paquete de trabajo 1 Construir banco de inventario 1051
Paquete de trabajo 2 Configurar periodo de prueba 1052
Paquete de trabajo 3 Pruebas de funcionamiento 1053
Paquete de trabajo 4 Evaluación de la calidad 1054
Paquete de trabajo 5 Documentación del proceso 1055
Entregable 6 Embalaje 1060
Paquete de trabajo 1 Diseño del nuevo embalaje 1061
Paquete de trabajo 2 Coordinar con marketing 1062
Paquete de trabajo 3 Ensamblaje de partes 1063
Paquete de trabajo 4 Aprobación del embalaje 1064
Entregable 7 Ventas y servicio 1070
Paquete de trabajo 1 Pruebas beta de los productos 1071
Paquete de trabajo 2 Aprobación de ventas 1072
Paquete de trabajo 3 Aprobación del cliente 1073
Entregable 8 Iniciar el cambio 1080
Paquete de trabajo 1 Ensamble inventario 1081
Paquete de trabajo 2 Cancelar contratos de proveedores 1082
Paquete de trabajo 3 Cerrar el proyecto 1083
Paquete de trabajo 4 Desarrollar lecciones aprendidas 1084

Matriz de asignación de responsabilidades

Sheila Susan Bob Lanny

Del 1010

Del 1020

Del 1030

Del 1040

Del 1050

Del 1060

Del 1070

Del 1080

Responsable Soporte

Notificación Aprobación
184 Capítulo 5  •  Gerencia del alcance

Notas
1. Feickert, A. (2008). “The Marines’ Expeditionary FightingVehicle 12. Meredith, J. R., and Mantel, Jr., S. J. (2003). Project
(EFV): Background and issues for Congress.”Congressional Management, 5th ed. New York: Wiley.
Research Service, Library of Congress, www.dtic.mil/cgi- 13. Globerson, S. (2001). “Scope management: Do all that you
bin/GetTRDoc?Location=U2&doc=GetTRDoc.pdf&A- need and just what you need,” in Knutson, J. (Ed.), Project
D=ADA486513; Hodge, N. (2010, 27 de agosto). “Marines Management for Business Professionals. New York: Wiley,
question craft needed to hit the beach,” Wall Street Journal, p. pp. 49–62.
B8; www.wired.com/dangerroom/2008/08/Marines-swimmin/; 14. Obradovitch, M. M., and Stephanou, S. E. (1990). Project
Merle, R. (2007). “Problems stallPentagon’snew fighting Management: Risks & Productivity. Bend, OR: Daniel
vehicle.”www.washingtonpost.com/wp-dyn/content/arti- Spencer.
cle/2007/02/06/AR2007020601997.html; Ackerman, S. (2010). 15. Project Management Institute (2010), como se cita en la nota 2.
“Senate may finally sinkMarines’ swimming tank.” www.wired. 16. Yourdon, E. (2004). Death March, 2nd ed. Upper Saddle
com/dangerroom/2010/09/senate-may-finally-sink-Mari- River, NJ: Prentice-Hall.
nes-swimmingtank/;www.aviationweek.com/aw/jsp_includes/ 17. Kidd, C., and Burgess, T. F. (2004). “Managing configuration
articlePrint.jsp?storyID=news/asd/2010/11/08/01.xml&head- sand data for effective project management,” in Morris,P.
Line=null;www.aviationweek.com/aw/generic/story.jsp?id=- W. G., and Pinto, J. K. (Eds.), The Wiley Guide to Managing
news/asd/2010/10/12/08.xml&channel=misc. Projects.New York: Wiley, pp. 498–513.
2. Project Management Institute. (2010). “Scope Management,” 18. Meredith, J. R., and Mantel, Jr., S. J. (2003), como se cita en la
Project Management Body of Knowledge (PMBOK). nota 12.
UpperDarby, PA: Project Management Institute; Westney, 19. Frame, J. D. (2001). “Requirements management: Addressing
R. E.(1993). “Paradigms for planning productive projects,”in customer needs and avoiding scope creep,” in Knutson, J.
Dinsmore, P. C. (Ed.), The AMA Handbook of Project (Ed.),Project Management for Business Professionals.New
Management.New York: AMACOM. York:Wiley, pp. 63–80.
3. Kerzner, H. (2001). Project Management: A SystemsApproach 20. Kidd, C., and Burgess, T. F. (2004), como se cita en la nota 17.
to Planning, Scheduling, and Controlling, 7th ed.New York: 21. Turner, R. (2000). “Managing scope—Configuration and
Wiley; Mepyans-Robinson, R. (2010). “Projectscope mana- work methods,” in Turner, R. (Ed.), Gower Handbook of
gement in practice,” in Dinsmore, P. C., andCabanis-Brewin, Project Management, 3rd ed. Aldershot, UK: Gower.
J. (Eds.), The AMA Handbook of Project Management, 3rd 22. Antonioni, D. (1997). “Post-project review prevents poor
ed. New York: AMACOM, pp. 79–87;Cleland, D. I., and project performance,” PMNetwork, 11(10).
Kimball, R. K. (1987). “The strategic contextof projects,” 23. Kouri, J. (2010, 11 de noviembre). “Border ‘virtual fence’
Project Management Journal, 18(3): 11–30. projecta costly failure.” http://island-adv.com/2010/11/
4. Project Management Institute (2000), como se cita en la nota 2. border-%E2%80%9Cvirtual-fence%E2%80%9D-pro-
5. Stuckenbruck, L. C. (1981). The Implementation of Project ject-a-costlyfailure/;Krigsman, M. (2007, 23 de agosto).
Management: The Professional’s Handbook. Boston, “Boeing virtual fence: $30 billion failure.” www.zdnet.com/
MA:Addison-Wesley; Laufer, A. (1991). “Project plannin- blog/projectfailures/boeing-virtual-fence-30-billion-fai-
g:timing issues and path of progress,” Project Managemen lure/36;Krigsman, M. (2007, 24 de septiembre). “Update:
tJournal, 22(2): 39–45. Boeing’s virtual fence ‘unusable.’” www.zdnet.com/blog/
6. Martin, M. G. (1998). “Statement of work: The foundation projectfailures/update-boeing-virtual-fence-unusable/403;
fordelivering successful service projects,” PM Network, Lipowicz, A.(2010, 21 de abril). “Senate committee chair-
12(10):54–57. man suggests killing Boeing’s virtual fence.” http://was-
7. www.fgdc.gov/geospatial-lob/smartbuy/understandingsta- hingtontechnology.com/articles/2010/04/21/lieber-
tement-of-work.pdf/. man-calls-sbinet-virtual-fence-afailure.aspx; Richey, J.
8. Duncan, W. R. (1994). “Scoping out a scope statemen- (2007, 7 de julio). “Fencing the border: Boeing’s high-tech
t,”PMNetwork, 8(12): 24–27; Wideman, R. M. (1983). plan falters.” www.theinvestigativefund.org/investigations/
“Scope management,”Project Management Quarterly, 14: immigrationandlabor/1243/fencing_the_border%3A_boe-
31–32; Pinto, J. K.(1999). “Project scope management,” in ing%27s_high-tech_plan_falters.
Pinto, J. K. (Ed.), TheProject Management Institute’s Project 24. California High-Speed Rail Authority Web site, www.cahi-
Management Handbook.San Francisco, CA: Jossey-Bass, pp. ghspeedrail.ca.gov/home.aspx; Castaneda, V., and Severston,
109–18. A. (2010, 11 de octubre). “Economists say high speedrail
9. Lavold, G. D. (1988). “Developing and using the work system won’t make money.” http://menlopark.patch.com/
breakdownstructure,” in Cleland, D. I., and King, W. R. articles/economists-say-high-speed-railsystem-will-ne-
(Eds.),Project Management Handbook, 2nd ed. New York: ver-achieve-positive-cash-flow; Enthoven, A.,Grindley, W.,
VanNostrand Reinhold, pp. 302–23. and Warren, W. (2010).“The financial risks of California’s
10. Obradovitch, M. M., and Stephanou, S. E. (1990). proposed high-speed rail.” www.cc-hsr.org/assets/pdf/
ProjectManagement: Risks & Productivity. Bend, OR: Daniel CHSR-Financial_Risks-101210-D.pdf; Garrahan,M. (2009,
Spencer. 6 de octubre). “California keen to set the pace.”Financial
11. Project Management Body of Knowledge. (2008). Project Times, www.ft.com/cms/s/0/1c0b3676-b28a-11deb7d2-
Management Institute: Newton Square, PA. 00144feab49a.html#axzz18CGc6USH; Mitchell, J.(2010, 13
Notas 185

de diciembre). “At start of rail project, a tussle over where gets a frantic push.” (1957, 7 de diciembre). Business Week,
to begin.”Wall Street Journal, http://online.wsj.com/article/ p. 35;Deutsch, J. G. (1976). Selling the People’s Cadillac: The
SB10001424052748703727804576011871825514428.html; Edsel and Corporate Responsibility. New Haven, CT: Yale
“Subsidy trains to nowhere.” (2010, 11-12 de diciembre). University Press; Hartley, R. J. (1988). Management Mistakes
Wall Street Journal, p. A14; Weikel, D. (2010, 10 de diciem- and Successes, 4th ed. New York: Wiley; Kharbanda, O. P.,and
bre). “U.S. shifts $624 million to California bullet train.” Pinto, J. K. (1996). What Made Gertie Gallop? New York: Van
LosAngeles Times, http://articles.latimes.com/2010/dec/10/ Nostrand Reinhold; Reynolds, W. H. (1967). “The Edsel ten
local/la-me-high-speed-money-20101210. years later,” Business Horizons, 10: 38–47;Ward’s Automotive
25. Baker, H. G. (1957, junio). “Sales and Marketing plan- Yearbook. (1973). Detroit, MI: Ward’s Communications;
ningof the Edsel,” in Marketing’s Role in Scientific Warnock, C. G. (1980). The Edsel Affair,... What Went Wrong:
Management,Proceedings of the 39th National Conference A Narrative. Paradise Valley, AZ:Pro West.
of theAmerican Marketing Association, pp. 128–29; “Edsel
CAPÍTULO

6
Conformación del equipo del proyecto,
conflicto y negociación

Contenido del capítulo


PERFIL DE PROYECTO Etapa cuatro: desempeño
Control de la fuga de un pozo de petróleo—Respuesta al Etapa cinco: terminación
desastre de la BP Equilibrio puntuado o equilibrio interrumpido
INTRODUCCIÓN 6.5 LOGRAR LA COOPERACIÓN INTERFUNCIONAL
6.1 CONFORMACIÓN DEL EQUIPO DEL PROYECTO Metas de orden superior
Identificar el conjunto de habilidades necesarias Normas y procedimientos
Identificar a las personas que cuentan con las habilidades Proximidad física
Hablar con los miembros potenciales del equipo y Accesibilidad
  negociar con los jefes funcionales Resultados de la cooperación: tarea y resultados
Crear planes alternativos  psicosociales
Conformar el equipo 6.6 EQUIPOS DE PROYECTOS VIRTUALES
6.2 CARACTERÍSTICAS DE LOS EQUIPOS PERFIL DE PROYECTO
EFECTIVOS DE PROYECTOS La tecnología de teleinmersión facilita la utilización de
Claro sentido de la misión   equipos virtuales
Interdependencia productiva 6.7 GERENCIA DEL CONFLICTO
Cohesión ¿Qué es conflicto?
Confianza Fuentes de conflicto
Entusiasmo Métodos para resolver conflictos
Orientación a los resultados 6.8 NEGOCIACIÓN
6.3 RAZONES POR LAS CUALES LOS EQUIPOS Preguntas que se deben formular antes de negociar
FRACASAN Negociación basada en principios
Metas poco desarrolladas o poco claras Búsqueda de opciones de ganancia mutua
Funciones e interdependencias del equipo de proyecto Insistencia en el uso de criterios objetivos
  mal definidas Resumen
Falta de motivación del equipo del proyecto Términos clave
Comunicación deficiente Preguntas para discusión
Liderazgo deficiente Estudio de caso 6.1 Columbus Instruments
Rotación de los miembros del equipo del proyecto Estudio de caso 6.2 El contador y los vaqueros
Comportamiento disfuncional Estudio de caso 6.3 Johnson & Rogers Software Engineering, Inc.
6.4 ETAPAS EN EL DESARROLLO DEL GRUPO Ejercicios de negociación
Etapa uno: formación Ejercicios en internet
Etapa dos: adaptación Preguntas de ejemplo del examen para la certificación PMP®
Etapa tres: asimilación Notas

186
Perfil de proyecto 187

Objetivos de aprendizaje
Al finalizar el capítulo, el estudiante estará en capacidad de:
1. Comprender los pasos requeridos en la construcción de equipos de proyectos.
2. Conocer las características de los equipos efectivos y por qué fallan los equipos de proyectos.
3. Conocer las etapas para el desarrollo de grupos.
4. Describir cómo lograr la cooperación interfuncional en equipos.
5. Conocer las ventajas y los desafíos de los equipos de proyectos virtuales.
6. Comprender la naturaleza del conflicto y evaluar los métodos de respuesta.
7. Comprender la importancia de la habilidad de negociación en la gerencia de proyectos.

PERFIL DE PROYECTO

Control de la fuga de un pozo de petróleo—Respuesta al desastre de la BP


El 20 de abril de 2010 se produjo una explosión catastrófica en la plataforma submarina de perforación petrolera
Horizon de la BP, a 50 millas de la costa de Luisiana en el golfo de México, y causó la muerte a 11 trabajadores, heridas
a otros 17 y un desastre ambiental, cuyos efectos aún están debatiéndose (véase la figura 6.1). Dos días después, la pla-
taforma se hundió y provocó que un tubo de 5,000 pies, que conectaba la boca del pozo a la plataforma de perforación,
se doblara. El 24 de abril, dispositivos robóticos descubrieron dos fugas en el tubo doblado, a casi una milla por debajo
de la superficie del océano. La boca del pozo estaba equipada para prevenir fugas, con una pila de dispositivos de 40
pies diseñados para sellar rápidamente el pozo, pero el mecanismo de prevención falló. Los resultados fueron la peor
pesadilla que cualquier compañía petrolera podría imaginar: un derrame de petróleo fuera de control, en un ambiente
inhóspito y remoto, que dejó a la empresa sin ningún medio obvio para corregir inmediatamente el desastre.
Una investigación preliminar de las causas de la explosión sugiere que una combinación de falta de mantenimiento,
procedimientos de perforación simplificados y una cultura de miedo o represalias llevaron a los trabajadores a tomar
atajos y correr riesgos. Por ejemplo, en la plataforma Deepwater Horizon, la British Petroleum (BP) decidió no instalar un
disparador acústico que podría haber cerrado el pozo en caso de que se dañara seriamente. Los disparadores acústicos son

US Coast Guard Photo / Alamy

FIGURA 6.1  Explosión de la plataforma submarina Horizon

(continúa)
188 Capítulo 6  •  Conformación del equipo del proyecto, conflicto y negociación

obligatorios en la mayoría de países desarrollados, pero Estados Unidos solo los recomienda y deja su elección a las compa-
ñías petroleras. Sin embargo, el reto inmediato que enfrentaban los ingenieros de BP era encontrar un medio eficaz para
tapar la boca del pozo de petróleo, que se encontraba cerca de un kilómetro bajo la superficie y lanzaba petróleo crudo a
una tasa de 60,000 barriles al día, directamente en el golfo. Sus esfuerzos para encontrar una solución creativa y efectiva
para contrarrestar la fuga de petróleo representan un excelente ejemplo de la gerencia de proyectos en emergencia, ya
que se vieron obligados a adaptarse y superar una serie de limitaciones complicadas, a fin de lograr sus metas.
La explosión se produjo debido a una presión anormal acumulada de gas metano dentro de uno de los tubos
de perforación (llamado “ elevador marino”) que, al acercarse a la superficie, se expandió rápidamente y se encen-
dió. Subiendo por la columna del elevador, el gas metano se expandió y estalló a través de una serie de sellos y
barreras antes de explotar: el ejemplo clásico de una explosión catastrófica. En general, los diversos procedimien-
tos que debían seguirse cuando se presentara una fuga de la boca de pozo en el mar, incluían:
• En la incineración in situ—la clave es atrapar en la superficie la mayor cantidad de la fuga de petróleo como sea
posible con plumas y otros artefactos flotantes y encenderlo para quemarlo en el sitio.
• Dispersantes—desde buques y aeronaves se rocían productos químicos sobre las manchas de petróleo para dis-
persarlas antes de que puedan flotar la costa y dañar la vida silvestre y las áreas ecológicas.
• Barreras—millas de barreras flexibles, flotantes, que contienen la propagación del petróleo pueden ser útiles en
aguas tranquilas o en áreas relativamente pequeñas.
Aunque BP y sus socios utilizaron todos estos medios para contener la rápida expansión de la mancha de petróleo,
solo se lograban éxitos parciales. Demasiado petróleo seguía brotando rápidamente de la boca del pozo dañada
en el lecho marino, a pesar de que estos esfuerzos de recuperación se ejecutaran muy bien. Peor aún, la explosión
había dañado tan severamente la boca del pozo que no había en el sitio válvulas en buen estado que pudieran
cerrarse. Las cámaras conectadas a las unidades sumergibles de control remoto indicaban que el petróleo salía a
una velocidad tan grande que prácticamente no había manera de detenerlo.
Este era el desafío de emergencia con el que se enfrentaban los ingenieros de la BP cuando comenzaron a plan-
tear estrategias para cerrar del pozo. En experiencias anteriores, la respuesta habitual era perforar “pozos de alivio”
desde otros ángulos dentro del eje afectado. Los pozos de alivio, básicamente, reducen la fuerza de la presión que
obliga el petróleo a salir a la superficie, y les permite a los ingenieros diseñar una tapa más tradicional para el pozo.
Infortunadamente, en este caso, se necesitaría mucho tiempo —probablemente semanas o incluso meses— para per-
forar los pozos de alivio. Mientras tanto, el petróleo seguiría brotando del pozo, dispersándose a través del golfo de
México y contaminaría las playas desde Texas hasta Florida. Los retrasos eran simplemente inaceptables.
La siguiente línea de tiempo para las soluciones indica cuán amplio era el rango de las alternativas plantea-
das por los ingenieros de BP, en busca de los medios más efectivos para sellar el pozo:
• 25 de abril—Primer intento para reparar el aparato de prevención de fugas. BP utilizó sumergibles operados
por control remoto para tratar de activar el mecanismo de prevención de fugas. Infortunadamente, una válvula
clave nunca había sido instalada completamente y fue imposible activar el dispositivo después de la explosión.
• 30 de abril—El uso de dispersantes químicos bajo la superficie. Equipos inyectan dispersantes químicos en el
aceite que fluía desde el pozo, tratando de romper el petróleo en pequeñas partículas antes de que este saliera
a la superficie. Los efectos no se conocían, pero el flujo de petróleo desde el pozo no se detuvo.
• 2 de mayo—BP comenzó a perforar el primero de dos pozos de alivio que luego podrían utilizarse para inyectar
“lodo de perforación” y cemento al pozo actual.
• 7 de mayo—BP construyó e instaló una cúpula de contención de acero de 40 pies de altura, esperando atrapar
el escape de petróleo y canalizarlo hacia las válvulas y tuberías de la parte superior de la cúpula. Sin embargo,
cuando los equipos descubrieron que la apertura de la cúpula estaba obstruida con una mezcla congelada de
agua y gas, se dejó a un lado esta alternativa.
• 16 de mayo—Los ingenieros de BP insertan con éxito un tubo de kilómetros de largo en el tubo de elevación
roto en la base de la boca del pozo para desviar parte del petróleo a un barco de perforación anclado en la su-
perficie. Durante nueve días, el tubo logró desviar cerca de 22,000 barriles de petróleo, pero infortunadamente
representaban solo una fracción del vertido total.
• 26 de mayo—La compañía implementó dos técnicas para el cierre de emergencia del pozo, el “top kill” y el
“junk shot.” En el “top kill,“ los ingenieros bombean lodo pesado directamente al pozo, con la esperanza de
que el peso del lodo supere la presión de liberación del petróleo y tapone el pozo. El “junk shot” es un procedi-
miento en el que se inyectan objetos, incluidas pelotas de golf y piezas de caucho, en el mecanismo de preven-
ción de fugas. Infortunadamente, ninguna de las dos técnicas lograron tapar la fuga.
• 31 de mayo—En otro intento por tapar el pozo, los ingenieros posicionaron robots submarinos para cortar lo
que quedaba del tubo de elevación colapsado, de modo que se pudiera colocar un tapón sobre el mecanismo
de prevención de fugas y así canalizar algo del petróleo a un buque cisterna en la superficie. A pesar de que
con esta iniciativa se comenzó a capturar una parte del petróleo, otra parte continuo fluyendo por debajo del
tapón a través de cuatro orificios de ventilación abiertos en el dispositivo (vease la figura 6.2). Los ingenieros no
Perfil de proyecto 189

Otro “Plan B”
para el pozo
Líneas de
metanol

BP asegura que si el procedimiento


“top kill” falla se instalará un dispositivo
similar a un tapón para capturar el
petróleo de la fuga y conducirlo a la
superficie
La siguiente opción
Cómo funciona el tapón del conjunto
de preventores esféricos submarinos
(Lower Marine Riser Package: LMRP)

1. El buque cisterna baja el tapón


del LMRP hasta el extremo de la Arandela
tubería de elevación, en el fondo de sellado
Dispositivos
marino
antierupción
2. Robots submarinos cortan el (Blowout
elevador dañado de los BOP

petróleo
Preventer: BOP)

Flujo de
3. La arandela de sellado del situados en la
tapón del LMRP encaja en la parte parte superior del
superior de los BOP para impedir la
entrada de agua de mar pozo
4. Se inyecta metanol en el tapón

Yingling/MCT/Newscom
para evitar que el hielo
hidratado obstruya el tubo Elevador dañado
elevador conectado al
5. El petróleo se desvía pozo de la plata-
hacia el buque cisterna en la forma antes de la
superficie explosión
Fuente: BP
Gráfica: Melina Yinging. Judy Treible

FIGURA 6.2  Tapón de petróleo montado en la parte superior de la


válvula de dispositivos antierupción

podían cerrar todos los orificios de ventilación como lo habían previsto. Sin embargo, esta iniciativa comenzó a
captar cerca de 15,000 barriles diarios.
• 16 de junio-–Se inició un segundo sistema de contención de efecto sifón para el petróleo y gas adicional del
pozo. Combinado con el primer sistema de taponamiento, los dos métodos bombeaban casi 25,000 barriles por
día, directamente a un buque en la superficie. Este barco no tenía capacidad de almacenamiento y el petróleo y
el gas se quemaban al llegar a la superficie. El 5 de julio, la BP anunció que sus esfuerzos de incineración conta-
bilizaban 25,000 barriles de petróleo y 57.1 millones de pies cúbicos de gas natural por día.
• 10 de julio—BP diseña un mejor sistema de taponamiento y lo instala en la parte superior de la boca del pozo.
Para el 15 de julio este nuevo sistema detuvo el flujo de petróleo del pozo. Los ingenieros continuaron contro-
lando la presión del pozo para asegurar su integridad.
• 3 de agosto—Los ingenieros completaron exitosamente el “static kill”, el bombeo de lodo a través de una vál-
vula del mecanismo de prevención de fugas, y en la carcasa de metal de la tubería utilizaron un procedimiento
similar al fallido “top kill.” Se pudo bombear barro lentamente y a baja presión debido a que el nuevo tapón
encima del pozo había cortado el flujo de petróleo. El barro forzó el regreso del petróleo y del gas al reservorio.
También se bombeó cemento para sellar el pozo.
• 21 de septiembre-–Después de casi cinco meses de intentos fallidos, el gobierno federal declaró el cierre del pozo.
El desastre de la plataforma submarina Horizon ha sido el derrame de petróleo más grande en la historia de Estados
Unidos, y sus efectos ambientales y económicos seguramente seguirán sintiéndose durante años en el futuro. Las causas de
la explosión son objeto de investigación y no reflejan bien la filosofía de operación de BP en la perforación y en los procedi-
mientos de mantenimiento. Sin embargo, si somos capaces de separar las causas de la catástrofe de las respuestas de la orga-
nización a esta, surge una imagen diferente de la BP en su reacción a una situación de emergencia. No hay duda de que, con
la fuga, el equipo de ingenieros de BP enfrentó una situación única y crítica. Además, debido a la configuración y otras res-
tricciones físicas, las respuestas tenían que filtrarse a través de la esfera de todo lo posible en esas circunstancias. Finalmente,
el tiempo desempeñaba un papel importante: cada día sin una solución traía más y más petróleo que brotaba desde el pozo
dañado. Aunque sin duda fue una catástrofe, la situación habría sido peor sin la creatividad y las habilidades de resolución
de problemas de los ingenieros de BP, dada una asignación tan crucial para la cual el fracaso no era una opción.1
190 Capítulo 6  •  Conformación del equipo del proyecto, conflicto y negociación

INTRODUCCIÓN
Las dificultades de la conformación y coordinación de un equipo eficaz pueden hacer de esta labor algo desalen-
tadora y muy compleja. Llegar a ser técnicamente competente en programación, presupuesto y evaluación de
proyectos es esencial para el desarrollo de las habilidades de la gerencia de proyectos; igualmente es importante
desarrollar una apreciación y voluntad de enfrentar los retos humanos del trabajo. La conformación de equi-
pos y la gerencia de conflictos son dos de las habilidades relacionadas con las personas más importantes que los
gerentes de proyectos deben cultivar, pero también las más difíciles de conseguir. Tenemos que usar nuestras
habilidades de liderazgo para negociar con los jefes de departamento el acceso de personal capacitado al equipo,
debemos reconocer que ningún equipo de proyecto viene “totalmente conformado” y listo para funcionar.
Simplemente agrupar un conjunto de diversos individuos no es lo mismo que conformar un equipo.
En este capítulo se ofrece una visión general de algunas de las tareas de comportamiento claves que enfren-
tan gerentes de proyectos: dotar de personal al equipo del proyecto, lograr un propósito común y un compro-
miso compartido, fomentar la cooperación transfuncional entre los miembros del equipo, reconocer las causas
de los conflictos y resolver los conflictos entre todos los interesados del proyecto. La mala noticia: este no es un
proceso fácil, no trata de fórmulas o cálculos de la misma manera que se hace para la estimación de la duración
de una tarea. Las “reglas” de conducta humana a menudo consisten en amplias generalizaciones que, en el mejor
de los casos, se utilizarán solo para proponer acciones de gerencia apropiadas. La buena noticia: cuando se evalúa
y se hace con cuidado, la gerencia del lado humano de la gerencia de proyectos puede ser igual de eficaz, gratifi-
cante e importante para el éxito del proyecto como cualquiera de las funciones técnicas.
Dotación de personal de proyectos, trabajo en equipo, cooperación multifuncional y gerencia de con-
flictos no son temas complementarios en la gerencia de proyectos; el estudio de estas habilidades es funda-
mental para fomentar nuestras competencias en una profesión muy compleja y difícil. En este capítulo no
solo se analizarán la conformación de equipos y los procesos de conflicto, sino que también se ofrecerán
algunos consejos preceptivos a los lectores sobre cómo mejorar estos procesos y nuestras habilidades en
el manejo del comportamiento humano. Un punto es claro: si tenemos que llevar a cabo proyectos con un
equipo de proyectos como nuestro principal recurso para hacer el trabajo y completar el proyecto, es vital
que aprendamos todo lo posible sobre cómo moldear a la gente en un equipo de alto rendimiento y cómo
controlar los inevitables conflictos que puedan surgir en el camino.

6.1  CONFORMACIÓN DEL EQUIPO DEL PROYECTO


Los equipos efectivos de proyectos no se generan por accidente. Una gran cantidad de trabajo y preparación
cuidadosa se requiere dar a cabo los pasos necesarios para encontrar el personal y desarrollar los miembros
del equipo hasta el punto en el que comiencen a funcionar en forma conjunta y el proyecto obtenga dividen-
dos positivos en su desempeño colectivo. El mejor escenario para un gerente de proyectos es hacerse cargo
de un proyecto con un equipo unificado integrado por personas que lucharon y fueron premiadas con su
membresía en el equipo. Infortunadamente, en muchas organizaciones, los equipos de proyectos se unen en
torno a otros criterios, sobre todo en torno al que esté disponible. Independientemente de las circunstancias,
el gerente de proyectos se enfrenta con el reto de conformar un equipo de proyecto cohesionado de alto ren-
dimiento, a partir de un conjunto de diversos individuos. Sin embargo, el procedimiento preferido debe ser
lo más estructurado posible; la dotación del personal debe estar muy bien alineada con el juicio del gerente de
proyectos de lo que es mejor para el proyecto.
La figura 6.3 ilustra cómo se puede asignar personal al equipo del proyecto. En muchas organizaciones,
este proceso surge como resultado de prolongadas negociaciones con los supervisores funcionales o departa-
mentales, como vimos en el capítulo 2. El diagrama de flujo de la figura 6.3 ilustra varios puntos de decisión
claves o interfaces críticas en el desarrollo de un equipo de proyectos.2

Identificar el conjunto de habilidades necesarias


La primera etapa en el desarrollo del equipo del proyecto es llevar a cabo una evaluación realista de los tipos
de habilidades que los miembros del equipo necesitan para complementarse entre sí y desempeñar sus fun-
ciones lo más eficaz posible dentro del proyecto. Por ejemplo, en proyectos de alta complejidad técnica es
imprescindible conocer la disponibilidad de recursos humanos calificados y su capacidad de agregar valor al
desarrollo del proyecto. Nadie podría embarcarse seriamente en un proyecto de desarrollo de software, sin
antes cerciorarse de que las medidas técnicas del proyecto se entienden claramente.
6.1  Conformación del equipo del proyecto 191

Identificar las
habilidades
requeridas
(de la EDT)

Identificar al personal
que cuenta con • Del personal asignado de
las habilidades forma permanente o
grupos funcionales

Hablar con los


• Explicar la naturaleza del
miembros potenciales
proyecto y evaluar
del equipo
su interés

Negociar con los


supervisores
funcionales

• Desarrollar la matriz
de inventario
de habilidades
SÍ Ajustar el • Desarrollar la matriz
¿Éxito?
equipo de responsabilidades
• Aclarar las funciones
• Aclarar los métodos
NO y procedimientos

Renegociar con
la alta gerencia


¿Éxito?

NO

Ajustar el cronograma, Notificar a la alta


Tratar de negociar
el presupuesto o gerencia de las
un apoyo parcial
prioridades del proyecto consecuencias

FIGURA 6.3  Pasos básicos para conformar un equipo de proyectos


Fuente: V. K. V. K. Verma. (1997). Managing the Project Team, p. 127. Upper Darby, PA: Project
Management Institute. Derechos de autor y todos los derechos reservados. El material de esta
publicación ha sido reproducido con permiso del PMI.

Identificar a las personas que cuentan con las habilidades


Una vez completada la evaluación razonable de las habilidades requeridas para el proyecto, se requiere una eva-
luación complementaria de la disponibilidad de personal que cuente con las habilidades necesarias. Tenemos
dos opciones: (1) contratar nuevo personal para el proyecto (por ejemplo, en muchos casos, las empresas con-
tratan personal por un periodo fijo mientras dure un proyecto) o (2) capacitar al personal actual para alcanzar
competencias en las habilidades que necesitarán para llevar a cabo las tareas. La decisión final a menudo se
reduce a una evaluación costo/beneficio: ¿quién puede hacer el trabajo? ¿El costo de contratación o de forma-
ción de la persona para hacer el trabajo es muy costoso? ¿Una vez que la persona ha sido entrenado/contrata-
dos, estas habilidades serán de beneficio continuo para la empresa?
192 Capítulo 6  •  Conformación del equipo del proyecto, conflicto y negociación

Hablar con los miembros potenciales del equipo y negociar con los jefes
funcionales
El tercer paso en el proceso de conformación del equipo del proyecto consiste en abrir comunicación con
los posibles candidatos para el equipo y evaluar su nivel de interés en participar en el proyecto. En algunos
casos, el personal tiene una gran autoridad en la asignación de su tiempo a los proyectos. Sin embargo, en la
mayoría de los casos (sobre todo dentro de las organizaciones funcionales), todos los especialistas funciona-
les están bajo la autoridad de los jefes de departamento. Por tanto, en algún momento el gerente de proyectos
debe comenzar a entablar negociaciones con los jefes funcionales para encajar los servicios de los futuros
miembros del equipo de proyecto.
Estas negociaciones pueden ser complejas y largas. Los gerentes departamentales generalmente no se
oponen a la utilización de su personal en los proyectos. Sin embargo, ellos están principalmente orientados
a todo lo que tiene que ver con el buen funcionamiento de su organización. Privar a un gerente funcional de
personal clave para servir en un equipo de proyectos puede verse como una amenaza para un departamento que
funciona sin problemas. Por tanto, se requieren negociaciones. Entre las cuestiones que deben decidirse están:
1. ¿Por cuánto tiempo se requieren los servicios de los miembros del equipo?  Los miembros del equipo
del proyecto pueden asignarse de tiempo completo (40 horas por semana) o tiempo parcial (menos de
40 horas por semana). Además, el miembro del equipo puede asignarse por un periodo determinado
(por ejemplo, seis meses) o por la duración del proyecto.
2. ¿Quién debe elegir a la persona que se asignará al proyecto?  Otro punto de la negociación es quién
debe seleccionar a la persona para formar parte del equipo del proyecto. El gerente funcional puede
tener sus propias ideas acerca de la mejor opción, mientras que el gerente de proyectos podrá emplear
criterios diferentes y llegar a otros posibles candidatos.
3. ¿Qué sucede cuando se presenten circunstancias especiales?  En caso de alguna circunstancia de
emergencia o especial, el jefe del departamento funcional podría mantener el control de los miem-
bros del equipo o tener la opción regresar al individuo a trabajar en las actividades departamentales.
¿Cómo se definen las “emergencias”? Si el miembro del equipo es devuelto a su departamento, ¿el jefe
funcional debe proporcionar un reemplazo? ¿Cuál es la máxima cantidad de tiempo que un miembro
del equipo puede ser removido de su cargo en el proyecto? Todas estas preguntas son importantes y
deben contestarse antes de la designación de los miembros del equipo del proyecto.
La mayoría de los recursos del proyecto se negocian con los jefes de departamento. Este punto es cru-
cial: para la mayoría de gerentes de proyectos, el control absoluto sobre los miembros del equipo del proyecto
puede ser limitado, sobre todo al principio del proceso, cuando se realizan las asignaciones del equipo del
proyecto. La mejor estrategia que un gerente de proyectos puede plantear en este punto es haber pensado
cuidadosamente sobre los tipos de conocimientos y habilidades que se requieren para la terminación exitosa
del proyecto y comenzar la negociación con estos objetivos claros en mente. Tratar a los gerentes funcionales
como aliados y no adversarios. Si la organización apoya el proyecto, los departamentos funcionales lo van a
apoyar también, pero su nivel de apoyo debe ser cuidadosamente planeado.

Crear planes alternativos


¿Cuáles son sus opciones como gerente de proyectos, cuando los recursos no están disponibles? Supongamos
que se necesitan tres ingenieros de diseño altamente capacitados para el proyecto y el jefe de ingeniería no
está dispuesto a desprenderse de ellos o negociar un compromiso. En la figura 6.3 se muestra, en el caso en
que las negociaciones con los gerentes funcionales y altos gerentes no son fructíferas, que el gerente de pro-
yectos se enfrenta con tres alternativas básicas.

TRATAR DE NEGOCIAR UN APOYO PARCIAL   La mejor alternativa a una negativa rotunda es buscar
alguna ayuda limitada. Una vez que el personal se asigna al proyecto, incluso en términos limitados, se forma
la base para su regreso al jefe de departamento en un momento posterior en el que se puede pedir de nuevo,
mientras el retraso del proyecto es solo marginal. En efecto, este principio sostiene que es mejor tener la
mitad de un pan que ninguno.

AJUSTAR LA PROGRAMACIÓN Y LAS PRIORIDADES DEL PROYECTO CONSECUENTEMENTE  Cuando


los recursos críticos no están disponibles, el cronograma del proyecto debe ajustarse para reflejar este hecho.
6.2  Características de los equipos efectivos de proyectos 193

Como se señalará en el capítulo 12, Gerencia de recursos, no tiene sentido desarrollar un programa sofis-
ticado para el proyecto si no está respaldado por los recursos. Para decirlo de otra manera: solo cuando
podamos ajustar la gente con las tareas del proyecto, podremos avanzar. Con la incapacidad de convencer a
los gerentes funcionales que se necesitan recursos para apoyar el proyecto, deben realizarse ajustes serios y
honestos a todos los planes del proyecto, incluidos los documentos de alcance, cronograma, evaluación de
riesgos, etcétera.

NOTIFICAR A LA ALTA GERENCIA DE LAS CONSECUENCIAS   Al no tener los recursos necesarios se debe
reportar a la alta gerencia, los patrocinadores finales del proyecto. Es posible que, al final, se conviertan en
los árbitros finales de la cuestión de los recursos y del personal. Ante la persistente resistencia de un gerente
funcional, el único recurso puede ser presentarle a la alta gerencia, tan francamente como sea posible, las con-
secuencias del éxito del proyecto sin el apoyo suficiente. La decisión final entonces se reduce a la alta gerencia:
ellos podrían apoyar el proyecto y requerir que el personal se completará de acuerdo con lo solicitado, sugerir
un compromiso o apoyar al gerente funcional. En los dos primeros casos, el proyecto proseguirá; en el tercero,
la alta gerencia está terminando efectivamente el proyecto antes de que este haya comenzado.

Conformar el equipo
Cuando el proyecto se haya aprobado y dotado de personal , el último paso es la conformación del equipo
del proyecto. Esto implica el desarrollo de una matriz de inventario de habilidades que identifique las habi-
lidades necesarias para el proyecto contra las habilidades adquiridas y utilizar la metodología de la matriz
de asignación de responsabilidades (responsibility activity matrix: RAM) (analizada en el capítulo 5).
Además, todas las funciones y responsabilidades del equipo del proyecto deben aclararse, junto con todos
los métodos, expectativas y procedimientos operativos estándares del equipo del proyecto. Cuando alguno
de estos no exista, se requerirá comenzar a establecerlo.

6.2  CARACTERÍSTICAS DE LOS EQUIPOS EFECTIVOS DE PROYECTOS


Una gran cantidad de investigaciones analizan las cualidades que poseen los equipos efectivos y cómo estas
mismas cualidades no se encuentran en los grupos menos efectivos. Los equipos exitosos comparten carac-
terísticas comunes subyacentes, incluidos un claro sentido de la misión, la comprensión de las interdepen-
dencias del equipo, la cohesión, un alto nivel de confianza, un sentido compartido de entusiasmo y una
orientación hacia los resultados.

Claro sentido de la misión


Un factor determinante del éxito del proyecto es la clara misión del proyecto.3 Además, ese sentido de misión
debe ser mutuamente entendido y aceptado por todos los miembros del equipo. La investigación ha demos-
trado que una misión del proyecto claramente entendida es el predictor número uno del éxito del desarro-
llo del proyecto.4 Dos aspectos importantes son claros: primero, los equipos de proyectos funcionan bien
cuando hay un claro sentido del propósito o de los objetivos de su proyecto; segundo, cuanto más amplia-
mente compartidos y entendidos sean los objetivos, mejor será el rendimiento del proyecto. La alternativa es
permitir que el gerente de proyectos funcione como el eje de una rueda, con cada miembro del equipo como
un radio separado, interactuando solamente a través del gerente de proyectos. Esta disposición no es tan útil
o exitosa como aquella en la que todos los miembros del equipo entienden los objetivos generales del pro-
yecto y cómo su desempeño contribuye a la consecución de esos objetivos.
Un error que a veces cometen los gerentes de proyectos es segmentar el equipo en cuanto a sus funcio-
nes, dándole a cada miembro una tarea pequeña, bien especificada, pero sin el significado de cómo la actividad
contribuye al esfuerzo general de desarrollo del proyecto. Este enfoque es un grave error por varias razones
importantes. Primera, el equipo del proyecto es la mejor fuente de la gerencia para la resolución de problemas,
tanto reales como potenciales. Si el equipo se mantiene en la oscuridad, los miembros que podrían ayudar con
el buen desarrollo del proyecto mediante la participación en otros aspectos de la instalación no estarían en con-
diciones de contribuir de manera útil. Segunda, los miembros del equipo se resienten cuando se mantienen en
la oscuridad diversas características del proyecto en el que están trabajando. Conscientemente o no, cuando los
gerentes de proyectos mantiene a su equipo aislado y participando en tareas fragmentadas, envían la señal de
que confían o no confían en su equipo o no sienten que su equipo tenga la competencia para abordar cuestiones
194 Capítulo 6  •  Conformación del equipo del proyecto, conflicto y negociación

relacionadas con el esfuerzo general de la implementación. Por último, desde una perspectiva de “apagar incen-
dios”, simplemente tiene sentido para los líderes del equipo mantener a su gente al tanto de la situación del
proyecto. Cuanto más tiempo se dedique a la definición de metas y a aclarar las funciones en las etapas iniciales
del desarrollo del equipo, menos tiempo se necesitará para resolver problemas y disputas en el futuro.

Interdependencia productiva
La interdependencia se refiere al grado de actividad conjunta entre los miembros del equipo que se requiere
para completar un proyecto. Si, por ejemplo, un proyecto puede completarse a través del trabajo de un
pequeño grupo de personas o de un departamento en una organización, la interdependencia necesaria se
considera baja. En la mayoría de situaciones, sin embargo, un gerente de proyectos debe conformar el equipo
con miembros de diferentes áreas funcionales de la organización. Por ejemplo, la introducción de un pro-
yecto de IT en una gran empresa posiblemente podría requerir la entrada o esfuerzos de un equipo que
incluye a miembros de los departamentos de sistemas de información, ingeniería, contabilidad, marketing y
administración. Como indica el concepto de diferenciación, cada uno de estos individuos aporta al equipo
sus nociones preconcebidas de los papeles que debería desempeñar, la importancia de sus diversas contribu-
ciones y otras actitudes localistas.
Interdependencia se refiere al grado de conocimiento que tienen los miembros del equipo y la importancia
que ellos le conceden a la interrelación de sus esfuerzos. El desarrollo de una comprensión de las interdependen-
cias mutuas implica el desarrollo de un nivel mutuo de reconocimiento por las fortalezas y aportes que cada miem-
bro del equipo trae a la mesa, una condición previa para el éxito del equipo. Los miembros del equipo deben ser
conscientes no solo de sus propias contribuciones, sino también de cómo su trabajo encaja en el esquema general
del proyecto y, además, de cómo se relaciona con el trabajo de miembros del equipo de otros departamentos.

Cohesión
La cohesión, en su nivel básico, simplemente se refiere al grado de atracción mutua de los miembros del equipo
y hacia su tarea. Es la fuerza del deseo que todos los miembros tienen para seguir siendo un equipo. Se supone
que la mayoría de los miembros del equipo del proyecto necesitan una razón o unas razones para aportar sus
conocimientos y tiempo para la terminación con éxito de un proyecto. A pesar de que se han asignado al pro-
yecto, para muchas personas, este proyecto puede competir con otras obligaciones o responsabilidades que van
en otras direcciones. Los gerentes de proyectos trabajan para construir un equipo cohesionado, como punto de
partida en la realización de sus tareas. Dado que la cohesión se basa en la atracción que el grupo tiene para cada
miembro individual, los gerentes deben hacer uso de todos los recursos a su disposición, incluidos los sistemas
de recompensa, reconocimiento, evaluaciones de desempeño y cualquier otra fuente de recompensa organiza-
cional, para inducir a los miembros del equipo a dedicar tiempo y energía en promover los objetivos del equipo.

Confianza
Confianza significa diferentes cosas para diferentes personas.5 Para un equipo de proyecto, la confianza se
entiende mejor como el nivel de comodidad que tiene el equipo con cada miembro individual. Teniendo en
cuenta ese nivel de comodidad, la confianza se manifiesta en la capacidad y la voluntad del equipo para abor-
dar directamente las diferencias de opinión, valores y actitudes y lidiar con ellos en consecuencia. La confianza
es el denominador común sin el cual las ideas de la cohesión del grupo y el aprecio se discuten. Lo interesante
acerca de la confianza es que en realidad puede fomentar el desacuerdo y el conflicto entre los miembros del
equipo. Cuando los miembros de un equipo del proyecto han desarrollado un nivel de confort en el que están
dispuestos a confiar en las opiniones de los demás, sin importar cuántas opiniones divergentes haya de las
suyas, pueden ventilarse puntos de vista opuestos, para discutir temas, e incluso para argumentar. Debido a
que confiamos los unos en los otros, los desacuerdos no se tratan como ataques personales, reconocemos que
las opiniones diferentes de las nuestras son valiosas y pueden contribuir al proyecto. Por supuesto, antes de
que resultados positivos puedan provenir de desacuerdo, tenemos que desarrollar la confianza.
Hay unas maneras en las que los miembros del equipo comienzan a confiar entre sí. Primera, es impor-
tante que el gerente de proyectos genere una mentalidad de “Lo que pasa aquí, se queda aquí”, en la que los
miembros del equipo no se preocupen en que sus opiniones puedan divulgarse o sus confidencias traicionadas.
La confianza primero debe demostrarse con el profesionalismo del gerente de proyectos y la forma en que trata
a todos los miembros del equipo. Segunda, la confianza se desarrolla con el tiempo. No hay manera de poner
en marcha la confianza entre las personas. Continuamente nos examinan para garantizar que somos dignos de
6.3  Razones por las cuales los equipos fracasan 195

confianza. Tercera, la confianza es una cuestión de “todo o nada.” O somos dignos de confianza o no lo somos.
No hay tal cosa como poco confiable. Cuarta y última, la confianza se produce en varios niveles:6 (1) la confianza
que se refiere a la interacción profesional y a la expectativa de la competencia de la otra persona (“Yo confío en
que usted sea capaz de realizar la tarea”); (2) la confianza que se produce en un nivel de integridad (“Yo confío
en usted al honrar sus compromisos”); y (3) la confianza que existe en un nivel emocional basado en la intuición
(“Se siente bien o le permite tomar esta decisión”). Por tanto, es importante reconocer que la confianza entre los
miembros del equipo es compleja, requiere tiempo para desarrollarse, depende de la historia y puede ocurrir en
varios niveles, cada uno de ellos importante en el desarrollo de un equipo de alto rendimiento.

Entusiasmo
El entusiasmo es la clave para la creación de la energía y el espíritu que impulsan los esfuerzos efectivos de proyec-
tos. Un método para generar entusiasmo en el equipo es promover la idea de la eficacia, la creencia de que si tra-
bajamos hacia ciertas metas, estas se alcanzarán. El entusiasmo cataliza la dirección positivamente, genera energía
positiva hacia el proyecto, mientras haya compromiso con sus metas. Los gerentes de proyectos, por tanto, son los
más capacitados para promover un sentido de entusiasmo en el equipo del proyecto, al crear un ambiente que es:
• Desafiante—Cada miembro del proyecto percibe que su papel le ofrece la oportunidad de crecimiento
profesional y personal, un nuevo aprendizaje y la capacidad de probarse profesionalmente.
• Solidario—Los miembros del equipo adquieren un sentido de espíritu de equipo y la identidad de
grupo que crea la sensación de exclusividad, en relación con el proyecto. Todos los miembros del
equipo trabajan en colaboración, se comunican a menudo y tratan las dificultades como oportunidades
para el intercambio y la solución conjunta de problemas.
• Personalmente gratificante—Los miembros del equipo llegan a ser más entusiastas cuando perciben
beneficios personales derivados de la terminación exitosa del proyecto. Vincular la oportunidad de
desarrollo personal con el desempeño del equipo del proyecto les da a todos los miembros del equipo
un sentido de propiedad del proyecto y un gran interés en su realización exitosa.
La importancia del entusiasmo entre los miembros del equipo del proyecto se ilustra mejor con un
ejemplo reciente. Un líder de equipo había sido asignado a la reingeniería de un proceso de fabricación en
una planta de alta producción en Nueva Inglaterra. A pesar de su entusiasmo y energía inicial, fue sintién-
dose cada vez más frustrado con su equipo del proyecto, pues la mayoría de los miembros fue asignada al
proyecto sin ningún tipo de estudio. Su principal preocupación fue cómo tratar con la letanía constante de
“No podemos hacer eso aquí” que había oído cada vez que sugirió cambiar un procedimiento o intentar
algo nuevo. Un lunes por la mañana, los miembros de su equipo entraron en la oficina y se encontraron con
las palabras “¡SÍ SE PUEDE!” pintadas en letras de tres metros de altura en una pared. (El fin de semana, el
gerente de proyectos había entrado y hecho un poco de redecoración). A partir de ahí, el lema ¡SÍ SE PUEDE!
se convirtió en el tema del equipo y tuvo un gran efecto en el éxito del proyecto.

Orientación a los resultados


La orientación a los resultados sugiere que cada miembro del equipo del proyecto se comprometa a alcanzar
las metas del proyecto. El gerente de proyectos puede influir en el rendimiento del equipo de muchas mane-
ras, pero al enfatizar constantemente en la importancia de la ejecución de la tarea y en los resultados del pro-
yecto todos los miembros del equipo estarán unidos y enfocados hacia una misma orientación. Algunos se
han referido a este fenómeno como la actitud de “los ojos en el premio”, una característica generalizada entre
los equipos de proyectos exitosos. El beneficio de la orientación hacia los resultados es que reúne a los miem-
bros del equipo continuamente alrededor de los aspectos significativos, lo que les evita malgastar tiempo y
recursos en problemas que pueden ser solo periféricos a las principales metas del proyecto.

6.3  RAZONES POR LAS CUALES LOS EQUIPOS FRACASAN


Debido a que los desafíos involucrados en la conformación de equipos del proyecto de alto rendimiento son tan
profundos, no extraña que los equipos de proyectos no alcancen su potencial en muchas circunstancias. Los equipos
operan con un rendimiento menor al óptimo por varias razones, incluidos objetivos poco desarrollados o poco cla-
ros, funciones e interdependencias del equipo de proyecto mal definidas, falta de motivación del equipo de proyecto,
mala comunicación, liderazgo deficiente, rotación de los miembros del equipo y comportamiento disfuncional.7
196 Capítulo 6  •  Conformación del equipo del proyecto, conflicto y negociación

Metas poco desarrolladas o poco claras


Una de las causas más comunes del fracaso de un equipo de proyectos es la falta de objetivos claros y bien
entendidos. Cuando las metas del proyecto se fragmentan, cambian constantemente o se comunican mal, el
resultado es un alto grado de ambigüedad. Esta ambigüedad es muy frustrante para los miembros del equipo
del proyecto por una serie de razones.

LAS METAS POCO CLARAS PERMITEN MÚLTIPLES INTERPRETACIONES   El problema más común
con las metas poco claras es que le permiten a cada miembro múltiples interpretaciones que a menudo
difieren de los objetivos del proyecto. Como resultado, en lugar de ayudar al equipo a centrarse en el
proyecto que les ocupa, estas metas en realidad sirven para aumentar los desacuerdos, ya que cada uno
interpreta las metas del proyecto de diferentes maneras.

LAS METAS POCO CLARAS MINAN LA VOLUNTAD DE LOS MIEMBROS DEL EQUIPO PARA TRABAJAR
JUNTOS  Cuando los miembros del equipo se enfrentan con metas ambiguas, cada persona las interpreta a
su manera. Cuando se utilizan metas para apoyar a las personas y no al equipo, con frecuencia esto conduce a
situaciones en las cuales el deseo de una persona por satisfacer las metas del proyecto, como él las interpreta,
entra en conflicto con el deseo de otro miembro del equipo por satisfacer las suyas.

OBJETIVOS POCO CLAROS AUMENTAN EL CONFLICTO  Los conflictos del equipo del proyecto se
refuerzan por metas vagas que permiten múltiples interpretaciones. En lugar de trabajar en la realización
del proyecto, los miembros del equipo gastan energía y tiempo en conflictos entre sí escudriñando los
objetivos del proyecto.

Funciones e interdependencias del equipo del proyecto mal definidas


La interdependencia del equipo es un estado en el que las actividades de unos miembros del equipo se coordi-
nan y complementan con el trabajo de otros miembros del equipo del proyecto. Hasta cierto punto, todos los
miembros del equipo dependen mutuamente y deben trabajar en colaboración con el fin de lograr las metas
del proyecto. Los equipos de alto desempeño se estructuran de tal forma que dejan poca ambigüedad respecto
a los papeles y responsabilidades individuales. Cuando las asignaciones o responsabilidades de los miembros
del equipo no quedan claras, es natural que se produzcan desacuerdos o se pierda tiempo en el esclarecimiento
de las tareas. Otro problema serio con las funciones mal definidas es la pérdida de tiempo significativo entre
las actividades del proyecto. Cuando los miembros del equipo no son conscientes de sus funciones e inter-
dependencias, en relación con los otros miembros del equipo, comúnmente se pierde tiempo en el proyecto
debido a transiciones pobres, cuando se finalizan tareas, y se espera que comiencen las que siguen.

Falta de motivación del equipo del proyecto


Un problema común con el bajo rendimiento de los equipos de proyectos es la falta de motivación de sus
miembros. La motivación es generalmente un fenómeno muy individualista, lo cual sugiere que los factores
que motivan a uno de los miembros del proyecto (por ejemplo, dificultad técnica, oportunidades de pro-
greso) pueden no ser motivadores para otro miembro. Cuando la motivación del equipo de proyecto en
general es baja, los resultados del proyecto, naturalmente, se afectan, debido a que los miembros del equipo
se desempeñan por debajo del óptimo. Algunas de las razones por las cuales la motivación del equipo de
proyecto puede ser baja son las siguientes.

EL PROYECTO SE PERCIBE COMO INNECESARIO  Cuando los miembros del equipo perciben los proyectos
como poco importantes, lógicamente, su motivación para desempeñarse bien se afecta. Por tanto, la percep-
ción de un proyecto como “innecesario” por los miembros del equipo del proyecto puede ser correcta o no,
pero si la organización y el gerente de proyectos permiten que esta interpretación llegue a ser permanente,
será muy difícil lograr una alta motivación en el equipo. En consecuencia, los gerentes de proyectos deben
comunicarle a su equipo, lo más honestamente posible, los beneficios del proyecto, sus metas y por qué el
equipo es importante para la organización.

EL PROYECTO PUEDE TENER BAJA PRIORIDAD  Los miembros del equipo dentro de las organizacio-
nes a menudo son conscientes de las iniciativas de proyectos de alta prioridad y de las que no lo son. Las
6.3  Razones por las cuales los equipos fracasan 197

comunicaciones internas de la empresa, incluidos boletines, correos electrónicos y otros métodos para divul-
gar las actividades, identifican claramente los proyectos claves o importantes para la administración y cuáles
proyectos no lo son. Cuando los miembros del equipo del proyecto perciben que están trabajando en un pro-
yecto de baja prioridad, adoptan un nivel de compromiso bajo y tienen poca motivación para desempeñarse
bien.

Comunicación deficiente
La falta de comunicación se produce por una variedad de razones. Por ejemplo, los miembros del equipo del
proyecto pueden tener dudas sobre la estructura del proyecto y las interdependencias entre los miembros
del equipo, por lo que no saben con quién se espera que compartan información. Otra razón por cual se
puede romper la comunicación dentro del equipo del proyecto es que algunos miembros del equipo no estén
dispuestos a compartir información, y ven esto como una fuente de poder sobre los demás miembros del
equipo. La comunicación también puede interferirse dentro del equipo del proyecto, debido a las diferentes
orientaciones funcionales o profesionales de sus miembros. El personal técnico, como ingenieros, se sienten
cómodos utilizando una jerga científica o técnica difícil de entender para el personal no técnico. Del mismo
modo, los profesionales con antecedentes financieros pueden usar terminología relacionada con negocios
que no es clara para los miembros del equipo técnico.
La clave para resolver muchos de los problemas de comunicación radica en la buena voluntad del
gerente de proyectos para establecer y hacer cumplir las normas del intercambio de información entre los
miembros del equipo, mediante la creación de un ambiente dentro del equipo del proyecto que fomente
intercambios francos y abiertos. Otros mecanismos para fomentar la cooperación entre departamentos fun-
cionales se examinan más adelante, en este capítulo.

Liderazgo deficiente
En el capítulo 4 se analizó la importancia del enfoque de liderazgo del gerente de proyectos, con gran detalle.
Debido a que este individuo es el eje que sostiene el equipo unido, el estilo de liderazgo elegido por el gerente
de proyectos es promotor o inhibidor de la clave en la efectividad de los equipos de proyectos. Los gerentes
de proyectos que adoptan un liderazgo de “estilo único para todos” no reconocen que los diferentes estilos
de liderazgo se requieren para obtener el mejor rendimiento de cada miembro del equipo. Además, algu-
nos gerentes de proyectos adoptan un enfoque de liderazgo que puede ser completamente antiético para el
equipo del proyecto, con el que intimidan, acosan o amenazan a los miembros del equipo con la creencia de
que la clave para el alto rendimiento del equipo del proyecto se basa en crear una atmósfera de miedo y ansie-
dad. Los líderes exitosos de proyectos entienden que los estilos de liderazgo dependen de una serie de cri-
terios inherentes al equipo del proyecto—incluidos la composición del equipo, los niveles de motivación, la
experiencia y cualificación de los miembros del equipo—y en consecuencia modifican su estilo de liderazgo.

Rotación de los miembros del equipo del proyecto


Un problema común en muchas organizaciones es que los miembros del equipo se asignan a un proyecto y
luego inesperadamente se reasignan. Cuanto mayor sea la rotación de los miembros del equipo del proyecto,
más se altera la capacidad del gerente de proyectos para generar cohesión en el equipo. Además, el hecho
de estar continuamente añadiendo y quitando personal de los equipos de proyectos causa problemas con
el aprendizaje y trabajo en equipo. En investigaciones se ha encontrado que el hecho de añadir miembros
al equipo de un proyecto en desarrollo, con frecuencia, genera retrasos en el proyecto y afecta la curva de
aprendizaje. Los nuevos miembros del equipo necesitan tiempo para ponerse al día con el proyecto, no tie-
nen clara la estructura o las relaciones del equipo y no entienden la dinámica interna del equipo.
Aunque el mejor escenario de los gerentes de proyectos es ejecutar proyectos en los que los miembros
del equipo no cambian, la práctica dice que debemos prever la posibilidad de rotación y estudiar estrategias
que eviten la mínima repercusión sobre la programación del proyecto, cuando haya rotación. Un método
para minimizar esta repercusión es que el gerente de proyectos exija que todos en el equipo entiendan, lo más
claramente posible, no solo su propio papel, sino también el de los demás miembros del equipo, con el fin de
que sean capaces de apoyar aquellas actividades que podrían retrasarse debido a la reasignación de personal
fuera del proyecto. Otra opción es que el gerente de proyectos trabaje en estrecha colaboración con los jefes
de departamentos funcionales, a fin de anticiparse a la eventualidad de que los miembros del equipo del pro-
yecto abandonen prematuramente el equipo, y empiecen a preparar potenciales sustitutos.
198 Capítulo 6  •  Conformación del equipo del proyecto, conflicto y negociación

Comportamiento disfuncional
El comportamiento disfuncional se refiere a actos perjudiciales de algunos miembros del equipo del proyecto
debido a problemas de personalidad, agendas ocultas o problemas interpersonales. A veces, la solución sim-
plemente es hacerles un llamado a los miembros del equipo para que reconozcan estos comportamientos y
tomen medidas para corregir el problema. Otras veces, casos graves de comportamiento disfuncional pueden
requerir que un miembro del equipo sea retirado del proyecto.

6.4  ETAPAS EN EL DESARROLLO DEL GRUPO


El proceso de desarrollo del grupo es dinámico.8 Los grupos atraviesan varias etapas de maduración fácilmente
identificables que, por lo general, se encuentran en una variedad de organizaciones e incluyen grupos conforma-
dos para una variedad de propósitos. Estas etapas se ilustran en el cuadro 6.1 y en la figura 6.4.9

CUADRO 6.1  Etapas en el desarrollo del grupo

Etapa Características
Formación Los miembros se conocen entre sí y se sientan las bases de las reglas de juego del
proyecto y del equipo.
Adaptación Comienza el conflicto debido a que los miembros del equipo empiezan a resistirse a la
autoridad y a demostrar agendas y prejuicios ocultos.
Asimilación Los miembros acuerdan procedimientos de operación y tratan de trabajar juntos, desarro-
llar relaciones más estrechas y se comprometen con el proceso de desarrollo del proyecto.
Desempeño Los miembros del grupo trabajan en conjunto para llevar a cabo sus tareas.
Terminación Los grupos se pueden disolver ya sea después de la terminación del proyecto o mediante
la reasignación significativa de personal del equipo.

Terminación Convocatoria

4. Desempeño 1. Formación
ad

In
id

cl
tiv

us

• Confiado • Silencioso
uc

• Cortés
od

• Flexible
n
Pr

• Solidario • Vigilado
• Confidente • Impersonal
• Eficiente • Formal
• Alta moral • Alta moral

Productivo Probado
Organizado Lucha interna
• Establece • Conflicto sobre
procedimientos el control
• Desarrolla habilidades • Confrontaciones
de equipo • Alienación
• Enfrenta los problemas • Agendas
• Reconstruye la moral personales
Co

• Baja moral
l

3. Asimilación 2. Adaptación
op

ro
nt
er

Co
ac

n

FIGURA 6.4  Etapas en el desarrollo del grupo


Fuente: V. K. Verma. (1997). Managing the Project Team, p. 71. Upper Darby, PA: Project
Management Institute. Derechos de autor y todos los derechos reservados. El material de esta
publicación ha sido reproducido con permiso del PMI.
6.4  Etapas en el desarrollo del grupo 199

Etapa uno: formación


La formación consta del proceso o de los métodos utilizados para moldear un conjunto de individuos en un
equipo de proyecto coherente. Esta etapa se refiere, a veces, como la etapa de “forcejeo”, puesto que los miem-
bros del equipo no están seguros de las metas del proyecto, pueden desconocer a otros miembros del equipo y
están confundidos acerca de sus propias tareas.10 Los miembros del equipo comienzan a familiarizarse con los
otros y a hablar de los propósitos del proyecto, de la forma en que perciben sus papeles, de qué tipos de patro-
nes de comunicación se utilizan y de cuáles serán los comportamientos aceptables dentro del grupo. Durante
la etapa de formación, se establecen algunas normas preliminares del comportamiento, incluidas las reglas de
interacción (quién está realmente a cargo y cómo se espera que los miembros interactúen) y de actividad (qué
tan productivos se espera que sean los miembros del equipo). Cuanto más rápido se realice esta fase, mejor; así
se evitarán ambigüedades más adelante. En estos primeros encuentros, el papel del líder del equipo es crear la
estructura y establecer el tono para la cooperación futura y las actitudes positivas de cada miembro.

Etapa dos: adaptación


La adaptación se refiere a las reacciones naturales que los miembros del equipo tienen hacia las normas básicas
iníciales. Los miembros comienzan a probar los límites y restricciones impuestos a su comportamiento. La adap-
tación es una etapa conflictiva en la que los patrones preliminares de liderazgo, las relaciones de dependencia,
las normas de trabajo y los comportamientos interpersonales se desafían y, tal vez, se restablecen. Durante esta
etapa, probablemente el líder del equipo comience a ver a varios miembros del grupo que demuestran agendas
personales, tratan de desafiar o de reescribir las reglas del equipo y muestran prejuicios hacia sus compañeros de
otros orígenes funcionales. Por ejemplo, un miembro del equipo puede decidir unilateralmente que no es necesa-
rio asistir a todas las reuniones del equipo, y propone en su lugar participar más adelante en el proyecto cuando
sea “realmente necesario.” Otros comportamientos incluyen relaciones no tan sutiles con los miembros de otros
departamentos (“Oye, ¿qué hace aquí, en un proyecto técnico, la gente de marketing?”) o antiguas hostilidades
entre individuos que pueden resurgir. La adaptación es una fase muy natural a través de la cual todos los grupos
transitan. En la segunda mitad de este capítulo se abordan formas de manejar todo tipo de conflictos.

Etapa tres: asimilación


La asimilación es una regla no escrita de comportamiento. En la etapa de asimilación, el comportamiento
del grupo implica que los miembros del equipo establecen de mutuo acuerdo sus prácticas y actitudes. Las
normas ayudan al equipo a determinar la forma en que se deben tomar decisiones, la frecuencia con que se
deben reunir, qué nivel de franqueza y confianza tendrán los miembros y cómo se resolverán los conflictos.
La investigación ha demostrado que durante la etapa de asimilación de normas, la cohesión del grupo crece
hasta alcanzar su nivel más alto. Se desarrollan relaciones cercanas, un sentido de interés común, surgen el
aprecio y los sentimientos de camaradería y la responsabilidad compartida se evidencia. La etapa de asimila-
ción establece una base saludable sobre la cual comienza el trabajo real del equipo.

Etapa cuatro: desempeño


El verdadero trabajo del equipo del proyecto se lleva a cabo durante la etapa de desempeño. Solamente
cuando las tres primeras fases se han abordado adecuadamente, el equipo habrá alcanzado un nivel de madu-
rez y confianza, necesario para desempeñar eficazmente sus funciones. Durante esta etapa, las relaciones del
equipo se caracterizan por altos niveles de confianza, una apreciación mutua del desempeño y contribucio-
nes de los otros y la voluntad de colaborar activamente. La moral ha venido mejorando durante el ciclo de
desarrollo del equipo del proyecto hasta este punto, en el cual todos los miembros del equipo trabajan con
seguridad y eficiencia. Mientras se establezcan, tempranamente en el desarrollo del equipo, fuertes normas
de grupo orientadas a tareas y se resuelva el conflicto, la etapa de desempeño se caracterizará por la moral alta
y el fuerte rendimiento.

Etapa cinco: terminación


La terminación reconoce que los proyectos y sus equipos no duran para siempre. En algún momento, el
proyecto se ha completado y el equipo se disuelve para regresar a sus labores dentro de la organización. En
algunos casos, el grupo puede ir reduciendo su tamaño lenta y deliberadamente. Por ejemplo, en el caso del
desarrollo de un proyecto de ingeniería de sistemas, al entrar en funcionamiento los diversos componentes
200 Capítulo 6  •  Conformación del equipo del proyecto, conflicto y negociación

del sistema, los servicios de ingeniería de diseño del equipo pueden ya no ser necesarios y, por tanto, se
reasignarán. En otras circunstancias, al completar sus tareas el equipo se disuelve. En todo caso, vale la pena
recordar que durante las etapas finales del proceso de implementación, los miembros del grupo suelen mos-
trar cierta preocupación relacionada con sus futuras asignaciones y/o nuevas tareas. Los gerentes de pro-
yectos deben ser sensibles a las preocupaciones reales de los miembros del equipo y, en lo posible, ayudar a
suavizar la transición del antiguo equipo a las nuevas asignaciones.

Equilibrio puntuado o equilibrio interrumpido


A finales de la década de1980, la investigadora Connie Gersick de UCLA impugnó la validez del modelo
estándar de desarrollo del equipo del proyecto.11 En una serie de estudios, ella observó un proceso totalmente
diferente por el cual los equipos de proyectos evolucionan. Ella se refirió a su modelo como equilibrio pun-
tuado o equilibrio interrumpido, basada en un modelo científico similar propuesto por Stephen J. Gould para
explicar el cambio evolutivo en grande del mundo natural. El equilibrio puntuado o equilibrio interrum-
pido propone que más que una evolución que ocurre por un estado constante de cambio gradual, el cambio
real natural se produce mediante largos periodos de estancamiento, interrumpido por algún cataclismo que
impulsa un ajuste evolutivo.
Este fenómeno de equilibrio puntuado se presenta con frecuencia en el campo de la dinámica de grupos.
Ella descubrió que la mayoría de los equipos desarrolla rápidamente una serie de normas de funcionamiento,
durante la primera reunión del equipo y sobre una base limitada de la interacción y el conocimiento del otro o
de la misión del proyecto. Estas normas, a menudo menos que óptimas, tienden a orientar el comportamiento y
el rendimiento del grupo durante un largo periodo de la vida del proyecto. El grupo continuará operando como
consecuencia de estas normas hasta que ocurra algún evento de activación, casi exactamente en el punto medio
entre la primera reunión y el plazo límite de entrega del proyecto (véase la figura 6.5). El evento de activación
puede ser la insatisfacción general con el progreso del proyecto hasta la fecha, un punto de ebullición sobre los
antagonismos interpersonales o alguna otra fuerza externa. Sin embargo, una vez producida esta erupción, sirve
de motivación para revisar las normas del grupo, desarrollar mejores procedimientos intragrupo y promover
un mejor desempeño en la tarea. Por lo general, durante esta segunda fase de la vida del grupo la mayoría del
trabajo se hace efectivo y el grupo comienza a funcionar más como un equipo y no tanto como una colección
de individuos.
El equilibrio puntuado tiene unas implicaciones significativas para los líderes del equipo del proyecto.
Primera, sugiere que las primeras impresiones a menudo son duraderas, pues a medida que los compor-
tamientos y normas iniciales se solidifican se convierten rápidamente en la fuerza dominante detrás de la

Alto

Terminación

Desempeño
del equipo
Erupción
Primera
reunión

Bajo

Inicio Punto medio Fecha límite


Línea de tiempo del proyecto

FIGURA 6.5  Modelo de equilibrio puntuado o interrumpido


6.5  Lograr la cooperación interfuncional 201

conducta del equipo. Por tanto, los líderes del equipo del proyecto deben observar cómo se desenvuelven las
reuniones iníciales y los mensajes que envían (intencionales o no) respecto a las tareas adecuadas y al com-
portamiento interpersonal. Segunda, el modelo sugiere que los grupos experimentan colectivamente un tipo
de “crisis de la mediana edad” en la gerencia de su proyecto, ya que la falta de resultados concretos, junto a la
escalada de las tensiones interpersonales, tiende a acumularse en un estado de insatisfacción que, finalmente,
se desborda en la mitad del proceso de desarrollo. Los líderes tienen que prever estos comportamientos, reco-
nocer las señales de advertencia de su enfoque y, de manera proactiva, trazar e indicar los pasos necesarios
para obtener resultados más positivos de la transición. Finalmente, la investigación de Gersick halló que los
miembros del grupo tendían a sentir mayor frustración porque carecían de un sentido real de cómo iba el
proyecto en un momento dado. Por tanto, los gerentes de proyectos que quieran evitar los efectos más dañi-
nos de las transiciones de mediana edad en los proyectos tienen que reconocer que cuanto más se planea para
los hitos intermedios y otros indicadores de progreso, lograrán mitigar los efectos adversos de las explosiones
del equipo del proyecto.

6.5  LOGRAR LA COOPERACIÓN INTERFUNCIONAL


¿Cuáles son algunas de las tácticas que los gerentes pueden utilizar en el desarrollo efectivo de los equipos?
Un proyecto de investigación sobre los equipos de proyectos descubrió una serie de factores claves que con-
tribuyen a la cooperación interfuncional.12 La figura 6.6 muestra un modelo de dos etapas: la primera ilus-
tra los factores que influyen en la cooperación y la segunda, las influencias que genera. Los factores claves
que influyen en la cooperación y en el comportamiento son las metas de orden superior, normas y procedi-
mientos, proximidad física y accesibilidad. A través de la cooperación interfuncional, estos influyen en los
resultados de las tareas (asegurándose de que el proyecto esté bien hecho) y en los resultados psicosociales
(efectos emocionales y psicológicos que generarán buenos resultados en el equipo del proyecto).

Metas de orden superior


Una meta de orden superior se refiere a una meta general o propósito importante para todos los grupos
funcionales implicados, pero cuya consecución requiere recursos y esfuerzos de más de un grupo.13 Cuando
Apple desarrolló su tableta iPad, ese emprendimiento incluyó una serie de subproyectos: la creación de un
sistema operativo amigable; una interfaz gráfica para el usuario; una serie de aplicaciones y funciones únicas

Metas de
orden superior

Resultados
Normas y de la tarea
procedimientos

Cooperación
interfuncional

Proximidad física
Resultados
psicosociales

Accesibilidad

Retroalimentación

FIGURA 6.6  Cooperación interfuncional del equipo del proyecto


Fuente: M. B. Pinto, J. K. Pinto, and J. E. Prescott. (1993). “Antecedents and consequences
of project team cross-functional cooperation.” Management Science, 39: 1281–97, p. 1283.
Copyright 1993, the Institute for Operations Research and the Management Sciences, 7240
Parkway Drive, Suite 300, Hanover, MD 21076 USA. Reproducido con permiso de Project
Team Cross-Functional Cooperation.
202 Capítulo 6  •  Conformación del equipo del proyecto, conflicto y negociación

para ejecutarlas en múltiples programas; 4G y capacidades inalámbricas, entre otros. Cada uno de estos
subproyectos fue soportado por decenas de ingenieros electrónicos, profesionales de IT, programadores
especialistas en codificación, diseñadores gráficos, personal de investigación de mercados y especialistas en
operaciones, todos trabajando y colaborando juntos. El iPad no habría sido un éxito si alguno de sus proyec-
tos no hubiera tenido éxito: todo lo que necesitaban para tener éxito implicaba mantener fuertes relaciones
colaborativas entre los desarrolladores y los otros miembros del equipo de trabajo.
La meta de orden superior es un complemento y no un sustituto de otras metas que los grupos
funcionales hayan establecido. La premisa es que cuando los miembros del equipo de diferentes áreas fun-
cionales comparten una meta general o propósito común, tienden a cooperar para este fin. Consideremos
un ejemplo de creación de un nuevo proyecto de software para el mercado comercial. Una meta de orden
superior para este equipo de proyecto podría ser “desarrollar un sistema de alta calidad, amigable con el
usuario y de gran utilidad que mejorará el funcionamiento de varios departamentos y funciones.” Esta
meta general pretende mejorar o agrupar algunas de las metas específicas de las diversas funciones, bus-
cando efectividad de costos, adherencia al cronograma, calidad e innovación. Esto proporciona un obje-
tivo central o meta primordial hacia el cual todo el equipo del proyecto puede aspirar.

Normas y procedimientos
Las normas y procedimientos son fundamentales para cualquier análisis de la cooperación intrafuncional,
porque ofrecen un medio para coordinar o integrar actividades que implican varias unidades funciona-
les.14 Las normas y procedimientos se definen como procesos formales establecidos por la organización que
gobiernan o controlan las actividades del equipo de proyecto, en cuanto a miembros del equipo, asignación
de tareas y evaluación del desempeño. Durante años, las organizaciones han dependido de normas y procedi-
mientos para vincular las actividades con los miembros de la organización. Las normas y los procedimientos
se han utilizado para asignar tareas, evaluar el desempeño, resolver conflictos, etcétera.
El valor de las normas y los procedimientos están en que sin ellas y estos, no habrá cooperación entre
los miembros del equipo. En los casos en que los equipos de proyectos no pueden basarse en normas y
procedimientos establecidos en toda la organización, para ayudar a los miembros con sus tareas, con fre-
cuencia estos se ven obligados a establecer sus propias reglas y procedimientos con el fin facilitar el avance
del proyecto. Por ejemplo, una de estas reglas podría ser que todos los miembros del equipo del proyecto
se pusieran a disposición de otros proyectos, una vez finalizadas sus asignaciones.

Proximidad física
La proximidad física se refiere a las percepciones que los miembros del equipo del proyecto tienen de
su ubicación física o espacial apropiada para poder interactuar. Las personas son más propensas a inte-
ractuar y a comunicarse cuando las características físicas de los edificios o lugares son adecuados para
hacerlo.15 Por ejemplo, el tamaño y la distribución espacial de un edificio pueden afectar las relaciones
de trabajo. Cuando un equipo de trabajo se agrupa en una misma planta o en un pequeño edificio, las
relaciones tienden a ser más estrechas, ya que las personas permanecen en proximidad física. Cuando
las personas se distribuyen a lo largo de pasillos o en diferentes edificios, las interacciones son menos
frecuentes y/o espontáneas. En estas situaciones, a los empleados se les dificulta la interacción con los
miembros de su propio o de otro departamento.
Muchas empresas consideran seriamente los posibles efectos que la proximidad física tiene sobre la coope-
ración del equipo del proyecto. De hecho, algunas organizaciones de proyectos reubican al personal que trabaja
junto en un proyecto, en la misma oficina o piso. El término “cuarto de guerra” se utiliza a veces para ilustrar esta
agrupación deliberada de los miembros del equipo del proyecto en una localidad central. Cuando los miembros
del equipo trabajan cerca unos de otros son más propensos a comunicarse y, en última instancia, a cooperar.

Accesibilidad
Si bien la proximidad física es importante para fomentar la cooperación interfuncional, otro factor, la
accesibilidad, parece ser igualmente un indicador importante del fenómeno. La accesibilidad es la percep-
ción que los demás tienen de una persona en torno a su disposición para comunicarse e interactuar con los
problemas o inquietudes relacionados con el éxito de un proyecto. Aparte de la cuestión de la proximidad
física, la accesibilidad se refiere a los factores adicionales que pueden inhibir la cantidad de interacción que
se produce entre miembros de la organización (por ejemplo, el horario de una persona, posición en una
6.6  Equipos de proyectos virtuales 203

organización o compromisos fuera de la oficina). A menudo, estos factores afectan la accesibilidad entre
los miembros de la organización. Por ejemplo, considere una organización del sector público en la que un
miembro del departamento de ingeniería se encuentra físicamente cerca de un miembro del departamento
de censo de la ciudad. Aunque estos individuos estén próximos entre sí, raramente interactúan debido a
sus horarios de trabajo diferentes, variadas funciones y prioridades y compromiso con sus agendas. Estos
factores suelen crear una percepción de falta de acceso entre los individuos involucrados.

Resultados de la cooperación: tarea y resultados psicosociales


Como la figura 6.6 sugiere, la meta de promover la cooperación intrafuncional entre los miembros de
un equipo de trabajo no es un fin en sí mismo, sino que refleja un medio para un mejor rendimiento del
equipo del proyecto y, en última instancia, para mejorar los resultados del proyecto. Hay dos tipos de
resultados del proyecto importantes por considerar: los de las tareas y los psicosociales. Los resultados de
las tareas se refieren a los factores que intervienen en la ejecución real del proyecto (tiempo, cronograma
y funcionalidad del proyecto). Los resultados psicosociales, por otro lado, representan la evaluación de
cada miembro del equipo de si la experiencia del proyecto fue satisfactoria y productiva y valió la pena. Es
posible, por ejemplo, tener un proyecto “exitoso” en términos de la realización de sus tareas, pero todos los
miembros del equipo están tan desalentados debido a los conflictos y malas experiencias que solo tienen
malos recuerdos del proyecto. Los resultados psicosociales son importantes porque representan las actitu-
des que los miembros del equipo llevarán con ellos a proyectos posteriores (como se muestra en el circuito
de retroalimentación en la figura 6.6). ¿La experiencia del proyecto fue satisfactoria y gratificante? Si es
así, probablemente se iniciarán nuevos proyectos con una actitud positiva que en los casos en que hemos
tenido malas experiencias en proyectos anteriores. Sin importar qué tan cuidadosamente planeemos y
efectuemos nuestra selección del equipo de proyecto y el proceso de ejecución, nuestros esfuerzos pueden
tardar en dar sus frutos.
Finalmente, ¿cuáles son algunas conclusiones generales que podemos extraer de los métodos para la
conformación de equipos de alto rendimiento? Basado en la investigación, los gerentes de proyectos deben
tomar tres medidas concretas para sentar las bases en el trabajo en equipo:16
1. Hacer el equipo del proyecto lo más tangible que se pueda.  Los equipos eficaces habitualmente desa-
rrollan su propia y única identidad. A través de la publicidad, promoviendo la interacción, fomentando
una terminología y lenguaje únicos y enfatizando la importancia de los resultados del proyecto, los
gerentes de proyectos pueden crear un sentido tangible de la identidad del equipo.
2. Premiar el buen comportamiento.  Hay muchos métodos no monetarios para recompensar el buen
desempeño. Las claves son: (1) flexibilidad, reconociendo que cada uno vemos las recompensas de
manera diferente; (2) creatividad, proporcionando medios alternativos para hacer llegar el mensaje; y (3)
pragmatismo, reconociendo lo que puede ser recompensado y auténtico con el equipo, en torno a cómo
se reconocerá un rendimiento superior.
3. Dar un toque personal.  Los gerentes de proyectos necesitan establecer relaciones uno a uno con
los miembros del equipo del proyecto. Si lideran con el ejemplo, al dar su opinión positiva de los
miembros del equipo, reconocer públicamente un buen rendimiento, mostrar interés por el trabajo del
equipo, ser accesibles y coherentes en la aplicación de las normas de trabajo, los miembros del equipo
del proyecto llegarán a valorar tanto los esfuerzos como el trabajo del gerente de proyectos.
Estas sugerencias son un buen punto de partida para aplicar el concepto de trabajo en equipo en el
difícil escenario de la gerencia de proyectos. Dada la naturaleza temporal de los proyectos, el movimiento
dinámico de los miembros del equipo, dentro y fuera de este, y el hecho de que en muchas organizaciones los
miembros del equipo trabajan en varios proyectos a la vez, la creación de un equipo de trabajo cohesionado
que pueda trabajar en armonía y eficacia para lograr las metas del proyecto es extremadamente valioso.17 El
uso de estas pautas para el trabajo en equipo les permite a los gerentes de proyectos conformar rápidamente
un equipo de alto rendimiento.

6.6  EQUIPOS DE PROYECTOS VIRTUALES


La globalización de las empresas ha tenido efectos en cómo están ejecutándose los proyectos actualmente.
Imagine un proyecto multimillonario para diseñar, construir e instalar una plataforma de perforación de
petróleo en el Atlántico Norte. El proyecto requiere la experiencia de las organizaciones socias de Rusia,
204 Capítulo 6  •  Conformación del equipo del proyecto, conflicto y negociación

Finlandia, Estados Unidos, Francia, Noruega y Gran Bretaña. Cada uno de los socios tiene que estar plena-
mente representado en el equipo del proyecto, todas las decisiones deben concertarse en un alto porcentaje
y el éxito del proyecto requerirá comunicación permanente entre todos los miembros del equipo del pro-
yecto. ¿Suena difícil? De hecho, estos proyectos se llevan a cabo frecuentemente. Hasta hace poco, el mayor
reto era encontrar una manera para que los gerentes se reunieran y estuvieran en contacto cercano. Los
viajes constantes eran la única opción. Sin embargo, ahora muchas organizaciones conforman equipos de
proyectos virtuales.
Los equipos virtuales implican el uso de medios electrónicos, incluidos correo electrónico, internet
y teleconferencias, para vincular a los miembros de un equipo de proyecto dispersos geográficamente. Los
equipos virtuales comienzan con el supuesto de que las barreras físicas o la distancia hacen poco práctico
reunir los miembros del equipo de una manera regular, cara a cara. Por tanto, el equipo virtual implica el
establecimiento de medios de comunicación alternativos que les permitan a todos sus miembros mante-
nerse en contacto, hacer contribuciones al proyecto en curso y comunicar toda la información necesaria
relacionada con el proyecto, a los demás miembros del equipo.
Los equipos virtuales utilizan la tecnología para resolver el espinoso problema de la vinculación
productiva de socios del proyecto geográficamente dispersos. Los equipos virtuales presentan dos desafíos
principales: generar confianza y establecer las mejores formas de comunicación.18 Como comentamos,
la confianza es un ingrediente necesario para convertir un grupo dispar de individuos en un equipo de
proyecto integrado. La separación física puede hacer más lento el surgimiento de la confianza. Los medios
de comunicación pueden crear contextos formales e impersonales y el nivel de confort que permite hacer
bromas casuales demora en establecerse. Esto puede retrasar el proceso de generación de confianza entre
los miembros del equipo.
A continuación se presentan algunas de las opciones disponibles para los equipos de proyectos que se
disponen a utilizar la tecnología virtual.19
• Cuando sea posible, hallar maneras de complementar la comunicación virtual con encuentros
cara a cara.  Trate de no depender exclusivamente de la tecnología virtual. Aun si solo se pro-
duce al comienzo del proyecto y después de hitos claves, cree oportunidades para que el equipo en
conjunto intercambie información, haga una puesta en común y comience a desarrollar relaciones
personales.
• No permita que miembros del equipo desaparezcan.   Uno de los problemas con los equipos virtua-
les es que fácilmente los miembros del equipo se “desconectan” durante largos periodos, especialmente
si no se han establecido horarios regulares de comunicación. La mejor solución para este problema es
asegurarse de que las comunicaciones incluyen reuniones regulares y encuentros especiales, ya sea a
través de videoconferencia o de conexiones por correo electrónico e internet.
• Establezca un código de conducta entre los miembros del equipo.  Aunque puede ser relativamente
fácil llegar a un acuerdo sobre el tipo de información que necesita compartirse entre los miembros del
equipo, deben establecerse reglas relacionadas con cuándo hacer el contacto y la duración de los retra-
sos aceptables y no aceptables para responder a los mensajes.
• Mantenga todos los miembros del equipo en el circuito de la comunicación.   Los equipos virtuales
requieren una hiperconciencia del gerente de proyectos de la necesidad de mantener los canales de
comunicación abiertos. Cuando los miembros del equipo entienden cómo encajan en el panorama
general están más dispuestos a mantenerse en contacto.
• Cree un proceso claro para hacerles frente a los conflictos, desacuerdos y normas de grupo.  Cuando
los proyectos se ejecutan en un entorno virtual, la capacidad real del gerente de proyectos para
medir las reacciones y sentimientos de los miembros del equipo acerca del proyecto y con los demás
puede ser mínima. Elabore un conjunto de directrices que permitan la libre expresión de dudas o
desacuerdos entre los miembros del equipo. Por ejemplo, un equipo virtual compuesto por miem-
bros de varias organizaciones grandes estableció una sesión de quejas los viernes en la tarde, lo cual
habilitó un bloque de dos horas a la semana para que los miembros del equipo expresaran sus senti-
mientos o desacuerdos. La única regla de la sesión fue: todo lo dicho aquí debía permanecer dentro
del proyecto, y estos mensajes no podían llevarse fuera del equipo del proyecto. Al cabo de dos
meses de haberse instituido las sesiones, los miembros del equipo del proyecto consideraron que las
sesiones eran la parte más productiva de la comunicación del proyecto y las esperaban más que a las
reuniones formales del proyecto.
6.6  Equipos de proyectos virtuales 205

PERFIL DE PROYECTO

La tecnología de teleinmersión facilita la utilización de equipos virtuales


Para muchos usuarios de la tecnología de videoconferencia, las ventajas y los inconvenientes en ocasiones parecen
más o menos iguales. Aunque no hay duda de que las teleconferencias ponen en contacto directo a las personas
entre sí, a grandes distancias geográficas, las limitaciones actuales sobre hasta qué punto se puede aplicar la tecno-
logía conducen a algunas salvedades importantes. Como un escritor observó:
Soy un usuario frecuente, pero renuente de la videoconferencia. La interacción humana tiene tanto
elementos verbales como no verbales, y la videoconferencia parece configurada precisamente para
confundir los no verbales. Por ejemplo, es imposible hacer contacto visual adecuado, en los sistemas de
videoconferencia de hoy día, debido a que la cámara y la pantalla no pueden estar en el mismo lugar.
Esto generalmente tiene un efecto amortiguado y formal en las interacciones, porque el contacto visual
es un método subconsciente casi omnipresente que afirma la confianza. Además, los participantes no
pueden establecer un sentido de la posición relativa entre sí y, por tanto, no cuentan con una forma
clara para llamar la atención, aprobación o desaprobación.20
Al abordar estos problemas de las teleconferencias, se creó la tecnología de teleinmersión, un nuevo medio
para la interacción humana gracias a las tecnologías digitales. Ella crea la ilusión de que un usuario se encuentra
en el mismo espacio físico que los demás, a pesar de que los demás participantes podrían de hecho estar a miles
de kilómetros de distancia. Además, combina las técnicas de visualización y la interacción de la realidad virtual
con nuevas tecnologías de visión que trascienden las limitaciones tradicionales de una cámara. El resultado es
que todos los participantes, no obstante distantes, pueden compartir y explorar un espacio de tamaño real.
Esta fascinante nueva tecnología, que ha surgido muy recientemente, ofrece la posibilidad de cambiar por completo
la naturaleza de cómo los equipos de proyectos virtuales se comunican entre sí. Instaurado por Advanced Network &
Services como parte de la Iniciativa Nacional de Teleinmersión (National Tele-Immersion Initiative: NTII), la teleinmersión
les permite a usuarios, distribuidos geográficamente en lugares distintos, colaborar en tiempo real en un entorno compar-
tido, simulado como si estuvieran en el mismo lugar físico. La teleinmersión es una transmisión a larga distancia de escenas
tridimensionales de tamaño natural, sintetizadas, elaboradas con precisión en tiempo real a través de gráficas por com-
putador y técnicas avanzadas de visión. El uso de esta sofisticada representación de modelado tridimensional le permite a
la teleconferencia adoptar un aspecto totalmente nuevo: todos los miembros del proyecto, literalmente aparecen en un
entorno natural en tiempo real, casi como si estuvieran sentados uno frente al otro, en una mesa de reuniones.
Con mayor ancho de banda y la tecnología adecuada, la videoconferencia con teleinmersión ofrece un
enorme salto hacia adelante en comparación con los estándares actuales de la industria bidimensional. En su estado
actual, la tecnología de teleinmersión requiere que el miembro de videoconferencia utilice gafas polarizadas y un
dispositivo de seguimiento para la cabeza, lo cual le permite ver una imagen estereoscópica de 3D generada por
computador de los demás teleconferencistas. Esto da como resultado una representación plenamente dimensional
y comprensible de tales entornos del mundo real, lo cual es posible con la tecnología de video existente. Qué tan
lejos puede llegar esta tecnología en los próximos años es imposible de predecir, pero nadie está apostando en
contra de que sea la base para una nueva forma de llevar a cabo reuniones de equipos virtuales.21
Como se muestra en la figura 6.7, los recientes avances tecnológicos han permitido las conferencias con
teleinmersión que a veces requieren utilizar equipos de enlace adicionales como gafas o dispositivos de rastreo. La
HO Marketwire Photos/Newscom

FIGURA 6.7  Tecnología de teleimmersión (continúa)


206 Capítulo 6  •  Conformación del equipo del proyecto, conflicto y negociación

capacidad de traducir y comunicar imágenes sofisticadas de personas, planos o modelos totalmente representados
en tres dimensiones hace que esta tecnología sea única y de gran atractivo, además de una alternativa para la con-
ferencia telefónica estándar.
Los equipos virtuales, con sus limitaciones y retos, pueden contar con una efectiva alternativa para la solu-
ción de algunos de los problemas que se generan en equipos de proyectos globales y dispersos, al emplear avances
tecnológicos de las telecomunicaciones. La clave para el uso de estas tecnologías virtuales reside efectivamente en
un claro conocimiento de estas y de qué pueden y no pueden hacer. Por ejemplo, mientras internet vincula a los
miembros del equipo, no puede transmitir mensajes no verbales o sentimientos que los miembros del equipo ten-
gan sobre el proyecto o sobre otros miembros del proyecto. Del mismo modo, aunque la videoconferencia actual
permite interacciones cara a cara en tiempo real, no sustituye perfectamente una verdadera comunicación “cara
a cara” entre los miembros del equipo del proyecto. No obstante, el desarrollo de tecnologías virtuales ha sido de
gran beneficio para las organizaciones de proyectos, pues los equipos se han vuelto más globales en su composi-
ción y cada vez más se presentan asociaciones de empresas para ejecutar proyectos.

6.7  GERENCIA DEL CONFLICTO


Un estudio afirma que el gerente promedio gasta más de 20% de su tiempo tratando con los conflictos. 22
Debido a que gran parte del tiempo de un gerente de proyectos lo absorben el conflicto activo y sus secuelas
residuales, tenemos que entender que este es proceso natural en el contexto de la gerencia de proyectos. Esta
sección del capítulo explora formalmente el proceso del conflicto, examina la naturaleza de los conflictos en
los equipos de proyectos, desarrolla un modelo de comportamiento de conflicto y fomenta la comprensión
de algunos de los métodos más comunes para el escalamiento del conflicto.

¿Qué es conflicto?
El conflicto es un proceso que comienza cuando usted percibe que alguien ha frustrado o va a frustrar uno
de sus principales asuntos de interés.23 Hay dos elementos importantes en esta definición. El primero sugiere
que el conflicto no es un estado, sino un proceso. Como tal, contiene un aspecto dinámico muy importante.
Los conflictos evolucionan.24 Además, las causas iniciales de un conflicto pueden cambiar con el tiempo, es
decir, las razones por las que dos individuos o grupos desarrollaron inicialmente un conflicto ya no tienen
validez. Sin embargo, debido a que el proceso de conflicto es dinámico y en evolución, una vez se produce un
conflicto, las razones detrás de este pueden seguir importando. El proceso de conflicto tiene ramificaciones
que vamos a explorar en detalle.
El segundo elemento de la definición: el conflicto es una percepción natural. En otras palabras, no
importa, en última instancia, si una de las partes realmente ha ofendido a la otra parte. Lo importante es que
una de las partes percibe que ese estado o evento se ha producido. Esa percepción es suficiente porque, para
esa parte, su percepción de frustración define la realidad.
En general, la mayoría de los tipos de conflicto encajan dentro de una de las tres categorías,25 aunque
también es común que algunos conflictos que involucran aspectos de más de una categoría.
El conflicto orientado a las metas se asocia con desacuerdos sobre los resultados, producto del alcance
del proyecto, especificaciones y criterios de desempeño y las prioridades y objetivos del proyecto. Los conflictos
orientados a las metas a menudo resultan de múltiples percepciones del proyecto y se alimentan con metas
vagas o incompletas que les permiten a los miembros del equipo del proyecto hacer sus propias interpretaciones.
El conflicto administrativo surge de la jerarquía gerencial, estructura organizacional o de la filosofía
de la empresa. Estos conflictos se centran en desacuerdos en las relaciones, en quien tiene la autoridad,
control administrativo y decisión sobre las funciones, tareas e informes. Un buen ejemplo de conflicto
administrativo se presenta en las estructuras organizacionales matriciales, en las que cada miembro del
equipo del proyecto responde a dos jefes, el gerente de proyectos y el supervisor funcional. En efecto, esta
estructura promueve la continuidad del conflicto administrativo.
El conflicto interpersonal se presenta por las diferencias de personalidad entre los miembros del
equipo del proyecto y los interesados del proyecto. Las fuentes de conflicto interpersonal incluyen diferencias
en la ética de trabajo, estilos de comportamiento y los egos y personalidades de los miembros del equipo del
proyecto.
Existen al menos tres escuelas de pensamiento acerca de cómo deben percibirse y tratarse los conflic-
tos. Estas varían según la opinión predominante de la persona o la organización que la sostiene.26
6.7  Gerencia del conflicto 207

La primera visión del conflicto es la tradicional, que percibe el conflicto como generador de efectos
negativos en las organizaciones. Los tradicionalistas, debido a que suponen que el conflicto es malo, creen
que se debe evitar y cuando se produce, afirman que hay que resolverlo tan rápido y sin dolor como sea posi-
ble. El énfasis de los tradicionalistas está en la supresión y eliminación de los conflictos.
La segunda visión de los conflictos está en la escuela de conducta o de pensamiento contemporáneo.
Los teóricos del comportamiento ven el conflicto como una parte natural e inevitable de la vida organiza-
cional. La diferenciación entre los departamentos funcionales, metas, actitudes y creencias diferentes son
estados naturales y permanentes entre los miembros de una empresa, por lo que es natural que se presenten
conflictos. Según los teóricos de comportamiento, la solución al conflicto es gerenciar efectivamente los con-
flictos en lugar de intentar eliminarlos o suprimirlos.
La tercera visión de los conflictos, la interactiva, toma actitudes de comportamiento hacia el con-
flicto un paso más allá. Con esta visión, los interactivistas aceptan que cuando ocurren comportamientos
de conflicto, ellos animan a que se desarrollen. Según un interactivista, el conflicto impide que las orga-
nizaciones lleguen a ser apáticas o a estancarse. El conflicto en realidad introduce un elemento de tensión
que produce innovación, creatividad y una mayor productividad. Los interactivistas no pretenden que
el conflicto continúe sin control, sin embargo, argumentan que existe un nivel óptimo de conflicto que
mejora la organización. Más allá de ese punto, el conflicto se torna demasiado grave e intenso que llega
a perjudicar a la empresa. La clave, para un interactivista, está en encontrar el nivel óptimo de conflicto:
muy poco conduce a la inercia y demasiado, al caos.

Fuentes de conflicto
Las fuentes potenciales de conflicto en los proyectos son numerosas. Algunas de las más comunes incluyen la
competencia por los recursos escasos, violaciones de las normas del grupo o de la organización, desacuerdos
sobre las metas o los medios para alcanzarlas, desaires personales y amenazas a la seguridad en el empleo,
rencillas de vieja data, prejuicios, etc. Muchas de las causas de los conflictos surgen de la situación de la
gerencia del proyecto en sí. Es decir, las mismas características de los proyectos que los hacen únicos se con-
vierten en factores desencadenantes de conflicto entre los interesados del proyecto.

CAUSAS ORGANIZACIONALES DE CONFLICTOS  Algunas de las causas más comunes de conflicto orga-
nizacional son los sistemas de recompensa, la escasez de recursos, la incertidumbre y la diferenciación. Los
sistemas de recompensa son procesos competitivos que algunas organizaciones han establecido como una
rivalidad entre grupo o departamento funcional contra otro. Por ejemplo, cuando evalúan los gerentes fun-
cionales según el desempeño de sus subordinados dentro del departamento, se resisten a permitir que sus
mejores trabajadores participen en el trabajo de un proyecto durante mucho tiempo. Involuntariamente, la
organización crea un estado en el cual los gerentes perciben que los equipos de proyectos o los departamen-
tos serán premiados por su rendimiento superior. En tales casos, es natural que conserven a su mejor gente
para las tareas funcionales y ofrezcan sus subordinados menos aptos para conformar el equipo de trabajo del
proyecto. Por otro lado, los gerentes de proyectos también perciben una competencia entre sus proyectos y
los departamentos funcionales y desarrollan un fuerte sentido de animosidad hacia los gerentes funcionales
a quienes perciben, con cierta justificación, como opositores de sus propios intereses, por encima de los de
la organización.
Los recursos escasos son causa natural de conflictos; individuos y departamentos compiten por los
recursos que ellos creen necesarios para hacer bien su trabajo. Dado que las organizaciones se caracterizan
por la escasez de los recursos solicitados por grupos diferentes, la lucha por obtenerlos es una fuente princi-
pal de conflicto organizacional. En tanto que los recursos escasos sean el estado natural de las organizaciones,
los grupos entrarán en conflicto en su intento de negociar y obtener una ventaja en su distribución.
La incertidumbre sobre las líneas de autoridad, esencialmente genera esta pregunta: “¿Quién manda
aquí?” En el entorno de proyectos, es fácil ver cómo este problema se agrava debido a la ambigüedad que con
frecuencia existe en lo que respecta a los canales formales de autoridad. En muchas organizaciones, los geren-
tes de proyectos y sus equipos perciben la jerarquía organizacional formal como “externa”, particularmente
en las estructuras funcionales. Como resultado de esto, se encuentran en una posición frágil de autonomía y
de responsabilidad frente a los jefes de los departamentos funcionales que proporcionan el personal para el
equipo. Por ejemplo, cuando un miembro del equipo de un proyecto de (I+D) recibe órdenes de su gerente
funcional que se oponen directamente a las directivas del gerente de proyectos, se ve en la disyuntiva de tener
que encontrar (si es posible) un término medio entre las dos figuras de autoridad nominales. En muchos
208 Capítulo 6  •  Conformación del equipo del proyecto, conflicto y negociación

casos, los gerentes de proyectos no tienen la autoridad para evaluar el desempeño de los miembros de su
equipo, y ese control sigue manteniéndose en el departamento funcional. En tales situaciones, el miembro
del equipo de (I+D), frente al conflicto provocado por la incertidumbre de las líneas de autoridad, proba-
blemente haga lo conveniente y obedezca a su gerente funcional en razón de su “poder de la evaluación del
desempeño.”
La diferenciación refleja el hecho de que los diversos departamentos funcionales desarrollan sus pro-
pios modos de pensar, actitudes, marcos temporales y sistemas de valores, que pueden entrar en conflicto
con los de otros departamentos. En pocas palabras, la diferenciación significa que a medida que las personas
se unen a una organización dentro de alguna especialidad funcional, empiezan a adoptar las actitudes y
perspectivas de ese grupo funcional. Por ejemplo, cuando se le pregunte a un miembro del departamento de
finanzas su opinión acerca marketing, podría responder: “Todo lo que ellos hacen es viajar y gastar dinero.
Son un grupo de vaqueros que regalarían la tienda si tuvieran que hacerlo.” La opinión de un miembro del
departamento de marketing sobre el personal de finanzas podría ser igualmente desfavorable: “La gente de
finanzas son solo un grupo de contadores que no entienden que la empresa será exitosa solamente si vende
sus productos. Están tan pegados a sus márgenes que no saben lo que pasa en el mundo real.” Lo interesante
de estos puntos de vista es que, dentro de sus estrechos marcos de referencia, los dos son correctos: marke-
ting está interesado principalmente en la realización de ventas y finanzas se dedica al mantenimiento de altos
márgenes. Sin embargo, estas opiniones de ninguna manera son del todo ciertas, sino que simplemente refle-
jan las actitudes subyacentes y los prejuicios de los miembros de los respectivos departamentos funcionales.
Cuanto más profunda sea la diferenciación dentro de una organización, mayor será la probabilidad de que
los individuos y los grupos se dividan en campamentos “nosotros” contra “ellos,” que seguirán provocando
y promoviendo conflictos.

CAUSAS INTERPERSONALES DE CONFLICTOS  Atribuciones erróneas se les endilgan a nuestros conceptos


preconcebidos respecto a las razones que implican la conducta de los demás. Cuando la gente percibe que
sus intereses se han afectado por otro individuo o grupo, por lo general trata de determinar por qué la otra
parte actuó como lo hizo. Al hacer suposiciones sobre las acciones de los demás, queremos determinar si sus
motivos se basan en la malevolencia personal, agendas ocultas, etc. A menudo, los grupos y los individuos
atribuyen motivos a las acciones de los demás, personalmente, más convenientes. Por ejemplo, cuando un
miembro de un equipo de proyecto tiene sus deseos frustrados, es normal que perciba como motivos de estos
las acciones de la otra parte, acomodándolas a las causas más convenientes para él. En lugar de reconocer
el hecho de que las personas razonables pueden diferir en sus opiniones, para la persona frustrada es más
conveniente asumir que el otro está provocando un conflicto por motivos personales: “Simplemente no me
gusta.” Esta atribución conviene por una razón obvia y psicológicamente “segura”; si suponemos que la otra
persona no está de acuerdo con nosotros por razones válidas, esto implica que nuestra posición estaba equi-
vocada. Muchas personas no tienen la fortaleza del ego para reconocer y aceptar un desacuerdo objetivo, y
prefieren enfocar su frustración en términos personales.
Fallas en la comunicación son la segunda y común causa de un conflicto interpersonal. Una falla en la
comunicación implica la posibilidad de que dos errores ocurran: comunicarse en formas ambiguas dan lugar
a diferentes interpretaciones, lo que provoca un conflicto, y, sin querer, comunicarse en formas que molestan
o hacen enfadar a las otras partes. La falta de claridad puede enviar señales contradictorias: entre el mensaje
que el emisor pretende comunicar y el que fue recibido e interpretado por el receptor. En consecuencia, el
gerente de proyectos puede sorprenderse y molestarse por el trabajo realizado por un subordinado que real-
mente pensaba que adhería a los deseos de su jefe. Del mismo modo, los gerentes de proyectos suelen partici-
par en la crítica con la esperanza de corregir y mejorar el rendimiento del miembro del equipo del proyecto.
Lamentablemente, lo que el gerente de proyectos considera una crítica inofensiva puede percibirse como una
crítica injusta, si la información no se comunica con precisión y efectividad.
Los rencores y prejuicios personales son otra causa de conflictos interpersonales. Cada uno de nosotros
adopta actitudes en cualquier situación de trabajo. Estas actitudes surgen como resultado de las experiencias
a largo plazo o lecciones recibidas en algún momento del pasado. A menudo, estas actitudes se mantienen
inconscientemente, es decir, podemos no estar conscientes de que nos nutrimos de ellas y podemos sentir un
genuino sentido de afrenta cuando se nos desafía o acusa de mantener prejuicios. No obstante, estos rencores
y prejuicios, ya sea que se materialicen en contra de otra raza, género o departamento funcional, tienen un
efecto debilitante en nuestra capacidad para trabajar con otros en un equipo determinado y pueden arruinar
cualquier posibilidad de cohesión en el equipo y subsecuentemente en el rendimiento posterior del proyecto.
6.7  Gerencia del conflicto 209

CUADRO 6.2  Fuentes de conflicto en proyectos y su clasificación según el grado de intensidad

Clasificación de la intensidad del conflicto

Fuentes de conflicto Thamhain & Wilemon Posner


Prioridades del proyecto 2 3
Procedimientos administrativos 5 7
Opiniones técnicas y trade-offs de 4 5
desempeño
Recursos humanos 3 4
Costo y presupuesto 7 2
Cronogramas 1 1
Personalidad 6 6

El cuadro 6.2 muestra algunas de las conclusiones de dos estudios que investigaron las principales
fuentes de conflicto en los equipos de proyecto.27 Aunque los estudios se llevaron a cabo con más de una
década de intervalo, los resultados son muy consistentes en varias dimensiones. Los conflictos sobre cro-
nogramas y prioridades de los proyectos tienden a ser las fuentes más comunes e intensas de desacuerdo.
La investigación de Posner encontró que los problemas de costos y presupuestos desempeñan un papel más
importante en el desencadenamiento de los conflictos respecto al trabajo anterior de Thamhain y Wilemon.
Los cambios significativos en el orden de clasificación de las fuentes de conflicto y su intensidad se producen
por los cambios en las prioridades y en las prácticas de gerencia de proyectos a través del tiempo, lo cual
convierte a los temas de costos en la mayor preocupación y conflicto.28 No obstante, el cuadro 6.2 da algunas
indicaciones claras sobre las principales causas de los conflictos dentro de los equipos de proyectos y el nivel
de intensidad de aquellos.

Métodos para resolver conflictos


Existe una serie de métodos para resolver los conflictos de grupo disponibles para el gerente del proyectos.
Antes de tomar una decisión sobre el método por seguir, el gerente de proyectos debe tener en cuenta varias
cuestiones.29 Por ejemplo, ¿el gerente de proyectos tomará partido en la disputa por una de las partes para
alinear a la otra? ¿El conflicto es de naturaleza profesional o personal? ¿Tiene que existir una intervención o
los miembros del equipo pueden resolver el problema ellos mismos? ¿El gerente de proyectos tiene tiempo
y disposición para mediar en el conflicto? Todas estas preguntas desempeñan un papel importante en la
determinación de la forma de abordar una situación de conflicto. Los gerentes de proyectos deben aprender
a desarrollar flexibilidad al enfrentar los conflictos, saber cuándo intervenir y cuándo permanecer neutral.
Podemos manejar el conflicto mediante cinco opciones.30

MEDIAR EN EL CONFLICTO  En este enfoque, el gerente de proyectos tiene un interés directo en el conflicto
entre las partes, y trata de hallar una solución. El gerente de proyectos podrá emplear tácticas de apacigua-
miento o confrontación en la negociación de una solución. Apaciguar implica que el gerente de proyectos
está menos preocupado por la fuente del conflicto que por encontrar una solución mutuamente aceptable.
En esta táctica se pueden usar frases como “Todos estamos en el mismo equipo”, para demostrar el deseo
por desactivar el conflicto sin importar la fuente. Confrontar, por lo general, consiste en trabajar con ambas
partes para llegar a determinar las causas más profundas del conflicto; es más emocional, requiere mucho
tiempo y en realidad, a corto plazo, puede agravar el conflicto debido a que ambas partes ventilan sus dife-
rencias. Sin embargo, a la larga, la confrontación como mecanismo mediador puede ser más eficaz por-
que busca determinar las causas del conflicto para corregirlas. Los gerentes de proyectos median soluciones
cuando no se sienten cómodos al imponer una sentencia; por tanto, prefieren trabajar con ambas partes para
llegar a un acuerdo común.

ARBITRAR EL CONFLICTO  En la elección de arbitrar un conflicto, el gerente de proyectos debe estar


dispuesto a imponer una sentencia a las partes en conflicto. Después de escuchar a ambas posiciones,
el gerente de proyectos toma su decisión. Como si fuera un juez, lo mejor que puede hacer es reducir
al mínimo las personalidades en la decisión y centrarse en la propia sentencia. Por ejemplo, decir “Se
210 Capítulo 6  •  Conformación del equipo del proyecto, conflicto y negociación

equivocó aquí, Phil, y Susan tenía razón” conducirá sin duda a una respuesta emocional negativa de Phil.
Sin embargo, al emitir un juicio impersonal, el gerente de proyectos puede quedarse con los detalles del
caso, a la mano, sin meterse con las personas. “La política de la compañía establece que todos los clientes
deben recibir copias de las órdenes de revisión de los proyectos dentro de tres días hábiles” es un ejemplo
de un juicio impersonal que no señala con el dedo a cualquiera de las partes como culpable.

CONTROLAR EL CONFLICTO   No todos los conflictos pueden (ni deben) resolverse rápidamente. En algu-
nos casos, una respuesta pragmática a un conflicto podría ser esperar un par de días para que las dos partes
se enfríen. Esta no es una respuesta cobarde; en cambio, eso reconoce que los gerentes de proyectos deben
ser selectivos en cómo intervenir y la manera óptima de intervenir. Otra manera de controlar los conflictos es
limitando la interacción entre las dos partes. Por ejemplo, si se sabe que uno de los miembros del equipo del
proyecto y el cliente tienen una larga historia de animosidad, el sentido común dicta que no se debe permitir
la comunicación directamente, salvo en circunstancias muy controladas.

ACEPTAR EL CONFLICTO  No todos los conflictos son manejables. A veces, las personalidades de los dos
miembros del equipo simplemente no son compatibles. No se agradaban antes de que el proyecto y seguirán
desagradándose después de que el proyecto se complete.

ELIMINAR EL CONFLICTO  Tenemos que evaluar críticamente la naturaleza y severidad de los conflictos
que ocurren continuamente en un proyecto. En algunas situaciones, se requiere, por el bien del proyecto,
transferir a un miembro del equipo o efectuar otros cambios. Si hay una parte claramente culpable, una
respuesta común es sancionar a esa persona, retirarla del proyecto o castigarla de otra manera. Si dos o más
personas son parte del conflicto, es conveniente transferirlas; así se envía una señal de que se tiene la inten-
ción de ejecutar el proyecto tan imparcialmente como sea posible.
El punto importante para tener en cuenta es que los distintos enfoques pueden ser adecuados en dife-
rentes situaciones. No asuma que una sesión de resolución de problemas es siempre beneficiosa o una garan-
tía, ni que ignorar la gerencia de conflictos siempre lo convierte en “perezoso.” Los gerentes de proyectos
tienen que aprender a entender sus propias preferencias a la hora de gerenciar el conflicto. Una vez logrado
un mayor sentido de autoconciencia, estaremos en una mejor posición para resolver de manera constructiva
nuestros propios conflictos y de responder mejor a los conflictos de los subordinados. La clave es la flexibili-
dad. Es importante no bloquear ningún estilo de conflicto en particular, ni favorecer a una resolución táctica
que excluya a todos los demás. Cada uno tiene sus ventajas y desventajas y puede ser un elemento importante
de la caja de herramientas del gerente de proyectos.
Con frecuencia, el conflicto es una evidencia del progreso del equipo del proyecto. Al comenzar a reu-
nir un grupo de individuos dispares con diversos orígenes funcionales en un equipo de proyecto, se obliga a
que despierten una variedad de conflictos. El conflicto es natural dentro de un equipo. Sin embargo, recuerde
que los enfoques que decidimos emplear para lidiar con el conflicto dicen mucho de nosotros: ¿somos tole-
rantes, autoritarios, intransigentes, o realmente queremos encontrar soluciones mutuamente beneficiosas?
Podemos enviar muchos mensajes —intencionales o no intencionales, claras o confusos— para el resto del
equipo del proyecto mediante la forma en que construimos los equipos y gestionamos los conflictos.

6.8 NEGOCIACIÓN
Uno de los puntos centrales de este capítulo es el hecho de que gran parte de nuestro éxito futuro recae sobre
nuestra capacidad de apreciar y manejar la diversidad de comportamientos de las “personas” fundamentales
para la vida de los proyectos. La negociación se basa en la capacidad de un gerente para usar su influencia de
manera productiva.
Las habilidades de negociación son muy importantes porque gran parte de la vida de un gerente de pro-
yectos transcurre en sesiones de negociación de un tipo u otro. De hecho, la gerencia de los interesados puede
verse como una negociación mutua efectiva y constante, entre múltiples partes. Los gerentes de proyectos nego-
cian para obtener tiempo y dinero adicionales. Para evitar interferencia y cambios excesivos en las especifica-
ciones de los clientes, el préstamo o cesión de personal importante para el equipo del proyecto con los gerentes
funcionales, etc. La negociación representa el arte de la influencia llevada a su nivel más alto. Debido a que la
negociación efectiva es un imperativo para la gerencia exitosa del proyecto, es vital que los gerentes de proyectos
6.8 Negociación 211

entiendan el papel que desempeña la negociación en sus proyectos, cómo ser mejores negociadores y algunos de
los elementos importantes en la negociación.

Preguntas que se deben formular antes de negociar


Todo quien entre en una negociación debe tener en cuenta tres cuestiones: ¿cuánto poder tengo? ¿Qué tipo
de presiones de tiempo hay? ¿Confío en mi oponente?31
Una autoevaluación realista sobre el poder y las restricciones es vital antes de sentarse a negociar,
porque puede demostrar dónde son fuertes los negociadores y, sobre todo, cuáles son sus debilidades. Un
gerente de proyectos, una vez relató esta historia:

Fue a principios de junio cuando participamos en la segunda semana de negociaciones muy inten-
sas con los proveedores para establecer las consideraciones antes de arrancar un proyecto de cons-
trucción. Infortunadamente, el proveedor descubrió que llevamos nuestros libros de contabilidad
sobre una base fiscal, con fecha de corte a 30 de junio y se imaginó, correctamente, que estábamos
desesperados para llegar a un acuerdo antes de final de mes. Él se cruzó de brazos durante los
siguientes diez días. Ahora es 21 de junio y mi jefe está sufriendo un ataque al corazón debido a
la dependencia del proveedor. Por último, regresamos a la mesa prácticamente arrastrándonos a
finales de junio y le dimos todo lo que estaba pidiendo con el fin de registrar el contrato.

¡El gerente de proyectos perdió energía y tiempo!


¿Cuánto poder se debe tener para entrar a negociar? Usted no está necesariamente buscando una posi-
ción dominante sino una defensiva, es decir, una en la que la otra parte no pueda dominarlo. ¿Cuánto tiempo
tengo? El cronograma puede ser difícil de superar. Así, por ejemplo, un jefe dominante puede estar constan-
temente diciendo “resuelva el problema con (I+D), marketing, o con quien sea.” Una vez que se corre la voz
de que usted tiene una restricción de tiempo, simplemente va a ver como su oponente desacelera el ritmo,
razonando correctamente que usted tiene que llegar a un acuerdo más temprano que tarde y que este va a ser
en sus términos y no en los suyos.
¿Es posible confiar en la otra parte? ¿La empresa cumplirá su palabra, o tiene fama de cambiar los
acuerdos después de haberlos hecho? ¿Están dispuestos a dar información precisa? ¿Juega rudo en nego-
ciación? Tenga en cuenta que no todas estas preguntas le indican a alguien quién no es de fiar. En efecto,
conviene, en algunas ocasiones, jugar duro. Por otro lado, la pregunta esencial es si usted puede sentarse a la
mesa con su oponente y creer que los dos tienen intereses profesionales creados para solucionar un problema
mutuo. Si la respuesta es no, es poco probable que usted negocie con el mismo grado de entusiasmo o de
apertura que la otra parte.

Negociación basada en principios


Uno de los libros más influyentes sobre negociación, de los últimos años, es Getting to Yes, de Roger Fisher y
William Ury.32 Ellos ofrecen consejos útiles sobre “principios” de negociación, el arte de llegar a un acuerdo
con la otra parte, manteniendo un principio: la actitud gana-gana. Entre las sugerencias que ellos ofrecen
para desarrollar una estrategia de negociación eficaz están las siguientes.

SEPARAR LAS PERSONAS DEL PROBLEMA  Una de las ideas más importantes de la negociación es recor-
dar que los negociadores son, primero, personas. Esta afirmación significa que los negociadores no son
diferentes de cualquier otra persona en términos de ego, actitudes, prejuicios, educación, experiencias, etc.
Todos reaccionamos negativamente a los ataques directos, todos nos ponemos a la defensiva por cargos y
acusaciones injustificadas, y tendemos a personalizar puntos de vista opuestos, suponiendo que sus obje-
ciones están dirigidas a nosotros, y no hacia la posición que representamos. En consecuencia, si los nego-
ciadores son primero personas, debemos buscar formas en las que podamos mantener a la gente (junto a su
personalidad, actitud defensiva, ego, etc.) fuera del problema en sí. Cuanto más nos centremos en los asuntos
que nos separan y prestemos menos atención a la gente detrás de los problemas, mayor será la probabilidad
de lograr un resultado negociado positivo.
Póngase en los zapatos de la otra parte. Un punto de partida vital en las negociaciones es discutir al
inicio del proceso de negociación no solo nuestra propia posición, sino entender la posición de la otra parte.
212 Capítulo 6  •  Conformación del equipo del proyecto, conflicto y negociación

Cuando la otra parte escucha una discusión razonada de las dos posiciones, se producen dos hechos impor-
tantes: (1) se establece una base de confianza porque nuestro oponente descubre que estamos dispuestos a
discutir abiertamente las percepciones desde el principio, y (2) esto reconstruye la negociación como un
ejercicio de gana-gana, en lugar del ganador se lo lleva todo.
No deduzca las intenciones de la otra parte a partir de sus miedos. Un efecto secundario común de casi
todas las negociaciones, sobre todo al principio del proceso, es la construcción de estereotipos del otro lado.
Por ejemplo, en una reunión con el contador para negociar una financiación adicional para el proyecto, es
posible adoptar una mentalidad en la que todos los contadores son avaros, que solo están esperando la opor-
tunidad para cancelar el proyecto. Nótese que incluso antes de que la negociación se haya llevado a cabo, nos
hemos creado una imagen de los miembros del departamento de contabilidad y de su forma de pensar, basa-
dos en nuestra propia percepción errónea y en nuestros temores, más que en una realidad objetiva. Cuando
se supone que ellos van a actuar de una manera, nosotros inconscientemente empezamos a negociar con
ellos, como si el dinero fuera su única preocupación, y, antes de darnos cuenta, hemos creado un oponente
basados en nuestros peores temores.
No culpe a la otra parte de sus problemas. En las negociaciones, es casi siempre contraproducente ini-
ciar un episodio de señalamientos de culpa sobre las dificultades que nuestro proyecto ha tenido. Es más
efectivo avanzar más allá del deseo de señalar culpables y buscar soluciones beneficiosas para todos. Por
ejemplo, supongamos que una empresa acaba de desarrollar un programa de software para el registro y
control interno que se interrumpe siempre en mitad de la operación. Un enfoque sería que el gerente de
contabilidad exasperado llamara al gerente de proyectos de desarrollo de software y lo insultara verbalmente:
“Su programa es realmente deficiente. Cada vez que usted afirma haberlo arreglado, nuevamente se daña. Si
usted no consigue arreglar los errores dentro de dos semanas vamos a volver al viejo sistema y asegurándo-
nos de que todo el mundo conozca cuál fue la razón.”
Aunque puede ser satisfactorio para el gerente de contabilidad reaccionar de esta manera, es poco pro-
bable que resuelva el problema, sobre todo en cuanto a las relaciones con el equipo del proyecto de desarrollo
de software. Un enfoque mejor debería tener menos confrontación, tratando de enmarcar el problema como
uno mutuo que necesita solución. Por ejemplo: “El programa de registro se cayó nuevamente a mitad de
camino. Cada vez que pasa, mi gente tiene que volver a introducir los datos y utilizando tiempo que podría
emplearse en otras labores. Necesito su asesoría sobre la manera de solucionar este problema con el software.
¿Es solo que no está listo para una prueba beta, o estamos usándolo de manera incorrecta, o qué?” Observe
que, en este caso, el gerente de contabilidad evita señalar con el dedo un culpable. Se abstiene de tomar el
camino más fácil a través de simplemente establecer la culpa y exigir la corrección, y en su lugar trata la situa-
ción como un problema que requiere cooperación para resolverlo.
Reconozca y comprenda las emociones: las de ellos y las suyas. Aunque a menudo es fácil llegar a ser emo-
cional durante el curso de una negociación, el impulso debe resistirse tanto como sea posible.33 Comúnmente,
las emociones comienzan a salir a flote en negociaciones difíciles y prolongadas: normalmente ira o frustra-
ción con las tácticas y actitudes de la otra parte. No obstante, no suele ser una buena idea responder de una
manera emocional, incluso cuando la otra parte llega a tornarse emocional. Ellos pueden utilizar la emoción
como una táctica para conseguir que su equipo responda de una manera igualmente emocional y permitir
así que su corazón comience a guiar la cabeza; esto siempre será un camino peligroso. Aunque las emociones
son un efecto secundario natural en negociaciones prolongadas, tenemos que entender precisamente lo que
nos hace sentir infelices, estresados, tensos o enojados. Además, ¿somos suficientemente astutos como para
tomar nota de las emociones que emanan de nuestro oponente? Tenemos que ser conscientes de si lo que
estamos haciendo molesta o irrita a la otra persona.
Escuche activamente. La escucha activa significa nuestra intervención directa en la conversación con
nuestro oponente, incluso cuando la otra persona está hablando realmente. La mayoría de nosotros sabe por
experiencia cuándo la gente está escuchándonos realmente y cuándo están siendo simplemente formales. En
este último caso, nuestra frustración por su aparente indiferencia a nuestra posición puede ser una fuente
grande de emoción negativa. Por ejemplo, supongamos que un cliente está negociando con el gerente de pro-
yectos para una mejora de rendimiento de una pieza a punto de lanzarse al equipo de fabricación. El gerente
de proyectos está igualmente deseoso de mantener el proyecto tal como está, pues cualquier reconfiguración
en este momento simplemente retrasará la liberación del producto final y costará mucho dinero extra. Cada
vez que el cliente expresa sus problemas, el gerente de proyectos dice: “Escucho lo que dices, pero...” En este
6.8 Negociación 213

caso, el gerente de proyectos no está escuchando una palabra de lo que el cliente está diciendo, sino que sim-
plemente guarda las apariencias frente a las preocupaciones del cliente.
La escucha activa significa trabajar duro para entender no simplemente las palabras, sino las motiva-
ciones subyacentes de la otra parte. Una técnica eficaz implica interrumpir de vez en cuando para hacer una
pregunta directa: “Como yo lo entiendo, ¿entonces, usted está diciendo...?” Tácticas como estas convencen
a su oponente de que usted está tratando de escuchar lo que él está diciendo en lugar de, simplemente, adhi-
riéndose a la posición de su empresa sin importar qué argumentos o temas plantee la otra parte. Recuerde
que demostrar que usted entiende claramente la posición de la otra parte no es lo mismo que estar de acuerdo
con él. Puede haber muchos puntos en los cuales está en desacuerdo. No obstante, una negociación cons-
tructiva solo puede proceder con información completa y objetiva y no con ideas preconcebidas o posiciones
arraigadas e intransigentes.
Construya una relación de trabajo. La idea de negociar como si se tratara de una persona con la que le
gustaría mantener una relación a largo plazo es clave en las negociaciones efectivas. Pensamos en relaciones
a largo plazo como las que tenemos con individuos u organizaciones que valoramos y, por tanto, nos incli-
namos a trabajar duro para mantenerlas. Cuanto más fuerte sea la relación de trabajo, mayor será el nivel de
confianza que se puede generar.

CÉNTRESE EN LOS INTERESES, NO EN LAS POSICIONES  Existe una diferencia grande entre las posicio-
nes que cada parte adopte y los intereses que subrayan y moldean esas posiciones. Cuando nos referimos
a “intereses”, nos referimos a las motivaciones fundamentales que enmarcan las posiciones de cada parte.
Como Fisher y Ury anotan, “los intereses definen el problema.”34 No es la posición adoptada por cada
parte lo que le da forma a la negociación sino los intereses, que son la fuente de los miedos, necesidades y
deseos de las partes.
¿Por qué buscar intereses subyacentes en lugar de centrarse simplemente en las posiciones que se
ponen sobre la mesa? Ciertamente, es más fácil negociar con la otra parte, desde el punto de nuestra posi-
ción contra la de ellos. Sin embargo, hay algunas razones de peso por las cuales enfocarse en los intereses,
en lugar de las posiciones que nos puede ofrecer una “ventaja” importante para el éxito de las negociacio-
nes. Primera, a diferencia de las posiciones, por lo general para todo interés hay varias alternativas que
pueden satisfacerlo. Por ejemplo, si mi mayor interés es asegurar que mi empresa perdure en el negocio
durante los próximos años, puedo buscar soluciones en una negociación que no sean simplemente expri-
mir hasta la última gota de la ganancia del contratista. Por ejemplo, podría entrar en una relación a largo
plazo con el contratista en la que estoy dispuesto a renunciar a algunos beneficios de este trabajo, mientras
el contratista acepte un acuerdo de exclusividad los próximos tres años. El contratista entonces recibirá
una ganancia adicional del trabajo pagándome menos de lo que yo deseo (mi posición), mientras me sumi-
nistra trabajo a largo plazo (mi interés).
Otra razón para centrarse en los intereses sostiene que la negociación basada en las posiciones a
menudo genera obstáculos, puesto que cada parte trata de descubrir la posición de su oponente mientras
oculta la propia. Consumimos tiempo y recursos valiosos para hacer visibles nuestras distintas posiciones
mientras escondemos tanto como sea posible nuestras verdaderas intenciones. Por el contrario, al centrarnos
en los intereses, adoptamos una mentalidad de socios que reconoce la legitimidad de los intereses de ambas
partes y trata de encontrar soluciones mutuamente satisfactorias.

Búsqueda de opciones de ganancia mutua


Los gerentes a veces se ponen obstáculos, por lo que es difícil considerar opciones gana-gana cuando negocian.
Los gerentes pueden tener juicios a priori. Rápidamente llegamos a conclusiones acerca de la otra parte y
cualquier cosa que digan por lo general sirve para solidificar nuestras impresiones. Además, en lugar de tratar de
ampliar nuestras opciones al iniciar la negociación, solemos ir en otra dirección poniendo límites a cuánto estamos
dispuestos a renunciar, hasta dónde estamos dispuestos a llegar, y así sucesivamente. Cada juicio prematuro limita
nuestra libertad de acción y nos coloca en un intercambio de adversarios en donde hay ganadores y perdedores.
Algunos gerentes buscan solo la mejor respuesta. Un error común que cometen es asumir que si se
someten a todas sus tácticas y posiciones de negociación con el tiempo van a obtener la “mejor” respuesta.
En realidad, la mayoría de las negociaciones, sobre todo si van a resultar en gana-gana, nos obligan a ampliar
nuestra búsqueda, sin límites. Por ejemplo, podemos definir erróneamente la “mejor” respuesta como lo que
214 Capítulo 6  •  Conformación del equipo del proyecto, conflicto y negociación

generalmente significaría lo mejor para nuestro lado, sin considerar otra parte. Es importante reconocer que
todos los problemas se prestan a múltiples soluciones. En efecto, considerando las múltiples soluciones, se
tienen más probabilidades de lograr aquella mutuamente satisfactoria.
Los gerentes asumen que solamente hay un “pastel fijo.” ¿Hay realmente solo un conjunto fijo de alternativas
disponibles? Tal vez no. Es común encajarse en un escenario de “yo gano, tú pierdes” que prácticamente garantiza
una dura negociación con poco o ningún esfuerzo para buscar soluciones creativas que satisfagan mutuamente.
Los gerentes piensan que “la solución de su problema, es su problema” es otro obstáculo. La negociación
engendra egocentrismo. Cuanto mayor sea nuestra creencia de que la negociación consiste simplemente en
cuidar de nosotros mismos, menor será la probabilidad de que estemos dispuestos a participar en soluciones
que beneficien a todos. Nuestra posición se convierte rápidamente en puro interés propio.
Si estos son los problemas más comunes que impiden el gana-gana, ¿qué se puede hacer para mejorar
el proceso de negociación? Hay algunas pautas importantes que podemos seguir para fortalecer la relación
entre las dos partes y mejorar la probabilidad de obtener resultados positivos. En pocas palabras, algunas
opciones por considerar en la búsqueda de alternativas gana-gana incluyen un positivo e integrador inter-
cambio de ideas, ampliación de opciones e identificación de intereses comunes.
Un positivo e integrador intercambio de lluvia de ideas implica que una vez iniciado un proceso de
negociación, durante esta primera fase buscamos incluir a la otra parte en una sesión de resolución de pro-
blemas, con el fin de detectar resultados alternativos. Este enfoque está muy lejos de las típicas tácticas de tra-
zar estrategias de negociación para utilizarlas en contra del otro equipo. Al involucrar a la otra parte en una
sesión de lluvia de ideas, tratamos de convencerla de que percibimos el problema como uno mutuamente
solucionable que requiere la participación y creatividad de ambas partes. Invitar a la otra parte a una sesión
de lluvia de ideas de este tipo tiene un efecto poderoso para desarmar su actitud defensiva inicial. Demuestra
que no estamos interesados en vencer al otro lado, sino en la solución del problema. Además, refuerza el
punto anterior de la necesidad de separar a la gente del problema. De esta manera, ambas partes trabajan
en colaboración para encontrar una solución satisfactoria para los dos, fortaleciendo los lazos de la relación.
La ampliación de opciones es también una ramificación directa de la noción de lluvia de ideas. Al ampliar
nuestras opciones se nos obliga a abrirnos a posiciones alternativas y puede ser el resultado natural de centrarse
en intereses, en lugar de en posiciones. Cuanto más conozco acerca de los intereses de la otra parte y estoy
dispuesto a examinar detenidamente el mío, mayor será la probabilidad de que juntos podamos trabajar en la
generación de un abanico de opciones más amplio del que inicialmente tendríamos la tentación de encerrarnos.
Finalmente, la tercera técnica para mejorar las posibilidades de obtener resultados gana-gana es la
identificación de intereses comunes. Un método de negociación empleado comúnmente por negociadores
experimentados es centrarse primero en cuestiones menores o periféricas que ofrecen una mayor probabi-
lidad de llegar a un acuerdo y dejar para un momento posterior en la negociación poner sobre la mesa los
temas más importantes. Una vez que las dos partes comienzan a trabajar juntas para identificar sus intereses
comunes y ganan algo de confianza al trabajar de forma colaborativa, es posible volver a introducir los pun-
tos de conflicto más importantes. Para entonces ambas partes habrán desarrollado un ritmo de trabajo y un
nivel de armonía que facilita buscar intereses comunes dentro de estos grandes temas.

Insistencia en el uso de criterios objetivos


Uno de los mejores métodos para garantizar que la negociación avance a lo largo de las líneas de fondo es
enmarcar la discusión en torno a criterios objetivos,35 sin agobiarse argumentando percepciones o evaluacio-
nes subjetivas. Por ejemplo, un gerente de proyectos recientemente casi vio cancelado su proyecto de desa-
rrollo de nuevos productos (DNP) debido a las negociaciones prolongadas con su cliente sobre la entrega de
un prototipo de trabajo “aceptable.” Obviamente, el gerente de proyectos tenía una interpretación de la pala-
bra aceptable muy diferente de la del cliente. El gerente de proyectos suponía que aceptable incluía los fallos
normales y los problemas técnicos preliminares, mientras que el cliente había usado la palabra para significar
libre de errores. En su deseo de poner el peso de la responsabilidad sobre el otro, ninguno estaba dispuesto a
alejarse de su interpretación de la palabra “aceptable.”
Datos objetivos y otros criterios cuantificables constituyen frecuentemente la mejor base para las negocia-
ciones precisas. Cuando las empresas o los individuos discuten sobre costos, precios, cronogramas de trabajo,
etc., utilizan normas y los conceptos establecidos que ambas partes pueden entender con un mínimo de error
de interpretación. Por otro lado, cuanto más vagos sean los términos empleados o más subjetivo sea el len-
guaje, mayor será el potencial para discutir propósitos cruzados, mientras ambas partes asumen que la otra está
usando las mismas interpretaciones de estos términos.
Resumen 215

Elaborar normas y procedimientos justos. Sea cual fuere la norma que se utilice como base de la negocia-
ción debe estar expresada claramente y puesta en términos que tengan el mismo significado para ambas partes.
Este punto es relevante en las negociaciones interculturales en donde los diferentes países y culturas frecuente-
mente conceden significados diferentes a expresiones o conceptos. Por ejemplo, varias empresas de construcción
pesada de Norteamérica, incluida Bechtel Corporation, presentaron una protesta contra una serie de empresas
constructoras japonesas por su complicidad en la división de contratos en licitación (uniones temporales en las
licitaciones) antes de la asignación del proyecto del aeropuerto de la bahía de Tokio. Las empresas japonesas a
su vez argumentaron que ellas estaban cumpliendo los términos de los recientes acuerdos de libre competencia
al permitirle a Bechtel presentar una oferta. Además, en la sociedad japonesa no hay nada inherentemente ilegal
o poco ético en la participación en este tipo de uniones temporales entre oferentes. Evidentemente, ambas par-
tes tenían interpretaciones muy diferentes de la idea de prácticas de licitaciones justas y claras.
Normas y procedimientos justos requieren que ambas partes se reúnan y negocien un mismo enten-
dimiento básico de los términos y responsabilidades. En la gerencia de proyectos, este concepto es especial-
mente clave porque la elaboración de contratos de construcción requiere la comprensión universal de un
conjunto de términos y normas. Cuando las dos partes participan en una negociación basada en estándares
apropiados, eliminan efectivamente la fuente de muchos malentendidos o malas interpretaciones.
Visualizando la necesidad de convertirse en expertos en formación de equipos, gerencia de conflictos
y negociación, es importante recordar que los mayores desafíos que enfrentan los gerentes de proyectos en la
ejecución de estos son los innumerables retos de las “personas”, los cuales se derivan del proceso de forma-
ción de un conjunto diverso de miembros en un equipo unificado y colaborativo, cuya meta es buscar el éxito
del proyecto. Crear un equipo e iniciar el proceso de desarrollo del proyecto riega las semillas de una amplia
variedad de conflictos entre los interesados del proyecto. Estos conflictos son inevitables y deben tratarse
no como una obligación, sino como una oportunidad. El conflicto puede conducir a resultados positivos
mediante la solidificación de compromiso y motivación entre los miembros del equipo y la generación de la
energía para completar las actividades del proyecto.
No obstante, la canalización de los conflictos de manera apropiada requiere un toque seguro del gerente
del proyecto. Nuestra capacidad para mantener la influencia y utilizar la negociación de manera hábil es una
gran ventaja para garantizar el desarrollo del equipo y que el conflicto no sirva para descarrilar el proyecto,
sino para renovarlo. El conflicto es inevitable, pero no desastroso. De hecho, el grado en que un conflicto
perturbe el desarrollo de un proyecto depende de la buena voluntad del gerente de proyectos para aprender
lo suficiente acerca de cómo enfrentar los conflictos de manera eficaz.

Resumen
1. Comprender los pasos necesarios para la confor- otro lado, los equipos fracasan a menudo debido a metas
mación de equipos de proyectos.   El primer paso en poco desarrolladas, funciones del equipo mal definidas,
la conformación del equipo del proyecto es la selección falta de motivación, mala comunicación, liderazgo defi-
del personal que integrará el equipo del proyecto. Este ciente, alta rotación del equipo del proyecto y el com-
proceso puede complicarse, sobre todo debido al alto portamiento disfuncional.
potencial de conflicto y negociación con los gerentes 3. Conocer las etapas de desarrollo de grupos. Los
funcionales que puedan mantener control efectivo sobre equipos de proyectos no comienzan sus tareas como
los miembros del equipo del proyecto. Después del aná- un cuerpo unido, cohesionado y motivado. Más bien,
lisis de los requisitos de formación y de la disponibilidad su desarrollo es un desafío que debe gerenciarse
de personal, el proceso normalmente implica vincular efectivamente si se quiere obtener el máximo rendi-
a las mejores personas para las tareas identificadas en el miento del equipo. Los equipos atraviesan algunas
proyecto; al mismo tiempo, se entiende la necesidad de etapas identificables en su proceso de desarrollo y los
tomar estas decisiones de personal, en colaboración con gerentes de proyectos tienen que reconocer y tratar
otros altos gerentes o jefes de departamento. de gerenciar estas etapas de desarrollo tan eficiente-
2. Conocer las características de los equipos efectivos y mente como sea posible. Un modelo de desarrollo del
por qué fallan los equipos de proyectos.  Los equi- equipo plantea un enfoque de cinco etapas—forma-
pos de alto desempeño se caracterizan por: (1) un claro ción, adaptación, asimilación, desempeño y termi-
sentido de la misión; (2) la comprensión de las inter- nación—cada uno con sus retos y comportamientos
dependencias; (3) la cohesión; (4) la confianza; (5) el grupales propios. Un modelo alternativo validado a
entusiasmo; y (6) la orientación hacia los resultados. Por través de trabajos de grupos de investigación sostiene
216 Capítulo 6  •  Conformación del equipo del proyecto, conflicto y negociación

que los grupos adoptan un proceso de “equilibrio efectivamente de los equipos virtuales se encuentran en
intermitente” a medida que evolucionan. el establecimiento y refuerzo de la confianza entre los
4. Describir cómo lograr la cooperación interfuncional miembros del equipo y en el establecimiento de patro-
en equipos.  Metas de orden superior, normas y pro- nes de comunicación efectivos.
cedimientos, proximidad física y accesibilidad son facto- 6. Comprender la naturaleza del conflicto y evaluar los
res importantes para motivar a la gente a colaborar. Los métodos de respuesta.  El conflicto es un resultado
efectos de esta cooperación entre funciones son dobles: inevitable cuando miembros del equipo con orígenes
pueden tener un impacto positivo en los resultados de funcionales, personalidades, experiencias y actitudes
la tarea del proyecto y en los resultados psicosociales diferentes se reúnen y esperan trabajar colaborativa-
del equipo del proyecto. Los resultados de la tarea afec- mente. Entre las causas de los conflictos organizacio-
tan positivamente el proyecto en cuestión, mientras los nales están los recursos escasos, la incertidumbre sobre
resultados psicosociales significan que los miembros del las líneas de autoridad y la diferenciación. Las causas
equipo mantienen una actitud positiva hacia la expe- de los conflictos interpersonales son: atribuciones erró-
riencia en el proyecto y entrarán en nuevos proyectos neas, comunicación deficiente y rencores y prejuicios
con una fuerte motivación para tener éxito nuevamente. personales. Los conflictos pueden resolverse mediante
5. Conocer las ventajas y desvantajas de los equipos de la mediación, el arbitraje, el control, la aceptación o la
proyectos virtuales.  Los equipos de proyectos vir- eliminación.
tuales se definen como la utilización de medios electró- 7. Comprender la importancia de la habilidad de nego-
nicos, incluido el correo electrónico, internet y telecon- ciación en la gerencia de proyectos.  Los gerentes
ferencias, para vincular a los miembros de un equipo de proyectos negocian habitualmente con una amplia
de trabajo dispersos geográficamente, en gran parte variedad de interesados organizacionales por recursos,
debido a la globalización de la gerencia de proyectos. consideraciones contractuales, términos y condiciones,
A medida que las empresas multinacionales intentan etc. Los gerentes de proyectos efectivos a menudo son
gerenciar proyectos de unidades geográficamente dis- personas que abordan las negociaciones de una manera
persas, se necesitan medios técnicos sofisticados que sistemática, tomándose tiempo para analizar cuidado-
apoyen sus comunicaciones y redes de trabajo. Las samente la naturaleza de la negociación, lo que espe-
grandes barreras físicas causadas por la globalización, ran alcanzar, y cuánto están dispuestos a ofrecer para
junto al aumento de equipos de proyectos multiorga- lograr su meta importante. En la negociación basada
nizacionales, han generado un mayor uso de tecnolo- en principios, el objetivo principal es tratar de buscar
gías virtuales para vincular a los miembros del equipo. alternativas gana –gana, que les permitan a ambas par-
Dos de los mayores desafíos en la creación y gerencia tes negociar para lograr sus metas.

Términos clave
Accesibilidad (p. 202) Cooperación interfuncional Etapa de formación (p. 199) Orientación (p. 195)
Confianza (p. 194) (p. 201) Etapa de levantamiento Proximidad física (p. 202)
Conflicto administrativo Diferenciación (p. 194) (p. 199) Resultados (p. 203)
(p. 206) Equilibrio interrumpido Frustración (p. 208) Resultados de la tarea (p. 203)
Conflicto orientado a las (p. 200) Interacción (p. 195) Resultados psicosociales
metas (p. 206 ) Equipos virtuales (p. 204) Interdependencias (p. 194) (p. 203)
Conflictos (p. 206) Etapa de adaptación Meta de orden superior Terminación (p. 194)
Conflictos interpersonales (p. 199) (p. 201)
(p. 206 ) Etapa de asimilación Negociación (p. 210)
Conformación de equipos (p. 199) Negociación basada en
(p. 190) principios (p. 211)

Preguntas para discusión


1. Este capítulo analizó las características de los equipos de pro- 3. Identifique las etapas de desarrollo del grupo. ¿Por qué es nece-
yectos de alto rendimiento. Enumere los factores que caracteri- sario que los equipos de proyectos se muevan a través de estas
zan a estos equipos y dé ejemplos de cada uno. etapas con el fin de ser productivos?
2. “La confianza en realidad puede fomentar desacuerdos y con- 4. El modelo de equilibrio puntuado o interrumpido ofrece una
flictos entre los miembros del equipo.” Explique por qué este visión alternativa del desarrollo del grupo. ¿Por qué se sugiere que
podría ser el caso. algún momento decisivo (como una explosión de emociones), a
Estudio de caso 6.1 217

menudo se produce alrededor del punto medio del proyecto? 7. Identifique los cinco métodos principales para la resolución de
¿Qué quiere lograr para el equipo este evento definitivo? conflictos. Dé un ejemplo de cómo cada uno puede aplicarse a
5. Explique los conceptos de resultados de “tarea” y “psicosocia- un episodio hipotético de conflicto, en un equipo de proyectos.
les” de un proyecto. ¿Por qué son tan importantes los resultados 8. ¿Cuáles son algunas de las directrices para adoptar una estrate-
psicosociales para los miembros del equipo del proyecto? gia de “negociación basada en principios”?
6. Distinga entre los puntos de vista tradicional, de conducta e inte- 9. Explique la idea de que debemos “centrarnos en los intereses,
ractivo, del conflicto en el equipo. ¿Cómo explicaría y cómo trata- no en las posiciones.” Dé un ejemplo en el que se negoció con
ría cada uno un episodio de conflicto en un equipo de proyectos? éxito con otra persona utilizando este principio.

Estudio de caso 6.1


Columbus Instruments
Desde hace varios años han venido presentándose pro- ni siquiera se les permite a los miembros del equipo del
blemas con el nuevo proceso de desarrollo de productos proyecto realizar una evaluación del desempeño: de este
en Columbus Instruments, Inc. (CIC) (no es su nombre derecho gozan solo los jefes de los departamentos funcio-
real). Los últimos seis proyectos de alta visibilidad o bien nales. Tercero, muchos proyectos requieren que se asig-
se desecharon por completo debido a costos excesivos y nen miembros al equipo de forma exclusiva, es decir, una
retrasos en la programación o, una vez liberados al mer- vez que el personal ha sido asignado a un proyecto, por
cado, fueron un desastre comercial. La compañía estima lo general, permanecen en el equipo del proyecto tiempo
que en los últimos dos años, ha malgastado más de 15 completo hasta la terminación del proyecto. El tiempo
millones de dólares en proyectos mal ejecutados o fraca- promedio de duración de un proyecto es de catorce meses.
sados. Cada vez que un nuevo proyecto fracasó, la com- Una mañana, mientras usted está caminando por
pañía realizó extensas reuniones posteriores de revisión, los pasillos, nota un equipo de proyecto en su “cuarto
análisis, documentación y estudios de mercado para tratar de guerra” establecido para la más reciente iniciativa de
de determinar la causa. Hasta la fecha, CIC no ha podido desarrollo de nuevos productos dentro de la empresa. El
determinar en qué parte del proceso de gerencia y desa- concepto de cuarto de guerra exige que los miembros del
rrollo de proyectos se localizan los problemas. Algo, en equipo del proyecto puedan agruparse en un espacio cen-
alguna parte, está ejecutándose muy mal. tral, lejos de sus departamentos funcionales, durante la
A usted se le llama a la organización como con- vida del proyecto. Lo que le intriga es un cartel escrito a
sultor para tratar de entender el origen de los problemas mano, pegado en la puerta del cuarto de guerra del pro-
que conducen a la desmoralización generalizada en toda yecto: “Colonia de leprosos.” Cuando usted pregunta por
la empresa. Después de pasar horas entrevistando al per- ahí acerca del cartel, algunos miembros de la empresa le
sonal directivo de la gerencia de proyectos y al personal dicen con una sonrisa: “Oh, nos gusta jugar bromas a la
técnico, usted está convencido de que el problema no gente asignada a nuevos proyectos.”
radica en sus procesos, que son lógicos y están actualiza- Investigando un poco más en el equipo del pro-
dos. Por otra parte, usted tiene algunas preguntas acerca yecto, determina que ellos no se divierten con el cartel.
de la productividad del equipo del proyecto. Parece que Un ingeniero se encoge de hombros y dice: “Esa es su
cada proyecto se ha ejecutado con retrasos, por encima del forma de asegurarse de que entendemos lo que se nos
presupuesto y ha generado funcionalidades subóptimas, ha asignado. La semana pasada pusieron otro que decía
independientemente de las habilidades del gerente de pro- ‘Purgatorio.’” Ese día, más tarde, cuando se le pregunta
yectos a cargo. Esta información indica que puede haber al gerente de proyectos acerca de los carteles, él confirma
algunos problemas en la forma en que los equipos de pro- la historia y añade algunos datos interesantes: “Por aquí
yectos están operando. se utiliza un significado centralizado para los equipos de
Al analizar el proceso de desarrollo de proyectos de proyectos. No puedo decir nada en cuanto a quién será
CIC, usted detecta varios elementos de interés. Primero, la asignado al proyecto y últimamente, los jefes funcionales
empresa está organizada con líneas estrictamente funcio- han estado usando nuestros proyectos como un vertedero
nales. Los proyectos cuentan con personal de los departa- para sus empleados de bajo rendimiento.”
mentos después de negociaciones entre el gerente de pro- Cuando usted le hace otra pregunta, el gerente
yectos y los jefes de departamento. Segundo, la cultura de de proyectos señala: “Piense en esto. No puedo decidir
CIC parece asignar poco estatus o autoridad a los gerentes quién se asigna al equipo. Ni siquiera puedo evaluarles su
de proyectos. Como evidencia de este hecho, se nota que de­sempeño. Ahora, si usted fuera un jefe de departamento

(continúa)
218 Capítulo 6  •  Conformación del equipo del proyecto, conflicto y negociación

que trata de descargarse de un alborotador o de alguien proyectos de desarrollo de nuevos productos en CIC. Él
incompetente, ¿qué mejor que enviárnoslo a un equipo reflexiona sobre las implicaciones de cómo se han aten-
de proyectos durante un año o algo así? Por supuesto, se dido los proyectos de su organización y, a continuación,
puede imaginar cómo se sienten cuando escuchan que se dice: “Está bien, ¿qué sugiere que hagamos?”
ha asignado a uno de nuestros equipos de proyectos. Es
como si usted acabara de firmar su sentencia de muerte.
Preguntas
¡Ni hablar de la baja motivación!”
Cuando usted les pregunta a varios jefes de depar- 1. ¿Cuáles son las implicaciones del enfoque de asigna-
tamento sobre las afirmaciones del gerente de proyectos, ción de personal a los equipos de proyectos en CIC?
ellos niegan que esta sea una política adoptada. Como dijo ¿La empresa utiliza los equipos de proyectos como
el jefe de finanzas: “Cuando solicitan personal, les damos campos de entrenamiento para los talentosos o como
a los equipos de proyectos a nuestros mejores hombres vertederos de bajo rendimiento?
disponibles.” Sin embargo, también admiten que tienen 2. ¿Qué le aconsejaría al CEO para corregir el problema?
la última palabra en la asignación del personal y que los ¿Por dónde empezar?
gerentes de proyectos no pueden apelar sus decisiones. 3. Analice cómo los aspectos de la estructura organi-
Después de estas discusiones, usted le sugiere al zacional y del poder desempeñaron un papel en la
CEO que el método de asignación de personal a los pro- forma en que la gerencia del proyecto redujo su efec-
yectos puede ser una razón del pobre desempeño de los tividad en CIC.

Estudio de caso 6.2


El contador y los vaqueros
La reunión del equipo del proyecto de la mañana pro- Neil responde, “ Hasta la fecha, esa ha sido su excusa para
metía ser interesante. Desde hace varias semanas han ido no asistir a la mitad de las reuniones. Solo por curiosi-
acumulándose tensiones entre la representante de marke- dad,” continúa con sarcasmo, “¿A cuántas más cree que va
ting, Susan Scott, y el de finanzas, Neil Scheinde, desde a faltar mientras que pasa el tiempo descansando junto a
que se formó el equipo del proyecto. Como gerente del la piscina con sus amigos?”
proyecto, usted ha sido consciente de que Susan y Neil no Susan se sonroja: “No tengo por qué aguantar esto.
se miran a los ojos, pero pensó que con el tiempo iban a Ustedes, los contadores, no tienen ni idea de cómo fun-
empezar a apreciar la perspectiva de cada parte y a coope- ciona este negocio o de qué valor aporta. ¡Están tan ocu-
rar. Infortunadamente, eso no ha sucedido, hasta ahora. pados analizando cada centavo que sufren de fatiga visual
De hecho, no pasa un día en el que no reciba queja del uno permanente!”
o del otro respecto al comportamiento, la falta de compro- “Tal vez debería prestar mayor atención, si no tuviera
miso, cooperación, mala calidad o rendimiento general que vigilar constantemente a los vaqueros de las ventas,”
del otro miembro del equipo. argumenta en contra Neil. “¡Apuesto a que ustedes regala-
Cuando el equipo se reúne para revisar el estado rían nuestros productos, si esto les permitiera cumplir sus
del proyecto, usted comienza con la actualización de números trimestrales, incluso si nos hacen caer!”
las tareas del proyecto, de los problemas que tienen los Usted, sentado atrás, está sorprendido por la hosti-
miembros del equipo y la evaluación de los resultados del lidad de la discusión entre Susan y Neil, que amenaza con
proyecto hasta la fecha. Antes de avanzar en la revisión, salirse de control. Los demás miembros del equipo están
Susan interrumpe diciendo: “John, voy a estar fuera de la esperando su respuesta. George, de ingeniería, con una
ciudad los próximos diez días visitando clientes, así que expresión divertida en su rostro, como si dijera: “Está bien,
no puedo asistir a las reuniones del comité los próximos usted nos condujo hasta este punto. Ahora, ¿qué va a hacer
dos viernes.” al respecto?”
”Qué cifras”, Neil murmura lo suficientemente alto Usted responde: “Gente,” dando un golpe seco
para que todos lo escuchen. sobre la mesa, “es suficiente. Hemos terminado por hoy.
Susan se voltea. “Tengo otro trabajo por realizar Quiero reunirme con Susan y Neil en mi oficina dentro
aquí, y usted sabe lo que representa la venta. Puede que le media hora.”
convenga dejarlo todo para asistir a estas reuniones, pero Mientras todos se retiran, se inclina hacia atrás en
algunos de nosotros tenemos otras responsabilidades.” su silla y piensa cómo va a resolver este problema.
Estudio de caso 6.3 219

Preguntas 3. Desarrolle un procedimiento de gerencia de con-


flictos para la reunión que se llevará a cabo dentro
1. ¿El alegato de hoy entre Neil y Susan fue el verdadero
conflicto o más bien un síntoma? ¿Qué pruebas ten- de 30 minutos. Elabore un libreto sencillo que le
dría usted para sugerir que no es más que un síntoma ayude a anticipar los comentarios que probable-
de un problema mayor? mente escucharía de ambas partes.
2. Explique cómo la diferenciación desempeña un papel 4. ¿Qué estilo de resolución de conflictos se ajusta a este
importante en los problemas que existen entre Susan caso? ¿Por qué? ¿Por qué serían inadecuados los otros
y Neil. métodos de solución, en esta situación?

Estudio de caso 6.3


Johnson & Rogers Software Engineering, Inc.
Kate Thomas, gerente de proyectos de Johnson & Rogers de contactos con altos funcionarios de su compañía. Ella no
Software Engineering, estaba pendiente de su primera “reu- lo sabía, pero no tardaría en descubrir cómo se sentían con
nión” de equipo de proyectos. “Reunión” va entre comi- el proyecto y cuál sería su nivel de compromiso.
llas, porque, en realidad, no iba a permanecer sentada en La primera reunión virtual del proyecto se programó
una mesa con ninguno de los otros miembros del equipo para comenzar con puntualidad a las 9:00 a.m., hora del
del proyecto. A ella se le había responsabilizado de un gran Pacífico. Esto suscitó el primer problema. A medida que
proyecto de desarrollo de software en el cual tomarían Kate miraba la cámara montada sobre su monitor, ella
parte miembros del equipo tanto del interior de la organi- observaba la parte inferior de la pantalla en busca de señales
zación, como de fuera de ella, ninguno de los cuales estaba que le indicaran que habían iniciado sesión los otros miem-
actualmente trabajando en la misma oficina de Redlands, bros del equipo. Finalmente, a las 9:15, se unió Sally, con
California, donde ella trabajaba. De hecho, mientras Kate Toshiro inició sesión poco después. Mientras conversaban,
marcaba los nombres en una libreta de apuntes que tenía continuaron esperando a que los otros miembros iniciaran
frente a ella, no sabía si estar impresionada o aprehensiva su sesión. El tiempo seguía pasando. A las 9:30 a.m., nadie
acerca del proyecto que estaba a punto de iniciar. más se había conectado; entonces Kate le pidió a su secreta-
ria que comenzara a hacer llamadas telefónicas para com-
Vignish Ramanujam (programador sénior): Nueva
probar si los otros miembros del equipo estaban tratando
  Delhi, India
de acceder al sistema. Finalmente, a las 10:25, el equipo
Anders Blomquist (diseñador de sistemas): Uppsala,
estaba integrado por cinco miembros: Anders, Sally, Penny,
 Suecia
Patrick y Toshiro. Se decidió que, en pro de hacer algo, se
Sally Dowd (ingeniero de sistemas): Atlanta, Georgia
comenzaría la reunión con quienes habían iniciado sesión.
Penny Jones (programador júnior): Bristol, Inglaterra
La reunión empezó con el orden del día que Kate había pre-
Patrick Flynn (programador junior): San Antonio,
parado y enviado por correo electrónico el día anterior. A
 Texas
los diez minutos, el enlace del video con Penny se perdió
Erik Westerveldt (subcontratista): Pretoria, Sudáfrica.
repentinamente. Los otros miembros del equipo esperaron
Toshiro Akame (representante del cliente): Kioto,
durante cinco minutos, y se tornaron impacientes porque
 Japón
Penny no lograba unirse a la reunión. No había ninguna
Kate se dio cuenta rápidamente de que el reto con señal de Vignish o de Erik.
este equipo implicaría hallar la manera de crear un equipo La reunión rápidamente se empantanó en detalles
de proyecto integrado con estas personas, la mayoría de técnicos y los asistentes se dieron cuenta de que varios de
las cuales nunca se habían tratado antes. Aunque Sally y los aspectos técnicos no podrían resolverse sin la participa-
Patrick trabajaron para Johnson & Rogers en otras sec- ción de los miembros del equipo que faltaban. A pesar de
ciones de la planta, el resto del “equipo” era extranjero. que él hizo todo lo posible para ocultarlo, se hizo evidente
Erik, de Sudáfrica, era clave para el proyecto debido a que que Toshiro, en particular, estaba frustrado por la falta
su compañía había desarrollado algunos de los procesos de progreso de la reunión. Kate sugirió que se hiciera un
especializados que el proyecto requería y, por tanto, debía receso hasta las 11 a. m., mientras ella hacia otro intento por
tratarse como un socio industrial. Los otros miembros del ponerse en contacto con los miembros que faltaban, pero
equipo habían sido integrados al equipo por Erik o a través Toshiro se opuso, diciendo: “Serían las 3 a.m. en mi país.
(continúa)
220 Capítulo 6  •  Conformación del equipo del proyecto, conflicto y negociación

Acaba de pasar la medianoche. He estado aquí durante 15 todos pudieran cumplir. Finalmente, después de dar
horas y me gustaría regresar a casa.” Finalmente, se acordó varias vueltas, para acordar el horario de las teleconfe-
convocar la reunión para mañana a la misma hora. Toshiro rencias, Erik tomó la palabra: “Tal vez no todos nece-
estuvo de acuerdo, pero de mala gana: “¿No podemos bus- sitamos reunirnos al mismo tiempo. Kate, ¿por qué no
car un horario acorde con mi pro­gra­ma­ción?” Kate pro- programa reuniones con cada uno de nosotros cuando
metió considerar el asunto. usted requiera hablar.”
La reunión del día siguiente tuvo un éxito relativo. Kate se opuso diciendo: “Erick, el objetivo principal
Aunque todos pudieron iniciar sesión en el sistema, en un de las teleconferencias es mantener el equipo unido, no es
plazo razonable, la conexión de Penny siguió cayéndose, para llevar a cabo reuniones uno a uno con cada miembro
lo cual exasperó a Vignish, el programador sénior. A pesar del equipo.”
de que la reunión se llevó a cabo con cortesía, nadie estaba Erik respondió: “Bueno, lo único que sé es que esta
dispuesto a manifestar sus opiniones sinceras acerca de las es apenas la primera videoconferencia y se está convir-
metas del proyecto y de cómo se esperaba que el equipo eje- tiendo en una carga.”
cutara sus tareas. Después de pedirles a los miembros del Penny tomó la palabra: “Tiene suerte. Al menos su
equipo una retroalimentación honesta y conseguir poca sistema funciona. El mío viene y va.”
respuesta, Kate finalmente declinó. Además, tenía la sen- “Bueno, ¿qué tal si se usan solo correos electróni-
sación de que había algo de animosidad tácita en la manera cos?”, sugirió Erik. “De esa manera. no importa qué hora
en que Patrick y Sally interactuaban. es en nuestra localidad.”
Después de ajustar la meta general y discutir acerca Los otros miembros del equipo estuvieron de
las responsabilidades del equipo, Kate les preguntó sobre acuerdo en que esta idea tenía sentido y parecía estar a
la fecha en la que se realizaría la próxima reunión. Siguió punto de aprobarse el uso de mensajes de correo electró-
un silencio general, y Anders pregunto: “Bueno, ¿con qué nico para las comunicaciones. En ese momento, Kate vol-
frecuencia usted espera que nos sigamos reuniendo de vió a entrar en la discusión y dijo con firmeza: “Miren, eso
esta manera? Para ser honesto, resulta inconveniente para no es suficiente. Debemos tener la oportunidad de hablar
mí asistir a estas sesiones con regularidad, ya que nuestro juntos. Los correos electrónicos no van a permitir eso.”
equipo de telecomunicaciones está en Estocolmo y tengo La discusión continuó. Con el tiempo, los miembros
que conducir una hora en cada dirección.” del equipo firmaron y acordaron que debían “hablar más”
A continuación, Toshiro tomó la palabra: “Siento acerca de estos temas. La reacción de Kate fue de decepción
tener que repetir este punto”, dijo, los horarios de las reu- y frustación. Ella percibía renuencia entre los miembros del
niones son muy incómodos para mí. ¿No podríamos acor- equipo a hablar sobre estos temas y utilizar el sistema de
dar un horario que fuera más aceptable?” videoconferencia de la manera que ella imaginaba. Cuando
Kate respondió: “Bueno, ¿qué le parece a las 5 de la Kate se sentó a almorzar al mediodía, se preguntó cómo
tarde. Serían las...” Kate se detuvo y rápidamente consultó debería proceder de aquí en adelante.
su agenda personal: “ 9 de la mañana para usted.”
Esta sugerencia fue recibida con una ola de objecio-
Preguntas
nes, la primera de Penny, quien declaró: “Uh, Kate, sería
la 1 a.m. en Inglaterra.” 1. ¿Qué le aconsejaría a Kate para que procediera?
Apenas terminó de hablar ella, Anders, Erik y Analice la conversación que ella tuvo esta mañana.
Vignish intervinieron: “Kate, serían las 2 a.m. en Estocolmo ¿Qué salió bien? ¿Qué salió mal?
y en Pretoria” y “Kate, ¿sabe usted que serían las 6 a.m. en 2. ¿Cuáles deberían ser los próximos pasos de Kate?
Nueva Delhi?” 3. ¿Cómo ella puede utilizar la tecnología de internet
Los miembros del equipo discutieron, de ida y y las teleconferencias para mejorar el desarrollo y el
vuelta, tratando de encontrar un horario razonable que rendimiento del equipo?

Ejercicios de negociación
El siguiente es un escenario de negociación entre dos empresas: Steel Perspectiva de Steel Fabrik
Fabrik, Inc., (SFI), y Building Contractors of Toledo (BCT). Se le
Usted es el gerente de proyectos de un nuevo proyecto de construc-
pide que tome cualquier parte de la negociación, SFI o BCT. ¿Cómo
ción de una planta para la fabricación de acero que construye Building
se prepararía para esta negociación? ¿Cómo crearía un resultado
gana-gana para ambas partes? Contractors of Toledo (BCT). Su cliente es Steel Fabrik, Inc. (SFI), una
Ejercicios de negociación 221

multinacional fabricante de productos de acero. La fecha límite para llegar a un acuerdo que preserve el margen de ganancia para BCT,
terminar el proyecto es de dieciocho meses y tiene un presupuesto de pero, al mismo tiempo, debe mantener contento a SFI. Al sentarse
6 millones de dólares. Durante las últimas semanas, ha sido cada vez frente al computador de su casa, este domingo por la tarde, ya está
más difícil enfrentar las demandas de su cliente. SFI ha insistido en temeroso del regreso al trabajo mañana por la mañana. ¿Qué actitud
una lista de órdenes de cambio para satisfacer sus necesidades inme- debería tomar para las próximas negociaciones?
diatas de distribución y diseño de la planta. Su contraparte dice que
debido a que SFI paga millones por la planta tiene derecho a realizar
cambios en el proyecto durante el tiempo que sea necesario, para “ha- Perspectiva de SFI
cer las cosas bien.” Usted está preocupado porque todos los días se Usted es el gerente de Steel Fabrik, Inc. (SFI) y es responsable de
dedica tiempo al procesamiento de órdenes de cambio, lo cual retra- la supervisión de la construcción de la planta de fabricación en la
sa aún más la fecha de terminación específica ya que ingeniería debe región noroeste de Ohio. Recientemente, su gerente le informó que
aprobar los cambios, diseño debe alterar los planos y fabricación debe debido a nuevas oportunidades, esta planta podría ser muy valiosa
cambiar la estructura de la planta. para su empresa, siempre que el ramal de conexión con el sistema de
BBCT ya está en problemas en este proyecto. Con el fin de transporte ferroviario de mercancías pueda modificarse y mejorarse
ganar el contrato, ellos bajaron de manera significativa la oferta de para manejar grandes volúmenes de tráfico de entrada y salida de la
sus competidores locales, dejando un margen de ganancia mínimo planta. Esta instalación representa una inversión significativa para
en el mejor de los casos. Infortunadamente, ahora con la lista de soli- su empresa en el Medio Oeste de Estados Unidos, después de varios
citudes de cambio, en el presupuesto y el cronograma se estiran hasta años de contactos con funcionarios del gobierno local tratando de
el límite. Usted está bajo una creciente presión de la alta gerencia traer nuevos empleos a la región. Como resultado, usted siente que
por completar el trabajo con el margen de beneficio esperado. Usted tiene derecho de hacer los ajustes necesarios al proyecto para obte-
tiene 50,000 dólares para trabajar y cumplir sus metas de rentabili- ner el máximo provecho de este. Estas solicitudes de cambio son, se-
dad. Usted ya estaba bajo presión en su organización, debido a que gún su opinión, razonables, necesarias y no tan costosas. Sin embar-
su trayectoria en los últimos tres años no ha sido buena, pues varios go, desde hace varias semanas, usted ha experimentado el aumento
proyectos entregados fuera de presupuesto y tarde le han dado la de “no aceptaciones” del gerente de proyectos BCT a una serie de
razón a la alta gerencia para vigilar muy de cerca su rendimiento solicitudes de cambios relativamente menores. Su enfoque ha sido
en este proyecto. Aunque nadie se lo ha dicho en voz alta, usted es ridiculizar la necesidad de los cambios, usar “soluciones rápidas”
consciente de que otro rebasamiento o retraso significativo proba- de bajo costo, o simplemente tratar de disuadirle de ellas. Como re-
blemente le costará su puesto en BCT. sultado, usted está convencido de que también se resistirán a estas
Debido a que usted ve a SFI como un cliente potencial a largo últimas solicitudes de cambio, por lo que su relación general con el
plazo está reacio a negarse a sus demandas. Usted sabe que un resul- gerente de proyectos de BCT se ha vuelto cada vez más tensa.
tado gana-gana probablemente traiga un futuro negocio de SFI a su Usted ha informado casualmente al representante de ventas de
empresa y que podría ser el origen de una cartera rentable de nego- BCT que este es la primera de lo que su empresa anticipa será una serie
cios durante al menos los próximos cinco años. Su departamento de de plantas similares que se construirán en la región de los Grandes La-
ventas es consciente de que este proyecto con SFI podría conducir gos en los próximos diez años. A pesar de que no ha contraído compro-
a futuros negocios y se ha sumado a la presión haciendo hincapié misos para hacer negocios futuros con BCT, le ha quedado claro que el
constantemente en la importancia de mantener al cliente feliz. Como desempeño exitoso en este proyecto hará que la opción preferida para el
resultado, usted cuenta con elementos importantes en su organiza- trabajo futuro serán ellos. Después de todo, ellos entienden sus necesi-
ción, así como con el cliente, a la espera de que complete con éxito el dades y tienen un historial comprobado de éxito de proyectos.
proyecto para satisfacción de todos. Usted ha recibido presiones de la alta gerencia, con sede en
Al leer sus correos electrónicos durante el fin de semana, nota Bruselas, para completar el proyecto a tiempo; de hecho, finalizarlo
que ha llegado la última serie de órdenes de cambio de SFI para ajus- a tiempo es su mayor preocupación. SFI ya ha licitado proyectos de
tar el diseño de la planta, a fin de mejorar el tráfico ferroviario den- construcción en la región de los Grandes Lagos y tiene varios contra-
tro y fuera de la planta. Estos cambios implicarán detener el trabajo tos pendientes, muchos de gran tamaño. Además, los políticos locales
de construcción en curso; sus propios ingenieros y los reguladores están ansiosos de mostrar el proyecto como un ejemplo de una asocia-
del gobierno deberán reunirse para discutir estas solicitudes y se ción pública/privada exitosa, y con las elecciones locales acercándose,
deberán diseñar nuevas zonas de ensamble y de carga. Basado en se preguntan cuándo pueden anunciar su terminación. Si no tiene la
su experiencia, estima que los cambios necesarios añaden 150,000 planta lista a tiempo, pone en riesgo tener que anular una serie de con-
dólares al costo del proyecto y prorroga la fecha de terminación, mí- tratos importantes de construcción y frenar la contratación; además,
nimo, seis semanas. Peor aún, al examinar las solicitudes de cambio, esto lo avergonzaría a usted y al gobierno de la región. Debido a que
usted está convencido de que estas alteraciones son innecesariamen- las ofertas del contrato de construcción de la compañía todavía están
te complicadas y no agregan valor al diseño de la planta. La última revisándose, usted está ansioso por mantener esta información confi-
línea del correo electrónico preocupa más: SFI espera que los cam- dencial para así desviar la atención de sus competidores.
bios se realicen inmediatamente, sin reajustes en el cronograma para Hay 250,000 dólares en su presupuesto para gastar en costos
incluir esas modificaciones; de hecho, ellos mencionan que es obli- de las órdenes de cambio adicionales si es necesario, a pesar de que
gatorio que la planta entre en operación según lo programado. La usted está interesado en dar la mejor impresión posible a la alta ge-
única buena noticia es que su departamento de ventas ha encontrado rencia manteniendo los costos lo más bajo posible. Sin embargo, es
estrategias para hacer que SFI pague más dinero por los cambios, imposible ponerse de acuerdo para programar prórrogas, debido a
pero no están seguros de cuánto. todas las licitaciones pendientes y a otras presiones para finalizar la
Usted apenas acaba de escribir una breve nota para programar planta a tiempo. Fuentes de la industria han dado a entender cla-
una reunión este miércoles, con el objetivo de negociar un acuerdo ramente que BCT está en dificultades financieras y necesita tanto
sobre los cambios solicitados. Usted está bajo una fuerte presión por trabajo futuro, como puedan conseguir.
222 Capítulo 6  •  Conformación del equipo del proyecto, conflicto y negociación

Los ingenieros de la planta han revisado los requisitos de ca- detallado de cambios necesarios en el diseño y construcción y acaba
pacidad de transporte para la nueva planta y recomendaron cam- de recibir como respuesta una nota solicitando reunión formal para
bios significativos a la zona de embarque para acomodar el tráfico el miércoles por la mañana, con el objetivo de discutir los cambios
ferroviario adicional. Estos cambios se consideran claves debido a y encontrar una manera de “resolver nuestras diferencias.” Usted
las proyecciones de los modelos de negocio que su empresa ha de- sabe que esto significa que el gerente de proyectos ya decidió cómo
sarrollado para obtener el máximo uso y rentabilidad de la nueva responder a sus peticiones y que ahora está planeando una nego-
planta de fabricación. El sábado por la noche, usted le ha enviado un ciación. Cuando usted se sienta y reflexiona acerca de las presiones
correo electrónico al gerente de proyectos de BCT, con un conjunto que recibe de Bruselas, se pregunta qué enfoque se debería utilizar.

Ejercicios en internet
1. Dé clic sobre la página web de equipos de proyectos en www. a. Creación de una EDT para el proyecto
projectsmart.co.uk/five-steps-to-a-winning-project-team. b. Evaluaciones de desempeño
html/. ¿Cuál de estos cinco pasos parece el más fácil para un c. Salida a un evento deportivo del equipo del proyecto
gerente de proyectos y cuál parece ser más difícil? ¿Por qué? ¿De d. Almuerzos del equipo
qué forma se comparan las ideas de este capítulo con los con-
sejos dados en el enlace “cinco elementos esenciales para pro- 3. Dos programadores están involucrados en un conflicto que
yectar el éxito del equipo” en www.projectsmart.co.uk/5-essen- amenaza con perturbar el desarrollo del proyecto. El gerente
tials-to-project-team-success.html? ¿Qué sugiere esto acerca de de proyectos llama a los dos programadores a su oficina y les
la importancia de establecer las bases para el éxito del proyecto recuerda que están juntos “del mismo lado” en el trabajo para
a través del desarrollo del equipo? el desarrollo de la aplicación de software para la empresa. Su
2. Ingrese en el sitio web de un equipo deportivo profesional y expló- estilo de resolución de conflictos sería mejor verse como:
relo. ¿Qué claves se pueden conseguir respecto a la importancia de a. Arbitraje
los “equipos” y del “trabajo en equipo” en este sitio? Dé dos o tres b. Apaciguamiento
ejemplos concretos. c. Control del conflicto
3. Ingrese en el sitio web de una compañía farmacéutica. Explore d. Eliminación del conflicto
el sitio, en particular información sobre una nueva investiga-
4. Carrie está vinculada al departamento de marketing y ha
ción. ¿Qué tipos de equipos de proyectos se utilizan dentro de
estado cada vez más molesta con la actitud del miembro de
las compañías farmacéuticas? ¿Se pueden identificar al menos
producción del equipo del proyecto, Andrew. Él parece ig-
cinco áreas funcionales dentro de esas organizaciones, en las
norar sus opiniones o hacer comentarios despectivos cada
que deban trabajar juntos en un equipo de proyectos para desa-
vez que ella habla; por lo general, se refiere a marketing
rrollar un nuevo medicamento?
de una manera desagradable. ¿Qué fase de desarrollo de
4. Ingrese en www.ebxml.org/project_teams/project_teams.htm
grupo atraviesa el equipo del proyecto y se evidencia en las
y explore los proyectos y equipos de proyectos enumerados.
interacciones de Carrie y Andrew?
Observe el tamaño y la diversidad de algunos de estos equi-
a. Asimilación
pos de trabajo. ¿Qué desafíos podría encontrar en el intento
b. Ejecución
de traer a estos individuos a un equipo de proyectos? ¿De qué
c. Adaptación
manera el hecho de que algunos de los equipos estén conforma-
d. Terminación
dos por personal de diferentes organizaciones afecta nuestros
mejores intentos por moldear un equipo de proyectos? 5. Entre los medios útiles para desarrollar un sentido de
5. Ingrese en http://multimedia.journalism.berkeley.edu/works- equipo personal de trabajo desde los diferentes departa-
hops/projects/49/show/ y explore la naturaleza del proyecto de mentos funcionales, están todos los siguientes EXCEPTO:
trabajo para desarrollar tecnología de teleinmersión. Conéctese a. Colocación (proximidad física)
con el enlace marcado como “The Mision” y observe cómo la b. Metas comunes
tecnología ha cambiado hasta la fecha. ¿Cuáles son los avances c. Normas organizacionales que gobiernen su interacción
proyectados en la tecnología de teleinmersión para el año 2015? d. Horario de trabajo flexible
Preguntas de ejemplo del examen para la certificación
PMP ® Respuestas: 1. d—La resolución de problemas sería la mejor al-
ternativa cuando los temas no son muy personales como en este
1. Un gerente de proyectos está experimentando serios con- caso la percepción (con base en la interpretación de alcance del
flictos, profundamente arraigados entre los dos principales proyecto). Comprometerse sería un problema, ya que podría
miembros del equipo del proyecto. Es evidente que estos con-
conducir a diluir los entregables 2. a—Las demás actividades pue-
flictos se basan en interpretaciones diferentes del alcance del
den dar como resultado el desarrollo del equipo; 3. b—Debido
proyecto. ¿Qué enfoque de resolución de conflictos sería el
a que el gerente de proyectos hace énfasis en aspectos comu-
más útil para el gerente de proyectos?
nes y en trabajar juntos, esto se considera un método de reso-
a. Compromiso
lución de conflictos a través del apaciguamiento del conflicto;
b. Retirada
4. c—Se exhiben claramente las conductas que están asociadas
c. Castigo
con adaptación; 5. d—El horario de trabajo flexible no tiene
d. Resolución de problemas
efecto en la disposición de personal para trabajar en cooperación
2. ¿Cuál de los siguientes no es un ejemplo de una estrategia con los miembros de otros departamentos.
de desarrollo del equipo?
Notas 223

Notas
1. “Methods that have been tried to stop the leaking oil time predictable transitions in task groups.” Academy of
well.” (2010, 17 de agosto). www.nytimes.com/interac- Management Journal, 32: 274–309.
tive/2010/05/25/us/20100525-topkill-diagram.html?re- 12. Pinto, M. B. (1988). Cross-functional cooperation in the imple-
f=us;Robertson, C., and Krauss, C. (2010, 2 de agosto). “Gulf mentation of marketing decisions: The effects of superordinate
spill is the largest of its kind, scientists say,” New York Times, goals, rules and procedures, and physical environment. Tesis
www.nytimes.com/2010/08/03/us/03spill.html?_r=1&fta=y;- doctoral sin publicar, University of Pittsburgh, PA; Pinto, M.
Brenner, N., Guegel, A., Hwee, T., and Pitt, A. (2010, 22 de B., Pinto, J. K., and Prescott, J. E. (1993).“Antecedents and
abril). “Coast Guard confirms Horizon sinks.” www.upstrea- consequences of project team cross functional cooperation,”
monline.com/live/article212769.ece; Eley, T. (2010).“What Management Science, 39: 1281–97.
caused the explosion on the Deepwater Horizon?”www. 13. Sherif, M. (1958). “Superordinate goals in the reduction of
wsws.org/articles/2010/may2010/spil-m14.shtml;Langford, intergroup conflict,” American Journal of Sociology, 63(4):
M. (2010, 22 de julio). “Rig workers raised safety fears be- 349–56.
fore blast.” http://news.sky.com/skynews/Home/Business/ 14. Galbraith, J. R. (1977). Organization Design. Reading, MA:
Gulf-Of-Mexico-Oil-Disaster-Transocean-Reports- Addison-Wesley.
Highlight-Workers-Concerns-Over-Deepwater-Horizon/ 15. Davis, T. E. (1984). “The influence of the physical environment
Article/201007415669165. in offices,” Academy of Management Review, 9(2): 271–83.
2. Verma, V. K. (1996). Human Resource Skills for the 16. Frame, J. D. (2002). The New Project Management, 2nd ed.
Project Manager. Upper Darby, PA: Project Management San Francisco, CA: Jossey-Bass.
Institute;Verma, V. K. (1997). Managing the Project Team. 17. Tjosvold, D. (1993). Teamwork for Customers: Building
Newtown Square, PA: Project Management Institute. Organizations That Take Pride in Serving. San Francisco, CA:
3. Hoegl, M., and Parboteeah, K. P. (2003). “Goal setting and Jossey-Bass; Logue, A. C. (2002). “Building and keeping the
team performance in innovative projects: On the moderating dream team,” PM Network, 16(3): 30–36.
role of teamwork quality,” Small Group Research, 34:3–19; 18. Adams, J. R., and Adams, L. L. (1997). “The virtual projects:
Mc Comb, S. A., and Green, S. G. (1999). “Project goals, Management of tomorrow’s team today,” PMNetwork,11(1):
team performance, and shared understanding,” Engineering 37–41; Kostner, J. (1994). Knights of the Tele-Round Table. New
Management Journal, 11(3). York: Warner Books; Delisle, C. (2001). Success and commu-
4. Pinto, J. K., and Prescott, J. E. (1988). “Variations in criti- nication in virtual project teams. Tesis doctoral sin publicar.
cal success factors over the stages in the project life cycle, Dept. of Civil Engineering, Project Management Specialization.
“Journal of Management, 14(1): 5–18. University of Calgary,Calgary, Alberta; Fagerhaug, T. (2002).
5. Hartman, F. T. (2000). Don’t Park Your Brain Outside: A “Virtual project organizations—design of and challenges for,” in
Practical Guide to Improving Shareholder Value Through Slevin, D. P.,Pinto, J. K., and Cleland, D. I. (Eds.), Proceedings of
SMART Management. Newtown Square, PA: Project PMI Research Conference 2002. Newtown Square, PA: Project
Management Institute; Karlsen, J. T., Grae, K., and Massaoud, Management Institute, pp. 217–23.
M. J. (2008). “The role of trust in project-stakeholder relations- 19. Coutu, D. L. (1998). “Organization: Trust in virtual teams,”
hips: A study of a construction project,” International Journal Harvard Business Review, 76(3): 20–21.
of Project Organization and Management, 1: 105–118; Lander, 20. Lanier, J. (2001, abril). “Virtually there: Three dimensio-
M. C., Purvis, R. L., McCray, G. E., and Leigh, W. (2004). nal tele-immersion may eventually bring the world to your
“Trust-building mechanisms utilized in outsourced IS develo- desk,” Scientific American, 284(4): 66–75.
pment projects: A case study,” Information and Management, 21. Ditlea, S. (2001, enero).“Tele-immersion: Tomorrow’s tele-
41: 509–28; Kadefors, A. (2004). “Trust in project relations- conferencing,” Computer Graphics World, www.cgw.com;
hips—inside the black box,” International Journal of Project (2008). tele-immersion.citris-uc.org/video.
Management, 22: 175–82; Smyth, H. J., and Thompson, N. J. 22. Posner, B. Z. (1986). “What’s all the fighting about? Conflicts
(2005). “Managing conditions oftrust within a framework of in project management,” IEEE Transactions on Engineering
trust,” Journal of Construction Procurement, 11(1): 4–18. Management, EM-33: 207–11; Thamhain, H. J., and Wilemon,
6. Hartman, F. T. (2002). “Update on trust: A collection of D. L. (1975). “Conflict management in project life cycles,
trust-based research findings,” in Slevin, D. P., Pinto, J. ”Sloan Management Review, 16(3): 31–50; Thamhain, H. J.,
K.,and Cleland, D. I. (Eds.), Proceedings of the PMI Research and Wilemon, D. L. (1977). “Leadership, conflict, and program
Conference 2002. Newtown Square, PA: Project Management management effectiveness,” Sloan Management Review,19(1):
Institute, pp. 247–53. 69–89; Chan, M. (1989). “Intergroup conflict and conflict ma-
7. Gido, J., and Clements, J. P. (2003). Successful Project nagement in the R&D divisions of four aerospaceEM-36: 95–
Management, 2nd ed. Mason, OH: South-Western. 104; Adams, J. R., and Barndt, S. E. (1988).“Behavioral impli-
8. Tuchman, B. W., and Jensen, M. A. (1977). “Stages in small cations of the project life cycle,” in Cleland, D. I., and King, W.
group development revisited.” Group and Organizational R. (Eds.), Project Management Handbook,2nd ed. New York:
Studies, 2: 419–27. Van Nostrand Reinhold, pp. 206–30.
9. Tuchman and Jensen, ibid. 23. Thomas, K. W., and Schmidt, W. H. (1976). “A survey of
10. Verma, V. K. (1997). Managing the Project Team, p. 71, as cited. managerial interests with respect to conflict,” Academy of
11. Gersick, C. (1988). “Time and transition in work teams: Management Journal, 10: 315–18.
Toward a new model of group development.” Academy of 24. Thomas, K. W. (1992). “Conflict and negotiation processes
Management Journal, 31: 9–41; Gersick, C. (1989). “Making in organizations,” in Dunnette, M. D. (Ed.), Handbook of
224 Capítulo 6  •  Conformación del equipo del proyecto, conflicto y negociación

Industrial and Organizational Psychology, 2nd ed. Palo Alto, 29. Verma, V. K. (1998), como se cita en la nota 26.
CA: Consulting Psychologists Press, pp. 889–935; Pondy, 30. Ware, J. (1983). “Some aspect of problem-solving and con-
L. (1968). “Organizational conflict: Concepts and models,” flict resolution in management groups,” in Schlesinger, L. A.,
Administrative Science Quarterly, 12: 296–320. Eccles, R. G., and Gabarro, J. L. (Eds.), Managing Behavior
25. Thamhain, H. J., and Wilemon, D. L. (1975), como se cita en la in Organization: Text, Cases, Readings. New York: McGraw-
nota 22. Hill, pp. 101–15.
26. Verma, V. K. (1998). “Conflict management,” in Pinto,J. 31. Slevin, D. P. (1989). The Whole Manager. New York:
K. (Ed.), The Project Management Institute’s Project AMACOM.
Management Handbook. San Francisco, CA: Jossey-Bass. 32. Fisher, R., and Ury, W. (1981). Getting to Yes: Negotiating
27. Verma, V. K. (1996), como se cita en la nota 2; Robbins, S. P. Agreement Without Giving In. New York: Houghton Mifflin.
(1974).Managing Organizational Conflict: A Nontraditional 33. Fisher, R. and Ury, W. (1981), ibid.
Approach. Englewood Cliffs, NJ: Prentice-Hall. 34. Fisher, R. and Ury, W. (1981), ibid.
28. Thamhain, H. J., and Wilemon, D. L. (1975), como se cita en 35. Fisher, R. and Ury, W. (1981), ibid.
la nota 22; Posner, B. Z. (1986), como se cita en la nota 22.
CAPÍTULO

7
Gerencia del riesgo

Contenido del capítulo


PERFIL DE PROYECTO 7.2 GERENCIA DE LOS RIESGOS DEL PROYECTO:
Ayuda en el terremoto de Haití UN ENFOQUE INTEGRADO
INTRODUCCIÓN Resumen
GERENTES DE PROYECTOS EN LA PRÁCTICA Términos clave
Mohammed Al-Sadiq, de Saudi Aramco Oil Company Problema resuelto
Preguntas para discusión
7.1 GERENCIA DEL RIESGO:
Problemas
UN PROCESO DE CUATRO ETAPAS
Estudio de caso 7.1 Caso clásico: la caída del Comet de
Identificación del riesgo
 Havilland
Análisis de probabilidad y de consecuencias
Estudio de caso 7.2 Caso clásico: el puente colgante de Tacoma
Estrategias de mitigación de riesgo
 Narrows
Uso de reservas para las contingencias
Ejercicios en internet
Otras estrategias de mitigación
Preguntas de ejemplo del examen para la certificación PMP®
Control y documentación
Proyecto integrado. Evaluación de los riesgos del proyecto
PERFIL DE PROYECTO Notas
Colapso de un edificio de apartamentos en Shanghái

Objetivos de aprendizaje
Al terminar el capítulo, el estudiante estará en capacidad de:
1. Definir los riesgos del proyecto.
2. Reconocer las cuatro etapas claves en la gerencia de los riesgos del proyecto y los pasos necesarios para
gerenciar el riesgo.
3. Comprender las cinco principales causas de los riesgos del proyecto y los cuatro enfoques principales en la
identificación de riesgos.
4. Reconocer las cuatro estrategias principales para la mitigación de los riesgos.
5. Explicar el proceso de análisis y gerencia de riesgos del proyecto (Project Risk Analysis and Management: PRAM).

CONCEPTOS BÁSICOS DE LOS FUNDAMENTOS PARA LA GERENCIA DE PROYECTOS


(PROJECT MANAGEMENT BODY OF KNOWLEDGE, PMBOK® GUIDE, 5A. EDICIÓN) CUBIERTOS
EN ESTE CAPÍTULO
1. Plan de gerencia de riesgos (PMBOK®, sección 11.1)
2. Identificación de los riesgos (PMBOK®, sección 11.2)
3. Análisis cualitativo de los riesgos (PMBOK®, sección 11.3)
225
226 Capítulo 7  •  Gerencia del riesgo

4. Análisis cuantitativo de los riesgos (PMBOK®, sección 11.4)


5. Plan de respuesta a los riesgos (PMBOK®, sección 11.5)
6. Monitoreo y control de los riesgos (PMBOK®, sección 11.6)

PERFIL DE PROYECTO

Caso—Ayuda en el terremoto de Haití


En este momento, nuestro objetivo no es escapar de la pobreza, es escapar de la miseria para que
podamos volver a la pobreza.
—Jean-Max Bellerive,
primer ministro de Haití

Haití, el país más pobre del hemisferio occidental, durante su existencia como país independiente ha tenido miseria y
pobreza generalizadas. Con una democracia inestable, Haití ha padecido una serie de problemas endémicos antes y
después del derrocamiento de la dictadura de Duvalier en 1986. Como si fuera poco, el país fue golpeado por un terre-
moto de magnitud 7.0 en la escala Richter justo antes de las 5 p.m. del 12 de enero de 2010. El terremoto causó, inme-
diatamente, daños extensos y, en muchos casos, catastróficos a edificios e infraestructura, ubicados principalmente en
la capital, Puerto Príncipe, y en su periferia. Puerto Príncipe es el área más densamente poblada de Haití, donde millo-
nes de persones viven en condiciones precarias, en construcciones con servicios públicos y sistemas sanitarios deficientes
. En pocas palabras, un terremoto en el hemisferio occidental no podría haber encontrado un blanco más vulnerable
para golpear. Los esfuerzos de ayuda inmediata se obstaculizaron por dos réplicas que se produjeron casi inmediata-
mente después del primer sismo, con una tercera réplica de una magnitud de 6.1 ocurrida al día siguiente.
Se cree que la serie de terremotos provocaron la muerte de más de 230,000 personas y dejaron a más de 1.5
millones de personas sin hogar. Los estimativos establecen que más de 300,000 personas resultaron heridas en el
desastre y requirieron atención médica inmediata. Las Organización de Naciones Unidas (ONU) estima que los terre-
motos afectaron entre 2.8 y 3.5 millones de personas en el país. Sin importar el número exacto de víctimas de la catás-
trofe, un país con recursos tan limitados como Haití simplemente no podía enfrentar los esfuerzos de socorro que
se necesitaban. Solo en la región de Puerto Príncipe, se estima, más de 3 millones de personas vivían en una zona en
la que la infraestructura solamente podría apoyar a menos de 400,000. Además, más de 250,000 casas particulares y
30,000 edificios comerciales se derrumbaron o quedaron inhabitables. La prioridad era rescatar a las personas atrapa-
das en los edificios colapsados. Permanecimos diez días con brigadas del ejército haitiano en la búsqueda y rescate de
Design Pics Inc. - RM Content / Alamy

FIGURA 7.1  Desastre en Puerto Príncipe


Perfil de proyecto 227

las víctimas atrapadas bajo los escombros de los edificios derrumbados. Mientras tanto, en apenas cuatro días desde
la catástrofe, en toda la región prácticamente se habían agotado los suministros de supervivencia, como alimentos,
agua, medicinas y refugio. A pesar de los esfuerzos desesperados del ejército y de las agencias civiles, simplemente
Haití carecía de los medios necesarios para responder a los estragos producidos por el terremoto.
Las operaciones de socorro de la ONU, junto a los esfuerzos adicionales de otros países actuaron rápida-
mente. Pocas horas después del primer terremoto, Estados Unidos y otros países enviaron a Haití suministros de
emergencia como alimentos, agua, refugio temporal y medicinas, y efectivamente se encargaron del aeropuerto
y de las instalaciones circundantes, a fin de coordinar mejor el proyecto de ayuda. Rápidamente se evidenció que
el medio más efectivo para gerenciar la ayuda era pasar por encima de las autoridades de Haití o trabajar con
ellos en funciones secundarias de soporte. La falta de infraestructura desarrollada en el país, y especialmente en
la región de Puerto Príncipe, generaron grandes cuellos de botella que retrasaron, al comienzo, la distribución
de suministros a las personas afectadas. La lista de problemas que requerían atención inmediata era alarmante:
1. Puerto Príncipe estaba inundado de refugiados y bloqueado con edificios colapsados, lo cual obligó el envío
de la ayuda a través de la costa norte, para luego enviar los suministros desde allí a la capital.
2. Las vías estaban cerradas debido a los escombros y deslizamientos de tierra y tuvieron que despejarse para facilitar
el transporte de la ayuda. En algunas áreas, las carreteras permanecieron cerradas diez días después del terremoto.
3. Las líneas telefónicas fijas y de celular se interrumpieron total o parcialmente.
4. Las instalaciones de la morgue de Puerto Príncipe estaban completamente saturadas. Miles de muertos simple-
mente se ponían al aire libre durante un tiempo prolongado, lo cual favorecía la propagación de enfermedades,
antes de enterrarlos en fosas comunes.
5. Las agencias gubernamentales y civiles, incluida la policía, sencillamente permanecían cerradas, lo cual per-
mitía los saqueos y la violencia callejera.
Un “primer paso” clave en los esfuerzos de ayuda era proporcionar refugio a la población de la región. El terre-
moto averió severamente un gran porcentaje de los edificios, por lo que era peligroso utilizar la mayoría de construccio-
nes existentes. Además, la ONU señalaba que Haití era “altamente vulnerable” a una variedad de amenazas ambientales,
como inundaciones, deslizamientos de tierra, tormentas y huracanes. Estas amenazas exigían conseguir refugio temporal
para las personas, inmediatamente. Se estableció una serie de campamentos de refugiados alrededor de la capital, y las
personas sin hogar se trasladaron a estos lugares. El informe trimestral de progreso de la Cruz Roja de Estados Unidos,
a principios de abril, afirmó que la provisión de refugio había sido “una de las operaciones más rápidas de los últimos
años”, en tanto que se habían establecido refugios para 1.3 millones de personas sin hogar en Haití. A pesar del comienzo
encomiable de la operación de refugio, aún quedan unos 300,000 ciudadanos sin vivienda o refugio.
A pesar de que los esfuerzos internacionales de socorro se organizaron rápidamente, el proyecto de ayuda humani-
taria de Haití no fluyó, y tropezó con algunas deficiencias debido a una mala planeación y evaluación inicial de los riesgos.
Por ejemplo, mientras llegaban rápidamente suministros y personal de socorro de varios países, la administración central
de estos miles de voluntarios y toneladas de suministros era deficiente. El aeropuerto de Puerto Príncipe se sobrecargó
por el número de vuelos diarios dentro y fuera de la región, y los puertos locales simplemente no podían dar cabida a la
cantidad de buques que trataban de descargar en los muelles. Estos cuellos de botella ocasionaron retrasos en la distri-
bución de suministros y provocaron disturbios por turbas enfurecidas en diferentes campamentos de refugiados. Faltó
seguridad en los lugares de almacenamiento de los suministros y rápidamente los saqueos se tornaron incontrolables.
También hubo una tendencia a aplicar las lecciones aprendidas en los últimos proyectos de ayuda humanita-
ria, a pesar de que los parámetros eran diferentes. Por ejemplo, organizaciones de asistencia humanitaria habían
creado y enviado “sofisticados hospitales prefabricados” a Haití, con base en los requisitos médicos previstos para
la labor de ayuda del tsunami del sur de Asia. Infortunadamente, muchos de los suministros y del personal médico
que acompañaba esos hospitales prefabricados no estaban equipados para resolver las más comunes “lesiones por
aplastamiento” sufridas por la población haitiana.
Por último, la llegada del personal médico y de socorro de otros países no estaba coordinado. Docenas de
organizaciones no gubernamentales (ONG) establecieron sus propios campamentos, a menudo duplicando el tra-
bajo de los demás, debido a que no había un control central. El gobierno de Haití desempeñó un papel mínimo
en el intento de coordinar estos esfuerzos, pues este se paralizó en razón de la magnitud de la catástrofe. Como
un reportero comentaba, respecto al presidente de Haití y sus principales asesores: “El presidente sigue dirigiendo
reuniones de coordinación bajo un árbol de mango.”
Las consecuencias de la catástrofe del terremoto de Haití dejaron una gran oportunidad para cuestionar y criticar
los elementos de las labores de rescate. Sin embargo, no se puede negar que la respuesta internacional al terremoto fue
inmediata, generosa y amplia. Los desastres, por definición, no les avisan a los organismos de socorro para preparar sus
respuestas, y, en cambio, los obliga a depender de la evaluación de los riesgos, de la planeación previa y de la voluntad
de aprender todas las lecciones, tanto de los éxitos como de los fracasos, de las labores anteriores. El proyecto de ayuda a
Haití se ejecutó con muchos problemas, pero, a pesar de estas fallas, se destacó por un altruismo que impulsaba a la gente
a trabajar incansablemente para aliviar el sufrimiento de millones de residentes de la isla, afectados por la catástrofe.1
228 Capítulo 7  •  Gerencia del riesgo

INTRODUCCIÓN
Hace más de una década, apareció en televisión una serie de comerciales para los filtros de aceite FRAM. El
tema de cada uno de estos anuncios era esencialmente el mismo: el mantenimiento del motor en forma razo-
nablemente regular, con filtros de aceite (preferiblemente FRAM), evitaría daños graves a largo plazo y altos
costos de reparación del motor más adelante. El lema popularizado de FRAM en estos anuncios fue: “Usted
puede pagarme ahora o pagar más después.” La gerencia de riesgos del proyecto sigue una lógica similar. En
la determinación de los riesgos relevantes y la formulación de estrategias proactivas para su mitigación, el
equipo del proyecto puede pagar un poco más en términos de tiempo extra y costos iníciales o debe prepa-
rarse para pagar cantidades potencialmente exorbitantes de tiempo y dinero en el futuro.
Los proyectos operan en un entorno lleno de incertidumbre. Hay incertidumbre sobre la financiación del
proyecto, disponibilidad de los recursos necesarios o problemas técnicos; la lista es interminable. Esta incertidumbre
es la base de los riesgos del proyecto y de la necesidad de participar en la gerencia del riesgo. La gerencia del riesgo,
que reconoce la capacidad de un proyecto para ejecutarse con problemas, se define como el arte y la ciencia de iden-
tificar, analizar y dar respuesta a los factores de riesgo a lo largo de la vida de un proyecto, manteniendo el mejor
interés en el logro de sus objetivos. La diferencia entre los proyectos que fracasan y los que, en últimas, son exitosos
no tiene nada que ver con el hecho de que unos carezcan de los problemas que otro tiene. La clave está en los pla-
nes para enfrentar los problemas una vez estos se presentan. El riesgo del proyecto puede definirse simplemente
como cualquier evento que pueda afectar negativamente la viabilidad de un proyecto. Wideman2 define el riesgo del
proyecto como “un estimativo de la probabilidad de pérdida generada por una gran cantidad de circunstancias no
deseadas.” En estas definiciones se reconoce que pueden presentarse muchos eventos, tanto dentro como fuera del
control de la organización, para frustrar nuestros mejores esfuerzos para completar con éxito los proyectos.
La gerencia del riesgo consiste en anticipar, al comienzo del proyecto, el surgimiento de situaciones inespe-
radas más allá del control del gerente de proyectos. Estas situaciones socavan gravemente el éxito de un proyecto.
En términos generales, para el gerente, el proceso de gerencia de riesgos incluye las siguientes preguntas:
• ¿Qué es probable que suceda (la probabilidad y el efecto)?
• ¿Qué se puede hacer para minimizar la probabilidad o el efecto negativo de estos eventos?
• ¿Qué señales indicarán la necesidad de tal acción? (Es decir, ¿qué pistas debo buscar activamente?)
• ¿Cuáles son los posibles resultados de estos problemas y cómo debo reaccionar anticipadamente?
En este capítulo se analizará la gerencia de riesgos de los proyectos. Vamos a abordar algunas de las principales
fuentes de incertidumbre, y por tanto de riesgo, en los proyectos. También, se proporcionará información sobre
la identificación de los pasos claves para tener en cuenta en la formulación de los procesos de gerencia de riesgos
de los proyectos, métodos de evaluación de efecto de los riesgos y los procesos para mitigar los efectos negativos.
El riesgo del proyecto se basa en una ecuación simple:

Riesgo = (probabilidad de evento) (consecuencia del evento)

En otras palabras, todos los riesgos se deben evaluar en función de dos elementos distintivos: la probabilidad de
que el evento se produzca y las consecuencias o el efecto de su ocurrencia. El riesgo de que un gerente de proyec-
tos en su empresa sea alcanzado por un rayo en el camino al trabajo, constituiría claramente una importancia
alta para el proyecto, pero la probabilidad de que esto ocurra es baja para minimizar la preocupación por ello.
Por otro lado, la gente cambia de trabajo; así, un evento como la pérdida de un miembro importante del equipo
de proyectos a mitad de camino de la fase de desarrollo puede tener tanto un efecto potencialmente grave como
un alto grado de probabilidad, en algunas organizaciones. Por tanto, en estos ambientes de proyectos, conven-
dría desarrollar estrategias de mitigación para enfrentar este riesgo, dada su alta probabilidad de ocurrencia y
las consecuencias negativas que podría generar. Por ejemplo, el gerente de proyectos podría proponer un bono
u otro programa de incentivos para premiar al personal que permanezca en el equipo del proyecto, como una
respuesta útil (reducción del riesgo) a la posible pérdida de personal clave durante el proyecto.
Riesgos y oportunidades son lados opuestos de la misma moneda: la oportunidad surge de las circunstancias
favorables del proyecto y el riesgo de eventos adversos. La figura 7.2 ilustra la dinámica del riesgo y de la oportunidad
durante el ciclo de vida del proyecto, en comparación con la gravedad de las consecuencias negativas. A principios
de la vida de un proyecto, el riesgo y la oportunidad son altos. El concepto puede considerarse valioso y las oportu-
nidades son fuertes, tanto como los riesgos. Este resultado se debe a la incertidumbre básica a principios del ciclo de
vida de un proyecto. Hasta que avancemos en las fases de desarrollo, muchas preguntas siguen sin respuesta, sumán-
dose a la incertidumbre general del proyecto. Por otra parte, la gravedad de las consecuencias negativas (“cantidad
Introducción 229

Ciclo de vida total del proyecto


Tiempo

PLAN PRODUCCIÓN

Mayor Mayor Mayor Mayor


Fase 1 Fase 2 Fase 3 Fase 4
Concepción Desarrollo Ejecución Finalización
(C) (D) (E) (F)

Oportunidad y Periodo de
riesgo mayor
Aumento de riesgo

efecto del riesgo

Valor en dólares
do
ina
b
c om
o
sg
rie
del
acto
I mp
juego
Monto en

FIGURA 7.2  Riesgos versus monto en juego: el desafío de la gerencia de riesgos


Fuente: R. Max Wideman. (2004). A Management Framework for Project, Program and
Portfolio Integration. Victoria, BC, Canada, 2004. Copyright © 2004 by R. Max Wideman,
AEW Services Vancouver, BC, Canada: Trafford Publishing. Figura de la página 64.
Reproducido con permiso de R. Max Wideman.

en peligro”) es mínima al comienzo de la vida del proyecto. Aún no se han comprometido muchos recursos en el
proyecto, por lo que el nivel de exposición de la compañía sigue siendo muy bajo. A medida que el proyecto avanza
y más dinero del presupuesto se compromete, el potencial global de consecuencias negativas asciende de forma dra-
mática. Sin embargo, al mismo tiempo, el riesgo disminuye. El proyecto adopta una forma más concreta y muchas
de las preguntas previas sin respuesta (“¿Funcionará la tecnología?” “¿El desarrollo será viable de acuerdo con la
línea de tiempo?”) se despejan. El resultado es una circunstancia en la cual la oportunidad y el riesgo general (defi-
nido por la incertidumbre) disminuyen mientras el monto que la compañía tiene en juego en el proyecto aumenta.
Los periodos de mayor preocupación, mostrados en la figura 7.2, se registran en las fases ejecución y
finalización, considerando que la incertidumbre sigue siendo relativamente alta y el monto en juego aumenta
rápidamente. La meta de la estrategia de gerencia de riesgos es reducir al mínimo la exposición de la compa-
ñía a esta combinación indeseable de incertidumbre y posibilidad de consecuencias negativas.

RECUADRO 7.1

GERENTES DE PROYECTOS EN LA PRÁCTICA


Mohammed Al-Sadiq, de Saudi Aramco Oil Company
Para aquellos que buscan un trabajo duro pero único, oportunidades para resolver problemas, desafíos
y oportunidades de lograr grandes cosas, consideren una carrera en gerencia de proyectos.
­—Mohammed Al-Sadiq

Mohammed Al-Sadiq es licenciado en ingeniería de la King Fahd University of Petroleum & Minerals, en
Dhahran, Arabia Saudita. Vive y trabaja en la provincia oriental de Arabia Saudita, donde se localiza la Saudi
Aramco Oil Company. “Estoy trabajando como ingeniero de proyectos de la Offshore Project division de Saudi
Aramco”, dice, al describir su posición. “Como ingeniero de proyectos, estoy involucrado en la planeación
(continúa)
230 Capítulo 7  •  Gerencia del riesgo

FIGURA 7.3  Mohammed Al-Sadiq de Saudi Aramco

de proyectos futuros. Después de que se aprueba un proyecto mar adentro, empiezo a trabajar en el diseño,
fabricación, instalación y puesta en marcha de las instalaciones en alta mar, con un contratista especializado.”
Al-Sadiq continúa describiendo su compañía: “Nuestra división es responsable de todos los proyectos de
petróleo y gas que se realizan en aguas de Arabia Saudita (sobre todo en el golfo Pérsico). Los proyectos varían
desde pequeñas actualizaciones de sistemas de control en las instalaciones en alta mar hasta la construcción
de nuevas grandes plataformas, oleoductos submarinos y sistemas de cable submarino de alta tensión.”
Antes de graduarse de la universidad, Al-Sadiq recibió una beca y una oferta de empleo de Saudi Aramco.
Después de su graduación, ingresó en un programa de desarrollo profesional de tres años con el fin de pre-
pararse en ingeniería y gerencia de proyectos. La empresa cuenta con una unidad de negocios en gerencia de
proyectos dedicada (encabezada por el vicepresidente de gerencia de proyectos) a ejecutar todos sus proyectos.
Dos de los proyectos más recientes de Al-Sadiq se encuentran entre los más grandes en la historia de
Saudi Aramco. Esto es lo que Al-Sadiq dice acerca de sus proyectos y sobre la gerencia del proyecto:
Yo era parte de un equipo de cinco miembros de ingenieros de gerencia para este proyecto. El
proyecto consistió en la instalación de un “tanque-plataforma”: una nueva plataforma central
para recoger el petróleo crudo desde varias plataformas de perforación y reenviarlo a una planta
en tierra. También tuvimos que mejorar las plataformas existentes de la boca del pozo e instalar
nuevas tuberías submarinas y cables de alta tensión. El ciclo de vida del proyecto llevó alrededor de
36 meses desde su aprobación por la junta hasta su finalización, con un presupuesto de 500 millo-
nes de dólares. Estos 36 meses son muy ajustados para proyectos en alta mar, teniendo en cuenta
todas las dificultades y demoras causadas por las condiciones climáticas que se enfrentan en alta
mar. El proyecto era clave porque el proceso de modernización y de conexión a las instalaciones
de producción existentes significaba que las paradas de producción de petróleo serían observadas
por todo el mundo. Completamos este proyecto en el 2007.
Mi proyecto actual es uno similar, aunque más grande, que implicará la instalación de la
plataforma submarina más grande, de la Saudi Aramco, y se utilizará por primera vez, en aguas de
Arabia Saudita, una técnica de montaje diferente. El proyecto se encuentra actualmente en la fase
de propuesta y estimación de costos, con un presupuesto previsto de 1,200 millones de dólares,
con finalización a mediados del 2013.
Esos proyectos mar adentro proporcionan la infraestructura necesaria para que Saudi Aram-
co pueda aumentar su producción y, por tanto, logre satisfacer la creciente demanda de petróleo
de los países industrializados y de los del mundo en desarrollo. Estos son vigilados de cerca por la
gerencia ejecutiva de la empresa, así como por funcionarios del gobierno, con el fin de asegurarse
de que el Reino de Arabia Saudita es capaz de suministrar el petróleo que el mundo requiere.
Antes de unirme al equipo de gerencia de proyectos de Saudi Aramco, apenas entendía
la idea de la gerencia de proyectos. Siempre pensé que iba a terminar sentado detrás de un es-
critorio trabajando en los planos de ingeniería, especificaciones o en el desarrollo de soluciones
7.1  Gerencia del riesgo: un proceso de cuatro etapas 231

novedosas a problemas. Ahora, puedo afirmar que la gerencia de proyectos es un desafío más
grande. La belleza de la gerencia de proyectos está en que contiene todos los elementos y retos
de otros trabajos organizacionales. Se trata de la búsqueda de soluciones de ingeniería, gerencia
de recursos humanos y no humanos, gerencia de costos, desarrollo de estrategias de relaciones
públicas y estar en puntos claves las 24 horas del día. Es un trabajo no rutinario, incluso si usted
está trabajando en proyectos similares, le puedo garantizar que no hay dos proyectos iguales.
En gerencia de proyectos, usted puede ver cosas que se hacen de la nada. Se inicia el proyec-
to con una idea y luego se trabaja hasta llegar a hacerla realidad. Por ejemplo, aquí en proyectos
marítimos, podemos ver nuestras plataformas e instalaciones desde el día en que solo eran bocetos
y trabajar con estos hasta que, literalmente, están produciendo petróleo en el agua. En otras pala-
bras, la gerencia de proyectos hace que estas ideas se materialicen.

7.1  GERENCIA DEL RIESGO: UN PROCESO DE CUATRO ETAPAS


La gerencia sistemática de riesgos comprende cuatro etapas distintas:
• Identificación del riesgo—el proceso de determinar los factores de riesgo específicos que razonable-
mente pueden afectar su proyecto.
• Análisis de probabilidades y de consecuencias—el efecto potencial de estos factores de riesgo está deter-
minado por la probabilidad de que ocurran y por el efecto que tendrían sobre el proyecto si se presentaran.
• Estrategias de mitigación de riesgo—las medidas adoptadas para minimizar el efecto potencial de los
factores de riesgo que se consideran suficientemente peligrosas para el proyecto.
• Control y documentación—la creación de una base de conocimiento para futuros proyectos basados
en las lecciones aprendidas.

Identificación del riesgo


Un método útil para desarrollar una estrategia de identificación de riesgos comienza por generar un sistema
de clasificación para los riesgos probables. Comúnmente, los riesgos caen en uno o más de los siguientes
grupos de clasificación:3
• Riesgo financiero—El riesgo financiero se refiere a la exposición financiera de la empresa a la hora
de desarrollar un proyecto. Si se requiere una gran inversión de capital inicial, como en el caso del
desarrollo de una nueva estructura aeronáutica en Boeing o en Airbus Industries, la compañía asume
voluntariamente, con en el proyecto, un riesgo financiero elevado. Las empresas de construcción que
edifican estructuras “sin especificaciones del cliente” son otro ejemplo. Sin un comprador contratado
antes de la construcción, estas empresas asumen un riesgo financiero significativo con la esperanza de
vender los espacios de oficina y el edificio, después de construido.
• Riesgo técnico—Cuando nuevos proyectos contienen elementos técnicos únicos o tecnología no
probada, aquellos se desarrollan con riesgos técnicos significativos. Naturalmente, hay grados en esos
riesgos. En algunos casos, el riesgo técnico es mínimo (modificaciones a un producto ya desarro-
llado); en otros, el riesgo técnico puede ser sustancial. Por ejemplo, TRW, ahora parte de Goodrich
Corporation, recientemente desarrolló una modificación a su sistema de elevador electrónico, usado
en polipastos de cable de helicópteros de rescate. Debido a que la empresa ya había desarrollado la
tecnología y ha venido aumentando la potencia del polipasto solo marginalmente, el riesgo técnico
se considera mínimo. Cuanto mayor sea el nivel de riesgo técnico, mayor es la posibilidad de que el
proyecto tenga un desempeño bajo en el cumplimiento de los requisitos de las especificaciones.
• Riesgo comercial—En los proyectos desarrollados para una rentabilidad definida (intención comercial), un
elemento desconocido constante es su grado de éxito comercial, una vez que se han introducido en el mer-
cado. El riesgo comercial es la incertidumbre que las empresas pueden aceptar voluntariamente, ya que es
casi imposible predecir con exactitud el grado de aceptación del cliente para un nuevo producto o servicio.
• Riesgo de ejecución—¿Cuáles son las incógnitas específicas relacionadas con la ejecución del plan del
proyecto? Por ejemplo, usted puede preguntarse si las condiciones geográficas o físicas podrían desem-
peñar un papel que afecte al proyecto. Por ejemplo, el desarrollo de una planta de energía en las laderas
del Monte Pinatubo (un volcán activo) en Filipinas, ¡implicaría serios riesgos de ejecución! Del mismo
232 Capítulo 7  •  Gerencia del riesgo

modo, personal del equipo del proyecto mal entrenado o insuficiente puede restringir la ejecución del
proyecto. El riesgo de ejecución es una categoría amplia que evalúa las circunstancias únicas o inciertas
que podrían tener un efecto negativo en la ejecución del plan.
• Riesgo legal o contractual—Este tipo de riesgo suele ser consistente con proyectos en los cuales se
elaboran de antemano términos y condiciones estrictos. Muchos términos contratados (por ejemplo,
margen fijo, costos fijos, daños y perjuicios) ponen en riesgo el proyecto, en un grado significativo.
Naturalmente, las empresas tratan de limitar su exposición legal por medio de la protección legal, pero
a veces es imposible pasar el riesgo contractual a las otras partes. Por ejemplo, la mayoría de los ferro-
carriles de Estados Unidos no van a aceptar cláusulas de penalización por retrasos en las entregas de los
componentes, porque tienen un control casi monopólico del mercado. Por tanto, las organizaciones
que utilizan el transporte ferroviario deben aceptar todos los riesgos de suministro para ellos mismos.
Después de entender las categorías generales de riesgo, usted desearía anticipar algunas de las formas más
comunes de riesgo en los proyectos. La siguiente lista, no exhaustiva, ofrece un conjunto de algunos de los
tipos más comunes de riesgos a que pueden exponerse la mayoría de los proyectos:
• Ausentismo
• Resignación
• Personal separado por la gerencia
• Personal adicional/habilidades no disponibles
• Capacitación no tan efectiva como se desea
• Especificaciones iniciales pobres o incompletas
• Se multiplican las órdenes de trabajo o de cambio debido a diversos problemas
• Mejoras que toman más tiempo de lo esperado

A pesar de que las categorías generales y los tipos comunes de riesgo de las listas anteriores son buenos
puntos de partida, también vale tener en cuenta los riesgos comunes, específicos de la industria en la que se
trabaja el proyecto. Se dispone de una serie de métodos, tanto cualitativos como cuantitativos, para identifi-
car los factores de riesgo específicos de la industria, que incluyen:

• Reuniones de lluvia de ideas —Reunir a los miembros del equipo del proyecto, la alta gerencia, incluso
a los clientes, para una lluvia de ideas puede generar una buena lista de posibles factores de riesgo. La
lluvia de ideas es una técnica cualitativa que genera ideas y no se centra en la toma de decisiones. Las
reuniones de intercambio de ideas deben estar libres de prejuicios, críticas a los puntos de vista de los
demás y presión para realizarse, si se quiere que sean efectivas. El trabajo es un miniescenario para la
gerencia de riesgos. Piense en esto: ¿estaría usted dispuesto a poner sus ideas más creativas sobre la
mesa, frente a otras diez personas, si estuviera en riesgo de ser criticado de inmediato? O si su jefe exige
que se presenten las ideas totalmente desarrolladas, ¿tendría usted la tentación de mantener una idea
para más adelante? En resumen, es necesario que el medio ambiente para la lluvia de ideas sea seguro.
• Opinión de expertos —Esta técnica se puede utilizar de dos maneras alternativas en la evaluación de los riesgos
del proyecto. El método más cuantificable, comúnmente conocido como el método Delphi, recoge y consolida
los juicios de encuestados anónimos aislados. Para que el Delphi se utilice efectivamente, se requiere algún aná-
lisis preliminar de los posibles contribuyentes. La “sabiduría” colectiva del grupo de expertos se utiliza entonces
como base para la toma de decisiones. El método más simple e intuitivo para el uso de juicios de expertos se
basa en el principio de que “la experiencia cuenta.” Usted simplemente identifica y consulta a personas den-
tro de la organización que han tenido experiencias similares en proyectos ejecutados o que han estado con la
empresa el tiempo suficiente para tener una clara comprensión de la mecánica del análisis de riesgo del pro-
yecto. Por obvio que parezca, esta oportunidad puede no ser clara para todos, sobre todo si ha habido cambios
recientes en la gerencia de la empresa o si los nuevos empleados no conocen la historia de esta.
• Historia—En muchos casos, la historia es la mejor fuente de información sobre los riesgos futuros. ¿La
empresa ha mantenido un cuadro persistente de problemas, al desarrollar sus proyectos a lo largo del
tiempo? ¿Se han detectado “señales de alerta” o acontecimientos que han precedido los problemas anterio-
res? La experiencia puede utilizarse para identificar no solo los factores de riesgo, sino también sus indicado-
res principales. El problema con la experiencia es que esta no es garantía de futuros eventos. Los problemas
o condiciones que contribuyeron al riesgo del proyecto en la última década, años, o incluso meses, pueden
ahora no ser relevantes en las condiciones actuales del mercado o en el estado de trabajo del proyecto que se
realiza. Por tanto, la historia puede ser útil para identificar los factores claves de riesgo del proyecto, siempre
y cuando se tenga un grado razonable de cautela a la hora de evaluar proyectos en curso, a través del portal
7.1  Gerencia del riesgo: un proceso de cuatro etapas 233

CUADRO 7.1  Variables comunes de riesgo6

Variable de riesgo Descripción


Riesgos de mercado Probabilidad de que el volumen previsto de ventas o el precio real para el nuevo proyecto
no se materialice o sea inferior a la previsión inicial
Riesgos políticos Expropiación, cambios legislativos o reglamentarios discriminatorios que regulan los códigos
de impuestos y leyes ambientales; disturbios políticos como movimientos civiles, huelgas,
guerras, acciones terroristas, pugnas religiosas
Riesgos técnicos Probabilidad de que el proyecto no alcance los estándares técnicos requeridos, fabrique
productos de calidad inferior o tenga costos de operación excesivos
Riesgos de financiación Probabilidad de que los ingresos del proyecto no sean suficientes para pagar las deudas y,
por tanto, no se pueda obtener una financiación apropiada para el proyecto
Riesgos de impacto ambiental Probabilidad de que el proyecto genere impactos ambientales adversos y sobrepase los
límites aceptables
Riesgo de costo Probabilidad de que las estimaciones de los costos hayan sido inexactas o demasiado optimis-
tas, lo cual dará lugar a la asignación de fondos insuficientes para completar el proyecto
Riesgo de programación Probabilidad de que el proyecto rebase su duración prevista
Riesgo de calidad (funcionalidad) Probabilidad de que el proyecto no pueda entregar los resultados esperados, o que estos no
funcionen adecuadamente o resulte en un consumo ineficiente de recursos
Riesgo gerencial Probabilidad de que los sistemas de control de gerencia y estructuras organizativas que se
han desarrollado y operan juntos en el proyecto no tengan un buen desempeño
Riesgo de integración Probabilidad de que los participantes del proyecto tales como patrocinador, promotor (o
(interesados) cliente) y operador no puedan trabajar en asociación
Actos de Dios Probabilidad de que se presenten eventos fuera del control del equipo de proyecto
Fuente: basado en A. Jaafari. (2001). “Management of risks, uncertainties and opportunities on projects: time for a fundamental shift,” International
Journal of Project Management, 19(2): 89–101, figura de la página 85. Derechos reservados © 2001; reproducido con permiso de Elsevier.

de acontecimientos pasados. Por ejemplo, Rauma Corporación de Finlandia desarrolló equipos de registro
de última generación que casi no requerían mantenimiento y que funcionaban bien en lugares con buena
infraestructura. Sin embargo, cuando intentó utilizar los equipos en regiones remotas de los bosques tropi-
cales de Indonesia, la compañía encontró que no había previsto algunos problemas de servicio y tuvo que
transportar las máquinas por aire a cientos de kilómetros de los bosques hasta los centros de servicio. La
experiencia no había preparado a la empresa para los nuevos riesgos.
• Evaluaciones múltiples (o basadas en el equipo)—Utilizar una sola fuente para identificar los ries-
gos del proyecto es un método muy arriesgado, debido al sesgo potencial desde el punto de vista de
una persona determinada.4 Tiene sentido que ningún individuo, independientemente de su grado de
experticia, puede discernir todas las fuentes de amenaza y riesgo del proyecto. Aunque es probable que
un ingeniero se sienta más identificado con los riesgos técnicos, un contador de costos con los riesgos
presupuestarios, y así sucesivamente, ni siquiera el gerente más experimentado, con experiencia en
muchos campos, lo sabe todo. Un enfoque basado en el equipo, para la identificación de los factores
de riesgo, fomenta la identificación de un conjunto más completo de posibles riesgos del proyecto. Al
mismo tiempo, un enfoque colaborativo ayuda a persuadir a los miembros del equipo medio conven-
cidos o no comprometidos a apoyar las metas del proyecto.5
Una vez que el proceso de análisis de los factores de riesgo se completa y se descubre una variedad de
circunstancias o fuentes de riesgo, se procede a llevar cabo una evaluación del efecto potencial del riesgo. El
cuadro 7.1 nombra y describe las variables comunes de riesgo.

Análisis de probabilidad y de impacto


El siguiente paso en el proceso consiste en contemplar una estimación razonable de la probabilidad de que cada
uno de estos eventos ocurra. Podemos construir una matriz de efecto del riesgo similar a la que se muestra en la
figura 7.4.7 La matriz refleja todos los riesgos del proyecto identificados, cada uno se prioriza de acuerdo con su
probabilidad de ocurrencia y con las consecuencias más graves posibles que podrían presentarse en el proyecto,
determinadas por el equipo del proyecto o por la organización patrocinadora. La probabilidad combinada con las
234 Capítulo 7  •  Gerencia del riesgo

Consecuencias
Baja Alta

Alta
Probabilidad
Baja

FIGURA 7.4  Matriz de efecto del riesgo

consecuencias proporciona una idea del efecto general del riesgo. Con este esquema de priorización, el equipo del
proyecto estará en capacidad de centrar su atención en los factores de más riesgo, según su incidencia en el proyecto.
La figura 7.5 muestra una matriz de efecto del riesgo utilizada en varias empresas de Fortune 500.Tenga
en cuenta que, en lugar de una clasificación de máximos y mínimos, esta alternativa cuenta con tres niveles:
alto, medio y bajo. Esta matriz se refina aún más mediante la clasificación de efecto del riesgo, ya sea como
grave, moderado o menor. La razón fundamental para el empleo de esta matriz más completa es generar una
priorización que permita enfrentar los diversos riesgos.
Después de que un equipo de proyectos ha trabajado y completado una matriz detallada, está mejor equi-
pado para reconocer los tipos de riesgos a los que se expone el proyecto y la “criticidad” de cada uno de los
riesgos, en términos de su efecto potencial sobre el rendimiento del proyecto. Evidentemente, los tipos de ries-
gos más relevantes para la planeación del proyecto son aquellos que el equipo clasifica con alta probabilidad de
ocurrencia (probabilidad) y alto potencial de perjudicar al proyecto (efecto negativo). Los riesgos que entran en
esta categoría requieren una planeación detallada de contingencia, con el fin de proteger adecuadamente el ciclo
de desarrollo del proyecto. La figura 7.5 muestra cómo pueden clasificarse los proyectos, en función de su efecto
potencial de riesgo. El equipo identifica en primer lugar los factores de riesgo y luego evalúa su efecto a través de
la matriz. Usted puede ver cómo se utiliza en este ejemplo el esquema de clasificación de alto-bajo-moderado.

Consecuencias
Baja Media Alta
Alta

D
Probabilidad
Media

B
Baja

C A

FIGURA 7.5  Clasificación de los riesgos del proyecto


7.1  Gerencia del riesgo: un proceso de cuatro etapas 235

Factor de riesgo Consecuencia Probabilidad Efecto potencial


A. Pérdida del programador Alta Baja Moderado
principal
B. Fracaso técnico Alta Media Serio
C. Recorte de presupuesto Media Baja Menor
D. Competidor primero en Alta Alta Serio
el mercado

El cuadro 7.2 muestra este método cuantitativo mediante un ejemplo de una empresa que desarrolla
un nuevo producto de software para el mercado minorista. El escenario toma en cuenta tanto la probabilidad
de fallo como sus consecuencias. En la probabilidad de fracaso, estamos interesados en la identificación de

CUADRO 7.2  Determinación de los riesgos probables y sus consecuencias

Probabilidad de fracaso (Pf)


Valoración Madurez Complejidad Dependencia
Baja (0.1) Software existente Diseño simple No se limita al sistema o a clientes existentes. No hay
eventos externos e incontrolables que probablemente
tengan un efecto en el proyecto.
Menor (0.3) Rediseño menor Leve aumento de la El cronograma o el resultado dependen del sistema exis-
 complejidad tente. El efecto en el precio o en el cronograma es de
menor importancia.
Moderada (0.5) Cambios mayores Incremento moderado Riesgo moderado en el cronograma o en el resultado de-
bido a la dependencia del sistema existente, instalación
o procesos. El efecto en el costo es moderado.
Significativa (0.7) La tecnología está Aumento significativo El cronograma o el rendimiento dependen de un nuevo
  disponible, pero el sistema o proceso. El riesgo sobre el costo o el crono-
  diseño es complejo grama es significativo.
Mayor (0.9) Estado del arte, inves- Extremadamente El cronograma y los resultados dependen del nuevo sistema
tigación completa complejo y proceso. Muy alto riesgo sobre el costo o el cronograma.
Consecuencias del fracaso (Cf)
Valoración Costo Cronograma Confiabilidad Desempeño
Baja (0.1) No se excede el Efecto insignificante Mínima o ninguna Ninguna o mínima
 presupuesto   sobre el programa,   consecuencia sobre   consecuencia sobre
  no hay efecto en la   la confiabilidad   el desempeño.
  ruta crítica
Menor (0.3) El presupuesto El cronograma se retrasa Pequeña reducción de Pequeña reducción en el
  estimado se supera  mínimamente   la confiabilidad   desempeño del sistema.
  en < 5%   (menos de 5%)
Moderada (0.5) El costo estimado se Pequeño retraso en el Alguna confiabilidad de Cierta reducción en el
  supera en < 15%   cronograma inicial y   la confiabilidad   desempeño del sistema.
  efecto en la   Puede requerir depuración
  ruta crítica  moderada.
Significativa (0.7) El costo estimado se El tiempo de desarrollo Degradación Degradación significativa en
  supera en < 30%   se excede en 1 mes;   significativa en   el desempeño del sistema.
  se requiere reajuste   la confiabilidad   Las garantías están en
  de la ruta crítica   riesgo. Se requiere depura
ción seria.
Mayor (0.9) El costo estimado se Los grandes retrasos en el Las metas de Metas de desempeño no se
supera en > 50%   cronograma aseguran   confiabilidad no   pueden lograr. Los
  el incumplimiento de   pueden alcanzarse   resultados pueden no
  la fecha de entrega   ser utilizables.
  al cliente
236 Capítulo 7  •  Gerencia del riesgo

los factores que puedan afectar significativamente la probabilidad de que el nuevo proyecto sea completado
con éxito. Piense en esta categoría, pues requiere que nos centremos en las posibles causas de fracaso. Para el
ejemplo de esta sección, vamos a suponer que los factores identificados por contribuyentes potenciales son:
(1) madurez del diseño de software: ¿se trata de un nuevo producto o se basa en una plataforma de software
existente?; (2) complejidad del producto: ¿el diseño es relativamente simple o su estructura es muy compleja?;
y (3) dependencia: el producto puede desarrollarse independiente de cualquier sistema utilizado actualmente
en la empresa o está ligado a los sistemas y prácticas de operación actuales? Un número de factores pueden
tener efecto en la probabilidad de terminación exitosa de un proyecto. Aunque nuestro ejemplo identifica
tres (madurez, complejidad y dependencia), según el proyecto, un equipo puede identificar muchos proble-
mas o factores únicos que aumentarían la probabilidad de falla.
En la dimensión de las consecuencias del fracaso, nos ocupamos de los temas que destacarán los efectos
de fracaso del proyecto. Las consecuencias del fracaso nos obligan a evaluar críticamente, en varias dimensio-
nes claves, los resultados de éxito o fracaso de un proyecto. Para este ejemplo, la organización ha identificado
cuatro elementos que deben considerarse como efectos críticos del fracaso del proyecto: (1) costo, es decir,
cumplimiento del presupuesto versus los excesos; (2) cronograma, o sea, a tiempo versus retrasos graves; (3)
confiabilidad, es decir, la utilidad y la calidad del producto acabado; y (4) desempeño, o sea, qué tan bien
realiza sus funciones diseñadas el nuevo software. Igual que con los elementos que aparecen debajo de la pro-
babilidad de fracaso, el conjunto de factores relacionados con las consecuencias de fracaso debe claramente
identificarse de forma única para cada proyecto.
El cuadro 7.3 muestra el proceso de creación de una puntuación para el riesgo del proyecto. Se inclu-
yen valoraciones a cada dimensión de probabilidad y consecuencia, y la suma se divide por el número de
factores utilizados para evaluarlos. Por ejemplo, en la probabilidad de falla, las puntuaciones de los tres
elementos evaluados (madurez, complejidad y dependencia) se suman para obtener la puntuación total y
ese número se divide por 3 para llegar a la valoración de la probabilidad. Este cuadro muestra la fórmula
para el factor de riesgo general del proyecto de ejemplo, con base en la evaluación cuantitativa. Una regla
común es calificar los proyectos con valoración por debajo de 0.30 como de “bajo riesgo”, con puntuacio-
nes entre 0.30 y 0.70 como de “riesgo medio” y los que tienen más de 0.70 como de “riesgo alto.”

Estrategias de mitigación de riesgo


La siguiente etapa en la gerencia del riesgo es el desarrollo de estrategias efectivas para la mitigación de ries-
gos. En un sentido general, hay cuatro opciones que una organización puede adoptar para decidir la forma
de abordar los riesgos del proyecto: (1) aceptar el riesgo; (2) minimizar el riesgo; (3) compartir el riesgo o (4)
transferir el riesgo.

CUADRO 7.3  Cálculo del factor de riesgo del proyecto


1. Utilice el consenso del equipo del proyecto para determinar las valoraciones de probabilidad de
falla en cada categoría: madurez (Pm), complejidad (Pc), dependencia (Pd).
2. Calcule Pf sumando las tres categorías y divida entre 3:
Pf = (Pm + Pc + Pd) /3

3. Utilice el consenso del equipo del proyecto para determinar las valoraciones de las consecuen-
cias de falla en cada categoría: costo (Cc), cronograma (Cs), confiabilidad (Cr), desempeño (Cp).
4. Calcule Cf agregando las cuatro categorías y dividiendo entre 4:
C f = (C c + C s + C r + C p) /4

5. Calcule el factor general de riesgo del proyecto utilizando la siguiente fórmula:


RF = Pf + C f - (Pf ) (C f )

Regla empírica:
Riesgo bajo RF < .30
Riesgo medio RF = .30 a .70
Riesgo alto RF > .70
7.1  Gerencia del riesgo: un proceso de cuatro etapas 237

ACEPTAR EL RIESGO   Una de las opciones que el equipo del proyecto siempre debe tener en cuenta es si
el riesgo es suficientemente fuerte como para justificar cualquier acción. Una cantidad de riesgos de natu-
raleza relativamente menor puede estar presente en un proyecto como rutina. Sin embargo, debido a que la
probabilidad de su ocurrencia es tan pequeña o a que las consecuencias de su impacto son mínimas, pueden
catalogarse como aceptables y se ignoran. En este caso, la decisión de “no hacer nada” es un cálculo razonado,
no el resultado de la falta de atención o de la incompetencia. Del mismo modo, para muchos tipos de pro-
yectos, algunos riesgos son simplemente parte de la ecuación y deben aceptarse. Por ejemplo, se estima que
la industria discográfica de Estados Unidos gasta millones de dólares cada año en el desarrollo, producción
y promoción de nuevos artistas, a sabiendas de que de los miles de álbumes producidos cada año, menos de
5%, son rentables.8 Del mismo modo, el capítulo 3 detalló las medidas extraordinarias que los fabricantes
farmacéuticos deben tomar y el alto porcentaje de fracasos que aceptan, con el fin de obtener un pequeño
porcentaje de los medicamentos con éxito comercial en el mercado. Por tanto, un alto grado de riesgo comer-
cial es inherente a los propios sistemas y debe aceptarse a fin de operar en ciertas industrias.

MINIMIZAR EL RIESGO   La siguiente opción son las estrategias para minimizar el riesgo. Considere los
desafíos que enfrenta Boeing Corporation en el desarrollo de nuevos fuselajes de avión, como el modelo
787, un prototipo en desarrollo. Cada aeronave contiene millones de piezas individuales, la mayoría de las
cuales se deben adquirir de los proveedores. Además, Boeing ha experimentado con el uso de materiales
compuestos, en lugar de aluminio, a lo largo de la estructura del avión. Los riesgos para Boeing, en el caso
de que piezas defectuosas puedan ocasionar una falla catastrófica, son enormes. En consecuencia, el proceso
de selección y aseguramiento de la calidad de desempeño de los proveedores es un reto que Boeing se toma
muy en serio. Un método empleado por Boeing para minimizar el riesgo en la calidad de los proveedores
es insistir en que todos los proveedores importantes deben mantener un contacto directo y permanente con
los equipos de evaluación de la calidad de Boeing. Además, en el examen de un nuevo proveedor potencial,
Boeing insiste en el derecho de intervenir en el proceso de producción del proveedor con el fin de garantizar
que la calidad que resulta de todas las piezas de proveedores cumpla sus exigentes estándares. Debido a que
Boeing no puede producir todos los componentes para fabricar una aeronave, minimiza el riesgo adoptando
estrategias que le permitan intervenir directamente en los procesos de producción de sus proveedores.

COMPARTIR EL RIESGO   El riesgo puede distribuirse proporcionalmente entre varios miembros del pro-
yecto. Dos ejemplos de riesgo compartido incluyen la investigación y el desarrollo realizados por la Agencia
Espacial Europea (European Space Agency: ESA) y el consorcio Airbus. Debido a las enormes barreras de
entrada, ningún país de la Unión Europea cuenta con los recursos de capital y conocimientos técnicos para
desarrollar el cohete Ariane de distribución satelital o la creación de una nueva estructura de avión para
competir con Boeing en la industria aeronáutica comercial. ESA y los socios de Airbus en varios países
han agrupado conjuntamente sus recursos y acordado compartir conjuntamente el riesgo inherente a estos
emprendimientos.
Además de las asociaciones, la gerencia de riesgos del proyecto se puede mejorar compartiendo los
riesgos contractualmente. Muchas organizaciones de proyectos crean relaciones con proveedores y clientes,
que incluyen requisitos legales para que el riesgo sea compartido entre los involucrados en el proyecto. Los
países anfitriones de grandes proyectos de construcción industrial, como plantas petroquímicas o de gene-
ración de energía, han comenzado a insistir en contratos que exigen cumplir una disposición: “Construya-
Aprópiese-Opere-Transfiera” para todas las empresas de proyectos. Se espera que la organización líder del
proyecto construya la planta, tome posesión inicial de esta hasta que se pruebe su capacidad operativa y
depure la producción antes de que finalmente transfiera la propiedad al cliente. De esta manera, la organi-
zación del proyecto y el país anfitrión aceptan conjuntamente la propiedad financiera (riesgo) del proyecto
hasta el momento en que este se haya completado y su capacidad se haya demostrado.

TRANSFERIR EL RIESGO   En algunas circunstancias, cuando es imposible cambiar la naturaleza del riesgo,
ya sea mediante la eliminación o la minimización, se pueden trasladar los riesgos ligados al proyecto a otra
parte. Esta opción, transferir el riesgo a terceros siempre que sea posible, reconoce que incluso en los casos
en que el riesgo no pueda reducirse, es posible que la organización del proyecto no tenga que aceptarlo,
siempre que exista un medio razonable para transferir el riesgo. Las empresas utilizan varios métodos para
transferir los riesgos, dependiendo de su poder en la relación con las organizaciones de los clientes y los
tipos de riesgos que enfrentan. Por ejemplo, si nuestro objetivo es evitar sobrecostos presupuestarios exce-
sivos, un buen método para transferir directamente el riesgo consiste en desarrollar contratos de precio fijo.
238 Capítulo 7  •  Gerencia del riesgo

En los contratos de precio fijo, la empresa establece un valor fijo inicial para el proyecto; en caso de que
el presupuesto del proyecto comience a inflarse, la organización del proyecto deberá asumir el costo total
de estos sobrecostos. Por otra parte, si nuestra meta es garantizar la funcionalidad del proyecto (calidad
y rendimiento), el concepto de daños y perjuicios ofrece una manera de transferir el riesgo por medio de
contratos. Daños y perjuicios representan cláusulas de penalización de proyectos que entran en operación
de mutuo acuerdo, durante el desarrollo e implementación del proyecto. Por ejemplo, una organización de
proyectos que instala un nuevo sistema de información en una gran empresa, puede acordar una cláusula de
indemnización si el sistema no entra en operación después de una fecha determinada. Por último, las pólizas
de seguros son una opción común para algunas organizaciones, en particular en el sector de la construcción,
pues se utiliza como una herramienta de mitigación de riesgos al transferir la obligación financiera a una
agencia aseguradora.

Uso de reservas para las contingencias


Las varias formas de reservas para las contingencias, incluidas la financiera y de gerencia, están entre los méto-
dos más comunes para mitigar los riesgos del proyecto. Se definen como una provisión específica de costo para
elementos no previstos en el alcance definido para el proyecto. Sin embargo, las reservas para las contingencias
se ven de manera diferente, dependiendo del tipo de proyecto realizado y de la organización que lo desarrolla.
En los proyectos de construcción, es común dejar entre 10% y 15% del precio de la construcción en un fondo de
contingencia. Un contrato para la construcción de un edificio de 5 millones de dólares en realidad se construirá
a un costo aproximado de 4.5 millones de dólares, con el saldo retenido por contingencia. Sin embargo, en otros
campos, los equipos de proyectos son más reacios a admitir la necesidad inicial de establecer reservas de contin-
gencia, por temor de que los clientes u otras partes interesadas del proyecto puedan ver esto como un signo de
mala planeación o de insuficiente definición del alcance (véase el capítulo 5).
La mejor manera de contrarrestar las preocupaciones sobre el uso de las reservas para las contingencia
es contar con documentación de los riesgos anteriores, circunstancias imprevistas o incontrolables que gene-
ran la necesidad de tal plan de contingencia. Algunos de los problemas que pueden generarse, al respecto,
también puede compensarse si el equipo del proyecto ha hecho su tarea y ha plasmado, en un plan detallado,
cómo se liberarán los fondos de contingencia, en caso de necesitarse. Dado que la meta de la creación de los
fondos de contingencia es asegurarse contra riesgos imprevistos, la clave para su uso efectivo radica en una
planeación proactiva que establezca activadores razonables para su liberación.9

CONTINGENCIA DE TAREAS   Tal vez la forma más común de la reserva para las contingencias es la con-
tingencia de tarea, la cual se utiliza para compensar recortes presupuestarios, excesos en el cronograma u
otras circunstancias imprevistas que resultan de tareas individuales o paquetes de trabajo del proyecto. Estas
reservas presupuestarias resultan muy valiosas en la gerencia del riesgo, ya que le proporcionan al equipo
del proyecto un apoyo en las dificultades de finalización de las tareas. Se puede encontrar, por ejemplo, que
algunos de los componentes o paquetes de trabajo del proyecto son únicos e innovadores, lo cual sugiere que
los estimativos de desarrollo y sus costos relacionados no pueden estimarse con nada menos que una cota
de ± 20% o aún mayor. Por tanto, la contingencia de tarea se torna muy importante como un método para
compensar la incapacidad del equipo de proyectos para hacer una estimación precisa del presupuesto.

EJEMPLO 7.1 Cálculo del costo esperado de la contingencia

Supongamos que la ejecución de una tarea del proyecto se estima que costará 10,000 dólares, pero se ve
como una operación de alto riesgo. Se requeriría entonces un multiplicador de contingencia de tarea y
nuestro presupuesto debe reflejar lo siguiente:

(Costo estimado de la tarea) (multiplicador de contingencia de tarea) = costo esperado


($10,0000)(1.2)  $12,000

Naturalmente, a medida que el proyecto avanza, pueden reducirse los requerimientos de reservas de presu-
puesto para las contingencias de tarea, porque el alcance del proyecto se habrá aclarado más y su desarrollo
habrá progresado; es decir, muchas de las tareas para las cuales se estableció un fondo para imprevistos se
habrán completado. Como resultado, es común que las organizaciones de proyectos asignen reservas de presu-
puesto para los proyectos que van disminuyendo, a medida que transcurre el ciclo de desarrollo del proyecto.
7.1  Gerencia del riesgo: un proceso de cuatro etapas 239

CONTINGENCIA GERENCIAL   Mientras la contingencia de tarea implica el riesgo asociado con el desarro-
llo de los paquetes de trabajo individuales o incluso de las tareas, la contingencia gerencial es un margen de
seguridad adicional que se aplica en el proyecto. La contingencia gerencial es una reserva de presupuesto
como medida de seguridad para los riesgos de nivel superior. Por ejemplo, supongamos que un equipo de
proyectos comienza el desarrollo de un nuevo dispositivo de comunicación inalámbrica configurado para
operar dentro de unos lineamientos establecidos para el desempeño técnico. En algún momento, en medio
del proceso de desarrollo, el cliente principal solicita unos cambios importantes en el alcance, que altera-
rán dramáticamente la naturaleza de la tecnología por emplear. La contingencia gerencial suele utilizarse
como reserva contra un problema como este. Otra forma en que puede utilizarse la contingencia gerencial es
para compensar los potencialmente desastrosos “actos de Dios”, desastres naturales que, por definición, son
imprevisibles y altamente perjudiciales.
Un punto final sobre las reservas presupuestarias, ya sea de tarea o gerencial: es extremadamente
importante mantener canales de comunicación abiertos entre la alta gerencia y el gerente de proyectos en
relación con la disponibilidad y el uso de los fondos de reserva de contingencia. Los gerentes de proyec-
tos deben estar plenamente conscientes de las directrices para solicitar estos fondos adicionales y de cómo
se desembolsan las reservas de presupuesto. Si bien el gerente de proyectos o el grupo de la alta gerencia
utilizan las reservas de contingencia como una política o método para mantener el control, la otra parte
desarrollará rápidamente una actitud de espíritu de juego hacia la adquisición de esas reservas. En este caso,
el ambiente y las comunicaciones entre los principales interesados se caracterizarán por la desconfianza y el
secreto, dos factores que pueden provocar el fracaso del proyecto.

Otras estrategias de mitigación


Además del conjunto de estrategias de mitigación comentadas, muchas organizaciones adoptan enfoques
prácticos para minimizar el riesgo a través de sistemas efectivos de capacitación para todos los miembros
de sus equipos de proyecto. Un método eficaz para enfrentar los riesgos del proyecto consiste en moni-
torear a los nuevos gerentes de proyectos y miembros del equipo. En un programa de tutoría, el personal
de proyectos júnior o sin experiencia se asigna a trabajar en pareja con los altos directivos, con el fin de
ayudarles a aprender las mejores prácticas. El objetivo de la tutoría es ayudar al nuevo personal del pro-
yecto a asimilar sus funciones, brindándoles un contacto formal con quienes pueden ayudarles a aclarar
los problemas, proponer soluciones y monitorear cómo desarrollan sus habilidades en proyectos. Otro
método para la mitigación de riesgos consiste en el entrenamiento transversal del personal del equipo del
proyecto, a fin de que cada uno esté en capacidad de ejecutar el trabajo del otro en caso de que se presenten
imprevistos. El entrenamiento transversal requiere que los miembros del equipo del proyecto aprendan no
solo a sus propios deberes, sino también los papeles que se espera que los otros miembros del equipo lleven
a cabo. Así, en caso de que un miembro del equipo se retire del equipo del proyecto durante un periodo
prolongado, otros miembros del equipo están en capacidad de relevarlo, lo cual minimiza el tiempo per-
dido en el cronograma del proyecto.

Control y documentación
Una vez que el análisis de riesgo del proyecto se completa, vale la pena comenzar a desarrollar un sistema
de información y documentación para su futura referenciación y catalogación. Los métodos de control y la
documentación ayudan a los gerentes a clasificar y codificar los diferentes riesgos que enfrenta la empresa,
las respuestas a estos riesgos, así como los resultados de las estrategias de respuesta. El cuadro 7.4 muestra un
ejemplo de una versión simplificada de un formulario de informe de gerencia del riesgo, utilizado en varias
organizaciones. Los gerentes pueden mantener un archivo de copias impresas de todos estos análisis o pasar
el análisis a una base de datos para una mejor accesibilidad.
Tener un repositorio de las operaciones pasadas de análisis de riesgos es muy valioso, sobre todo para
los gerentes de proyectos novatos que se enfrentan con la necesidad de realizar las tareas de gerencia de
riesgos, pero no están seguros de hacerlo de la mejor manera o por dónde empezar. Por ejemplo, el Ejército
de Estados Unidos ha invertido presupuesto y tiempo significativo en la creación de una exhaustiva base de
datos de los factores de riesgo de los proyectos y sus estrategias de mitigación, como parte de la formación en
gerencia de proyectos para sus oficiales. Los funcionarios de contratación del Ejército y las oficinas de geren-
cia de proyectos están obligados a acceder a esta información con el fin de comenzar a establecer estrategias
preliminares de gerencia de riesgos antes de iniciar nuevos programas. El cuadro 7.5 muestra un documento
de contingencia para ajustes al plan del proyecto.
240 Capítulo 7  •  Gerencia del riesgo

CUADRO 7.4  Ejemplo de un formato de gerencia del riesgo


Cliente: _________________________________________ Nombre del proyecto: ___________________________
Presupuesto número: _____________________________ Equipo de proyecto: ____________________________
Fecha de la evaluación más reciente: _________________________________________________________________
Descripción del riesgo: _______________________________________________________________________________
__________________________________________________________________________________________________
__________________________________________________________________________________________________
__________________________________________________________________________________________________
Plan de reducción del riesgo: ______________________________ Factor de riesgo: _________________________
Observaciones: ___________________________________________________________________________________
__________________________________________________________________________________________________
__________________________________________________________________________________________________
Plan de reducción de riesgo: ___________________________ Propietario: __________________________________
__________________________________________________________________________________________________
Tiempo para la siguiente evaluación: _______________________________________________________________
Resultado esperado: ______________________________________________________________________________
__________________________________________________________________________________________________
__________________________________________________________________________________________________

Establecer la gerencia del cambio como parte de las estrategias de mitigación de riesgos también
requiere un sistema de documentación al que todos los socios del proyecto puedan acceder. Toda estrate-
gia dirigida a reducir al mínimo un factor de riesgo del proyecto, junto al miembro del equipo del proyecto
responsable de cualquier acción, debe estar claramente identificada. El formulario de informe de gerencia
del riesgo de ejemplo que se muestra en el cuadro 7.4 incluye los elementos importantes de esa gerencia
del cambio. Para ser efectivo, el informe deberá ofrecer el análisis exhaustivo del problema, el plan para

Evento
Ajuste de los planes
probable

Ausentismo

Reasignación

Renuncia

Personal sin
habilidades
requeridas

Cambio de
especificaciones

Adiciones
al trabajo

Necesidad
de mayor
capacitación
CUADRO 7.5  Documento de
Incumplimiento
contingencia para ajustes de los
al plan de proyecto proveedores
Perfil de proyecto 241

su minimización, la fecha límite y el resultado esperado una vez que la estrategia de mitigación se ha
implementado. En resumen, como documento de control, un formulario de informe tiene que identificar
coherentemente la información importante: qué, quién, cuándo, por qué y cómo.
• Qué—Identificar claramente la fuente de riesgo descubierta.
• Quién—Asignarle a un miembro del equipo del proyecto la responsabilidad directa del seguimiento de
este problema y designarlo como propietario, en relación con su resolución.
• Cuándo—Establecer un marco de tiempo claro, incluidos hitos si es necesario, que determinará
cuándo se espera que ocurra la mitigación. Si no es posible identificar de antemano una fecha de
finalización, se deben identificar metas razonables del proceso en el camino hacia el punto final de la
reducción de los riesgos.
• Por qué—Identificar las causas más comunes del riesgo, esto es, identificar sus causas para asegurarse
de que los esfuerzos dirigidos a su minimización corresponderán adecuadamente a la razón que dio
origen al riesgo.
• Cómo—Elaborar un plan detallado de cómo debe abatirse el riesgo. ¿Qué medidas han adoptado los
miembros del equipo de proyectos como un método para cerrar una “ventana de riesgo” en particular
del proyecto? ¿Parecen razonables o exageradas? ¿Demasiado costosas en tiempo o dinero? La estrate-
gia particular para la reducción de riesgos, preferiblemente, debe desarrollarse de forma colaborativa
entre los miembros del equipo, incluidos aquellos con experiencia administrativa y técnica para asegu-
rar que las medidas adoptadas para resolver el problema sean técnicamente lógicas y administrativa-
mente posibles.
La documentación del análisis de riesgos, como se muestra en los cuadros 7.4 y 7.5 representa el último com-
ponente clave en el proceso global de gerencia de riesgos.

PERFIL DE PROYECTO

Caso—Colapso de un edificio de apartamentos en Shanghái


Los principios de la ciencia y la ingeniería que rodean la construcción de bloques de apartamentos simples son bien
conocidos y se han practicado durante siglos. Sin embargo, incluso en el proyecto de construcción más básico, se
pueden presentar eventos que producen resultados sorprendentes. Justamente, una historia ocurrió a finales de
junio de 2009 en China, cuando un edificio de apartamentos de trece pisos en Shanghái, literalmente, se derrumbó
sobre un costado. La estructura casi terminada formaba parte de un complejo de apartamentos de once edificios
en una nueva zona conocida como “Lotus Riverside.” Debido a que el edificio de apartamentos de 629 unidades
aún no había sido terminado, estaba prácticamente vacío. Aunque un trabajador murió en el accidente, la tragedia
podría haber sido peor si el edificio hubiera estado habitado.
imago stock&people/Newscom

FIGURA 7.6  Edificio de apartamentos colapsado en Shanghái


242 Capítulo 7  •  Gerencia del riesgo

La demanda de viviendas a precios razonables en las ciudades chinas nunca ha sido mayor. Con una economía
en alza y una alta demanda de trabajadores en las regiones económicas, como Shanghái, hay una gran escasez de
viviendas disponibles. Organizaciones privadas y gubernamentales trabajan para construir rápidamente nuevos
bloques de apartamentos, a fin de mantenerse al día con esta gran demanda. Infortunadamente, uno de los ries-
gos con la construcción rápida es la tentación de tomar atajos o la utilización de métodos poco convencionales.
Cuando la velocidad prima, la preocupación obvia es si se mantienen estándares aceptables de construcción.
En el proyecto de construcción de Lotus Riverside, por desgracia, la constructora optó por un procedimiento
generalmente equivocado (de hecho, el método está prohibido en Hong Kong debido a su grado de riesgo inhe-
rente). En este método, en lugar de verter una base profunda de hormigón sobre la cual descansa la estructura, se
utiliza una serie de pilotes de hormigón prefabricados a manera de anclas para “fijar” el edificio al suelo. Aunque
este sistema puede ser efectivo en pequeños edificios, se considera como peligroso para estructuras más grandes.
El problema se hizo crítico cuando los equipos de construcción comenzaron a cavar un garaje subterráneo en
el lado sur del edificio, a una profundidad de cerca de 5 metros. La tierra excavada se apilaba en el lado norte del
edificio hasta una altura de 10 metros. Los pilotes subterráneos comenzaron a recibir una presión lateral severa de la
excavación, la cual se comprometió aún más por las fuertes tormentas. Las tormentas socavaron el lado sur del edifi-
cio de apartamentos, causaron más erosión del suelo y ejercieron aún más presión lateral (estimada en 3,000 tonela-
das) en el sistema de pilotes de anclaje (véase figura 7.7). Repentinamente, los pilotes comenzaron a quebrarse y el
edificio se vino abajo de lado. Las autoridades locales señalaron que había sido una suerte que el edificio se hubiera
caído en un espacio vacío. Considerando que todos los edificios del complejo se habían construido de una manera
similar, había una posibilidad muy real de crear una reacción en cadena para derribar los edificios, al igual que caen
las fichas de dominó.
El gobierno chino comenzó inmediatamente a rastrear insistentemente la causa del colapso, y cuestionó al con-
tratista privado por emplear trabajadores no calificados, prácticas cuestionables de construcción y malas prácticas de
control de calidad general. La agencia oficial de noticias de China Xinhua dijo que las autoridades estaban tomando
“medidas de control apropiadas” contra nueve personas, incluido al desarrollador, el contratista de la construcción y el
supervisor del proyecto, después de que se informó que la licencia de construcción de la compañía había expirado en
2004. Aunque se impondrían sanciones por el fracaso de la construcción, un futuro incierto les espera a los inquilinos
de los otros edificios del complejo. Después de todo, ¿qué evidencia más visible se podría hallar para la falta de solidez
de la construcción en el complejo que ver un “edificio hermano” derrumbado no muy lejos de las otras estructuras?
Cientos de futuros inquilinos han sitiado las oficinas del gobierno exigiendo reembolsos por apartamentos que ellos
compraron en el mismo complejo por encima de 60,000 dólares, pero que ahora temen habitar.
Mientras tanto, China Daily, el periódico estatal, publicaba un fuerte editorial culpando del colapso a la rela-
ción, frecuentemente, corrupta entre los promotores inmobiliarios chinos y funcionarios del gobierno local cuyos
ingresos dependen en una proporción significativa de los impuestos sobre la propiedad y sobre los terrenos. El
artículo hizo temer—expresado por algunos expertos de la industria de la construcción en China—que muchos edi-
ficios diseñados para tener una vida útil de 70 años “no se mantendrían en pie más allá de 30 o 40 años”, debido
a los métodos utilizados durante el auge de la construcción desenfrenada en China. “Es irónico que tal accidente
haya ocurrido en Shanghái—una de las ciudades chinas e internacionales más avanzadas”, concluye el editorial. “El
simple hecho de que semejante colapso se produjera en la metrópoli más grande del país debe servir como adver-
tencia a todos los desarrolladores y autoridades para garantizar que los proyectos de construcción no implementen
métodos que pongan en peligro la vida de las personas.”10

Garaje subterráneo 10 m Tierra


removida

5m
Cimentación
Pilotes de hormigón

FIGURA 7.7  Esquema de las causas del colapso


7.2  Gerencia de los riesgos del proyecto: un enfoque integrado 243

7.2  GERENCIA DE LOS RIESGOS DEL PROYECTO: UN ENFOQUE INTEGRADO


La Asociación Europea para la Gestión de Proyectos ha desarrollado un programa integrado de gerencia
de riesgos, con el propósito de ampliar la gerencia de riesgos para cubrir todo el ciclo de vida del proyecto.
Este programa, conocido como Análisis y gerencia de riesgos de proyectos (Project Risk Analysis and
Management: PRAM), presenta una metodología genérica que puede aplicarse a múltiples entornos de pro-
yectos y abarca los componentes claves de la gerencia de riesgos del proyecto.11 El beneficio último de mode-
los como el PRAM es que dan una alternativa sistemática de los enfoques ad hoc para la evaluación de riesgos
y, por tanto, pueden ayudar a las organizaciones que no cuentan con un proceso integral de gerencia de
riesgos desarrollado y, en cambio, se centran en uno o dos aspectos (por ejemplo, la identificación de riesgos
y el análisis de la probabilidad y consecuencias). El modelo PRAM ofrece un enfoque paso a paso para crear
un método integral y una secuencia lógica para analizar y abordar los riesgos del proyecto. Las principales
características de la metodología PRAM son las siguientes:
Los elementos claves de la metodología PRAM incluyen:
• El reconocimiento de que la gerencia de riesgos sigue su propio ciclo de vida, como un proyecto sigue
su ciclo de vida. La gerencia del riesgo está integrada en todo el ciclo de vida del proyecto.
• La aplicación de diferentes estrategias de gerencia de riesgos en diferentes puntos del ciclo de vida
del proyecto. El enfoque PRAM adopta diferentes estrategias para las diferentes etapas del ciclo de
vida del proyecto.
• La integración de múltiples enfoques para la gerencia de riesgos en un método coherente y sinteti-
zado. PRAM recomienda que todas las herramientas necesarias de gerencia de riesgos se apliquen,
cuando sea necesario, en vez de un enfoque pick and choose.
Cada una de las nueve fases de la metodología PRAM se basan en un propósito específico y requiere
un conjunto comprensivo de entregables (targets). Al completar la PRAM, se le proporciona al equipo
del proyecto una plantilla para conseguir el máximo rendimiento de la gerencia de riesgos y le ayuda
a dirigir sus esfuerzos de la manera más productiva. PRAM también crea un documento para fusionar
la gerencia de riesgos con la planeación general del proyecto, enlazándolas de forma colaborativa.
Las nueve fases de una evaluación completa de riesgos del proyecto incluyen los siguientes pasos:
1. Definir—Asegúrese de que el proyecto está bien definido, que incluye todas las entregas, declaración
de trabajo y el alcance del proyecto.
2. Enfocar—Comience a planear el proceso de gerencia de riesgos como un proyecto en sí mismo, así
como a determinar los mejores métodos para enfrentar los riesgos del proyecto, según la especifici-
dad del proyecto que está desarrollando.
3. Identificar—Evalúe las fuentes específicas de riesgo en el inicio del proyecto, incluidas las respuestas
apropiadas. Este paso requiere primero buscar todas las fuentes de riesgo y sus respuestas y luego clasi-
ficar estos riesgos mediante algún método de priorización u organización.
4. Estructurar—Revise y redefina la forma en que tenga clasificados los riesgos del proyecto; determine
si existen puntos en común entre los diversos riesgos descubiertos (sugiriendo que las causas comunes
de los riesgos que se pueden abordar en un nivel superior) y elabore un esquema de priorización para
enfrentar estos riesgos.
5. Aclarar la propiedad de los riesgos—Distinga entre los riesgos que la organización del proyecto está
dispuesta a manejar y los que se espera que los clientes acepten; asigne la responsabilidad de la gerencia
de riesgos y sus respuestas.
6. Estimar—Desarrolle una estimativo razonable de los efectos en el proyecto tanto de los riesgos detec-
tados como de las soluciones propuestas. ¿Cuáles son los posibles escenarios y sus posibles costos
relativos?
7. Evaluar—Evalúe críticamente los resultados de la fase de estimación para determinar el plan más probable
para mitigar los riesgos potenciales. Comience a priorizar los riesgos y las respuestas del equipo del proyecto.
8. Planear —Elabore un plan de gerencia de riesgos para proyectos, que plantee de forma proactiva las
estrategias de mitigación de los riesgos del proyecto, según se necesite.
9. Gerenciar—Monitoree el progreso real contra el plan de gerencia del riesgo del proyecto, y actúe en res-
puesta a cualquier variación de estos planes, con la mirada puesta en el desarrollo de estos planes para el
futuro.
244 Capítulo 7  •  Gerencia del riesgo

CUADRO 7.6  Un proceso de gerencia del riesgo genérico (risk management process: RMP) según la metodología PRAM

Fases Propósitos Entregables


Definir Consolidar la información pertinente y vigente Una comprensión inequívoca, clara y compartida de
  sobre el proyecto.   todos los aspectos claves del proyecto documentados,
  verificados y notificados.
Enfocar 1. Identificar el alcance y proporcionar un plan Una comprensión inequívoca, clara y compartida de
estratégico para el RMP.   todos los aspectos fundamentales pertinentes al
2. Planear el RMP a nivel operativo.   RMP, documentado, verificado y reportado.
Identificar 1. Identificar dónde pueda haber riesgo. Todos los riesgos y respuestas claves, identificando las
2. Identificar lo que se podría hacer sobre cada   amenazas y oportunidades clasificadas,
riesgo en términos de respuestas proactivas y   caracterizadas, documentadas, verificadas
reactivas.   y reportadas.
3. Identificar lo que podría salir mal con
nuestras respuestas.
Estructurar 1. Probar supuestos. Una clara comprensión de las implicaciones de los
2. Proveer una estructura más compleja cuando   supuestos sobre las relaciones entre los riesgos,
sea apropiado.   las respuestas y el plan base de las actividades.
Aclarar la 1. Asignar la propiedad de la gerencia de Asignaciones de propietarios responsables de la
propiedad   riesgos y respuestas.   gerencia efectiva y eficiente.
de los 2. Asignar clientes para los riesgos identificados.
riesgos 3. Aprobar las asignaciones.
Estimar 1. Identificar áreas claras de incertidumbre 1. Una base para entender que los riesgos y las respues-
 significativa. tas son importantes.
2. Identificar áreas de posible incertidumbre 2. Estimaciones de probabilidad y efecto en el escenario
significativa. o en términos numéricos.
Evaluar Síntesis y evaluación de los resultados de la fase Diagnóstico de todas las dificultades importantes y análisis
  de estimación.   comparativo de las implicaciones de las respuestas a
  estas dificultades, con resultados específicos, como
  una lista de prioridades de los riesgos.
Planear Plan listo para la implementación y el plan de 1. Plan base en términos de actividad a nivel de detalle
  gerencia del riesgo asociado del proyecto. de implementación.
2. Evaluación de riesgos considerando amenazas y
oportunidades priorizadas, evaluadas según el efecto.
3. Planes de contingencia en términos de actividades
proactivas y reactivas recomendadas.
Gerenciar 1. Monitorear. 1. Diagnóstico de la necesidad de revisar los planes
2. Controlar. anteriores y el inicio de una replaneación según
3. Desarrollar planes de implementación corresponda.
inmediata. 2. Informes de excepción después de eventos
importantes y de la replaneación asociada.

El cuadro 7.6 muestra un proceso de gerencia de riesgos genéricos siguiendo la metodología PRAM. En
cada una de las fases de gerencia de riesgos se pueden identificar entregables específicos, lo cual le permite al
equipo del proyecto documentar la gerencia integral de los riesgos del proyecto mientras ejecuta pasos específi-
cos en el camino. Estos entregables son importantes porque les indican a los gerentes de proyectos exactamente
el tipo de información que ellos deben recolectar en las diferentes fases del proyecto y los materiales que deben
poner a disposición de los interesados.
El modelo PRAM para la gerencia del riesgo es muy útil, porque les ofrece a los gerentes de proyectos un
proceso sistemático para la evaluación de los riesgos y de las estrategias de mitigación. Compuesto por nueve pasos
interconectados que forman una secuencia lógica, el PRAM crea una estructura unificadora en la que se puede
llevar a cabo una gerencia efectiva del riesgo. Debido a que sigue la lógica del ciclo de vida del proyecto, el PRAM
debe realizarse no como una actividad de “una sola vez”, sino como un esquema progresivo que vincula directa-
mente el desarrollo del proyecto con la evaluación y la gerencia precisa del riesgo. Finalmente, en la identificación
Resumen 245

de los entregables claves en cada paso del proceso, el modelo PRAM asegura una similitud de forma que le permite
a la alta gerencia realizar comparaciones razonables en todos los proyectos del portafolio de una organización.
La gerencia de riesgos del proyecto demuestra el valor de la planeación proactiva en los proyectos como
una forma de anticipar y, con suerte, mitigar los problemas graves que podrían afectar negativamente el pro-
yecto en algún momento en el futuro.12
El valor de este proceso de solución de problemas nos obliga a pensar críticamente y a ser abogados del diablo,
al examinar cómo estamos pensando en desarrollar un proyecto. La investigación y el sentido común sugieren, como
las palabras del refrán, “una onza de prevención vale más que una libra de cura.” Utilizar un método sofisticado y
sistemático para la gerencia de riesgos de los proyectos nos da más confianza cuando el proyecto se mueve de la fase
de planeación a la de ejecución, ya que hemos hecho todo lo posible para preparar el camino para el éxito de este.

Resumen
1. Definir los riesgos del proyecto.  El riesgo del pro- de riesgos una vez que ha determinado una visión clara
yecto se define como cualquier evento que pueda afectar de los factores de riesgo. El último paso en el proceso de
negativamente su viabilidad. Con frecuencia utilizamos gerencia de riesgo, control y documentación de riesgos, se
la ecuación riesgo = (probabilidad del evento)*(con- basa en el conocimiento de que las estrategias de gerencia
secuencias del evento). La gerencia efectiva del riesgo de riesgos son más efectivas cuando se han codificado e
recorre un largo camino que influye en el desarrollo del introducido como parte de los procedimientos operativos
proyecto. Sin embargo, para ser efectivo, la gerencia de estándares de la organización. La meta es crear estrategias
riesgo del proyecto debe realizarse tempranamente en la sistemáticas y repetibles para la gerencia del riesgo de los
vida del proyecto. Como dice Shakespeare en Macbeth: proyectos.
“ Si fuera hecho, cuando debe ser hecho; entonces esta- 3. Comprender las cinco principales causas de los ries-
ría bien que se hiciera rápidamente.” Como un elemento gos del proyecto y los cuatro enfoques principales
importante de la planeación general del proyecto, la para la identificación de riesgos.   Las cinco princi-
gerencia de riesgos identifica riesgos específicos que pales causas de riesgos en el proyecto son: (1) financie-
pueden tener un efecto perjudicial sobre el desempeño ras; (2) técnicas; (3) comerciales; (4) de ejecución; y (5)
del proyecto y cuantifica el efecto que cada riesgo pueda contractuales o legales. Entre los métodos más comu-
tener. El efecto de cualquier factor de riesgo se define nes para la identificación de riesgos se encuentran: (1)
como el producto de la probabilidad de ocurrencia del lluvia de ideas; (2) opinión de expertos; (3) historia; y
evento y las consecuencias adversas que resultarían. El (4) evaluaciones múltiples o basada en un equipo.
enorme número de incógnitas en las primeras fases de 4. Reconocer las cuatro principales estrategias para la
un proyecto hace que durante ese tiempo el riesgo sea mitigación de riesgos.   Los riesgos pueden ser miti-
más alto. A medida que el proyecto avanza, el equipo gados a través de cuatro enfoques principales. En primer
sigue ocupándose del riesgo al implementar estrategias lugar, podemos simplemente aceptar el riesgo. Podemos
técnicas, administrativas y presupuestarias. optar por hacer esto en una situación en la que o bien
2. Reconocer las cuatro etapas clave en la gerencia de ries- no hay otra alternativa o consideramos que el riesgo es
gos del proyecto y los pasos necesarios para gerenciar lo suficientemente pequeño como para ser aceptado. En
el riesgo.  Hay cuatro fases en la gerencia de riesgos de segundo lugar, podemos tratar de minimizar el riesgo,
proyectos: (1) identificación de riesgos; (2) análisis de pro- quizás a través de alianzas o jointventures con el fin de
babilidad y consecuencias; (3) estrategias de reducción del reducir la exposición de la compañía al riesgo. En tercer
riesgo; y (4) control y documentación. La identificación lugar, podemos compartir el riesgo con otras organiza-
de riesgos se centra en determinar un conjunto realista ciones o interesados del proyecto. Finalmente, cuando
de los factores de riesgo que enfrenta el proyecto. En el sea apropiado, podemos tratar de transferir el riesgo a
análisis de la probabilidad y consecuencias, el equipo del otros interesados del proyecto.
proyecto prioriza sus respuestas a los diversos factores de 5. Explicar el proceso de análisis y gerencia de riesgos
riesgo mediante la evaluación del “factor de impacto” de del proyecto (Project Risk Analysis and Management:
cada uno. Los factores de impacto se determinan ya sea en PRAM).  El PRAM es un enfoque genérico para
forma cualitativa, utilizando un método de matriz y toma la gerencia de los riesgos del proyecto que ofrece un
de decisiones en consenso, o de una manera cuantitativa, modelo paso a paso para el ciclo de vida, que el equipo
en el que se establecen todos los parámetros de probabi- de proyectos podría adoptar en el desarrollo de su meto-
lidad y consecuencias relevantes y se utilizan para evaluar dología de gerencia de riesgos. El modelo PRAM cuenta
el riesgo general del proyecto. El equipo del proyecto ini- con nueve pasos distintos para presentar cada fase del
cia el proceso de desarrollo de estrategias de mitigación proceso y sus entregables asociados.
246 Capítulo 7  •  Gerencia del riesgo

Términos clave
Análisis de la probabilidad Contingencia gerencial Estrategias de mitigación de Riesgo comercial (p. 231)
y de impacto (p. 239) riesgo (p. 236) Riesgo de ejecución (p. 231)
(p. 233) Control y documentación Gerencia de riesgos (p. 243) Riesgo financiero (p. 231)
Análisis y gerencia de (p. 239) Gerencia del cambio (p. 240) Riesgo legal o contractual
riesgos de proyectos Daños y perjuicios Identificación del riesgo (p. 232)
(PRAM) (p. 243) (p. 238) (p. 231) Riesgo técnico (p. 231)
Contingencia de tareas Entrenamiento transversal Reservas para las contin- Tutoría (p. 239)
(p. 238) (p. 239) gencias (p. 238)

Problema resuelto
7.1 Evaluación cuantitativa del riesgo cuadro 7.3, podemos calcular la probabilidad del riesgo del proyecto
y las consecuencias de la calificación de riesgo del proyecto, de la
Refiérase a los factores de riesgo que se muestran en el cuadro 7.2.
siguiente manera:
Suponga que su equipo del proyecto decidió los siguientes valores
de riesgo: Pf = (.1 + .5 + .9)/3 = .5
Pm = .1  Cc = .7 Cf = (.7 + .5 + .3 + .1)/4 = .4
Pc = .5  Cs = .5 RF = .5 + .4 - (.5)(.4) = .70
Pd = .9  Cr = .3 Conclusión: riesgo medio para el proyecto en general.
       Cp = .1
Usted quiere determinar el riesgo general del proyecto mediante un
método cuantitativo. Aplicando las fórmulas que se muestran en el

Preguntas para discusión


1. ”Con una planeación adecuada es posible eliminar la mayoría/ 6. ¿Cuáles son las ventajas y desventajas de utilizar una herra-
todos los riesgos de un proyecto.” ¿Está de acuerdo con esta mienta de evaluación cuantitativa de riesgos, como la que se
declaración? ¿Por qué sí? ¿Por qué no? mostró en el capítulo?
2. Al evaluar proyectos en diferentes sectores de la industria, a veces 7. Dé algunos ejemplos de proyectos que hayan utilizado cada
se detectan patrones de los tipos más comunes de riesgos que ellos una de las estrategias de mitigación de riesgos (aceptar, mini-
enfrentan rutinariamente. Considere el desarrollo de un nuevo mizar, compartir o transferir). ¿Cuánto éxito tuvieron estas
producto de software y compárelo con la coordinación de un estrategias? En retrospectiva, ¿habría sido mejor utilizar otro
evento, como un baile de la escuela. ¿Qué tipos de riesgo puede enfoque?
enfrentar el equipo del proyecto en cualquiera de estas circunstan- 8. Explique la diferencia entre contingencia gerencial y contingen-
cias?
 cia de tarea.
3. Analice la figura 7.2 (grado de riesgo a lo largo del ciclo de vida 9. ¿Cuáles son las ventajas de desarrollar y utilizar un método
del proyecto). ¿Cuál es el significado práctico de este modelo? sistemático de gerencia de riesgos, tal como la metodología
¿Qué implicaciones tiene para la gerencia de riesgos? PRAM? ¿Percibe alguna desventaja en este enfoque?
4. ¿Cuáles son las ventajas y desventajas de cada uno de los 10. Considere la siguiente observación: “El problema con el análisis
métodos de identificación de los riesgos mencionados en el de riesgos es se puede imaginar que casi cualquier cosa vaya mal
capítulo (por ejemplo, reuniones lluvia de ideas, opiniones de en un proyecto. ¿Dónde se traza el límite? En otras palabras,
expertos, etcétera)? ¿hasta dónde llega el análisis de riesgos antes de que sea una
5. ¿Cuáles son las ventajas y desventajas de utilizar una matriz exageración?” ¿Cómo respondería usted?
cualitativa de efecto del riesgo para la clasificación de los tipos
de riesgos del proyecto?

Problemas
1. Evaluación de factores de riesgo. Considere la construcción pre- este edificio de oficinas. ¿Cómo cambiaría su análisis, si el caso
vista de un nuevo edificio de oficinas en el centro de Houston, fuera de gran demanda para los espacios de oficinas?
en un momento en el que hay sobredemanda de espacio de ofici- 2. Evaluación cualitativa del riesgo. Imagine que usted es miem-
nas (más espacio para oficinas que usuarios). Realice un análisis bro de un equipo de proyectos que se encarga de desarrollar un
de riesgo que contemple las diversas formas de riesgo (técnica, nuevo producto para la industria de la construcción residen-
comercial, financiera, etc.) relacionadas con la construcción de cial. Utilizando una matriz de análisis cualitativo de riesgos,
Estudio de caso 7.1 247

desarrolle una evaluación de riesgos para el proyecto basado en Calcule el factor de riesgo general para este proyecto. ¿Cómo
los siguientes datos: evaluaría este nivel de riesgo, bajo, moderado o alto? ¿Por qué?
5. Desarrollo de estrategias de mitigación de riesgos. Suponga
que usted es miembro del equipo de un proyecto muy complejo
Factores de riesgo identificados Probabilidad
basado en una nueva tecnología que nunca ha salido directa-
1. Miembros claves del equipo son 1. Alta mente al mercado. Además, se requieren los servicios de un
arrebatados del proyecto gran número de subcontratistas para realizar el diseño y desa-
2. Posibilidad de recesión económica 2. Baja rrollo de este proyecto. Debido a que usted enfrentaría graves
3. Recorte de financiación del proyecto 3. Media sanciones en caso de que el proyecto entrara tarde en el mer-
4. Cambios en el alcance del proyecto 4. Alta cado, su jefe les ha solicitado, a usted y a su equipo de proyecto,
el desarrollo de estrategias de mitigación de riesgos para redu-
5. Bajo desempeño de las especificaciones 5. Baja
cir al mínimo la exposición de la empresa. Analice los tipos de
riesgo que probablemente encontrará. ¿ Cómo debe enfrentar la
Con base en esta información, ¿cómo calificaría usted las con- empresa a estos riesgos (aceptarlos, compartirlos, transferirlos o
secuencias de cada uno de los factores de riesgo identificados? minimizarlos)? Justifique sus respuestas.
¿Por qué? Construya la matriz de riesgos y clasifique cada uno 6. Evaluación de riesgos y beneficios. Suponga que usted es
de los factores de riesgo en la matriz. miembro de un equipo de proyectos que evalúa las ofertas de
3. Desarrollo de estrategias de mitigación de riesgos. Desarrolle contratistas potenciales para el desarrollo de algunos subcon-
una estrategia preliminar de mitigación de riesgos para cada juntos de su proyecto. Su jefe deja claro que cualquier oferta
uno de los factores de riesgo identificados en el problema 2. Si ganadora debe demostrar un equilibrio entre el riesgo y el pre-
va a darle prioridad a sus esfuerzos, ¿qué factores de riesgo ten- cio. Explique cómo se podría dar esa situación. En concreto,
dría que abordar en primer lugar? ¿Por qué? ¿por qué el precio y el riesgo pueden verse como factores
4. Evaluación cuantitativa del riesgo. Suponga que tiene la igualmente importantes pero opuestos en la adjudicación del
siguiente información: contrato? ¿Es aceptable una oferta de bajo precio/alto riesgo?
¿Es aceptable una oferta alto precio/bajo riesgo? ¿Por qué sí?
Probabilidad de falla Consecuencias de la falla ¿Por qué no?

Madurez = 0.3 Costo = 0.1


Complejidad = 0.3 Programación = 0.7
Dependencia = 0.5 Desempeño = 0.5

Estudio de caso 7.1


Caso clásico: la caída del Comet de Havilland
El desarrollo del Comet se podría reducir la duración de los vuelos de dos o tres
La Havilland Aircraft Company de Gran Bretaña siempre días a pocas horas, lo que motivaría a más empresarios
ha sido respetada en la industria de fabricación de avio- y turistas a utilizar aeronaves como su principal medio
nes por sus diseños innovadores y de alto rendimiento. Al de viaje. Además, los jets tendían a ser más silenciosos
salir de los trabajos realizados durante la Segunda Guerra que los aviones de hélice, lo cual generaría un viaje más
Mundial, la compañía creyó que se encontraba al borde cómodo para los pasajeros, en relación con el nivel de
del éxito en la industria del fuselaje comercial. Los dise- ruido interior.
ñadores y ejecutivos de Havilland estaban convencidos Los ingenieros de Havilland buscaron crear un
de que la próxima generación de aviones sería de reac- avión ágil capaz de transportar cómodamente hasta 50
ción. En consecuencia, decidieron que la armadura de su pasajeros, manteniendo la aerodinámica y la alta velo-
nuevo avión comercial, denominado provisionalmente el cidad. Después de trabajar con una serie de alternativas
Comet, emplearía propulsión a chorro y otras tecnologías de diseño, el Comet comenzó a tomar forma. Su diseño
de vanguardia. fue, de hecho, distintivo: cuatro motores de reacción se
Los jets ofrecen un número de ventajas sobre los incorporaron en pares en las raíces de las alas, en el punto
aviones de hélice, la más evidente de las cuales era la velo- donde se unen al fuselaje. De frente, el avión se veía como
cidad. Los jets podrían viajar a casi 450 millas por hora si sus alas estuvieran literalmente mantenidas en su sitio
en comparación con las 300 millas por hora que podría por los motores. El resultado de estos innovadores diseños
generar uno de hélice. En particular, para el vuelo sobre de ingeniería fue un avión de notable estabilidad de vuelo,
el océano esta era una ventaja importante, con lo cual elegante apariencia y muy rápido.
(continúa)
248 Capítulo 7  •  Gerencia del riesgo

Heanly Mirrorpix/Newscom

FIGURA 7.8  El Comet de Havilland

Otro rasgo distintivo de la aeronave era su cabina Los problemas


presurizada, con la intención de mantener la comodidad de A principios de mayo de 1953, la nueva marca Comet ope-
los pasajeros en viajes de crucero a altitudes de hasta 30,000 rada por BOAC abandonaba Calcuta, India, y despegaba
pies. En sus pruebas iniciales de seguridad, los ingenieros por el cielo de la tarde. Seis minutos más tarde y a solo
de Havilland presurizaron el fuselaje a más de cinco veces 22 millas del aeropuerto Dum Dum de Calcuta, el avión
la densidad de aire recomendada, para asegurarse de que explotó, se estrelló contra la tierra y mató a los 43 pasaje-
estaba sellado herméticamente. En consecuencia, ellos esta- ros y tripulantes a bordo. No había habido ningún indicio
ban seguros de que el sistema de presurización tendría un de problemas y tampoco alguna advertencia de dificultades
buen desempeño. Finalmente, en un esfuerzo por añadir técnicas por los pilotos. Los investigadores de Gran Bretaña
un poco de estilo al diseño, cada ventana de la cabina de y de India se inclinaron a creer que el accidente había ocu-
pasajeros era cuadrada, en lugar de las formas de pequeños rrido debido a un error del piloto aunado a las condicio-
círculos u óvalos, comúnmente utilizadas. nes climáticas. La evidencia de los restos del avión, incluida
Sabiendo que se enfrentaban con la competencia de la sección de cola, parecía indicar que el avión había sido
Boeing Corporation para ser los primeros en comerciali- golpeado por un objeto pesado; sin ninguna información
zar un jet comercial, el objetivo de Havilland era introdu- adicional concluyente, tanto las autoridades como los inge-
cir en el mercado su nuevo avión lo más rápido posible, nieros de Havilland atribuyeron la culpa a causas externas.
con el fin de establecer un estándar para la industria aero- El 10 de enero de 1954 era un día claro y templado en
náutica comercial. Al principio, parecía que habían tenido Roma cuando los pasajeros abordaron su avión BOAC para
éxito: BOAC (British Overseas Airways Corporation) el tramo final de su vuelo de Singapur a Londres. Cuando
ordenó varios Comets, al igual que Air France y el ejér- el avión alcanzó su altitud y velocidad de crucero, se desin-
cito británico. De Havilland también recibió algunas tegró sobre el mar Mediterráneo, cerca de la isla de Elba. La
consultas de aerolíneas estadounidenses interesadas, en mayor parte del avión se perdió en el fondo del mar, pero
especial de Pan American Airlines. Parecía que la estra- en medio de los restos flotantes se recuperaron 15 cuerpos
tegia de de Havilland estaba funcionando; la empresa fue de los pasajeros y de la tripulación. Un médico local que
la primera en el mercado con un nuevo diseño radical, examinó los restos señaló: “Ellos no mostraban expresiones
utilizando una serie de tecnologías de última generación. de terror. La muerte debió haber llegado sin avisar.” Como
Los primeros nueve Comet 1s de la BOAC entraron en medida de seguridad, BOAC impartió una prohibición
servicio de la aerolínea el 2 de mayo de 1952. El futuro sobre el uso de los Comets hasta que los aviones hubiesen
parecía brillante. sido revisados a fondo. Los técnicos no hallaron nada malo
Estudio de caso 7.1 249

en el nuevo avión y después de renovar la certificación, los reacondicionamiento estructural mayor, las simulaciones
aviones fueron puestos de nuevo en servicio. mostraron signos inequívocos de la fatiga del metal des-
Por desgracia, fue demasiado pronto. En el octavo día pués de un equivalente de solo 3,000 horas de vuelo. Los
del mes de abril, solo 16 días después de que el Comet fuera expertos sostuvieron que, incluso si los niveles de fatiga
reintroducido en el servicio, un tercer avión, operado por se revisaran a la baja, a menos de 3,000 horas, los Comets
South African Airways, partió del aeropuerto romano de no serían seguros pasadas 1,000 horas de vuelo, una cifra
Ciampino hacia El Cairo, una de las escalas de su vuelo regu- ridículamente baja en términos de la cantidad de uso que
lar desde Londres a Johanesburgo. Bajo un tiempo de vuelo se espera para un avión comercial. Además, las pruebas del
perfecto, el avión ganó rápidamente su altitud de crucero de fuselaje mostraban indicios preocupantes de la causa de las
26,000 pies y su velocidad relativa de casi 500 millas por hora. fallas. En concreto, las grietas comenzaban a presentarse en
De repente, la radio del vuelo se quedó en silencio y no respon- las esquinas de las ventanas de la cabina y estas grietas se
dió a las repetidas llamadas. Una búsqueda en el océano frente exacerbaban por la presurización y despresurización repe-
a la isla de Stromboli, Italia, solo encontró una mancha de tidas de la cabina. Los investigadores señalaron que este
aceite y un poco de suciedad. Debido a la profundidad del agua resultado era más pronunciado a lo largo de las líneas de
y al tiempo requerido para llegar al lugar del accidente, había remaches cercanas a las ventanas del fuselaje.
poco por hallar por los equipos de búsqueda. Cinco cuerpos Las pruebas también demostraron que las alas tenían
fueron todo lo que se logró recuperar en esta ocasión, aunque una baja resistencia a la fatiga. En varias etapas de las prue-
con una similitud inquietante con las víctimas de la segunda bas, aparecieron grietas graves que iniciaban en los aguje-
catástrofe: Las expresiones faciales no mostraban temor, como ros de los remaches cerca de los ejes de las ruedas, lo cual
si la muerte hubiera venido sobre ellos de repente. daba como resultado que las cabezas de los remaches en la
superficie del ala superior se cizallaran. Ingenieros e inves-
¿Qué salió mal? tigadores encontraron en las piezas de restos recuperados
Los investigadores se abalanzaron sobre los restos recu- pruebas irrefutables de que la causa de la repentina des-
perados de la aeronave y reexaminaron las piezas del pri- integración de la aeronave solo podría atribuirse al escape
mer accidente en Calcuta; al mismo tiempo, se realizaban de la presión de la cabina. Los ingenieros sospechaban que
búsquedas submarinas en el lugar del segundo accidente, la falla crítica de la aeronave se produjo después de una
cerca de la isla de Elba. Guiados por cámaras submarinas, despresurización repentina, cuando una o más ventanas
los investigadores lograron recoger suficientes fragmentos fueron literalmente expulsadas de la aeronave. Esto llevó a
del avión (de hecho, finalmente recuperaron casi 70% de un repentino “momento giroscópico”, la nariz del avión se
la estructura de la aeronave) como para hacer algunos des- enfiló hacia abajo y empezó su caída a tierra.
cubrimientos sorprendentes. El hallazgo más importante, Aunque en el momento nadie lo admitiría, la suerte
procedente de la recuperación de toda la sección de cola estaba echada. Después de dos años, en los que los Comets
intacta, fue que el fuselaje de la aeronave había explotado. habían transportado a más de 55,000 pasajeros en más de 7
En segundo lugar, parecía que una falla en el motor no era la millones de millas aéreas, el Comet 1 nunca volvería a volar.
causa de los accidentes. Otro dato igualmente importante: De Havilland efectivamente había ganado la carrera por ser
las alas y el fuselaje mostraron signos inconfundibles de la el primero en comercializar un jet comercial: una carrera
fatiga del metal; más tarde se demostró que esta era la causa que hubiera sido mejor no haber corrido en lo absoluto.13
del fracaso en las tres aeronaves. Este punto fue importante,
ya que la teoría se podía dirigir a que el problema se debía al Preguntas
diseño estructural y no a la falla de una pieza en particular.
La Britain’s Civil Aviation Board (CAB) inmediata- 1. ¿Cómo podría haber ayudado la gerencia de riesgos al
mente ordenó dejar en tierra toda la flota Comet en espera desarrollo del Comet?
de extensas revisiones y de la certificación de aeronave- 2. Analice los distintos tipos de riesgos (técnicos, financie-
gabilidad. Durante los próximos cinco meses, la CAB se ros, comerciales, etc.) en relación con el Comet. Elabore
embarcó en una serie de pruebas extensas para determinar una matriz de riesgos cualitativa de estos factores de riesgo
las causas exactas de los misteriosos accidentes. Antes de y evalúelos en términos de probabilidad y consecuencias.
que la prueba final se completara, un Comet, literalmente, 3. Teniendo en cuenta que una versión modificada del
se había destruido, otro tenía los depósitos de combustible Comet (el Comet IV) se utilizó hasta hace poco por el
rotos y entre 50 y 100 modelos de prueba se habían ave- gobierno británico, como un avión de guerra antisub-
riado. Los resultados de estas pruebas indicaron una serie marino, está claro que corregir los defectos de diseño era
de defectos estructurales y de diseño. cuestión de tiempo. Entonces, ¿cuál cree usted que fue el
Aunque los diseñadores del avión estaban convenci- error crítico de Havilland en el desarrollo del Comet?
dos de que la estructura se mantendría en buenas condi- 4. Dé su opinión acerca de esta afirmación: “El fracaso
ciones para 10,000 horas de vuelo antes de requerir algún es el precio que se paga por el avance tecnológico.”
250 Capítulo 7  •  Gerencia del riesgo

Estudio de caso 7.2


Caso clásico: el puente colgante de Tacoma Narrows
El dramático colapso del puente colgante Tacoma por hora que soplaban de manera constante, el tramo
Narrows en 1940, apenas cuatro meses después de su fina- principal de 280 metros, que ya había comenzado a mos-
lización, fue un duro golpe para el diseño y la construc- trar una marcada flexión, entraba en una serie de violentas
ción de puentes de grandes luces. Este fue un fallo tras- oscilaciones verticales y de torsión. De forma alarmante,
cendental en la historia de la ingeniería y, de hecho, es una las amplitudes aumentaron constantemente, las sus-
lección impartida en la mayoría de los programas de inge- pensiones se desprendieron, las estructuras de apoyo se
niería civil. La historia del colapso sirve como un relato doblaron y las arcadas comenzaron a romperse. En efecto,
fascinante de un aspecto importante en el fracaso de los el puente parecía haber cobrado vida: luchando como un
proyectos: la falta de comprensión de los efectos que una animal atado y se sacudía literalmente. Los conductores
variedad de fuerzas naturales puede tener en los proyectos atrapados en el puente tuvieron que abandonar sus autos
de ingeniería, en particular en el sector de la construcción. y se arrastraron fuera del puente; como el vaivén de lado
Inaugurado en julio de 1941, el puente de Tacoma a lado se había vuelto tan pronunciado (en ese momento,
Narrows fue construido a un costo de 6.4 millones de el movimiento había alcanzado 45 grados en cualquier
dólares y financiado en gran parte por la Public Work dirección, haciendo que los lados del puente subieran y
Administration del gobierno federal. El propósito del bajaran, más de 30 pies) era imposible atravesar el puente
puente fue visto esencialmente como una medida de caminando.
defensa para conectar Seattle y Tacoma con la Puget Sound Después de un periodo relativamente corto de
Navy Yard, en Bremerton.14 Como el tercer puente col- tiempo, las oscilaciones se tornaron violentas, la suspen-
gante simple del mundo, tenía un tramo central de 2,800 sión del puente simplemente no pudo resistir el golpe-
pies y contactos de 1,000 pies en cada extremo. teo y se rompió. Los observadores que estaban a ambos
Incluso antes de su inauguración y puesta en fun- lados del puente entraron en estado de shock viendo
cionamiento, el puente comenzó a exhibir características cómo caían, en el Tacoma Narrows, primero grandes
extrañas que fueron perceptibles inmediatamente. Por piezas de la carretera y luego tramos enteros de la arcada.
ejemplo, el menor viento ocasionaba que el puente desa- Afortunadamente, no se perdieron vidas humanas, ya
rrollara una presión longitudinal pronunciada. El puente, que el tráfico se había cerrado a último momento.
literalmente, empezaba a levantarse en un extremo y Los 12 metros de ancho del puente principal delgado
en un movimiento de olas. Dependiendo de la grave- había sido apoyada por enormes torres de 130 metros de
dad del viento, las cámaras podían detectar en cualquier altura de acero formada por arcadas de 335 pies de largo.
lugar hasta ocho nodos verticales separados en su acción Estos tramos lograron permanecer intactos a pesar del
rodante. Muchos automovilistas que cruzaron el puente se colapso del tramo principal. El segundo puente (TNB II)
quejaban de mareos agudos provocados por los ascensos y acabaría utilizando estos tramos cuando fue reconstruido
descensos del puente. Entonces, debido al extraño movi- poco después.
miento ondulado, bien conocido por los vecinos del lugar, Después de este fracaso catastrófico, inmediatamente
el puente fue apodado el “Galloping Gertie.” un comité de tres personas fue convocado para determinar
Para todos los involucrados en el proyecto, era claro las causas del colapso del puente de Tacoma Narrows. El
que el puente experimentaba crecientes e inesperadas difi- comité estaba integrado por algunos de los mejores científi-
cultades. De hecho, el movimiento del Galloping Gertie cos e ingenieros de todo el mundo en ese momento: Othmar
llegó a ser peor cuando el verano dejó entrar al otoño, y Ammann, Theodore von Karman y Glenn Woodruff.
obligó la instalación, externamente al tramo, de pesados Aunque consideraron que el diseño básico era bueno y que
cables de acero, en un intento por reducir el movimiento la suspensión del puente se había construido competente-
producido por el viento. En el primer intento, los cables mente, estos expertos descubrieron rápidamente las causas
se rompieron cuando se estaban instalando en su lugar. que contribuyeron a la caída de puente:
El segundo intento, más tarde en el otoño, inicialmente
• Características de diseño—La construcción del
parecía calmar el movimiento de balanceo y oscilación del
puente contribuyó directamente a su fracaso y se
puente. Infortunadamente, los cables resultaron incapaces
convirtió en una fuente constante de preocupación
de reducir los efectos que las fuerzas dinámicas (viento)
desde el momento de su finalización. A diferencia de
producían sobre el puente; aquellos se rompieron justo
otros puentes colgantes, una característica distintiva
antes de que las oscilaciones torsionales se tornaran críti-
del puente Tacoma Narrows era su pequeña rela-
cas y llevaran al colapso del puente.
ción ancho/largo: más pequeño que cualquier otro
El 7 de noviembre de 1940, unos cuatro meses des-
puente colgante de su tipo en el mundo (aunque con
pués de la apertura del puente, con vientos de 42 millas
Estudio de caso 7.2 251

casi una milla de longitud, el puente fue construido fueron tanto las oscilaciones, sino la forma espectacular
para albergar un solo carril de circulación en cada en la que los movimientos de olas a lo largo del tramo
sentido). Esta relación significa, sencillamente, que principal se convirtieron en un sacudón destructivo que
el puente era muy estrecho para su extensa longitud, finalmente condujo a un clímax en el cual la plataforma
hecho que contribuyó enormemente a su comporta- fue arrancada de su posición. Los cables de soporte se
miento oscilante distintivo. rompieron uno por uno, y el puente comenzó a perder sus
• Materiales de construcción—Otra característica piezas en pedazos más grandes hasta que toda su estruc-
de la construcción que iba a desempeñar un papel tura se comprometió.
importante en el colapso fue la sustitución de com-
ponentes estructurales claves. Los planes originales El puente de Tacoma Narrows: El post mortem
contemplaban el uso de vigas abiertas en la construc-
Inmediatamente después del colapso del puente, el
ción de los laterales del puente. Infortunadamente,
informe final de la junta investigadora responsabilizó al
en algún momento, un ingeniero de la construcción
diseño, el cual no previó las propiedades dinámicas del
las sustituyó por vigas planas y sólidas que desviaban
viento y sí consideró a este como estático. Aunque las
el viento en lugar de permitir su paso. El resultado:
oscilaciones longitudinales se contemplaron y se presen-
el puente atrapaba el viento “como una cometa” y
taron al inicio de la construcción del puente, solo cuando
adoptaba un balanceo permanente. En términos de
el puente experimento balanceos de torsión adicionales su
ingeniería, los lados planos simplemente no permi-
colapso empezó a ser inevitable.
tirían que el viento pasara a través de los laterales
Un miembro de la junta investigadora del accidente,
del puente, reduciendo su resistencia al viento. En
el doctor Theodore von Karman, enfrentó la incredulidad
cambio, las caras sólidas y planas capturan el viento
de la ingeniería mientras él empujaba la aplicación de la
que empuja el puente hacia los lados hasta que se
aerodinámica en la ciencia de la construcción de puentes.
haya balanceado suficiente como para “verter” el
En este contexto, más tarde escribió sus memorias en las
viento del plano vertical, así como un velero atrapa
cuales proclamó su dilema en este sentido: “Los ingenie-
y vierte el viento a su favor.
ros del puente, aunque fueran excelentes, no podían ver
• Localizacion del puente—El último problema con
cómo una ciencia aplicada a una pequeña cosa inestable
el plan inicial consistía en la ubicación seleccionada
como el ala de un avión, también se pudiera aplicar a una
para la construcción del puente. Aunque el comité
gran estructura sólida, no voladora como un puente.”
de investigación no percibió que la ubicación física
Las lecciones del colapso del puente de Tacoma
del puente contribuyera a su colapso, esta desem-
Narrows son principalmente: se debe garantizar un cono-
peñó un papel secundario debido al efecto de las
cimiento general de las limitaciones técnicas al diseñar un
corrientes de viento. La topografía de Tacoma
proyecto; los avances tecnológicos con frecuencia condu-
Narrows sobre la que se construyó el puente era
cen a impulsar continuamente los límites del diseño, para
particularmente propensa a fuertes vientos, debido
tratar de lograr la máxima eficiencia; el problema con los
a que la tierra va estrechándose hacia abajo en cada
diseños radicales o incluso con diseños bien conocidos
lado del río. Las características únicas del terreno
pero usados en formas no tradicionales es que su efecto no
sobre el que se construyó el puente prácticamente
se puede predecir utilizando las fórmulas de uso común;
duplicaban la velocidad del viento y actuaban como
en esencia, cuando se quiere experimentar algo nuevo se
una especie de túnel de viento.
requiere que los diseñadores e ingenieros comiencen a
Antes de este colapso, no se sabía mucho acerca de trabajar simultáneamente en desarrollar nuevos cálculos
los efectos de las cargas dinámicas en las estructuras. Hasta para probar tales diseños; es peligroso asumir que si una
entonces, en la construcción de puentes siempre se había tecnología ha funcionado bien en un entorno, va a funcio-
dado por sentado que la carga estática (fuerzas hacia abajo), nar igual de bien en otro, sobre todo cuando otras varia-
el gran volumen y la masa de las grandes estructuras de bles de la ecuación están sujetas a cambios.
acero apuntaladas eran suficientes para protegerlos de los El colapso del puente de Tacoma Narrows comenzó
posibles efectos del viento. Este desastre sirvió para estable- con un gran drama y terminó en una farsa. Después de la
cer firmemente en las mentes de los ingenieros de diseño destrucción del puente, cuando el estado de Washington
que el factor clave en el diseño de este tipo de estructuras intentó cobrar la restitución del seguro del puente por
eran realmente las cargas dinámicas y no las estáticas. 6 millones de dólares, descubrió que el agente de segu-
La ingeniería tomó estas lecciones y se dispuso ros simplemente no podía pagar la prima del estado,
a replantear radicalmente las prácticas convencionales puesto que nunca se había molestado en expedir la póliza.
de diseño. La parte más sorprendente de este fracaso no Después de todo, ¿quién ha oído hablar que un puente

(continúa)
252 Capítulo 7  •  Gerencia del riesgo

del tamaño del Tacoma Narrows haya colapsado? Como otros aspectos particulares del puente para el proceso
señaló von Karman con ironía: “Él [el agente de segu- de gerencia de riesgos. ¿Estos aspectos fueron toma-
ros] terminó en la cárcel, uno de los hombres con la peor dos en cuenta? ¿Por qué sí? ¿Por qué no?
suerte en el mundo.”15 2. Realice una evaluación de riesgos ya sea cualitativa o
cuantitativa para este proyecto. Identifique los facto-
Preguntas res de riesgo que usted considere más importante en
la construcción del puente colgante. ¿Cómo evaluaría
1. ¿De qué formas se apropiaron la planeación y la
el nivel de riesgo de este proyecto? ¿Por qué?
gerencia del alcance del proyecto? ¿Cuándo empeza-
3. ¿Qué formas de mitigación del riesgo consideraría
ron los planificadores a tomar riesgos desconocidos o
usted adecuadas para este proyecto?
innecesarios? Analice las limitaciones del proyecto y

Ejercicios en internet
1. Ingrese en http://www.informationweek.com/whitepaper/ ocurrir en el próximo proyecto. La sesión de hoy pretende
Management/ROI-TCO/managing-risk-an-integrated generar posibles problemas que podrían surgir y conse-
-approacwp1229549889607?articleID=54000027 y accede guir que cada uno empiece a pensar en lo que debe bus-
al artículo en “Managing Risk: An Integrated Approach.” car una vez que el proyecto se inicie. ¿ De cuál elemento
Considere la importancia de la gerencia proactiva de los ries- del proceso de gerencia de riesgos podría ser ejemplo esta
gos a la luz de uno de los casos al final de este capítulo. ¿Cómo reunión?
se violaron estas directrices por las organizaciones de los a. Mitigación del riesgo
proyectos de construcción de Havilland o Tacoma Narrows? b. Control y documentación
Apoye sus argumentos con la información, ya sea del caso o c. Identificación del riesgo
de otros sitios web. d. Análisis de probabilidad y consecuencias
2. La Federal Emergency Management Agency (FEMA) es res-
ponsable de mitigar o responder a los desastres naturales en 2. Todd trabaja en la programación de recursos de preparación
Estados Unidos. Ingrese en www.fema.gov/about/divisions/mi- para el inicio de un proyecto. Hay un problema potencial en
tigation.shtm. Explore el sitio y desplácese hacia abajo para ver el trabajo, ya que el nuevo acuerdo de negociación colectiva
ejemplos de proyectos en los que participa la agencia. ¿Cómo con el sindicato de la empresa no se ha concluido. Todd de-
puede FEMA implementar las diferentes estrategias de mitiga- cide continuar trabajando en la programación de los recur-
ción (por ejemplo, aceptar, minimizar, compartir y transferir) sos a la espera de una solución satisfactoria. De que método
en su enfoque de gerencia de riesgos? para hacer frente a los riesgos sería un ejemplo el enfoque de
3. Ingrese en www.mindtools.com/pages/article/newTMC_07.htm Todd?
y lea el artículo sobre la gerencia de riesgos. ¿Qué dice el artículo a. Aceptar
sobre la creación de una metodología sistemática para la gerencia b. Minimizar
de los riesgos del proyecto?¿Cómo se compara esta metodología c. Transferir
con el método de evaluación cualitativa del riesgo tratado en este d. Compartir
capítulo. ¿En qué se diferencia de nuestro enfoque? 3. Un pequeño fabricante gana un importante contrato con
4. Con la frase “casos sobre la gerencia de riesgos del proyecto” bus- el Ejército de Estados Unidos para desarrollar una nueva
que en internet para identificar e informar acerca de un ejemplo generación de teléfonos satelitales, para aplicaciones en el
reciente de cómo un proyecto enfrentó sus riesgos significativos. campo de batalla. Debido a los importantes retos tecnoló-
¿Qué medidas tomó la organización del proyecto para identificar gicos que participan en este proyecto, a las propias limita-
primero y luego para mitigar los factores de riesgo en ese caso? ciones de tamaño de la empresa y a la falta de experiencia
5. Acceda al podcast gratuito sobre las actitudes de riesgo en los en el trato con el Ejército en este tipo de contratos, la com-
proyectos en http://projectmanagement.ittoolbox.com/research/ pañía decide asociarse con otra empresa a fin de colaborar
pm-podcast-episode-063-how-do-risk-attitudesaffect-your-pro- en el desarrollo de la tecnología. ¿Esta decisión sería un
ject-4947?r=http%3A%2F%2Fresearch.ittoolbox.com%2Fpod- ejemplo de qué tipo de respuesta a los riesgos?
casts%2Fitmgmt%3Fpage%3D4. ¿Qué dice el narrador, Cornelio a. Aceptar
Fichtner, PMP, sobre las causas de los fracasos de los proyectos b. Minimizar
en lo que respecta a los aspectos de la gerencia de riesgos? c. Transferir
d. Compartir
Preguntas de ejemplo del examen para la certificación 4. Todos los siguientes se considerarían ejemplos de riesgos
PMP® importantes del proyecto, excepto:
1. El gerente de proyectos se reúne con su equipo para una a. Riesgos financieros
lluvia de ideas sobre algunos de los problemas que podrían b. Riesgos técnicos
Ejercicios en internet 253

c. Riesgos comerciales c. Ambos deben considerarse igualmente importantes


d. Riesgos legales d. Ninguno es realmente una gran amenaza para este
e. Todos son ejemplos de importantes riesgos potencia- proyecto, por lo que no importa qué orden se les asigne
les del proyecto
Respuestas: 1. c—Reuniones de lluvia de ideas que se crean
5. Suponga que su organización utiliza una matriz de evaluación normalmente como un medio efectivo para que los miembros
de riesgos cualitativa con tres niveles de probabilidad y con- del equipo del proyecto comiencen a identificar los riesgos
secuencias (alto, medio y bajo). En la evaluación de los ries- potenciales; 2. a—La elección de Todd es aceptar el riesgo de
gos de un proyecto, se determina que los riesgos comerciales posibles problemas en el futuro, al continuar trabajando en su
tienen una baja probabilidad de ocurrencia, pero representan programación de recursos, anticipándose a los resultados posi-
altas consecuencias. Por otro lado, los riesgos legales se eva- tivos de la negociaciones de la convención colectiva; 3. d—La
lúan con alta probabilidad de ocurrencia y consecuencias en firma decidió compartir el riesgo del nuevo proyecto mediante
nivel medio. Si usted está interesado en la priorización de los la asociación con otra empresa; 4. e—Todos son ejemplos de
riesgos, ¿cuál de ellos debería considerarse en primer lugar? importantes riesgos potenciales de los proyectos; 5. b—Los ries-
a. Riesgo comercial gos legales serían de mayor importancia global (alta probabili-
b. Riesgo legal dad, consecuencia media) y, por tanto, probablemente deberían
considerarse primero en un esquema de priorización.
254 Capítulo 7  •  Gerencia del riesgo

PROYECTO INTEGRADO
Evaluación de los riesgos del proyecto
Realice un análisis preliminar de los riesgos de su proyecto. Utilice dos técnicas, una cualitativa y otra cuanti-
tativa, para sustentar la evaluación de los riesgos del proyecto. Para hacer esto, usted tendrá que:
• Generar un conjunto de factores de riesgo probables.
• Discutirlos en términos de probabilidad y consecuencias.
• Desarrollar estrategias preliminares para la mitigación de riesgos.
Un análisis efectivo de riesgos demostrará una comprensión clara de los riesgos relevantes del proyecto, su impacto
potencial (probabilidad y consecuencias) y los planes preliminares para reducir al mínimo los efectos negativos.

EJEMPLO DE ANÁLISIS DE RIESGOS—ABCups, INC.


Las posibles amenazas o incertidumbres de este proyecto incluyen:
1. La reestructuración de la planta podría tomar más tiempo del previsto. La ingeniería del proceso puede
ser más complicada o pueden surgir dificultades inesperadas mientras las modificaciones de los proce-
sos están en marcha.
2. Un miembro clave del equipo del proyecto podría reasignarse o no continuar trabajando en el pro-
yecto. Debido a otras necesidades o a una reasignación de recursos por la alta gerencia, el proyecto
podría perder a uno de sus miembros claves del equipo central.
3. El presupuesto del proyecto podría reducirse debido a los recortes presupuestarios en otras partes de la
empresa. El presupuesto del proyecto podría recortarse en medio del ciclo de desarrollo.
4. Los proveedores pueden incumplir los contratos. Después de calificar a los proveedores y celebrar contratos
con ellos, podría descubrirse que no pueden cumplir sus obligaciones contractuales, lo que obliga al equipo
del proyecto y a la organización a renegociar los contratos o a aceptar suministros de menor calidad.
5. Los nuevos diseños del proceso pueden encontrarse inviables técnicamente. Los ingenieros de proceso
pueden determinar a mediados del proyecto que los objetivos técnicos del proyecto no pueden alcan-
zarse de la manera planeada.
6. Los nuevos productos podrían no pasar las pruebas de control de calidad. El equipo del proyecto
podría descubrir que los equipos adquiridos o que la capacitación que el personal de la planta recibió
son insuficientes para lograr los niveles adecuados de calidad de la producción.
7. Los proveedores podrían descubrir nuestras intenciones y recortar las entregas. Los proveedores actuales
podrían determinar nuestra intención de eliminar su trabajo y reducir la velocidad o parar las entregas anti-
cipándose a la cancelación de nuestros contratos.
8. Marketing puede no aprobar las tazas prototipo producidas. El departamento de ventas y marketing
pueden determinar que la calidad o la “apariencia” de los artículos que producimos es inferior y es
improbable venderlas.
9. El nuevo diseño de la fábrica no se podría aprobar durante las inspecciones de seguridad del gobierno.
Es posible que la fábrica no cumpla con los requisitos de OSHA.

EVALUACIÓN CUALITATIVA DEL RIESGO


Probabilidad
Baja Media Alta

5 8
Alta
Consecuencias

Media

3, 9 2 1
Baja

4 6, 7
Proyecto integrado 255

EVALUACIÓN CUANTITATIVA DEL RIESGO

Probabilidad de la falla
• Madurez (moderada) = .50
• Complejidad (menor) = .30
• Dependencia (moderada) = .50

Consecuencia de la falla
• Costo (significativa) = .70
• Cronograma (moderada) = .50
• Confiabilidad (menor) = .30
• Desempeño (moderada) = .50

Pm Pc Pd Pf
.50 .30 .50 .43
Cc Cs Cr Cp Cf
.70 .50 .30 .50 .50
Factor de riesgo = (.43) + (.50) – (.43)(.50) = .715 (riesgo alto)

Estrategias de mitigación del riesgo

Riesgo alto Estrategia de mitigación


1. Reestructuración de la planta lleva 1. Desarrollar un programa de seguimiento de proyectos integral
más tiempo de lo previsto. para mantener la programación.
2. Marketing no aprueba las tazas pro- 2. Mantener estrechos vínculos con el departamento de ventas:
totipo producidas. mantenerlos en el bucle durante todo el desarrollo del proyecto
y los ciclos de control de calidad.

Riesgo moderado
3. Los nuevos diseños de procesos 3. Asignar tiempo suficiente para la evaluación de la calidad du-
son técnicamente inviables. rante la fase de prototipo.
4. Un miembro clave del equipo del 4. Desarrollar una estrategia para el entrenamiento del personal en
proyecto podría reasignarse o no los elementos de trabajo de los demás miembros del equipo o
continuar trabajando en el proyecto. identificar dentro de la organización recursos humanos adecua-
dos, en caso de que se requiera una sustitución.

Riesgo bajo
5. El presupuesto del proyecto se 5. Mantener un estrecho contacto con la alta gerencia sobre el
podría reducir. estado del proyecto, incluido el valor del trabajo y otros docu-
mentos de control.
6. La fábrica no pasa las inspecciones 6. Programar una inspección preliminar a mitad del proyecto para
de la OSHA. calmar cualquier preocupación.
7. Los proveedores no pueden cumplir 7. Calificar múltiples proveedores en la fase de prototipo.
los contratos.
8. Los nuevos productos no pasan las 8. Asignar miembros del equipo para trabajar con el departamento
pruebas de control de calidad. de control de calidad, en un plan provisional de inspección.
9. Los proveedores descubren nuestras 9. ¡Mantener el secreto que rodea el desarrollo del proyecto!
intenciones y paran las entregas.
256 Capítulo 7  •  Gerencia del riesgo

Notas
1. Allen, N., and Leonard, T. (2010). “Haití earthquake: 8. “MCA spent millions on Carly Hennessy—Haven’t heard
Exodus forPort-au-Prince as time runs out,” www.tele- ofher?” (2002, 26 de febrero). Wall Street Journal, pp. A1, A10.
graph.co.uk/news/worldnews/centralamericaandthecarib- 9. Hamburger, D. H. (1990). “The project manager: Risk
bean/haiti/7046878/Haiti-earthquake-exodus-from-Port- taker and contingency planner,” Project Management
au-Prince-as-time-runsout.html; OCHA Flash Appeal. Journal,21(4): 11–16; Levine, H. A. (1995). “Risk manage-
ment for dummies: Managing schedule, cost and technical
(2010). Haiti Earthquake Flash Appeal, 2010; Padgett, T.
risk, and contingency,” PMNetwork, 9(10): 31–33.
(2010, 22 de febrero). “Haiti PM: Wecan rise out of our
10. http://blogs.wsj.com/chinarealtime/2009/06/29/shanghai-
postquake squalor,” Time, www.time.com/time/world/arti- building-collapses-nearly-intact/; http://news.bbc.co.uk/2/
cle/0,8599,1967003,00.html; Rencorcet, N., etal. (2010, julio). hi/8123559.stm; www.telegraph.co.uk/news/worldnews/asia/
“Haiti earthquake response: Context analysis,ALNAP and china/5685963/Nine-held-over-Shanghai-building-collapse.
prevention consortium,” London, www.alnap.org/pool/files/ html.
haiti-context-analysis-final.pdf; “2010 Haitiearthquake.” 11. Chapman, C. B. (1997). “Project risk analysis and man-
(2010). http://en.wikipedia.org/wiki/2010_Haiti_earthquake; agement—The PRAM generic process,” International
“Haiti devastated by massive earthquake.”(2010). http:// Journal of Project Management, 15(5): 273–81; Chapman,
news.bbc.co.uk/2/hi/8455629.stm. C. B.,and Ward, S. (2003). Project Risk Management:
2. Wideman, M. (1998). “Project risk management,” in Pinto,J. K. Processes,Techniques and Insights, 2nd ed. Chichester, UK:
(Ed.), The Project Management Institute’s Project Management John Wiley.
Handbook.San Francisco, CA: Jossey-Bass, pp. 138–58. 12. Artto, K. A. (1997). “Fifteen years of project risk manage-
3. Chapman, C. B., and Ward, S. C. (1997). Project Risk ment applications—Where are we going ?” in Kahkonen, K.,
Management: Process, Techniques, and Insights. Chichester,UK: andArtto, K. A. (Eds.), Managing Risks in Projects.London:
John Wiley; Kahkonen, K., and Artto, K. A. (1997).Managing E &FN Spon, pp. 3–14; Williams, T. M. (1995). “A classi-
Risks in Projects. London: E & FN Spon. fied bibliography of recent research relating to project risk
4. Chapman, R. J. (1998). “The effectiveness of working grouprisk management,”European Journal of Operations Research, 85:
identification and assessment techniques,” International Journal 18–38.
of Project Management, 16(6): 333–44. 13. “Fatigue blamed in Comet crashes.” (1954, 25 de octubre).
5. Martin, P., and Tate, K. (1998). “Team-based risk assessment: Aviation Week, 61: 17–18; “Comet verdict upholds RAE find-
Turning naysayers and saboteurs into supporters,”PMNetwork, ings.” (1955, 21 de febrero). Aviation Week, 62: 16–17; Hull,
12(2): 35–38. S. (1954, 1 de noviembre). “Comet findings may upset de-
6. Jaafari, A. (2001). “Management of risks, uncertainties sign concepts,” Aviation Week, 61: 16–18; “Fall of aComet.”
and opportunities on projects: Time for a fundamental (1953, 11 de mayo). Newsweek, 41: 49; “A column of smoke.”
shift,”International Journal of Project Management, 19(2): (1954, 18 de enero). Time, 63: 35–36; “Death of the Comet I.”
89–102. (1954, 19 de abril). Time, 63: 31–32.
7. Graves, R. (2000). “Qualitative risk assessment,” PMNetwork, 14. “Big Tacoma Bridge crashes 190 feet into Puget Sound.”(1940,
14(10): 61–66; Pascale, S., Troilo, L., and Lorenz, C. (1998).“Risk 8 de noviembre). New York Times, pp. 1, 3.
analysis: How good are your decisions?” PMNetwork,12(2): 15. Kharbanda, O. P., and Pinto, J. K. (1996). What Made Gertie
25–28. Gallup? New York: Van Nostrand Reinhold.
CAPÍTULO

8
Estimación de costos y presupuesto

Contenido del capítulo


PERFIL DE PROYECTO 8.3 CREACIÓN DEL PRESUPUESTO DE UN PROYECTO
Los sobrecostos persiguen a los proyectos importantes Presupuestación de arriba abajo (top down)
8.1 GERENCIA DE COSTOS Presupuestación abajo arriba (bottom up)
Costos directos versus costos indirectos Costeo basado en actividades
Costos recurrentes versus costos no recurrentes 8.4 DESARROLLO DE CONTINGENCIAS DE
Costos fijos versus costos variables PRESUPUESTO
Costos normales versus costos acelerados Resumen
8.2 ESTIMACIÓN DE COSTOS Términos clave
Curvas de aprendizaje en la estimación de costos Problemas resueltos
Estimación de proyectos de software—Puntos de función Preguntas para discusión
Problemas con la estimación de costos Problemas
INVESTIGACIÓN DE GERENCIA DE PROYECTOS EN Estudio de caso 8.1 La central eléctrica de Dulhasti
SÍNTESIS Estudio de caso 8.2 Proyecto Central Artery/Tunnel de Boston
Estimación de costos del desarrollo del software Ejercicios en internet
INVESTIGACIÓN DE GERENCIA DE PROYECTOS EN Preguntas de ejemplo del examen para la certificación PMP®
SÍNTESIS Proyecto integrado. Desarrollo de las estimaciones de costos y
“Engaños y decepciones” en los grandes proyectos del presupuesto
  de infraestructura Notas

Objetivos de aprendizaje
Al finalizar el capítulo, el estudiante estará en capacidad de:
1. Entender los tipos de costos más comunes usados en los proyectos.
2. Reconocer la diferencia entre las diversas formas de costos del proyecto.
3. Aplicar las técnicas más comunes de estimación de costos en el trabajo del proyecto, incluidas las esti-
maciones iniciales y definitivas.
4. Entender las ventajas de la estimación de costos paramétricos y la aplicación de modelos de curva de
aprendizaje en la estimación de costos.
5. Identificar los motivos por los cuales la estimación del costo del proyecto se realiza equivocadamente.
6. Elaborar presupuestos aplicando las técnicas de arriba abajo y de abajo arriba en la gerencia de costos.
7. Comprender el uso de los presupuestos basados en actividades y en fase temporal para la estimación y
el control de costos.
8. Reconocer la conveniencia de incluir los fondos de contingencia en la estimación de los costos del proyecto.

257
258 Capítulo 8  •  Estimación de costos y presupuesto

CONCEPTOS BÁSICOS DE LOS FUNDAMENTOS PARA LA GERENCIA DE PROYECTOS


(PROJECT MANAGEMENT BODY OF KNOWLEDGE,PMBOK® GUIDE, 5A. EDICIÓN)
CUBIERTOS EN ESTE CAPÍTULO
1. Estimar los costos (PMBOK®, Guide, 5a. edición, sección 7.2).
2. Determinar el presupuesto (PMBOK®, Guide, 5a. edición, sección. 7.3).
3. Controlar los costos (PMBOK® Guide, 5a. edición, sección 7.4).

PERFIL DE PROYECTO

Los sobrecostos persiguen a los proyectos importantes


Parece un hecho normal de la vida que los proyectos importantes sean una fuente permanente de problemas sin impor-
tar el entorno, el país o el propósito de aquellos, sobre todo en lo referente a la generación de sobrecostos. Sin importar
qué tanto apoyo reciba el proyecto dentro de la organización, ni el esfuerzo puesto en la estimación de costos y en la
planeación del presupuesto, como tampoco el seguimiento ejercido al control de la ejecución presupuestaria, muchos
proyectos tienen problemas serios originados en una aparente incapacidad para controlar los costos. Como fácilmente
se supone, el resultado final es a menudo la cancelación del proyecto o, en el mejor de los casos, la reducción de los fon-
dos disponibles, lo que a su vez afecta seriamente el alcance esperado por los interesados. A continuación se presenta
una lista breve de proyectos recientes que han comprometido su éxito debido a un mal control de costos.
1. El proyecto James Webb Space Telescope (JWST)—Este proyecto de la NASA está en problemas debido a los
excesos de costos continuos que apuntan a serias deficiencias en la capacidad de la agencia para supervisar sus
programas. El JWST es un gran telescopio espacial infrarrojo con un espejo plegable de 6.5 metros y un parasol
desplegable del tamaño de una cancha de tenis (véase la figura 8.1). Fue concebido en 1996 como sucesor del
famoso telescopio espacial Hubble y es una herramienta sofisticada de la astrofísica moderna. El JWST está
diseñado para ser lanzado al espacio profundo, a un “punto gravitacionalmente estable”, localizado aproxi-
madamente a 1.5 millones de kilómetros de la Tierra.
Aunque los objetivos del JWST son loables, la realidad práctica es que el programa ha estado fuera de
control casi desde el principio, y a medida que avanza su ejecución se corre el riesgo de afectar el presupuesto
general de la NASA. Durante una conferencia de prensa, a finales de 2010, la NASA publicó los resultados de un
estudio independiente que encontró que el JWST tendrá un sobrecosto de 1,500 millones de dólares a la estima-
ción de 5,000 millones de dólares iniciales para la ejecución del ciclo de vida del proyecto y que el lanzamiento
Photoshot/Newscom

FIGURA 8.1  Telescopio espacial James Webb


Perfil de proyecto 259

del telescopio, previamente programado para junio de 2014, no se producirá antes de septiembre de 2015.
La NASA ha presupuestado 600 millones de dólares para la operación de los primeros cinco años del JWST. El
Independent Comprehensive Review Panel atribuyó el sobrecosto en el desarrollo del JWST a la mala gerencia y
a las reservas de fondos insuficientes, necesarias para desarrollar, lanzar y operar la misión de astronomía insig-
nia de la próxima generación.­
El resultado del control deficiente de costos por la NASA presenta un serio dilema: seguir apoyando el
desarrollo del JWST, en el que tanto se ha invertido, o utilizar el presupuesto disponible para mantener en
funcionamiento los sistemas de satélites que operan actualmente. Cada vez más se nota con mayor fuerza
que la NASA no puede cumplir ambos objetivos. Alan Stern, un exadministrador asociado del Science Mission
Directorate de la NASA, dice que el crecimiento del costo de JWST podría absorber hasta 1,100 millones de
dólares del presupuesto anual de la agencia para astrofísica, de los cuales 40% ya se ejecutó en el desarrollo
del JWST. “¿Vamos a desactivar todos los satélites de astrofísica existentes, eliminar el apoyo para el análisis
de los datos provistos por estos y para la construcción de todo lo demás, con tal de financiar el sobrecosto del
JWST?”, se preguntó Stern. “Esa es la pregunta que la comunidad de astrofísicos debe hacerse, y que la NASA
debería formularse.”
De acuerdo con el Science Mission Directorate, el Congreso debería adicionarle al presupuesto de la
NASA en 2011 cerca de 250 millones de dólares a los 444 millones de dólares que el JWST necesita para cumplir
la nueva fecha de lanzamiento programada en el 2015. Además, se estima que el proyecto JWST necesita 250
millones de dólares en 2012, adicionales al presupuesto de 380 millones de dólares proyectado por la NASA
para ese año. La meta de la NASA en el proyecto JWST, sin la debida supervisión y control de costos, está a
punto de afectar su capacidad operativa y pone en duda una vez más la capacidad de los organismos guberna-
mentales para implementar los controles adecuados sobre los presupuesto de los grandes proyectos.
2. Connecting for Health, el fracaso de la conexión electrónica de los registros médicos del sistema de salud
británico—En 2002, Inglaterra se embarcó en un ambicioso programa de apoyo al Sistema Nacional de Salud
(National Health System: NHS) hacia un único y sencillo sistema centralizado que con el apoyo de las tecnolo-
gías de la información (information technology: IT) facilitaría la creación y el mantenimiento de los registros
médicos electrónicos de los pacientes, conectaría 30,000 médicos y 300 hospitales, proporcionaría acceso se-
guro y controlaría estos registros por los profesionales de la salud autorizados. Originalmente, se estimó el
costo de esta herramienta en 2,300 millones de libras esterlinas en tres años; en junio de 2006, la National
Audit Office estimó el costo total de la Connecting for Health en 12,400 millones de libras esterlinas durante
10 años, y la British Computer Society concluyó en 2006 que “los costos incurridos por NHS son tales que, hasta
ahora, la relación calidad/precio de los servicios desplegados es pobre.” Los funcionarios que participaron en
el programa, citados en los medios, estiman que el costo final para terminar el proyecto puede ser de 20,000
millones de libras esterlinas, lo cual indica un sobrecosto entre 440% y 770%.
Entre los problemas que el proyecto ha enfrentado están: el sistema no ha podido ofrecer unos beneficios
clínicos reales; la resistencia del personal de la salud para utilizar el sistema; riesgos altos para la seguridad de los
datos y un modelo “de transferencia del riesgo” que incluye un sistema de reembolso a los proveedores de la
tecnología solo cuando se demuestra que el problema se solucionó. En su conjunto, estos problemas ponen de
relieve un sistema informático que no se ha explicado claramente al público, no desempeña bien su papel, se re-
sista a los médicos, no es seguro y ha ido perdiendo credibilidad ante el público y el gobierno, en tanto los retrasos
en el cronograma y los costos siguen aumentando. En abril de 2007, el Public Accounts Committee of the House
of Commons publicó un informe de 175 páginas criticando el proyecto. El presidente del comité, Edward Leigh,
afirmó: “Este es el proyecto más grande de IT en el mundo y se está convirtiendo en el mayor desastre.” El informe
concluye que, a pesar de un gasto estimado en 20 mil millones de libras esterlinas, “al ritmo actual de progreso no
es probable que los beneficios clínicos significativos puedan entregarse a la terminación del contrato.”
Connecting for Health sigue tambaleándose entre largas demoras en el cronograma y aumentos en el
presupuesto. En esencia, el gobierno británico ha invertido mucho en el proyecto (dinero y prestigio personal)
para cancelarlo, pero carece de los medios para acelerarlo. Un informe del King Fund entregado en 2007 cri-
ticó al gobierno por la “aparente renuencia a auditar y evaluar el proyecto”; cuestionaba la falta de una estra-
tegia en la cual los beneficios compensen los costos. En un informe de 2009, el Public Accounts Committee of
the House of Commons denominó a los riesgos para la implementación exitosa del sistema “tan graves como
siempre”, y agregó que los resultados claves del proyecto estuvieron “fuera de ritmo”, y concluyó que “los
sistemas esenciales están atrasados o que si se despliegan, no colman las expectativas del personal clínico.”
3. El Virtual Case File del FBI—Originalmente iniciado en 2000, el proyecto Virtual Case File tenía como alcance la
automatización del entorno de trabajo basado en el papel del FBI para permitirles a los agentes y analistas de
inteligencia compartir información vital de investigación y sustituir el obsoleto sistema Automated Case Support
(ACS). Ante la exigencia del FBI, el contratista del proyecto VCF, Science Applications International Corp. (SAIC)
de San Diego, entregó 700,000 líneas de código llenas de defectos y funcionalmente fuera del objetivo, por lo
(continúa)
260 Capítulo 8  •  Estimación de costos y presupuesto

que a mediados de 2005 el FBI desechó los 170 millones de dólares del proyecto, incluido el código inservible
avaluado en 105 millones de dólares. Sin embargo, las diferentes administraciones y los informes independien-
tes indican que el FBI —que no tiene gerencia de IT ni conocimiento técnico—comparte la responsabilidad en el
fracaso del proyecto.
En una auditoría al proyecto realizada en 2005, el inspector general del Departamento de Justicia de
Estados Unidos identificó ocho factores que contribuyeron al fracaso del VCF. Entre estos se incluyen: la mala y
lenta definición de los requisitos de diseño; un cronograma excesivamente ambicioso y la falta de planes que
orientaran las compras de hardware; la instalación de redes y el desarrollo de software. El informe señaló que
“el arcaico sistema ACS—que algunos agentes evitan usar— es engorroso, ineficiente y limitado en su capa-
cidad y no logra vincular la investigación con el análisis y compartir información de forma eficaz y oportuna
según la necesidad. Los continuos retrasos en el desarrollo del VCF afectaron la capacidad del FBI para llevar a
cabo el cumplimiento de su misión clave.”
Infortunadamente, las cosas no han mejorado mucho. Después de desechar el proyecto VCF, el grupo del
FBI trabajó en un “nuevo y mejor” sistema de gerencia de casos llamado Sentinel. El proyecto Sentinel, que se
espera cumpla el papel originalmente asignado al cancelado VCF, fue adjudicado a Lockheed Martin. Con un
presupuesto de alrededor de 450 millones de dólares, el FBI espera haber aprendido de sus errores durante
la ejecución del VCF y ser capaz de trabajar con Lockheed para desarrollar rápidamente su sistema de regis-
tro. Por desgracia, a finales de 2010, el proyecto Sentinel estaba en tan mal estado como su predecesor. Tan
mal había quedado atrás el proyecto de presupuesto y el cronograma que el FBI despidió a Lockheed Martin
en septiembre y asumió el control del proyecto. La Oficina del Inspector General (OIG) del Departamento de
Justicia de Estados Unidos evalúo el nuevo Sentinel al final del año y emitió un informe muy crítico, en el cual
se puede leer: “Nuestra revisión encontró que en agosto de 2010, después de haber ejecutado alrededor de
405 millones de dólares de los 451 millones de dólares presupuestados para el proyecto Sentinel, el FBI ha
entregado a sus agentes y analistas solo dos de las cuatro fases de Sentinel.” El informe continúa: “Además,
creemos que el trabajo de desarrollo más difícil de Sentinel sigue sin hacerse. En julio de 2010 se esperaba que
Sentinel pudiera eliminar el uso de papel y generara y procesara de manera segura 18 formas relacionadas con
casos a través de proceso de revisión y aprobación. Hoy Sentinel solo tiene la capacidad de generar y procesar
4 de las 18 formas. Incluso estas cuatro formas aún no están totalmente automatizadas.”
El FBI rechaza enfáticamente el concepto que emitió la OIG sobre Sentinel, e insiste en que después de
despedir a Lockheed, es capaz de completar el proyecto dentro del presupuesto original y del marco de tiempo
estimado utilizando sus propios conocimientos especializados. Sin embargo, una evaluación independiente
llevada a cabo en julio de 2010, a petición del FBI, estimó que el desarrollo de Sentinel, con el enfoque actual,
tendrá como mínimo un costo adicional de 351 millones de dólares y necesitará 6 años más.1

8.1  GERENCIA DE COSTOS


La gerencia de costos es muy importante para la ejecución de proyectos exitosos. La gerencia de los costos, en
muchos aspectos, refleja las metas estratégicas de la organización del proyecto, la misión y el plan de negocios.
La gerencia de costos incluye la recopilación de datos, la contabilidad y el control de costos2 y consiste en tomar la
información de los reportes financieros y aplicarlo a los proyectos en el nivel finito de la rendición de cuentas, a
fin de mantener un sentido claro de la gerencia del dinero en el proyecto.3 La contabilidad de costos y el control de
costos constituyen las principales herramientas para identificar y mantener el control sobre los costos del proyecto.
La estimación de costos es el paso natural para determinar si un proyecto es viable, es decir, ¿puede
el proyecto generar rentabilidad? El proceso de estimación de costos crea la línea base del presupuesto del
proyecto e identifica los recursos (humanos y materiales), y elabora un presupuesto por fases de tiempo vin-
culadas al proyecto. De esta manera, la estimación de costos y el presupuesto del proyecto van de la mano:
las estimaciones de los costos de los diversos componentes del proyecto se desarrollan en un documento que
integra el presupuesto, lo cual permite el constante seguimiento y el control de costos del proyecto.
Durante la etapa de desarrollo de la propuesta, el contratista del proyecto inicia la estimación de cos-
tos mediante la identificación de todos los posibles costos asociados con el proyecto y la inclusión de estos
en la propuesta inicial. Mientras en un modelo simplificado de estimación de costos solo se requiere una
cifra global, la mayoría de clientes quiere ver un mayor detalle de identificar la forma en que el proyecto ha
estimado el precio, es decir, un desglose de todos los gastos pertinentes. Por ejemplo, un constructor puede
presentarle a un cliente potencial una lista de precios que muestra solo el costo total de la construcción de
la casa, pero probablemente el comprador pida un mayor desglose del precio para identificar en qué costos
se incurre. Algunas de las fuentes más comunes de los costos del proyecto son:
8.1  Gerencia de costos 261

1. Mano de obra—Los costos laborales se relacionan con la contratación y el pago de los distintos miem-
bros del personal que participan en el desarrollo del proyecto. Estos costos pueden llegar a ser com-
plejos, porque un proyecto requiere los servicios de varias clasificaciones de trabajadores (calificados,
semicalificados, operarios) en el tiempo. Como mínimo, una estimación de los costos del proyecto
debe tener en cuenta el personal que se va a emplear, el sueldo y las retribuciones y todo lo relacionado
con la seguridad social del empleado, como las pensiones o beneficios para la salud. Para hacer una
estimación preliminar razonable de los gastos de personal, se requiere determinar la dedicación del
personal al proyecto, según las horas comprometidas.
2. Materiales—Los costos de materiales se aplican a los equipos y materiales que el equipo del proyecto
requiere para completar las tareas del proyecto. En proyectos como los de construcción, los costos de mate-
riales son bastante altos e incluyen la madera, los revestimientos, el aislamiento, la pintura e incluso cosas
como la jardinería y la pavimentación. En otros proyectos, los costos de los materiales pueden ser relativa-
mente bajos; por ejemplo, la compra de un paquete de software que permite la compilación rápida de código
informático. Del mismo modo, muchos proyectos en el sector servicios puede implicar poco o nada en cos-
tos de materiales. En algunos proyectos, los costos de materiales se pueden cargar a los gastos generales de la
empresa; por ejemplo, el uso del computador central puede imputarse al proyecto con base en “su uso.”
3. Subcontratistas—Cuando los subcontratistas proporcionan recursos (y en el caso de los consultores,
experiencia) para el proyecto, sus costos deben tenerse en cuenta en la estimación preliminar de costos
del proyecto y, por tanto, se reflejan en el presupuesto. Un costo de subcontratista, por ejemplo, puede
ser un cargo para contratar el servicio de comunicaciones de marketing profesional para el diseño de
material promocional del proyecto o la estimación del costo de contratar un diseñador industrial para
el diseño de un empaque atractivo del nuevo producto.
4. Equipos e instalaciones—Algunos proyectos pueden desarrollarse fuera de las oficinas de la empresa,
lo cual requiere que los miembros del equipo del proyecto trabajen “fuera de las instalaciones.” Por
tanto, se deben incluir costos como el alquiler de equipos y el de instalaciones con cargo al proyecto.
Por ejemplo, las compañías petroleras habitualmente envían, durante periodos prolongados, equipos
de cuatro o cinco personas a trabajar en la sede de los principales subcontratistas. El alquiler de cual-
quier equipo o espacio de instalación se convierte en un costo del proyecto.
5. Viajes—Si es necesario, los gastos relacionados con los viajes de negocios (alquiler de autos, boletos de
avión, hoteles y comidas) pueden aplicarse al proyecto como un gasto por adelantado.
Otra forma de analizar los costos del proyecto es agruparlos por su naturaleza. Entre las diversas clases
de costos de un proyecto están los relacionados con el tipo (directo e indirecto), la frecuencia de ocurrencia
(recurrente y no recurrente), la posibilidad de ajustar (fijos o variables), y el cronograma de ejecución (nor-
mal o acelerado). A continuación, en este capítulo se analizan cada uno de estos costos.

Costos directos versus costos indirectos


Los costos directos Son aquellos que están claramente asignados a la actividad del proyecto que genera
el costo. El trabajo y los materiales son ejemplos de este tipo de costos. Todos los costos de mano de obra
asociados con los trabajadores que directamente construyen una casa se consideran costos directos. Sin
embargo, algunos costos de mano de obra no pueden considerarse costos directos del proyecto. Por ejemplo,
los costos de personal de apoyo, como el contador y en general los recursos de gerencia de proyectos, no se
pueden asignar directamente, sobre todo cuando sus funciones consisten en el mantenimiento o supervisión
de varios proyectos que se ejecutan de manera simultánea. En entornos distintos a los de proyectos, como los
procesos de manufactura, es común que los operarios se asignen directamente a las máquinas involucradas
en la línea de producción. En esos casos, los costos laborales se cargan a las órdenes de producción.
La fórmula para determinar los costos totales de mano de obra directa para un proyecto es sencilla:

(Tarifa de mano de obra directa) (horas totales trabajadas) = costo total de mano de obra directa

Los costos directos de materiales también son relativamente fáciles de calcular, siempre y cuando se tenga
una comprensión clara de los materiales necesarios para completar el proyecto. Por ejemplo, los costos direc-
tos de la construcción de un puente o de organizar una cena para un congreso de 300 personas, se pueden
estimar con bastante exactitud. Estos costos pueden cargarse directamente al proyecto de manera sistemá-
tica; por ejemplo, todas las órdenes de compra (OC) del proyecto se pueden registrar al recibir las facturas de
los materiales y cargarse al proyecto como un costo directo.
262 Capítulo 8  •  Estimación de costos y presupuesto

Los costos indirectos, por otra parte, normalmente se vinculan a dos aspectos: los costos generales, y la
venta y administración general. Los gastos generales son, quizá, la forma más común de los costos indirectos y
pueden ser una ser los más complejos de estimar. Los gastos generales incluyen todas las fuentes de materiales
indirectos, servicios públicos, impuestos, seguros, bienes inmuebles y reparaciones, depreciación de equipos y
los pagos por salud y pensión del personal del proyecto. Los gastos que comúnmente entran en la categoría de
venta y administración general incluyen publicidad, transporte, salarios, ventas y servicios de secretaría, comi-
siones de venta y costos similares. Identificar y vincular estos costos al proyecto no es tan sencillo como en los
costos directos, y los procedimientos utilizados varían según la organización. Algunas organizaciones estiman
una tarifa plana para todos los gastos generales, en relación con los costos directos del proyecto. Por ejemplo,
algunas universidades que llevan a cabo proyectos de investigación para el gobierno utilizan un porcentaje mul-
tiplicador para calcular los gastos administrativos y los gastos generales indirectos que se suma a los costos de
la propuesta. El rango normalmente usado para estimar el multiplicador de los costos indirectos fluctúa entre
20% y 50% del total de los costos directos. Otras empresas estiman los costos indirectos por proyecto basadas en
el análisis de cada propuesta. Cualquiera que sea el enfoque que se escoja, vale hacer hincapié en que todas las
estimaciones de costos del proyecto incluyen estimaciones de costos directos e indirectos.

EJEMPLO 8.1 Cálculo de los costos de mano de obra directa

Supongamos que estamos tratando de desarrollar una estimación razonable del costo de un programador
sénior en un proyecto de software. El programador tiene un salario anual de $75,000, que se traduce en una
tarifa por hora aproximada de $37.50/hora. Se espera que este programador trabaje unas 80 horas durante
todo el ciclo de vida del nuevo proyecto. Recuerde, sin embargo, que también hay que tener en cuenta los
gastos generales. Por ejemplo, la empresa paga los beneficios integrales de salud y pensión, cobra el uso
de maquinaria y equipo usado en el proyecto, y así sucesivamente. Para cubrir estos costos indirectos, la
empresa utiliza un multiplicador de 65%. El empleo de un multiplicador de gastos generales normalmente
se conoce como la tasa a costo máximo de la mano de obra directa. Por tanto, para presupuestar el costo de
este programador en el proyecto se procede de la siguiente manera:
Costo total de mano
Tarifa por hora Horas requeridas Multiplicador de obra directa
($37.50) ◊ (80) ◊ (1.65) = $4,950

Algunos autores sostienen que una estimación más realista de los costos totales de mano de obra directa
asignada al proyecto reflejaría el hecho de que nadie trabaja realmente un día completo de 8 horas, como parte
del trabajo. Una asignación de un grado razonable de tiempo personal durante la jornada de trabajo no es más
que el reconocimiento de la necesidad de hacer llamadas personales, tener descansos para tomar café, caminar
por los pasillos para ir al baño, y así sucesivamente. Meredith y Mantel (2003) afirman que si el tiempo personal
no está incluido en el cálculo del costo total del trabajo original, se debe usar un multiplicador de 1.12 para refle-
jar este costo, lo que aumenta el costo de mano de obra directa de nuestro programador sénior:4

Horas Tiempo Costo total de mano


Tarifa hora requeridas Multiplicador personal de obra directa
($37.50) ◊ (80) ◊ (1.65) ◊ (1.12) = $5,544

Otro punto para considerar en relación con la utilización de los gastos generales (costos indirectos) incluye
la forma en que los gastos generales se pueden cargar a las diferentes formas de contratación laboral. En
algunas empresas, por ejemplo, se hace una distinción entre los trabajadores asalariados y no asalariados.
Por tanto, se deben usar dos o más tipos de multiplicadores de gastos generales, dependiendo de la categoría
del personal a los que se aplican. Supongamos que una empresa aplica una tasa de gastos generales más baja
(35%) para los trabajadores por hora, lo cual refleja el menor costo de las contribuciones por pensión o salud.
El costo de mano de obra directa calculada para este personal (incluso asumiendo un cargo por tiempo de
personal) sería el siguiente:

Horas Tiempo Costo total de mano


Tarifa hora requeridas Multiplicador personal de obra directa
($12.00) ◊ (80) ◊ (1.35) ◊ (1.12) = $1,451.52
8.1  Gerencia de costos 263

CUADRO 8.1  Estimación preliminar de costos para la mano de obra directa

Costo total de
Salario Horas mano de obra
Personal Cargo (hora) requeridas Multiplicador directa
Linda Arquitecto lider $35/h 250 1.60 $14,000.00
Alex Dibujante—Junior $20/h 100 1.60 3,200.00
Jessica Diseñador—Temporal $8.50/h 80 1.30 884.00
Todd Ingeniero—Sénior $27.50/h 160 1.60 7,040.00
Thomas Capataz $18.50/h 150 1.30 3,607.50
Total $28,731.50

La decisión de incluir el tiempo personal requiere información del cliente del proyecto. Cualquiera que
sea el enfoque adoptado, al final del proceso se podrá contar con una tabla del presupuesto preliminar del
costo laboral total similar al cuadro 8.1. Este cuadro supone un proyecto pequeño con solo cinco personas en el
equipo del proyecto, cuyos costos de mano de obra directa se calculan sin tener en cuenta el tiempo personal.

Costos recurrentes versus costos no recurrentes


Los costos también pueden examinarse en cuanto a la frecuencia con que se producen, ya que pueden ser
recurrentes o no recurrentes. Los costos no recurrentes pueden ser los relacionados con las tarifas aplica-
das una vez al principio o al final del proyecto, como el análisis preliminar de marketing, la capacitación de
personal o los servicios de reinserción laboral. Los costos recurrentes suelen continuar causándose durante
todo el ciclo de vida del proyecto. La mayor parte del trabajo, de los materiales, de la logística y de los costos
de venta se consideran recurrentes debido a que se estiman cargos contra estos rubros en el presupuesto
durante una parte significativa del ciclo de vida del proyecto. En la gerencia del presupuesto y la estimación
de costos es necesario destacar los costos recurrentes frente a los no recurrentes. Como veremos, esto es
particularmente importante a medida que comenzamos a desarrollar presupuestos por etapas: aquellos pre-
supuestos que proyectan gastos previstos sobre la línea de base del cronograma.

Costos fijos versus costos variables


Una alternativa para la aplicación de los costos del proyecto es identificar en el presupuesto los costos fijos y
variables. Los costos fijos, como su nombre lo indica, no varían respecto a su uso.5 Por ejemplo, cuando se
arrienda un bien de capital u otro hardware usado en el proyecto, el valor del alquiler no varía en relación con
la cantidad que se use el equipo. Si se usa una máquina durante 5 o 50 horas, el costo de su alquiler es el mismo.
Al entrar en contratos de alquiler de equipos por tarifa fija, un aspecto importante en la decisión de los geren-
tes es si el equipo se utilizará lo suficiente como para justificar su costo. Los costos variables son aquellos que
aumentan a través del uso, es decir, el costo es directamente proporcional a la cantidad de uso del bien o del ser-
vicio. Supongamos, por ejemplo, que se utilizó una costosa pieza de equipo de perforación para una operación
minera. El equipo se degrada significativamente como resultado de su uso en un sitio particularmente difícil.
En este caso, los costos variables de la maquinaria están en proporción directa a su uso. Es común, en muchos
casos, que los proyectos tengan una serie de costos que se basan en tipos de cambio fijos y otros que son varia-
bles y que están sujetos a fluctuaciones significativas, tanto al alza como a la baja.

Costos normales versus costos acelerados


Los costos normales se refieren a los generados por la ejecución normal de trabajo para completar el pro-
yecto según el cronograma original previamente acordado al inicio del proyecto con todos los participantes.
Aunque el cronograma aprobado puede ser muy agresivo, lo cual implica grandes gastos adicionales con el
fin de cumplir con este cronograma, estos costos se basan en el plan normal del proyecto. Los costos acele-
rados son los costos no planeados en los que se incurre cuando se toman medidas para acelerar la realización
del proyecto. Por ejemplo, supongamos que el proyecto se ha retrasado y se toma la decisión de “compri-
mir” algunas actividades del proyecto, con la esperanza de recuperar el tiempo perdido. Entre los costos
para comprimir actividades se incluyen el uso de las horas extras, la contratación adicional de trabajadores
264 Capítulo 8  •  Estimación de costos y presupuesto

CUADRO 8.2  Clasificación de los costos

Tipo Frecuencia Uso Cronograma

No
Costos Directos Indirectos Recurrentes recurrentes Fijos Variables Normal Acelerado
Mano de X X X X
obra directa
Arriendo de X X X X
edificio
Costos X X X X
acelerados
Materiales X X X X

temporales, la contratación de recursos externos y de organizaciones de apoyo y la de incurrir en mayores


costos de transporte y logística para reducir los tiempos de entrega de materiales.
Todos los métodos anteriores para clasificar los costos se relacionan entre sí como se presenta en el cuadro
8.2.6 En la fila superior se muestran los diversos esquemas de clasificación, de acuerdo con el tipo de costo, la
frecuencia, el ajuste y al cronograma. La columna izquierda da algunos ejemplos de los costos incurridos en el
desarrollo de un proyecto. Aquí vemos cómo los costos normalmente pueden tener un sistema de clasificación
múltiple; por ejemplo, la mano de obra directa es un costo directo, que también es recurrente, fijo y normal. Por
otro lado, el arrendamiento de un edificio puede clasificarse como un costo indirecto (o general), recurrente, fijo
y normal. De esta manera, pueden aplicarse a la mayoría de los costos del proyecto múltiples clasificaciones.

8.2  ESTIMACIÓN DE COSTOS


La estimación de los costos del proyecto es un proceso difícil, que puede parecerse a una forma de arte como a
una ciencia. Para hacer las estimaciones de los costos de un proyecto se requiere tener en cuenta dos importan-
tes principios o leyes. El primero: si se definen con claridad desde el principio los diferentes tipos de costos del
proyecto, se reduce la posibilidad de cometer errores en la estimación. El segundo principio: cuanto más preci-
sas sean las estimaciones iniciales, mayor será la posibilidad de preparar un proyecto de presupuesto que refleje
fielmente la realidad de este y mayores serán las posibilidades de finalizar el proyecto dentro de las previsiones
presupuestarias.
La clave para desarrollar estimaciones de costos de un proyecto consiste en desglosar inicialmente los costos
del proyecto, es decir, dividir el proyecto por entregables y por paquetes de trabajo como método para la estimación
de costos a nivel de tarea. Por ejemplo, en lugar de de crear una estimación de costos para completar un entregable
conformado por cuatro paquetes de trabajo, suele ser más preciso primero identificar los costos para completar cada
paquete de trabajo individualmente y luego calcular el costo del entregable, como se muestra en el cuadro 8.3.
Las empresas utilizan distintos métodos para estimar los costos de un proyecto, que van desde la téc-
nica cuantitativa hasta enfoques más cualitativos. Entre los métodos más comunes de estimación de costos
están los siguientes:7
1. Estimaciones preliminares—A veces denominadas de orden de magnitud, las estimaciones aproxima-
das suelen utilizarse en los casos en que la información o el tiempo son escasos. Las empresas utilizan

CUADRO 8.3  Desagregación de las actividades del proyecto para crear una estimación de costos razonable

Actividades del proyecto Estimación del costo


Entregable 1040—Preparación del sitio
  Paquete de trabajo 1041—Topografía $ 3,000
  Paquete de trabajo 1042—Instalación de servicios 15,000
  Paquete de trabajo 1043—Descapote 8,000
  Paquete de trabajo 1044—Remoción de escombros 3,500
Costo total del entregable 1040 $29,500
8.2  Estimación de costos 265

a menudo este método como estimaciones preliminares de las necesidades de recursos o para deter-
minar si es posible presentar una oferta competitiva para la realización de un proyecto. Por ejemplo,
un cliente puede enviar una solicitud de cotización (request for quote: RFQ) con un plazo muy corto
para la presentación de la respectiva oferta. La empresa tendrá entonces poco tiempo para hacer una
evaluación exacta de las cualificaciones o requisitos del solicitante, pero podrían solicitar estimaciones
aproximadas de su personal para determinar incluso si vale la pena hacer un análisis más detallado
para elaborar la oferta. La regla de oro no oficial para efectuar estimaciones aproximadas es apuntar a
una precisión de ± 30%. Con una varianza tan amplia como esta, debe quedar claro que las estimacio-
nes aproximadas no están destinadas a sustituir las estimaciones de costos más detalladas.
2. Estimados comparativos—Las estimaciones comparativas se basan en el supuesto de que los datos
históricos pueden utilizarse como marco de referencia para realizar estimaciones actuales para proyec-
tos similares. Por ejemplo, la Boeing Corporation emplea habitualmente un proceso conocido como
estimación paramétrica, en la que los gerentes efectúan estimaciones detalladas para los proyectos en
curso tomando como base información de trabajo ya realizado y aplicando un multiplicador que tiene
en cuenta el efecto de los aumentos de la inflación, la mano de obra, los materiales y de otros costos
directos relevantes. Esta estimación paramétrica, cuando se realiza con cuidado, le permite a Boeing
obtener estimaciones muy precisas del costo del trabajo por realizar y la preparación de presupuestos
detallados de los nuevos proyectos de desarrollo de aviones. Incluso en los casos en que la tecnología
es nueva o representa una mejora significativa respecto a las viejas tecnologías, a menudo es posible
obtener información valiosa sobre los costos probables de desarrollo, a partir de datos históricos.
Boeing no es la única empresa que ha empleado con éxito la estimación de costos paramétrica.
La figura 8.2 muestra una gráfica de la estimación paramétrica en relación con el desarrollo de la

Semanas hombre (miles) de diseño para la primera prueba

20

BAC-SNIAS Concorde
10
8
6
4

2
Boeing 747
Douglas DC-6
1
0.8
0.6
Boeing 707
0.4

0.2 Douglas DC-3

0.1
0.08
0.06
Fokker VII Junkers Ju 52/3m
0.04
de Havilland DH 4

0.02

0.01
10 20 40 60 80 100 200 400 600 1000 2000
Velocidad de crucero
FIGURA 8.2  Estimaciones paramétricas de los costos de diseño del Concorde
Nota: relación entre el esfuerzo de diseño y la velocidad de crucero de las aeronaves co-
merciales más importantes.
266 Capítulo 8  •  Estimación de costos y presupuesto

aeronave Concorde en la década de 1960. El Concorde representó un diseño del fuselaje único e inno-
vador que era difícil estimar el tiempo de diseño requerido para completar los planos del avión. Sin
embargo, el uso de la estimación paramétrica con base en la experiencias del desarrollo reciente de
otras aeronaves permitió descubrir una relación lineal entre el número de semanas de todo el personal
(Concorde se refirió a este tiempo como “semanas hombre”) necesarias para el diseño de la aeronave
y la velocidad de crucero requerida. Es decir, la gráfica muestra una relación directa entre la velocidad
de crucero de la aeronave y la cantidad de tiempo requerida en el diseño para completar los planos.
Con estos valores, es posible hacer una proyección de costos razonablemente exacta del presupuesto
previsto para el diseño, lo cual demuestra que a pesar de los cambios significativos en el diseño de
aviones durante las últimas décadas, la relación entre la velocidad de crucero y el esfuerzo de diseño se
había mantenido constante.
Las estimaciones comparativas efectivas dependen de algunas fuentes complementarias impor-
tantes, incluidos un historial de proyectos similares y un archivo detallado de los datos del proyecto
que involucra información técnica, de presupuesto y de costos. Los ajustes de los costos para tener
en cuenta la inflación se convierten simplemente en un paso necesario del proceso. La clave para
hacer estimaciones comparativas precisas radica en qué tan comparable es el proyecto anterior. No
tiene sentido comparar los costos de mano de obra directa para dos proyectos cuando el original fue
hecho en otro país con diferentes niveles salariales, gastos generales, y así sucesivamente. Aunque
algunos sostienen que la estimación de costos comparativos tiene un grado de precisión de ± 15%, en
algunas circunstancias, esta estimación puede ser mucho más precisa y útil de lo que esa cifra indica.
3. Estimaciones de factibilidad—Estas estimaciones se realizan a partir de las cifras derivadas de la
fase preliminar de planeación del trabajo del proyecto. Después del desarrollo inicial del alcance, es
posible solicitar cotizaciones de los proveedores y subcontratistas con un mayor grado de confianza,
particularmente respecto a algunos procesos generales de planeación para comenzar a determinar la
línea base de trabajo del proyecto. Las estimaciones de factibilidad se utilizan habitualmente en los
proyectos de construcción, donde hay tablas de costos de materiales que pueden dar estimaciones
razonablemente exactas del costo de un amplio abanico de actividades de los proyectos con base en
la estimación de las cantidades. Debido a que se desarrollan en una etapa más avanzada del ciclo de
vida del proyecto, las estimaciones de factibilidad tienen a menudo un grado de exactitud de ± 10%.
4. Estimaciones definitivas—Estas estimaciones solo se pueden obtener en una etapa avanzada de la
planeación del proyecto, en el momento en que el alcance y las especificaciones del proyecto están
suficientemente bien entendidas. En este punto, todas las órdenes de compra se han presentado
con base en los precios y la disponibilidad conocida de los recursos, hay poco o ningún margen de
maniobra en las especificaciones del proyecto, las etapas para la terminación del proyecto han sido
identificadas y un plan completo del proyecto está en ejecución. Dado que la estimación de costos
puede mejorar con el tiempo, a medida que más información está disponible y menos incógnitas
siguen sin resolver, se espera que las estimaciones definitivas reflejen con precisión el costo esperado
del proyecto a su terminación, salvo, claro está, circunstancias imprevistas. Por tanto, se espera que
las estimaciones definitivas tengan una precisión de ± 5%. Vimos en capítulos anteriores que algu-
nos proyectos pueden ofrecer márgenes de utilidad mínimos; por ejemplo, en el caso de los contra-
tos de costo fijo, la organización del proyecto asume casi todo el riesgo de completar el proyecto de
acuerdo con los términos del contrato originalmente acordados. En consecuencia, cuanto mejor sea
el trabajo que hagamos en la estimación de costos, más probable será lograr el margen de utilidad
pactado en el contrato.
¿Qué enfoque de estimación de costos debe emplear la organización del proyecto? La respuesta a esta pregunta
presupone el conocimiento de la industria de la empresa (por ejemplo, desarrollo de software frente a la cons-
trucción), la capacidad de identificar y administrar la mayoría de las variables de costos del proyecto, la historia
de la empresa en gerencia de proyectos exitosos, el número de proyectos similares que la empresa ha realizado
en el pasado, el conocimiento y la habilidad del gerente del proyecto y los requisitos del presupuesto de la
empresa. En algunos casos (por ejemplo, los proyectos de investigación y desarrollo extremadamente innova-
dores) es imposible crear estimaciones de costos con un grado de exactitud menor a ± 20%. En contraste, en
algunos proyectos, como la organización de eventos (por ejemplo, la gerencia de una conferencia y el banquete
respectivo), puede ser razonable esperar presupuestos definitivos en una etapa temprana del proyecto.
La clave en la estimación de costos está en una evaluación realista del tipo de proyecto que se lleva a cabo,
la velocidad con la que se deben crear varias estimaciones de costos y en que la alta gerencia esté satisfecha con
8.2  Estimación de costos 267

HOJA DEL PRESUPUESTO ESTIMADO


Proyecto No. Descripción Tipo No.
Paquete de trabajo No. Tarea No. Estimación No.
Descripción del Descripción de
paquete de trabajo: la tarea:
Personal
Cargo Categoría Tasa Horas Costo
Ingeniero sénior de pruebas TE4 18.50 40 $   740.00
Ingeniero de pruebas TE3 14.00 80 1,120.00
Instalador PF4 13.30 30 399.00
Asistente DR2 15.00 15 225.00
Dibujante DR3 16.50 3 49.50
Subtotal, horas y costos 168 $2,533.50
Imprevistos (10%) 17 254.00
Total personal horas y costos 185 $2,787.50
Gastos generales (80%) 2,230.00
Costo bruto del personal $5,017.50
Costo de adquisiciones
Materiales (especificar): tornillos y elementos de limpieza $ 20.00
Productos terminados (especificar): N/D
Servicios e enstalaciones: alquiler del local de pruebas; 12,300.00
reporte de instrumentos
Subcontratación (especificar): modificación e instalación de pernos 250.00
Subtotal $12,570.00
Imprevistos (15%) 1,885.50
Total costo de adquisiciones $14,455.50
Gastos
Especificar: viáticos y transporte $ 340.00
Total costos de adquisiciones y gastos $14,795.50
Utilidad %: N/D
Presupuesto total: personal más costo de adquisiciones y gastos $19,813.00
Elaborado por:
Aprobado: Fecha

CUADRO 8.4  Ejemplo de una hoja de estimación de costos de las actividades del proyecto

el margen de error de la estimación del costo. Si la información está disponible, es razonable esperar que el
equipo del proyecto proporcione una estimación de costos muy precisa en una fase lo más temprana posible del
proyecto. El cuadro 8.4 muestra un ejemplo de formulario para la estimación de costos del proyecto.

Curvas de aprendizaje en la estimación de costos


La estimación de costos, especialmente cuando se refiere a las horas de trabajo, a menudo supone que el
trabajo se realiza a un ritmo constante o uniforme. Si hay que realizar múltiples actividades, la cantidad de
tiempo requerido para completar la primera actividad no es significativamente diferente del tiempo nece-
sario para completar la actividad enésima. Por ejemplo, en el desarrollo de software, es práctica estándar
estimar el costo de cada actividad de forma independiente de otras actividades relacionadas con la que está
268 Capítulo 8  •  Estimación de costos y presupuesto

implicado el programador. Por tanto, si un programador requerido para completar cuatro asignaciones de
trabajo que implican diferentes actividades de codificación similares, la mayoría de los estimadores de cos-
tos simplemente aplican el multiplicador de la regla del dedo pulgar:

Número de veces que la


Costo de la actividad actividad se repite Costo total estimado
($8,000) ◊ (4) = $32,000

Cuando estimamos que cada actividad de codificación tiene aproximadamente 40 horas de trabajo, podemos
crear de manera más formal la base del presupuesto del costo directo de este recurso. Suponiendo una tasa de
gastos generales del 0.60 y un costo por hora por los servicios del programador de $ 35/hora, podemos llegar
a un cargo de facturación directa de:

Salario Unidades Tasa de gastos generales Horas/actividad


($35/h) ◊ (4 iteraciones) ◊ (1.60) ◊ (40 horas) = $8,960

Aunque esta regla de oro es simple, también puede ser simplista. Por ejemplo, ¿es razonable suponer que en
la realización de actividades similares, el tiempo necesario para hacer por cuarta vez una rutina de codifica-
ción tomará el mismo tiempo que se tardó en efectuarla la primera vez? ¿O es más razonable suponer que el
tiempo necesario (y, por tanto, el costo) de la cuarta iteración debería ser un poco más corto que los tiempos
de las iteraciones anteriores?
Estas preguntas son el meollo de la discusión de cómo las curvas de aprendizaje afectan la estimación
de costos del proyecto.8 En resumen, la experiencia y el sentido común nos enseñan que la repetición de las
actividades a menudo conduce a la reducción del tiempo para completar esa actividad. Algunas investigacio-
nes, de hecho, apoyan la idea de que el rendimiento mejora en un porcentaje fijo cada vez que la producción
se duplica.9
Supongamos que el tiempo necesario para codificar una rutina de software se estima en 20 horas
de trabajo para la primera iteración. Hacer el trabajo de codificación por segunda vez requiere solo 15
horas. La diferencia entre la primera y la segunda iteración sugiere una tasa de aprendizaje de .75 (15/20).
Podemos aplicar esa tasa de aprendizaje para hacer las estimaciones de los costos de las iteraciones adi-
cionales de codificación. Si la producción se duplicó, pasando de los dos desarrollos iniciales a los cuatro
requeridos por el cliente, podemos estimar el tiempo necesario para completar la cuarta iteración de la
siguiente manera:

15 horas  (.75) = 11.25 horas

Estas estimaciones de tiempo y de costos siguen una fórmula definida,10 que es el tiempo requerido para
alcanzar el punto de equilibrio en la producción, y se representa como:

Yx = aX b
Donde
Yx = tiempo requerido para alcanzar el punto de equilibrio en x unidades de producción.
a = tiempo requerido para la unidad inicial de salida.
 X = número de unidades que se producen al alcanzar el punto de equilibrio.
b = pendiente de la curva de aprendizaje, representado como tasa de aprendizaje decimal log/log 2.
Supongamos la necesidad de llevar a cabo una estimación de costos en un proyecto de construcción,
en el que un recurso tendrá la tarea de realizar múltiples repeticiones de un mismo trabajo (por ejemplo,
instalar, remachar o ajustar). Un trabajador tiene que hacer 15 veces una actividad para alcanzar un estado
de equilibrio en el rendimiento. Supongamos también que el tiempo estimado para realizar la última ite-
ración (estado de equilibrio) es 1 hora, y sabemos por experiencia que la tasa de aprendizaje para esta
actividad altamente repetitiva es .60. Al calcular el tiempo necesario para completar la primera actividad,
queremos aplicar estos valores en la fórmula para determinar el valor de a, que es el tiempo necesario para
completar la tarea por primera vez:
8.2  Estimación de costos 269

b = log 0.60/log2
=- 0.2219/0.301
=- 0.737

1 h = a (15) -0.737
a = 7.358 horas

Tenga en cuenta que la diferencia entre la primera y la decimoquinta iteración de esta actividad representa
un cambio en la estimación de la duración (y por tanto del costo) de más de 7 horas para la primera vez que
la tarea se efectúe a 1 hora para el estado de equilibrio. La diferencia en el rendimiento de la curva de apren-
dizaje hace que las estimaciones de los costos del proyecto sean grandes, sobre todo cuando un proyecto
incluye numerosos casos de trabajos repetitivos o grandes “corridas de producción” de actividades similares.

EJEMPLO 8.2 Estimación de la curva de aprendizaje

Volvamos al ejemplo anterior, en el que estamos tratando de determinar el costo real del tiempo del progra-
mador sénior. Recordemos que se encontró la primera estimación lineal, en la que no se hizo ajuste alguno
por el efecto de curva de aprendizaje; teníamos:

($35/h)  (4 iteraciones)  (1.60)  (40 horas) = $8,960

Ahora podemos aplicar alguna información adicional a esta estimación de costos, con base en un mejor
conocimiento del efecto de la tasa de aprendizaje. Supongamos, por ejemplo, que se encontró que la tasa de
aprendizaje de este programador es .90. El tiempo de estado de equilibrio para la programación de esta tarea
es 40 horas por iteración. Nuestra estimación del tiempo necesario para la primera iteración de este trabajo
de programación es:

b = log 0.90/log2
=- 0. 0458/0.301
=- 0.1521

40 horas = a (4) -0.1521


a = 49.39 horas

Por tanto, para el primer desarrollo se necesitan 9.39 horas más que el estado de equilibrio estimado en 40
horas. En este ejemplo de programación, podemos determinar la unidad adecuada y los multiplicadores de
tiempo total para la unidad de tiempo inicial consultando las tablas de coeficientes de la curva de aprendi-
zaje (multiplicadores) derivados de la fórmula, haciendo a = 1. También podemos calcular la unidad y el
tiempo total de multiplicadores identificando el multiplicador de la unidad de tiempo, las unidades 1 a 3 de
producción (secuencias de programación), con una tasa de aprendizaje de 0.90. Utilizamos las iteraciones
1 a 3 porque suponemos que para la cuarta iteración el programador ha alcanzado el tiempo de estado de
equilibrio de 40 horas. Si a = 1, los coeficientes de las unidades de tiempo de la curva de aprendizaje son
1 – 0.5121 = 1, 2 – 0.1521 = 0.90, y 3 – 0.1521 = 0.846, para un multiplicador de tiempo total de 2.746. Por tanto,
el tiempo necesario para codificar las tres primeras secuencias es:

Multiplicador de Tiempo requerido Tiempo total de programación


tiempo total para la unidad inicial primeras tres secuencias
(2.746) ◊ (49.39) = 135.62 horas

Debido a que el tiempo de estado de equilibrio de 40 horas se logra en la iteración final de codificación, el
tiempo total requerido para la codificación de todas las cuatro secuencias es:

135.62 + 40 = 175.62
270 Capítulo 8  •  Estimación de costos y presupuesto

El costo de mano de obra directa más preciso para esta actividad de codificación es:

Salario Tasa de costos generales Total horas


($35/h) ◊ (1.60) ◊ (175.62 horas) = $9,834.72

Compare esta cifra con el valor original de $8,960 que habíamos calculado inicialmente, lo cual subestima el costo
de programación en $874.72. La segunda cifra, que incluye una provisión por efectos de la curva de aprendizaje,
representa una estimación más realista del tiempo y los costos necesarios para que el programador complete las
actividades del proyecto.

En algunas industrias es posible seguir el costo de las actividades repetitivas para ajustar con precisión
la estimación de costos de la curva de aprendizaje. Tenga en cuenta la curva de tiempo relativo (o costos) con
repetición de actividades que se muestra en la figura 8.3.11 El efecto de curva de aprendizaje aquí muestra
un ahorro de tiempo en función de la repetición de actividades que se encuentran en muchos proyectos.
Algunos libros de gestión de operaciones ofrecen tablas que muestran el multiplicador de tiempo total, con
base en los valores de la velocidad de aprendizaje, multiplicado por el número de repeticiones de una acti-
vidad.12 El uso de estos multiplicadores ahorra la necesidad de hacer revisiones significativas a la baja en la
estimación de los costos para incluir el efecto de curva de aprendizaje. Sin embargo, hay una salvedad: efectos
de curva de aprendizaje pueden ocurrir diferencialmente entre proyectos; los proyectos con trabajo repe-
tido pueden permitir el uso de los multiplicadores de la curva de aprendizaje, mientras otros proyectos con
trabajo más variado no. Del mismo modo, probablemente veamos los efectos de la aplicación de la curva de
aprendizaje en mayor proporción en proyectos de algunas industrias (por ejemplo, la construcción) que en
otras (como la investigación y el desarrollo). En últimas, los presupuestos de los proyectos deben ajustarse en
las actividades en las cuales los efectos de la curva de aprendizaje tengan mayor probabilidad de ocurrencia,
teniendo en cuenta estos impactos en las estimaciones de los costos por actividad.
Cada vez, con mayor frecuencia, los contratos de proyectos reflejan el efecto de las curvas de apren-
dizaje en las operaciones repetitivas. Por ejemplo, en la industria automotriz, los fabricantes de cilindros
hidráulicos pueden aceptar un contrato para proporcionar cilindros a un precio para el primer año de $24
cada uno. A partir del segundo año, el costo del cilindro se reduce en $1 por año, con el supuesto de que las
curvas de aprendizaje le permitirán al fabricante del cilindro producir el producto a un costo cada vez menor.
Por tanto, las curvas de aprendizaje se tienen en cuenta en el valor de los contratos a largo plazo.13

50

40
Tiempo (costo)

30

20

10

0
0 20 40 60 80 100
Repeticiones
FIGURA 8.3  Curva de aprendizaje modelo relación log Lineal
Fuente: J. P. Amor and C. J. Teplitz. (1998). “An efficient ap-
proximation for project composite learning curves,” Project
Management Journal, 29(3), pp. 28–42, figura de la página
36. Copyright © 1998 de Project Management Institute
Publications. Derechos de autor y todos los derechos reserva-
dos. El material de esta publicación ha sido reproducido con
permiso del PMI.
Nota: gráfica en coordenadas aritméticas.
8.2  Estimación de costos 271

Estimación de proyectos de software—Puntos de función


La evidencia presentada en el capítulo 1 y en el recuadro 8.1 (estimación de costos de desarrollo de software)
pone de relieve las dificultades de desarrollar estimaciones realistas para grandes proyectos de software. El
historial no es alentador: con mayor frecuencia los proyectos de software sobrepasan en gran medida las

RECUADRO 8.1

INVESTIGACIÓN DE GERENCIA DE PROYECTOS EN SÍNTESIS


Estimación de costos de desarrollo de software
La industria de proyectos de software ha desarrollado una reputación notoria cuando se trata de rendimiento
del proyecto. Una investigación realizada por Standish Group14 sugiere que en las grandes empresas, menos
de 9% de los proyectos de IT se terminó dentro del tiempo y el presupuesto originalmente estimados. Más
de 50% de estos proyectos tuvieron una sobreejecución presupuestaria de 189% y 202% en lo que a sobre
tiempo empleado se refiere. Evidentemente, tanto desde la perspectiva de la estimación de los costos como
del cronograma, la industria se frustra por las expectativas poco realistas de estas estimaciones. A pesar de
las recientes mejoras en la estimación de costos, cronograma y esfuerzo necesario para desarrollar software,
logrados con el uso del modelo de estimación constructiva de costos (Constructive Cost Estimating: COCOMO
II), exigido en las licitaciones del gobierno norteamericano, nuestra falta de habilidad para predecir con preci-
sión los costos del proyecto de software sigue siendo una grave preocupación.15
En un libro escrito por Steven McConnell, presidente de Construx Software,16 se arrojan a la luz algunas de
las principales razones por las cuales los proyectos de software registran tan pobres resultados. Entre sus hallaz-
gos, la causa más común es la falta de un adecuado presupuesto de tiempo y financiación de las actividades del
proyecto, que varían considerablemente, dependiendo del tamaño del proyecto. Él divide en seis etapas los pro-
yectos de desarrollo de software: (1) arquitectura; (2) diseño detallado; (3) codificación y depuración; (4) pruebas
del desarrollador; (5) la integración; y (6) las pruebas del sistema. McConnell determinó que en los pequeños
proyectos de IT de 2,000 líneas de código o menos, 80% del trabajo del proyecto consistió en tres etapas: diseño
detallado, codificación y depuración y pruebas de unidad (véase la figura 8.4). Sin embargo, a medida que la
complejidad de los proyectos de software aumenta, la participación de estas actividades en el costo global del
proyecto se reduce drásticamente. Los proyectos de más de 128,000 líneas de código requieren más atención en
etapas como la arquitectura, la integración y las pruebas del sistema (cerca de 60% del esfuerzo total).
Esta investigación implica que los presupuestos de los proyectos de IT deben considerar el tamaño
del proyecto en el momento en que se calculan los costos de cada componente (paquete de trabajo).
Los proyectos grandes que requieren cientos de miles de líneas de código necesitan que una mayor pro-
porción del presupuesto se asigne a las etapas de arquitectura de software y pruebas, en relación con el
costo de desarrollo (diseño, codificación y pruebas del programador).

100%
Sistema de prueba

Integración
Unidad de prueba
Porcentajes de
tiempo de
desarrollo Codificación y depuración Construcción

Diseño detallado
Arquitectura
0%
2K 8K 32K 128K 512K
Tamaño del proyecto en líneas de código

FIGURA 8.4  Actividades de los proyectos de desarrollo de software en función del tamaño
Fuente: Tomado de Code Complete, 2d ed. (Microsoft Press, 2004), Steve McConnell. Usado
con permiso del autor.
272 Capítulo 8  •  Estimación de costos y presupuesto

estimaciones del cronograma y de costos. Una de las razones se debe simplemente a la incertidumbre de la
naturaleza de estos proyectos. Podemos hacer estimaciones del costo, pero sin una clara idea de la naturaleza
del software, de su tamaño y funcionalidad; estas son a menudo solo buenas conjeturas que rápidamente nos
damos cuenta de que son inadecuadas.
Análisis de puntos de función es un sistema para estimar el tamaño de los proyectos de software basado
en lo que hace el software. Para desarrollar un sistema, se necesita tiempo para crear archivos que contienen
información y las interfaces con otras pantallas (archivos e interfaces). También se necesita crear pantallas de
entrada (inputs), pantallas de consulta (consultas) e informes (outputs). Si se cuentan todos los archivos, interfa-
ces, entradas, consultas y resultados, se puede calcular la cantidad de trabajo por realizar. Esta medida entonces
se relaciona directamente con los requisitos del negocio que el software debe cumplir. Por tanto, se puede apli-
car fácilmente a una amplia gama de entornos de desarrollo y al ciclo de vida del proyecto de desarrollo, desde
la etapa temprana de definición de los requisitos hasta la entrega para su uso operacional.
En pocas palabras, los puntos de función son una unidad de medida estándar que representa el tamaño fun-
cional de una aplicación de software. De la misma manera que el tamaño de una casa se mide en metros cuadrados,
el tamaño de una aplicación se puede medir por el número de puntos de función que les ofrece a los usuarios de la
aplicación. Es importante tener en cuenta que el tamaño de la aplicación se mide con base en la visión del usuario
del sistema. Se basa en lo que el usuario pide, no lo que se entrega, y en la manera en que el usuario interactúa con
el sistema, incluidos las pantallas que el usuario accede para ingresar datos y los informes que recibe de salida.
Sabemos que se necesitan diferentes cantidades de tiempo para construir diferentes funciones; por ejemplo,
puede tomar el doble de tiempo construir una tabla de interfaz que una tabla de entrada. Una vez que tenemos una
idea general de los tiempos relativos de cada una de las funciones del sistema, debemos tener en cuenta factores
adicionales para ponderar estas estimaciones. Estas ponderaciones se basan en factores de “complejidad técnica” y
“complejidad ambiental.” Complejidad técnica evalúa la complejidad de la aplicación que se construirá. ¿Estamos
desarrollando un modelo complejo para determinar los múltiples caminos de satélites en órbita geoestacionaria o
estamos simplemente creando una base de datos de nombres y direcciones de clientes? La complejidad ambiental
se refiere a la naturaleza del entorno en el que el sistema está diseñado para trabajar. ¿Va a apoyar a un solo usuario
en un equipo o va estar en una terminal colgado a una red externa? ¿Qué lenguaje de programación se usará para
escribir la aplicación? Un lenguaje relativamente simplificado y común, como Visual Basic, requiere menos tra-
bajo que un lenguaje más complejo y, en consecuencia, podemos suponer que los programadores serán más pro-
ductivos (generar más puntos de función). Una vez los puntos de función se ajustan por factores de complejidad,
se suman para determinar una estimación razonable del costo del desarrollo del software.
Tomemos un ejemplo sencillo. Supongamos que un restaurante local contrató con nuestra firma el
desarrollo de un sistema de pedidos de reposición que garantice que en todo momento se mantengan los
niveles mínimos de alimentos y bebidas. El restaurante quiere que la aplicación tenga un número razonable
de pantallas de entrada y de salida, un pequeño número de opciones de consulta e interfaces, pero grande
y detallada capacidad de generación de informes. Además, sabemos por experiencia que el trabajo de un
programador durante un mes (una “persona-mes”) en nuestra empresa puede generar un promedio de 10
puntos de función. Por último, con base en los antecedentes de nuestra empresa, tenemos un conjunto de
coeficientes técnicos y ambientales de sistemas con complejidad media que podemos aplicar en todas las
funciones (véase el cuadro 8.5). Por ejemplo, sabemos que en la construcción de una función de entrada para
la aplicación de un sistema de alta complejidad es aproximadamente tres veces más complicado (y requiere
más esfuerzo) que uno con baja complejidad.

CUADRO 8.5  Ponderación de la complejidad para el análisis de puntos de función

Complejidad ponderada

Función Baja Media Alta Total


Número de entradas 2 ◊ _____ = 4 ◊ _____ = 6 ◊ _____ =
Número de salidas 4 ◊ _____ = 6 ◊ _____ = 10 ◊ _____ =
Número de interfaces 3 ◊ _____ = 7 ◊ _____ = 12 ◊ _____ =
Número de consultas 5 ◊ _____ = 10 ◊ _____ = 15 ◊ _____ =
Número de archivos 2 ◊ _____ = 4 ◊ _____ = 8 ◊ _____ =
8.2  Estimación de costos 273

Con esta información, podemos aplicar los requisitos del sistema del cliente para construir una estimación
de puntos de función para el proyecto. Supongamos que determinamos (a partir de las entrevistas con los pro-
pietarios de restaurantes) que la estimación de la complejidad relativa fue entradas (media), salidas (alta), inter-
faces (baja), consultas (media) y archivos (baja). Además, sabemos que los clientes requieren el siguiente número
de cada función: pantallas de entrada (15), pantallas de salida (20), interfaces (3), consultas (6) e informes (40).
Combinamos esta información con nuestros coeficientes históricos de complejidad para crear el cuadro 8.6.
El cuadro 8.6 muestra los resultados de la combinación de nuestras estimaciones de la complejidad de
las diversas funciones del programa, de acuerdo con los requisitos del cliente, como el número de pantallas y
otros elementos de cada función. El resultado de nuestra estimación es que el proyecto requerirá aproxima-
damente 409 puntos de función. Sabemos que nuestra organización estima que cada recurso puede realizar
10 puntos de función “persona-mes.” Por tanto, se calcula el número esperado de personas-mes para com-
pletar este trabajo como 409/10 = 40.1. Si le asignamos solo cuatro programadores a este trabajo, se necesi-
tarían unos 10 meses. Por el contrario, si asignamos los 10 programadores disponibles en nuestra empresa,
se esperaría que el trabajo se complete en poco más de cuatro meses. La estimación de costos utilizando esta
información es sencilla: si el costo promedio de recursos por programador es de $5,000/mes, multiplicamos
esta cifra por 40.1 y determinamos que el costo estimado para completar el trabajo es $200,500.
El análisis de puntos de función no es una ciencia exacta. La determinación de la complejidad se basa en
estimaciones históricas que cambian con el tiempo y, por tanto, deben actualizarse continuamente. Además,
puede que no sean comparables entre entre organizaciones con diferentes procedimientos de estimación y
normas para determinar la complejidad técnica. Sin embargo, el análisis de puntos de función sí les ofrece a
las organizaciones un sistema útil para el desarrollo de estimaciones de costos para proyectos de software, un
tipo de proyectos históricamente difícil de estimar con precisión.17

Problemas en la estimación de costos


A pesar de los mejores esfuerzos de la gerencia del proyecto, una serie de cuestiones afecta la capacidad de
realizar estimaciones razonables y exactas del costo del proyecto. Los proyectos altamente innovadores son
muy difíciles de estimar en costos. Sin embargo, sorprende incluso que proyectos tradicionalmente consi-
derados como altamente estructurados, como los proyectos de construcción, son susceptibles a sobrecostos.
Entre las razones más comunes de los excesos de costos están las siguientes:18
1. Bajas estimaciones iniciales—Causadas por una percepción errónea del alcance del proyecto, las bajas
estimaciones iniciales son una espada de doble filo. Al proponer estimaciones bajas al inicio del pro-
yecto, la gerencia prepara a menudo su propia imposibilidad de cumplir las restricciones impuestas al
presupuesto. Por tanto, estimaciones bajas, que pueden hacerse de manera consciente (por la creencia
de que la alta gerencia no financiará un proyecto demasiado costoso) o involuntariamente (por error
o simple negligencia), casi siempre garantiza que el resultado sea un sobrecosto. Una parte de la razón
por la que las estimaciones iniciales pueden ser bajas es no considerar el proyecto en relación con otras
actividades de la organización. Si simplemente nos limitamos a costear las diversas actividades del pro-
yecto, sin tener en cuenta las actividades del entrono organizacional, no será posible asumir un tiempo
realista para que los miembros del equipo del proyecto puedan ser capaces de realizar las actividades en
un tiempo realista. (Véase el capítulo 11 sobre el cronograma de la cadena crítica del proyecto).

CUADRO 8.6  Cálculos con puntos de función del sistema de reórdenes para restaurante

Complejidad ponderada

Function Baja Media Alta Total


Número de entradas 4 ◊ 15 = 60
Número de salidas 10 ◊ 20 = 200
Número de interfaces 3◊3= 9
Número de consultas 10 ◊ 6 = 60
Número de archivos 2 ◊ 40 =  80
Total 409
274 Capítulo 8  •  Estimación de costos y presupuesto

Las bajas estimaciones también pueden ser el resultado de una cultura empresarial que premia
la subestimación. Por ejemplo, es común que en algunas organizaciones se crea que los sobrecostos no
afectan la carrera de un gerente de proyectos tanto como una falla técnica. Por esto, los gerentes de pro-
yectos subestiman drásticamente los costos del proyecto, con el fin de conseguir financiación para este,
usando de manera reiterativa los fondos de reserva y así poder continuar con la ejecución del proyecto,
con lo cual se logra eventualmente un producto con enormes sobrecostos. Las consideraciones políti-
cas también pueden ocasionar que los equipos de proyecto o la alta gerencia vean un proyecto a través
de lentes color rosa, lo cual minimiza las estimaciones iniciales de costos, sobre todo si atentan contra
los resultados esperados. El Denver International Airport es un buen ejemplo de una comunidad que
ignorar las señales de advertencia de las estimaciones de costos demasiado optimistas por el interés de
completar el proyecto. Los sobrecostos resultantes han sido enormes.
2. Problemas técnicos inesperados—Un problema común con la estimación de los costos asociados a
muchas de las actividades del proyecto es asumir que los problemas técnicos serán mínimos; es decir,
frecuentemente la estimación de costos parece decir: “Esta tarea con todas las cosas en condiciones
iguales, debe costar $XX.” Por supuesto, el resto de las cosas rara vez son iguales. Para que una esti-
mación tenga sentido, debe considerar la posibilidad de ocurrencia de problemas técnicos, retrasos
de puesta en marcha y otros riesgos técnicos. Es un hecho que las nuevas tecnologías, procedimien-
tos innovadores y avances de ingeniería habitualmente se acompañan de fallas de diseño, prueba y
aplicación. A veces, el efecto de estas dificultades es la pérdida de cantidad significativa de dinero;
otras veces las pérdidas son más trágicas, lo cual resulta en la pérdida de vidas. Por ejemplo, el avión
de transporte Boeing V-22 Osprey que emplea una tecnología radical denominada “tilt-rotor” fue
desarrollado para utilizarse por la Armada y los infantes de Marina de Estados Unidos. Durante las
prueba iniciales de los prototipos se identificaron fallas en el diseño que contribuyeron a la muerte
de los pilotos de pruebas.
3. Falta de definición—El resultado de la mala definición inicial del alcance, frecuentemente permite la
planeación de proyectos con una pobre definición de características, metas o incluso del propósito del
proyecto (véase el capítulo 5, Gerencia del alcance). Esta falta de visión clara del proyecto se manifiesta
inmediatamente en estimaciones de costos mal realizadas e inevitables sobrecostos. Vale la pena reco-
nocer que el proceso de estimación de costos y presupuesto del proyecto debe seguir la declaración
del alcance global y la estructura de desglose del trabajo. Cuando los primeros pasos se dan mal, estos
efectivamente hacen inútil cualquier intento de estimación razonable de los costos del proyecto.
4. Cambios en las especificaciones—Una de las pesadillas de la estimación de costos en la gerencia y el
control de proyectos son los cambios en las especificaciones en la mitad del proyecto (denominado
“scope creep”), a los que muchos proyectos son tan propensos. Los proyectos de tecnologías de la
información, por ejemplo, suelen estar llenos de peticiones de características adicionales, modifi-
caciones serias y actualización de procesos, aunque las actividades del proyecto estén todavía en
desarrollo. En presencia de cambios importantes en el alcance del proyecto o de sus especificaciones,
no extraña que muchos proyectos rebasen frecuentemente sus estimaciones iniciales de costos. En
efecto, en muchas empresas las estimaciones iniciales de costos pueden carecer totalmente de sen-
tido, sobre todo cuando estas tienen una bien ganada reputación por hacer ajustes sobre la marcha
en el alcance de los proyectos.
5. Factores externos—La inflación y otros fenómenos económicos ocasionan muchas veces serios sobre-
costos en las estimaciones del proyecto. Por ejemplo, ante una crisis financiera o una inesperada esca-
sez mundial de una materia prima, los costos estimados sin tomar en cuenta estas variaciones son
rápidamente superados. Para citar un ejemplo reciente, los enormes esfuerzos de industrialización y
modernización de China y de India, junto a la debilidad del dólar estadounidense, han impulsado el
precio del crudo a máximos históricos. Como el petróleo crudo se cotiza en dólares estadounidenses,
divisa que la Reserva Federal mantiene débil, ahora se necesitan más dólares para comprar petróleo.
Además, la demanda de petróleo de China e India ha provocado un aumento de los precios interna-
cionales. Un proyecto que requiera importantes suministros de petróleo crudo tendrá que recalcular al
alza un incremento significativo de su presupuesto, debido al costo de este recurso crítico. Otro efecto
externo que frecuentemente se presenta es el caso de los cambios políticos que se espera puedan ocurrir
en el transcurso del ciclo de vida del proyecto. Este fenómeno se manifiesta a menudo en los proyectos
del gobierno, particularmente en los contratos de suministros militares que tienen antecedentes de
sobrecostos, intervención gubernamental bajo la forma de comités de vigilancia, múltiples interesados
y numerosas solicitudes de cambio durante la ejecución del contrato.
8.2  Estimación de costos 275

RECUADRO 8.2

INVESTIGACIÓN DE GERENCIA DE PROYECTOS EN SÍNTESIS


”Engaños y decepciones” en los grandes proyectos de infraestructura
Esta debe ser la edad de oro de los proyectos de infraestructura. Un número de The Economist informó que
se estima en 22,000 millones de dólares el valor de los proyectos de infraestructura por ejecutar durante los
próximos diez años, por lo que el gasto en infraestructura “significa el mayor auge de la inversión en la histo-
ria.” Debido a este compromiso a largo plazo, en asocio con los enormes costos de estas obras, los gobiernos
y los agentes responsables del diseño y gerencia de estos proyectos deben hacer las cosas bien. En otras pala-
bras, hay demasiado en juego como para administrar mal los proyectos.
Lamentablemente, como los ejemplos anteriores de este capítulo lo evidencian, tanto el sector privado
como el sector público tienen un terrible historial en el desempeño, a la hora de gerenciar con éxito y cumplir
la costosa infraestructura y las metas de desempeño. Ejemplos como el de la Casa de la Ópera de Sidney (costo
original proyectado de 7 millones de dólares australianos, costo final de 102 millones de dólares), el Eurotúnel
(costos finales de más del doble de las proyecciones originales) y el “Big Dig” de Boston (costo original esti-
mado de 2,500 millones de dólares; costo final de casi 15,000 millones de dólares) siguen siendo la regla y no
la excepción cuando se trata de los resultados de los proyectos de infraestructura. La larga lista de proyectos
con increíbles excesos en la ejecución presupuestaria plantea algunas preguntas simples: ¿qué pasa aquí?
¿Por qué estamos haciendo habitualmente tan malas estimaciones de costos? ¿Qué factores causan las fallas
continuas, a la hora de estimar los costos del proyecto?
El profesor Bent Flyvbjerg, investigador de gerencia de proyectos en la Universidad de Oxford, y algunos colegas
han estudiado los registros de capturas de grandes proyectos de infraestructura en los últimos años y han llegado a
unas conclusiones sorprendentes sobre las causas de los costos fuera de control: en la mayoría de casos, las causas
provienen de una de las tres fuentes: un optimismo excesivo, el engaño deliberado o simplemente la mala suerte.
1. Optimismo excesivo—La obra de Flyvbjerg mostró que los ejecutivos son víctimas frecuentes de engaños
cuando se trata de proyectos, algo que él llama la “falacia de la planeación.” Con la falacia de la planeación,
los gerentes minimizan sistemáticamente los problemas y toman sus decisiones con base en el optimismo
delirante, pues subestiman los costos y obstáculos, e involuntariamente escogen los escenarios exitosos con
las mejores opciones y resultados. El optimismo excesivo lleva a los gerentes de proyectos y ejecutivos a errar
por el lado de la subestimación de los costos y del tiempo de las actividades del proyecto, incluso frente a
las evidencias previas o experiencias vividas. En resumen, tendemos a desarrollar escenarios excesivamente
optimistas del cronograma y los costos del proyecto y hacer previsiones que reflejan estos delirios.
2. Engaño deliberado—Los grandes proyectos de inversión de capital a menudo requieren niveles com-
plejos de toma de decisiones, con el fin de conseguir la aprobación. Por ejemplo, los gobiernos tie-
nen que trabajar con contratistas privados y otros agentes que se encargan de hacer las proyecciones
iniciales de costos. Flyvbjerg encontró que en ocasiones se sesga de manera inapropiada el proyecto
(engaño), lo cual ocurre cuando los interesados del proyecto tienen diferentes incentivos para realizar
el proyecto. Por ejemplo, el consorcio constructor quiere el proyecto, el Gobierno quiere satisfacer a los
contribuyentes y los votantes, los banqueros quieren asegurar las inversiones a largo plazo, y así sucesi-
vamente. En esta situación, los contratistas pueden tener un incentivo para proporcionar estimaciones
infravaloradas deliberadamente, con el fin de asegurar el contrato. Ellos saben que los “verdaderos”
costos estimados podrían ahuyentar a los socios del sector público, por lo que adoptan una política de
engaño deliberado para, en primer lugar, ganar el contrato, sabiendo que una vez que el gobierno se
ha comprometido, es muy difícil que cambien de opinión, incluso ante una serie de ampliaciones de las
estimaciones de costos. En resumen, el objetivo es conseguir firmar los contratos de los proyectos, pues
una vez firmados es muy difícil que no se ejecuten.
3. Mala suerte—Una última razón para la escalada de costos de los proyectos es simple mala suerte.
Mala suerte implica que a pesar de la consistencia de las estimaciones, la debida diligencia de todos los
interesados involucrados en el proyecto, así como las mejores intenciones tanto de los contratistas como
de los clientes, siempre se presentarán casos en los que las circunstancias, los factores ambientales y
la pura desgracia conspiran para descarrilar un proyecto o paralizar seriamente su entrega. Aunque no
hay duda de que la mala suerte a veces ocurre, Flyvbjerg advierte que por lo general la “mala suerte” es
una buena excusa para los problemas del proyecto, cuando la realidad, los desfases del presupuesto y el
cronograma son causados por razones más previsibles, como se señaló anteriormente.
La investigación sobre los graves sobrecostos de los proyectos y sus causas ofrece alguna información sobre
las razones por las cuales no logramos los objetivos en los proyectos claves. También sugiere que los efectos
continúa
276 Capítulo 8  •  Estimación de costos y presupuesto

adicionales son igualmente importantes: subestimar los costos y sobreestimar los beneficios de cualquier pro-
yecto conducen a dos problemas: (1) optamos por iniciar muchos proyectos que no son (y jamás fueron)
económicamente viables; (2) la selección de estos proyectos significa que estamos ignorando alternativas que
en realidad podrían haber arrojado una mayor rentabilidad si hubiéramos hecho un mejor análisis inicial. En
últimas, la queja común sobre los grandes proyectos de infraestructura (“Presupuesto y tiempo excedidos, una
y otra vez”) es una para la cual la mayoría de las organizaciones no tienen a quién culpar sino a ellas mismas.19

8.3  CREACIÓN DE PRESUPUESTO DE UN PROYECTO


El proceso de elaboración del presupuesto para un proyecto es una interesante combinación de estimación,
análisis, intuición y el trabajo repetitivo. La meta principal de un presupuesto es la necesidad de ayudar
a resolver los conflictos entre el proyecto y las metas de la organización. El presupuesto del proyecto es
un plan que identifica los recursos asignados, las metas del proyecto y el cronograma que le permite a una
organización alcanzar estas metas. La presupuestación efectiva siempre busca la integración corporativa—las
metas de departamento—con los objetivos específicos, las necesidades a corto plazo con los planes a largo
plazo, y, de una manera más amplia, la misión estratégica con problemas concretos basados en las necesida-
des. Los presupuestos útiles evolucionan a través de una intensa comunicación con todos los interesados y se
elaboran a partir de múltiples fuentes de datos. Tal vez lo más importante es que el presupuesto del proyecto
y el cronograma de este deben crearse simultáneamente, pues el presupuesto determina efectivamente si los
hitos del proyecto se pueden lograr.
Como uno de los pilares de la planeación del proyecto, el presupuesto del proyecto debe coordinarse
con las actividades del proyecto definidas en la estructura de desglose de trabajo (véase el capítulo 5). Como
muestra la figura 8.5, la EDT establece las bases para la creación del cronograma del proyecto, posterior-
mente el presupuesto del proyecto asigna los recursos necesarios para apoyar ese cronograma.
Varias cuestiones entran en la creación del presupuesto del proyecto, incluidos el proceso mediante el
cual el equipo del proyecto y la organización reúnen los datos para las estimaciones de costos, la proyección
del presupuesto, el flujo de efectivo de ingresos y gastos y las fuentes de los ingresos esperados. Los métodos
para la recopilación de datos y su distribución pueden variar mucho entre compañías; algunas firmas de pro-
yectos se basan en la asignación directa y lineal de los ingresos y gastos, sin tener en cuenta el tiempo; otras
utilizan sistemas más sofisticados. La forma en la que se recoge e interpretan los datos sobre costos dependen
principalmente de si la empresa cuenta con un procedimiento para elaborar el presupuesto de arriba abajo
o de abajo arriba. Estos enfoques implican métodos radicalmente diferentes para recopilar la información
pertinente al presupuesto del proyecto y posiblemente pueden dar lugar a resultados muy diferentes.

Presupuestación de arriba abajo (top down)


El uso del método para elaborar presupuestos de arriba abajo requiere la participación directa de la alta
gerencia de la organización; en esencia, este enfoque pretende conocer primero las opiniones y experiencias de
la alta gerencia respecto a los costos estimados del proyecto. Se supone que la alta gerencia tiene experiencia
con proyectos anteriores y está en condiciones de proporcionar información precisa y las estimaciones de los
costos para la operación futura del proyecto. Se toman las estimaciones iniciales tanto de los costos generales
del proyecto como de los principales paquetes de trabajo. Estas proyecciones pasan entonces al nivel inferior
de la jerarquía, a la siguiente área funcional, donde se recoge información adicional y más específica. A medida
que se desciende a lo largo de la jerarquía de la organización, el proyecto se divide en piezas más detalladas,
hasta llegar, en últimas, al personal del proyecto que realmente realiza el trabajo que proporcionará informa-
ción sobre los costos específicos tarea por tarea.

EDT

Plan del
FIGURA 8.5  Relación entre proyecto
la EDT, la programación y el
presupuesto Cronograma Presupuesto
8.3  Creación de presupuesto de un proyecto 277

Este enfoque puede crear una cierta fricción dentro de la organización, entre los niveles superior e infe-
rior como también entre los gerentes de nivel inferior que compiten por el dinero del presupuesto. Cuando la
alta gerencia establece un presupuesto total inicial, en esencia, está clavando una estaca en el suelo diciendo
“Esto es todo lo que estamos dispuestos a gastar.” Como resultado, todos los niveles sucesivos del proceso de
elaboración del presupuesto deberán hacer sus estimaciones ajustadas al marco del presupuesto general que
se estableció desde el principio. Este proceso conduce naturalmente a una negociación entre las diferentes
áreas en su intento de dividir el pastel de presupuesto, lo cual se convierte en un juego de suma cero: a más
dinero del presupuesto que reciba ingeniería, menos hay para usar en contratación.
Como aspecto positivo, la investigación sugiere que las estimaciones de los costos del proyecto de la
alta gerencia son a menudo bastante precisas, al menos en el agregado.20 Utilizar esta cifra como base para el
desglose hasta asignar costos a los paquetes de trabajo y las tareas individuales, aporta un sentido de disciplina
presupuestaria y control de costos. Por ejemplo, un empresario de la construcción a punto de firmar un con-
trato para desarrollar un centro de convenciones tiene a menudo el conocimiento suficiente para juzgar los
costos de construcción con una precisión razonable, tomando en cuenta la información necesaria acerca de
las características del edificio, su ubicación y los impedimentos de construcción conocidos o las restricciones
en los sitios de trabajo. Todos los subcontratistas y los miembros del equipo del proyecto deben entonces
desarrollar sus propios presupuestos con el método de arriba abajo basados en el contrato general.

Presupuestación de abajo arriba (bottom up)


El enfoque para elaborar el presupuesto con el método de abajo arriba es completamente diferente del realizado por
el método de arriba abajo. El enfoque para elaborar el presupuesto de abajo arriba comienza inductivamente de la
estructura de desglose del trabajo, cargando los costos directos e indirectos a las actividades del proyecto. La suma de
los costos totales asociados a cada actividad se agregan, primero a nivel de paquete de trabajo, y luego, a nivel de entre-
gable, en cuyo punto se combinan todos los presupuestos de la tarea; a continuación se asciende en la EDT: la suma de
los presupuestos de los paquetes de trabajo se agregan para crear el presupuesto general del proyecto.
En este enfoque de presupuestación, se requiere que cada gerente de proyecto prepare un presupuesto
del proyecto que identifique las actividades del proyecto y determine los fondos solicitados para ejecutar
estas tareas. El uso del primer nivel de requerimientos de presupuesto les permite a los gerentes funcionales
desarrollar sus propios presupuestos cuidadosamente documentados, teniendo en cuenta tanto las requisitos
de la compañía como las necesidades propias de su área. Por último, esta información se transmite a la alta
gerencia, se consolida y optimiza eliminando solapamientos o doble recuento. Esta es la responsable dentro
de la organización de crear el presupuesto maestro final.
El presupuesto de abajo arriba pone de relieve la necesidad de crear planes detallados del proyecto, en
particular la EDT, como paso inicial para hacer las asignaciones del presupuesto. También facilita la coordi-
nación entre los gerentes de proyecto y los jefes de las áreas funcionales, ya que enfatiza en la creación de pre-
supuestos únicos para cada proyecto, que le permite a la alta gerencia una visión clara para el establecimiento
de prioridades entre los proyectos que compiten por los recursos. Por otro lado, una desventaja de la elabora-
ción de presupuestos de abajo arriba es que reduce el papel de la alta gerencia en el proceso de construcción
del presupuesto a solo actividades de control, en lugar de permitirle la iniciativa directa, lo cual puede dar
lugar a diferencias significativas entre sus preocupaciones estratégicas y las actividades del nivel operativo de
la organización. Además, la fina sintonización que suele acompañar la presupuestación de abajo arriba puede
requerir mucho tiempo, ya que los ajustes realizados por la alta gerencia requiere que los gerentes del nivel
inferior vuelvan a presentar sus números hasta que logren un presupuesto aceptable.

Costeo basado en actividades


La mayoría de los presupuestos de los proyectos utilizan alguna forma de costeo basado en actividades. El
costeo basado en actividades(ABC) (activity based costing: ABC) es un método de elaboración de presu-
puestos que primero asigna costos a las actividades y luego a los proyectos, basándose en el uso de recursos
de cada proyecto. Recuerde que las actividades del proyecto son tareas discretas que el equipo del proyecto se
compromete a hacer o entregar durante el proyecto. El costeo basado en actividades, por tanto, se basa en la
idea de que los proyectos consumen actividades y las actividades consumen recursos.21
El costeo basado en actividades consta de cuatro pasos:
1. Identificar las actividades que consumen recursos y asignar costos a estas, como se hace en un proceso
de presupuestación de abajo arriba.
278 Capítulo 8  •  Estimación de costos y presupuesto

2. Identificar los determinantes de los costos asociados a cada actividad. Los recursos, en la forma de per-
sonal del proyecto y materiales, son los principales determinantes de los costos.
3. Calcular una tasa de costo por unidad de determinantes de costo o de la transacción. El trabajo, por
ejemplo, es con frecuencia simplemente el costo de mano de obra por hora, dado como:

Tasa de costo/unidad Costo $/h

4. Asignar los costos al proyecto multiplicando la tasa del determinante del costo por la cantidad de uni-
dades del determinante del costo consumidas en el proyecto. Por ejemplo, suponga que el costo de un
programador sénior de software es 40 dólares/hora y que trabaja en el proyecto un total de 80 horas. El
costo del proyecto sería:

($40/h) (80 horas) = $3, 200.00

Como se mencionó en este capítulo, existen numerosas fuentes de costos en un proyecto (determinantes de
costos) que se aplican tanto a los costos indirectos como a los directos. El costeo basado en actividades es una
técnica empleada en la elaboración de la mayoría de los presupuestos de los proyectos, y requiere la identifica-
ción temprana de estas variables con el fin de crear un documento que permita un control efectivo.
El cuadro 8.7 muestra una parte del presupuesto de un proyecto. El propósito del presupuesto prelimi-
nar es identificar los costos directos y los que se cargan a los gastos generales. A veces es necesario desglosar
los gastos generales para tener en cuenta rubros del presupuesto separados. La cifra de gastos generales de
500 dólares de los estudios, por ejemplo, puede incluir los gastos que cubren seguro de salud, las contribucio-
nes de pensión y otros tipos de gastos que se desglosan en un presupuesto más detallado del proyecto.

CUADRO 8.7   Ejemplo de presupuesto de un proyecto

Actividad Costo directo Gastos generales Costo total


Estudios 3,500 500 4,000
Diseño 7,000 1,000 8,000
Limpieza del sitio 3,500 500 4,000
Cimientos 6,750 750 7,500
Cerramiento 8,000 2,000 10,000
Plomería y cableado 3,750 1,250 5,000

El cuadro 8.8 muestra el presupuesto en el que los gastos totales previstos en cuadro 8.7 se comparan
con los gastos acumulados reales del proyecto. Este método ofrece la posibilidad de centralizar la tabulación
de los datos de los costos del proyecto y permite el desarrollo preliminar de los informes de varianza. Por
otro lado, este tipo de presupuesto es un documento estático que no refleja el cronograma del proyecto como
tampoco el hecho de que las actividades se ejecutan progresivamente siguiendo la secuencia de la red.

CUADRO 8.8  Ejemplo de un presupuesto de seguimiento del costo de las


actividades planeadas y ejecutadas

Actividad Planeado Presupuesto actual Variación


Estudios 4,000 4,250 250
Diseño 8,000 8,000 -0-
Limpieza del sitio 4,000 3,500 (500)
Cimientos 7,500 8,500 1,000
Cerramiento 10,000 11,250 1,250
Plomería y cableado 5,000 5,150 150
Total 38,500 40,650 2,150
8.4  desarrollo de contingencias de presupuesto 279

El cuadro 8.9 muestra un ejemplo de un presupuesto por fases, en las que el presupuesto total de cada acti-
vidad del proyecto se desglosa en el cronograma, en el momento en que se planifica el trabajo. El presupuesto por
fases asigna los costos a través de ambos criterios, por las actividades del proyecto y por el tiempo en que se estima
que el presupuesto debe ejecutarse. Esto le permite al equipo del proyecto hacer que la línea base del cronograma
coincida con la línea de base del presupuesto, identificando hitos tanto para el rendimiento del cronograma como
para los gastos del proyecto. Como se verá en el capítulo 13, la creación de un presupuesto por fases trabaja en
conjunto con técnicas de control de proyectos más complejas, como la gerencia del valor ganado.

CUADRO 8.9  Ejemplo de un presupuesto por fases

Meses
Total por
Actividad Enero Febrero Marzo Abril Mayo actividad
Estudios 4,000  4,000
Diseño  5,000  3,000  8,000
Limpieza del sitio  4,000  4,000
Cimientos  7,500  7,500
Cerramiento  8,000  2,000 10,000
Plomería y  1,000  4,000  5,000
cableado
Planeado 4,000  9,000 10,500  9,000  6,000
mensual
Acumulado 4,000 13,000 23,500 32,500 38,500 38,500

Podemos hacer un seguimiento gráfico que ilustre los gastos del presupuesto previstos para el pro-
yecto, representando gráficamente el costo acumulado presupuestado del proyecto respecto a la línea base
del cronograma. La figura 8.6 muestra el trazado de la gráfica, otro método para identificar la línea base del
cronograma y del presupuesto durante la vida esperada del proyecto.

8.4  DESARROLLO DE CONTINGENCIAS DE PRESUPUESTO


Las contingencias del presupuesto simbolizan el reconocimiento de que las estimaciones de los costos del
proyecto son solo eso: estimaciones. Acontecimientos imprevistos a menudo conspiran para hacer inexacto
el presupuesto inicial del proyecto, o incluso inútil. (Supongamos que un proyecto de construcción que había

Costo acumulado
presupuestado (en miles)

40

35

30

25

20

15

10

Ene. Feb. Mar. Abr. May.


FIGURA 8.6  Costo acumulado presupuestado del proyecto
280 Capítulo 8  •  Estimación de costos y presupuesto

presupuestado un monto fijo para excavar los cimientos de un edificio accidentalmente descubre serios pro-
blemas de hundimientos o aguas subterráneas). Hasta en los proyectos en que la incertidumbre es mínima,
simplemente no existe la posibilidad de darse el gusto de contar con el conocimiento de todos los eventos.
Una contingencia de presupuesto es la asignación de fondos adicional para cubrir estas incertidumbres y
mejorar las posibilidades de que el proyecto pueda llevarse a cabo dentro del tiempo especificado original-
mente. El dinero para contingencias normalmente se añade al presupuesto del proyecto después de la iden-
tificación de todos los costos del proyecto, es decir, el presupuesto del proyecto no incluye la contingencia
como parte del proceso de costeo basado en actividades. Más bien, la contingencia se calcula como un amor-
tiguador adicional en el nivel superior del costo estimado del proyecto.
Hay varias razones por las cuales se recomienda incluir los fondos de contingencia en las estimaciones
de los costos del proyecto. Muchas de estas razones apuntan a la incertidumbre que acompaña a la mayoría
de las estimaciones de los costos del proyecto:22
1. El alcance del proyecto está sujeto a cambios.  Muchos proyectos tienen como objetivo blancos en
movimiento, es decir, el alcance del proyecto parece bien articulado y definido. Sin embargo, puesto
que el proyecto se mueve a través de su ciclo de desarrollo, eventos externos o cambios ambientales
pueden a menudo obligarnos a modificar o actualizar las metas de un proyecto. Por ejemplo, supon-
gamos que nuestra organización se propuso desarrollar un producto de electrónica para el mercado de
la música comercial, solo para descubrir, a medio camino de la ejecución del proyecto, que los avances
tecnológicos habían hecho obsoleto nuestro producto original. Una opción para no abandonar el pro-
yecto es que ingeniería rediseñe el producto haciéndole mejoras en medio del desarrollo del proyecto.
Esos cambios en el alcance causarán potencialmente costosos reajustes presupuestarios.
2. La ley de Murphy siempre está presente.  La ley de Murphy sugiere que si algo puede salir mal, a
menudo lo hará. La contingencia de presupuesto representa un método para anticipar la probabilidad
de problemas que ocurren durante el ciclo de vida del proyecto. Por tanto, los planes de contingencia
se entienden como acciones prudentes.
3. La estimación de costos debe anticipar los costos de interacción.  Es habitual que el presupuesto de
las actividades del proyecto sean operaciones independientes. Por tanto, en un proyecto de desarro-
llo de producto, desarrollamos un presupuesto discreto para cada paquete de trabajo en los procesos
de diseño, ingeniería, mecanizado, etc. Sin embargo, este enfoque no toma en cuenta la naturaleza a
menudo “interactiva” de estas actividades. Por ejemplo, supongamos que la fase de ingeniería requiere
que se produzca una serie de ciclos iterativos entre los diseñadores y los ingenieros. Como se crean una
serie de diseños, estos se remiten a la sección de ingeniería para pruebas y para la evaluación de la cali-
dad. Si se encuentran problemas, deben enviarse de nuevo a diseño para corregirse. La coordinación de
múltiples ciclos de diseño y correcciones cuando el producto se mueve en estas dos fases, a menudo no
se contabilizan en el presupuesto estándar de un proyecto. Por tanto, los presupuestos de contingencia
permiten los posibles ciclos de trabajo repetido que vinculan las actividades interactivas del proyecto.
4. Rara vez se dan condiciones normales.  Los costos estimados del proyecto generalmente predicen “con-
diciones normales.” Sin embargo, muchos proyectos se realizan en situaciones diferentes a las condiciones
normales de trabajo. Algunas de las formas en que habitualmente se viola el supuesto de condiciones nor-
males son la disponibilidad de recursos y la naturaleza de los impactos ambientales. Los estimadores de
costos suponen que los recursos necesarios para el proyecto estarán disponibles cuando se necesiten. Sin
embargo, el personal puede faltar; las materias primas pueden ser de mala calidad; la financiación prometida
puede no materializarse, y así sucesivamente. Cuando los recursos faltan o son limitados, las actividades que
dependen de su disponibilidad a menudo se retrasan, lo cual genera costos adicionales. Del mismo modo,
la geografía y los efectos del medio ambiente sobre algunos proyectos ponen de manifiesto la dificultad de
crear una situación de proyecto “normal.” Por ejemplo, un gerente de proyecto fue asignado para desarrollar
una planta de energía en India en la provincia de Bengala Occidental, solo para descubrir, a su llegada, que
el proyecto estaba a punto de empezar, ¡al tiempo que las torrenciales lluvias anuales del monzón debían
llegar! Su primera actividad del proyecto, después de llegar a la obra, fue pasar tres semanas construyendo
diques y un muro de contención de cinco pies alrededor del sitio para asegurarse de que no se inundara. Por
supuesto, el costo de esta construcción necesaria no se había tenido en cuenta en el presupuesto inicial.

Mientras los equipos de proyectos favorecen naturalmente las contingencias como un amortiguador para
controlar los costos del proyecto, su aceptación por los interesados del proyecto, en particular los clientes, es menos
segura. Algunos clientes pueden sentir que se les está pidiendo para cubrir un deficiente control del presupuesto.
Otros clientes se oponen a lo que parece un proceso arbitrario de cálculo de las contingencias. Por ejemplo, es
Resumen 281

común en la industria de la construcción aplicar una tasa para contingencias de 10% -15% a cualquier estructura
antes de diseño arquitectónico. En consecuencia, un edificio presupuestado en 10 millones de dólares tendrá un
costo real de diseño de 9 millones de dólares. El millón de dólares adicionales se mantendrá en reserva como fondos
para contingencias y cubrir imprevistos durante la construcción y no se cargan al presupuesto de funcionamiento.
Por último, ¿debe el fondo de contingencias cargarse por igual a todos los paquetes de trabajo del proyecto o debe
mantenerse en reserva para apoyar actividades claves según la necesidad? El último punto de la discordia es dónde
o a qué actividades del proyecto se deben cargar los fondos de contingencias. A pesar de estos inconvenientes, hay
varias ventajas en el uso de los fondos para contingencias en los proyectos; entre estas se incluyen:

1. Se reconoce que el futuro se desconoce y es probable que los problemas que surjan tengan un efecto
directo sobre el presupuesto del proyecto. Al aprovisionar las contingencias, el proyecto acepta los
efectos negativos de la variación tanto en tiempo como en dinero.
2. Las provisiones se hacen en los planes de la empresa para cubrir los aumentos en el costo del proyecto.
Algunos se refieren a las contingencias como la primera alarma contra incendios del proyecto. Aceptar
que los fondos de contingencia se deben cargar a un proyecto es el primer paso en la obtención de la
aprobación de los aumentos de presupuesto, en caso de ser necesario.
3. La consideración del fondo de contingencia da una señal de alerta de un posible presupuesto sobregirado.
En casos de tales señales, la alta gerencia de la organización debe examinar seriamente el proyecto y los
motivos de la variación del presupuesto y comenzar a formular planes de reserva adicionales, en caso de
que las contingencias resultaran insuficiente para cubrir el exceso de gastos del proyecto. En los grandes
contratos de la industria de la defensa, por ejemplo, la organización del proyecto ante excesos en la ejecución
del presupuesto a menudo toma primero los recursos reservados para contingencia del proyecto antes de
solicitarle a la agencia gubernamental fondos adicionales. En un contrato con el Ejército, el gerente del pro-
yecto deberá comprender que tendrá que presentar una contabilidad completa de los gastos del proyecto,
incluidos los fondos de contingencia, antes de que este considere una financiación adicional.

La estimación de los costos y el presupuesto del proyecto son dos componentes vitales de control del proyecto.
Debido a que una restricción en cualquier proyecto es su presupuesto, la forma en que calculamos los costos
del proyecto y creamos presupuestos realistas es fundamental para planeación efectiva del proyecto. Además, la
mejor defensa contra la sobreejecución de los presupuestos es preparar la estimación de los costos del proyecto
lo más cuidadosamente posible. Aunque no podemos prever todas las eventualidades, cuanto más cuidadosos
seamos en la estimación inicial, mayor será la probabilidad de que podemos crear un presupuesto que refleje de
manera precisa los verdaderos costos del proyecto. La estimación de costos nos desafía a desarrollar suposicio-
nes y expectativas razonables de los costos del proyecto a través de articular con claridad la forma en que llega-
mos a nuestras estimaciones. El presupuesto es el mejor método para cargar, de forma sistemática, los gastos del
proyecto, con el objetivo de mantener los costos del proyecto en concordancia con las estimaciones iniciales. En
conjunto, la estimación de costos y el presupuesto requieren que cada gerente de proyectos se sienta cómodo,
no solo con los desafíos técnicos del proyecto, sino también con sus restricciones monetarias.

Resumen
1. Entender los diferentes tipos de costos más comunes de toda la planta y equipo, ya sea que estén en el sitio
en los proyectos.  El presupuesto del proyecto consta del proyecto o fuera de este.
de dos elementos distintos: estimación de costos y el pro- e. Viajes—En ocasiones se requiere cargar gastos de
pio proceso de elaboración de presupuestos. Entre los viajes de los miembros del equipo del proyecto a te-
gastos más comunes en la mayoría de proyectos están: rreno u otros sitios.
a. Costo de mano de obra—Es el valor de los recursos 2. Reconocer la diferencia entre las diversas formas de
humanos necesarios para completar el proyecto. los costos del proyecto.  Los tipos de costos en los
b. Costo de materiales—Son los gastos relativos a los que incurren los proyectos se agrupan de varias mane-
equipos o suministros específicos necesarios para el ras. Los tipos más comunes de costos son:
desarrollo del proyecto. • Directos versus indirectos—Los costos directos se pue-
c. Subcontratistas—Cargos contra el presupuesto del den asignar directamente a las actividades realizadas
proyecto, para el empleo de consultores u otros traba- para crear el proyecto. Los costos indirectos se relacio-
jos subcontratados. nan con los gastos generales o de administración de la
d. El costo de equipos e instalaciones—Son los costos empresa. Por ejemplo, los gastos generales con cargo
282 Capítulo 8  •  Estimación de costos y presupuesto

al proyecto incluyen los beneficios para la salud o las para realizar múltiples iteraciones de una tarea. Cuando
contribuciones de pensión. Los gastos de administra- se producen estas situaciones, por lo general, es más fácil
ción incluyen los gastos de envío, apoyo secretarial o y rápido completar la iteración n-ésima de lo que fue
computador, comisiones de ventas, entre otros. completar la primera, debido al efecto del aprendizaje en
• Recurrentes versus no recurrentes—Los costos recu- las actividades repetitivas. Usando algunas fórmulas dis-
rrentes son gastos corrientes, como el trabajo o costos ponibles, podemos reajustar las estimaciones del costo
de materiales. Aparecen en el ciclo de vida del proyecto. de las actividades repetitivas para reflejar el efecto de la
Gastos no recurrentes suelen ser los gastos extraordi- curva de aprendizaje sobre el costo de una actividad.
narios relacionados con algún gasto o compra especial, 5. Discernir las distintas razones por las cuales la esti-
como la capacitación o la compra de un edificio. mación del costo del proyecto se hace a menudo de
• Fijos versus variables—Los costos fijos no varían manera deficiente.  La estimación de costos puede estar
respecto a su uso. Los costos variables generalmente mal por varias razones; entre ellas:
aumentan en proporción al grado en que se utilizan. a. Bajas estimaciones iniciales—Estas son causadas
• Normales versus acelerados—Gastos normales son por la falta de conocimiento del alcance del proyecto
los costos normalmente programadas del proyecto, o debido a un clima organizacional que premia a las
establecidos en relación con la línea base del crono- estimaciones iniciales bajas y no sanciona el costo
grama. Los costos acelerados se denominan a veces ulterior o los retrasos en el cronograma.
como “costos crashing” y aumentan debido a los b. Problemas técnicos inesperados—En muchos pro-
recursos adicionales asignados para acelerar la reali- yectos en los cuales el desempeño técnico depende
zación de una actividad específica del proyecto. de soluciones de última generación suelen surgir
3. Aplicar las formas de estimación de costos de trabajo del problemas inesperados.
proyecto, incluidas las estimaciones preliminares y las c. Falta de definición—Las especificaciones pobre-
estimaciones definitivas.  La estimación de costos puede mente definidas generalmente conducen a proyectos
realizarse por diferentes métodos, pero en general con el mal presupuestados y controlados.
aumento en la precisión de las estimaciones se logra que d. Cambios en las especificaciones—Las constantes
estas resulten más cercanas a los resultados logrados una solicitudes de cambio en las especificaciones del
vez concluidos los trabajos programados. Las estimacio- proyecto llevan rápidamente a sobrecostos.
nes preliminares de las tareas del proyecto, a veces llama- e. Factores externos—Los efectos incontrolables de la
das “estimaciones iniciales”, pueden tener una precisión inflación o la interferencia política o económica en
hasta de ± 30%. En cambio, cuando el proyecto se acerca un proyecto pueden hacer que las estimaciones ini-
a la terminación de la fase de planeación, es posible esperar ciales pierdan validez.
estimaciones definitivas más precisas (± 5%). Un método 6. Aplicar en la gerencia de costos tanto el método de esti-
para la estimación de costos es a través del uso de técnicas mación del presupuesto de arriba abajo como el de abajo
paramétricas, que comparan actividades actuales con el arriba.  El proyecto de presupuesto implica un proceso
costo de las actividades similares de proyectos pasados y, de adopción de las estimaciones de costos de las activida-
a continuación, asigna un multiplicador para considerar des individuales y la creación de un documento de trabajo
aumentos de los costos por inflación u otras causas. con los gastos previstos del proyecto. Los dos enfoques
4. Entender las ventajas de la estimación de costos para hacer el presupuesto implican el esfuerzo del uso de
paramétricos y la aplicación de modelos de curva de los métodos de arriba abajo y abajo arriba para identificar
aprendizaje en la estimación de costos.  La estima- mejor los costos y asignar dinero al presupuesto del pro-
ción de costos paramétricos les permite a los gerentes yecto. Por otra parte, las técnicas de presupuestación basa-
de proyectos desarrollar estimaciones detalladas de los das en actividades les permiten a los equipos de proyecto
costos de los proyectos actuales, tomando trabajo viejo identificar las actividades que consumen recursos y asig-
e insertando un multiplicador para tener en cuenta el nar costos a estas. En segundo lugar, permiten identificar
efecto de los aumentos de la inflación, la mano de obra, los determinantes de los costos asociados a las actividades
los materiales, entre otros. La estimación paramétrica (normalmente recursos humanos y costos de materiales);
les permite a los gerentes de proyectos iniciar la for- y tercero, permite calcular un multiplicador del costo por
mulación de las estimaciones con base en antecedentes cada uno de los determinantes de costo del proyecto. La
históricos, muy útiles en proyectos complejos en los presupuestación basada en actividades permite la creación
que es difícil formular estimaciones razonables. de presupuestos de proyectos con partidas específicas de
Un elemento en la estimación del costo del pro- cada tarea necesaria para completar el proyecto.
yecto que no se puede ignorar es el efecto de las tasas de 7. Comprender el uso del presupuesto basado en activi-
aprendizaje sobre la capacidad de un individuo para rea- dades y del presupuesto por fases para la estimación y
lizar una tarea del proyecto. Normalmente los efectos de el control de costos.  A partir del presupuesto basado en
la curva de aprendizaje solo son relevantes en los casos actividades, podemos dar un paso adelante para crear los
en que se asigna a miembros del equipo del proyecto presupuestos de fase tiempo, en los que los costos de las
Problemas resueltos 283

actividades específicas se distribuyen a través de la línea proyectos, se requiere, por diversas razones, dejar en una
base del cronograma del proyecto, para reflejar los puntos cuenta aparte del proyecto cierta cantidad de presupuesto
de la línea de tiempo del proyecto en donde el presupuesto para atender eventos inesperados que no hubieran sido
se ejecuta. El uso de un enfoque de presupuesto de fase previstos en la estimación de costo inicial. Esta cuenta
tiempo le permite al equipo del proyecto vincular tiempo se conoce como fondo de contingencia del proyecto. En
y costo en una sola línea base que puede ajustarse para ser- muchos proyectos, en particular los de construcción, el
vir como el plan del proyecto. El control de costos del pro- fondo de contingencia es una parte normal del presu-
yecto, a medida que el proyecto avanza, se fundamenta en puesto del proyecto. La contingencia no se asigna a las
la creación del presupuesto de fase tiempo. actividades específicas del proyecto, sino que se utiliza
8. Reconocer la conveniencia de cargar los fondos de como fondo de emergencia del proyecto para sufragar los
contingencia en la estimación de costos.  En muchos costos asociados con la ocurrencia de problemas.

Términos clave
Contingencia de Costos no recurrentes Estimación paramétrica Presupuestación de abajo
presupuesto (p. 280) (p. 263 ) (p. 265) arriba (p. 277)
Costeo basado en Costos recurrentes (p. 263) Estimaciones de factibilidad Presupuesto del proyecto
actividades (ABC) Costos variables (p. 263) (p. 266) (p. 276)
(p. 277) Comprimir actividades Estimaciones definitivas Presupuesto por fases
Costos acelerados (p. 263 ) (p. 263 ) (p. 266) (p. 279)
Costos directos (p. 261) Curvas de aprendizaje Estimaciones preliminares Presupuestación de arriba
Costos fijos (p. 263) (p. 267) (p. 264) abajo (p. 276)
Costos indirectos (p. 262) Estimación de costos (p.264) Estimados comparativos Puntos de función (p. 272)
(p. 265)

Problemas resueltos
1. Cálculo de los costos de la mano de obra directa Calcule el costo datos. ¿Cuáles son los costos de los distintos miembros del equipo
de la mano de obra directa del equipo del proyecto con los siguientes del proyecto? ¿Cuál es el costo total de la mano de obra directa?

Horas Multiplicador Multiplicador Tarifa por Costo total mano


Nombre necesarias gastos generales tiempo personal hora de obra directa
John 40 1.80 1.12 $21/h
Bill 40 1.80 1.12 $40/h
J.P. 60 1.35 1.05 $10/h
Sonny 25 1.80 1.12 $32/h
Costo total mano de obra directa =

SOLUCIÓN
Utilizamos la fórmula para el cálculo de los costos directos, dado que: Aplicamos cada tasa indicada anteriormente y, a su vez, diligencia-
Tarifa por hora  horas necesarias  gastos generales  mos el cuadro de costos directos de la siguiente manera:
tiempo personal = costo total mano de obra directa

Horas Multiplicador Multiplicador Tarifa por Costo total mano


Nombre necesarias gastos generales tiempo personal hora de obra directa
John 40 1.80 1.12 $21/h $1,693.44
Bill 40 1.80 1.12 $40/h 3,225.60
J.P. 60 1.35 1.05 $10/h 850.50
Sonny 25 1.80 1.12 $32/h 1,612.80
Costo total mano de obra directa = $7,382.34
284 Capítulo 8  •  Estimación de costos y presupuesto

2. Estimación de costos de software con puntos de función se pueden desglosar de la siguiente forma: entradas (4), salidas
Suponga que se le requirió para hacer una estimación razona- (7), interfaces (12), consultas (20) y archivos (16). Además, se
blemente detallada del desarrollo de un nuevo sistema de infor- ha determinado que la complejidad relativa de cada una de
mación de admisiones de estudiantes en una universidad local. estas funciones es la siguiente: entradas (baja), salidas (media),
El promedio de los programadores de su empresa es 6 puntos de interfaces (alta), consultas (media) y archivos (media). Con esta
función por persona/mes. Después de hablar con los encarga- información y la tabla siguiente, calcule el número de puntos de
dos de la universidad, usted determinó que los requerimientos función para este proyecto.

Ponderación de la complejidad

Función Baja Media Alta Total


Número de entradas 3 ◊ _____ = 6 ◊ _____ =  9 ◊ _____ =
Número de salidas 2 ◊ _____ = 6 ◊ _____ = 10 ◊ _____ =
Número de interfaces 1 ◊ _____ = 3 ◊ _____ =  5 ◊ _____ =
Número de consultas 4 ◊ _____ = 8 ◊ _____ = 12 ◊ _____ =
Número de archivos 4 ◊ _____ = 6 ◊ _____ =  8 ◊ _____ =

SOLUCIÓN elaboremos una tabla que se muestra a continuación, en el que se mul-


Una vez que sabemos el número de requerimientos de cada una de las tiplica la complejidad relativa de cada una de las cinco funciones del
cinco funciones del programa y la ponderación de la complejidad de programa por el número de pantallazos requeridos. El cuadro mues-
estas actividades, el cálculo del total de puntos de función requiere que tra que el número total de puntos de función para este proyecto es 370.

Ponderación de la complejidad

Función Baja Media Alta Total

Número de entradas 3◊4= 12


Número de salidas  6 ◊ 7 = 42
Número de interfaces 5 ◊ 12 = 60
Número de consultas 8 ◊ 20 = 160
Número de archivos 6 ◊ 16 = 96

3. Estimación del presupuesto utilizando la curva de aprendizaje Donde


Suponga que tiene un proyecto de software que requiere los ser- Yx = tiempo requerido en estado de equilibrio para x unidades
vicios de codificación de un programador sénior para completar de producción
14 secuencias de codificación que son relativamente similares.   a = tiempo requerido para la primera unidad de producción
Sabemos que la tasa de aprendizaje del programador es 0.90 y  X = número de unidades producidas al alcanzar el estado de
que la primera secuencia de codificación probablemente tome equilibrio
15 horas para terminarse. Utilizando la fórmula de curva de   b = pendiente de la curva de aprendizaje, representada como:
aprendizaje, calcule el tiempo de estado de equilibrio para codifi- log de la tasa de aprendizaje en decimal/log 2
car estas secuencias.
b = log0.90/log2
SOLUCIÓN = - 0.4576/0.301
Recordemos que la fórmula de la curva de aprendizaje para el cálculo = - 0.1521
del tiempo requerido para producir una unidad en estado de equi- Yx = 15 (14) -0.1521
librio de la producción se representa como:
Yx = 10.04 horas
Yx = aX b
Problemas 285

Preguntas para discusión


1. Describa un entorno en el que sería común presentar ofertas ¿Cómo afecta el nivel de conocimientos de un programador
para contratos con bajos márgenes de ganancia. ¿Por qué este recién contratado su cálculo mensual de los puntos de función,
contexto sugiere un ambiente de competencia? en comparación con un programador más experimentado?
2. ¿Cómo afecta la economía mundial la estimación y el control de 8. Póngase en la posición de un cliente del proyecto. ¿Debería
costos en la organización de muchos proyectos? usted insistir o no en ajustar los costos asociados a los impac-
3. ¿Por qué la estimación de costos es un componente tan impor- tos de la curva de aprendizaje? ¿En qué circunstancias podría la
tante en la planeación del proyecto? Analice cómo se vincula curva de aprendizaje ser adecuadamente presupuestada en los
con la EDT y con el cronograma del proyecto. costos de un proyecto?
4. Imagínese que usted está desarrollando un paquete de software 9. Tenga presente los problemas más comunes en la estimación de
para la intranet de su empresa. Dé ejemplos de los distintos los costos de un proyecto y recuerde un proyecto en el que usted
tipos de costos (mano de obra, materiales, equipos e instalacio- se haya involucrado. ¿Cuáles de estos problemas ha encontrado
nes, subcontratistas, etc.) y cómo se aplican a su proyecto. con más frecuencia? ¿Por qué?
5. Dé argumentos en favor y en contra de las razones para hacer 10. ¿Prefiere el presupuesto de abajo arriba o de arriba abajo para el
o no cargos por concepto de tiempo de personal, como estima- control de los costos de un proyecto? ¿Cuáles son las ventajas y
ción del costos de las actividades de proyecto. desventajas de cada enfoque?
6. Según su experiencia personal, dé un ejemplo de estimación 11. ¿Por qué los equipos de proyectos crean presupuestos por fases?
paramétrica usando un multiplicador de costos basado en un ¿Cuáles son sus principales fortalezas?
costo pasado similar. ¿Funciona o no la estimación paramé- 12. El presupuesto por fases para contingencias se puede usar en
trica? Argumente su respuesta. los proyectos por varias razones. Enumere tres de las princi-
7. Suponga que su organización utiliza el análisis de puntos de pales razones por las cuales una gerencia del proyecto debe
función para estimar los costos de un proyecto de software. considerar las contingencias de presupuesto.

Problemas
1. Calcule el costo directo laboral de un miembro del equipo del 2. Calcule el costo directo laboral del equipo del proyecto con los
proyecto de acuerdo con los siguientes datos: siguientes datos. ¿Cuál es el costo de cada uno de los miem-
bros del equipo del proyecto?¿Cuál es el costo total de la mano
Tarifa por hora: $35/h
de obra directa?
Horas requeridas: 150
Gastos generales: 55%

Horas Multiplicador Multiplicador Tarifa por Costo total mano


Nombre necesarias gastos generales tiempo personal hora de obra directa
Sandy 60 1.35 1.12 $18/h
Chuck 80 1.75 1.12 $31/h
Bob 80 1.35 -0- $9/h
Penny 40 1.75 1.12 $30/h
Costo total mano de obra directa =

3. Suponga que los gastos generales se cargan en forma global. A Para resolver los problemas 4 a 6, consulte la tabla de coeficientes
cada miembro del equipo del proyecto se le asigna un costo por de la curva de aprendizaje (unidad y multiplicadores de tiempo
concepto de gastos generales de $150 por semana. ¿Cuál será total) que se muestran en la siguiente página.
el costo directo laboral de un empleado asignado al proyecto
4. A MegaTech, Inc. le tomó 100,000 horas-hombre producir la pri-
durante 200 horas a $10.50/hora?
mera de varias torres de perforación de petróleo para exploración
La fórmula simplificada para calcular la tasa de tiempo de aprendi- en la Antártida. Su empresa, Natural Resource Inc., ha acordado la
zaje usada en la tabla de los coeficientes se da como: compra de la quinta (en estado de equilibrio) plataforma de per-
foración de petróleo puesta en la planta de MegaTech. Asuma que
TN = T1 C MegaTech tiene una tasa de aprendizaje de 80%. Con un costo de
mano de obra de $35 por hora, ¿cuánto deberá usted pagar, como
Donde: agente de compras, por la quinta unidad?
TN = tiempo necesario para producir la enésima unidad 5. El problema 4 identifica cuánto tiempo se necesita para cons-
  T1 = tiempo necesario para producir la primera unidad truir la quinta plataforma de perforación de petróleo que
            C = coeficiente de la curva de aprendizaje
286 Capítulo 8  •  Estimación de costos y presupuesto

Natural Resource planea comprar. ¿Cuánto tiempo tomará horas-hombre para completar la primera iteración de la codifi-
fabricar las cinco plataformas de perforación de petróleo? cación y una tasa de aprendizaje de 70%. Usted estima el costo de
6. Suponga que usted asigna costos a un gran proyecto que veinte (en estado de equilibrio) iteraciones de esta codificación
emprenderá este año su empresa, DynoSoft Applications. En repetitiva. Con base en esta información y una tarifa por mano
particular, hay un proceso de codificación que implica muchas de obra de $60 por hora, ¿qué presupuesto estimaría como costo
horas de trabajo muy repetitivo. Se estima un total de 200,000 de la vigésima iteración? ¿Y de la cuadragésima iteración?

Coeficientes de la curva de aprendizaje (unidad de tiempo y total de los multiplicadores de tiempo)

70% 75% 80% 85%


Unidad
punto Unidad Tiempo Unidad Tiempo Unidad Tiempo Unidad Tiempo
equilibrio tiempo total tiempo total tiempo total tiempo total
 5 .437  3.195 .513  3.459 .596  3.738 .686  4.031
10 .306  4.932 .385  5.589 .477  6.315 .583  7.116
15 .248  6.274 .325  7.319 .418  8.511 .530  9.861
20 .214  7.407 .288  8.828 .381 10.485 .495 12.402
25 .191  8.404 .263 10.191 .355 12.309 .470 14.801
30 .174  9.305 .244 11.446 .335 14.020 .450 17.091
35 .160 10.133 .229 12.618 .318 15.643 .434 19.294
40 .150 10.902 .216 13.723 .305 17.193 .421 21.425
Base a = 1.

7. Suponga que usted es el ingeniero de costos del proyecto y cal- programadores pueden manejar 5 puntos de función por per-
cula el costo de una actividad repetitiva. El proyecto requiere sona/mes y que en su empresa el costo por el programador es
un total de 20 repeticiones de esta actividad. La actividad toma $4,000/mes. El proyecto cuyo costo se estima, se basa en los
2.5 horas en estado de equilibrio y tiene una tasa de aprendi- siguientes requerimientos:
zaje de 75%. Calcule el tiempo de producción para la primera
unidad usando la fórmula de aprendizaje:
Función Número de pantallas Complejidad
Yx = aX b
Donde Entradas 8 Baja
Yx = tiempo requerido para el estado de equilibrio en la Salidas 6 Baja
x unidad de producción Interfaces 15 Alta
a = tiempo requerido producir la primera unidad Consultas 5 Alta
X = número de unidades que se producen al alcanzar el Archivos 25 Media
estado de equilibrio
b = pendiente de la curva de aprendizaje, representada
como logaritmo decimal de la tasa de Además, usted sabe que la ponderación de la complejidad de estas
aprendizaje/log 2 funciones se ajusta a un proceso interno estándar que incluye:
8. Usted trabaja en un centro regional de atención de la salud y a. Calcular el número total de puntos de función para el
le han solicitado estimar el costo de un proyecto de software proyecto.
para su organización. Usted sabe que históricamente los b. Calcular el costo total esperado del proyecto.

Ponderación de la complejidad

Función Baja Media Alta Total


Número de entradas 2 ◊ _____ =  4 ◊ _____ =  6 ◊ _____ =
Número de salidas 3 ◊ _____ =  6 ◊ _____ = 12 ◊ _____ =
Número de interfaces 6 ◊ _____ = 12 ◊ _____ = 18 ◊ _____ =
Número de consultas 4 ◊ _____ =  6 ◊ _____ =  8 ◊ _____ =
Número de archivos 2 ◊ _____ =  4 ◊ _____ =  8 ◊ _____ =
Estudio de caso 8.1 287

Estudio de caso 8.1


La central eléctrica de Dulhasti
Comenzada en 1983, el proyecto de la central eléctrica apoyadas por el Gobierno paquistaní y unidades del ejér-
de Dulhasti, situada entre las provincias de Jammu y cito indio estacionadas en la región para mantener la paz. La
Cachemira al norte de India, constituye un ejemplo del construcción de una central eléctrica en la zona en disputa
desastre en la estimación de costos y fecha de entrega de se constituía en un blanco obvio para los ataques terroris-
un proyecto. En su concepción inicial, el costo del pro- tas de los grupos nacionalistas como su principal medio de
yecto se estimó en 1.6 billones de rupias (alrededor de 40 oposición. Por tanto, los costos adicionales para propor-
millones de dólares). En el momento en que el contrato se cionar seguridad al sitio de la construcción se convirtieron
inició, las estimaciones de los costos habían aumentado a rápidamente en excesivamente caros. El segundo problema
4.5 billones de rupias y más tarde a 8, 11, 16, y 24 billones era la geografía de la región donde se construiría la gran
de rupias (cerca de 750 millones de dólares). En abril de hidroeléctrica, pues estaba casi totalmente desprovista de
2008, cuando el proyecto finalmente fue inaugurado por infraestructura de apoyo, incluida una red logística adecuada
el primer ministro indio, Manmohan Singh, el costo final (carreteras y ferrocarriles). Las estribaciones de la cordillera
del proyecto fue de poco menos de 1.1 billones. del Himalaya pueden ser pintorescas, pero la construcción de
El proyecto se basa en un concepto simple: Dulhasti una hidroeléctrica no es rentable, especialmente porque casi
se diseñó como una hidroeléctrica de 390 megavatios que todos los suministros tenían que ser traídos en transporte
se construiría de forma acelerada sobre el río Chenab, en aéreo a costos exorbitantes. Todas las materias primas como
la región de Doda, una sección escarpada de la cordillera el cemento, la madera, la piedra y el acero tuvieron que trans-
del Himalaya, a varios cientos de kilómetros de las ciuda- portarse en helicóptero por kilómetros sobre áreas nevadas.
des más grandes. El proyecto consistía en construir una El trabajo en la planta continuó a trompicones
represa, levantar una central hidroeléctrica y tender cien- durante más de 20 años. Para principios del siglo, casi
tos de kilómetros de líneas de transmisión que comienzan 1,000 millones de dólares habían sido gastados en el pro-
cerca de la cabecera de un sistema de ríos que fluyen hacia yecto Dulhasti y la planta todavía no estaba en operación.
las llanuras al sur de la región montañosa. Cuando el con- Además, con el fin de compensar el costo del proyecto, el
trato se adjudicó a un precio de 50 millones de dólares, precio de la energía por generar había aumentado en más
el contratista anticipó que el proyecto podría estar termi- de 500%, lo que hacía a esta planta un productor inefi-
nado en un plazo razonable de tiempo. ciente de la energía eléctrica para el campo. El consorcio
El contrato para el proyecto de generación de ener- encabezado por los franceses que originalmente contrató
gía se adjudicó inicialmente a un consorcio francés que el desarrollo de la planta se había retirado, lo que obligó
casi de inmediato pidió una revisión al alza de los pre- al Gobierno indio a volver a licitar la obra que fue adjudi-
cios. El Gobierno indio se negó, ante la sospecha de que cada a una empresa noruega.
el consorcio francés había hecho una oferta inicial muy El proyecto fue terminado a mediados de 2008 des-
baja y esperaba simplemente “comprar” el proyecto para pués de 24 años de historia accidentada. No hay duda de
después renegociar. La negativa del gobierno a revisar el que el proyecto terminado ayudará a aliviar las necesida-
precio se tradujo en un segundo proceso de licitación. des de electricidad de la zona norte del país. De hecho, los
Debido a que en esta ocasión hubo una mayor cantidad de gobiernos estatales de Jammu y Cachemira han pedido
ofertas presentada por otros países europeos, la segunda que el control de la planta y sus ingresos se transfieran al
oferta francesa, aceptada, era aún más baja que la anterior. control local, como un medio para impulsar las economías
Aunque este proceso pareció inicialmente salvar el dinero regionales. Por otra parte, quedan las inquietudes sobre un
del Gobierno indio, no fue un buen comienzo en las rela- proyecto presupuestado inicialmente por 40 millones de
ciones entre el Gobierno y el consorcio francés. dólares que tomó más de 20 años para terminarse y tuvo un
Situada en las montañosas provincias de Jammu y costo de más de 25 veces su presupuesto inicial. ¿Fue error
Cachemira, la ubicación fue escogida para aprovechar la en la estimación, mala suerte o control equivocado del pro-
proximidad a los grandes sistemas fluviales capaces de pro- yecto? Seguramente la respuesta es: ¡los tres!23
porcionar el volumen de agua necesario para hacer funcionar
una central hidroeléctrica de las dimensiones de Dulhasti.
Preguntas
Infortunadamente, el lugar elegido para el proyecto incluía
además algunas desventajas serias. En primer lugar, se 1. Explique el reto de hacer unas estimaciones exactas
encuentra en la región fronteriza en disputa entre Pakistán de los costos cuando se trabaja en condiciones geo-
e India. Jammu y Cachemira han sido el centro de numero- gráficas adversas.
sos y graves enfrentamientos entre las fuerzas separatistas
(continúa)
288 Capítulo 8  •  Estimación de costos y presupuesto

2. El proceso de licitación original favoreció el proyecto para el Gobierno de India cuando se utiliza este tipo de
con la oferta de construcción más barata con un con- proceso de licitación? ¿Cómo este proceso contribuye
trato de precio fijo. ¿Cuáles son las ventajas y desventajas con ofertas bajas y con las sucesivas escaladas de costos?

Estudio de caso 8.2


Proyecto Central Artery/Tunnel de Boston
Desde que el proyecto “Big Dig” fue introducido por suficiente para llenar el estadio de fútbol de los Patriots
primera vez en la edición anterior de este texto, una de New England 16 veces y ha utilizado 2.9 millones de
serie adicional de eventos se han producido que requie- metros cúbicos de hormigón. El segundo gran desafío era
ren una revisión de la historia original y la actualización realizar estas actividades sin interrumpir los patrones de
del estado de este proyecto monumental. Cuando se tráfico existentes o producir un efecto perjudicial sobre el
inauguró en 1959, la autopista Central Artery de Boston sistema de la autopista actual y sus flujos de tráfico. Así,
fue aclamada como una maravilla de la ingeniería y del mientras el túnel se excava debajo de la antigua Central
urbanismo con visión de futuro. Diseñada como una Artery, el volumen de tráfico no debe ser más lento en la
autopista de seis carriles elevados por el centro de la ciu- antigua autopista elevada.
dad, la autopista tenía por objeto permitir un volumen El proyecto ha sido una fuente de controversia
de tráfico de 75,000 vehículos al día. Infortunadamente, durante varios años, sobre todo debido a sus crecientes
para la década de 1980, la Central Artery tenía un volu- costos y a las constantes revisiones del presupuesto. En
men diario de más de 200,000 vehículos, un aumento el momento del kickoff del proyecto en 1983, las proyec-
de casi tres veces los niveles de tráfico máximos pre- ciones originales asumieron como fecha de terminación
vistos. El resultado fue una de las peores congestiones 1998 y una financiación por el gobierno federal de 60%
urbanas del país, con un tráfico de vehículos pegados del presupuesto original del proyecto, es decir, 2,500
parachoques con parachoques por más de 10 horas cada millones de dólares. En realidad, el presupuesto y el pro-
día. Una tasa de accidentalidad de más de cuatro veces grama se han revisado al alza casi constante desde que el
el promedio nacional agregó mayor desdicha a los via- proyecto comenzó. Considérense los siguientes niveles
jeros de la Central Artery. Es evidente que la Central de presupuesto:
Artery-derrumbes por sobrecarga causados por la
sobreutilización hacían cada vez más peligrosa la auto-
Presupuesto (en miles
pista-había dejado de ser útil. Año de millones de dólares)
La solución al problema fue el proyecto Central
Artery/Tunnel (CA/T), comúnmente conocido por la 1983 2.56
gente de la zona de Boston como el “Big Dig.” Bajo la 1989 4.44
supervisión de la Massachusetts Turnpike Authority y con 1992 6.44
fondos federales y estatales, el proyecto CA/T consta de 1996 10.84
dos elementos principales: (1) la sustitución de la enveje- 2000 14.08
cida autopista elevada de 8-10 carriles por una autopista 2003 14.63
subterráneas de 14 carriles, directamente debajo de la
vía existente, con dos puentes sobre el río Charles, y (2) La proyección final de costos subieron a más de
extender la Interestatal 90 a través de un túnel por debajo 14,500 millones de dólares y el proyecto se inauguró ofi-
de South Boston y del puerto hasta el aeropuerto Logan. cialmente a finales de 2004, o sea con siete años de retraso.
Originalmente concebido e iniciado a principios de 1980, Las estimaciones de costos y los subsecuentes gastos eran
el proyecto ha venido ejecutándose de manera continua tan erradas que en el año 2000, una auditoría federal al pro-
(algunos dirían “dolor de cabeza”) por más de 20 años. yecto concluyó que el Big Dig estaba oficialmente en ban-
Los desafíos técnicos en el Big Dig han sido enor- carrota. Una de las conclusiones de la auditoría federal fue
mes. En su punto máximo generó alrededor de 5,000 que una de las principales causas de que los costos del pro-
empleos; el proyecto ha incluido la construcción de yecto estuvieran fuera de control se debió a la falta de una
13 kilómetros de autopista, 259 kilómetros de carri- adecuada gerencia del proyecto. Específicamente, se encon-
les en total, casi la mitad bajo tierra. Se ha requerido la tró que la gerencia del proyecto falló de forma permanente
excavación de 12 millones de metros cúbicos de tierra, en mantener a los contratistas dentro de su oferta o en
Estudio de caso 8.2 289

Michael Dwyer / Alamy

FIGURA 8.7  El Big Dig de Boston

imponer sanciones por los errores, lo que resultó en enor- La pregunta que se hace cada vez con mayor insis-
mes aumentos de costos para el Big Dig. Debido al intenso tencia es: ¿se hicieron las estimaciones originales de costos
escrutinio público y la naturaleza sensible del proyecto, los del proyecto CA/T de buena fe o se “ajustaron” para cum-
gerentes también suspendieron el seguimiento o dejaron plir las necesidades políticas? Es decir, ¿acaso los funciona-
de reconocer públicamente el aumento de los costos, por rios subestimaron deliberadamente los verdaderos costos
temor a que la reacción política podría paralizar el pro- del proyecto por temor de que el proyecto fuera rechazado
yecto. En efecto, Taypayer for Common Sense, un grupo si el público conocía la verdadera magnitud de la obra?
de vigilancia no partidista denunció que el presupuesto del Si es así, el resultado deja un sabor agridulce en la boca
proyecto se hizo tan mal que los gerentes pospusieron con- de los contribuyentes, pues el proyecto CA/T representa
tratos por valor de 260 millones de dólares a una firma de una combinación de logros técnicos brillantes asociados
consultoría, porque ellos no pudieron compensar un costo a un mal cálculo y un control laxo. El expresidente de la
tan grande a corto plazo. En respuesta a las protestas públi- Cámara de Representantes del Estado de Massachusetts
cas por los retrasos y aumento de los costos, el gerente del Thomas Finnerman, toca directamente la cuestión: “Sería
proyecto presentó su renuncia. mucho, mucho mejor si le contaran por adelantado la rea-
No sorprende que los ciudadanos de Boston hayan lidad, ‘Hey, probablemente va a tomar incontables años y
visto la apertura del Big Dig con un genuino sentido de miles de millones de dólares’, en lugar de venderlo como
ambivalencia. A pesar de ser una maravilla tecnológica un acto de humo y espejos, ‘Oh, son dos mil millones de
que sin duda va a mejorar la vida de los usuarios, en dólares y un par de años de trabajo’.”
tanto que reduce las emisiones de monóxido de carbono
y mejora la reputación “verde” de la ciudad, el proyecto Consecuencias: reconsideraciones del Big Dig
ha demostrado ser un barril sin fondo financiero, tanto Con la finalización del Big Dig, se esperaba que la con-
así que la administración de la ciudad canceló silenciosa- moción desapareciera, las quejas quedaran atendidas
mente la inauguración de la obra principal. Identificar las y que los habitantes de Boston se acostumbraran a las
causas de los errores en la estimación y en el control de ventajas de esta enorme obra. Por desgracia, ese no ha
los costos en el proyecto Big Dig ha sido un trabajo arduo. sido el caso. Desde su “conclusión” a principios de 2004,
Por su parte, la Massachusetts Turnpike Authority planea la mala prensa, los desastres y la rendición de cuentas
interponer una demanda por 150 millones de dólares en siguen persiguiendo al sistema Central Tunnel/Artery.
contra de las empresas que gerenciaron el proyecto, argu- En 2001, antes de la terminación del proyecto, miles
mentando que muchos de los sobrecostos se atribuyen a la de fugas comenzaron a aparecer en el techo de las secciones
deficiente gerencia y supervisión del proyecto. del sistema de túneles. ¿La causa? Los registros indican que el
(continúa)
290 Capítulo 8  •  Estimación de costos y presupuesto

contratista principal para el vertido del hormigón, Modern perspectiva de las relaciones públicas, los enfrentamientos
Continental, no consiguió eliminar los residuos antes de entre las autoridades estatales y federales por la supervisión
verter el hormigón, dando lugar a fallas, cavidades y bolsas y control de los proyecto con problemas es una mancha per-
de aire que debilitaron el techo y las paredes de los túneles. manente para todos los interesados.
En mayo de 2006, seis empleados del proveedor principal de A principios de 2008, los contratistas del Big Dig,
hormigón fueron detenidos por falsificación de documentos. incluidos el contratista principal, Bechtel and Parsons
En efecto, 2006 fue un año malo para el Big Dig por Brinckerhoff, fueron condenados a pagar 450 millones
diversas razones. El 10 de julio de 2006, el sistema de pernos de dólares para resolver la demanda del estado por el
y resina epóxica que sostenían cuatro secciones (12 tonela- derrumbe del túnel en el 2006. Aunque este acuerdo no
das) de paneles del techo de concreto falló, y provocó que exime a los contratistas de futuras demandas, por no resol-
una sección cayera sobre la vía matando al pasajero de un ver algunos de los errores más graves ocurridos cuando
automóvil que pasaba en ese preciso momento. Ese mes, ellos lideraron el proyecto. Michael Sullivan, el fiscal de
una inspección detallada de los paneles de techo en todo Estados Unidos que llevó el pleito, señaló que los con-
el sistema de túneles identificó otros ¡242 pernos que mos- tratistas inicialmente obtuvieron unos beneficios de 150
traban signos de estrés! El sistema de túneles fue cerrado millones de dólares por el proyecto Big Dig; sin embargo,
durante el mes de agosto para su inspección y reparación. “Han perdido dinero como resultado de las fallas que ocu-
También en agosto, el estado asumió el control del Central rrieron bajo su vigilancia.”24
Tunel/Artery quitándole esta responsabilidad a la Turnpike
Authority y alegando el pobre historial de la TA en la super-
Preguntas
visión y control eficaz de los proyectos.
El drama se convirtió en algo parecido a una farsa 1. Considere la siguiente afirmación: “Los proyectos
cuando la Turnpike Authority y la Federal Highway financiados por el Gobierno con el objetivo de servir
Administration se negaron a entregarle documentos cla- como ‘proyectos de prestigio,’ como el ‘Big Dig’, no
ves al estado, que incluían: deben juzgarse en función de los costos.” ¿Está de
acuerdo o en desacuerdo con esta afirmación? ¿Por
• Informe de deficiencias, en el que se señalabala baja qué?
calidad en los trabajos iniciales. 2. El éxito de un proyecto se define como ceñirse al pre-
• Órdenes de cambio en la obra y las revisiones a los supuesto, al cronograma, a la funcionalidad (perfor-
contratos. mance) y a la satisfacción del cliente. Según estos cri-
• Informes de avance de la obra y de la calidad de los terios, cite una evidencia que sugiera que el proyecto
materiales. “Big Dig” fue un éxito y/o fracaso.
3. ¿Cuáles son las lecciones que se pueden aprender del
Hasta que el sistema judicial ordene la entrega de todos
los documentos del proyecto, no sabremos nunca el alcance proyecto “Big Dig”? ¿Fue este un fracaso de la estima-
ción de proyectos o del control del proyecto por los
de la mala gerencia y los errores en la toma decisiones que
contratistas y el gobierno local?
acompañaron el desarrollo del CT/A. Sin embargo, desde la

Ejercicios en internet
1. En internet, busque usando la frase “las herramientas de análi- 4. Vaya al sitio www.stickyminds.com/articles.asp y haga clic en
sis de costos.” ¿Cuáles son algunos de los enlaces y ejemplos de “Stickyminds.com Original Articles.” Busque y haga clic en el
análisis de costos que se aplican a los proyectos? Ingrese ahora artículo de Karl Wiegers, “Estimation Safety Tips.” En el artí-
al sitio www.galorath.com/tools_sem.shtm. ¿Qué enfoques de culo (que se encuentra como un enlace pdf), el autor ofrece
análisis de costos de proyectos tiene en cuenta Galorath, Inc.? consejos para evitar errores comunes y obtener estimaciones
2. En el sitio http://pmworldtoday.net/ en el enlace de búsqueda es- precisas y justificables. ¿Cuál de estos puntos tiene más sentido
criba la frase “estudios de caso.” Seleccione un proyecto y su res- para usted? ¿Por qué le parece una sugerencia plausible?
pectivo informe desde la perspectiva de la estimación de costos,
la elaboración de presupuestos y (si procede) de la aceleración de Preguntas de ejemplo del examen para la certificación
actividades. ¿Fue el proyecto un éxito o un fracaso? ¿Por qué? PMP®
3. Vaya al sitio www.seattlearch.org/NR/rdonlyres/BBDEC5EC-
8DD6- 4A4D-8AB7-DE63476E8C3/0/ABCBudgetWorksheet. 1. El gerente del proyecto prepara el presupuesto del pro-
pdf y copie la hoja del resumen del presupuesto del proyecto. yecto y suma el costo de un computador nuevo para uso
Después de examinar los distintos elementos del presupuesto, del equipo del proyecto. ¿Qué tipo de costo es la compra
¿cuáles son los principales generadores de costos para los de este computador?
proyectos de ese tipo de construcciones? a. Variable
Ejercicios en internet 291

b. Directo gerentes de proyecto de alto nivel, con experiencia en pro-


c. Indirecto yectos similares para desarrollar un estimativo de costos
d. Variable directo del proyecto. Este proceso es un ejemplo de:
a. Costos basados en actividades
2. La gerente de un gran proyecto que se desarrolla en el
b. Planeación de contingencias
norte de Ontario estima que es necesario que ella tenga
c. Presupuestación de arriba abajo
presencia en la obra en construcción durante su desarrollo
d. Estimación de costos
y ha negociado el uso de un edificio para su equipo cerca
del proyecto. El costo del edificio debe tenerse en cuenta 5. Juan elabora el presupuesto para un proyecto y como parte
dentro de los costos del proyecto y aumenta con el uso, es del proceso solicita y examina activamente estimaciones
decir, el costo de la calefacción y otros servicios está sujeto a cada uno de los miembros del equipo del proyecto. Él
a variaciones dependiendo del uso del servicio. ¿Qué tipo presenta su presupuesto a la alta gerencia y Susan lo re-
de costo representa este edificio? chaza, al afirmar: “Los miembros del equipo siempre van
a. Variable directo a rellenar sus estimaciones. Yo le daré la cifra que quiero
b. Indirecto que use.” ¿Qué método usa Susan para el proyecto de pre-
c. No recurrente supuesto de costos?
d. Ninguno de los anteriores a. Abajo arriba
b. Arriba abajo
3. El presupuesto de un proyecto tenía asignado 5,000 dó-
c. Paramétrico
lares para los gastos de programación. El monto real de
d. Comparativo
los costos de programación fue de 5,450 dólares. ¿Cuál
de las siguientes afirmaciones es correcta?
Respuestas: 1. b—La compra del computador es un ejemplo
a. Los $450 representan una varianza negativa del
de costo directo; 2. a—Los costos por el uso de las oficinas va-
presupuesto
rían de acuerdo con su utilización y deben cargarse como costo
b. No hay una varianza del presupuesto
directo al proyecto; 3. c—La sobreejecución de $450 se debe re-
c. Los $450 representan una varianza positiva del
gistrar como una variación positiva del presupuesto; 4. d—El
presupuesto
proceso de preguntarles a los gerentes de proyectos de alto nivel
d. Los $5,450 representan una variación positiva del
por sus mejores estimaciones para el proyecto de costos es parte
presupuesto
del proceso de estimación de costos; 5. b—Susan, como gerente
4. La etapa de planeación del proyecto está avanzando. El general, usa el método arriba abajo mediante el cual suministra
equipo del proyecto ha solicitado la opinión de varios los estimativos de costos del presupuesto.
292 Capítulo 8  •  Estimación de costos y presupuesto

PROYECTO INTEGRADO

Desarrollo de las estimaciones de costos y presupuesto


Desarrolle una estimación detallada de los costos y una declaración del alcance del proyecto que soporte su
oferta inicial, incluida la EDT. Elabore una justificación detallada de los costos de personal, de materiales,
de los gastos generales y de otros costos que eventualmente puedan generarse en su proyecto. Sea específico,
sobre todo en lo relativo a los gastos de personal y al tiempo requerido. Por ejemplo, el cuadro de costos podría
ser el siguiente:

Tarifa con Semanas de trabajo


Personal Nivel Tarifa recargo necesarias Costo total
Programador Sénior $35 $49/h 20 $39,200
Analista de sistemas Júnior $22 $31/h 10 $12,400
*40 horas por semana.

Recuerde que la “Tarifa con recargo” incluye los gastos generales de la organización por cada empleado. Un
multiplicador normal para esta cifra puede ser hasta de 100% del salario del empleado. Asegúrese de que el ins-
tructivo del curso indique el porcentaje de gastos generales que debe aplicar a su proyecto. Por tanto, utilizando
el ejemplo del programador sénior con una tarifa con recargo y suponiendo un multiplicador de 1.40 tenemos:

($49) (40h) (20 semanas) (1.40) = $54, 880

Ejemplo de plan de proyecto: ABCups, Inc.

Salario
(incluye Tarifa Tiempo
Recurso prestaciones hora Tarifa plena necesario Duración
Nombre tipo Cargo sociales) ($) (recargo= .40) (h/semana) (semanas) Total
Carol Seguridad Ingeniero de 64,600 32.30 45.22 10 h/semana 15 $ 6,783
Johnson seguridad
Bob Hoskins Ingeniería Ingeniero 35,000 17.50 24.50 20 h/semana 35 17,150
industrial
Sheila Gerencial Gerente de 55,000 27.50 38.50 40 h/semana 50 77,000
Thomas proyecto
Randy Egan Gerencial Gerente de 74,000 37.00 51.80 10 h/semana 6 3,108
planta
Stu Hall Industrial Supervisor 32,000 16.00 22.40 15 h/semana 8 2,688
mantenimiento
Susan Berg Contador Contador de 45,000 22.50 31.50 10h/semana 12 3,780
costos
Marty Green Industrial Supervisor de 24,000 12.00 16.80 10 h/semana 3 504
tiendas
John Pittman Calidad Ingeniero de 33,000 16.50 23.10 20 h/semana 25 11,550
calidad
Sally Reid Calidad Jr. Ingeniero de 27,000 13.50 18.90 20 h/semana 18 6,804
calidad
Lanny Adams Ventas Gerente de 70,000 35.00 49.00 10 h/semana 16 7,840
marketing
Kristin Abele Compras Agente de 47,000 23.50 32.90 15 h/semana 20    9,870
compras
Total $147,077

292

Presupuesto de fase-tiempo para ABCups, Inc.

Paquetes de trabajo Junio Julio Ago. Sep. Oct. Nov. Dic. Ene. Feb. Mar. Abril Mayo Total
Factibilidad 2,500 2,500
Selección de 7,678 3,934 1,960 3,934 17,506
proveedores
Diseño 12,563 8,400 5,300 26,263
Ingeniería 9,992 14,790 15,600 40,382
Pruebas del prototipo 3,250 12,745 7,250 23,245
Ventas y servicio 1,467 4,467 1,908 7,842
Embalaje 2,434 8,101 650 11,185
Montaje 1,676 9,234 890 11,800
Cierre 1,198 5,156 6,354
Mensual planeado 10,178 3,934 14,523 12,334 15,292 18,040 29,812 14,151 11,685 9,884 2,088 5,156
Acumulado mes 10,178 14,112 28,635 40,969 56,261 74,301 104,113 118,264 129,949 139,833 141,921 147,077 147,077
Proyecto integrado 293
294 Capítulo 8  •  Estimación de costos y presupuesto

Notas
1. Klamper, A. (2010, 15 de noviembre). “NASA’s space tele- 15. Para discutir acerca de las normas COCOMO II, véase http://
scope cost overruns may imperil other projects,” www.space. sunset.usc.edu/csse/research/COCOMOII/cocomo_main.html.
com/9530-nasa-space-telescope-cost-overruns-imperilprojects. 16. McConnell, S. (2004). Code Complete. Redmond, WA:
html; Moulds, J. (2006, 28 de septiembre). “IT providers left Microsoft.
in the debris of NHS’s ‘big bang,’” The Telegraph, www.tele- 17. Turbit, N. “Function points overview,” www.projectperfect.
graph.co.uk/finance/2948063/IT -providersleft-in-the-debris- com.au/downloads/Info/info_fp_overview.pdf; International
of-NHSs-big-bang.html; http://en.wikipedia.org/wiki/NHS_ Functional Points Users Group, www.ifpug.org; Dillibabu, R.,
Connecting_for_Health; Doward, J. (2008, 10 de agosto). “Chaos and Krishnaiah, K. (2005). “Cost stimation of a software product
as £13bn computer system falters,” The Guardian, www.guard- using COCOMO II.2000 model—a case study,” International
ian.co.uk/society/2008/aug/10/nhs.computersystem; Goldstein, Journal of Project Management, 23(4): 297–307; Jeffery, R.,
H. (2005, septiembre).“Who killed the Virtual Case File?” IEEE Low, G. C., and Barnes, M. (1993). “A comparison of function
Spectrum, http://spectrum.ieee.org/computing/software/who- point counting techniques,” IEEE Transactions on Software
killed-the-virtual-case-file; Charette, R. (2010, 21 de octubre). Engineering, 19(5): 529–32.
“FBI’s Sentinel project: In bad shape as IG claims, or now okay, as 18. Hamburger, D. (1986). “Three perceptions of project cost—Cost
FBI management claims?” IEEE Spectrum, http://spectrum.ieee. is more than a four-letter word,” Project Management Journal,
org/riskfactor/computing/it/fbis-sentinel-project-in-bad-shape- 17(3): 51–58; Sigurdsen, A. (1996). “Principal errors in capital cost
as-ig-claims-ornow-okay-as-fbi-management-claims. estimating work, part 1: Appreciate the relevance of the quantity-
2. Needy, K. S., and Petri, K. L. (1998). “Keeping the lid on project dependent estimating norms,” Project Management Journal, 27(3):
costs,” in Cleland, D. I. (Ed.), Field Guide to Project Management. 27–34; Toney, F. (2001). “Accounting and financial management:
New York: Van Nostrand Reinhold, pp. 106–20. Finding the project’s bottom line,” in J. Knutson (Ed.), Project
3. Miller, G. J., and Louk, P. (1988). “Strategic manufacturing Management for Business Professionals. New York: John Wiley,
cost management,” APICS 31st International Conference pp. 101–27; Shtub, A., Bard, J. F., and Globerson, S. (1994). Project
Proceedings, Falls Church, VA: API CS; Kerzner, H. (1988). Management: Engineering, Technology, and Implementation.
“Pricing out the work,” in Cleland, D. I., and King, W. R. Englewood Cliffs, NJ: Prentice-Hall; Smith, N. J. (Ed.). (1995).
(Eds.), Project Management Handbook, 2nd ed. New York: Project Cost Estimating. London: Thomas Telford; Sweeting, J.
Van Nostrand Reinhold, pp. 394–410. (1997). Project Cost Estimating: Principles and Practices. Rugby,
4. Meredith, J. R., and Mantel, Jr., S. J. (2003). Project UK: Institution of Chemical Engineers; Goyal, S. K. (1975). “A
Management, 5th ed. New York: Wiley. note of a simple CPM time-cost tradeoff algorithm,” Management
5. Needy, K. S., and Petri, K. L. (1998). “Keeping the lid on Science, 21(6): 718–22; Venkataraman, R., and Pinto, J. K. (2008).
project costs,” in Cleland, D. I. (Ed.), Field Guide to Project Cost and Value Management in Projects. New York: Wiley.
Management. New York: Van Nostrand Reinhold, pp. 106–20. 19. Flyvbjerg, B., Garbuio, M., and Lavallo, D. (2009). “Delusion and
6. Fuente del cuadro 8.2: Needy, K. S., and Petri, K. L. (1998). deception in large infrastructure projects: Two models for explain-
“Keeping the lid on project costs,” in Cleland, D. I. (Ed.), ing and preventing executive disaster,” California Management
Field Guide to Project Management. New York: Van Nostrand Review, 51(2): 170–93; “Building BRICs of growth.” (2008, 7 de
Reinhold, p. 110. junio). The Economist, www.economist.com/node/11488749;
7. Lock, D. (2000). “Managing cost,” in Turner, J. R., and Simister, Lovallo, D., and Kahneman, D.(2003). “Delusions of success: How
S. J. (Eds.), Gower Handbook of Project Management, 3rd ed. optimism undermines executives’ decisions,” Harvard Business
Aldershot, UK: Gower, pp. 293–322. Review, 81(7): 56–63; Flyvbjerg, B., Holm, M. S., and Buhl, S.
8. Amor, J. P., and Teplitz, C. J. (1998). “An efficient approxima- (2002). “Underestimating costs in public works projects: Error or
tion for project composite learning curves,” Project Management lie?” Journal of the American Planning Association, 68(3): 279–95.
Journal, 29(3): 28–42; Badiru, A. B. (1995). “Incorporating learn- 20. Meredith, J. R., and Mantel, Jr., S. J. (2003). Project Manage­
ing curve effects into critical resource diagramming,” Project ment, 5th ed. New York: Wiley; véase también Christensen,
Management Journal, 26(2): 38–46; Camm, J. D., Evans, J. R., and D. S., and Gordon, J. A. (1998). “Does a rubber baseline guar-
Womer, N. K. (1987). “The unit learning curve approximation antee cost overruns on defense acquisition contracts?” Project
of total cost,” Computers in Industrial Engineering, 12: 205–13; Manage­ment Journal, 29(3): 43–51.
Fields, M. A. (1991). “Effect of the learning curve on the capital 21. Maher, M. (1997). Cost Accounting: Creating Value for
budgeting process,” Managerial Finance, 17(2–3): 29–41; Teplitz, Management, 5th ed. Chicago: Irwin.
C. J., and Amor, J. P. (1993). “Improving CPM’s accuracy using 22. Gray, C. F., and Larson, E. W. (2003). Project Management,
learning curves,” Project Management Journal, 24(4): 15–19. 2nd ed. Burr Ridge, IL: McGraw-Hill.
9. Meredith, J. R., and Mantel, Jr., S. J. (2003). Project 23. Kharbanda, O. P., and Pinto, J. K. (1996). What Made Gertie
Management, 5th ed. New York: Wiley. Gallop? New York: Van Nostrand Reinhold; www.jammu-
10. Amor, J. P., and Teplitz, C. J. (1998). “An efficient approxi- kashmir.com/archives/archives2007/kashmir20070508a.
mation for project composite learning curves,” Project html; www.india-server.com/news/pm-dedicates-dulhas-
Management Journal, 29(3): 28–42. tiproject-to-nation-589.html.
11. Crawford, J. R. (n.d.), Learning curve, ship curve, rations, re- 24. “Boston’s Big Dig opens to public.” (2003, 20 de diciembre). www.
lated data. Burbank, CA: Lockheed Aircraft Corp. msnbc.com/id/3769829; www.masspike.com/bigdig; “Big Dig
12. Heiser, J., and Render, B. (2001). Operation Management, 6th billions over budget,” www.taxpayer.net/TCS/wastebasket/trans-
ed. Upper Saddle River, NJ: Prentice Hall. portation/4-12-00.htm; “Massachusetts to sue Big Dig compa-
13. Hackbarth, G. (2005), comunicación personal. nies,” www.msnbc.msn.com/id/15917776; “Big Dig contractors
14. “Extreme chaos.” (2001). Standish Group International. to pay $450 million,” www.msnbc.msn.com/id/22809747.
CAPÍTULO

9
Programación del proyecto
Redes, estimación de la duración y ruta crítica

Contenido del capítulo


PERFIL DE PROYECTO Probabilidad de terminación del proyecto
Sudáfrica tiene los estadios listos para la Copa Mundo 2010 Actividades de escalamiento
INTRODUCCIÓN Actividades resumen
9.1 PROGRAMACIÓN DEL PROYECTO Opciones para reducir la ruta crítica
9.2 TERMINOLOGÍA CLAVE DE PROGRAMACIÓN INVESTIGACIÓN DE GERENCIA DE PROYECTOS EN
SÍNTESIS
9.3 DESARROLLO DE UNA RED
Retrasos y soluciones en el desarrollo de software
Etiquetado de nodos
Resumen
Actividades en serie
Términos clave
Actividades concurrentes
Problemas resueltos
Actividades convergentes
Preguntas para discusión
Actividades divergentes
Problemas
9.4 ESTIMACIÓN DE LA DURACIÓN Ejercicios en internet
9.5 CONSTRUCCIÓN DE LA RUTA CRÍTICA Ejercicios con MS Project
Cálculo de la red Preguntas de ejemplo del examen para la certificación PMP®
Recorrido hacia adelante Notas
Recorrido hacia atrás

Objetivos de aprendizaje
Al finalizar el capítulo, el estudiante estará en capacidad de:
1. Entender y aplicar la terminología clave de programación.
2. Aplicar la lógica utilizada para crear redes de actividades que incluyan tareas predecesoras y sucesoras.
3. Desarrollar una red de actividades utilizando la técnica actividad en el nodo (activity-on-node:AON).
4. Estimar la duración de las actividades, con base en el uso de técnicas de estimación de probabilidad.
5. Construir la ruta crítica para la red del cronograma del proyecto utilizando los recorridos hacia adelante
y hacia atrás.
6. Identificar la holgura de una actividad y la manera en que esta se determina.
7. Calcular la probabilidad de terminación de un proyecto en un tiempo determinado, según las estimaciones
PERT.
8. Comprender los recorridos que se pueden dar para reducir la ruta crítica.
295
296 Capítulo 9  •  Programación del proyecto

CONCEPTOS BÁSICOS DE LOS FUNDAMENTOS PARA LA GERENCIA DE PROYECTOS


(PROJECT MANAGEMENT BODY OF KNOWLEDGE,PMBOK® GUIDE, 5A. EDICIÓN)
CUBIERTOS EN ESTE CAPÍTULO
1. Definición de actividades (PMBOK®, sección 6.2).
2. Secuenciación de actividades (PMBOK®, sección 6.3).
3. Estimación de los recursos para las actividades (PMBOK®, sección 6.4).
4. Estimación de la duración de las actividades (PMBOK®, sección 6.5).
5. Desarrollo del cronograma (PMBOK®, sección 6.6).
6. Control del cronograma (PMBOK®, sección 6.7).

PERFIL DE PROYECTO

Sudáfrica tiene los estadios listos para la Copa Mundo 2010

El deporte tiene el poder de cambiar el mundo. Tiene el poder de unir de una manera que pocos lo hacen.
—Nelson Mandela, primer presidente de Sudáfrica elegido democráticamente

La Copa Mundo, el evento más visible y perdurable de fútbol internacional, tiene lugar una vez cada cuatro años
en lugares seleccionados con casi una década de anticipación. Varios países ofrecen para ganar el derecho a orga-
nizar la Copa Mundo y después de meses de intensa competencia, cuando se anuncian los ganadores, el evento
genera celebraciones de júbilo en el país ganador y tristeza, en los demás países. Un aspecto de enorme impor-
tancia en la decisión de hacer una oferta para realizar la Copa Mundo es si la infraestructura del país respalda la
candidatura y, en definitiva, si el evento que se llevará a cabo en un ambiente positivo de emoción y competencia.
El ganador de la puja para la Copa Mundo 2010 fue Sudáfrica, la primera nación africana en organizar el
torneo en sus 80 años de historia. A pesar de poseer la economía más fuerte del hemisferio sur del continente afri-
cano, con una cultura vibrante y un entusiasmo natural surgido después del apartheid, Sudáfrica no es una nación
rica ni una que podría absorber fácilmente los costos de acometer la celebración de este campeonato. Los retos
eran enormes. En un periodo relativamente corto, Sudáfrica gastó más de 6,000 millones de dólares y se involucró
en una serie de proyectos importantes para apoyar la Copa Mundo, incluidos:
• Construcción de estadios—Un total de diez sedes tuvieron que desarrollarse en todo el país para el torneo.
Cinco estadios existentes necesitaron remodelarse con ascensores u otras reformas, y otros cinco tuvieron que
construirse.
• Modernización de los aeropuertos—Varios aeropuertos en todo el país tuvieron que reconstruirse, para apoyar
los eventos, con el fin de permitir el flujo de turistas y pasajeros de un evento a otro.
• Reparación y desarrollo de la infraestructura vial—Junto a los trabajos de construcción de los estadios y los aero-
puertos, cientos de kilómetros de carreteras tuvieron que ampliarse, reconstruirse o repararse, en gran medida
para apoyar los flujos de tráfico. El gobierno de Sudáfrica invirtió más de 2,000 millones de dólares en proyectos
de transporte e infraestructura, con la esperanza de que sean un legado duradero de la Copa Mundo para el país.
• Un tren de alta velocidad—Se puso en marcha el primer eslabón de la red ferroviaria de alta velocidad de África,
el "Gautrain", con un recorrido entre el centro financiero de Sandton de Johannesburgo y el aeropuerto inter-
nacional O.R. Tambo. El trabajo del ferrocarril se aprobó incluso antes de que la Copa Mundo fuera otorgada a
Sudáfrica y su construcción se adelantó para ayudar al país a enfrentar el flujo de turistas durante el evento de un
mes de duración. Se esperaba que el tren prestara su servicio de transporte de manera eficiente y accesible para
la población en general, durante muchos años, después de la Copa Mundo y ayudara a aliviar los problemas de
tráfico.
• Desarrollo de espacios públicos y parques urbanos—Al considerar que la Copa Mundo atrae a turistas de todo el
mundo, los más pobres dentro de Sudáfrica no podrían asistir a ningún juego. Al reconocer que en realidad lle-
gar al estadio de Johannesburgo podría ser difícil para los más de 3.5 millones de habitantes de esta ciudad, los
funcionarios también aprovecharon la Copa Mundo como motor económico para construir una serie de espacios
públicos en algunas de las zonas menos favorecidas de la ciudad. Solo en Johannesburgo, el gobierno construyó
23 nuevos parques públicos e instalaciones comunitarias con pantallas gigantes para permitirles a los residentes
ver los partidos. Construcciones similares se realizaron en todo el país, que produjeron nuevos y enormes zonas
verdes y espacios públicos.
La construcción del estadio era una labor particularmente impresionante dentro del camino de Sudáfrica para organi-
zar la Copa Mundo. Los estadios construidos en diez lugares en todo el país, tenían modelos impresionistas y diseños
Perfil de proyecto 297

Allstar Picture Library / Alamy


FIGURA 9.1  Soccer City Stadium de Johanesburgo

artísticos. Por ejemplo, la más extensa renovación, en el Soccer City Stadium de Johannesburgo, implicó 700,000 pies
cuadrados. Inaugurado en 1987, el Soccer City fue el primer estadio de fútbol internacional de Sudáfrica; allí también
se reunieron los ciudadanos cuando Nelson Mandela fue liberado de prisión en 1990. Las empresas de construcción
cambiaron la fachada del edificio y la transformaron en un colorido mosaico de baldosas de hormigón con fibra de
vidrio reforzada, con la intención de hacerlo semejante a un fruto de calabaza, un árbol tradicional africano, con ven-
tanas intercaladas. El estadio albergó 94,000 espectadores en el partido final.

Problemas en el camino
Con esta enorme labor, los gastos de los recursos nacionales y el compromiso de todo el país para acoger este
evento, la preparación para la Copa Mundo no fue muy fluida. Los proyectos se comportaron muy por encima
del presupuesto y sobrepasaron los plazos, hechos que comprometieron su viabilidad. El costo del sistema de
tránsito rápido de autobuses (Bus Rapid Transit: BRT) de la Ciudad del Cabo se disparó desde un estimado de 171
millones de dólares en 2008 a más de 600 millones de dólares, y se anunció que una sección del sistema de BRT de
Johannesburgo a Rea Vaya no estaría lista a tiempo para el torneo, como se había planeado. Anteriormente, las
expectativas optimistas para el sistema Gautrain en Johannesburgo se habían descartado. Además, los sistemas BRT
planeados se retrasaron o cancelaron en Durban, Bloemfontein y Tshwane.
Muchos de los proyectos de estadios se afectaron por graves retrasos en los plazos o por protestas relacionadas
con las prácticas de licitación de la construcción. De hecho, se presentaron acusaciones de "manipulación de las lici-
taciones" en contra de funcionarios del gobierno; en algunos casos, la financiación aprobada inicialmente luego fue
negada temporalmente, lo cual obligó a detener la construcción o a interrumpir los cronogramas en muchos sitios.
En varios lugares, incluido el estadio Green Point de Ciudad del Cabo, el estadio Mbombela, en Nelspruit, y el estadio
King’s Park en Durban, se afectaron negativamente por las interrupciones en la financiación o por las protestas.
El 9 de julio de 2009, 70,000 trabajadores de la construcción se declararon en huelga en todo el país, y exigieron
aumentos de 13% para continuar trabajando en los diferentes proyectos relacionados con la Copa Mundo. Los traba-
jadores amenazaron con retrasar o detener la construcción si sus niveles salariales no se llevaban a niveles aceptables.
Sus huelgas se produjeron en un momento particularmente vulnerable para los organizadores del evento, ya que
numerosos estadios aún estaban en construcción y gran parte de las obras de infraestructura aún se encontraban en
curso. La FIFA amenazó con empezar a multar al país si no se hacía nada para reanudar la construcción. El gobierno
de Sudáfrica negoció con el sindicato que lideraba el paro y rápidamente puso fin a la huelga, después de haber acep-
tado aumentos salariales considerables y otros beneficios para los trabajadores de la construcción.
Aún más polémico fue el documental Fahrenheit 2010 que acusó a Sudáfrica de desviar los escasos recursos
para atender la epidemia del VIH/SIDA y otras causas sociales urgentes. La película apuntaba especialmente al
Mbombela Stadium por falta de uso efectivo después de la Copa Mundo.
(continúa)
298 Capítulo 9  •  Programación del proyecto

A pesar de estos problemas y distracciones, la Copa Mundo, que vio a España ganar su primer campeonato,
fue un evento próspero y bien dirigido. Unos 400,000 aficionados y turistas visitaron Sudáfrica durante el mes de la
Copa Mundo, y se llevaron consigo un caudal de recuerdos duraderos de modernas instalaciones e infraestructura
y de eventos bulliciosos administrados magníficamente. El editorial de The Economist del 3 de junio señalaba que
Sudáfrica, un país lleno de problemas, era digno de elogio por su preparación para la Copa Mundo. "Los escépticos
dijeron que Sudáfrica nunca lo haría", refirió el artículo. "Sin embargo, después de invertir miles de millones de
dólares y con muchos dolores de cabeza, está lista. Con diez espectaculares estadios nuevos o modernizados, así
como con muchos aeropuertos nuevos o renovados, cientos de kilómetros de carreteras y de calles ampliadas en las
ciudades y con el primer tren de alta velocidad del continente en funcionamiento, Sudáfrica está merecidamente
orgullosa de su logro.”1

INTRODUCCIÓN
La programación de proyectos es una tarea compleja que implica una serie de pasos relacionados. Cuando
pensamos en la programación, ayuda mucho si nos imaginamos un rompecabezas gigante. Al principio,
trazamos una frontera y empezamos a crear una imagen mental de cómo se diseñan las piezas para encajar.
A medida que el cuadro empieza a tomar forma, podemos añadir más y más piezas, dando poco a poco la
forma del rompecabezas y de la imagen. Cada paso en la construcción del rompecabezas depende de haber
realizado el trabajo anterior correctamente. De esta manera, las metodologías de programación de proyectos
se construyen una sobre otra. La programación de proyectos requiere que sigamos cuidadosamente algunos
pasos, con el fin de que el cronograma tome forma. Al igual que un rompecabezas que con el tiempo, si se ha
seguido el procedimiento correctamente, producirá un cuadro acabado, la forma del cronograma del pro-
yecto también se enfocará correctamente cuando nos enteramos de los pasos necesarios para llevarlo a cabo.

9.1  PROGRAMACIÓN DEL PROYECTO


Las técnicas de programación del proyecto se encuentran en el centro de la planeación de proyectos y del
subsecuente seguimiento y control. Los capítulos anteriores examinaron el desarrollo de la visión y de las
metas del proyecto, las actividades de selección de proyectos, las prácticas de gerencia de riesgos y del alcance
del proyecto (incluida la estructura de desglose de trabajo). La programación de proyectos representa la con-
versión de las metas del proyecto en una metodología viable para su realización, crea un cronograma y pone
de manifiesto la lógica de la red que relaciona las actividades del proyecto entre sí, de una manera coherente.
Debido a que la gerencia del proyecto se basa en completar un conjunto finito de metas en un tiempo espe-
cificado, cómo se desarrolla exactamente el cronograma del proyecto es de vital importancia para su éxito.
En este capítulo se examinará una serie de elementos de la programación de proyectos y mostrará
cómo construir el plan de proyecto de un conjunto simple de actividades de los proyectos identificando en
una gráfica las relaciones secuenciales entre las tareas que, cuando se realizan, dan lugar al logro de las metas
del proyecto. La planeación del proyecto, en relación con el proceso de programación, se define según la
Project Management Body of Knowledge como "la identificación de los objetivos del proyecto y de las acti-
vidades ordenadas necesarias para completar el proyecto, incluidas la identificación de los tipos y cantidades
de recursos necesarios para llevar a cabo cada actividad o tarea.”2 La expresión actividad ordenada es impor-
tante porque ilustra la meta de la programación. La programación del proyecto define la red lógica de todas
las actividades, es decir, las tareas predecesoras o sucesoras a otras tareas desde el principio del proyecto
hasta su terminación.
Supongamos que a usted y a su equipo de clase se les asignó una tarea sobre liderazgo y se espera que
entreguen un artículo y hagan una presentación al final del semestre. Primero sería necesario dividir la asig-
nación en un conjunto discreto de actividades individuales (estructura de desglose del trabajo: EDT) que le
permita a su equipo completar el proyecto. Tal vez usted podría identificar las siguientes actividades:
1. Identificar el tema
2. Investigar el tema
3. Escribir el primer borrador del artículo
4. Editar y reescribir el artículo
5. Preparar la presentación en clase
9.1  Programación del proyecto 299

6. Completar el documento final


7. Completar la presentación
8. Entregar el artículo y presentar el tema en la clase
Definir cuidadosamente todos los pasos necesarios para completar la tarea es la primera actividad importante
en la planeación del proyecto, puesto que proporciona una lógica secuencial de las tareas y va más allá, porque le
permite elaborar un plan de proyecto coherente de principio a fin. Supongamos que, para asegurar el mejor uso
de su tiempo y de la disponibilidad, va a crear una red de las actividades mencionadas anteriormente, es decir, el
orden más probable en que deben ejecutarse para hacer la tarea correctamente. En primer lugar, sería necesario
determinar una secuencia razonable para las actividades. Las actividades predecesoras son aquellas que deben
realizarse antes de que otras puedan ejecutarse. Por ejemplo, primero se identifica el tema del artículo antes de
comenzar a realizar una investigación sobre este. Por tanto, la actividad 1, Identificar el tema, precede a la acti-
vidad 2, Investigar el tema, una actividad posterior o sucesora.
Una vez identificada la secuencia lógica razonable para la red, se puede construir un diagrama de
red, el cual visualiza esquemáticamente las actividades secuenciadas del proyecto y sus relaciones lógicas. La
figura 9.2 muestra dos ejemplos de red para su proyecto. Note que en la opción A, el método más fácil en la
construcción del diagrama de red es simplemente disponer todas las actividades en serie, que empieza con
la primera actividad y se concluye con la última. Esta opción, si embargo, no es la más eficiente. Se podría
argumentar, por ejemplo, que no es necesario que todo el equipo participe en cada una de las actividades, lo
cual retrasaría el inicio de la actividad 6, completar el documento final (F en la figura 9.2), hasta después de la
actividad 5, preparar la presentación de la clase. Otra opción sería utilizar mejor el tiempo ocupando a algu-
nos de los miembros del equipo en el inicio de la presentación, mientras otros trabajan en la finalización del
documento. Cualquiera de estas opciones significa que usted está construyendo una red del proyecto con dos
caminos, o flujos de actividades paralelas, algunas de las cuales avanzan simultáneamente. Esta alternativa de
red se muestra en la opción B de la figura 9.2.
Este ejemplo simplificado ilustra el proceso de aplicación de la lógica secuencial a las tareas del proyecto,
con el fin de construir una red de actividades. Al crear un sentido de sincronización entre las actividades, ade-
más de sus funciones, la red de actividades les permite a los equipos de proyecto utilizar un método de pla-
neación y programación. Hay varias razones por las que es tan importante que las redes y programación del
proyecto deban hacerse bien, entre ellas las siguientes:3

Opción A: secuencia lógica seriada

A B C D
Identificar Investigar Borrador Editar el
el tema el tema del artículo artículo

E F G
H
Preparar la Documento Finalizar la
Finalización
presentación final presentación

Opción B: secuencia lógica no seriada

D F
Editar el Documento
artículo final

A B C
Identificar Investigar Borrador H
tema el tema del artículo Finalización

E G
Preparar la Finalizar la
presentación presentación

FIGURA 9.2  Redes de actividades alternativas para la tarea de elaboración de un artículo


300 Capítulo 9  •  Programación del proyecto

• Una red ilustra claramente la interdependencia de todas las tareas y los paquetes de trabajo. Cometer
errores en etapas tempranas del proyecto tiene graves implicaciones para las actividades posteriores.
• Debido a que una red ilustra esta interrelación entre las actividades y el personal del proyecto, facilita
los flujos de comunicación. La gente está más sintonizada con el trabajo que va luego de su participa-
ción, y aprecia más los aspectos que tendrá a cargo posteriormente.
• Una red ayuda a la programación maestra de los recursos de la organización, puesto que muestra
momentos en que varios miembros del personal deben estar plenamente comprometidos con las acti-
vidades del proyecto. Sin un sentido claro de dónde se inscribe el proyecto en el esquema general de
la organización, el personal podría asignarse a múltiples actividades en el momento en que más se
requiere en el proyecto.
• Una red identifica las actividades claves y las distingue de las menos claves. La red pone de manifiesto las
actividades que se deben completar a tiempo para asegurarse de que todo el proyecto se entregue oportu-
namente; en este proceso, las actividades con poco "margen de maniobra" también se identifican.
• Las redes determinan cuándo se puede esperar que los proyectos se completen.
• Las fechas en las que las diversas actividades del proyecto deben comenzar y terminar, con el fin de
mantener la programación general, se identifican en la red.
• Una red muestra qué actividades dependen de otras actividades. A continuación, identifica las activida-
des que deben realizarse de forma muy coordinada, a fin de garantizar el buen desarrollo del proyecto.
Estas son solo algunas de las ventajas del uso de redes de actividades para la programación del proyecto.

9.2  TERMINOLOGÍA CLAVE EN LA PROGRAMACIÓN DEL PROYECTO


Cada profesión tiene su jerga y terminología. En la programación de proyectos, comúnmente se emplea una
serie de términos que, por tanto, requieren definiciones específicas. En muchos casos, sus definiciones se
toman del Project Management Institute’s Body of Knowledge. Algunos conceptos que se utilizan una y otra
vez a lo largo de este capítulo (y en capítulos posteriores) se enumeran en seguida. Usted ya ha manejado
algunos de estos términos en capítulos anteriores.

Actividad convergente—Una actividad con dos o más actividades predecesoras inmediatas (tareas que flu-
yen hacia adentro). Las actividades convergentes se localizan al hacer un recorrido hacia adelante a lo
largo de la red.
Actividad divergente—Una actividad con dos o más actividades sucesoras (tareas que fluyen hacia afuera).
Las actividades divergentes pueden localizarce al hacer un recorrido hacias atrás a lo largo de la red.
Alcance—Contenido del trabajo y productos de un proyecto o un componente de un proyecto. El alcance
se describe por completo al nombrar todas las actividades realizadas, los recursos consumidos y los
productos finales que resultan, incluidos los estándares de calidad.
Diagrama de red del proyecto (proyect network diagram: PND)—Toda visualización esquemática de las
relaciones lógicas entre las actividades del proyecto.
Estructura de desglose del trabajo (EDT)—Un "árbol genealógico" de las actividades que organiza, define
y muestra gráficamente el trabajo total que debe realizarse, con el fin de alcanzar los objetivos finales
del proyecto. Cada nivel descendente representa una definición cada vez más detallada del objetivo del
proyecto.
Evento—Un punto en una actividad ya sea su inicio o su final. A menudo utilizadas con las redes actividad en la
flecha (activity on arrow: AOA), los eventos no consumen recursos ni tienen tiempo de duración asociados
a estos.
Fecha de fin tardío (late start: LS)—Fecha de fin tardío en que una actividad puede comenzar sin demorar
un hito específico (normalmente la fecha de terminación del proyecto).
Fecha de inicio temprano (early start: ES)—Fecha de inicio temprano en la que las partes no completadas
de una actividad (o proyecto) pueden comenzar, basada en la lógica red y las restricciones del crono-
grama. Las fechas de inicio temprano pueden cambiar a medida que el proyecto avanza y se realizan
cambios en el plan del proyecto.
Holgura—Cantidad de tiempo que una actividad puede retrasarse desde su inicio temprano, sin retrasar
la terminación del proyecto. La holgura es un cálculo matemático y puede cambiar a medida que el
9.3  Desarrollo de una red 301

proyecto avanza y se realizan cambios en el plan del proyecto. También se denomina flotador, holgura
total u holgura de ruta. En general, la holgura es la diferencia entre la fecha de inicio tardío y la fecha
de inicio temprano (LS - ES) o entre la fecha de fin tardío (late finish: LF) y la fecha de fin temprano
(early finish: EF) (LF – EF).
Método de la ruta Critica (Critical Path Method: CPM)—Una técnica de análisis de red que se utiliza para
determinar la cantidad de flexibilidad de la programación (la cantidad de holgura) en varias rutas lógi-
cas de la red del cronograma del proyecto y para determinar la duración mínima del proyecto total.
Implica el cálculo de inicio y fin de las fechas de inicio temprano (programación hacia adelante), y fin
tardío (programación hacia atrás) de cada actividad. En esta técnica está ímplicito el supuesto de que
estarán disponibles todos los recursos que se requieran en un periodo determinado.
Nodo—Cada uno de los puntos que definen una red; un punto de unión que junta algunos o todos los otros
con líneas de dependencia (rutas).
Paquete de trabajo—Un entregable en el nivel más bajo de la estructura del proyecto es un elemento del tra-
bajo realizado durante el curso de un proyecto. Un paquete de trabajo normalmente tiene una duración
prevista y un costo esperado. Otros términos genéricos para el paquete de trabajo son tarea o actividad.
Predecesoras—Aquellas actividades que deben completarse antes de la iniciación de una actividad que va
más adelante en la red.
Recorrido hacia adelante—Cálculos de red que determinan el inicio temprano/tiempo de fin temprano
(fecha) para cada actividad. Las fechas de inicio y fin temprano están determinadas por el trabajo hacia
adelante a través de cada actividad en la red.
Recorrido hacia atrás—Cálculo de los tiempos (fechas) de fin tardío de todas las actividades de la red sin
completar. Las fechas de fin tardío se determinan trabajando hacia atrás a lo largo de cada actividad.
Ruta—Secuencia de las actividades definidas por la lógica red del proyecto.
Ruta crítica—Camino a lo largo de la red del proyecto de mayor duración. La ruta crítica puede cambiar en
caso de que las actividades que la componen se realizan antes o después de lo previsto. Las actividades
de la ruta crítica se identifican por tener holgura cero en el proyecto.
Sucesoras—Actividades que no pueden iniciarse hasta que las actividades previas se hayan completado.
Estas actividades siguen a las actividades predecesoras.
Técnica de revisión y evaluación de programas (Program Evaluation and Review Technique: PERT)—
Sistema de análisis de eventos y probabilidades basado en redes; se utiliza generalmente en proyectos
en los cuales las actividades y su duración son difíciles de definir. PERT se utiliza con frecuencia en
programas grandes en los que los proyectos involucran numerosas organizaciones en lugares muy
diferentes.
Los dos métodos más comunes para la elaboración de redes de actividades implican las lógicas de actividad
en la flecha (activity on arrow: AOA) y actividad en el nodo (activity on node: AON). En el método AOA,
la flecha representa la tarea o actividad y el nodo significa un marcador de eventos que sugiere la realización
de una actividad y el potencial para iniciar la siguiente. En la metodología de AON, el nodo representa una
actividad y las trayectorias de las flechas muestran la secuencia lógica de un nodo a lo largo de la red. El enfo-
que AOA es muy popular desde hace varias décadas y todavía se utiliza, en cierta medida, en el sector de la
construcción, pero con el rápido aumento de la informática y de la programación basadas en el computador,
ahora hay un fuerte énfasis en la metodología AON. Por tanto, en este capítulo, utilizamos exclusivamente
ejemplos y diagramas AON. En el capítulo 10 se analizarán las generalidades del modelado de la red AOA.

9.3  DESARROLLO DE UNA RED


La diagramación de una red es un proceso lógico y secuencial que requiere que usted considere el orden en
que deben ejecutarse las actividades para programar el proyecto tan eficientemente como sea posible. Hay dos
métodos principales para el desarrollo de redes de actividades, PERT y CPM. PERT, que significa Técnica de
revisión y evaluación de programas, fue desarrollado a finales de la década de 1950 entre la Armada de Estados
Unidos, Booz-Allen Hamilton y Lockheed Corporation para la creación del programa de misiles Polaris. PERT
originalmente se utilizó en investigación y desarrollo (I+D), un campo en el que las estimaciones de la duración
de las actividades puede ser difícil de hacer y se calculan a partir de un análisis de probabilidades. El CPM, o
302 Capítulo 9  •  Programación del proyecto

método del ruta crítica, se desarrolló de forma independiente al mismo tiempo que PERT por DuPont, Inc.
CPM, de uso común en la industria de la construcción, se diferencia de PERT principalmente en los supuestos
de la estimación de duración de las actividades. En el CPM se asume que las duraciones son determinísticas,
es decir, son más fáciles de determinar con mayor confianza y se pueden asignar a las actividades. Además,
el CPM fue diseñado para vincular mejor (y por tanto controlar) el tiempo de actividad del proyecto con los
costos, en particular las negociaciones tiempo/costo que llevan a las decisiones de compresión (aceleración del
proyecto). La técnica de compresión del proyecto se explicará con más detalle en el capítulo 10. En la práctica,
sin embargo, en los últimos años las diferencias entre PERT y CPM se han difuminado hasta el punto de que
ahora es común referirse simplemente a estas técnicas de redes como PERT/CPM.4
Antes de construir una red de actividad, algunas reglas de oro simples se necesitan para familiarizarse con
el desarrollo del diagrama de red. Estas reglas son muy útiles para entender la lógica de las redes de actividades.5
1. Antes de la creación de la red debe hacerse un ordenamiento de las actividades, según sus relaciones de
precedencia. Es decir, todas las actividades deben relacionarse lógicamente entre sí: unas actividades
que preceden a otras, y otras que siguen a las demás.
2. Por lo general, el flujo de diagramas de red va de izquierda a derecha.
3. Una actividad no puede empezar hasta tanto se hayan completado todas sus actividades predecesoras
relacionadas.
4. Las flechas en las redes indican la precedencia y el flujo lógico. Las flechas se pueden cruzar entre sí,
aunque, en pro de la claridad, debe limitarse este efecto cuando sea posible.
5. Cada actividad debe tener un identificador único asociado con esta (número, letra, código, etc.). Por
simplicidad, estos identificadores ocurren en orden ascendente, y cada uno debe ser más grande que
los identificadores de las actividades predecesoras.
6. No se permiten ciclos o circuitos entre las actividades.
7. Aunque no se requiere, comúnmente se inicia un proyecto con un solo nodo, incluso si múltiples pun-
tos de inicio son posibles. Un punto de nodo único también suele utilizarse como un indicador en la
terminación del proyecto.
Con estas simples reglas empíricas en mente, usted puede comenzar a descubrir algunos de los principios
básicos para desarrollar un diagrama de red. Recuerde que en la metodología AON se representan todas las
actividades dentro de la red como nodos. Las flechas se usan solo para indicar el flujo secuencial de las activi-
dades desde el principio del proyecto hasta su finalización.

Etiquetado de nodos
Los nodos que representan las actividades del proyecto deben estar claramente etiquetados con varios tipos de
información. Conviene que los nodos contengan al menos los siguientes datos: (1) identificador; (2) etiqueta
descriptiva; (3) duración de la actividad; (4), fecha de inicio temprano; (5) fecha de fin temprano, (6) fecha de
inicio tardío; (7) fecha de fin tardío; y (8) la holgura de la actividad. El cuadro 9.1 muestra el etiquetado para
un nodo con cada tipo de información asignado a una ubicación dentro de la caja de la actividad. La disposi-
ción seleccionada para este nodo fue arbitraria; no hay un estándar aceptado para el etiquetado de los nodos
de actividad. Por ejemplo, el nodo que se muestra en cuadro 9.2 se derivó de un archivo de salida estándar de
Microsoft Project 2010. Tenga en cuenta que en este ejemplo se muestran las fechas de inicio y fin de la activi-
dad, así como la persona responsable de los recursos para la realización de aquella.
Elaborar etiquetas completas acerca de nodos de actividad facilitan el uso de la red para realizar cálculos
adicionales, como la identificación de la ruta crítica, la holgura de la actividad, la duración total del proyecto, entre
otros. Al construir diagramas de red durante el desarrollo temprano del proyecto, puede recuperarse rápidamente
toda la información necesaria de cada actividad, siempre y cuando los nodos estén plenamente identificados.

Inicio Identificador Fin


temprano numérico temprano
Holgura
Descripción de
de la
la actividad
actividad

CUADRO 9.1  Etiquetas de Inicio Duración de Fin


tardío la actividad tardío
nodo para las actividades
9.3  Desarrollo de una red 303

FIGURA 9.2  Etiquetas de nodo


de actividad con MS Project 2010

Actividades en serie
Las actividades en serie son aquellas que se derivan una después de otra, en secuencia. Siguiendo la lógica de
la figura 9.3, no se puede empezar a trabajar en la actividad B hasta tanto la actividad A se haya completado.
La actividad C no puede comenzar hasta tanto las actividades A y B se finalicen. Las redes de actividad en serie
son las más simples, puesto que solo crean vínculos de secuencia entre las actividades. En muchos casos, las
redes seriales son representaciones adecuadas de las actividades del proyecto. La figura 9.3 muestra cómo, en
el ejemplo anterior de la preparación de un artículo y su presentación en clase, varias actividades deben nece-
sariamente estar vinculadas en serie. Identificar el tema, investigar el tema y escribir el primer borrador son
actividades que deben vincularse en serie, porque las actividades posteriores no pueden comenzar hasta tanto
se hayan completado las predecesoras.
La lógica de la red sugiere que:
La actividad A puede comenzar de inmediato.
La actividad B no puede comenzar hasta tanto la actividad A se haya completado.
Actividad C no puede comenzar hasta tanto las actividades A y B se hayan completado.

A B C
FIGURA 9.3  Actividades del Identificar Investigar Borrador del
el tema el tema artículo
proyecto vinculadas en serie

Actividades concurrentes
En muchas circunstancias, se puede empezar a trabajar en más de una actividad al mismo tiempo, en el
supuesto de que tengamos los recursos disponibles para estas. La figura 9.4 proporciona un ejemplo de cómo
se representan rutas simultáneas o en paralelo, en una red de actividades del proyecto. Cuando la naturaleza
del trabajo permite que más de una actividad se lleve a cabo al mismo tiempo, estas actividades se denominan
concurrentes y construyen rutas paralelas a lo largo de la red de actividades del proyecto. Para operar con
éxito las actividades concurrentes, el proyecto debe atenderse con recursos humanos suficientes para apoyar
todas estas actividades. Este es un asunto fundamental, puesto que la red no se puede crear sin dar una idea
de las necesidades de recursos necesarios para apoyarla.
La lógica de la red sugiere que:
D y E pueden empezar después de la finalización de la actividad C.
La actividad F puede comenzar después de la finalización de la actividad D y es independiente de la actividad.
La actividad G puede comenzar después de la finalización de la actividad E y es independiente de la actividad D.
La actividad H puede comenzar después de la finalización de las actividades F y G.

D F
Editar el Documento
articulo final

C H
Borrador Finalización
del artículo
E G
Preparar la Finalizar la
presentación presentación

FIGURA 9.4  Actividades vinculadas en paralelo (concurrentes)


304 Capítulo 9  •  Programación del proyecto

Actividades convergentes
Las actividades convergentes son aquellas con dos o más predecesoras inmediatas. La figura 9.5 es un dia-
grama de la red parcial que muestra cómo se expresan gráficamente las actividades convergentes. A menudo,
estas actividades son los puntos claves de unión, lugares donde dos o más rutas de proyecto paralelas conver-
gen dentro de la red global. La figura 9.5 muestra la lógica de una actividad convergente: no se puede iniciar
la actividad D hasta tanto todas las actividades predecesoras, A, B y C, se hayan completado. El inicio de la
actividad de convergencia está sujeto a la finalización de la actividad predecesora más larga. Por ejemplo,
supongamos que las actividades A, B, y C, todas, empiezan el mismo día. La actividad A tiene una duración
de 3 días, la duración de la actividad de B, 5 días y la actividad de C, 7 días. La fecha de inicio temprano de la
actividad D, el punto de convergencia es el día 7, después de la finalización de las tres actividades anteriores.
La lógica de la red sugiere que:
La actividad D solo puede comenzar después de la finalización de las actividades A, B y C.

Actividades divergentes
Las actividades divergentes son aquellas con dos o más actividades sucesoras inmediatas. La figura 9.6 repre-
senta gráficamente una tarea divergente, con las actividades B, C, y D programadas para seguir a la finaliza-
ción de la actividad A. Las tres siguientes solo pueden realizarse luego de la finalización de la actividad A. A
diferencia de las actividades convergentes, en las que la sucesora depende de la finalización de la actividad
predecesora más larga antes de que pueda comenzar, todas las sucesoras inmediatas pueden comenzar simul-
táneamente con la finalización de la actividad divergente.
La lógica de la red sugiere que:
Las actividades B, C y D solo pueden comenzar después de la finalización de la actividad A.

Actividad A

Actividad B Actividad D

Actividad C
FIGURA 9.5  Actividad convergente

Actividad B

Actividad A Actividad C

Actividad D
FIGURA 9.6  Actividad divergente
9.3  Desarrollo de una red 305

EJEMPLO 9.1

Vamos a comenzar la construcción de una red de actividad básica. El cuadro 9.3 identifica ocho actividades
y sus predecesoras en un ejemplo de proyecto simple. Una vez determinadas las tareas necesarias para com-
pletar el proyecto, vale la pena comenzar a vincular las tareas entre sí. En efecto, estamos tomando las tareas
del proyecto de la WBS del proyecto agregándole la cronología del proyecto.
Una vez desarrollado el cuadro de las actividades de la red e identificado las predecesoras, podemos
comenzar el proceso de construcción de la red. La primera actividad (A) no tiene predecesoras, es el punto
de partida de la red y se coloca en el extremo izquierdo de nuestro diagrama. Luego, las actividades B y C
tienen la actividad A como su predecesora. Podemos colocarlas en la red también. La actividad D muestra a
las actividades B y C como sus predecesoras.
La figura 9.7 muestra un diagrama de la red parcial basado en la información que hemos recopilado
hasta este punto. Tenga en cuenta que, a partir de las definiciones, la actividad A es una de actividad diver-
gente y la actividad D es una actividad convergente.
Podemos seguir creando la red de forma iterativa, puesto que seguiremos añadiendo nodos de acti-
vidad adicionales al diagrama. La figura 9.8 muestra la red de actividad final. Haciendo referencia de
nuevo a un punto anterior, tenga en cuenta que esta red se inicia con un único nodo (actividad A) y fina-
liza con punto de nodo simple (actividad H). Las actividades convergentes asociadas a esta red incluyen
las actividades D (con actividades B y C en la convergencia de este nodo) y H (con actividades E, F, y G de
convergencia en este nodo). Las actividades A, B y C son las actividades divergentes. Recordemos que las
actividades divergentes se definen como aquellas con dos o más sucesoras inmediatas en la red. La activi-
dad A tiene como sucesoras las tareas B y C, la actividad B tiene tareas D y E después de ella, y la actividad
C tiene dos sucesoras (D y G).

CUADRO 9.3  Informacion para la construcción de la red

Nombre: proyecto Delta


Actividad Descripción Predecesoras
A Firmar el contrato Ninguna
B Diseñar el cuestionario A
C Investigar el mercado objetivo A
D Aplicar muestra de la encuesta B, C
E Desarrollar la presentación B
F Analizar los resultados D
G Realizar análisis demográfico C
H Hacer presentación al cliente E, F, G

A D

FIGURA 9.7  Red de actividades C


parciales basada en el proyecto Delta
306 Capítulo 9  •  Programación del proyecto

E
Desarrollar la
B presentación
Diseño

A D F H
Contrato Encuesta Análisis Presentación

C
ID de
Mercados G
Demográficos

FIGURA 9.8  Red de actividades completa del proyecto Delta

Si empleamos MS Project 2010 para elaborar el diagrama de la red, deberíamos antes introducir cada
una de las actividades en la plantilla que se muestra en la pantalla 9.1. Tenga en cuenta que en este ejemplo no
asignamos ninguna duración a las actividades, por lo que por defecto se fija en 1 día cada actividad.

PANTALLA 9.1  Desarrollo de la red de actividades con MS Project 2010

PANTALLA 9.2  Ventana de información de la tarea usada para especificar las actividades predecesoras de la red
9.4  Estimación de la duración 307

El siguiente paso en el uso de MS Project para elaborar una red es identificar las actividades predecesoras
para cada tarea del proyecto. En la pantalla 9.2, empezamos a construir la red especificando cada predecesora y
sucesora en la red. Al dar doble clic con el ratón en una actividad, se abre una ventana de información de la tarea
(que se muestra en la pantalla 9.2). En esa ventana, se puede especificar la tarea o tareas predecesoras de nues-
tra actividad actual. Para la actividad B (diseñar el cuestionario), especificamos una sola predecesora (firmar el
contrato).
Una vez añadida cada tarea, a su vez, se completa la red del proyecto. MS Project se puede utilizar para
generar la red final, como se muestra en la pantalla 9.3. Tenga en cuenta que cada actividad se etiqueta con la
necesidad de solamente 1 día para su ejecución. En la siguiente sección de este capítulo, empezamos a consi-
derar la forma en que se pueden determinar las duraciones de las actividades individuales.

PANTALLA 9.3  Diagrama de red completo con MS Project 2010

9.4  ESTIMACIÓN DE LA DURACIÓN


El siguiente paso en la construcción de la red consiste en estimar las duraciones de las actividades de cada
etapa del proyecto. El primer punto para recordar es que estas estimaciones se basan en lo que se supone
son los métodos normales de trabajo durante las jornadas o las horas de trabajo normales en las empresas.
El segundo, a pesar de que factores como la experiencia o familiaridad con el trabajo influirán en la preci-
sión de estas estimaciones, las duraciones de las actividades son siempre algo incierto. El tercero, los plazos
para las estimaciones de tareas pueden variar desde varias horas o días en proyectos cortos y en semanas
para proyectos más largos.
La duración de las actividades se puede estimar de maneras diferentes, incluidas:6
• Experiencia.  En casos donde la organización ha realizado un trabajo similar, podemos usar la
historia como guía. Este enfoque es relativamente fácil porque acudimos a ejemplos pasados ​​de pro-
yectos similares y los utilizamos como referente. El principal inconveniente de este enfoque es que
asume que lo que ha funcionado en el pasado seguirá funcionando en la actualidad. Los proyectos
son afectados por acontecimientos externos que son únicos en su tiempo. Por tanto, al utilizar la
experiencia, tenemos que ser conscientes de la posibilidad de utilizar información distorsionada o
desactualizada.
• Opinión de expertos.  A veces es conveniente ponernos en contacto con un gerente de proyectos
pasados o experto en un área específica, para obtener información precisa sobre las estimaciones de
una actividad. Intuitivamente, este enfoque parece útil—si usted quiere conocer algo, acuda a un
experto. Tenga en cuenta que los "expertos" se consideran expertos, precisamente porque conocen
las formas más fáciles, los mejores contactos y procesos más rápidos para completar las tareas. ¿La
estimación de un experto sobre el tiempo de finalización será válida para los inexpertos que realizan
la misma actividad? La respuesta es un no absoluto; entonces, la pregunta sugiere ser precavidos en
poner en práctica la opinión de un experto.
• Derivación matemática.  Otro enfoque ofrece una alternativa más objetiva sobre la estimación de la
duración y deja a un lado muchos de los problemas de los métodos subjetivos. Este método consiste en
308 Capítulo 9  •  Programación del proyecto

calcular la probabilidad de la duración, basados en un análisis razonado de tres escenarios: el mejor de


los casos, el caso más probable y el peor de los casos.
Para entender cómo usar la derivación matemática para determinar los tiempos de duración de las activi-
dades previstas, debemos tener en cuenta los fundamentos de las distribuciones de probabilidad. La pro-
babilidad sugiere que la cantidad de tiempo que una actividad toma para su ejecución rara vez se puede
determinar de manera exacta; por tanto, es necesario calcularla como resultado de un muestreo en un rango
de probabilidades, o probabilidades de que el evento ocurra. Estas probabilidades oscilan entre 0 (ninguna
probabilidad) a 1 (probabilidad total). Con el fin de obtener una estimación probabilística razonable para la
duración de una actividad, tenemos que identificar tres valores: (1) la duración más probable de la actividad,
(2) la duración más pesimista de la actividad, y (3) la duración más optimista de la actividad. La duración
más probable se determina según el tiempo que se espera para completar una actividad, suponiendo que el
desarrollo de esta se realiza normalmente. La duración pesimista es la duración prevista de tiempo necesario
para desarrollar la actividad, con el supuesto de que todo vaya mal (ley de Murphy). Por último, la duración
optimista se calcula con la suposición de que el proceso de desarrollo va a continuar bien.
Para estas estimaciones de tiempo, podemos utilizar las distribuciones de probabilidad simétricas (dis-
tribución normal) o asimétricas (distribución beta). Una distribución normal implica que la probabilidad de
un evento puede tomarse como el tiempo más probable, aquel que se centra en la media de la distribución
(véase figura 9.9). Dado que los valores pesimistas y optimistas se estiman en el nivel de confianza de 95%
a partir de los dos extremos de la distribución, se anulan entre sí, y dejan el valor medio como el tiempo de
duración prevista para la actividad.
En la vida real es muy raro encontrar ejemplos en los que las duraciones optimistas y pesimistas sean
simétricas entre sí, respecto a la media. En la gerencia de proyectos, es más común ver distribuciones de
probabilidad asimétricas, las cuales se conocen como distribuciones beta. La asimetría de la distribución
de probabilidad sugiere que reconocemos que ciertos eventos son menos probables que ocurran en relación
con otros. El tiempo optimista de una actividad puede estar dentro de una desviación estándar de la media;
su tiempo pesimista puede ubicarse tanto como tres o cuatro desviaciones estándar. Para ilustrar, suponga-
mos que iniciamos la construcción de un puente en una autopista y se quiere estimar la cantidad de tiempo
(duración) necesaria para colocar las vigas de acero requeridas para el marco del puente. Esperamos que la
duración de la tarea de enmarcar llevará seis días; sin embargo, una serie de factores podrían cambiar esa
estimación de la duración. Podríamos, por ejemplo, extraordinariamente, experimentar buen tiempo y no
tener retrasos técnicos, lo cual nos permitiría terminar la actividad de enmarcado en solo cuatro días. Por
otro lado, podríamos tener un tiempo terrible, retrasos en la entrega de los materiales requeridos y perder
tiempo en conflictos laborales, todo lo cual conduce a una estimación pesimista de 14 días. Este ejemplo
demuestra la naturaleza asimétrica de las estimaciones de duración; mientras la duración más probable es 6
días, el rango puede variar de 4 a 14 días para completar la tarea.
Los valores de duración optimista y pesimista sirven como límites superior e inferior del rango de
la distribución. La figura 9.10 ilustra una distribución beta con valores de m (la duración más probable), a
(duración más optimista) y b (duración más pesimista).

f (x)

Área sombreada = 1– D

x
–Z1– D/2 Z1– D/2

FIGURA 9.9  Distribución simétrica (normal) para la estimación de la duración de


la actividad
9.4  Estimación de la duración 309

Distribución beta

0 a m b
Tiempo transcurrido

FIGURA 9.10  Distribución asimétrica (beta) para la estimación de la duración de la actividad

Dos supuestos se toman para convertir los valores de m, a y b en las estimaciones del tiempo esperado
(TE) y la varianza (s2) de la duración de la actividad. Un supuesto importante es que s, la desviación estándar
de la duración requerida para completar la tarea, es igual a una sexta parte del rango de tiempos razonable-
mente posibles. La varianza de la estimación de la duración de la actividad está dada por la fórmula:

La lógica para este supuesto se basa en que, para lograr una distribución de probabilidad con un intervalo de
confianza de 99%, las observaciones deben estar dentro de tres desviaciones estándar de la media en cual-
quier dirección. Una extensión de seis desviaciones estándar de la cola a la cola de la distribución de probabi-
lidad, entonces, representa 99.7% de las posibles alternativas de duración de la actividad.
Debido a que veces las estimaciones optimista y pesimista no son simétricas alrededor de la media, la segunda
hipótesis se refiere a la forma de la distribución de probabilidad. Una vez más, la distribución beta, o asimétrica,
representa mejor la distribución de la alternativa más posible por esperar para la estimación del tiempo de duración
(TE) de la actividad. La distribución beta sugiere que el cálculo para derivar TE es como se muestra en seguida:

TE = (a + 4m + b) /6

Donde:
TE = tiempo estimado para la actividad
a = tiempo más optimista para completar la actividad
m = tiempo más probable para completar la actividad; la moda de la distribución
b = tiempo más pesimista para completar la actividad
En este cálculo, el punto medio entre los valores pesimista y optimista es la media aritmética ponderada de la
moda y el rango medio, que representa dos tercios de la ponderación global para el tiempo esperado calcu-
lado. La ponderación adicional tiene por objeto destacar la agrupación de los valores esperados alrededor de
la media de la distribución, independientemente de la duración tanto pesimista como optimista (desviación
estándar de la distribución).
¿Cómo juntamos todos estos supuestos para realizar una estimación exacta de la duración de la acti-
vidad? El siguiente paso es construir una tabla de la estimación de la duración de la actividad (véase cuadro
9.4). Para simplificar, los números que se muestran se refieren a semanas.
El cuadro 9.4 muestra los tiempos más probables para cada actividad, basados en una evaluación razo-
nablemente precisa de cuánto tiempo debería y podría tomar una tarea, si todo ha ido bien, y cuánto tomaría
si todo fuera mal. Si asignamos el valor de a la estimación de la duración más optimista, el gerente del pro-
yecto debe asignar un valor a esta actividad de manera que la cantidad real de tiempo necesario para com-
pletar la actividad será a o mayor a 99% de este tiempo. Por el contrario, en la asignación de un valor para
la duración más pesimista, b, el gerente del proyecto debe estimar la duración de la actividad para tener una
probabilidad de 99% que tomará b o menos de esa cantidad de tiempo.
La fórmula estándar para la estimación del tiempo esperado de duración de la actividad se basa en la
relación de ponderación de 1 × optimista, 4 × más probable y 1 × pesimista. Sin embargo, investigadores y
profesionales han hallado que esta relación se ve mejor como un enfoque heurístico cuyos supuestos básicos se
afectan por las circunstancias particulares de cada proyecto. Un argumento sostiene que la relación anterior es
demasiado optimista y no toma en consideración el efecto negativo que se crea cuando la estimación del peor
caso o pesimista, resulta precisa. Además, dada la incertidumbre inherente en muchos proyectos, deben tenerse
en cuenta niveles significativos de riesgo en todas las estimaciones probabilísticas de duración.
310 Capítulo 9  •  Programación del proyecto

CUADRO 9.4  Estimación de la duración de las actividades para el proyecto Delta

Nombre: proyecto Delta


Las duraciones están dadas en semanas
Actividad Descripción Optimista Más probable Pesimista

A Firmar el contrato 3  4 11
B Diseñar el cuestionario 2  5  8
C Investigar el mercado objetivo 3  6  9
8
D Aplicar muestra de la encuesta 12 20
3
E Desarrollar la presentación  5 12
2
F Analizar los resultados 6  4  7
G Realizar análisis demográfico 1  9 14
H Hacer presentación al cliente  2  4

Una amplia investigación enfocada en mejorar la precisión de la estimación de duración de la actividad,


no ha dado resultados definitivos. Técnicas de modelamiento como la simulación Monte Carlo y algoritmos de
programación lineal y no lineal, en general, han demostrado que el grado de incertidumbre en la duración de las
tareas puede tener un efecto significativo sobre el método óptimo de estimación de la duración. Debido a que la
incertidumbre es tan común en la estimación de la actividad, calcular más de una estimación para la duración
de la actividad puede ser razonable. La meta es obtener un intervalo de confianza que proporciona la más alta
probabilidad razonable para considerarse precisa. La estimación de la probabilidad utilizando intervalos de
confianza de 99% representa un grado de confianza que gerentes de proyecto estarían dispuestos a demostrar,
según Meredith y Mantel.7 En consecuencia, cuando el supuesto nivel de confianza es relajado, por ejemplo, a
90%, los cálculos de la varianza y de las estimaciones de duración pueden modificarse en consecuencia. Aunque
probablemente continúe el debate, una fórmula de estimación conmúnmente aceptada es 1:4:1 (optimista: más
probable: pesimista)/6.
Utilizando esta relación como herramienta, ahora se puede calcular los tiempos de duración esperados
para cada una de las tareas identificadas en el cuadro 9.4. El cuadro 9.5 muestra los tiempos calculados para
cada actividad, con base en el supuesto de una distribución beta.
La creación de la red del proyecto y el cálculo de la duración de las actividades son los dos primeros
pasos claves en el desarrollo del cronograma del proyecto. La siguiente etapa es la combinación de estas dos
piezas de información, con el fin de crear el diagrama de la ruta crítica del proyecto.

CUADRO 9.5  Estimación de las duraciones de las actividades con la


distribución beta

Nombre: Proyecto Delta


Las duraciones están dadas en semanas
Actividad Descripción Beta (relación 1:4:1)/6
A Firmar el contrato 5
B Diseñar el cuestionario 5
C Investigar el mercado objetivo 6
D Aplicar muestra de la encuesta 12.7
E Desarrollar la presentación 5.8
F Analizar los resultados 4.2
G Realizar análisis demográfico 9.3
H Hacer presentación al cliente 2.2
9.5  Construcción de la ruta crítica 311

9.5  CONSTRUCCIÓN DE LA RUTA CRÍTICA


El siguiente paso es vincular la estimación de la duración de la actividad y comenzar la construcción de la
ruta crítica. El cálculo de la ruta critica enlaza las duraciones con la red de actividades, preconstruida para
el proyecto. Este punto es importante porque la red del proyecto se desarrolló primero usando la lógica de
precedencia de las actividades; luego, se estimó la duración de las tareas; estos valores se aplicaron en un
proceso estructurado para cada actividad, con el fin de determinar la longitud total del proyecto. Además
de determinar el tiempo que el proyecto va a tomar, la aplicación de las estimaciones de tiempo de la red
nos permiten determinar las holguras de las actividades (qué actividades se pueden retrasar y cuáles no), los
tiempos tempranos y tardíos en que cada actividad puede empezar, y los tiempos tempranos y tardíos en que
cada actividad puede completarse.

Cálculo de la red
El proceso de desarrollo de la red con las estimaciones de tiempo es sencillo. Una vez que la red de activida-
des y las duraciones estimadas se realizan, se procede a calcular la red real del proyecto. Observe la red de la
figura 9.8 y las estimaciones de la duración en el cuadro 9.5 que adoptan una distribución beta. En este ejem-
plo, las estimaciones de tiempo se redondean al número entero más próximo. La información de la actividad
se resume en el cuadro 9.6.
La metodología para el uso de esta información en la creación de la ruta crítica requiere dos recorridos:
uno hacia adelante a lo largo de la red desde la primera a la última actividad y un recorrido hacia atrás, a lo
largo de la red de la actividad final hasta la inicial. El paso siguiente es un proceso aditivo que calcula los
tiempos tempranos en que una actividad puede comenzar y terminar. Una vez completado el recorrido hacia
adelante, vamos a saber cuánto tiempo se espera que el proyecto en general va a tomar. El recorrido hacia
atrás es un proceso sustractivo que nos da información sobre cuándo, a más tardar, las actividades pueden
empezar y finalizar. Una vez que los recorridos hacia adelante y hacia atrás se completan, también vamos a
ser capaces de determinar la holgura de la actividad individual y, por último, la ruta crítica del proyecto.
Después de etiquetar la red con las duraciones de las actividades, comenzamos a determinar las dife-
rentes rutas a lo largo de la red. La figura 9.11 muestra una red parcial de actividades con duraciones etique-
tadas para cada una de las ocho actividades del proyecto. Cada ruta se descubre por la evaluación de todas las
posibles secuencias predecesoras de las actividades desde el nodo de inicio hasta el del final. Aquí, podemos
identificar cuatro rutas separadas, denominadas así:
Ruta uno: A-B-E-H
Ruta dos: A-B-D-F-H
Ruta tres: A-C-D-F-H
Ruta cuatro: A-C-G-H
Puesto que ahora sabemos los tiempos de actividad para cada tarea, también podemos identificar la ruta crí-
tica. La ruta crítica se define como la "serie de actividades interdependientes de un proyecto, que se conectan
de extremo a extremo y determina la longitud total más corta del proyecto."8 La longitud total de tiempo
más corto necesario para completar un proyecto se determina por la ruta más larga a lo largo de la red. La

CUADRO 9.6  Información del proyecto

Proyecto Delta
Actividad Descripción Predecesoras Duración estimada
A Firmar el contrato Ninguna  5
B Diseñar el cuestionario A  5
C Investigar el mercado objetivo A  6
D Aplicar muestra de la encuesta B, C 13
E Desarrollar la presentación B  6
F Analizar los resultados D  4
G Realizar análisis demográfico C  9
H Hacer presentación al cliente E, F, G  2
312 Capítulo 9  •  Programación del proyecto

E
B
Desarrollar
Diseño
presentación
5
6

A D F H
Contrato Encuesta Análisis Presentación
5 13 4 2

C G
(I+D) Demográficos
mercados 6 9

FIGURA 9.11  Red parcial de actividades con duraciones de las tareas

longitud de las cuatro rutas de acceso indicadas anteriormente puede derivarse simplemente mediante la
suma de la duración individual de las actividades. Por tanto,
Ruta uno: A - B - E - H = 18 semanas
Ruta dos: A - B - D - F - H = 29 semanas
Ruta tres: A - C - D - F - H = 30 semanas
Ruta cuatro: A - C - G - H = 22 semanas
La ruta tres, que une las actividades A – C – D – F – H, tiene una duración prevista de 30 semanas y es la ruta
fundamental para este proyecto. En la práctica, este camino no tiene holgura o tiempos muertos, asociados a él.

Recorrido hacia adelante


Ahora podemos empezar a añadir más información a la red mediante la realización del recorrido hacia adelante
para determinar los tiempos más tempranos en que cada actividad puede comenzar y el tiempo más temprano en
que puede completarse. El proceso es iterativo y cada recorrido se basa en la información contenida en el nodo que
le precede inmediatamente en la red. La actividad de inicio, la firma del contrato, se puede empezar en el momento
0 (inmediatamente). Por tanto, lo más temprano que la actividad A puede completarse es el día 5. La fecha de
fin temprano de cualquier actividad (EF) se encuentra tomando su fecha de inicio temprano (ES) y sumando la
duración (Dur) de la actividad (ES + Dur = EF). Entonces, la fecha de inicio temprano de la actividad B (diseño
del cuestionario) es el día 5. Este valor corresponde a la fecha de fin temprano de la actividad que le precede inme-
diatamente en la red. Del mismo modo, la actividad de C, que también depende de la finalización de la actividad
A para iniciar, tiene una fecha de inicio temprano de 5. La fecha de fin temprano para la actividad B, calculada por
(ES + Dur = EF), es 5 + 5, o 10. La fecha de fin temprano de la actividad C se encuentra en 5 + 6 = 11. La figura 9.12
muestra el proceso de elaboración del recorrido hacia adelante a lo largo de la red de actividades.
El primer reto se genera en la actividad D, el punto en que convergen las actividades B y C. La actividad
B tiene una fecha de fin temprano (EF) de 10 semanas; sin embargo, la actividad C tiene un EF de 11 sema-
nas. ¿Cuál debería ser el inicio temprano (ES) de la actividad D?
Para responder a esta pregunta, vale la pena revisar las normas que rigen el uso de la metodología de
recorrido hacia adelante. Principalmente, hay tres pasos para implementar el recorrido hacia adelante:
1. Sumar todos los tiempos de actividad a lo largo de cada ruta, a medida que avanzamos a lo largo de la
red (ES + Dur = EF).
2. Llevar el tiempo EF a los nodos de actividad inmediatamente siguientes al nodo analizado. Así, EF se
convierte en el ES del siguiente nodo, a menos que el nodo siguiente sea un punto de convergencia.
3. En un punto de convergencia el mayor EF predecesor se convierte en el ES para ese nodo.
Al aplicar estas normas, en la actividad D, punto de converegencia, tenemos la opción de aplicar o bien
un EF de 10 (actividad B) o de 11 (actividad C), como nuestro nuevo ES. Debido a que el fin temprano
9.5  Construcción de la ruta crítica 313

5 B 10
Diseño
5

0 A 5 D
Contrato Encuesta
5 13

5 C 11
(I+D) Mercados
FIGURA 9.12  Red de actividades parcial con 6
un punto de convergencia en la actividad D

de la actividad C es mayor, seleccionamos el valor ES de 11 para este nodo. La lógica de esta norma sobre
los puntos de convergencia es importante: recuerde que el inicio temprano se define como lo más tem-
prano que una actividad puede comenzar. Cuando dos o más predecesoras inmediatas tienen tiempos EF
diferentes, lo más temprano que la primera sucesora puede comenzar ocurre cuando todas las actividades
predecesoras se han completado. Por tanto, podemos determinar que sería imposible que la actividad D
comience en la semana 10, debido a que una de sus predecesoras (actividad C) no se habría terminado en
ese momento.
Si seguimos implementando el recorrido hacia adelante en la red, podemos trabajar de manera directa
hasta llegar al nodo final, la actividad H, que también es un punto de convergencia. La actividad H tiene tres
predecesoras inmediatas, las actividades E, F y G. El EF para la actividad E es 16, el EF para la actividad F
es 28 y el EF de la actividad G es 20. Por tanto, el ES para la actividad H debe ser el EF más grande, es decir,
28. La duración total del proyecto es 30 semanas. La figura 9.13 ilustra la red general con todas las fechas de
inicio y fin tempranos.

10 E 16
5 B 10
Desarrollar
Diseño
presentación
5
6

0 A 5 11 D 24 24 F 28 28 H 30
Contrato Encuesta Análisis Presentación
5 13 4 2

5 C 11 11 G 20
(I+D) Mercados Demográficos
6 9

FIGURA 9.13  Red de actividades con recorrido hacia adelante


314 Capítulo 9  •  Programación del proyecto

Recorrido hacia atrás


Ahora estamos en condiciones de determinar la longitud total del proyecto, así como cada fecha de inicio
y fin tempranos de cada actividad. Cuando podemos ocuparnos del siguiente paso por realizar, el recorrido
hacia atrás a lo largo de la red, vamos a determinar la ruta crítica del proyecto y el tiempo de holgura total de
cada actividad del proyecto. El recorrido hacia atrás es un proceso iterativo, tal como el recorrido hacia ade-
lante. La diferencia es que empezamos en el extremo de la red, con el nodo final. La meta del recorrido hacia
atrás es determinar, a la vez, la fecha de inicio tardío de cada actividad (LS) y de fin tardío (LF). Los tiempos
LS y LF se determinan a través de una metodología de sustracción.
En la figura 9.14, empezamos el recorrido hacia atrás con el nodo que representa la actividad H (presenta-
ción). El primer valor que se puede llenar en el nodo es valor de fin tardío (LF) para el proyecto. Este valor es el
mismo que el fin temprano (30 semanas). Para el nodo final de una red de proyectos, EF = LF. Una vez identifi-
cada la LF de 30 semanas, la LS para la actividad H es la diferencia entre LF y la duración de la actividad; en este
caso, 30 – 2 = 28. La fórmula para determinar LS es LF – Dur = LS. Por tanto, la LS para la actividad H es 28 y la
LF es 30. Estos valores se muestran en la parte inferior del nodo, con LS en la esquina inferior izquierda y LF en
la esquina inferior derecha. Con el fin de determinar LF para las próximas tres actividades que están vinculadas
a la actividad H (actividades E, F y G), llevamos el valor LS de la actividad H hacia atrás, a estos nodos. Por tanto,
las actividades E, F, y G tendrán cada una 28 como su valor LF.
Una vez más, restamos las duraciones de los valores LF de cada una de las actividades. El proceso conti-
núa hacia atrás, de derecha a izquierda, a lo largo de la red. Sin embargo, al igual que en el recorrido hacia ade-
lante nos encontramos con un problema en los puntos de convergencia (D y H), ahora nos encontramos con
dificultades similares en los puntos de divergencia—las actividades A, B y C. En estos tres nodos, más de una
actividad predecesora converge, lo cual sugiere que existen múltiples opciones para elegir el valor LF correcto.
Las actividades divergentes, tal como las definimos, son aquellas con dos o más actividades sucesoras inmedia-
tas. Para la actividad B, tanto la actividad de D como la E son sucesoras. Para la actividad D, LS = 11, y para la
actividad E, LS = 22. ¿Qué valor LS debe seleccionarse como el LF para estas actividades divergentes?
Para responder a esta pregunta, se necesita revisar las reglas para el recorrido hacia atrás.
1. Reste los tiempos de duración de cada actividad a lo largo de cada ruta que se mueve a través de la red
(LF – Dur = LS).
2. Lleve de nuevo el tiempo de LS de los nodos de actividad inmediatamente anteriores al nodo siguiente.
Así, LS se convierte en LF del siguiente nodo, a menos que el nodo predecesor sea un punto de divergencia.
3. En el caso de un punto de divergencia, la LS más pequeña se convierte en LF para ese nodo.
La elección correcta para LF de la actividad B es 11 semanas, basados en la actividad D. La elección correcta para la
actividad C, entre 11 o 19 semanas a partir del diagrama de red, es 11 semanas. Por último, el LS para la actividad B
es 6 semanas y se encuentra 5 semanas para la actividad C, por lo que LF para la actividad A es 5 semanas. Una vez
denominado cada nodo con sus valores LS y LF, el recorrido hacia atrás a lo largo de la red se completa.

10 E 16
5 B 10
Desarrollar
Diseño
presentación
6 5 11
22 6 28

0 A 5 11 D 24 24 F 28 28 H 30
Contrato Encuesta Análisis Presentación
0 5 5 11 13 24 24 4 28 28 2 30

5 C 11 11 G 20
(I+D) Mercados Demográficos
5 6 11 19 9 28

FIGURA 9.14  Red de actividades con recorrido hacia atrás


9.5  Construcción de la ruta crítica 315

5 B 10 10 E 16
1 Diseño 12 Desarrollar presentación
6 5 11 22 6 28

0 A 5 11 D 24 24 F 28 28 H 30
0 Contrato 0 Encuesta 0 Análisis 0 Presentación
0 5 5 11 13 24 24 4 28 28 2 30

5 C 11 11 G 20
0 (I+D) Mercados 8 Demográficos
5 6 11 19 9 28
ES ID EF
Holgura Tarea Nombre
LS Duración LF

FIGURA 9.15  Red de actividades del proyecto, con holguras de actividad y ruta crítica
Nota: la ruta crítica se indica con flechas resaltadas.

Ahora podemos determinar la holgura, o slack, para cada actividad, así como la ruta crítica en general. Una
vez más, la holgura nos informa de la cantidad de tiempo que una actividad puede retrasarse, sin demorar el pro-
yecto. La holgura de cada actividad se halla mediante el uso de una de estas dos ecuaciones: LF – EF = holgura o
LS – ES = holgura. Considere la actividad E con 12 semanas de holgura. Suponga el peor de los casos, en el que la
actividad se retrasa inesperadamente 10 semanas, empezando en la semana 20 en lugar de la semana planeada 10.
¿Cuáles son las consecuencias de este retraso en el proyecto en general? Ninguna. Con 12 semanas de holgura para
la actividad E, un retraso de 10 semanas no afectará la longitud general del proyecto ni retrasará su finalización.
¿Qué pasaría si la actividad se retrasara 14 semanas? ES, en lugar de 10, ahora es de 24. Al sumar la duración de
la actividad (6 semanas), el nuevo EF es 30. Observe la red que se muestra en la figura 9.15 para apreciar el efecto
de este retraso. Dado que la actividad H es un punto de convergencia para las actividades E, F, y G, el valor más
grande de EF es ES para el nodo final. El nuevo EF es más grande 30 en la actividad E. Por tanto, el nuevo nodo
EF = ES + Dur, o 30 + 2 = 32. El efecto del uso excesivo de la holgura disponible retrasa el proyecto en 2 semanas.
Otro punto importante para recordar acerca de la holgura de la actividad es que esta se determina como
resultado de la realización de los recorridos hacia adelante y hacia atrás a lo largo de la red. Hasta tanto no se efec-
túen los cálculos para ES, EF, LS y LF, no podemos estar seguros de cuáles actividades tienen alguna holgura aso-
ciada a ella y cuáles no. El uso de esta información para determinar la ruta crítica del proyecto sugiere que la ruta
crítica es el camino de la red sin holgura asociada a las actividades que lo conforman. En nuestro proyecto, podemos
determinar la ruta crítica mediante la vinculación de los nodos sin holgura: A – C – D – F – H. La única vez que
esta regla se viola cuando es un valor arbitrario, se utiliza para el LF del proyecto; por ejemplo, supongamos que
una fecha clave del plazo se inserta en el extremo de la red como LF. Independientemente de cuántos días se calcu-
len que el proyecto tome, basado en el cálculo del recorrido hacia adelante, si el plazo se sustituye por una última
fecha posible para completar el proyecto (LF), se puede presentar alguna holgura negativa asociada con el pro-
yecto. La holgura negativa se refiere a los retrasos en los que hemos agotado toda la seguridad disponible y ahora
nos enfrentamos con retrasos en el proyecto. Por ejemplo, si la alta gerencia establece unilateralmente una fecha
de terminación del proyecto de solo 28 semanas como LF, la ruta crítica del proyecto se iniciará con 2 semanas de
holgura negativa. A menudo, es mejor resolver los problemas de las fechas de terminación impuestas, recortando
estimaciones de actividades en lugar de comenzar el proyecto con cierta holgura negativa.
También podemos determinar la holgura de la ruta, es decir, la vinculación de cada nodo dentro de una ruta
no crítica. La ruta A – B – E – H tiene un total de 13 semanas de holgura; sin embargo, es imposible "pedir pres-
tado" de la holgura de las actividades posteriores, si el resultado está en conflicto con la ruta crítica. Aunque hay 13
semanas de holgura para la ruta, la actividad B no puede consumir más de una semana de la holgura total antes de
convertirse en parte de la ruta crítica. Esto se debe a que B es una actividad predecesora a la actividad D, que está
en la ruta crítica. El uso de más de una semana de tiempo de holgura adicional para completar la actividad B se
traducirá en el retraso del SE de la actividad crítica D, lo cual alarga la ruta crítica del proyecto.
316 Capítulo 9  •  Programación del proyecto

Probabilidad de terminación del proyecto


El cálculo de la ruta crítica en nuestro ejemplo nos muestra que la terminación prevista del proyecto Delta
es 30 semanas, pero recuérdese que nuestras estimaciones originales de tiempo para cada actividad fueron
probabilísticas, basadas en la distribución beta. Esto implica que existe un potencial de varianza (tal vez una
gran varianza) en la estimación global de duración del proyecto. Las variaciones en las actividades de la ruta
crítica pueden afectar el tiempo total de la terminación del proyecto y posiblemente retrasarlo significativa-
mente. Como resultado de ello, es importante tener en cuenta la manera en que se calcula y hacer uso de las
varianzas de la duración de cada actividad. Recordemos que la fórmula de la varianza en la duración de las
actividades es la siguiente:

La determinación de las varianzas individuales de cada actividad es sencilla. Como ejemplo, vamos a hacer
referencia al Cuadro 9.5 para hallar la varianza de la actividad A (firmar el contrato). Como sabemos los
tiempos más optimistas y pesimistas para esta tarea (3 y 11 días, respectivamente), su varianza se calcula así:

Esta información es importante para los gerentes de proyectos, porque queremos saber no solo los posibles
tiempos para las actividades, sino también el grado de confianza que podemos colocar en estas estimaciones,
por lo que, para la actividad de nuestro proyecto A, se puede observar que a pesar de que es más probable
terminarla en 5 semanas, hay una cantidad considerable de varianza en la estimación (cerca de 2 semanas).
También es posible utilizar esta información para calcular la varianza esperada y la desviación estándar para
todas las actividades en nuestro proyecto Delta, como se muestra en el cuadro 9.7.
También podemos utilizar la información del cuadro 9.7 para calcular la variación global del proyecto.
La varianza del proyecto se halla mediante la suma de las varianzas de todas las actividades claves y se puede
representar según la siguiente ecuación:

Σ
Por tanto, en nuestro ejemplo, podemos calcular la varianza global y la desviación estándar para el proyecto
Delta. Recordemos que las actividades claves en este proyecto son A – C – D – F – H. Para la varianza global
del proyecto, el cálculo es:
2
Varianza del proyecto (s p ) = 1.78 + 1.00 + 4.00 + 0.69 + 0.25 = 7.72

La varianza del proyecto (sp) se encuentra como: Varianza del proyecto = 7.72 = 2.78 semanas.
La información de la varianza del proyecto es útil para evaluar la probabilidad de la terminación del
proyecto a tiempo, porque las estimaciones PERT hacen dos suposiciones más útiles: (1) el tiempo total de

CUADRO 9.7  Duraciones esperadas y varianzas de las actividades del proyecto Delta

Optimista Más Duración


Actividad (a) probable (m) Pesimista (b) esperada Varianza [(b - a)/6]2
A 3  4 11 5 [(11 - 3)/6]2 = 64/36  = 1.78
B 2  5  8 5 [(8 - 2)/6]2  = 36/36   = 1.00
C 3  6  9 6 [(9 - 3)/6]2   = 36/36  = 1.00
D 8 12 20 12.7 [(20 - 8)/6]2 = 144/36 = 4.00
E 3  5 12 5.8 [(12 - 3)/6]2 = 81/36   = 2.25
F 2  4  7 4.2 [(7 - 2)/6]2   = 25/36  = 0.69
G 6  9 14 9.3 [(14 - 6)/6]2 = 64/36   = 1.78
H 1  2  4 2.2 [(4 - 1)/6]2   = 9/36   = 0.25
9.5  Construcción de la ruta crítica 317

Desviación estándar del proyecto = 2.78

30 semanas

FIGURA 9.16  Distribución de probabilidad para el tiempo de terminación del


proyecto Delta

terminación del proyecto se comporta como una distribución de probabilidad normal, y (2) los tiempos de
las actividades son estadísticamente independientes. Como resultado, la curva de la distribución normal
mostrada en la figura 9.16 se puede utilizar para representar tiempos de terminación de proyectos. La distri-
bución normal implica que hay 50% de probabilidad de que el tiempo total del proyecto Delta sea menor de
30 semanas y 50% de probabilidad de que sea mayor de 30 semanas. Con esta información podemos determi-
nar la probabilidad de que el proyecto se terminará a más tardar en una fecha determinada.
Supongamos, por ejemplo, que es fundamental para nuestra empresa que el proyecto Delta termine
antes de 32 semanas. Aunque el cronograma del proyecto arroja una fecha de terminación de 30 semanas,
recuerde que nuestras estimaciones se basan en probabilidades. Por tanto, si queremos determinar la proba-
bilidad de que el proyecto se termine a más tardar en 32 semanas, tendríamos que determinar el área bajo la
curva correspondiente a la distribución normal de la figura 9.17 que corresponde a una fecha de terminación
en la semana 32 o antes. Podemos utilizar la ecuación de la distribución normal estándar para determinar
esta probabilidad. La ecuación de la normal estándar se representa como:
Z = (fecha de terminación - fecha prevista de terminación)/vp
= (32 - 30) /2.78, o 0.72

Donde Z es el número de desviaciones estándar desde la fecha límite (32 semanas) a la fecha media o espe-
rada de terminación (30 semanas). Ahora podemos utilizar una tabla de distribución normal (véase el apén-
dice A) para determinar que un valor Z de 0.72 indica una probabilidad de 0.7642. Por tanto, existe 76.42%
de probabilidad de que el proyecto Delta finalice en o antes de la fecha crítica de 32 semanas. Visualmente,
este cálculo se asemejaría a la imagen de la figura 9.17, que muestra las dos semanas adicionales representa-
das como parte de la curva normal sombreada a la izquierda de la media.

0.72 Desviaciones estándar

Probabilidad
(T ≤ 32 semanas es 76.42%)

30 32 Tiempo
semanas semanas
FIGURA 9.17  Probabilidad de terminación del proyecto Delta en 32 semanas
318 Capítulo 9  •  Programación del proyecto

Recordemos que en este ejemplo, el cumplir el plazo de 32 semanas es fundamental para la empresa. ¿Qué
tan seguros estaríamos en trabajar en este proyecto, si la probabilidad de finalizarlo en esa fecha es solo de 76.42%?
Lo más probable es que el equipo del proyecto (y la organización) podría encontrar como inaceptable 76% de
posibilidades de éxito para el cumplimiento de la fecha límite, lo cual conduce naturalmente a la pregunta: ¿cuánto
tiempo necesita el equipo del proyecto, para garantizar la entrega con un alto grado de confianza?
La primera pregunta que debe responderse es: ¿cuál es el porcentaje de probabilidad mínimo acepta-
ble que una organización necesita para tomar esta decisión? Por ejemplo, hay una gran diferencia en que se
requiera una confianza de 99% para la terminación frente a una probabilidad de 90%. Supongamos que la
organización que desarrolla el proyecto Delta requiere una probabilidad de 95% para la entrega a tiempo. En
esta circunstancia, ¿qué cantidad de tiempo adicional se requiere para asegurar una probabilidad de 95% de
cumplimiento de la fecha de entrega del proyecto?
Estamos en condiciones de determinar este valor, una vez más, con la ayuda de las tablas de distribución
normal estándar Z. Las tablas indican que para 95% de probabilidad, se obtiene un valor Z de 1.65. Podemos
reescribir la ecuación normal estándar anterior y calcular la fecha de terminación, de la siguiente manera:

= 30 semanas + (1.65) (2.78)


= 34.59 semanas

Si el equipo del proyecto puede negociar un periodo adicional de 4.59 semanas, tienen una muy alta probabi-
lidad (95%) de garantizar que el proyecto Delta se completará a tiempo.
Es importante tener en cuenta un punto final respecto a la estimación de las probabilidades de la termi-
nación del proyecto. Hasta ahora, solo hemos abordado las actividades de la ruta crítica, ya que, lógicamente,
definen la duración total de un proyecto. Sin embargo, hay algunas circunstancias en las que puede ser nece-
sario tener en cuenta las actividades no críticas y su efecto sobre la duración total del proyecto, sobre todo
si estas actividades tienen poco tiempo de holgura individual y una alta varianza. Por ejemplo, en nuestro
proyecto Delta, la actividad B tiene solo 1 día de holgura y no hay variación suficiente de 1.00. De hecho, el
tiempo pesimista para la actividad B es 8 semanas, lo cual provocaría que el proyecto pierda su plazo de obje-
tivo de 30 semanas, a pesar de que la actividad B no está en la ruta crítica. Por esta razón, es necesario calcular
las varianzas de tareas individuales no solo para las actividades críticas, sino para todas las actividades del
proyecto, especialmente para aquellas con varianzas mayores. Entonces podemos calcular la probabilidad de
cumplir nuestras fechas de terminación previstas en todas las rutas, tanto críticas como no críticas.

Actividades de escalamiento
La red PERT/CPM típica opera según el supuesto de que una actividad predecesora debe estar completamente
terminada antes del inicio de la tarea sucesora. Sin embargo, en muchas circunstancias, puede comenzar una
parte del trabajo de una actividad, mientras continúa en otros elementos de la tarea, en particular en proyectos
prolongados o complejos. Considere un proyecto de desarrollo de software para un nuevo sistema de registro
de pedidos. Una de las tareas de la red global del proyecto podría ser la creación de un código Visual Basic
compuesto por varias subrutinas para cubrir los sistemas de múltiples departamentos. Un PERT estándar dia-
gramaría la lógica de la red de la codificación a través de la depuración como una secuencia lógica sencilla, en
la que el diseño del sistema precede a la codificación, que precede a la depuración (véase figura 9.18). Bajo una
gran presión de tiempo para utilizar nuestros recursos de manera eficiente, sin embargo, desearíamos encontrar
un método para simplificar o hacer más eficiente la secuencia de desarrollo.
El escalamiento es una técnica que nos permite volver a trazar la red de actividades, haciendo énfasis en
las subtareas del proyecto para que la secuencia general de la red sea más eficiente. La figura 9.19 muestra la ruta
para el proyecto de desarrollo de software, con escalamiento. Tenga en cuenta que por razones de simplicidad,

A
Diseño del B C
sistema Codificación Depuración

FIGURA 9.18  Red AON Para la secuencia de programación sin escalamiento


9.5  Construcción de la ruta crítica 319

A1 A2 A3
Diseño Diseño Diseño

A1 A2 A3
Codificación Codificación Codificación

A1 A2 A3
Depuración Depuración Depuración

FIGURA 9.19  Red AON para la secuencia de programación con el efecto del escalamiento

hemos dividido las etapas de diseño, codificación y depuración en tres subtareas. Típicamente, el número de
escalas construidas es una función del número de puntos de quiebre identificados y de pasos secundarios lógi-
cos disponibles. Si asumimos que el diseño del software y el proyecto de codificación tienen tres subprogramas
importantes, podemos crear un efecto de escalamiento que le permita al equipo del proyecto completar primero
la fase de diseño 1, a continuación, pasamos a diseñar la fase 2 mientras la codificación de la fase de diseño 1 ya ha
comenzado. A medida que avanza el proceso de escalamiento, en el momento en que nuestros diseñadores están
listos para iniciar la fase de diseño 3 en el proyecto, los programadores han comenzado la segunda subrutina y
el personal de depuración está listo para empezar a depurar subprograma 1. El efecto global de las actividades de
escalamiento es simplificar la conexión y la secuencia entre las actividades y asegurar que los recursos del proyecto
se utilicen plenamente.

Actividades resumen
Las actividades resumen se utilizan como resúmenes de algunos subconjuntos de actividades señaladas en la
red global del proyecto. Si la empresa necesita un consultor externo para manejar las actividades de codificación
para la actualización del software de su sistema de inventario, una actividad resumen puede utilizarse dentro de
la red para resumir las tareas, la duración y el costo. También se conocen como hamaca porque cuelga debajo de
la ruta de la red para tareas de consultoría y sirve como una adición de duración de las tareas para las actividades
que se encuentran sobre ella. La duración de una actividad resumen se halla identificando primero todas las
tareas que deben incluirse y luego restando el ES la primera tarea del EF de la última sucesora. En la figura
9.20, se observa que la duración total de la actividad resumen es 26 días, lo cual representa una combinación de
actividades D, E y F, con sus duraciones individuales de 6, 14 y 6 días, respectivamente.

5 B 9 12 G 21
13 10
18 4 22 22 9 31

0 A 5 5 C 12 12 H 22 31 I 35
0 9 9 0
0 5 5 14 7 21 21 10 31 31 4 35

5 D 11 11 E 25 25 F 31
Necesidades 0 Codificación 0 Depuración
0
del usuario 11 14 25 25 6 31
5 6 11

5 A 31
Resumen
26

FIGURA 9.20  Ejemplo de una actividad resumen (hamaca)


320 Capítulo 9  •  Programación del proyecto

Las actividades resumen le permiten al equipo del proyecto desglosar mejor la red global del proyecto
en resúmenes lógicos. Este proceso resulta particularmente útil cuando la red del proyecto es muy compleja o
se compone de un gran número de actividades individuales. También es útil cuando el presupuesto del pro-
yecto se comparte entre varios centros de costo o departamentos. Las actividades resumen se pueden asignar
a cada centro de costo, haciendo que el trabajo de contabilidad de costos para el proyecto sea más fácil.

Opciones para reducir la ruta crítica


Es común que, al construir una red de actividades y determinar la duración prevista del proyecto, se bus-
quen formas en que el proyecto pueda acortarse. Para ello, se debe comenzar con mente abierta para evaluar
críticamente cómo se estimaron las duraciones de las actividades, cómo se construyó originalmente la red y
reconocer todos los supuestos en que se basó la construcción de la red. La reducción de la ruta crítica puede
requerir varias iniciativas o medidas, pero estas tienen que ser consistentes internamente (por ejemplo, que
sus efectos combinados no se anulen entre sí) y priorizarse lógicamente.
El cuadro 9.8 muestra algunos de los métodos más comunes para la reducción de la ruta crítica de un pro-
yecto. Las opciones incluyen no solo las destinadas a ajustar la red general del proyecto, sino también opciones que
se ocupan de las tareas individuales de la red. Entre las alternativas para la reducción de la ruta crítica se encuentran:9
1. Eliminar tareas de la ruta critica.  Algunas de las tareas que se encuentran en la ruta crítica pueden
eliminarse si no son necesarias o pueden moverse a caminos no críticos con holgura adicional.
2. Replanear rutas seriales para convertirlas en paralelo.  En algunas circunstancias, un proyecto
puede estar excesivamente cargado de actividades en serie que podrían fácilmente trasladarse a las
rutas paralelas o simultáneas en la red. La lluvia de ideas ayuda a determinar métodos alternativos para
sacar actividades en serie de la ruta crítica y moverlas a rutas no críticas.
3. Superponer tareas secuenciales.  El escalamiento es un buen método para la superposición de activi-
dades secuenciales. En lugar de desarrollar una larga lista de tareas en serie, el escalamiento identifica
puntos secundarios dentro de las actividades, de tal forma que los miembros del equipo del proyecto
pueden empezar a realizar operaciones simultáneas.
4. Acortar la duración de las tareas de la ruta crítica.  Esta opción debe explorarse cuidadosamente.
Aquí, la cuestión de fondo es examinar en primer lugar los supuestos que guiaron las estimaciones origi-
nales de duración de las actividades para el proyecto. ¿Es razonable utilizar la distribución beta? Las dura-
ciones estimadas en las tareas fueron excesivamente acolchadas por el jefe de proyecto o por el equipo?
Dependiendo de las respuestas a estas preguntas, puede acortarse la duración de las actividades de la ruta
crítica. Sin embargo, a veces, la opción de simplemente reducir las estimaciones de la duración, en una
cierta cantidad de ajuste (por ejemplo, 10% de descuento en todas las estimaciones de duración), prácti-
camente garantiza que el proyecto sea entregado con retrasos respecto a la programación original.
5. Acortar las tareas iniciales.  A veces es fácil recortar las tareas iniciales de un proyecto porque por lo gene-
ral son más precisas que las posteriores. Hay una mayor incertidumbre en las actividades programadas para
algún momento en el futuro. Muchos gerentes de proyecto ven poco probable arriesgar la reducción de las
primeras tareas, ya que cualquier retraso en el calendario se puede remediar aguas abajo. Sin embargo, una
vez más, cada vez que deliberadamente se acortan las actividades del proyecto, tenemos que ser conscientes
de los posibles efectos en cadena a lo largo de la red, ya que estos ajustes se hacen sentir más tarde.
6. Acortar las tareas más largas.  El argumento para acortar las tareas más largas tiene que ver con la
contracción relativa. Es menos probable que la reducción de estas actividades ocasione problemas de

CUADRO 9.8  Pasos para reducir la ruta crítica

1. Eliminar tareas de la ruta crítica.


2. Replanear rutas en serie para convertirlas en paralelo.
3. Superponer tareas secuenciales.
4. Acortar la duración de las tareas de la ruta crítica.
5. Acortar las tareas iniciales.
6. Acortar las tareas más largas.
7. Acortar las tareas más fáciles.
8. Acortar las tareas que cuestan menos acelerar.
Resumen 321

programación de la red general del proyecto, puesto que las tareas de mayor duración pueden absorber
más fácilmente los recortes, sin tener un efecto en el conjunto del proyecto. Por ejemplo, acortar una
tarea con una duración de 5 días en 1 día representa una reducción de 20% en la estimación de la dura-
ción. Por otro lado, al acortar una tarea de duración de 20 días en 1 día, se genera un impacto de solo 5%.
7. Acortar las tareas más fáciles.  La lógica aquí es que la curva de aprendizaje de una actividad de
proyecto puede hacer más fácil recortar su duración. Desde la perspectiva de costos y presupuestos,
que vimos en el capítulo 8, la metodología de curva de aprendizaje ocasiona costos más bajos para las
actividades del proyecto. Las estimaciones de duración de las tareas más sencillas suelen estar excesiva-
mente infladas, y razonablemente se pueden disminuir sin tener un efecto adverso en la capacidad del
equipo del proyecto para llevar a cabo la tarea en un lapso más corto.
8. Acortar las tareas que cuesta menos acelerar.  “Acelerar" las tareas de un proyecto es otra manera de deno-
minar las actividades de compresión. Con más detalle, en el capítulo 10 vamos a cubrir el proceso de compre-
sión para las actividades del proyecto. La opción de comprimir las actividades del proyecto debe considerarse
cuidadosamente respecto a la relación tiempo/costo para que las actividades menos costosas sean las que se
aceleran.

RECUADRO 9.1

INVESTIGACIÓN DE GERENCIA DE PROYECTOS EN SÍNTESIS


Retrasos y soluciones en el desarrollo de software
Uno de los problemas más comunes en la gerencia de proyectos de IT se refiere a los retrasos en el cronograma de
proyectos de desarrollo de software. El promedio del sector, en relación con el tiempo y el costo, sobrepasa en más
de 100% los cronogramas y presupuestos originales. Un estudio realizado por Callahan y Moretton trató de exami-
nar cómo se podrían reducir estos retrasos. Analizando los resultados en 44 empresas que participaron en proyectos
de desarrollo de software, ellos encontraron que el nivel de experiencia que las empresas han tenido en la gerencia
de proyectos de IT, tuvo un efecto significativo en la velocidad con la que trajeron nuevos productos al mercado.
Cuando las empresas tenían poca experiencia, la acción más importante que tomaron para acelerar el tiempo de
desarrollo,fue interactuar tempranamente y con frecuencia, durante todo el ciclo de desarrollo, con los grupos de
clientes y dentro de sus propias organizaciones. Cuanta más información pudieron recoger respecto a las necesi-
dades de los clientes, más rápido se lograron desarrollar sus productos de software. Además, encontraron que fre-
cuentemente implementaron pruebas y múltiples iteraciones de diseño, con el fin de acelerar el tiempo de entrega.
En las empresas con amplia experiencia en proyectos de desarrollo de software, se encontró que el deter-
minante más importante de ciclos de desarrollo más cortos fue el desarrollo de relaciones con los proveedores
externos, particularmente durante las fases de definición de los requisitos del producto, diseño de sistemas y
pruebas beta del proyecto. La participación de proveedores en todas las fases del ciclo de desarrollo ha sido clave
para mantener cronogramas de desarrollo dinámicos.10

Este capítulo describió los elementos esenciales para iniciar la programación del proyecto, incluidos la lógica
detrás de la construcción de una red de actividades del proyecto, el cálculo de las estimaciones de la duración
de la actividad y la conversión de esta información en un diagrama de ruta crítica. Estas tres actividades for-
man el núcleo de la programación de proyectos y nos dan el impulso para comenzar a considerar algunos de
los temas avanzados adicionales importantes, si queremos llegar a ser expertos en el proceso de programa-
ción de proyectos. Estos temas se tratarán en los siguientes capítulos.

Resumen
1. Entender y aplicar la terminología clave de progra­ 2. Aplicar la lógica utilizada para crear redes de activi­
mación.  Los procesos claves en la programación de dades, incluidas tareas predecesoras y sucesoras. El
proyectos incluyen cómo se construyen las redes de capítulo analiza la manera en que se emplea la lógica de
actividades, cómo se estima la duración de las tareas, la red. Después de la creación de las tareas del proyecto,
cómo se calcula la ruta crítica y la holgura de cada acti- mediante el uso de estructuras de desglose de trabajo,
vidad y cómo se integran los retrasos en las relaciones se requiere implementar una lógica para estas tareas,
de las actividades. con el fin de identificar qué actividades se consideran
322 Capítulo 9  •  Programación del proyecto

predecesoras (iniciando antes en la red) y cuáles son a determinar la duración estimada de cada actividad.
las sucesoras (iniciando después, o después de que las La estimación de la duración se realiza frecuentemente
actividades predecesoras se han completado). utilizando estimaciones probabilísticas basadas en la
3. Desarrollar una red de actividades utilizando la téc­ técnica de revisión y evaluación de programas (PERT),
nica actividad en el nodo (AON).  El capítulo exa- en la cual se recogen las estimaciones de duración opti-
minó el proceso para la creación de una red AON mista, más probable y pesimista para cada actividad.
mediante la identificación de las relaciones de prece- Utilizando una fórmula estándar basada en la distribu-
dencia entre las actividades del proyecto. Una vez que ción beta, se estima la duración para cada actividad del
se conocen estas relaciones, puede comenzarse a vin- proyecto y se utiliza para etiquetar los nodos de activi-
cular las actividades para crear la red del proyecto. La dad en la red.
técnica AON aplica la lógica de asignación de todas Con las duraciones de las actividades y la red,
las tareas como "nodos" específicos en la red y su vin- podemos identificar las trayectorias individuales, sus
culación con flechas para identificar las relaciones longitudes y la ruta crítica. La ruta crítica del proyecto
predecesora/sucesora. se define como aquellas actividades de un proyecto
4. Estimar la duración de las actividades basándose en que, cuando se unen, definen la longitud total más
el uso de técnicas de estimación de probabilidad. La corta. La ruta crítica identifica la rapidez con que pode-
estimación de la duración de la actividad se realiza pri- mos completar el proyecto. Todos los otros caminos
mero mediante la identificación de las diversas tareas contienen actividades que, hasta cierto punto, tienen
de un proyecto y luego la aplicación de un método para holgura o tiempos muertos asociados a ellas. La iden-
estimar la duración de cada una de estas actividades. tificación de la ruta crítica y de los tiempos de holgura
Entre los métodos que nos pueden ayudar en la esti- de la actividad se realiza mediante el uso de un proceso
mación de la duración de las actividades se encuentran: de recorrido hacia adelante y de recorrido hacia atrás,
(1) las técnicas no computacionales, por ejemplo, el en los cuales se calcula para cada actividad el tiempo de
examen de los registros anteriores para tareas similares inicio temprano (ES), de fin temprano (EF), de inicio
que se han realizado en otras ocasiones en organizar y tardío (LS) y de fin tardío (LF).
obtener la opinión de expertos; (2) obtener estimacio- 7. Calcular la probabilidad de terminación de un pro­
nes de duración a través de el análisis por computador, yecto en un tiempo determinado, según estimacio­
o de las matemáticas; y (3) mediante la técnica de revi- nes PERT. Debido a que las estimaciones PERT se
sión y evaluación de programas (PERT), que utiliza las basan en un rango de tiempos estimados (optimista,
probabilidades para estimar la duración de una tarea. más probable, pesimista), habrá algo de varianza aso-
En la implementación de PERT, para estimar la dura- ciada con estos valores y con la duración estimada
ción de cada tarea, se emplea una distribución de pro- para la tarea. La determinación de la varianza de
babilidad beta, a fin de determinar primero las estima- todas las actividades en las rutas críticas (y no críti-
ciones más optimistas, más probables y pesimistas para cas) nos permite pronosticar con mayor precisión la
la duración de cada actividad y después se les asignará probabilidad de completar el proyecto antes o en una
en una proporción de: fecha de terminación esperada. También podemos
utilizar la ecuación de la distribución normal están-
dar (y valor Z asociado) para pronosticar el tiempo
adicional necesario para completar un proyecto en
5. Construir la ruta crítica para la red del cronograma diferentes niveles de confianza.
del proyecto utilizando recorridos hacia adelante y 8. Comprender los pasos que se pueden dar para reducir
hacia atrás.  Realizar el recorrido hacia adelante nos la ruta crítica.  La duración del proyecto se puede
permite determinar la duración total prevista para reducir por diferentes medios. Entre las opciones que
el proyecto, mediante el uso de reglas de decisión, pueden emplear los gerentes de proyectos para acortar
sumando el tiempo de inicio temprano y la duración de la ruta crítica del proyecto están las siguientes: (1) eli-
la actividad para determinar el tiempo de fin temprano minar tareas de la ruta crítica; (2) replanear rutas de
y luego aplicar este valor de fin temprano al siguiente actividades en serie para convertirlas en paralelo; (3)
nodo de la red, donde se convierte en el inicio tem- superponer tareas secuenciales; (4) acortar la duración
prano de esta actividad. A continuación, utilizamos de tareas de la ruta crítica; (5) acortar las tareas iniciales
reglas de decisión para el recorrido hacia atrás para del proyecto; (6) acortar las tareas más largas; (7) acortar
identificar todas las actividades y rutas con holgura y la las tareas más fáciles; y (8), acortar las tareas que cuestan
ruta crítica del proyecto (la ruta del proyecto sin tiem- menos acelerar. La eficacia de la aplicación de uno de
pos muertos). estos enfoques sobre otro, variará dependiendo de una
6. Identificar la holgura de una actividad y la manera en serie de aspectos relacionados con las limitaciones del
que se determina.  Una vez construida la red que une proyecto y con las expectativas del cliente y de la misma
todas las actividades del proyecto, se puede comenzar organización del gerente del proyecto.
Problemas resueltos 323

Términos
Problemasclave
resueltos
Actividad (también llamada Actividades concurrentes Fecha de inicio temprano Programación con recursos
tarea) (p. 298) (p. 303) (ES) (p. 300) limitados (p. 301)
Actividad convergente Alcance (p. 300) Flecha (p. 300) Recorrido hacia adelante
(p. 300) Diagrama de red (p. 299) Holgura (también llamada (p. 301)
Actividad en la flecha Diagrama de red del flotante) (p. 300) Recorrido hacia atrás (p. 301)
(AOA) (p. 301) proyecto (PND) (p. 300) Intervalo de confianza Ruta (p. 301)
Actividad en el nodo Distribución beta (p. 308) (p. 310) Ruta crítica (p. 301)
(AON)(p. 301) Duración de estimación Método de la ruta crítica Sucesoras (p. 301)
Actividad ordenada (p. 298) (p. 307) (CPM) (p. 301) Tarea (véase actividad)
Actividades de Estructura de desglose Nodo (p. 301) (p. 298)
escalamiento (p. 318) del trabajo (WBS) (p. 300) Paquete de trabajo Técnica de revisión y
Actividades divergentes Evento (p. 300) (p. 301) evaluación de programas
(p. 304) Fecha de inicio tardío (LS) Planeación del proyecto (PERT) (p. 301)
Actividades en serie (p. 303) (p. 300) (p. 298) Varianza (actividad y
Actividades resumen (p. 319) Predecesoras (p. 301) proyecto) (p. 309)

Problemas resueltos

9.1 Creación de una red de actividades 9.2 Cálculo de las duraciones y varianzas de
las actividades
Supongamos que tenemos la siguiente información:
Supongamos que tenemos las siguientes estimaciones pesimista, más pro-
bable y optimista para una serie de actividades. Usando la distribución
Actividad Predecesoras beta, estime las duraciones y las varianzas para cada una de las tareas.

A —
Duración estimada
B A
C B Más
D B Actividad Pesimista probable Optimista
E C, D A  7  5 2
F C B  5  3 2
G E, F C 14  8 6
H D, G D 20 10 6
E  8  3 3
Elabore una red de actividades que muestre la lógica secuencial F 10  5 3
entre las tareas del proyecto. ¿Puede identificar actividades con- G 12  6 4
vergentes y actividades divergentes? H 16  6 5

SOLUCIÓN SOLUCIÓN
Esta red de actividades puede resolverse como se muestra en la figura Recuerde que con la distribución beta, la duración esperada (TE) de
9.21. Los puntos de convergencia en la red son las actividades E, G y la actividad se calcula como:
H. Las actividades divergentes son B, C y D. TE = (a + 4m + b) /6
Donde
TE = tiempo estimado para la actividad
C F a = tiempo más optimista para completar la actividad
m
  = tiempo más probable para completar la actividad,
  la moda de la distribución
A B E G b = tiempo más pesimista para completar la actividad
La fórmula de la varianza de cada actividad es:
H
D
Por tanto, la duración esperada (TE) de la actividad y la varianza de
FIGURA 9.21  Solución al problema 9.1 cada tarea se muestra en el siguiente cuadro:
324 Capítulo 9  •  Programación del proyecto

Duración estimada

Actividad Pesimista Más probable Optimista TE (Beta) Varianza


A  7  5 2 4.8 2
[(7 - 2)/6]    = 25/36   = 0.69
B  5  3 2 3.2 [(5 - 2)/6]2    = 9/36    = 0.25
C 14  8 6 8.7 [(14 - 6)/6]2   = 64/36   = 1.78
D 20 10 6 11.0 [(20 - 6)/6]2   = 196/36 = 5.44
E  8  3 3 3.8 [(8 - 3)/6]2    = 25/36   = 0.69
F 10  5 3 5.5 [(10 - 3)/6]2   = 49/36   = 1.36
G 12  6 4 6.7 [(12 - 4)/6]2   = 64/36   = 1.78
H 16  6 5 7.5 [(16 - 5)/6]2 = 121/36 = 3.36

9.3 Determinación de la ruta crítica y de la SOLUCIÓN


holgura de cada actividad Siga el proceso iterativo para la creación de la red y etiquete los no-
dos tan completos como sea posible. Luego, siguiendo la figura 9.22,
Supongamos que tenemos un conjunto de actividades, sus duracio-
primero realice el recorrido hacia adelante a lo largo de la red para
nes esperadas y predecesoras inmediatas. Construya una red de ac-
determinar que la duración prevista del proyecto es 27 días. Con
tividades, identifique la ruta crítica y todas las holguras de actividad.
el uso del recorrido hacia atrás, puede determinar los periodos de
holgura individual, así como la ruta crítica. La ruta crítica para este
Actividad Predecesoras Duración esperada ejemplo es la siguiente: A – B – D – G – H. Los tiempos de holgura
A — 6 para cada actividad son:
B A 7 C = 1 día
C A 5 E = 1 día
D B 3 F = 8 días
E C 4
F C 5
G D, E 8
H F, G 3

6 B 13 13 D 16
6 7 13 13 3 16

16 G 24
16 8 24

0 A 6 11 E 15 24 H 27
0 6 6 12 4 16 24 3 27

6 C 11
7 5 12

11 F 16

19 5 24

FIGURA 9.22  Solución al problema 9.3

Preguntas para discusión


1. Defina los siguientes términos: e.
Inicio tardío
a. Ruta f.
Fin tardío
b. Actividad g.
Recorrido hacia adelante
c. Inicio temprano h.
Recorrido hacia atrás
d. Fin temprano i.
Nodo
Problemas 325

j.
AON 4. Según su opinión, ¿cuáles son las principales ventajas e inconve-
k.
Holgura nientes de la utilización de la distribución beta (basado en técnicas
l.
Ruta crítica PERT) para calcular estimaciones de la duración de la actividad?
m.
PERT 5. “La longitud total más corta de un proyecto se determina por la
2. Distinga entre las actividades en serie y las actividades en para- ruta más larga a través de la red". Explique el concepto que sub-
lelo. ¿Por qué buscamos utilizar las actividades en paralelo yace en esta afirmación. ¿Por qué la ruta más larga determina la
como una manera de acortar la longitud del proyecto? duración más corta del proyecto?
3. Enumere tres métodos para calcular la duración estimada de las 6. La holgura asociada a cada tarea del proyecto solo se puede
actividades del proyecto. ¿Cuáles son las fortalezas y debilidades obtener después de completar recorridos hacia adelante y hacia
asociadas a cada método? atrás. Explique por qué esto es cierto.

Problemas
1. Considere un proyecto, tal como mudarse a un nuevo vecindario, 5. Con la siguiente información, elabore un diagrama de activi-
completar una tarea escolar de finalización de curso o incluso la dades AON. Calcule el TE para cada actividad (redondee al
limpieza de su habitación. Desarrolle el conjunto de actividades entero más cercano), la duración total del proyecto y su inicio
necesarias para llevar a cabo ese proyecto y luego ordénelas de una temprano, fin temprano, inicio tardío y fin tardío, y la hol-
manera de precedencia para crear la lógica secuencial. Explique y gura para cada actividad. Por último, muestre la ruta crítica del
defienda el número de pasos que ha identificado y el orden en que proyecto.
se dan los pasos para la mejor realización del proyecto.
2. ¿Cuál es el tiempo estimado de la siguiente actividad en la que
Actividades Más
la estimación optimista es 4 días, pesimista 12 días, y la más Mejor
Actividad predecesoras probable Peor
probable 5 días? Muestre sus cálculos.
3. Considere las siguientes tareas del proyecto y las estimaciones más A — 12 15 25
probables, pesimistas y optimistas para cada tarea. Supongamos B A  4  6 11
que la organización trabaja calculando el TE con base a la fórmula C — 12 12 30
de distribución beta estándar. Calcule el TE para cada una de las
D B, C  8 15 20
siguientes tareas (aproxime al entero más cercano):
E A  7 12 15
F E  9  9 42
Actividad Mejor Más probable Peor TE
G D, E 13 17 19
A  5  5 20 H F  5 10 15
B  3  5  9 I G 11 13 20
C  7 21 26 J G, H  2  3  6
D  4  4  4 K J, I  8 12 22
E 10 20 44
F  3 15 15 a. Ahora, suponga que la actividad E ha tomado 10 días más
G  6  9 11 allá de su duración prevista para completarse. ¿Qué sucede
H 32 44 75 con el cronograma del proyecto? ¿Ha cambiado la duración?
I 12 17 31 ¿Hay una nueva ruta crítica? Demuestre sus conclusiones.
6. Un gerente de proyecto de publicidad desarrolla un programa
J  2  8 10
para una nueva campaña publicitaria. Además, el gerente ha
reunido la información de tiempo para cada actividad, como se
4. Construya un diagrama de red de actividades, con base en la muestra en el siguiente cuadro.
siguiente información:
Tiempo estimado (semanas)
Actividad Actividades predecesoras
Más Predecesora(s)
A — Actividad Optimista probable Pesimista inmediata(s)
B —
C A A 1  4  7 —
D B, C B 2  6 10 —
E B C 3  3  9 B
F C, D D 6 13 14 A
G E E 4  6 14 A, C
H F F 6  8 16 B
I G, H G 2  5  8 D, E, F
326 Capítulo 9  •  Programación del proyecto

a. Calcule los tiempos de duración esperados de cada activi- a. Construya la red de actividades del proyecto, utilizando la
dad (redondee al número entero más cercano). metodología AON y etiquete cada nodo.
b. Calcule la holgura de cada actividad. ¿Cuál es la longitud b. Utilice la siguiente información para determinar la probabili-
total del proyecto? Asegúrese de etiquetar completamente dad de que este proyecto finalice dentro de 34 semanas de la
todos los nodos de la red. fecha de terminación programada. Suponga que las activida-
c. Identifique la ruta crítica. ¿Cuáles son los caminos alternati- des A - B - D - F - G son la ruta crítica del proyecto.
vos y la cantidad de tiempo de holgura asociado a cada ruta?
d. Identifique las actividades convergentes y divergentes.
Más Tiempo
e. Teniendo en cuenta las varianzas de cada actividad, ¿cuál es
Actividad Optimista probable Pesimista esperado Varianza
la probabilidad de que el proyecto finalice en 24 semanas?
f. Suponga que se quiere tener una confianza de 99% en que el A 1  4  8
proyecto terminara a tiempo. ¿Cuántas semanas adicionales B 3  5  9
necesitaría su equipo de proyecto para negociar la fecha de
C 4  6 10
terminación, con el fin de obtener este 99% de probabilidad?
7. Considere un proyecto con la siguiente información: D 3  7 15
E 5 10 16
Actividad Duración Predecesoras F 3  6 15
A 3 — G 4  7 12
B 5 A
C 7 A a. Calcule las duraciones estimadas para cada actividad.
D 3 B, C b. Calcule las varianzas de las tareas individuales y la varianza
E 5 B total del proyecto.
c. La empresa debe presentar una solicitud de permiso ante
F 4 D
el gobierno local dentro de un tiempo limitado, después de
G 2 C que el proyecto esté terminado. ¿Cuál es la probabilidad de
H 5 E, F, G que el proyecto se finalice en 34 semanas?
d. Si se quiere estar 99% seguro de la entrega a tiempo del pro-
Actividad Duración ES EF LS LF Holgura yecto, ¿cuánto más tiempo se requerería añadir al tiempo de
entrega esperado del proyecto?
A 3  0  3  0  3 —
B 5  3  8  8 13 5
C 7  3 10  3 10 —
D 3 10 13 10 13 —
E 5  8 12 13 17 5
F 4 13 17 13 17 —
G 2 10 12 15 17 5
H 5 17 22 17 22 —

Ejercicios en internet
1. Ingrese en www.gamedev.net/page/resources/_/business/bu- y programación de proyectos. Seleccione un artículo y sintetice
sinessand-law/critical-path-analysis-and-scheduling-for-ga- los puntos principales. ¿Cuáles son los mensajes que el artículo
me-r1440 y dé clic en el sitio. Hay varios artículos sobre cómo quiere transmitir?
gerenciar su propia empresa de juegos de computador. Dé clic 4. Digite "programación de proyectos" para una búsqueda en la
en los artículos relativos a la gerencia y programación de ruta web. Cientos de miles de visitas se generan de esa búsqueda.
crítica para el diseño de juegos. ¿Por qué es tan importante Examine una sección transversal de los accesos. ¿Cuáles son al-
la programación de proyectos para el desarrollo de juegos de gunos de los temas más comunes en estos sitios web?
computador? 5. Digite "proyectos en ________" (seleccione el país de interés)
2. Ingrese en http://management.about.com/lr/project_time_ (por ejemplo, "proyectos en Finlandia"). Muchos de los pro-
management/174690/1/ y considere algunos de los artículos yectos generados por esa búsqueda son iniciativas patrocina-
sobre la gerencia del tiempo en los proyectos. ¿Qué sentido das por el gobierno. Analice el papel de la programación y la
tiene hablar en la programación de proyectos de la gerencia planeación adecuada en uno de esos proyectos que encuentra
del tiempo personal, si se trata de programación efectiva? Cite en internet. Comparta sus conclusiones y las razones por las
algunos artículos o información para apoyar o no estar de cuales usted cree que la planeación era tan importante para
acuerdo con esta posición. ese proyecto.
3. Ingrese en www.infogoal.com/pmc/pmcart.htm y examine al-
gunos de los artículos y documentos técnicos sobre planeación
Ejercicios con MS Project 327

Ejercicios con MS Project


Utilice un manual paso a paso sobre el uso de MS Project 2010, para
elaborar cronogramas de proyectos que están disponibles en el apén- Actividad
dice B. Para aquellos que decidan realizar los siguientes ejercicios, M Evaluar las capacidades de L
les resultará muy útil primero consultar el apéndice B para obtener comportamiento
consejos sobre cómo empezar. N Identificar los criterios de M
selección
Ejercicio 9.1 O Desarrollar RFQ M
Tome en cuenta la siguiente información que se ha recopilado sobre P Desarrollar programa maestro de N, O
los pasos necesarios para completar un proyecto. Usted ha identifi- producción
cado todas las medidas pertinentes y ha tomado algunas determina- Q Servir de enlace con el personal P
ciones respecto a las relaciones predecesora/sucesora. Con base en de ventas
MS Project, elabore un diagrama de red simple para este proyecto, R Preparar el lanzamiento del Q
que muestre los vínculos entre las actividades del proyecto. producto

Actividad Predecesoras
Ejercicio 9.3
A – Levantamiento —
Suponga que añade algunas estimaciones a la duración de cada una
B – Instalación de alcantarillado y drenaje pluvial A de las actividades del ejercicio 9.1. Una parte del cuadro revisado
C– Instalación de líneas de gas y de electricidad A se muestra en seguida. Vuelva a crear el diagrama de red para este
D – Excavación B, C proyecto y observe cómo MS Project se vale de los nodos para iden-
E – Vertimiento de la fundición D tificar la duración de las actividades, fechas de inicio y de fin, y pre-
decesoras. ¿Cuál es la ruta crítica para este diagrama de red? ¿Cómo
se determina?
Ejercicio 9.2
Actividad Duración Predecesoras
Suponga que tiene un cuadro completo de las actividades y sus pre-
decesoras y quiere elaborar un diagrama de red que muestre la se- A – Levantamiento 5 días —
cuencia de actividades para este proyecto. Con base en MS Project, B – Instalación de alcantarillado 9 días A
introduzca las actividades y sus predecesoras y elabore un diagrama y drenaje pluvial
de red para este proyecto. C – Instalación de líneas de 4 días A
gas y de electricidad
Proyecto de rediseño de un electrodoméstico D – Excavación 2 días B, C
Actividad Predecesoras E – Vertimiento de la fundición 2 días D

A Realizar análisis competitivo —


B Revisar informes de campo de — Preguntas de ejemplo del examen para la certificación
ventas PMP®
C Realizar evaluación de las —
1. Un ingeniero construye una casa de campo (de vacaciones)
capacidades de tecnología
y al consultar el cronograma del proyecto, se da cuenta de
D Desarrollar enfoque de técnicas A, B, C que este contempla primero la cimentación, luego la fun-
de grupo dición y después las cubierta. En este plan, la cubierta sería
E Realizar encuestas telefónicas D un ejemplo de qué tipo de actividad:
F Identificar mejoras pertinentes E a. Tarea sucesora
en las especificaciones b. Tarea predecesora
G Realizar interfaz con el personal F c. Holgura de actividad
de marketing d. Actividad de compresión
H Desarrollar especificaciones G 2. Su equipo de proyectos trabaja en uno nuevo con tecnolo-
técnicas gía de punta. Como resultado, es muy difícil para su equipo
I Comprobar y depurar diseños H dar estimaciones precisas y razonables acerca de la dura-
J Desarrollar protocolo de pruebas G ción de las actividades para completar el proyecto. Debido
K Identificar los niveles de J a esta incertidumbre, ¿qué tipo de lógica deberían utilizar
rendimiento claves los integrantes del equipo para estimar las duraciones?
L Evaluar y modificar los I, K a. Distribución normal
componentes del producto b. Distribución beta
c. Estimación determinística
d. Experiencia
328 Capítulo 9  •  Programación del proyecto

3. Suponga que un plan de proyecto tenía tres rutas dife- a. La actividad predecesora
rentes a lo largo de la red. La primera ruta consta de las b. Estimaciones de duración para las actividades y el
actividades A (3 días), B (4 días) y C (2 días). La segunda cronograma general
ruta consta de las actividades D (4 días), E (5 días) y F (5 c. Las fechas en que se espera que las actividades puedan
días). La tercera ruta consta de las actividades G (2 días), comenzar
H (3 días) e I (10 días). ¿Cuál es la ruta crítica? d. Un diagrama de red que mostrará ninguna de las
a. ABC anteriores
b. DEF
c. GHI Respuestas: 1. a—La cubierta es una tarea sucesora, ya que
d. ADG está previsto que ocurra después de la finalización de ver-
ter los cimientos; 2. b—La distribución beta funciona mejor,
4. La holgura de la actividad (también conocida como flota-
porque toma en cuenta las estimaciones del mejor de los
dor) se puede calcular a través de
casos, el más probable y el peor caso; 3. c—GHI tiene una
a. Fin temprano (EF) – fin tardío (LF)
ruta con duración de 15 días; 4. d—Una forma de calcular la
b. Fin temprano (EF) – inicio temprano (ES)
holgura es LS – ES; la otra forma es LF – EF; 5. a—La prin-
c. Fin tardío (LF) – inicio tardío (LS)
cipal ventaja de las redes de actividad es el ordenamiento,
d. Inicio tardío (LS) – inicio temprano (ES)
según las relaciones de precedencia de todas las actividades
5. Su equipo de proyectos trabaja a partir de un diagrama de del proyecto.
red. Este tipo de herramienta le mostrará al equipo:

Notas
1. 1.www.sa-venues.com/2010/2010-stadium.htm; www.ex- 4. La bibliografía sobre PERT/CPM es numerosa. Entre las citas,
ploresouthafrica.net/2010soccerworldcup/stadiums.htm; los lectores pueden encontrar útiles las siguientes: Gallagher, C.
Bearak, B. (2010, 12 de marzo). “Cost of stadium reveals (1987). “A note on PERT assumptions,” Management Science,
tensions in South Africa,” www.nytimes.com/2010/03/13/ 33: 1350; Gong, D., and Rowlings, J. E. (1995). “Calculation of
world/africa/13stadium.html; Berg, N. (2010, 10 de mayo). safe float use in risk-analysis-oriented network scheduling,”
“The infrastructural benefit of South Africa’s World International Journal of Project Management, 13: 187–94; Hulett,
Cup,”www.planetizen.com/node/44124; Clayton, J. (2009, D. (2000). “Project schedule risk analysis: Monte Carlo simula-
8 de julio). “Construction workers strike threatens 2010 tion or PERT?” PMNetwork, 14(2): 43–47; Kamburowski, J.
World Cup preparations,” www.timesonline.co.uk/tol/news/ (1997). “New validations of PERT times,” Omega: International
world/africa/article6660910.ece; Sokol, D. (2010, 7 de junio). Journal of Management Science, 25(3): 189–96; Keefer, D. L., and
“South Africa, host of 2010 World Cup, is ready for its big Verdini, W. A. (1993). “Better estimation of PERT activity time
debut,” http://archrecord.construction.com/news/daily/ parameters,” Management Science, 39: 1086–91; Mummolo,
archives/2010/100607south_africa_world_cup.asp; “When G. (1994). “PERT-path network technique: A new approach to
the whistle blows.” (2010, 3 de junio). www.economist.com/ project planning,” International Journal of Project Management,
node/16274395. 12: 89–99; Mummolo, G. (1997). “Measuring uncertainty and
2. Project Management Institute. (2000). Project Management criticality in network planning by PERT-path technique,”
Body of Knowledge. Newtown Square, PA: PMI. International Journal of Project Management, 15: 377–87;
3. Hay numerosas citas para el desarrollo de redes de proyec- Moder, J. J., and Phillips, C. R. (1970). Project Management with
tos. Algunas de las más importantes son: Callahan, J., and CPM and PERT. New York: Van Nostrand Reinhold; Mongalo,
Moretton, B. (2001). “Reducing software product develop- M. A., and Lee, J. (1990). “A comparative study of methods
ment time,” International Journal of Project Management, for probabilistic project scheduling,” Computers in Industrial
19: 59–70; Elmaghraby, S. E., and Kamburowski, J. (1992). Engineering, 19: 505–9; Wiest, J. D., and Levy, F. K. (1977). A
“The analysis of activity networks under generalized prece- Management Guide to PERT/CPM, 2nd ed. Englewood Cliffs,
dence relations,” Management Science, 38: 1245–63; Kidd, J. NJ: Prentice-Hall; Sasieni, M. W. (1986). “A note on PERT
B. (1991). “Do today’s projects need powerful network plan- times,” Management Science, 32: 942–44; Williams, T. M.
ning tools?” International Journal of Production Research, (1995). “What are PERT estimates?” Journal of the Operational
29: 1969–78; Malcolm, D. G., Roseboom, J. H., Clark, C. E., Research Society, 46(12): 1498–1504; Chae, K. C., and Kim, S.
and Fazar, W. (1959). “Application of a technique for re- (1990). “Estimating the mean and variance of PERT activity
search and development program evaluation,”Operations time using likelihood-ratio of the mode and the mid-point,” IIE
Research, 7: 646–70; Smith-Daniels, D. E., and Smith-Daniels, Transactions, 3: 198–203.
V. (1984). “Constrained resource project scheduling,” Journal 5. Gray, C. F., and Larson, E. W. (2003). Project Management,
of Operations Management, 4: 369–87; Badiru, A. B. (1993). 2nd ed. Burr Ridge, IL: McGraw-Hill.
“Activity-resource assignments using critical resource diagram- 6. Hill, J., Thomas, L. C., and Allen, D. C. (2000). “Experts’
ming,” Project Management Journal, 24(3): 15–22; Gong, D., estimates of task durations in software development proj-
and Hugsted, R. (1993). “Timeuncertainty analysis in project ects,” International Journal of Project Management, 18:
networks with a new merge event time-estimation technique,” 13–21; Campanis, N. A. (1997). “Delphi: Not a Greek ora-
International Journal of Project Management, 11: 165–74. cle, but close,” PMNetwork, 11(2): 33–36; DeYoung-Currey,
Notas 329

J. (1998). “Want better estimates? Let’s get to work,” 9. DeMarco, T. (1982). Controlling Software Projects:
PMNetwork, 12(12): 12–15; Lederer, A. L., and Prasad, J. Management, Measurement and Estimate. New York:
(1995). “Causes of inaccurate software-development cost Yourdon; Horner, R. M. W., and Talhouni, B. T. (n.d.). Effects
estimates,” Journal of Systems and Software, 31: 125–34; of Accelerated Working, Delays and Disruptions on Labour
Libertore, M. J. (2002).“Project schedule uncertainty analysis Productivity. London: Chartered Institute of Building;
using fuzzy logic,”Project Management Journal, 33(4): 15–22. Emsley, M. (2000). Planning and Resource Management—
7. Meredith, J. R., and Mantel, Jr., S. J. (2003). Project Module 3. Manchester, UK: UMIST.
Management, 5th ed. New York: Wiley. 10. Callahan, J., and Moretton, B. (2001). “Reducing software
8. Project Management Institute. (2000). Project Management product development time,” International Journal of Project
Body of Knowledge. Newtown Square, PA: PMI. Management, 19: 59–70.
CAPÍTULO

10
Programación del proyecto.
Retraso, compresión y redes de actividades

Contenido del capítulo


PERFIL DE PROYECTO ¿Qué tan diferentes son?
Dreamliner 787 de Boeing: problemas en su lanzamiento Actividades dummy
INTRODUCCIÓN Recorridos hacia adelante y hacia atrás en redes AOA
10.1 EL RETRASO EN LAS RELACIONES DE AOA versus AON
PRECEDENCIA 10.5 CONTROVERSIAS EN EL USO DE LAS REDES
Final a inicio Conclusiones
Final a final Resumen
Inicio a inicio Términos clave
Inicio a final Problemas resueltos
10.2 DIAGRAMAS DE GANTT Preguntas para discusión
Adición de recursos a los diagramas de Gantt Problemas
Incorporación de retrasos en los diagramas de Gantt Estudio de caso 10.1 Programación de proyectos en Blanque
  Cheque Construction (A)
GERENTES DE PROYECTOS EN LA PRÁCTICA
Estudio de caso 10.2 Programación de proyectos en Blanque
Mayor Julia Sweet, Ejército de Estados Unidos
  Cheque Construction (B)
10.3 COMPRESIÓN DE PROYECTOS Ejercicios con MS Project
Opciones para acelerar los proyectos Preguntas de ejemplo del examen para la certificación PMP®
Efectos en el presupuesto de comprimir el proyecto Proyecto integrado. Desarrollo del cronograma del proyecto
10.4 REDES ACTIVIDAD EN LA FLECHA Notas

Objetivos de aprendizaje
Al finalizar el capítulo, el estudiante estará en capacidad de:
1. Aplicar las relaciones de retrasos en las actividades del proyecto.
2. Construir y comprender los diagramas de Gantt.
3. Reconocer los medios alternativos para acelerar los proyectos, incluidas sus ventajas y desventajas.
4. Comprender las ventajas y desventajas en la decisión de comprimir las actividades del proyecto.
5. Desarrollar redes de actividades utilizando técnicas actividad en flecha (AOA).
6. Comprender las diferencias entre AON y AOA y reconocer las ventajas y desventajas de cada técnica.

330
Perfil de proyecto 331

CONCEPTOS BÁSICOS DE LOS FUNDAMENTOS PARA LA GERENCIA DE PROYECTOS


(PROJECT MANAGEMENT BODY OF KNOWLEDGE, PMBOK® GUIDE, 5A. EDICIÓN)
CUBIERTOS EN ESTE CAPÍTULO
1. finalDefinalición de actividades (PMBOK®, sección 6.1).
2. Secuenciación de actividades (PMBOK®, sección 6.2)
3. Adelanto y retraso de actividades (PMBOK®, sección 6.2.3).
4. Estimación de recursos para las actividades (PMBOK®, sección 6.3).
5. Estimación de las duraciones de las actividades (PMBoK, sección 6.4).
6. Desarrollo del cronograma (PMBOK®, sección 6.5).
7. Compresión del cronograma (PMBOK®, sección. 6.5.2.7).
8. Control del cronograma (PMBOK®, sección 6.6).

PERFIL DE PROYECTO

Dreamliner 787 de Boeing: problemas en su lanzamiento


Cuando Boeing anunció el desarrollo de su nuevo y más grande avión de alta tecnología, el 787 Dreamliner, pare-
cía que se habían tomado todas las decisiones correctas. Al centrarse en la construcción de un avión con el más bajo
consumo de combustible, en el uso de materiales más ligeros que influyeran en el peso total, en la disminución
del consumo de combustible en 20%, en la subcontratación del trabajo en una red global de proveedores y al ser
pioneros en nuevas técnicas de montaje, parecía que Boeing había tenido una visión clara con sus ojos fijados en
el futuro de la aviación comercial y había diseñado el equivalente a un jonrón: un nuevo avión que cumplía todos
los requisitos.
Los clientes de avión parecían estar de acuerdo. Cuando Boeing anunció el desarrollo del 787 y abrió su
libro de pedidos, rápidamente se convirtió en el avión más vendido en la historia: los pedidos por adelantado
para el avión ascendieron a 847 unidades. Con precios de lista que iban desde 161 millones de dólares hasta 205
millones de dólares por unidad, dependiendo del modelo, el Dreamliner fue valorado como fuente de ingresos a
largo plazo de miles de millones de dólares para la empresa. El avión se diseñó para vuelos de larga distancia y
tenía capacidad para 330 pasajeros. La mayoría de los analistas del sector manifestaron: con la introducción del
Dreamliner, el futuro nunca había parecido tan brillante para Boeing.

Peter Carey / Alamy

FIGURA 10.1  Dreamliner 787 de Boeing


(continúa)
332 Capítulo 10  •  Programación del proyecto. Retraso, compresión y redes de actividades

Pero cuando las primeras fechas de entrega incumplidas, aun en el 2012, cuatro años más tarde de lo programado y
el precio de las acciones fue golpeado en el mercado de valores, Boeing y sus aliados de la industria comenzaron a tratar
de desenmarañar un montón de problemas técnicos y de suministro en cadena que amenazaban no solo el buen nombre
de Boeing, sino la viabilidad del Dreamliner. Irónicamente apodado el “7-L-7” por “late (retraso)”, el proyecto fue víctima
de grandes sobrecostos y continuos incumplimientos del cronograma y se había tropezado recientemente con una preo-
cupante serie de fallas estructurales y eléctricas, que fueron alarmantes para las aerolíneas que esperaban la entrega de
sus aviones. Estos eventos se combinaron para poner a Boeing en el ojo del huracán, mientras trataba de hallar la manera
de corregir estos problemas y salvar tanto su reputación como la viabilidad de sus aviones de alto perfil.
El plazo para el desarrollo del Dreamliner contenía algunos hitos importantes en su camino a la comerciali-
zación, incluidos los siguientes:
• 2003—Boeing anunció oficialmente el desarrollo del “7E7”, su avión más moderno.
• 2004—Se recibieron los primeros pedidos para 55 de los aviones de All Nippon Airlines, con una fecha de en-
trega fijada para finales de 2008.
• 2005—El 7E7 fue renombrado oficialmente el 787 Dreamliner.
• Julio de 2007—El primer Dreamliner fue dado a conocer en una ceremonia de lanzamiento en la planta de en-
samblaje de Boeing en Everett, Washington.
• Octubre de 2007—Se anunció el primer retraso de seis meses. Los problemas identificados como causa de los
retrasos se orientaban a las entregas de los proveedores y a problemas con los tornillos utilizados para fijar los
componentes de los aviones. El director del programa, Mike Bair, fue reemplazado una semana más tarde.
• Noviembre de 2008—Boeing anunció el quinto retraso en el calendario, debido a continuos problemas de coor-
dinación con los proveedores, repetidos fracasos de los sujetadores y debido a los efectos de una huelga de
mecánicos. El primer vuelo fue aplazado hasta el segundo trimestre de 2009.
• Junio de 2009—Boeing anunció que el primer vuelo se posponía “debido a la necesidad de reforzar un área dentro de
la sección lateral del cuerpo de la aeronave.” Se retrasa aún más el primer vuelo de prueba hasta finales de 2009. Al
mismo tiempo, Boeing registraba un sobrecosto de 2,500 millones de dólares para los tres primeros 787 construidos.
• Diciembre 7 de 2009—Primer vuelo de prueba exitoso del 787.
• Julio de 2010—Boeing anunció que las desviaciones en el cronograma empujarían las primeras entregas hasta
el 2011, responsabilizando de la situación a una explosión en un motor en un banco de pruebas en la planta de
Rolls-Royce, aunque Rolls negó que sus motores fueran la causa del retraso en el cronograma.
• Agosto de 2010—Air India anunció una demanda contra Boeing pidiendo una indemnización de 1,000 millones
de dólares, alegando repetidos retrasos en las entregas de los veintisiete aviones 787 que habían ordenado.
• Noviembre 9 de 2010—Se presentó fuego durante un vuelo de prueba del Dreamliner 2, cerca de Laredo, Texas.
El fuego fue extinguido rápidamente y la causa fue atribuida a una falla en los sistemas eléctricos. Los aviones
se quedaron en tierra para extensas pruebas. Con ese percance técnico, se temía que la fecha de entrega de la
aeronave se aplazara hasta el 2012.
• Enero 19 de 2011—Boeing anunció un nuevo retraso en su programa de entregas del 787. El último retraso (y
séptimo oficial) llegó más de dos meses después de que se presentara fuego eléctrico en el Dreamliner 2. All
Nippon Airways, primer cliente del avión, fue informado de que la primera entrega de su orden de 55 aviones
podría esperarse para el tercer trimestre del 2011; aunque las expectativas eran altas la aerolínea podría no re-
cibir ningún avión hasta principios del 2012, con casi 3 ½ años de retraso.
No hay duda de que el Dreamliner es un avión de última generación. El 787 fue el primer avión comercial que
hizo un amplio uso de materiales compuestos en lugar de aluminio, tanto en la estructura como en el recubrimiento
externo. De hecho, cada 787 contiene aproximadamente 35 toneladas de plástico reforzado con fibra de carbono.
Los materiales compuestos de fibra de carbono tienen una relación resistencia/peso más alta que los materiales tra-
dicionales utilizados en las aeronaves, como el aluminio y el acero, lo cual ayuda a que el 787 sea una aeronave más
liviana. Estos materiales compuestos se utilizan en el fuselaje, alas, cola, puertas y en las secciones interiores; el alu-
minio se emplea en los bordes de las alas y de la cola. El fuselaje se arma como una sola pieza de secciones cilíndricas
compuestas, en lugar de las varias hojas de aluminio y los aproximadamente 50,000 elementos de fijación utilizados
en las aeronaves existentes. Debido su peso liviano y a la nueva generación de motores de reacción utilizados el
encendido, el Dreamliner tiene un menor costo de operación, lo que lo hace especialmente atractivo para las compa-
ñías aéreas. Además, la cadena de suministro global establecida por Boeing para la fabricación de los componentes
para el avión se leía como un quién es quién en la lista de expertos internacionales. Las empresas de Suecia, Japón,
Corea del Sur, Francia, Inglaterra, Italia e India contrataron con Boeing para suministrar partes de la aeronave, que se
enviaban a dos plantas de ensamblaje en Estados Unidos (una en Washington y otra prevista en Carolina del Sur) para
el montaje final y las pruebas antes de ser enviados a los clientes. En resumen, el 787 es un producto muy complicado,
tanto en su composición física como en la intrincada cadena de suministros creada por Boeing para producirlo.
Como se puede apreciar, el programa 787 es muy complicado. De hecho, en el desarrollo del Dreamliner, sim-
plemente Boeing trató de hacer demasiadas cosas a la vez. Los críticos han argumentado que la creación de un avión
10.1  Retraso en las relaciones de precedencia 333

de nueva generación, con materiales compuestos, mientras se utiliza una cadena de suministro totalmente nueva,
manteniendo altos estándares de control de calidad y depurando una larga lista de problemas inesperados, simple-
mente va más allá de la capacidad de cualquier organización, sin importar que tan ágil pueda ser en la gerencia de
proyectos. Los proveedores han luchado por cumplir las especificaciones técnicas más exigentes de Boeing, con ver-
siones de prueba anticipadas para la sección de la nariz, por ejemplo, pero han fallado en las pruebas realizadas por
Boeing, quien al final consideraba las piezas inaceptables. Boeing ha asumido un gran riesgo con el Dreamliner. En su
intento por mantener bajos los costos, la compañía decidió tercerizar muchos aspectos del proyecto, dependientes de
una cadena de suministro muy grande: 43 proveedores “de primer nivel” en tres continentes. Es la primera vez que
Boeing externaliza las partes más críticas del avión como las alas y el fuselaje. Alrededor del 80% del Dreamliner lo
fabrican los proveedores externos, frente al 51% de los demás aviones de Boeing.
Jim McNerney, presidente ejecutivo de Boeing, admite que el desarrollo de los aviones 787, con amplia ter-
cerización, era “demasiado ambicioso”: “A pesar de que participar en un juego de innovación de esta magnitud
nunca es fácil, debemos ser cuidadosos con los adelantos que hemos logrado y tal vez nunca volvamos a ver. Así
que estamos ajustando nuestro enfoque para programas futuros “. McNerney continuó: “ Estamos decepcionados
por los cambios en el cronograma, pero independientemente de las dificultades que estamos experimentando al
llevar adelante este reto de innovación del producto, seguimos confiando en el diseño de los 787.”1

INTRODUCCIÓN
En el capítulo anterior se presentó el desafío de la programación de proyectos, su terminología importante, la red de
actividades, la estimación de la duración de las actividades y la construcción de la ruta crítica. En este capítulo, se apli-
carán estos conceptos con el final de explorar otras técnicas de programación, incluidos la utilización de las relaciones
de retraso entre las actividades del proyecto, los diagramas de Gantt, el análisis de compresión de las actividades del
proyecto, y comparar el uso de las técnicas actividad en la flecha (activity on arrow: AOA) versus actividad en el nodo
( activity on node: AON) para construir redes. En el capítulo anterior, se utilizó la analogía del rompecabezas en el
que el acto de desarrollar la programación del proyecto requiere una serie de pasos hasta llegar a su conclusión. Con
estos conceptos básicos estudiados, estamos listos para considerar algunos elementos adicionales importantes en la
programación de proyectos, todos ellos destinados a la construcción de un plan de proyecto significativo.

10.1  RETRASO EN LAS RELACIONES DE PRECEDENCIA


El término retraso se refiere a la relación lógica entre el inicio y el final de una actividad y el inicio y el final
de otra. En la práctica, las retrasos se incorporan a veces en las redes para permitir una mayor flexibilidad
en la construcción de la red. Supongamos que queremos acelerar un cronograma y determinamos que no
era necesario que una tarea predecesora estuviera completamente terminada antes de comenzar la sucesora.
Determinamos que una vez que la primera actividad se ha iniciado, un retraso de dos días es todo lo que se
necesita antes de comenzar la siguiente actividad. Las retrasos demuestran esta relación entre las tareas en
cuestión. Generalmente, se presentan según cuatro relaciones lógicas de precedencia entre las tareas:
1. Final a inicio
2. Final a final
3. Inicio a inicio
4. Inicio a final

Final a inicio
El tipo más común de la secuencia lógica entre tareas se denomina relación final a inicio. Supongamos tres
tareas vinculadas en una ruta en serie, similar a la mostrada en la figura 10.2. La actividad C no puede
comenzar hasta tanto el proyecto reciba una entrega a un proveedor externo que está previsto que ocurra
cuatro días después de la finalización de la actividad B. La figura 10.2 representa visualmente el retraso de 4
días entre la finalización de la actividad B y el inicio de actividad C.
Observe en la figura 10.2 que la fecha de inicio temprano (ES) para la actividad C se ha retrasado en
cuatro días. Un retraso final a inicio suele aparecer en la línea que une los nodos y debe sumarse en los cál-
culos del paso hacia adelante y restarse en los cálculos del paso hacia trás. Un retraso final a inicio no es lo
mismo que una holgura adicional para las actividades y no debe tratarse de esta manera.
334 Capítulo 10  •  Programación del proyecto. Retraso, compresión y redes de actividades

0 A 6 6 B 11 15 C 22
Especificaciones Evaluación Retraso 4
Prototipo
del diseño del diseño
6 5 7

FIGURA 10.2  Red que incorpora un retraso final a inicio de cuatro días

30 R 36
Cableado
6

31 S 33 33 T 36 36 U 42
Plomería HVAC Construcción interna
2 3 6

FIGURA 10.3  Relación final a final

Final a final
Las relaciones final a final establecen que dos actividades vinculadas compartan una fecha de finalización
similar. El vínculo entre las actividades R y T en la figura 10.3 muestra esta relación. Aunque la actividad R
empieza antes que actividad T, comparten la misma fecha de finalización.
En algunas situaciones, puede ser apropiado que dos o más de las actividades deban concluir al mismo
tiempo. Si, por ejemplo, un contratista de construcción de un complejo de oficinas no puede iniciar la cons-
trucción de la pared interna hasta que todo el cableado, plomería, calefacción, ventilación y aire acondi-
cionado (heating, ventilation and air conditioning: HVAC) se haya instalado, se puede incluir un retraso
para que la finalización de todas las actividades predecesoras se produzcan al mismo tiempo. La figura 10.4
muestra un ejemplo de un retraso en una relación final a final, en el que las actividades predecesoras R, S y T
se deben finalizar para permitir que la actividad pueda comenzar inmediatamente después. El retraso de tres
días entre las actividades R y T permite que las tareas puedan finalizar en el mismo punto.

Inicio a inicio
A menudo dos o más actividades pueden comenzar simultáneamente o se puede presentar una retraso entre el inicio
de una actividad después de que una actividad anterior ha comenzado. Una empresa podría comenzar la adquisición
de materiales, mientras los planos están finalizándose. Se ha argumentado que el retraso en las relaciones de inicio a
inicio es redundante en una red normal de actividades en donde las actividades paralelas o simultáneas se especifican
según lo acostumbrado. En la figura 9.15, vemos que la actividad C, un punto de divergencia en una red, y sus acti-
vidades (tareas sucesoras D y G) son, en efecto, operaciones con la lógica inicio a inicio. La sutil diferencia entre este
ejemplo y una especificación inicio a inicio es que en la figura 9.15 no se requiere que ambas actividades comiencen
simultáneamente; en una relación inicio a inicio, la lógica debe mantenerse a través de la red tanto en el paso hacia
adelante como en el paso hacia atrás y puede, por tanto, alterar la cantidad de holgura disponible para la actividad G

30 R 36
Retraso 3
Cableado
6

34 S 36 36 T 39 39 U 45
Plomería HVAC Construcción interna
2 3 6

FIGURA 10.4  Relación final a final con un retraso incorporado


10.1  Retraso en las relaciones de precedencia 335

El retraso inicio a inicio se utiliza cada vez más como un medio para acelerar los proyectos (anali-
zaremos esto en detalle más adelante en este capítulo) a través de un proceso conocido como ejecución
rápida (fast-tracking). En lugar de confiar en la relación más común final a inicio entre las actividades, las
organizaciones tratan de comprimir sus cronogramas, adoptando la programación de tareas en paralelo, lo
cual caracteriza la relación inicio a inicio. Por ejemplo, pueden solaparse las actividades en una variedad de
configuraciones. La corrección del manuscrito de un libro no tiene que esperar hasta que se complete todo
el documento; un editor de textos puede comenzar a trabajar con el capítulo uno, mientras el autor escribe
los borradores. Además, en proyectos de desarrollo de software, es común empezar a codificar diferentes
secuencias mientras el diseño general de las funciones del software todavía está realizándose. No siempre
es posible reconfigurar relaciones predecesora/sucesora en una programación inicio a inicio, pero cuando
puede hacerse, el resultado es un cronograma más comprimido y de rápida ejecución.
La figura 10.5 muestra un ejemplo de una red inicio a inicio, en la cual se incorpora un retraso de tres
días, para la relación entre las actividades de R, S y T.

30 R 36
Cableado
6

3 días 33 T 36 36 U 42
HVAC Construcción interna
3 6

31 S 33
Plomería
2

FIGURA 10.5  Red con relaciones inicio a inicio

Inicio a final
Tal vez el tipo de relación de retraso menos común se produce cuando el final de una sucesora depende del
inicio de una predecesora (inicio a final). Un ejemplo de tal situación es la construcción en una zona con
mal drenaje de las aguas subterráneas. La figura 10.6 muestra esta relación. La finalización de la actividad
de vertido de hormigón, Y, depende del inicio del drenaje de agua del sitio, W. A pesar de que se presenta
raramente, la opción inicio a final no puede rechazarse automáticamente. Al igual que con los otros tipos de
relaciones predecesora/sucesora, debemos examinar la lógica de nuestra red para determinar la manera más
adecuada de vincular las actividades de la red entre sí.

20 W 26

6
3 días

20 Y 23 23 Z 29

3 6

18 X 20

FIGURA 10.6  Red de relación inicio a final


336 Capítulo 10  •  Programación del proyecto. Retraso, compresión y redes de actividades

10.2  DIAGRAMAS DE GANTT


Desarrollados por Harvey Gantt en 1917, los diagramas de Gantt son una herramienta muy útil para la creación de
una red de proyectos. Los diagramas de Gantt establecen una red de base temporal que vincula las actividades del
proyecto al cronograma de línea de base del proyecto en referencia. También pueden utilizarse como una herra-
mienta de seguimiento de proyectos para evaluar la diferencia entre el rendimiento previsto y el real. Un ejemplo
de un diagrama de Gantt básico se muestra en la pantalla 10.1. Las actividades se ordenaron de principio a final
a lo largo de una columna en el lado izquierdo del diagrama con sus duraciones ES y EF dibujadas horizontal-
mente. Las fechas ES y EF corresponden al calendario línea de base trazado en la parte superior de la pantalla. Los
diagramas de Gantt representan uno de los primeros intentos por desarrollar un diagrama de red que especifican
el orden de las actividades del proyecto, según las fechas calendario de referencia, lo cual le permite al equipo del
proyecto centrarse en el estado del proyecto, en cualquier fecha durante su desarrollo.
Algunos de los beneficios de los diagramas de Gantt son: (1) muy fáciles de leer y comprender; (2) identifican
la red del proyecto junto a la línea base del cronograma; (3) permiten la actualización y el control de proyectos; (4)
su utilidad para identificar las necesidades de recursos y la asignación de recursos a las tareas; (5) fáciles de crear.
1. Comprensión—Los diagramas de Gantt funcionan como un diagrama de precedencia del proyecto
global porque vincula todas las actividades. El diagrama de Gantt se presenta a lo largo de una línea
de tiempo horizontal, de manera que los usuarios pueden identificar rápidamente la fecha actual y ver
qué actividades deberían haberse completado, cuáles deberían estar en marcha y cuáles están previstas
para el futuro. Además, debido a que estas actividades están vinculadas en la red, pueden identificarse
actividades sucesoras y predecesoras.
2. Red de línea base del cronograma—El diagrama de Gantt vincula información en tiempo real, por lo que
todas las actividades del proyecto tienen adjuntas sus ES, EF, LS, LF y holgura. También tienen las fechas en que
se espera deben haber comenzado y finalizado, y se ubican en relación con el cronograma general del proyecto.
3. Actualización y control—Los diagramas de Gantt les permiten a los equipos de proyectos acceder
fácilmente a información del proyecto, actividad por actividad. Supongamos, por ejemplo, que una
actividad de proyecto se retrasa cuatro días. Es posible que en un gráfico de Gantt pueda actualizarse
la red global calculando el nuevo tiempo y ver el estado del proyecto actualizado. Muchas empresas
utilizan gráficos de Gantt para actualizar continuamente el estado de las actividades en curso. Los
diagramas de Gantt permiten a los gerentes evaluar la situación de las actividades en curso, por lo que
es posible comenzar la planeación de medidas correctivas en los casos en que la finalización de una
actividad se retrase con respecto a lo planeado.
4. Identificación de las necesidades de recursos—Al colocar todo el proyecto en una línea base del crono-
grama, se le permite al equipo del proyecto iniciar la programación de los recursos mucho antes de que
se necesiten, lo cual facilita la planeación de los recursos.
5. Fácil de crear—Los diagramas de Gantt, por ser intuitivos, son unos de los elementos de programación
más fáciles de desarrollar en los equipos de proyecto. La clave es tener una comprensión clara de la
longitud de las actividades (su duración), las relaciones de precedencia del proyecto, la fecha en que se
espera que el proyecto pueda comenzar, y cualquier otra información necesaria para construir la línea
base del cronograma (por ejemplo, si se necesita tiempo extra).

PANTALLA 10.1  Ejemplo de un diagrama de Gantt utilizando Microsoft Project 2010 “[Observe que los días de
final de semana no se contabilizan en el tiempo de duración de las tareas].”
10.2  Diagramas de Gantt 337

PANTALLA 10.2  Diagrama de Gantt para el proyecto Delta

La pantalla 10.2 utiliza la información relacionada con el ejemplo del proyecto Delta del capítulo anterior para
construir un diagrama de Gantt utilizando MS Project 2010 (véase pantalla 9.1). La duración y las fechas de
inicio y de final de cada actividad se representan en la barra horizontal trazada de izquierda a derecha a lo largo
de la red. El gráfico muestra las actividades en orden de arriba abajo. El “flujo” general del diagrama se mueve
desde la esquina superior izquierda hasta la parte inferior derecha. La línea de base del cronograma se muestra
horizontalmente en la parte superior de la pantalla. Cada actividad vinculada indica la lógica de prioridad a lo
largo de la red. Todas las actividades se registran basándose en sus fechas de inicio temprano (ES). Podemos
ajustar la red cambiando la lógica subyacente a la secuencia de las tareas. Por ejemplo, las actividades que se
pueden ajustar sobre la base de las fechas de inicio tardío (LS) o alguna otra convención.
A medida que avanzamos en el desarrollo del diagrama de Gantt para el proyecto Delta (véase la pan-
talla 10.2), es posible determinar información adicional de la red. En primer lugar, la holgura de la actividad
se representa con las flechas largas que vinculan esta actividad con las sucesoras. Por ejemplo, la actividad E,
con 60 días (12 semanas) de holgura, se representa con la barra sólida que muestra la duración de la actividad
y la flecha larga que conecta la actividad con la tarea sucesora en la secuencia de la red (actividad H). Por
último, una red generada por software para los diagramas de Gantt también calculará automáticamente la
ruta crítica, identificando las actividades críticas, al desarrollar el diagrama. La pantalla 10.3 muestra la ruta
crítica, resaltándola en la línea base del cronograma.

PANTALLA 10.3  Diagrama de Gantt para el proyecto Delta, en el cual se resalta la ruta critica

Adición de recursos a los diagramas de Gantt


Agregar recursos a los diagramas de Gantt es muy sencillo. Consiste en suministrar el nombre o nom-
bres de los recursos que se asignan para realizar las distintas actividades. La pantalla 10.4 es una salida de
MS Project que muestra la inclusión de un conjunto de recursos del equipo del proyecto asignados a las
338 Capítulo 10  •  Programación del proyecto. Retraso, compresión y redes de actividades

PANTALLA 10.4  Diagrama de Gantt con recursos especificados

distintas tareas. También es posible asignar el porcentaje de tiempo que cada recurso le asigna a cada acti-
vidad. Esta característica es importante porque, como veremos en capítulos posteriores, constituye la base
para el seguimiento y control del proyecto, sobre todo en control de costos.
La pantalla 10.4 muestra seis miembros del equipo de proyecto asignados a las seis funciones de otro
proyecto de ejemplo. Recuerde que el diagrama de Gantt se basa en la duración de las actividades calcu-
ladas con una asignación total de los recursos. Sin embargo, supongamos que los recursos pudieron asig-
narse a las tareas en una cifra menor (por ejemplo, 50%), ya que no tenemos suficientes recursos disponi-
bles cuando se requieren. El resultado será el aumento de la cantidad de tiempo necesario para completar
las actividades del proyecto. El reto de la gerencia de recursos, puesto que se aplica a la programación de la
red, es importante y se detalla en el capítulo 12.

Incorporación de retrasos en los diagramas de Gantt


Los diagramas de Gantt se pueden ajustar para mostrar retrasos, cuando sea necesario, y crear una ima-
gen visual de la programación del proyecto. La pantalla 10.5 es un diagrama de Gantt con algunas relacio-
nes de retraso especificadas. En esta red, las actividades C (revisar especificaciones) y D (comprar partes)
están vinculadas con una relación final a final, así que las dos deben terminar en la misma fecha. La activi-
dad E es una sucesora de la actividad D, y las dos últimas actividades, E y F, se vinculan con una relación
de inicio a inicio. Similarmente a la construcción de retrasos en una red, la clave está en el desarrollo de
una lógica razonable para la relación entre las tareas. Una vez se incluyen los diversos tipos de retrasos, el
proceso real de identificación de la ruta crítica de la red y de otra información pertinente es muy sencillo.

PANTALLA 10.5  Diagrama de Gantt con relaciones de retraso


10.2  Diagramas de Gantt 339

RECUADRO 10.1

GERENTES DE PROYECTOS EN LA PRÁCTICA


Mayor Julia Sweet, Ejército de Estados Unidos
La mayor Julia Sweet trabaja en un entorno donde los proyectos son una forma de vida, incluso en ocasiones
en condiciones peligrosas. Sweet se desempeña como gerente de programas en una brigada de ingeniería
situada en el centro de Afganistán. La brigada es responsable del diseño de todos los proyectos de construcción
en el Regional Comand South (RC-S) y el Regional Comand East (RC-E). Desde 2008, la sección de gerencia
del diseño ha diseñado y obtenido la aprobación de más de 500 proyectos de construcción por un valor total
superior a 1,600 millones de dólares. Los proyectos más comunes incluyen plantas de tratamiento de aguas resi-
duales, contenedores de vida/carpas, zonas de aterrizaje de helicópteros, perímetros y edificios.
Sweet se ha interesado en los proyectos y en la gerencia de proyectos a lo largo de varios años de trabajo
en entornos muy diferentes. Después de su graduación de la universidad con un título en química, primero trabajó
como ingeniero del ejército en Alemania antes de pasar a la reserva y permanecer 12 años en diversos puestos de
gerencia de proyectos en la industria farmacéutica, incluidos cinco años con Eli Lilly, Inc. A finales de su carrera,
ella se abrió camino hasta llegar a ser líder de un equipo clínico de investigación y desarrollo (I+D), donde participó
en numerosos proyectos de desarrollo de productos. Después de ser llamada al servicio activo, Sweet ha pasado
los últimos quince años, primero como planificadora máster de base en un campamento en Bosnia y ahora como
gerente de programa en Afganistán, gerenciando cientos de proyectos de millones de dólares.
Con la fuerza del Ejército creciendo en Afganistán, las responsabilidades de Sweet se han incrementado
enormemente. Para atender a las nuevas tropas, sus más recientes grupos de proyectos se han involucrado en
la protección de la fuerza y la ampliación del perímetro para todas las nuevas bases de operaciones de avanzada
(forward operating bases: FOB) y puestos avanzados de combate ( combat outposts: COP). La prioridad en de
estos sitios es la fuerza de protección (es decir, torres de vigilancia, posiciones defensivas y puntos de control de
acceso). Con el final de proteger a los trabajadores y a las tropas de avanzada, el perímetro debe ser seguro. El
aumento de tropas también ha presionado a las brigadas de ingenieros del Ejército a trabajar en otros frentes.
Sweet y sus colegas están desarrollando áreas de vida o trabajo para los miles de soldados que llegan. Como
Sweet indica: “No sólo existe el reto de determinar cuántos soldados, qué tipo de unidades, la cantidad de espa-
cio para camas se necesita, sino también que los proyectos deben diseñarse, aprobarse, financiarse y construirse
antes de su llegada. También está el reto de la adquisición de bienes inmuebles y de garantizar que la ubicación
sea suficientemente segura para pagarles a los contratistas locales por realizar el trabajo.”

FIGURA 10.7  Mayor Julia Sweet, Ejército de Estados Unidos


(continúa)
340 Capítulo 10  •  Programación del proyecto. Retraso, compresión y redes de actividades

¿Cómo gestionar eficazmente el tamaño y la escala de los proyectos necesarios, mientras se trabaja
en una zona de combate? Los desafíos y la presión nunca paran. Por ejemplo, estos proyectos requieren una
serie de decisiones sobre seguridad, logística, finalización y velocidad a la que la construcción debe ejecutarse.
Sweet anota:
El enemigo también tiene un voto en la situación, por lo que no es raro llevar un proyecto hasta su
punto de ejecución y posteriormente tener que cambiar la ubicación o mantener todo el proyecto en
espera. Los convoyes con los materiales de construcción son constantemente atacados y los materiales
son robados o volados y nunca llegan al lugar de trabajo. Muchas veces, los materiales de construcción
tienen que transportarse por aire desde sitios muy remotos. Millones de dólares en materiales se per-
dieron el año pasado, y la mayoría de los elementos son muy difíciles de reemplazar. El financiamiento
y la velocidad son también claves tanto como el flujo que se mantiene en aumento, y simplemente
tienes que hacer que suceda para asegurar el éxito de la unidad en el campo de batalla. A veces parece
que todo se da por sentado por todos aquí, debido a que si los soldados tienen un lugar para trabajar,
comer y dormir están en mayor capacidad para concentrarse en la tarea que deben realizar.
Los ingenieros trabajan con los horarios de entrega rápidos y están obligados a mantener un estrecho control
de los costos y, aún más, tienen que encontrar formas innovadoras para obtener una gran cantidad de proyec-
tos finalizados, y siempre hay una larga lista de otros proyectos “claves” a la espera de empezarse.
El trabajo de Sweet es de alta presión, pero muy gratificante. “Hacer este trabajo adecuadamente salva
vidas”, dice. “Aquí todo el mundo reconoce que se trata de mucho más que ‘construcción’. Nuestro trabajo,
literalmente, aumenta la probabilidad de éxito del ejército en el campo de batalla. Me encanta la autoridad
que el Ejército les da a los oficiales como yo para realizar su trabajo. Como gerente del programa, yo soy
responsable del éxito general de este de principio a final. Aquí, el objetivo es mantener un sentido de unidad
y cohesión en proyectos en todos los ámbitos, especialmente en función de las necesidades operativas, las
especificaciones de diseño y el costo total.”

10.3  COMPRESIÓN DE PROYECTOS


A veces se requiere acelerar el proyecto, agilizando su desarrollo para lograr una fecha de terminación antes
de lo previsto. El proceso de aceleración de un proyecto se conoce como compresión. Comprimir un pro-
yecto se relaciona directamente con el compromiso de los recursos. Cuanto más recursos estemos dispuestos
a gastar, más rápido podemos llevar el proyecto hasta su culminación. Puede haber buenas razones para
comprimir un proyecto, como:2
1. El cronograma inicial puede estar demasiado ajustado. En esta circunstancia, es posible programar el
proyecto con una serie de actividades con duraciones tan condensadas, lo cual hace inevitable un pro-
ceso de compresión.
2. El mercado está cambiando y se requiere satisfacer, con el proyecto, la demanda lo antes posible. Por
ejemplo, supongamos que su compañía descubrió que el proyecto secreto en el que estaba trabajando,
también está desarrollándolo una empresa rival. Debido a que la participación de mercado y los benefi-
cios estratégicos llegarán a la primera empresa en introducir el producto, usted tiene un gran incentivo
para hacer lo necesario a final de asegurarse de que sea el primero en comercializar el producto.
3. El proyecto se ha retrasado considerablemente. Es posible determinar que la única manera de recupe-
rar los hitos originales es comprimir todas las actividades restantes.
4. La situación contractual provee un incentivo aún mayor para evitar el retraso en el cronograma. La
empresa puede darse cuenta de que es más costoso pagar más penalidades por la de entrega tardía en
comparación con el costo de comprimir las actividades.

Opciones para acelerar los proyectos


Se cuenta con varios métodos para acelerar o comprimir proyectos. Un factor determinante del método por
utilizar es “qué tan limitados son los recursos” del proyecto, es decir, si hay más recursos presupuestarios o
extras disponibles para asignarle al proyecto. La cuestión es si el gerente del proyecto (y la organización) está
dispuesto a destinar recursos adicionales para el proyecto, la principal preocupación que pesa en sus decisio-
nes. Entre los principales métodos para acelerar un proyecto se encuentran los siguientes:
10.3  Compresión de proyectos 341

1. Mejorar la productividad de los recursos existentes del proyecto—La mejora de la productividad de los
recursos existentes del proyecto significa hallar formas más eficientes de hacer el trabajo con el equipo de
personal y otros recursos materiales actualmente disponibles. Algunas maneras de lograr estos objetivos
incluyen mejorar la planeación y la organización del proyecto, eliminando barreras a la productividad
como la interferencia burocrática excesiva o las limitaciones físicas, y mejorar la motivación y la producti-
vidad de los miembros del equipo del proyecto. Siempre se deben hacer esfuerzos para encontrar formas
de mejorar la productividad de los recursos del proyecto, sin embargo, estos esfuerzos casi siempre se
logran mejor durante el tiempo de inactividad entre proyectos y no durante estos.
2. Cambiar el método de trabajo empleado para la actividad, por lo general mediante cambios de tec-
nología y tipos de recursos empleados—Otra opción para acelerar las actividades del proyecto es cam-
biar los métodos de trabajo empleados para ejecutar la actividad, por lo general mediante cambios de
tecnología y de los tipos de recursos empleados. Por ejemplo, muchas empresas optan por técnicas de
programación de proyectos basadas en computador, y así ahorran un tiempo considerable en este pro-
ceso. Cambiar los métodos de trabajo también puede incluir la asignación de personal de alto nivel, o la
contratación de personal contratado o subcontratista para realizar las funciones específicas del proyecto.
3. Comprometer la calidad y / o reducir el alcance del proyecto—Estas dos opciones se refieren a decisiones
conscientes tomadas dentro de la organización que sacrificar algunas de las especificaciones originales del
proyecto, debido a una gran presión o a la necesidad de acelerar la terminación del proyecto. Comprometer
la calidad puede implicar decisiones relativamente simples como el uso de materiales más baratos o realizar
menos controles en la supervisión, a medida que el proyecto avanza. Rara vez, estas decisiones de sacrificar
la calidad son beneficiosas para el proyecto; de hecho, la decisión por lo general implica tratar de limitar o
controlar el daño que podría potencialmente ocurrir. En algunos casos, esto es incluso imposible de considerar
siquiera como una opción; las empresas de construcción, por ejemplo, tienen la seguridad (y, por tanto, la
calidad) como una de sus mayores preocupaciones y no considerarían deliberadamente, reducir la calidad.
La reducción del alcance del proyecto, por el contrario, es una respuesta más común a la presión
crítica de la organización para entregar un proyecto, sobre todo si se han experimentado retrasos o si los
beneficios de ser el primero en comercializar un producto es un factor determinante para el proyecto. Por
ejemplo, supongamos que un fabricante de televisión de Corea del Sur (Samsung) trabaja para diseñar un
nuevo producto que ofrece una visualización en 3D, que estaría a la vanguardia en sonido, conectividad a
internet y otras características de última generación. En medio del desarrollo, la compañía tiene conoci-
miento de que un competidor directo libera su nuevo televisor con un conjunto más modesto de caracterís-
ticas durante la temporada de compras de Navidad. Samsung podría tener la tentación de limitar el trabajo
de su modelo a los avances que en la actualidad se han completado, dejar las otras mejoras para un modelo
posterior y entregar su televisión con este alcance reducido, a final de mantener su cuota de mercado.
La decisión de limitar el alcance del proyecto no debe tomarse a la ligera; en muchos casos, puede
tener un impacto negativo limitado sobre la empresa, pues ésta siempre tiene que priorizar y diferen-
ciar entre el “debe tener” de las características del proyecto y otros aspectos que pueden no resultar
claves para los objetivos del proyecto. Muchos proyectos se han introducido con éxito con alcance
reducido porque la organización analizó estas reducciones de manera sistemática, revisando la EDT y
el cronograma del proyecto e implementando las modificaciones necesarias. Analizar cuidadosamente
la reducción del alcance de una manera proactiva puede minimizar los efectos negativos sobre el pro-
yecto final entregado.
4. Ejecución rápida del proyecto—La ejecución rápida de un proyecto se refiere a maneras de reorganizar la
programación del proyecto, a final de acelerar las actividades de la ruta crítica, como utilizar relaciones de
secuencia en paralelo (simultáneamente). En algunos casos, las oportunidades para acelerar el proyecto
requerirá la creatividad del equipo de proyecto. Por ejemplo, en un proyecto de construcción sencillo,
puede comenzarse el vertido de la base de hormigón, mientras el trabajo de diseño de interiores final o
de los planos más detallados aún está completándose. Es decir, el diseño de los gabinetes o la colocación
de puertas y ventanas de la casa no se afectará por la decisión de empezar a trabajar en la fundición, y el
efecto será acortar la duración del proyecto. En el capítulo 9, hablamos de opciones para reducir la ruta
crítica, la ejecución rápida puede emplear algunos de esos métodos, así como otros enfoques, incluidos:
a. Acortar las actividades críticas más largas—Identificar las actividades claves con las duraciones
más largas y reducirlas en un determinado porcentaje. Acortar las actividades normalmente ofrece
mayor oportunidad de influir en la duración de la totalidad del proyecto, sin incurrir en graves ries-
gos adicionales.
342 Capítulo 10  •  Programación del proyecto. Retraso, compresión y redes de actividades

b. Superponer parcialmente las actividades—Iniciar la tarea sucesora antes que de su predecesora se


haya completado. Podemos utilizar “desfases negativos” entre las actividades para reprogramar
nuestras actividades claves y permitir que una tarea se superponga a otra. Por ejemplo, supongamos
que tenemos dos actividades en secuencia: (1) codificar las funciones del programa y (2) depurar el
código. En muchos casos, puede comenzar la depuración del código antes de que el programador
haya completado totalmente su asignación. Podríamos indicar, por ejemplo, que la actividad de
depuración tiene un desfase negativo de dos semanas para permitir que el depurador comience su
tarea dos semanas antes del final previsto para la actividad de programación.
c. Emplear relaciones de retraso de inicio a inicio—Relaciones tradicionales entre las tareas predecesoras/
sucesoras se caracterizan por relaciones de final a inicio, lo cual sugiere que la sucesora solo puede
comenzar cuando la predecesora esté completamente terminada. En las relaciones de inicio a inicio, el
supuesto es que ambas actividades pueden llevarse a cabo al mismo tiempo; por ejemplo, en lugar de
esperar a que la oficina de planeación, curaduría o su equivalente le expida la aprobación de los permi-
sos de construcción, un contratista local puede comenzar a limpiar el sitio para la nueva construcción o
contactar con otros departamentos de la administración pública para iniciar los trámites de los permi-
sos para los arreglos viales y de alcantarillado. No todo conjunto de actividades puede redefinirse con
una relación final a inicio o una de inicio a inicio, pero a menudo se presentan oportunidades dentro de
la programación del proyecto en donde es posible emplear esta técnica de ejecución rápida.
5. Utilizar horas extras—Una respuesta común a la decisión de acelerar un proyecto es hacer que los
miembros del equipo trabajen más tiempo, es decir, horas extras. Por un lado, la decisión es atractiva:
si nuestros trabajadores dedican 40 horas a la semana al proyecto, al adicionar otras 10 horas de tiempo
extra aumentamos la productividad en 20%. Sin embargo, se deben revisar las regulaciones de trabajo
extra para los empleados, y en algunos casos se pueden plantear acuerdos con los empleados. Por tanto,
el las horas extras parecen a primera vista una opción por recomendar.
La decisión de recurrir al tiempo extra, sin embargo, tiene algunos inconvenientes que deben
considerarse. El primero es el costo: si se tienen trabajadores por horas, las horas extras pueden con-
vertirse rápidamente en prohibitivamente costosas. El resultado sería la afectación del presupuesto
del proyecto, con el final de ganar tiempo (una parte de lo que se conoce como negociaciones “dólar
- días”). Otro problema con las horas extras son los posibles efectos de la productividad de los miem-
bros del equipo sobre el proyecto,. El trabajo de Ken Cooper ofrece algunos puntos que los gerentes
de proyecto deben considerar cuando se ven tentados a acelerar sus proyectos, a través de la utiliza-
ción de las horas extras. La figura 10.8 muestra los resultados de sus investigaciones que examinan los
efectos de las horas extras en los miembros del equipo del proyecto para dos clases de trabajadores:
los ingenieros y el personal de producción. Al considerar la productividad y los reprocesos (tener que
corregir el trabajo hecho incorrectamente la primera vez), el efecto de las horas extras es preocupante:
con solo cuatro horas extras trabajadas por semana, el proyecto puede esperar recibir menos de dos

Ingeniería
Resultado real generado por hora extra

Producción
3

0
4 8 12

−1 Horas extras

FIGURA 10.8  Resultado real obtenido con diferentes niveles de horas extras sostenidas
10.3  Compresión de proyectos 343

horas de productividad real tanto de los ingenieros como del personal de producción. Al utilizar más
horas extras, el problema se agrava. En efecto, con 12 horas de tiempo extra semanal sostenido, el
efecto neto es insignificante para el personal de ingeniería y de hecho pasa a ser negativo para los recur-
sos de producción. Entonces, cuando se requiere trabajar horas extras, con la esperanza de acelerar el
cronograma del proyecto a menudo se tiene el efecto real de aumentar la fatiga inducida, incrementar
nuestro presupuesto, mientras se obtiene casi ninguna productividad adicional.
6. Agregar recursos al equipo del proyecto—Las duraciones previstas para las actividades se basan en el
uso de un número determinado de personas para llevar a cabo la tarea; sin embargo, cuando se dispone
de recursos adicionales, se tiene el efecto neto de reducir la cantidad de tiempo para completar la tarea.
Por ejemplo, supongamos que nos asignaron originalmente un programador para completar una ope-
ración de codificación específica y se determinó que la tarea podría tomar 40 horas. Ahora, decidimos
acortar esa tarea mediante la adición de dos programadores más. ¿Cuál es el nuevo tiempo esperado
para completar la actividad? Sin duda, nos anticipamos a que es inferior a la duración original de 40
horas, pero cuánto menos no siempre es claro, ya que el resultado puede no ser una función lineal
simple (por ejemplo, 40/3 = 13,33 horas). Otras variables pueden afectar el tiempo de terminación
(por ejemplo, retrasos en la comunicación o dificultad en la coordinación de los tres programadores).
En general, la adición de recursos a las actividades puede conducir a una reducción significativa en la
duración esperada de la actividad de programación.
Al igual que con las horas extras, tenemos que considerar cuidadosamente el efecto de la adi-
ción de recursos a un proyecto, especialmente cuando algunas de las actividades ya están en marcha.
Por ejemplo, al agregar personas a las actividades, tenemos que considerar los efectos de la “curva de
aprendizaje.” Supongamos que nuestro programador ya ha comenzado a trabajar en la tarea cuando
decidimos agregar dos recursos adicionales para ayudarle. El efecto de la adición de dos programado-
res para esta actividad en curso en realidad puede ser contraproducente para el proyecto. Esta hipó-
tesis fue sugerida originalmente por un exejecutivo de IBM llamado Fred Brooks, quien sugirió, en su
famosa ley de Brook, que la adición de recursos para las actividades en curso solo las retrasa aún más.
Su punto era que el tiempo y la formación adicional necesaria para que estos recursos adicionales se
encuentren al día con la tarea niega el impacto positivo de aumentar la plantilla de personal. Es mejor,
según él, añadir recursos adicionales a las actividades que aún no han comenzado, en donde realmente
se puede acortar las duraciones de las tareas. Aunque la investigación tiende a confirmar la ley de
Brook, en la mayoría de situaciones es posible realizar contracción en el cronograma siempre que haya
tiempo suficiente para que los recursos actuales disponibles puedan entrenar al personal adicional o se
agreguen oportunamente a la actividad para minimizar los efectos negativos de la ley de Brook.3
Aunque la discusión anterior demuestra que hay algunos aspectos importantes al agregar recursos a un pro-
yecto, esta alternativa sigue siendo, por mucho, el método más común para acortar duraciones de las activi-
dades y a menudo es útil siempre y cuando se respete la relación entre el costo y el cronograma.
Para determinar la utilidad de comprimir las actividades del proyecto, primero se debe determinar
el costo real asociado con cada actividad del proyecto, tanto en términos de los costos fijos como de costos
variables. Estos conceptos se analizan en mayor detalle en el capítulo 8 dedicado al presupuesto del proyecto.
Supongamos que tenemos un método razonable para estimar el costo total de las actividades del proyecto, en
tiempo de desarrollo normal y con una alternativa de compresión. La figura 10.9 muestra la relación entre el
costo de las actividades y su duración. Tenga en cuenta que la longitud normal de la duración para una activi-
dad refleja un costo asociado a los recursos necesarios para realizar esa tarea. Al tratar de comprimir las acti-
vidades, los costos asociados a estas actividades aumentan considerablemente. El punto de compresión en
el diagrama representa la actividad del proyecto totalmente acelerada, en donde no se escatiman gastos para
completar la tarea. Debido a que la línea muestra la pendiente entre los puntos normales y de compresión,
también se entiende que una actividad del proyecto se puede acelerar hasta cierto punto inferior al punto de
compresión total, respecto a la pendiente de la línea de compresión.
En el análisis de las opciones de compresión para las actividades del proyecto, el objetivo es encontrar
el punto en el que la relación tiempo/costo se optimiza. Podemos calcular varias combinaciones de relaciones
tiempo / costo para las opciones de compresión de un proyecto, determinando la pendiente para cada activi-
dad utilizando la siguiente fórmula:

costo de compresión - costo normal


Pendiente = tiempo normal - tiempo de compresión
344 Capítulo 10  •  Programación del proyecto. Retraso, compresión y redes de actividades

Punto de
compresión

Comprimido

Costo

Punto
normal

Normal

Comprimida Normal

Duración de la actividad
FIGURA 10.9  Relaciones tiempo/costo para comprimir las actividades

EJEMPLO 10.1 Cálculo del costo de compresión

Para calcular el costo de comprimir las actividades del proyecto, suponga que para la actividad X, la duración
normal es 5 semanas y el costo presupuestado es 12,000 dólares. El tiempo de compresión de esta actividad
es 3 semanas y el costo esperado es 32,000 dólares. Utilizando la fórmula anterior, se puede calcular la pen-
diente de costos para la actividad X como:
32, 000 - 12, 000 $20, 000
5-3 o 2 = $10, 000 por semana

En este ejemplo, para la actividad X se calcula un costo de 10,000 dólares de aceleración por cada semana de su
cronograma original. ¿Es este un precio razonable? Para responder esta pregunta, debemos tener en cuenta:

a. ¿Qué costos están asociados con la aceleración de otras actividades del proyecto?  Puede ser que el
costo unitario 10,000 dólares por semana para la actividad X sea una verdadera ganga. Supongamos, por
ejemplo, que una actividad alternativa del proyecto costaría 25,000 dólares por semana de aceleración.
b. ¿Cuáles son los beneficios frente a las pérdidas por la aceleración de la actividad?  Por ejemplo,
¿el proyecto no tiene sanciones excesivas por la entrega tardía, que harían que comprimir fuera más
barato que el retraso en la entrega? Por otra parte, ¿hay un enorme beneficio potencial por ser el pri-
mero en comercializar el proyecto?

EJEMPLO 10.2 Compresión del proyecto

Suponga que tenemos un proyecto con solo ocho actividades, como se ilustra en el cuadro 10.1. El cuadro
también muestra las duraciones y los costos normales de actividad y la duración y sus costos de compresión.
Queremos determinar cuáles actividades son las candidatas óptimas para comprimir. Suponga que los costos
mencionados incluyen los costos fijos y los variables para cada actividad. Utilice la fórmula proporcionada
anteriormente para calcular los costos por unidad (en este caso, los costos por día) para cada actividad. Estos
costos se muestran en el cuadro 10.2.
10.3  Compresión de proyectos 345

CUADRO 10.1  Actividades del proyecto y costos (normal vs. compresión)

Normal Compresión
Actividad Duración Costo Duración Costo
A 5 días $ 1,000 3 días $ 1,500
B 7 días 700 6 días 1,000
C 3 días 2,500 2 días 4,000
D 5 días 1,500 5 días 1,500
E 9 días 3,750 6 días 9,000
F 4 días 1,600 3 días 2,500
G 6 días 2,400 4 días 3,000
H 8 días 9,000 5 días 15,000
Costo total = $22,450 $37,500

Los cálculos sugieren que las actividades menos costosas por comprimir serían, en primer lugar, la acti-
vidad A (250 dólares/día), seguido por las actividades B y G (300 dólares/día). Por otro lado, el proyecto podría
incurrir en los grandes aumentos de costos al comprimir las actividades H, E y C (2,000 dólares/día, 1,750 dóla-
res/día y 1,500 dólares/día, respectivamente). Nótese que en este ejemplo estamos suponiendo que la actividad
D no puede reducirse, así que no hay costo de compresión asociado.
Ahora vamos a transferir estos costos de compresión a una red que muestra la lógica de prioridad
de cada actividad. Podemos formar una relación entre el acortamiento del proyecto y el aumento de sus
costos totales mediante el análisis de cada alternativa. La figura 10.10 muestra la red AON del proyecto
como un ejemplo simplificado solo identificando la actividad de compresión con sus valores de duración.
La red también muestra la ruta crítica como A - D - E - H con 19 días. Se determinó que el costo inicial
del proyecto, con duraciones de las actividades normales, es de 22,450 dólares. La actividad por comprimir
es la A (el más bajo de 250 dólares), que al acelerarla en 1 día aumentará el presupuesto del proyecto de
22,450 dólares a 22,700 dólares. Al comprimir totalmente la actividad A se acortará la duración del pro-
yecto a 25 días, mientras el costo se aumenta a 22,950 dólares. La actividades B y G son las próximas can-
didatas a comprimirse con 300 dólares por día cada una. Sin embargo, ninguna de estas dos actividades se
encuentra en la ruta crítica del proyecto, por lo que el beneficio general para el proyecto al acelerar estas
actividades puede ser mínimo. La actividad D no se puede acortar. El costo por unidad de compresión de
la actividad E es 1,750 dólares y el costo de compresión de H es mayor ($2,000 dólares). Por tanto, compri-
miendo la actividad E en 1 día aumentará el presupuesto del proyecto de 22,950 dólares a 24,700 dólares.
Los costos totales para cada día de compresión del proyecto se muestran en el cuadro 10.3

CUADRO 10.2  Costos de compresión para cada CUADRO 10.3  Costos del proyecto
actividad según la duración

Costo de compresión ¿Sobre la ruta Duración Costo total


Actividad (por día) crítica? 27 días $22,450
A $ 250 Sí 26 días 22,700
B 300 No 25 días 22,950
C 1,500 No 24 días 24,700
D — Sí 23 días 26,450
E 1,750 Sí 22 días 28,200
F 900 No 21 días 30,200
G 300 No 20 días 32,200
H 2,000 Sí 19 días 34,200
346 Capítulo 10  •  Programación del proyecto. Retraso, compresión y redes de actividades

B F
6 3

A C E H
3 2 6 5

D G
5 4

Actividad
Leyenda
Duración

FIGURA 10.10  Red de actividades en el proyecto totalmente comprimido

Tenga en cuenta que la red del proyecto comprimida de forma total se muestra en la figura 10.10 y la
ruta crítica es invariable cuando todas las actividades están totalmente comprimidas. La asociación de los
costos para la duración del proyecto se representa en la figura 10.11. A medida que cada actividad del pro-
yecto se comprime en orden, se presentan aumentos generales en el presupuesto del proyecto. La figura 10.11
demuestra, sin embargo, que, más allá del compresión de las actividades A, E y H, hay poco incentivo para
comprimir cualquiera de las otras tareas del proyecto. La longitud total del proyecto no puede reducirse por
debajo de 19 días y cualquier compresión adicional simplemente agrega costos al presupuesto. Por tanto, la
estrategia de compresión óptima para este proyecto es acelerar solamente las actividades A, E, y H a un costo
total de 11,750 dólares y un costo del proyecto revisado de 34,200 dólares.

44,000

40,000

Comprimir todo
36,000
Comprimir A+E+H

Costo 32,000

28,000 Comprimir A+E

24,000 Comprimir A
Todo Normal
20,000

16 18 20 22 24 26 28 30
Duración (días)

FIGURA 10.11  Relación entre costo y días de recorte en un proyecto comprimido


10.3  Compresión de proyectos 347

La decisión de compresión para un proyecto debe considerar sus ventajas y desventajas. Teniendo
en cuenta la relación entre la duración de la actividad y el aumento de los costos del proyecto, nunca es
una operación “sin dolor”, siempre hay un costo significativo asociado con la aceleración de la activi-
dad. Sin embargo, si las razones para acelerar son suficientemente convincentes, la duración total del
proyecto puede disminuirse significativamente.

Efectos en el presupuesto de comprimir el proyecto


Como se vio, comprimir es la decisión de acortar el tiempo de duración de una actividad mediante la adición de
recursos con su correspondiente pago de costos directos adicionales. Existe una clara relación entre la decisión
de compresión de las actividades del proyecto y su efecto en el presupuesto. Como muestra la Figura 10.11, el
costo de compresión siempre debe sopesarse con el ahorro de tiempo al acelerar la ejecución de la actividad.
Para poner de relieve este problema, tenga en cuenta la tabla de compresión que se muestra en el cua-
dro 10.4. Supongamos que las actividades A, C, D y H están en la ruta crítica, por tanto, la primera decisión
se refiere a cuál de las actividades críticas debemos comprimir. Una simple comparación de las actividades
y sus costos de compresión revela lo siguiente:

Actividad Costo de compresión


A $2,000
C $1,500
D $3,000
H $3,000

De acuerdo a los datos del cuadro 10.4, se debe comprimir la actividad C, la más barata de acelerar, disminu-
yendo 3 días a un costo de 1,500 dólares en gastos adicionales. Los otros candidatos para comprimir (A, D y
H ) también pueden evaluarse de forma individual en términos de tiempo de programación ganado frente a
los costos para el presupuesto del proyecto (suponga que todos los otros caminos son ≤ 48 días). Al compri-
mir la actividad A se disminuye el proyecto en 3 días a un costo adicional de 2,000 dólares, elevando el costo
total de A a 4,000 dólares. Al comprimir las actividades D y H se presenta un ahorro de tiempo de 5 y 3 días,
respectivamente, con costos adicionales de 3,000 dólares para cada una.
También los costos indirectos se afectan por la aceleración. El cuadro 10.5 muestra las opciones que
tiene el equipo del proyecto al enfrentarse con la decisión de acelerar el proyecto analizando los costos que
resultan del proyecto. Supongamos que el proyecto se carga a una tasa fija, por ejemplo, 200 dólares por día.
Supongamos también que una serie de penalizaciones por retraso entran en juego, si el proyecto no se comple-
tado dentro de 50 días. El cronograma original de 57 días nos deja claramente en riesgo de sanciones, y aunque
hemos mejorado la fecha de la entrega, aún estamos 4 días pasados de la fecha límite. Ahora descubrimos que
al iterar tres veces el compresión de la programación del proyecto nos llevará desde un cronograma original de
57 días a un nuevo cronograma de 48 días (acelerando primero la actividad C, después la A y luego la H). La
programación se ha acortado en 9 días frente a un aumento del presupuesto de 6,500 dólares.

CUADRO 10.4  Actividades del proyecto, duraciones y costos directos

Normal Comprimida
Costo Costo de
Actividad Costo Duración extra Duración compresión
A $2,000 10 días $2,000   7 días $ 667/día
B  1,500   5 días  3,000   3 días  1,500/día
C  3,000 12 días  1,500   9 días    500/día
D  5,000 20 días  3,000 15 días    600/día
E  2,500   8 días  2,500   6 días  1,250/día
F  3,000 14 días  2,500 10 días    625/día
G  6,000 12 días  5,000 10 días  2,500/día
H  9,000 15 días  3,000 12 días  1,000/día
348 Capítulo 10  •  Programación del proyecto. Retraso, compresión y redes de actividades

CUADRO 10.5  Costo del proyecto frente a duración

Duración del Costos Penalidad por Costos


proyecto (días) directos daños liquidados Sobrecostos totales
57 $32,000 $5,000 $11,400 $48,400
54  33,500  3,000  10,800  47,300
51  35,500  1,000  10,200  46,700
48  38,500 -0-   9,600  48,100

55

45 Costos totales

Costos directos
35
Costo
(miles)
25

15 Sobrecostos

5 Penalidad

30 35 40 45 50 55 60
Linea base del cronograma del proyecto (días)

FIGURA 10.12  Costos del proyecto en su ciclo de vida


Fuente: A. Shtub, J. F. Bard, and S. Globerson. (1994). Project Management:
Processes, Methodologies, and Economics, Segunda Edición. Copyright © 2005.
Adaptado con permiso de Pearson Education, Inc., Upper Saddle River, NJ.

Podríamos hacer el cuadro 10.5 más completo comprimiendo cada actividad y calculando los costos
y sus efectos en los costos totales del proyecto. Sin embargo, intuitivamente podemos ver que los costos
directos seguirán aumentando a medida que se incluyan los costos adicionales de las actividades acelera-
das. Por otra parte, los costos adicionales podrían reducir los gastos por daños y perjuicios; de hecho, en
48 días, los daños y perjuicios no serían un factor en la estructura de costos. Por tanto, el reto es decidir
en qué momento ya no es económicamente viable continuar comprimiendo las actividades del proyecto.
La figura 10.12 muestra las opciones del equipo del proyecto cuando se trata de equilibrar las necesi-
dades del cronograma y del costo, junto a otros factores que intervienen en la gerencia del proyecto, como
sanciones por retraso en la entrega. Los costos directos se muestran con una pendiente hacia abajo, lo cual
refleja que los costos rápidamente aumentan mientras el cronograma se reduce (el efecto disyuntivo tiem-
po-costo). Al presentarse daños y perjuicios por sanciones después de la fecha límite de 50 días programa-
dos, vemos que el equipo del proyecto se enfrenta con la opción de incurrir en costos extras al comprimir
cronograma del proyecto frente al pago de las penalizaciones por la entrega del proyecto fuera del plazo
establecido. El proceso con que se enfrenta el equipo del proyecto es equilibrar dos factores que compiten
entre sí, los costos de compresión y los costos de penalización por finalizar tarde el proyecto.

10.4  REDES DE ACTIVIDAD EN LA FLECHA


Hasta ahora, este texto se ha centrado en el uso de la convención actividad en el nodo ( activity on node: AON)
para la representación de diagramas de red de actividades. Una de las razones de la popularidad de este sistema
es que refleja el estándar utilizado en casi todos los software de programación de gerencia de proyectos, que
es visualmente más fácil de comprender y que simplifica muchas de las normas y convenciones del pasado
en los diagramas de red. Sin embargo, las técnicas de actividad en la flecha (activity on arrow: AOA) es una
10.4  Redes de actividad en la flecha 349

Actividad en el nodo Actividad en la flecha

Fecha de
inicio
temprano
Nombre de Descripción
la actividad
Fecha de Duración
fin tardío

FIGURA 10.13  Notación para redes de actividad en flecha (AOA)

alternativa a la metodología de AON, que aunque ya no es tan popular como lo era antes, la AOA sigue uti-
lizándose en cierta medida en diversas situaciones de gerencia de proyectos. Algunas convenciones AOA son
exclusivas de su uso y no se traducen directamente o se integran con los enfoques de AON.

¿Qué tan diferentes son?


Tanto el método AON como el AOA se utilizan para crear la red de actividades del proyecto. Estos simple-
mente difieren en los medios que emplean y la forma gráfica en la que la red, una vez completada, se repre-
senta. Las redes AOA también emplean flechas y nodos para construir la red de actividades; sin embargo, con
AOA la flecha representa la actividad con su estimación de tiempo de duración, mientras el nodo se utiliza
solo como un marcador de eventos que, por lo general, representa la finalización de una tarea.
Considere el nodo de actividad que se muestra en la figura 10.13. El nodo AOA es similar a los nodos
de AON en que no hay ninguna norma establecida para el tipo de información que el nodo debe contener,
sin embargo, debe ser suficientemente claro para que sea entendido por los usuarios. La convención en la
figura 10.13 ofrece una mejor ubicación de la información de la red para cada actividad flecha y nodo:

La flecha incluye una breve descripción de la tarea y su duración esperada.


El nodo incluye una etiqueta para el evento, como un número, una letra o un código, y las fechas de los
eventos de inicio temprano y fin tardío. Estos valores corresponden a las fechas de inicio temprano y
fin tardío de la actividad.

EJEMPLO 10.3 Desarrollo de una red de actividad en la flecha

El desarrollo de una red AOA sigue un proceso similar al que se aplica en la metodología de AON, con algu-
nas diferencias importantes. Con el fin de aclarar las diferencias, volvamos al problema de red mostrado al
principio de este capítulo, el proyecto Delta. El cuadro 10.6 nos da la información pertinente de las relaciones
predecesoras que necesitamos para construir la red AOA.

CUADRO 10.6  Información del proyecto

Proyecto Delta
Actividad Descripción Predecesoras Duración estimada
A Firmar el contrato Ninguna  5
B Diseñar el cuestionario A  5
C Investigar el mercado objetivo A  6
D Aplicar muestra de la encuesta B, C 13
E Desarrollar la presentación B  6
F Analizar los resultados D  4
G Realizar análisis demográfico C  9
H Hacer presentación al cliente E, F, G  2
350 Capítulo 10  •  Programación del proyecto. Retraso, compresión y redes de actividades

A
1 2

FIGURA 10.14  Ejemplo de diagrama de red con enfoque AOA

Comenzamos la construcción de una red de la misma manera que con la metodología AON desarro-
llada en el capítulo 9. En primer lugar, podemos empezar con la actividad A y sus sucesoras inmediatas, las
actividades B y C. Debido a la convención, ahora se indica la actividad en la flecha: es común que las redes
AOA tengan un nodo correspondiente a un evento inicial “inicio” que precede a la inclusión de todas las acti-
vidades. La figura 10.14 muestra el proceso de comenzar a añadir la información del proyecto en el diagrama
de red. Tenga en cuenta que las actividades B y C siguen directamente a la actividad A. La convención sería
elaborar dos flechas, que representan estas actividades, directamente desde el nodo del evento 2.
El primer problema con las redes AOA se evidencia una vez que tengamos que introducir la actividad
D en la red. Tenga en cuenta que tanto las actividades B y C son predecesoras inmediatas de la actividad D.
Representar esta relación en una red AON es fácil, simplemente dibujamos dos arcos que conectan los nodos
B y C al nodo de la actividad D (véase la figura 9.8) . Sin embargo, con las redes de AOA no podemos emplear
el mismo proceso. ¿Por qué no? Debido a que cada flecha se utiliza no solo para conectar los nodos, sino tam-
bién para representar una tarea independiente en la red de actividades. ¿Cómo podemos mostrar esta relación
de precedencia en la red? La figura 10.20 ofrece varias opciones, de las cuales dos son incorrectas. La primera
opción (Figura 10.15a) es asignar dos flechas que representan la actividad D y las actividades de enlace B y C a
través de sus respectivos nodos (3 y 4) con el nodo 5. Esto sería un error, porque la convención AOA es asignar
una sola actividad a cada flecha. Alternativamente, podríamos tratar de representar esta relación de precedencia
mediante la segunda opción (véase figura 10.15b), en la que se utiliza un doble conjunto de flechas de activi-
dad para las actividades B y C vinculando conjuntamente el nodo 2 al nodo 3. Una vez más, este enfoque no
es correcto, ya que no cumple la regla de que cada nodo representa un evento único, como la finalización de
una actividad individual. Esto puede llegar a ser confuso, considerando que la convención es emplear múltiples
flechas entre los nodos de eventos, y precisamente para resolver esta circunstancia se crearon las actividades
dummy.

B D

2 5

C D

FIGURA 10.15a  Representación de actividades con dos o más sucesoras inmediatas (incorrecta)
10.4  Redes de actividad en la flecha 351

D
2 3 4
C

FIGURA 10.15b  Manera alternativa para representar actividades con dos o más
sucesoras inmediatas (incorrecta)

Actividades dummy
Las actividades dummy se utilizan en redes AOA para indicar la existencia de relaciones de precedencia entre
las actividades y sus nodos de eventos. Ellas no tienen ningún valor de trabajo o de tiempo asignados. Se
utilizan cuando se quiere indicar una dependencia lógica, de manera que una actividad no puede comenzar
antes de que otra se haya completado, pero las actividades no se encuentran en el mismo camino de la red.
Las actividades dummy generalmente se representan como líneas discontinuas o punteadas y pueden o no
pueden tener asignadas su propio identificador.
La figura 10.15c muestra el método adecuado para vincular las actividades B y C con su sucesora, la actividad
D, mediante el uso de actividades dummy. En este caso, las actividades dummy solamente demuestran que tanto la
actividad B como la C deben completarse antes del inicio de la actividad D. Cuando se utilizan actividades dummy
en los diagramas de red, una buena regla para su uso es la moderación. El uso excesivo de actividades dummy puede
añadir confusión a la red, sobre todo cuando a menudo es posible representar la lógica de precedencia sin emplear
el mayor número posible de actividades dummy. Para ilustrar este punto, considere la figura 10.16, en la que se ha
reconfigurado ligeramente la red de actividades parcial del proyecto Delta. Tenga en cuenta que en este diagrama
simplemente se eliminó una de las actividades dummy que entra en el nodo 5, sin cambiar la lógica de la red.

3
B

D
2 5 6

FIGURE 10.15c  Representación de actividades con dos o más sucesoras inmediatas mediante
actividades dummy (mejor)

3
B

A
1 2
C

FIGURA 10.16  Red parcial del proyecto Delta utilizando la notación AOA
352 Capítulo 10  •  Programación del proyecto. Retraso, compresión y redes de actividades

3
B
E
A
1 2
H
C 6 7
G
4 F
D

FIGURA 10.17  Red AOA completa del proyecto Delta

Ahora que tenemos una idea de la utilización de actividades dummy, podemos construir la red
AOA completa para el proyecto Delta. La actividad E sigue a la B y se introduce en la red con su evento de
finalización en el nodo 6. Del mismo modo, la actividad de F, después de la D, se introduce en la red con
su punto de finalización en el nodo 6. La actividad G también se puede introducir después de la finaliza-
ción de la C, y su nodo de punto final es también el 6. Por último, la actividad H, que tiene actividades E,
F, y G como predecesoras, se introduce y se completa la red básica AOA (véase la figura 10.17).

Recorridos hacia adelante y hacia atrás en redes AOA


La información que buscamos reunir con estos procesos que determinan las fechas de inicio temprano y
tardío es ligeramente diferente de la utilizada en AON, cuando nos referimos a los valores de inicio temprano
(ES) para cada nodo de actividad en el recorrido hacia adelante. Las reglas de decisión siguen siendo válidas:
cuando se presenten nodos que sirven como puntos de convergencia de varias actividades predecesoras,
seleccionamos el mayor ES. El único punto por recordar es que a las actividades dummy no se les asigna
ningún valor de duración.
La figura 10.18 muestra los resultados del recorrido hacia adelante para el proyecto Delta. Los
nodos muestran la información relativa al ES en el cuadrante superior derecho. Al igual que con el
recorrido hacia adelante AON, el proceso consiste simplemente en sumar las estimaciones de duración
para cada moviéndose de izquierda a derecha, a lo largo de la red. Los únicos lugares en la red que
requieren aplicar una deliberación sobre el valor del ES se encuentran en los puntos de convergencia,
representados en los nodos 4 y 6. El nodo 4 es el punto de convergencia para la actividad C y la activi-
dad ficticia representada por la línea punteada. Debido a que las actividades dummy no tienen ningún
valor de duración, el ES para el nodo 4 es el más grande de los caminos para las actividades A - C = 11
frente a las actividades A - B = 10. Por tanto, el ES en el nodo 4 debe ser 11. El otro punto de conver-
gencia, el nodo 6, utiliza el mismo proceso de selección. Debido a que la trayectoria A - C - D - F =
28, que es el valor más grande que entra en el nodo, entonces utilizamos 28 como el ES para el nodo 6.
Finalmente, después de sumar la duración de la actividad H, la longitud total de la red es 30 semanas, el
mismo valor calculado con la red AON mostrada en el capítulo anterior (véase la figura 9.13).

10
3
B
E
5
0 A 5 6
1 2
5 28 H 30
C 6 7
G 2
6 11 9
4
F 4
D
13 24
5

FIGURA 10.18  Recorrido hacia adelante en el Proyecto Delta con una red AOA
10.4  Redes de actividad en la flecha 353

10
3
B 22
E
5
0 A 5 6
1 2
0 5 5 28 H 30
C 6 7
G 28 2 30
6 11 9
4
11 F 4
D
13 24
5
24

FIGURA 10.19  Recorrido hacia atrás en el proyecto Delta con una red AOA

El recorrido hacia atrás es similar al procedimiento utilizado anteriormente para la red AON. El reco-
rrido hacia atrás comienza en el extremo derecho o en la terminación de la red en el nodo 7, con duración
de 30 semanas como punto de partida, restando los tiempos de duración de cada actividad a lo largo de cada
ruta (LF - Dur = LS). Cuando llegamos a un evento de divergencia, como el nodo 2 o 4, seleccionamos el
valor más pequeño de LS. Usando la figura 10.19 como referencia, podemos empezar restando los valores de
las duraciones al pasar de derecha a izquierda en la red. Los valores de LS se incluyen en el nodo en el cua-
drante inferior derecho, justo debajo de los valores de ES.
El recorrido hacia adelante nos permitió determinar que la duración prevista del proyecto es 30 sema-
nas. Mediante el recorrido hacia atrás, podemos determinar las holguras de actividades individuales, así
como la ruta crítica, similar al proceso AON. La diferencia es que el etiquetado de los valores de ES y LS se
encuentra dentro de los nodos de eventos, por tanto, es necesario examinar cada trayectoria de actividad para
determinar la holgura asociada a ella. Sabemos, por ejemplo, que el ES para la actividad E es 10 semanas y
la duración de la actividad es 6 semanas. Por tanto, al comparar el EF para la actividad de E de 16 semanas,
con el valor de ES en el nodo 6 de 28 semanas, podemos ver que la diferencia, de 12 semanas, es la cantidad
de holgura para la actividad. Del mismo modo, el ES de actividad G es 11 semanas, y su duración es 9. Este
valor de FE de 20 semanas es 8 semanas menos que el ES para el nodo 6, lo cual indica que la holgura de la
actividad es 8. La misma lógica se puede aplicar a cada actividad en la red para determinar la ruta crítica y las
actividades con holgura.

AOA versus AON


Los diagramas de red actividad en la flecha y actividad en el nodo tienen la misma intención: crear una lógica
secuencial para todas las actividades de un proyecto y, una vez vinculadas, determinar la duración del pro-
yecto, la ruta crítica y la holgura de las actividades. Una pregunta común que tiene que ver con la eficacia de
un enfoque de red sobre el otro es: ¿cuáles son las ventajas y desventajas de seleccionar ya sea la metodología
AON o la AOA? En consecuencia, en la elección de estos métodos de red es importante tener en cuenta algu-
nas fortalezas y debilidades de cada una de ellas.4

FORTALEZAS Y DEBILIDADES DE AON  Los beneficios de AON se centran principalmente en el hecho de


que se ha convertido en el formato más popular en los programas informáticos, como MS Project. Por tanto,
a medida que más empresas utilizan la programación de proyectos basada en software, se emplea cada vez
más el método de AON para los diagramas de red. Otro beneficio de AON es que colocamos la actividad
dentro de un nodo y usamos las flechas solo como dispositivos de conexión, simplificando el etiquetado de
los nodos de la red. Esta convención hace que las redes AON sean muy fáciles de leer y comprender, incluso
para los gerentes de proyectos novatos. En las redes AON, su principal inconveniente se produce cuando el
proyecto es muy complejo, con numerosos caminos a lo largo del modelo. Cuando el proyecto cuenta con
muchos nodos de convergencia y divergencia se genera un gran número de flechas y conexiones de nodos
que pueden hacer que las redes AON sean difíciles de leer.

FORTALEZAS Y DEBILIDADES DE AOA  El mayor beneficio de los modelos AOA radica en que se acep-
tan en determinadas áreas de negocio, como la construcción, donde las redes AON se utilizan menos.
Además, en proyectos grandes y complejos, a menudo es más fácil emplear el proceso de ruta utilizada en
354 Capítulo 10  •  Programación del proyecto. Retraso, compresión y redes de actividades

AOA. Por último, debido a que el sistema de actividad y nodos se utiliza para proyectos con muchos hitos
importantes, como entregas de los proveedores, los nodos de eventos AOA son muy fáciles de identificar
y etiquetar. Por otro lado, no hay duda de que algunas convenciones de los diagramas AOA son incómo-
das de utilizar, en particular en las actividades dummy. El concepto de actividades dummy no es fácil de
dominar, y se requiere, por tanto, una mayor capacitación para que los gerentes de proyectos novatos estén
en capacidad de utilizar el concepto fácilmente. Además, las redes AOA pueden ser de “información inten-
siva”, en donde tanto las flechas como los nodos contienen alguna información importante del proyecto.
En lugar de centralizar todos los datos en un nodo, como en la convención AON, las redes AOA utilizan
las flechas y los nodos de la red para etiquetar.
Finalmente, la elección de emplear la metodología de red AON o la AOA se reduce a las preferencias
personales y las presiones externas que enfrenten en las situaciones de trabajo. Por ejemplo, si la organiza-
ción para la que trabajo decide adoptar el modelado AON por el software de programación de uso gene-
ral, con toda probabilidad, me centraré exclusivamente en el enfoque de diagramación de la red AON.
Independientemente de la decisión que cada uno de nosotros tome en relación con la utilización de la meto-
dología AOA o la AON, es importante que todos se sientan cómodos con la teoría básica y el funcionamiento
de los dos tipos de modelos de red.

10.5  CONTROVERSIAS EN EL USO DE LAS REDES


La técnica de evaluación y revisión de programas (Program Evaluation and Review Technique: PERT)/
método del camino crítico (Critical Path Method: CPM) (PERT/CPM) es un sistema bien entendido y muy
popular de planeación y programación de proyectos. Sin embargo, las redes son representaciones abstractas de
eventos en los que el tiempo se reduce a un valor numérico. Ellas pueden o no pueden realizarse con una escala
que tenga relación con el patrón de los acontecimientos en curso. A veces, esta abstracción puede ser engañosa.
De hecho, hay varias críticas y advertencias que debemos tener en cuenta al desarrollar las redes de la actividad
del proyecto, incluidas:5
1. Las redes pueden llegar a ser demasiado grandes y complejas.  Muchos proyectos son grandes y
enormemente complejos. Por ejemplo, la creación de un sistema operativo para computadores perso-
nales, la construcción de un estadio deportivo, o el desarrollo de un medicamento son todos proyec-
tos que pueden contener fácilmente miles de tareas o actividades individuales. Muchos proyectos se
extienden por años, y la estimación de la duración de las actividades, en el mejor de los casos, puede
hacerse mediante conjeturas generales. Como resultado, cuando se trabaja con redes de proyectos a
gran escala o a largo plazo, se requiere hallar formas de simplificar los cálculos de la red de actividades.
Una regla de oro para los grandes proyectos es tratar de simplificar la lógica de la red y reducirla a las
relaciones más evidentes o significativas. En lugar de mostrar todos los caminos posibles a través de la
red y cada secuencia de actividades, se puede crear una “red resumida” que muestra solo las subrutinas
o rutas de red clave. Estos subprogramas se pueden desglosar por el gerente del proyecto o el adminis-
trador responsable de su realización, para generar una red general del proyecto más ágil que incluya
solo las actividades más generales o los proyectos conexos.
Utilizar periodos a escalas variables es otra opción para los proyectos a largo plazo. Por ejem-
plo, las actividades programadas dentro de los primeros nueve meses pueden aparecer con una escala
de días necesarios para su realización. Las actividades programadas entre el primero y segundo año
podrán aparecer en la red con una escala de semanas o incluso de meses, y las actividades incluidas en
la red más allá del segundo año solo se pueden enumerar con duraciones indicadas en meses.
2. El razonamiento defectuoso en la construcción de la red a veces puede conducir a simplificaciones o
representaciones incorrectas.  Es frecuente que se presenten inconvenientes cuando las organizaciones
intentan gerenciar sus proyectos sobre la base de múltiples capas de redes de actividades. La información
que fluye a través de los diferentes niveles de la organización a menudo no se entiende o no es fácil de
traducir entre los niveles, ya que no comparten una agenda común de proyectos. Por tanto, es importante
que al simplificar una red de proyectos se tomen medidas para garantizar que la información no se pierde
en la simplificación excesiva o en la creación de múltiples redes sin procesos de integración.
Los cronogramas complejos requieren un enfoque combinado “de arriba abajo” y de “abajo
arriba” para el control de las actividades del proyecto. El control de arriba abajo significa que hay un
sistema de niveles para los programas del proyecto. En la parte superior se encuentra la información
básica de resumen, por ejemplo, una simple enumeración de los paquetes de trabajo o resumen de
10.5  Controversias en el uso de las redes 355

Nivel uno: superior

Nivel dos: medio

Nivel tres: inferior

FIGURA 10.20  Sistema de niveles para el cronograma del proyecto

las numerosas tareas individuales. La alta gerencia se ocupa de la parte superior: la información de
resumen a nivel de agregados y programación simplificada. A pesar de que es más fácil de entender,
esta red resumen de primer nivel no le permite a la alta gerencia contar con base para comprender el
desarrollo real del proyecto, ya que no están al tanto de la situación de las tareas individuales. Por otra
parte, los responsables de las fases del proyecto, así como los gerentes de proyectos, necesitan contar
con más información de “abajo arriba” que les permita mantener en sus manos el control de la parte
de la red del proyecto de la cual son responsables. El personal del proyecto de nivel inferior necesita
información específica de la red de actividades, para optimizar la programación y el control.
La figura 10.20 proporciona un ejemplo de un sistema escalonado simplificado para el crono-
grama. La alta gerencia recibiría información agregada de la gerencia de nivel superior, del nivel medio
(por ejemplo, los jefes de departamento) y obtendría información un poco más detallada basada en
las actividades relacionadas con sus departamentos o funciones, en tanto que el gerente del proyecto
y el equipo del proyecto utilizará la información plena, detallada y específica de la programación del
proyecto en el nivel inferior.
3. Las redes se utilizan a veces en tareas para las que no son muy adecuadas.  Las empresas a veces
tratan de adoptar la programación de la red del proyecto a otras actividades de planeación en sus
organizaciones, pero las actividades de la red no son útiles para todos los retos de programación.
Supongamos, por ejemplo, que una empresa de fabricación tiene problemas con la programación de la
producción. Con la noción errónea de que la técnica PERT funciona igual de bien para las operaciones
de fabricación como lo hace para la planeación de proyectos, los gerentes podrían erróneamente deci-
dir emplear PERT en situaciones en las que no es adecuada. De hecho, las metodologías de red para la
planeación de proyectos son una técnica importante en la gerencia de proyectos, que no representan
una panacea para todos los problemas de programación con que se enfrentan las organizaciones.
4. La utilización de las redes para controlar el comportamiento de los subcontratistas tiene peligros
especiales.  Muchos proyectos implican el uso de subcontratistas. Cuando la organización “contra-
tista principal” emplea múltiples subcontratistas, un error común es que esta los obliga a desarrollar
planes de actividades independientes sin referencia a la comprensión o la planeación de otros sub-
contratistas con los que pueden o deben interactuar. Si una empresa utiliza múltiples subcontratistas,
se necesitan dos importantes principios para guiar su uso de las redes: (1) Todos los subcontratis-
tas deben estar al tanto de la red general del contratista principal, que incluye los cronogramas para
356 Capítulo 10  •  Programación del proyecto. Retraso, compresión y redes de actividades

cada “sub”, para que los subcontratistas puedan tomar decisiones de programación que no se basen en
suposiciones, sino más bien en un claro conocimiento de los planes de otros subcontratistas; y (2) las
redes de todos los subcontratistas deben estar integradas—utilizando un conjunto común de técnicas
de red, marco temporal y demás—y el documento de la red debe ser mutuamente accesible.
5. Hay un fuerte potencial de sesgo optimista en las estimaciones de PERT usado en la construcción de
la red.  Investigaciones han demostrado que la mayoría de las estimaciones de actividad utilizadas en
los métodos PERT conducen a estimaciones de la duración de la actividad excesivamente optimistas. El
análisis PERT se basa en las estimaciones de tiempo probabilísticos que, si se determinan sin criterios
objetivos, pueden conducir a cronogramas de proyectos inexactos y engañosos. La lógica que impulsa las
estimaciones de la duración y el desarrollo de la red PERT deberá ser demostrable y razonable para que la
programación PERT tenga sentido.

Conclusiones
El desarrollo de la red de actividades es el corazón del proceso de planeación de la gerencia de proyectos.
Esto nos obliga a hacer estimaciones razonables para la duración de las actividades, y se espera que desa-
rrollemos la lógica de secuencia de las actividades y usemos esta información para crear cronogramas de
proyectos significativos. Solo mediante el análisis detallado de los pasos en la programación de proyectos
podemos convertir ideas de proyectos en realidades. La programación nos permite determinar respuestas
a las preguntas verdaderamente importantes de la gerencia del proyecto: ¿qué se necesita hacer? ¿Cuándo
tienen que llevarse a cabo las actividades? ¿Cómo puede lograrse? Las técnicas de programación que se
seleccionen no son tan importantes para el éxito final de los proyectos como el compromiso de llevar a
cabo estas operaciones con cuidado, metódica y honestamente . El cronograma es nuestra hoja de ruta que
muestra el camino que debemos tomar para completar el proyecto exitosamente. El cuidado con el que
se crea el cronograma y la forma en que lo seguimos determinará si vamos a tener éxito en la gerencia de
nuestros proyectos.

Resumen
1. Aplicar relaciones de retrasos a las actividades del 3. Reconocer los medios alternativos para acelerar los
proyecto.  Ejemplos de desarrollo de lógicas de red proyectos, incluidas sus ventajas y desventajas. El
incluyen determinar cómo se aplican las relaciones de cronograma del proyecto puede acelerarse con una serie
precedencia a cada actividad del proyecto; es decir, ¿qué de medios, entre ellos adicionar recursos al equipo del
actividades siguen a otras de manera común: el fin tem- proyecto, la ejecución rápida, comprometer la calidad,
prano de la actividad predecesora se convierte en el ini- reducir el alcance del proyecto y utilizar horas extras.
cio temprano de la actividad predecesora o de acuerdo Cada una de estas opciones ofrece los medios para ace-
con otras relaciones específicas? Entre estas relaciones lerar el proyecto, pero no todas son adecuadas en todas
alternativas, denominadas relaciones de retraso, se las circunstancias; por ejemplo, puede no ser adecuado
encuentran las de final a inicio, final a final, inicio a ini- o útil comprometer intencionadamente la calidad de un
cio e inicio a final. proyecto. Algunas de estas opciones pueden en teoría
2. Construir y comprender los diagramas de Gantt. Un mejorar la productividad, pero pueden no funcionar tan
método alternativo para el desarrollo de la red del pro- bien en la realidad; por ejemplo, la investigación sugiere
yecto, que no sea el uso de diagramas PERT, es la utiliza- que el uso de las horas extras sostenidamente durante
ción de los diagramas de Gantt. Los diagramas de Gantt largos periodos puede realmente tener un efecto perju-
ofrecen una importante ventaja sobre los diagramas dicial sobre el proyecto debido a los efectos de la fatiga y
PERT, debido a que vinculan todas las actividades de la los costos del retrabajo. Por último, la elección de alter-
línea base del cronograma del proyecto a las fechas del nativas nos obliga a entender las limitaciones de recur-
calendario actual. Por tanto, podemos ver no solo qué sos de la organización.
actividades tienen que ejecutarse y en qué orden, sino 4. Comprender las ventajas y desventajas en la decisión
también cuándo están programadas para comenzar y de comprimir las actividades del proyecto. Cuando
finalizar. En los últimos años, los diagramas de Gantt se se determina que el proyecto debe acelerarse, ya sea
han utilizado con los gráficos PERT, en particular en el debido a cambios en el medio ambiente o a las presio-
software de programación de proyectos. nes de la alta gerencia o de los clientes, se emplea un
Problemas resueltos 357

método conocido como el análisis de compresión del incluidos la creación y el uso de variables dummy, y
proyecto. El compresión vincula directamente todas examina los pasos necesarios para construir una red
las actividades con sus respectivos costos y nos permite AOA, así como sus ventajas y desventajas en compara-
calcular el costo por cada día que elegimos acelerar el ción con la notación AON.
proyecto. La decisión de si debe o no se debe compri- 6. Comprender las diferencias entre AON y AOA y reco-
mir una actividad está directamente relacionada con nocer las ventajas y desventajas de cada técnica. El
las implicaciones de los costos adicionales de la acele- capítulo concluye con una revisión crítica de algunas de
ración, lo cual le permite al gerente del proyecto tomar las controversias del desarrollo y uso de diagramas de red
una decisión basada en la relación tiempo/costo. para la programación del proyecto. Varias desventajas o
5. Desarrollar redes de actividades utilizando técnicas inquietudes respecto a diagramas se analizaron, inclui-
actividad en la flecha (AOA).  Aunque la red AON das: (1) las redes pueden llegar a ser demasiado grandes y
se ha convertido en el método más popular de diagra- complejas; (2) el razonamiento defectuoso puede condu-
mación, desde hace muchos años la creación de diagra- cir a simplificaciones o representaciones incorrectas; (3)
mas de red AOA fue la técnica de elección, y todavía las redes pueden ser usados para tareas en las que son no
se aplica ampliamente en varios ámbitos de proyectos, son apropiadas, y (4) la diagramación de la red tiene peli-
como el de la construcción. En este capítulo se analiza- gros especiales cuando se utiliza para controlar el com-
ron en detalle las redes AOA y sus propiedades únicas, portamiento de los subcontratistas.

Términos clave
Actividad en la flecha Actividades dummy Ejecución rápida (p. 341) Nodo (p. 349)
(AOA) (p. 348) (p. 351) Evento (p. 349) Retraso (p. 333)
Actividad en el nodo Compresión (p. 340) Flecha (p. 349) Técnica de evaluación y
(AON) (p. 348) Convergencia (p. 352) Horas extras (p. 336, 342) revisión de programas
Actividades en serie (p. 333) Diagrama de Gantt (p. 336) Ley de Brook (p. 343) (PERT) (p. 354)

Problemas resueltos
10.1 Comprimir actividades del proyecto los otros caminos están totalmente comprimidos menos el A – C
– D – F – H. Priorice los candidatos para ser comprimidos ¿Cómo
Suponga que usted está considerando si debe o no comprimir las
cambia la red de actividades?
actividades del proyecto, con el final de agilizar su proyecto. Ha cal-
culado los costos por actividad para las opciones normales y de com-
presión. Estos se muestran en el siguiente cuadro: SOLUCIÓN
Recuerde que la fórmula para el cálculo de los costos de compresión
se basa en la pendiente entre los costos normales y los de compresión
Normal Comprimidos de cada actividad:
Actividad Duración Costo Duración Costo
A 6 días $ 2,400 4 días $ 3,600 costos de compresión - costo normal
Pendiente = tiempo normal - tiempo de compresión
B 7 días 3,500 5 días 5,000
C 5 días 3,000 4 días 3,800
Usando esta ecuación, podemos crear un cuadro que muestre los
D 3 días 2,700 2 días 4,500
costos de compresión por día:
E 4 días 800 3 días 1,500
F 5 días 1,200 3 días 2,100 Actividad Costo de compresión (por día)
G 8 días 2,400 5 días 4,200 A $  600
H 3 días   4,500 2 días   7,000 B 750
Costo total = $20,500 $31,700 C 800
D 1,800
E 700
F 450
a. ¿Cuáles actividades son las candidatas más probables para com-
G 600
primirse (es decir, las más rentables de acelerar)?
H 2,500
b. Remítase a la figura 10.19. Usando la ruta crítica de esta red, con-
sidere A – C – D – F – H como la ruta crítica y suponga que todos
358 Capítulo 10  •  Programación del proyecto. Retraso, compresión y redes de actividades

a. Al priorizar las opciones de compresión, las actividades más a. ¿Cuál es el costo de compresión por día de cada una de las acti-
rentables por acelerar son: (1) la actividad F; (2) las actividades A vidades?
y G; y (3) la actividad E. b. Suponiendo que todos ellas forman parte de la ruta crítica, ¿qué
b. Las opciones para comprimirse deben priorizarse primero para las actividades deben comprimirse primero?
actividades que están en la ruta crítica. En este ejemplo, la ruta
crítica se compone de las actividades A – C – D – F – H. Por tanto, SOLUCIÓN
la primera actividad que debería comprimirse sería la actividad F, a. La fórmula para el cálculo de los costos de compresión es:
seguida por la actividad A. Debido a que ni actividad G ni la E se
encuentran en la ruta crítica, comprimirlas no reducirá la duración
costos de compresión - costo normal
del proyecto, pero sí incrementará los costos. Pendiente = tiempo normal - tiempo de compresión

10.2 Costo de comprimir un proyecto Los costos de compresión para cada actividad son:
Tenga en cuenta el siguiente cuadro de actividades del proyecto, Actividad A = $500
en el que se identifica cada actividad, su duración y costo normal y Actividad B = $1,500
duración y costo de compresión:
Actividad C = $700
Actividad D = $1,750
Normal Comprimidos Actividad E = $1,200
Actividad F = $700
Actividad Duración Costo ($) Duración Costo ($)
b. Suponiendo que las actividades son parte de la ruta crítica,
A 3 días $1,500 2 días $2,000 se comprimirían en orden de la menos costosa a la más cos-
B 5 días  3,500 4 días 5,000 tosa. En este caso, la primera opción para comprimir es la
C 4 días  6,800 3 días 7,500 actividad A ($500), seguida de las actividades C y F ($700).
D 5 días  2,500 3 días 6,000 La última actividad que podríamos comprimir sería la acti-
E 7 días  4,200 6 días 5,400 vidad D ($1,750). El tiempo total que podemos ahorrar al
comprimir todas las actividades es 7 días, a un costo total
F 4 días  2,000 3 días 2,700
adicional de $8,100.

Preguntas para discusión


1. Dé ejemplos de circunstancias en las que un proyecto pueda esfuerzos de “aceleración” en realidad puedan dar lugar a retrasos
emplear relaciones de retraso entre las actividades: importantes?
a. Final a inicio 5. ¿En qué circunstancias querría usted comprimir un proyecto?
b. Final a final 6. Al comprimir un proyecto, nos centramos de forma rutinaria
c. Inicio a inicio en las actividades que se encuentran en la ruta crítica, no en
d. Inicio a final actividades con holgura. Explique por qué se presenta este caso.
2. La ventaja de los diagramas de Gantt radica en su vinculación 7. ¿Cuáles son algunas de las ventajas del uso de la notación AOA
con la línea base del cronograma del proyecto. Explique este en oposición a la AON? ¿En qué circunstancias no parece mejor
concepto. aplicar la metodología AON en el desarrollo de la red?
3. ¿Cuáles son las ventajas de utilizar los diagramas de Gantt sobre 8. Explique el concepto variable dummy. ¿Por qué se emplea este
los diagramas PERT? ¿De qué manera pueden ser ventajosos los concepto en notación AOA? ¿Por qué no hay necesidad de uti-
diagramas PERT? lizar dummy ficticias en una red AON?
4. ¿De qué manera conceptos como la ley de Brook y los efectos de 9. Identifique y analice algunos de los problemas o peligros del
las horas extras sostenidas nos hacen repensar en mejores formas uso de redes de proyectos. ¿En qué circunstancias pueden ser
de acelerar un proyecto? ¿Es particularmente irónico que estos beneficioso y cuándo puede ser peligroso?

Problemas
1. Desarrolle el diagrama de red de actividades e identifique la
ruta crítica de un proyecto basado en la siguiente información. Actividad Duración esperada Predecesoras
Dibuje la red de actividades en forma de diagrama de Gantt. D   4 días A
¿Cuál es la duración prevista del proyecto? E   6 días B, C
F   6 días D, E
Actividad Duración esperada Predecesoras G 12 días F
A   5 días — H   4 días G
B   6 días A I   6 días F
C   2 días A J   7 días H, I
Problemas 359

2. Considere un proyecto con la siguiente información. Construya


la red de actividades del proyecto utilizando la metodología Normal Comprimidas
AOA y etiquete cada nodo y flecha apropiadamente. Identifique Actividad Duración Costo ($) Duración Costo ($)
todas las actividades dummy necesarias para completar la red.
F 5 días  2,000 4 días 3,000
G 9 días  4,500 7 días 6,300

Actividad Duración esperada Predecesoras


A 3 — a. Calcule los costos de compresión por día para cada actividad.
b. ¿Cuáles son las candidatas más atractivas para comprimir?
B 5 A
¿Por qué?
C 7 A 4. Al tratar de decidir sobre si debe o no comprimir las activida-
D 3 B, C des del proyecto, un gerente de proyecto se encontró con la
E 5 B siguiente información. Las actividades de la ruta crítica se des-
F 4 D tacan con un asterisco:
G 2 C
H 5 E, F, G Normal Comprimidas
Actividad Costo Duración Costo extra Duración
Actividad Duración ES EF LS LF Holgura A $ 5,000 4 semanas $4,000 3 semanas
A 3 0 3 0 3 — B* 10,000 5 semanas  3,000 4 semanas
B 5 3 8 5 10 2 C 3,500 2 semanas  3,500 1 semanas
C 7 3 10 3 10 — D* 4,500 6 semanas  4,000 4 semanas
D 3 10 13 10 13 — E* 1,500 3 semanas  2,500 2 semanas
E 5 8 13 12 17 4 F 7,500 8 semanas  5,000 7 semanas
F 4 13 17 13 17 — G* 3,000 7 semanas  2,500 6 semanas
G 2 10 12 15 17 5 H 2,500 6 semanas  3,000 5 semanas
H 5 17 22 17 22 —
a. Identifique la secuencia de las actividades que se deben
comprimir en los primeros cuatro pasos. ¿Cuál de las activi-
3. Usted está considerando la decisión de comprimir o no su pro- dades críticas deben comprimirse primero? ¿Por qué?
yecto. Después de hablar con su gerente de operaciones para b. ¿Cuál es la ruta crítica del proyecto? Después de cuatro itera-
llevar a cabo un análisis que permita determinar las duraciones ciones de actividades del proyecto que se deben comprimir, ¿en
y los costos “precompresión” y “poscompresión” de las activi- cuánto se ha reducido la ruta crítica? (Suponga que todos las
dades, se llega al siguiente cuadro (suponga que todas las acti- rutas no críticas son ≤ a la ruta crítica totalmente comprimida).
vidades están en la ruta crítica): c. Suponga que los costos generales del proyecto se acumulan
a una tasa fija de $500 por semana. Grafique la disminución
de los costos directos durante la vida del proyecto, en rela-
Normal Comprimidas ción con el aumento de los gastos generales.
d. Suponga que una cláusula de penalización del proyecto entra
Actividad Duración Costo ($) Duración Costo ($)
en acción después de 19 semanas. La penalidad establecida es
A 4 días $1,000 3 días $2,000 $5,000 por semana. Cuando se agregan los cargos de penaliza-
B 5 días  2,500 3 días 5,000 ción, ¿cómo se comporta la curva de costo total del proyecto? Ela-
C 3 días    750 2 días 1,200 bore un cuadro con los costos que resultan en una base semanal.
e. Si no se presentaran multas para el proyecto, ¿tendría senti-
D 7 días  3,500 5 días 5,000
do comprimir todas las actividades del proyecto? Demues-
E 2 días    500 1 día 2,000 tre su trabajo.

Estudio caso 10.1


Programación de proyectos en Blanque Cheque Construction (A)
Joe ha trabajado para Blanque Cheque Construction cuenta de que la gerencia de proyectos era típicamente la
(BCC) durante cinco años, principalmente en puestos carrera que lo llevaría a la cima en BCC, y todo el mundo
administrativos. Hace tres meses, se le informó de que tenía que demostrar su capacidad para “empaparse” de los
sería trasladado al grupo de gerencia de proyectos de proyectos en ejecución para lograr el éxito.
la empresa. Joe estaba muy emocionado porque se dio
(continúa)
360 Capítulo 10  •  Programación del proyecto. Retraso, compresión y redes de actividades

Joe acaba de salir de una reunión con su superior, Preguntas


Jill, quien le ha asignado responsabilidades de gerencia
1. Desarrolle una red de proyecto compuesta por un
de proyectos para un nuevo proyecto de construcción en
mínimo de 20 actividades que se deben hacer para
que la empresa ha licitado con éxito. El proyecto consiste
completar el proyecto. Como sugiere el caso, man-
en el desarrollo de un pequeño establecimiento comercial
tenga el nivel de estas actividades en general, no en
que los propietarios esperan que se convierta en un cen-
detalle. Asegúrese de indicar cierto grado de relación
tro comercial, justo al otro lado de la calle del campus de
de precedencia entre las actividades.
una universidad suburbana. Con el tamaño del terreno y
2. Suponga que ahora quiere calcular estimaciones para
de la construcción es prudente desarrollar cuatro tiendas
la duración de estas actividades. ¿Cómo hacer uso
de aproximadamente el mismo tamaño. Más allá de ese
de los siguientes enfoques? ¿Son algunos más útiles
deseo, los propietarios han dejado claro a BCC que toda
que otros?
la gerencia de proyectos relacionada con el desarrollo del
a. Opinión de expertos
sitio es responsabilidad de BCC.
b. Experiencia
Joe está sentado en su oficina en BCC tratando
c. Derivación matemática
de desarrollar un plan razonable para el proyecto, con
3. Joe está tratando de decidir qué formato de progra-
retrasos para algunas de las actividades más importantes
mación debe emplear para su planeación: AON o
del proyecto. En este punto, se contenta con tratar los
AOA. ¿Cuáles son algunos de los asuntos que Joe
niveles generales de las actividades, es decir, no quiere
debe considerar en primer lugar antes de elegir entre
llegar a ser demasiado específico respecto a las diferentes
estos métodos?
etapas de construcción para el desarrollo del sitio.

Estudio de caso 10.2


Programación de proyectos en Blanque Cheque Construction (B)
Joe ha gerenciado su proyecto por más de 12 meses y es que la fecha de entrega del proyecto es fija y no se
está preocupado porque debe eliminar los retrasos en puede modificar sin incurrir en sanciones severas, algo
el cronograma. Debido a una serie de contratiempos, que BCC no está dispuesto a aceptar. El mensaje a Joe es
entregas tardías de los proveedores, el mal tiempo y claro: usted puede pasarse un poco en dinero, pero no
otros imprevistos, el proyecto se ha retrasado cada vez puede tener tiempo extra.
más. Aunque el plan original para el proyecto se com- Joe acaba de pedir una reunión con el encargado de
pletará dentro de los próximos cuatro meses, como la obra y otros miembros claves del equipo del proyecto
encargado de la obra Joe está seguro de que BCC no para discutir la posibilidad de comprimir las actividades
puede tomar esa fecha de finalización. Completar tarde restantes del proyecto. Se calcula que al comprimir la
el proyecto tiene algunas consecuencias graves, tanto mayoría de las actividades finales se acercará a la fecha
para BCC como para Joe. La empresa se afectaría por original de finalización contratada, pero a un costo consi-
una serie de cláusulas de penalización que se activan derable. Él tiene que sopesar las opciones cuidadosamente
por cada semana de retraso del proyecto respecto a la con miembros de su equipo para determinar si tiene sen-
fecha de terminación del contrato. Para Joe personal- tido comprimir.
mente, una terminación tardía de su primera asigna-
ción de proyectos puede ser muy perjudicial para su
Preguntas
carrera.
Joe acaba de terminar una reunión con su supervi- 1. ¿Cuáles son algunas de las cuestiones que pesan a
sor directo para determinar cuáles son las opciones que favor y en contra de comprimir el proyecto?
tiene en este momento. La buena noticia es que la oferta 2. Suponga que usted fuera el encargado de la obra para
BCC para el proyecto de construcción llegó con un poco este proyecto. ¿Qué le aconsejaría a Joe para conti-
de margen de beneficio adicional, por encima de lo que nuar? Antes de decidir si desea o no comprimir el
es común en la industria, por lo que el jefe de Joe le ha proyecto, ¿qué preguntas debe formular y cómo debe
dado un “margen de maniobra” de $30,000 en dinero del evaluar sus opciones?
presupuesto discrecional, si es necesario. La mala noticia
Ejercicios con MS Project 361

Ejercicios con MS Project


Ejercicio 10.1
Supongamos que tenemos una tabla completa de actividades prede- proyecto. Usando MS Project, introduzca las actividades de la A a
cesoras (que se muestra en a continuación) y queremos elaborar un la E, su duración y sus predecesoras. Tenga en cuenta que todos los
diagrama de red destacando la secuencia de las actividades para este tiempos de duración están en días.

Proyecto: relanzamiento de un electrodoméstico

Actividad Duración Predecesoras


A Realizar análisis competitivo  3 —
B Revisar informes de campo de ventas  2 —
C Realizar evaluación de las capacidades de tecnología  5 —
D Desarrollar enfoque de técnicas de grupo  2 A, B, C
E Realizar encuestas telefónicas  3 D
F Identificar mejoras pertinentes en las especificaciones  3 E
G Realizar interfaz con el personal de marketing  1 F
H Desarrollar especificaciones técnicas  5 G
I Comprobar y depurar diseños  4 H
J Desarrollar protocolo de pruebas  3 G
K Identificar los niveles de rendimiento críticos  2 J
L Evaluar y modificar los componentes del producto  6 I, K
M Evaluación de las capacidades de conducta 12 L
N Identificar criterios de selección  3 M
O Desarrollar RFQ  4 M
P Desarrollar programa maestro de producción  5 N, O
Q Servir de enlace con el personal de ventas  1 P
R Preparar el lanzamiento del producto  3 Q

Ejercicio 10.2
Actividad Duración Relación de retraso
Ahora, siga desarrollando el diagrama de Gantt con el resto de la
D Construcción 6 HVAC (inicio a inicio)
información contenida en el cuadro del ejercicio 10.1, y elabore el
interna
diagrama de red de actividad completo para este proyecto.

Ejercicio 10.3 Preguntas de ejemplo del examen para la certificación


PMP®
Identifique la ruta crítica del proyecto que se muestra en el ejercicio
10.1. ¿Cómo se puede identificar la ruta crítica? (Sugerencia: dé clic 1. El proyecto de implementación de IT se está empanta-
nando y ha tenido retrasos respecto al cronograma. Los
en la opción “Gantt de seguimiento”).
jefes de departamento se quejan de que el proyecto no los
ayudará, sino se lleva a cabo en un plazo razonable. Su
Ejercicio 10.4 gerente de proyecto considera poner recursos adicionales
para trabajar en actividades a lo largo de la ruta crítica para
Supongamos que queremos incorporar relaciones de retraso en
acelerar la programación. ¿Este es un ejemplo de qué?
nuestra red de actividades del proyecto Relanzamiento de un elec-
a. Cambiar la línea base
trodoméstico. Tenga en cuenta el cuadro que se muestra a continua-
b. Compresión
ción y las relaciones de retraso observadas. Desarrolle un diagrama
c. Ejecución rápida del proyecto
de Gantt MS Project que demuestre estos retrasos.
d. Identificar dependencias críticas

Actividad Duración Relación de retraso 2. ¿Las actividades dummy se utilizan en qué tipo de método
de diagramas de red?
A Cableado 6 Ninguna a. AON
B Plomería 2 Ninguna b. Diagramas de Gantt
C HVAC 3 Cableado (final a inicio), c. AOA
Plomería (final a final) d. OBS
362 Capítulo 10  •  Programación del proyecto. Retraso, compresión y redes de actividades

3. Suponga que se evaluó el mejor de los casos, el más proba- d. Un proyecto; a pesar de tener varias rutas críticas, en
ble y el peor caso para la estimación de la duración de una realidad es probable que disminuya el riesgo general
actividad y se determinó que eran 3 días, 4 días y 8 días, del proyecto.
respectivamente. Utilizando técnicas de estimación PERT,
5. ¿Cuál de las siguientes circunstancias requeriría la crea-
¿cuál sería la duración prevista para la actividad?
ción de una relación de retraso en un diagrama de red?
a. 4 días
a. La ruta crítica
b. 8 días
b. La inserción de una variable ficticia en un diagrama
c. 5 días
de red
d. 4.5 días
c. Un retraso después de pintar una habitación para per-
4. Suponga que ha creado la red de actividades y descubrió mitir que la pintura se seque, antes de comenzar a colo-
que tenía dos rutas críticas en el proyecto. Usted comparte car la alfombra del piso de la habitación
esta información con otro gerente del proyecto, quien sos- d. Una relación de fin temprano entre dos actividades
tiene firmemente que un proyecto solo puede tener una
sola ruta crítica, por lo que los cálculos no son correctos. Respuestas: 1. b—Acelerar el proyecto mediante la adición de
¿Cuál es el argumento correcto de esa afirmación? recursos en las actividades críticas se conoce como “comprimir”
a. Un proyecto puede tener más de una ruta crítica; al el proyecto; 2. c—Se emplean actividades dummy en los dia-
tener varias rutas críticas también es probable que au- gramas de red actividad en flecha (AOA); 3. d—La estimación
mente el riesgo de que el proyecto se retrase. PERT llevaría al cálculo (3 + (4 × 4) + 8)/6 = 27/6 o 4,5 días;
b. Su compañero de trabajo está en lo correcto: un pro- 4. a—Tener más de una ruta crítica es posible; sin embargo,
yecto solo puede tener una ruta crítica. Es necesario cuanto más actividades existan en la(s) ruta(s) crítica(s), mayor
volver a la red y determinar dónde se cometió un error será el riesgo para el cronograma del proyecto, ya que los retra-
en el desarrollo de la lógica de la red y del diagrama. sos en las actividades críticas retrasarán la ejecución del pro-
c. El camino crítico es el camino más corto a través de la yecto; 5. c—Permitir que la pintura se seque antes de comenzar
red, por lo que tener más de uno no es un problema la siguiente actividad es un ejemplo de una relación de retraso
significativo. que se produce entre las actividades.
Proyecto integrado 363

PROYECTO INTEGRADO

Desarrollo del cronograma del proyecto


Desarrolle un cronograma detallado para su proyecto inicial basado en la estructura de desglose del trabajo (EDT)
que ha completado. Usted tendrá que completar varias actividades en esta etapa: (1) crear un diagrama de prece-
dencia de actividades que muestre la lógica de la red para cada actividad que haya identificado en el proyecto; (2)
elaborar una tabla de duración de la actividad que muestre los tiempos optimista, probable y pesimista para cada
tarea; y (3) crear el diagrama de red y el diagrama de Gantt para el proyecto, indicando la ruta crítica, la duración
total del proyecto y todas las actividades con holgura.
Al momento de preparar el diagrama de predecedencia, considere:
1. ¿Se han identificado oportunidades para crear rutas paralelas o estamos poniendo demasiadas activi-
dades directamente en una ruta en serie?
2. ¿Es correcta nuestra lógica en la identificación de las actividades predecesoras y sucesoras?
3. ¿Hay algunos hitos claros que podemos identificar a lo largo del diagrama de precedencia?
Mientras se prepara la tabla de duración de actividades, es posible que desee definirla en los siguientes
términos:

Duración

Actividad Optimista Problable Pesimista Duración


A 6 9 18 10
B 3 8 13  8

Por último, se desarrolla el diagrama de red y las gráficas de Gantt, usando MS Project o un paquete
de software de programación similar (véanse los ejemplos de las pantallas 10. 6, 10. 7 y 10.8a, 10.8b y 10.8c).

Programación para el proyecto de ejemplo, ABCups, Inc.

Tareas Duración (en días)


Solicitud de viabilidad  1
Obtener la aprobación técnica  5
Determinar si es necesario trabajo adicional  4
Investigar acerca del equipo 26
Determinar los mejores proveedores 21
Reunirse con los proveedores 21
Obtener cotizaciones de los proveedores 21
Elegir el proveedor 14
Negociar precio y condiciones  7
Obtener financiamiento para el equipo  3
Calcular ROI  3
Obtener las firmas requeridas  3
Aprobar capital 10
Emitir el pedido  1
Producción del equipo 40
Nuevo proceso de comercialización 21
Crear anuncio publicitario 15
Diseñar nuevo folleto  9
Actualizar el sitio web  9
Diseñar la planta para el nuevo equipo 15
Nota: esta es una red y cronograma de actividad parcial.
364 Capítulo 10  •  Programación del proyecto. Retraso, compresión y redes de actividades

PANTALLA 10.6  Diagrama de Gantt parcial para el proyecto ABCups, Inc. (lado izquierdo)

PANTALLA 10.7  Diagrama de Gantt parcial para el proyecto ABCups, Inc. (lado derecho)
Proyecto integrado 365

PANTALLA 10.8a  Diagrama de red para el proyecto ABCups, Inc. (lado izquierdo)

PANTALLA 10.8b  Diagrama de red Para el proyecto ABCups, Inc. (centro)

PANTALLA 10.8c  Diagrama de red Para el proyecto ABCups, Inc. (lado derecho)
366 Capítulo 10  •  Programación del proyecto. Retraso, compresión y redes de actividades

Notas
1. Blass, G. (2008). “Boeing’s 787 Dreamliner has a compos- xml&channel=comm; Sanders, P., and Cameron, D. (2011,
ite problem,” www.zimbio.com/Boeing+787+Dreamliner/ 19 de enero). “Boeing again delays 787 delivery,”Wall Street
articles/18/Boeing+787+Dreamliner+composite+p Journal, p. B3.
roblem;Cohan, P. (2010). “Yet another problem for 2. Nicholas, J. M. (1990). Managing Business & Engineering
Boeing’s 787 Dreamliner,” www.dailyfinalance.com/ Projects. Englewood Cliffs, NJ: Prentice-Hall; Hulett,D.
story/company-news/yet-another-problem-for-boeings- (1995). “Project schedule risk assessment, ”Project
787-dreamliner/19734254/;Done, K. (2007, 10 de octu- Management Journal, 26(1): 23–44; Lock, D. (2000).
bre). “Boeing 787 Dreamliner hitby delays,”Finalancial ProjectManagement, 7th ed. Alders hot: Gower; Oglesby, P.,
Times, www.ft.com/cms/s/0/d42602de-774c-11dc-9de8- Parker, H., and Howell, G. (1989). Productivity Improvement
0000779fd2ac.html#axzz17R08yXyV; “The 787 encoun- in Construction.New York: McGraw-Hill.
ters turbulence.” (2006, 19 de junio). www.businessweek. 3. Brooks, F. P., Jr. (1994). The Mythical Man-Month: Essays
com/magazine/content/06_25/b3989049.htm;Johnsson, on Software Engineering, Anniversary Edition. Reading,MA:
J. (2010, 4 de diciembre). “787 Dreamliner proving be Addison-Wesley; Cooper, K. G. (1998). “Four failuresin
deviling for Boeing, ”Chicago Tribune, http://articles. project management,” in Pinto, J. K. (Ed.), The Project
chicagotribune.com/2010-12-04/business/ct-biz-1205- Management Institute Project Management Handbook. San
787-delay-20101204_1_dreamliner-teal-group-richard- Francisco, CA: Jossey-Bass, pp. 396-424; Ibbs, C. W., Lee,S.
aboulafia;Lemer, J. (2010, 4 de diciembre). “Boeing 787 A., and Li, M. I. (1998). “Fast-tracking’s impact on project
risks further delays, ”Finalancial Times, www.ft.com/ change,”Project Management Journal, 29(4): 35-42.
cms/s/0/941df738-ee8a-11df-9db0-00144feab49a. 4. Gray, C. F., and Larson, E. W. (2003). Project Management.
html#axzz17QyTnbm0;Norris, G. (2010, 15 de noviembre). Burr Ridge, IL: McGraw-Hill.
“787 schedule hinges on fire investigation, ”Aviation Week, 5. Shtub, A., Bard, J. F., and Globerson, S. (1994). Project
www.aviationweek.com/aw/generic/story.jsp?id=news/ Management: Engineering, Technology, and Implementation.
avd/2010/11/15/09.xml&channel=com; Norris, G. (2010, 26 Englewood Cliffs, NJ: Prentice-Hall; Navarre, C., and Schaan,
de noviembre). “787design and software changes follow fire, J. (1990). “Design of project management systems from top
”Aviation Week, www.aviationweek.com/aw/generic/story. management’s perspective,”Project Management Journal,
jsp?id=news/awx/2010/11/24/awx_11_24_2010_p0-272395. 21(2), pp. 19–27.
CAPÍTULO

11
Programación de proyectos
con cadena crítica

Contenido del capítulo


PERFIL DE PROYECTO 11.4 CADENA CRÍTICA: UNA SOLUCIÓN PARA LA
Suiza celebra la finalización del túnel más largo del PROGRAMACIÓN DEL PROYECTO
 mundo Desarrollo de la red de actividades de cadena crítica
INTRODUCCIÓN Soluciones de cadena crítica versus soluciones de ruta
11.1 LA TEORÍA DE LAS RESTRICCIONES Y LA  crítica
PROGRAMACIÓN DE PROYECTOS CON PERFIL DEL PROYECTO
CADENA CRÍTICA Eli Lilly Farmaceuticals y su compromiso con la
Teoría de las restricciones   gerencia de proyectos con cadena crítica
Causas comunes y especiales de la variación 11.5 SOLUCIONES DE CADENA CRÍTICA A LOS
11.2 CCPM Y LAS CAUSAS DE RETRASOS DEL CONFLICTOS DE RECURSOS
PROYECTO 11.6 GERENCIA DEL PORTAFOLIO DE PROYECTOS
Método uno: sobreestimación de la duración de las CON CADENA CRÍTICA
  actividades individuales INVESTIGACIÓN DE GERENCIA DE PROYECTOS EN
Método dos: margen de seguridad del gerente del SÍNTESIS
 proyecto Ventajas de la programación con cadena crítica
Método tres: anticiparse a los recortes esperados de la 11.7 CRÍTICAS A LA CCPM
  alta gerencia Resumen
11.3 CÓMO LOS EQUIPOS DE PROYECTOS Términos clave
DESPERDICIAN LA SEGURIDAD EXTRA Problemas resueltos
ADQUIRIDA Preguntas para discusión
Método uno: síndrome del estudiante Problemas
Método dos: omitir la variación positiva Estudio de caso 11.1 Judy, a la caza de la honestidad
Método tres: consecuencias negativas de la multitarea Estudio de caso 11.2 Ramstein Products, Inc.
Método cuatro: demora por rutas con actividades Ejercicios en internet
 convergentes Notas

Objetivos de aprendizaje
Al finalizar el capítulo, el estudiante estará en capacidad de:
1. Entender la diferencia entre causas comunes y especiales de variación en las organizaciones.
2. Reconocer las tres formas en que los equipos de proyecto sobreestiman la cantidad de seguridad para todas las
tareas del proyecto.
3. Entender las cuatro formas en que se puede perder la seguridad adicional de las tareas del proyecto.
4. Distinguir entre las técnicas de programación de proyectos con ruta crítica y con cadena crítica.
5. Comprender cómo la metodología de la cadena crítica resuelve los conflictos de recursos del proyecto.
367
368 Capítulo 11  •  Programación de proyectos con cadena crítica

6. Aplicar la gerencia de proyectos de la cadena crítica en los portafolios de proyectos.

CONCEPTOS BÁSICOS DE LOS FUNDAMENTOS PARA LA GERENCIA DE PROYECTO


(PROJECT MANAGEMENT BODY OF KNOWLEDGE,PMBOK® GUIDE, 5A. EDICIÓN)
CUBIERTOS EN ESTE CAPÍTULO
1. Secuenciar actividades (PMBOK®, sección 6.2).
2. Estimar los recursos de las actividades (PMBOK®, sección 6.3).
3. Estimar las duraciones de las actividades (PMBOK®, sección 6.4).
4. Desarrollar el cronograma (PMBOK®, sección 6.5).
5. Controlar el cronograma (PMBOK®, sección 6.6).
6. Desarrollar el cronograma (técnicas y herramientas) (PMBOK®, sección 6.5.2).
7. Método de la cadena critica (PMBOK®, sección 6.5.2.3).
8. Nivelar recursos (PMBOK®, sección 6.5.2.4).

PERFIL DE PROYECTO

Suiza celebra la finalización del túnel más largo del mundo


El viernes 15 de octubre del 2010, los trabajadores se reunieron para ser testigos de la culminación del túnel más
largo del mundo, el cual atraviesa los Alpes suizos, mientras el país celebraba la finalización de la primera etapa
crítica de un proyecto que había tomado casi 20 años en lograrse. El Gotthard Base Tunnel, como se conoce el
proyecto, es el resultado de un plan de casi 70 años, formulado para hallar un medio más económico y eficiente
del transporte de mercancías a través de la accidentada geografía de los Alpes suizos. Cuando los perforadores
extraían los últimos metros de tierra, completaban un túnel de 35.4 kilómetros que servirá como medio de trans-
porte para este país montañoso. Debido a que el proyecto en realidad consta de un par de túneles de 10 metros de

CHRISTIAN HARTMANN/REUTERS/Newscom

FIGURA 11.1  Los trabajadores celebran la salida de la perforadora Bit Breaking por la sección
final del túnel
(continúa)
 369

diámetro, dispuestos a lado a lado, la excavación total del proyecto incluyó pozos adicionales, túneles y pasos para
una longitud total de 94.3 millas. El plan actual es comenzar por las vías del tren en el túnel para darles cabida a
trenes de alta velocidad. La apertura del túnel se prevé, para los viajeros, en 2017.
El plan original de un túnel bajo los Alpes se basó en la necesidad de transportar mercancías de un extremo
del país al otro. Infortunadamente, viajar por las carreteras montañosas produce desgaste de los vehículos, por no
hablar de la congestión que se acumula, debido a los cientos de camiones que transitan a diario por las carreteras
empinadas. Una combinación de preocupación por el medio ambiente y frustración por los retrasos constantes, la
monstruosidad del tráfico de camiones y la degradación permanente de las vías y de los puentes llevó al Gobierno
suizo a iniciar el proyecto de túnel. Otro de los objetivos de desarrollo del túnel era fomentar una mejora adicional
de la red ferroviaria europea de alta velocidad. El túnel que se utiliza actualmente, más corto y más alto, tiene
capacidad para solo tres trenes de carga de hasta 2,000 toneladas. El nuevo túnel dará vía a trenes de carga de
4,000 toneladas, por el corazón de las montañas. Los trenes de pasajeros podrán viajar a velocidades de hasta 250
kilómetros por hora, lo que equivale, en tiempo, a un viaje en tren entre Zurich y Milán de solo 2 horas y 40 minu-
tos, un tercio menos que en la actualidad.
Construir túneles es un procedimiento peligroso. En la perforación del túnel, los trabajadores han retirado
más de 23 millones de toneladas de roca. Más de 2,600 personas han trabajado conjuntamente en el proyecto,
luchando contra el polvo, el ruido, la humedad y temperaturas de 30 grados Celsius (casi 90 grados Fahrenheit).
Ocho trabajadores han perdido la vida hasta el momento en la construcción del túnel Gotthard Base. Durante la
construcción del antiguo túnel Gotthard Base, en el siglo xix, murieron cerca de 300.
Uno de los problemas era la inestabilidad básica de las formaciones de roca en profundidad, lo que produjo
riesgos imprevistos. Por ejemplo, en la perforación de los túneles, los trabajadores utilizaron simultáneamente
ocho gigantescas máquinas perforadoras de 3,000 toneladas. Un pozo de 800 metros de largo fue perforado
verticalmente en la montaña, para que los trabajadores pudieran comenzar a trabajar en medio del túnel. Sin
embargo, con frecuencia, las enormes máquinas de perforación no podían hacer el trabajo por cuenta propia. En
las zonas donde la roca era particularmente frágil, los trabajadores se vieron obligados a utilizar métodos más
tradicionales, como los explosivos. Triturar las capas de formación geológica de los Alpes resultó particularmente
problemático.
Otro problema fue que a menudo era imposible predecir qué encontrararían los trabajadores al excavar. Por
ejemplo, el 31 de marzo de 1996, los expertos de perforación llevaban a cabo las pruebas geológicas en un tramo
del túnel, cuando de repente golpearon una capa conocida como la Piora Mulde. De repente, una gran cantidad de
agua y arena salió disparada del eje del taladro con una fuerza inimaginable. La Piora Mulde es una banda estre-
cha, vertical, en el corazón de los Alpes, formada por dolomita finamente molida, un sedimento mineral blanco,
cristalino que se asentó en el fondo de un mar hace 230 millones de años. Mezclada con agua, la sustancia se torna
impredecible, y es un reto difícil de superar para los ingenieros del túnel. En ese día de marzo de hace más de 10
años, miles de metros cúbicos de la materia inundaron desde el eje del taladro. Fue un milagro que ninguno de los
trabajadores presentes resultaran heridos.
“Nadie ha trabajado con este tipo de material a tal profundidad”, dice el geo-técnico Georgios Anagnostou,
del Swiss Federal Institute of Technology en Zurich. En estas zonas, los ingenieros del túnel se vieron obligados a
resolver una especie de juego de azar. Aplicando una enorme presión, empujaron el material más suave en el túnel
(llamado “distorsiones”) e instalaron tubos gruesos en esos segmentos. Los modelos de computador habían pro-
nosticado distorsiones de hasta un metro y, al final, resultaron de alrededor de 80 centímetros. Los trabajadores,
en últimas, tuvieron éxito en estabilizar lo inestable. “Vale la pena mencionar que ya no hay ninguna parte del
túnel donde se encuentran las distorsiones “, dice Anagnostou.
Pero se descubrieron otros problemas. En el lugar donde una de las paradas de emergencia debía construirse,
los ingenieros detectaron otra zona de inestabilidad, lo que aumentaba la posibilidad de derrumbes. La gran
caverna que albergaría la estación subterránea de emergencia tuvo que construirse en un sitio diferente, más al
sur. Justo cuando un problema se corregía, otro surgía; por ejemplo, en el mismo segmento de túnel, una de las
máquinas de perforación se atascó y fue sepultada por los escombros que cayeron del techo del túnel. Los trabaja-
dores tenían que moler y quitar la piedra que había taponado el túnel; luego el techo fue estabilizado, utilizando
acero y hormigón. Incidentes similares ocurrieron en otras partes del túnel. En un momento, una de las máquinas
de perforación permaneció inutilizada durante seis meses completos, mientras que a solo 40 metros de distancia,
en el túnel paralelo, los trabajadores no encontraban ningún problema.
En su reto por crear el túnel más largo del mundo, el consorcio liderado por Suiza se ha encontrado con
todo tipo de problemas, muchos de los cuales no podrían haberse previsto. Los esfuerzos exitosos por finalizar el
primero y más importante paso—la fase de perforación—han sido un testimonio de las habilidades de ingeniería,
solución creativa de problemas y compromiso firme por salir adelante en una empresa que se espera traerá ven-
tajas a los viajeros, al Gobierno suizo y a la población en general. Aunque todavía en construcción, el proyecto
Gotthard Base Tunnel es un ejemplo fascinante de una solución creativa a largo plazo de las apremiantes necesi-
dades nacionales suizas.1
370 Capítulo 11  •  Programación de proyectos con cadena crítica

INTRODUCCIÓN
Los enfoques de programación basados en las técnicas CPM/PERT se aceptan generalmente como proce-
dimiento operativo estándar en la mayoría de las organizaciones basadas en proyectos. Sin embargo, con
frecuencia se presentan inconvenientes cuando empezamos a vincular las necesidades de recursos a nuestros
cronogramas establecidos. Como veremos en el capítulo 12, el problema de los recursos limitados frecuen-
temente reduce la flexibilidad al crear una programación óptima para el proyecto. En los últimos años, un
enfoque alternativo de programación con el nombre de Gerencia de proyectos con cadena crítica (Critical
Chain Project Management: CCPM) es cada vez más popular. Esta alternativa fue desarrollada a mediados
de la década de 1990 por el doctor Eli Goldratt. CCPM presenta algunas diferencias y ventajas respecto a
las metodologías comunes de la ruta crítica. Lucent Technologies, Texas Instruments, Honey y la industria
de la aviación israelí se encuentran entre un grupo diverso de organizaciones notables que han hallado las
premisas de la CCPM suficientemente ventajosas para comenzar la difusión de este proceso a través de sus
operaciones de proyectos.2
En este capítulo se analizarán algunos de los componentes de la Gerencia de proyectos con cadena
crítica. Veremos cómo, según sus defensores afirman, este mecanismo de programación alternativa promete
acelerar la ejecución de los proyectos, hacer un mejor uso de los recursos del proyecto y asignar y discipli-
nar de manera más eficiente el proceso de ejecución de los proyectos. El modelo se basa en la teoría de las
restricciones (theory of constraints: TOC), de Goldratt, que se propuso originalmente como un procedi-
miento para eliminar los cuellos de botella en los procesos de producción. En su configuración actual, TOC
también ofrece algunas pautas para la gerencia de proyectos. Una característica clave de la CCPM es que
representa a la vez un cambio cultural y un cambio en los procesos de planeación. En la práctica, si la teoría
de CCPM se aplica correctamente, los elementos técnicos y de comportamiento deben entenderse entre sí. El
capítulo se centra en estos aspectos del proceso.

11.1 LA TEORÍA DE LAS RESTRICCIONES Y LA PROGRAMACIÓN DE


PROYECTOS CON CADENA CRÍTICA
En la práctica, las redes de programación construidas en los dos capítulos anteriores, usando PERT y esti-
maciones probabilísticas de las duraciones, dependen de los recursos. Es decir, la exactitud de estas estima-
ciones y de la programación de nuestros proyectos son sensibles a la disponibilidad de recursos; los recursos
críticos del proyecto deben estar disponibles en las cantidades necesarias y en el momento preciso para que
el cronograma funcione según lo previsto. Una de las consecuencias de la utilización de la programación
“inicio temprano” es que el gerente del proyecto debe estar consciente de proteger las holguras durante todo
el proyecto. Cuanto más podamos conservar esta holgura, mejor “buffer” (reserva) tendremos contra cual-
quier imprevisto o insuficiencia de recursos posteriores. Por tanto, los gerentes de proyectos frecuentemente
permanecen a la defensiva, preparándose para los problemas, mientras realizan un seguimiento cuidadoso
a la disponibilidad de recursos para conservar los tiempos de holgura. El concepto de la teoría de las restric-
ciones, al aplicarse en la gerencia de proyectos por cadena crítica, representa un método alternativo para la
gerencia de las holguras y para la utilización de los recursos del proyecto de forma más eficiente.

Teoría de las restricciones


Originalmente desarrollada por Goldratt, la teoría de restricciones (TOC) fue descrita por primera vez en su libro
The Goal (1984), para aplicaciones en ambientes de producción.3 Uno de los puntos más importantes planteados
por este autor era que, por lo general, la mayoría de efectos de los pobres resultados dentro de las operaciones
comerciales se derivaban de un número muy pequeño de causas; es decir, cuando nos remontábamos a sus orí-
genes, muchos de los problemas que tratábamos eran el resultado de pocos problemas fundamentales. La idea
principal que subyace a la TOC es la noción de que cualquier “sistema debe tener una restricción. De lo contrario,
su resultado podría aumentar sin límite, o tendería a cero.”4 La clave está en identificar la restricción central dentro
del sistema. Cinco etapas conforman el mensaje principal de la metodología TOC (véase la figura 11.2):
1. Identificar la restricción del sistema.  En primer lugar, se debe hacer una búsqueda intensiva para
descubrir la restricción principal, su causa raíz, que limita el resultado del sistema. Es importante no
estancarse en la identificación de numerosas causas secundarias o de “pequeños problemas.”
2. Explotar la restricción del sistema.  Una vez identificada la restricción, se requiere determinar una
estrategia para focalizar y visualizar todas las actividades en términos de esta restricción. Por ejemplo,
11.1  La teoría de las restricciones y la programación de proyectos con cadena crítica 371

1. Identificar la restricción
del sistema

5. Reevaluar 2. Explotar la
el sistema restricción del sistema

4. Elevar la 3. Subordinar todo


restricción lo demás a la restricción
del sistema del sistema

FIGURA 11.2  Cinco pasos claves en la teoría de las restricciones

si la restricción dentro de una empresa de desarrollo de software es tener solo un programador de apli-
caciones avanzadas, la secuencia de todos los trabajos del proyecto por realizar por el programador tie-
nen que programarse primero a lo largo de todo el portafolio de proyectos activos de la organización.
3. Subordinar todo lo demás a la restricción del sistema.  Asigne los recursos o tome las decisiones de
programación, después de administrar las necesidades de la restricción raíz. En el ejemplo anterior,
una vez que la “restricción del recurso crítico”, un programador, se ha identificado y se ha programado
el tiempo del programador, en varios proyectos, se programa el resto de las actividades del proyecto.
4. Elevar la restricción del sistema.  Los tres primeros pasos reconocen que la restricción del sistema limita
las operaciones de la organización. De acuerdo con Goldratt, el cuarto paso es mejorar el sistema mediante
la elevación de la restricción, o tratar de resolver el problema mediante la eliminación de la restricción que
genera el cuello de botella. En nuestro ejemplo, programación de software, esto puede significar la con-
tratación de otro programador de aplicaciones avanzadas. En muchos proyectos, “elevar la restricción del
sistema” puede ser tan simple como adquirir recursos adicionales en los momentos oportunos.
5. Determinar si se descubre una nueva restricción y luego repetir el proceso.  Claramente, la elimina-
ción de la restricción clave del sistema dará lugar a ventajas positivas durante un tiempo. Sin embargo,
puesto que siempre hay una restricción en el sistema, la eliminación de una restricción solo permite
identificar una nueva fuente de restricción en la operación. La TOC promueve la necesidad de prepa-
rarse siempre para tratar con el siguiente problema potencial, antes de que este sea torne demasiado
serio, por lo que este último paso es realmente solo un paso más en un ciclo de mejora continua.
Al examinar la programación del proyecto desde el punto de vista de la metodología TOC, nos centramos
en la restricción clave del sistema, es decir, la causa raíz por la cual se generan todos los demás problemas del cro-
nograma. Inicialmente se pensó que la restricción principal en un sistema de proyectos era la ruta crítica. Recuerde
que la ruta crítica se define como el momento más temprano posible, en la red de actividades, que se puede tomar
para completar el proyecto. Si se retrasan las actividades de la ruta crítica, el efecto son retrasos en el proyecto en
general. La ruta crítica se determina por la serie de actividades cuyas duraciones definen el camino más largo a tra-
vés de la red y, por tanto, representa lo más temprano posible en que se puede finalizar el proyecto. Goldratt señala
que todos los problemas asociados con la programación y los recursos se producen, por lo general, por tratar de
mantener la ruta crítica, y de ahí que se identifique, con frecuencia, como la principal restricción del sistema.5

Causas comunes y especiales de la variación


Un error común en muchas organizaciones es suponer de forma rutinaria que cada evento (error, accidente
o defecto) es atribuible a una fuente directa o persona. Por tanto, es común considerar que esos errores sean
indicativos de problemas generales dentro de la organización y sus operaciones.6 Rutinariamente erramos al
suponer que esa variación (fallas en el sistema) se genera por causas especiales y no causas comunes. Uno de
372 Capítulo 11  •  Programación de proyectos con cadena crítica

los autores industriales más importantes de la última parte del siglo xx, el doctor J. Edwards Deming, sugirió
que una de las principales fuentes de conocimiento profundo que se debe adquirir a partir de estudiar la acti-
vidad organizacional es la “comprensión de la variación.” Él identificó dos tipos de variación:7
1. La causa común de la variación es inherente al sistema; existe la posibilidad de que se presenten fallas
debido a la forma como se creó originalmente el sistema.
2. La causa especial de la variación se atribuye a una circunstancia especial. Por ejemplo, pueden ser
específicas a un grupo de trabajadores, pieza de maquinaria o condición local.
Lo más importante por destacar del concepto de la variación es que se debe identificar la principal res-
tricción del sistema. Todos los proyectos contienen como causa común de la variación cuánto tiempo se tarda
en completar las actividades del proyecto. Esta variación se refiere al rango normal de incertidumbre en el ren-
dimiento de la ejecución de cualquier actividad. Debido a que el enfoque más común de secuenciamiento de las
actividades para la programación es la conexión “final a inicio”, se deduce que los proyectos contendrán un grado
de variación estadística basada en la cadena de eventos dependientes. Según Deming, suponer que esta variación
estadística se presenta por causas especiales y no por causas comunes es un error frecuente. Esto se debe a que,
junto a la definición de proyecto como “único en su clase”, se tiende a definir también como únicas todas las acti-
vidades del proyecto, o como fuentes de variación de causas especiales que no están sujetas a control estadístico.
Por tanto, cuando surgen problemas, reaccionamos ante ellos de forma individual, en lugar de buscar en el sis-
tema la fuente de la causa subyacente. Este tipo de respuesta a la variación puede llevar a la gerencia a reaccionar
de forma exagerada, a confundir la respuesta correcta de la inmediata o a intentar corregir los problemas sistémi-
cos (variación de causa común), porque se perciben como únicos (variación de causa especial).8
Un ejemplo de empresas que tratan las dificultades derivadas de la variación por causas comunes como si
fueran producto de causas especiales se ilustra con el caso en que la alta gerencia de una empresa le exigió al gerente
del proyecto presentar un informe detallado del avance del proyecto, cada dos semanas. Supongamos que en una
de esas reuniones de seguimiento, los altos ejecutivos señalaron una desviación de 5% del cronograma frente a
lo previsto en el proyecto. En lugar de tratar este hecho como un simple caso de variación de causa común que
podría corregirse en el curso natural del desarrollo del proyecto en las próximas semanas, el grupo de alta gerencia
reaccionó exageradamente y ordenó la evaluación detallada del proyecto (y de costos) para “corregir” el problema.
En este caso, la alta gerencia eligió tratar la desviación como resultado una variación de causa especial, suponiendo
que un problema único había surgido. El resultado final en situaciones como estas, en las que la variación de causa
común se trata como una de causa especial, es llevar a la organización a buscar un “problema” específico, con lo
cual se pierde mucho tiempo y dinero en esta tarea, a pesar de no ser necesario.
Deming ilustra la distinción entre causa común y causa especial, con un ejercicio de embudo. El
embudo deja caer una canica sobre una hoja de papel doblada en cuartos, con un punto medio que indica el
origen del problema (véase la figura 11.3). El objeto es dejar caer la canica directamente en el punto de origen,

1.5

0.5

0
–2 –1.5 –1 –0.5 0 0.5 1 1.5 2
–0.5

–1

–1.5

–2
FIGURA 11.3  Distribución basada en variación de causa común
Fuente: L. P. Leach. (1999). “Critical chain project management improves
project performance,” Project Management Journal, 30(2), 39–51, figura
en la página 42. Derechos reservados © 1999 por Project Management
Institute Publications. Todos los derechos reservados. El material de esta
publicación ha sido reproducido con permiso del PMI.
11.1  La teoría de las restricciones y la programación de proyectos con cadena crítica 373

1.5

0.5

0
–2 –1.5 –1 –0.5 0 0.5 1 1.5 2
–0.5

–1

–1.5

–2
FIGURA 11.4  Distribución basada en la mala interpretación de la varianza
Fuente: L. P. Leach. (1999). “Critical chain project management improves
project performance,” Project Management Journal, 30(2), 39–51,fig-
ureon page 42. Copyright © 1999 por Project Management Institute
Publications. Todos los derechos reservados. El material de esta publi-
cación ha sido reproducido con permiso del PMI.

lo cual indica que no hay varianza. Como muestra la figura, en un ejercicio de muestra en el que el embudo se
mantuvo fijo en un lugar, el patrón de caída de la canica sobre el papel se agrupa alrededor del punto medio.
Este patrón representaría un ejemplo de variación de causa común.
Ahora, supongamos que la persona dejar caer la canica reaccionando a cada golpe en el papel,
mediante el reposicionamiento del embudo para compensar el error (la distancia desde el origen al punto
en que la canica cae). Se mueve el embudo en la misma distancia, pero en la dirección opuesta, desde el
punto donde la canica golpea el objetivo. Esta es la típica reacción de un gerente que responde a la varianza
y trata de corregirla. Por ejemplo, si se establece que una actividad del proyecto se ha retrasado 10% res-
pecto a lo previsto, el gerente del proyecto puede reorientar los recursos para responder al problema.
Tenga en cuenta el resultado, como Deming señaló, cuando el gerente realiza una serie de movimientos
discretos, reactivos en respuesta a cada caso de varianza. La figura 11.4 muestra el nuevo patrón para la
canica basado en los movimientos realizados para compensar las respuestas subóptimas (no centradas
en el origen). La variación ha aumentado debido a que, como señala Deming, el gerente está malinter-
pretando la variación de causa común (inherente al sistema) como si fuera variación de causa especial
(exclusiva de la actividad).
Además, el tratamiento de la variación de causa especial, como si se tratara de una variación de causa
común, puede dar lugar a su propia serie de problemas. Confundir las formas discretas de riesgo del proyecto
con la variación de causa común general del sistema hace casi imposible llevar a cabo un análisis de riesgos y
un planteamiento de respuestas adecuado. Todo riesgo identificable es, por definición, una fuente de varia-
ción de causa especial.
Para aplicar el principio de variación de causa común a la teoría de CCPM, los escritores han reco-
mendado lo siguiente, basados en el análisis de Deming.
1. Entender la diferencia entre las causas comunes y especiales de la variación.
2. No realizar ajustes a los proyectos cuando la variación en el desempeño del proyecto (o duración de las
actividades) se encuentra dentro del rango de variación de causa común.
3. No incluir la variación de causa especial en la simulación de riesgos del proyecto. Esto hace que el
equipo del proyecto tienda a sobreestimar la contingencia del cronograma del proyecto.
4. Realizar la gerencia de riesgos del proyecto sobre los riesgos discretos; no agregar riesgos.
Incluso cuando se utilizan modelos de simulación Monte Carlo, se puede desestimar ampliamente el
tiempo necesario para completar las actividades. Los controles estadísticos de programación de proyectos
implican que los gerentes deben tener una visión realista en la asignación del tiempo de contingencia. Una
fuente para cometer errores en la estimación se encuentra en el concepto de variación de causa común
versus la de causa especial. Otras razones, como Goldratt y otros han señalado, se relacionan con el com-
portamiento natural.9
374 Capítulo 11  •  Programación de proyectos con cadena crítica

11.2  CCPM Y LAS CAUSAS DE RETRASOS DEL PROYECTO


CCPM tiene mucho que decir acerca de la naturaleza de las causas de la inexacta estimación de la duración de las
actividades del proyecto. En primer lugar, el mundo real es una de las fluctuaciones estadísticas, por lo que, de
acuerdo con CCPM, una estimación puntual no es adecuada y da un rango de valores para la duración. Deming
diría que este proceso es otro ejemplo de la incapacidad de los equipos de proyecto para comprender la variación.
Sin embargo, incluso aceptando la falacia de las equivocadas estimaciones puntuales para la duración, una serie de
aspectos pueden distorsionar la estimación exacta de la duración. Muchas de estas causas, sostiene Goldratt, son
comportamientos naturales, en lugar de aspectos técnicos (relacionados con las métricas pobres de estimación).
Específicamente, CCPM sugiere que hay varias maneras en que los miembros del proyecto pueden, de forma ruti-
naria, añadir seguridad (holgura del proyecto) a la duración estimada de las actividades del proyecto.

Método uno: sobreestimación de la duración de las actividades individuales


Cuando se estima la cantidad de tiempo necesario para completar una actividad, es común que los miembros
del equipo construyan sus estimaciones con bastante holgura, a fin de sentirse seguros de que serán capaces de
completar el proyecto en del tiempo previsto. Por ejemplo, cuando alguien viaja a una reunión pregunta cuánto
tiempo se tardará en coche desde Washington, D.C., a Baltimore, Maryland, la respuesta razonable podría ser
45 minutos. Sin embargo, si se asocian las sanciones por llegar tarde a la reunión, es más probable que la res-
puesta incluya un tiempo adicional para los posibles imprevistos durante el viaje (desvíos, pinchazos, exceso de
velocidad o tráfico pesado). Con estas contingencias en mente, la nueva conjetura razonable podría ser de una,
dos o incluso más horas para recorrer una ruta que normalmente podríamos cubrir en 45 minutos. Los mismos
principios se aplican cuando cambiamos el ejemplo a un proyecto. Un miembro del equipo del proyecto encar-
gado de una tarea, probablemente asignaría suficiente tiempo de holgura adicional (de seguridad) para sentirse
razonablemente seguro de que cumplirá la fecha de entrega que prometerá.
La figura 11.5 muestra un ejemplo de una distribución gaussiana o logarítmica normal para el tiempo
estimado para completar un paquete de trabajo. Tenga en cuenta las probabilidades para la finalización de
la tarea como una función del tiempo. Cuanto más tiempo se le asigne a la tarea, mayor probabilidad de que
se termine en el plazo estipulado. Infortunadamente, como la distribución sugiere, con el fin de estimar la
terminación de una actividad con un grado de confianza de 90% o más alto, el tiempo puede sobreestimarse
200%. Razonablemente, se podría esperar que una actividad del proyecto se finalice el día 6 (basados en una
estimación media) * pero podría no prometerse hasta el día 18. Este exceso de holgura para las tareas indivi-
duales suma una enorme cantidad de tiempo adicional en la estimación del proyecto.

25%
50%

80%
90%

Tiempo

FIGURA 11.5  Distribución gaussiana (logarítmica normal)

Método dos: margen de seguridad del gerente de proyectos


Una vez que cada miembro del equipo ha hecho sus estimaciones de la duración de la actividad (con su factor de
seguridad para cada tarea), el gerente de proyectos consolida estas estimaciones en una estimación global para
el proyecto. Sin embargo, los gerentes de proyectos tienden a proteger su seguridad, al igual que los miembros
de su equipo lo hacen. Por lo general, agregan a sus propios márgenes según el nivel del proyecto en conjunto.

*La idea de emplear la estimación de la media de la distribución gaussiana es distinguirla de la estimación de probabilidad de 50%, basada
en la mediana. La media es linealmente independiente de la distribución, mientras que una probabilidad de 50% se refiere a la mediana,
que en una distribución asimétrica como la mostrada en la figura 11.5 puede ser significativamente diferente de la media de la distribución.
11.3  Cómo los equipos de proyectos desperdician la seguridad extra adquirida 375

Consideremos un caso en el que tres miembros del equipo, cada uno aporta a su gerente, estimaciones de 2 sema-
nas por cada actividad. Una consolidación normal de estas estimaciones individuales sería 2 + 2 + 2 = 6 semanas.
Sin embargo, debido a que los gerentes de proyectos, a su vez, les temen a los efectos por el incumplimiento de los
plazos, a menudo incluyen un factor como margen de seguridad adicional a nivel de proyecto. Por tanto, 2 + 2 +
2 puede ser igual a 8, 9, o incluso 10 semanas, en lugar de 6. El gerente del proyecto ha añadido un tiempo para
obtener algún tipo de protección personal en la programación general del proyecto.

Método tres: anticiparse a los recortes esperados de la alta gerencia


La tercera manera en que rutinariamente se incorpora una seguridad adicional a las actividades del proyecto,
se basa en el hecho de que la alta gerencia de una organización típicamente respalda programas dinámicos. A
menudo, los miembros del equipo directivo que examinarán el cronograma podrán decidir que es demasiado
largo, y exigirán recortes significativos. En un caso, la alta gerencia de una empresa se caracterizaba por su
insistencia en la reducción de las estimaciones de duración, en un mínimo de 20%. Con el tiempo, los equi-
pos de proyectos empezaron a reconocer este proceso y simplemente añadían un extra de 25% al cronograma
inicial, con el fin de proteger su horizonte de tiempo “real.”
Cuando se combinan, estas tres prácticas pueden conducir a duraciones extremadamente infladas, pero, lo
más importante, hablan de la falta de confianza dentro de la organización. Cuando la cultura de una organización
no fomenta la conducta auténtica, envía la señal de que lo que “realmente” se recompensan son los actos enfocados
a la autoprotección y al engaño en la ejecución de los proyectos, y no a la satisfacción de los clientes. En conjunto,
estas prácticas parecen tener en común la falta de disciplina de la organización en la ejecución de los proyectos.10

11.3  CÓMO LOS EQUIPOS DE PROYECTOS DESPERDICIAN LA SEGURIDAD


EXTRA ADQUIRIDA
Algunas de las formas en que se pierde tiempo en los proyectos son institucionales; son el resultado de las
actitudes culturales propagadas en la empresa o de lo que promueven las políticas de la organización. Otros
motivos de estos retrasos son producto de los comportamientos, derivados de los hábitos de trabajo indivi-
duales y de la pobre autodisciplina.

Método uno: síndrome del estudiante


El primer análisis de por qué los miembros del equipo desperdician el tiempo de la actividad del proyecto se llama
el síndrome del estudiante o modelo del paper final. Básicamente, se trata de la dilación, la tendencia a postergar
el máximo esfuerzo hasta el último momento posible. Este efecto ocurre en nuestro ejemplo (véase la figura 11.6),

100
Porcentaje finalizado del proyecto

Modelo del
"mundo perfecto"
50
Modelo de
curva de
aprendizaje

0
0 50 100

Porcentaje de tiempo transcurrido


FIGURA 11.6  Modelo del síndrome del estudiante
376 Capítulo 11  •  Programación de proyectos con cadena crítica

que vincula el porcentaje de tiempo transcurrido en una actividad con el porcentaje de trabajo completado. Esta
cifra representa el tipo de progreso que con frecuencia se encuentra en la realización de una actividad de pro-
yecto. A pesar de que una línea de proceso idealizada mostraría aumento constante del progreso desde la fecha de
inicio hasta la de terminación del proyecto, muchas personas tienden a retrasar el inicio de la actividad, siempre
y cuando sea posible, para concentrarse en tareas más visibles o críticas. Con el tiempo, sin embargo, según se
observa en la figura 11.6, los miembros del equipo del proyecto comienzan a darse cuenta de que la fecha hito se
acerca, y su esfuerzo aumenta de forma espectacular. El síndrome del estudiante es un modelo útil para resaltar el
esfuerzo común que se debe poner en el proyecto porque:
1. La gente tiende a minimizar las responsabilidades con largos plazos, a favor de los más inmediatos o
críticos.
2. Si la gente cree que se han añadido tiempo extra a sus estimaciones iniciales, los desmotiva enfrentar
estos compromisos desde el comienzo.
3. Los recursos de personal del proyecto de “alta demanda” deben hacer malabares con sus horarios
para darles cabida a múltiples compromisos, lo que impide empezar a abordar las tareas con plazos
largos en el momento oportuno.
La ley de Parkinson establece que el trabajo se expande hasta llenar el tiempo disponible. Rara vez, los
miembros del equipo terminan en menos del tiempo inicialmente previsto para realizar una tarea. La razón
de este fenómeno se encuentra, en parte, en el segundo método para el despilfarro del tiempo de seguridad.

Método dos: falla al transmitir la variación positiva


Cuando múltiples actividades se vinculan en un formato de final a inicio, como en el caso de la mayoría de las
redes de actividad estándar, cada actividad sucesora se encuentra a merced de sus predecesoras en términos
de cuándo puede comenzar. Los retrasos en la actividad del proyecto (variación negativa) conducen a retra-
sos adicionales aguas abajo, por lo que las actividades sucesoras deben iniciarse después; la holgura del ruta
se agota, y así sucesivamente. Cuando una actividad predecesora finaliza más temprano, sería natural esperar
que esta terminación temprana (variación positiva) se trasladara a lo largo de la ruta de la red en la que la
actividad se encuentra y se ganaría tiempo aguas abajo. Sin embargo, uno de los argumentos a las consecuen-
cias del comportamiento de la gerencia de proyectos sugiere que el caso opuesto ocurre con más frecuencia;
la variación positiva no es transmitida. ¿Por qué no? Hay diferentes razones:
1. Terminar una tarea temprano les da a los miembros del equipo del proyecto la oportunidad de trabajar
en otros proyectos o asignaciones de trabajo que esperan en sus escritorios. En efecto, las terminacio-
nes tempranas representan una oportunidad para poner un proyecto en espera durante un periodo,
con el fin de cumplir otros compromisos.
2. Los miembros del equipo temen que sus futuras estimaciones de tiempo de trabajo ya no sean tomadas en
serio si entregan el trabajo temprano. Al preguntarles a los miembros del equipo para calcular la cantidad
de tiempo necesario para completar una tarea, el gerente del proyecto confía en su juicio técnico. Si un
miembro del equipo estima que una tarea requerirá 6 días y lo entrega en 4, la próxima vez que se le pida
una estimación, su gerente de proyecto quiere recortar el valor con base en los resultados anteriores.
3. Algunas personas sienten la necesidad de hacer pequeños ajustes a sus asignaciones de tareas, para
utilizar tiempo adicional y refinar o modificar aún más los resultados. La variación positiva de los
miembros del equipo se considera una oportunidad para mejorar sus esfuerzos iniciales.

Método tres: consecuencias negativas de la multitarea


Podemos usar la palabra multitarea para describir la forma en que comúnmente los miembros del equipo de
proyecto se involucran en múltiples esfuerzos o tareas simultáneamente. Por rutina, en la mayoría de organi-
zaciones se espera que el personal del proyecto este activo en varios proyectos, actividades o tareas al mismo
tiempo y utilice la gerencia del tiempo y las habilidades de priorización para equilibrar eficazmente sus cargas
de trabajo. Cuando se espera que los miembros del equipo del proyecto dediquen su tiempo a, por ejemplo,
10 proyectos en lugar de centrarse exclusivamente en uno, la gerencia del tiempo puede ser un gran desafío.
La naturaleza de la multitarea también alarga el tiempo necesario para completar las tareas de cada proyecto,
como ilustra la figura 11.7. Supongamos que un miembro del equipo del proyecto tiene tres tareas por reali-
zar, cada una con una duración prevista de 10 días. La línea superior muestra las actividades establecidas, de
11.3  Cómo los equipos de proyectos desperdician la seguridad extra adquirida 377

A B C

10 10 10

A B C A B C

20

20

20

FIGURA 11.7  Efectos de la multitarea en la duración


de las actividades
Fuente: E. M. Goldratt, © 1997, “The Critical Chain.” Reproducido
con permiso de The North River Press Publishing Corporation.

extremo a extremo. En este escenario, debido a que los esfuerzos individuales están completamente dedicados a
una sola actividad a la vez, el tiempo total necesario para completar las tres asignaciones es 30 días.
Si se espera que la persona trabaje en las tres asignaciones de proyectos al mismo tiempo, dedicando
cinco días a un proyecto antes de pasar al siguiente, y así sucesivamente, obsérvese el efecto que se muestra en
la segunda, en la línea de fondo. La duración prevista para cada actividad del proyecto ha crecido de manera
dramática, a partir de los 10 días originales, a algo cercano a los 20 días por cada actividad. Con los efectos de
trabajar en un entorno multitarea, el tiempo real para completar cada tarea del proyecto se ha duplicado. El
problema se complica aún más por los efectos del tiempo de transición, o el tiempo extra que se requiere para
moverse entre las tareas. Por lo general, es un error suponer que una persona con multitareas pueda moverse
fácilmente de una asignación a la siguiente. Al retrasar o abandonar por un tiempo prolongado el trabajo
del proyecto sin terminarlo, tenemos que dar cuenta de más tiempo desperdiciado entre el fin y el inicio de
todas las tareas. Como resultado de la multitarea, es probable que no solo se duplique la duración real de la
actividad, sino que se aumente aún más allá de ese nivel.

Método cuatro: demora por rutas con actividades convergentes


La mayoría de proyectos tienen varias rutas de actividad. Por ejemplo, el diagrama PERT simple, que se
muestra en la figura 11.8, indica tres rutas distintas, la ruta crítica y dos adicionales o caminos no críticos.
En el punto de convergencia, cerca de la actividad final de la red del proyecto, tres caminos se fusionan en el
final, la ruta crítica justo antes de la terminación del proyecto. Los caminos con actividades convergentes tie-
nen el efecto de crear un filtro para eliminar cualquier holgura positiva. Todas las rutas de actividades que se
fusionan son confinadas a la ruta con mayor retraso. La figura 11.8 ilustra este fenómeno. Supongamos que

15 dias de retraso

Ruta A

Según lo programado 15 dias de retraso


Ruta B Ruta fusionada

15 días antes de lo previsto

Ruta C

FIGURA 11.8  Efecto de múltiples rutas con actividades convergentes


Fuente: L. P. Leach. (1999). “Critical chain project management improves project
performance,” Project Management Journal, 30(2), 39–51, figura en la página 44.
Copyright © 1999 por Project Management Institute Publications. Todos los derechos
reservados. El material de esta publicación ha sido reproducido con permiso del PMI.
378 Capítulo 11  •  Programación de proyectos con cadena crítica

las rutas A, B y C tienen la condición de programación asociados con ellos de 15 días de retraso, a tiempo,
y de 15 días de antelación, respectivamente. El problema es que en el movimiento aguas abajo del punto de
convergencia, lo más temprano que puede comenzar la actividad siguiente está determinado por la finali-
zación de la última actividad predecesora, en este caso la trayectoria A, que tiene 15 días de retraso. Como
resultado, los caminos C y B, que ya se han finalizado a tiempo o temprano, pierden su holgura positiva
debido a los retrasos asociados con el otro camino de convergencia.
El Project Management Institute’s Body of Knowledge (PMBOK®) identifica este problema en par-
ticular cuando señala que “las técnicas de análisis matemáticos tradicionales, como el método del ruta
crítica ... no tienen en cuenta las rutas de convergencia ... y, por tanto, tienden a subestimar la duración de
los proyectos.”11
El impacto de estos dos procesos de comportamiento —conducta diseñada para aumentar la seguridad
en la ejecución de la actividad del proyecto y el comportamiento que resulta en la pérdida de la seguridad— ilus-
tra el desafío que enfrentan los equipos al intentar programar y gerenciar de manera más eficiente sus proyectos.

11.4  CADENA CRÍTICA: UNA SOLUCIÓN PARA LA PROGRAMACIÓN DEL


PROYECTO
La solución de Goldratt a las variables que intervienen en la programación de proyectos consiste en la agrega-
ción, o colectivización, de todos los riesgos del proyecto en forma de estimaciones inciertas para la duración
y las fechas de entrega. La agregación de riesgos es un fenómeno bien conocido en el negocio de seguros.12 El
teorema del límite central establece que si se suman una serie de distribuciones de probabilidad, la varianza
de la suma es igual a la suma de las varianzas de las distribuciones individuales. La fórmula se acepta en dis-
tribuciones independientes de varianza igual V, como:

VR = n # V

donde V∑ es la suma de las varianzas.


La deviación estándar σ puede utilizarse como un sustituto para el riesgo, y como σ 2 = V, hallamos:

σR = (n) 1/2 # σ

donde σ ∑ es la suma de las desviaciones estándar. Por tanto:

σR 1 n # σ

Matemáticamente, la fórmula anterior ilustra el hecho de que la agregación de los riesgos conduce a una reduc-
ción de los riesgos generales.
Este mismo principio de agregación de los riesgos puede aplicarse de una manera ligeramente diferente
a la metodología de la cadena crítica. Hemos utilizado el término seguridad o buffer (reserva) del proyecto para
hacer referencia a la contingencia considerada para las actividades individuales, que los gerentes de proyecto
desean mantener. Cuando agregamos riesgo, esta reserva se reduce drásticamente y hace que todos los periodos
de actividad sean realistas y desafiantes. Es decir, en lugar de establecer las estimaciones de duración basadas en
una probabilidad de 90% de finalización exitosa, todas las duraciones de las actividades se estiman en 50%. La
provisión para contingencias, en forma de seguridad para el proyecto, se retira de las actividades individuales
y se aplica a nivel de proyecto. Debido al concepto de agregación, este buffer total es menor que la suma de los
buffers de las actividades individuales del proyecto. Por tanto, la duración del proyecto se reduce.
La historia exitosa reciente de Apple Computer Corporation con su tableta iPad ilustra algunas de las
ventajas de la agregación de riesgos. Apple tomó una decisión consciente con el iPad al subcontratar la mayor
parte de los componentes del producto a varios proveedores. La compañía determinó que hacerse cargo de toda
la ingeniería del producto hubiera sido una alternativa muy compleja y arriesgada. En su lugar, se contactó con
un número de proveedores que habían producido tecnología probada. La decisión de combinar estos compo-
nentes de producto de otras fuentes, en lugar de fabricarlos en casa, dio lugar a un ciclo de desarrollo más rápido
y aumentó en gran medida la rentabilidad.13
Dos preguntas fundamentales deben responderse en este punto: ¿exactamente cuánto se reduce la
duración del proyecto? ¿Cuánto buffer agregado es suficiente? Goldratt y sus partidarios no abogan por
la eliminación de todos los buffers del proyecto, sino simplemente por la reaplicación de ese buffer en el
11.4  Cadena crítica: una solución para la programación del proyecto 379

proyecto (como se muestra en la figura 11.9). El cálculo de la cantidad apropiada de buffer se puede derivar
de dos maneras: (1). Un enfoque de “regla de oro” que Goldratt sugiere mantener en 50% el buffer total del
proyecto, y (2) aplicar el modelo matemático sugerido por Newbold (1998):14

Buffer = σ = 6^^w 1 - a 1h /2 h2 + ^^w 2 - a 2h /2 h2 + f + ^^w i - a ih /2h2@1/2

donde wi es la duración en el peor de los casos y ai es la duración promedio de cada tarea que proporciona
una parte del valor agregado del buffer. La desviación estandar presumida sería (wi - ai)/2. Supongamos, por
ejemplo, que el equipo del proyecto ha definido la longitud del buffer como:

Buffer = 2 # σ = 2 # 6^^w 1 - a 1h /2h2 + ^^w 2 - a 2h /2h2 + f + ^^w i - a ih /2h2@1/2

Supongamos, por ejemplo, que tenemos tres tareas vinculadas entre sí, cada una de 20 días de duración. Así, el
peor de los casos (wi) para estas duraciones son los 20 días originales. Además, mediante la agregación del buffer
basada en una solución de 50%, nuestro valor ai es 10 días para cada actividad. Podemos calcular el tamaño
apropiado del buffer (dos desviaciones estándar) por:

Buffer = ^^20 1 - 10 1h2 + ^20 2 - 10 2h2 + ^20 3 - 10 3h2h


= 300 = 17.32 días

Visualmente, podemos entender la aplicación de CCPM en tres fases diferentes. En la primera, todas las
tareas pertinentes del proyecto se ponen en un diagrama simplificado de precedencia (que se muestra en la línea
1 de la figura 11.9), con sus duraciones previstas especificadas. Recuerde que las estimaciones originales de la
duración más probable se han basado en la alta probabilidad de terminación estimada y, por tanto, requieren
un nuevo examen basado en una evaluación más realista de su duración “real.” La segunda fase consiste en la
reducción de estas estimaciones de duración al nivel probabilidad de 50%. Toda la seguridad individual de las
tareas, o buffers, se han agregado y ahora están dadas como el buffer de proyecto.
En esta fase, la longitud total del proyecto no ha cambiado porque el buffer de tarea individual es sim-
plemente agregado y se añade al final de la programación del proyecto. Sin embargo, la fase 3 ilustra la etapa
final en la reconfiguración, el punto en el que el buffer del proyecto se contrae en cierta cantidad identificable.
Usando la regla de oro del 50% de contracción, nos encontramos con un cronograma del proyecto que sigue
siendo significativamente menor que el original. Este cronograma corto modificado incluye un poco de holgura
menor en cada actividad. Como resultado, la CCPM conduce a programas de proyectos acortados.
Supongamos que un diagrama de red de actividades del proyecto arrojó los valores iniciales dados en el
cuadro 11.1. Tenga en cuenta que la red modificada acorta la duración total del proyecto por 22 días, respecto
al original de 40 a18. Debido a que todo el riesgo está agregado al proyecto, hay un total de 22 días de posi-
ble holgura en el programa que resulta de la reducción de las estimaciones de la actividad en cada etapa del

Paso #1 #2 #3 #4

#1 #2 #3 #4 Buffer de proyecto

#1 #2 #3 #4 Buffer de proyecto

FIGURA 11.9  Reducción de la duración del proyecto después de la agregación


Fuente: L. P. Leach. (1999). “Critical chain project management improves project
performance,” Project Management Journal, 30(2), 39–51, figura de la página
44.Copyright © 1999 por Project Management Institute Publications. Copyright y
todos los derechos reservados. El material de esta publicación ha sido reproducido
con permiso del PMI.
380 Capítulo 11  •  Programación de proyectos con cadena crítica

CUADRO 11.1  Reducción de los tiempo de duración de las actividades con cadena crítica

Duración basada en
Actividad Duración original estimada probabilidad de 50%
A 10 días   5 días
B   6 días   2 días
C 14 días   7 días
D   2 días   1 day
E   8 días   3 días
Total 40 días 18 días

proyecto. Un cronograma del proyecto CCPM modificado vuelve a aplicar 11 días a la programación con-
traída para servir como buffer general del proyecto. Por tanto, la nueva programación del proyecto podría
anticipar una duración estimada de 29 días hasta la terminación.
¿Cuáles son las implicaciones de esta nueva aplicación de la holgura del proyecto en el agregado? En
primer lugar, todas las fechas de vencimiento de las actividades individuales y actividades secundarias se han
eliminado. Los hitos no se utilizan en la red de actividades CCPM. El único compromiso en firme que se
mantiene es la fecha de entrega del proyecto, no la realización de las tareas individuales. Se anima a los miem-
bros del equipo del proyecto para hacer estimaciones realistas y comunicar continuamente sus expectativas.
Evidentemente, para que la CCPM pueda funcionar es vital una cultura organizacional compatible con una
política de “no culpa.” Recuerde: la naturaleza de requerir estimaciones de probabilidad de 50% para la dura-
ción de las actividades individuales implica que los trabajadores tienen la misma probabilidad de perder una
fecha de compromiso que de cumplirla. En una cultura que castiga sistemáticamente el cumplimiento tardío,
los trabajadores volverán a adquirir rápidamente los hábitos que una vez los protegieron: estimaciones infla-
das, desperdiciar la seguridad, y así sucesivamente.
La segunda implicación puede ser más significativa, en particular cuando se trata de subcontratistas
externos. Dado que las fechas de las actividades individuales se han eliminado y los hitos se han desechado,
programar eficazmente las entregas de subcontratistas se convierte en un problema, debido a que los con-
tratistas aceptan proporcionar materiales para el proyecto, habitualmente operando de acuerdo con (calen-
dario) fechas de entrega establecidas por los hitos. La CCPM, con su filosofía de hacer menos énfasis en
las fechas previstas para las tareas individuales, crea un entorno complicado de programación necesaria de
proveedores o las entregas del subcontratista. Los autores de la CCPM sugieren que un método para aliviar
esta preocupación es trabajar con los contratistas para negociar la pronta terminación y entrega de los com-
ponentes necesarios para actividades críticas.15

Desarrollo de la red de actividades de cadena crítica


Según los capítulos anteriores, con las redes tradicionales CPM/PERT, la holgura individual de la actividad
es un artefacto de la red general. El tiempo de inicio de la actividad, por lo general, está determinado por la
disponibilidad de recursos. Por ejemplo, aunque la actividad podría comenzar más temprano el 15 de mayo,
podemos posponerla tres días debido a que la persona responsable de su realización no está disponible hasta
esa fecha. De esta manera, la holgura se utiliza como un dispositivo de nivelación de recursos.
Con CCPM, no se requiere nivelación de los recursos, porque estos se redistribuyen dentro del pro-
yecto en el proceso de identificación de la cadena crítica. Por tanto, para la programación, CCPM aboga
por colocar todas las actividades no críticas lo más tarde posible, al tiempo que proporciona su propio
buffer a cada ruta no crítica en la red (véase la figura 11.10). Estos buffers no críticos se conocen como
buffers de alimentación porque se colocan donde las rutas no críticas alimentan la ruta crítica. Como se
muestra en la figura 11.10, una parte de la ruta crítica y una de las rutas no críticas se unen justo pasando
el punto de actividad C. La duración del buffer de alimentación se calcula de manera similar al proceso
utilizado para crear el buffer de proyecto, unido al final de la cadena crítica.
Para entender cómo se construye la lógica de la cadena crítica, tenga en cuenta que los primeros pasos
se dan en algunos ajustes importantes a los enfoques de programación tradicionales, como:
1. Ajuste de la duración esperada de las actividades para reflejar una probabilidad de 50% de finalización
(reducción del cronograma).
11.4  Cadena crítica: una solución para la programación del proyecto 381

Actividad X Actividad Y Buffer de


no crítica no crítica alimentación

Actividad A Actividad B Actividad C Actividad D Buffer de


crítica crítica crítica crítica proyecto

FIGURA 11.10  CCPM uso de los buffers de alimentación


Nota: los buffers de alimentación tienen por objeto impedir las demoras en las
actividades críticas.

2. Cambiar de un enfoque de proceso de inicio temprano a uno de fin tardío.


3. De ser necesario, considerar los efectos de los conflictos de recursos.
Las figuras 11.11a, b, y c presentan una serie simplificada de ejemplos que siguen estos pasos. La figura
11.11a muestra una red de actividad estándar basada en un enfoque PERT, con un total de cinco actividades
(A, B, C, D y E) a lo largo de dos rutas separadas que alimentan la actividad E en la terminación. Todas las
actividades se programan para comenzar tan pronto como sea posible (inicio temprano) y se basan en un
método estándar para estimar duraciones. El cuadro 11.2 muestra estas duraciones esperadas.
La figura 11.11a muestra una duración general esperada del proyecto de 90 días, con la serie más larga
de actividades vinculadas (ruta A – B – E). La segunda ruta, C – D – E, tiene una duración total de 60 días y,
por tanto, tiene 30 días de holgura asociada. Con el fin de ajustar esta red, el primer paso consiste en cam-
biar a un cronograma de inicio tardío. En el segundo paso, CCPM desafía las estimaciones originales de la
duración de las actividades y las sustituye basado en el punto medio de la distribución. La red de actividades
modificada supone que las estimaciones se contraen 50%. Por tanto, la nueva red tiene una duración total de
45 días, en lugar de la estimación original de 90 días (véase la figura 11.11b).
El siguiente paso en la conversión a un programa de cadena crítica implica la inclusión de buffers de
alimentación del proyecto para todas las rutas de la red. Recordemos que estos buffers se calculan basados
en la aplicación de ahorros de 50% en el cronograma general. El buffer de alimentación para la ruta C - D se
calcula como (0.50) (10 + 5), o 7.5 días. El buffer de proyecto, que se encuentra a partir de los valores de la
trayectoria A - B - E, se calcula como (0.50) (5 + 25 + 15), o 22.5 días. Por tanto, una vez que los buffers de
alimentación se añaden a la red de actividades modificada, el diagrama PERT original que muestra una dura-
ción de 90 días con 30 días de holgura, y ahora la nueva red de cadena crítica tiene una duración total de 67.5
días, o un ahorro de 22.5 días (véase la figura 11.11c ). Por tanto, con tres pasos, nos movemos de una pro-
gramación de inicio temprano a una de inicio tardío, identificamos la ruta crítica (secuencia de actividades
vinculadas, más larga) y, a continuación, aplicamos los buffers de alimentación y de proyecto. El resultado
es un programa modificado del proyecto, el cual, incluso con buffers, reduce significativamente el tiempo de
terminación prevista para el proyecto.16

CUADRO 11.2  Duración de las actividades

Actividad Duración
A 10 días
B 50 días
C 20 días
D 10 días
E 30 días
382 Capítulo 11  •  Programación de proyectos con cadena crítica

A (10) B (50)

E (30)

Holgura
C (20) D (10)

90 Días

FIGURA 11.11a  Programación del proyecto con inicio temprano

A (5) B (25)

E (15)

C (10) D (5)

45 Días

FIGURA 11.11b  Programación reducida con inicio tardío

A (5) B (25)

Buffer de
E (15) proyecto (22.5)

Buffer de
C (10) D (5) alimentación
(7.5)

67.5 Días

FIGURA 11.11c  Programación de cadena crítica con buffers incluidos

Soluciones de cadena crítica versus soluciones de ruta crítica


Entonces, ¿cuál es la diferencia real entre el método de ruta crítica y la gerencia de proyectos con cadena
crítica? La cadena crítica no suele ser el mismo camino de la ruta crítica dentro de una red de actividades.
La ruta crítica solo considera la dependencia de las tareas, es decir, la vinculación de las tareas con sus
predecesoras. De hecho, en este proceso, la holgura de actividad se descubre después; una vez que la red se
distribuye y la ruta crítica se identifica, todos los otros caminos y actividades pueden contener cierto nivel
de holgura. Además, la cadena crítica, por lo general, se salta los enlaces de dependencia de tareas. Una
vez más, este efecto se produce porque la cadena crítica requiere toda la nivelación de recursos antes de
que la cadena crítica pueda identificarse, no después, como en las redes de PERT y CPM.
Para ilustrar esta distinción, considere las diferencias cuando la red de actividades de la figura 11.12a se
compara con la solución modificada en la figura 11.12b. La figura 11.12a muestra una red PERT simplificada
que identifica tres rutas. El camino central es la ruta crítica. La dificultad se presenta cuando se requiere el
mismo recurso (Bob) para completar actividades programadas simultáneamente. Claramente, Bob no puede
realizar las tres tareas al mismo tiempo sin alargar significativamente la ruta crítica general. La alternativa,
que se muestra en la figura 11.12b, es nivelar primero los recursos de las actividades que Bob debe realizar. El
cronograma del proyecto debe tener en cuenta el conflicto de recursos y demostrar una nueva lógica de red
que permita que el proyecto siga adelante.
11.4  Cadena crítica: una solución para la programación del proyecto 383

Bob, nuestra limitación de recursos (véase la figura 11.12b) hace que el cronograma se vuelva a
dibujar para reflejar sus asignaciones de trabajo. Tenga en cuenta que en el programa con cadena crítica
(que se muestra con la línea discontinua), Bob primero termina su tarea en la ruta central. Las otras dos
rutas requieren de Bob también, por lo que se le asigna a la primera tarea en el camino inferior y luego
se dedica a su trabajo final, por la ruta superior. También tenga en cuenta cómo los diferentes buffers de
alimentación deben dibujarse en el nuevo programa de la cadena crítica. Debido a que Bob trabaja en la
primera tarea, la predecesora de sus actividades sucesoras, los buffers de alimentación en la parte superior
e inferior del cronograma se mueven hacia adelante o atrás, en la red, teniendo en cuenta la disponibilidad
de recursos (si él se retrasa). Por tanto, puesto que Bob es el recurso crítico en la red, es imprescindible pri-
mero nivelarlo con las tareas de las cuales es responsable y luego redibujar la red para generar una nueva
cadena crítica, distinta de la ruta crítica inicial. Una vez identificada la cadena crítica, se añaden buffers
de alimentación para apoyar las actividades críticas y, al mismo tiempo, para proporcionar un margen de
seguridad en los caminos no críticos.

Bob Buffer de
alimentación

Bob

Ruta crítica

Buffer de
Bob alimentación

FIGURA 11.12a  Red de ruta crítica con conflicto de recursos

Buffer de
alimentación Bob

Buffer de Buffer de
Bob
alimentación proyecto

Buffer de
alimentación Bob

FIGURA 11.12b  La solución con cadena crítica


Nota: la cadena crítica se muestra como una línea discontinua.
384 Capítulo 11  •  Programación de proyectos con cadena crítica

PERFIL DE PROYECTO

Eli Lilly Pharmaceuticals y su compromiso con la gerencia de proyectos con cadena crítica
Eli Lilly Corporation es uno de los gigantes de la industria farmacéutica, pero en el sector de la fabricación de medi-
camentos el tamaño no es garantía de éxito en el futuro. Todas las empresas farmacéuticas en Estados Unidos se
enfrentan con una creciente variedad de fuentes de presión, como: (1) el gobierno federal, que promulgó reciente-
mente algunos elementos de la “Obamacare” con parámetros estrictos para el control de los costos de medicamen-
tos; (2) la pérdida de las patentes cuando los medicamentos esenciales se convierten en genéricos; y (3) la necesidad
de mantener el liderazgo en un sector altamente competitivo. Lilly empezó a sentir los efectos de estas presiones, a
partir de 2011, cuando varios de sus principales medicamentos se quedaron sin protección de patente, lo cual obligó
a la empresa a luchar por introducir rápidamente nuevos medicamentos en el mercado. Infortunadamente, la última
etapa de su proceso de innovación es tenue, hay pocos fármacos esperando aprobación para comercializarse.
En sus esfuerzos por mantenerse al frente de la industria, durante los últimos años Lilly ha anunciado
una serie de movimientos estratégicos. En primer lugar, la empresa estableció una iniciativa de reducción de
costos en toda la organización, con la esperanza de recortar más de 1,000 millones de dólares en sus opera-
ciones. En segundo lugar, Lilly se reorganizó en cuatro divisiones para racionalizar y consolidar sus operacio-
nes y con el fin de orientarse mejor al mercado y ser más sensible. Por último, la firma anunció la formación
de un centro de desarrollo de excelencia en (I+D), que se localizará en la sede corporativa en Indianápolis,
Indiana. Este centro será responsable de acelerar la realización de ensayos en etapa tardía y la presentación
de nuevos fármacos. ¿Cuál ha sido la clave del éxito que Lilly ha considerado para su Centro de Excelencia?
Un elemento importante es el uso generalizado de la gerencia de proyectos con cadena crítica (Critical Chain
Project Management: CCPM).
Desde 2007, Lilly ha implementado la CCPM en su unidades de (I+D) y se ha comprometido a institucionalizar
el proceso de (I+D) a lo largo de toda la organización. El apoyo de la empresa para la CCPM se basa en los resulta-
dos obtenidos, con las pruebas contundentes: “Por ahora se ha implementado en 40% de nuestra nueva gama de
productos, y 100% de nuestros proyectos han cumplido el tiempo de entrega, en comparación con alrededor de
60% para otro 60% de los [medicamentos] en los programas de desarrollo más tradicionales”, según Steven Paul,
presidente de Lilly Research Labs.
Lilly ha encontrado que CCPM aporta varias ventajas a la compañía, empezando por volver a crear un
ambiente interno cooperativo basado en el compromiso compartido de varios departamentos, en el proceso de
Blend Images / Alamy

FIGURA 11.13  Laboratorio de investigación y desarrollo de medicamentos


11.5  Soluciones de cadena crítica a los conflictos de recursos 385

desarrollo de medicamentos. Además, la CCPM maximiza la eficiencia de los recursos de la empresa, evitando los
cuellos de botella comunes en el ciclo de desarrollo y permitiendo trasladar más rápidamente los medicamentos
a través de las fases de prueba. Por último, promueve una atmósfera interna de autenticidad en la estimación, la
programación y el control de proyectos.
El cambio a la CCPM no fue fácil. Algunos gerentes señalan que se requiere una mentalidad diferente de los
empleados, quienes tienen que ver sus proyectos desde un punto de vista “organizacional” y no con una perspec-
tiva estrictamente departamental. No obstante, el compromiso público de Lilly con la CCPM ha dado sus frutos y
continúa sirviendo como un catalizador para el éxito competitivo de la empresa.17

11.5  SOLUCIONES DE CADENA CRÍTICA A LOS CONFLICTOS DE RECURSOS


Supongamos que después de revisar el cronograma elaborado (véase la figura 11.11c) descubrimos un
punto de conflicto de recursos. Supongamos que las actividades B y D requieren la misma persona, lo
que resulta en un recurso sobrecargado. ¿Cómo podemos resolver esta dificultad? Debido a que las fechas
de inicio de todas las actividades son movidas lo más tarde posible, los pasos que se deben seguir son los
siguientes:
1. La tarea predecesora de la actividad D es la actividad C. Por tanto, el primer paso consiste en asignarle
una nueva restricción de inicio tardío como sea posible para la actividad C.
2. Para eliminar el conflicto de recursos, trabajar hacia atrás desde el final del proyecto, eliminando las
fuentes de conflicto.
La pantalla 11.1 presenta un archivo de MS Project que ilustra los pasos para ajustar la programación
de la cadena crítica, a fin de eliminar los conflictos de recursos. Tenga en cuenta que la figura original
(figura 11.11c) pone de relieve un problema estándar en el desarrollo de una programación temprana
típica, que incluye evaluar el cronograma contra una posible sobrecarga de recursos. Supongamos, por
ejemplo, que el diagrama de Gantt (véase la pantalla 11.1) indica un conflicto para el recurso Joe, a quien
se le han asignado la actividad B y la D, durante la semana del 6 de marzo. Dado que esta persona no
puede realizar ambas actividades al mismo tiempo, hay que volver a configurar el cronograma conside-
rando esta restricción.
La pantalla 11.2 muestra el siguiente paso en el proceso de resolución del conflicto de recursos.
Mientras se mantiene un formato de inicio tardío, la actividad D se obliga de nuevo a producirse después de
la actividad B, lo que permite que Joe pueda ejecutar primero la actividad B antes de pasar a su siguiente asig-
nación. El retraso total en el cronograma equivale a aproximadamente una semana, con la reconfiguración
del cronograma.
Alternativamente, este problema de conflicto de recursos puede solucionarse reprogramando según
se muestra en la pantalla 11.3, en donde las actividades C y D se mueven hacia adelante en la red. Esta

PANTALLA 11.1  Programación del proyecto con inicio tardío para las actividades
386 Capítulo 11  •  Programación de proyectos con cadena crítica

PANTALLA 11.2  Reconfiguración de la programacion para resolver el conflicto de recursos

PANTALLA 11.3  Solución alternativa para el problema de conflicto de recursos

solución alternativa agrega tiempo adicional a la ruta de la red, pues mueve la fecha de finalización prevista
para la segunda semana de abril. Al elegir la solución más viable a los problemas de conflictos de recursos,
se recomienda la opción que minimice la alteración total del cronograma de la red. En los ejemplos mos-
trados, es preferible adoptar el cronograma que se indica en la pantalla 11.2, ya que soluciona el conflicto
de recursos y ofrece una programación reconfigurada en la que se pierde solo una semana, en general.

11.6  GERENCIA DEL PORTAFOLIO DE PROYECTOS CON CADENA CRÍTICA


La gerencia de proyectos con cadena crítica también puede aplicarse a la gerencia del portafolio de proyec-
tos de la empresa. La lógica básica de la TOC se puede aplicar al portafolio de proyectos de la compañía,
con el fin de identificar la restricción clave del sistema. Recordemos que en el ejemplo de un solo pro-
yecto, la restricción clave se encuentra en la cadena crítica. En toda la organización, la principal restricción
se ve comúnmente como la capacidad de recursos de la empresa. Para balancear el portafolio de proyectos
en proceso, primero tenemos que evaluar las limitaciones principales en los recursos de la empresa para
determinar la capacidad disponible. La restricción de recursos puede ser una persona o un departamento,
también una política operativa general en la empresa, incluso un recurso físico. En relación con la capa-
cidad de producción, Goldratt utiliza el término tambor (drum), en referencia a una restricción clave del
sistema, ya que la limitación de este recurso se convierte en el tambor que define el ritmo del resto del
rendimiento de la compañía.18
Para la aplicación de la CCPM en un entorno de multiproyecto, primero debemos identificar el
actual portafolio de proyectos. Luego, se identifica la restricción de recursos más importante, o el tambor,
y, siguiendo la metodología TOC, se aprovecha la restricción del sistema. Dentro de la programación del
11.6  Gerencia del portafolio de proyectos con cadena crítica 387

portafolio de proyectos, este paso, por lo general, consiste en enviar los proyectos adelante en el tiempo,
porque el cronograma del tambor determina la posterior secuenciación del portafolio de proyectos de la
empresa. Si el recurso de tambor es temprano, algunos proyectos se pueden enviar hacia adelante para
aprovechar el inicio temprano. Si el tambor es tardío, se podría requerir enviar los proyectos hacia el
futuro. También tenemos que emplear buffers en la programación del portafolio, así como lo hicimos
para las rutas alimentadoras y un buffer general de proyecto en el caso de proyectos individuales. La
expresión buffer de restricción de capacidad (capacity constraint buffer: CCB) se refiere a un margen de
seguridad que separa los diferentes proyectos programados para usar el mismo recurso. La aplicación de
un CCB antes de la secuenciación del próximo proyecto asegura que el recurso clave se proteja. Por ejem-
plo, si Julia es la experta en la evaluación de calidad y debe inspeccionar todos los proyectos de software
beta antes de su lanzamiento para el desarrollo total, tenemos que aplicar un CCB entre su transición
de un proyecto a otro. Por último, también podemos utilizar buffers tambor (drum buffers) en la pro-
gramación del portafolio. Los buffers de tambor representan una seguridad adicional que se aplica a un
proyecto inmediatamente antes de la utilización del recurso limitado, para garantizar que el recurso no
esté escaso de trabajo. En efecto, se asegura que el recurso de tambor (nuestra restricción) tenga entrada
para trabajar en el proyecto, cuando sea necesario.19
Dentro de los pasos formales necesarios para aplicar CCPM a múltiples portafolios de proyectos, se incluyen.20
1. Identificar la restricción de recursos de la empresa o el tambor, la fuerza motriz detrás de la programa-
ción de los múltiples proyectos. Determinar qué restricción de recurso afecta directamente el rendi-
miento del sistema en general o cual típicamente tiene el menor suministro y requiere, frecuentemente,
más horas extras. Tal evidencia física es el mejor indicador de la restricción central de la compañía.
2. Explotar la restricción del recurso para:
a. Preparar una programación con cadena crítica en cada proyecto, de forma independiente.
b. Determinar la prioridad entre los proyectos para el acceso al tambor, o al recurso restringido.
c. Determinar la restricción de recursos multiproyecto, o el cronograma del tambor. Se recogen las
demandas de recursos para cada proyecto y se resuelven los conflictos basados en la prioridad y el
deseo de maximizar el rendimiento en el desarrollo del proyecto.
3. Subordinar los horarios individuales de los proyectos para:
a. Programar cada proyecto y empezar de acuerdo con el cronograma del tambor.
b. Designar la cadena crítica como la ruta en la que se utiliza por primera vez el recurso restringido
hasta el final del proyecto.
c. Insertar buffers de restricción de capacidad (CCBs) entre los cronogramas de cada proyecto, por
delante de la utilización prevista de los recursos limitados. Esta acción protege el cronograma del
tambor y asegura que esté listo para entrar cuando se requiera.
d. Resolver cualquier conflicto, si la creación de los BCC afecta negativamente el cronograma del tambor.
e. Insertar buffers de tambor en cada proyecto para asegurar que el recurso restringido no sea escaso
para el trabajo. Los buffers deben situarse inmediatamente antes de la utilización del recurso res-
tringido en el proyecto.
4. Elevar la capacidad del recurso restringido, es decir, aumentar la capacidad del tambor para futuras
iteraciones del ciclo.
5. Cada vez, volver al paso 2 y reiterar la secuencia, y así mejorar los flujos de operación y de los niveles
de restricción del flujo de operación y los niveles de restricción del recurso.
Como ejemplo, considere la figura 11.14. Hemos identificado una restricción de recursos tambor, lo que
sugiere que el suministro de recursos no es suficiente para darles cabida a los tres proyectos (A, B, y C) que están
en cola para completarse. Este punto se ilustra por medio de la línea de trazos horizontales en la figura. Una
opción, por supuesto, es dejar caer el proyecto a la prioridad más baja, que en esencia permite que el recurso
tambor determine el número de proyectos que pueden lograrse. Alternativamente, podemos considerar los
métodos para explotar la restricción del sistema mediante el uso de buffers de restricción de capacidad para lle-
var a cabo los tres proyectos, en su condición de prioritario. La figura 11.14 muestra la naturaleza del problema,
en donde el proyecto A tiene la más alta prioridad, B la siguiente, y C la más baja prioridad. Los recursos actua-
les son suficientes para manejar solamente dos proyectos a la vez, pero los recursos no se requieren de forma
continua, como muestra la figura. Como resultado de ello, el problema de restricción de recursos realmente se
convierte en uno de programación, de forma similar a un solo proyecto.
Una vez que hemos identificado la restricción de recursos y priorizado los proyectos para el acceso al recurso
tambor, podemos reprogramar los proyectos de manera similar a la mostrada en la figura 11.15.21 El problema
388 Capítulo 11  •  Programación de proyectos con cadena crítica

C C
Suministro de recursos

B B B

A A A

Tiempo
Prioridad: 1. Proyecto A
2. Proyecto B
3. Proyecto C

FIGURA 11.14  Tres proyectos en cola esperando acceso a un recurso tambor


Suministro de recursos

CCB
B B C B

A A A C

Tiempo
A y B inician Fecha de inicio
inmediatamente del proyecto C

FIGURA 11.15  Aplicación de CCB a la programación tambor

es de capacidad limitada, por lo que la tarea consiste en empujar el proyecto adicional C hasta el momento en que
pueda incluirse en la programación tambor. Se coloca un CCB frente a la fecha de inicio para empezar a trabajar
sobre el proyecto C. Este buffer asegura que el recurso clave esté disponible cuando se necesite para la ejecución del
próximo proyecto y define la fecha de inicio para el nuevo proyecto.
11.6  Gerencia del portafolio de proyectos con cadena crítica 389

RECUADRO 11.1

INVESTIGACIÓN DE GERENCIA DE PROYECTOS EN SÍNTESIS


Ventajas de la programación con cadena crítica
¿Realmente funciona la CCPM? Aunque recientemente ha aparecido una serie de libros y artículos defen-
diendo la metodología, a la fecha existe poca evidencia empírica para confirmar o refutar la viabilidad del
enfoque de la cadena critica para la programación. La evidencia tiende a ser principalmente de naturaleza
anecdótica, en la medida que los defensores de la CCPM apuntan a una serie de empresas que han logrado
un ahorro sustantivo en tiempo y cambios de actitud positivos de los miembros del equipo del proyecto, des-
pués de la implementación de la programación con cadena crítica.
Un estudio reciente realizado por Budd y Cooper22 buscó probar la eficacia de la CCPM contra la tradicio-
nal planeación de la ruta crítica, en un entorno de simulación. A partir de tres proyectos y más de 1,000 itera-
ciones tanto para la cadena crítica como para la ruta crítica, los autores proyectaron los tiempos de terminación
de los proyectos en estudio y determinaron que la duración total de las actividades en programación con cadena
crítica eran más cortas en comparación con la duración utilizando el método de la ruta crítica. Para los modelos
de simulación, en una programación CPM, se estimaron proyectos con longitudes entre 291 y 312 días para
completarse, con un tiempo meta promedio de 293 días. Para la programación con cadena de crítica se tomaron
proyectos de 164 a 181 días, con un valor promedio de 170 días para su terminación. De hecho, múltiples ite-
raciones implican diferentes duraciones de los proyectos; en todos la programación con cadena crítica redujo el
tiempo promedio de duración para completar los proyectos entre 18% y 42%. La única salvedad que los autores
observaron fue su incapacidad para reconocer los efectos negativos de la multitarea sobre cada programación.
Sin embargo, sus resultados ofrecen cierta evidencia en apoyo de la gerencia de proyectos con cadena critica
como una alternativa viable sobre la programación de la ruta crítica.
Evidencia adicional de investigación también sugiere que la CCPM tiene un efecto positivo sobre los
resultados del proyecto. En la gerencia de proyectos de IT, los resultados publicados sugieren que la adopción
exitosa de la CCPM, muestra reducciones en la duración de los proyectos alrededor de 25%, aumento de
rendimiento de 25% (del número de proyectos terminados por unidad de tiempo), y el número de proyectos
terminados a tiempo se elevó 90%. Por último, una recopilación de los últimos resultados de diferentes confi-
guraciones de proyectos ofrece algunas pruebas alentadoras (véase el cuadro 11.3).23

CUADRO 11.3  Mejoras en el rendimiento de los proyectos de la empresa, mediante el uso de la


gerencia de proyectos con cadena crítica (CCPM)

Implementación de la CCPM Antes Después


Desarrollo de nuevos 34 productos nuevos por año. Aumentó a 52 productos nuevos en
productos para electrodomésticos 74% de los proyectos a el primer año y a más de 70 en el
(Hamilton Beach/Proctor-Silex) tiempo. segundo año. 88% de los proyectos
a tiempo
Diseño e instalación de redes Entrega a tiempo de menos de Aumento de la entrega a tiempo a
de telecomunicaciones (Eircom, 75%. Tiempo de ciclo prome- más de 98%.
Irlanda) dio de 70 días. Tiempo promedio del ciclo se redujo
a 30 días.
Fabricación y mantenimiento Solo 33% de los proyectos Proyectos terminados a tiempo
de helicópteros (Erickson Aire terminados a tiempo. aumentó a 83%.
Crane)
Diseño y fabricación de Ingeniería de diseño tomó Ingeniería de diseño tarda 9 meses.
plataformas de petróleo y gas 15 meses. Ingeniería de Ingeniería de producción se lleva a 5
(LeTourneau Technologies, Inc.) producción tomó 9 meses. meses. La fabricación y el montaje se
Fabricación y montaje tomó lleva a 5 meses con una mejora de
8 meses. 22% en la productividad del trabajo.
Desarrollo de alta tecnología Proyectos de dispositivos Tiempo de ciclo de desarrollo se re-
médica (Medtronic Europe) tomaron 18 meses en duce a 9 meses. La entrega a tiempo
promedio y eran impredecibles. aumentó a 90%.
Reparación y revisión de trans- 42 proyectos terminados entre 54 proyectos terminados entre enero
formadores (ABB, Halle) enero y diciembre de 2007. y diciembre de 2008. Entrega a
Entrega a tiempo de 68%. tiempo 83%.
390 Capítulo 11  •  Programación de proyectos con cadena crítica

Este mismo procedimiento puede utilizarse cuando se añade un cuarto, quinto o sexto proyecto al por-
tafolio. Cada proyecto se limita por el acceso al recurso tambor y debe, por tanto, programarse teniendo en
cuenta la restricción del sistema. De esta forma estamos en capacidad de elaborar una programación del pro-
yecto principal empleando la filosofía de la teoría de restricciones de Goldratt, en un entorno multiproyecto.

11.7  CRÍTICAS A LA CCPM


La gerencia de proyectos con cadena crítica no está exenta de críticas. Varios argumentos en contra del pro-
ceso incluyen las siguientes falencias y debilidades detectadas en la metodología:
1. La falta de los hitos del proyecto hacen la coordinación de la programación, en particular con los
proveedores externos, altamente problemática. Los críticos afirman que la falta de los hitos del pro-
yecto en proceso afecta negativamente la capacidad de coordinar las fechas de programación con los
proveedores que proporcionan el suministro externo de componentes claves.24
2. La “novedad” de la CCPM es un punto rebatido por algunos que ven la técnica, ya sea como una adap-
tación de muchos tipos de proyectos o simplemente como una reconceptuación de las metodologías de
programación bien entendidas (como PERT), incluido el cuidado especial sobre los recursos en la red.25
3. Aunque puede ser cierto que la CCPM aporta mayor disciplina a la programación de proyectos, no
se cuenta con métodos eficaces para la aplicación de esta técnica al portafolio de proyectos de una
empresa. El método parece ofrecer beneficios sobre una base de proyecto por proyecto, pero su utili-
dad a nivel de programa no se ha probado.26 Además, debido a que la CCPM aboga por los recursos
asignados, en un entorno multiproyecto, donde se comparten recursos, es imposible evitar la multita-
rea, lo que disminuye el poder de la CCPM.
4. La evidencia del éxito de la CCPM sigue siendo casi exclusivamente anecdótica y se basa en estudios de caso
único. El debate sobre los méritos y riesgos de la CCPM ha mantenido, en gran medida, un ejercicio inte-
lectual entre académicos y escritores de la teoría de la gerencia de proyectos. Con la excepción del trabajo de
Budd y de Cooper, no existe investigación empírica a gran escala para confirmar o refutar su eficacia.
5. Una reciente análisis de la CCPM afirmó que aunque ofrece una serie de conceptos de valor, no repre-
senta una solución completa a las necesidades actuales de programación en la gerencia de proyectos.
Los autores afirmaron que las organizaciones deben tener mucho cuidado al excluir los procesos con-
vencionales de planeación en la gerencia de proyectos al adoptar la CCPM como método único para la
planeación y programación de actividades.27
6. Los críticos también alegan que la evaluación de Goldratt de la estimación de la duración es excesi-
vamente negativa y crítica, y argumentan que su afirmación de que el personal del proyecto agrega
rutinariamente enormes niveles de actividad para la de estimación de la duración es exagerada.
7. Por último, preocupa que Goldratt subestima las dificultades asociadas con la consecución del tipo
de cambio cultural necesario para implementar con éxito la CCPM en toda la empresa. En particular,
mientras la estimación de actividad colchón puede ser problemática, no está claro que los miembros
del equipo estén dispuestos a abandonar la seguridad, a petición del gerente del proyecto, a medida que
perciben la posibilidad de sanciones por el incumplimiento de los plazos.28
La implementación exitosa y el uso de la CCPM se basan primero en acordar un compromiso para examinar
de manera crítica el cambio de la cultura en organizaciones de proyectos, en las cuales muchos de los proble-
mas identificados en este capítulo son evidentes. La veracidad de la programación, evitando el síndrome del
estudiante y la transferencia de la seguridad del proyecto para el control por el gerente de proyecto son ejem-
plos de acciones que denotan una auténtica cultura saludable. Ganando “confianza” de miembros de la orga-
nización para este proceso de planeación es vital para el éxito de de la aplicación de estas técnicas nuevas e
innovadoras que pueden mejorar drásticamente el tiempo de salida al mercado y la satisfacción del cliente.29

Resumen
1. Entender la diferencia entre causas comunes y • Causa común de la variación —Una causa inhe-
especiales de la variación en las organizaciones.  rente al sistema; es decir, existe una probabilidad de
Deming identificó dos principales fuentes de variación que se presente un error debido a fallas en la forma
(error) en las organizaciones: como se creó originalmente el sistema.
Resumen 391

• Causa especial de la variación —Una causa atribui- de la mayoría de las organizaciones a exigirles a los
ble a una circunstancia especial; por ejemplo, puede miembros del equipo del proyecto que realicen múl-
ser específica a algún conjunto de los trabajadores, tiples tareas, trabajando en múltiples asignaciones
pieza de maquinaria o condición local. simultáneamente. Cuantas más tareas se les asignen
Al aplicar los cinco pasos de la teoría de las a los miembros del equipo, más tiempo se tardan en
restricciones, hay que identificar correctamente los completar una sola tarea. Por último, la ruta de acti-
cuellos de botella u otros errores en las activida- vidades con puntos de convergencia son otra forma
des de una organización. Cuando se confunde una en que perdemos la seguridad de la actividad. En los
causa común de la variación con una causa especial puntos de convergencia, las actividades deben espe-
de variación, existe la posibilidad de aplicar mal las rar a que la más lenta de las actividades que con-
acciones correctivas o de perder tiempo y dinero vergen se complete antes de que se pueda pasar a la
persiguiendo la fuente de los problemas que no son tarea sucesora. Las actividades que finalizaron tem-
exclusivos de un proyecto, sino inherentes a la pro- prano pierden la holgura de tiempo esperando por la
pia organización. Por otro lado, cuando una causa más tardía.
especial de variación se atribuye a una causa común, 4. Distinguir entre las técnicas de programación de
existe la posibilidad de perder la verdadera fuente de proyectos con ruta crítica y con cadena crítica. 
error al suponer que los errores se encuentran den- Como resultado de los problemas sistemáticos pre-
tro del sistema, en lugar de considerar que se deben sentados con la programación de proyectos, Goldratt
a una causa específica. desarrolló el proceso gerencia de proyectos con cadena
2. Reconocer las tres formas en que los equipos de crítica (Critical Chain Project Management: CCPM).
proyecto inflan la cantidad de seguridad para todas Con la CCPM, se realizaron varias modificaciones al
las tareas del proyecto.  Goldratt afirma que la pro- proceso tradicional de programación PERT. En pri-
gramación de proyectos se afecta dramáticamente mer lugar, toda la holgura individual de actividad,
por la conducta humana. En nuestro deseo de “prote- o “buffer”, se convierte en un amortiguador del pro-
gernos” de las consecuencias negativas de los plazos yecto. Cada miembro del equipo, responsable de su
incumplidos, habitualmente los miembros del equipo componente en la red de actividades, hace una estima-
del proyecto sobrevaloran sus estimaciones, hasta en ción de la duración libre de cualquier factor de seguri-
200%. Al mismo tiempo, los gerentes de proyectos se dad, es decir, basada en 50% de probabilidad de éxito.
protegen agregando de su propio factor de seguridad Todas las actividades en las cadenas críticas y en las
a las estimaciones que reciben de sus subordinados. cadenas alimentadoras (cadenas no críticas en la red)
Finalmente, ellos también agregan un factor debido a se enlazan con tiempo de seguridad mínimo. Ahora, se
los recortes que esperan que realice la alta gerencia, agrega el buffer al proyecto y cierta proporción de ese
al momento que se les presenten las estimaciones del tiempo ahorrado (Goldratt utiliza una regla empírica
cronograma. El resultado: se obtiene una actividad de 50%) se adiciona al proyecto. Incluso sumando 50%
de estimación y un proceso de programación plaga- del tiempo ahorrado, se reduce significativamente el
dos de falta de honradez en todas sus etapas y lle- cronograma general del proyecto, mientras los miem-
nos de seguridad excesiva. Debido a que nadie toma bros del equipo requeridos están más preocupados por
en serio las estimaciones, nadie realiza estimaciones la realización de la tarea que por la seguridad de esta.
serias. En segundo lugar, la CCPM aplica el mismo
3. Comprender las cuatro formas en que se puede des- enfoque para aquellas tareas que se encuentran en la
perdiciar la seguridad adicional de las tareas del cadena crítica. Todas las actividades de las rutas ali-
proyecto.  Los problemas continúan una vez se mentadoras se reducen en la misma magnitud y se
establecen los cronogramas. Todos los miembros del construye un buffer alimentador para todas las activi-
equipo del proyecto están propensos a determina- dades que no están en la cadena crítica.
das conductas, como el síndrome de estudiante “del Finalmente, la CCPM distingue entre el uso de
paper final”, por lo que retrasamos el comienzo de un buffer y el de la tradicional holgura del proyecto del
una actividad, tanto como sea posible. En segundo PERT. Con el enfoque PERT, la holgura del proyecto
lugar, mientras los retrasos se pasan de una actividad es una función de la red global de actividades. En otras
a la otra, a lo largo del cronograma, las finalizacio- palabras, la holgura es el resultado de las relaciones
nes tempranas nunca se transfieren a más adelante. de dependencia de las tareas, mientras el buffer de la
Todos los miembros del equipo son reacios a admitir CCPM se utiliza como una entrada a priori a la pla-
que terminaron antes de lo previsto por temor a que neación del cronograma, basado en el recorte a cada
la próxima vez se descuente tiempo en sus estima- actividad y la aplicación de un buffer de proyecto agre-
ciones. En tercer lugar, Goldratt sugiere que perde- gado al final.
mos tiempo en los proyectos debido a la tendencia
392 Capítulo 11  •  Programación de proyectos con cadena crítica

5. Comprender cómo la metodología de la cadena crítica puede aplicar en el portafolio de proyectos, en donde
resuelve los conflictos de recursos del proyecto.  La varios proyectos compiten por los recursos limitados
gerencia de proyectos con cadena crítica supone que la del proyecto. La gerencia del portafolio consiste, pri-
cadena crítica de un proyecto requiere primero identifi- mero, en identificar la máxima disponibilidad de recur-
car los conflictos de recursos y luego secuenciar tareas a sos en todos los proyectos del portafolio, priorizando
fin de eliminarlos . En lugar de emplear métodos de inicio los proyectos para el acceso a los recursos limitados,
temprano para las redes de actividades, el enfoque CCPM y luego secuenciar otras actividades de proyectos no
enfatiza el uso de los tiempos de inicio tardío, agregando claves en torno a los recursos a medida que estén dis-
buffers alimentadores en el cruce de las rutas alimenta- ponibles. El “recurso tambor” es el recurso crítico que
doras con la ruta crítica, y aplicando un buffer general en limita todo el portafolio. Para amortiguar los proyectos
el proyecto para utilizarlo cuando sea necesario. Todas que se secuenciaron para utilizar los recursos tambor,
las actividades secuencian a fin de explotar los conflictos la CCPM aconseja la creación de buffers de restricción
de recursos, lo cual garantiza mínimos retrasos entre las de capacidad (capacity constraint buffer:BCC) para
tareas y acelera el proyecto en general. controlar mejor la transición entre los proyectos, que
6. Aplicar la gerencia de proyectos con cadena crítica a hacen cola para emplear el recurso crítico.
los portafolios de proyectos.  La CCPM también se

Términos clave
Buffer de restricción de Causa especial de la gerencia Tambor (p. 386) Variación negativa (p. 376)
capacidad (CCB) (p. 387) de proyectos con cadena Teorema de límite central Variación positiva (p. 376)
Buffer tambor (p. 387) crítica (CCPM) (p. 370) (p. 378)
Cadena crítica (p. 378) Multitarea (p. 376) Teoría de las restricciones
Causa común de la Síndrome del estudiante (TOC) (p. 370)
variación (p. 372) (p. 375) Variación (p. 372)

Problemas resueltos
Suponga que tiene el diagrama PERT que se muestra en la figura proyecto. ¿Cómo volver a configurar esta parte del diagrama de red
11.16 y que ha identificado un conflicto de recursos en el que Cheryl del proyecto para mejorar la gerencia de su recurso crítico? ¿Cuál
está programada para trabajar en dos tareas al mismo tiempo. En sería la nueva “cadena crítica”?
este caso, Cheryl se ha convertido en el recurso restringido para su

Cheryl

Cheryl

Ruta crítica

FIGURA 11.16  Red de actividades actual


Problemas 393

SOLUCIÓN

Buffer de
alimentación Cheryl

Buffer de
alimentación

Buffer de
Cheryl
alimentación

FIGURA 11.17 SOLUCIÓN AL PROBLEMA RESUELTO   Red de cadena crítica

Preguntas para discusión


1. ¿Cuáles son las implicaciones prácticas de hacer promesas de 7. Distinga el buffer de proyecto del buffer de alimentación. ¿Cuán­do
entrega de proyectos excesivamente optimistas, tanto interna se utiliza y cuál es la utilidad cada uno de ellos?
(en términos de motivación del equipo) como externamente 8. Se afirma que una diferencia clave entre la seguridad de la
(para el cliente)? CCPM y tradicional holgura de actividad del grafo PERT es: la
2. Al considerar cómo hacer un gran cambio en las operaciones holgura de actividad se determina después de haber creado la
de una organización (por ejemplo, a la CCPM), ¿por qué red, mientras que la seguridad en la cadena crítica se determina
suele ser necesario centrarse en cambiar la cultura actual de la de antemano. Explique esta diferencia: ¿qué hace el equipo del
organización? Es decir, ¿por qué un cambio en la programa- proyecto para “encontrar” la holgura en un diagrama PERT? ¿,
ción de proyectos requiere tantos otros cambios vinculados? Cómo utiliza el equipo el buffer de actividad en la gerencia de
3. Explique la diferencia entre causa común de la variación y proyectos con cadena crítica?
causa especial de la variación. ¿Por qué son fundamentales 9. ¿Cuáles son los pasos por utilizar en la CCPM para resol-
estos conceptos para comprender los esfuerzos exitosos por ver conflictos de recursos en un proyecto? ¿De qué manera
mejorar la calidad y la fiabilidad de un sistema organizacional? el concepto de inicio tardío para las actividades ayuda a este
4. ¿Cuáles son las tres razones que Goldratt argumenta para justi- enfoque?
ficar la adición de cantidades excesivas de seguridad de nuestros 10. ¿Cuáles son los pasos claves por considerar en la CCPM
estimados de la duración del proyecto? Según sus experiencias como método para el control del portafolio de proyectos de la
en proyectos, ¿se justifican estos argumentos? empresa?
5. ¿Cuáles son las razones por las que rutinariamente desperdicia- 11. ¿Qué es un recurso tambor? ¿Por qué es importante entender
mos la excesiva seguridad que adquirimos para las actividades este concepto, a fin de mejorar el control de los requerimientos
del proyecto? Según sus experiencias, ¿algunas razones son más de recursos en los portafolios de proyectos?
frecuentes que otras?
6. ¿De qué manera la agregación de seguridad al proyecto per-
mite que el equipo del proyecto reduzca la seguridad global en
un valor que es menor que la suma de la seguridad individual
de las tareas? ¿Cómo emplea este mismo fenómeno la indus-
tria de seguros?

Problemas
1. Suponga el diagrama de la red que se muestra en la panta- recursos, a nivel de red, ¿cuáles serían dos opciones para vol-
lla 11.4. Megan es responsable de las actividades A y C. ver a dibujar la red? ¿Cuál es la más eficiente en tiempo para
Aplicando la metodología de la cadena crítica para nivelar los la terminación del proyecto? Muestre su trabajo.
394 Capítulo 11  •  Programación de proyectos con cadena crítica

PANTALLA 11.4 

2. Considere las siguientes actividades con sus duraciones. El crono-


grama del proyecto original, utilizando fechas de inicio temprano Actividad Duración
para las actividades, se muestra en la figura 11.18. Reconfigure la red A   5 días
aplicando la programación de proyectos con cadena crítica. B 30 días
¿Cuál es la ruta crítica? ¿Cuánta holgura está disponible en la ruta C 10 días
crítica? Reconfigure la red de la figura 11.18, como una red de D 10 días
cadena crítica. ¿Cuál es la nueva duración del proyecto? ¿De qué E 15 días
tamaño son los buffers de proyecto y los buffers dealimentación?

A (5) B (30)

E (15)

Holgura
C (10) D (10)

FIGURA 11.18 50 Días

3. Vuelva a reconfigurar la red de la figura 11.19 utilizando el enfo- ¿Cuánto buffer de alimentación debe aplicarse a rutas no críti-
que de cadena crítica. Recuerde que debe reconfigurar las activi- cas? ¿Cuál es el tamaño del buffer de proyecto? Suponga que la
dades para empezar más tarde, donde sea apropiado. ¿Cuál es la probabilidad de 50% es exactamente la mitad de la duración de
ruta crítica original? ¿Cuál es la duración original del proyecto? las actividades actuales del proyecto.

A (12) B (10) C (15)

D (8) E (10) H (15)

FIGURA 11.19  F (18) G (15)


Problemas 395

4. Suponga la red con conflictos de recursos, que se muestra en crítica con el fin de eliminar los conflictos de recursos? ¿Dónde
la figura 11.20. ¿Cómo redibujaría la red mediante una cadena se deben aplicar buffers de alimentación? ¿Por qué?

Buffer de
Joe
alimentación

Joe

RUTA CRÍTICA

Buffer de
Joe alimentación

FIGURA 11.20 

5. Considere el problema de portafolio de proyectos que se muestra Prioridad: 1. Proyecto X


en la figura 11.21. Usted está obligado a gerenciar los recursos para 2. Proyecto Y
darle cabida al portafolio de proyectos en curso de la compañía. 3. Proyecto Z
Una de las áreas de recursos, que incluye a Carol, Kathy y Tom, 4. Proyecto Q
es responsable de depurar todos los programas a medida que se
¿Dónde colocaría buffers de restricción de capacidad? ¿Por qué?
completan los nuevos proyectos. Cuatro proyectos tienen activi-
dades que requieren completarse. ¿Cómo programar el tiempo de
Carol, Kathy y Tom de manera más eficiente? Usando un buffer
tambor en la programación, reconfigure el siguiente cronograma
para obtener una utilización óptima del tiempo de los recursos:

Q Q
Suministro de recursos

Z Z

Y Y Y

X X X

Tiempo
FIGURA 11.21 
396 Capítulo 11  •  Programación de proyectos con cadena crítica

Estudio de caso 11.1


Judy, a la caza de la honestidad
Judy Thomas apenas tuvo tiempo para celebrar su nom- Judy se mordió los labios. “Bueno, tengo que
bramiento como directora de su departamento en Optimal hablar de eso con Randy. Aun teniendo en cuenta el
Logistics (OL), antes de verse envuelta en un problema hecho de que solicitar 24 horas en lugar de 32, Sid, usted
reiterativo con el personal de gerencia de proyectos. Como y yo sabemos que el trabajo que estamos estimando no
una parte de sus nuevas funciones, Judy es responsable de necesita tanto tiempo.”
lanzar todos los nuevos proyectos en OL, un trabajo que La respuesta de Sid no mejoró la confianza de Judy.
requiere la supervisión de 20 a 35 proyectos en cualquier “Umm, bueno, Judy, la cosa es... Quiero decir, tiene que
momento. Judy creyó en celebrar reuniones para revisar entender que en este momento estoy trabajando en un
detalladamente los proyectos cada dos semanas con sus montón de proyectos y...”
subordinados inmediatos, un grupo sénior de seis perso- Judy interrumpió: “No estoy preocupada por sus
nas de sistemas, evaluando el estado de los proyectos en otras tareas en este momento, Sid. Estoy tratando de tener
curso, desarrollando asignaciones de recursos para nue- una idea de esta estimación. ¿Cómo llegó a 24 horas?”
vos proyectos y, en general, solucionando los problemas Sid se retorció en su asiento. Finalmente, aclaró su
surgidos en el proceso de desarrollo de los proyectos. Una garganta y miró a Judy a los ojos. “Judy, el hecho es que
de las responsabilidades de los programadores sénior ‘fue tengo siete proyectos en marcha en estos momentos. Si
el desarrollo de la EDT para nuevos proyectos y, previa me quitan los otros seis, entonces podría conseguir fina-
consulta con los programadores júnior y líderes, dar una lizar la rutina en unas seis horas, pero no cuento con seis
estimación preliminar del tiempo necesario para comple- horas ininterrumpidas. Además, usted sabe cómo trabaja
tar la asignación. Randy. Si le doy una estimación honesta y no la cumplo,
Judy pronto se dio cuenta de que sus programa- aunque no sea por mi culpa, nunca dejaría que me olvide
dores sénior tenían una evaluación del tiempo necesario de él. Póngase en mi lugar por un momento: ¿cómo mane-
para completar los proyectos más pesimista, que desde el jar este trabajo?”
punto de vista de ella. En particular, todas las asignaciones Judy volvió a su escritorio reflexionando. “Tal vez el
de proyectos le parecían que estaban totalmente sobrees- problema aquí no sea nuestra capacidad para desarrollar
timadas. Como exprogramadora, con una experiencia de estimaciones precisas,” pensó. “Tal vez sea la cultura que
más de 10 años, Judy no lograba comprender cómo los nos está empujando a evitar ser honestos con los demás.”
programadores y los gerentes sénior de sistemas llegaron
a subir las estimaciones a tales niveles.
Preguntas
Una tarde, el problema estalló cuando recibió una eva-
luación para un trabajo de reprogramación de una rutina, el 1. Identifique, en el caso, algunos de los síntomas que apun-
cual fue estimado en más de 120 horas de trabajo. Con la eva- tan hacia los problemas culturales en el departamento
luación en la mano, ella se propuso descubrir cómo se había 2. ¿Qué medidas tomaría usted para comenzar a cam-
obtenido esa cifra. Judy primero se acercó al jefe de programa- biar la cultura en el departamento? En su respuesta,
ción, Sid, mientras él estaba sentado en su escritorio. tenga en cuenta los cambios que recomendaría en los
“Sid, esta estimación suya denota que requiere 32 sistemas de recompensa, en los métodos para estimar
horas para actualizar un sistema on line que solo necesita la duración de las actividades y en la asignación de
pequeños retoques. ¿Qué pasa?” tareas para el personal del proyecto.
Sid reaccionó con sobresalto. “Nunca puse 32 horas. 3. ¿Por qué supone que Randy tomó la estimación de la
Randy me pidió mi estimación y yo le dije que pensaba actividad de 24 horas de Sid y la aumentó a 32 horas
que tomaría aproximadamente 24 horas de trabajo.” cuando se la presentó a Judy?

Estudio de caso 11.2


Ramstein Products, Inc.
Jack Palmer, jefe de la División de Proyectos Especiales de las prácticas de gerencia de proyectos dentro de su divi-
de Ramstein Products, había estado en su nuevo cargo sión. Ramstein Products es un desarrollador líder de equi-
durante solo tres meses, cuando se le ordenó la evaluación pos integrados de prueba para la industria de la energía,
(continúa)
Notas 397

comercializa más de 45 líneas de productos para una de apoyo a un portafolio de 55 proyectos. Estos ingenie-
variedad de organizaciones que participan en los secto- ros fueron muy importantes para los esfuerzos de desa-
res de gas natural, exploración de petróleo, generación rrollo de nuevos productos de Ramstein, y sus servicios
de energía y servicios públicos. Como jefe de productos a menudo se extendían hasta el punto máximo. Uno de
especiales, Jack fue responsable de un portafolio de pro- los ingenieros sénior, Mary, recientemente informó a Jack
yectos en curso, con 50 a 60 proyectos de desarrollo de que estaba apoyando 14 proyectos, ¡todos desarrollándose
nuevos productos. La alta gerencia de Ramstein estima al mismo tiempo!
que 60% de los ingresos de la compañía proviene de nue- Jack reflexionó sobre alguna información que había
vos productos y tiene gran interés en las operaciones de la recibido durante su evaluación. Claramente, la opción
División de Proyectos Especiales. más sencilla sería acudir a la alta gerencia y solicitar más
Como una parte de la evaluación, Jack se dio cuenta ingenieros de sistemas de integración para su división. Sin
del hecho preocupante de que los proyectos estaban sobre- embargo, él tenía un presentimiento: en las condiciones
pasando sistemáticamente sus objetivos de presupuesto y económicas actuales, cualquier solicitud probablemente
de programación, a menudo por un margen significativo. sería rechazada. Tenía que formarse una idea clara de
Este hecho es especialmente preocupante porque Jack, los problemas y aplicar algunas soluciones ahora, con los
que trabajó una vez como jefe de proyecto dentro de la recursos disponibles.
división, era muy consciente de que la programación de
Preguntas
los proyectos no era muy dinámica. De hecho, él creía
que gran parte del tiempo en exceso había ingresado en 1. Aplicando las ideas de recursos críticos de Goldratt,
la programación del proyecto desde el momento en que ¿cuál es la restricción del sistema dentro de la División
se realizó inicialmente. Entonces, ¿por qué los proyectos de Proyectos Especiales que causa cuellos de botella y
no cumplían la fecha de terminación y estaban por encima retrasa los proyectos?
del presupuesto? 2. ¿Cómo contribuye la multitarea a los retrasos siste-
Aunque la División de Proyectos Especiales es muy máticos en el desarrollo de proyectos en Ramstein?
importante para el éxito futuro de Ramstein, por mucho 3. ¿Cómo podría aplicar el concepto de buffer tambor
tiempo había estado operando con un nivel de recursos a la gerencia del portafolio con cadena crítica, a este
ajustado. Hubo siete ingenieros de integración de sistemas problema?

Ejercicios en Internet
1. Ingrese en www.youtube.com/watch?v=BRMDCRPGYBE Your Project Management Problems.” ¿Cuáles son los beneficios
para que tenga una visión general de gerencia de proyectos que la CCPM ofrece a los proyectos organizacionales?
con cadena crítica. ¿Cuáles son los beneficios y los desafíos 4. Ingrese en www.focusedperformance.com/articles/multi02.
más grandes de la implementación de la CCPM, sugeridos html. En un artículo titulado “The Sooner You Start, the Later
por el presentador? You Finish” se trata una serie de puntos sobre la lógica de la
2. Visite el sitio web de Prentice Hall Companion y lea el artí- programación y el valor de la solución generada por la cadena
culo de Frank Patrick (1999), “Critical Chain Scheduling and crítica. Según su opinión, ¿cuáles son los argumentos centrales
Búfer Management: Getting Out from between Parkinson’s que autor expone en este artículo?
Rock and Murphy’s Hard Place,” PMNetwork, 13(4), pp. 5. Ingrese en www.goldratt.co.uk/Successes/pm2.html y examine
57–62. varias historias de casos de empresas que implementaron la
3. Visite el sitio web www.pqa.net/ccpm/W05001001.html y con- CCPM en sus operaciones de gerencia de proyectos. ¿Qué ca-
sidere algunos de los vínculos más importantes, incluido “What’s racterísticas propias a estas empresas ayudaron a que se desa-
New & Different about Critical Chain (CCPM)?” y “Diagnose rrollaran los métodos de la CCPM en sus proyectos?

Notas
1. www.railway-technology.com/projects/gotthard-base-tun- 2. Leach, L. P. (1999). “Critical chain project management im-
nel/; http://en.wikipedia.org/wiki/Gotthard_Base_Tunnel; proves project performance,” Project Management Journal,
www. yourdiscovery.com/machines_and_engineering/ 30(2): 39–51.
megabuilders/gotthardbasetunnel/index.shtml; Seidler, C. 3. Goldratt, E. (1984). The Goal. Great Barrington, MA: North
(2010). “Miracle under the Alps,” www.spiegel.de/interna- River Press; Goldratt, E. (1997). Critical Chain. Great
tional/ europe/0,1518,723202,00.html. Barrington, MA: North River Press.
398 Capítulo 11  •  Programación de proyectos con cadena crítica

4. Leach, L. P. (1999). “Critical chain project management im- calculations in project networks under resource constraints,”
proves project performance,” Project Management Journal, International Journal of Project Management, 14(4): 241–48;
30(2): 39–51; Leach, L. P., and Leach, S. P. (2010).Lean Patrick, F. (1999). “Critical chain scheduling and búfer man-
Project Leadership. Boise, ID: Advanced Projects, Inc. agement: Getting out from between Parkinson’s rock and
5. Goldratt, E. (1997). Critical Chain. Great Barrington, MA: Murphy’s hard place,” PMNetwork, 13(4): 57–62; Leach, L.
North River Press; Elton, J., and Roe, J. (1998, marzo-abril). P.(2003). “Schedule and cost búfer sizing: How to account
“Bringing discipline to project management,” Harvard for the bias between project erformance and your model,”
Business Review, 76(2): 78–83. Project Management Journal, 34(2): 34–47.
6. Leach, L. P. (2001). “Putting quality in project risk manage- 17. Merrill, J. (2009). “Lilly play up R&D productivity with reor-
ment, part 1: Understanding variation,” PMNetwork, 15(2): ganization,” www.biopharmatoday.com/2009/09/lilly-plays-
53–56. uprd-productivity-with-reorganization-.html.
7. Deming, J. E. (1989). Out of the Crisis.Cambridge, MA: MIT 18. Goldratt, E. (1984). The Goal. Great Barrington, MA: North
Press. River Press.
8. Leach, L. P. (2001). “Putting quality in project risk manage- 19. Gray, V., Felan, J., Umble, E., and Umble, M. (2000). “A com-
ment, part 1: Understanding variation,” PMNetwork, 15(2): parison of drum-búfer-rope (DBR) and critical chain(CC)
53–56. buffering techniques,” Proceedings of PMI Research
9. Goldratt, E. (1997). Critical Chain. Great Barrington, MA: Conference 2000. Newtown Square, PA: Project Management
North River Press; Herroelen, W., and Leus, R. (2000). “On the Institute, pp. 257–64.
merits and pitfalls of critical chain scheduling,” Proceedings of 20. Leach, L. P. (2000). Critical Chain Project Management.
PMI Research Conference 2000.Newtown Square, PA: Project Boston: Artech House.
Management Institute, pp. 283–95; Homer, J. L. (1998). 21. Leach, L.P. (1999). “Critical chain project management im-
“Applying the theory of constraints to projects,” Proceedings proves project performance,” Project Management Journal,
of the 29th Annual Project Management Institute Seminars and 30(2): 39–51, p. 41.
Symposium. CD-ROM. Newtown Square, PA: PMI. 22. Budd, C. S., and Cooper, M. J. (2005). “Improving on-time
10. Elton, J., and Roe, J. (1998, marzo-abril). “Bringing discipline service delivery: The case of project as product,” Human
to project management,” Harvard Business Review, 76(2): Systems Management, 24(1): 67–81.
78–83. 23. Emam, K. E., and Koru, A. G. (2008). “A replicated survey
11. Citado en Leach, L. P. (1999). “Critical chain project manage- of IT software project failures,” IEEE Software, 25(5): 84–90;
ment improves project performance,” Project Management www.realization.com/customers.html.
Journal, 30(2): 39–51, p. 43. 24. Zalmenson, E. (2001, enero). “PMBOK® and the critical
12. Steyn, H. (2000). “An investigation into the fundamentals of chain,” PMNetwork, 15(1): 4.
critical chain project scheduling,” International Journal of 25. Duncan, W. (1999, abril). “Back to basics: Charters, chains,
Project Management, 19: 363–69. and challenges,” PMNetwork, 13(4): 11.
13. Sherman, E. (2002). “Inside the iPod design triumph,” 26. Elton, J., and Roe, J. (1998, marzo, abril). “Bringing discipline
Electronics Design Chain Magazine, www.designchain.com/ to project management,” Harvard Business Review, 76(2):
coverstory.asp?issue=summer02. 78–83.
14. Newbold, R. C. (1998). Project Management in the Fast Lane. 27. Raz, T., Barnes, R., and Dvir, D. (2003). “A critical look at
Boca Raton, FL: St. Lucie Press; Tukel, O. I., Rom, W. O., critical chain project management,” Project Management
and Eksioglu, S. D. (2006). “An investigation of búfer sizing Journal, 34(4): 24–32.
techniques in critical chain scheduling,” European Journal of 28. Pinto, J. K. (1999). “Some constraints on the theory of
Operational Research, 172: 401–16. constraints: Taking a critical look at the critical chain,”
15. Steyn, H. (2000). “An investigation into the fundamentals of PMNetwork, 13(8): 49–51.
critical chain project scheduling.” International Journal of 29. Piney, C. (2000, diciembre). “Critical path or critical chain.
Project Management, 19: 363–69. Combining the best of both,” PMNetwork, 14(12): 51–54;
16. Hoel, K., and Taylor, S. G. (1999). “Quantifying búferes for Steyn, H. (2002). “Project management applications of the
project schedules,” Production and Inventory Management theory of constraints beyond critical chain scheduling,”
Journal, 40(2): 43–47; Raz, T., and Marshall, B. (1996). “Float International Journal of Project Management, 20: 75–80.
CAPÍTULO

12
Gerencia de recursos

Contenido del capítulo


PERFIL DE PROYECTO 12.5 GERENCIA DE RECURSOS EN ENTORNOS
Nissan LEAF: nuevo campeón en economía de MULTIPROYECTO
 combustible Retrasos en el cumplimiento del cronograma
INTRODUCCIÓN Utilización de recursos
12.1 LAS BASES DE LAS RESTRICCIONES DE Inventario en proceso
RECURSOS Toma de decisiones de recursos en entornos
La escasez de tiempo y de recursos  multiproyecto
Resumen
12.2 CARGA DE RECURSOS
Términos clave
12.3 NIVELACIÓN DE RECURSOS Problemas resueltos
Paso uno: desarrollar un cuadro de carga de recursos Preguntas para discusión
Paso dos: determinar los fines tardíos de las actividades Problemas
Paso tres: identificar la sobreasignación de recursos Estudio de caso 12.1 Los problemas de la multitarea
Paso cuatro: nivelar el cuadro de carga de recursos Ejercicios en internet
12.4 DIAGRAMAS DE CARGA DE RECURSOS Ejercicios con MS Project
GERENTES DE PROYECTOS EN LA PRÁCTICA Preguntas de ejemplo del examen para la certificación PMP®
Capitán Kevin O’Donell, US Marine Corps Proyecto integrado. Gerencia de los recursos de su proyecto
Notas

Objetivos de aprendizaje
Al finalizar el capítulo, el estudiante estará en capacidad de:
1. Reconocer la variedad de limitaciones que pueden causar dificultades en la programación y planeación de un proyecto.
2. Entender cómo aplicar las técnicas de carga de recursos a cronogramas de proyectos para identificar posibles sobreasignacio-
nes de recursos.
3. Aplicar procedimientos de nivelación de recursos a las actividades del proyecto sobre la línea base del cronograma, mediante
heurísticas adecuadas de priorización.
4. Seguir los pasos necesarios para suavizar efectivamente los requerimientos de recursos en todo el ciclo de vida del proyecto.
5. Aplicar la gerencia de recursos en un entorno multiproyecto.

399
400 Capítulo 12  •  Gerencia de recursos

CONCEPTOS BÁSICOS DE LOS FUNDAMENTOS PARA LA GERENCIA DE


PROYECTOS(PROJECT MANAGEMENT BODY OF KNOWLEDGE, PMBOK® GUIDE, 5A.
EDICIÓN) CUBIERTOS EN ESTE CAPÍTULO
1. Estimación de recursos de actividades (PMBOK®, 6.3).
2. Planeación de recursos humanos (PMBOK®, 9.1).

PERFIL DE PROYECTO

Nissan LEAF: nuevo campeón en economía de combustible


En esta era de mayor conciencia ambiental, pocos productos nuevos son más “verdes” que el Nissan LEAF. Los
automóviles híbridos que combinan gasolina y energía eléctrica han estado disponibles desde hace varios años y
están convirtiéndose cada vez más en la tendencia. De hecho, la revista Motor Trend destacó al híbrido Chevrolet
Volt como el Auto del año 2011, en reconocimiento a su estilo, calidad y características de rendimiento de este
nuevo venture. Ciertamente, muchos argumentan que con su capacidad para utilizar energía “limpia”, una menor
dependencia de fuentes externas de petróleo y un trato amable con el medio ambiente, la nueva generación de
automóviles híbridos probablemente gane mayor participación en el mercado y mayor aceptación de los clientes.
Desde esta perspectiva de respaldo a los automóviles híbridos, el LEAF de Nissan ha generado un efecto positivo.
En realidad, LEAF es una sigla de Leading, Environmentally friendly, Affordable, Family car. Nissan desarrolló
el LEAF diferente de la actual generación de híbridos; este no es, estrictamente hablando, un híbrido del todo,
porque no tiene motor de gasolina. Los autos híbridos estándar utilizan la electricidad para marchar en bajas velo-
cidades en recorridos relativamente cortos, lo cual es ideal para los viajeros que quieren ahorrar dinero en el reco-
rrido diario a la oficina o lugar de trabajo. Sin embargo, cuando se viaja a altas velocidades en las autopistas o en
recorridos más largos, las baterías no pueden alimentar el auto y el motor de gasolina se activa automáticamente,
mientras se carga la batería. Como resultado, los híbridos normalmente promedian cerca de 50 millas por galón
(mpg) para recorridos “menores” y no para recorridos extensos o viajes por carretera.
El LEAF de Nissan no trabaja de esa forma. El LEAF, que no usa gasolina en absoluto, fue calificado como el mejor
en su clase en pro del medio ambiente, pues no emite gases de efecto de invernadero o las tradicionales emisiones
del tubo de escape. La EPA calificó con ≈ 99 millas por galón para el 2011 Nissan LEAF, tanto en ciudad como en carre-
tera. Esta agencia obtuvo la cifra de economía de combustible del LEAF utilizando una fórmula de equivalencia para
ZUMA Wire Service / Alamy

FIGURA 12.1  El LEAF de Nissan


Introducción 401

darles a los compradores de autos un estándar por el cual juzgar la eficiencia del combustible en general y de impacto
ambiental de una amplia gama de vehículos que utilizan una variedad de combustibles y fuentes de energía.
En reconocimiento a los avances en su creación, el LEAF ganó en 2010 el premio “Mejor auto para comprar”
otorgado por Green Car Reports. Sus razones para la elección del LEAF sobre otros híbridos, incluido el Chevrolet
Volt, fueron:
• Un auto eléctrico real:   “Debido a que es el único vehículo ofrecido a los compradores de Estados Unidos (este
modelo del año, por un fabricante de automóviles global) que no utiliza gasolina en ningún caso. Vendrán mu-
chos más en el futuro, pero este año el LEAF 2011 es el único.”
• La huella de carbono más baja:  “Sin importar las cifras, es el vehículo con la huella de carbono más baja de
todos los autos nuevos vendidos en la actualidad.”
• 90% de sus necesidades es suficiente:  “Así como General Motors le dirá a usted que más de 70% de los ve-
hículos estadounidenses hacen menos de 40 millas al día, Nissan señala con frecuencia que más de 90% de los
vehículos estadounidenses hacen menos que el rango del LEAF de 100 millas por día.”
Green Car resume todo el asunto al concluir que el LEAF es el primer vehículo eléctrico práctico que se puede usar,
y el hecho de que nadie va a recargar con una onza de gasolina, supera las deficiencias que aún puede tener un
vehículo de gasolina, híbrido o no.
En el aspecto comercial del LEAF, Nissan está trabajando para minimizar todos los riesgos potenciales que
implican traer el auto a Norteamérica. Reconoce que esta tecnología será difícil de aceptar para los concesiona-
rios y mecánicos, y en un principio no querrán sacrificar su voluntad debido a problemas técnicos frustrantes.
Según Automotive News, el fabricante japonés ha reunido un grupo de trabajo de reacción rápida para identificar
oportunamente quejas de los clientes antes de que se salgan de control. El equipo, con sede en Los Ángeles, está
dirigido por un grupo de diez ingenieros entrenados profundamente en el tren motor del vehículo, y cada uno
de ellos tendrá un equipo de alrededor de 30 técnicos para brindar ayuda adicional cuando sea necesario. Nissan
estudia la posibilidad de instalar equipos similares en Europa y Japón.
La movida es parte de un esfuerzo para aliviar cualquier preocupación que los compradores puedan tener
acerca de su vehículo eléctrico. En Japón, Nissan ha ido tan lejos como para ofrecer un programa con remolque
gratis, carga gratuita ilimitada en los concesionarios y una línea telefónica 24 horas para atender preguntas de
los propietarios. Puede que en un futuro próximo Nissan Estados Unidos haga lo mismo. Los primeros vehículos
eléctricos 2011 llegaron a finales de 2010. A finales de ese año, había una lista de espera de más de 20,000 perso-
nas que se inscribieron para comprar un LEAF. Nissan planea construir los automóviles en Japón durante los dos
primeros años y luego cambiar a un sitio en Smyrna, Tennessee, para construirlos en Estados Unidos.
Desarrollar la tecnología para el automóvil híbrido ha sido costosa. De hecho, las inversiones de Toyota en su
programa híbrido, el cual ha sido unos dos tercios del mercado mundial de autos eléctricos híbridos, han costado
más de 10,000 millones de dólares durante 15 años. Los críticos también acusan a los fabricantes de automóviles
de utilizar estos autos de “líderes en pérdidas” para sus flotas, y señalan que el costo unitario para su fabricación es
más alto que su precio en el mercado, es decir, cuanto más autos se vendan más dinero pierden los fabricantes. No
obstante, aunque la tecnología todavía está perfeccionándose y el costo de estos autos es bastante alto, una com-
binación de incentivos del gobierno de sensibilización ambiental y de consumo está empujando a los compradores
estadounidenses a considerar la combinación eléctrica/híbrida de vehículos como una opción seria. Expertos de la
industria sugieren que la próxima década deberá mostrar autos eléctricos más económicos, con un rango mayor
de ahorro en el consumo, precios más económicos y cada vez mayor cuota de mercado, ya que los consumidores de
las áreas metropolitanas reconocen las ventajas del viaje en auto híbrido/eléctrico.1

INTRODUCCIÓN
Como se señaló en el capítulo 1, una de las características definitivas de los proyectos son las restricciones o
limitaciones con las cuales se debe operar. La principal restricción es la disponibilidad de recursos, tanto de
dinero como de personas en los momentos claves en que se necesitan. La estimación del costo del proyecto
inicial y la presupuestación —aquellas actividades que definen recursos—son elementos importantes en la
gerencia de proyectos. Cuando estos dos se llevan a cabo, se aseguran los recursos necesarios para el proyecto
a medida que este avanza.
En los capítulos 9 y 10 sobre la programación de proyectos, vimos que los diagramas de red, las esti-
maciones de duración de actividades y las listas globales pueden desarrollarse sin un debate serio sobre la
disponibilidad de los recursos. Solo fue en el capítulo 11 “Programación de proyectos con cadena crítica” en
donde la disponibilidad de recursos llegó como un requisito previo para la planeación exacta. La realidad de
402 Capítulo 12  •  Gerencia de recursos

la organización, por supuesto, es muy distinta. Si los proyectos se definen por sus restricciones de recursos,
cualquier intento de crear un cronograma de proyecto razonable debe pasar la prueba de la disponibilidad de
recursos. Así, la programación efectiva del proyecto es en realidad un proceso de varios pasos. Después que la
red de actividades se construye, la segunda etapa debe ser siempre verificarla contra los recursos implicados
en cada actividad. La disponibilidad de recursos apropiados siempre tiene una relación directa con la dura-
ción de las actividades del proyecto.
En este capítulo, vamos a explorar el concepto de la planeación y la gerencia de recursos. Lograr una mejor
comprensión de cómo la gerencia de recursos se ajusta al esquema general de planeación y programación del
proyecto nos da una ventaja importante a la hora de tomar todos esos planes cuidadosamente trazados y hacer
que funcionen. El capítulo se divide en dos secciones principales: restricciones de recursos y gerencia de recursos.

12.1  LAS BASES DE LAS RESTRICCIONES DE RECURSOS


Probablemente, el tipo más común de restricción gira en torno a la disponibilidad de recursos humanos para
llevar a cabo el proyecto. Como hemos señalado, uno de los métodos claves para acortar la duración de los pro-
yectos es mover tantas actividades como sea posible desde rutas secuenciales hasta rutas paralelas. Este enfoque
supone, por supuesto, que el personal es libre de apoyar la realización de múltiples actividades al mismo tiempo
(la idea detrás del trabajo paralelo). En los casos en los que no tenemos suficientes personas u otros recursos
críticos, simplemente no podemos trabajar en modo paralelo. Cuando se crean los proyectos sin tener en cuenta
los recursos humanos suficientes, los equipos de proyecto se sitúan inmediatamente en una posición difícil,
reactiva. El personal se asigna a múltiples tareas a la vez, se espera que trabajen muchas horas, y no podrán reci-
bir un entrenamiento adecuado. Los trade-offs entre la duración de las actividades del proyecto (y usualmente el
cronograma general del proyecto) y la disponibilidad de recursos son el resultado natural.
En algunas situaciones, las restricciones físicas que rodean un proyecto pueden ser una fuente de gran
preocupación para la empresa que intenta producir el entregable. Las cuestiones ambientales o contractuales
pueden crear algunos problemas verdaderamente memorables; por ejemplo, el gobierno de Filipinas con-
trató el desarrollo de una planta de energía nuclear en la ciudad de Manila. Curiosamente, el lugar elegido
para su construcción fue contra el ambiente del monte Natib, un volcán en las afueras de la ciudad. Como la
construcción procedió, ambientalistas condenaron, con razón, la elección del lugar, con el argumento de que
la actividad sísmica podría desplazar los sistemas de operación de los reactores y generar resultados catastró-
ficos. Finalmente, se llegó a un acuerdo de solución, en el que la fuente de energía para la planta se convirtió
de energía nuclear a carbón. Con la multitud de problemas que enfrentó este proyecto, se conoció como
el “Fiasco nuclear de 2,200 millones de dólares.”2 Este caso es un ejemplo extremo, pero como seguiremos
viendo, muchos problemas reales pueden derivarse de tomar un proyecto difícil y tratar de desarrollarlo en
condiciones físicas peligrosas o complejas.
Los materiales son un recurso común de proyecto que debe considerarse en la programación. Esto es
más obvio en una situación en la que un activo físico se va a crear, como un puente, edificio u otro proyecto
de infraestructura. Tener una reserva de una cantidad suficiente de los diversos recursos que se necesitan
para completar los pasos del proyecto es un factor clave en la estimación de la duración de las tareas.
La mayoría de los proyectos están sujetos a presupuestos muy limitados (fijos). ¿Hay suficiente capital
de trabajo para garantizar que el proyecto pueda completarse en el tiempo permitido? Es una apuesta segura
para suponer que cualquier proyecto sin un presupuesto adecuado está condenado al fracaso.
Muchos proyectos requieren técnicas o tipos específicos de equipos para tener éxito. En el desarrollo
de un nuevo concepto de revista, por ejemplo, un equipo de proyecto puede necesitar computadores de van-
guardia con software especializado de gráficos para crear brillo y encanto. La programación de equipos es
igualmente importante. Cuando el equipo se comparte entre departamentos, debería estar disponible en los
tiempos cuando sea necesario para el proyecto. En la construcción de vivienda, por ejemplo, la mezcladora
de cemento debe estar en el lugar a los pocos días después de que se ha excavado.

La escasez de tiempo y de recursos


En un proyecto con restricciones de tiempo, el trabajo debe finalizarse en una hora o fecha determinada, lo
más eficientemente posible. Si es necesario, se añadirán recursos adicionales para lograr los “objetivos claves.”
“Obviamente, el proyecto debe llevarse a cabo sin el uso excesivo de recursos, pero esta preocupación es secun-
daria al objetivo de completar el proyecto a tiempo. Por ejemplo, los proyectos destinados a una presentación
comercial o aquellos en los que la entrega tardía incurrirá en penas altas son a menudo limitados en tiempo.
12.1  Las bases de las restricciones de recursos 403

En proyectos con restricciones de recursos, el trabajo no debe ser superior a un nivel predetermi-
nado de uso de recursos dentro de la organización. Si bien el proyecto se completará lo más rápido posible,
la velocidad no es el objetivo final. El principal factor que impulsa el proyecto es reducir al mínimo el uso
de recursos. En este caso, retrasos en la terminación del proyecto pueden ser aceptables cuando se balancea
contra la sobreasignación de recursos.
El proyecto con restricciones mixtas está principalmente limitado por recursos, pero puede contener
algunas actividades o elementos de paquetes de trabajo limitados en tiempo, en un mayor nivel. Por ejemplo,
si las fechas críticas de entrega se deben cumplir para algunos subcomponentes del proyecto, pueden verse
como limitadas en tiempo dentro del proyecto global, con recursos limitados. En estas circunstancias, el
equipo del proyecto debe desarrollar un plan de gerencia del cronograma y de recursos que asegure la mini-
mización del uso de recursos en general, mientras asigna niveles necesarios para alcanzar las fechas máximas
de entrega para algunos componentes del proyecto.
Hay en casi todos los proyectos, por lo general, una restricción dominante que sirve como el árbitro
final en las decisiones del proyecto. Centrarse en la restricción crítica, basada en el tiempo o en los recursos,
sirve como punto de partida para la elaboración de una programación de recursos cargados razonablemente,
refleja las metas y objetivos corporativos que son alcanzables.3
El reto de la programación óptima de recursos en el diagrama de red de actividades del proyecto se
convierte rápidamente en algo altamente complejo. Por un lado, estamos tratando de crear una red eficiente
de actividades que programe actividades en paralelo y asegure el ciclo de desarrollo más corto posible. Al
mismo tiempo, nos enfrentamos inevitablemente con el problema de encontrar y proporcionar los recursos
necesarios para lograr estos cronogramas optimistas y agresivos. Somos siempre conscientes de la necesidad
de hacer malabares con los cronogramas y la disponibilidad de recursos, tratando de identificar la solución
óptima a este problema combinado. Hay dos retos igualmente importantes que hay que afrontar: (1) la iden-
tificación y adquisición de los recursos necesarios para el proyecto y (2) su adecuada programación o secuen-
ciación a lo largo de la línea de base del proyecto.4

EJEMPLO 12.1 Trabajo con restricciones de proyecto

Este es un ejemplo que muestra con lo que se enfrentan los equipos de proyecto cuando intentan gerenciar los
recursos del proyecto. Supongamos que creamos una red de actividades simple del proyecto, con base en la
información suministrada en el cuadro 12.1. La pantalla 12.1 muestra un diagrama parcial de red, creado con
Microsoft Project 2010. Tenga en cuenta que las tres primeras actividades se han asignado con una duración
de cinco días cada una; así, las actividades B y C* están listas para comenzar en la misma fecha, después de la
finalización de la actividad A. Desde el punto de vista de desarrollo del cronograma, en sentido estricto, esta
secuencia puede ser correcta; infortunadamente, el gerente del proyecto creó la red de tal manera que ambas
actividades requieren las habilidades especiales de un solo miembro del equipo del proyecto. Para que esta
persona lleve a cabo ambas tareas al mismo tiempo, requiere una gran cantidad de horas extras o realizar
ajustes a la fecha prevista para la finalización de ambas tareas. En resumen, tenemos un caso de recursos mal
asignados dentro de la línea base del cronograma. El resultado es forzar al equipo del proyecto a tomar una
decisión: aumentar de los costos para la realización de estas actividades o extender el cronograma para permi-
tir horas extras necesarias a fin de efectuar las dos actividades al mismo tiempo. Cualquiera de estas opciones
le cuesta al proyecto dos cosas que no pueden permitirse: aumento de tiempo y dinero.

CUADRO 12.1  Precedencia de actividades

Actividad Descripción Duración Predecesoras Responsable


A Asignación de ofertas 5 días Ninguna Tom
B Entrega de documentos 5 días A Jeff
C Cálculo de costos 5 días A Jeff
D Selección de la oferta 1 día B, C Sue
ganadora
E Desarrollo de la campaña PR 4 días D Carol

*Microsoft Project 2010 identifica las actividades B y C como las tareas 2 y 3, respectivamente.
404 Capítulo 12  •  Gerencia de recursos

PANTALLA 12.1  Ejemplo de red de actividades con conflictos

PANTALLA 12.2  Diagrama de carga de recursos con sobreasignación

El mejor método para establecer la existencia de conflictos de recursos a través de las actividades del
proyecto utiliza los diagramas de carga de recursos (que se describen con más detalle en la siguiente sección)
que analizan los recursos del proyecto contra de las actividades de línea base del cronograma del proyecto.
Los diagramas de carga de recursos le permiten al equipo del proyecto programar el trabajo y comprobar la
lógica en el establecimiento de las necesidades de recursos para las actividades del proyecto. Una gráfica sim-
plificada de diagrama de carga de recursos con MS Project 2010 destaca el conflicto de recursos de la pantalla
12.1 y se muestra en la pantalla 12.2.
Note lo que le ha sucedido a la disponibilidad de recursos de Jeff. La salida de MS Project 2010
destaca el hecho de que por un periodo de cinco días, se espera que Jeff trabaje 16 horas cada día para
llevar a cabo las actividades B y C al mismo tiempo. Debido a que el cronograma en la pantalla 12.1 no
prestó suficiente atención a las demandas que compiten por su trabajo cuando se creó el diagrama de
actividades, el equipo del proyecto se enfrenta ahora con el problema de haber determinado el tiempo
de Jeff de manera sobreasignada. Aunque simplificado, este caso es solo un ejemplo de la complejidad
que añadimos a la planeación del proyecto cuando empezamos a acoplar la red de actividades con la
asignación de recursos.

12.2  CARGA DE RECURSOS


La carga de recursos se refiere a la cantidad de recursos individuales que requiere un cronograma durante
periodos específicos.5 Podemos cargar o colocar en un cronograma detallado los recursos con relación a
tareas específicas o a la totalidad del proyecto. Como regla general, es beneficiosa para dos cosas: crear un
diagrama de carga de recursos del proyecto a nivel general e identificar las necesidades de recursos para cada
tarea individual. En términos prácticos, la carga de recursos intenta asignar los recursos apropiados, con el
grado o la cantidad adecuada para cada actividad del proyecto.
12.2  Carga de recursos 405

PANTALLA 12.3  Ejemplo de red de actividades del proyecto y diagramas de Gantt

PANTALLA 12.4  Cuadro de uso de recursos

Si relacionamos el ejemplo presentado, mostrado en detalle en la pantalla 12.3, con el diagrama de


Gantt original del proyecto, vemos que estos primeros pasos están incompletos hasta que las subsecuentes
asignaciones de recursos se hacen para cada actividad del proyecto. En la pantalla 12.3 hemos fijado tem-
poralmente el problema de sobreasignación de Jeff añadiendo otro recurso, Bob, que se ha convertido en
el responsable de la actividad C: cálculo de los costos.
Una vez desarrolladas la estructura de desglose de trabajo (EDT) y la red de actividades, la mecánica
real de la creación de un formato de carga de recursos (a veces conocido como un cronograma de uso de
recursos) es relativamente simple. Todo el personal se identifica y se le asigna la responsabilidad de cada
tarea. Además, sabemos que número de horas en función de cada semana de cada persona está disponible.
De nuevo, usando la plantilla de Microsoft Project 2010 podemos crear el cuadro de uso de recursos para
reflejar cada una de estas piezas de información (véase la pantalla 12.4).
La información en el cuadro de uso de recursos mostrada en la pantalla 12.4 incluye a los miembros
del equipo del proyecto, las tareas asignadas a estos y el tiempo esperado que cada actividad tomará a lo
largo de la línea base del cronograma. En este ejemplo, hemos reasignado personal para cubrir cada tarea,
eliminando así el problema de sobreasignación originalmente descubierto en la pantalla 12.2. Los miembros
del equipo se asignan al proyecto de tiempo completo (40 horas/semana) y la carga de sus asignaciones a lo
406 Capítulo 12  •  Gerencia de recursos

PANTALLA 12.5  Ejemplo de cuadro de uso de recursos con sobreasignación

largo de las actividades del proyecto corresponde a la red de actividades del proyecto, lo cual proporciona, en
esencia, una vista por fases del diagrama de carga de recursos.
El cuadro de uso de recursos también puede proporcionar señales de alerta de sobreasignación de
recursos del proyecto. Por ejemplo, supongamos que Jeff se asignó de nuevo a las dos actividades, B y C,
como en el ejemplo inicial de este capítulo. Viendo el cronograma original del proyecto, no hay ninguna
señal de esta sobreasignación de recursos. Cuando generamos el cuadro de uso de recursos, descubrimos
la verdad (véase la pantalla 12.5). En este ejemplo, Jeff está actualmente programado para trabajar 64 horas
durante un periodo de una semana (la semana del 11 de enero): ¡un escenario demasiado optimista respecto
a su capacidad de trabajo!
El beneficio del proceso de carga de recursos es evidente, pues sirve de “verificador” de la programa-
ción original del equipo del proyecto. Cuando el cronograma se somete a la carga de recursos, el equipo
rápidamente conoce la deficiente asignación de personal, la sobreasignación de los miembros del equipo y,
en algunos casos, la falta de recursos requeridos. Por tanto, el proceso de carga de recursos puede señalar
defectos en la (EDT) y en el cronograma del proyecto. ¿Cómo responder de la mejor forma a los problemas
de carga de recursos y otras restricciones del proyecto? es la siguiente pregunta que el gerente del proyecto y
el equipo del proyecto deben responder.

12.3  NIVELACIÓN DE RECURSOS


La nivelación de recursos es el proceso que aborda los complejos desafíos de las restricciones del proyecto.
Con la redistribución de recursos estamos obligados a desarrollar procedimientos que reduzcan al mínimo
los efectos de la demanda de recursos en todo el ciclo de vida del proyecto. La nivelación de recursos, a veces
conocido como suavizado de los recursos, tiene dos objetivos:
1. Determinar las necesidades de recursos para que puedan estar disponibles en el momento adecuado
2. Permitir que cada actividad que se programe con la transición más suave posible a través de los niveles
de utilización de recursos
La nivelación de recursos es útil porque nos permite crear un perfil de las necesidades de recursos para las
actividades de proyectos en todo el ciclo de vida. Además, minimizamos las fluctuaciones de un periodo al
otro a través del proyecto. Cuanto más lejos avancemos en anticipar y planificar las necesidades de recur-
sos, más fácil se torna la gerencia del flujo natural entre actividades del proyecto sin tiempo de inactividad,
mientras comenzamos la búsqueda de los recursos necesarios para continuar con las tareas del proyecto.
12.3  Nivelación de recursos 407

El reto principal es la toma de decisiones de asignación de prioridades que fijen la cantidad adecuada de
recursos a las actividades apropiadas en el momento adecuado.
Debido a que la gerencia de recursos es un problema multivariable y combinatorio (es decir, se carac-
teriza por múltiples soluciones que a menudo implican docenas, cientos o incluso miles de variables de acti-
vidad), la solución matemáticamente óptima puede ser difícil o inviable debido al tiempo necesario para
resolver todas las posibles opciones de la ecuación. Por tanto, un enfoque común para el análisis de proble-
mas de nivelación de recursos es aplicar algunas heurísticas de nivelación, o reglas simplificadas, al tomar
decisiones entre alternativas de nivelación de recursos.6
Algunas heurísticas simples para priorizar la asignación de recursos incluyen la destinación de los
recursos a:
1. Actividades con la menor cantidad de holgura.  La regla de decisión es asignar recursos prioritarios
a aquellas actividades con la menor cantidad de tiempo de holgura. Algunos argumentan que esta regla
de decisión es la mejor para la toma de decisiones de priorización, lo que genera la mínima demora en
el cronograma del proyecto.7
2. Actividades con la más corta duración.  Las tareas se ordenan de la menor hasta la mayor duración
y los recursos se priorizan de la misma manera.
3. Actividades con el más bajo número de identificación de la actividad.  (Por ejemplo, aquellas que
comienzan más temprano en la EDT). Esta heurística sugiere que en caso de duda, es mejor designar
primero los recursos a las tareas tempranas.
4. Actividades con el mayor número de tareas sucesoras.  Seleccionamos los recursos prioritarios para
las tareas que tienen el mayor número de tareas sucesoras.
5. Actividades que requieren más recursos.  Es común destinar primero los recursos a aquellas activida-
des que requieren el mayor apoyo y luego analizar las tareas pendientes en función de la disponibilidad
de recursos adicionales.
Con base en estas heurísticas, consideremos un simple ejemplo y el método que usaríamos para selec-
cionar las actividades que primero reciben el “derecho” al paquete de recursos. Supongamos que un
proyecto tiene dos actividades (véase la figura 12.2) programadas que requieren el mismo recurso al
mismo tiempo. Al decidir qué actividad debe tener la prioridad para los recursos disponibles, podemos
seguir la lógica heurística utilizada en la primera regla de decisión y examinar las tareas B y C por pri-
mera vez, en términos de su respectiva cantidad de tiempo de holgura. En este caso, la actividad C, con
tres días de holgura, sería la mejor elección para priorizar el recurso. Sin embargo, supongamos que las
actividades B y C tienen tres días de holgura cada una. Entonces, de acuerdo con el modelo heurístico,
podríamos pasar a la segunda regla de decisión y adjudicar la primera prioridad a la actividad B. ¿Por
qué? Porque la actividad B tiene una duración programada de cinco días, en lugar de una duración de
seis días de la actividad C. En el caso improbable de que se descubra que se mantuvo un empate entre
actividades B y C, después de usar las dos primeras heurísticas, se podría aplicar la tercera heurística
y simplemente asignar el recurso a la tarea con el menor número de identificación en la EDT (en este
caso, la actividad B). Como veremos, la implicación de cómo se priorizan los recursos es importante, ya
que tiene un “efecto dominó “ en la redistribución de recursos posterior a lo largo del resto de la red de
actividades.

B
4
5

C
FIGURA 12.2  Ejemplo de red de 3
actividades con nivelación de recursos 6
408 Capítulo 12  •  Gerencia de recursos

EJEMPLO 12.2 Una mirada a fondo de la nivelación de recursos

Un ejemplo más complejo de nivelación de recursos ilustra el desafío de los equipos de proyectos a la hora
de asignar la nivelación de recursos a una red de actividades. Supongamos que construimos un diagrama de
red del proyecto con base en la información del cuadro 12.2. Con el procedimiento sugerido en el capítulo 9,
también podemos derivar el inicio temprano (early start:ES), inicio tardío (late start: LS), fin temprano (early
finish:EF), fin tardío (late finish:LF) y la posterior holgura para cada tarea en la red. El cuadro 12.3 recoge el
conjunto de datos.

CUADRO 12.2 Actividades predecesoras y duraciones


y para el proyecto de ejemplo

Actividades Duración Predecesoras


A 5 —
B 4 A
C 5 A
D 6 A
E 6 B
F 6 C
G 4 D
H 7 E, F
I 5 G
J 3 G
K 5 H, I, J

CUADRO 12.3  Relación completa de tareas para el proyecto de ejemplo

Actividad Duración ES EF LS LF Holgura


A 5  0  5  0  5 —
B 4  5  9  6 10 1
C 5  5 10  5 10 —
D 6  5 11  8 14 3
E 6  9 15 10 16 1
F 6 10 16 10 16 —
G 4 11 15 14 18 3
H 7 16 23 16 23 —
I 5 15 20 18 23 3
J 3 15 18 20 23 5
K 5 23 28 23 28 —

El cuadro 12.3 muestra la ruta crítica A – C – F – H – K. La pantalla 12.6 muestra un diagrama de Gantt
simplificado que corresponde a las actividades enumeradas en el cuadro, sus duraciones y sus predecesoras.
Este diagrama se basa en la red de actividad mostrada en la figura 12.3. Una red de actividades más completa
se muestra en la figura 12.4, y se listan los ES, LS, EF y LF para cada actividad. Ahora es posible crear un cua-
dro de carga de recursos mediante la combinación de la información de la pantalla 12.6 y la figura 12.4, con
un factor adicional: los recursos requeridos para completar cada actividad del proyecto.
Naturalmente, existe una relación directa entre los recursos que podemos asignarle a una tarea y
el tiempo para su finalización. Por ejemplo, supongamos que una tarea que requiere una persona que
trabaja 40 horas por semana se estima tardará dos semanas (80 horas) para completarse. En general,
podemos modificar la estimación de la duración, dados los ajustes a la disponibilidad de los recursos
proyectados requeridos en la tarea. Por ejemplo, si ahora asignamos dos personas para trabajar tiempo
completo (40 horas) en la tarea, la nueva duración de la actividad será una semana. Aunque la tarea
12.3  Nivelación de recursos 409

PANTALLA 12.6  Diagrama de Gantt para el proyecto de ejemplo

B E H
4 6 7

A C F
5 5 6
K
5

I
5
D G
6 4

J
3

FIGURA 12.3  Red de actividades para el proyecto de ejemplo

5 B 9 9 E 15 16 H 23

6 4 10 10 6 16 16 7 23

0 A 5 5 C 10 10 F 16

0 5 5 5 5 10 10 6 16 23 K 28

23 5 28

15 I 20

18 5 23
5 D 11 11 G 15

8 6 14 14 4 18

15 J 18

20 3 23

ES ID LS
Leyenda –
LS Dur. LF

FIGURA 12.4  Red de actividades con inicios y finales tempranos y tardíos, para el proyecto de
ejemplo
410 Capítulo 12  •  Gerencia de recursos

CUADRO 12.4  Holguras y recursos de actividades requeridos para el proyecto de ejemplo

Horas de recursos Total de horas de


Actividad Duración Holgura total requeridas por semana recursos requeridas
A 5 0 6  30
B 4 1 2   8
C 5 0 4  20
D 6 3 3  18
E 6 1 3  18
F 6 0 2  12
G 4 3 4  16
H 7 0 3  21
I 5 3 4  20
J 3 5 2   6
K 5 0 5  25
Total 194

todavía requerirá 80 horas de trabajo para completarse, con dos recursos a tiempo completo asignados y
80 horas, en realidad, se puede finalizar en una semana de la línea base prevista del proyecto.
El cuadro 12.4 identifica las actividades, sus duraciones, la holgura total de las actividades y, lo más impor-
tante, el número de horas por semana que podemos asignar recursos a las tareas. El valor de tiempo es inferior
a tiempo completo, para ilustrar un problema típico: debido a otros compromisos, los miembros del equipo del
proyecto pueden asignarse al proyecto sobre una base menor de tiempo completo. Así, por ejemplo, la actividad
A se prevé que llevará cinco días, por los recursos que se les asignan seis horas por día (o una duración de la
tarea total estimado de 30 horas). La actividad F se prevé que tomará seis días para completarse con dos horas
por día que se le asignen. El total de recursos necesarios para completar el proyecto en el plazo previsto es 194
horas. Una vez que esta información se introduce en el proyecto, es posible seguir una serie de pasos encamina-
dos a la nivelación de recursos de la red de actividades. Estos pasos se consideran por separado.

Paso uno: desarrollar el cuadro de carga de recursos


El cuadro de carga de recursos se crea mediante la identificación de las actividades del proyecto y los recur-
sos necesarios para completar y aplicar esta información a la línea base del cronograma del proyecto. En
su forma más simple, el cuadro de carga de recursos se parece a un histograma, en el que se identifican las
necesidades de horas de recursos en el ciclo de vida del proyecto (véase la figura 12.5). Sin embargo, un cua-
dro de carga de recursos más completo se desarrolla en la figura 12.6. Se supone que el proyecto inicia el 1
de enero y las actividades siguen el orden definido en el diagrama de Gantt del proyecto. Tenga en cuenta

12
Requerimientos de recursos

10

0
1 3 5 7 9 11 13 15 17 19 21 23 25 27
Dias del proyecto
FIGURA 12.5  Perfil de recursos para la red del proyecto del ejemplo
12.3  Nivelación de recursos 411

Enero Febrero
Actividad 12345 8 9 10 11 12 15 16 17 18 19 22 23 24 25 26 29 30 31 1 2 567
A 66666
B 2 2 2 2
C 4 4 4 4 4
D 3 3 3 3 3 3
E 3 3 3 3 3 3
F 2 2 2 2 2 2
G 4 4 4 4
H 3 3 3 3 3 3 3
I 4 4 4 4 4
J 2 2 2
K 5 5 555
Total 66666 9 9 9 9 10 8 9 9 9 9 8 9 9 7 7 3 3 3 5 5 555

FIGURA 12.6  Cuadro de carga de recursos para la red del proyecto de ejemplo

que los recursos que se requieren por día para cada actividad se muestran contra los días de la línea base del
cronograma del proyecto, cuando ellos se requerirán. Estas horas totales de recursos se suman a lo largo de la
parte inferior del cuadro para identificar el perfil general de los recursos del proyecto. Observe, además, que
las necesidades de recursos tienden a moverse de arriba abajo a lo largo de la línea base, y alcanza un máximo
de 10 horas de los recursos necesarios en el día 10 (12 de enero).
La ventaja de desarrollar un perfil detallado de recursos es que proporciona una demostración visual útil
de las necesidades proyectadas de recursos necesarios a lo largo de toda la línea base del proyecto. Es posible
utilizar este perfil de recursos en conjunto con el cuadro de carga de recursos para desarrollar una estrategia de
la nivelación óptima de recursos.

Paso dos: determinar los finales tardíos de las actividades


El siguiente paso en el proceso de nivelación de recursos consiste en la integración de la información adicio-
nal, respecto a la holgura de actividades y fechas de fin tardío, en el cuadro de carga de recursos (véase el cua-
dro 12.3). Este cuadro modificado se muestra en la figura 12.7. Tenga en cuenta que en esta figura podemos
identificar las actividades con tiempos muertos y las actividades críticas (sin holgura). Los fines tardíos para
esas actividades con holgura se incluyen y se representan como corchetes cuadrados. Por tanto, las activida-
des B, D, E, G, I y J se muestran con finales tardíos correspondientes a holgura asociada a cada tarea, mientras
que los finales tardíos de las actividades a lo largo de la ruta crítica (A – C – F – H – K) son idénticos a las
fechas de inicio temprano de las actividades.

Enero Febrero
Actividad 12345 8 9 10 11 12 15 16 17 18 19 22 23 24 25 26 29 30 31 1 2 567
A 6 6 6 6 6˜
B 2 2 2 2 ˜
C 4 4 4 4 4˜
D 3 3 3 3 3 3 ˜
E 3 3 3 3 3 3 ˜
F 2 2 2 2 2 2˜
G 4 4 4 4 ˜
H 3 3 3 3 3 3 3˜
I 4 4 4 4 4 ˜
J 2 2 2 ˜
K 55 5 5 5˜
Total 66666 9 9 9 9 10 8 9 9 9 9 8 9 9 7 7 3 3 3 55 555
(˜ = límite de finalización)

FIGURA 12.7  Cuadro de carga de recursos para la red del proyecto de ejemplo, cuando se incluye la holgura
de las actividades
412 Capítulo 12  •  Gerencia de recursos

Paso tres: identificar sobreasignación de recursos


Después de que el cuadro de carga de recursos se ha completado y todas las fechas de fin tardío se definen,
el proceso de nivelación real de recursos puede comenzar con un examen del perfil de recursos para el pro-
yecto. Aquí buscamos puntos a lo largo de la línea base del proyecto en los cuales se hayan asignado los
recursos disponibles más allá del nivel máximo. Por ejemplo, en la figura 12.7, tenga en cuenta que el total
de recursos necesarios (la suma a lo largo de la fila de abajo) revela que el máximo necesario para cualquier
día del proyecto es el 12 de enero, cuando las tareas que requieren 10 unidades de recursos se programen. La
pregunta que el gerente de proyecto debe considerar es si este perfil de recursos es aceptable o si evidencia
problemas, debido a una asignación de recursos no disponibles. Si, por ejemplo, el proyecto tiene un presu-
puesto de hasta 10 unidades de recursos por día, entonces este perfil de recursos es aceptable. Por otro lado,
si los recursos se limitan a alguna cifra por debajo del máximo en que se encuentra en el perfil de los recursos
del proyecto, este tiene un problema de sobreasignación que hay que enfrentar y corregir.
Ciertamente, en este punto, lo mejor es descubrir que los recursos se han asignado en el máximo o por
debajo de este a lo largo de la línea base del proyecto. Dada la naturaleza de tiempo y de recursos del pro-
yecto, es común encontrar situaciones de conflictos de recursos que requieren nivelación. Supongamos que
en nuestro proyecto de ejemplo el número máximo de unidades de recursos disponibles en cualquier día es
nueve. Ya determinamos que el 12 de enero el proyecto está programado para requerir 10 unidades, lo que
representa una sobreasignación. El descubrimiento de sobreasignaciones desencadena el siguiente paso en
el proceso de nivelación de recursos, en el que se corrige el cronograma para eliminar conflicto de recursos.

Paso cuatro: nivelar el cuadro de carga de recursos


Una vez determinado que la línea base del proyecto incluye recursos sobreasignados, comienza un proceso
iterativo en el cual el cuadro de carga de recursos se vuelve a configurar para eliminar los puntos de conten-
ción de recursos. El punto más importante para recordar en la nivelación de recursos es que comúnmente
ocurre un efecto dominó cuando comenzamos a retrabajar en el cronograma de recursos para eliminar las
fuentes de conflicto de recursos. Este efecto dominó se evidenciará a medida que trabajamos en los pasos
necesarios para nivelar el proyecto de ejemplo.

FASE UNO  Utilizando la figura 12.7, examine el punto de conflicto, 12 de enero, para las tareas que requieren
10 unidades de recursos. Las tareas C, D y E están programadas para este día y tienen compromisos de recursos
unitarios de 4, 3 y 3 horas, respectivamente. Por tanto, la primera fase de la nivelación de recursos consiste en la
identificación de las actividades pertinentes para determinar cuáles son los posibles candidatos para la modifi-
cación. A continuación, ¿cuál actividad debe ajustarse? Usando la heurística de prioridad que se mencionó, pri-
mero se examinan las actividades para ver cuáles son claves y tienen una holgura asociada. Por el desarrollo de
la red, se sabe que la actividad C está en la ruta crítica. Por tanto, hay que evitar la reconfiguración de esta tarea,
si es posible, ya que cualquier ajuste en su duración afectará adversamente el cronograma general del proyecto.
La eliminación de la actividad C nos deja la opción de ajustar la actividad D o la actividad E.

FASE DOS  Seleccione la actividad que va a reconfigurarse. Las actividades D y E tienen holguras asociadas. La
actividad D tiene tres días de holgura y la actividad de E tiene un día. Según la regla general, es posible que deci-
damos dejar la actividad E sola, pues tiene la menor cantidad de tiempo de holgura. En este ejemplo, sin embargo,
esta opción daría lugar a “dividir” la actividad D, es decir, empezaríamos el 8 de enero la actividad D, la detendría-
mos en el 12, y luego la terminaríamos los dos últimos días de trabajo, el 15 y el 16 de enero. Simplemente repre-
sentando esta opción, vemos en la pantalla 12.7 la cual muestra el diagrama de Gantt para nuestro proyecto, que
el proceso de división complica nuestro proceso de programación en algún grado. Note además que la división no
alarga la línea base del proyecto, sin embargo, con los tres días de holgura asociados a esta tarea, aplazar la activi-
dad un día mediante fraccionamiento no afecta negativamente la fecha de la entrega final.
Por razones de simplicidad, vamos a evitar la decisión de dividir la actividad D por el momento; la elec-
ción es la opción alternativa de ajustar el horario para la actividad E. Esta opción también es viable, ya que no
viola la línea base del cronograma (hay holgura asociada con esta actividad).
La figura 12.8 muestra el primer ajuste al cuadro de carga de recursos originales. Las tres unidades de
recursos asignados a la actividad E el 12 de enero están tachadas y se agregan de nuevo al final de la actividad;
por consiguiente, se consume el día de holgura del proyecto para esa actividad. El cuadro de carga de recur-
sos reajustada ahora muestra que el 12 de enero ya no tiene un conflicto de recursos, porque la fecha de línea
base muestra un total de siete unidades de recursos.
12.3  Nivelación de recursos 413

PANTALLA 12.7  Reconfiguración del cronograma fraccionando la actividad D

Enero Febrero
Actividad 1 2 3 4 5 8 9 10 11 12 15 16 17 18 19 22 23 24 25 26 29 30 31 1 2 567
A 6 6 6 6 6˜
B 2 2 2 2 ˜
C 4 4 4 4 4˜
D 3 3 3 3 3 3 ˜
E 3 3 3 3 3 3 3˜
F 2 2 2 2 2 2˜
G 4 4 4 4 ˜
H 3 3 3 3 3 3 3˜
I 4 4 4 4 4 ˜
J 2 2 2 2 ˜
K 55 5 5 5˜
Total 66666 9 9 9 9 7 8 9 9 9 9 9 9 9 9 7 3 3 3 55 555
(˜ = límite de finalización)

FIGURA 12.8  Nivelación de recursos del cuadro de red

FASE TRES  Después de hacer ajustes para atenuar los conflictos de recursos, reexamine el resto del cuadro
para los nuevos conflictos de recursos. Recuerde que el ajuste del cuadro puede causar un efecto dominó en
el que estos ajustes pueden afectar el cuadro en otros lugares. Este efecto exacto se ha producido en este ejem-
plo. Tenga en cuenta que debajo del cuadro ajustado (véase la figura 12.8), el 12 de enero ya no muestra un
conflicto de recursos, sin embargo, el acto de aplazar la actividad E un día crearía un conflicto el 22 de enero,
en el cual 11 unidades de recursos deberían programarse. Como resultado, se requiere pasar por el proceso
de la segunda fase una vez más, para eliminar el último conflicto de recursos.
También, en este caso, las candidatas para el ajuste son todas las tareas del proyecto que están activas el
22 de enero, incluidas las actividades E, F, I y J. Claramente, las actividades E y F, de ser posible, se eliminarán
como primera elección, dada su falta de tiempo de holgura (es decir, ahora ambas residen en la ruta crítica).
Ajustando (atrasando) un día para cualquiera de las alternativas, las actividades I y J, se reducirá la necesidad de
recursos a un nivel por debajo del umbral, lo cual sugiere que cualquiera de estas actividades puede utilizarse.
La heurística anterior sugirió que se les dé prioridad a las actividades con menor tiempo de holgura, por lo que
en este ejemplo vamos a dejar la actividad I sola, y en su lugar atrasaremos el inicio de la actividad J en un día.
Tenga en cuenta que los totales de recursos sumados por toda la parte inferior del cuadro (véase la figura 12.8)
ahora muestran que todas las actividades se establecen en el nivel de corte, o por debajo de este, de nueve horas
por día los recursos para el proyecto, completando nuestra tarea. Además, en este ejemplo, hemos nivelado
recursos del proyecto sin agregar fechas adicionales al cronograma del proyecto o requerir recursos adicionales;
en efecto, la nivelación de recursos en este ejemplo no violó ninguna restricción de tiempo ni recursos. En algu-
nas ocasiones, se necesitan sacrificios en la línea base del cronograma, con el fin de no traspasar de los límites
en la carga de recursos.
414 Capítulo 12  •  Gerencia de recursos

Supongamos que nuestro proyecto funciona con las limitaciones de recursos más estrictas; por ejem-
plo, en lugar de un umbral de las nueve horas por día, ¿cuál sería el efecto práctico de nivelación de recursos
del proyecto para ajustarse a un límite de ocho horas diarias? El desafío para un gerente de proyecto ahora
es volver a configurar el cuadro de carga de recursos, de manera que el principio básico de la limitación de
recursos no se viola. Con el fin de demostrar la complejidad de este proceso, en este ejemplo, vamos a dividir
el proceso de decisión en una serie de pasos discretos que incluimos en cada actividad individual de la línea
base del cronograma del proyecto (véase el cuadro 12.5).
La figura 12.9 describe este ejemplo de nivelación de recursos dado en el cuadro 12.5 con enero y
febrero apilados. Como indican los pasos del cuadro, la determinación del retardo total del proyecto solo
se evidencia cuando todas las tareas predecesoras se han cargado; los recursos nivelados en el punto de
cada nueva actividad se suman a el cuadro y el cronograma general de referencia del proyecto se examina.
Curiosamente, note en este ejemplo que en el cronograma del proyecto no se presentó un retraso por la
inclusión de 8 de las 11 actividades (a través de la actividad H). Sin embargo, una vez que la actividad H
se incluyó en el cuadro de recursos, fue necesario retrasar el inicio de la actividad J con el fin de deter-
minar la restricción de recursos del proyecto. Como resultado, la línea base del cronograma del proyecto
se retrasó por una combinación de pérdida de holgura del proyecto y la necesidad de volver a evaluar la
red de actividades, en vista de las limitaciones de recursos. El efecto global de este proceso iterativo fue
retrasar la terminación del proyecto tres días.
El ejemplo ampliado en esta sección ilustra uno de los retos más difíciles que enfrentan los gerentes
de proyectos: la necesidad de equilibrar los asuntos de recursos con los asuntos de cronograma. De confor-
midad con el nuevo presupuesto de recursos limitado, que nos permite gastar solo hasta ocho unidades de
recursos por día, las alternativas a menudo giran en torno a hacer trade-offs razonables de cronograma para
contabilizar los recursos limitados. El cronograma básico del proyecto establece que cualquier cambio en la
disponibilidad de recursos suficientes para apoyar la red de actividades de la red van a involucrar alargue
en la duración del proyecto. Una parte de la razón en este caso, por supuesto, radica en el hecho de que este
ejemplo incluye un cronograma de proyecto simplificado con muy poca holgura en cualquiera de las activi-
dades del proyecto. Como resultado de ello, las transformaciones más importantes a la base de recursos del
proyecto determinaron negativamente el cronograma general.

CUADRO 12.5  Pasos en la nivelación de recursos

Paso Acción
1 Asignar la actividad A en el cuadro de recursos.
2 En la selección entre actividades B, C y D, emplear la heurística de selección y prioridad a C
(actividad crítica) y luego B (menor cantidad de holgura). Cargar C y B en el cuadro de recursos.
Atrasar la actividad D.
3 El 12 de enero, cargar la actividad D. D tenía 3 días de holgura y se cargan cuatro días de re-
traso. La demora total para la actividad D es 1 día.
4 El 15 de enero, cargar actividades E y F (después de la terminación de B y C). Priorizar F primero
(actividad clave) y luego añadir E. Ambas actividades terminan el 22 de enero, así que la ruta crí-
tica del cronograma no se afecta. Retraso total del proyecto hasta la fecha = 0.
5 Debido a las limitaciones de recursos, la actividad G solo puede comenzar el 23 de enero. G
tenía 3 días de holgura y se carga con cinco días más tarde, y termina el 26 de enero. La demora
total para la actividad G es 2 días.
6 Cargar la actividad H el 23 de enero, después de la finalización de las actividades E y F. H se
completa el 31 de enero, por lo que la ruta crítica del cronograma no se afecta. Retraso total del
proyecto hasta la fecha = 0.
7 Debido a las limitaciones de recursos, la actividad I solo puede comenzar el 29 de enero. I es
cargada con cinco días de retraso. La demora total para la actividad es 2 días (nueva fecha de
finalización = 2 de febrero).
8 Debido a las limitaciones de recursos, la actividad J solo puede empezar el 1 de febrero. Incluso
con el tiempo de holgura, J se demora 3 días, y se completa el 5 de febrero.
9 La actividad K no se puede cargar hasta la finalización de las predecesoras H, I y J. K comienza el
6 de febrero y termina el 12 de febrero. Retraso total del proyecto = 3 días.
12.4  Diagramas de carga de recursos 415

Enero
Holgura
total Actividad 1 2 3 4 5 8 9 10 11 12 15 16 17 18 19 22 23 24 25 26
0 A ¨6 6 6 6 6
1 B ¨2 2 2 2 2
0 C ¨4 4 4 4 4
-1 D ¨ 3 3 3 3 3 3
0 E ¨ 3 3 3 3 3 3
0 F ¨2 2 2 2 2 2
-2 G ¨ 4 4 4 4
H ¨ 3 3 3 3
I ¨
J ¨
K
Total 6 6 6 6 6 6 6 6 6 7 8 8 8 8 8 5 7 7 7 7

Febrero
Holgura
total Actividad 29 30 31 1 2 5 6 7 8 9 12 13 14 15 16 17
A
B
C
D
E
F
G
0 H 3 3 3
-2 I 4 4 4 4 4
-3 J 2 2 2
-3 K ¨ 5 5 5 5 5
Total 7 7 7 6 6 2 5 5 5 5 5
¨ - Fecha de inicio temprano para la actividad original

FIGURE 12.9  Cuadro de carga de recursos con restricciones disminuidas de recursos

En resumen, los pasos básicos necesarios para producir un cronograma nivelado de recursos del pro-
yecto son los siguientes:
1. Crear un diagrama de red de actividades del proyecto (véase la figura 12.4).
2. A partir de este esquema, crear un cuadro que muestra los recursos necesarios para cada actividad, las
duraciones de las actividades y la holgura total disponible (véase el cuadro 12.4).
3. Desarrollar un cuadro de carga de recursos que muestre los recursos requeridos para completar cada
actividad, los inicios tempranos y los fines tardíos (véase la figura 12.7).
4. Identificar los conflictos de recursos y comenzar a “suavizar” el cuadro de carga de recursos utilizando una
o más de las heurísticas para priorizar la asignación de recursos a través de actividades (véase la figura 12.8).
5. Repetir el paso 4 con la frecuencia necesaria para eliminar la fuente de los conflictos de recursos. Use su
criterio para interpretar y mejorar las características el cuadro de carga de recursos. Considere la posi-
bilidad de medios alternativos para minimizar el desplazamiento del cronograma; por ejemplo, utilizar
las horas extras durante los periodos pico.

12.4  DIAGRAMAS DE CARGA DE RECURSOS


Otra forma de visualizar el problema de la gerencia de los recursos es mediante el empleo de diagramas de
cargas de recursos. Los diagramas de carga de recursos se utilizan para mostrar la cantidad de recursos
necesarios en función del tiempo. Típicamente, las necesidades de recursos de cada actividad se representan
como un bloque (requerimientos de recursos en el tiempo) en el contexto de la línea base del cronograma
416 Capítulo 12  •  Gerencia de recursos

del proyecto. Los diagramas de carga de recursos tienen la ventaja de ofrecer un punto de referencia visual
inmediato, mientras tratamos de presentar los recursos necesarios para apoyar nuestro proyecto, así como
suavizar las necesidades de recursos en el ciclo de vida del proyecto.
Un ejemplo ilustra cómo operan los diagramas de carga de recursos. Supongamos que nuestro perfil de
recursos indicó una serie de “altos” y “bajos “ en todo el proyecto, es decir, a pesar de que los límites de recursos se
fijan en ocho unidades/horas de recursos por día, en un número de días de nuestros recursos reales empleados son
menos que el total disponible. La red simplificada del proyecto se muestra en la figura 12.10 y se resume en el cuadro
12.6; el correspondiente diagrama de carga de recursos se muestra en la figura 12.11. La red enumera las fechas de
inicio y de fin temprano de cada actividad, así como los recursos necesarios para cada tarea en cada día de trabajo.
En la construcción de un diagrama de carga de recursos que ilustra el carácter limitado en tiempo del
cronograma de recursos, se deben seguir seis pasos:8
1. Crear el diagrama de red de actividades (véase la figura 12.10).
2. Desarrollar un cuadro para cada actividad, los requerimientos de recursos, la duración, el inicio tem-
prano, la holgura y el fin tardío (véase el cuadro 12.6).
3. Listar las actividades con el fin de aumentar la holgura (o en orden del fin tardío para actividades con
la misma holgura).
4. Dibujar un diagrama inicial de carga de recursos con cada actividad programada en su inicio temprano; la
construcción de esta sigue el orden que se muestra en el paso 3. Este proceso genera un gráfico de carga de
recursos con las actividades más críticas en la parte inferior y las de mayor holgura, en la parte superior.
5. Reorganizar las actividades con sus holguras para elaborar un perfil; esto es posible, si no se cambian la
duración de las actividades o sus dependencias.
6. Usar su criterio para interpretar y mejorar la nivelación de actividades moviendo actividades con hol-
gura extra, a fin de suavizar el diagrama de recursos a lo largo del proyecto (véase la figura 12.11).
Tenga en cuenta que el fin temprano del proyecto, en función de su ruta crítica, es 12 días. Sin embargo,
cuando tomamos en cuenta las limitaciones de recursos, nos encontramos con que es imposible completar
todas las actividades dentro del tiempo asignado, y el cronograma se desplaza dos días para una nueva fecha
temprana de terminación de 14 días. La figura 12.11 ilustra la naturaleza de nuestro problema: aunque el pro-
yecto permite un total de ocho horas por día para las actividades del proyecto, en realidad, la manera en que la
red del proyecto se establece en relación con los recursos necesarios para completar cada tarea hace imposible

4 B 5 5 D 9 9 E 11
Res.  2 Res.  7 Res.  3

0 A 4
Res.  6

11 F 12
Res.  6
4 C 7
Res.  2

FIGURA 12.10  Ejemplo de red de proyecto

CUADRO 12.6  Recursos de personal (en horas) requeridos para cada actividad

Actividad Recurso Duración Inicio temprano Holgura Fin tardío


A 6 4  0 0  4
B 2 1  4 0  5
C 2 3  4 4 11
D 7 4  5 0  9
E 3 2  9 0 11
F 6 1 11 0 12
12.4  Diagramas de carga de recursos 417

Recursos
4
D
A B F
2
E
C

2 4 6 8 10 12 14
Días del proyecto

FIGURA 12.11  Diagrama de carga de recursos para el proyecto de ejemplo

el uso de recursos de la manera más eficiente posible. De hecho, durante los días 5 a 7, se utiliza un total de solo
dos horas de recursos cada día.
Un procedimiento común en la resolución de conflictos de recursos utilizando diagramas de carga de recur-
sos es considerar la posibilidad de dividir las actividades. Como señalamos en este capítulo, la división de una
actividad o tarea significa interrumpir el flujo continuo de trabajo de una actividad en algún punto medio en
su proceso de desarrollo y aplicar ese recurso a otra actividad por un determinado periodo antes de devolver el
recurso para completar la tarea original. La división puede ser una técnica alternativa útil para la nivelación de
recursos, siempre que no haya costos excesivos relacionados con la división de la tarea. Por ejemplo, los altos cos-
tos de puesta en marcha o parada pueden hacer la división de actividades una opción poco atractiva.
Para comprender visualmente la opción de división de tareas, véase el diagrama de Gantt de la pantalla
12.7. Tenga en cuenta que la decisión no se tomó para dividir la actividad D, con el fin de mover el inicio de la
actividad E hacia adelante. Esta decisión se tomó para hacer mejor uso de los recursos limitados; en este caso,
no había suficiente holgura en la actividad D para forzar su finalización y así no perjudicar el cronograma
general del proyecto. En muchas circunstancias, los equipos de proyecto que tratan de hacer el mejor uso de
los recursos disponibles dividirán las tareas para mejorar la eficiencia del cronograma.
¿Qué pasaría si intentamos dividir las actividades, cuando sea posible, con el fin de hacer un uso más eficiente
de los recursos disponibles? Para averiguarlo, volvamos a la red de actividades de la figura 12.10 y la comparamos
con el diagrama de carga de recursos de la figura 12.11. Tenga en cuenta que la actividad C tarda tres días en com-
pletarse. Aunque la actividad C no es predecesora de la actividad D, solo podemos empezar D cuando C se com-
plete, debido a la falta de recursos disponibles (el día 5 requeriría nueve horas de recursos cuando solo están dispo-
nibles ocho). Sin embargo, supongamos que tuviéramos que dividir la actividad de C para que inicie en el día 4 y el
resto se pospone hasta que se complete la actividad D. Podemos desplazar parte de esta actividad, ya que contiene 4
días de holgura. La figura 12.12 ilustra esta alternativa. Tenga en cuenta que los dos días de la actividad C se llevan
a cabo hasta después que D esté completa, cuando se llevan simultáneamente a la actividad E. Debido a que la tarea
final F requiere que C y E finalicen, no demoramos el inicio de actividad F al dividir C. De hecho, como muestra
la figura 12.12, la división de C en realidad hace un uso más eficiente de los recursos disponibles y como resultado
se desplaza la fecha de terminación del proyecto dos días antes, del día 14 regresamos al día 12 originalmente pro-
gramado. Este ejemplo ilustra la ventaja que a veces se puede derivar del uso de métodos creativos para una mejor
utilización de los recursos. En este caso, dividiendo la actividad C, dados sus cuatro días de holgura, se le permite al
proyecto emplear de mejor forma sus recursos y recuperar la fecha de terminación de la ruta crítica original.

6
Recursos

4 D C
A B F
2
E
C

2 4 6 8 10 12 14
Días del proyecto

FIGURA 12.12  Diagrama de carga de recursos modificado cuando se divide la tarea C


418 Capítulo 12  •  Gerencia de recursos

RECUADRO 12.1

GERENTES DE PROYECTOS EN LA PRÁCTICA


Capitán Kevin O’Donnell, U.S. Marine Corps
Como oficial de la Marina, el capitán Kevin O’Donnell ha estado trabajando como “gerente de proyecto “
por muchos años. Como O’Donnell admite libremente, a primera vista, sus funciones no parecen alinearse
con los papeles tradicionales de los gerentes de proyectos, y, sin embargo, cuanto más consideramos estos,
más podemos ver que aunque las circunstancias son únicas, los principios y prácticas de gerencia de proyec-
tos siguen siendo aplicables.
O’Donnell es licenciado en justicia penal de The Citadel, por The Military College of South Carolina, y
fue comisionado como segundo teniente en el U.S. Marine Corps. Él se desempeña actualmente como ofi-
cial de proyectos y oficial ejecutivo de la compañía en Marine Barracks, Washington, DC, y también ha sido
asignado al retiro presidencial de Camp David, como oficial de guardia y oficial ejecutivo de la compañía.
Como segundo y primer teniente, O’Donnell sirvió en el Second Battalion, 6th Marine Regiment,
como comandante de pelotón y oficial ejecutivo de la compañía, mientras realizaba dos despliegues de
combate a Fallujah, Iraq. Aunque sus cargos han sido de alto rango, incluido el liderazgo de un número de
misiones y la asignación de tareas, en palabras de O’Donnell, él prefiere centrarse en la forma en la que ha
utilizado la gerencia de proyectos en su carrera. Conceptos como la visión estratégica, la gerencia de intere-
sados, la gerencia del alcance, la estructura del proyecto, las tareas, las líneas de tiempo y las evaluaciones
de riesgo son comunes para todos los proyectos, y los infantes de marina los usan todos los días durante la
planeación de la formación y, al mismo tiempo, en despliegues, llevando a cabo y dirigiendo las operaciones
de los combates.
Como comandante de pelotón, O’Donnell fue el responsable de dirigir una fuerza de 45 infantes de
marina durante su primer despliegue a Iraq. Ellos se encargaron de llevar a cabo una variedad de misiones, y
habitualmente participaban en patrullas en vehículos y a pie, convoyes, registros domiciliarios al azar y redadas
dirigidas contra el personal enemigo. O’Donnell señala:
Tomemos, por ejemplo, un ataque específico de inteligencia dirigido a un insurgente conocido.
Esta situación, vista como un “proyecto”, me exigía como comandante de pelotón analizar el
área de operaciones e inteligencia disponibles, generar una orden de cinco párrafos que contenía
una declaración de objetivos, declaraciones de tareas, esquema de maniobra para la operación y
consideraciones de logística (muy similar a una visión del proyecto, el alcance del trabajo y la es-
tructura de desglose de trabajo). Además, yo tendría que coordinar todas las unidades adyacentes
y subordinadas que se afectarían por la misión, y avisar a altos miembros de la cadena de mando
(gerencia de interesados). También llevaba a cabo una evaluación del riesgo operativo, identifican-
do los problemas que pudieran surgir durante la ejecución de la misión y los cursos de acción del
enemigo que este pudiera efectuar. Los riesgos se priorizaban, aceptaban, preveían o mitigaban.
Por último, daba la orden a mis líderes subordinados en el pelotón, que, a su vez, generaban una
orden para su equipo y la transmitían a ellos.
Como gerente de proyecto para esta misión, era responsabilidad de O’Donnell asegurar que todos en su
equipo supieran lo que iban a hacer, ¿por qué iban a hacerlo?, ¿cómo iban a lograr que se hiciera?, y lo que
se esperaba como resultado.
Por otra parte, la programación con hitos importantes formó parte de los deberes de O’Donnell. Estas
líneas de tiempo se habrían establecido durante el plan, y, más veces que pocas, era clave que se cumplieran.
Controles y verificaciones de precombate se llevaban a cabo, junto a ensayos de la redada antes de comenzar la
misión. Dada la orden de moverse, el pelotón salía de las líneas aliadas y comenzaba a patrullar al sitio objetivo.
Al alcanzar el objetivo, cada unidad subordinada (un escuadrón), encabezada por su líder de escuadrón, comen-
zaba a realizar a la perfección su parte de la redada. O’Donnell señala que la comunicación, la coordinación y el
control eran fundamentales durante estas operaciones. Muchas lecciones aprendidas provienen de revisiones
posteriores a la acción, y, lo más importante, los demás podían aprender de lo que habían hecho bien o mal.
O’Donnell describe sus funciones de gerencia de proyectos:
Durante mi segundo despliegue en Iraq, tenía a cargo la planeación y la ejecución de una ope-
ración a gran escala de la compañía llamada Operación Alljah. Esta operación abarcaba una
serie de misiones más pequeñas, como el ejemplo de incursión anterior. Además, involucraba
la ejecución de un plan de acción no tradicional que no se había hecho antes en la ciudad de
Faluya. Nos asociamos con el ejército y la policía iraquíes de Faluya para volver a darles el poder,
les suministramos capacitación y la infraestructura adecuada y necesaria para que pudieran con-
12.4  Diagramas de carga de recursos 419

FIGURA 12.13  Capitán Kevin O’Donnell, USMC

trolar y asegurar su propia ciudad, y en última instancia, la transición de la responsabilidad de


esta misión a ellos, con el fin de proporcionarles a los ciudadanos de Faluya un medio ambiente
seguro y estable. La misión abarcó casi todos los principios de la gerencia de proyectos. Además
de los mencionados, esta misión requirió la gerencia de los interesados y una mayor participación
de estos, la construcción y el liderazgo de equipos multiculturales, romper barreras lingüísticas y
culturales, el cambio de administración en toda la organización, mando y control, y, hasta cierto
punto, vender el concepto, crear propiedad y lograr el “buy-in” entre el equipo y los ciudadanos.
La visión estratégica, que se describe en la intención de nuestro comandante, fue fundamental
para el éxito de esta misión. Nuestra capacidad de construir, perfeccionar y ejecutar un plan de
acción sólido, mientras alcanzábamos hitos críticos y líneas de tiempo, impactó significativamente
la ejecución exitosa de la misión.
La capacidad de mis líderes subordinados y las unidades adyacentes, para integrar e interac-
tuar con los demás y con sus homólogos iraquíes, desempeñaron un papel importante en el éxito
de la organización en conjunto. Nos vimos obligados a operar en un entorno externo en constante
cambio, y nuestra capacidad de adaptarnos sin esfuerzo y ajustar nuestro plan pagó dividendos
en el éxito de la misión. A lo largo de la ejecución de esta misión, los requisitos de los grupos
interesados fueron cambiando, los parámetros de la misión se ajustaron, la dinámica del entorno
interno y externo se cambió, y el personal y la composición de equipos se ajustaron. Sin embargo,
al final, a través de un liderazgo sólido en todos los niveles de la cadena de mando y la ejecución
fundamental de la gerencia de proyectos y principios, la misión se completó y dobló el gran éxito.
La ciudad de Faluya es ahora un área autoasegurada y gobernada de Iraq, y las acciones de mi
batallón allí se utilizaron como modelo para seguir en la pacificación y derrotar a la insurgencia en
otras ciudades de Iraq.
Aunque los cargos de O’Donnell no parecen los de gerencia tradicional de proyectos, se apresura a
señalar que, de hecho, lo opuesto es verdad. Operaciones cuidadosamente planeadas, los objetivos definidos,
estrategias claras y la coordinación y la programación son todas las características de la gerencia de proyec-
tos, y formaron los procesos claves para las tareas de O’Donnell al comandar a los infantes de marina en un
ambiente hostil. “Al final del día, independientemente de la industria, la gerencia de proyectos sigue siendo
la misma”, concluye O’Donnell. “La comprensión de la diferencia entre el liderazgo y la gerencia es funda-
mental. Conocer sus entornos internos y externos, así como la forma de planificar, asignar y manejar personal,
mantener un presupuesto y líneas de tiempo, tener una comprensión clara de los objetivos, cómo se debe
cumplir los requisitos del cliente y de los interesados y el logro de los resultados deseados, son fundamentales
para el éxito de cualquier gerente de proyecto.”
420 Capítulo 12  •  Gerencia de recursos

12.5  GERENCIA DE RECURSOS EN ENTORNOS MULTIPROYECTO


La mayoría de gerentes de proyectos, finalmente, se enfrentan con la asignación de recursos en múltiples
proyectos. El principal desafío es la interdependencia: cualquier decisión de asignación de recursos en un
proyecto tiene implicaciones en otros proyectos. ¿Cuáles son algunos de los problemas más comunes que
encontramos cuando nos enfrentamos con este tipo de interdependencia entre los proyectos? Algunos de los
problemas más conocidos incluyen el uso ineficiente de los recursos, los cuellos de botella de recursos, un
efecto dominó y la mayor presión sobre el personal para ejecutar la multitarea.9
Todo sistema que se utiliza para resolver los complejos problemas de la asignación de recursos multipro-
yecto tiene que contemplar la necesidad, tanto como sea posible, para reducir al mínimo los efectos negativos
de los tres parámetros claves: (1) retrasos en el cumplimiento del cronograma; (2) utilización de recursos; (3)
inventario en proceso.10 Cada uno de estos parámetros constituye un reto significativo en múltiples proyectos.

Retrasos en el cumplimiento del cronograma


En muchos proyectos, el retraso del cumplimiento del cronograma puede ser más que simplemente la
constatación de que el proyecto va a retrasarse; en muchas industrias, también, puede dar lugar a graves
sanciones económicas. No es raro que las empresas deban pagar miles de dólares en las cláusulas de pena-
lización por cada día que un proyecto se retrasa más allá de la fecha de entrega contratada. Como resul-
tado de esto, una cuestión importante por considerar al tomar decisiones sobre la asignación de recursos a
múltiples proyectos es su prioridad basada en el efecto del retraso previsto para cada proyecto individual.

Utilización de recursos
El objetivo de todas las empresas es utilizar su reserva de recursos existentes lo más eficientemente posible.
Adicionar recursos en toda la compañía puede ser costoso y puede ser innecesario, según la manera en la que se
emplean los recursos actuales. Para ilustrar este punto, consideremos el ejemplo de un diagrama de carga de recur-
sos, que se muestra en la figura 12.14, aplicada más al portafolio de proyectos de una empresa que a las actividades
de solo un proyecto. En este diagrama de carga, la alta gerencia puede asignar hasta ocho unidades de recurso para
cada semana de su portafolio de proyectos. Incluso al implementar una metodología de separación para emplear
mejor estos recursos, hay todavía algunos puntos claros en los que el portafolio subutiliza los recursos disponibles.
Por ejemplo, en la semana 5, se emplean solo cuatro unidades de recursos. La zona sombreada del diagrama de
carga (véase la figura 12.14) muestra los recursos disponibles adicionales no utilizados en el proyecto actual. Para
maximizar el parámetro de la utilización de recursos, podríamos intentar asignar los recursos disponibles en otros
proyectos concurrentes, y mejorar así la eficiencia global con la que utilizamos los recursos del proyecto.

6
Recursos

4 Proyecto D E
Proyecto A B G
2
F
C

2 4 6 8 10 12 14
Semanas del proyecto

FIGURA 12.14  Diagrama de carga de recursos en multiproyectos

Inventario en proceso
El tercer parámetro para el análisis de la utilización óptima de los recursos multiproyectos es considerar
su impacto en el inventario durante el proceso. El inventario en proceso representa la cantidad de trabajo
que se espera completar pero que se retrasa debido a los recursos que no están disponibles. Por ejemplo, un
estudio de arquitectura puede encontrar varios proyectos retrasados debido a que solo emplea a un inspector
12.5  Gerencia de recursos en entornos multiproyecto 421

responsable de último detalle de todos los planos. Los proyectos se apilan detrás de este cuello de botella de
recursos y representan el inventario de la empresa durante el proceso de los proyectos. El exceso de inven-
tario en proceso, a menudo, ocurre por la falta de recursos disponibles y representa el tipo de decisiones
trade-off que las empresas deben tomar en entornos multiproyecto. ¿Hay que contratar recursos adicionales
a fin de reducir nuestro proceso de inventario? Si este problema es solo temporal, ¿la contratación de recur-
sos adicionales conducirá a una asignación ineficiente de los recursos en el futuro?
En efecto, las organizaciones orientadas a proyectos a menudo tienen que hallar un equilibrio ade-
cuado entre los tres parámetros: retraso en el cumplimiento del cronograma, la utilización de recursos y el
inventario en proceso. Los pasos necesarios para mejorar una de las medidas pueden tener efectos negativos
en uno o más de los otros parámetros. Por ejemplo, medidas para maximizar la utilización de recursos pue-
den provocar retrasos en el cumplimiento del cronograma o aumentar el inventario en proceso. Cualquier
estrategia que utilicemos para hallar un equilibrio razonable entre estos parámetros debe reconocer la nece-
sidad de hacer malabares con múltiples demandas en competencias.

Decisiones de recursos en entornos multiproyecto


El reto de la programación de recursos en entornos multiproyecto tiene que ver con la necesidad de trabajar en
dos niveles para lograr la máxima eficiencia. En primer lugar, con múltiples proyectos tenemos que tomar deci-
siones de asignación de alta prioridad en los proyectos. Sin embargo, también es vital reconocer que muchas
veces se nos exige programar las actividades de varios proyectos a la vez. Considere el diagrama de carga de
recursos en la figura 12.14. Por un lado, podemos ver que este diagrama ha programado proyectos de A a G en
12 semanas. El proyecto A se llevará la mayor parte de los recursos en las primeras cuatro semanas. Sin embargo,
durante la cuarta semana, hemos programado dos proyectos al mismo tiempo (B y C). Ahora debemos trabajar
para equilibrar sus necesidades individuales de recursos de las actividades, a fin de que ambos proyectos puedan
completarse en el mismo periodo. Esta figura ilustra la naturaleza del problema: en un nivel más amplio, la
asignación de recursos a múltiples proyectos nos obliga a planear los proyectos y utilizar de manera más efi-
ciente nuestros recursos. Sin embargo, en otro nivel, cuando los proyectos compiten por los recursos al mismo
tiempo, tenemos que trabajar para priorizar nuestros recursos y a través de ellos maximizar su disponibilidad.
Hay una serie de posibles métodos para resolver los desafíos de asignación de recursos en un entorno
multiproyecto, los cuales van desde la heurística bastante simplificada a opciones de programación matemá-
tica más complejas. El objetivo de cada técnica consiste en hacer el uso más eficiente de los recursos en varios
proyectos, a menudo con requisitos y prioridades que compiten.

PRIMERO EN LA FILA  La más simple de las técnicas para la asignación de recursos es priorizar basados en los
proyectos que entraron primero en la lista. Este enfoque de “primero en llegar primero en atender “es fácil de
utilizar, ya que se limita a seguir el cronograma del proyecto principal. Cuando se requiere tomar decisiones de
asignación de recursos, estas se pueden tomar de forma rápida mediante la comparación de las fechas de inicio
de los proyectos en cuestión. Infortunadamente, esta técnica no tiene en cuenta cualquier otra información
importante que puede sugerir la necesidad de reordenar el proceso de asignación de recursos, como las priori-
dades estratégicas, situaciones de emergencia o crisis, o proyectos con mayor potencial para el éxito comercial.
La opción del primero en la fila ocasionaría que las empresas subasignen recursos potenciales a proyectos de
alta rentabilidad, solo basados en el momento de su autorización, en los proyectos anteriores y menos útiles.

MAYOR DEMANDA DE RECURSOS Esta regla de decisión comienza con la determinación de qué proyec-
tos del portafolio de la empresa supondrán la mayor demanda de los recursos disponibles. Aquellos proyec-
tos que requieren la mayoría de recursos se identifican primero, y sus recursos se ponen a su disposición.
Una vez priorizados y los recursos asignados, la compañía vuelve a examinar la reserva restante para los
otros proyectos y seleccionará aquellos con las más altas exigencias de recursos próximos, hasta que se agota
el recurso disponible. La lógica del enfoque de mayor demanda de recursos es reconocer que los cuellos de
botella de recursos tienden a surgir de los picos inesperados en las necesidades de recursos, en relación con el
número de proyectos en desarrollo. En consecuencia, este enfoque identifica estos posibles cuellos de botella
y los utiliza como el punto de partida para la asignación de recursos adicionales.

MAYOR UTILIZACIÓN DE RECURSOS  Una variación de la heurística de mayor demanda de recursos es


la asignación de recursos, con el fin de asegurar el mayor uso de los recursos del proyecto o minimizar el
tiempo de inactividad de los recursos. Por ejemplo, una organización puede tratar de darles prioridad a tres
422 Capítulo 12  •  Gerencia de recursos

proyectos, A, B y C, a través de un fondo de recursos integrado por programadores, analistas de sistemas y


especialistas en redes. Aunque el proyecto A requiere la mayor cantidad de recursos para su terminación,
no necesita ningún trabajo del recurso analista de sistemas. Por otro lado, el proyecto B no requiere tantos
recursos totales para la terminación, pero sí necesita utilizar los miembros de los tres grupos del grupo de
recursos, es decir, los programadores, analistas de sistemas y especialistas de red. Como resultado, la empresa
puede optar por priorizar el proyecto B primero con el fin de garantizar que todos los recursos están utilizán-
dose en la mayor medida posible.

MÍNIMO FIN TARDÍO  Este método establece que la prioridad de los recursos debe asignarse a las activi-
dades y a los proyectos basados en las fechas finales de la actividad. Los proyectos con las fechas de final
temprano se programan primero. Recuerde que “finales tardíos” se refieren a lo más tarde que una actividad
puede terminar sin comprometer la red general del proyecto, por el alargamiento de la ruta crítica. El obje-
tivo de esta heurística es examinar las actividades de proyectos que tengan tiempo de holgura adicional como
resultado de la fecha de final tardío, y priorizar los recursos de actividades con holgura mínima, es decir,
fechas de finalización tempranas.

PROGRAMACIÓN MATEMÁTICA  La programación matemática puede utilizarse para generar soluciones


óptimas a los problemas de recursos limitados en el entorno multiproyecto, del mismo modo que se puede
utilizar en proyectos individuales. Los objetivos comunes que tales modelos buscan optimizar son:11
1. Minimizar el tiempo de desarrollo total para todos los proyectos
2. Minimizar el uso de recursos en todos los proyectos
3. Minimizar el retraso total a lo largo de todos los proyectos
Estas metas están sujetas a las limitaciones de recursos que caracterizan la naturaleza del problema, incluidos: (1)
escasez de recursos, (2) relaciones de precedencia entre las actividades y proyectos, (3) las fechas de entrega de los
proyectos y actividades, (4) oportunidades para división de actividades, (5) requerimientos de desempeño de acti-
vidades concurrentes versus no concurrentes, y (6) la sustitución de recursos para asignar a las actividades. Aunque
la programación matemática es un enfoque apropiado para resolver el problema de los recursos limitados, ya sea
en un entorno único o multiproyecto, su uso tiende a limitarse en función de la complejidad del problema, el gran
número de variables de cálculo y el tiempo necesario para generar un pequeño conjunto de opciones.
La gerencia de recursos en los proyectos es un problema que con frecuencia se pasa por alto por los
gerentes de proyectos o en empresas que no han dedicado el tiempo suficiente para comprender la naturaleza
completa del desafío de la gerencia de proyectos con la que se enfrentan. Como se señaló, es común desarro-
llar planes y programas de proyectos con el supuesto de recursos ilimitados, como si la organización siempre
pudiera encontrar el personal capacitado y otros recursos necesarios para apoyar las actividades del proyecto,
sin importar el grado de compromiso en la actualidad para proyectar el trabajo. Esta práctica conduce inevita-
blemente a retraso del cumplimiento de los cronogramas y costos adicionales que, por la real disponibilidad de
recursos, ensombrece el optimismo de la programación inicial. De hecho, la gerencia de recursos representa un
paso serio en la creación de estimaciones razonables y precisas para duraciones de las actividades del proyecto,
mediante la comparación de los recursos necesarios para llevar a cabo una actividad para los que están disponi-
bles en cualquier momento. Además, la gerencia de recursos reconoce la naturaleza de los trade-offs de tiempo/
costo que los gerentes de proyectos se ven obligados a hacer con frecuencia. Los recursos adicionales para rea-
lizar las tareas de manera oportuna no son económicos y su costo debe equilibrarse con los cronogramas de
proyectos agresivos que apremian sin prestar atención a su incidencia presupuestaria.
La gerencia de recursos es un proceso iterativo que puede consumir mucho tiempo. A medida que
equilibramos nuestra red de actividades y el cronograma general en contra de los recursos disponibles, el
resultado inevitable será la necesidad de realizar ajustes a la red y reprogramar las actividades de tal manera
que tengan un efecto negativo mínimo sobre la red de actividades y la ruta crítica. La nivelación de recursos,
o suavizado, es un procedimiento que facilita la programación de recursos al minimizar las fluctuaciones en
las necesidades de recursos de todo el proyecto, mediante la aplicación de recursos de la manera más uni-
forme posible. Por tanto, la gerencia de recursos puede hacer los cronogramas de proyectos más ajustados al
tiempo que permite la programación óptima de los recursos del proyecto. Aunque este proceso puede tomar
tiempo en la fase temprana de planeación del proyecto, generará grandes dividendos a largo plazo, a medida
que creamos y gerenciamos planes de proyectos basados en las necesidades de recursos significativos y esti-
maciones de duración, más que basados en ilusiones.
Resumen 423

Resumen
1. Reconocer la variedad de limitaciones que pueden hay que ajustar? En el uso de la heurística de priori-
afectar un proyecto, lo cual dificulta la programación dad mencionado, tendríamos primero que examinar
y la planeación.  La gerencia eficaz de los recursos las actividades para ver cuáles son críticas y tienen
para los proyectos es un reto complejo. Los gerentes un tiempo de holgura asociada. El segundo paso es
deben primero reconocer la amplia variedad de restric- seleccionar la actividad que va a reconfigurarse. De
ciones que pueden afectar negativamente la planeación acuerdo con la regla general, primero seleccionamos
eficiente de la programación de los proyectos, incluidas las actividades con la mayor holgura para su respec-
las limitaciones técnicas, de recursos y físicas. Entre el tiva reconfiguración.
conjunto de limitaciones de recursos están el personal 4. Seguir los pasos necesarios para suavizar efectiva-
del proyecto, los materiales, dinero y equipo. Una eva- mente los requerimientos de recursos en todo el
luación razonable y exhaustiva del grado en que cada ciclo de vida del proyecto.  En la construcción de
uno de estos tipos de recursos se necesitarán para el un diagrama de carga de recursos que ilustra el carác-
proyecto y de su disponibilidad es fundamental para ter limitado del cronograma de recursos, hay seis
apoyar los cronogramas del proyecto. pasos principales que deben seguirse: (1) elaborar el
2. Entender cómo aplicar las técnicas de carga de recur- diagrama de red de actividades para el proyecto; (2)
sos a cronogramas de proyectos, para identificar producir un cuadro para cada actividad que incluya
posibles sobreasignaciones de recursos.  La carga de los recursos necesarios, la duración, la fecha de inicio
recursos es un proceso para la asignación de recursos temprano, la holgura y el tiempo de fin tardío; (3) lis-
necesarios en cada actividad del proyecto a lo largo de tar las actividades con el fin de aumentar la holgura (o
la línea de base del cronograma. La carga de recursos en el orden del fin tardío para las actividades con la
efectiva asegura que el equipo del proyecto sea capaz misma holgura); (4) elaborar un diagrama de carga de
de soportar el cronograma, asegurando que todas las recursos inicial con cada actividad programada, en su
actividades identificadas en el cronograma tienen el inicio temprano, siguiendo el orden que se muestra en
nivel necesario de recursos asignados para apoyar su el paso 3, para crear un diagrama de carga de recursos
conclusión dentro de las estimaciones de tiempo pre- con las actividades más importantes en la parte infe-
vistas. Podemos perfilar las necesidades de recursos rior y las de mayor holgura en la parte superior; (5)
para un proyecto a través de su ciclo de vida y plani- reorganizar las actividades con su holgura para crear
ficar de forma proactiva los recursos necesarios (en un perfil lo más nivelado posible, sin cambiar la dura-
términos de tipo y la cantidad requerida de recursos), ción de las actividades o sus dependencias; y (6) uti-
en el punto del proyecto cuando las actividades están lizar el juicio para interpretar y mejorar la nivelación
programadas para llevarse a cabo. Un método visual de actividades moviendo actividades de holgura extra,
eficaz para la planeación de recursos utiliza técnicas con el fin de “suavizar” el diagrama de recursos a lo
de nivelación de recursos para “bloquear” las activida- largo del proyecto.
des, incluidos los niveles de dedicación de los recursos 5. Aplicar la gerencia de recursos en un entorno multi-
requeridos a lo largo de la línea base del cronograma proyecto.  La gerencia de recursos es una actividad
del proyecto. La nivelación de recursos ofrece una más compleja cuando la consideramos dentro de un
herramienta heurística útil para reconocer los “picos y entorno multiproyecto, esto es, cuando tratamos de
valles” en la asignación de nuestros recursos a través programar los recursos para varios proyectos que
del tiempo, lo cual puede hacer problemática la progra- compiten por una cantidad limitada de recursos. En
mación de recursos. tales circunstancias, un número de opciones están
3. Aplicar los procedimientos de nivelación de recursos disponible para los gerentes de proyecto, con el fin
a las actividades de la línea base del proyecto, usando de que estos encuentren el equilibrio óptimo entre
heurísticas adecuadas de priorización. Empleamos múltiples proyectos en competencia y recursos fini-
técnicas de suavizado de recursos en un esfuerzo tos. Entre las heurísticas de decisión que podemos
para reducir al mínimo los problemas asociados a las emplear en la toma de las decisiones de asignación
fluctuaciones excesivas en el diagrama de carga de de recursos están las que se eligen basados en: (1)
recursos. La suavización de recursos minimiza estas cuáles son los proyectos prioritarios; (2) cuáles son
fluctuaciones con la reprogramación de actividades, a los proyectos de mayor demanda de recursos; (3)
fin de que sea más fácil aplicar los recursos de forma cuáles proyectos tendrán la mayor utilización de
continua en el tiempo. El primer paso en la redistri- recursos, según las políticas de nuestra firma; (4)
bución de recursos consiste en la identificación de las cuáles nos permitirán alcanzar la meta de reducir al
actividades con los posibles candidatos para la modi- mínimo los finales tardíos; y (5) el uso de la progra-
ficación. La pregunta por contestar es: ¿qué actividad mación matemática.
424 Capítulo 12  •  Gerencia de recursos

Términos clave
Carga de recursos (p. 404) División de actividades Nivelación de recursos Proyecto con restricciones
Cuadro de carga de (p. 417) (p. 406) mixtas (p. 403)
recursos (p. 410) Heurísticas de nivelación Proyecto con restricciones Suavizado (p. 406)
Cuadro de uso de recursos (p. 407) de recursos (p. 403) Restricciones de recursos
(p. 405) Inventario en proceso Proyecto con restricciones (p. 402)
Diagramas de carga de (p. 420) de tiempo (p. 403) Restricciones físicas
recursos (p. 415) (p. 402)

Problemas resueltos
1. Considere el cuadro de carga de recursos que se muestra abajo. a. ¿Puede identificar algún día que involucre conflictos de recursos?
Suponga que no puede programar más de ocho horas de trabajo b. ¿Cómo volver a configurar el cuadro de carga de recursos para
durante cualquier día del mes. resolver estos conflictos?

Junio

Actividad 1 2 3 4 5 8 9 10 11 12 15 16 17 18 19 22 23 24 25 26
A 4 4 4 4 4⎦
B 4 4 4 ⎦
C 4 4 4 4 4⎦
D 3 3 3 3 3 3 ⎦
E 3 3 3 3 3 ⎦
F 2 2 2 2 2 2⎦
G 4 4 4 4 ⎦

SOLUCIÓN sos es aprovechar los tiempos muertos disponibles en las ac-


a. De acuerdo con el cuadro de carga de recursos, las fechas 8, 9 y 10 tividades D y G y mover estas actividades más adelante en el
de junio se sobreasignaron (11 horas), al igual que los de los días cronograma, para que corresponda con sus fechas de fin más
16, 17, 18 y 19 de junio (9 horas). tarde (véase el cuadro de carga de recursos que se muestra a
b. Una solución para la nivelación del cuadro de carga de recur- continuación).

Junio

Actividad 1 2 3 4 5 8 9 10 11 12 15 16 17 18 19 22 23 24 25 26
A 4 4 4 4 4⎦
B 4 4 4  ⎦
C 4 4 4 4 4⎦
D 3 3 3 3 3 3 3 3 3 ⎦
E 3 3 3 3 3 ⎦
F 2 2 2 2 2 2⎦
G 4 4 4 4 4 4 4 4 ⎦
Total 4 4 4 4 4 8 8 8 7 7 8 8 8 8 5 6 4 4 4

Preguntas para discusión


1. Considere un proyecto para construir un puente sobre el des- del equipo del proyecto es a menudo un recurso crítico del
filadero de un río. ¿Cuáles serían algunas de las limitaciones de proyecto.
recursos que haría desafiante este proyecto? 3. ¿Cuál es la filosofía subyacente a la carga de recursos? ¿Cómo
2. En muchos proyectos, el recurso clave es el personal del equipo influye en nuestro proyecto? ¿Por qué es un elemento crítico en
del proyecto. Explique en qué sentido y cómo el personal la gerencia eficiente del plan del proyecto?
Problemas 425

4. Un cronograma de proyecto que no ha sido nivelado en recur- d. Actividades con el mayor número de tareas sucesoras
sos es inútil. ¿Está de acuerdo o en desacuerdo con esta afirma- e. Actividades que requieren más recursos
ción? ¿Por qué sí o por qué no? 7. La multitarea tiene un gran efecto negativo en su capacidad
5. Discuta la naturaleza de trade-offs de tiempo/costo en los pro- para nivelar recursos en un proyecto. Cuando los miembros del
yectos. ¿Qué implica este concepto para nuestra práctica de equipo están implicados en múltiples compromisos adicionales,
gerencia de proyectos? debemos evitar asignar su tiempo con demasiado optimismo.
6. Cuando hay nivelación de recursos en un proyecto, una serie de De hecho, se afirma: “Recuerda, 40 horas no es lo mismo que el
heurísticas puede ayudar a priorizar las actividades que deben trabajo de una semana.” Opine sobre esta idea. ¿Cómo la mul-
recibir los recursos en primer lugar. Explique cómo opera cada titarea dificulta nivelar recursos con precisión en un proyecto?
una de las siguientes heurísticas y dé un ejemplo: 8. ¿Por qué la gerencia de recursos es más difícil en un entorno
a. Actividades con la más pequeña holgura multiproyecto? ¿Cuáles son algunas de las técnicas para ayudar
b. Actividades con la duración más corta a los gerentes de proyectos a tener un mejor control sobre los
c. Actividades con el más bajo número de identificación recursos de varios proyectos simultáneos?

Problemas
Considere un proyecto con la siguiente información:

Actividad Duración Predecesoras Actividad Duración ES EF LS LF Holgura


A 3 — A 3  0  3  0  3 —
B 5 A B 5  3  8  5 10 2
C 7 A C 7  3 10  3 10 —
D 3 B, C D 3 10 13 10 13 —
E 5 B E 5  8 13 12 17 4
F 4 D F 4 13 17 13 17 —
G 2 C G 2 10 12 15 17 5
H 5 E, F, G H 5 17 22 17 22 —

Holgura Horas requeridas Recurso totales


Actividad Duración total por semana requeridos
A 3 semanas — 6  18
B 5 semanas 2 4  20
C 7 semanas — 4  28
D 3 semanas — 6  18
E 5 semanas 4 2  10
F 4 semanas — 4  16
G 2 semanas 5 3   6
H 5 semanas — 6  30
Total 146

1. Construya el diagrama de red de actividades del proyecto, 6. Considere el diagrama parcial de carga de recursos que se mues-
basado en la metodología AON. tra más abajo. Suponga que usted puede comprometer máximo 8
2. Identifique la ruta crítica y otras redes a lo largo de la red. horas de trabajo por día.
3. Elabore un cuadro de carga de recursos para este proyecto, a. ¿Cuáles fechas y cuáles recursos del proyecto están
identificando los inicios tempranos y los finales tardíos de las sobreasignados?
actividades. b. ¿Cómo debería reconfigurarse el cuadro de carga de recur-
4. Suponga que hay disponible para el proyecto un máximo de 8 sos para permitir esta sobreasignación?
horas de recurso por semana. ¿Puede identificar las semanas c. Ahora suponga que el máximo número de horas de
con recursos sobreasignados? recurso por día se reduce a 6. ¿Cómo podría reconfigu-
5. Elabore el cuadro de carga de recursos. Identifique la actividad rar el cuadro de carga de recursos ajustada a este nuevo
que puede reprogramarse y reconfigure el cuadro que muestre número? ¿Cuál debería ser la nueva fecha de terminación
esta reubicación. del proyecto?
426 Capítulo 12  •  Gerencia de recursos

&DOHQGDULRGHOSUR\HFWR

-XQLR

$FWLYLGDG

Estudio de caso 12.1


Los problemas de la multitarea
Una empresa de servicios financieros del este de Estados trabajo. De nuevo, en palabras de la consultora, “asuntos
Unidos se retrasó mucho y por encima del presupuesto, del programa aparecían y no había nadie para gerenciar-
en un programa estratégico vital. Tanto las líneas base del los [a su debido tiempo].” Esos pequeños problemas, no
presupuesto y el cronograma habían comenzado atrasa- corregidos, con el tiempo crecieron hasta convertirse en
das casi desde el principio, y a medida que el proyecto grandes problemas. El cronograma continuó con retrasos
avanzaba, los retrasos se convirtieron suficientemente y la moral de los empleados comenzó a decaer.
en graves como para que la compañía recurriera a ayuda Después del reconocimiento del problema, el pri-
experta, mediante una empresa consultora de gerencia mer paso que sugirieron los consultores era consultar a la
de proyectos. Después de investigar las operaciones de alta gerencia para renegociar las asignaciones de trabajo
la organización, la consultora determinó que la principal con el equipo del proyecto. En primer lugar, los miem-
fuente de problemas con este proyecto en particular, y de bros del equipo central fueron liberados de otras respon-
las prácticas de gerencia de proyectos de la empresa en sabilidades para que pudieran dedicarse de tiempo com-
general, fue no pronosticar con precisión las necesidades pleto al programa. Luego, otros miembros de apoyo del
de recursos. En palabras de uno de los consultores: “No proyecto fueron liberados de funciones multitarea y asig-
hubo suficientes recursos de tiempo completo [recurso nados al proyecto en jornada completa o casi de tiempo
humano] dedicados al programa.” completo. El resultado, junto a otros cambios sugeridos
El mayor problema era el hecho de que muchos de por los consultores, era igualar finalmente el horario del
los miembros del equipo del proyecto trabajaban en dos proyecto y la duración estimada de actividad del proyecto,
o más proyectos a la vez, un claro ejemplo de multitarea. con una comprensión realista de las necesidades de recur-
Infortunadamente, los líderes del programa desarrolla- sos y su disponibilidad. En resumen, el programa se puso
ron su ambicioso programa sin reflexionar sobre la dis- de nuevo en marcha, porque finalmente se nivelaron sus
ponibilidad de recursos para apoyar a los hitos del pro- recursos, sobre todo mediante las asignaciones de trabajo
yecto. Con sus excesivas responsabilidades adicionales, de tiempo completo para el equipo del proyecto, lo cual
nadie estaba dispuesto a asumir la propiedad directa de reflejaba con precisión la necesidad de vincular la gerencia
su trabajo en el programa; la gente hacía malabares con de recursos con el cronograma.12
las tareas, y todo el mundo se atrasaba cada vez más en el
(continúa)
Ejercicios con MS Project 427

Preguntas diferencia entre la duración de una actividad y el cro-


nograma del proyecto. En otras palabras, 40 horas de
1. ¿Cómo dificulta la multitarea la disponibilidad de los
trabajo de una tarea del proyecto no es lo mismo que
recursos de personal del equipo del proyecto?
una semana de trabajo. Por favor, comente acerca de
2. “En las organizaciones modernas, es imposible elimi-
esta afirmación. ¿Por qué la multitarea “desacopla”
nar la multitarea para el empleado promedio.” ¿Está de
estimaciones de la duración de las actividades del cro-
acuerdo o en desacuerdo con esta afirmación? ¿Por qué?
nograma del proyecto?
3. Debido a los problemas de la multitarea, los geren-
tes de proyectos deben tener en cuenta que hay una

Ejercicios en internet
1. Ingrese en www.fastcompany.com/magazine/87/project-mana- En cada uno de los ejemplos, cite evidencias de los tipos de res-
gement.html. ¿Qué sugerencias ofrece el autor para gerenciar tricciones que usted ha identificado. ¿Hay evidencia de cómo el
las presiones de la multitarea? El autor sugiere la necesidad de proyecto está desarrollándose para minimizar o resolver estas
“multiproyecto.” ¿Cuál es su punto de vista sobre el aprendizaje restricciones?
de multiproyectos? 3. Ingrese en sitios web relacionados con el proyecto del túnel
2. Busque en la web ejemplos de proyectos que tienen: de Boston conocido como “Big Dig.” Describa los problemas
a. Restricciones de tiempo que tuvo el proyecto. ¿Cómo la gerencia de recursos desem-
b. Restricciones de recursos peñó un papel en las demoras y en los sobrecostos asociados
c. Restricciones mixtas al proyecto?

Ejercicios con MS Project


Ejercicio 12.1 Recurso
Remítase al cuadro de actividades que se muestra a continuación. Actividad Duración Predecesora asignado
Introduzca esta información en MS Project para generar un diagra- A. Encuesta a usuarios  4 None Gail Wilkins
ma de Gantt. Suponga que cada recurso se ha asignado a la actividad
B. Codificación 12 A Tom Hodges
de proyecto en una base de tiempo completo (8 horas/día o 40 horas/
semana). C. Depuración  5 A Tom Hodges
D. Diseño de interfaz  6 B, C Sue Ryan
Recurso E. Capacitación  5 D Reed Taylor
Actividad Duración Predecesora asignado
A. Encuesta a usuarios  4 Ninguna Gail Wilkins a. Al utilizar la Vista de uso de recursos (Resource Usage), ¿puede
determinar alguna señal de advertencia sobre algún miembro del
B. Codificación 12 A Tom Hodges
equipo del proyecto que está sobreasignado?
C. Depuración  5 B Wilson Pitts b. Dé clic en Uso de tarea (Task Usage) para determinar los días es-
D. Diseño de interfaz  6 A, C Sue Ryan pecíficos en que hay un conflicto en el cronograma de asignación
E. Capacitación  5 D Reed Taylor de recursos.

Ejercicio 12.2 Ejercicio 12.4


Con la información del ejercicio 12.1, elabore un cuadro de uso de Con la información del ejercicio 12.3, ¿cómo podría nivelar los re-
recursos que identifique el número total de horas y las asignaciones cursos de esta red para superar los conflictos? Muestre cómo nive-
diarias para cada miembro del equipo del proyecto. laría los recursos de la red de actividades. Desde la perspectiva de
cronograma, ¿cuál es la nueva duración del proyecto?
Ejercicio 12.3
Preguntas de ejemplo del examen para la certificación
Remítase al cuadro de actividades del ejercicio 12.1. Suponga que PMP®
modificamos ligeramente el cuadro original para mostrar la siguiente
relación de precedencia entre tareas y recursos asignados para ejecu- 1. La gerente de proyectos identifica 20 tareas que requie-
tar estas actividades. Ingrese la información en MS Project y genere ren completarse en su proyecto. Ella tiene 4 miembros del
el diagrama de Gantt. Suponga que cada recurso se ha asignado a la equipo del proyecto disponibles para asignarlos a estas ac-
actividad de proyecto en una base de tiempo completo (8 horas/día o tividades. El proceso de asignar personal a las actividades
40 horas/semana). del proyecto se conoce como:
428 Capítulo 12  •  Gerencia de recursos

a. Nivelación de recursos d. Las actividades con el mayor número de identifi-


b. Carga de recursos cación en la EDT son las primeras en recibir los re-
c. Hallar la línea base cursos disponibles
d. Crear la EDT
5. Uno de los beneficios de los diagramas de carga de recur-
2. La definición correcta de nivelación de recursos es: sos es que:
a. Una gráfica que muestra los recursos utilizados a a. Representan un método para hallar holguras dis-
través del tiempo en el proyecto ponibles de actividades
b. El proceso de aplicar recursos a las actividades del b. Gráficamente muestran la cantidad de recursos re-
proyecto queridos en función del tiempo
c. El proceso de crear un nivel de carga de trabajo con- c. Ayudan a resolver conflictos en la definición de
sistente para los recursos del proyecto, basado en las multiproyectos
restricciones de recursos existentes d. Todos los anteriores son beneficios del uso de dia-
d. Un cronograma de proyecto cuyas fechas de inicio y gramas de carga de recursos
fin reflejan la disponibilidad esperada de los recursos
Respuestas: 1. b—La acción de asignar recursos de persona a las
3. Las restricciones de recursos en el proyecto pueden invo-
actividades específicas de proyecto regularmente se llama carga de
lucrar cualquiera de los siguientes ejemplos:
recursos; 2. c—La nivelación de recursos involucra suavización o
a. Trabajadores mal entrenados
creación de cargas de trabajo consistentes, a lo largo del crono-
b. Falta de materiales disponibles para construcción
grama del proyecto para los recursos disponibles; 3. d—Los recur-
c. Restricciones ambientales o físicas del sitio del
sos de proyectos pueden incluir personas, condiciones físicas y re-
proyecto
cursos de material; por tanto, todos los ejemplos representan
d. Todas las anteriores deberían considerarse restriccio-
restricciones de recursos; 4. a—Como una útil heurística de nive-
nes del proyecto
lación de recursos, las actividades con la menor holgura deberían
4. Cuando se adoptan heurísticas de restricción de recursos, tener asignados los recursos primero; 5. b—Los diagramas de carga
¿cuáles de las siguientes son reglas de decisión relevantes? de recursos son un medio gráfico para identificar requerimientos
a. Las actividades con la menor holgura deberían tener de recursos, como una función de la duración del proyecto; ayudan
asignados los recursos primero a identificar visualmente sobrecargas o ineficiencias en la asigna-
b. Las actividades con la mayor duración son las mejo- ción de recursos.
res candidatas para recibir recursos extras
c. Actividades con el menor número de tareas sucesoras
deberían tener prioridad en los recursos
Notas 429

PROYECTO INTEGRADO

Gerencia de los recursos de su proyecto


Usted tiene una tarea importante en este caso. Ahora que ha creado un plan de red, incluido un cronograma
para su proyecto, es vital nivelar los recursos del plan. Desarrolle un diagrama de carga de recursos para su
proyecto. Al hacer esto, tenga en cuenta el presupuesto que ha creado para su plan y el personal que ha selec-
cionado para el equipo del proyecto. Su procedimiento de nivelación de recursos debe ser coherente con el
cronograma del proyecto (lo máximo que sea posible), mientras mantiene su compromiso con el uso de los
recursos del proyecto que pretende emplear.
Recuerde que la clave para hacer esta tarea de manera eficiente radica en ser capaz de maximizar el uso
de los recursos del proyecto, mientras se produce un efecto mínimamente perjudicial en la programación
inicial del proyecto. Como resultado de ello, puede que sea necesario involucrarse en varias iteraciones del
proceso de nivelación de recursos a medida que comienza a cambiar tareas no críticas a fechas posteriores,
con el fin de maximizar el uso de personal sin alterar la fecha de entrega del proyecto. Para simplificar, se
puede suponer que sus recursos para el proyecto se han comprometido 100% de su tiempo de trabajo. En
otras palabras, cada recurso es capaz de trabajar 40 horas a la semana en este proyecto.
Elabore el cuadro de nivelación de recursos. Asegúrese de incluir la línea base del cronograma en el eje
horizontal. ¿Cuál fue su base inicial? ¿Cómo afectaron los recursos de nivelación de su proyecto la línea base?
¿Es la nueva fecha de terminación prevista mayor que la fecha original? Si es así, ¿por cuánto tiempo?

Notas
1. Bowman, Z. (2010). “Nissan Leaf owners have rapid response 6. Fendley, L. G. (1968, octubre). “Towards the development
system lying in wait,” www.autoblog.com/2010/11/24/nis- of a complete multiproject scheduling system,” Journal of
san-leaf-owners-have-rapid-response-system-lying-in-wait/; Industrial Engineering, 19, 505–15; McCray, G. E., Purvis, R.
Cole, J. (2010). “Best car to buy in 2011? Nissan LEAF accord- L., and McCray, C. G. (2002). “Project management under
ing to green car reports,” http://nissan-leaf.net/2010/11/20/ uncertainty: The impact of heuristics and biases,” Project
best-car-to-buy-in-2011-nissan-leaf-according-to-green- Management Journal, 33(1): 49–57; Morse, L. C., McIntosh,
car-reports/; Ramsey, M. (2010, 23 de noviembre).“Nissan J. O., and Whitehouse, G. E. (1996). “Using combinations
Leaf claims 99 MPG,” Wall Street Journal, p. B8; Voelker, of heuristics to schedule activities of constrained multiple
J. (2010). “GM confirms, yes, we’re losing money on every resource projects,” Project Management Journal, 27(1):
Volt we build,” www.greencarreports.com/blog/1052107_ 34–40; Woodworth, B. M., and Willie, C. J. (1975). “A
gm-confirms-yes-were-losing-money-on-​e very-volt-we- ­heuristic ­algorithm for resource leveling in multiproject,
build; Welsh, J. (2010, 24 de noviembre). “Nissan Leaf gets ­multiresource scheduling,” Decision Sciences, 6: 525–40;
99-MPG rating from EPA, Volt still waiting,” Wall Street Boctor, F. F. (1990). “Some efficient multi-heuristic proce-
Journal, http://blogs.wsj.com/drivers-seat/2010/11/24/ dures for resource-constrained project scheduling,” European
nissan-leaf-gets-99-mpg-rating-from-epa-volt-still-waiting/. Journal of Operations Research, 49: 3–13.
2. Dumaine, B. (1986, 1 de septiembre). “The $2.2 billion nu- 7. Fendley, L. G. (1968), as cited.
clear fiasco,” Fortune, 114: 14–22. 8. Field, M., and Keller, L. (1998). Project Management.
3. Raz, T., and Marshall, B. (1996). “Effect of resource London: The Open University; Woodworth, B. M., and
constraints on float calculation in project networks,” Shanahan, S. (1988). “Identifying the critical sequence in
International Journal of Project Management, 14(4): 241–48. a ­resource-constrained project,” International Journal of
4. Levene, H. (1994, abril). “Resource leveling and roulette: Project Management, 6(2): 89–96; Talbot, B. F., and Patterson,
Games of chance—Part 1,” PMNetwork, 7; Levene, H. (1994, J. H. (1979). “Optimal models for scheduling under resource
julio). “Resource leveling and roulette: Games of chance— constraints,” Project Management Quarterly, 10(4), 26–33.
Part 2,” PMNetwork, 7; Gordon, J., and Tulip, A. (1997). 9. Gray, C. F., and Larson, E. W. (2003). Project Management,
“Resource scheduling,” International Journal of Project 2nd ed. Burr Ridge, IL: McGraw-Hill.
Management, 15: 359–70; MacLeod, K., and Petersen, P. 10. Meredith, J. R., and Mantel, Jr., S. J. (2003), como se cita.
(1996). “Estimating the tradeoff between resource allocation 11. Meredith, J. R., and Mantel, Jr., S. J. (2003), como se cita.
and probability of on-time completion in project manage- 12. Weaver, P. (2002). “Vanquishing PM nightmares,” PMNetwork,
ment,” Project Management Journal, 27(1): 26–33. 16(1): 40–44.
5. Meredith, J. R., and Mantel, Jr., S. J. (2003). Project Management:
A Managerial Approach, 5th ed. New York: Wiley and Sons.
CAPÍTULO

13
Evaluación y control de proyectos

Contenido del capítulo


PERFIL DE PROYECTO PERFIL DE PROYECTO
New Zeland’s Te Apiti Wind Farm— Éxito bajo presión Valor ganado en Northrop Grumman
INTRODUCCIÓN 13.5 PROBLEMAS DEL USO EFECTIVO DE LA
13.1 CICLOS DE CONTROL: UN MODELO GENERAL GERENCIA DEL VALOR GANADO
13.2 MONITOREAR EL DESEMPEÑO DEL 13.6 FACTORES HUMANOS EN LA EVALUACIÓN Y
PROYECTO EL CONTROL DE PROYECTOS
Curva S del proyecto: una herramienta básica Definición de los factores claves de éxito
Inconvenientes de la curva S Conclusiones
Análisis de hitos Resumen
Problemas con los hitos Términos clave
Diagrama de Gantt de seguimiento Problema resuelto
Ventajas y desventajas de los diagramas de Gantt de Preguntas para discusión
 seguimiento Problemas
13.3 GERENCIA DEL VALOR GANADO Estudio de caso 13.1 El Departamento de IT de la Universidad
Terminología del valor ganado  Kimble
Creación de las líneas base del proyecto Estudio de caso 13.2 El superconductor Supercollider
¿Por qué utilizar el valor ganado? Ejercicios en internet
Pasos en la gerencia del valor ganado Ejercicios con MS Project
Evaluación del valor ganado del proyecto Preguntas de ejemplo del examen para la certificación PMP®
Apéndice 13.1—Cronograma ganado*
13.4 APLICACIÓN DEL VALOR GANADO A LA
Notas
GERENCIA DEL PORTAFOLIO DE PROYECTOS

Objetivos de aprendizaje
Al finalizar este capítulo, el estudiante estará en capacidad de:
1. Comprender los fundamentos del ciclo de control y sus cuatro pasos claves en un modelo general de control del proyecto.
2. Reconocer las fortalezas y debilidades de los métodos comunes de evaluación y control de proyectos.
3. Comprender cómo la gerencia del valor ganado puede ayudar al seguimiento y evaluación de proyectos.
4. Utilizar la gerencia del valor ganado en el análisis del portafolio de proyectos.
5. Comprender los conceptos del comportamiento y otros aspectos humanos en la evaluación y en el control.
6. Del apéndice 13.1, comprender las ventajas de los métodos de programación ganada para determinar la variación de la
programación del proyecto, el índice de desempeño del cronograma y la estimación de la terminación.
430
Perfil de proyecto 431

CONCEPTOS BÁSICOS DE LOS FUNDAMENTOS PARA LA GERENCIA DE


PROYECTOS(PROJECT MANAGEMENT BODY OF KNOWLEDGE, PMBOK® GUIDE, 5A.
EDICIÓN)CUBIERTOS EN ESTE CAPÍTULO
1. Control del cronograma (PMBOK®, sección 6.6).
2. Control de costos (PMBOK®, sección 7.3).
3. Sistema de valor ganado (PMBOK®, sección 7.3.2).

PERFIL DE PROYECTO

Caso: New Zeland’s Te Apiti Wind Farm — Éxito bajo presión


En la era moderna, en la búsqueda de fuentes alternativas de energía, una de las más populares en los últimos años ha
sido el aprovechamiento y utilización de la energía eólica. La generación de energía eólica puede ser un medio impor-
tante para reducir al mínimo el uso de combustibles fósiles en la generación de electricidad. Durante la última década,
el gobierno de Nueva Zelanda ha trabajado diligentemente para expandir su compromiso con la energía eólica, una
fuente obvia de energía en un país de gran belleza natural pero sin reservas de las fuentes de energía más comunes,
como el carbón o el petróleo. Desde el año 2000, Nueva Zelanda ha desarrollado doce parques eólicos con una capaci-
dad conjunta de casi 500 megavatios y capaz de generar 4% de las necesidades energéticas actuales del país.
Tal vez el proyecto más impresionante, dentro de los parques eólicos, fue el primer trabajo de Nueva Zelanda
para suministrar energía a la red nacional: el Wind Farm Te Apiti, ubicado en la región sur de la isla norte. Las ins-
talaciones del Te Apiti se encuentran en el Manawatu Gorge, un sitio excepcional en donde el desfiladero actúa
como un túnel de viento natural, creando vientos consistentes de alta velocidad. Infortunadamente, la ventaja de
la ubicación fue también una limitación para el proyecto: El sitio remoto está, rodeado de tierras de propiedad
privada y con acceso restringido a la zona de construcción.
Cuando el proyecto se inició en noviembre de 2003, las primeras actividades incluían la construcción de más
de 20 kilómetros de carreteras en el Manawatu Gorge, por donde se instalarían más de 40 kilómetros de cableado
Picade LLC / Alamy

FIGURA 13.1  Torre de generación en


el Te Apiti WInd Farm

(continúa)
432 Capítulo 13  •  Evaluación y control de proyectos

subterráneo. El terreno está lleno de barrancos, arroyos, pendientes empinadas y suelos inestables. Todo el equipo
del parque eólico, incluidos 55 turbinas y el material para la construcción de las torres y de las palas eólicas, tuvo que
transportarse por una pista estrecha y difícil hasta dentro del sitio de construcción. Cada torre se diseñó con una
altura de aproximadamente 220 pies de altura y para sostener tres aspas de las turbinas, cada una de más de 100 pies
de longitud. Además, la construcción del parque eólico requirió verter 60,000 metros cúbicos de hormigón y mover
1.2 millones de metros cúbicos de tierra.
El proyecto tuvo un difícil comienzo, por causas ajenas. Las condiciones meteorológicas fueron atroces, desde el
momento en que los primeros equipos de trabajadores comenzaron sus labores en el sitio. Una serie casi continua de
tormentas generaron precipitaciones de más del doble del promedio de lluvia e inundaron el sitio del proyecto. El 6 de
febrero de 2004, la precipitación alcanzó un registro máximo en 50 años, seguido diez días después de otra tormenta
¡que estableció un nuevo récord en 100 años! Las precipitaciones provocaron inundaciones, jamás registradas en la
zona, y originaron la declaración de emergencia civil. El puente de acceso principal a la obra de construcción fue arras-
trado por las inundaciones, y Manawatu George, la principal vía fluvial, fue cerrada durante cuatro meses, lo cual dejó
al equipo del proyecto con una sola pista de barro para transportar todo el material y el equipo al sitio de construcción.
El clima afectó el proyecto y obligó algunos de los principales cambios en el alcance inicial, entre ellos:
1. Trabajar con el gobierno local para restaurar el puente de acceso destruido.
2. Reformar el cronograma de trabajo, con el fin de permitir que todos los contratistas, la planta y los equipos
de trabajo colaboraran en la atención de las inundaciones como una parte de la implementación de la Civil
Emergency Act de Nueva Zelanda.
3. Estabilizar las vías existentes para garantizar la entrega continua de materiales.
4. Actualizar la programación del proyecto del parque eólico para mantener el plazo de terminación, a pesar de
estas responsabilidades adicionales.
Las restricciones del proyecto obligaron a todos los miembros del equipo a trabajar juntos de manera colaborativa
para enfrentar los nuevos retos de la construcción, manteniendo un ambicioso cronograma para la terminación del
parque eólico. Con la utilización de técnicas eficaces de gestión de riesgos, el proyecto logró evitar muchos de los
problemas comunes que se presentan en los proyectos de construcción civil a gran escala. Por ejemplo, no se regis-
traron incidentes con tiempo perdido durante la totalidad de las 250,000 horas hombre de trabajo del proyecto.
En general, el proyecto del Te Apiti Wind Farm se terminó cinco días antes de lo previsto, en julio de 2004, con un
excelente historial de seguridad, y dentro del presupuesto de 150 millones de dólares Actualmente, es el parque
eólico más grande en el hemisferio sur, y produce suficiente energía para 45,000 hogares. A pesar de tener que
enfrentar las terribles condiciones climáticas, la lluvia incesante y ser suficientemente ágil como para ampliar el
alcance del proyecto original, a fin de incluir la asistencia en medidas de emergencia civil, el proyecto es un exce-
lente ejemplo de trabajo en un entorno difícil, de la aplicación eficaz de técnicas de gerencia de proyectos y del
cumplimiento riguroso de las ambiciosas metas del cronograma y del presupuesto para completar un proyecto que
ha tenido resultados importantes en la política energética del gobierno de Nueva Zelanda.1

INTRODUCCIÓN
Uno de los retos más importantes durante la ejecución de un proyecto tiene que ver con mantener un sistema de
monitoreo y control preciso. Dado que los proyectos, a menudo, se definen por sus restricciones (es decir, por sus
limitaciones de presupuesto y de cronograma), es vital que nos aseguremos de que están controlados lo más cuida-
dosamente posible. El seguimiento y el control del proyecto son los principales mecanismos que permiten que el
equipo del proyecto pueda mantenerse al tanto de la situación de evolución de un proyecto, a medida que avanza
en las diferentes etapas de su ciclo de vida hacia su finalización. En lugar de adoptar un enfoque para el seguimiento
y control de los proyectos de “no tener noticias es una buena noticia”, se requiere entender claramente los beneficios
que pueden derivarse de evaluaciones cuidadosas y minuciosas del estado de avance del proyecto.
Con el fin de garantizar que el control del proyecto sea lo más óptimo posible, tenemos que centrar
nuestra atención en dos aspectos importantes del proceso de seguimiento. El primero, tenemos que identi-
ficar las señales apropiadas que indican el estado del proyecto; el segundo, entender los mejores momentos
de todo el ciclo de vida del proyecto para obtener una evaluación precisa de su rendimiento. En otras pala-
bras, tenemos que ser plenamente conscientes para responder las preguntas qué y cuándo: ¿qué aspectos
del proyecto deben medirse? y ¿cuándo son los mejores momentos para medirlos? Nuestra meta es tener
una idea de cómo desarrollar un control sistemático del proyecto, de forma que sea completo, preciso y
oportuno. En otras palabras, cuando somos responsables de una inversión de varios millones de dólares
en nuestra organización, queremos conocer el estado del proyecto, deseamos la información tan pronta y
actualizada como sea posible.
13.1  Ciclos de control: un modelo general 433

13.1  CICLOS DE CONTROL: UN MODELO GENERAL


Un modelo general de control organizacional consta de cuatro componentes que pueden operar en un ciclo
continuo y se puede representar como una rueda. Estos elementos son:
1. Establecer una meta.  La fijación de metas del proyecto va más allá del desarrollo global del alcance,
incluido el establecimiento del plan de línea base del proyecto. La línea base del proyecto se funfa-
menta en un proceso adecuado para definir la estructura de desglose de trabajo (EDT). Recuerde que
la EDT establece todos los entregables y paquetes de trabajo relacionados con el proyecto, asigna el
personal responsable de estos, y crea un gráfico visual del proyecto, desde el más alto nivel pasando
por los niveles de entregables y de tareas. La línea base del proyecto se genera cuando todas las tareas
se representan en un diagrama de red y los recursos y duraciones se asignan a estas.
2. Medir el progreso.  Un sistema eficaz de control de proyectos requiere mecanismos exactos de medi-
ción. Los gerentes de proyecto deben tener un sistema en la obra que les permita medir el estado actual
de las diversas actividades del proyecto en tiempo real. Necesitamos un sistema de medición que pro-
porcione información lo más rápidamente posible. También se necesita definir qué medir. Cualquier
número de dispositivos nos permitirá medir algún aspecto del proyecto, sin embargo, la pregunta más
importante es si estamos o no estamos recibiendo el tipo de información que realmente necesitamos y
podemos utilizar.
3. Comparar el rendimiento real con el planeado.  Cuando hemos definido la línea base original (plan)
y un método para medir con precisión el progreso, el siguiente paso es comparar los dos tipos de infor-
mación. Un análisis de brecha se puede utilizar como base para probar el estado del proyecto. El análisis
de brechas se refiere a todo proceso de medición que determine primero las metas y luego el grado de
rendimiento real respecto a esas metas. Cuanto menor sea la brecha entre el rendimiento previsto y el
real, mejor será el resultado. En los casos en los que vemos diferencias obvias entre lo planeado y lo real,
tenemos una señal clara de advertencia.
4. Pasar a la acción.  Una vez detectamos desviaciones significativas en el plan del proyecto, se requiere
realizar algún tipo de acción correctiva para reducir al mínimo, o eliminar, tal desviación. El proceso
de tomar una acción correctiva generalmente es inmediato. La acción correctiva bien puede ser relati-
vamente menor o implicar medidas significativas. En su forma más extrema, la acción correctiva puede
incluso llegar a detener un proyecto sin rendimiento. Después de la acción correctiva, el ciclo de moni-
toreo y control comienza de nuevo.
Como muestra la figura 13.2, el ciclo de control es continuo. A medida que creamos un plan, empeza-
mos labores de medición para hacerle seguimiento al progreso y comparar las etapas del proyecto contra el
plan previsto. Cualquier indicio de desviaciones significativas respecto al plan, debe activar inmediatamente
una respuesta adecuada, como la reconfiguración del plan o la reevaluación del progreso, entre otras. El
seguimiento del proyecto es un ciclo continuo, que incluye la fijación de objetivos, la medición, la corrección,
la mejora y de nuevo volver a medir.

1. Establecer una meta

4. Tomar acciones 2. Medir el


y reanudar el progreso
ciclo del proceso

3. Comparar lo real con lo planeado

FIGURA 13.2  El ciclo de control del proyecto


434 Capítulo 13  •  Evaluación y control de proyectos

13.2  MONITOREAR EL DESEMPEÑO DEL PROYECTO


Como descubrimos en los capítulos sobre el presupuesto de proyectos y gerencia de recursos, una vez establecido
un presupuesto de referencia para el proyecto, uno de los métodos más importantes para monitorear el estado
actual del proyecto es evaluarlo contra las previsiones presupuestarias iniciales. Para el seguimiento y control de
proyectos, los presupuestos de las tareas individuales y el presupuesto acumulado del proyecto son relevantes. El
presupuesto acumulado se puede dividir en el tiempo, de acuerdo con la duración prevista del proyecto.

Curva S del proyecto: una herramienta básica


Como base para la evaluación de las técnicas de control de proyectos, vamos a considerar un ejemplo senci-
llo. Supongamos un proyecto (Proyecto Sierra) con cuatro paquetes de trabajo (diseño, ingeniería, instalación
y pruebas), con un presupuesto de $80,000, y una duración prevista de 45 semanas. El cuadro 13.1 desglosa el
presupuesto acumulado del proyecto, en términos de paquetes de trabajo y de tiempo.
Para determinar el desempeño y estado del proyecto, la primera opción es realizar un análisis de tiempo/
costo. Aquí el estado del proyecto se evalúa en función de los costos acumulados y las horas de mano de obra
o las cantidades de trabajo, en función del tiempo, para los montos presupuestados y los reales. Podemos
ver que el tiempo (mostrado horizontalmente, o en el eje x) se compara con el dinero gastado (mostrado
verticalmente o en el eje y).La clásica curva S del proyecto representa una relación de este tipo. Los gastos
del presupuesto inicialmente son bajos y se incrementan rápidamente durante la fase principal de ejecución
del proyecto, antes de comenzar a estabilizarse de nuevo a medida que se acerca la terminación del proyecto
(véase la figura 13.3). Las proyecciones presupuestarias acumuladas para el Proyecto Sierra se muestran en
el cuadro 13.1 respecto al cronograma del proyecto. La curva S representa la línea base del presupuesto del
proyecto contra la cual se evalúan los gastos presupuestarios reales.
Controlar el estado de un proyecto utilizando curvas S se convierte en un problema de seguimiento
simple. Al finalizar cada periodo determinado (semana, mes o trimestre), simplemente el total de los gastos
acumulados del presupuesto del proyecto hasta la fecha son comparados con los patrones de gasto previstos.
Las desviaciones significativas entre el gasto presupuestado real y el previsto revelan un problema potencial.
La simplicidad es la principal ventaja del análisis de la curva S. Debido a que la línea base del proyecto
se establece por adelantado, los únicos datos adicionales que se muestran son los gastos reales del presupuesto
del proyecto. La curva S también proporciona, en tiempo real, la información de seguimiento debido a que
los gastos presupuestarios se actualizan constantemente y los nuevos valores modifican el gráfico. La infor-
mación del proyecto se puede visualizar inmediatamente y se actualiza continuamente, por lo que las curvas S
bridan una lectura fácil de la evaluación del estado del proyecto, en un momento particular. (Sin embargo, la
información no es necesariamente fácil de interpretar, como veremos más adelante).
Nuestro ejemplo, el Proyecto Sierra (cuyo presupuesto se muestra en el cuadro 13.1) también puede uti-
lizarse para ilustrar cómo se emplea el análisis de la curva S. Supongamos que en la semana 21 en el proyecto,
el presupuesto inicial de gastos es $50,000. Sin embargo, las inversiones reales del proyecto fueron de solo
$40,000. En efecto, se presenta un déficit presupuestario de $10,000, o una variación negativa entre el costo
acumulado presupuestado del proyecto y su costo acumulado real. La figura 13.4 muestra el seguimiento
de los costos presupuestados versus los costos reales del proyecto, incluida la identificación de la variación
negativa, en la semana 21. En esta ilustración, vemos la importancia del análisis de la curva S, como un buen
método visual para vincular los costos del proyecto (tanto presupuestados como reales) durante el avance en
el cronograma de los proyectos.

CUADRO 13.1  Costos presupuestados para el Proyecto Sierra (en miles de dólares)

Duración (en semanas)


5 10 15 20 25 30 35 40 45 Total
Diseño 6  2
Ingeniería  4  8  8  8
Instalación  4 20  6
Pruebas  2  6  4  2
Total 6  6  8 12 28  8  6  4  2
Acumulado 6 12 20 32 60 68 74 78 80 80
13.2  Monitorear el desempeño del proyecto 435

80

Costo acumulado (en miles de dólares)


60

40

20

5 10 15 20 25 30 35 40 45
Tiempo transcurrido (en semanas)

FIGURA 13.3  Curva S del proyecto

80
Costo acumulado (en miles de dólares)

60

$10,000 Variación negativa.


40

20

5 10 15 20 25 30 35 40 45
Tiempo transcurrido (en semanas)

Costo presupuestado acumulado


Costo real acumulado

FIGURA 13.4  Curva S para el Proyecto Sierra, con una variación negativa

Inconvenientes de la curva S
Cuando los equipos de proyecto utilizan las curvas S, tienen que tomar en cuenta los inconvenientes del método,
así como sus fortalezas. Las curvas S pueden identificar variaciones positivas o negativas (los costos del presu-
puesto por encima o por debajo de las proyecciones), pero que no nos permitirá hacer interpretaciones razona-
bles en cuanto a la causa de estas variaciones. Considere la curva S que se muestra en la figura 13.4. La línea de
los gastos presupuestarios reales sugieren que, hasta la fecha, el equipo del proyecto no ha gastado el dinero total
previsto en el presupuesto (variación negativa). Sin embargo, la pregunta es cómo interpretar este hallazgo. La
436 Capítulo 13  •  Evaluación y control de proyectos

relación entre los costos acumulados del proyecto y el tiempo, no siempre es fácil de resolver. ¿Es el equipo del
proyecto, quien ha retrasado la ejecución del proyecto (dado que no ha ejecutado el presupuesto previsto a la
fecha) o podrían existir razones alternativas para la variación negativa)?
Suponga que su organización realiza el seguimiento de costos del proyecto, empleando el método de la
curva S, y utiliza esa información para evaluar el estado de un proyecto en curso. Suponga también que el pro-
yecto se completará en 12 meses y tiene un presupuesto de $150,000. En la revisión de seis meses, se descubre
que la curva S del proyecto muestra déficit significativo; hasta la fecha, se ha gastado menos en el proyecto de lo
que se había presupuestado originalmente. ¿Es esto bueno o malo? Por un lado, podríamos suponer que este es
un signo de mal desempeño; estamos quedándonos atrás en la ejecución del proyecto, y el monto más pequeño
que hemos gastado hasta la fecha es la evidencia de que nuestro proyecto se ha retrasado. Por otro lado, hay una
serie de razones para justificar por qué esta circunstancia, en realidad, podría ser positiva. Por ejemplo, supon-
gamos que durante la gerencia del proyecto se encontró un método rentable para fabricar algún componente de
la obra o se halló con una nueva tecnología que redujo significativamente los gastos. En ese caso, la métrica de
tiempo/costo podría no solo estar mal utilizada, sino que también podría conducir a conclusiones radicalmente
inexactas.
Del mismo modo, la variación positiva no siempre es un signo de progreso del proyecto. De hecho, un
equipo puede tener un graves problemas respecto a los gastos, que pueden interpretarse como un gran pro-
greso en el proyecto cuando en realidad indica otra cosa, incluso el uso ineficiente de los recursos de capital
del proyecto. El fondo es este: simplemente al evaluar el estado de un proyecto de acuerdo con su desem-
peño en el tiempo, en función de los gastos del presupuesto, puede fácilmente llevarnos a hacer suposiciones
inexactas sobre el rendimiento del proyecto.

Análisis de hitos
Otro método para monitorear el progreso del proyecto es el análisis de hitos. Un hito es un evento o una
etapa del proyecto que representa un logro significativo en el camino hacia la terminación del proyecto. La
finalización de un entregable (una combinación de múltiples tareas del proyecto), una actividad importante
en la ruta crítica del proyecto, o incluso una fecha del calendario, todos estos pueden ser ejemplos de hitos.
En efecto, los hitos son marcadores de carretera que observamos en nuestros viajes a lo largo del ciclo de
vida del proyecto. Hay varias ventajas al usar hitos como una forma de control del proyecto.

1. Los hitos señalan la finalización de importantes etapas del proyecto.  Los hitos del proyecto son
indicadores importantes de la situación actual del proyecto en desarrollo. Le dan al equipo del proyecto
un lenguaje común para utilizar en el análisis de la situación actual del proyecto.
2. Los hitos pueden motivar al equipo de proyecto.  En grandes proyectos con duración de varios años,
la motivación se vuelve importante debido a que los miembros del equipo tienen dificultades para
identificar cuál ha sido y sigue siendo su contribución a medida que el proyecto avanza, y por cuánto
tiempo más el proyecto la requerirá. Centrar la atención en los hitos ayuda a que los miembros del
equipo sean más conscientes de los éxitos del proyecto, así como su estatus, y pueden comenzar a desa-
rrollar una identidad más clara de las tareas en relación con su trabajo en el proyecto.
3. Los hitos ofrecen puntos de referencia para volver a evaluar las necesidades del cliente y las solicitudes
de cambio potenciales.  Un problema común en muchos tipos de proyectos se relaciona con las repeti-
tivas y constantes solicitudes de cambio por los clientes. El uso de hitos formales de revisión del proyecto
como “puntos de parada” permiten que el equipo del proyecto y los clientes tengan claro en qué momento
realizar revisiones de medio término del proyecto y cómo manejar las solicitudes de cambio. Cuando los
clientes son conscientes de estos puntos formales de revisión del proyecto, están en mejores condiciones
para presentar retroalimentación (y solicitudes de cambio de especificaciones) razonable y bien susten-
tada al equipo.
4. Los hitos ayudan a coordinar cronogramas con los vendedores y proveedores.  La fijación de las
fechas de entrega que no retrasen las actividades del proyecto es un desafío común en la programación
de suministro de componentes claves del proyecto. Desde el punto de vista de los recursos, el equipo
del proyecto debe recibir los suministros antes de que se necesiten, pero no con tanta antelación debido
a problemas como las limitaciones de espacio, el capital ocioso, los costos de inventario y, en algunos
casos, el deterioro. Por tanto, para equilibrar las demoras de los despachos tardíos con los costos de
mantener las entregas tempranas, un sistema de hitos bien elaborado genera una programación y un
mecanismo de coordinación que identifica las fechas claves, cuando se requieren los suministros.
13.2  Monitorear el desempeño del proyecto 437

5. Los hitos identifican momentos claves de revisión de proyectos.  En muchos proyectos complejos es
obligatorio definir una serie de revisiones de medio término. Por ejemplo, muchos de los proyectos que
se desarrollan para el gobierno de Estados Unidos requieren evaluaciones periódicas como condición
previa al contratista del proyecto para la adjudicación del contrato. Los hitos generan puntos apropia-
dos para estas revisiones. A veces, la lógica detrás de cuándo llevar a cabo esas evaluaciones se basa en
nada más que en el transcurso del tiempo (“La revisión se programa para el 1 de julio”). En otros pro-
yectos, los puntos de revisión se determinan basados en la finalización de una serie de pasos claves del
proyecto (como la evaluación de los resultados de software en los sitios de prueba).
6. Los hitos señalan cuando se espera que otros miembros del equipo comiencen su partici-
pación.  Muchas veces los proyectos requieren aportes de personal que no forman parte del equipo
del proyecto. Por ejemplo, puede necesitarse la intervención de personal externo para llevar a cabo las
pruebas de los sistemas o las inspecciones y evaluaciones de calidad del trabajo realizado hasta la fecha.
Si el supervisor de calidad no sabe cuándo asignar a una persona para nuestro proyecto, podemos
encontrar, cuando lleguemos a ese hito, que no hay nadie disponible para ayudarnos. Debido a que la
persona de control de calidad no forma parte del equipo del proyecto, tenemos que coordinar su parti-
cipación con el fin de minimizar la posibilidad de interrupción de la programación del proyecto.
7. Los hitos pueden delinear los diferentes entregables establecidos en la EDT y de ese modo permitir
que el equipo del proyecto desarrolle una mejor visión general del proyecto.  Somos, entonces, capa-
ces de reorientar los esfuerzos y recursos de función específica hacia los entregables que muestran
signos de problemas, en lugar de la simple asignación de recursos de manera general. Por ejemplo,
hay indicios de que existen problemas para lograr el hito inicial de un proyecto de programación de
software al obligar al gerente del proyecto a solicitar específicamente programadores adicionales aguas
abajo, con el fin de recuperar el tiempo, más tarde, en el desarrollo del proyecto.
La pantalla 13.1 muestra un ejemplo de un sencillo diagrama de Gantt con hitos incluidos. En este caso
los hitos, simplemente puntos arbitrarios establecidos en la gráfica, podríamos fácilmente haberlos colocado
después de completar los paquetes de trabajo o mediante el uso de algún otro criterio.

PANTALLA 13.1  Diagrama de Gantt con hitos

Problemas con los hitos


Los hitos, de una forma u otra, son, probablemente, la más simple y utilizada de todas las herramientas de control
de proyectos. Sus ventajas radican en su claridad y su facilidad con la que suelen relacionarse todos los miembros del
equipo del proyecto, con la idea de los hitos como una métrica de desempeño del proyecto. El problema con ellos es
el carácter de sistema de control de reactivo. Primero, usted debe involucrarse en las actividades del proyecto y luego
evaluarlas en relación con su meta. Si se enfrenta con un desempeño significativamente inferior para su trabajo, en
ese punto, usted debe corregir lo que ya ha ocurrido. Por ejemplo, imagine que un equipo de proyecto pierde un hito
por un amplio margen. Al no haber recibido ningún informe de progreso hasta el punto que las malas noticias se
hacen públicas, el gerente del proyecto, probablemente, no está en condiciones de elaborar una solución inmediata
438 Capítulo 13  •  Evaluación y control de proyectos

para el déficit. En este punto, se agravan los problemas. Debido al retraso en la recepción de las malas noticias, las
medidas correctivas se inician con retraso, lo cual empuja el proyecto a su finalización aún más tarde.

Diagrama de Gantt de seguimiento


Un tipo de diagrama de Gantt, conocido como diagrama de Gantt de seguimiento, sirve para evaluar el des-
empeño del proyecto en puntos específicos en el tiempo. El diagrama de Gantt de seguimiento le permite
al equipo del proyecto actualizar constantemente el estado del proyecto registrando la finalización de cada
tarea en la línea base del cronograma. Más que los costos de control o gastos del presupuesto, un diagrama de
Gantt de seguimiento identifica el grado de realización que cada tarea ha alcanzado en una fecha específica
del proyecto. Por ejemplo, la pantalla 13.2 representa el Proyecto Blue, compuesto de cinco actividades. A
medida que el proyecto avanza, su estado actual se indica mediante la barra de estado vertical que se muestra
para el jueves 10 de febrero. A la fecha, la actividad A (Acuerdo de licenciamiento) se ha completado 100%,
mientras que sus dos tareas sucesoras, Especificación del diseño y Certificación del sitio, se muestran con
progresos proporcionalmente de acuerdo con la fecha de seguimiento identificada. Es decir, la actividad de B
(Especificación del diseño) tiene 43% de avance, y la actividad C (Certificación del sitio) 60% de avance. Las
actividades D y E aún no han comenzado, en este ejemplo.
En el diagrama de Gantt de seguimiento, también es posible medir las desviaciones positivas y negativas
respecto a la línea base de cronograma del proyecto. Supongamos, usando nuestro ejemplo del Proyecto Blue,
que la actividad B sigue aproximadamente con 43% de avance, en la fecha de referencia indicada. Por otro lado,
la actividad C no ha progresado tan rápidamente y se encuentra solo con 20% completado al 10 de febrero. La
gráfica puede configurarse para identificar las variaciones, ya sean positivas o negativas, en la finalización de la
actividad contra la línea base del proyecto. Estas características se ilustran en la pantalla 13.3, en la cual se mues-
tra la fecha actual para el proyecto y el retraso en el progreso de la actividad C.

PANTALLA 13.2  Evaluación del estado del Proyecto Blue mediante el diagrama de Gantt de seguimiento

PANTALLA 13.3  Diagrama Gantt de seguimiento con desviación en una actividad del proyecto

Ventajas y desventajas de los diagramas Gantt de seguimiento


Una ventaja clave de los diagramas de Gantt de seguimiento es su fácil comprensión. La naturaleza visual
del informe de retroalimentación es fácil de asimilar e interpretar. Este gráfico de control puede actualizarse
rápidamente, lo cual proporciona una sensación de control del proyecto, en tiempo real.
13.3  Gerencia del valor ganado 439

Por otra parte, el seguimiento por medio de los diagramas de Gantt tiene algunos inconvenientes inhe-
rentes que limitan su utilidad general. El primero: a pesar de que pueden mostrar cuáles son las tareas que
avanzan antes de lo previsto, según lo previsto, y cuáles están retrasándose, estos gráficos no identifican la
fuente de los problemas en los casos de desviaciones de ejecución de las tareas. Las razones de los retrasos
en la programación no pueden deducirse de los datos presentados. El segundo: las gráficas de control del
seguimiento no permiten proyecciones del estado del proyecto. Es difícil estimar con precisión el tiempo de
terminación de un proyecto en particular, con variación positiva o negativa significativa respecto a su cro-
nograma de línea base. ¿Una serie de fines tempranos, para algunas actividades, son buenas noticias? ¿Esa
señal indica que el proyecto puede finalizar antes de lo previsto? Debido a estos inconvenientes, las gráficas de
seguimiento deben usarse junto a otras técnicas que ofrecen más seguridad prescriptiva.

13.3  GERENCIA DEL VALOR GANADO


Un método cada vez más popular, utilizado en el seguimiento y control del proyecto, consiste en un meca-
nismo conocido como gerencia del valor ganado (Earned Value Management: EVM).* Los orígenes de la
EVM se remontan a la década de 1960 cuando las agencias de contratación del gobierno de Estados Unidos
comenzaron a cuestionar la capacidad de los contratistas para rastrear con precisión sus costos a través del
ciclo de vida de varios proyectos. Como resultado, después de 1967, el Departamento de Defensa impuso el
35 Cost/Schedule Control Systems Criteria, el cual sugiere, en efecto, que los proyectos futuros por contratar
por el gobierno de Estados Unidos en los cuales el riesgo de crecimiento de los costos debía controlarse por
el gobierno, deberían satisfacer estos 35 criterios.2 Después de más de 4 años desde su origen, la EVM se ha
practicado en múltiples contextos, por agencias de gobiernos tan diversos como Australia, Canadá y Suecia,
así como por una serie de empresas basadas en proyectos, en numerosas industrias.
A diferencia de los anteriores enfoques de seguimiento del proyecto, la EVM reconoce necesario
considerar de forma conjunta el efecto del tiempo, costo y desempeño del proyecto en cualquier análisis
de la situación actual del proyecto. En otras palabras: todo sistema de seguimiento que solo compara los
valores reales de los costos con los presupuestados, ignora el hecho de que el cliente gasta ese dinero para
lograr algo: llevar a cabo un proyecto. Por tanto, la EVM reintroduce y destaca la importancia de analizar
el elemento tiempo en las actualizaciones del estado del proyecto. El tiempo es importante, ya que se con-
vierte en la base para determinar la cantidad de trabajo que debe llevarse a cabo en determinados puntos.
La EVM también le permite al equipo del proyecto hacer proyecciones futuras del estado del proyecto en
función de su estado actual. En cualquier momento del desarrollo del proyecto, está en capacidad de calcu-
lar factores de eficiencia del cronograma y del presupuesto (la eficiencia con la que el presupuesto se utiliza
en relación con el valor que se está creando) y utilizar esos valores para realizar proyecciones futuras sobre
el costo estimado y la programación para la terminación del proyecto.
Podemos ilustrar lo que representa la gerencia del valor ganado en el desarrollo del proceso de control
de proyectos, al compararla con los otros mecanismos de seguimiento del proyecto. Si tenemos en cuenta
las métricas claves de desempeño del proyecto como los criterios de éxito tratados en el capítulo 1 (crono-
grama, presupuesto y desempeño), la mayoría de los enfoques de evaluación de proyectos tienden a aislar de
la medida global de éxito, un subconjunto. Por ejemplo, el análisis de la curva S del proyecto vincula direc-
tamente los gastos del presupuesto con el cronograma del proyecto (véase la figura 13.5). Una vez más, la
desventaja obvia de este enfoque es que ignora la vinculación del desempeño del proyecto.

Costo

Curvas S
del proyecto

FIGURA 13.5  Control del avance


Desempeño Cronograma
del proyecto (análisis de la curva S)

*Tenga en cuenta que la EVM se usa de manera intercambiable con el análisis del valor ganado (earned value analysis: EVA). EVA es un
término más antiguo, aunque todavía muy en uso. La EVM se ha convertido cada vez más popular y se utiliza en muchas empresas de
orientadas a los proyectos.
440 Capítulo 13  •  Evaluación y control de proyectos

Costo

Desempeño Cronograma
Gráficas de control
FIGURA 13.6  Control del avance
(por ejemplo, diagramas de Gantt)
del proyecto (gráficas de control)

Costo

Valor
ganado
FIGURA 13.7  Control del avance
del proyecto (valor ganado) Desempeño Cronograma

Las gráficas de control de proyectos, como el diagrama de Gantt de seguimiento, vinculan el desem-
peño del proyecto con el cronograma, pero dan poca importancia a los gastos del presupuesto (véase la figura
13.6). La esencia de un enfoque de seguimiento al estado del proyecto es enfatizar el desempeño del proyecto
sobre el tiempo. Aunque el argumento podría ser que el presupuesto se asume implícitamente al gastarse de
cierta manera preconcebida, este indicador no se aplica directamente a la relación entre los factores de tiempo
y de rendimiento con el costo del proyecto.
Por otro lado, el valor ganado (Earned Value: EV) vincula directamente las tres métricas primarias
de éxito de los proyectos (costo, tiempo y desempeño). Esta metodología es muy valiosa, ya que permite la
actualización periódica del presupuesto para determinar variaciones en el costo y el cronograma, identifica-
das mediante la medición periódica de los resultados del proyecto (véase la figura 13.7).

Terminología del valor ganado


Los siguientes son algunos de los conceptos claves que nos permiten calcular el valor ganado y el uso de sus
datos en las futuras proyecciones de desempeño del proyecto.

PV Valor planeado (Planned Value: PV). Un costo estimado de los recursos presupuestados progra-
mados a lo largo del ciclo de vida del proyecto (línea base acumulada).
EV Valor ganado (Earned Value: EV). Este es el costo real presupuestado, o “valor” del trabajo que
realmente se ha efectuado hasta la fecha.
AC Costo real del trabajo desarrollado (Actual Cost of Work Performed: AC). Los costos totales
acumulados incurridos en el cumplimiento de los diversos paquetes de trabajo del proyecto.
SPI Índice de desempeño del cronograma (Schedule Performance Index: SPI). El valor ganado
hasta la fecha, dividido por el valor previsto del trabajo programado que debe realizarse (EV/PV). Este
valor nos permite calcular el cronograma previsto del proyecto hasta su terminación.
CPI Índice de desempeño del costo (Cost Performance Index: CPI). El valor ganado, dividido por el
costo real acumulado de los trabajos realizados hasta la fecha (EV/AC). Este valor nos permite calcu-
lar el presupuesto previsto para la fecha de terminación.
BAC Costo presupuestado hasta la terminación (Budget Cost at Completion: BAC). Esto representa
el presupuesto total de un proyecto.

Creación de las líneas base del proyecto


El primer paso en el desarrollo de un proceso preciso de control consiste en la creación de las líneas base del pro-
yecto contra las cuales se medirá el progreso. Las líneas base no solo son fundamentales, independientemente del
proceso de control que empleemos, sino también elementales en el desempeño de la EVM. La primera parte de la
información necesaria para calcular el valor ganado es el valor planeado(PV), es decir, la línea base del proyecto.
13.3  Gerencia del valor ganado 441

El PV debe incluir todos los costos relevantes del proyecto, de los cuales los más importante son los gastos de per-
sonal, equipo y materiales, y gastos generales del proyecto, a veces referido como el nivel de esfuerzo. Los gastos
generales (nivel de esfuerzo) pueden involucrar una variedad de costos fijos que se deben incluir en el presupuesto
del proyecto, como el apoyo técnico y administrativo, trabajo de cómputo y otros gastos de personal (como asesoría
legal o marketing). Los pasos básicos en el establecimiento de la línea base del proyecto son bastante sencillos y
requieren dos datos: la EDT y un presupuesto por fases del proyecto.
1. La estructura de desglose del trabajo identifica los paquetes individuales y las tareas necesarias para llevar
a cabo el proyecto. Como tal, la EDT nos permitió identificar primero las tareas individuales que habrían
que ejecutarse. También nos dio un poco de comprensión acerca de la jerarquía de las tareas necesarias para
configurar los paquetes de trabajo y determinar las necesidades de personal (recursos humanos), con el fin
de que coincidan los requisitos de las tareas con las personas correctas y competentes para llevarlas a cabo.
2. El presupuesto por fases del proyecto va un paso más allá de la EDT nos permite identificar la secuencia
correcta de las tareas; pero lo más importante: permite que el equipo del proyecto determine los puntos
del proyecto cuando es probable que se gaste el dinero del presupuesto en la ejecución de esas tareas
dinero. Digamos, por ejemplo, que nuestro equipo de proyecto determina que para ejecutar una activi-
dad del proyecto, Entrada de datos, será necesario un presupuesto de $20,000 y, además, se estima que
la tarea requerirá dos meses para su finalización, con la mayoría de los trabajos realizados en el primer
mes. Un presupuesto por fases para esta actividad podría ser similar al siguiente:

Actividad Enero Febrero … Diciembre Total


Entrada de datos $14,000 $6,000 -0- $20,000

Una vez recopilada la EDT y generado un presupuesto desglosado por fases, podemos crear la línea base del pro-
yecto. El resultado es un componente importante del valor ganado, ya que representa el estándar contra el cual
vamos a comparar todos los datos de desempeño, costo y programación del proyecto, a medida que tratamos de
evaluar la viabilidad de un proyecto en curso. Entonces, esta línea base representa nuestra mejor comprensión de
cómo debe progresar el proyecto. Sin embargo, ¿cómo avanza en realidad el proyecto? es otro asunto.

¿Por qué utilizar el valor ganado?


Vamos a ilustrar la relevancia de la EVM utilizando nuestro ejemplo, el Proyecto Sierra. Regresemos a la
información del proyecto, que se presenta en el cuadro 13.1, que se representa gráficamente con la curva S de
la figura 13.3. Supongamos que ahora es la semana 30 del proyecto, y estamos tratando de evaluar el estado
del proyecto. También supongamos que no hay diferencia entre los costos previstos y reales del proyecto; es
decir, el presupuesto del proyecto se está gastando de acuerdo con los plazos correctos. Sin embargo, después
de un examen, supongamos que descubrimos que solo la mitad de la instalación se ha completado y las prue-
bas del proyecto aún no han comenzado. Este ejemplo ilustra un problema con el análisis de la curva S y la
robustez de la EVM. La evaluación del estado del proyecto es relevante solo cuando se considera, además del
presupuesto y del cronograma transcurrido, alguna medida de desempeño.
Considere los datos revisados del Proyecto Sierra mostrados en el cuadro 13.2. Observe que a partir de
la semana 30, los paquetes de trabajo relacionados con el diseño y la ingeniería se han completado totalmente,

CUADRO 13.2  Porcentaje completado de las tareas del Proyecto Sierra (en miles de dólares)

Duración (en semanas)

5 10 15 20 25 30 35 40 45 % comp.
Diseño 6  2 100
Ingeniería  4  8  8  8 100
Instalación  4 20  6  50
Pruebas  2  6  4  2   0
Total 6  6  8 12 28  8  6  4  2
Acumulado 6 12 20 32 60 68 74 78 80
442 Capítulo 13  •  Evaluación y control de proyectos

mientras que de la instalación se ha realizado solo 50%, y las pruebas aún no han comenzado. Estos valores
porcentuales se han calculado basados en la evaluación del equipo del proyecto o de un individuo clave en
la situación actual de la ejecución del paquete de trabajo. La pregunta ahora es: ¿cuál es el valor ganado del
trabajo del proyecto, efectuado a la fecha? Hasta la semana 30, ¿cuál es el estado de este proyecto en términos
de presupuesto, cronograma y desempeño?
Calcular el valor ganado para estos paquetes de trabajo es un proceso relativamente sencillo. Como se
indica en el cuadro 13.3, podemos modificar el cuadro anterior para centrarnos exclusivamente en la infor-
mación relevante para la determinación del valor ganado hasta la semana 30. El presupuesto previsto para
cada paquete de trabajo se multiplica por el porcentaje completado, a fin de determinar el valor ganado hasta
la fecha, para los paquetes de trabajo, así como para el proyecto en general. En este caso, el valor ganado en la
semana 30 es $51,000.
Ahora podemos comparar el presupuesto previsto con el valor ganado real, utilizando la línea base
original del presupuesto del proyecto, que se muestra en la figura 13.8. Este proceso nos permite contar con
una estimación más realista de la situación del proyecto, al representar el valor ganado en función la línea
base del presupuesto. Compare esta cifra con el método alternativo de la figura 13.4, en el cual se calcula una
variación negativa, sin ninguna explicación de apoyo acerca de la causa o alguna indicación acerca de si esta
cifra es significativa o no. Recordemos que a finales de la semana 30, las proyecciones de presupuesto iniciales
sugirieron que se debería haber gastado $68,000. En su lugar, estamos proyectando un déficit de $17,000. En
otras palabras, estamos mostrando una variación negativa no solamente en términos de dinero gastado en el
proyecto, sino también en términos de valor ganado (desempeño) del proyecto hasta la fecha. A diferencia de
la evaluación estándar con la curva S, en la EVM la variación es significativa, ya que no se basa simplemente
en el presupuesto gastado, sino en el valor ganado. Una variación negativa de $10,000 en el presupuesto puede
ser, o no, una señal preocupante, sin embargo, un déficit de $17,000, en el valor ganado hasta la fecha, repre-
senta una variación con graves consecuencias para el proyecto.

CUADRO 13.3  Cálculo del valor ganado (en miles de dólares)

Planeado % completado Valor ganado


Diseño  8 100  8
Ingeniería 28 100 28
Instalación 30  50 15
Pruebas 14   0  0
Valor ganado acumulado 51

80
Costo acumulado (en miles de dólares)

Línea base
del proyecto
60

Valor ganado

40

20

0 5 10 15 20 25 30 35 40 45
Tiempo transcurrido (en semanas)
FIGURA 13.8  Línea base del proyecto, según el valor ganado
13.3  Gerencia del valor ganado 443

Pasos en la gerencia del valor ganado


En la gerencia del valor ganado (EVM), hay cinco pasos:
1. Definir claramente cada actividad o tarea que se va a realizar en el proyecto, incluidas sus necesi-
dades de recursos, así como un presupuesto detallado.  Como lo demostramos, la EDT les permite a
los equipos de proyecto identificar todas las tareas necesarias para ejecutar el proyecto. Además, per-
mite asignarle a cada tarea sus propios recursos, incluyidos los costos de materiales y equipos, así como
las asignaciones de personal. Finalmente, asociando los desgloses de tareas y las asignaciones de recur-
sos, es posible estimar el valor del presupuesto o del costo para cada tarea del proyecto.
2. Crear los cronogramas de uso de actividad y de recursos.  Estos identificarán el porcentaje del presu-
puesto total asignado a cada tarea en el cronograma del proyecto. Determinan cuánto del presupuesto
de una actividad se gasta cada mes (u otro periodo apropiado de tiempo) a través del ciclo de desarrollo
del proyecto. El desarrollo del presupuesto del proyecto debe realizarse en asociación directa con el cro-
nograma del proyecto. La determinación de la cantidad de dinero del presupuesto del proyecto que se
destinará a realizar las tareas es tan importante como comprender cuándo se van a emplear los recursos
durante todo el ciclo de desarrollo del proyecto.
3. Desarrollar un presupuesto “por fases”, que muestre los gastos a lo,largo de la vida del proyecto. El
monto total (acumulado) del presupuesto se convierte en la línea base del proyecto y se conoce como el
valor planeado (PV). En términos reales, el PV solo significa que podemos identificar los gastos presu-
puestarios acumulados previstos en cualquier etapa de la vida del proyecto. El PV, como un valor acumu-
lado, se deriva de la suma de los gastos presupuestarios previstos en cada periodo anterior.
4. Sumar los costos reales de hacer cada tarea para obtener el costo real del trabajo realizado (AC). También
podemos calcular los valores presupuestados para las tareas en las que está realizándose el trabajo. Esto se
conoce como el valor ganado (EV) y es el término que dio origen a este proceso de control.
5. Calcular las variaciones de presupuesto y de los cronograma, mientras el proyecto aún se encuentra
en marcha.  Una vez recopilado los tres datos clave (PV, EV y AC), es posible realizar estos cálculos.
La variación del cronograma se calcula mediante una ecuación simple: SV = EV - PV, o la diferencia
entre el valor ganado a la fecha menos el valor planeado del trabajo programado para desarrollarse a la
fecha. La variación de presupuesto, o de costo, se calcula como CV = EV - AC, o el valor ganado menos
el costo real del trabajo realizado
Un modelo simplificado que se ajusta a las tres partes principales de valor ganado (PV, EV y AC) se
muestra en la figura 13.9. La línea base original, compuesta del cronograma y del presupuesto para todas las
tareas del proyecto, se indica en el círculo en la parte inferior izquierda del gráfico como PV. Cualquier des-
viación del cronograma respecto al PV original se atribuye al EV y comprende el valor ganado del proyecto.
Finalmente, utilizando las cifras del valor ganado, que se basan en una evaluación del grado en que se han
completado las tareas del proyecto, podemos crear la AC del proyecto. Ahora tenemos otro vínculo directo de
la diferencia entre los gastos presupuestados y reales de las actividades del proyecto.

AC
Actual

Sobrecosto
Costo
PV EV
Presupuesto

Desfase

Planeado Realizado
Cronograma

FIGURA 13.9  Hitos del valor ganado


444 Capítulo 13  •  Evaluación y control de proyectos

Evaluación del valor ganado del proyecto


El cuadro 13.4 presenta los primeros componentes de un análisis del valor ganado para el Proyecto Mercury.3
Este proyecto tiene una duración prevista de siete meses y un presupuesto de $118,000. El proyecto se inició en
enero y estamos interesados en calcular su valor ganado para finales de junio. Por razones de simplicidad, los
paquetes de trabajo totales para este proyecto son solo siete en número. Si sabemos la cantidad presupuestada
para cada paquete de trabajo y cuándo está programado el trabajo por hacer, podemos construir un cuadro
de presupuesto similar al que se muestra en el cuadro 13.4. Observe que cada paquete de trabajo tiene un pre-
supuesto fijo a través de una serie de periodos (por ejemplo, el personal se ha presupuestado con un costo de
$15,000 y se va a realizar casi por igual entre los meses de enero y febrero, mientras que para los planos comien-
zan en marzo, con $4,000 presupuestados y se concluye en abril con $6,000).
Si graficamos los gastos en cada mes transcurrido del proyecto, hasta la fecha (enero a junio), podemos
determinar la cantidad presupuestada y, mediante la recopilación de información del equipo del proyecto y del
contador, el monto real gastado cada mes. Estas cifras se añaden a las cuatro filas inferiores del cuadro. Por ejem-
plo, observamos que, en marzo, habíamos planeado gastar $21,000 en las actividades hasta la fecha, según el
presupuesto del proyecto. Y nuestros costos acumulados reales fueron $27,000. La pregunta obvia es: ¿esto es una
buena o una mala noticia? A primera vista, podríamos concluir que es una mala noticia porque hemos sobre-
pasado nuestro presupuesto. Sin embargo, hay que recordar que el principal problema con la metodología de la
curva S es que solo tiene en cuenta los costos reales en comparación con los costos previstos. Simplemente, esta
no es información suficiente para efectuar una determinación real de la situación del proyecto.
Las piezas claves de información que nos permiten identificar el valor ganado se incluyen en las columnas
de la derecha. Estamos muy interesados en determinar el estado actual del proyecto en función del número de
tareas completadas en el tiempo presupuestado para ello. Por consiguiente, las últimas columnas muestran los
gastos previstos para cada tarea, el porcentaje de las tareas realizadas y el valor ganado. En este sentido, el valor
no es más que el producto entre los gastos previstos y el porcentaje completado de estas tareas. Por ejemplo, para
el paquete de trabajo planos, a esta actividad se le asignó un presupuesto de $10,000 en total, para dos meses. A
la fecha, 80% de la actividad se ha completado, lo que resulta en un valor de $8,000. Si sumamos las columnas
correspondientes a los gastos previstos y valor real (EV), nos encontramos con nuestro presupuesto previsto
($118,000) y el valor realizado a finales de junio ($44,000).
Ahora tenemos suficiente información para tomar una decisión razonable sobre el estado del proyecto, apli-
cando la gerencia del valor ganado. El primer número que necesitamos es el valor planeado (PV). Este valor se puede
encontrar en los costos previstos acumulados al final del mes de junio ($103,000). También hemos calculado que
el valor ganado (EV) para el proyecto hasta la fecha asciende a $44,000. Las variaciones de cronograma de interés

CUADRO 13.4  Cuadro de valor ganado (a finales de junio) con $6,000 para el Proyecto Mercury (en
miles de dólares)

Actividad Enero Febrero Marzo Abril Mayo Junio Julio Planeado % comp. Valor
Contratación 8 7  15 100 15
de personal
Planos  4  6  10  80  8
Desarrollo de  2  8  10  60  6
prototipo
Diseño  3  8  10  21  33  7
completo
Construcción  2  30  32  25  8
Transferencia  10  10   0  0
Lista de  15   5  20   0  0
verificación
= 118 44
Plan mensual 8  7  6 17 10  55  15
Acumulado 8 15 21 38 48 103 118
Mensual real 8 11  8 11 10  30   0
Acumulado real 8 19 27 38 48 78
13.3  Gerencia del valor ganado 445

CUADRO 13.5  Variación de cronograma para la EVM del Proyecto Mercury

Variación de cronograma
Valor planeado (PV) 103
Valor ganado (EV) 44
Índice de desempeño del cronograma EV/PV = 44/103 = .43
Tiempo estimado de terminación (1/.43  7) = 16.3 meses

para nosotros son el índice de desempeño del cronograma (SPI) y el tiempo estimado para la terminación. El SPI
se determina dividiendo el EV entre el PV. El cuadro 13.5 muestra este cálculo (54,000/103.000 = .43). Con el SPI,
ahora podemos proyectar la cantidad de tiempo para completar el proyecto. Debido a que el SPI nos indica que
estamos operando a solo 43% de eficiencia en la ejecución del proyecto, tomamos el recíproco del SPI, multiplicado
por el cronograma original del proyecto para determinar el marco temporal real proyectado para la terminación del
proyecto (1/.43  7 = 16.3 meses). La mala noticia es: a partir de junio, no podemos esperar 10 meses para completar
este proyecto; estaríamos incurriendo en un retraso de más de nueve meses.
¿Qué hay de los costos? Aunque nos estamos quedando con más de nueve meses de retraso, ¿podemos
hacer proyecciones similares sobre el proyecto en términos de cuánto se prevé que finalmente costará? La
respuesta, según la EVM, es sí. Así como podemos determinar las variaciones de cronograma, también pode-
mos calcular las variaciones de costos, siempre y cuando tengamos dos piezas muy importantes de los datos:
el costo real del trabajo realizado (AC) acumulado y el valor ganado (EV). La cifra del valor ganado ya se ha
calculado ($44,000) y ahora volvemos al cuadro 13.4 para ubicar el AC. El costo real acumulado, a finales de
junio, es $78,000. Esta cifra es nuestro AC y se agrega al cuadro 13.6.

CUADRO 13.6  Variaciones de costo para la EVM del Proyecto Mercury

Variación de costos
Costo real del trabajo realizado (AC) acumulado 78
Valor ganado (EV) 44
Índice de desempeño del costo EV/AC = 44/78 = .56
Costo estimado de terminación acumulado (1/.56  $118,000) = $210,714

De la misma manera que se calculó la variación del cronograma, se calcula la variación de costos divi-
diendo el EV entre AC, o $44,000 / $78,000 = .56. Ese es el índice de desempeño del costo (CPI) para este
proyecto. La determinación del costo proyectado hasta completar el proyecto consiste en tomar el recíproco del
CPI, multiplicado por el presupuesto original del proyecto ($118,000). La mala noticia es la siguiente: este pro-
yecto no solamente se encuentra retrasado, sino que también se prevé que termine costando más de $210,000,
un sobrecosto significativo.
Finalmente, podemos representar gráficamente estos valores de variación, mostrando la diferencia
entre el EV (valor ganado), el PV y el AC (véase la figura 13.10). El resultado de este ejemplo es interesante
porque sugiere que las curvas S, a veces, pueden ser engañosas. Por ejemplo, en este caso, al final de junio
hemos descubierto una diferencia de $25,000 entre el AC ($78,000) y el PV ($103,000). Aunque el análisis en
ese momento demostró que habíamos gastado un poco menos de lo presupuestado, en realidad los resultados
fueron más graves cuando se analizaron desde la perspectiva del valor ganado, a finales de junio ($44,000).
En realidad, las variaciones de cronograma y de costos fueron más graves debido al lag en el valor ganado
del proyecto, según los cálculos del porcentaje de terminación de todas las tareas programadas. Este ejemplo
muestra claramente las ventajas del valor ganado para determinar con mayor precisión el estado real del pro-
yecto en función de sus tres componentes: tiempo, presupuesto y alcance.
También podemos aplicar la gerencia del valor ganado con MS Project 2010. Supongamos que quere-
mos realizar un seguimiento del Proyecto Atlas, que se muestra en la pantalla 13.4. Observe que a partir del 7
de marzo, el proyecto comienza a mostrar algunos signos de retraso. En este punto, deberíamos haber com-
pletado cuatro de los seis paquetes de trabajo, y sin embargo las pruebas, bajo la responsabilidad de Stewart,
apenas está en curso. Desde la perspectiva de la supervisión y el control, la pregunta que queremos responder
es: ¿cómo la EVM refleja los posibles retrasos en nuestro proyecto?
446 Capítulo 13  •  Evaluación y control de proyectos

PV
100

90

Presupuesto (en miles de dólares)


80 AC

70

60

50
EV
40

30
deslizamiento
20

10

0
Abril Mayo Junio

FIGURA 13.10  Variaciones de valor ganado en el Proyecto Mercury

PANTALLA 13.4  Ejemplo de diagrama de Gantt para el Proyecto Atlas que muestra su estado al 7 de marzo

Supongamos que, además de actualizar regularmente la línea base del cronograma, hemos controlado
los costos asociados a cada uno de los paquetes de trabajo y, como lo muestra la pantalla 13.5, hemos gastado
todo el dinero presupuestado asignado a los paquetes de trabajo de diseño, ingeniería y calificación de pro-
veedores. Solo hemos gastado $520 del presupuesto de pruebas. Estos son los valores de los costos reales (AC)
de esas actividades. Ahora tenemos suficiente información actualizada para determinar el valor ganado en el
Proyecto Atlas al 7 de marzo.

PANTALLA 13.5  Ejemplo del reporte de costos para el Proyecto Atlas al 7 de marzo
13.4  Aplicación del valor ganado a la gerencia del portafolio de proyectos 447

La pantalla 13.6 muestra un ejemplo de un informe de valor ganado, generado por MS Project
2010 para nuestro Proyecto Atlas.* Además de proporcionar las métricas claves PV, EV y AC (véase la
nota de pie de página), el informe genera las variaciones de cronograma y de costos. La variación del
cronograma (schedule variance: SV) es simplemente la diferencia entre el valor ganado y el Valor pla-
neado, mientras que la variación de costos (cost variance: CV) es la diferencia entre el valor ganado y
el costo real. La columna estimación hasta la terminación (estimate at completion: EAC) muestra el
costo total previsto del proyecto hasta su terminación, en función del rendimiento en las distintas tareas
a la fecha de revisión. Observe que en el Proyecto Atlas, actualmente, están presentándose variaciones
de cronograma y de costos, lo cual sugiere que nuestro proyecto está por encima del presupuesto y reta-
sado. De hecho, la EAC demuestra que a partir del 7 de marzo, se espera que este proyecto cueste $9,480
hasta su terminación.

PANTALLA 13.6  Reporte del valor ganado en el Proyecto Atlas al 7 de marzo

13.4  APLICACIÓN DEL VALOR GANADO A LA GERENCIA DEL PORTAFOLIO DE


PROYECTOS
La gerencia del valor ganado puede funcionar tanto a nivel del portafolio como de los proyectos individuales. El
proceso consiste simplemente en la agregación de todas las medidas del valor ganado en todo el portafolio de
proyectos de la empresa, con el fin de proveer una medida en cuanto a la eficiencia con la que una empresa rea-
liza la gerencia de sus proyectos. El cuadro 13.7 proporciona un ejemplo de control de gerencia del valor ganado
a nivel de portafolio que identifica las variaciones positivas y negativas, de costos y de cronograma y con base en
estas evaluaciones, se proyecta el costo de la terminación de cada proyecto en curso.4

CUADRO 13.7  Valor ganado de un portafolio de proyectos (en miles de dólares)

Estimación
Variación de Variación de Variación hasta la
Proyecto PV EV tiempo ($) Variación AC costos ($) + Plan terminación
Alfa  91  73 -18 18  83 -10 10 254 289
Beta 130 135   5  0 125  10  0 302 280
Gama  65  60   -5  5  75 -15 15 127 159
Delta  25  23   -2  2  27   -4  4  48  56
Épsilon  84  82   -2  2  81   1  0 180 178
395 373 391 962
Variación total del cronograma 27          Variación total de costos 29
Variación relativa en el cronograma= 27/395 = 6.84%   Variación relativa de costos=29/395 = 7.34%

*MS Project 2010 utiliza los términos BCWS (Budget Cost of Work Schedule: costo presupuestado del trabajo programado) para el valor
planeado (PV), BCWP (Budget Cost of Work Performed: costo presupuestado del trabajo realizado) para el valor ganado (EV), y ACWP
(Actual Cost of Work Performed: costo real del trabajo realizado) para el costo real (AC). MS Project 2010 emplea términos actualizados
por el PMBoK del Project Management Institute.
448 Capítulo 13  •  Evaluación y control de proyectos

Otra información útil contenida en el cuadro de gerencia del valor ganado para el portafolio incluye
las variaciones totales positivas para el presupuesto y para el calendario, así como un cálculo de las variacio-
nes relativas de cronograma y de costos como un porcentaje del portafolio total de proyectos. En el ejemplo
que se muestra en el cuadro 13.7, la empresa está experimentando, en sus proyectos, variaciones promedio
de costo y de cronograma de 7.34% y 6.84%, respectivamente. La utilización de la gerencia del valor ganado
para el seguimiento y control del portafolio provee a la alta gerencia una excelente herramienta para verificar
la capacidad de la empresa para ejecutar de manera eficiente sus proyectos, permite realizar comparaciones
entre todos los proyectos en desarrollo y saca a flote las variaciones positivas y negativas que se producen.
Todo esto es información útil para la gerencia de nivel superior de proyectos múltiples.

PERFIL DE PROYECTO

Valor ganado en Northrop Grumman


“Llega el momento de disparar a los ingenieros y seguir adelante con la producción.” Esta frase, de uso común en
empresas de la industria de defensa, se refiere a la tendencia de los ingenieros a mejorar continuamente pero nunca
completar un proyecto. La inclinación por “retoques” continuos tiene enormes implicaciones para las empresas que
viven o mueren por su capacidad para poner en práctica de manera eficaz y eficiente sus proyectos. El tipo de trabajo
que realizan los contratistas de defensa complica aún más el problema. Hay requisitos del gobierno que estas empre-
sas deben cumplir, relacionadas con costos y pruebas de control de calidad, durante el ciclo de desarrollo de los
proyectos. En un esfuerzo por recuperar el control del proceso de desarrollo del proyecto, el contratista de defensa
Northrop Grumman, desde hace varios años, se ha comprometido con el uso de la gerencia del valor ganado.
Northrop Grumman, uno de los principales contratistas de defensa del mundo (véase la figura 13.11), ha
utilizado la gerencia del valor ganado como un componente clave de su enfoque para un mejor seguimiento y
control de sus proyectos. Debido a los numerosos proyectos que la División de Sistemas de Defensa de la compa-
ñía emprende rutinariamente, su presupuesto operativo anual de proyectos es de miles de millones de dólares.
Con docenas de proyectos en curso en cualquier momento y enormes compromisos de capital para soportar sus
actividades, es inevitable que la corporación desarrolle y mantenga un sistema de control de proyectos, lo más
sofisticado posible.
Northrop Grumman ha seleccionado la gerencia del valor ganado como su principal herramienta de control
de proyectos, por las siguientes razones:

1. La EVM desarrolla un plan integral de línea base para el alcance programado a lo largo de toda su duración.
2. El sistema incorpora herramientas para medir el rendimiento en el trabajo, con base en criterios objetivos.
3. La EVM analiza y pronostica el efecto de las variaciones más importantes sobre el plan.
4. Produce información para la toma de decisiones en los niveles ascendentes de la gerencia.
5. La EVM ofrece planes para implementar acciones correctivas cuando se presentan desviaciones respecto al
plan previsto.
6. Todas las partes involucradas en el plan acuerdan y documentan todos los cambios.
La empresa ha desarrollado un enfoque de cuatro niveles en el control de proyectos, utilizando la EVM. Todos los
proyectos se clasifican en una de las siguientes categorías, según un método individualizado para la implementa-
ción de la EVM:
El nivel uno es el más exigente, puesto que se compone de proyectos que requieren la mayor parte de las
funciones del sistema para controlarse. Se emplea cuando un contrato necesita que se genere y se reporte una
gran cantidad de información detallada, para su control.
El nivel dos es similar al uno, excepto que estos contratos requieren un estricto control de gerencia, debido a
que el proyecto es arriesgado y tiene una carga más pesada para cumplir los objetivos de margen de beneficio.
El nivel tres se aplica a programas de tamaño significativo que son maduros y funcionan sin problemas.
El nivel cuatro aplica las ventajas del valor ganado a proyectos con bajos costos administrativos.
Una vez determinado el nivel de complejidad (el nivel en el que se clasifica el proyecto), Northrop Grumman
aplica la EVM a sus contratos considerando seis criterios:
1. Requerimientos del contrato
2. Riesgo del programa
3. Tipo de incentivos contractuales (continúa)
13.5  Problemas del uso efectivo de la gerencia del valor ganado 449

PJF News / Alamy


FIGURA 13.11  El F-35 Joint Strike Fighter de Northrop Grumman

4. Grado de desarrollo y producción implicado en el programa


5. Visibilidad del programa
6. Requerimientos de reportes de los clientes
Dependiendo de cómo se aplican las consideraciones, la EVM desarrollada diferencialmente se adapta al tipo
de proyecto en el que la empresa está trabajando.
En Northrop Grumman, la EVM no es simplemente una opción, sino un mandato corporativo. El enfoque de
cuatro niveles ayuda a la empresa a adaptar el sistema a cada nuevo proyecto con el fin de aplicarlo correctamente
y buscar el beneficio máximo, el control de costos y la rentabilidad corporativa.5

13.5  PROBLEMAS DEL USO EFECTIVO DE LA GERENCIA DEL VALOR GANADO


Al igual que con cualquier otra métrica que nos ayude a entender la situación “real” de un proyecto en curso, la
clave para el uso efectivo de la EVM consiste en proporcionar información actualizada y precisa sobre el proyecto,
en particular en cuanto al porcentaje completado de los paquetes de trabajo. Debido a que esta información es clave
para determinar el valor ganado en cualquier punto del tiempo, el EV calculado es tan preciso como miembros del
equipo de proyecto y gerentes permitan, mediante el desarrollo y aplicación de un sistema de información honesto.
En nuestro ejemplo, el Proyecto Mercury mostrado anteriormente (véase el cuadro 13.4), la columna de
porcentaje completado contiene valores de porcentaje que van de 100, 80, 60, 33, 25, a cero. En realidad, las
organizaciones a menudo adoptan una regla de decisión más simple para asignar los porcentajes ejecución.
Entre los métodos más comunes para la asignación de estos valores, se manejan los siguientes:
1. Regla 0/100 —El método más simple y tal vez menos eficaz consiste en asignar un valor de cero (0)
hasta cuando la actividad se termina, momento en el cual el valor cambia a 100%. Esta regla funciona
mejor para paquetes de trabajo con duraciones muy cortas, como un día o dos, pero no es útil para
paquetes de trabajo más largos, debido a que proporciona poca información en tiempo real. También
es útil en paquetes de trabajo que requieren entregas de proveedores o que dependen de que los inte-
resados externos realicen algún trabajo. Por ejemplo, contamos con un paquete de trabajo como “com-
pleto” cuando el proveedor entrega un componente necesario.
2. Regla 50/50 —Según esta regla de decisión, una actividad que se ha iniciado automáticamente recibe
una valoración de 50% completada. Ese valor permanece ligado al paquete de trabajo hasta que se haya
completado la actividad, y en ese momento se convierte en 100%. Al igual que la regla 0/100 anterior,
este modelo de decisión se utiliza en paquetes de trabajo de muy corta duración.
450 Capítulo 13  •  Evaluación y control de proyectos

3. Regla del porcentaje de avance —Con la regla del porcentaje de avance, el gerente del proyecto y los
miembros del equipo acuerdan una serie de hitos de finalización, ya sea basados en cuartos (25%,
50%, 75%, 100%), terceras partes (33%, 67%, 100%), o algunos otros valores. Luego, de forma regular,
se actualiza el estado de cada paquete de trabajo en proceso. Puede o no asignarse, un nuevo valor de
avance para el paquete, y entonces la EVM del proyecto se actualiza con base en esta nueva informa-
ción. Como se señaló, la clave para que funcione el proceso radica en la evaluación honesta de la situa-
ción de las actividades en curso, no se basa en el tiempo transcurrido o el presupuesto gastado, sino en
el porcentaje real de avance de la actividad.

Una advertencia importante con la regla del porcentaje de avance tiene que ver con la controversia en torno
al nivel de detalle que se utilizará en el cálculo de valor de la tarea. Los críticos del valor ganado argumentan
que, a menos que los gradientes de terminación sean razonables, reconocidos y utilizados por todas las partes,
existe un alto potencial de creación de información engañosa en el análisis del valor ganado. Por ejemplo, una
de las críticas contra La EVM sostiene que los niveles excesivos de detalle son peligrosos y, esencialmente,
no interpretables. Por ejemplo, supongamos que un proyecto utiliza los valores de avance basados en incre-
mentos de 10% (es decir, 10%, 20%, 30%, etc.) En la práctica, es imposible diferenciar con éxito entre, por
ejemplo, 30% y 40% de avance para la mayoría de las actividades del proyecto, por lo que es más probable
confundir que aclarar la verdadera situación de un proyecto, con el uso de demasiados detalles.
La principal excepción a esta dificultad con la regla del porcentaje de avance del proyecto ocurre en
proyectos en los que el proceso de desarrollo se encuentra bien delimitado y existe un alto grado de cono-
cimiento previo, o en situaciones en las que es fácil medir con precisión la cantidad de trabajo realizado en
cualquier tarea del proyecto. En un proyecto de construcción simple, por ejemplo, donde los pasos del pro-
yecto son bien conocidos con anterioridad y seguidos rigurosamente, se puede emplear un mayor nivel de
detalle. Del mismo modo, en el desarrollo de software, donde la tarea consiste en la escritura de código, un
programador sénior puede tener un excelente sentido del número total de líneas de código necesarias para
completar la tarea. Por consiguiente, si la tarea total requiere aproximadamente 5,000 líneas de código y un
programador completa 500 líneas del programa, sería razonable asignar un porcentaje de 10% de avance de
las necesidades totales de la ejecución de la tarea.
La importancia de establecer un nivel razonable en el cumplimiento del proyecto no se puede exagerar.
En ausencia de un conjunto claro de directrices para la identificación de los puntos de corte y del nivel de
detalle adecuado, es posible derivar conclusiones muy diferentes con la misma información del proyecto. Por
ejemplo, vamos a revisar el problema anterior de la EVM que se muestra en el cuadro 13.4. Esta vez, vamos a
utilizar dos reglas de decisión en cuanto a los niveles de detalle de las actividades del proyecto para calcular el
EV. En el primer ejemplo, mostrado en el cuadro 13.8, la columna 1 contiene los cálculos originales, basados
en el primer conjunto de valores porcentuales de avance del cuadro 13.4. En la columna 2, se emplea una regla
de decisión simple basada en tres incrementos (0%, 50% y 100% de avance). La columna 3 muestra un nivel
ligeramente más detallado, empleando niveles de 0%, 25%, 50%, 75% y 100% de avance. Se han redondeado
los valores originales de porcentaje de terminación (que se muestran en la columna 1) a los equivalentes más
cercanos en las otras dos alternativas.
Observe lo que ocurre como resultado del uso de niveles alternativos de detalle. Redondeando el nivel
de terminación a valores simplificados de 0%, 50%, 100%, los resultados obtenidos son significativamente
diferentes, tanto para la proyección del proyecto como para las desviaciones de cronograma y de costos des-
viaciones. Con el retraso original se proyecta una nueva terminación de 16.28 meses, la cual ha sido mejorada
a 12.73 meses, con un retraso de solo 5.73 meses. Del mismo modo, la proyección original del presupuesto del
valor ganado del proyecto ($210,714) se ha reducido a $163,889, con un ahorro de $46,825, debido simple-
mente a la adopción de un nivel alternativo de detalle en el avance de las actividades del proyecto. De manera
similar, utilizando el nivel de detalle con un poco más de gradientes (0%, 25%, 50%, 75% y 100%), que se
muestran en la columna 3, y redondeando los valores originales para coincidir estrechamente con esta alter-
nativa, se descubre que las proyecciones para el proyecto, desarrolladas por medio del SPI y del CPI, son más
negativas que las originales. Se pronostica un nuevo cronograma para el proyecto que puede durar 17.5 meses
y el presupuesto del proyecto se ha incrementado a $226,923, o $16,209 más que nuestra primera proyección.
Aún más, la diferencia absoluta entre las proyecciones presupuestarias es de más de $63,000, todo porque se
pasa de un nivel de tres puntos de detalle (columna 2) a uno basado en cinco niveles de avance (columna 3).
¿Un enfoque es “más correcto” que el otro? A falta de alguna regla de decisión o de una lógica para tomar
estas determinaciones, es virtualmente imposible sugerir que un nivel de detalle sea más representativo de la
situación “real” de la finalización de cada actividad del proyecto.
13.6  Factores humanos en la evaluación y el control de proyectos 451

CUADRO 13.8  Cálculo del valor ganado del Proyecto Mercury basado en niveles de detalle alternativos (en miles de
dólares)

Col. 1 Col. 2 Col. 3


(Original) (0, 50, 100%) (0, 25, 50, 75, 100%)

Valor % % %
Actividad planeado completado Valor completado Valor completado Valor
Contratación de personal 15 100 15 100 15 100 15
Planos 10  80  8 100 10  75 7.5
Desarrollo de prototipo 10  60  6  50 5  50 5
Diseño completo 21  33  7  50 10.5  25 5.25
Construcción 32  25  8  50 16  25 8
Transferencia 10   0  0   0 0   0 0
Lista de verificación 20   0  0   0 0   0 0
Total EV = 44 56.5 40.75
SPI y proyección de terminación 44/103 = .43 56.5/103 = .55 40.75/103 = .40
(1/.43  7) = 16.28 (1/.55  7) = 12.73 (1/.40  7) = 17.5
meses meses meses
CPI y proyección de terminación 44/78 = .56 56.5/78 = .72 40.75/78 = .52
$210,714 $163,889 $226,923

Como se ha señalado en este capítulo, la gerencia de valor ganado no es una metodología impecable
para el seguimiento y control de proyectos, en particular respecto a los problemas para determinar con pre-
cisión el porcentaje de avance de los paquetes de trabajo en cualquier momento durante el desarrollo del
proyecto. Sin embargo, la EVM representa un importante paso hacia adelante, al permitirles a los gerentes
de proyectos y sus equipos obtener una mejor perspectiva de la “verdadera” naturaleza de la condición a
medio camino de un proyecto, es decir, en el medio del proceso de desarrollo e implementación.6 Este tipo de
datos en tiempo real puede ser muy valioso para obtener información actualizada del estado del proyecto y
para desarrollar planes realistas a fin de corregir cualquier problema sistemático en el proceso de desarrollo.
Cuanto más aprendemos, y más rápido, sobre el estado de un proyecto, mejor equipados estaremos para dar
pasos medidos y eficaces orientados a conseguir que un proyecto con problemas retome su curso.

13.6  FACTORES HUMANOS EN LA EVALUACIÓN Y EL CONTROL DE PROYECTOS


Otro problema recurrente con la obtención de resultados precisos o significativos con la EVM tiene que ver
con la necesidad de reconocer el factor humano en todas las proyecciones de finalización de las actividades del
proyecto. Es decir, en la mayoría de organizaciones, de parte de los miembros del equipo del proyecto existe una
fuerte tendencia a informar continuamente resultados más positivos o a enviar señales correctas sobre el estado
del proyecto, que puede justificarse en su interés por verse bien ante el jefe, o, peor aún, muchas veces implícita o
explícitamente puede provenir de los propios gerentes de proyectos, ya que estos se encuentran bajo presión de
la alta gerencia y de mostrar resultados estables. Por tanto, la controversia no solo se centra en determinar con
precisión el mejor indicador de rendimiento técnico del proyecto o el número de gradientes. Con frecuencia,
el comportamiento humano también es un problema arraigado, lo cual sugiere que niveles de detalle excesiva-
mente finos, no solamente pueden ser inapropiados para varios tipos de actividades de los proyectos que acome-
temos, sino que también pueden estar propensos a un mal uso por el equipo del proyecto.
La característica común de los enfoques de control de proyectos es su dependencia de datos cuantifi-
cables basados en los resultados del proyecto, es decir, los resultados de las acciones del proyecto, tomadas en
cualquier periodo, se recopilan y reportan después de los hechos. Por tanto, determinamos las variaciones del
cronograma y de los costos después de recopilar y reportar los datos. Sin embargo, algunos escritores de gerencia
de proyectos han sugerido que es igualmente esencial mantener un claro entendimiento de la importancia de la
gerencia de las personas en la ejecución del proyecto. En otras palabras, la información recopilada según las dife-
rentes técnicas de evaluación y control representan las medidas de resultado importantes para el proyecto, sin
452 Capítulo 13  •  Evaluación y control de proyectos

embargo, el control integral del proyecto también requiere que la organización del proyecto emplee suficientes
procesos de evaluación, para determinar cómo está progresando la ejecución del proyecto.
Un componente clave de cualquier proceso de evaluación del desempeño del proyecto debe incluir
una evaluación de su personal, sus habilidades técnicas, de gerencia, de trabajo en equipo, de los procesos de
comunicación, motivación, liderazgo, etc.7 En resumen, muchas de las técnicas de evaluación y de control
(como la EVM) proveen un excelente trabajo al responder a los “Cuáles” (¿cuál es el estado de avance del pro-
yecto? , ¿cuál es su factor de eficiencia de costos? y ¿cuáles tareas se ejecutan actualmente con retraso?), pero
ellos no tratan de responder los “porqués” (¿por qué las actividades están retrasadas? y ¿por qué el equipo de
proyecto está trabajando a un nivel sub óptimo?). En un esfuerzo por dar respuesta a los “porqués”, se ha ini-
ciado y continuará haciéndose, en la gerencia de proyectos, un trabajo sobre los procesos humanos.
Investigaciones anteriores relacionadas con el efecto de los factores humanos en el éxito de los proyec-
tos confirman la importancia de considerar una “gerencia” más amplia inherente a la gerencia de proyectos.
Por ejemplo, los primeros trabajos de Baker y otros8 identificaron una serie de factores que predicen directa-
mente el éxito del proyecto. Se incluyen en su lista aspectos como:
• La coordinación y las relaciones entre las partes interesadas del proyecto
• La adecuación de la estructura y el control del proyecto
• La singularidad, importancia y exposición pública del proyecto
• Los criterios de éxito, relevancia y consenso
• La falta de presión presupuestaria
• Evitar el exceso de optimismo inicial y las dificultades conceptuales
Sus hallazgos confirman la importancia de tener un claro conocimiento de los principales problemas de
gerencia que intervienen al ejecutar los proyectos. Estos hallazgos se han reforzado con otras investigaciones
que han examinado un conjunto de proyectos exitosos y no exitosos a lo largo de sus ciclos de vida.9
Las conclusiones de esa investigación son interesantes por la importancia que les dan a los aspectos de la geren-
cia y del comportamiento humano en la gerencia exitosa de proyectos. Como lo indica el cuadro 13.9, independien-
temente de si el proyecto de estudio fue un éxito o un fracaso, los factores de mayor importancia demuestran algunas
similitudes claras. Aspectos como el liderazgo, apoyo de la alta gerencia, motivación del personal y soporte al cliente
se asociaron consistentemente con el éxito del proyecto, lo cual sugiere una vez más que la comprensión del proceso
de gerencia de proyectos es profundamente importante para determinar la probabilidad de éxito de un proyecto.

CUADRO 13.9  Principales conductores e inhibidores del éxito

Factores de éxito de los Factores de fracaso de los


Estado proyectos Estado proyectos
Formación Ambiciones personales Formación Desmotivación del equipo
Apoyo de la alta gerencia Liderazgo pobre
Motivación del equipo Limitaciones técnicas
Objetivos claros Problemas de financiación
Ventaja tecnológica
Crecimiento Motivación del equipo Crecimiento Desmotivación del equipo
Motivación personal Conflicto en los objetivos
Apoyo de la alta gerencia Problemas de liderazgo
Especialización técnica Poco apoyo de la alta gerencia
Problemas técnicos
Fase principal Motivación del equipo Fase principal Desmotivación del equipo
Motivación personal Poco apoyo de la alta gerencia
Atención al cliente Procedimientos deficientes
Apoyo de la alta gerencia
Liquidación Motivación personal Liquidación Poco control
Motivación del equipo Poco apoyo financiero
Apoyo de la alta gerencia Objetivos poco claros
Apoyo financiero Problemas de liderazgo
13.6  Factores humanos en la evaluación y el control de proyectos 453

Sin embargo, uno de los problemas recurrentes claves, con la generalización del uso de información no
técnica como método para el control de proyectos y la evaluación de su estado de avance, se relaciona con
la medición. Aunque los datos financieros y de programación pueden recopilarse fácilmente y son relativa-
mente fáciles de interpretar, medir los procesos humanos, como el nivel de motivación, liderazgo, apoyo de
la dirección, etc., es muy complicado. Como resultado, y a pesar de que un número de teóricos de la gerencia
de proyectos han aceptado el argumento a favor de la inclusión de los factores humanos en el proceso de
evaluación del estado de avance de los proyectos, hay poco acuerdo en cuanto a la mejor manera de hacer
esas evaluaciones, la interpretación de sus resultados y el uso los hallazgos de una manera prescriptiva para
mejorar los procesos del proyecto.
La investigación de Pinto y Slevin10 aborda las deficiencias de las evaluaciones de comportamiento en
los procesos de gerencia de proyectos. Ellos formularon la implementación del perfil del proyecto (project
implementation profile: PIP), un instrumento de 10 factores que evalúa el desempeño del equipo del proyecto
en relación con 10 factores claves de éxito, es decir, aquellos factores que resultaron ser predictivos del éxito
del proyecto. La ventaja del PIP es que les permite a los equipos de proyecto evaluar formalmente su desem-
peño en el proyecto en curso, con lo cual se pueden llevar a cabo correcciones de medio término y mejoras en
el proceso de gerencia. Los 10 factores claves de éxito representan una importante fuente adicional de infor-
mación sobre el estado del proyecto. Junto a otra información de evaluación y control suministrada a través
del seguimiento de las variaciones de cronograma y de costos respecto a la línea base del proyecto, los equipos
de proyecto pueden tener una visión integral del estado del proyecto durante todo su desarrollo.

Definición de los factores claves de éxito


Los 10 factores claves de éxito identificados por Pinto y Slevin en la formulación del instrumento PIP son:
(1) la misión del proyecto; (2) el apoyo de la alta gerencia; (3) la planeación y programación del proyecto; (4)
la consulta al cliente; (5 ) el personal; (6) las tareas técnicas; (7) la aceptación del cliente; (8) el monitoreo y
retroalimentación; (9) la comunicación; y (10) la solución de problemas. A continuación, se analizan estos
factores en detalle.
Misión del proyecto, el primer factor, se refiere a la finalidad subyacente del proyecto. El éxito del pro-
yecto se basa en la importancia de definir claramente sus objetivos, así como los beneficios finales que se
derivan del proyecto. Muchas veces, la primera etapa de la gerencia de proyectos consiste en una decisión
de viabilidad. ¿Los objetivos son claros y alcanzables? La misión del proyecto se refiere a la condición en la
cual los objetivos del proyecto son claros y entendidos, no solo por el equipo del proyecto en cuestión, sino
también por los otros departamentos de la organización. El gerente del proyecto debe ocuparse de aclarar
los objetivos, así como de lograr una amplia creencia en la congruencia de los objetivos del proyecto con los
objetivos globales de la organización.
El apoyo de la alta gerencia, el segundo factor, se ha considerado de gran importancia en la definición
del éxito o del fracaso final. Los gerentes de proyecto y sus equipos no solamente dependen de la autoridad,
dirección y apoyo de la alta gerencia, sino que también son el conducto para la implementación en la organi-
zación, de los planes o metas de la alta gerencia.11 Además, si el proyecto se desarrolla para clientes internos
(dentro de la empresa), el grado de apoyo a la gerencia de un proyecto dará lugar a variaciones significativas
en el grado de aceptación o resistencia al proyecto o producto. El apoyo de la alta gerencia al proyecto puede
incluir aspectos como la asignación de recursos (financieros, de personal, tiempo, etc.) suficientes, así como
la confianza y el soporte de la alta gerencia a la gerencia del proyecto en caso de crisis.
El tercer factor, planeación y programación del proyecto, se refiere a la importancia de desarrollar un plan
detallado de las etapas necesarias dentro del proceso de ejecución. Sin embargo, es importante recordar que
las actividades relacionadas con la planeación y programación de proyectos son diferentes. La planeación, el
primero y más general paso en el desarrollo de la estrategia de ejecución del proyecto, se compone de la defi-
nición del alcance, la EDT y de las asignaciones de recursos a las actividades. La programación es la fijación de
los plazos y los hitos de cada elemento importante en el proyecto global. El tema de los planes y programas de
los proyectos tiene que ver con el grado en el que se especifican los cronogramas, los hitos, los trabajadores y las
necesidades de equipo. Tiene que haber un sistema de medición satisfactoria para juzgar los resultados reales
respecto a las asignaciones presupuestarias y de cronograma.
El cuarto factor es la consulta al cliente. El “cliente” es toda persona que en última instancia va a utilizar
el producto del proyecto, ya sea un cliente externo a la empresa o un departamento dentro de la organiza-
ción. Cada vez más, se reconoce la importancia de consultar al cliente en la implementación del sistema
y, de hecho, el grado en que los clientes se involucran personalmente en el proceso de implementación se
454 Capítulo 13  •  Evaluación y control de proyectos

correlaciona directamente con su apoyo a los proyectos.12 Es importante identificar a los clientes para el pro-
yecto y determinar con precisión si están satisfaciéndo se sus necesidades.
El quinto factor, el personal, incluye el reclutamiento, la selección y la formación de los miembros del equipo
del proyecto. Un aspecto importante, pero a menudo pasado por alto en el proceso de ejecución, se refiere a la natu-
raleza del personal involucrado. En muchas situaciones, el personal del equipo del proyecto se elige sin considerar
el pleno cumplimiento de las competencias para contribuir activamente al éxito de la ejecución. El personal tiene
que ver con el desarrollo de un equipo con la capacidad y el compromiso para llevar a cabo sus funciones.
Las tareas técnicas, el sexto factor, se refiere a la necesidad de tener no solo el número necesario de
personal para el equipo del proyecto, sino también asegurarse de que poseen las habilidades técnicas, la tec-
nología y el apoyo técnico necesario para realizar sus tareas. Es importante que las personas que manejan
un proyecto conozcan la tecnología involucrada. Además, la tecnología adecuada debe existir para apoyar el
sistema. Sin la tecnología necesaria ni los conocimientos técnicos, los proyectos se desintegraran rápidamente
en una serie de desaciertos y errores técnicos.
El séptimo factor, la aceptación del cliente, se refiere a la etapa final del proceso de desarrollo del pro-
yecto, momento en el que se determina la eficacia global del proyecto. Además de la consulta al cliente en una
etapa temprana en el proceso de ejecución, sigue siendo de fundamental determinar si los clientes para los
que se ha iniciado el proyecto lo aceptarán. Con mucha frecuencia, los gerentes de proyectos caen en el error
de creer que si manejan bien las otras etapas del proceso de ejecución, entonces el cliente (ya sea interno o
externo a la organización) aceptará el sistema que resulte. De hecho, la aceptación del cliente es una etapa en
el proceso del ciclo de vida del proyecto que se debe manejar como cualquier otro.
El octavo factor, monitoreo y retroalimentación, se refiere al proceso de control del proyecto mediante
el cual, en cada etapa de la ejecución del proyecto, el personal clave recibe retroalimentación sobre cómo
progresa el proyecto respecto a las previsiones iniciales. Contar con mecanismos de control y retroalimen-
tación adecuados, le da al gerente del proyecto la capacidad de anticiparse a los problemas, supervisar las
medidas correctivas y asegurarse de no pasar por alto ninguna deficiencia. Los gerentes de proyecto deben
hacer hincapié en la importancia del monitoreo constante y del ajuste preciso en el desarrollo de proyectos;
los gráficos de seguimiento y control y la gerencia del valor ganado son excelentes ejemplos de técnicas y
tipos de mecanismos de monitoreo y control necesarios para ejecutar un proyecto.
La comunicación, el noveno factor, no solo es esencial dentro el equipo del proyecto en sí, sino —como
ya comentamos respecto a la gerencia de los interesados—, que también es vital entre el equipo y el resto
de la organización, así como con los clientes. La comunicación se refiere a los mecanismos de retroalimen-
tación y a la necesidad de intercambiar información con clientes y el resto de la organización en relación
con las capacidades, los objetivos, los cambios en las políticas y procedimientos, informes de estado del pro-
yecto, etc. Por tanto, los canales de comunicación son muy importantes para crear un ambiente apropiado
para la ejecución exitosa del proyecto.
La solución de problemas es el décimo y último factor del modelo. Existen aspectos problemáticos en
casi todos los proyectos en desarrollo. La medida del éxito de un proyecto no está relacionada con evitar los
problemas, sino en tomar las medidas correctas una vez que se presentan problemas. Sin importar qué tan
cuidadosamente se ha planeado el proceso de ejecución, es imposible prever todas las áreas problema o un
problema que posiblemente pueda surgir. Como resultado, el gerente del proyecto debe incluir mecanismos
en el plan de ejecución para identificar y solucionar problemas cuando surjan. Estos mecanismos hacen que
sea más fácil no solo reaccionar a los problemas a medida que surgen, sino también prever y, posiblemente,
prevenir los posibles problemas en el proceso de ejecución.

Conclusiones
En este capítulo se analizó una variedad de enfoques para el seguimiento y control de proyectos. Aunque la
mayoría de los modelos mencionados tienen muchas ventajas asociadas a ellos, los profesionales de gerencia
de proyectos, también, deben ser conscientes de los problemas y deficiencias concomitantes con estos enfo-
ques. La clave para el desarrollo de un proceso de control de proyectos útil radica en el reconocimiento de las
fortalezas y debilidades de los métodos alternativos y en última instancia del desarrollo de un enfoque que
se adapte mejor a la organización, a los proyectos emprendidos y a los interesados del proyecto. Un proceso
de control de proyectos se debe adaptar, en la medida de lo posible, a las necesidades específicas, a la cultura
y a los usos que la organización se propone. Por tanto, en algunas circunstancias, un sistema de control sim-
plificado puede ser suficiente para proporcionarle a la administración la información que necesita. Por otra
Resumen 455

parte, algunas organizaciones o proyectos tendrán que emplear procesos de control altamente sofisticados,
ya sea por la naturaleza única de sus procesos operativos o las demandas de los proyectos en desarrollo (por
ejemplo, disposiciones gubernamentales y legales).13
El concepto amplio y complejo de evaluación y control de proyectos implica necesidad de comprender
técnicas alternativas de evaluación, reconociendo su utilidad particular y los tipos de información que pue-
den proporcionar. Sin embargo, en última instancia, estas técnicas tan buenas como el proceso de planea-
ción del proyecto, es decir, un buen sistema de control no puede compensar planes iniciales inadecuados o
inexactos. Sin líneas base efectivas, buena estimación del costo y del presupuesto del proyecto, y asignaciones
adecuadas de recursos, el control de proyectos simplemente no funcionará. Sin embargo, si la planeación se
ha realizado de forma efectiva, la evaluación y control de proyectos puede trabajar en armonía con los planes
del proyecto, y proporcionarle al equipo del proyecto no solamente una hoja de ruta clara para el éxito, sino
también hitos excelentes a lo largo del camino.

Resumen
1. Comprender los fundamentos del ciclo de control y 3. Comprender cómo la gerencia del valor ganado
sus cuatro pasos claves en un modelo general de con- puede ayudar al seguimiento y evaluación de proyec-
trol del proyecto. Evaluar con precisión el estado de los tos.  La gerencia del valor ganado (EVM) es una
proyectos en curso representa un verdadero desafío para herramienta poderosa desarrollada en cumplimiento
los equipos de proyectos y para sus organizaciones patro- de un mandato del gobierno federal, para enlazar
cinadoras. El proceso de control del proyecto, un ciclo directamente el avance del proyecto con las líneas
recurrente de cuatro pasos (fijación de metas, medición base del cronograma y del presupuesto. En efecto, la
del progreso, comparación del progreso real con los pla- EVM proporciona la pieza faltante del rompecabezas
nes y corrección de las desviaciones significativas), mues- del control al requerir la presentación de informes de
tra un marco teórico para la comprensión de la natura- estado actual de las actividades del proyecto, en tiempo
leza continua del seguimiento y control de los proyectos. real. La gerencia del valor ganado ha comenzado a
2. Reconocer las fortalezas y debilidades de los méto- difundirse rápidamente dentro de las organizaciones
dos comunes de evaluación y control de proyec- enfocadas en proyectos, en donde las ventajas de su
tos.  Existen varias técnicas de evaluación y control de uso se perciben cada vez más.
proyectos, desde las más simples hasta las más sofistica- 4. Utilizar la gerencia del valor ganado en el análisis del
das. El proceso de evaluación de proyectos básico es el portafolio de proyectos.  Los principios que rigen el
de curvas S, que concilia la línea base del cronograma uso del valor ganado en un solo proyecto también se
del proyecto con los gastos previstos del presupuesto. pueden aplicar a un portafolio de proyectos. Cada pro-
El presupuesto acumulado del proyecto se asemeja a yecto se evalúa en función de los índices básicos de efi-
la letra S, y la relación cronograma/presupuesto fue el ciencia en tiempo y en costo, y se calcula una evaluación
primer método de seguimiento empleado para obte- global para el portafolio de proyectos de la empresa. Este
ner un indicador del progreso esperado del proyecto. modelo de portafolio nos permite determinar la eficien-
Infortunadamente, varios problemas asociados con el cia general con el que gerenciamos los proyectos, para
análisis de la curva S han disminuido su uso como una tener una idea de cuáles van cumpliendo los estándares
técnica precisa de evaluación y control. Otros métodos básicos de la empresa y cuáles van rezagados.
de evaluación incluyen el análisis de hitos y los diagra- 5. Comprender los conceptos de comportamiento y otros
mas de Gantt de seguimiento. Estos enfoques asocian el aspectos humanos en la evaluación y el control. Un
progreso del proyecto con la línea base del cronograma, último método para el seguimiento y la evaluación del
más que con el presupuesto del proyecto. Al igual que estado de los proyectos en curso se basa en el uso de méto-
con las curvas S, el análisis de hitos y las gráficas de dos alternativos de control, dirigido a evaluar y gerenciar
seguimiento tienen algunas ventajas, pero los dos com- los “aspectos humanos” de la gerencia de proyectos, en
parten una desventaja común: su incapacidad para eva- lugar de centrarse exclusivamente en los técnicos. En otras
luar con precisión el avance de las actividades en curso y, palabras, la EVM y otros mecanismos de seguimiento y
por tanto, el estado “real” del proyecto. Específicamente, de control descritos se centran en medidas basadas en
debido a que estos métodos de seguimiento y control los datos de rendimiento (presupuesto, horarios, y des-
no vinculan las líneas base del cronograma y del presu- empeño), pero otros modelos que abordan las cuestio-
puesto con el desempeño del proyecto en curso, pueden nes de gerencia y del comportamiento en la gerencia del
no llegar a ofrecer una medida razonable del estado del proyecto argumentan que, a menos que fusionemos estos
proyecto. modelos basados en datos con los enfocados a evaluar el
456 Capítulo 13  •  Evaluación y control de proyectos

proyecto en términos de las interacciones humanas (lide- del cronograma y la estimación de la termina-
razgo, apoyo de la gerencia, la comunicación, etc.), será ción.  El método de programación ganada determina
posible generar una buena cantidad de información sobre el estado del cronograma de un proyecto hasta su ter-
el estado actual de un proyecto, reconociendo la impor- minación, considerando que el valor ganado estándar
tancia de la conducta humana para determinar el éxito emplea datos de presupuesto para calcular no solo
o el fracaso de las actividades del proyecto. Para generar estimaciones de los costos del proyecto, sino también
un sentido cabal del estado del proyecto, hay que mezclar de tiempo (cronograma). La programación ganada
modelos de seguimiento orientados netamente a datos argumenta que el “cronograma se debe tratar de forma
con enfoques gerenciales. diferente” por lo cual la EVM está propensa a errores
6. Comprender las ventajas de los métodos de progra- en la estimación del cronograma y, por tanto, ofrece
mación ganada para determinar la variación de la algunos procedimientos correctivos para ajustar estos
programación del proyecto, el índice de desempeño cálculos.

Términos clave
Ciclo de control (p. 433) Diagrama de Gantt de Índice de desempeño del Programación ganada (ES)
Control del proyecto (p.436) seguimiento (p.438) costo (CPI) (p.440) (p.456)
Costo presupuestado a Estimación de la Índice de desempeño Valor ganado (EV) (p.439)
la terminación (BAC) terminación (EAC) del cronograma (SPI) Variación de cronograma
(p.465) (p.456) (p.465) (p.445)
Costo real del trabajo Gerencia del valor ganado Línea base del proyecto
realizado (AC) (p. 443) (EVM) (p.439) (p.442)
Curva S del proyecto Hito (p.436)
(p.434)

Problema resuelto

Ejemplo de valor ganado Variación de cronograma.  A medida que se realiza el trabajo, se


“gana” en las mismas condiciones previstas, en dólares o en otras
El Project Management Institute, la mayor organización de profe-
unidades cuantificables, como las horas de trabajo. La compara-
sionales de la gerencia de proyectos en el mundo, ha desarrollado
ción del valor planeado con el valor ganado mide el volumen en
un sencillo ejemplo de la lógica que subyace a la evaluación del va-
dólares de los trabajos planeados en comparación con el volumen
lor ganado para un proyecto. Con este ejemplo, presentado a con-
equivalente en dólares de trabajo realizado. Cualquier diferencia se
tinuación, se muestra el cálculo de los componentes más relevantes
denomina variación de cronograma. Al contrario de lo previsto, el
del valor ganado y cómo estas medidas se vinculan entre sí, para
cuadro 13.11 muestra que la unidad de trabajo D no se ha comple-
aportar una comprensión global del valor ganado.
tado y la unidad de trabajo F nunca se inició, es decir, $35 de las
El valor ganado es una técnica de gerencia que relaciona la pla-
obras previstas no se han llevado a cabo. Como resultado, la varia-
neación de recursos con el cronograma y con sus requerimientos
ción de cronograma indica que 35% de las obras previstas para este
técnicos y de costos. Todo el trabajo se planea, presupuesta y progra-
periodo no se efectuaron.
ma con incrementos de valor según las fases previstas para el pro-
yecto y constituye las líneas base de medida de costos y cronograma. Variación de costo.  El valor ganado en comparación con el costo
Hay dos objetivos principales en un sistema de valor ganado: fomen- real incurrido (a partir de los sistemas de contabilidad del contratis-
tar en los contratistas la utilización de sistemas internos efectivos, ta), para el trabajo realizado, proporciona una medida objetiva de
de control de gerencia de costos y de cronograma y permitir que el costos previstos y reales. Cualquier diferencia se denomina variación
cliente cuente con datos oportunos producidos por los sistemas para de costo. Una variación negativa significa que se gastó más dinero
determinar el estado del contrato. en la labor realizada que se había planeado. El cuadro 13.12 muestra
el cálculo de la variación de costo. El trabajo realizado fue planeado
Línea base.  El plan de línea base en el cuadro 13.10 muestra seis
con un costo de $65 y realmente costó $91. La variación de los costos
unidades de trabajo (A–F) que se completarían con un costo de
es 40%.
$100, en el periodo cubierto por este reporte.

CUADRO 13.10  Plan de línea base en las unidades de trabajo

A B C D E F Total
Valor planeado 10 15 10 25 20 20 100
Preguntas para discusión 457

Comparación de gastos.  El método típico de comparación de costos, Uso de los datos de valor ganado.  Los beneficios de la geren-
en el cual los contratistas informan los gastos reales y los costos previs- cia del enfoque del valor ganado del proyecto dependen de la buena
tos, no relaciona el trabajo que se llevó a cabo. El cuadro 13.13 mues- planeación y de la disponibilidad de indicadores que muestren las
tra una comparación simple del costo previsto con el real, sin tener en variaciones reales del plan, con el fin de generar las acciones correc-
cuenta el trabajo realizado y, por tanto, no es útil. El hecho de que el tivas necesarias.14
importe total gastado fuera de $9 menos de lo previsto para ese periodo,
no es útil sin considerar las comparaciones con el trabajo realizado.

CUADRO 13.11  Variación de cronograma en las unidades de trabajo

A B C D E F Total
Valor planeado 10 15 10   25 20  20 100
Valor ganado 10 15 10   10 20 —  65
Variación de cronograma  0  0  0 -15  0 -20 -35, o -35%

CUADRO 13.12  Variación de costo en las unidades de trabajo

A B C D E F Total
Valor planeado 10 15 10  10 20 — 65
Costo real  9 22  8  30 22 — 91
Variación de costo  1 -7  2 -20 -2 0 -26, o -40%

CUADRO 13.13  Método de comparación de gastos en las unidades de trabajo

A B C D E F Total
Gastos planeados 10 15 10 25 20 20 100
Gastos reales  9 22  8 30 22 — 91
Variación  1 -7  2 -5 -2 20 9, o 9%

Preguntas para discusión


1. ¿Por qué es útil el ciclo de control de cuatro etapas, para enten- 7. Considere las conclusiones principales de la investigación de
der cómo hacer el seguimiento y el control de los proyectos? los factores humanos en la ejecución del proyecto. ¿Qué temas
2. ¿Por qué la curva S fue una de las primeras técnicas de segui- comunes pueden identificarse de la investigación sobre los pro-
miento de proyectos? ¿Usted considera valioso vincular el blemas de comportamiento como un elemento clave para deter-
presupuesto con el cronograma para monitorear el avance del minar el estado del proyecto?
proyecto? 8. Los 10 factores claves de éxito se han aplicado en una variedad
3. ¿Cuáles son algunas de las desventajas del análisis de las cur- de entornos y tipos de proyectos. Considere un proyecto con
vas S? el cual usted se haya involucrado. ¿Algunso de estos factores
4. ¿Cuáles son las ventajas y desventajas del uso del análisis de resultaron ser los más importantes para el éxito del proyecto?
hitos como una herramienta de seguimiento de proyectos? ¿Por qué?
5. Se ha dicho que la gerencia del valor ganado (EVM) se produjo 9. Identifique los siguiente términos: PV, EV y AC. ¿Por qué estos
porque el gobierno federal utiliza frecuentemente contratos “a términos son importantes? ¿Cómo se relacionan ente sí?
todo costo” con las empresas de proyectos. La contratación a 10. ¿Qué reflejan el índice de desempeño del cronograma y el índice
todo costo le permite al contratista recuperar los costos totales de desempeño del costo? ¿Cómo puede un gerente de proyectos
de desarrollo del proyecto, más la ganancia del contrato. ¿Por utilizar esta información para estimar el desempeño futuro de
qué la exigencia a los contratistas de implementar la gerencia un proyecto?
del valor ganado ayuda al gobierno a mantener control sobre los 11. Suponga que el SPI calculado es menor que 1.0. ¿Esto es una
excesos de costos del proyecto? buena o una mala noticia para el proyecto? ¿Por qué?
6. ¿Cuáles son las principales ventajas del uso de la EVM como
una técnica de control de proyectos? ¿Qué desventajas percibe?
458 Capítulo 13  •  Evaluación y control de proyectos

Problemas
1. Con la siguiente información, represente la curva S de los gas- b. Dibuje la curva S del proyecto e identifique la relación entre el
tos presupuestados acumulados esperados para este proyecto valor inicial del presupuesto del proyecto y su cronograma.
(cifras expresadas en miles). 4. Utilice la siguiente información para construir un diagrama de
Gantt de seguimiento utilizando MS Project.
Duración (en días)

10 20 30 40 50 60 70 80 Duración Actividades
Actividades (días) predecesoras
Actividades 4  8 12 20 10  8  6  2
Acumulado 4 12 24 44 54 62 68 70 A 5 días -
B 4 días A
2. Suponga que las cifras de gasto del problema 1 se modificaron C 3 días A
de la siguiente manera (cifras en miles): D 6 días B, C
E 4 días B
Duración (en días) F 2 días D, E

10 20 30 40 50 60 70 80
Resalte el estado del proyecto para el día 14 mediante la opción
Actividades 4  8 10 14 20 24  28   8 de seguimiento y suponiendo que todas las tareas hasta la fecha
Acumulado 4 12 22 36 56 80 108 116 se han completado a tiempo. Imprima el archivo de resultado.
5. Con la información del problema 4, resalte el estado del proyecto
Dibuje la curva S. ¿Qué representa el nuevo diagrama de la curva para el día 14, pero suponiendo que la actividad D aún no ha
S? ¿Cómo explica la razón por la cual la curva no tiene forma de S? comenzado. ¿Cómo sería el nuevo diagrama de Gantt de segui-
3. Tome en cuenta la siguiente información (cifras en miles): miento? Imprima el archivo de resultado.
6. Utilice el siguiente cuadro para calcular la variación de cronograma
del proyecto, según las unidades de trabajo listadas (cifras en miles).
Costos presupuestados para el proyecto

Duración (en semanas) Variación de cronograma en las unidades de trabajo

5 10 15 20 25 30 35 40 45 Total A B C D E F Total
Diseño 4 4 2 Valor planeado 20 15 10 25 20 20 110
Ingeniería 3 6 12  8 Valor ganado 25 10 10 20 25 15
Instalación 4 12 24 6 Variación de
Pruebas  2 6 6 4 2 cronograma
Total
 Acumulado 7. Con los siguientes datos, complete el cuadro calculando los
 Mensual presupuestos acumulados mensuales previstos y reales, a fina-
les de junio. Complete la columna valor ganado. Suponga que
el proyecto está planeado para una duración de 12 meses y un
a. Calcule el presupuesto mensual y los presupuestos acumu- presupuesto de $250,000.
lados mensuales para el proyecto.

Actividad Febrero Marzo Abril Mayo Junio Planeado % completado Valor


Contratación de  8  7 15 100 _______
personal
Planos  4  6 10 100 _______
Desarrollo de  2  8 10  70 _______
prototipo
Diseño completo  3  8 10 21  67 _______
Construcción  2 30 32  25 _______
Transferencia 10 10   0 _______
Plan mensual
Acumulado
Mensual real 10 15 6 14 9 40
Acumulado real
Estudio de caso 13.1 459

8. Con los datos del problema 7, calcule los siguientes valores: 10. En el problema 9, suponga que su PV fue 75 y el EV fue 80.
Vuelva a calcular el SPI y el tiempo estimado para la termina-
ción del proyecto, con estos nuevos datos.
Variación de cronograma
11. Suponga que se han obtenido los siguientes datos para un pro-
Valor planeado (PV) ____________ yecto. El presupuesto es $75,000 y se espera que dure cuatro
Valor ganado (EV) ____________ meses. Después de dos meses, usted calcula lo siguiente del
Índice de desempeño del cronograma ____________ proyecto:
Tiempo estimado de terminación ____________ PV = $45,000
EV = $38,500
Variación de costo AC = $37,000
Costo real del trabajo realizado (AC) ____________ Calcule el SPI y el CPI. Considerando estos valores, estime
Valor ganado (EV) ____________ qué tiempo y presupuesto se requieren para completar el pro-
Índice de desempeño del costo ____________ yecto. ¿Cómo interpreta estos resultados? ¿Son buenas o malas
noticias?
Costo estimado de terminación ____________
1 2. (Opcional—Basado en el cronograma ganado del apéndice
13.1.) Suponga que tiene un proyecto con un costo presupues-
9. Usted calcula el tiempo estimado para la terminación de un tado a la terminación (BAC) de $250,000 y una duración esti-
proyecto de 15 meses de duración y un costo presupuestado de mada de 10 meses. Después de monitorear el proyecto durante
$350,000. Tomando en cuenta la siguiente información, calcule seis meses, se recoge la información que muestra el cuadro de
el índice de desempeño del cronograma y el tiempo estimado abajo.
para la terminación (cifras en miles). a. Complete el cuadro. ¿Cómo difieren el SPI de valor ganado
(en $) y el SPI del cronograma ganado?
b. Calcule las variaciones de cronograma para el proyecto,
Variación de cronograma
tanto para valor ganado como para cronograma ganado.
Valor planeado (PV) 65 ¿En qué difieren los valores?
Valor ganado (EV) 58
Índice de desempeño del ____________
cronograma
Tiempo estimado de terminación ____________

Enero Febrero Marzo Abril Mayo Junio


PV ($) 25,000 40,000 70,000 110,000 150,000 180,000
EV ($) 20,000 32,000 60,000  95,000 123,000 151,000
SV ($) -5,000
SPI ($) 0.80
ES (mes) 0.80
SV (t) -.20
SPI (t) 0.80

Estudio de caso 13.1


El Departamento de IT de la Kimble College
Como una parte de los esfuerzos para mejorar las capaci- las peticiones de los distintos departamentos universitarios,
dades de IT en la Kimble College, la institución inició un determinar qué necesidades son más apremiantes y crear
programa hace más de cinco años para aumentar drástica- un portafolio de proyectos priorizados. A los dos años de su
mente el tamaño del departamento de IT centrándose en la llegada a Kimble, Dan supervisaba un departamento de IT
gestión de datos y en la mejora de las funciones administra- de 46 personas, divididas en cuatro niveles: (1) soporte; (2)
tivas. Como una parte de la actualización, Kimble contrató programadores júnior; (3) programadores de alto nivel; y (4)
a un nuevo vicepresidente de sistemas de información, Dan líderes de equipos de proyectos. Solo había cuatro líderes del
Gray, y le dio amplia libertad para identificar problemas e equipo del proyecto y la mayoría del personal de Dan traba-
iniciar los proyectos orientados a la mejora del sistema del jaba en soporte como nivel de ingreso a la empresa o como
campus de IT. A Dan también se le dio el poder de decidir programadores júnior.
el desarrollo de nuevos proyectos, para lo cual debía analizar (continúa)
460 Capítulo 13  •  Evaluación y control de proyectos

En los últimos tres años, el desempeño del departa- como respuesta “Oh, bien,” usted se da cuenta de que no
mento de Dan ha sido de altibajos. A pesar de que ha sido están siendo evasivos, sino que simplemente no saben
responsable de una serie de nuevos proyectos, su trayec- cómo progresan sus proyectos en el día tras día. Cuando
toria de entrega es inestable; por ejemplo, más de la mitad se les pregunta cómo determinan el estado del proyecto,
de los nuevos proyectos han sobrepasado sus presupues- el consenso general entre los líderes de los equipos de pro-
tos y cronogramas iniciales, a veces en más de 100%. Peor yecto es que a menos que escuchen malas noticias, dan
aún, desde la perspectiva del presidente de la universidad, por sentado que todo va bien. Por otra parte, está claro
parece que Dan tiene una idea clara de la situación de los que, incluso si quisieran dedicar más tiempo al control de
proyectos en su departamento. En las reuniones del con- sus proyectos en curso, no están seguros de qué tipo de
sejo, habitualmente presenta un panorama color de rosa información deberían recolectar para efectuar un mejor
de su rendimiento, pero parece incapaz de responder sen- seguimiento y control del desarrollo del proyecto.
cillas preguntas acerca de la entrega tardía del proyecto,
dando vagas declaraciones de que “las cosas van bien.”
Preguntas
Según la opinión del presidente, el historial del departa-
mento de Dan justifica la financiación adicional que le 1. Como consultor, ¿qué soluciones podría proponer
sigue pidiendo para nuevo equipo y personal. para la solución a este problema de seguimiento?
Usted ha sido llamado, como consultor indepen- ¿Hasta qué punto el estilo de gerencia de Dan ha con-
diente, para evaluar el desempeño del departamento de tribuido al problema?
Dan y, en particular, la manera en que se ejecuta y controla 2. ¿Qué tipo de información sobre el estado del pro-
el desarrollo de su portafolio de proyectos. Su evaluación yecto se podría sugerir que comiencen a recopilar, a
inicial confirma la corazonada del presidente de la uni- los líderes del equipo del proyecto, a fin de evaluar el
versidad: el estado actual de los proyectos en el departa- estado de sus proyectos?
mento de IT no se entiende claramente. Todo el mundo 3. ¿Cómo mezclar “datos duros” con información “de
trabaja duro, pero nadie puede dar respuestas claras acerca gerencia o de comportamiento” para generar una
de cómo evolucionan los proyectos que se desarrollan. visión completa del estado de los proyectos en curso
Después de preguntarles a varios líderes de proyecto sobre en el departamento de IT de la Kimble College?
el estado de sus proyectos y en varias ocasiones recibir

Estudio de caso 13.2


El superconductor Supercollider
Concebido en la década de 1980 como un dispositivo para estimado solo para la construcción de los imanes fue de
acelerar partículas en la investigación de la física de alta 1,500 millones de dólares.
energía, el superconductor Supercollider (Suerconducting Las dificultades técnicas fueron solo una parte del alcance
Supercollider: SSC), desde sus inicios fue una papa general del proyecto. La construcción del SSC sería una
caliente política y técnicamente. Los retos técnicos asocia- empresa de proporciones únicas. Los científicos determi-
dos con el SSC eran de proporciones enormes. Su propó- naron que el acelerador requería una pista ovalada, ente-
sito era romper partículas subatómicas casi a la velocidad rrada bajo tierra para facilitar su uso. El perímetro total
de la luz. Eso requeriría niveles de energía de 40 trillones planificado para el SSC requería construir un túnel de 54
de electronvoltios. Usando física de la mecánica cuántica, millas a 165-200 pies bajo tierra. La estimación del presu-
el objetivo del proyecto consistía en dar luz a algunas de puesto inicial para la realización del proyecto fue de 5,000
las preguntas fundamentales sobre la formación del uni- millones de dólares, y el cronograma estimado requeriría
verso. El SSC fue diseñado para ser el mayor acelerador ocho años para terminar la construcción y el montaje.
de partículas jamás construido, mucho más grande que Los problemas del SSC comenzaron casi inmedia-
su contraparte del Laboratorio Fermi. Para alcanzar estos tamente después que el presidente Reagan, en 1988, diera
niveles de energía, se necesitaba un conjunto de 10,000 inicio al proyecto. En primer lugar, el público (incluido
imanes. Cada uno de los imanes, de forma cilíndrica (1 el Congreso) tenía poco entendimiento del propósito del
pie de diámetro y 57 pies de largo), tendría que operar a su proyecto. Un objetivo tan nebuloso como “la aceleración
nivel máximo para que el acelerador alcanzara los niveles de partículas” de la física de alta energía no era de fácil
de energía necesarios para la colisión de protones. El costo aceptación para la mayoría de ciudadanos. El consorcio
Estudio de caso 13.2 461

operador original, URA, consistía de 80 centros de inves- En un último intento desesperado de salvar la finan-
tigación estadounidenses públicos y privados y univer- ciación del SSC, el secretario de Energía Hazel O’Leary des-
sidades, pero se esperaba que científicos europeos y pidió a URA como contratista principal para el proyecto
asiáticos también estarían dispuestos a llevar a cabo expe- de construcción. Se habló de la sustitución de URA por un
rimentos con el SSC. En consecuencia, el Departamento contratista probado: Martin Marietta y Bechtel fueron los
de Energía de Estados Unidos esperaba compensar algu- dos principales candidatos. Sin embargo, para entonces, se
nos de los costos por intermedio de otros países. Aunque trataba de un caso de muy poco y demasiado tarde. Los cos-
en un principio estos países fueron receptivos a la idea de tos continuaban subiendo y el trabajo se realizaba a tal paso
participar en el proyecto, sus niveles de contribución y de tortuga que cuando se elaboró el presupuesto federal de
plazos para el pago fueron haciéndose vagos. 1994, la partida de financiación del SSC se había eliminado
Otro gran problema era encontrar un sitio ade- por completo. El proyecto estaba muerto. Los costos no
cuado para ubicar el SSC. En su punto máximo de labo- recuperables para el contribuyente Estados Unidos dedica-
res, se esperaba emplear 4,500 trabajadores en el SSC. dos al proyecto se han estimado en entre 1,000 millones de
Además, una vez en funcionamiento a tiempo completo, dólares y 2,000 millones de dólares.
el SSC requeriría un personal permanente de 2,500 Pocos cuestionaron la capacidad del gobierno para
empleados y un presupuesto anual de 270 millones. construir una instalación de ese tipo. La tecnología, aun-
Claramente, todos los estados estaban interesados en que de punta, se había utilizado anteriormente en otros
atraer al SSC. El resultado fue una pesadilla política, al laboratorios de investigación. El problema fue que los
punto que el National Researche Council nombró a un grupos pro-SSC y anti-SSC tendían a dividir entre los
comité de revisión de la localización del proyecto para partidarios de la investigación pura y los que argumenta-
evaluar las propuestas de los 43 estados. Después de emi- ban que la investigación de miles de millones de dólares,
tir sus juicios basados en una serie de criterios de des- al no tener un impacto discernible inmediato en la socie-
empeño y capacidad, la comisión redujo su lista a ocho dad, era un gusto que no se podía permitir, sobre todo en
estados. Finalmente, a finales de 1988, el contrato para el una época de recortes en el presupuesto federal y de deci-
SSC fue otorgado a Waxahachie, Texas, en una extensión siones difíciles. La posición del SSC se debilitó aún más
de 16,000 hectáreas al sur de Dallas. Aunque Texas estaba por las actividades de supervisión del proyecto por el
encantado con el logro, la decisión significó decepción consorcio de investigación, URA. Su comportamiento fue
en los otros estados y en sus congresistas. visto cada vez más arrogante por grupos de supervisión
El problema final con el SSC, casi desde el princi- del Congreso, que comenzaron a hacer preguntas legíti-
pio, era el déficit del presupuesto federal, lo que provocó mas acerca de los gastos y de las exorbitantes solicitudes
que más y más políticos cuestionaran la decisión de asig- de presupuesto. En lugar de reportar evidencia del pro-
nar el dinero en momentos en que el Congreso buscaba greso del proyecto, se presentó un panorama deficiente
formas de recortar más de 30,000 millones de dólares del control y seguimiento de los costos; claramente, este
del presupuesto. Esta preocupación terminó siendo un no es el mensaje adecuado para enviar cuando los contri-
problema a largo plazo, ya que al SSC se asignaron solo buyentes estadounidenses estaban cuestionando su deci-
100 millones de dólares para 1989, menos de un tercio sión de asumir una factura multimillonaria.15
de la solicitud de financiamiento inicial por 348,000,000
dólares. Las batallas presupuestarias serían un estribillo Preguntas
constante durante la corta vida del SSC. El trabajo proce- 1. Suponga que usted era un consultor nombrado por
dió lentamente en Waxahachie a lo largo de la década de el gobierno federal cuando aún parecía viable el pro-
1990. Mientras tanto, el apoyo financiero europeo para yecto, en 1990. Teniendo en cuenta los inicios del pro-
el proyecto nunca llegó. Varios gobiernos sospechaban yecto, ¿qué pasos habría tomado para generar algún
en privado que el proyecto nunca se completaría. Sus “giro” positivo en el superconductor Supercollider?
temores se justificaban cada vez más, ya que el costo del 2. ¿Cuáles fueron las señales de alerta de fallas inminentes
proyecto seguía aumentando. Para 1993, la estimación que se presentaron a medida que el proyecto avanzaba?
original de 5,000 millones de dólares se había disparado ¿Estas señales pudieron haberse reconocido para que
a 11,000 millones de dólares. Mientras tanto, menos de los problemas se hubieran previsto y solucionado o,
20% de la construcción se había completado. El proceso según su opinión, el proyecto simplemente era imposi-
se frenó cuando el Congreso comenzó a investigar los ble de lograr? Tome una posición y argumente.
gastos y determinó que los procedimientos de contabi- 3. Busque “ superconductor supercollider” en internet.
lidad eran insuficientes. Es evidente que el control del ¿De que tratan la mayoría de las historias sobre el pro-
presupuesto y de la programación del proyecto se había yecto? Dada la perspectiva negativa, ¿cuáles son las tres
convertido en una seria preocupación. principales lecciones que aprendizaje de este proyecto?
462 Capítulo 13  •  Evaluación y control de proyectos

Ejercicios en internet
1. Ingrese en el sitio web www.prenhall.com/pinto y acceda al artí- 4. Digite la dirección www.massdot.state.ma.us/highway/the-
culo de Q.W. Fleming y J.M. Koppelman, “Earned value project BigDig.aspx y navegue por el sitio web que trata del túnel de
management... an introduction,”Crosstalk: The Journal of Defense Boston. Evalúe el desempeño de este proyecto con el modelo
Software Engineering (July 1999), pp. 10–14. De su lectura, elabore de 10 factores claves de éxito de los proyectos, discutidos en
un resumen de los puntos claves o ventajas que argumentan la este capítulo. ¿Cuál sería la evaluación del proyecto, según su
práctica del valor ganado en el control y evaluación de proyectos. opinión? Presente ejemplos y pruebas concretas que apoyen sus
2. Ingrese en www.acq.osd.mil/evm y explore los diferentes enlaces calificaciones.
y pantallas. ¿Qué significa el tamaño y la diversidad de este sitio, y 5. Ingrese en el sitio web de Prentice Hall Companion y acceda
que le dicen estos acerca de la aceptación y el uso del valor ganado al artículo de J. K. Pinto y J. G. Covin,“Critical factors in proj-
en las organizaciones de hoy día? ect implementation: A comparison of construction and R&D
3. Ingrese en www.erpgenie.com/general/project.htm y acceda a projects,” Technovation, 9 (1989), pp. 49–62. ¿Qué sugiere esta
la lectura de “ Six Steps to Successful Sponsorship.” Considere investigación acerca de la importancia del factor clave de éxito en
los factores claves de éxito identificados para la gerencia de la diferentes tipos de proyectos? ¿En el ciclo de vida del proyecto?
implementación de proyectos de IT. ¿Cómo relacionar estos
factores en el modelo de 10 factores de Pinto y Slevin? ¿Cómo
explica las diferencias?

Ejercicios con MS Project


Ejercicio 13.1 ponsables de cada actividad, y una vez que haya completado la red,
actualice con la herramienta porcentaje completado. ¿Cómo aparece
Utilizando los siguientes datos, introduzca las diversas tareas y ela- el archivo de resultado?
bore un diagrama de Gantt con MS Project. Asigne las personas res-

Actividad Duración Predecesoras Recursos % completado


A. Investigación de producto 6 — Tom Allen 100
B. Entrevistar a los clientes 4 A Liz Watts  75
C. Diseñar encuestas 5 A Rich Watkins  50
D. Recopilar datos 4 B, C Gary Sims   0

Ejercicio 13.2 una fecha de aproximadamente la mitad de la duración total del pro-
yecto, y actualice todas las tareas en la red para mostrar el estado ac-
Ahora, suponga que se asignan costos a cada uno de los recursos, de tual. Usted puede suponer que las actividades de la A a la I están 100%
la siguiente forma: completadas. ¿Cómo aparece el diagrama de Gantt de seguimiento?

Recursos Costo Proyecto de remodelación de un electrodoméstico

Tom Allen $50/hora Actividad Duración Predecesoras


Liz Watts $55/hora
A. Analizar la competencia 3 —
Rich Watkins $18/hora
B. Revisar informes de ventas 2 —
Gary Sims $12.50/hora de campo
C. Evaluar las funciones 5 —
Dé la instrucción de utilización de recursos para el proyecto, a partir tecnológicas
de la actualización más reciente. ¿Cuáles son los gastos del proyecto,
D. Obtener datos del grupo focal 2 A, B, C
por tarea, hasta la fecha?
E. Realizar encuestas 3 D
telefónicas
Ejercicio 13.3 F.   Identificar mejoras en espe- 3 E
Utilice MS Project para generar un informe resumen del estado más cificaciones pertinentes
reciente del proyecto. G.  Interactuar con personal de 1 F
marketing
Ejercicio 13.4 H. Desarrollar especificaciones 5 G
de ingeniería
Utilizando los datos mostrados en el siguiente cuadro de precedencia
I.   Comprobar y depurar diseños 4 H
de red, introduzca las diversas tareas con MS Project. Luego seleccione
Ejercicios con MS Project 463

a. $1,600
Actividad Duración Predecesoras b. $1,075
J.   D esarrollar el protocolo de 3 G c. $1,290
pruebas d. -$1,075
K. Identificar los niveles de de- 2 J 3. Con la información de la pregunta 2, calcule el índice del
sempeño claves desempeño de costos (CPI) para el proyecto.
L.  Evaluar y modificar los com- 6 I, K a. 1.20
ponentes del producto b. -1.20
M. Evaluar las capacidades 12 L c. 0.83
N.  Identificar los criterios de 3 M d. -0.83
selección 4. ¿Cuál de los siguientes términos relaciona la cantidad res-
O.  Desarrollar RFQ 4 M tante para gastarse en el proyecto de las preguntas 2 y 3,
P.  Elaborar programa maestro 5 N, O sobre la base de la eficiencia del gasto actual?
de producción a. Presupuesto restante
Q.  Enlazar con el personal de 1 P b. Estimación hasta la terminación
ventas c. Variación de los costos
R. Preparar el lanzamiento del 3 Q d. Índice de desempeño de costos (CPI)
producto 5. La actividad A cuesta $100, está completa, y en realidad
costó $150. La actividad B cuesta $500, está con 75% de
avance, y ha costado realmente $400 hasta el momento.
Preguntas de ejemplos del examen para la La actividad C cuesta $500, está con 25% de avance, y ha
certificación PMP® costado realmente $4,200 hasta el momento. ¿Cuál es el
costo estimado para la terminación del proyecto?
1. Suponga que el PV para un proyecto fue de $100,000 y a. $1,100
el EV fue de $60,000. El índice de desempeño del crono- b. $750
grama (SPI) para este proyecto sería: c. $880
a. 1.52 d. $1,375
b. .60
c. No se puede calcular el SPI con la información Respuestas: 1. b—SPI se calcula dividiendo el valor ganado
proporcionada (EV) entre el valor planeado (PV); 2. b—El valor ganado a
d. 1.66 la fecha es $1,075; 3. c— El CPI se calcula como el valor ga-
2. La actividad A cuesta $500, se ha completado y en reali- nado (EV) dividido entre el costo real (AC). En este caso, es
dad costó $500. La actividad B cuesta $ 1,000, tiene 50% $1,075/$1,290, o 0.83; 4. b—Estimación hasta la terminación;
de avance y ha costado realmente $700 hasta el momento. 5. d— La estimación a la terminación se basa en la fórmula
La actividad C cuesta $100, está con 75% de avance y ha (1/0.80)  $1,100, o $1,375.
costado realmente $90 hasta el momento. ¿Cuál es el valor
total ganado para el proyecto?
464 Capítulo 13  •  Evaluación y control de proyectos

APÉNDICE 13.1
Cronograma ganado*
La investigación y la práctica de la gerencia del valor ganado (EVM) han demostrado que este método de seguimiento
y previsión del proyecto es fiable y le ofrece al equipo del proyecto una instantánea precisa tanto de la situación actual
del proyecto como una previsión de sus condiciones de terminación. Sin embargo, en los últimos años, algunos crí-
ticos han señalado que la EVM también tiene algunas limitaciones. Una de las más importantes de estas limitaciones
es el hecho de que toda la información del estado del proyecto se deriva en términos de presupuesto del proyecto,
incluidos el índice de desempeño del cronograma del proyecto (SPI) y la variación del cronograma. Una segunda
preocupación expresada sobre la EVM es que llega a ser menos precisa (no fiable) a medida que avanza el proyecto
y que, en las últimas etapas del proyecto, la información derivada de la EVM puede ser injustificadamente positiva o
negativa. Finalmente, se ha sugerido que la EVM se convierte en un indicador impreciso de los proyectos que ya van
retrasados, es decir, cuya duración ha sobrepasado la fecha de terminación de la línea base original. En otras palabras,
¿cómo podemos determinar el estado actual de un proyecto una vez que oficialmente está “retrasado”?
Vamos a considerar estas objeciones a la EVM, en el mismo orden. En primer lugar, sabemos que la
EVM se deriva del presupuesto del proyecto, no del desempeño de su cronograma, pero, intuitivamente,
tiene más sentido que el desempeño del cronograma de un proyecto sea expresado en términos de unidades
de tiempo. Por ejemplo, recuerde que la variación del cronograma (SV) se calcula restando del valor ganado
(EV) el Valor planeado (PV) y la fórmula para encontrar el índice de desempeño del cronograma (SPI) es SPI
= EV/PV. Por tanto, estamos evaluando el desempeño del cronograma del proyecto, no como una función de
tiempo, sino de dinero. Podemos ver esto gráficamente en la figura 13.12, que muestra una medida genérica
de la EVM para un proyecto. El eje vertical del gráfico de desempeño está en dólares de presupuesto, y la
variación del cronograma resultante también se expresa en términos del presupuesto del proyecto. Las métri-
cas de la EVM para el cronograma son, entonces, el valor ganado (EV) y el valor planeado (PV).
La segunda preocupación sugiere que cuanto más cerca la terminación de un proyecto, menos precisa y
útil es la información que proporciona la EVM. La importancia de las relaciones basadas en los costos que utili-
zan la duración prevista para predecir la duración final de un proyecto se puede ilustrar con un ejemplo sencillo.
Supongamos que un proyecto con un presupuesto de $1,000 ha completado la mayor parte de su trabajo pla-
neado, con EV = $990, PV = $1,000, BAC = $1,000 y PD (duración planeada) = 12 semanas. Estas métricas dan
un SPI de 0.99, lo que da una duración final de 12.12 semanas: estimación a la terminación = 1/.99  12. En una
inspección simple, podemos ver cómo el EV se acerca al PV, y en última instancia, la BAC, la duración prevista
del proyecto, disminuye, debido a que el límite superior para el EV siempre es la BAC. Independientemente de

CPI = EV/AC
SPI = EV/PV
PV

CV
$ SV

AC

EV

Tiempo
FIGURA 13.12  Métricas de desempeño de valor ganado
Fuente: Lipke, W. H. (2003, Spring). “Schedule is different,” The
Measureable News, pp. 10–15.

*Parte de este apéndice se preparó en colaboración con Bill Mowery, MPM, PMP.
Apéndice 13.1 465

si este cálculo se realiza durante la semana 10 o en la 15, la relación basada en el costo genera los mismos resul-
tados y puede demostrar que un proyecto en curso tiene una fecha de terminación prevista, en el pasado. Este
problema sugiere que la EVM se vuelve menos precisa cuanto más cerca está un proyecto de su terminación.
Mientras los primeros indicadores son razonablemente exactos, en la fase final del ciclo de vida del proyecto, la
métrica del cronograma del proyecto (recuerde, que se basa en unidades monetarias) probablemente muestre
evidencia alentadora para la terminación. Sin embargo, durante las etapas finales del proyecto, los datos de la
variación de costos y la variación del cronograma empiezan a divergir.
Los críticos de la EVM han señalado esta peculiaridad del sistema: a medida que un proyecto se acerca
a su fecha prevista de terminación, su valor planeado converge con el costo presupuestado del proyecto, es
decir, PV = BAC (costo presupuestado a la terminación). Sin embargo, al final de los proyectos, el valor
planeado del proyecto, por lo general, ya ha convergido en el presupuesto general del proyecto (es decir, PV
= BAC), mientras que el EV busca llegar a este valor de forma incremental. Una vez PV = BAC en la fecha
prevista de terminación del proyecto, el proyecto no puede calificarse como “atrasado.” En efecto, hay errores
de medición que no se manifiestan hasta que el proyecto se atrasa.
La solución que los investigadores han adoptado consiste en introducir el concepto cronograma ganado
(Earned Schedule:ES) en la gerencia del proyecto. El cronograma ganado reconoce, en primer lugar, que para las
predicciones precisas de la programación del proyecto se debe considerar alguna métrica en unidad de tiempo,
más que un enfoque basado en los costos como la EVM. El cronograma ganado utiliza una formulación rela-
tivamente sencilla para lograr su objetivo, que consiste en obtener una medición basada en el tiempo para el
desempeño del cronograma, comparado con el EV de hoy (tiempo real) del proyecto en un punto de la línea base
de medición del desempeño (la curva de valor planeado), en donde este debería haber sido ganado. La diferencia
representa un variación real de cronograma o un cronograma ganado, SVt, según la notación. La derivación de las
métricas de cronograma ganado se muestra en la figura 13.13. Como lo muestra la figura, el índice de desempeño
del cronograma para cualquier proyecto puede ser reconfigurado del original, SPI ($) = EV/PV, a la alternativa:
SPI (t) = ES/AT. En la segunda ecuación, el índice de desempeño del cronograma por el cálculo de cronograma
ganado se divide entre el valor del cronograma ganado por el tiempo real. Asimismo, en esta segunda configura-
ción, la variación del cronograma ganado es igual al cronograma ganado menos el tiempo (ES – AT).
Para calcular el cronograma ganado, usamos el valor ganado actual del proyecto (EV) para identificar en qué
incremento de tiempo del PV se produce el valor del costo. El valor de ES es, entonces, igual al tiempo acumulado del
inicio del incremento más una porción. Por ejemplo, supongamos que deseamos, a finales de junio, calcular el ES de
un proyecto que comenzó el 1 de enero (véase la figura 13.13). Utilizando incrementos mensuales en nuestro cálculo,
como ya estamos a finales de junio, AT = 6. Podemos apreciar visualmente que a finales de junio, el cronograma del
proyecto se ha desviado cierto grado; de hecho, para finales de junio, hemos completado todos los trabajos programa-
dos hasta abril y una parte de la obra de mayo. Podemos utilizar la siguiente fórmula para determinar el ES del proyecto:
 - PVc)/(PVc + 1 - PVc)
ES = C + (EV

SPI(t) = ES/AT SV($) = EV − PV


SPI($) = EV/PV SV(t) = ES − AT

PV
Comparación
entre EV y PV

ES = todo abril + una parte de mayo

EV

E F M A M J J A
Tiempo

FIGURA 13.13  Ejemplo de cronograma ganado (finales de junio)


466 Capítulo 13  •  Evaluación y control de proyectos

donde C es el número de incrementos de tiempo en la línea base del cronograma del proyecto, donde EV ≥
PV. En nuestro ejemplo específico, con incrementos de tiempo mensuales, la fórmula se convierte en:
ES = 4 + 6EV ^ $ h - PV ^abril
 h@ / 6PV ^mayoh - PV ^abrilh@
Podemos ver un ejemplo del cálculo completo del cronograma ganado, en el siguiente caso. Supongamos
que hemos estado recopilando datos sobre el estado de nuestro proyecto durante los últimos seis meses, utili-
zando el método estándar de la EVM. El cuadro 13.14 muestra esta información.
Para el cálculo del ES en enero, tenemos los valores:
EV (enero) = 95
PV (enero) = 105

CUADRO 13.14  Cronograma ganado

Enero Febrero Marzo Abril Mayo Junio Julio


PV ($) 105 200 515 845 1175 1475 1805
EV ($) 95 180 470 770 1065 1315
SV ($) -10 -20 -45 -75 -110 -160
SPI ($) 0.91 0.90 0.91 0.91 0.90 0.89
Contador mes 1 2 3 4 5 6 7
ES (mes)
SV (t)
SPI (t)

Podemos emplear esta información para calcular ES, SV y el SPI del proyecto, utilizando las fórmulas men-
cionadas anteriormente:
ES = 0 + (95 - 0)/(105 - 0) = 0.90
SV (t) = ES - AT, o 0.90 - 1.0 = -0.10
SPI (t) = ES/C, o 0.90 / 1 = 0.90
Con esta información, completamos el cuadro ES para finales de junio (véase el cuadro 13.15). Ahora el cua-
dro se alinea con la figura 13.13.
Podemos ver en la información que hemos calculado en el cuadro 13.15, y en la figura 13.13, que a finales
de junio, comparando el PV del proyecto con el ES real, se muestra un grave deslizamiento. Específicamente,
a finales de junio, solo hemos completado la programación del proyecto para aproximadamente la mitad del
periodo de mayo. Por otra parte, los valores de la variación del cronograma y SPI han ido empeorando durante
los últimos cuatro meses, lo que sugiere que el deslizamiento está acelerándose. Esta información no es tan
obvia, a partir del cuadro estándar de valor ganado, que utiliza valores monetarios del presupuesto del proyecto.
Finalmente, la investigación demuestra que el SPI basado en dólares en comparación con el SPI que utiliza el
tiempo, puede llegar a ser muy diferente a medida que el proyecto avanza hacia su terminación. Por tanto, como
se señaló, los datos reales confirman una de las preocupaciones centrales sobre la EVM, a saber, que sus estima-
ciones de cronograma se vuelven cada vez más imprecisas, cuanto más tarde nos movemos en el proyecto.

CUADRO 13.15  Valor ganado completado/valor de cronograma ganado

Enero Febrero Marzo Abril Mayo Junio Julio


PV ($) 105 200 515 845 1175 1475 1805
EV ($) 95 180 470 770 1065 1315
SV ($) -10 -20 -45 -75 -110 -160
SPI ($) 0.91 0.90 0.91 0.91 0.90 0.89
Contador mes 1 2 3 4 5 6 7
ES (mo) 0.90 1.79 2.86 3.77 4.66 5.47
SV (t) -0.10 -0.21 -0.14 -0.23 -0.33 -0.53
SPI (t) 0.90 0.90 0.95 0.94 0.93 0.91
Apéndice 13.1 467

La precisión relativa del cronograma ganado contra la EVM se puede ilustrar aún más cuando lo usa-
mos para anticipar las variaciones de cronograma y los posibles retrasos en los proyectos. Vamos a utilizar el
siguiente ejemplo para comparar los resultados que podríamos encontrar al usar la EVM frente al cronograma
ganado. Supongamos que tenemos un proyecto con una duración prevista de 18 meses (PD) y un presupuesto
total de $231,280 (BAC). Al final de 16 meses, se han gastado $234,080 (AC), mientras que solo hemos conse-
guido un EV de $207,470. Primero, calculamos la ejecución del presupuesto, o variación de costos (CV), como
CV = EV - AC, o bien:
CV = $207, 470 - $234, 080, o - $26, 610
La variación de cronograma (SV), en nuestro ejemplo, también se puede calcular a partir de esta información.
Recordemos que SV = EV - PV, o:
SV = $207, 470 - $220, 490, o - $13, 020

Las cifras anteriores muestran que el proyecto está por encima del presupuesto y tarde, pero ¿hasta qué punto de
la vida del proyecto? También podemos utilizar esta información para calcular el índice de desempeño del crono-
grama (SPI) y el índice de desempeño de costos (CPI) para el proyecto. Estos valores se hallan, respectivamente, así:
CPI = EV/AC, o $207 , 470/$234, 080 = .89
SPI = EV/PC, o $207 , 470/$220, 490 = .94
Sabemos, por este capítulo, que la simple interpretación de estos valores indican que cada dólar invertido en
el proyecto solo está produciendo 89 centavos, y cada día de 8 horas está produciendo solo 7.5 horas de tra-
bajo efectivo. ¿Cuáles serían los efectos a largo plazo que estos valores tendrían en el proyecto? Una forma de
determinar cuál es la estimación final de la duración, la estimación de tiempo a la terminación (Estimate at
Completion for Time: EACt), se halla mediante la siguiente fórmula:

BAC
 SPI
EAC t = BAC
PD

Donde:
BAC = presupuesto a la terminación ($231,280)
PD = duración planeada (18 meses)
SPI = índice de desempeño del cronograma (0.94)
Despejando EACt en nuestro ejemplo, tenemos:

231, 280
0.94 
231, 280 = 19.15 meses
18

Podemos resolver una ecuación similar para hallar la estimación a la terminación (Estimate at Completion:
EAC) para el presupuesto del proyecto. Dividiendo el BAC $231,280 entre el CPI (0.89), se obtiene un costo
hasta la terminación de $259,870.
Para ver cómo los cálculos del valor ganado y del valor del cronograma ganado pueden conducir a
importantes divergencias, vamos a utilizar la misma información del ejemplo anterior, mostrada en el cuadro
13.16, con las fórmulas de ES, para determinar el estado de la programación del proyecto cuando utilizamos
métricas de tiempo, no datos de presupuesto.

CUADRO 13.16  Datos de desempeño del ejemplo (en miles de dólares)

Diciembre Enero Febrero Marzo


Mes 13 14 15 16
Valor planeado 184.47 198.72 211.49 220.49
Valor ganado 173.51 186.71 198.74 207.47
Costo real acumulado 196.76 211.25 224.80 234.08
468 Capítulo 13  •  Evaluación y control de proyectos

Recordemos que a finales del mes 16, estamos interesados en determinar el estado de la programación.
Nuestra fórmula para el cálculo del cronograma ganado (ES) es:

ES = C + ^EV - PVch / ^PVc + 1 - PVch



Donde:
C = el número de meses de tiempo en la línea base del cronograma donde EV ≥ PV, o 14 meses
EV = $207,470
PV14 = $198,720
PV15 = $211,490
ES = 14 + (207,470 - 198,720) / (211,490 - 198,720) = 14.69 meses
Aplicando nuestra ecuación para la variación de cronograma, SVt = ES - tiempo actual (AT), encontramos
que el proyecto está 1.31 meses retrasado (SVt = 16 - 14.69). Ahora podemos aplicar esta información al cro-
nograma ganado. La fórmula para el índice de desempeño del cronograma (SPIt) es:
SPI t = ES/AT = 14.69/16 = 0.92
Por último, podemos derivar la estimación de la duración final del proyecto, utilizando la estimación
independiente de tiempo a la terminación (Independent Estimate at Completion for Time: IEACt) y llegar a
la previsión del tiempo, como se muestra:

IEAC t = PD/SPI t
Donde:
PD (duración planeada) = 18 meses
IEACt = 18/0.92 = 19.51 meses
Considere los resultados resumidos del cuadro 13.17. Al comparar las variaciones, los índices de des-
empeño, y las proyecciones a la terminación del proyecto de la EVM frente a las mismas métricas del cro-
nograma ganado, podemos percibir algunas discrepancias importantes. En primer lugar, observe el hecho
evidente de que por la variación del cronograma, el cronograma ganado proporciona una estimación de la
duración real basado en tiempo, no en dólares. Por tanto, podemos interpretar la información más fácil-
mente. Sin embargo, es más interesante ver las diferencias cuando se aplica el cronograma ganado al SPI, con
el fin de determinar la duración total probable del proyecto. En este caso, el valor del cronograma ganado
sugiere una duración final del proyecto de 19.51 meses, o aproximadamente medio mes más tarde que la
obtenida con un cálculo similar usando la EVM.
EL cronograma ganado es un concepto relativamente nuevo que ha generado un debate dentro de la
comunidad de la gerencia de proyectos. Hasta la fecha, la investigación del cronograma ganado proviene ya
sea de pequeñas muestras en pruebas de campo o de modelos computarizados. Sin embargo, los argumen-
tos subyacentes que apoyan al cronograma ganado se soportan con un examen cuidadoso. La investigación
sugiere que la EVM tiende a ser poco exacta a medida que un proyecto se mueve hacia su final, por lo que
es importante entender en qué medida se presenta esta situación, según el caso. Por otra parte, se ha demos-
trado que, a medida que un proyecto progresa, la exactitud del enfoque ES realmente mejora. Otra ventaja del
cronograma ganado es que los cálculos son relativamente sencillos y los datos pueden calcularse a partir de
la misma información obtenida con los cálculos de la EVM. Por tanto, como mínimo, el cronograma ganado
ofrece un importante “chequeo” para comprobar la exactitud de la EVM en el seguimiento del proyecto, espe-
cialmente cuando este comienza a cubrir su línea base o a moverse hacia su terminación.16

CUADRO 13.17  Comparación de las métricas de la EVM y del cronograma ganado

Métrica Valor ganado Cronograma ganado


Variación del cronograma (SV) −$13,020 −1.31 meses
Índice de desempeño del cronograma (SPI)    0.94  0.92
Estimación de la duración (IEAC)    19.15 meses 19.61 meses
Notas 469

Notas
1. www.windenergy.org.nz/; www.windenergy.org.nz/nz-wind- 10. Slevin, D. P., and Pinto, J. K. (1987). “Balancing strategy
farms/operating-wind-farms/te-apiti; “New Zealand wind and tactics in project implementation,” Sloan Management
farm: Completed on-time and within budget despite record Review, 29(1): 33–41; Pinto, J. K. (1998). “Critical success
storms,” PMI case study, www.pmi.org/Business-Solutions/ factors,” in Pinto, J. K. (Ed.), Project Management Handbook.
OPM3-Case-Study-Library.aspx. San Francisco, CA: Jossey-Bass, pp. 379–95; Slevin, D. P.,
2. Departments of the Air Force, the Army, the Navy, and the and Pinto, J. K. (1986). “The project implementation profile:
Defense Logistics Agency. (1987). Cost/Schedule Control New tool for project managers,” Project Management Journal,
Systems Criteria: Joint Implementation Guide. Washington, 17(3): 57–70; Belout, A., and Gauvreau, C. (2004). “Factors
DC: U.S. Department of Defense; Fleming, Q., and affecting project success: The impact of human resource
Koppelman, J. (1994). “The essence of evolution of earned management,” International Journal of Project Management,
value,” Cost Engineering, 36(11): 21–27; Fleming, Q., and 22: 1–11; Belout, A. (1998). “Effect of human resource man-
Koppelman, J. (1996). Earned Value Project Management. agement on project effectiveness and success: Toward a
Upper Darby, PA: Project Management Institute; Fleming, new conceptual framework,” International Journal of Project
Q., and Koppelman, J. (1998, julio). “Earned value proj- Management, 16: 21–26.
ect management: A powerful tool for software projects,” 11. Beck, D. R. (1983). “Implementing top management plans
Crosstalk: The Journal of Defense Software Engineering, pp. through project management,” in Cleland, D. I., and King,
19–23; Hatfield, M. A. (1996). “The case for earned value,” W. R. (Eds.), Project Management Handbook. New York: Van
PMNetwork, 10(12): 25–27; Robinson, P. B. (1997). “The per- Nostrand Reinhold, pp. 166–84.
formance measurement baseline—A statistical view,” Project 12. Manley, J. H. (1975). “Implementation attitudes: A model and
Management Journal, 28(2): 47–52; Singletary, N. (1996). a measurement methodology,” in Schultz, R. L., and Slevin,
“What’s the value of earned value?” PMNetwork, 10(12): D. P. (Eds.), Implementing Operations Research/Management
28–30. Science. New York: Elsevier, pp. 183–202.
3. Brandon, Jr., D. M. (1998). “Implementing earned value easily 13. Lock, D. (2000). “Managing cost,” in Turner, J. R., and
and effectively,” Project Management Journal, 29(2): 11–18. Simister, S. J. (Eds.), Gower Handbook of Project Management,
4. Brandon, Jr., D. M. (1998), ibid. 3rd ed. Aldershot, UK: Gower, pp. 293–321.
5. Petro, T., and Milani, K. (2000). “Northrop Grumman’s four- 14. www.acq.osd.mil/pm/evbasics.htm.
tier approach to earning value,” Management Accounting 15. http://psncentral.com/research/SSC.htm; “Superconducting
Quarterly, 1(4): 40–48. Supercollider project hangs on edge.” (1993, 27 de septiem-
6. Christensen, D. S., McKinney, J., and Antonini, R. (1995). “A bre). Boston Globe, p. 1; “Texas lands the SSC.” (1988, 18
review of estimate at completion research,” Journal of Cost de noviembre). Science, 242: 1004; “University consortium
Analysis, pp. 41–62; Christensen, D. S. (1998). “The costs faulted for management, accounting.” (1993, 9 de julio).
and benefits of the earned valued management process,” Science, 261: 157–58.
Acquisition Review Quarterly, 5, pp. 373–86; Marshall, R. A., 16. Lipke, W. H. (2003, Spring). “Schedule is different,” The
Ruiz, P., and Bredillet, C. N. (2008). “Earned value man- Measureable News, pp. 10–15; Lipke, W. H. (2009). Earned
agement insights using inferential statistics,” International Schedule. Lulu Publishing; Book, S. A. (2006, primavera).
Journal of Managing Projects in Business, 1: 288–94. “Earned schedule and its possible unreliability as an indica-
7. Morris, P. W. G. (1988). “Managing project interfaces—Key tor,” The Measureable News, pp. 24–30; Lipke, W. H. (2006,
points for project success,” in Cleland, D. I., and King, W. R. Fall). “Applying earned schedule to critical path analysis and
(Eds.), Project Management Handbook, 2nd ed. New York: more,” The Measureable News, pp. 26–30; Book, Stephen A.
Van Nostrand Reinhold, pp. 16–55. (2003, otoño). “Issues associated with basing decisions on
8. Baker, B. N., Murphy, D. C., and Fisher, D. (1988). “Factors schedule variance in an earned-value management system,”
affecting project success,” in Cleland, D. I., and King, W. R. National Estimator, Society of Cost Estimating and Analysis,
(Eds.), Project Management Handbook, 2nd ed. New York: pp. 11–15; www.earnedschedule.com; Vanhouckel, M., and
Van Nostrand Reinhold, pp. 902–19. Vandevoorde, S. (2007). “A simulation and evaluation of
9. Morris, P. W. G. (1988), como se cita. earned value metrics to forecast the project duration,” Journal
of the Operational Research Society, 58(10): 1361–74.
CAPÍTULO

14
Cierre y terminación del proyecto

Contenido del capítulo


PERFIL DE PROYECTO PERFIL DE PROYECTO
New Jersey cancela el proyecto Hudson River Tunnel El cierre de la Zion Nuclear Plant
INTRODUCCIÓN Terminación del proyecto
14.1 TIPOS DE TERMINACIÓN DEL PROYECTO INVESTIGACIÓN DE GERENCIA DE PROYECTOS EN
GERENTES DE PROYECTO EN LA PRÁCTICA SÍNTESIS
  Mike Brown, de Rolls-Royce Plc TERMINACIÓN DE PROYECTOS EN LA INDUSTRIA DE IT
14.2 TERMINACIÓN NATURAL—EL PROCESO DE Permitir reclamaciones y disputas
CIERRE 14.4 PREPARACIÓN DEL INFORME FINAL DEL
Finalizar el trabajo PROYECTO
Entregar el proyecto Conclusión
Obtener la aceptación del proyecto Resumen
Cosechar los beneficios Términos clave
Revisar cómo fue todo Preguntas para discusión
Archivar registros y documentos Estudio de caso 14.1 Proyecto Libra: terminar o no terminar
Disolver el equipo Estudio de caso 14.2 El proyecto que no podía morir
¿Qué impide los cierres efectivos de proyectos? Estudio de caso 14.3 La Armada cancela el desarrollo de su
14.3 TERMINACIÓN ANTICIPADA DE PROYECTOS   buque de guerra estrella
  Tomar la decisión de terminación anticipada Ejercicios en internet
Preguntas de ejemplo del examen para la certificación PMP®
Notas

Objetivos de aprendizaje
Al finalizar este capítulo, el estudiante estará en capacidad de:
1. Diferenciar las cuatro formas principales de la terminación de un proyecto.
2. Reconocer los siete pasos claves en la liquidación formal de un proyecto.
3. Entender las razones para la terminación anticipada de los proyectos.
4. Conocer los retos y los componentes de un informe final del proyecto.

CONCEPTOS BÁSICOS DE LOS FUNDAMENTOS PARA LA GERENCIA DE PROYECTOS (PROJECT


MANAGEMENT BODY OF KNOWLEDGE, PMBOK® GUIDE, 5A. EDICIÓN) CUBIERTOS EN ESTE CAPÍTULO
1. Cierre del proyecto (PMBOK®, sección 4.6).
2. Informe de desempeño (PMBOK®, sección 10.5).
3. Cierre de las adquisiciones (PMBOK®, sección 12.4).

470
 471

PERFIL DE PROYECTO

Caso—New Jersey cancela el proyecto Hudson River Tunnnel


En 2009, cuando dignatarios pusieron la primera piedra del proyecto Access to the Region Core (ARC) en el norte
de New Jersey, se suponía que había razones para celebrar el comienzo de un nuevo y brillante futuro. Aunque la
construcción de un túnel ferroviario bajo el río Hudson no era una idea nueva o particularmente difícil, se vio como
una necesidad clave. El proyecto fue propuesto por primera vez en 1995, y todos los gobernadores de New Jersey,
después esa fecha, habían apoyado públicamente la necesidad del túnel. Las razones eran de peso: el sistema de
trenes de cercanías que conecta Nueva York con New Jersey estaba soportado por un solo túnel de ferrocarril de
dos vías, construido hacía más de 100 años, en la congestionada estación Penn en el centro de Manhattan; ambas
pistas ya habían sobrepasado su capacidad y no tenían posibilidades de adaptarse al crecimiento de la ciudad. Cada
día, los pasajeros hacían más de 500,000 viajes por Penn Station, y la congestión y el hacinamiento de la estación
eran habituales. El proyecto era especialmente clave para los residentes de New Jersey, ya que la cantidad de pasa-
jeros a Nueva York se había más que cuadruplicado en los últimos 20 años: de 10 millones de viajes anuales a más
de 46 millones de viajes anuales de pasajeros. En las horas pico, la autoridad de tránsito de New Jersey operaba 20
de los 23 trenes desde Nueva York o hacia este. Con la construcción del ARC se duplicaría el número de trenes de
New Jersey, de 45 pasarían a 90, los cuales podrían entrar en Manhattan cada mañana en hora pico.
Ante la congestión y la necesidad manifiestas, el proyecto ARC fue concebido para incluir los siguientes
elementos:
• Dos nuevas pistas bajo los ríos Hudson y New Jersey Palisades
• Una nueva estación de pasajeros de seis pistas, que se conocerá como la “ New York Pennsylvania Station
Extension” (NYPSE) en la calle 34, con conexión a la estación Penn
• Un nuevo bucle ferroviario cerca de la estación Lautenberg Secaucus Junction para permitir el acceso a Nueva
York de dos líneas de trenes desde el norte de New Jersey
• Un patio de almacenamiento ferroviario intermedio en Kearny, New Jersey
Los proponentes también argumentaron las ventajas ambientales del proyecto, pues señalaron que el proyecto
ARC eliminaría 30,000 viajes diarios personales en automóvil, sacaba 22,000 automóviles de las carreteras, y las
millas recorridas por los vehículos se disminuirían en 600,000 al día. Así, se esperaba que el proyecto lograra reducir
las emisiones de gases de efecto de invernadero en cerca de 66,000 toneladas cada año.
La duración del proyecto ARC se estimó en ocho años, y entraría en servicio en 2017. El costo estimado del
proyecto fue significativo, considerando que la Federal Transito Administration (FTA) en su Informe Anual declaró
que el costo del proyecto sería de 8,700 de millones de dólares. Con el fin de compartir la carga de los costos del
proyecto, la financiación propuesta originalmente incluía las siguientes fuentes:
• El gobierno federal: 4,500 millones de dólares

FIGURA 14.1  Diseño de la plataforma del tren subterráneo de la estación de Penn para el
proyecto ARC
472 Capítulo 14  •  Cierre y terminación del proyecto

• Port Auhority de Nueva York y New Jersey: 3,000 millones de dólares


• New Jersey Turnpike Auhority: 1,250 millones de dólares
Una última característica importante del plan de financiación es que limitaba la exposición del gobierno federal ante
cualquier sobrecosto del proyecto, lo cual significa que el gobierno estaba obligado solamente con el importe original.
Cualquier exceso o desviación de costos del proyecto tendría que cubrirse exclusivamente por el estado de New Jersey.
Los contratos para diversas partes del proyecto comenzaron a adjudicarse después de una licitación pública
en junio de 2009, y el primer contrato de túneles se adjudicó en mayo de 2010. Después de un poco más de tres
meses, empezaron a escucharse ciertos estruendos en la oficina del gobernador de New Jersey debido a la viabili-
dad del proyecto. Chris Christie se postuló y fue elegido como gobernador con la promesa de frenar lo que muchos
veían como un gasto fuera de control por la legislatura del estado, y una de las propiedades y negocios con los
impuestos más altos del país. Christie se preocupaba cada vez más por los rumores acerca de los sobrecostos del
proyecto ARC. Peor aún, todas las proyecciones para la finalización del proyecto apuntaban a un costo más alto
que el estimado originalmente por 8,700 millones de dólares.
A principios de septiembre de 2010, el gobernador Christie ordenó la suspensión temporal del otorgamiento
de nuevos contratos para el proyecto hasta tanto su oficina pudiera estudiar más a fondo las proyecciones de
costos del proyecto. Este problema se puso de relieve cuando el Secretario de Transporte de Estados Unidos, Ray
LaHood, aunque partidario del túnel, admitió públicamente que las estimaciones federales mostraban que el pro-
yecto podría costar entre 1,000 y 4,000 millones por encima del presupuesto. Christie sospechaba que incluso esas
estimaciones podrían estar por lo bajo, lo cual ponía su estado a un paso de adquirir una nueva deuda poten-
cialmente enorme, en momentos en que la economía estaba mal y el estado buscaba desesperadamente medios
para recortar el gasto fuera de control. Como prueba adicional de las estimaciones de costos iniciales altamente
cuestionables, los partidarios de Christie señalaron el proyecto “Big Dig” de Boston recientemente concluido, que
comenzó con una etiqueta de precio inicial de 2,500 millones de dólares y finalmente su ejecución terminó cos-
tando más de 14,000 millones de dólares.
El 7 de octubre de 2010, el gobernador Christie canceló el contrato, argumentando que el estado no tenía
forma de pagar los sobrecostos. Al día siguiente, se acordó suspender temporalmente su orden de cancelación para
que pudiera tratar de resolver el dilema de la financiación con funcionarios federales de transporte y otros inte-
resados del proyecto. Después de un periodo de dos semanas analizando todas sus opciones, el gobernador hizo
oficial la cancelación. Christie dijo que dado el impacto de la recesión y la probabilidad de que se siguieran produ-
ciendo excesos de costos, el estado ya no estaría en capacidad de pagar los crecientes costos del túnel. Ya se habían
gastado más de 1,500 millones de dólares, en la construcción, ingeniería y adquisición de tierras en un proyecto
que se presupuestó en 8,700 millones de dólares, pero que el gobernador dijo, podría costar tanto como 14,000
millones de dólares. “La única medida prudente es ponerle fin a este proyecto “, dijo el gobernador Christie en una
conferencia de prensa en Trenton. “No puedo comprometer a los contribuyentes con gastos de nunca acabar.”1

INTRODUCCIÓN
Una de las características únicas de los proyectos, a diferencia de otras actividades o procesos organizaciona-
les, es que tienen una vida finita; en efecto, cuando planeamos el proyecto, también planeamos su extinción.
El ciclo de vida del proyecto mostrado en el capítulo 1 ilustra este fenómeno: la cuarta y última etapa del
proyecto se define como su terminación. La terminación del proyecto se compone de todas las actividades
involucradas en el cierre del proyecto. Es un proceso que establece la aceptación del proyecto por su patro-
cinador, la realización de diversos registros, la revisión final y edición de la documentación para reflejar su
estado final y el archivo de la documentación esencial del proyecto.
En este capítulo, vamos a explorar el proceso de terminación del proyecto y a analizar las medidas necesa-
rias para concluir efectivamente un proyecto. Los proyectos pueden terminarse por una variedad de razones. La
mejor circunstancia es el caso en cual un proyecto se ha completado con éxito y todas las actividades de cierre
del proyecto se han llevado a cabo para reflejar un trabajo bien hecho. Por otro lado, un proyecto puede concluir
prematuramente por diferentes razones. Puede cancelarse directamente, como en el caso del proyecto ARC
(anterior) o del destructor Zumwalt de la Armada (véase Estudio de caso 14.3). Este pudo llegar a ser irrelevante
con el tiempo y se cerró discretamente. Pudo llegar a ser tecnológicamente obsoleto debido a un desarrollo sig-
nificativo de la competencia. Pudo fallar por falta de apoyo de la gerencia, por cambios organizacionales o por
cambios de prioridad estratégica. O pudo terminarse debido a un evento catastrófico.
En resumen, aunque la mejor alternativa es terminar el proyecto por la culminación exitosa de sus
actividades, en realidad, muchos proyectos se concluyen lejos del cumplimiento de sus objetivos. Estas dos
14.1  Tipos de terminación del proyecto 473

alternativas se refieren a veces como terminación natural, cuando el proyecto alcanza sus objetivos y está
moviéndose a su conclusión lógica, y terminación no natural, cuando un cambio en las condiciones políti-
cas, económicas, de los clientes, o tecnológicas ha hecho que el proyecto se quede sin propósito alguno2. En
este capítulo, vamos a explorar los dos tipos de terminación, al examinar las medidas que debemos tomar
para cerrar efectivamente un proyecto durante su etapa de terminación.

14.1  TIPOS DE TERMINACIÓN DEL PROYECTO


Aunque el “cierre del proyecto” podría dar a entender que nos estamos refiriendo a un proyecto que se ha
completado y requiere una metodología sistemática para su cierre exitoso, como se anotó, los proyectos pue-
den terminarse por una variedad de razones. Las cuatro principales son:3
1. Terminación por extinción.  Este proceso se produce cuando el proyecto se detiene debido a una con-
clusión exitosa o no exitosa. En el caso de éxito, el proyecto se ha transferido a sus usuarios previstos y
todas las actividades de su fase final de terminación se han llevado a cabo. Sin embargo, ya sea un éxito o
no, durante la terminación del proyecto, el presupuesto final se audita, los miembros del equipo reciben
nuevas asignaciones de trabajo, y todos los bienes materiales empleados en el proyecto se dispersan o se
transfieren, de acuerdo con las políticas de la compañía o con los términos contractuales.
2. Terminación por adición.  En este caso, la conclusión de un proyecto se realiza debido a su institucio-
nalización como una parte formal de la organización principal. Por ejemplo, supongamos que un nuevo
diseño de hardware de Apple Computer ha sido tan exitoso que la compañía (la organización del proyecto)
en lugar de disolver el equipo del proyecto, lo convierte en un nuevo grupo de trabajo. En efecto, el pro-
yecto se ha “promovido” a un estatus formal, jerárquico dentro de la organización. El proyecto de hecho se
ha terminado, pero su éxito lo ha adicionado a la estructura organizacional.
3. Terminación por integración.  La integración representa un método común, pero sumamente complicado
para abordar proyectos exitosos. Los recursos del proyecto, incluido el equipo del proyecto, se reintegran dentro
de la estructura existente de la organización después de la conclusión del proyecto. Tanto en organizaciones
matriciales como en las de proyectos, el personal liberado de las tareas del proyecto es reabsorbido dentro de
sus departamentos funcionales para realizar otras funciones, o simplemente espera por nuevas asignaciones de
proyectos. En muchas organizaciones, en este punto no es raro perder miembros claves de la organización. Es
posible que hayan disfrutado de la atmósfera y de su desempeño dentro del equipo del proyecto que la idea de
reintegrarse a su antigua organización no es atractiva para ellos, y prefieren abandonar la compañía para acome-
ter nuevos desafíos en proyectos. Por ejemplo, el gerente de proyecto que dirigió el desarrollo e implantación de
un sistema de información geográfica (geographic information system: SIG) para la ciudad de Portland, Maine,
se marchó poco después de la finalización del proyecto en lugar de aceptar un trabajo funcional para desempe-
ñarse como administrador del sistema. Fue más grato el reto de gestionar el proyecto que mantenerlo.

RECUADRO 14.1

GERENTES DE PROYECTO EN LA PRÁCTICA


Mike Brown, de Rolls-Royce Plc
Con una carrera de 40 años en gerencia de proyectos, Mike Brown (véase la figura 14.2) puede reclamar con
seguridad que él ha visto y hecho casi todo en lo que respecta a la ejecución de proyectos. Con una trayectoria
que incluye grados en química industrial y en gerencia de proyectos de ingeniería civil, Brown ha trabajado en
grandes proyectos de construcción en todo el mundo. Su hoja de vida, una lectura fascinante, incluye: (1) ejecu-
ción de proyectos de investigación y desarrollo en el sector farmacéutico; (2) construcción de refinerías y plantas
petroquímicas; (3) liderazgo en proyectos de energía e infraestructura; y (4) gerencia de una variedad de progra-
mas de desarrollo aeronáutico. Entre sus proyectos más importantes están el de un complejo de tanques de gas
natural líquido y un proyecto de construcción de una planta de energía en India de 500 millones de dólares.
Brown ha trabajado en varios lugares exóticos, entre ellos Sri Lanka, India, África y la Cuenca del Pacífico.
Sin embargo, en su trabajo actual con Rolls-Royce Corporation, Brown ha encontrado mayores opor-
tunidades para poner en práctica la riqueza de conocimientos que ha acumulado. Como lo describe Brown:
Mi cargo es director del Center for Project Management, que es el Centro de Excelencia de
Rolls-Royce para la Gerencia de Proyectos. El Centro tiene la tarea de dirigir el mejoramiento en
474 Capítulo 14  •  Cierre y terminación del proyecto

gerencia de proyectos, programas y portafolios en toda la empresa, con el patrocinio del Project
Management Council, el grupo de gerencia de más alto nivel responsable de la gerencia de pro-
yectos en Rolls-Royce.
A nivel personal, soy coach, mentor, doy seminarios y hago presentaciones en la compañía
a personas y grupos de practicantes. Después de haber desarrollado programas de maestría en la
Universidad de Mánchester y Penn State ocho años atrás, en la actualidad hay unos 125 graduados
de maestría del Reino Unido y 50 en América del Norte. En conjunto, esta red es capaz de apoyar las
actividades de mejoramiento y se está convirtiendo en un poderoso motor del cambio.
Además de mi rol interno, represento a Rolls-Royce en el mundo como gerente de proyec-
tos. Esto incluye la representación de la empresa en diversos foros, además de presidir el British
Standards Committee, responsable del Project Management Standard.
Cuando se le preguntó acerca de qué lo ha mantenido tan comprometido con la profesión de gerente de
proyectos, Brown respondió con las siguientes reflexiones:
En mi juventud el reto era sacar adelante tres aspectos a la vez, resolver problemas, apagar in-
cendios y trabajar con un gran equipo, todos dirigidos hacia un mismo objetivo. Al madurar,
evidencié que uno resuelve los problemas de los proyectos antes de “empezarlos”, mediante el
pensamiento estratégico y acciones en áreas como la gerencia de requisitos, la gerencia de los
interesados, la gerencia del valor y el desarrollo sólido de casos de negocios. Además, no hay
muchas “profesiones” en las que se puede tocar, sentir y experimentar los frutos del trabajo. En
la gerencia de proyectos sí se puede.
Cuando se le preguntó sobre las experiencias más memorables de su carrera, Brown respondió:
Cada proyecto es único y, por tanto, en muchos sentidos, cada proyecto me ha ofrecido sus pro-
pias experiencias memorables. Sin embargo, uno que destaco, fue un proyecto de construcción
en India, que incluyó el desarrollo de un complejo de fertilizantes Para el levantamiento de obje-
tos pesados, se utilizó de todo, desde grúas estándar hasta mi pieza favorita de los equipos: ¡un
pesado elefante! ¡Alguien (probablemente, un oficial de seguridad) había pintado un número de
carga en el lomo del elefante!
Supongo que una de las razones por las que disfruto el trabajo es por su papel muy importante
en el desarrollo de cualquier persona dentro de una organización. Como jefe de proyecto se tienen
todas las responsabilidades de un gerente general. Usted trata con su propia gente, presupuestos,
clientes y problemas técnicos. Usted toma decisiones claves a diario y dirige las operaciones. En re-
alidad, con la excepción del CEO de la empresa, un gerente de proyectos tiene la mayor autonomía
y responsabilidad dentro de una organización. Pero también tiene una especie de magia para hacer
que funcione. Usted no tiene mucha autoridad formal, por lo que tiene que entender cómo influir,
dirigir y ganarse el respeto de su equipo, todo basado en su liderazgo y en el ejemplo personal.

FIGURA 14.2  Mike Brown de


Rolls-Royce Plc.

.
4. Terminación por inanición.  La terminación por inanición puede suceder por varias razones. Puede
haber razones políticas por mantener un proyecto oficial “en libros”, a pesar de que la organización no
tenga la intención de que finalice con éxito o de anticipar su terminación. El proyecto puede tener un
patrocinador poderoso que debe aplacarse manteniendo su “proyecto personal.“ A veces, los proyectos
no se pueden continuar por recortes presupuestarios generales, pero la organización puede mantener un
14.2  Terminación natural—El proceso de cierre 475

número de ellos en archivo, de modo que cuando la situación económica mejore, estos proyectos pue-
den reactivarse. Meredith y Mantel4 argumentan que la terminación por inanición no es un acto firme
de terminación absoluta, sino más bien una forma deliberada de abandono en la cual el presupuesto del
proyecto se disminuye lentamente hasta el punto que el proyecto no puede seguir siendo viable.

14.2  TERMINACIÓN NATURAL—EL PROCESO DE CIERRE


Cuando un proyecto avanza hacia su conclusión natural, se requiere una serie de actividades para cerrarlo.
La figura 14.3 proporciona un modelo simple para identificar las actividades y responsabilidades finales del
gerente del proyecto y de su equipo.5 Si el eje horizontal representa una línea de tiempo, podemos ver las
actividades que se producen tanto secuencial como simultáneamente. Por ejemplo, algunas de las activida-
des identificadas, como finalizar el trabajo, entregar el proyecto y obtener la aceptación del proyecto, están
destinadas a desarrollarse en serie, una actividad después de la otra. Sin embargo, al mismo tiempo que estas
tareas se realizan, otras actividades ocurren simultáneamente, como completar la documentación, archivar
registros y disolver el equipo. Por tanto, el proceso de cierre de un proyecto es complejo, e implica múltiples
actividades que tienen que ocurrir a lo largo de un periodo definido. Vamos a considerar, en orden, estas
actividades y los pasos necesarios para completarlas.

Finalizar el trabajo
Cuando el proyecto avanza hacia su finalización, aún se requiere llevar a cabo una serie de tareas, como la
depuración final en un proyecto de desarrollo de software. Al mismo tiempo, las personas que trabajan en
el proyecto, naturalmente, tienden a perder el foco, pues empiezan a pensar en sus nuevas asignaciones del
proyecto o en su liberación del equipo. El reto para el gerente de proyecto es mantener al equipo concentrado
en las actividades finales, sobre todo porque los elementos principales del proyecto están por entregarse. Un
proceso ordenado para realizar las tareas finales, por lo general, requiere el uso de una lista de verificación
como herramienta de control.6 Por ejemplo, en la construcción de una casa, el contratista deberá caminar
por la casa casi terminada con el nuevo propietario, marcando en una lista de verificación las tareas finales o
modificaciones que se necesitan antes de la finalización del proyecto.
Completar las actividades finales del proyecto es, a menudo, tanto un reto motivacional como un pro-
ceso técnico o administrativo para el gerente del proyecto. Las listas de verificación y otras herramientas sim-
ples de control constituyen un elemento importante en la estructura de las tareas finales, el cual le recuerda
al equipo del proyecto que, aunque la mayor parte del trabajo se ha terminado, el proyecto aún no se ha
entregado. El uso de listas de verificación también demuestra que, incluso en los mejores proyectos, puede
ser necesario realizar modificaciones o ajustes antes de que el proyecto sea aceptable para el cliente.7

Finalizar el
trabajo
Entregar el
proyecto
Actividades

Obtener la
aceptación
del proyecto
Cosechar los
beneficios
Revisar cómo
fue todo

Archivar registros y documentos

Disolver el equipo

Tiempo
FIGURA 14.3  Los siete elementos de la gerencia del cierre del proyecto
476 Capítulo 14  •  Cierre y terminación del proyecto

Entregar el proyecto
Transferir el proyecto a su usuario previsto puede ser un proceso simple o muy complejo, pues depende de
los términos contractuales, del cliente (ya sea interno o externo), de las condiciones ambientales y de otros
factores. El proceso en sí, por lo general, implica una transferencia formal de la propiedad del proyecto al
cliente, incluidos los términos y condiciones de esa entrega. Esta transferencia puede requerir una cuidadosa
planeación y de actividades y procesos específicos. La transferencia no solo implica el cambio de propiedad,
sino que también requiere establecer programas de entrenamiento para los usuarios, transferir y compartir
diseños técnicos y funcionalidades, entregar todos los planos y especificaciones de ingeniería disponibles,
entre otros aspectos. Por tanto, según la complejidad del proceso de transferencia, las actividades de entrega
pueden requerir una planeación meticulosa.
Una forma de gerenciar riesgos en grandes proyectos industriales, que se ha popularizado entre clientes
extranjeros, es rechazar la aceptación inicial de un proyecto hasta después de un periodo de transición en el
cual el contratista del proyecto debe demostrar la viabilidad del proyecto. En el Reino Unido, estos acuerdos
se refieren a menudo como iniciativas de financiación privada (Private Finance Initiatives: PFI) y se utilizan
para proteger del riesgo financiero excesivo a la agencia que contrata el proyecto que esta desarrollándose.8
Por ejemplo, suponga que su empresa acaba de construir una gran planta de fundición de mineral de hierro
para Botsuana con un costo para el país de 1,500 millones de dólares. En estas circunstancias, en las que
Botsuana considera que este tipo de inversión es muy arriesgada, primero requeriría a su empresa operar la
planta durante algún tiempo para asegurarse de que todas las características técnicas se cumplen. Se trata de
la opción de construir, operar y transferir (built, operate, and transfer: BOT) para grandes proyectos, que
es un método para permitir que el propietario final del proyecto pueda mitigar el riesgo, a corto plazo. Una
modificación de esta alternativa BOT es construir, apropiar, operar y transferir (Built, Own, Operate, and
Transfer: BOOT). En un contrato BOOT, el contratista del proyecto asume la propiedad inicial de la planta
por un periodo determinado para limitar la exposición financiera del cliente hasta que todos los problemas
se hayan resuelto contractualmente. La desventaja de los contratos BOT y BOOT para las organizaciones de
proyectos es que requieren que el contratista asuma un alto riesgo financiero durante la operación o mientras
asume la propiedad del proyecto durante un periodo específico. Por tanto, a pesar de que sirven para prote-
ger al cliente, exponen al contratista a graves perjuicios potenciales, en caso de fracaso del proyecto.

Obtener la aceptación del proyecto


Un estudio de investigación sobre los factores claves de éxito de los proyectos encontró que la aceptación del
cliente representa una determinante importante del éxito del proyecto.9 “La aceptación del cliente” repre-
senta que la simple transferencia del proyecto al cliente no es suficiente para asegurar su satisfacción con
aquel, su uso y el reconocimiento de sus beneficios. Muchos de nosotros sabemos, por experiencia propia,
que obtener la aceptación del cliente puede ser complicado y complejo. Los clientes pueden estar inseguros
acerca de sus capacidades o nivel de conocimientos técnicos. Por ejemplo, en la transferencia de proyectos
de IT a los clientes, es común que experimenten una confusión inicial o una incomprensión acerca de las
características del producto final. Algunos clientes deliberadamente se niegan a aceptar incondicionalmente
un proyecto por temor a que después de su concesión, van a perder la posibilidad de pedir modificaciones o
correcciones de errores evidentes. Finalmente, en función de cómo nuestro equipo de proyecto haya mante-
nido lazos de comunicación con el cliente durante el desarrollo del proyecto, el producto final puede o no ser
lo que el cliente realmente deseaba.
Considerando que el proceso de obtener la aceptación del cliente puede ser complicado, hay que comen-
zar a planear, con mucha antelación, la transferencia del producto final al cliente y la elaboración, en caso
necesario, de un programa para facilitar la transición de la propiedad a los clientes. En otras palabras, cuando
iniciamos la planeación de la ejecución del proyecto, tenemos que empezar también la planeación de la trans-
ferencia y el uso del proyecto. El equipo del proyecto debe comenzar por hacerse preguntas importantes,
como: “¿Qué objeciones podrían hacer los clientes del proyecto, cuando esté terminado?” y “¿cómo podemos
eliminar las preocupaciones del cliente en relación con el valor comercial o técnico del proyecto?”

Cosechar los beneficios


Se inician proyectos para resolver problemas, aprovechar oportunidades, o servir a un objetivo o conjunto
de objetivos específicos. Los beneficios de la realización de un proyecto deben ser fáciles de determinar; de
hecho, se podría argumentar que los proyectos se crean con el propósito de lograr algún beneficio para sus
14.2  Terminación natural—El proceso de cierre 477

organizaciones matrices. Como resultado de ello, la idea de cosechar estos beneficios sugiere que estemos en
condiciones de evaluar el valor que el proyecto agrega, ya sea para un cliente externo, para nuestra propia
empresa, o para ambos.
Los beneficios se presentan de muchas formas y se relacionan con el proyecto que está ejecutándose.
Por ejemplo, en un proyecto de construcción, los beneficios pueden acumularse como resultado del agrado
del público con el proyecto por razones estéticas o funcionales. Para un proyecto de software, los beneficios
pueden incluir una mayor eficiencia operativa y, si se diseña para el mercado comercial, altos beneficios y
mayor cuota de mercado. El fondo de la cosecha de beneficios sugiere que la organización del proyecto debe
identificar los resultados positivos de la realización del proyecto.
Sin embargo, en la práctica puede ser difícil evaluar con precisión los beneficios de un proyecto,
sobre todo a corto plazo. Por ejemplo, en un proyecto creado para instalar y modificar un paquete de pla-
neación de recursos empresariales (Enterprise Resource Planning: ERP), los beneficios pueden ser descu-
biertos en un periodo en el que el paquete le permita a la empresa ahorrar dinero en la planeación, adquisi-
ción, almacenamiento y uso de materiales de producción para sus operaciones. Los verdaderos beneficios
del sistema de ERP pueden no ser evidentes durante varios años, hasta que todos los fallos se hayan expul-
sado del software. Por otra parte, un proyecto bien ejecutado y que cumple con el presupuesto puede
fallar en el mercado debido a un avance tecnológico inesperado de un competidor que vuelve obsoleto el
proyecto, sin importar lo bien que se haya hecho. Por ejemplo, algunos argumentan que el compromiso de
Toyota para el lanzamiento de seis nuevos automóviles híbridos en el periodo 2011-2012 pudo no haber
sido una estrategia bien razonada, dado el nuevo vehículo “totalmente eléctrico” ofrecido por Nissan y la
dinámica más eficiente de los fabricantes de automóviles híbridos de Estados Unidos. La preocupación
de los observadores de la industria era que el híbrido, en su forma actual, era un “producto puente” que
podía sustituirse por tecnologías más nuevas y aún más eficaces (por ejemplo, el gas de nueva generación
o los motores propulsados por etanol) durante el mismo intervalo en el que Toyota esperaba introducir
sus nuevos productos.
La clave para comenzar a cosechar los beneficios de un proyecto es desarrollar primero un sistema de
medición efectivo y significativo que identifique los objetivos, los plazos y las responsabilidades involucra-
das en el uso del proyecto y la evaluación de valor. Por ejemplo, un sistema de evaluación del proyecto debe
medir como mínimo lo siguiente:10
1. El criterio por el cual se medirán los beneficios del producto o servicio.
2. Los momentos en el tiempo en los que se llevarán a cabo la medición o evaluación.
3. La persona que ha aceptado la responsabilidad de realizar la medición o evaluación de la forma y en los
momentos acordados.
Todos estos asuntos deben resolverse con antelación, ya sea como parte de la declaración del alcance del
proyecto o durante el desarrollo del proyecto.

Revisar cómo fue todo


Uno de los elementos más importantes en el cierre del proyecto implica un análisis profundo de las leccio-
nes aprendidas, basado en una revisión realista y crítica del proyecto, es decir, sus puntos altos y bajos, las
dificultades no anticipadas y los elementos que proporcionan sugerencias para proyectos futuros. Incluso en
empresas que revisan las lecciones aprendidas, puede ocurrir una serie de errores en esta etapa, que incluye:
• Equivocarse al identificar errores sistemáticos.  Es de naturaleza humana atribuir los fallos o errores
a causas externas, y no internas. Por ejemplo, es más fácil aceptar “El cliente cambió las especifica-
ciones” que esta: “No hemos hecho suficiente como para determinar las necesidades del cliente del
proyecto.“ Estrechamente relacionado con este error está el deseo de percibir los errores como si se
presentaran una sola vez o fueran eventos no recurrentes. En lugar de revisar nuestros sistemas de
gerencia de proyectos para ver si los errores podrían ser el resultado de problemas de fondo con estos,
muchos de nosotros preferimos la solución más fácil de creer que estos resultados eran impredecibles,
que se presentaron una sola vez y que no es probable que repita, y que, por tanto, no podríamos haber-
nos preparado para ellos y no hay por qué prepararse para ellos en el futuro.
• Aplicar erróneamente o interpretar mal las enseñanzas apropiadas basadas en eventos.  Un error
relacionado con una mala interpretación se produce cuando los miembros del equipo del proyecto
o los que revisan el proyecto, identifican erróneamente el origen del problema hallado. A veces las
lecciones correctas de un proyecto terminado se ignoran o alteran para reflejar un punto de vista
478 Capítulo 14  •  Cierre y terminación del proyecto

prevaleciente. Por ejemplo, un fabricante de computadores llegó a estar tan convencido de que la
tecnología que su equipo estaba desarrollando era superior al de la competencia, que el gerente ruti-
nariamente ignoró o malinterpretó las opiniones contrarias, tanto dentro de su propia compañía
como durante las sesiones de grupos focales con los clientes potenciales. Cuando el proyecto fracasó
en el mercado, la creencia común dentro de la empresa era que marketing no había podido soportar
adecuadamente el producto, independientemente de que marketing hubiera presentado durante
meses datos sugiriendo que el proyecto era un error.
• No poder transmitir las lecciones aprendidas.  Aunque los proyectos de la organización se carac-
terizan por ser procesos únicos y realizados por una sola vez, estos cuentan con suficientes áreas de
superposición, en particular en el ámbito de una sola empresa, para que la aplicación de las lecciones
aprendidas sea de gran utilidad. Estas lecciones aprendidas son una forma valiosa de aprendizaje para
la organización, mediante la cual los gerentes de proyecto novatos pueden acceder y aprender de la
información de proyectos anteriores proporcionada por otros gerentes de proyecto. El éxito de un
proceso de lecciones aprendidas es altamente dependiente de la imposición de archivar la información
histórico-crítica por los altos directivos. Aunque todos los proyectos son, hasta cierto punto, únicos,
esa singularidad nunca debería ser una excusa para no pasarle las lecciones aprendidas al resto de la
organización. En el Ejército de Estados Unidos, por ejemplo, las lecciones aprendidas de proyectos
anteriores se archivan y se almacenan electrónicamente. Se les exige a todos los gerentes de programas
que accedan a estos registros previos teniendo en cuenta el tipo de proyecto que estén manejando y
planteen anticipadamente respuestas detalladas a los problemas que se puedan enfrentar durante la
ejecución del proyecto.
Para sacar el máximo provecho de las reuniones de lecciones aprendidas, los equipos de proyecto
deben seguir tres reglas importantes:
1. Establecer reglas claras de comportamiento para todos los participantes de la reunión. Todos
los participantes deben entender que la clave para obtener beneficios duraderos de una reunión de
las lecciones aprendidas es la comunicación eficaz. La atmósfera debe promover la interacción, en
lugar sofocarla.
2. Describir, lo más objetivamente posible, lo que ocurrió.  Las personas suelen tratar de darles un
“giro” particular a los acontecimientos, sobre todo cuando las acciones podrían reflejarlos negativa-
mente a ellos mismos. El objetivo de las reuniones de lecciones aprendidas es recapitular, lo más obje-
tivamente factible, una serie de eventos desde tantos puntos de vista como sea posible, con el fin de
reconstruir la secuencia de eventos, los factores desencadenantes de los problemas, los lugares donde
se presentó falta de comunicación o mala interpretación, y así sucesivamente.
3. Buscar soluciones al problema, no culpables.  Las sesiones de lecciones aprendidas solo funcionan
cuando la atención se centra en la resolución de problemas, no en el señalamiento de los culpables
de los errores. Una vez se envíe el mensaje de que estas sesiones son formas para que la alta geren-
cia encuentre chivos expiatorios de proyectos fallidos, ellas quedan sin valor alguno. Por otro lado,
cuando el personal descubre que las reuniones de lecciones aprendidas son oportunidades para que
todos reflexionen sobre acontecimientos importantes y sobre maneras de promover prácticas de
éxito, la actitud defensiva se evaporará a favor de las reuniones como medio para resolver problemas
del proyecto.

Archivar registros y documentos


La conclusión de un proyecto implica una enorme cantidad de papeleo para los procesos de documen-
tación y de registro, cerrar las cuentas de recursos y, de ser necesario, realizar un seguimiento de los
acuerdos y términos contractuales y de las condiciones legales cumplidas. Algunos de los elementos más
importantes de esta fase son:
1. Documentales.  Todos los registros del proyecto deben archivarse en un repositorio central para que
sean de fácil acceso. Estos registros incluyen todos los documentos de programación y planeación,
todo el material de seguimiento y control, los registros de materiales o del uso de otros recursos, solici-
tudes y órdenes de cambio del cliente, aprobaciones de cambio de especificaciones, etcétera.
2. Legal.  Todos los documentos contractuales deben registrarse y archivarse. Estos incluyen todos los
términos y condiciones, el recurso legal, penalidades, cláusulas de incentivos y otros registros legales.
14.2  Terminación natural—El proceso de cierre 479

3. Costo.  Todos los registros contables deben cerrarse cuidadosamente, incluidos los registros de
contabilidad de costos, listas de materiales y otros recursos utilizados, así como de cualquier com-
pra importante, bonificaciones u otras partidas presupuestarias. Todas las cuentas de costos rela-
cionadas con el proyecto deben estar cerradas en este momento, y los fondos no utilizados o los
recursos del presupuesto que todavía están en la cuenta del proyecto deben revertirse al presu-
puesto general de la empresa.
4. Personal.  Los costos y otros cargos por todo el personal del equipo del proyecto deben tenerse en
cuenta, su tiempo debe cargarse a las cuentas del proyecto y también debe identificarse cualquier
sobrecosto o beneficio para la empresa. Además, cualquier contrato de personal no empleado en el
proyecto, como contratistas o consultores, deben liberarse y estas cuentas pagarse y cerrarse.
La figura 14.4 muestra, a manera de ejemplo, algunas páginas de un documento detallado de cierre de un
proyecto. Entre los elementos importantes en el documento completo aparecen unas revisiones requeridas
que incluyen:
• Programación general y de la gerencia de proyectos—evaluación de las especificaciones generales del
proyecto, planes, recursos, costos y evaluación de riesgos.
• Comercial—determinación de que el “caso de negocio” que dirigió el proyecto sigue siendo válido.
• Mercado y ventas—sobre la base de las políticas de precios, pronósticos de ventas y retroalimentación
de los clientes.
• Calidad del producto—verificación de todas las revisiones de diseño y las solicitudes de cambio
pertinentes.
• Manufactura —calidad de fabricación, capacidad de producción y gerencia de la producción en la
ejecución del proyecto.
• Cadena logística de suministro—aseguramiento de que la cadena de suministro del proyecto, el cum-
plimiento de la entrega y la calidad de los proveedores cumplen normas aceptables.
• Posventa —análisis de entrega, expectativas del cliente y el soporte al proyecto durante la etapa de
transferencia.
• Salud, seguridad y medio ambiente (health, safety & environment: HS&E)—verificación de que se
han identificado y documentado todos los efectos HS&E.

Disolver el equipo
El cierre de un proyecto representa el final de la relación del equipo del proyecto, fundada originalmente en
sus deberes compartidos para apoyar el proyecto. La disolución del equipo del proyecto puede ser un proceso
muy informal (celebración de una fiesta final) o muy estructurada (realización de evaluaciones de desem-
peño y evaluaciones detalladas de trabajo para todos los miembros del equipo). La formalidad del proceso de
disolución depende, en gran medida, del tamaño del proyecto, la autoridad otorgada al gerente del proyecto,
el compromiso de la organización con el proyecto, entre otros factores.
En el capítulo 2 señalamos que, en algunas organizaciones de proyectos, cierto grado de estrés acom-
paña la disolución del equipo, debido a la incertidumbre de muchos miembros sobre su futuro en la empresa.
Sin embargo, en la mayoría de casos, los miembros del equipo del proyecto simplemente son trasladados de
nuevo a sus deberes departamentales o funcionales a la espera de una nueva cita para futuros proyectos. La
investigación demuestra claramente que cuando los miembros del equipo han experimentado resultados
“psicosociales” positivos en el proyecto, son más propensos a trabajar colaborativamente en un futuro, tienen
sentimientos más positivos hacia los proyectos futuros, y entran en ellos con mayor entusiasmo.11 Por tanto,
la finalización de las relaciones del equipo de proyecto nunca deben manejarse de manera improvisada o
casual. Sí bien es cierto que los miembros del equipo ya no pueden afectar positivamente el proyecto recién
terminado, la forma en que se celebren sus logros puede generar una fuerza poderosa de motivación positiva
para futuros proyectos.

¿Qué impide los cierres efectivos de proyectos?


El desarrollo de un sistema para capturar el conocimiento de los proyectos terminados es tan importante
que parece que la necesidad de tal práctica sería obvia. No obstante, la investigación sugiere que muchas
organizaciones no realizan liquidaciones efectivas de proyectos, recopilación sistemática, almacenamiento y
480 Capítulo 14  •  Cierre y terminación del proyecto

Presidente: el presidente de la reunión es el gerente del proyecto o cualquier otra persona instruida por él.

Área Participante Comentario/Firma de aprobación


Ingeniería
Manufactura
Desarrollo de producto y
tecnología
Seguridad/Calidad
Finanzas
Marketing

Otros participantes
Compras
Jurídica

Revisión de decisiones
El presidente debe firmar en la casilla correspondiente y escribir el límite de gastos.

NIVEL DE APROBACIÓN
a. Proceder a la siguiente fase
b. Proceder con acciones a la próxima fase
c. Detener hasta que se hayan realizado las acciones designadas
d. No realizar más trabajos
LÍMITES FINANCIEROS
Límite de gasto aprobado para la siguiente fase $

Notas adicionales/Comentarios/Resumen

Acciones derivadas
Esta hoja de acción debe utilizarse para documentar las acciones requeridas por la revisión y de acuerdo con las
condiciones de aprobación. El equipo del proyecto es responsable de realizar todas las acciones a la fecha de
vencimiento. El empleado mencionado será responsable de la revisión en o antes de la fecha de vencimiento, si
la acción se ha efectuado. El proyecto continuará en situación de riesgo hasta que todas las acciones se hayan
completado y aceptado.
FIGURA 14.4  Páginas de muestra de un documento de cierre de proyecto
14.2  Terminación natural—El proceso de cierre 481

.
Fecha de Persona Aceptado
Acción No. Descripción de la acción vencimiento responsable /Firma

FIGURA 14.4  Continuación


482 Capítulo 14  •  Cierre y terminación del proyecto

Gerencia de proyectos Sí No Comentarios/Referencia


Revisiones requeridas
¿Se han aclarado todas las medidas de la revisión del
proyecto?
¿Se ha realizado una revisión de cierre de la ejecución? Ref:
¿Se han aclarado todas las acciones surgidas de la revisión
del proyecto?
Lecciones aprendidas
¿Se han registrado y archivado las lecciones aprendidas del
proyecto?
¿Se han preparado planes de acción para el seguimiento
del proyecto?
Especificaciones del proyecto
Desde la última revisión, ¿se han recopilado y reportado las
especificaciones del proyecto?
Plan del proyecto
¿Se ha actualizado y publicado el plan del proyecto? Ref:
Desde la última revisión, ¿se han alcanzado todos los hitos
de los clientes planificados?
Desde la última revisión, ¿se han alcanzado todos los hitos
internos planificados?
Recursos del proyecto
¿Todos los recursos previstos se han liberado, de acuerdo
con el cronograma del proyecto?
¿Se han comparado los recursos planeados versus el uso
real de los recursos y se han actualizado las métricas de los
departamentos pertinentes?
Costos del proyecto
¿El proyecto ha cumplido sus objetivos de costos?
Evaluación de los riesgos del proyecto
¿Se dispone de una evaluación de riesgos actualizada?
General del proyecto
¿El equipo ha realizado una revisión de todo el proyecto? Ref:
¿Se ha confirmado que el cliente haya recibido todos los
entregables acordados, incluidos documentos, maquetas,
etcétera?
¿Se ha preparado el informe de cierre del proyecto?
¿Hay necesidad de iniciar algún seguimiento del proyecto?
¿Se han cerrado todas las cuentas del proyecto?

FIGURA 14.4  Continuación


14.2  Terminación natural—El proceso de cierre 483

Negocio Sí No Comentarios/Referencia
Caso de negocio
¿Es aceptable el costo actual del producto? Ref:
¿Las hipótesis del ciclo de vida del producto y su efecto en
el precio del producto siguen siendo válidas?
¿Se han cumplido los objetivos de cumplimiento al cliente,
según el cronograma del proyecto?
¿El desempeño comercial ha coincidido con los criterios Ref:
financieros del caso de negocio inicial?
¿Se ha actualizado el modelo de negocio?
¿Todavía son aceptables otras medidas financieras
(incluidas TIR y VPN)?
¿Lo que resta del proyecto sigue siendo viable según este
modelo de caso de negocios?

Mercado y ventas Sí No Comentarios/Referencia


Política de precios
¿La política de precios original de los equipos y piezas de
repuesto sigue siendo válida?
Pronóstico de ventas
¿Todos los cronogramas de ventas han sido acordados,
incluidos los cronogramas de atención al cliente?
Retroalimentación al cliente
¿Se han recibido comentarios de los clientes sobre los
resultados del proyecto?
¿Se han creado planes de acción para identificar
oportunidades de mejora, con base en los comentarios
de los clientes?

Calidad del producto Sí No Comentarios/Referencia


Diseño
Desde las revisiones anteriores, ¿los cambios de diseño se
han listado?
¿Se han implementado todas las solicitudes de cambio de
diseño (design change requests: DCRs)?
¿Todas las acciones de revisión de diseño de ingeniería Ref:
se han realizado?
¿La certificación de los resultados del proyecto está Ref:
actualizada y aprobada?
¿Se ha revisado el proceso de diseño y documentado las
lecciones aprendidas?
¿Las lecciones aprendidas se han resumido y se han intro-
ducido en la base de datos?

FIGURA 14.4  Continuación


484 Capítulo 14  •  Cierre y terminación del proyecto

puesta a disposición, para la futura difusión de las lecciones que han aprendido de sus proyectos12. ¿Por qué
el cierre del proyecto se maneja al azar o de manera ineficaz en muchas empresas? Algunas de las razones
más comunes son:
• Tener firmado el proyecto desalienta otras actividades de liquidación.  Una vez que el proyecto se
ha pagado o aceptado por el cliente, la actitud predominante, parece, indica que no hay que tomar más
medidas. Sí se obtiene demasiado pronto el “sello de aprobación” final del proyecto, en lugar de abordar
cuestiones importantes, se genera el fuerte efecto de desalentar cualquier acción adicional en el proyecto.
Las actividades finales se prolongan o se ignoran con la esperanza de que ya no sean necesarias.
• La presión asumida por la urgencia en todos los proyectos conduce a tomar atajos en la fase
final.  Cuando una empresa ejecuta varios proyectos al mismo tiempo, sus recursos de gerencia de
proyectos a menudo se extienden al límite. Una actitud común es sugerir que no es posible retrasar el
inicio de nuevos proyectos simplemente para completar todas las actividades de la liquidación de los
que esencialmente están terminados. En efecto, en estas empresas argumentan que están demasiado
ocupados para terminar adecuadamente sus proyectos.
• A las actividades de liquidación se les da una prioridad baja y se ignoran fácilmente.  A veces, las
empresas asignan actividades finales de la liquidación a personas que no formaban parte del equipo del
proyecto, como gerentes de nivel medio o contadores con poco conocimiento real del proyecto. Por
tanto, su análisis es a menudo superficial o basado en una comprensión limitada del proyecto, de sus
objetivos, problemas y soluciones.
• El análisis de lecciones aprendidas se ve simplemente como un proceso de archivo.  Muchas organi-
zaciones requieren el análisis de las lecciones aprendidas solo para archivarlo rápidamente y olvidarse
que alguna vez ocurrieron. Cuando los miembros de la organización se enteran de que estos análisis no
están destinados a una difusión más amplia, en consecuencia, no los toman en serio, no se molestan en
leer los informes anteriores, y realizan un mal trabajo de preparación de sus propios informes.
• Las personas pueden asumir que debido a que todos los proyectos son únicos, el traspaso real de
proyecto a otro es mínimo.  Este mito ignora el hecho de que si bien los proyectos pueden ser únicos,
también pueden tener varios puntos en común. Por ejemplo, si los proyectos tienen el mismo cliente,
emplean tecnologías similares, utilizan contratistas o consultores similares o emplean personal similar
durante un periodo prolongado, pueden tener muchos más puntos en común. Aunque cada proyecto
es único, eso no implica que todas las circunstancias de gerencia de proyectos sean igualmente únicas
o que el conocimiento no se pueda transferir.
Desarrollar un proceso natural de cierre del proyecto le ofrece a la organización del proyecto una serie de
ventajas. Primera, les permite a los gerentes crear una base de datos de análisis de lecciones aprendidas que
puede ser de gran utilidad para ejecutar más efectivamente futuros proyectos. Segunda, proporciona una
estructura para el cierre, convirtiendo un proceso descuidado en una serie de pasos identificables para una
liquidación del proyecto más sistemática y completa. Tercera, cuando se maneja correctamente, el cierre del
proyecto puede servir de importante fuente de información y motivación para los miembros del equipo del
proyecto. Ellos descubren, a través de análisis de las lecciones aprendidas, buenas y malas prácticas y formas
de anticiparse a los problemas en el futuro. Además, cuando el equipo se disuelve de forma adecuada, pro-
bablemente los beneficios psicológicos conduzcan a una mayor motivación para futuros proyectos. Así, el
cierre sistemático de proyectos, por lo general, resulta en un cierre efectivo de estos.

14.3  TERMINACIÓN ANTICIPADA DE PROYECTOS


¿En qué circunstancias la organización del proyecto puede concluir razonablemente que un proyecto es candi-
dato para su terminación anticipada? Aunque puede influir una variedad de factores en esta decisión, Meredith
identifica seis categorías de factores dinámicos de proyectos y sugiere llevar a cabo un seguimiento periódico
de estos factores para determinar si han cambiado significativamente.13 En caso de que la respuesta sea “sí”,
las siguientes preguntas deben tratar de determinar la magnitud del desplazamiento como una base para con-
siderar si el proyecto debe continuar o debe terminarse. El cuadro 14.1 muestra estos factores dinámicos del
proyecto y algunos de los temas sobre los cuales debería formularse preguntas pertinentes, acerca de ellos.
Como se muestra en el cuadro 14.1, los factores estáticos del proyecto, en relación con las característi-
cas propias del proyecto y cualquier cambio significativo que haya experimentado el proyecto, son la primera
fuente de información sobre el potencial de la terminación anticipada. Los factores asociados con la tarea en
sí misma o con la composición del equipo del proyecto son otra fuente importante de información sobre sí
14.3  Terminación anticipada de proyectos 485

un proyecto debería terminarse. Otras señales importantes incluyen cambios en el patrocinio del proyecto,
cambios en las condiciones económicas o en el entorno operativo de la organización que puedan anular el
valor de seguir adelante con el proyecto, y los cambios iniciados por el usuario. Por ejemplo, la necesidad
original del cliente de un proyecto se puede eliminar por cambios en el entorno externo; por ejemplo, cuando
Goodrich Corporation adquirió TRW Corporación, canceló varios de sus propios proyectos de aeronáutica
porque la compra le suministró las tecnologías que buscaba.

CUADRO 14.1  Factores dinámicos del proyecto para revisión

1. Factores estáticos  
a. Experiencia
b. Imagen de la empresa
c. Fuerzas políticas
d. Altos costos irrecuperables
e. Recompensas intermitentes
f. Gastos de salvamento y de cierre
g. Beneficios al cierre
2. Factores de tarea- equipo  
a. Dificultad para lograr desempeño técnico
b. Dificultad para resolver problemas tecnológicos/industriales
c. Alargamiento de la fecha de finalización
d. Falta de tiempo en el proyecto o hitos de desempeño
e. Baja innovación del equipo
f. Pérdida de entusiasmo del equipo o del gerente de proyecto
3. Factores de patrocinio  
a. Proyecto menos consistente con las metas organizacionales
b. Vinculación más débil con otros proyectos
c. Bajo efecto en la empresa
d. Menos importancia para la empresa
e. Problema u oportunidad reducida
f. Menos compromiso de la alta gerencia con el proyecto
g. Pérdida del campeón del proyecto
4. Factores económicos  
a. Bajo ROI, cuota de mercado, o beneficio
b. Mayor costo para completar el proyecto
c. Menor disponibilidad de capital
d. Más tiempo para obtener los retornos del proyecto
e. Incumplimiento de los hitos de costos del proyecto
f. Disminución del rubro de presupuesto de la empresa asignado al proyecto
5. Factores ambientales  
a. Menor disponibilidad de capital
b. Aumento de la competencia
c. Menos capacidad para proteger los resultados
d. Aumento de las restricciones del gobierno
6. Factores del usuario  
a. Desaparición de la necesidad del mercado
b. Cambio en los factores del mercado
c. Reducida receptividad del mercado
d. Disminución del número de alternativas de uso final
e. Menor probabilidad de éxito en la comercialización
f. Menos posibilidades de éxito a largo plazo
486 Capítulo 14  •  Cierre y terminación del proyecto

Una gran cantidad de investigación se ha realizado sobre la decisión de cancelar los proyectos con el fin
de identificar las reglas claves de decisión por las cuales las organizaciones determinan dejar de perseguir la
oportunidad del proyecto. Un análisis de 36 empresas que terminaron proyectos de (I+D) identificó como prin-
cipal causa para la finalización anticipada las bajas probabilidades de alcanzar éxito técnico o comercial14. Otros
factores importantes en la decisión de terminación incluyen baja probabilidad de recuperación de la inversión,
bajo potencial de mercado, costos prohibitivos para continuar con el proyecto y problemas técnicos insupera-
bles. Otros autores han puesto de relieve algunos factores claves adicionales que pueden influir en la decisión
de sí se debe poner fin a los proyectos, como: (1) la eficacia de la gerencia del proyectos, (2) el apoyo de la alta
gerencia, (3) el compromiso de los trabajadores y (4) el liderazgo del gerente del proyecto.15
Un estudio ha tratado de determinar los signos de advertencia de la posible terminación temprana del
proyecto que pueden identificarse antes de que la decisión de terminación se haya tomado16. Los autores exa-
minaron 82 proyectos a lo largo de cuatro años. Sus hallazgos sugieren que para proyectos que finalmente se
terminaron, dentro de los seis primeros meses de su existencia, los miembros del equipo del proyecto ya sabían
que estos proyectos tenían una baja probabilidad de alcanzar los objetivos comerciales, debido a que no estaban
dirigidos por miembros del equipo con suficiente autoridad de decisión, y a que como se preveía su lanza-
miento en mercados relativamente estables, estaban catalogados de baja prioridad por la alta gerencia de (I+D).
A pesar de que estos proyectos estaban gestionándose con efectividad y eran valiosos para la alta gerencia, estos
factores generaron que los miembros del equipo del proyecto determinaran, muy poco tiempo después de ini-
ciado el proyecto, que era probable que fallaran o que se terminaran de forma anticipada por la organización.

Tomar la decisión de terminación anticipada


Cuando un proyecto se considera candidato para su terminación anticipada, la decisión de “tirar del enchufe”
por lo general no es clara. Pueden estar compitiendo diversas fuentes de información, en las que algunos
sugieren que el proyecto puede tener éxito y otros argumentan que el proyecto ya no es viable. Con frecuen-
cia, el primer desafío en la terminación del proyecto es la evaluación de estos puntos de vista para determinar
cuáles son más precisos y objetivos. Recuerde que, por lo general, la viabilidad de un proyecto no es una
cuestión puramente interna, es decir, solo porque el proyecto está bien desarrollado, no significa que se debe
seguir apoyándolo. Un cambio importante en las fuerzas externas puede hacer que cualquier proyecto pierda
su validez, mucho antes de que se haya completado.17 Por ejemplo, si la tecnología del proyecto se ha susti-
tuido o si las fuerzas del mercado han hecho que las metas del proyecto sean superfluas, el proyecto debería
cerrarse. Por otra parte, a pesar de que un proyecto que pueda cumplir un propósito útil en el mercado, puede
finalizar si la organización del proyecto comienza a ver su desarrollo como excesivamente largo y costoso.
Otra razón interna común para terminar un proyecto en medio de su ejecución es el reconocimiento de que
el proyecto no se ajusta con los lineamientos estratégicos dentro del portafolio de productos de la empresa.
Por ejemplo, un cambio estratégico importante en la oferta de productos dentro de una empresa puede hacer
que varios proyectos en marcha ya no sean viables, puesto que no cumplen los nuevos requerimientos para el
desarrollo de productos. En otras palabras, los proyectos pueden terminarse por razones tanto externas (por
ejemplo, cambios en el entorno operativo) como internas (por ejemplo, proyectos que ya no son rentables o
que no encajan con la dirección estratégica de la empresa).
Algunas reglas de decisión importantes utilizadas para decidir si terminar un proyecto en curso son las
siguientes:18
1. Cuando los costos exceden los beneficios empresariales.  Muchos proyectos deben primero demostrar
un buen retorno sobre la inversión (ROI) como criterio para su selección y puesta en marcha. El análisis
periódico de los costos previstos para el proyecto frente a los beneficios esperados puede poner de relieve
el hecho de que el proyecto ya no sea financieramente viable. Esto puede deberse a que los costos fueron
más altos de lo previsto en la finalización del proyecto o a una oportunidad de mercado más baja de lo
que la compañía había esperado originalmente. Si el valor presente neto de un proyecto en curso refleja
seriamente, pérdidas financieras, la decisión de dar por terminado el proyecto puede ser buen negocio.
2. Cuando el proyecto ya no cumple los criterios estratégicos.  Las empresas a menudo reevalúan sus portafo-
lios estratégicos de productos para determinar si los productos que ofrecen son complementarios y si el por-
tafolio es equilibrado. Cuando se adopta una nueva visión estratégica, es común hacer cambios significativos
en la mezcla de productos, eliminando líneas de productos que no se ajustan a las nuevas metas. Por ejemplo,
cuando Jack Welch, ex CEO de General Electric (GE), emitió su famoso lema “Uno o dos o fuera”, quiso decir
que GE no soportaría unidades de negocio a menos que estuvieran en primer o en segundo lugar en su indus-
tria. El resultado fue la eliminación de varias líneas de negocio que no cumplían la nueva visión estratégica.
14.3  Terminación anticipada de proyectos 487

PERFIL DE PROYECTO

Caso—El cierre de la Zion Nuclear Plant


En estos tiempos de búsqueda de fuentes alternativas de energía, en los que se motiva a las agencias estatales y fede-
rales para echar otro vistazo a la energía nuclear, la industria se enfrenta con un separado, pero no menos importante
desafío: el desmontaje seguro de viejas plantas de energía nuclear y la eliminación de residuos y materiales contami-
nados. La U. S. Nuclear Regulatory Comission (NRC) está revisando 22 solicitudes de construcción de centrales nuclea-
res en 13 sitios en todo el país. Al mismo tiempo, ha aprobado recientemente la demolición de al menos otras ocho
viejas centrales cerradas e inactivas. En muchos sentidos, la clausura y el desmantelamiento de las centrales nucleares
es tan difícil como su construcción y requiere experiencia que solo unas pocas empresas poseen.
Un reciente ejemplo es la planta de energía nuclear Zion, asentada en 257 acres a 40 millas al norte de Chicago,
a orillas del lago Michigan. Cuando se encendió por primera vez en 1973, la planta Zion era la central nuclear más
grande del mundo, con una nueva generación de reactores diseñados para la seguridad. Dirigida por Commonwealth
Edison (ComEd), la planta era una fuente importante de energía para el área metropolitana de Chicago. A pesar de
que contaba con los permisos que le permitirían a la planta seguir funcionando hasta bien entrado el siglo xxi, los
propietarios de la planta decidieron, a finales de la década de 1990, que la economía de mantener los reactores en
línea simplemente no sumaban más. Demasiados problemas con la seguridad estructural y procesal habían hecho
antieconómica la planta, y a finales de 1997 se decidió a tirar del enchufe.
Infortunadamente, tener una planta de energía nuclear fuera de línea es solo una parte del problema, el
mayor problema es: ¿qué hacer con ella? Exelon Corporation, la compañía hermana de ComEd y los propietarios de
la planta dejaron la planta fuera de uso durante 12 años, y pagaron más de 132 millones de dólares por chatarra, el
sellado de todos los materiales peligrosos y por el mantenimiento y seguridad del sitio. Sin embargo, Exelon tenía
un plan para la eliminación definitiva de la planta, después de haber recaudado más de 1,000 millones de dólares,
durante su vida operativa, desde que los clientes de ComEd comenzaron a pagar un fondo a finales de 1970, un
cargo que solo se eliminaría de sus cuentas en 2006.
Exelon contrató a Energy Solutions, Inc., de Salt Lake City, para desmantelar la central nuclear Zion. El pro-
yecto, previsto para comenzar en 2012, debe tener una duración máxima de 10 años: siete años para desmantelar
la planta y eliminar de forma segura todos los materiales y otros tres años para restaurar el área en una zona verde.
El costo proyectado es de aproximadamente 1,100 millones de dólares, cuando esté terminado.
El proceso de desmantelamiento de las centrales nucleares antiguas requiere una cuidadosa planeación y
ejecución. Además de remover todas las barras nucleares gastadas y otros materiales radiactivos, muchos de los
domos de contención y otras superficies de la planta que también están impregnadas de radiactividad, deben

Heather Charles/MCT/Newscom

FIGURA 14.5  Planta nuclear de Zion

(continúa)
488 Capítulo 14  •  Cierre y terminación del proyecto

desmontarse, empaquetarse y transportarse cuidadosamente. El CEO de Energy Solutions, Val Christensen señala:
“Es mucho más difícil desmontar estas plantas, que construirlas.“
El combustible nuclear usado se almacenará en “toneles” de concreto gigantes que se ven como pequeños
silos agrícolas, los cuales almacenan alrededor de 2.2 millones de libras de combustible nuclear usado y otras
80,000 libras de material altamente radiactivo de los dos reactores. Estos permanecerán indefinidamente en el
lugar, bajo vigilancia segura, hasta que Energy Solutions y el gobierno federal localicen una opción de almacena-
miento permanente. Mientras tanto, Christensen sugiere que su compañía empleará un enfoque de “desmontar
y transportar” para las otras partes de la planta de energía, desmantelando y removiendo grandes secciones de
la planta en secuencia cuidadosa. Aunque el calendario no se ha establecido, se moverán más de 500,000 metros
cúbicos de material, incluidos desde muros de hormigón, tuberías, cableado y maquinaria hasta escritorios y sillas.
Gran parte de este material (suficiente para llenar aproximadamente 80 vagones de ferrocarril) está contaminado
con radiación de bajo nivel y se transportará a un sitio de Energy Solutions, 80 millas al oeste de Salt Lake City,
donde se triturará y compactará.
Mientras tanto, ambas compañías planean próximas iniciativas. Exelon ya ha determinado que dos de sus
instalaciones, en Illinois y Pensilvania, se cerrarán y desmantelarán en los próximos 20 años. Energy Solutions, con
éxitos sólidos desmantelando plantas en Nueva Inglaterra y el Oriente Medio, busca futuros proyectos de desman-
telamiento. Los desafíos de la construcción de plantas nucleares seguras y fiables son altos Sin embargo, de igual
importancia, es una buena gerencia de proyectos en el desmontaje y eliminación de estas.19

3. Cuando los plazos no se cumplen.  Perder continuamente hitos o plazos claves es una señal de que el
proyecto está en problemas. Aun cuando hay algunas buenas razones para perder inicialmente estos hitos,
el efecto acumulativo de continuar incumpliendo plazos será, como mínimo, promover que la organi-
zación del proyecto analice las causas de tales retrasos. ¿Son debido a la mala gerencia del proyecto, a
objetivos iniciales poco realistas, o simplemente al hecho de que la tecnología no está desarrollandose con
la suficiente rapidez? Durante el primer periodo de mandato del presidente Reagan, se inició La iniciativa
de defensa estratégica (Strategic Defense Initiative: SDI). Más de 25 años después, todavía se abordan
muchos de los problemas técnicos con la implantación de una defensa viable de misiles. La mayoría de
los expertos admiten fácilmente que no tienen una buena estimación de cuando el sistema será suficiente-
mente robusto como para desplegarse con confianza.
4. Cuando la tecnología evoluciona más allá del alcance del proyecto.  En muchas industrias, como
la de IT, los cambios tecnológicos son rápidos y a menudo enormemente significativos. Por tanto,
los profesionales de IT siempre se enfrentan con el reto de completar los proyectos, mientras la
tecnología está en proceso de cambio. Su temor natural es que para el momento de introducción del
proyecto, la tecnología haya avanzado tanto que el proyecto ya no sea útil. El reto fundamental para
cualquier proyecto de IT es encontrar un balance razonable entre la congelación del alcance del pro-
yecto y la incorporación de cambios de especificaciones en curso que reflejen las nuevas tecnologías.
Obviamente, en algún momento el alcance debe congelarse o el proyecto nunca podrá completarse.
Por otro lado, la congelación del alcance demasiado pronto puede llevar a que un proyecto se vuelva
obsoleto antes de que se haya puesto en marcha.

Terminación del proyecto


Supongamos que después del análisis de los problemas y viabilidad de un proyecto en curso, se llega a la deci-
sión de darlo por terminado. Los próximos pasos implicados en el proceso de terminación pueden ser difíciles
y muy complejos. En particular, probablemente haya que resolver una serie de cuestiones antes y después de
la terminación anticipada del proyecto. Estas decisiones de terminación se dividen en dos clases: emocionales
e intelectuales.20 Además, en cada clase, se identifican aspectos adicionales. La figura 14.6 muestra el marco
que emplea una EDT modificada para identificar las decisiones claves en la terminación del proyecto.
La decisión de terminar un proyecto dará lugar a una variedad de respuestas y nuevas funciones para el
gerente y el equipo del proyecto (véase el cuadro 14.2). Tirar del enchufe en el proyecto, por lo general, con-
duce a serias respuestas emocionales de los interesados. Dentro del equipo del proyecto en sí, es natural espe-
rar una dramática pérdida de la motivación, pérdida de identidad de equipo, entre los miembros del equipo
miedo a no contar con un trabajo futuro, debilitamiento general y desvío de sus esfuerzos. Los clientes poten-
ciales del proyecto también comienzan a desinteresarse en el proyecto y, en efecto, se distancian del equipo del
proyecto y del proyecto terminado.
14.3  Terminación anticipada de proyectos 489

Aspectos de
terminación
del proyecto

Emocionales Intelectuales

Personal Cliente Internos Externos

Temor a no tener Identificación de Acuerdo con


Cambio de actitud
trabajo en el futuro entregables pendientes clientes sobre
entregables pendientes
Pérdida de interés Pérdida de interés
en las tareas restantes en el proyecto Necesidades de Acuerdo con
certificación proveedores sobre
Pérdida de motivación Cambio de personal que compromisos pendientes
derivada del proyecto se ocupa del proyecto Identificación de
compromisos Cierre de comunicación
Pérdida de identidad Personal clave pendientes
de equipo no disponible
Control de gastos Cierre de instalaciones
Selección de personal del proyecto
para reasignar
Screening de tareas Determinación de
parcialmente terminadas necesidades de datos
Desviación de esfuerzos
de registro para auditoría
Cierre de órdenes
y paquetes de trabajo

Eliminación de
materiales no utilizados

FIGURA 14.6  Estructura de desglose de trabajo para las decisiones de terminación del proyecto

CUADRO 14.2  Preocupaciones al cierre de un proyecto

Problemas emocionales del equipo del proyecto


1. Miedo a no tener trabajo futuro—La preocupación de que una vez que el proyecto esté cerrado, no haya ninguna opción de
trabajo futuro para los miembros del equipo.
2. Pérdida de interés en las tareas restantes—La percepción de que un proyecto terminado no requiere un rendimiento adicional.
3. Pérdida de motivación en el proyecto—Toda la motivación por realizar bien el proyecto o para crear un proyecto exitoso se pierde.
4. Pérdida de la identidad del equipo—El proyecto está disolviéndose, del mismo modo el equipo.
5. Selección de personal para reasignarse—Los miembros del equipo ya comienzan maniobras para obtener la reasignación a mejo-
res proyecto alternativos.
6. Desviación de esfuerzos—Con el proyecto en fase de terminación, otros trabajos toman mayor prioridad.

Problemas emocionales de los clientes


1. Cambios de actitud—Ahora que el proyecto se ha cancelado o concluido, la actitud del cliente puede volverse hostil o indiferente
2. Pérdida de interés en el proyecto—A medida que el equipo del proyecto pierde interés, también lo hace el cliente.
3. Cambio en el personal que se ocupa del proyecto—Muchas veces, a medida que se reasignan personas claves del proyecto
a nuevos desafíos, los clientes cambiarán por gente nueva en el proyecto que no tienen experiencia en este.
4. Falta de disponibilidad de personal clave - Recursos en la organización del cliente con las habilidades necesarias ya no están
disponibles o están interesados en contribuir con sus aportes al proyecto que se está terminando.
Asuntos intelectuales—Internos
1. Identificación de los entregables restantes —El equipo del proyecto debe distinguir entre lo que se ha logrado y lo que no se
ha completado.
2. Certificaciones necesarias—Puede ser necesario proporcionar certificación del cumplimiento de las normas ambientales o
legales, como parte del cierre del proyecto.
3. Iidentificación de los compromisos pendientes—El equipo del proyecto debe identificar cualquier entrega de suministros, hitos
que no se van a cumplir, y así sucesivamente.
4. Control de los gastos a cargo del proyecto—Por la liquidación, un número de personas y departamentos están interesados en
los números de contabilidad del proyecto. Es necesario cerrar rápidamente estas cuentas para evitar que otros grupos oculten
sus gastos en el proyecto.
(continúa)
490 Capítulo 14  •  Cierre y terminación del proyecto

CUADRO 14.2  Continúa

5. Screening de tareas parcialmente terminadas—Es necesario comenzar a eliminar el trabajo realizado en las tareas finales,
sobre todo cuando ya no apoyan el desarrollo del proyecto.
6. Cierre de órdenes y paquetes de trabajo—La autorización formal de cancelar las órdenes y paquetes de trabajo del pro-
yecto es necesaria una vez que las tareas en curso se han identificado.
7. Disposición del material no utilizado—Los proyectos acumulan cantidades de suministros y materiales no utilizados. Debe
desarrollarse un método para la eliminación o la transferencia de estos materiales a otros lugares.
Asuntos intelectuales—Externos
1. Acuerdo con el cliente sobre el resto de los entregables—Cuando está cancelándose un proyecto, la organización del
proyecto y el cliente deben ponerse de acuerdo sobre qué productos finales se suministrarán y cuando se programarán.
2. Acuerdo con los proveedores sobre los compromisos pendientes—Los proveedores programados para continuar
entregando materiales para el proyecto deben contactarse y sus contratos, cancelarse.
3. Comunicar el cierre—El equipo del proyecto debe asegurarse de que todos los interesados son claramente
conscientes del cierre del proyecto, incluida de la fecha en que cesarán todas las actividades.
4. Cierre de las instalaciones—Cuando sea necesario, se requiere un programa para clausurar las instalaciones.
5. Determinación de las necesidades de datos para los registros de auditoría—Los clientes y los interesados del proyecto exigen
requisitos diferentes de conservación de registros en auditorías posteriores. El equipo del proyecto debe realizar una evalua-
ción de los expedientes que se requieren de cada uno de los interesados, con el fin de cerrar el proyecto.

RECUADRO 14.2

INVESTIGACIÓN DE GERENCIA DE PROYECTOS EN SÍNTESIS


Terminación de proyectos en la industria de IT
Los gerentes de proyecto no entienden las necesidades de los usuarios
A mediados de 2010, se resolvió un litigio entre Waste Management y SAP Corporation. La demanda original surgió de un
esfuerzo fallido de implementación para instalar el software de Planeación de Recursos Empresariales (Enterprise Resource
Planning: ERP) de SAP en Waste Management. Waste Management es una empresa gigante que se ha constituido con base
en adquisiciones. Como resultado, cuenta con sistemas heredados por todas partes, muchos de ellos anticuados. En 2005,
Waste Management buscaba mejorar su proceso de pedido-cobro: facturación, cobros, fijación de precios y configuración del
cliente. Este era un sistema que sería capaz de manejar todas las necesidades de Waste Management. Sin embargo, no fue así.
El conglomerado de disposición de desechos afirmó que sufrió daños importantes, incluidos más de 100 millones de dólares,
la cantidad que gastó en el proyecto (denominado por Waste Management como “un fracaso total y absoluto”) y más de 350
millones de dólares por los beneficios que hubiera podido recibir en caso de que el software hubiera sido exitoso.
Como una parte de su denuncia en la demanda, Waste Management argumentó que quería un paquete ERP que
pudiera satisfacer sus necesidades de negocio, sin una gran cantidad de desarrollo a la medida; a cambio de esto, SAP utilizó
una demostración de un producto “falso” para engañar a los funcionarios de Waste Management haciéndoles creer que el
software llenaba sus expectativas. Aunque SAP no aceptó su culpabilidad en el caso, Waste Management recibió “un pago en
efectivo único”, de acuerdo con la conciliación.
Algunos de los retos más difíciles que se enfrentan en la gerencia de proyectos efectiva y en la finalización de proyectos
se relacionan con la industria de la tecnología de la información (IT). Las investigaciones sobre la gerencia de proyectos de
IT no ha sido tranquilizadora. El Standish Group de Dennis, Massachusetts, llevó a cabo un estudio largo y minucioso de los
proyectos de IT y determinó que:
• 40% de los proyectos de desarrollo de aplicaciones de IT se cancelan antes de completarse.
• 33% de los proyectos restantes se enfrentan con unos excesos significativos en costo o en cronograma, o cambios en
el alcance.
• Los fracasos en proyectos de IT les cuestan a la empresas estadounidenses y a las agencias gubernamentales un esti-
mado de 145,000 millones de dólares cada año.
Dados todos los ejemplos de proyectos en situación de riesgo, ¿cuáles son algunas de las señales de alerta que indican que un
proyecto puede llegar a ser un candidato para su cancelación? Los 10 signos de fracaso de un proyecto de IT son:
1. Los gerentes de proyecto no entienden las necesidades de los usuarios.
2. El alcance está mal definido.
3. Los cambios en el proyecto se manejan mal.
4. Se presentan cambios tecnológicos.
5. Las empresas necesitan un cambio.
14.3  Terminación anticipada de proyectos 491

6. Los plazos no son realistas.


7. Los usuarios son resistentes.
8. Se pierde el patrocinio.
9. El proyecto carece de personas con las habilidades adecuadas.
10. Las mejores prácticas y lecciones aprendidas se ignoran.
Con el fin de evitar la inevitabilidad del fracaso del proyecto, es fundamental reconocer las señales de alerta, como la incapaci-
dad de lograr los objetivos de referencia, la acumulación de problemas no resueltos, los problemas de comunicación entre los
interesados del proyecto y los costos crecientes. Estas señales de alerta son indicios seguros de que un proyecto de IT puede
ser un candidato para su terminación.20

Además de las reacciones emocionales esperadas por la decisión de terminación, el equipo del proyecto
debe atender una serie de asuntos administrativos o intelectuales importantes . Por ejemplo, dentro de la orga-
nización del proyecto, el cierre de un proyecto requiere una auditoría detallada de todas los entregables del
proyecto, el cierre de los paquetes de trabajo, la entrega de los equipos o los materiales no utilizados, entre otras
actividades. En relación con el cliente, la decisión de terminación requiere cierre de los acuerdos respecto a los
entregables, la terminación de los contratos o los compromisos vigentes con los proveedores, y la clausura de
las instalaciones, de ser necesario. El punto importante es: se necesita establecer un proceso sistemático para dar
por terminado un proyecto, en términos de los pasos utilizados para decidir si el proyecto debe terminarse y,
una vez se ha tomado la decisión, y la manera en que el proyecto se puede cerrar de manera más eficiente.

Permitir reclamaciones y disputas


En algunos tipos de proyectos, la decisión misma de terminación puede iniciar una serie de problemas legales
con el cliente. Los problemas más comunes en la terminación anticipada giran en torno a las reclamaciones
pendientes o no resueltas que el cliente o cualquiera de los proveedores del proyecto puedan tener en contra
de la organización del proyecto. Aunque las consecuencias legales de las decisiones de cancelación anticipada
aquí no se pueden explorar en gran detalle, vale reconocer que la terminación de un proyecto puede en sí
generar una serie de desacuerdos y acuerdos contractuales. El potencial para enfrentar las reclamaciones o
disputas debe tenerse en cuenta cuando se toma la decisión de terminación de un proyecto. Por ejemplo, una
empresa podría descubrir que a causa de la no entrega tendría severas sanciones, que en realidad sería menos
costoso completar el proyecto que terminarlo anticipadamente.
Dos tipos comunes de reclamaciones que pueden surgir en caso de cierre del proyecto son:
1. Reclamaciones a título gratuito.  Estas son reclamaciones que un cliente puede hacer cuando no existe
una base contractual para ello, pero el cliente piensa que la organización del proyecto tiene la obliga-
ción moral o comercial de compensarlo por algún evento inesperado (como la terminación prematura).
Supongamos, por ejemplo, que un cliente estaba promocionando una nueva línea de productos que iba a
utilizar una tecnología cuyo desarrollo había sido contratado con la organización del proyecto. En caso de
que la firma del proyecto cancele el proyecto, el cliente puede decidir hacer una reclamación a título gra-
tuito considerando que había planeado su nueva línea de productos en torno a esta tecnología avanzada.
2. Reclamos por incumplimiento en sus obligaciones de la compañía del proyecto en virtud del con-
trato.  Cuando las reclamaciones contractuales están predeterminadas por el fracaso en ser comple-
tado y entregado un proyecto, la empresa cliente puede tener algún derecho legal para la recuperación
de costos o daños punitivos. Por ejemplo, se puede presentar una liquidación de daños y perjuicios
cuando un contratista adjudica un proyecto a un proveedor y utiliza sanciones económicas como
incentivo para la entrega oportuna. En caso de incumplimiento o terminación temprana del proyecto,
el cliente puede invocar la cláusula de indemnización para recuperar su inversión financiera a expensas
de la organización del proyecto.
Además de las reclamaciones de las partes interesadas, la organización del proyecto también puede enfrentar
disputas legales sobre las condiciones contractuales, materiales o suministros precomprados, contratos a
largo plazo con proveedores o clientes, etcétera.
La organización del proyecto puede protegerse de problemas relacionados con reclamaciones durante
la terminación del proyecto, por los siguientes medios:22
492 Capítulo 14  •  Cierre y terminación del proyecto

• Considerar las posibles áreas de reclamaciones al inicio del contrato y planear en consecuencia. No
esperar hasta que se produzcan.
• Asegurarse de que los interesados del proyecto conocen sus áreas particulares de riesgo, de acuerdo
con el contrato para ayudar a prevenir reclamos sin fundamento después de los hechos.
• Mantener registros precisos, desde la fecha del inicio del contrato. Un buen registro diario de los hechos
puede ayudar a responder interrogantes cuando se presentan inconvenientes fatales aguas abajo.
• Mantener detalles claros de las solicitudes de cambio del cliente u otras alteraciones en las condiciones
contratadas originalmente.
• Asegurarse de que toda la correspondencia con los clientes se conserva y está archivada.
Cuando se encuentran disputas, estas normalmente se manejan a través de un recurso legal, a menudo en
forma de arbitraje.
El arbitraje se refiere a un sistema formal para tratar las reclamaciones y administrar justicia correctiva a
las partes en situación de negociación. Se utiliza para obtener una solución justa o resolver conflictos a través de
un tercero imparcial. En los proyectos, el arbitraje puede utilizarse como un recurso legal si las partes que están
en desacuerdo sobre la naturaleza de los términos y condiciones contractuales requieren un tercero, generalmente
un árbitro designado por la corte, para facilitar la solución de los términos en disputa. Siempre y cuando todas
las partes estén de acuerdo con el uso del arbitraje, este puede servir para determinar un arreglo vinculante para
todas las reclamaciones pendientes o los conflictos derivados de un contrato que no se completó adecuadamente.
Alternativamente, las partes pueden optar por un arbitraje no vinculante, en el que el juez puede ofrecer sugeren-
cias o vías de solución, pero no puede hacer cumplir estas opciones. Aunque el arbitraje tiene la ventaja de ser más
rápido que la presentación de reclamaciones a través de litigios estándares, en la práctica, es arriesgado: el juez o
árbitro puede estar del lado de la otra parte en la controversia y tomar una decisión que puede ser muy costosa para
la organización del proyecto, y en caso de no vinculante, el arbitraje puede ser considerado un “asesoramiento.“ Si
las partes desean adoptar las condiciones de la liquidación, pueden hacerlo. Por otro lado, si se deciden no adop-
tarlas, pueden obligarse a repetir todo el proceso en una audiencia administrativa, proceso judicial o un arbitraje
vinculante posteriormente. Cualquiera de estas opciones puede alargar aún más el conflicto.23
No todas las reclamaciones en contra del proyecto carecen de fundamento. Muchas veces la decisión
de terminar el proyecto se efectúa con el entendimiento de que se van a presentar litigios o reclamaciones de
partes externas, en contra de la empresa. En estos casos, la decisión de terminación debe sopesarse cuidado-
samente antes de promulgarse. Sí un proyecto está fallando y su terminación es la única opción realista, se
deben tener en cuenta las reclamaciones que resulten de esta decisión y entonces prepararse para enfrentarlas
en su totalidad después del hecho.

14.4  PREPARACIÓN DEL INFORME FINAL DEL PROYECTO


El informe final del proyecto es el registro administrativo del proyecto terminado, en el cual se identifican
todos sus componentes técnicos y funcionales, así como aspectos importantes de la historia del proyecto. Un
informe final del proyecto es valioso para la organización, al grado que el equipo del proyecto y los miembros
claves de la organización se toman el tiempo para elaborarlo de manera sistemática, identificar todas las áreas
relevantes de interés y poner en práctica procesos que aseguren que las lecciones relevantes se han identifi-
cado, aprendido y transmitido. El punto importante para recordar es que el informe final del proyecto es más
que un simple rezo de la historia del proyecto: un documento de evaluación que pone de relieve los puntos
fuertes y débiles durante el desarrollo del proyecto. Como tal, el informe final del proyecto debe ofrecer una
evaluación sincera de lo que salió bien y lo qué salió mal para el proyecto durante su ciclo de vida.
Los elementos del informe final del proyecto incluyen la evaluación de una serie de factores de proyec-
tos y organizacionales, como:24
1. Desempeño del proyecto.  El desempeño del proyecto implica una evaluación sincera de los logros del
proyecto en relación con su plan. ¿Cómo resultó el costo del proyecto en términos de métricas estándares,
como las líneas base del cronograma y del presupuesto? ¿El proyecto logró los objetivos técnicos que se
propuso? ¿Cómo resultó el rendimiento del proyecto en términos de satisfacción de los interesados, sobre
todo de la satisfacción del cliente? ¿Hay pruebas fehacientes que soporten las evaluaciones? El informe
final del proyecto es un documento de evaluación que presenta críticas objetivas, cuando sea necesario,
respecto al desempeño del proyecto y, si este se consideró deficiente, las causas más probables y las medi-
das correctivas para asegurar que resultados similares no vuelvan a ocurrir en el futuro.
14.4  Preparación del informe final del proyecto 493

2. Rendimiento administrativo.  La evaluación del desempeño administrativo del proyecto se refiere a la


evaluación de todas las prácticas administrativas estándares que se realizan dentro de la organización, así
como de sus beneficios o inconvenientes en el desarrollo del proyecto que acaba de concluir. Por ejemplo,
en una organización se encontró que todas las solicitudes de cambio del proyecto tuvieron que avalarse por
cinco niveles administrativos antes de que pudieran aprobarse, lo que provocaba una gran demora desde
el momento en que el cliente pedía un cambio hasta cuando se tomaba la decisión de aceptar o rechazar la
solicitud de cambio. El resultado de este análisis dio lugar a un proceso de orden de cambio simplificado que
hizo que la organización fuera mucho más rápida en responder a las solicitudes de cambio de los clientes.
3. Estructura organizacional.  El informe final debe ofrecer algunos comentarios sobre cómo la estructura
operativa de la organización ayudó u obstaculizó al equipo del proyecto y sus esfuerzos. Se puede encontrar,
por ejemplo, que una estructura funcional estándar es un continuo problema cuando se trata de responder
rápidamente a las oportunidades del mercado o que representa un problema para la comunicación entre
los grupos involucrados en el proyecto. Aunque es poco probable que una mala experiencia del proyecto dé
lugar a una demanda inmediata de cambiar la estructura de la empresa, los fracasos repetidos en proyectos
que apuntan de lleno a los problemas con la estructura organizativa, con el tiempo, promueven el impulso
necesario para hacer los cambios que mejor se alineen con la estructura de las actividades del proyecto.
4. Desempeño del equipo.  El informe final también debe reflexionar sobre la efectividad del equipo del
proyecto, no solo en términos de su desempeño real en el proyecto, sino también sobre la creación de
equipos respecto a las políticas de personal, capacitación o entrenamiento y evaluaciones de desem-
peño para todos los miembros del equipo del proyecto. En resumen, la evaluación del desempeño del
equipo debe abordar la eficacia de la dotación de personal a los equipos de proyectos de la empresa
(“¿Encontramos a las mejores personas para trabajar en el proyecto, dentro de la organización?”), la
creación de equipos y las actividades de entrenamiento (“¿Cómo se garantiza que los miembros del
equipo estén entrenados adecuadamente?” “Sí los miembros del equipo necesitan capacitación, ¿tene-
mos programas para proporcionarla?”) y las políticas de evaluación posterior al mismo (“¿El gerente
del proyecto tienen la capacidad de evaluar el desempeño de los miembros del equipo del proyecto?”
“¿La evaluación del gerente de proyecto tienen peso en la revisión anual de los subordinados?”).
5. Técnicas de gerencia de proyectos.  En el informe final, vale la pena tener en cuenta los métodos
utilizados por la organización para la estimación de la duración y de los costos de las actividades, así
como todos los procesos o técnicas de programación utilizados. Se puede encontrar, por ejemplo,
que la organización subestima constantemente el tiempo de duración necesario para completar las
tareas o que subestima los costos de los recursos asociados con estas tareas. Esta información puede
ser extremadamente útil en la futura estimación de proyectos. Además, deben revisarse críticamente
otras técnicas utilizadas en la gerencia de proyectos (por ejemplo, el software de programación, nor-
mas y procedimientos, etc.) para sugerir formas de mejora en el proceso en futuros proyectos.
6. Beneficios para la organización y el cliente.  Todos los proyectos se orientan al logro de un objetivo o de
un conjunto de objetivos diferenciados que tienen, de fondo, la presunción de proporcionar beneficios a la
organización patrocinadora y a los clientes del proyecto. El análisis del informe final del proyecto debe con-
siderar el grado en que el proyecto ha tenido éxito en el logro de sus metas y en proporcionar los beneficios
previstos. Sin embargo, una salvedad importante: recordar que, en algunos casos, los beneficios previstos
para un proyecto terminado pueden no ocurrir inmediatamente, sino con el tiempo. Por ejemplo, si nuestra
meta en la construcción de un complejo de viviendas es retornar un alto beneficio a nuestra empresa, sería
necesario esperar varios meses o incluso años, hasta que todos los lotes y casas se hayan vendido, antes de
evaluar si loa meta se ha logrado. Así, tenemos que tratar siempre de mantener un equilibrio entre las eva-
luaciones de los beneficios inmediatos y los que puedan acumularse en el tiempo.
El objetivo de requerir un informe final del proyecto es sentar las bases para futuros proyectos exitosos. Aunque
el informe final se utiliza para reflexionar sobre lo que salió bien y lo que salió mal con el proyecto actual, es
fundamentalmente un documento con visión de futuro usado para mejorar los procesos de la organización,
con el fin de hacer que los proyectos futuros sean más efectivos, las actividades del proyecto más productivas y
el personal del proyecto acumule más conocimientos.
Las organizaciones que aprenden están dispuestas a aplicar las lecciones importantes aprendidas de la expe-
riencia. Un gerente de proyecto sénior explica: “Es la diferencia entre un gerente con experiencia de 10 años, ¡y uno
con 10 veces la experiencia de un año!” Cuanto más podemos aplicar las lecciones importantes de los proyectos
anteriores a través de actividades como los informes finales, mayor será la probabilidad de que nuestros gerentes
de proyecto evolucionen como profesionales con conocimientos en lugar de simplemente repetir los mismos erro-
res una y otra vez: la definición clásica de un gerente con “con 10 veces la experiencia de un año.”
494 Capítulo 14  •  Cierre y terminación del proyecto

CONCLUSIÓN
“La terminación de un proyecto es un proyecto.”25 Esta afirmación sugiere que el grado en que un equipo de proyecto haga
un esfuerzo sistemático y planificado para cerrar el proyecto determina si la terminación se hará de manera eficiente y con
el mínimo desperdicio de esfuerzo y de tiempo. En los proyectos que se terminan de forma natural y completados, los pasos
de la terminación se pueden pensar de antemano y realizar de manera ordenada. Por otra parte, en circunstancias en las
que el proyecto sufre una terminación anticipada, el proceso de cierre puede ser más corto y más ad hoc, es decir, se puede
realizar de una manera menos que sistemática.
En este capítulo se analizaron los procesos de ambas terminaciones de proyectos, naturales y no naturales. Uno de los
mayores desafíos que enfrentan los equipos de proyecto durante la terminación es mantener la energía y la motivación para
llegar al último “paso en la línea de meta.“ Es normal empezar a buscar alrededor por el próximo reto de proyecto, una vez que
un proyecto llega inevitablemente a su conclusión. Nuestro reto como gerentes de proyecto es, en primer lugar, reconocer que
es normal que los miembros del equipo pierdan entusiasmo y, segundo, planear los pasos necesarios para cerrar el proyecto de
manera más efectiva. Cuando la terminación del proyecto se trata como un proyecto, es una señal de que estamos decididos a
que nuestros proyectos no terminen como un quejido negativo, sino como una explosión positiva.

Resumen
1. Diferenciar las cuatro formas principales de la ter- problemas en los proyectos que pueden señalar erro-
minación de un proyecto.  Identificamos cuatro res fatales o problemas irrecuperables. En este capí-
formas en las que los proyectos terminan; por (a) tulo también se examinaron algunas de las reglas de
extinción, (b) adición, (c) integración y (d) inanición. decisión que nos permiten tomar decisiones razona-
La terminación por extinción se refiere a proyectos bles sobre si se debe cancelar un proyecto en curso.
en los que toda la actividad finaliza sin extender el Específicamente, podemos optar por terminar los pro-
proyecto de ninguna manera, por lo general, como yectos en curso cuando:
resultado de una conclusión exitosa o de la decisión • Los costos exceden los beneficios empresariales
de terminar anticipadamente el proyecto. La termi- • El proyecto ya no cumple los criterios estratégicos
nación por adición implica desarrollar el proyecto • Los plazos no se cumplen
dentro de la organización como una entidad sepa- • La tecnología evoluciona más allá del alcance del
rada. La terminación por integración es el proceso de proyecto
realizar las actividades del proyecto dentro de la orga-
4. Conocer los retos y componentes de un informe
nización y distribuirlas entre las funciones existentes.
final del proyecto.  Dentro de los componentes del
Finalmente, la terminación por inanición consiste
informe final del proyecto se encuentran las evalua-
en cortar el presupuesto de un proyecto lo suficiente
ciones de desempeño del proyecto, del desempeño
como para detener su progreso, sin llegar a paralizar
administrativo, de la estructura organizacional, del
el proyecto.
desempeño del equipo, de las técnicas de gerencia de
2. Reconocer los siete pasos claves en la liquidación
proyectos, y de los beneficios del proyecto para la orga-
formal de un proyecto.  Los siete pasos para el cierre
nización y el cliente. Dos desafíos se involucran en el
formal de un proyecto son:
desarrollo de informes finales efectivos: primero, estar
• Finalizar el trabajo
dispuesto a hacer una evaluación objetiva y honesta de
• Entregar del proyecto
cómo avanzó el proyecto, destacando sus fortalezas y
• Obtener la aceptación del proyecto
debilidades, y segundo, elaborar informes de manera
• Cosechar los beneficios
que contengan una combinación de análisis descrip-
• Revisar cómo fue todo
tivo y material prescriptivo para futuros proyectos.
• Archivar registros y documentos
El objetivo de requerir un informe final del proyecto
• Disolver el equipo
es sentar las bases para futuros proyectos exitosos.
3. Entender las razones para la terminación anticipada Aunque el informe final se utiliza para reflexionar
de los proyectos.  Un proyecto puede ser candidato sobre lo que salió bien y lo que salió mal con el pro-
para la terminación anticipada por varias razones, yecto actual, es fundamentalmente un documento con
incluidos el reconocimiento de los cambios signifi- visión de futuro usado para mejorar los procesos de
cativos en los siguientes factores claves: (a) estáticos, la organización, con el fin de hacer que los proyectos
(b) de tarea-equipo, (c) de patrocinio, (d) económicos, futuros sean más efectivos, las actividades del proyecto
(e) ambientales y (f) del usuario. La investigación ha más productivas y el personal del proyecto acumule
determinado una serie de señales de advertencia de más conocimientos.
Estudio de caso 14.1 495

Términos clave
Arbitraje (p. 492) Lecciones aprendidas Terminación natural Terminación por
Construir, operar, transferir (p. 477) (p. 475) integración (p. 473)
(BOT) (p. 476) Reclamaciones a título Terminación no natural
Construir, apropiar, operar, gratuito (p. 491) (p. 473)
transferir (BOOT) Reclamaciones por in- Terminación por adición
(p. 476) cumplimiento (p. 491) (p. 473)
Disputas (p. 491) Terminación anticipada Terminación por extinción
Iniciativas privadas de (p. 484) (p. 473)
financiación (PFI) Terminación de proyecto Terminación por inanición
(p. 476) (p. 473) (p. 474)

Preguntas para discusión


1. ¿Por qué, con frecuencia, la decisión de terminar un proyecto es 7. ¿Por qué los programas de lecciones aprendidas con frecuencia
emocional e intelectual? no logran captar información significativa que pudiera ayudar a
2. Opine sobre los diferentes métodos para la terminación del pro- guiar proyectos futuros?
yecto. ¿Ha visto algún ejemplo de uno de estos métodos, ya sea 8. Comente sobre la siguiente afirmación: “Al decidir sobre la
a través de su escuela o de su experiencia laboral? conveniencia o no de cerrar un proyecto, es fundamental moni-
3. ¿Por qué tantos proyectos se cierran como consecuencia de la torear continuamente el entorno, en busca de signos de que ya
terminación por inanición? Discuta el papel del ego, del poder y no sea viable.“
de la política en esta forma de terminación del proyecto. 9. Remítase a la sección Investigación en gerencia de proyectos en
4. Remítase al capítulo 2. ¿Cómo funciona el concepto de esca- síntesis de este capítulo. Según su opinión, ¿por qué es tan difí-
lamiento del factor de compromiso en las decisiones terminar cil completar exitosamente los proyectos de IT? En otras pala-
los proyectos? bras, identifique algunas de las razones por las cuales la tasa de
5. Considere el caso del destructor clase Zumwalt de la Marina terminación de los proyectos de IT es de 40%?
del estudio de caso 14.3. Argumente sí la terminación de 10. Imagine que usted es miembro del equipo de un proyecto que
este proyecto después de haber invertido tanto en investi- ha incumplido los plazos, no ha alcanzado los resultados tec-
gación y desarrollo representa una buena o una mala deci- nológicos esperados y ha sido una fuente de problemas entre
sión de la Marina. su equipo y el cliente. Le informan que el proyecto está can-
6. De los siete elementos de la gerencia de cierre del proyecto, celándose. ¿De qué manera esta podría ser una buena noticia?
¿cuáles considera más importantes? ¿Por qué? ¿Cómo podría ser una mala noticia?

Estudio de caso 14.1


Proyecto Libra: terminar o no terminar
El titular de una sección del magazine ITWeek confirmó tribu­nales de magistrados. Sin embargo, explicó que el con-
lo que muchos sabían desde hacía mucho tiempo acerca trato con Fujitsu Services (anteriormente ICL) se encon-
de la situación de un proyecto de IT de alto perfil iniciado traba en proceso de renegociación y que “todavía no era
por el gobierno británico: “El gobierno rechaza el pro- posible indicar el resultado.“
yecto Bail Out Libra—debido a sus problemas y al retraso El departamento dijo que había pagado hasta ese
presentado.“ Después de retrasos significativos de más de momento 33 millones de libras esterlinas a Fujitsu Services.
dos años, el gobierno del Reino Unido, finalmente deter- El costo del contrato ya había aumentado de 183 millones
minó que no debería gastar más dinero en el emproble- a 319 millones de libras debido al trabajo adicional que
mado Proyecto Libra del Lord Chancellor Departament. el Lord Chancellor Departament había solicitado. Fujitsu
Libra combinaba infraestructura de oficinas con un había estado bajo fuerte presión de los partidos tanto del
nuevo sistema de trabajo de casos que enlaza los tribuna- gobierno como de la oposición, pero para entonces ya se
les de los magistrados, pero la aplicación de software no había reconocido que los costos finales y la fecha de fina-
se entregó en julio de 2001, como estaba previsto y siguió lización del proyecto no podían determinarse, razonable-
retrasado. Un portavoz de la oficina del Lord Chancellor mente, lo que sugería que el Proyecto Libra podría conti-
afirmó que el proyecto estaba vigente en 70% de los nuar en el futuro.
(continúa)
496 Capítulo 14  •  Cierre y terminación del proyecto

Infortunadamente, Libra continuaría una larga “En los negocios no hay interesados que pudieran
tradición de la mala gerencia de los proyectos de IT del soportar las pérdidas, los sobrecostos, e incluso el muy
gobierno en el Reino Unido. Recientemente se estimó que pobre software que han tenido los sucesivos gobiernos”,
el costo de los proyectos de IT del gobierno cancelados o dijo Derek Wyatt, un miembro del Parlamento. “El valor
por fuera de presupuesto habían superado los 1,500 millo- del costo de oportunidad es de cientos de pequeños nue-
nes de libras en los últimos seis años. La última encuesta vos hospitales y escuelas. Tal vez los funcionarios públi-
de Computing mostró un aumento de 50% en la cantidad cos deberían perder sus puestos de trabajo, con mayor
de dinero malgastado en proyectos de IT del gobierno mal frecuencia.”26
gerenciados, desde su estudio previo, casi dos años antes.
Preguntas
El ministro del Tesoro, Paul Boateng, admitió
recientemente que su departamento no sabía cuánto se 1. Haga una búsqueda en Google de “UK’s Project
ha perdido desde que el gobierno laborista llegó al poder. Libra”para ver la cadena de noticias relacionadas
Desastres de alto perfil tenidos en cuenta en las investi- con el Proyecto Libra. Identifique algunas de las
gaciones de Computing incluyen: 698 millones de libras fuentes de los problemas que el proyecto tuvo que
desperdiciados en el proyecto Pathway cancelado, el cual enfrentar.
tenía que desarrollar tarjetas inteligentes para pagos de 2. Si usted fuera el único en decidir si terminar este pro-
beneficios, y 260 millones de libras de sobrecostos del sis- yecto, ¿cuál podría haber sido su decisión? Justifique
tema Libra para los tribunales de los magistrados, identifi- su posición.
cados por la National Audit Office en 2008.

Estudio de caso 14.2


El proyecto que no podía morir
Ben entró de mal humor en la oficina de su jefe, el martes De repente, se iluminó Ben. “¿Harry Shapiro? ¿Se
por la mañana. Sin perder tiempo en cortesías, se enfrentó refiere al vicepresidente Harry Shapiro? “
con Alice. “¿Qué diablos hice para que me asignaran al “Es correcto. Harry fue ascendido al cargo de VP
Proyecto Regency”, preguntó, sosteniendo la nota que le hace poco más de un año. Antes de eso, él era responsable
informaba de su traslado inmediato. Alice había esperado de conseguir que Regency se pusiera en marcha. Piense
esta reacción y se sentó un momento para ordenar sus en ello: ¿realmente espera que Harry va a eliminar su idea
pensamientos sobre cómo proceder. original? Inútil o no, Regency seguirá por más tiempo que
El Proyecto Regency era una leyenda de menor impor- cualquiera de nosotros.”
tancia en la oficina. Comenzó como una auditoría interna de Ben gimió: “Muy bien, ¡así que estoy sirviendo en
las prácticas de negocios 20 meses antes; el proyecto nunca el proyecto favorito de Harry! ¿Qué se supone que debo
parecía tener algún logro, no fue tomado en serio dentro de hacer?”
la empresa, y aún tenía que hacer una propuesta concreta Alice le ofreció una mirada comprensiva. “Mire,
para la mejora de sus prácticas de trabajo. De hecho, en lo mi mejor consejo es que acepte estar en el proyecto con
que se refería a Ben y a muchos otros miembros de la compa- buenas intenciones y tratar de hacerlo lo mejor posible.
ñía, parecía una completa pérdida de tiempo. ¡Y ahora aquí He visto el presupuesto de Regency, y la alta gerencia ha
estaba Ben, asignado al proyecto! venido recortando su apoyo a este. Eso significa que ellos
Ben continuó: “Alice, sabe que esta asignación tienen que reconocer que el proyecto no va bien. Ellos
subutiliza mis habilidades. Nada ha venido de Regency, simplemente no lo quieren eliminar de plano.”
de hecho, me encantaría saber cómo la alta gerencia, que “Recuerde”, Alice continuó, “el proyecto no puede
suele ser tan consciente con los costos, ha permitido que morir debido a que Harry está tan comprometido con él,
este proyecto continúe. Quiero decir, ¡esta cosa, simple- pero eso también significa que tiene una alta visibilidad
mente, no va a morir!” para él. Haga un buen trabajo y llame la atención. Luego,
Alice se rió. “Ben, la respuesta a su pregunta se puede su próxima misión será ser mejor “. Alice se echó a reír.
encontrar fácilmente. ¿Se ha tomado la molestia de darle un “¡Caramba, esto no puede ser mucho peor!”
vistazo a cualquiera de los primeros trabajos que han salido de
Regency durante sus primeros tres meses? “ Cuando Ben negó Preguntas
con la cabeza, ella continuó:” La declaración de trabajo origi-
nal y la de desarrollo del alcance fue supervisado por Harry 1. ¿Qué método de terminación parece que la compañía
Shapiro. Él fue el primer gerente del proyecto Regency.“ está utilizando con el Proyecto Regency?
Estudio de caso 14.3 497

2. ¿Cuáles son los problemas motivacionales cuando los 3. ¿Por qué sospecharía que Harry Shapiro tiene la
miembros del equipo del proyecto perciben que su intención de mantener vivo el proyecto?
proyecto está destinado a la terminación?

Estudio de caso 14.3


La Armada cancela el desarrollo de su buque de guerra estrella
A mediados del verano de 2008, la Marina de Estados construido, y efectivamente cerraría el programa luego
Unidos anunció su decisión de cancelar el desarrollo del de completar los tres destructores.
destructor DDG 1000 Zumwalt, después de que los dos Además de su alto costo, una mayor y significativa
primeros se completaran en los astilleros de Maine y preocupación fueron el diseño y las fallas conceptuales de los
Mississippi. Esta decisión, originalmente tomada debido destructores Zumwalt, un asunto que la Marina ha tenido
al alto costo de la construcción del buque, apunta a un mucho interés en evitar hasta hace poco. Por ejemplo, el
muy controvertido, y se podría argumentar mal proceso buque no está equipado con un sistema efectivo de misiles
de gerencia del alcance desde el inicio. antibuques. En otras palabras, el Zumwalt no puede defen-
La clase de destructores Zumwalt fue concebida para derse contra misiles antibuques balísticos. Considerando que
desempeñar un papel único. Estos tenían que operar cerca la misión del Zumwalt es de apoyo cercano y de bombardeo
de la costa (en lo que se conoce como el ambiente litoral) y costero, la imposibilidad de defenderse con eficacia contra
proveer de cerca para apoyar el bombardeo contra objetivos misiles antibuques es una falla crítica. Los críticos han soste-
enemigos, usando sus armas de 155 milímetros y misiles de nido que la Armada sabía desde el principio que el Zumwalt
crucero. Con un desplazamiento de 14,500 toneladas y una no podía emplear una defensa razonable de misiles antibu-
longitud de 600 metros, los buques tienen una tripulación ques. La Armada sostiene que el buque puede transportar
de solo 142 personas, debido a los sistemas automatizados misiles de ese tipo pero reconoce que no puede guiar a los
avanzados que se utilizan. Las características adicionales de misiles hacia un objetivo. Esto plantea la pregunta: si estos
la clase Zumwalt incluyen sistemas avanzados de radar de buques necesitan barcos no sigilosos alrededor de ellos para
“doble banda” para disparar con acierto, fuego de apoyo, su protección contra amenazas entrantes, en primer lugar,
así como identificación y rastreo de amenazas. El sonar ¿cuál es el punto de crear un buque invisible?
también se considera superior para rastrear submarinos Otro problema ha surgido de un examen más deta-
en aguas costeras poco profundas. Sin embargo, la carac- llado de la función que la Armada prevé para el Zumwalt.
terística más notable de la clase Zumwalt fue la decisión Si su propósito principal era realmente servir de plataforma
de emplear la tecnología “stealth” en su diseño, con el fin de bombardeo en alta mar, ¿por qué se utiliza para todo?
de hacer que el destructor sea de difícil detección para el ¿No podrían los aviones con base en portaaviones destruir
radar enemigo. Esta tecnología incluye el uso de un “radar estos objetivos con la misma facilidad? ¿Qué hay de los
de absorción” y un diseño único del casco. Así, el Zumwalt, misiles de crucero guiados por GPS? El subjefe de operacio-
en desarrollo desde finales de 1990, estaba a punto de con- nes navales, el vice almirante Barry McCullough, admitió
vertirse en la incorporación más nueva e impresionante de este punto crítico al reconocer que “con el avance acelerado
la flota de la Armada. de municiones de precisión y focalizadas, la sobrecapaci-
Infortunadamente, se presentaron obstáculos para dad de fuego ya existe desde la aviación táctica.“ En otras
el buque desde el principio debido a varias fallas funda- palabras, ¿por qué correr el riesgo de exponer a barcos casi
mentales. En primer lugar, su precio, que originalmente indefensos cerca de las costas enemigas para destruir los
se esperaba que fuera de casi 2,500 millones de dólares mismos objetivos que el poder aéreo puede eliminar con
por buque, se infló a un estimado de 5,000 millones de riesgo más bajo?
dólares. En contraste, la clase actual de destructores de En resumen, a pesar de que en un principio se
última generación de la Marina, el Arleigh Burke, costó argumentaba que el Zumwalt era una nueva plataforma
1,300 millones de dólares por buque. Los sobrecostos se de armamento fundamental para apoyar la labor de la
hicieron tan grandes que los originales 32 barcos de la Armada, los críticos y el propio análisis de la Armada con-
clase Zumwalt, que la Armada quería construir, se redu- firmaron que el destructor de la clase DDG 1000 repre-
jeron primero a 12 y luego a siete. Finalmente, después senta una inversión en tecnología arriesgada basada en una
de otra revisión del Congreso, el tercer destructor de la necesidad cuestionable. Es demasiado costoso, no puede
clase, que se construirá en Maine Bath Iron Works, fue defenderse de manera adecuada, y está destinado a hacer
financiado con la condición de que este sería el último un trabajo para el que otras opciones se adaptan mejor. La
(continúa)
498 Capítulo 14  •  Cierre y terminación del proyecto

cancelación del proyecto destructor Zumwalt fue, en última del equipo para un proyecto de defensa, ¿qué aspec-
instancia, la decisión correcta, aunque tardía, ya que les ha tos serían esenciales o necesarios para apoyar un pro-
costado a los contribuyentes estadounidenses un estimado yecto de este tipo?
de 13,000 millones de dólares en (I+D) y en la financiación 2. ¿Por qué, según su opinión, existe una larga historia
del presupuesto para construir tres naves que no tienen uti- de proyectos de defensa que sobrepasan sus presu-
lidad inmediata o en un futuro próximo. 27 puestos o fallan en algunas métricas de desempeño
claves? (Considere otros casos de proyectos de este
texto, como el del Expeditionary Fighting Vehicle
Preguntas
analizado en el capítulo 5).
1. El U.S. Departament of de Defense tiene una larga 3. “El misterio no es que el Zumwalt se cancelara. El mis-
historia en el patrocinio de proyectos con utilidad terio es por qué se tardó tanto tiempo para cancelarlo
cuestionable. Sí usted fuera asignado como miembro “. ¿Está de acuerdo con esta afirmación? ¿Por qué?

Ejercicios en internet
1. Busque en internet enlaces relacionados con el túnel de Boston, archivar un proyecto. ¿Cuál de las siguientes actividades
“The Big Dig”, el Túnel del Canal, “El Chunnel” y el London no se espera que forme parte del cierre del proyecto?
Millennium Dome . ¿Por qué cree que estos proyectos contaron a. Proyecto archivado
con apoyo hasta su conclusión, a pesar de su bajo rendimiento b. Archivado del proyecto
de costos? ¿Qué faltaría para cerrar un proyecto de alta visibili- c. Liberación de recursos
dad, como estos? d. Verificación del proveedor
2. Ingrese en http://blog.projectconnections.com/project_prac-
3. Su proyecto está casi terminado. A solicitud suya, los
titioners/2009/04/why-bad-projects-are-so-hard-to-kill.html
miembros de su equipo de proyecto están recolectando la
y lea el blog ejecutivo matando malos proyectos. ¿Cuáles son
documentación clave del proyecto, como contratos, regis-
algunas de las historias claves o piezas de asesoramiento que
tros financieros, órdenes de cambio, alcance y material de
ofrece el escritor del blog y los comentarios sobre sus sugeren-
la gerencia de la configuración y registros de entrega de los
cias? ¿De qué manera las políticas de empresa desempeñan un
proveedores. ¿Cuál de los siguientes implica la creación de
papel en la continuación de proyectos mal concebidos? ¿Cuál
este proceso?
de estos argumentos tiene más sentido para usted? ¿Por qué?
a. Archivos
3. Ingrese en http://cs.unc.edu/~welch/class/comp145/media/
b. Lecciones aprendidas
docs/ Boehm_Term_NE_Fail.pdf y lea el artículo “Project
c. Contrato y archivos legales
Termination Doesn’t Equal Project Failure”, de Barry Boehm.
d. Documento del alcance
Resuma sus principales argumentos. ¿Cuáles son las 10 princi-
pales razones para el fracaso del proyecto? 4. La fase de ejecución de un proyecto de IT acaba de termi-
4. Ingrese en www.pmhut.com/wp-content/uploads/2008/03/ nar. El objetivo de este proyecto era actualizar los sistemas
projectcloseout-document.pdf. Critique el contenido de este de ingreso de pedidos para el departamento de despachos
formulario de cierre. ¿Qué información le sugeriría añadir a de su compañía. ¿Cuál de los siguientes es el próximo paso
este formulario para que sea un documento más completo de en el proceso de completar el proyecto?
cierre? a. Obtener aceptación del proyecto por el departamento
5. Vaya a un motor de búsqueda (Google, Yahoo, Ask, etc.) e intro- de despachos
duzca el término “Project failure” o “ project disaster “. Seleccione b. Finalizar el trabajo
un ejemplo y desarrolle un análisis del proyecto. ¿El proyecto fue c. Cerrar el contrato
terminado o no? Si no, ¿por qué, según su opinión, se permitió d. Liberar los recursos
que continuara?
5. El equipo acaba de terminar el trabajo del proyecto. Por las
cuentas, se trataba de un proyecto difícil desde el principio
Preguntas de ejemplo del examen para la certificación
y los resultados lo confirman. Usted sobrepasó el presu-
PMP® puesto en 20% y el cronograma fue excedido significativa-
1. ¿Cuándo se cierra un proyecto? mente. Progresivamente, la moral fue deteriorándose de
a. Cuando se cancela un proyecto cara a los numerosos desafíos. Al término del proyecto, se
b. Cuando un proyecto se queda sin dinero decide celebrar una reunión informal con el equipo para
c. Cuando un proyecto se completa con éxito discutir los problemas e identificar sus causas, todo ello
d. Todas las anteriores son respuestas correctas con el objetivo de evitar que algo como esto vuelva a suce-
der. ¿ Con qué nombre se conoce este proceso?
2. Usted acaba de terminar su proyecto y tiene que enfren-
a. Cerrar el proyecto
tar las actividades finales que su empresa requiere para
b. Auditar las adquisiciones
Notas 499

c. Lecciones aprendidas 3. a—La recopilación de la documentación relevante del


d. Terminación anticipada proyecto se conoce como archivos; 4. b—El inicio de la fase
final de un proyecto generalmente implica completar todas las
Respuestas: 1. d—Todas son razones por las que un proyecto tareas finales; 5. c—Una reunión de lecciones aprendidas tiene
se cerrará; 2. d—La verificación de proveedores es un proceso por objeto evaluar críticamente lo que salió bien y lo que salió
que debe ocurrir temprano en el proyecto para garantizar que mal en un proyecto para promover las buenas prácticas y evitar
las entregas lleguen oportunamente y sean de calidad suficiente; errores en los proyectos futuros.

Notas
1. Malanga, S. (2010, 16-17 de octubre). “Christie is right about Raelin, J. A. (1980). “How to decide when to abandon a
the Hudson River big dig,” Wall Street Journal, p. A15; project,” Research Management, 23(4): 24–29; Balachandra,
Schuerman, M. (2010). “New Jersey Governor Chris Christie R., and Raelin, J. A. (1984). “When to kill that R&D proj-
kills Hudson River train tunnel for second time,” www.wnyc. ect,” Research Management, 27: 30–33; Balachandra, R., and
org/articles/wnyc-news/2010/oct/26/new-jersey-governor- Raelin, J. A. (1985). “R&D project termination in high-tech
chris-christie-kills-hudson-river-train-tunnel-second-time/; industries,” IEEE Transactions on Engineering Management,
“N.J. Gov. Christie kills Hudson River tunnel project, citing EM-32: 16–23.
taxpayers woes.” (2010, 7 de octubre). www.nj.com/news/ 16. Green, S. G., Welsh, M. A., and Dehler, G. E. (1993). “Red
index.ssf/2010/10/gov_christie_kills_hudson_rive.html; flags at dawn or predicting project termination at start-up,”
http://en.wikipedia.org/wiki/Access_to_the_Region%27s_ Research Technology Management, 36(3): 10–12.
Core; www.arctunnel.com/pdf/news/Tunnel%20Info%20 17. Meredith, J. R. (1988), as cited; Cleland, D. I., and Ireland,
Kit_Dec2009_single%20page%20layout.pdf; http://blog. L. R. (2002). Project Management: Strategic Design and
nj.com/njv_editorial_page/2009/06/arc_transhudson_ Implementation, 4th ed. New York: McGraw-Hill; Staw, B. M.,
rail_­tunnel_co.html; Smart, M. (2009). “Digging deep,” and Ross, J. (1987, marzo, abril). “Knowing when to pull
PMNetwork, 23(10): 40–45. the plug,” Harvard Business Review, 65: 68–74; Shafer, S. M.,
2. Spirer, H. F., and Hamburger, D. (1983). “Phasing out the and Mantel, Jr., S. J. (1989). “A decision support system
project,” in Cleland, D. I., and King, W. R. (Eds.), Project for the project termination decision,” Project Management
Management Handbook. New York: Van Nostrand Reinhold, Journal, 20(2): 23–28; Tadasina, S. K. (1986). “Support sys-
pp. 231–50. tem for the termination decision in R&D management,”
3. Meredith, J. R., and Mantel, Jr., S. J. (2003). Project Project Management Journal, 17(5): 97–104; Cooper, R. G.,
Management, 5th ed. New York: Wiley. and Kleinschmidt, E. J. (1990). “New product success: A
4. Meredith, J. R., and Mantel, Jr., S. J. (2011). Project comparison of ‘kills’ versus successes and failures,” Research
Management, 8th ed. New York: Wiley. and Development Management, 20(1): 47–63; Royer, I.
5. Cooke-Davies, T. (2001). “Project closeout manage- (2003). “Why bad projects are so hard to kill,” Harvard
ment: More than simply saying good-bye and moving Business Review, 81(2): 48–56; Spiller, P. T., and Teubal, M.
on,” in Knutson, J. (Ed.), Project Management for Business (1977). “Analysis of R&D failure,” Research Policy, 6: 254–75;
Professionals. New York: Wiley, pp. 200–14. Charvat, J. P. (2002). “How to identify a failing project,” ar-
6. Cooke-Davies, T. (2001), ibid. ticles.techrepublic.com.com/5100-10878_11-1061879.html;
7. Turner, J. R. (1993). Handbook of Project-Based Work. Mersino, A. (2001). “Three warning signs that your project
London: McGraw-Hill. is doomed,” articles.techrepublic.com.com/5100-10878_11-
8. Ive, G. (2004). “Private finance initiatives and the manage- 1046522.html?tag=rbxccnbtr1; Mersino, A. (2001). “Four
ment of projects,” in Morris, P. W. G., and Pinto, J. K. (Eds.), more warning signs that your project is doomed,” ar-
The Wiley Guide to Managing Projects. New York: Wiley. ticles.techrepublic.com.com/5100-10878_11-1046005.
9. Pinto, J. K., and Slevin, D. P. (1987). “Critical factors in html?tag=rbxccnbtr1.
successful project implementation,” IEEE Transactions on 18. Frame, J. D. (1998). “Closing out the project,” in Pinto, J. K.
Engineering Management, EM-34: 22–27. (Ed.), The Project Management Institute Project Management
10. Cooke-Davies, T. (2001), as cited. Handbook. San Francisco, CA: Jossey-Bass, pp. 237–46;
11. Pinto, M. B., Pinto, J. K., and Prescott, J. E. (1993). Kumar, V., Sersaud, A. N. S., and Kumar, U. (1996). “To
“Antecedents and consequences of project team cross-­ terminate or not an ongoing R&D project: A managerial
functional cooperation,” Management Science, 39: 1281–97. dilemma,” IEEE Transactions on Engineering Management,
12. Cooke-Davies, T. (2001), as cited; Dinsmore, P. C. (1998). 43(3): 273–84; Pritchard, C. L. (1998). “Project termination:
“You get what you pay for,” PMNetwork, 12(2): 21–22. The good, the bad, the ugly,” in Cleland, D. I. (Ed.), Field
13. Meredith, J. R. (1988). “Project monitoring and early termi- Guide to Project Management. New York: Van Nostrand
nation,” Project Management Journal, 19(5): 31–38. Reinhold, pp. 377–93.
14. Dean, B. V. (1968). Evaluating, Selecting and Controlling 19. Smith, R. (2010, 1 de septiembre). “Nuclear plant’s tear-
R&D Projects. New York: American Management down is template,” Wall Street Journal, p. B10; Long,
Association. J. (2010). http://articles.chicagotribune.com/2010-06-
15. Balachandra, R. (1989). Early Warning Signals for R&D 10/news/ct-met-zion-nuke-plant-0610-20100610_1_
Projects. Boston: Lexington Books; Balachandra, R., and zion-plant-exelon-nuclear-exelon-officials; www.
500 Capítulo 14  •  Cierre y terminación del proyecto

chicagobreakingnews.com/2010/06/zion-nuclear-plant- 26. Ranger, S. (2002, 28 de mayo). “Government refuses to bail out


powers-up-for-teardown.html. Libra,” ITWeek, itweek.co.uk/News/1132159; Arnott, S.
20. Field, T. (1997, 15 de octubre). “When bad things hap- (2003, 13 de marzo). “Government IT projects squander
pen to good projects,” CIO Magazine; Dignan, L. (2008). £1.5bn,” ITWeek, itweek.co.uk/News/1139438.
“Promises, promises: A look at Waste Management’s case 27. “Navy scraps plans to build more than two stealth
against SAP,” www.zdnet.com/blog/btl/promises-­promises- ­d estroyers,” www.foxnews.com/0,3566,389222,00.html;
a-look-at-waste-managements-case-against-sap/833; Cavas, C. P. (2008, 22 de julio). “DDG 1000 program will
Kanaracus, C. (2010, 3 de mayo). “SAP, Waste Management end at two ships,” Defense News, www.defensenews.
settle lawsuit,” www.computerworld.com/s/article/9176259/ com/story.php?i=3639737; Axe, D., and Shachtman, N.
SAP_Waste_Management_settle_lawsuit. (2008, 4 de agosto). “Stealth destroyer largely d ­ efenseless,
21. Spirer, H. F., and Hamburger, D. (1983), como se cita. admiral says,” Wired Blog Room, blog.wired. com/​
22. Marsh, P. (2000). “Managing variation, claims, and disputes,” ­defense/2008/08/navys-stealth-d.html; “The A-12 and the
in Turner, J. R., and Simister, S. J. (Eds.), Gower Handbook of arsenal ship.” (2008, 3 de agosto). Information Dissemination,
Project Management, 3rd ed. Aldershot, UK: Gower. informationdissemination.blogspot.com/2008/08/
23. Bennett, S. C. (2006). “Non-binding arbitration: An intro- a-12-and-arsenal-ship.html; Sharp, D. (2008, 23 de Julio).
duction,” Dispute Resolution Journal, 61(2), 22–27. “Cost big factor in decision to sack DDG-1000,” www.
24. Frame, J. D. (1998), como se cita. boston.com/news/local/maine/articles/2008/07/23/
25. Spirer, H. F., and Hamburger, D. (1983), como se cita. navy_scraps_new_destroyer_to_build_older_models/.
APÉNDICE A
Distribución normal estándar acumulada

−' 0 z

Z .00 .01 .02 .03 .04 .05 .06 .07 .08 .09
0.0 .5000 .5040 .5080 .5120 .5160 .5199 .5239 .5279 .5319 .5359
0.1 .5398 .5438 .5478 .5517 .5557 .5596 .5636 .5675 .5714 .5753
0.2 .5793 .5832 .5871 .5910 .5948 .5987 .6026 .6064 .6103 .6141
0.3 .6179 .6217 .6255 .6293 .6331 .6368 .6406 .6443 .6480 .6517
0.4 .6554 .6591 .6628 .6664 .6700 .6736 .6772 .6808 .6844 .6879
0.5 .6915 .6950 .6985 .7019 .7054 .7088 .7123 .7157 .7190 .7224
0.6 .7257 .7291 .7324 .7357 .7389 .7422 .7454 .7486 .7518 .7549
0.7 .7580 .7612 .7642 .7673 .7704 .7734 .7764 .7794 .7823 .7852
0.8 .7881 .7910 .7939 .7967 .7995 .8023 .8051 .8078 .8106 .8133
0.9 .8159 .8186 .8212 .8238 .8264 .8289 .8315 .8340 .8365 .8389
1.0 .8413 .8438 .8461 .8485 .8508 .8531 .8554 .8577 .8599 .8621
1.1 .8643 .8665 .8686 .8708 .8729 .8749 .8770 .8790 .8810 .8830
1.2 .8849 .8869 .8888 .8907 .8925 .8944 .8962 .8980 .8997 .9015
1.3 .9032 .9089 .9066 .9082 .9099 .9115 .9131 .9147 .9162 .9177
1.4 .9192 .9207 .9222 .9236 .9251 .9265 .9279 .9292 .9306 .9319
1.5 .9332 .9345 .9357 .9370 .9382 .9394 .9406 .9418 .9429 .9441
1.6 .9452 .9463 .9474 .9484 .9495 .9505 .9515 .9525 .9535 .9545
1.7 .9554 .9564 .9573 .9582 .9591 .9599 .9608 .9616 .9625 .9633
1.8 .9641 .9649 .9656 .9664 .9671 .9678 .9686 .9693 .9699 .9706
1.9 .9713 .9719 .9726 .9732 .9738 .9744 .9750 .9756 .9761 .9767
2.0 .9772 .9778 .9783 .9788 .9793 .9798 .9803 .9808 .9812 .9817
2.1 .9821 .9826 .9830 .9834 .9838 .9842 .9846 .9850 .9854 .9857
2.2 .9861 .9864 .9868 .9871 .9875 .9878 .9881 .9884 .9887 .9890
2.3 .9893 .9896 .9898 .9901 .9904 .9906 .9909 .9911 .9913 .9916
2.4 .9918 .9920 .9922 .9925 .9927 .9929 .9931 .9932 .9934 .9936
2.5 .9938 .9940 .9941 .9943 .9945 .9946 .9948 .9949 .9951 .9952
2.6 .9953 .9955 .9956 .9957 .9959 .9960 .9961 .9962 .9963 .9964
2.7 .9965 .9966 .9967 .9968 .9969 .9970 .9971 .9972 .9973 .9974
2.8 .9974 .9975 .9976 .9977 .9977 .9978 .9979 .9979 .9980 .9981
2.9 .9981 .9982 .9982 .9983 .9984 .9984 .9985 .9985 .9986 .9986
3.0 .99865 .99869 .99874 .99878 .99882 .99886 .99889 .99893 .99897 .99900
3.1 .99903 .99906 .99910 .99913 .99916 .99918 .99921 .99924 .99926 .99929
3.2 .99931 .99934 .99936 .99938 .99940 .99942 .99944 .99946 .99948 .99950
3.3 .99952 .99953 .99955 .99957 .99958 .99960 .99961 .99962 .99964 .99965
3.4 .99966 .99968 .99969 .99970 .99971 .99972 .99973 .99974 .99975 .99976
3.5 .99977 .99978 .99978 .99979 .99980 .99981 .99981 .99982 .99983 .99983
3.6 .99984 .99985 .99985 .99986 .99986 .99987 .99987 .99988 .99988 .99989
3.7 .99989 .99990 .99990 .99990 .99991 .99991 .99992 .99992 .99992 .99992
3.8 .99993 .99993 .99993 .99994 .99994 .99994 .99994 .99995 .99995 .99995
3.9 .99995 .99995 .99996 .99996 .99996 .99996 .99996 .99996 .99997 .99997
La entrada representa el área bajo la distribución normal estándar acumulada desde - ∞ a z.
501
APÉNDICE B
Tutorial para MS Project 2010

EJERCICIO A: CONSTRUCCIÓN DE LA RED: PROYECTO DE PREPARACIÓN DE SITIO

Tarea Título Predecesora Duración


A Aprobación del contrato - 5
B Inspección del lugar A 5
C Aplicación/Solicitud de permiso A 4
D Evaluación B, C 5
E Líneas de alcantarillado B 7
F Base de pavimentación D 3
G Aprobación C, F 6
H Pavimentación final E, G 8

Con base en la información del cuadro anterior, complete las siguientes tareas:
1. Elabore un diagrama de red con MS Project 2010.
2. Identifique la ruta crítica. ¿Cuánto durará este proyecto?
3. Asigne y nivele los recursos.
4. Suponga que Rose es responsable de las actividades B y C. ¿Hay algún conflicto de recursos? ¿Cómo lo
sabemos?
5. Construya el mismo proyecto con un diagrama de Gantt y un diagrama de red.

1. CONSTRUCCIÓN DEL DIAGRAMA DE RED CON MS PROJECT 2010


Para crear un archivo MS Project 210, el primer paso es ingresar la información en la pantalla de Project. En
la columna “Nombre tarea” liste las diferentes tareas y su duración esperada. La pantalla A.1 muestra una
red incompleta con los nombres de las tareas y su duración esperada. Note que no todas las duraciones se
han completado. Además, observe en este punto que todas las actividades se muestran iniciando inmedia-
tamente. En otras palabras, la predecesora no se ha asignado para ordenar las actividades.

PANTALLA A.1  Ingreso de información del proyecto


503
504 Apéndice B  •  Tutorial para MS Project 2010

El segundo paso es asignar las relaciones predecesoras a cada una de las actividades. Dé doble clic sobre
la tarea B, Inspección del lugar. Esto abrirá una nueva caja de diálogo en la ventana como se muestra en la
pantalla A.2.
Note que una de los pestañas en la caja de diálogo se etiqueta como “Predecesoras”. Dé clic sobre esta
pestaña para abrir la segunda caja de diálogo. Dé clic en el nombre de la tarea y aparecerá la lista de todas las
actividades. Dé clic sobre la actividad “Aprobación de contrato” como se muestra en la pantalla A.3.
Finalmente, dé clic fuera de la caja de diálogo y observe que ha pasado en el diagrama de Gantt: una
flecha de precedencia se adicionó desde la actividad A hasta la actividad B (véase la pantalla A.4). Fechas de
“Inicio” y “Final” se han creado automáticamente , con base en la fecha que el diagrama creó.
Para completar el diagrama, dé doble clic en cada actividad y asigne sus predecesoras en la ventana de
diálogo. Cuando finalice, el diagrama de Gantt debe ser similar al que se presenta en la pantalla A.5.

PANTALLA A.2  Asignación de relaciones de precedencia

PANTALLA A.3  Selección de predecesoras


Ejercicio A: Construcción de la red: proyecto de preparación de sitio 505

PANTALLA A.4  Flechas de predecesoras adicionadas

PANTALLA A.5  Flechas de predecesoras finalizadas

2. IDENTIFICACIÓN DE LA RUTA CRÍTICA. ¿CUÁNTO DURARÁ ESTE PROYECTO?


¿Cómo determina las tareas críticas? ¿A qué se parece la ruta crítica del proyecto? Para encontrar esta infor-
mación, dé clic sobre el pestaña “Formato” en la parte superior de la pantalla y seleccione la caja que dice
“Tareas críticas” debajo de esta. Inmediatamente, se resaltarán todas las actividades críticas en color rojo, en
la pantalla de su computador (véase la pantalla A.6). La ruta crítica sigue el camino de las actividades A – B
– D – F – G – H y dura 32 días (o de noviembre 4 a diciembre 17, al usar el calendario y considerar los fines
de semana no hábiles).

PANTALLA A.6  Ruta crítica y duración del proyecto identificadas


Nota: en la columna “Predecesoras”, a todas las actividades se les asigna un número correspondiente a su fila en la
columna más a la izquierda. De esta forma, a “Aprobación de contrato” se le asigna el número 2.
506 Apéndice B  •  Tutorial para MS Project 2010

3. ASIGNACIÓN Y NIVELACIÓN DE LOS RECURSOS


Podemos entonces adicionar recursos al proyecto basados en la información que se suministra a continuación:

Actividad Recurso responsable


A Todd
B Rose
C Rose
D Mike
E Josh
F Todd
G Mary
H Todd

Dé clic sobre la pestaña “Recursos” y posteriormente dé clic sobre “Asignación de recursos”. A continuación,
se abrirá una nueva ventana para ingresar los nombres de los recursos del proyecto. Una vez el nombre
“Todd” se asigna a la actividad A, la pantalla será similar a la A.7

PANTALLA A.7  Asignación de recursos

PANTALLA A.8  Asignación de recursos finalizada

Continúe asignando recursos a las actividades del proyecto de las personas identificadas en la caja
“Asignación de recursos”. La asignación finalizada de recursos será similar a la de la pantalla A.8.

4. SUPONGA QUE ROSE ES RESPONSABLE DE LAS ACTIVIDADES B Y C. ¿HAY


ALGÚN CONFLICTO DE RECURSOS? ¿CÓMO LO SABEMOS?
¿Asignarle a Rose las actividades B y C causará un conflicto de recursos? Para contestar esta pregunta,
échele un vistazo al diagrama de Gantt generado en la pantalla A.9 y note las cifras de recurso humano en
la columna Información a la izquierda. Esto es una advertencia de conflicto de recursos. En el diagrama
Ejercicio A: Construcción de la red: proyecto de preparación de sitio 507

PANTALLA A.9  Advertencia de conflicto de recursos

de Gantt, puede verse que la asignació de Rose a las actividades B y C será un problema, debido a que
ambas actividades se programaron para comenzar al mismo tiempo. ¿Cómo se resuelve este conflicto?
Una opción es dar clic en la pestaña “Recursos” y resaltar las dos actividades que están en conflicto (B
y C). Entonces, al dar clic en la opción “Nivelación de recursos” aparecerá un cuadro de diálogo en el cual se
puede resaltar el nombre del recurso en conflicto (Rose). La pantalla A.10 muestra con el nombre de Rose
resaltado. Dé clic en “Nivelar ahora”.

PANTALLA A.10  Nivelación de recursos

Note que el cronograma del proyecto (diagrama de Gantt de la pantalla A11) se ha modificado
como resultado de la decisión de nivelar los recursos. Como lo se observa en la pantalla, el nuevo orden
de precedencia para las actividades mueve la actividad C dentro de una relación secuencial con la acti-
vidad D. La pregunta es: “¿Qué le pasa a la duración del proyecto como resultado de la nivelación de
recursos?” La pantalla A.11 muestra que no se cambia la fecha final esperada del proyecto, porque hubo
varios días de holgura en la actividad C. En este ejemplo, retardar el inicio de la actividad C no afecta la
ruta crítica del proyecto, como se observa en la pantalla A.12.
508 Apéndice B  •  Tutorial para MS Project 2010

PANTALLA A.11  Cronograma del proyecto modificado con nivelación de recursos

PANTALLA A.12  Nueva ruta crítica del proyecto después de la nivelación de recursos

5. MUESTRE EL MISMO PROYECTO CON UN DIAGRAMA DE GANTT Y UN


DIAGRAMA DE RED
Finalmente, este proyecto puede mostrarse como un diagrama de red en vez de usar un formato de diagrama
de Gantt. Para efectuar esto, dé clic en la pestaña ubicada a la izquierda de la pestaña “Tarea” y dé clic en
la opción “Vista del diagrama de Gantt”. En el menú desplegable, dé clic en “Diagrama de red” y la vista se
mostrará la pantalla A.13.

PANTALLA A.13  Diagrama de red


Ejercicio B: Adición de detalles y actualización de la redDE un proyecto en ejecución 509

EJERCICIO B: ADICIÓN DE DETALLES Y ACTUALIZACIÓN DE LA RED


DE UN PROYECTO EN EJECUCIÓN
Es importante hacer ajustes menores al cronograma del proyecto para reflejar la información más actuali-
zada. Mantener actualizado el plan con MS Project le permite generar la última información de costos, el
valor ganado u otras actualizaciones de estado del proyecto, así como cualquier otro informe adicional que
ayudará a mantener el registro del proyecto en ejecución.
Considere el plan de proyecto de preparación de sitio del ejercicio A. Hemos creado un cronograma
nivelado en recursos que tomará 32 días para finalizar. Para simplificar, Mary remplazó a Rose en la activi-
dad C (Aplicación de permiso) para omitir el conflicto de recursos del primer ejercicio (véase la pantalla B.1).
Esta reasignación no cambia la lógica de la red o la duración esperada del proyecto; esto solamente remueve
el potencial conflicto de recursos del ejercicio del primer tutorial.

PANTALLA B.1  Condiciones iniciales para el proyecto de preparación de sitio

Información más detallada puede adicionarse a este plan de proyecto, incluidos detalles sobre cada
actividad (retrasos, prioridad, horas de la actividad, etc.), costos asignables de materiales y equipo y el costo
por hora de cada recurso asignado. En la pestaña Vista, seleccione “Hoja de recursos” para ver la lista actual
de recursos para el proyecto, incluidos espacios para el valor de la hora estándar y extras y otra información
pertinente. Asigne el costo de la hora para los recursos, de acuerdo con el siguiente cuadro:

Recurso Costo por hora


Todd $22/hora
Rose $30/hora
Mike $14/hora
Josh $18/hora
Mary $10/hora

Llene con estos valores la hoja de recursos mostrada en la pantalla B.2


El siguiente paso es actualizar el desempeño real del proyecto. Suponga que decidimos actualizar el proyecto
a noviembre 30 en nuestro cronograma. La forma más simple de hacer esto es dar clic en la pestaña Proyecto y
en la opción “Actualizar proyecto”. Esto abrirá una caja de diálogo que pide la fecha en la que desea actualizar
el proyecto. Una vez establecida la fecha a noviembre 30, verá que varios eventos ocurren (véase la pantalla B.3).
Primero, el programa asume que todas las tareas se han completado exitosamente en ese punto del tiempo. En la
columna de la izquierda, una marca de chequeo aparece e indica la finalización de las primeras cinco actividades
(A – E). Además, una barra completa se dibuja en las actividades completadas, mientras que una barra parcial
aparece en la actividad F (Base de pavimentación), debido a que la tarea lleva solamente el 67 %.
También podemos actualizar el proyecto tarea por tarea dando clic en la pestaña Tarea y así resaltamos
cada tarea en orden. Tenemos la opción de marcar cada una como “Actualización según programación” o
podemos manualmente dar clic en las opciones de la izquierda de “Actualización según programación” y asig-
nar los porcentajes de ejecución, 0%, 25%, 50%, 75% o 100%, para cada actividad. Finalmente, podemos dar clic
510 Apéndice B  •  Tutorial para MS Project 2010

PANTALLA B.2  Hoja de recursos

PANTALLA B.3  Actualización del proyecto a noviembre 30

sobre las mismas actividades del diagrama de Gantt y mantener presionado el botón izquierdo del ratón, ubicar
el cursor hacia la derecha sobre la barra de actividades, y resaltar la cantidad de trabajo ejecutado de la tarea. Así,
se identificarán las tareas que se completarán a una fecha específica en el cronograma.
Adicionalmente, podemos generar otra información útil sobre el estado actual del proyecto. Por ejem-
plo, suponga que nos gustaría conocer el uso de recursos y los costos del proyecto a la fecha (recuerde que
en este ejemplo, todos los costos del proyecto se entienden como recursos de mano de obra; no se incluyen
costos adicionales de materiales o maquinaria). Podemos obtener esta información dando clic en la pestaña
“Proyecto” y en la opción “Informes”. En la caja de diálogo abierta, dé clic en “Generales” para generar un
“Resumen del proyecto”. La pantalla B.4 muestra el resumen, que lista los principales detalles del proyecto a
noviembre 30.
La pestaña de resumen del proyecto resalta toda la información importante del proyecto, incluidos
la duración programada del proyecto, la cantidad de trabajo programada (en horas), tanto lo completado
como lo restante y otros aspectos.
Ejercicio B: Adición de detalles y actualización de la redDE un proyecto en ejecución 511

Fechas
Inicio: lun 08/11/10 Fin: mar 21/12/10
Comienzo previsto: NOD Fin previsto: 344 horas
Comienzo real: lun 08/11/10 Fin real: 0 horas
Variación de comienzo: 0 días Variación de fin: 344 horas

Duración
Programada: 32 días Restante: 11,16 días
Prevista: 0 días Real: 20,84 días
Variación: 32 días Porcentaje completado: 65 %

Trabajo
Programado: 344 horas Restante: 120 horas
Previsto: 0 horas Real: 224 horas
Variación: 344 horas Porcentaje completado: 65 %

Trabajo
Programado: $ 6.416,00 Restante: $ 2.064,00
Previsto: $ 0,00 Real: $ 4.320,00
Variación: $ 6.416,00

Estado de las tareas Estado de los recursos


Tareas aún no comenzadas: 2 Recursos de trabajo: 5
Tareas en curso: 1 Recursos de trabajos sobreasignados: 0
Tareas finalizadas: 5 Recursos materiales: 0
Total de tareas: 8 Tola de recursos: 5

PANTALLA B.4  Resumen del proyecto

Retornemos a nuestro ejemplo de estado del proyecto a noviembre 30, pero con algunos paráme-
tros diferentes esta vez. Por ejemplo, suponga que el desempeño real de las tareas a noviembre 30 fue el
siguiente:

Actividad Porcentaje ejecutado


A 100
B 100
C 75
D 40
E 40
F 0
G 0
H 0

Podemos actualizar el progreso de nuestro proyecto realizando los siguientes pasos: primero, en la pestaña de
Vista sobre “Otras vistas”, seleccionamos “Hoja de tareas”. Esto mostrará, para cada actividad, la cantidad de tra-
bajo asignado para completarlo y la cantidad que actualmente se ha ejecutado a la fecha. En la pestaña Vista, en el
grupo “Datos”, dé clic en “Cuadros” y después dé clic en “Trabajo”. Es posible actualizar toda la información del
proyecto mostrado en el cuadro precedente. La hoja de tareas reconfigurada se muestra en la pantalla B.5.
La hoja de tareas corresponde a un diagrama de Gantt actualizado, como se muestra en la pantalla B.6.
Observe que debido a que definimos el trabajo real ejecutado, solamente las actividades A y B se muestran como
completadas. Para otras tareas en ejecución, las barras de tareas ahora solamente muestran ejecución parcial.
Como último ejercicio, suponga que deseamos determinar el valor ganado en este proyecto a noviem-
bre 30 con la información actualizada del estado de las actividades. Primero, se requiere establecer la línea
base del proyecto. Esto puede hacerse dando clic en la pestaña Proyecto. En el Grupo de cronograma, dé clic
en la opción “Establecer línea base”. Esto establece la línea base general del proyecto. Después, en la pestaña
Vista, en el Grupo de datos, dé clic en “Tablas” y en “Más cuadros” para la opción valor ganado. Aplique
esta opción y la información de valor ganado estará disponible como se muestra en la pantalla B.7.
512 Apéndice B  •  Tutorial para MS Project 2010

PANTALLA B.5  Hoja de tareas reconfigurada para noviembre 30

PANTALLA B.6  Diagrama de Gantt reconfigurado

PANTALLA B.7  Cuadro de valor ganado

La pestaña en la pantalla B.7 también contiene el valor planeado (PV, también conocido como BCWS),
el valor ganado (EV o BCWP), el costo real (ACWP) y varianzas de costo y cronograma para cada tarea.
Adicionalmente, la pestaña calcula el presupuesto hasta la conclusión (BAC) de cada actividad, dados los
retrasos actuales para completar varias actividades. Como en las otras pestañas y diagramas, esta informa-
ción puede actualizarse continuamente adicionando más información sobre el desempeño real a lo largo del
ciclo de vida del proyecto.
GLOSARIO

1. Inclusiones y exclusiones 2. Siglas de uso común


Este glosario incluye términos que: Sigla Inglés Español
• Son propios o casi propios de la gerencia de proyec- AC (actual cost): costo real
ACWP (actual cost of work costo real del trabajo realizado
tos (por ejemplo, enunciado del alcance del proyecto, performed):
paquete de trabajo, estructura de desglose del trabajo, BAC (budget at completion): presupuesto hasta la
método de la ruta crítica). conclusión
• No son propios de la gerencia de proyectos sino que se BCWP (budgeted cost of work costo presupuestado del tra-
performed): bajo realizado
usan de forma diferente o con un significado más cer- BCWS (budgeted cost of work costo presupuestado del tra-
cano a la gerencia de proyectos que en el uso general y scheduled): bajo planeado
cotidiano (por ejemplo, fecha de inicio temprano, acti- CCB (change control board): comité de control de cambios
vidad del cronograma). COQ (cost of quality): costo de la calidad
CPAF (cost plus award fee): costos más honorarios por
Este glosario no incluye: cumplimiento de objetivos
• Términos específicos de un área de aplicación (por CPF (cost plus fee): costo más honorarios
ejemplo, prospecto de proyecto como un documento CPFF (cost plus fixed fee): costo más honorarios fijos
CPI (cost performance index) índice de desempeño del costo
legal específico para el sector inmobiliario). CPIF (cost plus incentive fee): costos más honorarios con
• Términos usados en gerencia de proyectos que no difie- incentivos
ren de forma sustancial de su uso diario (por ejemplo, CPM (critical path metodología de la ruta crítica
día del calendario, retraso). methodology):
CV (cost variance): varianza del costo
• Términos compuestos cuyo significado se desprende EAC (estimate at completion): estimación de lo ejecutado
del significado de sus componentes. EF (early finish date): fecha de fin temprano
• Variantes, cuando el significado de la variante se des- EMV (expected monetary value): valor monetario esperado
prende del término base (por ejemplo, reporte de excep- ES (early start date): fecha de inicio temprano
ETC (estimate to complete): estimación hasta la conclusión
ción incluido, reporte de excepciones no incluido). EV (earned value): valor ganado
Como resultado de las inclusiones y exclusiones, este glosario EVM (earned value gerencia del valor ganado
incluye: management):
FF (finish-to-finish): final a final
• Una preponderancia de términos relacionados con la FFP (firm fixed price): contrato de precio fijo
gerencia del alcance del proyecto, gerencia del tiempo FMEA (failure mode and effect
análisis de modo de falla y
del proyecto y gerencia del riesgo del proyecto, ya que analysis): efectos
muchos de los términos utilizados en estas áreas de FPEPA (fixed price with economic
precio fijo con ajuste
price adjustment): económico
conocimiento son únicos o casi únicos en la gerencia de FPIF (fixed price incentive fee):
precio fijo más honorario con
proyectos. incentivos
• Muchos términos de gerencia de calidad del proyecto ya FS (finish to start): final a inicio
que esos términos se usan de manera más restringida que IFB (invitation for bid) invitación a ofrecer
LF (late finish date): fecha de fin tardío
en su uso diario. LOE (level of effort): nivel de esfuerzo
• Relativamente pocos términos relacionados con gerencia LS (late start date): fecha de inicio tardío
de recursos humanos del proyecto y gestión de comuni- OBS (organizational breakdown estructura de desglose
structure): organizacional
caciones del proyecto ya que la mayoría de los términos PDM (precedence diagramming método de diagramación por
usados ​​en estas áreas de conocimiento no difieren signifi- method): precedencia
cativamente de su uso cotidiano. PMBOK® (Project Management Body cuerpo de conocimiento de la
• Relativamente pocos términos relacionados con la geren- of Knowledge): gerencia de proyectos
PMIS (schedule management in- sistema de información de
cia de costos del proyecto, gerencia de la integración del
formation system): gerencia de proyectos
proyecto y la gerencia de adquisiciones del proyecto ya que PMP® (Project Management profesional en gerencia de
muchos de los términos utilizados en estas áreas de cono- Professional): proyectos
cimiento tienen significados concretos que son únicos en PV (planned value): valor planeado
QA (quality assurance): aseguramiento de calidad
un área de aplicación en particular. QC (quality control): control de calidad

®
A Guide to the Project Management Body of Knowledge (PMBOK Guide)—Fourth Edition ©2008 Project Management Institute, 14 Campus Blvd, Newton Square,
PA 19073-3299 USA. Todos los derechos reservados. El material de esta publicación ha sido reproducido con permiso del PMI

513
514 Glosario

RACI (responsible, accountable, responsable, rinde cuentas, Actividad sucesora. La actividad del cronograma que sigue a una activi-
consult, and inform): consultado, informado dad precedente, determinada por su relación lógica.
RAM (responsibility assignment matriz de asignación de Acción preventiva. Directriz documentada para realizar una actividad
matrix): responsabilidades que puede reducir la probabilidad de sufrir consecuencias negativas aso-
RBS (risk breakdown structure): estructura de desglose de
ciadas con los riesgos del proyecto.
riesgos
RFI (request for information): solicitud de información Activos de los procesos de la organización [salida/entrada]. Todos
RFP (request for proposal): solicitud de propuesta o cualquiera de los activos relacionados con los procesos, de todas o
RFQ (request for quotation): solicitud de cotización alguna de las organizaciones involucradas en el proyecto, que se usan
SF (start-to-finish): inicio a final o pueden usarse para ejercer una influencia sobre el éxito del proyecto.
SOW (statement of work): enunciado del alcance
SPI (schedule performance índice de desempeño del Estos activos de los procesos abarcan planes, políticas, procedimientos
index): cronograma y lineamientos, ya sean formales o informales. Los activos de los proce-
SS (start-to-start): inicio a inicio sos también incluyen las bases de conocimiento de las organizaciones,
SV (schedule variance): varianza en el cronograma como lecciones aprendidas e información histórica.
SWOT (strengths, weaknesses, op- DOFA: fortalezas, debilidades, Adelanto [técnica]. Una modificación de una relación lógica que per-
portunities, and threats) oportunidades, amenzas
mite una aceleración de la actividad siguiente. Por ejemplo, en una
T&M (time and material): tiempo y materiales
TQM (Total Quality Management): gerencia de la calidad total dependencia de final a comienzo con un adelanto de diez días, la acti-
WBS (work breakdown estructura de desglose del vidad siguiente puede comenzar diez días antes del final de la actividad
structure): trabajo precedente. Un adelanto negativo equivale a un retraso positivo. Véase
también retraso.
3. Definiciones Administración de las adquisiciones [proceso]. Gerencia de las relacio-
Muchas de las palabras tienen definiciones más amplias y en nes de las adquisiciones del monitoreo de la ejecución de los contratos y
de los cambios y correcciones cuando sean necesarios.
algunos casos diferentes en el diccionario.
Las definiciones utilizan las siguientes convenciones: Adquisición del equipo del proyecto [proceso]. Proceso que consiste
en confirmar la disponibilidad del recurso humano y conformar el
• En algunos casos, un solo término del glosario tiene equipo humano necesario para la ejecución del proyecto.
varias palabras (por ejemplo, planeación de respuesta al Alcance. La suma de productos, servicios y resultados que se proporcio-
riesgo). narán como un proyecto. Véanse también alcance del proyecto y alcance
• Cuando se incluyen sinónimos, no se da una definición del producto.
y se remite al lector al término preferido (por ejemplo, Alcance del producto. Los rasgos y funciones que caracterizan a un
véase término preferido). producto, servicio o resultado.
Alcance del proyecto. El trabajo que debe realizarse para entregar
• Términos relacionados que no son sinónimos se com- un producto, servicio o resultado con las funciones y características
paran al final de la definición (esto es, véase también especificadas.
término relacionado).
Amenaza. Condición o situación desfavorable para el proyecto, con-
junto de circunstancias negativas, conjunto de eventos negativos, riesgo
Acción correctiva. Directiva documentada para ejecutar el trabajo del que si se hace realidad tendrá un efecto negativo en un objetivo del pro-
proyecto y poder, de ese modo, alinear el desempeño futuro previsto del yecto, o posibilidad de cambios negativos. Compárese con oportunidad.
trabajo del proyecto con el plan para la gerencia del proyecto.
Análisis causa raíz [técnica]. Técnica analítica utilizada para determi-
Acta de constitución. Véase acta de constitución del proyecto. nar el motivo subyacente básico que causa una variación, un defecto o
Acta de constitución del proyecto [salida/entrada]. Documento emitido un riesgo. Más de una variación, defecto o riesgo pueden deberse a una
por el iniciador o patrocinador del proyecto que autoriza formalmente un causa.
proyecto, y le confiere al gerente de proyectos la autoridad para utilizar los Análisis cualitativo del desempeño [proceso]. Priorización de riesgos
recursos de la organización a las actividades del proyecto. para mayor análisis o para la acción, al evaluar y combinar la probabili-
Actividad. Componente del trabajo realizado en el transcurso de la eje- dad de ocurrencia y efecto de esos riesgos.
cución del proyecto. Análisis cuantitativo del desempeño [proceso]. Análisis numérico
Actividad casi crítica. Actividad del cronograma que tiene una holgura del efecto de los riesgos identificados sobre los objetivos generales del
total baja. El concepto de casi crítico se aplica a una actividad del crono- proyecto.
grama y a un camino de red del cronograma. El límite inferior al cual la
Análisis de árbol de decisiones [técnica]. El árbol de decisiones es un
holgura total se considera casi crítico depende del juicio de expertos y
diagrama que describe una decisión que se considera y sus consecuen-
varía de un proyecto a otro.
cias de seleccionar una u otra de las alternativas. Se usa cuando algunos
Actividad crítica. Toda actividad del cronograma en una ruta crítica del escenarios futuros de resultados de acciones son inciertos. Incorpora las
cronograma del proyecto. Se determina comúnmente con el método de probabilidades y los costos o recompensas de cada ruta lógica de eventos
la ruta crítica. Aunque algunas actividades son “críticas” en su sentido y decisiones futuras, además del análisis del valor monetario esperado
literal, sin estar en la ruta crítica, este significado se utiliza raramente en para ayudar a la organización a identificar los valores relativos de accio-
el contexto del proyecto. nes alternativas. Véase también valor monetario esperado.
Actividad predecesora. Actividad del cronograma que determina Análisis de debilidades, oportunidades, fortalezas y amenazas
cuándo la actividad siguiente lógica puede comenzar o terminar. (DOFA). Técnica para acopiar información que evalúa el proyecto
Actividad resumen. Grupo de actividades del cronograma relacionadas, desde la perspectiva de las fortalezas, debilidades, oportunidades y ame-
agregadas a algún nivel de resumen, que se muestran /informan como nazas de cada proyecto para aumentar la amplitud de los riesgos consi-
una única actividad en ese resumen. Véase también subproyecto y subred. derados por la gerencia de riesgos.
Glosario
515

Análisis de modo de falla y efectos (FMEA) [técnica]. Proce­dimiento Atributos de la actividad [salida/entrada]. Múltiples atributos asocia-
analítico mediante el cual se analiza cada modo de posible falla en cada dos con cada actividad del cronograma que pueden ser incluirse en la
uno de los componentes de un producto, a fin de determinar sus efectos lista de actividades. Los atributos de las actividades incluyen códigos de
sobre la fiabilidad de ese componente y, por sí mismo o en combinación actividades, actividades precedentes, actividades siguientes, relaciones
con otros modos de posible falla, sobre la confiabilidad del producto o lógicas, adelantos y atrasos, requerimientos de recursos, fechas impues-
sistema y sobre la función requerida del componente; o el examen de un tas, restricciones y supuestos.
producto (al nivel del sistema o en niveles inferiores) para detectar todas Autoridad. Derecho a usar recursos en el proyecto, utilizar los fondos
las formas en que se puede producir una falla. De cada posible falla, financieros, tomar decisiones o dar aprobaciones.
se estiman sus efectos sobre el sistema en su totalidad y de su efecto.
Adicionalmente, se revisan las acciones planeadas para minimizar la Autorización de trabajo. Permiso y directiva, generalmente por escrito,
probabilidad de las fallas y para minimizar sus efectos. para comenzar a trabajar en una actividad del cronograma, paquete de
trabajo o cuenta de control específica. Es un método para autorizar tra-
Análisis de red. Véase análisis de red del cronograma.
bajos del proyecto y garantizar que la organización identificada realice el
Análisis de red del cronograma [técnica].Identificación de las fechas de trabajo en el tiempo asignado y en la secuencia correcta.
inicio tempranas y tardías, así como fechas de finalización más tempra-
Base de conocimientos de lecciones aprendidas. Almacenamiento de
nas y tardías, para las partes no completadas de actividades del proyecto.
información histórica y lecciones aprendidas acerca de los resultados
Véanse también método de la ruta crítica, método de cadena crítica y nive-
de decisiones de selección de proyectos anteriores y de desempeño de
lación de recursos.
proyectos anteriores.
Análisis de reserva [técnica]. Técnica analítica que determina las carac-
Buffer. Véase reserva.
terísticas y relaciones esenciales de los componentes en el plan de la
gerencia del proyecto, a fin de establecer una reserva para la duración Calendario de recursos. Un calendario de días laborales y no laborales
del cronograma, el presupuesto, los costos estimados o los fondos para que determina aquellas fechas en las que cada recurso específico está
un proyecto. ocioso o puede estar activo. Por lo general, define días festivos espe-
cíficos de recursos y periodos de disponibilidad de los recursos. Véase
Análisis de sensibilidad.Técnica de análisis cuantitativo de riesgos y
de modelado utilizada para ayudar a determinar qué riesgos tienen el también calendario del proyecto.
mayor efecto posible sobre el proyecto. Este método evalúa el grado en Calendario del proyecto. Un calendario de días o turnos laborales que
que la incertidumbre de cada elemento del proyecto afecta al objetivo fija las fechas en las cuales se realizan las actividades del cronograma, y
que está examinándose cuando todos los demás elementos inciertos se de días no laborales que determinan las fechas en las cuales no se efec-
mantienen en sus valores de referencia. La representación habitual de túan las actividades del cronograma. Habitualmente define los días fes-
los resultados es un diagrama con forma de tornado. tivos, los fines de semana y los horarios de los turnos. Véase también
Análisis de tendencias [técnica]. Análisis que utiliza modelos matemá- calendario de recursos.
ticos para pronosticar resultados sobre la base de resultados históricos. Calidad. Grado en el que un conjunto de características inherentes
Es un método para determinar la variación respecto a la referencia de satisface los requerimientos.
un parámetro de presupuesto, costo, cronograma o alcance, en el que Cambio en el alcance. Cualquier cambio en el alcance del proyecto.
se utilizan datos de periodos de informes de avance anteriores y se pro- Un cambio en el alcance casi siempre requiere un ajuste en el costo o
yecta qué nivel puede alcanzar la variación de ese parámetro respecto a cronograma del proyecto.
la referencia en un punto futuro del proyecto, si no se realizan cambios
en la ejecución del proyecto. Categoría de riesgo. Grupo de posibles causas de riesgo. Las causas
de riesgo pueden agruparse en categorías como técnica, externa, de
Análisis de varianza [técnica]. Método para resolver la variación total la organización, ambiental o de gerencia de proyectos. Una categoría
en el conjunto de variables alcance, costo y cronograma en variantes del puede incluir subcategorías como madurez técnica, clima o estimación
componente específicas asociadas con factores definidos que afectan las
agresiva.
variables alcance, costo y cronograma.
Causa común. Una fuente de variación que es inherente al sistema y
Análisis Monte Carlo. Una técnica que calcula, o repite, el costo del
previsible. En un diagrama de control, aparece como una parte de la
proyecto o el cronograma del proyecto, muchas veces, utilizando valo-
variación de proceso al azar (es decir, la variación de un proceso que
res de datos iniciales seleccionados al azar, a partir de distribuciones de
se podría considerar normal o no inusual) y se indica por medio de un
probabilidades de costos o duraciones posibles, para calcular una distri-
patrón de puntos al azar dentro de los límites de control. También se la
bución de los costos totales del proyecto o fechas de conclusión posibles.
conoce como causa al azar. Compárese con causa especial.
Área de aplicación. Una categoría de proyectos que tienen componentes
Causa especial.Fuente de variación que no es inherente al sistema, que
comunes significativos pero que no necesariamente están presentes en
no es previsible pero sí intermitente. Se puede atribuir a un defecto en el
todos los proyectos. Usualmente se define en términos de sus produc-
sistema. En un diagrama de control, se indica por los puntos que exce-
tos (esto es, tecnologías similares o métodos de producción) o tipos de
den los límites de control o por los patrones de puntos que no son al
clientes (es decir, internos versus externos) o sector de la industria (esto
azar dentro de los límites de control. También se la conoce como causa
es, servicios, automóviles, industria aeroespacial, tecnología de informa-
atribuible. Compárese con causa común.
ción, etc.). Las áreas de aplicación pueden superponerse.
Área de conocimiento de la gerencia de proyectos. Un área definida Ciclo de vida. Véase ciclo de vida del proyecto.
por sus requerimientos de conocimientos y que se describe en términos Ciclo de vida del proyecto. Conjunto de fases del proyecto que gene-
de sus procesos de componentes, prácticas, datos iniciales, resultados, ralmente son secuenciales, y cuyos nombres y números se determinan
herramientas y técnicas. según las necesidades de control de la organización u organizaciones
Aseguramiento de la calidad del desempeño [proceso]. Auditaje de los involucradas en el proyecto. Un ciclo de vida puede documentarse con
requerimientos de calidad y los resultados obtenidos a partir de medidas una metodología.
de control de calidad, a fin de garantizar que las definiciones de las ope- Cierre de las adquisiciones [proceso]. Finalización de cada adquisición
raciones y las normas de calidad adecuadas se utilizan. del proyecto.
516 Glosario

Ciclo de vida del producto. Conjunto de fases del producto que, general- Control de calidad del desempeño [proceso]. Monitorear y registrar los
mente, son secuenciales y sin superposición, cuyos nombres y números se resultados de la realización de las actividades de control de calidad, a fin
determinan según las necesidades de fabricación y control de la organi- de evaluar el desempeño y recomendar los cambios necesarios.
zación. La última fase del ciclo de vida del producto es, por lo general, su Control de costos [proceso]. Monitoreo de la situación del proyecto
retiro. Generalmente, un ciclo de vida del proyecto está contenido dentro para actualizar el presupuesto de este y gerenciar cambios en la línea
de uno o más ciclos de vida del producto. base de costo.
Cierre del proyecto o fase [proceso]. Finalización de todas las activi- Control del alcance [proceso]. Monitorear la situación del proyecto, el
dades de todos los grupos de procesos de la gerencia de proyectos para alcance del producto y la gerencia de los cambios en la línea base del
completar formalmente el proyecto o la fase. alcance.
Código de cuentas [herramienta]. Todo sistema de numeración que se Control del cronograma [proceso]. Monitorear la situación del pro-
utilice para identificar de forma única cada uno de los componentes de yecto para actualizar el avance de este y gerenciar cambios en la línea de
la estructura de desglose del trabajo. base del cronograma.
Componente de la estructura de desglose del trabajo. Una entrada en la Convergencia de ruta. La fusión o unión de rutas de red de cronogra-
estructura de desglose del trabajo que se puede realizar en cualquier nivel. mas paralelos en un mismo nodo, en un diagrama de red de cronograma
Compresión del cronograma [técnica]. Reducción de la duración del del proyecto. La convergencia de ruta se caracteriza por una actividad
cronograma del proyecto sin disminuir el alcance del proyecto. Véanse del cronograma con más de una actividad precedente.
también intensificación y ejecución rápida. Corrección de defectos. Identificación formalmente documentada de
Conducción de adquisiciones [proceso]. Obtención de respuestas de los un defecto en un componente de un proyecto, con una recomendación
proveedores, selección de un proveedor y adjudicación de un contrato. de reparar ese defecto o remplazar completamente el componente.
Contingencia. Véase reserva. Corrupción del alcance. Adición de funciones y funcionalidad (alcance
Contrato [salida/entrada]. Un contrato es un acuerdo que vincula a las del proyecto) sin considerar los efectos sobre el tiempo, los costos y los
partes, en virtud del cual el vendedor se obliga a proveer el producto, recursos, o sin la aprobación del cliente.
servicio o resultado especificado y el comprador a pagar por aquel. Costo de la calidad (COQ) [técnica]. Método para determinar los
Contrato de costos más honorarios con incentivos (CPIF). Tipo de costos incurridos para asegurar la calidad. Los costos de prevención y
contrato de costos reembolsables en el que el comprador le reembolsa al evaluación (costos de cumplimiento) incluyen costos de planeación de
vendedor los costos permitidos a este (según se define costos permitidos calidad, control de calidad y garantía de calidad para asegurar el cumpli-
en el contrato), y el vendedor obtiene sus ganancias si cumple los crite- miento de los requerimientos (es decir, capacitación, sistemas de con-
rios de desempeño definidos. trol de calidad, etc.). Los costos de fallos (de no cumplimiento) incluyen
los costos de reprocesar productos, componentes o procesos que no
Contrato de costo más honorarios fijos (CPFF). Tipo de contrato de
cumplen, los costos de la garantía del trabajo y desperdicio y la pérdida
costos reembolsables en el que el comprador le reembolsa al vendedor
de reputación.
los costos permitidos a este (según se define costos permitidos en el con-
trato) más una cantidad fija de ganancias (pago fijo). Costo presupuestado del trabajo planeado (BCWS). Véase valor pla-
neado (PV).
Contrato de precio fijo (FFP). Tipo de contrato de precio fijo en el cual el
comprador le paga al vendedor un monto establecido (conforme lo defina Costo real del trabajo realizado (ACWP). Véase costo real (AC).
el contrato), independientemente de los costos que tenga el vendedor. Creación de EDT (estructura de desglose del trabajo) [proceso].
Contrato de precio fijo más honorario con incentivo (FPIF). Tipo de Subdivisión de los entregables del proyecto y del trabajo del proyecto en
contrato en el cual el comprador le paga al vendedor un monto esta- componentes más pequeños y más fáciles de manejar.
blecido (conforme lo defina el contrato), y el vendedor puede ganar un Criterios. Normas, reglas o pruebas en las que se basa una opinión o
monto adicional si este cumple los criterios de desempeño establecidos. decisión, o mediante las cuales se evalúa un producto, servicio, resul-
Contrato de tiempo y materiales (T&M). Acuerdo híbrido que con- tado o proceso.
tiene aspectos de contratos de costos reembolsables y de contratos de Cronograma.Véase cronograma del proyecto y véase también modelo del
precio fijo. Los contratos de tiempo y materiales se asemejan a los acuer- cronograma.
dos de costos reembolsables en que no tienen un final definido, porque Cronograma de hitos [herramienta]. Resumen que identifica los prin-
el valor total del acuerdo no se define en el momento de la adjudicación. cipales hitos del cronograma. Véase también cronograma maestro.
Por tanto, los contratos de tiempo y materiales pueden crecer en valor
contractual como si fueran acuerdos del tipo de costos reembolsables. Cronograma del proyecto [salida/entrada]. Las fechas planeadas para
Por otro lado, los acuerdos de tiempo y materiales también se aseme- ejecutar las actividades del cronograma y las fechas planeadas para cum-
jan a los acuerdos de precio fijo. Por ejemplo, el comprador y el vende- plir los hitos del cronograma.
dor establecen por anticipado las tarifas unitarias cuando las dos partes Cronograma maestro [herramienta]. Cronograma resumido del pro-
acuerdan una tarifa para la categoría de ingenieros expertos. yecto que identifica los principales entregables y componentes de la
Contrato reembolsable en costos. Tipo de contrato que implica el pago estructura de desglose del trabajo y los hitos claves del cronograma.
al vendedor por los costos reales de este, más un honorario que, por lo Cuenta control [herramienta]. Un punto de control de gerencia donde
general, representa la ganancia del vendedor. Los contratos de costos se integran el alcance, el presupuesto, el costo real y el cronograma y
reembolsables suelen incluir cláusulas de incentivos, en virtud de las se comparan estos con el valor ganado de la medición del desempeño.
cuales si el vendedor cumple o supera los objetivos seleccionados del Véase también paquete de trabajo.
proyecto, como metas del cronograma o costo total, entonces el vende- Cuerpo de conocimientos de la gerencia de proyectos (PMBOK ®).
dor recibe del comprador un pago de incentivo o bonificación. Expresión que describe la suma de conocimientos de la profesión geren-
Control. Comparación del desempeño real con el desempeño planifi- cia de proyectos. Al igual que en otras profesiones, como el derecho,
cado; análisis de las variaciones; cálculo de las tendencias para realizar la medicina y las ciencias económicas, los fundamentos residen en los
mejoras en los procesos; evaluación de las alternativas y recomendación practicantes y académicos que los aplican y desarrollan. El conjunto
de las acciones correctivas apropiadas, según sea necesario. de los fundamentos para la gerencia de proyectos incluye prácticas
Glosario
517

tradicionales comprobadas y ampliamente utilizadas, así como prácticas Diagrama de Gantt [herramienta]. Representación gráfica de informa-
innovadoras emergentes para la profesión. Los fundamentos incluyen ción relativa al cronograma. En un típico diagrama de barras, las acti-
material publicado y no publicado. El PMBOK® evoluciona de forma vidades del cronograma o los componentes de la estructura de desglose
permanente. La Guía del PMBOK® identifica el subconjunto de fun- del trabajo se enumeran en la parte izquierda del diagrama, las fechas se
damentos para la gerencia de proyectos que generalmente se conocen presentan en la parte superior y la duración de las actividades se muestra
como buenas prácticas. como barras horizontales.
Curva S. Representación gráfica de los costos acumulativos, las horas de Diagrama de influencia [herramienta]. Representación gráfica de situa-
mano de obra, el porcentaje de trabajo y otras cantidades, trazados en rela- ciones que muestran las influencias causales, la cronología de eventos y
ción con el tiempo. Se utiliza para representar el valor planeado, el valor otras relaciones entre las variables y los resultados.
ganado y el costo real del trabajo del proyecto. El nombre proviene de la Diagrama de Pareto [herramienta]. Un histograma, ordenado por la
forma en S de la curva (más uniforme al principio y al final, más pronun- frecuencia de ocurrencia, que muestra cuántos resultados se generaron
ciada en el medio) producida en un proyecto que comienza despacio, se por cada causa identificada.
acelera y desacelera al final. Término que también se utiliza para expresar
Diagrama de red del cronograma del proyecto [salida/entrada]. Toda
la distribución acumulada de probabilidad, que consiste en el resultado de
representación esquemática de las relaciones lógicas entre las activida-
una simulación, una herramienta de análisis cuantitativo de riesgos.
des del cronograma del proyecto. Siempre se traza de izquierda a dere-
Defecto. Imperfección o deficiencia en un componente de un proyecto, cha para reflejar la cronología de trabajo del proyecto.
la cual genera que ese componente no cumpla sus requerimientos o
Diagrama de red del cronograma escalado en tiempo [herramienta].
especificaciones y deba repararse o remplazarse.
Todo diagrama de red del cronograma del proyecto diseñado de forma
Definición de las actividades [proceso]. Identificación de las accio- tal que la posición y la longitud de la actividad representa su duración.
nes específicas que deben realizarse para elaborar los entregables del Esencialmente, es un diagrama de barras que incluye la lógica de la red
proyecto. del cronograma.
Definición del alcance [proceso]. Descripción detallada del proyecto Diccionario de la estructura de desglose del trabajo [entrada/salida].
y del producto. Documento que describe cada componente en la estructura de desglose
Dependencia. Véase relación lógica. del trabajo (EDT). Para cada componente de la EDT, el diccionario de
Desarrollo del acta de constitución del proyecto [proceso]. Autori­ la EDT incluye una breve definición del alcance o enunciado del tra-
zación formal de un proyecto o fase que documenta los requerimientos bajo, entregables definidos, una lista de actividades asociadas y una lista
iniciales que satisfacen las necesidades y expectativas de los interesados. de hitos. Otra información puede incluir: la organización responsable,
las fechas de comienzo y finalización, los recursos requeridos, una esti-
Desarrollo del cronograma [proceso]. Análisis de secuencias de activi-
mación del costo, el número de cargo, la información del contrato, los
dades, duraciones, requerimientos de recursos y restricciones del crono-
requerimientos de calidad y las referencias técnicas para facilitar el eje-
grama para elaborarlo.
cución del trabajo.
Desarrollo del equipo del proyecto [proceso]. Mejora de las competen-
Dirección y gerencia de la ejecución del proyecto [proceso]. Ejecución
cias y la interacción de los miembros del equipo y del ambiente general
del trabajo definido en el plan para la gerencia del proyecto a fin de
del equipo, para lograr un mejor desarrollo del proyecto.
cumplir los objetivos del proyecto.
Desarrollo del plan de gerencia del proyecto [proceso]. Documentación
Directorio del equipo del proyecto. Lista documentada de los miem-
de las medidas necesarias para definir, preparar, integrar y coordinar
bros del equipo del proyecto, sus funciones en este e información rela-
todos los planes subsidiarios.
cionada con la comunicación.
Desarrollo del plan de recursos humanos [proceso]. Identificación y
Disparadores. Indicadores de que ha ocurrido o está por ocurrir un
documentación de los papeles dentro de un proyecto, las responsabili-
riesgo. Los disparadores pueden descubrirse en el proceso de identifi-
dades, las habilidades requeridas y las relaciones de comunicación, así
cación de riesgos y pueden observarse en el proceso de seguimiento y
como la elaboración de un plan de gerencia de personal.
control de riesgos. A veces se los llama síntomas de riesgo o señales de
Descripción del alcance del producto. La descripción narrativa y docu- advertencia.
mentada del alcance del producto.
Distribución de información [proceso]. Procedimiento que pone a
Desglose [técnica]. Planeación que subdivide el alcance del proyecto disposición de los interesados del proyecto la información relevante,
y los entregables del proyecto en componentes más pequeños y más según se planifique.
fáciles de manejar, hasta que el trabajo del proyecto asociado a lograr
Divergencia de ruta. Extensión o generación de rutas de red de cro-
el alcance del proyecto y a conseguir los entregables se defina con deta-
nogramas paralelos de un mismo nodo, en un diagrama de red de cro-
lle suficiente para respaldar la ejecución, el seguimiento y el control del
nograma del proyecto. La divergencia de rutas se caracteriza por una
trabajo.
actividad del cronograma con más de una actividad siguiente.
Determinación del presupuesto [proceso]. Suma de los costos esti-
Documentos de adquisiciones [salida/entrada]. Documentos que se
mados de actividades individuales o paquetes de trabajo para establecer
usan en actividades de oferta y propuesta, que incluyen la invitación
una línea de base de costo aprobada.
a licitar del comprador, invitación a negociar, solicitud de informa-
Diagrama de control [herramienta]. Representación gráfica de datos ción, solicitud de presupuesto, solicitud de propuesta y respuestas del
del proceso a lo largo del tiempo y comparados con límites de control vendedor.
establecidos, que cuentan con una línea central que ayuda a detectar
Duración. El total de periodos de trabajo (sin incluir vacaciones u
una tendencia de valores trazados respecto a cualquiera de los límites
otros periodos no laborales) requeridos para terminar una actividad del
de control.
cronograma o un componente de la estructura de desglose del trabajo
Diagrama de flujo [técnica]. Representación en formato de diagrama (EDT). Generalmente, se expresa en jornadas o semanas laborales. A
de los datos iniciales, medidas de un proceso y resultados de uno o más veces se equipara incorrectamente a tiempo transcurrido. Compárese
procesos dentro de un sistema. con esfuerzo.
518 Glosario

Duración de la actividad. El tiempo medido en unidades calendario Especificación. Documento que especifica, de manera completa, pre-
que transcurre entre el comienzo y el final de una actividad del crono- cisa y verificable, los requerimientos, el diseño, el comportamiento y
grama. Véase también duración. otras características de un sistema, componente, producto, resultado
Duración real. Tiempo en unidades calendario entre la fecha de o servicio y, a menudo, los procedimientos para determinar si se han
comienzo real de la actividad del cronograma y la fecha de corte del cro- cumplido estas disposiciones. Algunos ejemplos son: especificaciones
de requerimientos, especificaciones de diseño, especificaciones del pro-
nograma del proyecto, si la actividad está en progreso; o la fecha de final
ducto y especificaciones de prueba.
real, si la actividad del cronograma está terminada.
Estándar. Documento que proporciona, para uso común y repetido,
Ejecución del control integrado de cambios [proceso]. Análisis de
reglas, pautas o características de actividades o sus resultados, orientado
todas las solicitudes de cambios, aprobación de los cambios y geren-
a lograr el óptimo grado de orden en un contexto determinado.
cia de los cambios a los entregables, a los activos de los procesos de la
organización, a los documentos del proyecto y al plan de la gerencia del Estimación [salida/entrada]. Evaluación cuantitativa del monto o resul-
proyecto. tado probable. Habitualmente se aplica a los costos, recursos, esfuerzo y
duraciones de los proyectos, y normalmente precedida de un calificador
Ejecución rápida [técnica]. Procedimiento específico de aceleración del (por ejemplo, preliminar, conceptual, de factibilidad, de orden de mag-
cronograma de un proyecto que cambia la lógica de la red para sola- nitud, definitiva). Siempre debería incluir alguna indicación de exacti-
par fases que normalmente se realizarían de forma secuencial, como la tud (por ejemplo, ± x por ciento). Véase también presupuesto.
fase de diseño y la fase de construcción, o para llevar a cabo activida-
Estimación análoga [técnica]. Estimación que usa valores de paráme-
des del cronograma en forma paralela. Véase también compresión del
tros como alcance, costos, presupuesto y duración o medidas como
cronograma.
tamaño, peso y complejidad de actividades similares anteriores, que
Ejecutar. Dirigir, gerenciar, realizar y llevar a cabo el trabajo del pro- sirve de base para la estimación de los mismos parámetros o medidas
yecto, proporcionar los entregables y brindar información sobre el des- de actividades futuras.
empeño del trabajo.
Estimación ascendente [técnica]. Un método de estimación de un
Elaboración progresiva [técnica]. Mejorar y agregar detalles continua- componente del trabajo. El trabajo se descompone más detalladamente.
mente a un plan con información más detallada y específica y con esti- Se prepara un estimado de lo que se necesita para cumplir los requeri-
maciones más precisas, a medida que el proyecto avanza. De ese modo mientos de cada una de las partes del trabajo inferiores y más detalla-
se podrán producir planes más precisos y completos que sean el resul- das, y estas estimaciones se suman luego a la cantidad total del compo-
tado de las reiteraciones sucesivas del proceso de planeación. nente del trabajo. La exactitud de la estimación ascendente se basa en el
Entrada [entrada de proceso]. Todo elemento, interno o externo, del tamaño y complejidad del trabajo identificado en los niveles inferiores.
proyecto requerido por un proceso antes de que ese proceso continúe. Estimación de la duración de las actividades [proceso]. Aproximación
Puede ser un resultado de un proceso precedente. de la cantidad de periodos de trabajo necesarios para finalizar activida-
des individuales con los recursos estimados.
Entregable [salida/entrada]. Todo producto, resultado o capacidad de
prestar un servicio único y verificable que debe producirse para finalizar Estimación de lo ejecutado (EAC) [salida/entrada]. El costo total
un procedimiento, una fase o un proyecto. A menudo se utiliza con- previsto de una actividad del cronograma, de un componente de la
cretamente en relación con un entregable externo, el cual está sujeto a estructura de desglose del trabajo o del proyecto, cuando se complete
aprobación del patrocinador del proyecto o del cliente. Véanse también el alcance definido del trabajo. El EAC puede calcularse sobre la base
producto y resultado. del desempeño hasta la fecha o del estimado por el equipo del proyecto
basado en otros factores; en este caso se denomina última estimación
Enunciado del alcance (SOW). Descripción de los productos, servicios revisada. Véanse también técnica del valor ganado y estimación hasta la
o resultados que deben suministrarse. También se conoce como defini- conclusión.
ción del trabajo o descripción del trabajo.
Estimación de los costos [proceso]. Desarrollo de una aproximación
Enunciado del alcance del proyecto [salida/entrada]. Descripción del de los recursos monetarios necesarios para completar las actividades del
alcance del proyecto con los principales entregables, hipótesis del pro- proyecto.
yecto, restricciones del proyecto, y del trabajo, la cual proporciona una
Estimación de los recursos de las actividades [proceso]. Aproximación
base documentada que permite tomar decisiones futuras sobre el pro-
del tipo y cantidad de materiales, personas, equipos o suministros
yecto y confirmar o desarrollar un entendimiento común del alcance del
requeridos para ejecutar cada actividad.
proyecto entre los interesados.
Estimación de tres puntos [técnica]. Análisis que utiliza tres estimacio-
Equipo de gerencia de proyectos. Los miembros del equipo del pro-
nes de costo o duración en las que se muestran un escenario optimista,
yecto que participan directamente en las actividades de gerencia de este. uno más probable y uno pesimista. Esta técnica se aplica para aumentar
En algunos proyectos más pequeños, el equipo de gerencia del pro- la precisión de las estimaciones de costo o duración, cuando el compo-
yecto puede incluir prácticamente a todos los miembros del equipo del nente de actividad o del costo subyacente es incierto.
proyecto.
Estimación hasta la conclusión (ETC). [salida/entrada]. El costo pre-
Equipo virtual. Grupo de personas con un objetivo en común, que visto necesario para terminar todo el trabajo restante para una actividad
cumple sus respectivos roles o papeles empleando muy poco o nada de del cronograma, un componente de la estructura de desglose del trabajo
tiempo en reuniones cara a cara. Por lo general, se utilizan varias tecno- o el proyecto. Véanse también técnica del valor ganado y estimación de
logías para facilitar la comunicación entre los miembros del equipo. Los lo ejecutado.
equipos virtuales pueden estar conformados por personas separadas por
Estimación paramétrica [técnica]. Estimación que utiliza una rela-
grandes distancias.
ción estadística entre los datos históricos y otras variables (por ejem-
Esfuerzo. Cantidad de unidades laborales necesarias para terminar una plo, pies cuadrados en la construcción; líneas de código en desarrollo
actividad del cronograma o un componente de la estructura de desglose de software) para calcular una estimación de parámetros de una acti-
del trabajo. Generalmente se expresa como horas, días o semanas de vidad, como alcance, costo, presupuesto y duración. Un parámetro de
trabajo del personal. Compárese con duración. costos se obtiene multiplicando la cantidad planeada de trabajo que se
Glosario
519

deba realizar por el costo histórico por unidad, a fin de obtener el costo Fecha de corte. Fecha hasta la cual el sistema de generación de infor-
estimado. mes del proyecto refleja la situación y los logros obtenidos. También se
Estructura de desglose de recursos. Estructura jerárquica de recursos denomina a la fecha de y fecha actual.
por categoría y tipos de estos utilizada en la nivelación de recursos de los Fecha de finalización. Punto en el tiempo asociado con la conclusión
cronogramas y en el desarrollo de cronogramas limitados por los recur- de una actividad del cronograma. Habitualmente se cualifica con una
sos; además, puede usarse para identificar y analizar las asignaciones de de las siguientes opciones: real, planificada, estimada, programada, tem-
recursos humanos a los proyectos. prano, tardío, de referencia, objetivo o actual.
Estructura de desglose de riesgos (RBS) [técnica]. Una descripción Fecha de fin temprano (EF). En el método de la ruta crítica, el punto en
jerárquica de los riesgos del proyecto, identificados y organizados por el tiempo más temprano posible en el cual las porciones no completa-
categoría y subcategoría, que identifica las distintas áreas y causas de das de una actividad del cronograma (o del proyecto) pueden finalizar,
posibles riesgos. La estructura de desglose del riesgo a menudo suele según la lógica de la red del cronograma, la fecha de los datos/ fecha de
adaptarse para tipos de proyectos específicos. corte y cualquier restricción del cronograma. Las fechas de finalización
Estructura de desglose del trabajo (EDT)/work breakdown struc- tempranas pueden cambiar a medida que el proyecto avanza y a medida
ture (WBS). [entrada/salida]. Descomposición jerárquica orientada al que se realizan cambios en el plan para la gerencia del proyecto.
entregable, relativa al trabajo que ejecutará el equipo del proyecto para Fecha de fin tardío (LF). En el método de la ruta crítica, el punto en el
lograr los objetivos de este y crear los entregables requeridos. Organiza y tiempo más lejano posible en que una actividad del cronograma puede
define el alcance total del proyecto. finalizar, sobre la base de la lógica de la red del cronograma, la fecha
Estructura de desglose organizacional (EDO)/organizational break- de conclusión del proyecto y cualquier restricción asignada a las acti-
down structure (OBS). [herramienta]. Descripción jerárquica de la vidades del cronograma, sin violar restricción alguna del cronograma
organización del proyecto, dispuesta de tal manera que se relacionan ni retrasar la fecha de conclusión del proyecto. Las fechas de fin tardío
los paquetes de trabajo con las unidades ejecutoras de la organización. se determinan durante el cálculo del recorrido hacia atrás de la red del
cronograma del proyecto.
Evitar el riesgo [técnica]. Planeación de la respuesta a los riesgos ante
una amenaza que genera cambios en el plan de la gerencia del proyecto, Fecha final planeada (schedule finish: SF). El momento de finalización
planeada del trabajo de una actividad del cronograma. Normalmente, la
con la intención de eliminar el riesgo o proteger los objetivos del pro-
fecha de finalización planificada se encuentra dentro del rango de fechas
yecto de su efecto.
delimitado por la fecha de finalización temprana y la fecha de finali-
Factores ambientales de la organización [salida/entrada]. Todo factor zación más tarde. Puede reflejar una nivelación de recursos escasos. A
ambiental externo e interno de la organización que rodean o tienen veces se denomina fecha de finalización programada.
alguna influencia sobre el éxito del proyecto. Estos factores correspon-
Fecha impuesta. Fecha fija impuesta sobre una actividad del crono-
den a cualquier empresa involucrada en el proyecto, e incluyen la cul-
grama o hito del cronograma, habitualmente expresada como una fecha
tura y la estructura de la organización, la infraestructura, los recursos
que exige “comenzar después del” y “finalizar antes del”.
existentes, las bases de datos comerciales, las condiciones del mercado y
el software de gerencia de proyectos de la organización. Fecha inicial planeada (schedule start: SS).El momento de inicio pla-
neado del trabajo de una actividad del cronograma. Normalmente, la
Fase. Véase fase del proyecto.
fecha de comienzo planeada se encuentra dentro del rango de fechas
Fase del proyecto. Conjunto de actividades del proyecto relacionadas delimitado por la fecha de inicio temprano y la fecha de inicio tardío.
lógicamente y que generalmente culminan con la finalización de un Puede reflejar una nivelación de recursos escasos. A veces se denomina
entregable principal. Las fases del proyecto suelen completarse de forma fecha de comienzo programada.
secuencial, pero pueden superponerse en determinadas situaciones de
Final a inicio (FS). La relación lógica en virtud de la cual el trabajo de la
proyectos. Una fase del proyecto es un componente de un ciclo de vida
actividad siguiente solo puede comenzar cuando concluya el trabajo de
del proyecto. Una fase del proyecto no es un grupo de procesos de la
la actividad precedente. Véase también relación lógica.
gerencia de proyectos.
Final a final (FF). La relación lógica en virtud de la cual el trabajo de la
Fecha de inicio. Punto en el tiempo asociado con el inicio de una activi-
actividad siguiente solo puede finalizar cuando concluya el trabajo de la
dad del cronograma, habitualmente calificada con una de las siguientes
actividad precedente. Véase también relación lógica.
opciones: real, planeada, estimada, programada, temprano, tardío, obje-
tivo de referencia o actual. Gerencia de adquisiciones del proyecto [área de conocimiento]. Esta
incluye los procesos de compra o adquisición de los productos, servicios
Fecha de inicio tardío (LS). En el método de la ruta crítica, el punto
o resultados que es necesario obtener fuera del equipo del proyecto, a fin
en el tiempo más lejano posible en que una actividad del cronograma
de ejecutar el trabajo.
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 Gerencia de calidad del proyecto [área de conocimiento]. Esta incluye
actividades del cronograma sin violar restricción alguna del cronograma los procesos y actividades de la organización ejecutante que determinan
ni retrasar la fecha de conclusión del proyecto. Las fechas de inicio tar- responsabilidades, objetivos y políticas de calidad, a fin de que el proyecto
dío se determinan durante el cálculo del recorrido hacia atrás de la red satisfaga las necesidades para la que lo lleva a cabo.
del cronograma del proyecto. Gerencia de comunicaciones del proyecto [área de conocimiento]. Esta
Fecha de inicio temprano (ES). En el método de la ruta crítica, el punto incluye los procesos requeridos para garantizar que la generación, reco-
en el tiempo más temprano posible en el cual las porciones no comple- pilación, distribución, el almacenamiento, recuperación y disposición
tadas de una actividad del cronograma (o del proyecto) pueden comen- final de la información del proyecto sean adecuados y oportunos.
zar, basado en la lógica de la red del cronograma, la fecha de los datos/ Gerencia de costos del proyecto [área de conocimiento]. Esta incluye
fecha de corte y cualquier restricción del cronograma. Las fechas de los procesos que involucran la estimación, presupuestación y el control
inicio temprano pueden cambiar a medida que el proyecto avanza y a de los costos, de modo que se complete el proyecto dentro del presu-
medida que se realizan cambios en el plan para la gerencia del proyecto. puesto aprobado.
520 Glosario

Gerencia de la integración del proyecto [área de conocimiento]. Esta Herramienta. Algo tangible, como una plantilla o un programa de sof-
incluye los procesos y actividades necesarios para identificar, definir, tware, utilizado al realizar una actividad para producir un producto o
combinar, unificar y coordinar los diversos procesos y actividades de resultado.
gerencia del proyecto dentro de los grupos de procesos de esta. Histograma de recursos. Diagrama de barras que muestra la cantidad
Gerencia de las expectativas de los interesados [proceso]. Comunicarse de tiempo que un recurso está planeado para trabajar durante una serie
y trabajar en conjunto con los interesados para satisfacer sus necesida- de periodos. La disponibilidad de recursos puede representarse como
des y abordar incidentes a medida que estos se presentan. una línea para fines comparativos. Barras contrastadas pueden mostrar
el consumo real de recursos utilizados a medida que avanza el proyecto.
Gerencia de portafolio [técnica]. La gerencia centralizada de uno o más
portafolios, que incluye la identificación, priorización, autorización, Hito. Punto o evento significativo dentro del proyecto.
gestión y control de proyectos, programas y otros trabajos relacionados, Holgura. También se denomina margen. Véanse holgura total y holgura
a fin de alcanzar objetivos estratégicos de negocio específicos. También libre.
se conoce como administración del portafolio o gerenciamiento del Holgura libre. La cantidad de tiempo que una actividad del crono-
portafolio. grama puede demorarse sin demorar la fecha de comienzo temprano
Gerencia de programa. La gerencia coordinada centralizada de un pro- de cualquier actividad del cronograma inmediatamente después. Véase
grama para lograr sus objetivos y beneficios estratégicos. también holgura total.

Gerencia de proyectos. La aplicación de conocimientos, habilidades, Holgura total. Cantidad total de tiempo que una actividad del crono-
herramientas y técnicas a actividades del proyecto para cumplir los grama puede retrasarse respecto a su fecha de inicio temprano sin retra-
sar la fecha de finalización del proyecto ni violar una restricción del cro-
requerimientos de este.
nograma. Se calcula utilizando la técnica del método de la ruta crítica y
Gerencia de recursos humanos del proyecto [área de conocimiento]. determinando la diferencia entre las fechas de fin temprano y las fechas de
Esta incluye los procesos que organizan y gestionan el equipo del fin tardío. Véase también holgura libre.
proyecto.
Identificación de interesados [proceso]. Identificación de todas las per-
Gerencia de riesgos del proyecto [área de conocimiento]. Esta incluye sonas u organizaciones que reciben el efecto del proyecto y documenta-
los procesos relacionados con llevar a cabo la planeación de la gestión, ción de la información relevante relativa a sus intereses, participación y
identificación, análisis de los riesgos y respuestas a estos, así como su sus efectos en el éxito del proyecto.
monitoreo y control en un proyecto. Identificación de riesgos [proceso]. Determinación de los riesgos que
Gerencia del alcance del proyecto [área de conocimiento]. Esta incluye pueden afectar al proyecto y documentar sus características.
los procesos requeridos para garantizar que el proyecto involucre todo Identificador de actividad. Una identificación numérica o de texto
(y únicamente) el trabajo requerido para completarlo con éxito. corta asignada a cada actividad del cronograma para diferenciar una
Gerencia del equipo del proyecto [proceso]. Monitorear el desempeño actividad de las demás en el proyecto. Típicamente es único en cualquier
de los miembros del equipo, proporcionar comentarios, resolver inci- diagrama de red de actividades del proyecto.
dentes y gerenciar cambios para optimizar la ejecución del proyecto. Incidente. Un punto o asunto cuestionado o respecto al cual existe una
Gerencia del tiempo del proyecto [área de conocimiento]. Esta incluye controversia, o que no se ha resuelto y se analiza, o respecto al cual exis-
los procesos requeridos para gestionar la conclusión a tiempo de un ten posiciones opuestas o desacuerdo.
proyecto. Índice de desempeño del costo (CPI). Medida de eficiencia en función
Gerencia del valor ganado (EVM). Metodología de gerencia que integra de los costos de un proyecto. Es la proporción entre el valor ganado
(EV) y costos reales (AC). CPI = EV dividido entre AC.
alcance, cronograma y recursos, y que mide el desempeño y el avance
del proyecto de forma objetiva. El desempeño se mide determinando Índice de desempeño del cronograma (SPI). Medida de eficiencia del
el costo presupuestado del trabajo realizado (es decir, el valor ganado) cronograma en un proyecto. Es la razón entre el valor ganado (EV) y
comparándolo con el costo real del trabajo realizado (es decir, el costo valor planeado (PV). SPI = EV dividido entre PV.
real). Inicio a inicio (SS).Relación lógica en la cual el inicio del trabajo de la
Gerente de proyectos (Project Management: PM). La persona nom- actividad siguiente del cronograma depende del inicio del trabajo de la
brada por la organización ejecutante para lograr los objetivos del actividad precedente del cronograma. Véase también relación lógica.
proyecto. Inicio a final (SF). Relación lógica en la cual la conclusión de la activi-
dad siguiente del cronograma depende del inicio de la actividad prece-
Gerente funcional. Alguien con autoridad de gerencia sobre una uni-
dente del cronograma. Véase también relación lógica.
dad de la organización dentro de una organización funcional. El gerente
de cualquier grupo que efectivamente realiza un producto o presta un Índice de desempeño del trabajo por completar (To-Complete-
servicio. A veces se le denomina gerente de línea. Performance-Index: TCPI).Proyección calculada del desempeño del
costo que se debe alcanzar en el trabajo restante, a fin de cumplir el obje-
Grado. Categoría o escala que se utiliza para distinguir elementos que tivo de gerencia especificado, como el presupuesto hasta la conclusión
tienen el mismo uso funcional (por ejemplo, “martillo”), pero que no (BAC) o la estimación de lo ejecutado. Es la relación entre el “trabajo
comparten los mismos requerimientos de calidad (por ejemplo, distin- restante” y los “fondos restantes”.
tos martillos pueden tener resistencia a distintos grados de fuerza).
Información de ejecución del trabajo [salida/entrada]. Información y
Grupo de procesos de la gerencia de proyectos. Modo lógico de agru- datos sobre la situación de las actividades del cronograma del proyecto,
par las entradas, herramientas y técnicas y salidas relacionados con la que se llevan a cabo para lograr el trabajo del proyecto, recopiladas
gerencia de proyectos. Los grupos de procesos de esta incluyen procesos como una parte de los procesos de dirigir y gerenciar la ejecución del
de iniciación, planeación, de ejecución, de monitoreo y control y proce- proyecto. La información incluye: situación de los entregables; situación
sos de cierre. Los grupos de procesos de la gerencia de proyectos no son de las solicitudes de cambio, acciones correctivas, acciones preventivas
fases del proyecto. y reparación de defectos; estimación hasta la conclusión pronosticada;
Glosario
521

porcentaje informado del trabajo físicamente terminado; valor de medi- general, se usa con un modificador (por ejemplo, línea base de costos,
das del desempeño técnico alcanzado; fechas de inicio y fin de las activi- línea base del cronograma, línea base de medición del desempeño, línea
dades del cronograma. base técnica).
Información histórica. Documentos y datos sobre proyectos anteriores, Línea base de desempeño del costo. Versión específica del presupuesto
que incluyen archivos de proyectos, registros, correspondencias, contra- con fases de tiempo utilizada para comparar el gasto real con el gasto
tos completados y proyectos cerrados. planeado, a fin de determinar si se requieren acciones correctivas para
Informes de desempeño [salida/entrada]. Documentos y presentacio- cumplir los objetivos del proyecto.
nes que ofrecen información organizada y resumida sobre el desempeño Línea base de medición del desempeño. Plan aprobado para el trabajo
del trabajo, de los parámetros y cálculos de la gerencia del valor ganado, del proyecto contra el que se compara la ejecución del proyecto y se
y el análisis del avance y situación del trabajo del proyecto. También se miden las desviaciones, con el fin de controlar la gestión. Por lo general,
conoce como informes de rendimiento o reportes de rendimiento. la medición del desempeño incluye los parámetros de alcance, del cro-
Ingeniería del valor. Enfoque utilizado para optimizar los costos del nograma y del costo de un proyecto, pero también puede incluir pará-
ciclo de vida del proyecto, ahorrar tiempo, aumentar las ganancias, metros técnicos y de calidad.
mejorar la calidad, ampliar la participación en el mercado, resolver inci- Línea base del alcance.Versión específica aprobada del enunciado del
dentes o utilizar recursos de forma más efectiva. alcance, de la estructura de desglose del trabajo (EDT) y del diccionario
Iniciación del proyecto. Presentación de un procedimiento que puede de esta.
dar por resultado la autorización de un nuevo proyecto. Línea base del cronograma.Versión específica del modelo de crono-
Inspección [técnica]. Examen o medición para verificar si una activi- grama utilizado para comparar los resultados actuales con el plan, a fin
dad, componente, producto, resultado o servicio cumple requerimien- de determinar si se necesitan acciones preventivas o correctivas para
tos específicos. cumplir los objetivos del proyecto.
Lista de actividades [salida/entrada]. Documento tabulado de las acti-
Intensificación [técnica]. Aceleración del cronograma del proyecto
vidades del cronograma que describe la actividad, el identificador de
implementada al tomar las medidas necesarias para disminuir la dura-
la actividad y el trabajo suficientemente detallado, de manera que los
ción del cronograma del proyecto total, después de analizar varias alter-
miembros del equipo entiendan el trabajo que debe realizarse.
nativas para determinar cómo obtener la mínima duración del crono-
grama, al menor costo adicional posible. Las acciones de intensificación Lluvia de ideas [técnica]. Recolección de datos y creatividad que
de un cronograma incluyen reducir la duración de la actividad del cro- puede usarse para identificar los riesgos, ideas o soluciones a incidentes
nograma y aumentar la asignación de recursos para cada una de estas. mediante el uso de un grupo de miembros del equipo o expertos en el
Véanse también ejecución rápida y compresión del cronograma. asunto.
Interesados. Personas y organizaciones como clientes, patrocinadores, Lógica de la red. Conjunto de dependencias de actividades del crono-
organización ejecutante y el público, involucrados activamente con el grama que conforma un diagrama de red del cronograma del proyecto.
proyecto, o cuyos intereses pueden afectarse de manera positiva o nega- Material. Conjunto de objetos utilizados por una organización en una
tiva por la ejecución o conclusión del proyecto. También pueden influir tarea, como equipos, aparatos, herramientas, maquinaria, útiles, mate-
en el proyecto y sus entregables. riales y suministros.
Invitación a ofrecer (IFB). En general, este término equivale a solici- Matriz de asignación de responsabilidades (RAM) [herramienta].
tud de propuesta. No obstante, en algunas áreas de aplicación, tiene una Estructura que relaciona la estructura de desglose de la organización con
acepción más concreta o más específica. la estructura de desglose del trabajo para ayudar a garantizar que cada
Juicio de expertos [técnica]. Juicio que se emite basado en la expe- componente del alcance del proyecto se asigne a una persona o equipo.
riencia en un área de aplicación, de conocimiento, disciplina, indus- Matriz de monitoreo de requerimientos. Gráfica que vincula reque-
tria, etc., según resulte apropiado para la actividad que se lleva a cabo. rimientos con su origen y los monitorea a lo largo del ciclo de vida del
Este juicio puede proporcionarse por cualquier grupo o persona con proyecto.
una educación, conocimiento, habilidad, experiencia o capacitación Matriz de probabilidad y efecto [herramienta]. Una manera de deter-
especializados. minar si un riesgo se considera bajo, moderado o alto, mediante la com-
Lecciones aprendidas [salida/entrada]. Lo que se aprende en la eje- binación de las dos dimensiones de un riesgo: su probabilidad de ocu-
cución del proyecto. Las lecciones aprendidas pueden identificarse en rrencia y su efecto sobre los objetivos.
cualquier momento. También se considera un registro del proyecto, que Medición de desempeño técnico [técnica]. Medición del desempeño
se debe incluir en la base de conocimientos de lecciones aprendidas. que compara los logros técnicos durante la ejecución del proyecto con
Límites de control. Área compuesta por tres desviaciones estándar a el cronograma de resultados técnicos planificados del plan de la geren-
cada lado de la línea central, o promedio, de una distribución normal cia del proyecto. Puede utilizar parámetros técnicos claves del producto
trazada en un diagrama de control que refleja la variación prevista de producido por el proyecto como métrica de calidad. Los valores métri-
datos. Véase también límites de las especificaciones. cos alcanzados son parte de la información sobre el desempeño del
Límites de las especificaciones. El área, a cada lado de la línea central, o trabajo.
promedio, de datos trazados en un diagrama de control que cumple los Método de diagramación por precedencia (PDM) [técnica].
requerimientos del cliente para un producto o servicio. Esta área puede Diagramación de redes del cronograma en la que las actividades de este
ser mayor o menor que el área definida por los límites de control. Véase se representan con casilleros (o nodos). Las actividades del cronograma
también límites de control. se vinculan gráficamente mediante una o más relaciones lógicas para
Línea base. Un plan aprobado en el proyecto con los cambios aprobados. mostrar la secuencia en que deben realizarse las actividades.
Esta se compara con el desempeño real para determinar si el desempeño Método de la cadena crítica [técnica]. Análisis de la red del cronograma
está dentro de los umbrales aceptables. Generalmente se hace referen- que permite modificar el cronograma del proyecto para adaptarlo a los
cia a la línea base actual pero puede referirse a otra línea de base. Por lo recursos limitados.
522 Glosario

Metodología. Sistema de prácticas, técnicas, procedimientos y normas Organización ejecutante. La empresa cuyo personal participa más
utilizado por quienes trabajan en una disciplina. directamente en el trabajo del proyecto.
Metodología de la ruta crítica (CPM) [técnica]. Un análisis de la red Organización funcional. Una organización jerárquica en la cual cada
del cronograma utilizado para determinar el nivel de flexibilidad de los empleado tiene definido claramente un superior, y el personal se agrupa
cronogramas (en holguras) sobre varias rutas lógicas de la red del cro- por áreas de especialización dirigidas por una persona con experiencia
nograma del proyecto y para determinar la duración total del proyecto. en esa área.
Las fechas de comienzo y final más tempranos se calculan mediante un Organización matricial. Estructura organizacional en la que el gerente
recorrido hacia adelante, con base en una fecha de inicio especificada. del proyecto comparte con los gerentes funcionales la responsabilidad
Las fechas de inicio y fin se calculan mediante un recorrido hacia atrás, de asignar prioridades y de dirigir el trabajo de las personas asignadas
a partir de una fecha de finalización especificada, que generalmente es la al proyecto.
fecha de fin temprano del proyecto determinada durante el cálculo del
Organización proyectizada. Toda estructura organizativa en la que el
recorrido hacia adelante. Véase también ruta crítica. gerente del proyecto tiene plena autoridad para asignar prioridades y
Mitigación del riesgo [técnica]. Planeación de la respuesta a los riesgos recursos y dirigir el trabajo de las personas asignadas al proyecto.
asociada con amenazas que pretende reducir la probabilidad de ocu- Paquete de planeación. Componente de la estructura de desglose del
rrencia o el efecto de un riesgo por debajo de un umbral aceptable. trabajo bajo la cuenta control con contenido de trabajo conocido, pero
Modelo de cronograma [herramienta]. Modelo usado junto con méto- sin actividades del cronograma detalladas. Véase también cuenta control.
dos manuales o software en la gerencia de proyectos para realizar un Paquete de trabajo. Producto entregable o componente del trabajo del
análisis de la red del cronograma, a fin de generar el cronograma del proyecto en el nivel más bajo de cada sector de la estructura de desglose
proyecto y usarlo al gerenciar la ejecución de un proyecto. del trabajo. Véase también cuenta control.
Monitorear. Recolectar datos de desempeño del proyecto respecto a un Patrocinador. Persona o grupo que ofrece recursos financieros, mone-
plan, producir medidas de desempeño e informar y difundir la informa- tarios o en especie, para el proyecto.
ción acerca del desempeño.
Plan de gerencia de adquisiciones [salida/entrada]. Documento que
Monitoreo y control de los riesgos [proceso]. Implementar los planes describe cómo se gestionarán los procesos de adquisición desde el desa-
de respuesta a los riesgos, monitorear los riesgos identificados y los ries- rrollo de adquisición hasta el cierre del contrato.
gos residuales, identificar nuevos riesgos y evaluar los riesgos a lo largo
Plan de gerencia de calidad [salida/entrada]. Este plan describe cómo el
del proyecto.
equipo de gerencia del proyecto implementará la política de calidad de
Monitoreo y control del trabajo del proyecto [proceso]. Monitorear, la organización ejecutante. El plan de gerencia de calidad es un compo-
analizar y regular el avance de la ejecución, a fin de cumplir los objetivos nente o un plan subsidiario del plan para la gerencia del proyecto.
de desempeño definidos en el plan de la gerencia del proyecto. Plan de gerencia de comunicaciones [salida/entrada]. Documento que
Nivelación. Véase nivelación de recursos. describe las necesidades y expectativas de comunicación para el proyecto;
Nivelación de recursos [técnica]. Cualquier forma de análisis de la red cómo y en qué formato se comunicará la información; dónde y cuándo
del cronograma en que las decisiones de planeación (fechas de inicio y se realizará cada comunicación; y quién es el responsable de efectuar cada
de fin) se basan en aspectos relativos a las restricciones de los recursos tipo de comunicación. El plan de gerencia de las comunicaciones es un
(por ejemplo, disponibilidad de recursos limitados o cambios de difícil plan subsidiario del plan de gerencia del proyecto o una parte de este.
gerencia de recursos). Plan de gerencia de costos [salida/entrada]. Documento que fija el for-
Nodo. Uno de los puntos que definen la red de un cronograma; un mato y establece las actividades y los criterios necesarios para planear,
punto de intersección unido a algunas o todas las demás líneas de la estructurar y controlar los costos del proyecto. El plan de gerencia de
dependencia. costos es un plan subsidiario del plan para la gerencia del proyecto o
una parte de este.
Objetivo. Algo hacia lo cual se dirige el trabajo, una posición estratégica
que se quiere lograr o un propósito que se desea alcanzar, un resultado Plan de gerencia de proyectos [salida/entrada]. Documento formal-
mente aprobado que define cómo se ejecuta, monitorea y controla un
por obtener, un producto por producir o un servicio por prestar.
proyecto. Puede resumirse o detallarse y componerse de uno o más pla-
Oficina de gerencia de proyectos (Project Management Office: PMO). nes de gerencia subsidiarios y otros documentos de planeación.
Un cuerpo o entidad de la organización que tiene varias responsabili-
Plan de gerencia de riesgos [salida/entrada). Documento que describe
dades asignadas con relación a la gerencia centralizada y coordinada de
cómo se estructurará y realizará en el proyecto la gerencia de riesgos. Es
aquellos proyectos que se encuentran bajo su jurisdicción. Las respon-
un plan subsidiario del plan de la gerencia del proyecto o una parte de
sabilidades de una oficina de gerencia de proyectos pueden variar, desde
este. La información del plan de gerencia de riesgos varía según el área
realizar funciones de apoyo para la gerencia de proyectos hasta ser real-
de aplicación y el tamaño del proyecto. El plan de gerencia de riesgos es
mente los responsables de la gerencia de un proyecto.
diferente del registro de riesgos, ya que este contiene la lista de riesgos del
Opinión del cliente. Técnica de planeación utilizada para brindar pro- proyecto, los resultados del análisis de riesgos y las respuestas a los riesgos.
ductos, servicios y resultados que reflejan fielmente los requerimientos
Plan de gerencia del alcance [salida/entrada]. Documento que des-
del cliente, al traducir estos en los requerimientos técnicos adecuados
cribe cómo se definirá, desarrollará y verificará el alcance del proyecto y
para cada fase de desarrollo del producto del proyecto.
cómo se creará y definirá la estructura de desglose del trabajo; asimismo,
Oportunidad. Condición o situación favorable para el proyecto, con- orienta sobre cómo se gestionará y controlará el alcance del proyecto
junto de circunstancias positivas o de eventos positivos, un riesgo que por el equipo de gerencia del proyecto. Es un plan subsidiario del plan
tendrá un efecto positivo sobre los objetivos del proyecto, o una posibi- de la gerencia del proyecto o una parte de este.
lidad de realizar cambios positivos. Compárese con amenaza. Plan de gerencia del cronograma [salida/entrada]. Documento que
Organigrama del proyecto [salida/entrada]. Documento que repre- establece los criterios y las actividades para desarrollar y controlar el cro-
senta gráficamente a los miembros del equipo del proyecto y sus interre- nograma del proyecto. Es un plan subsidiario del plan de la gerencia del
laciones en un proyecto específico. proyecto o una parte de este.
Glosario
523

Plan de gerencia del personal. Documento que describe cuándo y cómo Procesos de monitoreo y control [grupo de procesos]. Aquellos reque-
se cumplirán los requerimientos de recursos humanos. Es un plan subsi- ridos para monitorear, analizar y regular el progreso y el desempeño del
diario del plan de recursos humanos o una parte de este. proyecto, para identificar áreas en las que se requieran cambios al plan y
Plan de recursos humanos. Documento que describe cómo los papeles así iniciar los cambios correspondientes.
y responsabilidades, las relaciones de comunicación y la gerencia de per- Procesos de planeación [grupo de procesos]. Aquellos realizados para
sonal se tratarán y estructurarán para el proyecto. Es un plan subsidiario establecer el alcance total del esfuerzo, definir y refinar los objetivos y
del proyecto o una parte de este. desarrollar el curso de acción requerido para alcanzar esos objetivos.
Planeación de la calidad [proceso]. Identificación de los requerimien- Producto. Un artículo producido cuantificable y que puede ser un ele-
tos de calidad y/o normas para el proyecto y el producto, así como la mento terminado o un componente. Otras palabras para hacer referen-
documentación de la manera en que el proyecto demostrará el cumpli- cia a los productos son materiales y bienes. Compárese con resultado.
miento de aquellos. Véase también entregable.
Planeación de la gerencia de riesgos [proceso]. Definición de la manera Programa. Grupo de proyectos relacionados cuya gerencia se realiza
cómo se realizarán las actividades de la gerencia de riesgos en un proyecto. de manera coordinada para obtener beneficios y control, que no se
Planeación de la respuesta a los riesgos [proceso]. Desarrollo de opcio- obtendrían si se gerenciaran de forma individual. Los programas pue-
nes y medidas para mejorar las oportunidades y reducción de las ame- den incluir elementos de trabajo relacionados fuera del alcance de los
nazas a los objetivos del proyecto. proyectos diferenciados del programa.
Planeación de las adquisiciones [proceso]. Documentación de las Pronóstico. Estimación o predicción de condiciones y eventos futuros
decisiones de compra para el proyecto, en la cual se especifica el enfoque para el proyecto, basadas en la información y en el conocimiento dispo-
y se identifican los potenciales proveedores. nible en el momento de efectuar la proyección. La información se basa
en el desempeño pasado del proyecto y en el desempeño previsto para
Planeación de las comunicaciones [proceso]. Determinación de las
el futuro, e incluye información que podría ejercer un efecto sobre el
necesidades de información de los interesados del proyecto y de un
proyecto en el futuro, tal como estimación de lo ejecutado y estimación
enfoque para las comunicaciones.
hasta la conclusión.
Planeación gradual [técnica]. Elaboración gradual de planeación en la
Provisiones para contingencias. Véase reserva.
que el trabajo que se debe realizar a corto plazo se planifica en detalle
inferior de la estructura de desglose del trabajo, mientras que el trabajo Proyecto. Esfuerzo temporal que se lleva a cabo para crear un pro-
a largo plazo se planifica a un nivel relativamente alto de la estructura de ducto, servicio o resultado único.
desglose del trabajo; pero la planeación detallada del trabajo que se debe Reclamo. Solicitud, demanda o declaración de derechos realizada por
realizar dentro de uno o dos periodos en el futuro cercano se realiza a un vendedor contra un comprador, o viceversa, para su consideración,
medida que el trabajo se completa durante el periodo actual. compensación o pago en virtud de los términos de un contrato legal-
Plantilla.Documento parcial, en un formato predefinido, que pro- mente vinculante, por ejemplo, un cambio objeto de disputa.
porciona una estructura definida para recopilar, organizar y presentar Recopilación de requerimientos [proceso]. Definición y documenta-
información y datos. ción de las necesidades de los interesados para cumplir los objetivos
Porcentaje completado. Estimación, expresada como un porcentaje, de del proyecto.
la cantidad de trabajo que se ha ejecutado de una actividad o un compo- Recorrido hacia adelante. Cálculo de fechas de inicio temprano y fechas
nente de la estructura de desglose del trabajo. de fin temprano para las porciones no completadas de todas las activi-
Portafolio. Conjunto de proyectos o programas y otros trabajos que se dades de la red. Véase también análisis de la red del cronograma y reco-
agrupan para facilitar la gerencia eficiente de ese trabajo, a fin de cum- rrido hacia atrás.
plir los objetivos estratégicos de negocio. Los proyectos o programas del Recorrido hacia atrás. Cálculo de las fechas de fin tardío y fechas de
portafolio no son necesariamente interdependientes ni están directa- inicio tardío para las partes incompletas de todas las actividades del cro-
mente relacionados. nograma. Se determina yendo hacia atrás en la lógica de la red del cro-
Práctica. Tipo específico de actividad profesional o de gerencia que nograma a partir de la fecha de conclusión del proyecto. Véase también
contribuye a ejecutar un proceso y que utiliza una o más técnicas y análisis de la red del cronograma.
herramientas. Recurso. Recursos humanos especializados (disciplinas específicas, ya
Presupuesto. El estimado aprobado para el proyecto o cualquier com- sea en forma individual, o en equipos o grupos), equipos, servicios,
ponente de la estructura de desglose del trabajo o cualquier actividad suministros, materias primas, materiales, presupuestos o fondos.
del cronograma. Véase también estimación. Red. Véase diagrama de red de cronograma del proyecto.
Presupuesto hasta la conclusión (BAC). La suma de todos los presu- Registro. Documento que se utiliza para registrar y describir o indi-
puestos establecidos para el trabajo por desarrollar en un proyecto o un car los elementos seleccionados e identificados durante la ejecución de
componente de la estructura de desglose del trabajo o una actividad del un proceso o actividad. Habitualmente se utiliza con un modificador,
cronograma. El valor total planeado para el proyecto. como incidentes, control de calidad, acciones o defectos.
Procesos de cierre [grupo de procesos]. Aquellos realizados para fina- Registro de riesgos [salida/entrada]. Documento que contiene los
lizar todas las actividades de todos los grupos de procesos de la geren- resultados del análisis cualitativo de riesgos, del análisis cuantitativo de
cia de proyectos para completar formalmente el proyecto o una fase. riesgos y de la planeación de la respuesta a los riesgos. El registro de
También puede referirse a cerrar un proyecto cancelado. riesgos detalla todos los riesgos identificados, incluidos la descripción,
Procesos de ejecución [grupo de procesos]. Aquellos realizados para categoría, causa, probabilidad de ocurrencia, los efectos en los objetivos,
terminar el trabajo definido en el plan para la gerencia del proyecto, a respuestas, propuestas, responsables y condición actual.
fin de cumplir los objetivos del proyecto. Regulación. Requerimientos impuestos por una entidad gubernamen-
Procesos de iniciación [grupo de procesos]. Aquellos realizados para tal, para establecer las características del producto, del proceso o del
definir un nuevo proyecto o nueva fase de un proyecto existente, al servicio (incluidas las disposiciones administrativas aplicables) y son de
obtener la autorización para iniciar el proyecto o fase. obligatorio cumplimiento.
524 Glosario

Relación de precedencia. Expresión usada en el método de diagramación Ruta de la red. Cualquier serie continua de actividades del cronograma
por precedencia para indicar una relación lógica. Sin embargo, en el uso conectadas con relaciones lógicas en un diagrama de red de cronograma
corriente, la relación de precedencia, la relación lógica y la dependencia del proyecto. También se conoce como ruta de la red.
son conceptos intercambiables, independientemente del método de dia- Salida [de proceso]. Producto, resultado o servicio generado por un
gramación. Véase también relación lógica. proceso. Puede ser un dato inicial para un proceso siguiente.
Relación lógica. Dependencia entre dos actividades del cronograma del Secuenciación de actividades [proceso].Identificación y documenta-
proyecto, o entre una actividad del cronograma del proyecto y un hito ción de las relaciones entre las actividades del proyecto.
del proyecto. Los cuatro tipos posibles de relaciones lógicas son: final a
Simulación. Modelo de proyecto que traduce las incertidumbres espe-
inicio; final a final; inicio a inicio; inicio a final. Véase también relación
cificadas a un nivel detallado de su efecto posible en los objetivos expre-
de precedencia.
sados en el proyecto total. Las simulaciones de proyectos usan modelos
Reporte del desempeño [proceso]. Recopilación y distribución de informáticos y estimaciones de riesgo que, generalmente, se expresan
información sobre el desempeño, incluidos informes de estado, medi- como una distribución de probabilidad de costos o duraciones posibles
ciones del avance y proyecciones. a un nivel de trabajo detallado y, normalmente, se realizan usando el
Requerimiento. Condición o capacidad que un sistema, producto, ser- análisis Monte Carlo.
vicio, resultado o componente debe satisfacer o poseer para cumplir Simulación Monte Carlo. Procedimiento que genera cientos o miles de
un contrato, norma, especificación u otros documentos formalmente resultados de desempeños posibles sobre la base de distribuciones de
impuestos. Los requerimientos incluyen las necesidades, los deseos y probabilidades de costo y cronograma de tareas individuales. Los resul-
expectativas cuantificadas y documentadas del patrocinador, del cliente tados se usan luego para generar una distribución de probabilidad para
y de otros interesados. el proyecto en su totalidad.
Reserva. Provisión de fondos en el plan de la gerencia del proyecto para Sistema de autorización de trabajo [herramienta]. Subsistema del sis-
mitigar riesgos del cronograma y/o costos. Se utiliza a menudo con un tema de gerencia de proyectos general. Conjunto de procedimientos
modificador (por ejemplo, reserva de gestión, reserva para contingen- formalmente documentados que define cómo se autorizará el proyecto
cias), con el objetivo de proporcionar más detalles sobre qué tipos de de trabajo (comprometido) para garantizar que la organización identi-
riesgos se pretenden mitigar. ficada realice el trabajo en el tiempo asignado y en la secuencia correcta.
Reserva de contingencia [salida/entrada]. La cantidad de fondos, pre- Incluye los pasos, documentos, sistema de seguimiento y niveles de
supuesto o tiempo, que supere la estimación, necesaria para reducir el aprobación necesarios para emitir las autorizaciones de trabajo.
riesgo de sobrecostos de los objetivos del proyecto a un nivel aceptable Sistema de control de cambios [herramienta]. Un conjunto de proce-
para la organización. dimientos formalmente documentados que definen cómo se controla-
Restricción [entrada]. El estado, la calidad o la sensación de ser restringido rán, cambiarán y aprobarán los entregables, y la documentación del pro-
a un curso de acción o inacción determinado. Una restricción o limitación yecto. En la mayoría de las áreas de aplicación, el sistema de control de
aplicable, ya sea interna o externa a un proyecto, que afectará el desempeño cambios es un subconjunto del sistema de gerencia de la configuración.
del proyecto o de un proceso. Por ejemplo, una restricción del cronograma Sistema de gerencia de la configuración [herramienta]. Subsistema del
consiste en una limitación o condicionamiento aplicado sobre el crono- sistema de gerencia de proyectos general. Conjunto de procedimientos
grama del proyecto que afecta el momento en que una actividad puede formalmente documentados que se utilizan para implementar la geren-
programarse y que suele presentarse como fecha fija impuesta. cia y supervisión técnica y administrativa, identificar y documentar las
Resultado. Una salida de la ejecución de procesos y actividades de características funcionales y físicas de un producto, resultado, servicio o
gerencia de proyectos. Los resultados incluyen consecuencias (por componente; controlar cualquier cambio a esas características; registrar
ejemplo, sistemas integrados, procesos revisados, organización reestruc- e informar cada cambio y su estado de implantación; y brindar apoyo a
turada, pruebas, personal capacitado, etc.) y documentos (por ejemplo, la auditoría de productos, resultados o componentes para verificar que
políticas, planes, estudios, procedimientos, especificaciones, informes, cumplen los requerimientos. Incluye la documentación, los sistemas de
etc.). Compárese con producto. Véase también entregable. rastreo y los niveles necesarios de aprobación, definidos para autorizar
y controlar los cambios.
Retrabajo. Acción realizada para que un componente defectuoso o que
no responda a los requerimientos o especificaciones los cumpla. Sistema de gerencia de proyectos [herramienta]. Suma de los procesos,
herramientas, técnicas, metodologías, recursos y procedimientos nece-
Retraso [técnica]. Modificación de una relación lógica que causa un sarios para gerenciar un proyecto.
retraso en la actividad siguiente. Por ejemplo, en una dependencia de
final a inicio con un retraso de diez días, la actividad siguiente solo Sistema de información de la gerencia de proyectos (PMIS) [herra-
puede comenzar diez días después del final de la actividad precedente. mienta]. Un sistema de información compuesto por herramientas y
Véase también adelanto. técnicas utilizado para recopilar, integrar y difundir los resultados de
los procesos de gerencia de proyectos. Se usa para respaldar todos los
Riesgo. Un evento o condición incierta que, si se produce, tiene un aspectos del proyecto desde el comienzo hasta el cierre, y puede incluir
efecto positivo o negativo en los objetivos de un proyecto. sistemas manuales y automatizados.
Riesgo residual. Riesgo que permanece después de haber implemen- Solicitud de cambio. Solicitud para ampliar o reducir el alcance de un
tado las respuestas a los riesgos. proyecto, modificar políticas, procesos, planes o procedimientos, modi-
Riesgo secundario. El que surge como resultado directo de la implanta- ficar costos o presupuestos, o revisar cronogramas.
ción de una respuesta a los riesgos. Solicitud de cambio [salida/entrada]. Solicitud documentada formal-
Rol o papel. Función definida que debe realizar un miembro del equipo mente que se presenta para aprobar el proceso de control integrado de
del proyecto, como evaluar, archivar, inspeccionar o codificar. cambios.
Ruta crítica. Generalmente, pero no siempre, secuencia de actividades Solicitud de cotización (RFQ). Documento de adquisición que se uti-
del cronograma que determina la duración del proyecto. Es el camino liza para solicitar precios de potenciales proveedores de productos o ser-
más largo para el proyecto. Véase también metodología de la ruta crítica. vicios comunes o estándares. A veces se utiliza en lugar de la solicitud de
Glosario
525

propuesta y en algunas áreas de aplicación, puede tener un significado Transferencia del riesgo [técnica]. Planeación de la respuesta a los ries-
más limitado o específico. gos que traslada el efecto de una amenaza a un tercero, junto a la res-
Solicitud de información (RFI). Documento de adquisición por medio ponsabilidad de la respuesta.
del cual el comprador solicita al posible vendedor que proporcione Ubicación cercana [técnica]. Estrategia de localización de la organiza-
determinada información relacionada con un producto, servicio o capa- ción, en virtud de la cual se acercan físicamente los miembros del equipo
cidad del vendedor. del proyecto para mejorar la comunicación, las relaciones laborales y la
productividad.
Solicitud de propuesta (RFP). Documento de adquisición que se uti-
liza para solicitar propuestas de posibles proveedores de productos o Umbral. Valor de costo, tiempo, calidad, técnico o de recurso utilizado
como parámetro, y que puede incluirse en las especificaciones del pro-
servicios. En algunas áreas de aplicación, puede tener un significado más
ducto. Superar el umbral disparará alguna medida, como generar un
limitado o específico.
informe por excepción.
Solución temporal [técnica]. Respuesta a un riesgo negativo que se ha pro-
Unidad de calendario. Unidad de tiempo más pequeña utilizada en la
ducido. Se distingue del plan de contingencias en que en aquella no hay
planeación de un proyecto. Por lo general, las unidades calendario se
una solución alternativa planeada, de forma anticipada, al evento de riesgo. expresan en horas, días o semanas, pero también pueden expresarse en
Subfase. Subdivisión de una fase. trimestres, meses, turnos y hasta minutos.
Subproyecto.Porción más pequeña del proyecto general creada al sub- Validación. Asegurarse de que un producto, servicio o sistema cum-
dividir un proyecto en componentes o partes más fáciles de gerenciar. ple los requerimientos del cliente y de otros interesados identificados. A
Subred. Subdivisión (fragmento) de un diagrama de red del crono- menudo implica corroborar la aceptación y conveniencia para clientes
externos. Compárese con verificación.
grama del proyecto que, por lo general, representa un subproyecto o
un paquete de trabajo. A menudo, se utiliza para ilustrar o estudiar una Valor ganado (EV). El valor del trabajo completado expresado en tér-
condición del cronograma posible o propuesta, por ejemplo, cambios minos del presupuesto aprobado asignado a ese trabajo para una acti-
en la lógica preferencial del cronograma o en el alcance del proyecto. vidad del cronograma o un componente de la estructura de desglose
del trabajo. También se conoce como costo presupuestado del trabajo
Supuestos. Factores que por efecto de planeación se consideran verda- realizado (BCWP).
deros, reales y ciertos, sin prueba o demostración.
Valor monetario esperado (EMV) [análisis]. Técnica estadística que
Técnica. Procedimiento sistemático definido y utilizado por una persona calcula el resultado promedio cuando el futuro incluye escenarios que
para realizar una actividad a fin de producir un producto o un resultado, pueden ocurrir o no. Esta técnica se usa comúnmente dentro del análisis
o prestar un servicio, y que puede emplear una o más herramientas. de árbol de decisiones.
Técnica Delphi [técnica]. Acopio de información que se utiliza como Valor planeado (PV). El presupuesto autorizado asignado al trabajo
método para lograr el consenso de expertos acerca de un tema. Los planeado que debe realizarse respecto a una actividad del cronograma o
expertos en el tema participan en esta técnica de forma anónima. Un componente de la estructura de desglose del trabajo.
facilitador utiliza un cuestionario para solicitar ideas acerca de los pun- Varianza. Desviación, cambio o divergencia cuantificable de una refe-
tos importantes del proyecto, relacionados con ese tema. Las respues- rencia conocida o valor previsto.
tas se resumen y luego se envían nuevamente a los expertos para sus Varianza del costo (CV). Medida de desempeño en función de los cos-
comentarios adicionales. Mediante este proceso, en pocas rondas se tos de un proyecto. Es la diferencia entre el valor ganado (EV) y el costo
logra el consenso. La técnica Delphi reduce sesgos en los datos y evita real (AC). CV = EV menos AC.
que las personas ejerzan influencias impropias en el resultado.
Varianza en el cronograma (SV). Medida de desempeño del crono-
Técnica de revisión y evaluación de programas (PERT). Técnica de grama en un proyecto. Es una diferencia entre el valor ganado (EV) y el
estimación que aplica un promedio ponderado de estimaciones opti- valor planeado (PV). SV = EV menos PV.
mistas, pesimistas y más probables, cuando las estimaciones para las Vendedor. Distribuidor o proveedor de productos, servicios o resulta-
actividades individuales generan incertidumbres. dos de una organización. También se conoce como proveedor.
Técnica del valor ganado (earned value technique: EVT) [técnica). Esta Verificación. Evaluación en torno a un producto, servicio o sistema,
se utiliza para medir el desempeño del trabajo en un componente de la si cumple o no con determinada regulación, requisito, especifica-
estructura de desglose del trabajo, una cuenta de control o un proyecto. ción o condición impuesta. A menudo se trata de un proceso interno.
También se conoce como técnica del valor del trabajo realizado. Compárese con validación.
Tolerancia al riesgo. El grado, cantidad o volumen de riesgo que podrá Verificación del alcance [proceso]. Formalización de la aceptación de
resistir una organización o individuo. los entregables del proyecto que se hayan completado.
ÍNDICE DE COMPAÑÍAS
A DuPont, Inc.,302 I Nike, 138
Accident Fund Insurance Co. of E IBM, 60, 68-69, 343 Nissan, 400-401, 429n1,477
America, 58 Eli Lilly Corporation, 384 Infrastructure Management Group, Nokia, 101
Adelphia Cable Company, 62 EMC Corporation, 44, 102 176 Northrop Grumman, 35-36, 448-449
Advanced Network & Services, 205 Energy Solutions, Inc., 487 Institute for OneWorld Health, 74n33 Nova Western, Inc., 110-111
Airbus, 67-68, 231, 237 Enron, 62 Institute for Operations Research and
Air France, 248 Environmental Protection Agency the Management Sciences, 201 O
Air India, 332 (EPA), 400-401n1 Institution of Chemical Engineers, Occupational Safety and Health
All Nippon Airlines, 332 Ericksson, 4, 101 294n18 Administration (OSHA), 73
Amazon, 8 Ernest & Young, 134 Intel, 6 Optimal Logistics, 396
AMEC Corporation, 63 Escambia High (High Escambia), 148 International Function Point Oracle, 4, 40
American Marketing Association, ESI International, 21-22n32 Users Group (Standish Group O.R. Tambo International Airport, 296
185n25 European Association for Project International), 271n14, 294n14 Oxford University (Universidad de
American Red Cross, 227 Management (Asociación Iraqi Army, 419 Oxford,), 275
Apple Computer Corporation, 4, 6, 8, Europea para la Gestión de
12, 60, 201, 378 Proyectos), 243
Aston Martin, 116 J P
European Space Agency (ESA), 237 Jaguar, 116
Automobile Manufacturing Palo Alto Research Center (PARC),
Exelon Corporation, 487 Johnson & Rogers Software
Association, 180 61, 68-69
Exxon Chemical, 76 Engineering, 219 Parsons Brinckerhoff, 290
John Wiley & Sons, Inc., 38-39, 46 Pentagon (Pentágono), 9, 146-148
B F Pfizer, 100 n23, 101
Barnes and Noble, 8 Bayer Fallujah Police( policia de Faluya), 418 PING, 138
Corporation, 100 Federal Bureau of Investigation (FBI), K
Keflavik Paper Company, 109-110 Pitney-Bowes Credit Corporation
Bechtel Corporation, 135, 215 259-260, 294n1 (PBCC) (Pitney Bowes-Credit
Federal Emergency Management Kimble College, 459
Ben and Jerry’s Ice Cream, 62 Corporation) , 60
Agency (FEMA), 252 King Fahd University of Petroleum &
Blanque Cheque Construction (BCC), Pratt & Whitney Jet Engines, 67, 98
Federal Geographic Data Committee, Minerals, 229
359–360 Project Management Association, 100-
151 King’s Fund (king found), 259
Boeing Corporation, 4, 19, 43, 67, 112, 101, 112n7, 113n21, 113n23,
Federal Highway Administration, 290 King’s Park Soccer Stadium, 297
169, 237, 248, 265, 331-333,333n1 Project Management Institute (PMI),
Booz-Allen Hamilton, 301 Federal Reserve(Reserva federal), 274 5, 7, 13, 17, 20, 25-26, 31-32,
BP, 187-189 Federal Transit Administration (FTA), L 32n10, 32n15, 32n23, 32n30, 56-
British Computer Society, 245 471 Land Rover, 116 57, 74, 74n9, 74n10, 85-86, 129,
British Overseas Airways Corporation Fédération Internationale de Football LaSalles, 178 144n31, 191, 198, 223n6, 223n18,
(BOAC), 248 Association (FIFA), 297 Layne Christensen Company, 2 270, 328n2, 329n8, 372-373, 377,
Building Contractors of Toledo (BCT), Fermi Laboratory(Laboratorio Fermi), Lilly Research Labs, 384 379, 398n9, 398n19, 469n1
220-221 460 Lockheed Corporation, 54 Public Accounts Committee of the
Financial Services Group (FSG), 131 (Lockheed), 294n11,(Lockheed House of Commons, 259 Public
Fluor-Daniel Corporation, 19, 37, Corporation), 301 Works Administration, 250
C 61, 70 Lockheed Martin, 36, 260 Pureswing Golf, Inc., 138
California High-Speed Rail Authority Ford Motor Company, 44, 116, Logan Airport, 288
(CHSRA), 175–176, 184, 184n24 177-180 Lucent Technologies, 370 R
Calloway, 138 FRAM, 228
Carnegie Mellon University, 22, 22n32 Freefield Memorial Hospital, 150 Ramstein Products, 396
Center for Business Practices, 22, Freefield Public Library (Biblioteca M Rauma Corporation, 9, 233
22n32 publica Freefield), 150 Macintosh, 8, 60 Rolls-Royce plc, 61, 67-68, 332,
Chartered Institute of Building, 329n9 Fujitsu Services (formerly ICL), 495 Martin Marietta, 461 473–474
Chevrolet, 6, 400-401 Maryland State Department of Health, Royal Bank of Canada, 76
Chrysler, 48, 168, 178-180 G 150 Rubbermaid Corporation, 37, 77, 102
Ciampino Airport, ( 235, 249 Galorath, Inc., 290 Massachusetts Turnpike Authority,
Civil Aviation Board (CAB), 249 General Dynamics Corporation 288-289 S
Cleveland, 138 (General Dynamics Massivesoft Corporation, 108 Samsung, 341
Columbus Instruments, Inc. (CIC), CorporaITon) 146,148 Mbombela Stadium, 297 Sandton, 296
217-218 General Electric Company, 4, 12, 60- McKinsey Group, 10 Sanofil-Aventis, 64,64n33, 74n33
Commonwealth Edison, 487 62, 67, 97–98, 116, 130, 486 MegaTech, Inc., 28, 285 SAP Corporation, 80-81, 87, 490–491
Computer Sciences Corporation General Motors178-180, 429, 429n1 META Group, 8 Saudi Aramco Oil Company, 229-230
(CSC), 131-132 George Washington University, 74n25 Microsoft, 12, 131, 271, 294n16, Science applications International
Construx Software, 271 Geotec Boyles Brothers, 2, 3 302,336, 319, 403, 405, Corp. (SaIC), 259
Crown Corporation, 108 Gillette, 102 (MS project) 476, 481 Siemens, 76
Goodrich Corporation, 231, 485 Military College of South Software Engineering Institute (SEI), 22
Governmental Affairs Committee Carolina, 418 Sony, 12
D
(Comité del Senado de Mobil Chemical, 76 South African Airways, 249
Dallas Cowboys (vaqueros de Dallas),
Seguridad Nacional y Asuntos Modern Continental, 290 Special Inspector General for Iraq
148
Data General Corporation, 48, 102 Gubernamentales, 175 Reconstruction (SIGIR), 9
Defense Logistics Agency, 469n2 Grace Hospital, 127 N Standish Group International, 8, 32n,
Havilland Aircraft Company, Green Point Stadium (estadio Green National Aeronautics and Space 32n18, 271, 294n14, 490
247-249, 252 Point), 297 Administration (NASA), 3, 134, Steel Fabrik, Inc. (SFI), 220-221
Denver International Airport, 274 258-259, 294n1 Swiss Federal Institute of Technology,
Development Center of Excellence, H National Audit Office, 259, 496 369
384 Hamelin Hospital, 29 National Research Council (National Sylvania, 78
DHL Express, 99 Hoechst Marion Roussel, 76, 83 Researche Council), 461
Disney, 7, 28, 30-31, 33,33n33 Holcim Foundation for Sustainable National Safety Council, 180 T
Dotcom.com, 177 Construction, 115 New England Patriots (Patriots de Taxpayers for Common Sense, 148,
Dulhasti Power Plant, 287 Honeywell (honey), 370 New England), 288 (Taypayer) 289
527
528 Índice de compañías

Taylor Made, 138 Universities Research Association, 461 U.S. Department of Homeland W
Te Apiti, 431-432, 469n1 University of Calgary, 223n18 Security (DHS), 173-174 Walt Disney World Resort, 30
Texas Instruments, 62, 370 3M, 12, 37, 76 University of Manchester, 474 U.S. Department of Justice, 260 Waste Management, 490,
Titleist, 138 University of Pittsburgh, 14 U.S. Dept. of Civil Engineering, 500n20
Toshiba, 103 U.S. Air Force, 417n2 439 223n18 Westinghouse Electric Company,
Toyota, 401, 477 U.S. Army, 35-36,132, 240, 252, 339- U.S. House of Representatives, 14–15
TRW Corporation, 485 340, 417n2, 478 144n29 Weyerhaeuser, 76
U.S. Congress, 148,259, 460 U.S. Marines, 60, 146-148, 169, 418 Widgets ’R Us (WRU), 70
U U.S. Customs and Border Protection, U.S. Navy, 3, 146-148, 169, 301, 417n2, World Bank, 176
UCLA, 200 173, 175 495, 497, 500n27 WorldCom, 62
United Nations Educational, Scientific, U.S. Department for Work and U.S. Nuclear Regulatory Commission World Trade Center, 173
and Cultural Organization Pensions, 8 (NRC), 14-15, 487
(UNESCO), 116 U.S. Department of Defense (DoD), 36, X
United Parcel Service (UPS), 2–3 146-147, 151, 170, 439, 439n2, 498 V Xerox Corporation, 61, 68-69
United Technologies Corporation, U.S. Department of Energy, 134, Volkswagen, 180 Xinhua, 242
67, 98 134n29, 461 Volvo, 17, 116
ÍNDICE DE NOMBRES
A Cameron, D., 366n1 Dixit, A. K., 112n17 Gobeli, D. H., 74n20, 74n22, 55, 56,
Aalto, T., 93n21, 100-101, 112n7 Camm, J. D., 294n8 Dobson, M., 113n25 56n24
Ackerman, S., 184n1 Campanis, N. A., , 328n6 Done, K., 366n1 Goldratt, E. M., 370-371, 370n3,
Adams, J. R., 223n18, 223n22 Cardoza, D., 176 Doward, J., 294n1 371n5, 373, 373n9, 374, 377-378,
Adams, L. L., 223n18 Carland, J. C., 112n2 Dowd, S., 219-220 378n12, 378n14, 386, 386n18,
Akame, T., 219-220 Carland, J. W., 112n2 Dulewicz, V., 143n3 390-391, 393, 397
Al-Sadiq, M., 229-230 Carnes, B., 134, 134n29 Dumaine, B., 429n2 Goldstein, H., 294n1
Alexander, R. C., (pdf68), 74n34, Casey, W., 57, 74n27 Duncan, W. R., 184n8, 398n25 Goleman, D., 143n11
74n35 Castaneda, V., 184n24 Dunnette, M. D., 223n24 Gong, D., 328n3, 328n4
Allen, D. C., (pdf307), 328n6 Cavas, C. P., 500n27 Duranti, G., 133 Goodson, J. R., 143n13
Allen, N., (pdf227), 256n1 Chae, K. C., 328n4 Dvir, D., 32n26, 17, 398n27 Gordon, J. A., 294n20, 429n4
Ammann, O., 250 Chakrabarti, A. K., 144n22 Dworatschek, S., 74n24 Gould, S. J., 200
Amor, J. P., (pdf 268), (pdf268), 270 Chan, M., 223n22 Dye, L. D., 112n19 Gousty, Y., 112n5
Anagnostou, G., 369 Chan, T., 112n17 Govekar, M., 143n3
Anderson, C. C., (PDF 53)74n21 Chancellor, 495 E Goyal, S. K., 294n18
Antonini, R., (451), 463n6 Chaouni, A., 115-116 Eccles, R. G., 224n30 Grae, K., 223n5
Antonioni, D., (170) ,184n22 Chapman, C. B., 256n3, 256n11 Edgett, S., 113n25 Graham, R. J., 7, 7n13, 74n28
Arnott, S., 500n26 Chapman, R. J., 256n4 Edison, P., 4 Grant, K. P., 33n29
Artto, K. A., 99n21, 101 Charette, R., (pdf 260), 294n1 Eidsmoe, N., 74n26 Graves, R., 256n7
Atkinson, R., 18, 18n28 Charvat, J. P., 499n17 Einsiedel, A. A., 143n14 Gray, C. F., 32n20, 74n24, 74n25,
Aubry, M., ( 57), 74n26 Christensen, D. S., 294n20, 469n6 Eisenhardt, K. M., 102, 102n24 294n22, 328n5, 366n4, 429n9
Axe, D., 500n27 Christensen, L., 2-3 Eksioglu, S. D., 398n14 Gray, D., 459
Ayas, K., (134),144n29, 144n30 Christensen, V., 488 Eley, T., 223n1 Gray, V., 398n19
Azani, H., (79), 112n5 Christie, C., 472, 472n1 Elmaghraby, S. E., 328n3 Green, S. G., 223n3, 499n16
Clark, C. E., 328n3 Elmes, M., 74n29 Greenberger, D. B., 143n17
B Clark, K. B., 74n23, 112n2 Elton, J., 113n20, 398n5, 398n10, 398n26 Grindley, W., 176, 176n24
Bach, R., 131 Clarke, N., 143n11 Emam, K. E., 398n23 Grundy, T., 73n5, 74n16
Badiru, A. B., (268), (299), 294n8, 328n3 Clay, W. L., 174 Englund, R. L., 74n28 Guegel, A., 223n1
Bair, M., 332 Clayton, J., 328n1 Engwall, M., 74n22
Baker, B. N., 452n8 Cleland, D. I., 9, 9n20, 20, 31n7, 32n5, Enthoven, A., 184n24
32n11, 32n20, 33n30, 33n31, 38- Evans, D. A., 112n14, 112n16
H
Baker, H. G., (180), 185n25 Hackbarth, G., 294n13 Hamburger,
Balachandra, R., 499n15 39, 41, 41n11, 46, 46n17, 73n3, Evans, J. R., 294n8
D. H., 256n9, 294n18, 499n2,
Bard, J. F., (pdf 271)294n18, 348, (pdf 73n4, 73n6, 73n9, 74n9, 74n10, Excell, J., 73n1
500n21, 500n25
354), 366n5 74n1174n17, 112n6, 143n3,
Hannon, E., 143n16
Barndt, S. E., (206), 223n22 144n31, 184n3, 184n9, 223n6, F Hart, J., 3
Barnes, M., (271), 223n22 223n18, 223n22, 294n2, 294n3, Fagerhaug, T., 223n18
Hartley, R. J., 185n25
Barnes, R., (390), (418), 398n27 294n5, 294n6, 469n7, 469n8, Fazar, W., 328n3
Hartman, F. T., 74n10, 144n27, 223n5,
Beale, P., (pdf 16), 32n24 469n11, 499n17, 499n18 Feickert, A., 184n1
223n6
Bearak, B., (298), 328n1 Clements, J. P., 223n7 Felan, J., 398n19
Hatfield, M. A., 469n2
Bellerive, J., 226 Cole, J., 429n1 Fendley, L. G., 429n6, 429n7
Hauschildt, J., 143n15
Belout, A., (453), 469n10 Cooke-Davies, T., 33n28, 499n5, Fichtner, C., 252
Heiser, J., 294n12
Bennett, S. C., 500n23 499n6, 499n10, 499n12 Field, T., 500n20
Hennessy, C., 256n8
Bennis, W., 132, 132n25 Cooper, K. G., 342, 366n3 Fields, M. A., 32n9, 294n8, 429n8
Henry, P., 110
Berg, N., (298), 328n1 Cooper, M. J., 389, 389n22, 390 Finnerman, T., 289
Herroelen, W., 398n9
Blass, G., (333), 366n1 Cooper, R. G., 113n25, 499n17 Fisher, D., 469n8
Hill, J., 328n6
Block, P., 117, 117n5 Coutu, D. L., 223n19 Fisher, R., 44, 44n14, 211, 211n32, 213,
Hobbs, B., 74n26
Block, R., 44, 44n13 Covin, J. G., 462 213n34, 224n34, 203n35
Hodge, N., 184n1
Block, T., (57), 74n26 Cragg, C., 3 Fleming, M. M. K., 74n21
Hoegl, M., 223n3
Blomquist, A., 219 Crawford, J. K., 33n32, 112n1 Fleming, Q. W., 74n28, 462, 469n2,
Hoel, K., 398n16
Blomquist, T., (57), 74n26 Crawford, J. R., 294n11 Flynn, P., 219-220
Hoffman, E. J., 134, 134n31
Boateng, P., 496 Crawford, K., 33n31 Flyvbjerg, B., 275, 275n19
Holm, M. S., 294n19
Boctor, F. F., (PDF 407), 429n6 Crenshaw, J., 177 Ford, R. C., 74n21
Homer, J. L., 398n9
Boddy, D., 32n6 Foreman, E. H., 112n12
Horner, R. M. W., 329n9
Bonke, S., (40), 74n9 D Foti, R., 112n1
Houser, H. F., 143n13
Book, S. A., 469n16 Daft, R. L., 74n18, 74n21, 74n30, 143n7 Frame, J. D., 32n7, 74n15, 74n26,
Howell, G., 366n2
Bowman, Z., 429n1 Dai, C. X., 74n25, 74n26, 85, 85n11 184n19, 223n16, 499n18, 500n24
Huchzermeier, W., 112n17
Brandon, Jr., D. M., 469n3, 469n4 Das, T. K., 143n17 Freeman, M., 32n24
Huemann, M., 33n31
Bredillet, C. N., 469n6 Dastmachian, A., 143n13
Hugsted, R., 328n3
Brenner, N., 223n1 David, F. R., 73n2 G Hulett, D., 328n4
Brooks, F. P., Jr., 366n3 Davis, T. E., 223n15 Gabarro, J. L., 224n30
Hull, S., 256n13
Brown, A., 73n8 Dehler, G. E., 499n16 Galbraith, J. R., 223n14
Humphrey, W. S., 33n32
Brown, M., 473–474 Dekkers, M., 33n31, 33n32, 100 Gale, S., 74n33
Hunger, J. D., 73n7
Brown, S. L., 102n24 Delisle, C., 223n18 Gallagher, C., 328n4
Hwee, T., 223n1
Bryde, D., 144n20 DeLone, W. H., 18, 18n27 Gantt, H., 336
Buchanan, D. A., 32n6 DeMarco, T., 323n9 Garbuio, M., 294n19
Budd, C. S., 389, 389n22, 390 Deming, J. E., 372–374, 372n7 Gareis, R., , 20, 33n31 I
Buhl, S., 294n19 Deutsch, J. G., 185n25 Garrahan, M., 184n24 Ibbs, C. W., 33n29, 33n30, 33n31, 366n3
Burgess, T. F., 184n17, 184n20 DeYoung-Currey, J., 328n6 Gauvreau, C., 469n10 Ireland, L. R., 499n17
Burns, R., 45 Dignan, L., 500n20 Geoghegan, L., 143n3 Ive, G., 499n8
Bush, G., 174 Dillibabu, R., 294n17 Gersick, C., 200, 200n11
DiMarco, N., 143n13 Gido, J., 223n7 J
C Dinsmore, P. C., 184n2, 184n3, Gilbreath, R. D., 32n5 Jaafari, A., 233, 256n6 James, J., 139–140
Cabanis-Brown, J., 184n3 499n12 Globerson, S., 184n13, 294n18, 348, Javidan, M., 143n13 Jeffery, R., 294n17
Callahan, J., 321n10, 328n3 Ditlea, S., 223n21 366n5 Jenkins, R. N., 33n33
529
530 Índice de nombres

Jensen, M. A., 223n8, 223n9 Lehtonen, M., 101, 113n23 Moder, J. J., 328n4 Q
Jobs, S.,8, 69 Leigh, E., 259 Mongalo, M. A., 328n4 Qiu, F., 112n17
Johnsson, J., 366n1 Leigh, W., 223n5 Monroe, K., 64
Jones, P., 219-220 Lemer, J., 366n1 Moore, D., 74n18 R
Leonard, T., 256n1 Moretton, B., 321, 329n10, 328n3 Raelin, J. A., 499n15
Leus, R., 398n9 Morris, P. W. G., 32n25, 184n17, Ramanujam, V., 219-220
K Levine, H. A., 256n9, 469n7, 469n9
Kadefors, A., 223n5 Kahkonen, K., Ramsey, M., 429n1
Levy, F. K., 328n4 Morse, L. C., 429n6 Randolph, W. A., 74n21
256n3, 256n12 Levy, O., 32n26 Moulds, J., 294n1
Kahneman, D., 294n19 Ranger, S., 500n26
Li, M. I., 366n3 Mowery, B., 131-132 Raz, T., 112n5, 398n16, 398n27, 429n3
Kallqvist, A. S., 74n22 Libertore, M. J., 329n6 Mulally, A., 116
Kamburowski, J., 328n3 Reagan, R., 120, 460, 488
Lieberman, J., 175 Müller, R., 74n26, 143n13 Reginato, P. E., 33n30
Kanaracus, C., 500n20 Lipke, W. H., 469n16 Mummolo, G., 328n4
Kapur, G. K., 32n16 Reilly, F. K., 112n15
Loch, C. H., 112n17 Murphy, D. C., 469n8 Rencorcet, N., 256n1
Karlsen, J. T., 223n5 Lock, D., 294n7, 366n2, 469n13
Keefer, D. L., 328n4 Render, B., 294n12
Logue, A. C., 223n17 N Reynolds, W. H., 185n25
Keim, G., 143n15 Long, J., 499n19 Napolitano, J., 173,175
Keller, L., 32n9, 429n8 Robbins, S. P., 224n27
Longman, A., 113n25 Navarre, C., 366n5
Kelley, M., 32n19 Robertson, C., 223n1
Lorenz, C., 256n7 Needy, K. S., 294n2, 294n5, 294n6
Keown, A. J., 112n16 Robinson, P. B., 469n2
Louk, P., 294n3 Newbold, R. C., 398n14
Kerzner, H., , 22, 22n32, 32n8, 74n26, Roe, J., 113n20, 398n5, 398n10,
Low, G. C., 294n17 Nicholas, J. M., 366n2
74n28, 184n3, 294n3 398n26
Lundin, R. A., 32n12 Norris, G., 366n1
Kezbom, D., 144n31 Rohde, J., 30
Lutz, Robert, 48 Rom, W. O., 398n14
Kharbanda, O. P., 74n35, 143n4, Lynch, S., 174 O
185n25, 256n15, 294n23 O’Donnell, K., 418–419 Roseboom, J. H., 328n3
Khorramshahgol, R., 112n5 O’Leary, Hazel, 461 Ross, J., 74n34, 499n17
Kidd, C., 184n17, 184n20 M Obama, B., 175 Rouhiainen, P., 32n20
Kidd, J. B., 328n3 MacLeod, K., 429n4 Obradovitch, M. M., 184n10, 184n14 Rowlings, J. E., 328n4
Kiley, S., 177 Maher, M., 294n21 Oglesby, P., 366n2 Royer, I., 144n23
Kilmann, R. H., 74n29, 74n31 Maidique, M. A., 144n18 Olson, D. L., 33n28 Ruiz, P., 469n6
Kim, S., 328n4 Malanga, S., 499n1 Olsson, H., 17
Kim, W. C., 143n2 Malcolm, D. G., 328n3 Onsrud, H. J., 144n21 S
Kimball, R. K., 184n3 Mandela, N., 296 Saaty, T. L., 84, 84n9, 1125n12
King, W. R., 32n5, 73n4, 39, 39n6, Manley, J. H., 469n12 P Sandahl, D., 113n25
46, 46n17, 73n9, 74n11, 112n6, Mantel, Jr., S. J., 74n19, 112n4, Padgett, T., 256n1 Sanders, P., 366n1
143n3, 184n9, 223n22, 294n3, 184n12, 184n18, 262, 262n4, Palmer, J., 396 Sasieni, M. W., 328n4
469n7, 469n8, 469n11, 499n2 294n9, 294n20, 310, 310n7, Palmer, T., 143n3 Saxton, M. J., 74n29, 74n31
Kinlaw, C. S., 144n31 429n5, 429n10, 429n11, 499n3, Parboteeah, K. P., 223n3 Schaan, J., 366n5
Kinlaw, D. C., 144n31 475, 475n4, 499n17 Parker, H., 366n2 Schein, E. H., 74n29
Kirsner, S., 74n30 Martinsuo, M., 113n21 Pascale, S., 112n2, 256n7 Schein, N., 218
Klamper, A., 294n1 Marsh, P., 500n22 Patrick, F., 398n16 Schlesinger, L. A., 224n30
Kleinschmidt, E. J., 499n17 Marshall, B., 398n16, 429n3 Patterson, J. H., 429n8 Schmidt, W. H., 223n23
Knoepfel, H., 74n24 Marshall, R. A., 469n6 Paul, S., 384 Schon, D. A., 144n18
Knutson, J., 32n11, 112n1, 144n32, Martin, J. D., 112n16 Pearson, D., 73n1 Schoner, B., 112n13
184n13, 184n19, 294n18, 499n5 Martin, M. G., 184n6 Peck, W., 57, 74n27 Schuerman, M., 499n1
Koppelman, J. M., 74n28, , 462, 469n2 Martin, P., 256n5 Pennypacker, J. S., 33n29, 112n19 Schultz, R. L., 469n12
Koru, A. G., 398n23 Martinsuo, M., 100, 100n23, 101, Pescatore, P., 8 Scott, Jr., D. F., 112n16
Kostner, J., 223n18 112n7, 113n21, Peters, T. A., 4, 128, 128n19 Scott, S., 218
Kouri, J., 184n23 Marwick, P., 8 Petersen, P., 429n4 Seddon, P. B., 32n27
Kouzes, J. M., 133,143n7, 143n12, Massaoud, M. J., 223n5 Peterson, L., 148 Selly, M., 112n12
144n26 Mauborgne, R. A., 143n2 Petri, K. L., 294n2, 294n5, 294n6 Serpa, R., 74n29, 74n31
Krauss, C., 223n1 McComb, S. A., 223n3 Petro, T., 469n5 Sersaud, A. N. S., 499n18
Krigsman, M., 184n23 McConnell, S., 271, 294n16 Petroski, H., 32n21 Severston, A., 184n24
Krishnaiah, K., 294n17 McCray, C. G., 429n6 Pettersen, N., 143n13 Shachtman, N., 500n27
Kumar, U., 499n18 McCray, G. E., 223n5, 429n6 Petty, J. W., 112n16 Shafer, S. M., 499n17
Kumar, V., 499n18 McCullough, B., 497 Phillips, C. R., 328n4 Shakespeare, W., 245
Kwak, Y. H., 33n29, 33n31 McIntosh, J. O., 429n6 Pindyck, R. S., 112n17 Sharp, D., 500n27
McKinney, J., 469n6 Piney, C., 398n29 Shenhar, A. J., 32n26, 17, 144n32
McLean, E. R., 18, 18n27, 32n27 Pinto, J. K., 20, 32n15, 32n20, 33n30, Sherif, M., 223n13
L McNerney, J., 333 33n31, 73n3, 74n9, 74n35, Sherman, E., 398n13
LaHood, R., 176, 472 Medcof, J. W., 143n15 85-86, 112n8, 112n16, 129, Sherman, J. D., 112n3
Lai, K-K., 112n17 Mendelow, A., 73n9 143n3, 143n4, 143n17, 143n20, Shtub, A., 294n18, 348, 366n5
Lakshman, N., 143n16 Lander, M. C., Mepyans-Robinson, R., 184n3 144n21, 144n23, 144n31, 184n8, Sigurdsen, A., 294n18
223n5 Meredith, J. R., 120n20 184n17, 185n25,201, 201n12, Silver, D., 144n28
Langford, M., 223n1 Meredith, J. R., 74n19, 112n4, 112n18, 223n4,223n6, 223n12, 223n18, Simister, S. J., 33n31, 294n7, 469n13,
Lanier, J., 223n20 144n20, 184n12, 184n18, 262, 224n26, 256n2, 256n15, 294n18, 500n22
Larson, E. W., 32n20, 74n20, 74n22, 262n4, 294n9, 294n20, 310, 294n23, 366n3, 398n28, 453, 462, Simpson, T., 127
56, 56n25, 55, 55n24, 294n22, 310n7, 429n5, 429n10, 429n11, 469n10, 499n8, 499n9, 499n11 Singh, M., 287
328n5, 366n4, 329n9 475, 475n4, 484, 484n13, 499n17 Pinto, M. B., 201, 223n12, 499n11 Singletary, N., 469n2
Laufer, A., 184n5 Merle, R., 184n1 Pitt, A., 223n1 Singleton, D., 3
Lavallo, D., 294n19 Merrill, J., 398n17 Pondy, L., 224n24 Slevin, D. P., 20, 33n31, 74n9, 129,
Lavold, G. D., 184n9 Mersino, A., 499n17 Posner, B. Z., 133, 143n3, 143n7, 143n3, 143n8, 144n20, 144n23,
Leach, L. P., 372-373,377, 379, 397n2, Metzger, A., 35 143n12, 144n26, 223n22, 224n28 144n31, 223n6, 223n18, 224n31,
398n4, 398n6, 398n8, 398n11, Mian, S. A., 85, 85n11 Prasad, J., 329n6 453, 453n10, 469n12, 499n9
398n16, 398n20, 398n21 Milani, K., 469n5 Prescott, J. E., 201, 223n4, 223n12, Smith, D. K., 74n35
Leach, S. P., 398n4 Miller, G. J., 294n3 499n11 Smith, E., 148
Lederer, A. L., 329n6 Millet, I., 32n15, 79n8, 85, 85n10, 86, Pressman, R., 144n24 Smith, K., 138
Lee, J., 328n4 87n13 Pritchard, C. L., 33n32, 499n18 Smith, N. J., 294n18
Lee, S. A., 366n3 Mitchell, J., 184n24 Purvis, R. L., 223n5, 429n6 Smith, R., 499n19
Índice de nombres 531

Smith, S., 14–15 Telford, T., 294n18 V Wheelwright, S. C., 74n23,112n2


Smith-Daniels, D. E., 328n3 Teplitz, C. J., 294n8, 294n10, 270 Valery, P., 32n1 Whitehouse, G. E., 429n6
Smith-Daniels, V., 328n3 Teubal, M., 499n17 Van der Merwe, A. P., 73n5 Wideman, R. M., 74n10,
Smyth, H. J., 223n5 Thamhain, H. J., 224n25, 224n28 Vandevoorde, S., 469n16 144n32,184n8, 228, 228n2, 229
Soderholm, A., 32n12 Thomas, J., 396 Vanhouckel, M., 469n16 Wiegers, K., 290
Sohmen, V., 13, 13n23 Thomas, K. W., 223n23, 223n24, Venkataraman, R., 294n18 Wiener, E., 73n8
Sokol, D., 328n1 219-220 Verdini, W. A., 328n4 Wiest, J. D., 328n4
Speir, W., 113n25 Thomas, L. C., 328n6 Verma, V. K., 143n6, 143n2,143n10, Wilemon, D. L., 74n29, 223n22,
Spencer, D., 148n10, 148n14 Thomas, P., 32n3 224n29,191, 198, 224n26, 223n25, 223n28
Spiller, P. T., 499n17 Thompson, N. J., 223n5 224n27 Williams, T. M., 256n12, 328n4
Spirer, H. F., 499n2, 500n21, Thoms, P., 143n3, 143n17, 138, Voelker, J., 429n1 Willie, C. J., 429n6
500n25 138n33 von Karman, T., 250-252 Winch, G. M., 74n9
Sreedharan, E., 124-125 Toney, F., 294n18 Womer, N. K., 294n8
Staw, B. M., 74n34, 499n17 Trailer, J., 143n3 W Woodruff, G., 250
Stephanou, S. E., 184n10, 184n14 Troilo, L., 256n7 Waldron, R., 112n12 Woodworth, B. M., 429n6, 429n8
Stephen, A., 469n16 Tuchman, B. W., 223n8, 223n9 Ward, S. C., 256n3, 256n11 Wyatt, D., 496
Stewart, T. H., 32n4 Tukel, O. I., 398n14 Ware, J., 224n30
Steyn, H., 398n12, 398n15, 398n29 Tulip, A., 429n4 Turbit, N., Warnock, C. G., 185n25
Stuckenbruck, L. C., 184n5 294n17
Y
Warren, W., 184n24 Yasin, M. M., 143n10
Sullivan, M., 290 Turner, J. R., 33n31, 143n13, 294n7, Waxman, H., 174 Yeo, K. T., 112n17
Swanson, S., 143n16 469n13, 499n7, 500n22 Weaver, P., 429n12 Yourdon, E., 184n16
Sweet, J., 339-340 Turner, R., 170, 184n21 Weikel, D., 185n24 Yourker, R., 74n18
Welch, J., 116, 130, 486 Yukl, G. A., 121, 143n7, 143n9
T U Wells, W. G., 74n26
Tadasina, S. K., 499n17 Umble, E., 398n19 Welsh, M. A., 499n16
Talbot, B. F., 429n8 Umble, M., 398n19 Westerveldt, E., 219-220 Z
Talhouni, B. T., 329n9 Ury, W., 44, 44n14, 211, 211n32, 213, Westney, R.E., 184n2 Zalmenson, E., 398n24
Tate, K., 256n5 213n33, 224n34, 224n35 Wheatley, M., 112n1 Zhang, J., 112n17
Taylor, S. G., 398n16 Urzua, L., 2, 4 Wheelen, T. L., 73n7 Zimmerer, T. W., 143n10
ÍNDICE ANALÍTICO
A Carga de recursos, 404–406
Accesibilidad, 202 Causa común de la variación, 372
Aceptación del cliente, 16, 453-454 Causas
Aceptar de retrasos del proyecto, 374–375
el conflicto, 210 especiales de la variación, 371–373
el proyecto, 476 interpersonales de conflictos, 208-209
el riesgo, 237 margen de seguridad del gerente del proyecto, 374–375
Actividad (es) organizacionales de conflictos, 207–208
concurrentes, 303 Central eléctrica de Dulhasti, 287-288
convergentes, 300, 304, 377 Centrarse en los intereses vs. posiciones, 213
de escalamiento, 318-319 Centro de prácticas comerciales, 21
definición de, 348 Chaouni, Aziza, 115-116
diferenciación de, 348-351 Ciclo
divergente, 300, 304 de control 433
en el nodo (AON) vs. actividad en la flecha (AOA), 301, 353-354 de vida de un proyecto, 12
en la flecha, 348 Cierre del proyecto, 170–171
en serie, 303 Clientes, 41
dummy, 351 aceptación de, 16
fraccionar, 417 Código de conducta, 204
ordenada, 298 Códigos EDT, 158
posterior, 299 Cohesión, 194
predecesoras, 301, 305 Colapso de un edificio de apartamentos en Shanghái, 241–242
recorridos hacia adelante de, 352-353 Columbus Instruments, Inc. (CIC), 217-218
recorridos hacia atrás de, 352-353 Comet, 247–249
resumen, 319 Compartir el riesgo, 237
Actos de Dios, 233, 239 Competidores, 42
Adaptación, 199 Comportamiento disfuncional, 198
Adición de detalles de la red, 508–511 Compresión del proyecto, 340–347
Agregación de riesgos, 378 definición de, 340
Alcance, 300 efectos en el presupuesto, 347–348
Alentar y recompensar a los tomadores de riesgo, 130–131 opciones para acelerar los proyectos, 340–347
Alineación temporal, 126 Compromiso de los empleados con las metas, 63
Al-Sadiq, Mohammed, 229-230 Comunicación, 453-454
Alta dirección, 43 fallas de, 208
apoyo de la, 453 gerente de proyecto y la, 118-120
notificación de las consecuencias a la, 193 libertad de, 102
recortes esperados de la, 375 pobre, 197
Ambiente, 61. Ver también ambientes multiproyecto potenciales miembros del equipo de, 192
bajo costo del monitoreo del, 102 Comunidades técnicas conservadoras, 102
evaluación del, 44 Confianza, 194–195
externo, 47 Conflicto
Análisis aceptar, 210
de hitos, 436–437 administrativo, 206
definición de, 436 arbitrar, 209
problemas con los, 437–438 causas organizacionales de, 207-208
de puntos de función, 272 control, 210
y gerencia de riesgos de proyectos (PRAM), 243–245 definición de, 206-207
Arbitraje, 492 de recursos, 385–386
del conflicto, 209 eliminación de, 210
Asimilación, 199 en las redes, 505–507
Asistencia médica mundial, 64 fuentes de, 207-208
Atribuciones erróneas, 208 gerencia del, 206-207, 209–210
Autorización de trabajo, 164–165 interpersonal, 206, 208
Autorregulación, 122 mediación de, 209
Ayuda en el terremoto de Haití, 226-227 metas poco claras, 196
métodos para resolver, 209-210
B orientado a las metas, 206
Benchmarking, 19 recurso, 385–386
Boeing Corporation, 174-175, 248 Equipo (s)
Brown, Mike, 473–474 características de los, 190–193
Buffers conformación del, 190–193
alimentadores, 380–383 disolver el, 479
de restricción de capacidad (CCB), 387 efectivos, 193–195
de tambor, 387 etapas en el desarrollo de grupo,198–201
gerencia de conflicto, 206–210
lograr la cooperación interfuncional, 201–203
C miembros del, 43–44
Cadena crítica
negociación, 210–215
solución de, 378–382
razones por las cuales fracasan, 195–198
conflictos de recursos de, 385–386
seguridad desperdiciada por, 375-378
soluciones de ruta crítica vs., 382-383
virtual, 203–204
California high-speed rail authority (CHSRA), 175-176
Consecuencias
Campeones de proyectos, 127–131
análisis de, 231, 233–237
alentar y recompensar a los tomadores de riesgo, 130–131
de fracaso, 236
definición de, 128-129
notificación a la alta gerencia,193
desarrollo de, 130–131
Consecuencias negativas de la multitarea, 376–377
evitar a las actividades tradicionales de,131
Consideración válida, 149, 165
identificación de, 128
Construir, apropiar, operar y transferir (BOOT), 476
papel de, 129–130
Construir, operar y transferir (BOT), 476
surgimiento de, 130 533
534 Índice analítico

Consulta del cliente, 453–454 conceptual, 149–151


Contabilidad, 43 de la red de actividades de cadena crítica, 380–382
Contexto organizacional soluciones de cadena critica vs. soluciones de ruta crítica, 382–383
cultura organizacional, 59–60 Desastre del pozo petrolero Horizon de la BP, 187-189
estructura organizacional, 46–47 Desempeño, 199
gerencia del grupo de interesados (stakeholder), 40–46 análisis de hitos, 436–437
introducción de, 36–37 curva S del proyecto, 434–436
oficina de gerencia de proyectos, 56–59 del equipo, 93
proyectos y estrategia organizacional, 37–40 del proyecto, 434–439, 492
Contingencia de tareas, 238 desventajas, 438-439
Contingencia gerencial, 239 diagrama de Gantt de seguimiento de, 438–439
Contingencias en el desarrollo del presupuesto, 279-280 efecto de la estructura
Contratos organizacional en, 55–56
llave en mano, 165 ventajas de, 438-439
precio fijo, 238 Destructor DDG 1000 Zumwalt, 497–498
de costo incrementado, 165 Detección de proyectos
de valor global, 165 en General Electric Corporation, 97–98
Control, 239–241 enfoques para, 79–89
definición de, 231 finalizaciones tardías de las actividades, 411
del conflicto, 210 modelo de lista de verificación, 79–81
de adquisición, 168 modelo de puntuación simplificado, 81–84
de configuración, 168 Proceso de jerarquía analítica (AHP), 84–87
de diseño, 168 Diagrama (s)
de documento, 168 de carga de recursos, 415–417
de especificación, 168 división, 417
de proyectos, 434. Ver también gerencia del valor ganado (EVM) de Gantt, 336–338
ciclos de, 433 adición de recursos, 337-338
factores humanos en, 451–454 definición de, 336
introducción a, 432 de seguimiento, 438
Copa Mundo 2010, 296–298 incorporación de retrasos, 338
Costeo basado en actividades (ABC), 277-278 en las redes, 506–507
Costo real de trabajo realizado (AC), 440 de red del proyecto (PND), 300
Costos. Ver también el presupuesto del proyecto Diferenciación, 194, 208
de materiales, 261 Disney, 30-31
directos vs. indirectos, 261–262 Distorsión del tiempo, 126
fijos vs. variables, 263 Distribuciones beta, 308
gerencia de, 260–263 Documentación, 239-241
laborales, 260-261 definición, 231
normales vs. acelerados, 263 Dreamliner 787, 331–333
recurrentes vs. no recurrentes, 263
para comprimir, 263 E
Criterios objetivos, 214–215 Efecto de cámara de compensación, 56
Cronograma ganado (ES), 465-468 Ejecución rápida, 335
definición de, 465 Eliminación del conflicto, 210
Cuadro Elli Lilly Pharmaceuticals, gestion de proyectos con cadena crítica, 384
de carga de recursos Emociones y negociación, 212
desarrollo de, 410–411 Empatía, 122
nivelación de, 412–415 Emprendedor organizacional, 128
de uso de recursos, 405–406 Enfoque de comparación por pares, 85
Cuentas de control de costo, 160 Entornos multiproyecto
Cuerpo de conocimientos de la gerencia de proyectos (PMBOK), 154 asignación de recursos, 421–422
Cultura, 59-60 del cronograma, 420
organizacional, 59–61 gerencia de recursos, 320–422
formación de, 61–62 inventario en proceso, 420–421
gerencia de proyectos y, 62–64 utilización de recursos, 320
Curva S del proyecto, 434–435 Entregables, 5
inconvenientes de, 435–436 Entrenamiento transversal, 239
Curvas de aprendizaje en la estimación de costos, 267-268 Entusiasmo, 195
Equilibrio intermitente, 200–201
D Equipos de proyectos virtuales, 203–206
Daños y perjuicios, 238 Escalamiento, 64, 318-319
Decisiones Estación meteorológica PMO, 57–58
de choque, 302 Estimación de costos, 259, 264–275
de recursos en entornos multiproyecto, 421–422 curvas de aprendizaje en, 267–268, 270
de recursos, 421 problemas con, 273–274
mínimo fin tardío, 422 proyectos de software, 271–272
primero en la fila, 421 Estimación de costos y presupuestos, 257-294
programación matemática,422 contexto organizacional, 34-74
Declaración de la duración de la actividad, 308-309
de la misión, 37 de la duración del proyecto, 307-310
de la necesidad, 149–150 de la finalización (EAC), 447
de trabajo (SOW), 151–153 de tareas del proyecto, 69
del alcance, 153–164 paramétrica, 265–266
estructura de desglose de la organización,160–162 programación del proyecto, 295–329
estructura de desglose del trabajo,154–160 Estimaciones
matriz de asignación de responsabilidades,162–164 de factibilidad, 266
Definición de un paquete de trabajo del proyecto, 164 definitivas, 266
Definir el problema, 45 preliminares, 264
Demanda de recursos, 421 Estimados comparativos, 265
asignación de recursos y, 421–422 Estrategias de mitigación de riesgo, 231, 236–238. Ver también riesgo
mayor, 421 otras estrategias, 239
utilización de, 421–422 Estructura
Demora por caminos con actividades convergentes, 377 basada en proyectos, 50–52
Departamentos, 160, 163 de desglose de la organización (OBS), 160–162
Desarrollo de desglose del trabajo (EDT), 154–155, 300
Índice analítico 535

funcional, 48-50 declaración, 153–164


flexible, 102 definición de, 148
matricial, 52–53 desarrollo conceptual, 149–153
organizacional, 46–47, 493 introducción a, 148
formas de, 47–55 reporte del, 165–166
resultados de los proyectos, 55–56 sistemas de control, 168–170
propósitos de la, 155–160 de proyectos con cadena crítica, 386–388
Etapas en el desarrollo de un grupo, 198–201 definición de, 77
adaptación, 199 desarrollo proactivo de, 100–101
asimilación, 199 del cambio, 240
desempeño, 199 del conflicto, 206
equilibrio intermitente, 200-201 del grupo de interesados (stakeholder), 40–46.Ver también interesados
formación, 199 del portafolio, 98–103
levantamiento, 199-200 aplicación del valor ganado a la gerencia, 447–448
Evaluación claves para la gerencia exitosa, 102
cualitativa del riesgo, 254 definición de, 98
de proyectos. Ver también gerencia del valor ganado (EVM) iniciativas de, 99–100
del valor ganado, 444–447 introducción a, 77
factores humanos en, 451–454 objetivos de, 99–100
Evaluar sus propias capacidades, 45 proactivo, 100–101
Evento, 300 problemas en la implementación de,102–103
Éxito de los proyectos, 18–19 del riesgo
Expedición al Everest (Disney), 30-31 análisis de probabilidad, 233–236
análisis y consecuencias de, 233–236
F control, 239–241
Factores definición de, 228
claves de éxito, 453-454 documentación, 239–241
humanos en la evaluación y el control de proyectos, 451-453 enfoque integrado para, 243–245
Falla al omitir la variación positiva, 376 estrategias de mitigación, 236–238
Falta de motivación, 196 identificación, 231–233
Fase introducción a, 228
de conceptualización, 12–13 un proceso de cuatro etapas, 231–241
de ejecución, 14 uso de reservas para las contingencias, 238–239
Fecha del valor ganado (EVM), 439–447
de inicio temprano (ES), 300, 333 aplicación a la gerencia de proyectos, 447-448
de fin tardío (LS), 300, 337 aplicación a la gerencia del portafolio, 447-448
Final creación de las líneas base del proyecto, 440-441
a final, 333-334 definición de, 439
a inicio, 333-334 evaluación del,444-447
tardío, 422 pasos en, 443
Finalizar el trabajo, 475 problemas del uso efectivo, 449-451
Flecha, 301, 348 terminología, 440
Ford Gerente de proyectos, 114, 118, 129
Company, 177–180 adquisición de recursos del proyecto,18–119
Edsel, 177–180 comunicación, 120–121
Formación, 198–199 efectivo,123
Fragmentación de tiempo, 126 líderes de proyectos vs., 117–118
Frontera luchar contra los incendios, 119–120
eficiente, 88 margen de seguridad del proyecto del, 374
virtual de Boeing, 173–175 motivación y creación de equipos, 119
Frustración, 208 proceso de, 118–121
Fuente de recursos. PMO, 58 visión estratégica, 119–120
Gerentes funcionales, 43
G Gestión estratégica, 37
General Electric Corporation Gestor creativo, 128
detección del proyecto en, 97-98 Gotthard Base Tunnel, 368-369
selección del proyecto en, 97-98 Gráfico lineal de responsabilidad, 162
Gerencia Grupos interventores, 43
de proyectos (GP)
aplicación del valor ganado a la, 447–448 H
causas de retrasos del proyecto, 374-375 Habilidades
críticas de, 390 de las personas, 191
cultura organizacional y, 62–64 identificación necesaria de, 190–191
de la configuración, 168-170 identificar el conjunto de, 190–191
definición de, 8 Havilland Aircraft Company, 247-249
desarrollo de los modelos de madurez, 19–20 Heurísticas de nivelación, 407
Elli Lilly Pharmaceuticals, 384-385 Hitos, 436-437
en Dotcom.com, 177 Holgura, 300-301, 314–315, 333-334
en India, 124–125 negativa, 315
introducción a, 4 Honestidad, 396
modelos de madurez, 19
I
portafolio de proyectos, 386–388
Identificación presente de los objetivos de los actores principales, 44
profesionalismo en, 134–135
Identificar
técnicas de, 493
el conjunto de habilidades necesarias, 190–191
de recursos
sobreasignación de recursos, 412
carga de recursos, 404–406
Incertidumbre, 14, 207
diagramas de carga de recursos, 415–417
Incidentes críticos, 62
en entornos multiproyecto,420–422
introducción a, 401–402 India, 124-125
nivelación de recursos, 406–415 Índice
restricciones de recursos, 402–404 de desempeño del costo (CPI), 440
del alcance de desempeño del cronograma (SPI),440
autorización de trabajo, 164–165 Inflación, 89, 92-93, 274
cierre del proyecto, 170–171 Información sobre tecnología en Hamelin Hospital, 29
536 Índice analítico

Iniciativas Método
de financiación privada (PFI), 476 de flujo de efectivo descontado (DCF), 89
de infraestructura en China, 10–11 de la ruta crítica (CPM), 301
Inicio Metodología de la cadena crítica, 378
a final, 335 Miembros claves de la organización, 62
a inicio, 334–335 Modelo
Insistencia en el uso de criterios objetivos, 214–215 de opciones, 96
Interdependencias mal definidas, 196 de perfil, 87-89
Instituto para la Dirección de Proyectos (PMI), 5, 25–26 de puntuación simplificado, 81–83
Interacción, 195 de selección de elección de un enfoque proyectos, 96–98
Interdependencia productiva, 194 limitaciones del, 83–84
Interesados del proyecto (stakeholders), 40–41 lista de verificación, 79–80
análisis de, 40 periodo de recuperación, 90–91
definición de, 40 recuperación descontado, 93–94
gestión de, 44–46 tasa interna de retorno, 94–95
identificación de, 41–44 valor presente neto, 92–93
proyecto, 40 Modelos
Intervalo de confianza, 310 conclusiones, 454–455
Inventario en proceso, 420-421 de madurez, 19–21
de selección, 77
J desempeño de, 434–439
James, John, 139-142 factores humanos en, 451–454
Jefes de departamento, 192 introducción a, 432
Jerarquía dual, 52 no numéricos, 78
Johnson & Rogers Software Engineering, Inc., 219-220 numéricos, 78
Monitoreo, 454
K de tendencias, 168
Keflavik Paper Company, 109-110 Motivación
Kimble College, 459-460 y creación de equipos, 119
y liderazgo, 119, 122
Moverse hacia una organización basada en proyectos pesos-pesados, 54-55
L Mowery, Bill, 131–132
Lecciones aprendidas, 478
Multitarea, 376–377, 426–427
Levantamiento, 199
Ley
de Brook, 343 N
de Murphy, 280 Negociación, 210–215
Liderazgo búsqueda de opciones de con los jefes funcionales, 191
campeones de proyectos, 127–131 criterios objetivos, 214–215
definición de, 116 definición de, 210
de proyectos, 132–133 formular antes de, 211
e inteligencia emocional, 122, 138-139 ganancia mutua, 213–214
gerentes de proyecto, 117-121 intereses vs. posiciones, 213
inteligencia emocional y, 122, 138-139 para la asistencia parcial, 192
introducción, 116 principios, 211–213
líderes de proyectos, 123-124 separar las personas del problema, 211–213
pobre, 197 Negociar una asistencia parcial, 192
profesionalismo en la gerencia de proyectos, 134-135 Nissan LEAF, 400–401
proyecto, 132-133 Nivelación de recursos, 406–415
Líderes de proyectos cuadro de carga de recursos, 412–415
características de los efectivos, 123–124 determinar los finales tardíos de las actividades, 411
conclusiones acerca de, 124 identificar sobreasignación de recursos, 412
gerentes de proyecto vs., 117–118 Nodos, 301, 302, 348–349
Línea base Normas, 59–62, 199–202
alcance, 154 Northrop Grumman, el valor ganado, 448–449
definición de, 168 Nova Western, Inc., procedimientos para la selección de proyectos, 110–111
del proyecto, 433-434, 440–441 Nuevo liderazgo de proyectos, 132–133
Lista de verificación, 475
Localización geográfica y cultura organizacional, 61-62 O
Logro en la cooperación interfuncional O’Donnell, Kevin, 418–419
accesibilidad, 202-203 Objetivos, 37
metas de orden superior, 201-202 Oficina de gerencia de proyectos (PMO), 56–59
normas, 202 Opciones de riesgo / rentabilidad, 87–88
procedimientos, 202 Operación de riesgo, 238
proximidad física, 202 Opinión de expertos, 232, 307
resultados de, 203 Orden de magnitud, 264
Luchar contra incendios, 119 Organización del libro, 23–26
Organizaciones
M basadas en proyectos, 50–52
Mantenimiento del comportamiento del grupo, 120 funcionales, 47-50
Marcador de eventos, 349 matriciales, 52–54
Matriz pesos-pesados, 54–55
de asignación de responsabilidades (RAM), 162–164 Orientación, 195
de efecto del riesgo, 233–236 a los resultados, 195
débil, 53 a procesos, 7
del proyecto, 53 al tiempo pasado, 126
equilibrada, 55 de tiempo presente, 126
fuerte, 53 temporal, 126
funcional, 53
Mediar en el conflicto, 209 P
MegaTech, Inc., 28–29 Padrino, 128-129
Metas Paquetes de trabajo, 13,157–158, 301
de orden superior, 201–202 Periodo de recuperación, 90–91
poco claras, 196 Permitir reclamaciones y disputas, 491–492
conflicto de, 196 Pesos a los criterios en AHP, 84
Índice analítico 537

Planes alternativos en la formación de equipos, 192–193 Proyectos


Planeación, 7, 12, 24, 62, 169, 298 acelerar los, 340–347
Portafolios fuera de sincronización, 102–103 aceptación de los, 476
Precede a la actividad, 299 características de los, 6–9
Precedentes, 301 conclusión, 478
Predicción del tiempo, 126 con recursos limitados, 403
Preferencia definición, 5-6
monocrónica, 126 estimación de la duración de los, 307–310
policrónica, 126 estrategia organizacional, 37-40
Preguntas que se deben formular antes de negociar, 211 factores determinantes en el éxito de los, 16–19
Prejuicios, 208 fuera de sincronización, 97, 102–103
Preparación del informe final del proyecto, 492–493, 468–469 gerente de, 114
Presupuestación, 276 importancia de los, 9–12
contingencias en el desarrollo del presupuesto, 279-281 opciones para acelerar los, 340
costeo basado en actividades, 277-278 organización del libro de, 23–26
creación de, 276–277 pesos pesados, 54
de abajo arriba (bottom up), 277 poco prometedores, 103
de arriba abajo (top down), 276 screening de, 79
efectos al comprimir el proyecto, 347 transferir, 476
Presupuesto y estrategia organizacional, 37–40
del proyecto, 276–279 Puente colgante de Tacoma Narrows, 250–252
por fases, 279 Punto
Primero en la fila en la asignación de recursos, 421-422 de convergencia, 304
Priorización, 99 de equilibrio, 90
ajustar la, 192–193 Puntos de función, 272–273
Probabilidades
análisis de, 231, 233–236 R
de fracaso, 235 Ramstein Products, Inc., 396–397
y consecuencias, 231, 233–235 Realidad operativa, 38
Procedimientos, 62, 202 Realineación, 99–100
Proceso Reclamaciones a título gratuito, 491
definición de, 5 Reclamos por incumplimiento, 491–492
de cierre, 475 Recorrido
de jerarquía analítica (AHP), 84-87 hacia adelante, 301, 312–313, 352-353
asignación de valores numéricos para la evolución de la dimensiones, 85 hacia atrás, 301, 311, 314
criterios de, 84 Recuperación descontado, 93
evaluación de propuestas de proyectos, 86-87 Recursos
Proceso Tollgate, 97–98 asignación, 505
Programa definición de, 50, 53
de evaluación de la imagen (IAP), 39 en las redes, 505
Programación escasez de, 207, 402–404
ajuste, 192–193 escasos, 103
comprensión del proyecto, 340–348 nivelación, 505
conclusión sobre, 356 para diagramas de Gantt, 337–338
construcción de la ruta crítica, 311–321 restricciones de, 402
estimación de la duración, 307–310 suavizado, 406
de proyectos Blanque Cheque Construction, 359-36 Red
de proyectos con cadena crítica (CCPM), 370 actualización de la, 508–511
del proyecto /programas, 298–300. Ver también programación de proyectos con adición de detalles de la, 508–511
cadena crítica de actividades, 303
con cadena critica, 389 Redes
con recursos limitados, 301 actividad en la flecha (AOA), 348-349, 353
como desperdician los equipos de cálculo de, 311–312
desarrollo de la red en actividades de cadena critica, 380–381 controversias en el uso de, 354–356
diagramas de Gantt, 336–338 desarrollo de, 301–302
introducción a, 370 tutorial sobre redes, 502-511. Ver también MS Project 2010
matemática, 422 Regla
proyectos la seguridad, 375–378 0/100, 449
redes, 301–304, 354–356 50/50, 449
redes actividad en la flecha (AOA), 348–354 del porcentaje de avance, 450
reforma del producto (PRP), 40 Relaciones de precedencia, 333–335
soluciones de cadena critica, 382–383 final a final, 334
teoría de las restricciones y, 370–373 final a inicio, 333–334
retraso en las relaciones de precedencia, 333–335 inicio a final, 335
terminología, 300–301 inicio a inicio, 334–335
versus programación de proyectos /cronogramas Rencores personales, 208
Proveedores, 42 Rendimiento administrativo, 493
Proximidad física, 202 Reporte del alcance, 165–166
Proyecto Repriorización, 100
adquisición de recursos del, 118–119 Rescate de los mineros chilenos, 2–4
alcance de un, 148 Reservas, 238–239
Boston’s Central Artery/Tunnel, 288-290 para contingencia de tareas, 238
“Big Dig”, 288-290 para contingencia gerencial, 239
cierre del, 170–171 Restricción cuádruple, 16
con restricciones de recursos, 403 Restricciones de recursos, 402–404
disolver el equipo del, 479–484 definición de, 401–402
elementos del, 23–26 escasez de recursos, 402–404
Hudson River Tunnnel, 471–472 escasez de tiempo, 402–404
integrado físicas, 402
Libra, 495–496 Resultados, 155
Marchas de la muerte, 166–167 de las tareas, 203
monitorear el, ver también gerencia del valor ganado (EVM) psicosociales, 203
probabilidad de finalización, 316–321 Reto de la gerencia internacional, 133
terminación del, 488–490 Retraso, 333
538 Índice analítico

Retrasos en el cumplimiento del cronograma, 420 Tecnología, 61


Retroalimentación, 454 cultura organizacional y, 59–60
Revisión, 99, 477–478 de la información (IT), 8
Riesgo de teleinmersión, 205–206
aceptación de, 237 Teorema del límite central, 378
comercial, 231 Teoría de las restricciones (TOC), 370–373
compartir el, 237 causas comunes de la variación, 371–373
contractual, 232 causas especiales de la variación, 371–373
de ejecución, 231–232 Terminación
financiero, 231 anticipada de proyectos, 484–486
identificación del, 231–233 conclusión, 494
legal, 232 definición de, 472
minimizar el, 237 del proyecto, 488–491
proyecto, 228 introducción a, 472–47
técnico, 231 natural, 475–484
transferir el, 237–238 permitir disputas, 491–492
Rolls-Royce Corporation, 67–68, 473–474 permitir reclamaciones, 491–492
Rotación de miembros, 197 por adición, 473
Ruta, 301 por extinción, 473
crítica, 371 por inanición, 474
actividades de escalamiento, 318-319 por integración, 473
actividades resumen, 319 preparación del informe final del proyecto, 492–493
cálculo de la red, 311-312 tecnología, 488
construcción de, 311-321 tipos de, 473
definición de, 301, 337 tomar la decisión para, 486–488
identificación de, 504 Tiempo
recorrido hacia adelante, 312-313 escasez de, 402–404
recorrido hacia atrás, 314-315 fragmentación, 126
soluciones de cadena critica vs. soluciones de, 382–384 futuro, 126
probabilidad de finalización del proyecto, 316-317 pasado, 126
opciones para la reducción, 320–321 predicción, 126
en serie, 315 presente,126
Transferir
S el proyecto, 476
Sanofi-Aventis, 64–65 el riesgo, 237–238
Saudi Aramco Oil Company, 229–231 Transición regulada en tiempo, 102
Screening, 79 Triángulo de hierro, 18
Seguridad del proyecto Triple restricción, 16
demora por caminos con actividades convergentes, 377–378 Toma de decisiones, 99
desperdicio del equipo de proyecto, 375–378 terminación anticipada del proyecto para, 486–488
falla al omitir la variación positiva, 376 Torre de control PMO, 58
margen de seguridad del gerente del proyecto, 374 –375 Tutorial para MS Project 2010
síndrome del estudiante, 375–376 actualización, 508–511
Selección de proyectos, 77–79 adición de detalles y actualización de la red, 508–511
de General Electric Corporation, 97–98 asignación y nivelación de los recursos, 505
enfoque a, 96–98 conflicto de recursos, 505–507
enfoques para la detección y selección, 79–89 construcción de la red, 502–504
introducción a, 77 diagrama de Gantt, 507–511
modelos de perfil, 87–89 diagrama de red, 507–511
para Nova Western, Inc., 110–111 identificación de la ruta crítica, 504
Sentido de la misión, 193–194
Separar las personas del problema, 211–213
Siloing, 48–49
U
U.S. Army, 35–36, 339–340
Síndrome del estudiante, 375–376
U.S. Marine Corps, 418–419
Sistema de recompensas, 61–62, 207
Utilización de recursos en entornos multiproyecto, 420
Sistemas de control, 168–169
Smith, Stephanie, 14–15
Sobreestimación de la duración de las actividades individuales, 374-375 V
Solución de problemas, 454 Valor
Soluciones del dinero en el tiempo, 89
desarrollo de, 45 en Northrop Grumman, 448-449
probar y perfeccionar, 45–46 ganado (EV), 440
Sreedharan, Elattuvalapil, 124–125 planificado (PV), 440
Suavizado, 406 presente del dinero, 90
Superconductor Supercollider (SSC), 460–461 Variación
Sweet, Julia, 339–340 negativa, 376
positiva, 376
T Varianza, 309
Tambor, 386 Vehículo expedicionario de combate (EFV), 146-148
Tarea, 157, 203 Vehículos dirigibles multi-inteligentes de larga resistencia (LEMV), 35–36
Tareas, 298, 333 Visión interactiva del conflicto, 207
técnicas, 454
Tasa W
de descuento, 90 Westinghouse Electric Company, 14–15
de retorno requerida (RRR), 93 Widgets ’R Us (WRU), 70
de retorno sobre la inversión (ROI), 39, 95, 99
interna de retorno (IRR), 94-95 X
Te Apiti Wind Farm, 431–432 Xerox Alto, 68–69
Técnica Xerox Corporation, 68–69
de compresión, 302
de evaluación y revisión de programas (PERT/CPM), 354–356 Z
de revisión y evaluación de programas (PERT), 301 Zion Nuclear Plant, 487–488
GERENCIA de
PROYECTOS
Cómo lograr la ventaja competitiva
La gerencia de proyectos se ha convertido en el centro de operaciones en industrias
tan diversas como la construcción, las tecnologías de la información, la arquitectura,
la hotelería, la ingeniería y el desarrollo de nuevos productos, entre otras. Por ello, en esta
tercera edición de Gerencia de proyectos. Cómo lograr la ventaja competitiva se abarcan,
al mismo tiempo, los principios generales de la gerencia de proyectos y sus ejemplos
específicos, mediante una gran variedad de aplicaciones.

El libro tiene un enfoque holístico e integrado en gerencia de proyectos y en exploración de desafíos técnicos y
de gestión. Además, hace hincapié en la ejecución de proyectos individuales y proporciona una perspectiva
estratégica, al describir los medios con los cuales se pueden gerenciar proyectos de programas y de portafolios.

De otra parte, en el desarrollo del contenido, el autor amplía la visión tradicional de la gerencia de proyectos que
se centra en actividades de planeación, programación, control y su terminación a una perspectiva más general,
incluso, más valiosa del proceso de gerencia de proyectos porque se enmarca en aspectos relacionados con
liderazgo, trabajo en equipo, resolución de conflictos, negociación e influencia, entre otros.

Características destacadas en la tercera edición


• Perfiles de proyectos: cada capítulo contiene uno o más perfiles de proyectos que ponen de relieve
ejemplos actuales de la gerencia de proyectos en acción. Algunos de los perfiles son reflexiones sobre logros
significativos; otros detallan ejemplos famosos (y no tan famosos) acerca de proyectos que han fracasado.
• Estudio de casos: al final de cada capítulo se incluyen casos con ejemplos específicos acerca del contenido
tratado. La mayoría de los casos se basan en situaciones reales e incluyen preguntas para discusión que
pueden utilizarse para realizar tareas o para facilitar los debates en clase.
• Ejercicios de proyecto integrado: muchos de los capítulos presentan, al final, la posibilidad de desarrollar el
plan detallado de un proyecto. Esto incluye el alcance, la programación, la evaluación de riesgos, la
presupuestación y la estimación de costos.
• Integración con el PMBOK: como medio para demostrar la cobertura de los elementos críticos del PMBOK,
los lectores encontrarán que en los capítulos se identifican y referencian las áreas de conocimiento
correspondientes del PMBOK. Del mismo modo, todos los términos (incluidos en el glosario) se toman
directamente de la edición más reciente del PMBOK.
• Preguntas de ejemplo del examen de certificación PMP: la certificación Project Management Professional
(PMP) representa el más alto nivel de cualificación profesional de un gerente de proyectos en ejercicio, que
administra el Project Management Institute (PMI). Por ello, este libro incluye una serie de preguntas del
examen de certificación PMP al final de la mayoría de los capítulos, con el fin de darles a los lectores una idea
de los tipos de preguntas que normalmente se formulan en el examen y cómo se tratan estos temas.
• Ejercicios con MS Project: al final de cada capítulo se incluyen ejemplos de
problemas o actividades para generar archivos MS Project, a fin de que los estudiantes
adquieran habilidades para interactuar con este aplicativo. ISBN 978-958-699-297-8
• Micrositio: estudiantes y docentes cuentan con recursos complementarios en
www.pearsonenespañol.com/pinto, con el propósito de apoyar el proceso de
enseñanza aprendizaje.

Visítenos en:
www.pearsonenespañol.com

También podría gustarte