Español Proyect Management For Engineering, Bussiness and Technology 5th Edition

Machine Translated by Google
Gestión de Proyectos para Ingeniería,

Negocios y Tecnología
QUINTA EDICIÓN
Gestión de proyectos para ingeniería, negocios y tecnología, quinta edición, aborda la gestión
de proyectos en todas las industrias. Cubriendo primero los antecedentes esenciales, desde los
orígenes y la filosofía hasta la metodología, la mayor parte del libro está dedicada a conceptos
y técnicas para su aplicación práctica. La cobertura incluye el inicio y las propuestas de
proyectos, el alcance y la definición de tareas, la programación, la elaboración de presupuestos,
el análisis de riesgos, el control, la selección de proyectos y la gestión de carteras, la gestión de
programas, la organización de proyectos y todos los aspectos importantes de la "gente":
liderazgo de proyectos, formación de equipos, resolución de conflictos. y manejo del estrés.
El Ciclo de desarrollo de sistemas se utiliza como marco para discutir la gestión de proyectos
en una variedad de situaciones, lo que lo convierte en el libro de referencia para gestionar
prácticamente cualquier tipo de proyecto, programa o grupo de trabajo. Los autores se centran
en el propósito final de la gestión de proyectos: unificar e integrar los intereses, los recursos y
los esfuerzos de trabajo de muchas partes interesadas, así como la planificación, la programación
y el presupuesto necesarios para lograr los objetivos generales del proyecto.
Esta nueva edición incluye:
• Actualizaciones para cubrir los últimos desarrollos en el proyecto

metodologías de gestión
• Nuevos ejemplos y 18 nuevos estudios de casos para ayudar a los estudiantes a
desarrollar su comprensión y poner en práctica los principios • Un nuevo capítulo sobre
gestión ágil de proyectos y lean • Cobertura ampliada de gestión de programas,
participación de partes interesadas, gestión de búfer y gestión de equipos virtuales y
diferencias culturales en proyectos internacionales. • Alineación con los términos y
definiciones del PMBOK para facilitar su uso junto con
certificaciones PMI
• Referencia cruzada a las metodologías IPMA, APM y PRINCE2 •

Amplios materiales de apoyo para el instructor, incluido un Manual del instructor,
diapositivas de PowerPoint, respuestas a preguntas de revisión de capítulos,
problemas y casos, y un banco de preguntas de prueba.
Con un enfoque técnico pero accesible, Project Management for Business, Engineering and
Technology, 5.ª edición, es un recurso ideal y una referencia para todos los estudiantes
avanzados de pregrado y posgrado en cursos de gestión de proyectos, así como para los
directores de proyectos en ejercicio en todos los sectores de la industria.
John Nicholas, PhD, es profesor de Gestión de Operaciones en la Universidad de Loyola,

Chicago, EE. UU.
Herman Steyn, PhD, es profesor en la Graduate School of Technology Management de la

Universidad de Pretoria, Sudáfrica, donde se especializa en gestión de proyectos.
“Como profesor que ha enseñado Ingeniería de Proyectos durante los últimos 14 años, también he realizado
Ingeniería de Proyectos a gran escala a lo largo de mi primera carrera (más de 20 años) en Aeroespacial, Defensa
y Tecnología de la Información. Cuando me decidí por un libro de texto para mi clase de ingeniería de proyectos
de posgrado, miré detenidamente. No encontraba lo que buscaba e iba a escribir el mío propio, hasta que encontré
Gestión de Proyectos para Ingeniería, Negocios y Tecnología. Este es el libro de texto que habría escrito. Es robusto,
completo y fácil de seguir. Los gráficos, cuadros y figuras son todos muy descriptivos y reales. Y a mis alumnos les
gusta la naturaleza de bolsillo del libro. Recomiendo encarecidamente este libro de texto a cualquier persona que
enseñe Ingeniería, Gestión de Proyectos de Negocios o Tecnología/Ingeniería. También lo recomiendo como 'guardián'
para los estudiantes que guiarán proyectos en el futuro.”
Mark Calabrese, Universidad de Florida Central, EE. UU.
“La publicación de 5 John el edición de Gestión de Proyectos de Ingeniería, Negocios y Tecnología por
Nicholas y Herman Steyn es un hito importante en una conversación continua entre los autores y los profesionales
actuales y futuros de la gestión de proyectos en todo el mundo. Este libro ha sido durante mucho tiempo una publicación
completa pero accesible que brinda información valiosa sobre la gestión estratégica y cotidiana de proyectos tanto
grandes como pequeños. Existen numerosas publicaciones en este campo, pero Nicholas y Steyn han encontrado el
equilibrio entre las necesidades de los profesionales experimentados que buscan formas de mejorar los resultados de
los proyectos y las necesidades de los estudiantes que son nuevos en el campo de la gestión de proyectos. Los
conceptos están presentados de manera clara y lógica, y el lenguaje es apropiado para una amplia gama de audiencias.
Continúa siendo un punto de referencia en un abarrotado campo de publicaciones que ofrece conocimientos tanto
prácticos como estratégicos sobre el arte y el oficio de la gestión de proyectos”.
Barrie Todhunter, Universidad del Sur de Queensland, Australia
“He estado usando las ediciones anteriores de este libro en mi enseñanza de Gestión de Proyectos a ejecutivos
en activo de una importante empresa de ingeniería que emplea a cerca de 40000 personas en varios tipos de proyectos.
He evaluado la quinta edición actual del libro desde la perspectiva de (a) un recurso didáctico (b) material de estudio
y (c) como un recurso para estudios de casos y referencias. Encuentro que la quinta edición ha sido completamente
renovada e incorpora varios recursos relevantes y se presenta de una manera muy lúcida y estructurada. No dudo
en absoluto en recomendar este libro como un recurso estándar para enseñar a estudiantes en una universidad y/o
para ejecutivos que trabajan en un entorno de proyecto. El libro también es un buen recurso como material de estudio
para los cursos de certificación”.
Krishna Moorthy, exdecano, Larsen & Toubro Institute of Project Management, India
“Project Management for Engineering, Business and Technology es uno de los libros de texto más completos en
el campo. Nicholas y Steyn explican el asunto de forma amena y fácil de entender, ilustrado con interesantes ejemplos.
Los autores combinan el "asunto difícil" de la gestión de proyectos con aspectos conductuales relevantes. En general,
un trabajo útil para cualquier persona nueva en el campo o como referencia para el administrador de proyectos más
avanzado”.
Martijn Leijten, Universidad Tecnológica de Delft, Países Bajos
“La gestión de proyectos juega un papel vital en el logro de los objetivos del proyecto. Los proyectos traen cambios y la
gestión de proyectos se reconoce como la forma más eficaz de gestionar dicho cambio. Este libro alienta a los lectores
a interesarse e involucrarse en el cambio hacia una gestión de proyectos y una gestión de proyectos renovadas”.
Benita Zulch, Universidad del Estado Libre, Sudáfrica
“Un texto muy completo. Una excelente combinación de materiales para que los estudiantes aprendan técnicas y participen en
la discusión de escenarios”.
Richard Kamm, Universidad de Bath, Reino Unido

Gestión de Proyectos para Ingeniería,

Negocios y Tecnología
QUINTA EDICIÓN
Universidad John
M. Nicholas Loyola de Chicago
herman steyn
Universidad de Pretoria
Quinta edición publicada en 2017
por Routledge
2 Park Square, Milton Park, Abingdon, Oxón OX14 4RN
y por Routledge
711 Tercera Avenida, Nueva York, NY 10017
Routledge es una huella de Taylor & Francis Group, una empresa de información
© 2017 John Nicholas y Herman Steyn
El derecho de John Nicholas y Herman Steyn a ser identificados como autores de este trabajo ha sido afirmado por ellos de conformidad
con las secciones 77 y 78 de la Ley de derechos de autor, diseños y patentes de 1988.
Reservados todos los derechos. Ninguna parte de este libro puede ser reimpresa, reproducida o utilizada de ninguna forma o por ningún
medio electrónico, mecánico o de otro tipo, ahora conocido o inventado en el futuro, incluidas las fotocopias y grabaciones, o en cualquier
sistema de almacenamiento o recuperación de información, sin permiso por escrito. desde el
editores
Aviso de marca comercial: los nombres de productos o empresas pueden ser marcas comerciales o marcas comerciales registradas, y se utilizan
solo para identificación y explicación sin intención de infringir.
Cuarta edición publicada por Routledge 2012 Tercera
edición publicada por Elsevier Inc. 2008
Catalogación de la Biblioteca Británica en datos de publicación
Un registro de catálogo para este libro está disponible en la Biblioteca Británica.
Catalogación de la Biblioteca del Congreso en datos de publicación
Se ha solicitado un registro de catálogo para este libro.
ISBN: 978-1-138-93735-2 (hbk)
ISBN: 978-1-138-93734-5 (pbk)
ISBN: 978-1-315-67631-9 (ebk)
Compuesto en Joanna por Servis Filmsetting Ltd, Stockport, Cheshire
Visite el sitio web complementario: www.routledge.com/cw/nicholas

A Sharry, Julia, Joshua y Abigail

JMN
A Karen y Janine
HS
Contenidos breves
Introducción
PARTE I: FILOSOFÍA Y CONCEPTOS
1 ¿Qué es la gestión de proyectos?

2 Enfoque de Sistemas
PARTE II: CICLO DE VIDA DEL PROYECTO
3 Ciclo de vida del proyecto y concepción del proyecto

4 Definición del Proyecto y Definición del Sistema
PARTE III: SISTEMAS Y PROCEDIMIENTOS DE PLANIFICACIÓN Y CONTROL
5 técnicas básicas de planificación de proyectos

6 Planificación del cronograma del proyecto y redes
7 Programación y análisis de redes de proyectos avanzados
8 Estimación de costos y elaboración de presupuestos
9 Gestión de la calidad del proyecto

10 Gestión de riesgos del proyecto
11 Ejecución, Seguimiento y Control de Proyectos
12 Evaluación, Comunicación, Implementación y Cierre del Proyecto
13 Gestión Ágil de Proyectos y Lean
PARTE IV: COMPORTAMIENTO DE LA ORGANIZACIÓN
14 Estructura e integración de la organización del proyecto

15 Roles del proyecto y partes interesadas
16 Gestión de la participación, el trabajo en equipo y el conflicto
PARTE V: GESTIÓN DE PROYECTOS EN EL CONTEXTO CORPORATIVO
17 Meta-Gestión de Proyectos y Gestión de Programas

18 Selección de Proyectos y Gestión de Cartera

19 Gestión de Proyectos Internacionales
Apéndice A: RFP para Midwest Parcel Distribution Company

Apéndice B: Propuesta de Proyecto de Sistema Logístico en Línea (LOGON)
Apéndice C: Plan de evaluación del proyecto para el sistema logístico en línea
Índice
Contenido
Cubrir
Título
Derechos de autor
Dedicación
Contenidos breves
Contenido
Prefacio
Agradecimientos
Sobre los autores
Introducción
I.1 En el Principio…
I.2 ¿Qué es un proyecto?
I.3 No todos los proyectos son iguales I.4
Gestión de proyectos: la necesidad I.5 Meta
del proyecto: tiempo, costo y rendimiento I.6 Gestión de
proyectos: la persona, el equipo, la metodología I.7 Normas de gestión de proyectos
Conocimientos y competencias I.8 Acerca de este libro I.9 Proyecto de estudio
Apéndice: Relación entre los estándares profesionales y los capítulos de este libro
Preguntas de repaso Caso I.1 El aeropuerto de Denver Preguntas sobre el caso
Notas finales
PARTE I: FILOSOFÍA Y CONCEPTOS
1.1 Funciones de la Gerencia 1.2

Características de la Gerencia de
Proyectos 1.3 Evolución de la Gerencia de
Proyectos 1.4 ¿Dónde es Apropiada la Gerencia de Proyectos?
1.5 Gestión por proyecto: un enfoque común 1.6 Diferentes
formas de gestión relacionada con proyectos 1.7 Entornos
de proyectos 1.8 Proyectos de desarrollo de nuevos
productos y sistemas 1.9 Proyectos de construcción 1.10
Proyectos del sector de servicios 1.11 Proyectos y programas
gubernamentales y del sector público 1.12 Proyectos varios
1.13 Resumen de preguntas de revisión Preguntas sobre el caso
del proyecto de estudio 1.1 Recuperación de desastres en el
caso de Marshall Field 1.2 Implementación del sistema de
beneficios flexibles en el Centro Médico Shah Alam Notas finales
2.1 Sistemas y pensamiento sistémico

2.2 Conceptos y principios sistémicos 2.3
Enfoque sistémico 2.4 Ingeniería de
sistemas 2.5 Gestión de proyectos: un
enfoque sistémico 2.6 Resumen
Preguntas de revisión
Preguntas sobre el caso del proyecto de
estudio 2.1 Caso del distrito sanitario del condado de
Glades 2.2 Caso del proyecto de desarrollo de vida y muerte de una
aeronave 2.3 Caso del proyecto de extensión de la línea Jubilee 2.4
Proyecto del sistema de operaciones de tráfico y coordinación de señales
del condado de Santa Clara Notas finales
PARTE II: CICLO DE VIDA DEL PROYECTO
3.1 Ciclo de vida del

proyecto 3.2 Ciclo de desarrollo de
sistemas 3.3 Fase A: Concepción 3.4
Viabilidad del proyecto 3.5 La propuesta
del proyecto 3.6 Contratación del proyecto
3.7 Resumen Apéndice: Tipos de contratos
Preguntas de revisión Preguntas sobre el
estudio Caso del proyecto 3.1 Caso del
Centro Médico de la Universidad de la
Costa Oeste 3.2 Datos de X-Philes Management
Corporation: RFP Matters Caso 3.3 Evaluación de la propuesta
para la nave espacial Apolo Caso 3.4 Desorden del contrato en Polanski
Developers Notas finales
4.1 Fase B: Definición
4.2 Definición del Proyecto

4.3 Planificación del proyecto por fases (onda rodante)

4.4 Definición del sistema 4.5 Resumen Apéndice A:
Etapas de la ingeniería de sistemas Apéndice B:
Despliegue de la función de calidad Preguntas de
revisión Preguntas sobre el caso del proyecto de
estudio 4.1 Construcción de Star-Board y Santaro
Associates: Requisitos Snafu Caso 4.2

Revcon Products y Welbar, Inc.: Cliente–Contratista Comunicación
Caso 4.3 Lavasoft.com: Interpretación de los requisitos del cliente
Caso 4.4 Mina de oro propuesta en Canadá: Planificación de proyecto

por etapas Notas finales
PARTE III: SISTEMAS Y PROCEDIMIENTOS PARA LA PLANIFICACIÓN Y

CONTROL
5.1 Pasos de
planificación 5.2 El plan de ejecución
del proyecto 5.3 Alcance y declaración
del trabajo 5.4 Definición del trabajo
5.5 Organización y responsabilidades del proyecto 5.6

Programación 5.7 Gráficos de planificación y
programación 5.8 Línea de equilibrio (Método de
programación lineal)
5.9 Gestión de adquisiciones 5.10
Resumen de preguntas de revisión
Preguntas sobre el caso del proyecto
de estudio 5.1 Empresa constructora de
presas: Sean's WBS
Caso 5.2 Startrek Enterprises, Inc.: Plan de proyecto de Deva

Caso 5.3 Plan de proyecto de Walter Caso 5.4 Planificación
de la implementación de Boca en Kulczyÿski Productos Notas
finales
6.1 Diagramas de red 6.2

La ruta crítica
6.3 Conversión a cronogramas de calendario de
Gantt 6.4 Reserva de cronograma de administración
6.5 Relaciones alternativas 6.6 Programación con
restricciones de recursos 6.7 Críticas a los métodos
de red
6.8 Resumen
Apéndice A: Diagramas AOA
Apéndice B: Método de programación alternativo: el proyecto
comienza en el día 1 Preguntas y problemas de revisión
Preguntas sobre el caso del proyecto de estudio 6.1 Diagrama
de red para un caso de proyecto de construcción grande 6.2
Melbourne Construction Company, un caso 6.3 Melbourne
Construction Company, B Caso 6.4 Melbourne Construction
Company, C Notas finales
7.1 CPM y compensación de tiempo-

costo 7.2 Variabilidad de la duración de
la actividad 7.3 PERT 7.4 Asignación de
recursos y programación de múltiples proyectos
7.5 Teoría de restricciones y método de cadena crítica 7.6 Método TOC para
asignar recursos a múltiples proyectos 7.7 Discusión y resumen Lista resumida de
símbolos Preguntas y problemas de revisión Preguntas sobre el caso del proyecto de
estudio 7.1 Caso de Bridgecon Contractors 7.2 Caso del proyecto LOGON 7.3 Notas
finales del proyecto Papua Petera Village
8.1 Estimaciones de costos
8.2 Aumento de costos
8.3 Estimación de costos y el ciclo de desarrollo de sistemas 8.4 Proceso de estimación
de costos 8.5 Elementos de estimaciones y presupuestos 8.6 Sistemas de contabilidad
de costos de proyectos 8.7 Elaboración de presupuestos utilizando cuentas de control
(o de costos) 8.8 Resúmenes de costos 8.9 Cronogramas y pronósticos de costos
8.10 Costos del ciclo de vida
8.11 Resumen de preguntas y
problemas de revisión Preguntas sobre el caso
del proyecto de estudio 8.1 Costos del ciclo de vida
para el caso de la flota de naves espaciales turísticas 8.2 Costos estimados para el
caso del proyecto Chunnel 8.3 Estimación de Fiona para el caso del proyecto Gorgy
8.4 Melbourne Construction Company, D Notas finales

9.1 El concepto de calidad 9.2

Procesos de gestión de calidad del proyecto 9.3 Técnicas
para el aseguramiento de la calidad en el desarrollo de sistemas 9.4
Técnicas para el control de calidad 9.5 Resumen de preguntas de revisión
Preguntas sobre el caso del proyecto de estudio 9.1 Colapso del panel del
techo en el caso del proyecto Big Dig 9.2 FIFA 2010 World Cup South
Africa Caso 9.3 Notas finales sobre la adversidad de las bolsas de aire
10.1 Conceptos de
riesgo 10.2 Identificación de riesgos
10.3 Evaluación de riesgos
10.4 Planificación de la respuesta a

los riesgos 10.5 Supervisión y respuesta a los
riesgos 10.6 La gestión de proyectos es gestión de riesgos
10.7 Apéndice resumido: Métodos de análisis de riesgos
Preguntas y problemas de revisión Preguntas sobre el caso
del proyecto de estudio 10.1 El caso de la Ópera de Sídney
10.2 Infinity & Beyond, Inc.
Caso 10.3 El puente Nelson Mandela Notas finales
11.1 Fase C: Ejecución

11.2 Etapa de diseño

detallado 11.3 Etapa de
producción/construcción 11.4 Proceso
de seguimiento y control 11.5 Paquetes de
trabajo y cuentas de control 11.6 Énfasis en el
control y seguimiento del proyecto 11.7 Análisis de rendimiento
y gestión del valor ganado 11.8 Gestión de problemas 11.9
Control de cambios 11.10 Administración de contratos 11.11
Problemas con el seguimiento y control de proyectos 11.12
Resumen Resumen de variables Preguntas y problemas de
revisión Preguntas sobre el estudio Caso del proyecto 11.1
Caso del proyecto Cybersonic 11.2 Mina de oro SA: valor
ganado después de un cambio de alcance Caso 11.3 Proceso
de control de cambios en la empresa Dynacom Notas finales
12.1 Evaluación del

proyecto 12.2 Gestión de la comunicación del
proyecto 12.3 Sistemas de información de gestión
del proyecto 12.4 Comunicación informal 12.5 Etapa
de implementación 12.6 Terminación y cierre del
proyecto 12.7 Evaluación del resumen del proyecto
12.8 Después del proyecto—Fase D: Operación 12.9
Resumen
Preguntas sobre el caso del proyecto de estudio
12.1 Informe de estado del caso del proyecto LOGON 12.2 Caso
del edificio central de información de SLU 12.3 Comunicación

formal e informal
Notas finales
13.1 Gestión tradicional de proyectos 13.2 Gestión
ágil de proyectos, APM 13.3 Scrum
13.4 Controversia de APM 13.5
Producción ajustada y gestión de proyectos 13.6 Resumen de
preguntas de revisión Preguntas sobre el caso del proyecto de

estudio 13.1 Gran entrada para Accent, Inc.
Caso 13.2 Tecnología para rastrear vehículos robados Notas

finales
PARTE IV: COMPORTAMIENTO DE LA ORGANIZACIÓN
14.1 Estructura organizativa formal 14.2 Diseño
organizativo por diferenciación e integración 14.3 Requisitos de las
organizaciones de proyectos 14.4 Integración de las subunidades en los
proyectos 14.5 Funciones de enlace, grupos de trabajo y equipos 14.6
Impulsores y coordinadores de proyectos 14.7 Organizaciones puras de

proyectos 14.8 Organizaciones matriciales 14.9 Selección de una forma de
organización para proyectos

14.10 Oficina de proyectos y PMO

14.11 Integración en proyectos a gran escala
14.12 Integración en proyectos de desarrollo de sistemas 14.13
Ingeniería concurrente 14.14 Resumen de preguntas de revisión
Preguntas sobre el caso del proyecto de estudio 14.1
Organización para el caso del proyecto LOGON 14.2 Cámara
estenopeica y óptica, Inc.: por qué ¿Necesita un Gerente de
Proyecto?
Caso 14.3 Implementación de una estructura matricial en un

laboratorio de I+D Notas finales
15.1 El director del proyecto

15.2 Autoridad de gestión del proyecto 15.3
Cualificaciones del director del proyecto 15.4
Cumplimiento de la función de gestión del proyecto
15.5 Funciones en el equipo del proyecto 15.6
Funciones fuera del equipo del proyecto 15.7
Participación de las partes interesadas del proyecto
15.8 Resumen de las preguntas de revisión
Preguntas sobre el caso del proyecto de estudio
15.1 El caso del proyecto LOGON 15.2 Selección
de un gerente de proyecto en Nuwave Products
Company Caso 15.3 Partes interesadas en Big Dig de Boston Notas
finales
16.1 Liderazgo en Gestión de Proyectos

16.2 Gestión participativa 16.3

Equipos en la gestión de proyectos 16.4
El enfoque de creación de equipos 16.5
Mejora de los equipos de trabajo en curso
16.6 Creación de nuevos equipos 16.7
Resolución de problemas intergrupales 16.8
Equipos virtuales 16.9 Conflicto
16.10 Manejo de conflictos grupales

16.11 Manejo del estrés emocional
16.12 Resumen de preguntas de
revisión Preguntas sobre el caso del
proyecto de estudio 16.1 Caso de Wilma
Keith 16.2 Mars Climate Orbiter Spacecraft
Notas finales
PARTE V: GESTIÓN DE PROYECTOS EN EL CORPORATIVO

CONTEXTO
17.1 Madurez de la gestión de proyectos y modelos de madurez
17.2 Metodología de gestión de proyectos 17.3

Gestión del conocimiento del proyecto 17.4
Oficina de gestión de proyectos 17.5 Gestión
del programa 17.6 Fases del programa 17.7
Temas de gestión del programa 17.8
Organización del programa 17.9 Consideraciones
especiales 17.10 Resumen de preguntas de
revisión Preguntas sobre el proyecto de estudio
Caso 17.1 Maxim Corporation América (MCA)

Caso 17.2 Metodología M-Gate de Motorola y el proyecto RAZR Caso 17.3
Tecknokrat Company Caso 17.4 Programa de exploración de mercurio
Notas finales
18.1 Gestión de la cartera de proyectos 18.2

Marco para la selección y gestión de la cartera de proyectos 18.3 Métodos
para evaluar proyectos individuales 18.4 Métodos para comparar y

seleccionar proyectos 18.5 Integración del proceso de selección y la
gestión de la cartera 18.6 Resumen y discusión Preguntas y problemas de
revisión Pregunta sobre el caso del proyecto de estudio 18.1 Energía
consolidada Empresa Caso 18.2 Fábrica de cemento propuesta para PCS
Empresa Notas finales
19.1 Proyectos internacionales
19.2 Problemas en la gestión de proyectos internacionales 19.3

Instituciones locales y cultura
19.4 Partes interesadas locales
19.5 Cuestiones geonacionales
19.6 Gerente de Proyecto

19.7 Representante Local 19.8
Alta Gerencia, Comité Directivo y PMO 19.9 Construcción de Equipos y
Relaciones 19.10 Definición del Proyecto
19.11 Seguimiento del

proyecto 19.12 Comunicación
19.13 Riesgos y contingencias

19.14 Resumen de preguntas de
revisión Preguntas sobre el caso
del proyecto de estudio 19.1 Proyecto
Mozal: caso de inversión internacional en un país subdesarrollado
19.2 Notas finales de la oficina de Puerto Rico de Spirit Electronics
APÉNDICE A RFP para Midwest Parcel Distribution Company

APÉNDICE B Propuesta de Proyecto de Sistema Logístico en Línea (LOGON)
ANEXO C Plan de Ejecución del Proyecto Sistema Logístico en Línea
Índice
Prefacio
Cuando las personas ven o usan algo impresionante: un puente que se arquea alto
sobre un cañón, una sonda espacial aterrizando en un planeta distante, un juego
animado tan realista que crees que estás allí, o un teléfono/cámara/computadora
ingeniosos del tamaño de tu mano, a veces se preguntan: "¿Cómo hicieron eso?" Por
ellos, por supuesto, se refieren a los creadores, diseñadores y constructores, las
personas que crearon —pensaron e hicieron— esas cosas. Rara vez se preguntan
acerca de los líderes y gerentes, las personas que organizaron y dirigieron los
esfuerzos que llevaron esas cosas asombrosas del concepto a la realidad y sin quienes
las ideas más ingeniosas nunca se habrían logrado. Este libro trata sobre ellos: los
gerentes de los gerentes de proyectos, los héroes en su mayoría anónimos de la
ingeniería, los negocios y la tecnología que están fuera del ojo público pero que, en
última instancia, son responsables de prácticamente todo lo que requiere un esfuerzo humano colect
El gerente de proyecto es solo una de las muchas personas involucradas en la
creación de productos, sistemas y artefactos de la sociedad, pero es él o ella quien
involucra a los demás y organiza y dirige sus esfuerzos para que todo salga bien.
Ocasionalmente, el gerente y el creador son los mismos: Burt Rutan, Woody Allen y
Gutzon Borglum son ejemplos; el trabajo de su vida, en aeroespacial, películas y
esculturas monumentales, respectivamente, representa no solo el genio creativo o
tecnológico, sino también el liderazgo y el talento gerencial.
En las últimas décadas, las empresas se han expandido de empresas y mercados
nacionales y nacionalistas a empresas y mercados multinacionales y globales. Como
resultado, desde una perspectiva comercial, hay más de todo con lo que lidiar: más
ideas, competidores, recursos, restricciones y, ciertamente, más personas que hacen
y quieren cosas. La tecnología avanza y los productos y procesos evolucionan a un
ritmo más rápido; como resultado, los ciclos de vida de la mayoría de las cosas en la
sociedad se están acortando. Este “más de todo” ha tenido un impacto directo en la
realización de proyectos, incluidos proyectos para desarrollar productos,
sistemas o procesos que compiten en los mercados locales, nacionales e internacionales;

proyectos para crear e implementar nuevas formas de satisfacer la demanda de energía,
recreación, vivienda, comunicación, transporte y alimentación; y proyectos para responder
preguntas básicas de la ciencia y resolver problemas graves como enfermedades,
contaminación, calentamiento global y las consecuencias de los desastres naturales. Toda
esta actividad de proyectos ha estimulado un interés creciente en mejores formas de
planificar, organizar y guiar proyectos para satisfacer mejor las necesidades de los clientes,
los mercados y la sociedad dentro de los límites de tiempo y recursos limitados.
Asociado con este interés está la creciente necesidad de educar y capacitar a los
gerentes de proyecto. En el pasado, y todavía hoy, los gerentes de proyecto fueron elegidos
por alguna capacidad excepcional demostrada, aunque no necesariamente gerencial. Si
usted fuera un buen ingeniero, analista de sistemas, investigador, arquitecto o contador,
eventualmente se convertiría en gerente de proyectos. En algún momento del camino,
presumiblemente, adquirirías las "otras" habilidades necesarias. La falla en este
razonamiento es que la gestión de proyectos abarca una amplia gama de habilidades
(administrativas, de liderazgo, interpersonales) que son muy diferentes e independientes
de las habilidades asociadas con la competencia técnica. Y no hay razón para suponer que
el entorno del proyecto por sí solo brindará la oportunidad para que alguien "aprenda" estas
otras habilidades necesarias.
Como texto y manual, este libro trata sobre la forma "correcta" de gestionar proyectos.
Está destinado a estudiantes universitarios avanzados de pregrado y posgrado y gerentes
en ejercicio en ingeniería, negocios y tecnología. Como dice el título, es un libro sobre
principios y práctica, lo que significa que los temas que contiene son prácticos y están
destinados a ser aplicados. Cubre el panorama general de la gestión de proyectos:
orígenes, aplicaciones y filosofía, así como los pasos básicos y prácticos. Describe los
temas habituales de gestión de proyectos de cronogramas, presupuestos y controles, pero
también el lado humano de la gestión de proyectos, incluidos el liderazgo y los conflictos.
¿Por qué un libro sobre gestión de proyectos en ingeniería y negocios y tecnología? En

nuestra experiencia, los especialistas en tecnología como ingenieros, programadores,
químicos,
arquitectos, involucrados en “proyectos y así
de ingeniería/tecnología” a en,
menudoninguna
tienen poca o
capacitación en gestión o liderazgo. Este libro, que incluye muchos ejemplos de ingeniería
y tecnología, proporciona una exposición bastante amplia de los conceptos y
especificaciones de gestión para ayudar a estos especialistas a comenzar como gerentes y líderes.
¿Qué pasa con aquellas personas involucradas en el desarrollo de productos, marketing, mejora
de procesos y proyectos relacionados comúnmente considerados como "proyectos comerciales"?
Así como los especialistas en tecnología rara vez reciben capacitación administrativa formal, los
estudiantes y los profesionales de los negocios rara vez obtienen una exposición formal a las
prácticas comunes en los proyectos tecnológicos. Para ellos, este libro describe no solo cómo se
llevan a cabo los proyectos de “negocios”, sino también los pasos necesarios en la concepción y
ejecución de proyectos de ingeniería, desarrollo de sistemas, construcción y otros proyectos de
“tecnología”. Por supuesto, cada proyecto de tecnología es también un proyecto comercial: se lleva
a cabo en un contexto comercial e involucra cuestiones comerciales como la satisfacción del
cliente, la utilización de recursos, los plazos, los costos y las ganancias.
Prácticamente todos los proyectos (ingeniería, tecnología y negocios) se originan y se llevan a
cabo de manera similar, conceptualizados en este libro usando una metodología llamada Ciclo de
Desarrollo de Sistemas (SDC). El SDC sirve como un marco general para discutir los principios y
prácticas de la gestión de proyectos e ilustrar los puntos en común y las diferencias entre una
amplia variedad de proyectos.
Este libro es el resultado de varias décadas combinadas de experiencia de los autores en la
enseñanza de gestión de proyectos en la Universidad Loyola de Chicago y la Universidad de
Pretoria a estudiantes de negocios e ingeniería, precedido por varios años de experiencia en
proyectos de negocios y tecnología, incluido el diseño de aeronaves y pruebas de vuelo. ,
construcción de instalaciones de proceso a gran escala y desarrollo de aplicaciones de software y
mejora de procesos. Esta experiencia práctica nos dio una apreciación no solo del lado de la
gestión empresarial de la gestión de proyectos, sino también del lado humano-interpersonal. Hemos
visto los beneficios de la buena comunicación, la confianza y el trabajo en equipo, así como los
costos del liderazgo deficiente, el estrés emocional y los conflictos grupales. Según nuestra
experiencia, los proyectos más exitosos son aquellos en los que florecieron el liderazgo, la
confianza, la comunicación y el trabajo en equipo, independientemente de los métodos y sistemas
formales de planificación y control existentes. Este libro refleja en gran medida estas experiencias
personales. Por supuesto, la cobertura integral de la gestión de proyectos requería que miráramos
mucho más allá de nuestra propia experiencia y recurriéramos a los trabajos publicados de muchos
otros y la sabiduría y sugerencias de colegas y revisores.
En esta quinta edición hemos revisado y añadido material para incorporar nuevos
temas de interés, ejemplos actuales y el creciente cuerpo de literatura en gestión de

proyectos. Entre las nuevas incorporaciones importantes se encuentran un capítulo sobre
gestión ágil de proyectos y producción ajustada, una cobertura ampliada de la gestión de
programas, así como 18 nuevos estudios de casos al final del capítulo. La Introducción
incluye tablas que relacionan secciones del libro con las áreas de conocimiento y
metodologías de gestión de proyectos más comunes: PMI PMBOK, IPMA, APM y PRINCE2.
Los libros tienden a crecer en tamaño con cada nueva edición; para combatir que todos los
capítulos han sido reescritos para que todo sea más legible y conciso. A pesar de la inclusión
de material nuevo, hemos mantenido el recuento de páginas en aproximadamente lo que
era en la edición anterior.
Nuestro objetivo al escribir este libro es proporcionar a los estudiantes y gerentes en
ejercicio el texto más práctico, actual e interesante posible. Agradecemos escuchar sus
comentarios y sugerencias. Envíenoslos a jnichol@luc.edu y herman.steyn@up.ac.za.
Expresiones de gratitud
Como la mayoría de los proyectos, escribir un libro refleja las contribuciones de muchas personas.
Queremos reconocer y agradecer especialmente a quienes contribuyeron más.
En primer lugar, gracias a nuestros asistentes de investigación. Los asistentes de investigación en general
hacen mucho trabajo, tanto académico como de recadero, y sin sus arduos esfuerzos, la mayoría de los
profesores lograrían mucho menos. Tuvimos la suerte de contar con la ayuda de varias personas tan
brillantes y capaces, en particular Elisa Denney, Hollyce James, Diane Petrozzo, Miguel Velasco, Gaurav
Monga, Cary Morgan, Louis Schwartzman y Brian Whelan.
Un agradecimiento especial a los colegas actuales y anteriores de la Universidad Loyola de Chicago y

la Universidad de Pretoria. En Chicago, gracias al Dr. Gezinus Hidding por su entusiasmo y contribuciones
al campo de la gestión de proyectos; ya los Dres.
Enrique Venta, Harold Dyck, Samuel Ramenofsky y Donald Meyer, y Elaine Strnad, Paul Flugel, John
Edison, Sharon Tylus y Debbie Gillespie por sus sugerencias y apoyo para esta edición y las anteriores. En
Pretoria, gracias al Dr.
Tinus Pretorius por alentar la educación y la investigación en gestión de proyectos en la Graduate School
of Technology Management y por apoyar el trabajo en este libro. Yo (Herman) también quiero expresar mi
agradecimiento al Dr. Giel Bekker, Philip Viljoen, la Dra. Taryn Bond-Barnard, el Dr. Pieter Pretorius, el Dr.
Krige Visser, Corro van Waveren, el Dr. Michael Carruthers y la Dra. Marie-Louise Barry. por sus
contribuciones directas e indirectas a este libro y por todo lo que he aprendido de ellos. Yo (John) quiero
reconocer la influencia de tres de mis profesores, el Dr. Charles Thompson y el Dr. Gustave Rath de la
Universidad Northwestern, y el Dr. Dick Evans de la Universidad de Illinois, cuyas filosofías y enseñanzas
ayudaron a dar forma a este libro. También quiero agradecer a Chris Phares y Bob Zimmerman, queridos
amigos y directores de proyectos extraordinarios, por compartir continuamente su sabiduría sobre el
significado y la importancia del liderazgo de proyectos.
Un agradecimiento especial también a nuestras esposas Sharry y Karen. Sharry proporcionó numerosos
sugerencias a la primera edición y ayudó a reducir la cantidad de "jerga técnica" en el

libro; ella manejó el frente interno y liberó tiempo para que yo (John) pudiera seguir y
completar este proyecto. Karen brindó apoyo y aliento como esposa; como en el caso
de tantos otros proyectos en los que yo (Herman) he estado involucrado, mi contribución
a este proyecto nunca se habría materializado si no hubiera sido por su apoyo.
Gracias también a Amy Laurens y la gente de Routledge y Taylor and Francis, y un

agradecimiento especial a Holly Davis por su continuo apoyo durante la preparación de
esta quinta edición.
Otros colegas, estudiantes y amigos, algunos mencionados en las notas finales a lo
largo del libro, brindaron apoyo, aliento y materiales de referencia; a ellos también les
decimos gracias. A pesar de la asistencia de tantas personas y de nuestros mejores
esfuerzos, todavía es probable que haya omisiones o errores. Tuvimos la última palabra
y aceptamos la responsabilidad por ellos.
Juan M. Nicolás
herman steyn
Sobre los autores
JOHN NICHOLAS es Profesor de Gestión de Operaciones y Gestión de Proyectos

en la Escuela de Negocios Quinlan de la Universidad Loyola de Chicago. Es un
profesor activo, escritor e investigador en gestión de proyectos y gestión de
producción, y realiza seminarios ejecutivos y consultas sobre gestión de proyectos
y mejora de procesos. John es autor de numerosas publicaciones académicas y
técnicas, y de cinco libros, incluidos Lean Production for Competitive Advantage
(2011) y The Portal to Lean Production (2006). Ha ocupado los puestos de líder
de equipo e ingeniero en proyectos de desarrollo de aeronaves en Lockheed-
Martin Corporation, líder de equipo y analista de sistemas comerciales en proyectos
de operaciones en Bank America e investigador en proyectos de investigación de
energía y medioambiente en Argonne National Laboratory. Tiene una licenciatura
en ingeniería aeronáutica y astronáutica y una maestría en investigación de
operaciones de la Universidad de Illinois, Urbana-Champaign, y un doctorado en
ingeniería industrial y ciencias conductuales aplicadas de la Universidad Northwestern.
HERMAN STEYN es profesor de gestión de proyectos en la Graduate School of

Technology Management de la Universidad de Pretoria, Sudáfrica. Ha estado
involucrado en proyectos en la industria desde 1975, ha gestionado una variedad
de proyectos de ingeniería grandes y pequeños (desarrollo de sistemas, productos
y procesos) en las industrias de minerales, defensa y nuclear, y también ha
gestionado programas y carteras de proyectos. En 1996 fue designado para su
puesto actual en la Universidad de Pretoria, donde inició un programa de maestría
en gestión de proyectos. Además de supervisar la investigación en gestión de
proyectos y enseñar cursos de gestión de proyectos de posgrado, Herman ha
realizado más de 200 seminarios y talleres sobre gestión de proyectos. Tiene una
licenciatura y un diploma de posgrado en ingeniería metalúrgica, un MBA y un
doctorado en administración de ingeniería.
Introducción
I.1 En el Principio…
En algún momento durante el tercer milenio antes de Cristo, los trabajadores de la Gran Pirámide de
Keops colocaron la última piedra. Deben haberse sentido jubilosos, porque este evento representó una
especie de hito en una de las empresas más grandiosas de la humanidad.
Aunque gran parte de la tecnología de los antiguos egipcios sigue siendo un misterio, la enormidad y la
calidad del producto final sigue siendo una maravilla. A pesar de la falta de maquinaria sofisticada,
pudieron levantar y colocar unos 2.300.000 bloques de piedra, con un peso de 2 a 70 toneladas cada uno,
en una estructura de la altura de un edificio moderno de 40 pisos. Cada piedra de revestimiento se colocó
contra la siguiente con una precisión de 0,04 pulgadas (1 mm), y la base, que cubre 13 acres (52 600 m2 ),
se desvía menos de 1 pulgada (25 mm) del nivel (Figura I.1).
1
Igualmente asombroso fue el número de trabajadores involucrados. Para extraer las piedras y
transportarlas por el Nilo, se contrataron unos 100.000 trabajadores. Además, se emplearon 40.000
albañiles y asistentes calificados para preparar y colocar los bloques y montar o desmontar las rampas.
Las obras públicas fueron fundamentales para mantener ocupada y alimentada a la población trabajadora,
y se estima que no menos de 150.000 mujeres y niños también tuvieron que ser alojados y alimentados.
2 Pero
igual de alucinante fue la capacidad de gestión ejercida por los egipcios durante los 20 años que duró la
construcción de la pirámide. Francis Barber, un estudioso de las pirámides del siglo XIX, concluyó que:
Debe haber sido necesaria la capacidad organizativa de un genio para planificar todo el trabajo, diseñarlo, prever
emergencias y accidentes, para asegurarse de que los hombres en las canteras, en los botes y trineos, y en los
talleres de albañilería y herrería todos estaban empleados de manera continua y útil, que los medios de transporte
3
eran amplios... que el suministro de agua era amplio... y que los alivios para los enfermos estaban disponibles.
La construcción de la Gran Pirámide es lo que hoy llamaríamos un proyecto a gran escala. Se encuentra
entre numerosos proyectos de la historia temprana registrada que requirieron trabajos humanos masivos
y competencia gerencial. Son dignos de mención los logros gerenciales y de liderazgo de Moisés. El relato
bíblico del éxodo de los hebreos de la esclavitud de los egipcios da alguna perspectiva sobre la preparación,
organización y ejecución de esta tremenda empresa.
Supuestamente Moisés hizo un magnífico trabajo de selección de personal, entrenamiento, 4 El

famoso
organización y delegación de autoridad. “gerente” de gobernante
grandes proyectos.Salomón también
Transformó fue la
las ruinas
maltratadas de muchas ciudades antiguas y barrios marginales toscos en poderosas fortificaciones.
Con su riqueza y la ayuda de los artesanos fenicios, Salomón construyó el Templo de Jerusalén. Se
necesitaron siete años para la construcción del Templo, después de lo cual Salomón tardó 13 años
más en construir un palacio para sí mismo. Empleó una mano de obra de 30.000 israelitas para talar
árboles e importar madera de los bosques del Líbano. 5 Eso fue hace casi 3.000 años.
Figura I.1 La Gran Pirámide de Keops, uno de los primeros (alrededor del 2500 a. C.) proyecto a gran escala.
Foto cortesía de iStock.
Con civilizaciones posteriores, en particular los griegos y los romanos, los proyectos que requieren
se intensificó la planificación y organización extensiva. Para facilitar sus campañas militares

e intereses comerciales, los romanos construyeron redes de carreteras y caminos por toda
Europa, Asia Menor, Palestina y el norte de África para que todos los caminos “condujeran
a Roma”. Las civilizaciones del Renacimiento
Europa y el Medio y Lejano Oriente emprendieron la ingeniería fluvial, la construcción de
acueductos, canales, presas, esclusas e instalaciones portuarias y portuarias. Con la
difusión de las religiones modernas, se agregó a la lista de proyectos la construcción de
templos, monasterios, mezquitas y enormes catedrales urbanas.
Con el advenimiento de la industrialización y la electricidad, los proyectos para la
construcción de vías férreas, instalaciones e infraestructuras eléctricas e hidroeléctricas,
subterráneos y fábricas se volvieron comunes. En los últimos tiempos, el desarrollo de
grandes sistemas para las comunicaciones, la defensa, el transporte, la investigación y la
tecnología de la información ha estimulado diferentes y más complejos tipos de actividades
de proyectos.
Mientras la gente haga cosas, habrá proyectos. Muchos proyectos del futuro serán
similares a los del pasado. Otros serán diferentes en términos de mayor escala de esfuerzo
o tecnología más avanzada. Representativos de estos últimos son dos proyectos recientes,
el túnel del Canal de la Mancha (Chunnel) y la Estación Espacial Internacional. El Chunnel
requirió enormes recursos y tardó una década en completarse. La Estación Espacial
Internacional (Figura I.2) requirió el desarrollo de nuevas tecnologías y los esfuerzos de las
agencias espaciales de EE. UU., Rusia, Europa, Canadá y Japón.
Figura I.2 La Estación Espacial Internacional, un proyecto moderno a gran escala.
Foto cortesía de la NASA.

I.2 ¿Qué es un proyecto?
A partir de estos ejemplos, queda claro que la humanidad ha estado involucrada en actividades de
proyectos durante mucho tiempo. Pero, ¿por qué estos se consideran "proyectos" mientras que otras
actividades humanas, como plantar y cosechar un cultivo, abastecer un almacén, emitir cheques de
nómina o fabricar un producto, no lo son?
¿Qué es un proyecto? Esta es una pregunta que trataremos con mucho detalle más adelante. Sin
embargo, a modo de introducción, a continuación se enumeran algunas características que justifican la
6
clasificación de una actividad como proyecto.
1. Un proyecto tiene una meta definida: un propósito con elementos finales bien definidos,
entregables, resultados o productos para lograr beneficios específicos.
2. Es único; requiere hacer algo diferente de lo que se hacía anteriormente. Es una actividad de
una sola vez, que nunca debe repetirse exactamente de nuevo.
3. Es una organización temporal que busca lograr la meta dentro de un marco de tiempo
programado.
4. Utiliza personas y otros recursos de diferentes organizaciones y

funciones
5. Dado que cada proyecto es único, conlleva desconocimiento y riesgo.
Los ejemplos descritos anteriormente son para tipos familiares de proyectos como la construcción
(pirámides) y el desarrollo de tecnología (estación espacial). En general, la lista de actividades que
califican como proyectos es larga e incluye muchas que son comunes. Las bodas, remodelar una casa
y mudarse a otra casa son proyectos; también lo son las auditorías de empresas, los litigios importantes,
las reubicaciones corporativas y los proyectos; y también lo son los esfuerzos para desarrollar nuevos
productos e implementar nuevos sistemas.
Las campañas militares también califican como proyectos; son esfuerzos temporales, únicos, dirigidos
hacia una meta específica. La invasión de Normandía en la Segunda Guerra Mundial el 6 de junio de
1944 es un ejemplo:
El ingenio técnico y la habilidad organizativa que hicieron posible los aterrizajes fueron asombrosos. La armada de invasión
incluía casi 5.000 barcos de todas las descripciones protegidos por otros 900 barcos de guerra. El plan requería el
7
desembarco de 150.000 soldados y 1.500 tanques en la costa de Normandía en las primeras 48 horas.
La mayoría de los esfuerzos artísticos también son proyectos. Componer una canción o una sinfonía,
escribir una novela o hacer una escultura son proyectos de una sola persona. Algunos proyectos
artísticos también requieren las habilidades de ingenieros y constructores, por ejemplo, el Monte
Rushmore, la Estatua de la Libertad y la Torre Eiffel.
Muchos esfuerzos para salvar vidas humanas y recuperarse de desastres naturales o provocados
por el hombre se convierten en proyectos. Algunos ejemplos son la limpieza masiva que siguió al
accidente nuclear soviético en Chernobyl y las operaciones de rescate y recuperación luego de los
desastrosos terremotos en Chile, Haití, China, Pakistán, México, Turquía y otros lugares, el tsunami
del Océano Índico de 2004 y el brote de ébola en el oeste África en 2014.
La Figura I.3 muestra diversos esfuerzos de proyectos y ejemplos de proyectos bien conocidos,
y dónde se ubican los proyectos con respecto a la complejidad y la incertidumbre.
La complejidad se mide por la magnitud del esfuerzo: la cantidad de grupos y organizaciones
involucradas y la diversidad de habilidades o conocimientos necesarios para realizar el trabajo. Los
compromisos de tiempo y recursos tienden a aumentar con la complejidad.
La incertidumbre se mide aproximadamente por la dificultad de predecir el resultado final en

términos de las dimensiones de tiempo, costo y desempeño técnico. En la mayoría de los proyectos
existe cierta incertidumbre en una o dos dimensiones (pe bodas); en proyectos complejos hay
incertidumbre en las tres dimensiones (por ejemplo, la estación espacial).
En general, cuanto más a menudo se hace algo, menos incertidumbre hay al hacerlo. Esto se
debe simplemente a que las personas aprenden haciendo y, por lo tanto, mejoran sus esfuerzos: el
concepto de "curva de aprendizaje". Los proyectos que son muy similares a los anteriores y sobre
los que hay abundante conocimiento tienen menor incertidumbre.
Estos se encuentran en la parte inferior de la Figura I.3 (por ejemplo, bodas, carreteras, represas,
implementación del sistema). Los proyectos con alta incertidumbre se encuentran en la parte superior
de la figura.
Cuando la incertidumbre de un proyecto cae a casi cero, y cuando el esfuerzo del proyecto se
repite una gran cantidad de veces, entonces el trabajo ya no se considera un proyecto. Por ejemplo,
la construcción de un rascacielos es definitivamente un proyecto, pero la construcción en masa de
casas prefabricadas se parece más a una operación programada y repetitiva que a un proyecto. El
primer vuelo al Polo Sur del almirante Byrd fue un proyecto, pero los vuelos de suministro diarios
modernos a las bases allí son
no. Cuando en el futuro los turistas comiencen a realizar excursiones fletadas a Marte, los
viajes allí tampoco serán considerados proyectos. Serán simplemente operaciones ordinarias
programadas.
La curva de costo de la Figura I.3 indica que el gasto de un proyecto tiende a aumentar
aproximadamente en proporción a su complejidad e incertidumbre. El costo, representado en
términos de tiempo o valor económico, está al nivel de decenas o cientos de horas de trabajo
para proyectos con baja complejidad e incertidumbre, pero aumenta a millones y miles de
millones de horas para proyectos con la mayor complejidad e incertidumbre.
En todos los casos, los proyectos son llevados a cabo por organizaciones que, una vez
finalizado el proyecto, pasan a hacer otra cosa (empresas constructoras) o se disuelven (la
tripulación del almirante Byrd, el equipo de exploración de Marte). En contraste, las actividades
repetitivas y de alta certeza (viviendas prefabricadas, vuelos de suministro y viajes turísticos a
la Antártida o Marte) son realizadas por organizaciones permanentes que hacen lo mismo
repetidamente, con pocos cambios en las operaciones además de la programación. Debido a
que los proyectos no son repetitivos, es por eso que deben administrarse de manera diferente.
I.3 No todos los proyectos son iguales 8
Además de la Figura I.3, otra forma de ilustrar la diversidad de proyectos es con el llamado
modelo NTCP, que clasifica los proyectos y sus resultados finales o productos en cuatro
dimensiones, cada una con tres o cuatro niveles posibles. Las dimensiones y niveles son:
• Novedad: Esto representa qué tan nuevo es el producto o elemento final del proyecto
para los clientes y usuarios potenciales y qué tan bien definidos están los requisitos
iniciales del producto. Incluye tres niveles:
Figura I.3 Una tipología de proyectos.

• Derivado: el artículo o producto final del proyecto es una extensión o mejora de un

producto o sistema existente; por ejemplo, nuevas funciones para un modelo de
automóvil existente; • Plataforma: el artículo o producto final es una nueva
generación de una línea de productos existente en un mercado bien establecido;
por ejemplo, un nuevo modelo de automóvil;
• Avance: el artículo o producto final es nuevo en el mundo; por ejemplo, el primer

teléfono móvil, las primeras notas Post-it de 3M.
• Tecnología: Representa la incertidumbre tecnológica del proyecto y si es nuevo o maduro.

Aborda la cuestión de cuánta tecnología nueva se requiere para crear, construir, fabricar y
habilitar el uso del producto y cuánta competencia técnica necesitan el gerente del proyecto
y el equipo. Tiene cuatro niveles:
• Baja tecnología—involucra solo tecnologías bien establecidas; •

Tecnología media: utiliza principalmente tecnologías existentes, pero también un
uso limitado de algunas tecnologías nuevas o características nuevas; por ejemplo,
industrias automotriz y de electrodomésticos; • Alta tecnología: utiliza tecnologías
que en su mayoría son nuevas para la empresa pero que ya existen y están
disponibles al inicio del proyecto; típico de muchos proyectos de defensa e
informática; es sinónimo de “alto riesgo”;
• Súper alta tecnología: se basa en nuevas tecnologías que no existen al inicio del
proyecto. El objetivo del proyecto está bien definido, pero la solución no; por
ejemplo, aterrizar a un hombre en la luna; es a menudo sinónimo de "muy alto
riesgo".
• Complejidad: Mide la complejidad del producto y la organización del proyecto. Hay tres
niveles:
• Ensamblaje: el proyecto implica combinar una colección de elementos,

componentes y módulos en una sola unidad o entidad que realiza una sola
función; por ejemplo, desarrollar una nueva máquina de café o crear un
departamento para administrar una sola función (como
nómina de sueldos);
• Sistema—involucra una colección compleja de elementos interactivos y subsistemas

que conjuntamente realizan múltiples funciones para satisfacer necesidades
operativas específicas; por ejemplo, un auto nuevo, una computadora nueva, un
negocio completamente nuevo; • Conjunto: el proyecto involucra una gran variedad
de sistemas dispersos (un sistema de sistemas o “supersistema”) que funcionan juntos
para lograr un propósito común; por ejemplo, red nacional de comunicaciones,
infraestructura de tránsito masivo, red regional de generación y distribución de
energía, una corporación completa.
• Ritmo: se refiere al tiempo disponible para el proyecto: la urgencia o criticidad de cumplir con
los objetivos de tiempo del proyecto. Hay cuatro niveles:
• Regular: sin urgencia; el tiempo no es crítico para el éxito inmediato; • Rápido/

competitivo: complete el proyecto en el tiempo adecuado para abordar las oportunidades
del mercado, crear un posicionamiento estratégico o formar una nueva unidad de
negocios; por ejemplo, lanzar un nuevo fármaco, introducir una nueva línea de
productos;
• Tiempo crítico: completar el proyecto antes de una fecha límite específica; no cumplir
con el plazo significa el fracaso del proyecto; por ejemplo, proyectos Y2K;
construcción de instalaciones para los Juegos Olímpicos; lanzamiento de sonda
espacial a un cometa;
• Blitz—un proyecto de crisis; el criterio de éxito es resolver un problema lo más rápido
posible; por ejemplo, salvar a la gente de un barco que se hunde.
Todos los proyectos se pueden caracterizar según las cuatro dimensiones. En la Figura I.4, cada una
de las dimensiones está representada por un cuadrante en el gráfico. Los perfiles en forma de diamante
muestran las cuatro dimensiones de dos ejemplos, el programa lunar Apolo y el programa del
transbordador espacial.
Figura I.4 Modelo NTCP Diamond de Shenhar y Dvir que contrasta los programas Apolo y del transbordador espacial.
Fuente: Shenhar A. y Dvir D. Reinventar la gestión de proyectos: el enfoque de diamante para el éxito
Crecimiento e Innovación. Cambridge, MA: Prensa de la Escuela de Negocios de Harvard; 2007.

I.4 Gestión de Proyectos: La Necesidad
Aunque la humanidad ha estado involucrada en proyectos desde el comienzo de la historia

registrada, obviamente la naturaleza de los proyectos y el entorno han cambiado.
Muchos proyectos modernos involucran complejidad técnica y desafíos en términos de
ensamblar y dirigir grandes organizaciones temporales mientras están sujetos a recursos
limitados, cronogramas limitados e incertidumbre ambiental. Un ejemplo es la Misión Pathfinder
de la NASA para aterrizar y operar un vehículo rover en la superficie de Marte. Tal proyecto
no tiene paralelo no solo en términos de dificultad técnica y complejidad organizativa, sino
también en términos de los requisitos que se le imponen. En la antigüedad, los requisitos eran
flexibles. Si los faraones necesitaban más trabajadores, entonces reclutaban más esclavos o
más de la población general. Si los constructores del Renacimiento se quedaban sin fondos
durante la construcción de una catedral, el trabajo se detenía hasta que se pudieran recaudar
más fondos (una de las razones por las que las catedrales tardaron décadas o siglos en
completarse). Si un rey se quedaba sin dinero mientras construía un palacio, simplemente
aumentaba los impuestos. En los casos en que no se pudo encontrar dinero o trabajadores
adicionales o el proyecto se retrasó, la escala de esfuerzo o la calidad de la mano de obra se
redujo para adaptarse a las limitaciones.
En el proyecto Pathfinder, muchos de los requisitos eran inflexibles: el equipo de la misión
se enfrentó al desafío de desarrollar y aterrizar un vehículo en Marte en menos de 3 años y
con un presupuesto de $150 millones, que era menos de la mitad del tiempo y 1/20 el costo
de la última sonda que la NASA había aterrizado en Marte. El proyecto involucró investigación
y desarrollo avanzados y exploró nuevas áreas de la ciencia y la ingeniería. Los requisitos de
rendimiento técnico no podían verse comprometidos; hacerlo aumentaría el riesgo para
empresas que ya eran muy arriesgadas.
Las restricciones y la incertidumbre en el trabajo del proyecto no se limitan a los programas
científicos gubernamentales a gran escala. Son comunes en los negocios y la tecnología
cotidianos, donde las organizaciones se esfuerzan continuamente por desarrollar e implementar
nuevos productos, procesos y sistemas, y por adaptarse a los requisitos cambiantes de un
mundo cambiante. Considere el desarrollo del “Producto J” de Dalian Company, un proyecto
de desarrollo de productos que ejemplifica lo que las empresas de todo el mundo deben hacer
para ser competitivas y sobrevivir. El Producto J es una idea prometedora pero radicalmente nueva.
Pasar la idea de un concepto a un producto real requerirá la participación de ingenieros y

técnicos de varias divisiones y proveedores de Dalian. El Producto J requerirá enfrentar
desafíos técnicos difíciles, lanzar el producto muy por delante de la competencia y hacerlo a
un costo que la empresa pueda pagar.
Otro ejemplo es la instalación de un nuevo plan de beneficios para empleados en el Hospital
Shah Alam. El proyecto implicaría desarrollar nuevas políticas, capacitar a los trabajadores del
personal, familiarizar a 10,000 empleados con el plan e instalar una nueva red informática y
base de datos, y requeriría la participación activa del personal en recursos humanos, servicios
financieros y sistemas de información, así como expertos de dos firmas consultoras. Tipifica
proyectos de “cambio” en todas partes: proyectos iniciados en respuesta a necesidades
cambiantes y con el objetivo de transformar la forma de hacer las cosas de la organización.
Finalmente, considere que prácticamente todas las empresas tienen o tendrán un sitio web.
Detrás de cada sitio hay varios proyectos para desarrollar o mejorar el sitio web y para integrar
la tecnología comercial electrónica en las principales operaciones de marketing y cadena de
suministro de la empresa. Dichos proyectos también son ejemplos de la necesidad de cambio
de las organizaciones, en este caso para mantenerse al día con los avances en tecnología de
la información y procesos comerciales.
Actividades como estos ejemplos desafían los enfoques de gestión tradicionales para la
planificación, organización y control. Son representativos de actividades que requieren
métodos modernos de gestión de proyectos para cumplir con objetivos de desempeño
tecnológicos o relacionados con el mercado difíciles, a pesar del tiempo y los recursos limitados.
I.5 Meta del Proyecto: Tiempo, Costo y Desempeño
Figura I.5 Meta tridimensional del proyecto.
Fuente: Adaptado de Rosenau M., Success Project Management. Belmont, CA: aprendizaje de por vida
publicaciones; 1981, pág. 16.
El objetivo de prácticamente todos los proyectos se puede conceptualizar en términos de

alcanzar un objetivo que flota en un espacio tridimensional: las dimensiones son el costo, el
tiempo y el rendimiento (Figura I.5). El costo es el costo especificado o presupuestado para el proyecto.
El tiempo es el período programado durante el cual se debe realizar el trabajo. El desempeño
es lo que debe hacer el elemento final del proyecto, los entregables o el resultado final; incluye
todo lo que el cliente del proyecto, el usuario final y otras partes interesadas consideren
necesario o importante. El objetivo representa el objetivo de entregar algo determinado a
alguien en una fecha determinada y por un costo determinado. El propósito de la gestión de
9
proyectos es dar en el blanco, es decir, alcanzar la meta del proyecto.
Pero la complejidad tecnológica, los mercados cambiantes y un incontrolable
entorno hacen que sea difícil dar en el blanco. El tiempo, el costo y el desempeño técnico
están interrelacionados, y el énfasis exclusivo en cualquiera de ellos probablemente socavará
a los demás. Al tratar de cumplir con los cronogramas y los requisitos de desempeño,
aumentan los costos; por el contrario, al tratar de contener los costos, el desempeño laboral
se erosiona y los cronogramas fallan. En épocas anteriores, uno o dos aspectos de la meta
simplemente se dejaban deslizar para que se pudiera cumplir con el “más fijo”. La mayoría
de los proyectos, como muestran los ejemplos de Pathfinder, Dalian Company y Shah Alam
Hospital, no tienen este lujo. La gestión de proyectos ofrece una manera de mantener el
enfoque en las tres dimensiones y controlar las compensaciones entre ellas.
I.6 Gestión de Proyectos: La Persona, El Equipo,

La Metodología
Tres características clave distinguen la gestión de proyectos de las formas tradicionales de
gestión: la persona, el equipo y la metodología.
La característica más destacada de la gestión de proyectos es el papel del director del
proyecto: la persona que tiene la responsabilidad general de planificar, dirigir e integrar los
esfuerzos de todos los involucrados en el proyecto (partes interesadas) para lograr el objetivo
del proyecto. En el rol de gerente de proyecto, una persona es responsable del proyecto y está
totalmente dedicada a lograr sus objetivos. El gerente de proyecto coordina los esfuerzos de
cada área funcional y organización en el proyecto y supervisa la planificación y el control de
costos, cronogramas y tareas de trabajo. Como discutiremos más adelante, muchas otras
partes (partes interesadas) están involucradas y son cruciales para la gestión del proyecto; no
obstante, el papel del director de proyectos es una característica clave que distingue la gestión
de proyectos de la que no lo es.
Hacer un proyecto es un esfuerzo de equipo, y la gestión de proyectos significa reunir a
individuos y grupos para formar el equipo y dirigirlos hacia la meta común. El equipo a menudo
estará formado por personas y grupos de diferentes áreas funcionales y organizaciones. Según
el proyecto, el tamaño y la composición del equipo pueden variar; por lo general, el equipo se
disuelve después de que se completa el proyecto.
El director del proyecto y el equipo del proyecto suelen realizar el trabajo en fases de
acuerdo con una "metodología de gestión de proyectos". Esta metodología prevé la planificación
y el control integrador de proyectos, que según Archibald se refiere a
la recopilación de todos los elementos importantes de información relacionados con (1) los productos o resultados del
proyecto, (2) el tiempo y (3) el costo, en fondos, mano de obra u otros recursos clave... para todos (o como tantas como
prácticas) fases del proyecto. [Requiere] una revisión continua de los planes futuros, la comparación de los resultados
reales con los planes y la proyección del tiempo y el costo totales al finalizar a través de la evaluación interrelacionada
10
de todos los elementos de información.
A medida que un proyecto avanza de una fase a la siguiente, el director del proyecto se basa
en la metodología para (1) identificar las tareas del proyecto, (2) identificar las tareas requeridas
los recursos y los costos, (3) establecer prioridades, (4) planificar y actualizar cronogramas,
(5) monitorear y controlar la calidad y el desempeño del producto final, y (6) medir el
desempeño del11
proyecto.
I.7 Estándares de Conocimientos y Competencias de la

Dirección de Proyectos
La gestión de proyectos se ha convertido en una vocación reconocida respaldada por

varias organizaciones profesionales en todo el mundo. Estas organizaciones han
avanzado en la gestión de proyectos al establecer estándares, pautas y certificaciones.
Entre las más conocidas de estas organizaciones se encuentran IPMA (Asociación
Internacional de Gestión de Proyectos), APM Group (Asociación para la Gestión de
Proyectos) y PMI (Instituto de Gestión de Proyectos). El PMI tiene su sede en EE. UU. y
es la mayor de estas organizaciones; la IPMA, con sede en los Países Bajos, es un grupo
internacional de asociaciones nacionales de gestión de proyectos en Europa, África, Asia
y América del Norte y del Sur; la APM tiene su sede en el Reino Unido.
Estas organizaciones profesionales han recopilado las mejores prácticas aceptadas
de gestión de proyectos y las han publicado como estándares o "cuerpos de conocimiento".
12
(BOKs) y competencias para la profesión. Aunque ninguno de los estándares o
Los BOK cubren todo sobre la gestión de proyectos, se han convertido en normas
reconocidas sobre lo que debe saber mínimamente un profesional de gestión de
proyectos. Las organizaciones también ofrecen niveles de calificación y certificación que
incluyen, por ejemplo, la certificación PMP (Project Management Professional) de PMI;
APMP de APM (profesional de APM) y CPMA (asociado certificado en gestión de
proyectos) de IPMA. Las certificaciones de PMI y APM están “basadas en el cuerpo de
conocimiento”; Las certificaciones de IPMA están "basadas en competencias". Otra
certificación popular en Europa y particularmente en el Reino Unido se basa en PRINCE2
(Proyectos en entornos controlados, versión 2), una metodología para gestionar proyectos
13
originada por la Oficina de Comercio Gubernamental del Reino Unido.
Para los lectores interesados en la certificación profesional, las Tablas I.1 a la Tabla
I.4 en el Apéndice del capítulo muestran la correspondencia entre las áreas de
conocimiento, las competencias esperadas y los métodos de PMI, IPMA, APM y PRINCE,
y los capítulos de este libro. más relevante para ellos.
I.8 Acerca de este libro
Filosofía y Objetivos
Como filosofía y enfoque, la gestión de proyectos es más amplia y sofisticada que la gestión
tradicional de actividades repetitivas. Tiene raíces en muchas disciplinas, incluidas las
ciencias de la gestión, la teoría de sistemas, la contabilidad, la gestión de operaciones, el
diseño organizativo, el derecho y las ciencias del comportamiento aplicadas. Lo que ha
evolucionado y seguirá evolucionando es una filosofía, un enfoque y un conjunto de prácticas,
cuya suma total comprende la gestión de proyectos. Algunos gerentes no entienden esto,
creyendo que la aplicación de técnicas por sí solas, como "diagramas de Gantt", "PERT" o
"gestión matricial" (todo explicado más adelante) hacen que la gestión de proyectos sea
exitosa. La gestión de proyectos es mucho más que esto.
CP Snow escribió un ensayo titulado "Dos culturas" sobre la brecha cultural que los
14
separa a los científicos del resto de la sociedad. gerentes y los académicos de administración
también tienden a separar el mundo en cualquiera de dos perspectivas: (1) los “cuantitativistas”
tienden a ver los proyectos en términos de costos, fechas y variables económicas; (2) los
“conductistas” ven los proyectos en términos del comportamiento, las habilidades y actitudes
de las personas, y los sistemas de organización.
La intención de este libro es brindar una visión equilibrada que enfatice tanto el lado
conductista como el cuantitativo de la gestión de proyectos. La filosofía de este libro es que
para que los gerentes “hagan” la gestión de proyectos, deben familiarizarse con cuatro áreas
temáticas: metodología de sistemas; proceso de desarrollo de sistemas; métodos,
procedimientos y sistemas de gestión; y organización y comportamiento humano; en
consecuencia, los objetivos de este libro son cubrir en profundidad:
1. Los principios y la filosofía que guían la práctica de la dirección de proyectos.

2. La secuencia lógica de etapas en la vida de un proyecto.
3. Los métodos, procedimientos y sistemas para definir, planificar, programar,
controlar y organizar las actividades del proyecto.

4. Los aspectos organizacionales, administrativos y de comportamiento humano en el proyecto
administración.
En los últimos años, el alcance de la gestión de proyectos ha crecido para abarcar más que la
gestión de proyectos individuales, reconociendo que el éxito del proyecto implica más que las
habilidades y el talento de un buen director de proyectos; por lo tanto, un objetivo final del libro es
cubrir:
5. Responsabilidades de la organización para asegurar una gestión eficaz del proyecto y

proyectos exitosos.
Organización de este libro
Más allá de este capítulo introductorio, el libro se divide en cinco secciones principales. La primera
sección está dedicada a los conceptos básicos de la gestión de proyectos. Esta sección describe los
principios de gestión de proyectos, las metodologías de sistemas y el enfoque de sistemas, la
filosofía que subyace a la gestión de proyectos. También se cubren los orígenes y conceptos de la
gestión de proyectos, situaciones en las que se necesita y ejemplos de aplicaciones. La segunda
sección describe el proceso lógico en la creación y vida de un sistema. Llamado Ciclo de Desarrollo
de Sistemas, es la secuencia de fases a través de las cuales todos los sistemas creados por humanos
se mueven desde el nacimiento hasta la muerte. El ciclo se describe en términos de su relación con
los proyectos y la gestión de proyectos. La tercera sección está dedicada a los métodos y
procedimientos para planificar, programar, estimar costos, presupuestar, asignar recursos, controlar
y terminar un proyecto. También se cubren los temas de planificación de recursos, gestión de
proyectos basada en computadora y web, y evaluación de proyectos. La cuarta sección está dedicada
a las organizaciones de proyectos, los equipos y las personas en los proyectos. Abarca formas de
organización de proyectos, funciones y responsabilidades de los directores de proyectos y miembros
del equipo, estilos de liderazgo y métodos para gestionar el trabajo en equipo, los conflictos y el
estrés emocional. La última sección cubre temas que van más allá del gerente del proyecto pero que
son cruciales para el éxito del proyecto y, más ampliamente, el éxito de las organizaciones y
comunidades que patrocinan y emprenden proyectos. También cubre un tema que abarca la mayoría
de los demás temas de este libro, pero
requiere especial atención, gestionando proyectos en diferentes países.

Los cinco objetivos declarados de este libro se dividen aproximadamente en capítulos en
las cinco secciones del libro:
1. Conceptos básicos y filosofía de sistemas: Capítulos 1 y 2.

2. Desarrollo de sistemas y ciclo de vida del proyecto: Capítulos 3 y 4.
3. Métodos, procedimientos y sistemas de planificación y control: Capítulos 5
hasta el 13.
4. Organización, gestión y comportamiento humano: Capítulos 14 a 16.
5. El contexto corporativo y la gestión de proyectos internacionales: Capítulos 17
hasta el 19.
Tres Apéndices proporcionan ejemplos de temas mencionados a lo largo del libro: solicitud de
propuesta (Apéndice A), propuesta de proyecto (Apéndice B) y plan de ejecución del proyecto
(Apéndice C).
I.9 Proyecto de Estudio
La mejor manera de aprender sobre la gestión de proyectos es participar realmente en él o, en su defecto, ser
testigo. Al final de cada capítulo de este libro hay dos tipos de preguntas: el primer tipo son las preguntas
habituales de repaso del capítulo, el segundo se llama "Preguntas sobre el proyecto de estudio". Estos últimos
están destinados a ser aplicados a un proyecto particular elegido por el lector. Esto se llamará el “proyecto de
estudio”. El propósito de estas preguntas y del proyecto de estudio es ayudar al lector a relacionar los conceptos
de cada capítulo con situaciones de la vida real.
Las preguntas del proyecto de estudio se pueden utilizar de dos maneras:
1. Para los lectores que actualmente trabajan en proyectos como gerentes o miembros del equipo del
proyecto, las preguntas pueden estar relacionadas con su trabajo actual. Las preguntas sirven para
aumentar la conciencia del lector sobre cuestiones clave relacionadas con el proyecto y para guiar a
los gerentes en la conducción de la gestión del proyecto.
2. Para los lectores que actualmente son estudiantes a tiempo completo o parcial, las preguntas se
pueden aplicar a proyectos de la "vida real" que pueden observar e investigar. Muchas empresas
comerciales y agencias gubernamentales están felices de permitir que los grupos de estudiantes
entrevisten a los gerentes y recopilen información sobre sus proyectos. Aunque de segunda mano,
esta es una excelente manera de aprender sobre la práctica de gestión de proyectos (y la mala gestión).
Asignación
Seleccione un proyecto para investigar. Debe ser un proyecto “real”; es decir, un proyecto que tiene un propósito
real y no está ideado solo para que puedas investigarlo. Puede ser un proyecto actual o uno ya realizado;
cualquiera que sea, debe ser un proyecto para el cual pueda obtener información fácilmente.
Si actualmente no está involucrado en un proyecto como miembro del equipo, debe encontrar uno para el que
tenga permiso para estudiar (recolectar datos y entrevistar a personas) como un "externo". El proyecto debe
incluir un equipo de proyecto (mínimo de

cinco personas) con un líder de proyecto y tener una duración mínima de 2 o 3 meses. También
debe tener un objetivo específico en términos de una fecha de finalización objetivo, un límite de
presupuesto y un resultado o producto final específico. En general, los proyectos más grandes
brindan una mejor oportunidad de observar los conceptos de gestión de proyectos que los más pequeños.
unos.
Si está estudiando un proyecto desde fuera, también es una buena idea hacerlo en un equipo
de tres a seis personas y un líder de equipo designado (es decir, realizar el estudio usando un
equipo). Esto, en esencia, se convierte en su equipo de proyecto: un equipo organizado con el
propósito de estudiar un proyecto. Luego puede aplicar fácilmente muchos de los procedimientos
de planificación, organización, creación de equipos y otros que se analizan a lo largo del libro
como práctica y para ver cómo funcionan. Esta experiencia "práctica" con su propio equipo,
combinada con lo que aprende del proyecto que está estudiando, le dará una imagen bastante
precisa de los problemas encontrados y las técnicas de gestión utilizadas en la gestión de
proyectos de la vida real.
Apéndice: Relación entre estándares profesionales

y Capítulos de este Libro
Cuadro I.1 Cuerpos de conocimiento y grupos de procesos de la dirección de proyectos del PMI
GUIA PMBOK Y DIEZ CAPÍTULOS QUE ABORDAN ESTOS
ÁREAS DE CONOCIMIENTO AREAS
LA MAYORÍA
RELACIONADO
IMPORTANTE
1. Introducción 0, 1 15, 16
2. Influencia organizacional y vida del proyecto 1, 2, 4, 5, 13, 14–

3, 14, 16
ciclo 17
3. Procesos de gestión de proyectos 4. Gestión 3, 13
de integración de proyectos* 5. Gestión del 4, 11 2, 5, 9, 12, 14, 19
alcance del proyecto* 6. Gestión del 4, 5, 11 2, 13, 19
cronograma del proyecto* 7. Gestión de costes 6, 7, 11 5, 13, 19
del proyecto* 8. Gestión de la calidad del 8, 11 19
proyecto* 9. Gestión de recursos del proyecto* 9 11, 13
10. Gestión de las comunicaciones del proyecto* 6, 16 7, 11, 14, 15, 19
11. Proyecto gestión de riesgos* 12. Gestión de 11, 12 13, 19
adquisiciones del proyecto* 13. Participación de 10 7, 11, 18, 19
las partes interesadas del proyecto* 14. Apéndice X3: 3, 5 11
Relaciones interpersonales y 15 1, 2, 3, 19
dieciséis
habilidades de comportamiento
*Área de conocimiento
Grupos de procesos
Grupo de proceso de iniciación 3, 4
Grupo de proceso de planificación 5, 6, 7, 8 9, 10, 13, 19
Grupo de proceso de ejecución 11 13, 19

Grupo de Procesos de Seguimiento y Control 11 12, 13, 19
Grupo de Proceso de Cierre 12
Cuadro I.2 Competencias de gestión de proyectos IPMA
ICB - COMPETENCIA IPMA CAPÍTULOS QUE ABORDAN ESTOS
BASE COMPETENCIAS
LO MÁS RELEVANTE RELACIONADO
1. Competencias técnicas
1.01 Éxito en la gestión del proyecto 1.02 3, 5, 9
Partes interesadas 1.03 Requisitos 15 1, 3, 19
del proyecto y
4, 5 2, 11, 19
objetivos
1.04 Riesgo y oportunidad 10 7, 11, 18, 19
1.05 Calidad 1.06 9 11, 13
Organización del proyecto 1.07 14, 15 13, 16, 19

Trabajo en equipo dieciséis 13
1.08 Resolución de problemas dieciséis

2, 9, 10
1.09 Estructuras del proyecto 5, 14 1, 4, 8, 13, 15
1.10 Alcance y entregables 1.11 4, 5 2, 3, 13
Tiempo y fases del proyecto 1.12 3, 4, 6, 7 3
Recursos 5, 6, 7 8, 11, 12, 14, 16, 18, 19

1.13 Costo y finanzas 8 -
1.14 Adquisición y contrato 3, 5 11, 19
1.15 Cambios 11 13
1.16 Control e informes 1.17 11 13, 19

Información y documentación 9, 12
1.18 Comunicación 11, 12 19
1.19 Puesta en marcha 3, 4 dieciséis
1.20 Cierre 12
2. Competencias conductuales
2.01 Liderazgo dieciséis

15, 19
2.02 Compromiso 2.03 15, 16

Autocontrol dieciséis
2.04 Asertividad dieciséis
2.05 Relajación dieciséis
2.06 Apertura 2.07 dieciséis
Creatividad 2.08 9, 10
Orientación a resultados dieciséis
2.09 Eficiencia 2.10 5–9, 11, 16

Consulta 5, 16
2.11 Negociación 3, 16
2.12 Conflicto y crisis dieciséis
2.13 Confiabilidad 5–9, 16
2.14 Apreciación de valores 2.15 dieciséis
Ética dieciséis
3. Competencias contextuales
3.01 Orientación a proyectos yo, 1, 17
3.02 Orientación a programas 17 1
3.03 Orientación a portafolios 18 1
3.04 Proyecto, programa y cartera 18 17

implementación
3.05 Organización permanente 3.06 4, 14, 17

Negocios 14, 17–19
3.07 Sistemas, productos y tecnología 3.08 2, 3, 4 9
Gestión de personal 3.09 Salud, seguridad, 6, 16, 19
protección y 3 4, 10
ambiente
3.10 Finanzas 8, 11, 18
3.11 Legal 3, 19
Cuadro I.3 Áreas de conocimiento de la gestión de proyectos de APM
CAPÍTULOS QUE ABORDAN ESTOS

CUALIFICACIÓN APMP 37
ÁREAS DE CONOCIMIENTO AREAS
LA MAYORÍA
RELACIONADO
IMPORTANTE
Gestión de proyectos en contexto
1.1 Gestión de proyectos 1.2 1 yo, 17, 19
Gestión de programas 1.3 Gestión de 17 1
carteras 1.4 Contexto del proyecto 18 1
1.5 Patrocinio del proyecto 1.6 1 2
Oficina del proyecto Planificación 15 19
de la estrategia 17 14
2.1 Éxito y beneficios del proyecto

3 9
administración
2.2 Gestión de partes interesadas 2.4 15 1–3, 19
Plan de gestión del proyecto 2.5 4 5–10
Gestión de riesgos del proyecto 2.6 10 7, 11, 18, 19
Gestión de la calidad del proyecto 2.7 9 11, 13
Salud y seguridad Ejecución de la 3 4, 10
estrategia
3.1 Gestión del alcance 3.2 4, 5, 11 2, 13, 19
Programación 6,7 5, 11, 13, 19
8, 11, 12, 14, 16, 18,

3.3 Gestión de recursos 5–7
19
3.4 Elaboración de presupuestos y gestión 8 11, 19
de costes 3.5 Control de cambios 11 13
3.6 Análisis del valor ganado 3.7 11
Gestión de información y generación de informes 3.8 12 19
Técnicas de gestión de problemas 11
4.1 Gestión de requisitos 4.3 Estimación 4,5 2, 11, 13, 19

8
4.7 Gestión de la configuración 8 2, 11

4.7 Gestión de la configuración 8 2, 11

Empresarial y comercial
5.1 Caso de negocio 3
5.4 Adquisiciones 3, 5 11
Organización y gobernanza
6.1 Ciclos de vida del 3 13, 17
proyecto 6.5 Traspaso y cierre 12
6.6 Revisiones de 12 9, 13
proyectos 6.7 Estructura 14
organizacional 6.8 Roles 15
organizacionales 6.9 Métodos y 17 13
procedimientos 6.10 Gobernanza de la gestión de 17, 18
proyectos Las personas y la profesión

7.1 Comunicación 12
7.2 Trabajo en equipo dieciséis 13
7.3 Liderazgo 7.4 dieciséis

15, 19
Gestión de conflictos 7.5 dieciséis
Negociación 3, 16
Cuadro I.4 Metodología PRINCE2: Principios, Temas, Procesos
CAPÍTULOS QUE ABORDAN PRINCIPIOS,

PRÍNCIPE 2
TEMAS, PROCESOS
LO MÁS RELEVANTE RELACIONADO
1. Siete principios
negocios continuos
18
justificación
Aprender de la experiencia 17 4, 13
Roles definidos y
15
responsabilidades
Administrar por etapas 3 2, 4
Administrar por excepción 9
Enfoque en productos 4,5,9

Adaptarse al entorno del proyecto 1 yo, 1 7
2. S eventostemas
Caso de negocio 3
Organización 5, 1 4 1, 4, 8, 1 3, 1 5
Calidad 9 1 1, 1 3
P lanes 5 6–10
Riesgo 10 7, 1 1, 1 8, 1 9
C ambio P 11 9, 1 3
rogreso 3. 11 1 1, 1 9
Sieteprocesos Inicio de un
proyecto D irección de un 3, 4 dieciséis
proyecto Inicio de un proyecto 11 1 2, 1 3, 1 9
Gestión de un límite de etapa 3, 4
C ontrol de una etapa

4
Gestión de la entrega
de productos C errar un 11
proyecto 11
12
1. Busque ejemplos de proyectos en sitios web, periódicos, revistas o televisión.

Sorprendentemente, una gran cantidad de temas de interés periodístico se
relacionan con proyectos actuales y futuros, o con el resultado de proyectos
pasados. Prepare una lista de estos temas.
2. Prepare una lista de actividades que no son proyectos. ¿Qué los distingue de las
actividades del proyecto? ¿Qué actividades son difíciles de clasificar como proyectos
o no proyectos?
3. Debido a que este es un capítulo introductorio, no se ha dicho mucho acerca de por
qué los proyectos deben administrarse de manera diferente a las "operaciones"
ordinarias y qué constituye la administración de proyectos, el tema de este libro.
Ahora es un buen momento para especular sobre esto: ¿Por qué cree que los
proyectos y los no proyectos deben administrarse de manera diferente? ¿Cuáles
cree que son algunas consideraciones adicionales o especiales necesarias para la
gestión de proyectos?
15
Caso I.1 El aeropuerto de Denver
Cuando se inició el proyecto del Aeropuerto de Denver en 1989, el plazo previsto de 4

años parecía adecuado. Sin embargo, a pesar del abundante respaldo político y la
financiación adecuada, el proyecto sufrió un retraso de 16 meses y un sobrecosto de
1500 millones de dólares. El modelo NTCP se puede utilizar en retrospectiva para
explicar la causa raíz de gran parte del desempeño insatisfactorio del proyecto. En
retrospectiva 20-20, se puede argumentar que un análisis NTCP relativamente simple
del proyecto y sus subproyectos en una etapa temprana (y ajustar el estilo de gestión
en consecuencia) podría haber mejorado significativamente el desempeño.
Para permitir la rotación de aeronaves en menos de 30 minutos según lo solicitado
por United Airlines, uno de los mayores arrendatarios del aeropuerto, era necesario un
sistema automatizado de clasificación y manejo de equipaje para mejorar la eficiencia.
frente al tradicional sistema de manipulación manual. En diciembre de 1991 se

contrató a BAE Automatic Systems para diseñar e implementar el sistema
automatizado en un plazo estimado de 2,5 años.
En agosto de 1994, el sistema tenía 11 meses de retraso y estaba obstaculizando
gravemente las operaciones aeroportuarias. La gerencia decidió construir un sistema
de equipaje alternativo y más tradicional como respaldo a un costo adicional de $ 50
millones, y solo United usaría el sistema BAE para su propio vestíbulo de terminal.
En enero de 1995 se ejecutó con éxito una práctica a gran escala del sistema BAE y
en febrero de 1995 se inauguró el aeropuerto, con 16 meses de retraso.
La construcción del aeropuerto fue principalmente un gran proyecto de construcción

típico; en términos de NTCP se clasificaría de la siguiente manera: Novedad—
Plataforma; Tecnología—Baja tecnología; Complejidad: matriz; Ritmo—Rápido/
Competitivo. El inconveniente del proyecto era ese elemento: el sistema automático
de manejo de equipaje: era tecnología nueva y, por lo tanto, más riesgoso que el
resto del proyecto, un riesgo que no se consideró. El sistema fue el primero de su
tipo (se había utilizado antes solo en una escala mucho menor) y requirió varios
ciclos de diseño y pruebas intensivas. Por lo tanto, debería haber sido considerado
"alta tecnología" y gestionado en consecuencia. Como se analiza más adelante en el
libro, los proyectos de alto riesgo deben administrarse de manera diferente a los
proyectos de bajo riesgo. Los perfiles NTCP del proyecto total y el sistema de manejo
de equipaje se ilustran en la Figura I.6.
Figura I.6 Perfiles “Diamante” para el Aeropuerto de Denver y para el Sistema de Manejo de Equipaje.
Fuente: Shenhar A. and Dvir D. Reinventing Project Management: The Diamond Approach to
Crecimiento exitoso e innovación. Cambridge, MA: Prensa de la Escuela de Negocios de Harvard; 2007.
Preguntas sobre el caso
1. ¿De qué manera deben gestionarse los proyectos de alta tecnología de manera diferente a los
de baja tecnología?
2. BAE Automatic Systems es una corporación acreditada de alta tecnología y estaba familiarizada
con la construcción de sistemas automatizados de manejo de equipaje. ¿Qué podría haberlos
convencido de aceptar un cronograma de 2,5 años para el diseño y construcción del sistema
de manejo de equipaje?
3. Si se realizó un análisis NTCP y se identificó el perfil del sistema de manejo de equipaje,
¿qué debería haber hecho el gerente del proyecto para ayudar a garantizar el éxito del
proyecto?
4. Explique cómo el modelo NTCP prevé 144 tipos diferentes de
proyectos
Notas finales
1. Tompkins P. Secretos de las Grandes Pirámides. Nueva York, Nueva York: Harper & Row; 1976, págs. 233 y 234; Poirier R.
Las Quince Maravillas del Mundo. Nueva York, Nueva York: Random House; 1961, págs. 54–67.
2. Ibíd., págs. 227–228.
3. Barber F. Los triunfos mecánicos de los antiguos egipcios. Londres, Reino Unido: Tribner; mil novecientos.
4. George CS La historia del pensamiento gerencial. Upper Saddle River, Nueva Jersey: Prentice Hall; 1968, pág. 11
5. Potok C. Andanzas. Nueva York, Nueva York: Fawcett Crest; 1978, págs. 154–162.
6. Véase Archibald RD Gestión de proyectos de alta tecnología. Nueva York, Nueva York: Wiley; 1976, pág. 19; meredith j.
y Mantel S. Gestión de proyectos: un enfoque de gestión, 3.ª ed. Nueva York, Nueva York: Wiley; 1995, págs. 8–
9; Roman D. Gestión de proyectos: un enfoque de sistemas. Nueva York, Nueva York: Elsevier; 1986.
7. Véase Terraine J. The Mighty Continent. Londres, Reino Unido: BBC; 1974, págs. 241–242.
8. Esta sección está adaptada de: Shenhar A. y Dvir D. Reinventing Project Management: The Diamond
Enfoque para el crecimiento exitoso y la innovación. Cambridge, MA: Harvard Business School Press, 2007.
Desde la publicación del libro, el modelo NTCP ha sido revisado: "Breakthrough" se ha dividido en
Nuevo en el mercado y Nuevo en el mundo; a “Complejidad” se ha añadido el nivel de Componente a continuación
Asamblea.
9. Véase Gestión exitosa de proyectos de Rosenau MD . Belmont, CA: aprendizaje de por vida; 1981, págs. 15–19.
10. Archibald, Gestión de proyectos de alta tecnología, págs. 6–7.
11. Kerzner H. Gestión de proyectos: un enfoque de sistemas para la planificación, organización y control, décimo
ed. Hoboken, Nueva Jersey: John Wiley & Sons; 2009, pág. dieciséis.
12. Cuerpo de conocimientos de APM, 6.ª ed. Asociación para la Gestión de Proyectos, 2013; Competencia IPMA
Línea de base: ICB, Asociación Internacional de Gestión de Proyectos. Disponible para descargar en
http://ipma.ch/certification/competence/ipma-competence-baseline/ (consultado el 30 de diciembre de 2014); A
Guía de los Fundamentos de la Dirección de Proyectos (Guía del PMBOK), 5.ª ed. Gestión de proyectos
Instituto, 2013.
13. Gestión de proyectos exitosos con PRINCE2, 2009 edn. Oficina de Comercio del Gobierno. Disponible para
descargar en https://www.prince2.com/downloads (consultado el 30 de diciembre de 2014).

14. Snow CP Las dos culturas y una segunda mirada. Cambridge, Reino Unido: Prensa de la Universidad de Cambridge; 1969.
15. Shenhar A. y Dvir D. Reinventar la gestión de proyectos: el enfoque de diamante para un crecimiento exitoso
e Innovación. Boston, MA: Prensa de la Escuela de Negocios de Harvard; 2007.

Parte I
Filosofía y Conceptos
Los dos capítulos de esta sección describen la filosofía y los conceptos que diferencian
la gestión de proyectos de la gestión tradicional sin proyectos. El primer capítulo presenta
las características asociadas con la gestión de proyectos y las variaciones de la gestión
de proyectos. La gestión de proyectos es una aplicación de lo que se ha denominado el
enfoque de sistemas para la gestión; el segundo capítulo describe los principios, la
terminología y la metodología de ese enfoque. Los dos capítulos preparan el escenario
para una cobertura más detallada en secciones posteriores.
Capítulo
Los proyectos mencionados en la Introducción: la Gran Pirámide de Egipto, la

Estación Espacial Internacional, el Canal y el desarrollo del “Producto J” tienen
algo en común entre sí y con cualquier otra empresa de las organizaciones
humanas: todos requieren, en una palabra, gestión. Aunque los recursos, las
tareas de trabajo y los objetivos de estos proyectos varían mucho, ninguno de
ellos podría haber sucedido sin la gestión. Este capítulo contrasta la gestión
de proyectos y la gestión sin proyectos y analiza la variedad de formas y
lugares donde se utiliza la gestión de proyectos.
1
1.1 Funciones de la Gerencia
El papel de la administración es planificar, organizar e integrar recursos y tareas para lograr las
metas de la organización. Aunque las responsabilidades específicas de los gerentes varían
mucho, todos los gerentes, ya sean presidentes corporativos, directores de agencias, gerentes
de línea, administradores escolares, productores de películas o gerentes de proyectos, tienen
el mismo rol.
Las actividades de los gerentes, incluidos los gerentes de proyectos, se pueden clasificar en
las cinco funciones identificadas en la Figura 1.1. Lo primero es decidir qué se tiene que hacer
y cómo se va a hacer. Esta es la función de planificación , que implica establecer un propósito
o una meta y establecer los medios para lograrlo de acuerdo con las metas, los recursos y las
limitaciones del entorno de la organización de nivel superior.
En segundo lugar, y relacionado con la planificación, se dispone el trabajo a realizar; esta es
la función organizadora . Esto implica (1) contratar, capacitar y reunir personas en un equipo
con relaciones específicas de autoridad, responsabilidad y rendición de cuentas; (2) adquirir y
asignar materiales, capital y otros recursos; y (3) crear una estructura organizativa con políticas,
procedimientos, patrones de informes y canales de comunicación.
El tercero es dirigir y motivar a las personas para que alcancen la meta. Este es el
función de liderazgo .
El cuarto es monitorear el desempeño del trabajo con respecto a la meta y tomar las medidas
necesarias siempre que el trabajo se desvíe de la meta; esta es la función de control .
Las cuatro funciones están dirigidas a la meta, lo que implica una quinta función: evaluar las
cuatro funciones para determinar qué tan bien está funcionando cada una de las funciones y si
es necesario cambiar las funciones o las metas.
En el día a día, rara vez los gerentes realizan las funciones de la figura 1.1 en secuencia.
Aunque la planificación precede lógicamente a las demás, siempre existe la necesidad de
organizar actividades, dirigir personas y evaluar el trabajo, independientemente de la secuencia.
Los gerentes enfrentan cambios constantemente, lo que significa que los planes, las actividades,
los estándares de desempeño y los estilos de liderazgo también deben cambiar.
Figura 1.1 Las funciones de la dirección.
Los trabajos de diferentes gerentes conllevan diferentes responsabilidades

según el área funcional y el nivel gerencial del trabajo. Algunos gerentes dedican
la mayor parte de su tiempo a planificar y organizar, otros a controlar y otros a
dirigir y motivar. En algún momento u otro, los gerentes de proyecto realizan
todas estas funciones.
1.2 Características de la gestión de proyectos
La gestión de proyectos es un enfoque de sistemas para la gestión. Un sistema es una colección de

componentes o elementos interrelacionados que en combinación hacen algo. Se puede pensar en un
proyecto como un sistema: es una colección de elementos —tareas de trabajo, recursos y partes
interesadas (individuos, equipos, organizaciones)— dirigidos a lograr algún objetivo. El enfoque del
enfoque de sistemas es optimizar el sistema general (no sus elementos individuales) para lograr la
meta. El enfoque comienza definiendo la meta, identificando los componentes o elementos del sistema
que contribuyen o restan valor al logro de la meta, y luego administra los elementos para lograr la meta
de la mejor manera. Implica todas las funciones de la administración: planificación, organización,
liderazgo, etc.
Como se describe en la Introducción, los proyectos difieren de los no proyectos. Las actividades
ajenas al proyecto, como la producción en masa en las fábricas o la prestación de servicios de rutina,
son rutinarias y rara vez cambian; hay poca incertidumbre o riesgo involucrado. Tienden a involucrar a
las mismas personas que realizan los mismos procedimientos, día tras día. Por el contrario, cada
proyecto es único y desconocido en algún sentido, y requiere personas o equipos de diferentes
funciones u organizaciones. Esto genera incertidumbre y riesgo y dificulta la consecución del objetivo
deseado. Así que la pregunta es: ¿Cómo gestionas algo así como un proyecto? La respuesta: utilice la
gestión de proyectos.
Las características clave de la gestión de proyectos son:2
1. Una sola persona, el director del proyecto, dirige la organización del proyecto y trabaja
independientemente de la cadena de mando normal. La organización del proyecto refleja la
naturaleza interfuncional, orientada a objetivos y temporal del proyecto.
2. Debido a que cada proyecto requiere una variedad única de habilidades y recursos, el trabajo
del proyecto puede ser realizado por personas de diferentes áreas funcionales o contratistas
externos.
3. El gerente del proyecto es responsable de integrar a las personas de las diferentes áreas
funcionales o contratistas externos.
4. El director del proyecto trabaja directamente con los directores funcionales o contratistas
que pueden ser responsables de las tareas de trabajo individuales y del personal dentro
del proyecto.
5. Mientras que los gerentes de proyectos se enfocan en entregar productos o servicios
particulares a tiempo y dentro del presupuesto, los gerentes funcionales pueden ser
responsables de proporcionar trabajadores del proyecto y recursos de sus departamentos.
Como resultado, pueden surgir conflictos entre los gerentes funcionales y de proyecto
sobre las personas y los recursos asignados a los proyectos.
6. Un proyecto puede tener dos cadenas de mando, una funcional y otra de proyecto, por lo
que las personas que trabajan en un proyecto reportan tanto a un gerente de proyecto
como a un gerente funcional.
7. La toma de decisiones, la rendición de cuentas, los resultados y las recompensas se
comparten entre el equipo del proyecto y las unidades funcionales de apoyo y los
contratistas externos.
8. Aunque la organización del proyecto es temporal, por lo general las unidades funcionales
o de subcontratación a partir de las cuales se forma son permanentes. Cuando termina
un proyecto, la organización del proyecto se disuelve y las personas regresan a sus
unidades funcionales o de subcontratación.
Debido a que los proyectos requieren los esfuerzos coordinados de diferentes individuos y
unidades dentro y fuera de la organización, los gerentes y trabajadores en diferentes unidades y
en diferentes niveles trabajan directamente entre sí. Con frecuencia se pasan por alto las líneas
formales de comunicación y autoridad y se crea una jerarquía horizontal . Esta jerarquía horizontal
permite que las personas de la organización del proyecto de diferentes áreas funcionales y
organizaciones externas trabajen directamente entre sí según sea necesario.
En las organizaciones sin proyectos, los gerentes tienden a ser especialistas y responsables
de una sola unidad o departamento funcional. Sin embargo, un proyecto, dado que puede
involucrar a muchos departamentos, necesita a alguien más allá de estos departamentos para
asumir la responsabilidad de cumplir con los objetivos del proyecto. Esa persona es el director del
proyecto. El énfasis en las metas del proyecto versus las metas de cada unidad funcional es una
característica clave que distingue a los gerentes de proyectos de los gerentes funcionales.
Los gerentes de proyecto a menudo dirigen a personas que no están "bajo" ellos pero que
están "asignadas" a ellos desde diferentes áreas de la organización según sea necesario. Este
potencialmente hace que ser un gerente de proyecto sea más complicado (y

difícil) que ser un gerente departamental. Los gerentes de proyecto deben saber
cómo usar la diplomacia, resolver conflictos y poder funcionar sin la comodidad
de tener siempre el mismo equipo reportándoles.
1.3 Evolución de la Gestión de Proyectos
A ningún individuo o industria se le puede atribuir la idea de la gestión de proyectos. A menudo

se asocia con los primeros programas espaciales y de misiles de la década de 1960, pero
claramente sus orígenes se remontan a mucho antes. Las técnicas de gestión de proyectos
probablemente aparecieron por primera vez en las principales obras de construcción de la
antigüedad, como las pirámides y los acueductos romanos, y luego se modificaron para su uso
en otros proyectos, como la construcción naval. A principios del siglo XX, los gerentes
desarrollaron técnicas para usar en otros tipos de proyectos, como diseñar y probar nuevos
productos y construir e instalar maquinaria especializada. Durante la Primera Guerra Mundial,
se desarrolló una nueva herramienta llamada diagrama de Gantt para programar y realizar un
seguimiento del trabajo de tipo proyecto (ejemplos en el Capítulo 5), seguida unos 40 años
más tarde por el diagrama de red del proyecto (discutido en el Capítulo 6).
En la década de 1950, el tamaño y la complejidad de muchos proyectos habían aumentado

tanto que las técnicas de gestión existentes resultaron inadecuadas. En repetidas ocasiones,
los proyectos a gran escala para el desarrollo de aviones, misiles, sistemas de comunicación
y buques de guerra sufrieron enormes sobrecostos y plazos. Para resolver el problema, se
desarrollaron dos nuevos métodos "basados en redes" para la planificación y el control, uno
llamado PERT y el otro llamado CPM (descritos en los Capítulos 6 y 7).
Una década más tarde, los métodos basados en redes se refinaron para integrar la contabilidad
de costos de proyectos con la programación de proyectos. Estos métodos se generalizaron
en la década de 1960, cuando el gobierno de los EE. UU. ordenó su uso en proyectos para el
Departamento de Defensa, la NASA y esfuerzos a gran escala, como plantas de energía
nuclear. En la década de 1970, se desarrolló el método del valor ganado para el seguimiento
de proyectos (consulte el Capítulo 12); esto condujo a sistemas de medición del desempeño
que rastrean simultáneamente los gastos de trabajo y el progreso del trabajo.
Ver Capítulos 5 y 6
Ver capítulos 6 y 7
Ver Capítulo 12
Los últimos 50 años han sido testigos del aumento de la informatización de la gestión de proyectos.
Mientras que los sistemas iniciales de planificación y seguimiento de proyectos cuestan entre $ 10,000 y $
100,000, hoy en día, el software y el software gratuito de costo relativamente bajo hacen posible el uso de
una variedad de herramientas para planificar, programar, calcular costos y controlar proyectos de
prácticamente cualquier tamaño.
Asociado con la evolución de la gestión de proyectos estuvo la aparición de formas de organización de
proyectos y el papel del director de proyectos. No fue sino hasta la Segunda Guerra Mundial que “el
proyecto” fue reconocido como una forma organizativa distinta. En la urgencia de desarrollar armamento
sofisticado y organizar grupos de trabajo masivos de tropas y material, evolucionó la forma de organización
de "proyecto puro" (descrita en el Capítulo 14), y no fue hasta la década de 1960 que las empresas
comenzaron a utilizar el término "proyecto". “gerente” como título y rol formal (ver Capítulo 15).
En los últimos años, la gestión de proyectos ha proliferado en todas las industrias del mundo. Las
aplicaciones más extendidas y los ejemplos de cada una se discuten en las siguientes secciones.
3
1.4 ¿Dónde es adecuada la gestión de proyectos?
El hecho es que la gestión de proyectos se aplica en todas partes y hay pocas industrias o situaciones
en las que no se aplica al menos una parte del tiempo. Esta sección identifica las condiciones y
situaciones en las que se aplica o es esencial una organización tipo proyecto.
La gestión de proyectos se puede aplicar a cualquier empresa “ad hoc”. Como se muestra en la
Figura I.3 en la Introducción, “ad hoc” incluye actividades que van desde escribir un trabajo o
remodelar una cocina hasta recaudar fondos y construir parques temáticos. En general, cuanto más
desconocida o única sea la empresa, mayor será la necesidad de gestión de proyectos; cuanto más
numerosas, interdisciplinarias e interdependientes sean las actividades de la empresa, mayor será la
necesidad de que la gestión de proyectos asegure que todo esté coordinado, integrado y completado,
y que nada se pase por alto.
Los clientes, como las grandes corporaciones y los gobiernos, solicitan u ordenan con frecuencia
la gestión formal de proyectos porque creen que ofrece mejores costos, cronogramas y control de
calidad, y prefieren tener un único punto de contacto, el gerente del proyecto, con quien tratar.
Ver Introducción
Criterios
Cleland y King enumeran cinco criterios para determinar cuándo utilizar proyecto
4
métodos de gestión y organización:
1. Desconocimiento
Por definición, un proyecto implica hacer cosas diferentes, hacer las mismas cosas pero de manera
diferente, o ambas cosas. Por ejemplo, mientras que los cambios menores continuos en los productos
Por ejemplo, las pequeñas mejoras en las piezas de automóviles generalmente se pueden lograr
sin la gestión de proyectos, la modernización de una planta automotriz, que requiere esfuerzos
no rutinarios, como la mejora de las instalaciones, el reemplazo de equipos, la capacitación de
los empleados y la modificación de los procedimientos, sin duda requeriría la gestión de proyectos.
2. Magnitud del Esfuerzo

Cuando un trabajo requiere sustancialmente más recursos (personas, capital, equipos, etc.) de
los que normalmente emplea un departamento u organización, puede ser necesaria la gestión
de proyectos. Los ejemplos incluyen la reubicación de una instalación, la fusión de dos
corporaciones o el desarrollo de un nuevo producto y su colocación en el mercado. Incluso
cuando el trabajo se encuentra principalmente dentro del ámbito de un área funcional, la tarea
de coordinar el trabajo con otras áreas funcionales puede ser grande. Por ejemplo, aunque
parezca que un proyecto de instalación de software corporativo se enmarca completamente
dentro del área funcional de la tecnología de la información, en realidad podría requerir una
combinación de los procedimientos y recursos de todos los departamentos afectados por la
instalación e involucrar a cientos de personas.
3. Entorno dinámico
Industrias como la aeroespacial, la biotecnología, la informática, la electrónica, la farmacéutica y
las comunicaciones se enfrentan a cambios continuos impulsados por un entorno caracterizado
por una gran innovación, una competencia intensa y cambios en los mercados y las demandas
de los consumidores. La gestión de proyectos proporciona la flexibilidad necesaria para hacer
frente a las amenazas y oportunidades emergentes en dichos entornos.
4. Interrelación
Las áreas funcionales tienden a ser egoístas y trabajan de forma independiente. Cuando el
esfuerzo requiere que trabajen en conjunto, la gestión de proyectos es necesaria para construir
relaciones entre las áreas, agilizar el trabajo y conciliar conflictos. El director del proyecto
coordina los esfuerzos de las áreas funcionales internas y con
subcontratistas y proveedores externos.
5. Reputación de la Organización
Si el hecho de no completar satisfactoriamente un proyecto resultaría en la ruina financiera, la

pérdida de participación en el mercado, el daño a la reputación o la pérdida de contratos futuros,
el caso para utilizar la gestión de proyectos es sólido. La gestión de proyectos no puede
garantizar el éxito, pero mejora las probabilidades al reducir los riesgos inherentes en proyectos
grandes y complejos.
Ejemplo 1.1 Renovación de la Estatua de la Libertad 5
Noventa y cinco años después de que se presentara la Estatua de la Libertad al pueblo

estadounidense, su superficie y su estructura interior se habían corroído tanto que se
consideró estructuralmente defectuosa. Para supervisar la restauración de la estatua y
otros edificios en la cercana Isla Ellis, el Departamento del Interior de EE. UU. estableció
una fundación.
Muy poco del trabajo de restauración calificó como "estándar". Involucraba habilidades
altamente especializadas, como erigir el andamio, construir una nueva antorcha, construir
ventanas para la corona y reemplazar el marco interior, experiencia que tiende a
encontrarse en empresas más pequeñas. Como resultado, el trabajo fue realizado por
una legión de más de 50 pequeñas empresas, muchos de cuyos trabajadores eran
inmigrantes o descendientes de inmigrantes a quienes la estatua les había dado la
bienvenida a Estados Unidos.
Había una miríada de características notables sobre el trabajo. Los andamios que
rodeaban la estatua nunca la tocaron en ningún momento. Construido con cientos de
miles de piezas de aluminio, calificó para el Libro Guinness de los récords mundiales
como el andamio independiente más grande jamás construido. Para renovar el interior de
la estatua, se fabricaron minuciosamente 1.699 barras de 1,5 m (5 pies) con 15.900 kg
(35.000 libras) de acero inoxidable y luego se instalaron individualmente. Alrededor de la
corona se reemplazaron 25 ventanas. Cada uno fue hecho a mano y tuvo que ser tratado
como un proyecto en sí mismo. Para fabricar una antorcha completamente nueva, los
artesanos franceses practicaron una antigua forma de cobre.
técnica. El proyecto fue verdaderamente una unión de arte e ingeniería.

El esfuerzo de renovación de 30 meses y $31 millones involucró miles de tareas
realizadas por cientos de personas. La mayoría de las tareas no eran rutinarias y
estaban interrelacionadas, y todas debían completarse dentro de un presupuesto y un
cronograma ajustados; tal situación exige la gestión de proyectos. (El Capítulo 16 trata
sobre la empresa responsable de gestionar la renovación).
Ver Capítulo 16
Donde la gestión de proyectos no es adecuada
El anverso de todo esto es que cuanto más familiar y rutinaria sea la empresa, más estable el
entorno, menos singular y más estandarizado el producto final, y cuanto menor sea la
participación en el resultado, menor será la necesidad de gestión de proyectos. La producción
de productos industriales y agrícolas estandarizados, por ejemplo, generalmente se administra
de manera más eficiente mediante procedimientos probados y verdaderos de planificación y
control de operaciones que mediante la gestión de proyectos. Esto se debe a que para
operaciones repetitivas y estandarizadas, hay mucha certeza en el proceso y el resultado;
para tales operaciones, los procedimientos rutinarios y estandarizados para la planificación,
programación y elaboración de presupuestos de la producción son adecuados, pero la gestión
de proyectos no lo es.
1.5 Gestión por Proyecto: Un Enfoque Común

Aunque no es apropiado para todas las situaciones, la gestión de proyectos se aplica a muchas, y no
solo a empresas infrecuentes y de gran escala, sino también a todo tipo de actividades más pequeñas
y frecuentes. Siempre que una empresa involucre actividades que son un tanto únicas o desconocidas
y requiere la cooperación de varias partes, se aplica la gestión de proyectos.
Por ejemplo, los consultores en la mayoría de las industrias realizan el trabajo proyecto por
proyecto. Siempre que su trabajo requiera la participación coordinada de varios individuos o grupos,
se aplica la gestión de proyectos. Cuantas más personas o grupos participen, mayor será la
aplicabilidad de la gestión de proyectos.
De manera similar, los grupos que desarrollan o implementan nuevos productos, sistemas o
servicios también trabajan proyecto por proyecto. Cuanto más grande, más arriesgado, más complejo,
costoso, innovador o diferente sea lo que se está desarrollando o implementando, mayor será la
aplicabilidad de la gestión de proyectos.
Además, cualquier grupo que realice un trabajo único cliente por cliente (lo que se denomina
hecho a pedido o hecho a medida) está realizando un trabajo de proyecto. Si el trabajo requiere
esfuerzos coordinados de diferentes partes, se aplica la gestión de proyectos.
Piense en estas situaciones por un momento y comenzará a darse cuenta de los muchos casos
en los que suceden proyectos y se aplica la gestión de proyectos.
La gestión de cualquier tipo de trabajo como un proyecto discreto se conoce como "gestión por 6
MBP. gestionado como
Con
si MBP,
fuera un
se proyecto.
planifica una
En particular,
empresa oMBPun conjunto
implica que
de actividades
la empresaytendrá
proyecto", o
objetivos y alcance bien definidos, requisitos firmes para los resultados finales, un plan de trabajo,
una fecha de finalización y un presupuesto para los recursos necesarios. Se forma un equipo con el
único propósito de realizar el trabajo, y se asigna un jefe de proyecto o jefe de equipo para guiar y
coordinar el trabajo.
En algún momento, todas las organizaciones hacen proyectos. Incluso en industrias estables y
repetitivas, los pequeños proyectos que involucran a unas pocas personas siempre están en
progreso: se instalan nuevas máquinas, se reparan las viejas; la oficina esta remodelada; la cafetería
está renovada. Cuando surgen estos o esfuerzos de proyectos más grandes, un grupo de proyecto formalizado
se forma y se nombra un director de proyecto.
Ejemplo 1.2 Reubicación de Goman

Publishing Company
Muchas empresas, independientemente de su tamaño (la sede de una corporación

multimillonaria o un restaurante familiar), en algún momento se enfrentan a la decisión de
reubicarse. La reubicación requiere la planificación y coordinación de numerosas tareas
que involucran a muchas personas, departamentos y contratistas externos. Es un evento
importante que, si se realiza correctamente, puede ser una experiencia emocionante y
rentable, pero si se realiza de manera deficiente, puede provocar pérdidas financieras o la
ruina. También es representativo de una situación en la que una empresa debe hacer algo
que normalmente no hace.
Goman Publishing estaba experimentando un rápido crecimiento y esperaba superar
sus instalaciones actuales. La tarea inicial en la reubicación de la empresa fue decidir entre
dos opciones: comprar un terreno y construir un nuevo edificio, o arrendar o comprar una
estructura existente. Después de decidir construir, la siguiente tarea fue seleccionar un
sitio. Los principales criterios de selección fueron los gastos de compra, la distancia desde
la ubicación actual, el prestigio y el tamaño de la nueva ubicación y el acceso a las
principales autopistas. La siguiente tarea fue la planificación de la reubicación, que
constaba de dos fases principales: el diseño y la construcción de las nuevas instalaciones
y el traslado físico, cada una de las cuales implicaba numerosas consideraciones. Por
ejemplo, Goman quería retener a sus empleados actuales y, para maximizar el atractivo
de las nuevas instalaciones, decidió construir un área de estacionamiento interior para
empleados y una cafetería grande y bien equipada. Entre las muchas consideraciones
relacionadas con la mudanza estaban la adquisición de muebles, el manejo especial de las
computadoras, la contratación de empresas de mudanzas, la información a los empleados
y clientes sobre la mudanza y el mantenimiento de la seguridad corporativa. Además, la
reubicación tendría que programarse para minimizar el tiempo de inactividad y la interrupción de las operacio
Para supervisar el proyecto y garantizar que la construcción y la mudanza física salieran
según lo planeado, Goman nombró a un gerente de proyecto. El director del proyecto
trabajó con arquitectos y contratistas de obras durante las fases de diseño y construcción,
y con representantes de las áreas funcionales.
departamentos y contratistas de mudanzas durante la mudanza de reubicación. A

pesar del alcance y la falta de familiaridad con el proyecto, Goman pudo completar la
construcción y el traslado físico a tiempo y dentro del presupuesto.
1.6 Diferentes formas de gestión relacionada con proyectos
La gestión de proyectos adopta diferentes formas con diferentes nombres, incluida la gestión de
sistemas, la gestión de grupos de trabajo, la gestión de equipos, la gestión ad hoc, la gestión matricial
y la gestión de programas. Todos estos formularios comparten dos características: (1) un equipo de
proyecto u organización de proyecto creada únicamente con el propósito de lograr un objetivo específico,
y (2) una sola persona, un gerente de proyecto , a quien se le asigna la responsabilidad de ver que se
logre el objetivo.
Más allá de estos, las características de los formularios son algo diferentes.
La primera sección a continuación cubre la gestión de proyectos "básica", el concepto más
comúnmente entendido de gestión de proyectos. Las otras secciones cubren formas de gestión
similares a la gestión de proyectos o relacionadas con la selección de proyectos.
Gestión básica de proyectos
Comúnmente, el gerente de proyecto y los gerentes funcionales están en el mismo nivel organizacional
y ambos reportan a las mismas personas de alto nivel. El director del proyecto tiene autoridad formal
para planificar, dirigir, organizar y controlar el proyecto de principio a fin. El director del proyecto puede
trabajar directamente con cualquier nivel y área funcional de la organización para lograr los objetivos
del proyecto. Ella informa al gerente general o propietario y lo mantiene informado sobre el estado del
proyecto. El director del proyecto a veces tiene autoridad para contratar personal y adquirir instalaciones,
aunque más a menudo tiene que negociar con los directores funcionales para "tomarlos prestados".
La gestión básica de proyectos se implementa en dos formas ampliamente utilizadas: proyecto puro
y matriz. En la gestión pura de proyectos se crea una organización completa y autónoma; los recursos
necesarios pertenecen al proyecto y no tienen que ser prestados. En la gestión matricial, la organización
del proyecto se crea a partir de recursos prestados de las unidades funcionales. El proyecto debe
compartir sus recursos con otros proyectos y con las áreas funcionales de las que se toman prestados.
Estas dos formas de gestión de proyectos se describirán con más detalle en
Capítulo 14.
Ver Capítulo 14
A menudo se encuentra en las industrias de la construcción y la tecnología, la gestión básica

de proyectos también se aplica fácilmente a actividades pequeñas y no técnicas, incluidas las
7
artes y las ciencias sociales. Adams, Barndt y Martin citan ejemplos:
• Salud, Educación y Bienestar (HEW) realiza trabajo social en gran parte sobre la base de
subvenciones asignadas a través de agencias estatales y locales. Asociados con cada
subvención están los requisitos de tiempo, costo y desempeño para las agencias de
financiamiento. En esencia, cada subvención da como resultado un proyecto al que se
pueden aplicar los conceptos de gestión de proyectos.
• Una empresa de publicidad que realiza campañas promocionales utiliza los servicios de
investigación de mercados, contabilidad, gráficos, ventas y otros departamentos. Las
campañas son similares a los proyectos en otras industrias: requieren una planificación
y coordinación de los departamentos tal y como lo proporciona la gestión de proyectos.
Gestión de programas
El término "gestión de programas" a veces se usa indistintamente con la gestión de proyectos

debido a las similitudes de los programas y los proyectos: ambos se definen en términos de metas
u objetivos sobre lo que se debe lograr y ambos requieren planes, presupuestos y cronogramas
para lograr las metas.
No obstante, los programas y proyectos son diferentes; las principales distinciones son que un
programa se extiende a lo largo de un horizonte de tiempo más largo (a veces indefinidamente)
que un proyecto, y consta de varios esfuerzos de trabajo paralelos o secuenciales o proyectos
que trabajan para alcanzar una meta del programa. Los proyectos dentro de un programa
comparten objetivos y recursos comunes y, a menudo, son interdependientes. Como ejemplos, un
programa de desarrollo urbano puede incluir varios proyectos, como rehabilitación de viviendas,
capacitación laboral y de habilidades, y asistencia de consultoría para pequeñas empresas; un
programa de exploración de Marte puede incluir varios proyectos para sondas no tripuladas al planeta rojo y
sus lunas, Fobos y Diemos, seguidas de una misión tripulada a Marte.

Otra distinción es que los proyectos están orientados a producir y entregar un producto o
servicio, pero después de eso, la organización del proyecto se disuelve y la responsabilidad se
transfiere a otra persona para operar el artículo final. En un programa, sin embargo, es
responsabilidad de la gestión del programa garantizar que el elemento final no solo se entregue,
sino que se integre con otros sistemas y esté operativo durante el tiempo que sea necesario. Por
ejemplo, la gestión del programa supervisaría no solo el desarrollo de un satélite y su cohete
propulsor y su lanzamiento, sino también la operación y el monitoreo continuos del satélite, lo que
sea necesario para lograr el objetivo general del programa satelital.
Muchos conceptos para la gestión de proyectos también se aplican a la gestión de programas,

aunque con modificaciones para manejar el mayor alcance y magnitud de los programas y permitir
que el administrador del programa supervise y coordine los proyectos dentro del programa. El
Project Management Institute ha publicado un Estándar para la Gestión de Programas que se
alinea con su PMBOK; la Oficina del Gobierno del Reino Unido ha producido uno que se alinea
8
con Prince2. La gestión de programas se analiza más
en el Capítulo 17.
Ver Capítulo 17
Gestión de nuevas empresas
La gestión de proyectos se asemeja a la gestión de nuevas empresas, un tipo de gestión utilizada

en empresas orientadas al consumidor para generar nuevos productos o mercados. En la gestión
de nuevas empresas, se crea un equipo para encontrar nuevos productos o mercados que se
ajusten a las habilidades, capacidades y recursos especializados de una organización. Una vez
que ha definido el producto, el equipo puede pasar a diseñarlo y desarrollarlo, y luego determinar
los medios para producirlo, comercializarlo y distribuirlo.
Gestión de productos
El término gestión de productos se refiere a un tipo especial de gestión de programas.

donde una sola persona es responsable de supervisar todos los aspectos de la programación
de producción, el inventario, la distribución y las ventas de un producto. El gerente de producto
coordina y agiliza el lanzamiento, la fabricación, la distribución y el soporte del producto. Al
igual que el gerente de proyecto, el gerente de producto se comunica directamente con las
funciones dentro y fuera de la organización y coordina los esfuerzos dirigidos a las metas del
producto. El gerente de producto participa activamente en el manejo de conflictos y la
resolución de problemas que degradarían la capacidad de fabricación, impedirían la distribución,
alterarían el precio, perjudicarían las ventas o afectarían de alguna manera el financiamiento,
la producción y la comercialización del producto. Para productos con ciclos de vida prolongados,
el rol de gerente de producto se ocupa de manera rotativa.
Gestión del portafolio de proyectos
Muchas organizaciones seleccionan y agrupan proyectos y programas en "carteras", cada una

similar a una cartera de inversión, con el objetivo de maximizar el valor de la cartera en
términos de, por ejemplo, ganancias, tasa de rendimiento o cumplimiento de los objetivos
estratégicos de la empresa. El administrador de cartera ayuda a la organización a tomar
decisiones sobre agregar, cancelar o cambiar proyectos o programas en función del desempeño
financiero, la utilización de recursos, los riesgos y otros factores que afectan el valor comercial.
Mientras que el propósito de la gestión de proyectos y programas es gestionar proyectos y

programas particulares, el objetivo de la gestión de carteras es asegurarse de que se
seleccionen los proyectos y programas correctos , es decir, asegurar que se alineen con las
metas estratégicas y financieras de la organización y encajen dentro de los limitados recursos
disponibles.
La gestión de cartera no se trata realmente de gestionar proyectos en sí, sino de seleccionar
y retener los proyectos correctos . Por lo tanto, para los gerentes de cartera, la experiencia en
gestión de proyectos es menos importante; de mayor importancia son las habilidades
financieras y analíticas necesarias para seleccionar y agrupar proyectos y programas en
función de sus contribuciones a las metas estratégicas y financieras. El administrador de la
cartera debe saber cómo diversificar una cartera de proyectos para aprovechar los recursos
disponibles y la compensación riesgo-recompensa. El PMI creó el Estándar para Portafolio
Gestión y ofrece una Certificación en Gestión de Cartera; el OCG del Reino Unido
también ha creado un estándar. 9 La gestión de cartera se trata en el Capítulo 18.
Ver Capítulo 18
1.7 Entornos del proyecto 10
La práctica de gestión de proyectos también varía según el entorno del proyecto, que el autor
Daniel Roman clasifica como comercial/con fines de lucro, gubernamental/sin fines de lucro y
militar. Todas las formas de proyecto descritas anteriormente se encuentran en el entorno
comercial. Las dos formas que se encuentran más comúnmente en el gobierno y las fuerzas
armadas son la gestión básica de proyectos y la gestión de programas.
Gestión de proyectos comerciales/con fines de lucro
En un proyecto comercial, el artículo final es un producto o servicio claramente definido,

generalmente personalizado para satisfacer a un cliente y motivado por criterios de ganancias.
El director del proyecto suele guiar el proyecto de principio a fin, coordinando los esfuerzos del
equipo del proyecto con las áreas funcionales, los subcontratistas y los proveedores, y
manteniendo informados al cliente y a la alta dirección sobre el progreso hacia los objetivos del
proyecto y los beneficios.
Gestión de proyectos gubernamentales y sin fines de lucro
Los proyectos gubernamentales y sin fines de lucro difieren de las actividades comerciales de
varias maneras. En primer lugar, no existe ningún incentivo de lucro en el trabajo gubernamental
y sin fines de lucro, y los factores económicos pueden ser de menor importancia. Los gerentes
de proyecto son frecuentemente reasignados a mitad de camino en sus proyectos, lo cual es
problemático en términos de continuidad administrativa. Para el trabajo del gobierno, la
continuación del proyecto a menudo depende de las consideraciones políticas y de la financiación
que se asigna legislativamente.
En segundo lugar, la mayoría de estos proyectos se centran en la evaluación o prueba de
productos o servicios adquiridos de contratistas o proveedores comerciales. Debido a que el
trabajo de diseño y desarrollo en proyectos gubernamentales generalmente lo realizan
contratistas, el rol del gerente del proyecto es principalmente administrativo. Aunque ella es responsable de
controlar el progreso de los contratistas, el director del proyecto puede tener poco control sobre
los asuntos técnicos. Los gerentes de proyecto supervisan y coordinan con frecuencia múltiples
proyectos relacionados; en otras palabras, son administradores de programas.
Gestión de Proyectos Militares
La mayoría de los proyectos militares implican probar y evaluar hardware desarrollado por
contratistas. La evaluación a menudo se basa en el enfoque de "sistemas de armas" en el que
cada proyecto es parte de un programa de sistemas más grande y el hardware se evalúa por
su contribución a la misión del sistema en general. Los principales criterios para evaluar
proyectos son técnicos y políticos; los costos son de menor importancia; el beneficio no es una
consideración. Cada contratista civil tiene un director de proyecto que trabaja con un director
de proyecto militar. Estos últimos son oficiales militares y, debido a sus períodos de servicio
limitados, por lo general no supervisan un proyecto en su totalidad.
Las siguientes secciones describen situaciones donde la gestión de proyectos es más

común: desarrollo de nuevos productos y sistemas, construcción, servicios y obras del sector
público.
1.8 Proyectos de desarrollo de nuevos productos y sistemas
El desarrollo de cada nuevo producto y sistema es un proyecto. Los ejemplos incluyen

proyectos para desarrollar productos (como electrodomésticos, maquinaria industrial y
computadoras) y sistemas para defensa, aeroespacial, energía y telecomunicaciones. Los
proyectos en medicina y productos farmacéuticos incluyen el desarrollo de nuevos
medicamentos, procedimientos médicos y equipos médicos.
Los proyectos en TI/TIC incluyen el desarrollo de sistemas de información y productos de
software.
Cuando el desarrollo de nuevos productos y sistemas comprende nuevas tecnologías, las
primeras fases de los proyectos suelen implicar pruebas y experimentación. Aunque el
objetivo principal de cada proyecto es crear un producto o sistema de nuevo diseño, el
entregable real del proyecto podría ser el producto o sistema físico, o simplemente documentos
que muestren el diseño del producto o cómo producirlo. Todos estos proyectos tienen un
importante componente de ingeniería; los ejemplos descritos en el Capítulo 2 entrarían en
esta categoría.
Los siguientes son dos ejemplos de proyectos de desarrollo de productos y sistemas.
Ver Capítulo 2
11
SpaceShipOne y el concurso X-Prize
En abril de 2003, SpaceShipOne (SS1) y su nave nodriza White Knight se presentaron al

público. Simultáneamente, se anunció que SS1 participaría en la competencia X-Prize de $10
millones contra otros 23 equipos de siete países para ser el primer vehículo tripulado en
realizar con éxito dos viajes al espacio en menos de 2 semanas (Figura 1.2). Se reconoce
internacionalmente que el espacio comienza a los 100 km, o unas 62 millas (los aviones
comerciales vuelan a una altura de unos 8 km). La creación del célebre ingeniero aeroespacial
y visionario Burt Rutan y la culminación de casi 8 años de trabajo de diseño y desarrollo, fue
solo el primer paso en el sueño más amplio de Rutan de construir vehículos para transportar
pasajeros de pago.
en el espacio. El principal desafío de Rutan no fue solo ganar el premio, sino diseñar y construir un sistema de
lanzamiento espacial completo (nave espacial, vehículo de lanzamiento aéreo, motor de cohete y todos los
subsistemas de apoyo) sin tener que hacer muchos cientos de ingenieros y muchos millones de dólares en apoyo del
gobierno. eso. Rutan intentaría hacerlo con su propia empresa de 130 personas, un puñado de subcontratistas y el
respaldo de 25 millones de dólares del multimillonario Paul Allen, cofundador de Microsoft.
Figura 1.2 SpaceShipOne debajo de su nave nodriza, White Knight.
Foto: Vuelo 16P taxi antes del lanzamiento, foto de D Ramey Logan; http://creativecommons.org/licenses/by-sa/4.0/.
Además de Rutan y Allen, los principales interesados en el programa incluyeron la Fundación Ansari, Sir Richard
Branson y la FAA (Administración Federal de Aviación). La Fundación Ansari es el patrocinador del concurso X-Prize.
Su objetivo a largo plazo es impulsar las innovaciones que harán que los viajes espaciales sean seguros, asequibles
y accesibles para todos, y los requisitos del X-Prize eran para “un programa no financiado por el gobierno para llevar
a tres personas de forma segura al espacio dos veces en 2 semanas”. con una nave espacial reutilizable”. Sir Richard
Branson, fundador de Virgin Group, es el cliente del programa; su plan es comprar naves espaciales y la tecnología
asociada para su nueva aerolínea espacial, Virgin Galactic. Branson ha estimado que Virgin podrá obtener ganancias
si puede llevar 3,000 clientes a

suborbitar durante un período de 5 años a alrededor de $ 190,000 por boleto, para incluir
controles médicos, 3 días de capacitación previa al vuelo, asientos moldeados a medida y 5
minutos de flotación ingrávida mientras está en el espacio. (En comparación, un viaje civil a
bordo de la Estación Espacial Internacional cuesta alrededor de $ 50 millones). Los pasajeros
que pagan son otro grupo de partes interesadas. Aunque ninguno estaría a bordo del SS1, el
vehículo fue diseñado pensando en ellos. Por ejemplo, la cabina del SS1 está diseñada para
proporcionar un ambiente de "manga de camisa" para que los pasajeros no tengan que usar
trajes espaciales. La FAA también es una parte interesada; impone una larga lista de requisitos
necesarios para que la nave espacial sea “certificada” y comercialmente viable.
Como en la mayoría de los proyectos técnicos, un director de proyecto compartió la
supervisión del proyecto con un ingeniero de proyecto. El ingeniero del proyecto fue responsable
de identificar los requisitos técnicos y supervisar el trabajo de diseño, la integración del sistema
y las pruebas. Todo esto, y lo que le queda por hacer al director del proyecto, se aclarará en
capítulos posteriores.
12
El desarrollo del "Producto J" en Dalian Company
El futuro de Dalian Company depende de su capacidad para desarrollar y comercializar

continuamente nuevos productos. Dalian se especializa en aditivos para alimentos y bebidas,
pero es representante de empresas en industrias como la farmacéutica, los productos
alimenticios, la biotecnología, los electrodomésticos y comerciales, la electrónica informática y
de entretenimiento y las comunicaciones que deben generar continuamente nuevos productos
para sobrevivir en un entorno competitivo.
Dalian Company estaba preocupada por mantener la participación de mercado de su
"Producto H", pero sabía que los competidores estaban desarrollando sustitutos para el
Producto H que podrían ser menos costosos. Para vencer a la competencia, Dalian tuvo que
desarrollar su propio sustituto mejorado, el "Producto J".
El proceso de desarrollo de productos en Dalian es facilitado por el Departamento de
Desarrollo de Nuevos Productos. El departamento es responsable de gestionar y coordinar
todos los proyectos de desarrollo contratados interna y externamente; su propósito es garantizar
que se puedan desarrollar buenas ideas y llevarlas rápidamente al mercado. El departamento
tiene tres directores que son los gerentes de proyecto. Los directores facilitan, coordinan y
monitorean los esfuerzos del proyecto de los diversos
departamentos: investigación y desarrollo, ingeniería, marketing, fabricación y legal.
Para cada nuevo concepto de producto se crea un equipo con representantes de los
departamentos funcionales. Un director trabaja con el equipo para evaluar el progreso y los
requisitos del proyecto. Los gerentes funcionales deciden qué se debe hacer y cómo, pero
los directores tienen la última palabra sobre la dirección del proyecto. Los directores siempre
conocen el estado de sus proyectos e informan cualquier problema o demora a los gerentes
de nivel superior que administran los proyectos como una "cartera" (es decir, son gerentes
de cartera). Los proyectos que enfrentan grandes problemas o señales de fracaso se
cancelan para que los recursos puedan asignarse a proyectos más prometedores.
Similar a todos los desarrollos de nuevos productos, el desarrollo del “Producto J” involucró
la participación de varios departamentos: I+D desarrolló un prototipo de producto y preparó
especificaciones; la ingeniería definió dónde y de qué manera se usaría el producto; el
marketing definía el mercado comercial y determinaba cómo posicionar el producto;
fabricación desarrolló un nuevo proceso para fabricar el producto que sería difícil de copiar
para los competidores; finanzas determinó el costo inicial del producto y realizó pronósticos
de pérdidas y ganancias; y legal obtuvo la aprobación regulatoria y realizó investigación de
patentes.
El director del "Producto J" estuvo involucrado desde la concepción del proyecto. Trabajó
con científicos de I+D y expertos en marketing para determinar la viabilidad del proyecto y
participó activamente en la obtención de la aprobación de la alta dirección. Trabajó con
científicos y gerentes para preparar planes y cronogramas de proyectos. Cuando se
necesitaba mano de obra, equipos, instrumentos o materias primas adicionales, escribía
solicitudes de fondos. Cuando se necesitaban personas adicionales, escribía solicitudes de
personal a la alta dirección. Durante el proyecto, programó y presidió reuniones de revisión
del proyecto y emitió informes de progreso mensuales y trimestrales.
1.9 Proyectos de Construcción
Al igual que en el desarrollo de nuevos productos y sistemas, los proyectos de construcción a

menudo tienen una parte frontal dedicada al diseño de arquitectura/ingeniería seguida de una
parte final para la fabricación y la construcción. Esto es típico para la mayoría de los proyectos
de construcción, ya sea para nuevos edificios, infraestructura de transporte (carreteras,
puentes, sistemas ferroviarios, puertos, aeropuertos), fábricas, instalaciones de petróleo y gas,
represas, minas y plantas de energía renovable y servicios públicos. Cuando se realizan con
fines de lucro, dichos proyectos se clasifican como proyectos de gastos de capital. A lo largo
de este libro hay ejemplos de gestión de proyectos en la construcción, por ejemplo: Caso 8.2,
el Proyecto Chunnel; Caso 9.1, Gran Excavación; Caso 10.1, Ópera de Sídney; Caso 10.3,
Puente Nelson Mandela; y Caso 19.1, Fundición de Aluminio Mozal. Estos casos describen
grandes proyectos. El siguiente estudio de caso ilustra la gestión de proyectos en un proyecto
más pequeño.
Pequeños proyectos en Delamir Roofing Company
Delamir Roofing Company instala y repara techos para fábricas y empresas.

Al igual que otras empresas relacionadas con la industria de la construcción, Delamir considera
cada trabajo como un proyecto y asigna un gerente de proyecto para supervisarlo.
La participación del director del proyecto comienza cuando se recibe una solicitud de trabajo
de un cliente potencial. El director del proyecto examina los planos para determinar cuánto
material y tiempo de mano de obra se necesitarán (llamado "preparación del trabajo") y luego
prepara un presupuesto y una breve propuesta. Después de que se firma el contrato, el gerente
del proyecto visita el sitio antes que el equipo para hacer arreglos y acomodaciones para que
comience el trabajo. El gerente del proyecto tiene discreción en la selección del equipo de
trabajo para garantizar que el tamaño y las habilidades del equipo se ajusten
los requisitos del trabajo. Una vez que comienza el trabajo, es responsable no solo de la
supervisión del trabajo y la entrega de suministros, sino también de mantener registros del
presupuesto e informar el progreso a la oficina central. El gerente del proyecto realiza la
inspección final con el cliente y firma cuando se completa el trabajo. General,
su responsabilidad es ver que el trabajo se haga bien.

1.10 Proyectos del Sector Servicios
La gestión de proyectos se emplea en una amplia gama de servicios, incluidos la banca, la

consultoría, los seguros, los servicios fiscales nacionales, las bolsas de valores y la contabilidad,
e incluye proyectos para desarrollar nuevos sistemas y procesos de servicios. Los siguientes
dos ejemplos muestran cómo se usa en una auditoría corporativa y en una campaña de
recaudación de fondos sin fines de lucro.
13
Auditoría en CPAone
Las grandes auditorías realizadas por la división de auditoría de CPAone requieren la

participación de muchas personas. En la auditoría de una corporación nacional, por ejemplo, se
necesitan numerosos auditores con diversas especialidades para investigar todos los aspectos
de las operaciones en varias áreas geográficas. Dada la cantidad de personas y la variedad de
habilidades, experiencia y personalidades involucradas, se necesita un gerente de proyecto
para supervisar la auditoría. Cada auditoría comienza asignando al cliente a un socio que esté
familiarizado con el negocio del cliente. El socio se convierte en el “director del proyecto” de la
auditoría y es responsable del inicio, la dotación de personal, la programación y el presupuesto
del proyecto.
El director del proyecto comienza estudiando el estado de resultados, el balance general y
otros estados financieros del cliente. Si el cliente tiene una mala reputación financiera, el director
del proyecto puede tomar la decisión de que CPAone rechace la auditoría. Si el cliente es
aceptado, el director prepara una propuesta que explica el enfoque general para realizar la
auditoría y designa la fecha de finalización y el
costo estimado.
Al determinar el enfoque general para realizar la auditoría, el director del proyecto considera
el tamaño de la empresa y el número de departamentos. Luego, los auditores se asignan
departamento por departamento. El equipo de auditoría es un equipo de proyecto puro, creado
de nuevo para cada auditoría, compuesto por personas que tienen las habilidades que mejor se
adaptan a las necesidades de la auditoría. Generalmente, cada equipo de auditoría tiene uno o
dos contadores de planta y uno o dos contadores senior. Durante la auditoría el
El director supervisa todo el trabajo para garantizar que cumpla con el Libro de Normas de
Auditoría y se complete a tiempo. Cada semana, el cliente y el director del proyecto se reúnen
para revisar el progreso. Cuando los problemas no se pueden resolver de inmediato, el director
puede llamar a personas de las divisiones de impuestos o consultoría de CPAone. Si el IRS
(Servicio de Impuestos Internos) solicita un examen después de que se complete la auditoría,
el director del proyecto se asegura de que el cliente esté representado.
14
Proyecto de campaña de recaudación de fondos sin fines de lucro: Arquidiócesis de Boston
La Arquidiócesis de Boston contrató a American Services Company, una firma consultora de

recaudación de fondos para organizaciones sin fines de lucro, para administrar una campaña
de 3 años para recaudar $30 millones para educación, servicios sociales y de atención médica,
renovaciones de edificios y un fondo de jubilación para clérigos. American Services nombró a
un gerente de proyecto para preparar la estrategia de la campaña y organizar y dirigir al
personal de la campaña. El director del proyecto tuvo que trabajar con tres grupos de partes
interesadas: los donantes, la Junta Directiva de la Arquidiócesis y los voluntarios de la campaña.
Los donantes objetivo potenciales tenían que ser identificados y proporcionados con evidencia
para mostrar cómo sus compromisos financieros beneficiarían a la comunidad y la Arquidiócesis;
la junta y el liderazgo de la iglesia tenían que participar y mantenerse informados sobre la
planificación y el progreso de la campaña; y los voluntarios tenían que ser identificados,
organizados y motivados.
Una de las primeras tareas del administrador del proyecto fue realizar un estudio de
factibilidad para determinar si había suficiente capacidad de liderazgo, voluntad de voluntariado
y “profundidad de donantes” dentro de la comunidad de la Arquidiócesis para lograr la meta de
$30 millones. El estudio indicó que la meta era alcanzable y se invitó a los párrocos a un
almuerzo de lanzamiento en el que el Cardenal de la Arquidiócesis presentó la campaña.
Durante la reunión, se inscribió al personal influyente de la iglesia y se inició el proceso de
identificación de posibles donantes y voluntarios.
El gerente del proyecto brindó orientación para establecer un equipo de liderazgo de

campaña y una oficina de proyecto, reclutar voluntarios, formar comités de campaña y reclutar
y capacitar voluntarios. Además de las cuestiones organizativas, convocó varias “sesiones de
realidad” con los presidentes para recordarles la
importancia de la campaña y renovar su compromiso con el objetivo de la campaña,

y organizaron reuniones frecuentes con los voluntarios para infundirles un sentido de
orgullo y participación en la campaña.
1.11 Proyectos y Programas del Sector Público y

Gubernamentales
Los dos ejemplos siguientes ilustran cómo se lleva a cabo la gestión de proyectos y programas en
grandes empresas del sector público y empresas conjuntas gubernamentales/comerciales.
Recuperación de desastres
Los esfuerzos de asistencia de ayuda, limpieza, reconstrucción y regreso a la normalidad después de

un desastre involucran el trabajo de numerosas organizaciones. Un gran desastre como el tsunami de
diciembre de 2004 en el Océano Índico afecta a muchos países y requiere el apoyo y los esfuerzos
coordinados de los gobiernos anfitriones, las agencias no gubernamentales (ONG), las empresas
locales, las organizaciones religiosas y comunitarias, y la ayuda internacional, organizaciones benéficas
y organizaciones de financiación.
Casi por definición, la recuperación posterior a un desastre es un programa, o varios programas,
una serie de esfuerzos dedicados a los objetivos de rescatar y brindar ayuda inmediata a las víctimas
y, en última instancia, devolver a la normalidad la vida de las personas en las áreas afectadas. Cada
programa involucra muchos proyectos para abordar los múltiples aspectos de un esfuerzo de
15
recuperación, incluidos proyectos para proporcionar:
• Rescate inmediato de víctimas

• Alimentos y atención médica
• Refugio y vivienda temporal • Ropa,

frazadas y otras necesidades físicas inmediatas • Asistencia social,
moral y espiritual.
Idealmente, la recuperación ante desastres se trata como un esfuerzo organizado y coordinado, un

programa administrado con numerosos proyectos, que permite una evaluación rápida del alcance de
la situación, la identificación y organización de los recursos necesarios y disponibles, y el despliegue
efectivo de esos recursos. Para que todo eso suceda se requiere liderazgo, generalmente en la persona
de alguien con excepcionalmente fuerte
habilidades de organización y liderazgo—en efecto, un líder de programa. Sin embargo, en el caos

y el frenesí que siguen inmediatamente a un desastre, a menudo no está claro quién está a cargo.
De hecho, la respuesta inmediata deficiente y los esfuerzos confusos de rescate y recuperación
en Nueva Orleans y la región costera del Golfo de EE. UU. que la rodea después del huracán
Katrina se han atribuido a la falta de liderazgo y gestión coordinada en todos los niveles de
gobierno: federal, estatal y local.
En los meses y años posteriores a un desastre, la atención se centra en obtener y asignar
fondos de ayuda; reconstrucción, redesarrollo y reconstrucción (infraestructura, organizaciones,
instalaciones); ubicar permanentemente (regresar a casa o reubicarse) a las víctimas; tratamiento
de desechos y escombros; y proporcionando oportunidades, empleos y apoyo continuo. Para
lograr esto se requieren numerosos proyectos, por ejemplo, para obtener y asignar asistencia
financiera a personas, empresas y gobiernos locales, y proporcionar viviendas y materiales de
construcción subsidiados. A menudo, el objetivo es emplear a las víctimas en muchos proyectos
intensivos en mano de obra a pequeña escala para proporcionar empleos e ingresos.
Por ejemplo, el tsunami de diciembre de 2004 causó graves daños en las zonas costeras de
Sri Lanka, Tailandia, Indonesia, las Maldivas y otros países del Océano Índico, y solo en la India
afectó a unos 2,7 millones de personas que ya eran pobres, el 80 % de cuyos medios de
subsistencia dependía de la pesca y el 15 por ciento de la agricultura. El gobierno de India lanzó
el Proyecto de Reconstrucción de Emergencia por Tsunami, con un costo estimado de US $ 682,8
millones, para ayudar a reparar o reconstruir alrededor de 140,000 casas dañadas en dos regiones
costeras y ayudar con la reconstrucción de edificios públicos y la reactivación de los medios de
subsistencia en la pesca y la agricultura. de proyectos, lleva muchos años y continúa mientras
dure la financiación. Es un proyecto, un programa en realidad, que consta de muchos cientos
dieciséis
17
Gestión de proyectos y programas de la NASA
La NASA ha tenido una exitosa historia de trabajo en asociación con investigadores en

universidades, la industria y el ejército. La NASA y la industria trabajan en estrecha colaboración
en los problemas técnicos, pero las iniciativas técnicas y las decisiones técnicas las toman las
instalaciones de campo de la NASA.
La organización de la NASA incluye (1) alta dirección, (2) apoyo funcional para la parte superior
administración, (3) oficinas de programas para desarrollar y controlar programas principales, y

(4) instalaciones de campo, que llevan a cabo los programas y sus proyectos, ya sea en el sitio
o en universidades para contratistas. La NASA se divide en cuatro misiones
direcciones u oficinas: Sistemas de Exploración, Operaciones Espaciales, Ciencias e
Investigación Aeronáutica, que se muestran en la Figura 1.3.
Cada dirección es responsable del desarrollo, la justificación y la gestión de los programas
que respaldan los objetivos amplios de la NASA. A las direcciones se les asignan instalaciones
de campo para realizar actividades permanentes para la dirección, pero, aún así, también
realizan proyectos o tareas bajo la dirección de otras direcciones. Por ejemplo, aunque Ames
informa a Science, también contribuye a proyectos de operaciones espaciales.
En un proyecto típico de una agencia gubernamental ajena a la NASA, la agencia prepara

las especificaciones para un programa, firma un contrato y luego depende del contratista para
obtener los resultados. La NASA utiliza un enfoque diferente, ya que es probable que ninguna
empresa tenga toda la capacidad para ejecutar un proyecto grande. Aunque la NASA depende
de la industria para construir, integrar y probar el hardware, depende de su propia competencia
técnica y de administración interna para monitorear y trabajar con los contratistas.
Debido a que los proyectos de la NASA exigen una diversidad de competencias técnicas y
gerenciales, los gerentes de proyectos practican la filosofía de "responsabilidad participativa":
una integración de la competencia técnica y gerencial en la industria, la academia y los
laboratorios de la NASA. Independientemente de la ubicación, la NASA trae expertos de sus
propias instalaciones de campo, universidades y otros laboratorios gubernamentales para
ayudar a los contratistas a abordar problemas difíciles. Este enfoque de equipo participativo
evita los retrasos habituales causados por trabajar a través de los límites que separan las
organizaciones gubernamentales y comerciales. El concepto utiliza el trabajo en equipo, el
control central y la ejecución descentralizada, pero respeta el estado semiautónomo de las
instalaciones de campo de la NASA.
La NASA define un programa como una serie de proyectos que, a lo largo de varios años,
están diseñados para lograr amplios objetivos científicos o técnicos. Define un proyecto como
una empresa dentro de un programa con un comienzo y un final programados, y normalmente
implica el diseño, la construcción y/o la operación y el soporte de elementos de hardware
específicos.
La NASA utiliza un sistema dual de responsabilidad. El mayor contribuyente al éxito de un

proyecto es la persona sobre la que recae la responsabilidad final, el proyecto
gerente. Ella es la oficial responsable de ejecutar el proyecto dentro de las pautas y

controles de la NASA, y de la supervisión, ejecución y finalización diaria de los
proyectos. Aunque la mayoría de los trabajadores de un proyecto están fuera de la
autoridad administrativa del director del proyecto, siguen sus instrucciones sobre
cualquier asunto del proyecto.
Figura 1.3 Programa y organigrama de la NASA.
Cada director de proyecto tiene una contraparte en Washington, el director de

programa, que es el funcionario superior de la NASA responsable de desarrollar y
administrar las directrices y controles de la sede con respecto a un proyecto
determinado. Debe pelear las batallas por la asignación de recursos dentro de la sede,
trabajar con todas las organizaciones que participan en el proyecto, relacionar el
proyecto con los objetivos más amplios de la NASA y testificar o justificar las
autorizaciones del Congreso o del Presidente. El éxito de un proyecto depende de que
los directores de proyecto y de programa trabajen juntos y de la calidad de su relación.
Un ejemplo es el Caso 17.4, el Programa de Exploración de Mercurio.
Ver Capítulo 17
1.12 Proyectos Misceláneos

Si todavía se pregunta acerca de las innumerables situaciones en las que se aplica la gestión de
proyectos, siga leyendo.
Mantenimiento
Todas las instalaciones y máquinas importantes requieren trabajos de mantenimiento que toman
proporciones de proyecto, desde pequeñas reparaciones y trabajos de mantenimiento preventivo
hasta cierres programados de grandes instalaciones como plantas químicas y plantas generadoras
de energía. Los aviones se retiran del servicio después de un cierto número de horas de vuelo, se
desmontan hasta el nivel de los componentes, se inspeccionan y se reemplazan, reparan o
reconstruyen partes. Proyectos como este ponen las instalaciones y el equipo fuera de servicio y
requieren que la gestión del proyecto haga un trabajo de calidad, rápido.
Eventos
En la Introducción se mencionan campañas políticas y de recaudación de fondos, e incluso bodas.

Dichos proyectos, si son pequeños, se pueden manejar sin la gestión de proyectos, pero a medida
que crecen en tamaño y complejidad, también lo hacen los méritos de utilizar la gestión de proyectos.
Muchos eventos deportivos importantes, como los Juegos Olímpicos, ciertamente necesitan gerentes
de proyecto, pero también los más pequeños, como los campeonatos de liga. El caso 9.2, la Copa
Mundial FIFA 2010, es un ejemplo.
Implementación del cambio
Cualquier forma de esfuerzo de cambio a gran escala es un proyecto. Los ejemplos incluyen la
implementación de una nueva estrategia corporativa, la mejora de las disposiciones de seguridad y
salud en el lugar de trabajo y el establecimiento de una nueva unidad de negocios. Las aplicaciones
de la gestión de proyectos a dichos proyectos se ilustran a lo largo de este libro; ver por
ejemplo: Caso 1.2: Sistema de Beneficios Flexibles, y Caso 3.1: Centro Médico de la Universidad
de la Costa Oeste.
1.13 Resumen
El aspecto más importante de la gestión de proyectos es el director del proyecto, la persona que
funciona para unificar la planificación, las comunicaciones, el control y la dirección relacionados con
el proyecto para lograr los objetivos del proyecto. El gerente de proyecto es el integrador que une los
esfuerzos de las áreas funcionales, los proveedores y los contratistas, y mantiene informados a la alta
gerencia y al cliente sobre el progreso del proyecto. La gestión de proyectos incluye muchas cosas,
pero en particular la organización, los sistemas y los procedimientos que permiten al director del
proyecto planificar, organizar, dirigir e integrar todo lo necesario para lograr los objetivos del proyecto.
La gestión de proyectos se puede aplicar a cualquier actividad temporal orientada a objetivos, pero
se vuelve más esencial a medida que aumenta la magnitud, la falta de familiaridad y el interés de la
empresa. Las organizaciones que se encuentran en entornos empresariales y tecnológicos que
cambian rápidamente necesitan especialmente la gestión de proyectos.
La gestión de proyectos adopta una variedad de formas, como formas puras de gestión de
proyectos, matrices y programas. Las empresas orientadas al consumidor utilizan formas de gestión
de productos y nuevas empresas que son similares a la gestión básica de proyectos. La gestión de
proyectos se aplica de la misma manera en proyectos comerciales, sin fines de lucro, gubernamentales
y militares, con variaciones para tener en cuenta las diferencias en los entornos.
La gestión de proyectos es un "enfoque de sistemas" para la gestión. El siguiente capítulo amplía

ese concepto y analiza la filosofía y las metodologías de sistemas que subyacen en gran parte de la
teoría y la práctica de la gestión de proyectos.
1. Hacer una película y llevar a cabo una misión espacial son proyectos costosos realizados
por equipos y sujetos a restricciones presupuestarias y de cronograma. La experiencia
técnica para aterrizar una nave espacial en un planeta es similar a la requerida para crear
la ilusión de una nave espacial aterrizando en una película. Utilice el modelo NTCP descrito
en la Introducción para indicar las formas en que difieren los dos tipos de proyectos.
2. Describa cinco funciones de la administración. ¿Alguno de estos no son realizados por los
gerentes? ¿Cómo crees que entra en juego cada una de estas funciones en el transcurso
de un proyecto?
3. Enumere las principales características de los “proyectos”. ¿Cómo distinguen estas
características los proyectos de otras actividades ajenas al proyecto?
4. ¿Cuáles son las características de la “gestión de proyectos”? Compare estos con los tipos
funcionales y otros tipos de gestión que no son de proyectos.
5. ¿Qué hace que la gestión de proyectos sea más adecuada para los entornos de proyectos
que la gestión y organización tradicionales?
6. ¿Dónde se originaron los métodos y la organización de la gestión de proyectos?
¿Qué sucedió durante el siglo XX que hizo necesaria la gestión de proyectos?
7. ¿Qué cinco criterios sugieren Cleland y King para determinar cuándo utilizar la gestión de
proyectos? De estos, describa brevemente cómo un gerente debe saber cuándo la gestión
de proyectos es apropiada para la tarea.
8. ¿Cuándo es evidente que la gestión de proyectos no es adecuada? Enumere algunas
actividades de "tipo de proyecto" en las que cree que no se debe utilizar la gestión de
proyectos. Describa las organizaciones o los tipos de trabajo en los que son apropiados
tanto los tipos de gestión de proyectos como los que no son de proyectos.
9. Compare y contraste brevemente las siguientes formas de gestión de proyectos: proyecto
puro, matriz, programa, nueva empresa, producto y cartera. Proporcione al menos una
ilustración de una organización donde se utilice cada uno.
10. ¿Cuáles son algunos de los problemas de ser un líder de proyecto comercial,
proyectos gubernamentales y militares? ¿De dónde obtienen líderes de proyecto

las organizaciones en estos entornos?
11. En los ejemplos de la industria, el sector de servicios y el gobierno de este capítulo,
¿qué características comunes del entorno, las metas del proyecto y las tareas del
proyecto hacen que la gestión del proyecto sea apropiada (o necesaria)?
Además, ¿cuáles parecen ser las características comunes de los roles y
responsabilidades de los gerentes de proyecto en estos ejemplos? ¿Cuáles son
las diferencias?
12. Ahora que sabe un poco sobre proyectos y gestión de proyectos, enumere algunas
organizaciones gubernamentales y privadas en las que cree que la gestión de
proyectos podría ser útil. Es posible que desee verificar si, de hecho, están
utilizando la gestión de proyectos.
Preguntas sobre el proyecto de estudio
1. En el proyecto que está estudiando, ¿qué características de la empresa, los objetivos

del proyecto, las tareas o la experiencia necesaria hacen que el uso de la gestión
de proyectos sea adecuado o inadecuado? Considere el tamaño del proyecto, la
complejidad, el riesgo y otros criterios al responder esta pregunta.
2. ¿Cómo encaja el proyecto que estás estudiando en la definición de proyecto?
3. ¿Qué tipo de gestión de proyectos se utiliza: programa, producto, nueva empresa u
otro? Explique. ¿Se llama "gestión de proyectos" o algo más?
4. ¿Qué funciones cumple el director del proyecto? ¿Cuál es su título?

5. ¿En qué forma(s) la industria del proyecto de estudio difiere de otras industrias
descritas en el capítulo? ¿Tienen las diferencias un efecto sobre cómo se gestionan
los proyectos?
18
Caso 1.1 Recuperación de desastres en Marshall Field's
Una mañana temprano, los sótanos del distrito central de negocios del centro de
Chicago comenzaron a inundarse. Se había desarrollado un agujero del tamaño de un
automóvil entre el río y un túnel abandonado adyacente. El túnel, construido a principios
del siglo XX para transportar carbón, recorre todo el centro de la ciudad.
Cuando el túnel se inundó, también lo hicieron los sótanos de los edificios conectados
a él, unos 272 en total, incluido el del importante minorista Marshall Field's.
El problema se notó por primera vez a las 5:30 am cuando un miembro de la mesa
de problemas de Marshall Field vio que el agua entraba en el sótano. Notificó al gerente
de mantenimiento, quien se comunicó de inmediato con los Departamentos de Agua y
Bomberos de Chicago y con la empresa matriz de Marshall Field, Dayton Hudson en
Minneapolis. La electricidad, y con ella todos los servicios de ascensores, computadoras,
comunicaciones y seguridad para el edificio de 15 pisos, pronto se perdería. El edificio
fue evacuado y los ascensores se movieron arriba
niveles de sótano. Se instaló un puesto de comando y se formó un equipo de varios departamentos,

como instalaciones, seguridad, recursos humanos, relaciones públicas y servicios financieros,
legales, de seguros y de apoyo. Más tarde ese día, miembros del grupo de gestión de riesgos de
Dayton Hudson llegaron desde Minneapolis para hacerse cargo de la coordinación de los esfuerzos
del equipo. El objetivo del equipo era garantizar la seguridad de los empleados y clientes, minimizar
los daños por inundaciones y reanudar las operaciones normales lo antes posible. Esperaban
reabrir la tienda a los clientes en una semana.
Se hizo un intento de bombear el agua; sin embargo, mientras el agujero del túnel permaneciera
sin reparar, el río Chicago continuó regresando a los sótanos. Así, los sótanos permanecieron
inundados hasta que se selló el túnel y el Cuerpo de Ingenieros del Ejército dio el visto bueno para
iniciar el bombeo.
Todo en el sótano del segundo nivel fue una pérdida, incluidos los equipos de seguridad,
calefacción, ventilación, aire acondicionado, rociadores contra incendios y servicios mecánicos. La
mayoría de las mercancías en el sótano del primer nivel.
También se perdieron almacenes.
Los electricistas trabajaron las 24 horas para instalar generadores de emergencia y restaurar la
iluminación y el servicio de ascensores. Se contrataron oficiales de seguridad adicionales.
Se instaló un sistema de bombeo de emergencia y una nueva tubería al tanque de aspersión de
agua para poder reactivar el sistema de aspersión. Se tomaron medidas para monitorear la
ventilación y la calidad del aire, y se instalaron deshumidificadores y ventiladores para mejorar la
calidad del aire. Dentro de la semana, los inspectores de la Ciudad de Chicago y OSHA
(Administración de Salud y Seguridad Ocupacional) dieron su aprobación para reabrir la tienda.
Después de drenar el agua de los sótanos de Marshall Field, la mercancía dañada se retiró y
se vendió a un salvador. El segundo sótano tuvo que ser vaciado para asegurar la eliminación de
contaminantes. La maquinaria recuperable tuvo que ser desmontada y desinfectada.
Se evaluó el alcance de los daños y se presentaron reclamaciones de seguros. Se contrató a

una empresa constructora para gestionar la restauración de las áreas dañadas. A lo largo de la
terrible experiencia, el departamento de relaciones públicas trató con los medios de comunicación,
siendo sincero pero mostrando confianza en el esfuerzo de recuperación.
Los clientes tenían que estar seguros de que la tienda estaba segura. El equipo que supervisaba
la recuperación se reunía dos veces por semana para evaluar el progreso y tomar decisiones, luego
se disolvió lentamente a medida que la tienda se recuperaba.
Este caso ilustra la gestión de crisis, un elemento importante del cual es tener un equipo que pueda moverse
rápido para minimizar las pérdidas y recuperar rápidamente los daños. Al comienzo de un desastre, hay poco tiempo
para planificar, aunque las empresas y las agencias públicas suelen tener pautas de crisis para responder a
situaciones de emergencia. Cuando ocurre una emergencia, desarrollan planes más específicos y detallados para
guiar los esfuerzos de recuperación a corto y largo plazo.

Preguntas
1. ¿De qué manera es un proyecto el esfuerzo de recuperación de desastres por inundación de
Marshall Field? ¿Por qué son proyectos de esfuerzos de recuperación y respuesta ante
desastres a gran escala?
2. ¿De qué manera las características de la gestión de crisis descritas en este caso
corresponden a las de la gestión de proyectos?
3. ¿Quién(es) era(n) el(los) director(es) del proyecto y cuál era su(s) responsabilidad(es)?
¿Quién fue asignado al equipo del proyecto y por qué estaban en el equipo?
4. Comente sobre la idoneidad de utilizar la gestión de proyectos para

administrar esfuerzos de recuperación de desastres como este.
5. ¿A qué forma de gestión de proyectos (básica, de programas, etc.) se parece más este caso?
Caso 1.2 Implementación del Sistema de Beneficios

Flexibles en el Centro Médico Shah
19 Alam
La alta gerencia del Centro Médico Shah Alam decidió adquirir e implementar un nuevo sistema que
reduciría el costo y mejoraría el servicio de la cobertura de beneficios para empleados. El nuevo
sistema tendría que cumplir cuatro objetivos: mayor capacidad de respuesta a las necesidades de los
empleados, mayor flexibilidad en los beneficios, mejor administración de costos y mayor coordinación
de los objetivos de recursos humanos con las estrategias comerciales. Se formó un equipo multifuncional
de 13 miembros con representantes de cuatro departamentos—Recursos Humanos (HR), Sistemas
Financieros (FS) y Servicios de Información (IS)—y seis
expertos técnicos de la consultora de Hun and Bar Software (HBS).

Al comienzo del proyecto, se llevó a cabo un taller con participantes de Shah Alam y
HBS para aclarar y finalizar los objetivos del proyecto y desarrollar un plan, hitos y
cronograma del proyecto. La finalización del proyecto se fijó en 10 meses. En ese
tiempo, HBS tuvo que desarrollar y suministrar todo el hardware y software para el
nuevo sistema; el sistema tuvo que ser puesto en línea, probado y aprobado; Los
trabajadores de recursos humanos debían recibir capacitación sobre cómo operar el
sistema y cargar los datos existentes de los empleados; todos los empleados de Shah
Alam tuvieron que ser educados e inscritos en el nuevo proceso de beneficios; y los
datos de inscripción tenían que ser ingresados en el sistema.
El director de FS fue elegido para supervisar el proyecto. Tenía la formación técnica
y había trabajado anteriormente en el grupo IS en la implementación del sistema de
información de atención al paciente de Shah Alam; todos en el equipo aprobaron su
nombramiento como líder del proyecto. Seleccionó a dos líderes de equipo para que la
ayudaran, uno de RR. HH. y uno de SI. La tarea del líder de recursos humanos era
garantizar que el nuevo sistema cumpliera con los requisitos de recursos humanos y las
necesidades de los empleados de Shah Alam. La tarea del líder de SI era garantizar
que el nuevo software se interconectara con otros sistemas de Shah Alam.
Los miembros del equipo de Shah Alam trabajaron en el proyecto a tiempo parcial,
dedicando aproximadamente la mitad de su tiempo al proyecto y la otra mitad a sus
tareas diarias normales. El director del proyecto y los jefes de equipo también trabajaron
a tiempo parcial en el proyecto, aunque cada uno le dio prioridad al proyecto.
La alta gerencia de Shah Alam había dejado en claro que cumplir con los requisitos del
proyecto y los plazos era imperativo. El gerente del proyecto recibió autoridad sobre los
gerentes funcionales y los miembros del equipo del proyecto para todas las decisiones
relacionadas con el proyecto.
Preguntas
1. ¿A qué forma de gestión de proyectos (básica, de programa, etc.) se parece

más este caso?
2. El gerente del proyecto también es el director de FS, uno de varios
departamentos que se verán afectados por el nuevo sistema de beneficios.
¿Parece una buena idea? ¿Cuáles son los pros y los contras de que ella sea
seleccionada?
3. Comente sobre la asignación de tiempo parcial de los miembros del equipo al
proyecto y la expectativa de que le den la máxima prioridad al proyecto.
4. Gran parte del éxito de este proyecto depende del desempeño de los
miembros del equipo que no son empleados de Shah Alam, a saber, los
consultores de HBS. Deben desarrollar todo el sistema de prestaciones
hardware/software. ¿Por qué probablemente se eligió una empresa externa
para una parte tan importante del proyecto? ¿Qué dificultades podría plantear
esto al director del proyecto para cumplir los objetivos del proyecto?
Notas finales
1. Adaptado de Szilagyi A. Management and Performance, 2.ª ed. Glenview, IL: Scott, capataz; 1984;
págs. 7–10, 16–20, 29–32.
2. Partes de esta sección están adaptadas de Cleland D. y King W. Systems Analysis and Project
Gestión, 3ª ed. Nueva York, NY: McGraw-Hill; 1983, págs. 191–192.
3. Partes de esta sección están adaptadas de Johnson R., Kast F. y Rosenzweig J. The Theory and
Gestión de Sistemas, 3ª ed. Nueva York, NY: McGraw-Hill; 1973, págs. 395–397.
4. Cleland y King, Análisis de sistemas y gestión de proyectos, pág. 259.
5. Basado en el ejército comercial de Hofer W. Lady Liberty. Negocios de la Nación julio; 1983: 18–28.
6. Sharad D. La dirección por proyectos, un avance ideológico. Revista de Gestión de Proyectos Marzo;
1986: 61–63.
7. Adams J., Barndt S. y Martin M. Gestión por gestión de proyectos. Dayton, OH: Universal
Tecnología; 1979, págs. 12 y 13.
8. Instituto de Gestión de Proyectos. El Estándar para la Gestión de Programas, 3ª ed. Newton Square, Pensilvania:
PMI; 2013; Oficina de Comercio del Gobierno. Gestión de Programas Exitosos (MSP). Reino Unido: El
Oficina de papelería; 2007.
9. Instituto de Gestión de Proyectos. El Estándar para la Gestión de Portafolios, 3ra ed. Newton Square, Pensilvania:
PMI; 2013; Oficina de Comercio del Gobierno. Gestión de Carteras. Reino Unido: The Stationery Office; 2011.
10. Esta sección es una adaptación de Roman D. Management Projects: A Systems Approach. Nueva York, NY: Elsevier,
1986; págs. 426–429, con autorización del editor.
11. Este y los ejemplos de capítulos posteriores de SpaceShipOne ilustran conceptos. Mucha información objetiva sobre el
proyecto y los sistemas está disponible en fuentes publicadas, pero la información de diseño y desarrollo
de los sistemas es confidencial. SpaceShipOne, el X-Prize y las partes interesadas descritas son de la vida real,
pero por falta de información, partes de este ejemplo y los siguientes son hipotéticos.
12. Basado en información compilada por Jenny Harrison a partir de entrevistas con gerentes en Dalian
Empresa (empresa de hecho, nombre ficticio).
13. Basado en información compilada por Darlene Capodice de entrevistas con gerentes en el
firma contable (compañía de hecho, nombre ficticio).
14. Información sobre este proyecto aportada por Daniel Molson, Mike Billish, May Cumba, Jesper Larson,
Anne Lanagan, Madeleine Pember y Diane Petrozzo.
15. Respuesta a desastres. Lección 7: Apoyo a Operaciones de Emergencia. Universidad de Wisconsin, Desastre
Centro de gestión, http://dmc.engr.wisc.edu/courses/response/BB08-07.html.
16. India: Proyecto de Reconstrucción de Emergencia por Tsunami. El Grupo del Banco Mundial, 3 de mayo de 2005, Comunicado de prensa
No: 453/SAR/2005, ReliefWeb, http://www.reliefweb.int/rw/RWB.NSF/db900SID/VBOL-6C3CF8?
Abrir documento&rc=3&cc=ind
17. Partes de esta sección están adaptadas de Chapman R. Project Management in NASA: The System and
Los hombres. Washington, DC: NASA SP-324, NTIS No. N75-15692; 1973.
18. Información sobre este caso aportada por Jennifer Koziol, Sussan Arias, Linda Clausen, Gilbert Rogers,
y Nidia Sakac.
19. Información sobre este caso aportada por Debbie Tomczak, Bill Baginski, Terry Bradley, Brad Carlson,
y Tom Delaney. Los nombres de las organizaciones son ficticios, pero el caso es real.
Capítulo 2
Enfoque de sistemas
Un proyecto puede conceptualizarse como un sistema de personas, equipos, materiales

e instalaciones organizado y administrado para lograr una meta. Gran parte de la teoría
y la práctica establecidas sobre lo que se necesita para organizar y coordinar un
proyecto proviene de una perspectiva llamada "enfoque de sistemas". Al mismo tiempo,
el trabajo realizado en proyectos a menudo se realiza con el propósito de crear
sistemas, y dichos proyectos comúnmente emplean metodologías como "análisis de
sistemas" e "ingeniería de sistemas". Este capítulo introduce conceptos que forman la
base para la gestión de proyectos y las metodologías de sistemas utilizadas en proyectos técnicos.
2.1 Sistemas y pensamiento sistémico
Por definición, el término sistema se refiere a “un todo organizado o complejo; un conjunto de
cosas o partes que interactúan de manera coordinada”. Las piezas pueden ser jugadores de
un equipo de fútbol, teclas de un teclado o componentes de una máquina.
Las partes pueden ser entidades físicas o pueden ser abstractas o conceptuales, como
palabras en un idioma o pasos en un procedimiento. Más allá de ser un “ensamblaje de
1
partes”, sin embargo, un sistema tiene otras tres características:
1. Partes del sistema afectan al sistema y son afectadas por él.

2. El ensamblaje de partes hace algo; sirve a un propósito o meta.
3. El conjunto es de especial interés.
La primera característica significa que, en un sistema, el todo es más que la suma de las
partes. El cuerpo humano, por ejemplo, se compone de componentes separados: el hígado,
el cerebro, el corazón, las fibras nerviosas, etc.; sin embargo, si alguno de estos se quita del
cuerpo, tanto ellos como el cuerpo cambiarán. Las partes del cuerpo no pueden vivir fuera del
cuerpo, y sin las partes, el cuerpo tampoco puede vivir. La idea de que las partes afectan al
todo y viceversa es fundamental para el pensamiento sistémico.
La segunda característica de los sistemas es que las partes trabajan en combinación para
hacer algo. Lo que hacen generalmente se puede observar en las salidas del sistema o la
forma en que el sistema convierte las entradas en salidas (aunque a veces ese proceso de
conversión puede ser bastante oscuro). En un sistema hecho por humanos, las partes están
diseñadas para interactuar para lograr algún propósito o meta.
Tercero, los sistemas son concebidos por las personas que los miran, lo que significa que
existen en el ojo (o la mente) del espectador. de 2 Lo que esto dice es que la concepción
un sistema puede ser alterado para adaptarse al propósito de uno. Por ejemplo, al diagnosticar
la enfermedad de un paciente, un médico puede ver todo el cuerpo humano como “el sistema”.
El médico puede enviar al paciente a un especialista, que solo ve el tracto digestivo como “el
sistema”. Si el diagnóstico es intoxicación alimentaria y el paciente presenta una demanda,
su abogado podría ampliar la vista del "sistema" para incluir el restaurante donde comió el
paciente por última vez.
El pensamiento sistémico es una forma particular de ver el mundo, su característica clave

es un enfoque en "el panorama general: todo el sistema u organismo", en lugar de solo las
partes del sistema. Los pensadores de sistemas también observan las partes y tratan de
comprender las relaciones entre ellas, pero siempre dan un paso atrás para ver cómo encajan
las partes en el todo. 3 El pensamiento
en unasistémico significa
situación; ser capaz
tomar una de percibir
situación el “sistema”
aparentemente
confusa y caótica y percibir algún grado de orden o armonía en ella. Como tal, es una forma
útil de lidiar con sistemas complejos creados por humanos y esfuerzos como proyectos
grandes.
Aunque los gerentes de proyecto deben estar familiarizados y ser capaces de coordinar
las partes individuales del proyecto, la mayor parte de la responsabilidad de cada una de
esas partes se delega a los gerentes y técnicos que se especializan en ellas. Los gerentes
de proyecto se preocupan por el “panorama general”: el proyecto completo con sus objetivos,
tareas de trabajo y las personas involucradas; como tales, deben ser pensadores de sistemas.
2.2 Conceptos y principios de los sistemas
Los siguientes conceptos y principios se aplican a todos los sistemas.
Metas y objetivos
Los sistemas hechos por humanos están diseñados para hacer algo; tienen metas y objetivos
que son concebidos por personas. Para las intenciones de este libro, una meta se define como
una declaración amplia y global del propósito de un sistema, y un objetivo como una declaración
de propósito más detallada, generalmente cuantificable, perteneciente a algún aspecto del
sistema. La meta del sistema se cumple logrando un grupo de objetivos del sistema.
Un proyecto puede conceptualizarse como un sistema que existe con el propósito de crear un
sistema hecho por humanos. El objetivo del proyecto puede definirse como, por ejemplo,
“construir una estación espacial por $15 mil millones en 10 años”. Comenzando con la meta, el
proyecto se puede definir en términos de muchos objetivos, como "seleccionar el diseño general
para la estación", "seleccionar los principales contratistas", "entrenar a la tripulación", "poner
componentes en órbita", "ensamblar componentes" “haz un proyecto por un costo de $15 mil
millones”, y así sucesivamente. Los objetivos se pueden dividir en objetivos más detallados y
específicos denominados requisitos. Los requisitos son los criterios específicos a los que el
sistema y sus partes deben ajustarse para que el sistema cumpla con sus metas y objetivos
generales.
Elementos y Subsistemas
Cualquier sistema se puede dividir en partes más pequeñas. Estas partes en combinación
forman “el conjunto de partes” que constituye el sistema. La parte más pequeña de un sistema
es un elemento. Un sistema también se puede dividir en partes que son en sí mismas sistemas,
llamados subsistemas. Un subsistema es un sistema que funciona como un componente de un
sistema más grande. Cuando no es necesario comprender su funcionamiento interno, un
subsistema puede considerarse simplemente como un elemento. Figura 2.1, una
organigrama común, ilustra esto: el subsistema de producción puede ser visto como un
“elemento” en la empresa; sin embargo, si optamos por profundizar en él, la producción
se convierte en un subsistema con elementos de programación, fabricación e inventario.
Cada uno de estos elementos podría a su vez ser visto como un subsistema que
contiene elementos. En un proyecto, un elemento puede ser una unidad de trabajo, una
persona o un grupo que realiza el trabajo, o un componente del artículo final producido
por el proyecto.
Figura 2.1 Una empresa representada en términos de sistemas, subsistemas y elementos.
Atributos
Todos los sistemas, subsistemas y elementos tienen características distintivas denominadas

atributos; estos describen la condición de los sistemas, subsistemas y elementos en
términos cualitativos o cuantitativos. En los sistemas creados por humanos, los atributos
están diseñados en el sistema para que funcione según lo requerido. A menudo, los
atributos de un sistema y sus componentes se supervisan para realizar un seguimiento del
comportamiento y el rendimiento del sistema. En un proyecto, el tiempo y el costo son
atributos universales de la mayoría de sus elementos, y se les da seguimiento para evaluar
el desempeño del proyecto.
Entorno y Límite
El término ambiente se refiere a cualquier cosa fuera del sistema que influya en el
comportamiento o resultado del sistema. En los sistemas hechos por humanos,
generalmente se refiere a cosas sobre las cuales los diseñadores y administradores de
sistemas no tienen control. El medio ambiente puede incluir, por ejemplo, la comunidad o
sociedad en la que vivimos, el aire que respiramos o las personas con las que nos
relacionamos, aunque no es necesariamente ninguno de estos. Un sistema está separado
de su entorno por una frontera. En muchos sistemas, el límite es algo oscuro y es difícil
separar el sistema de su entorno. Para determinar qué es el entorno, haga las preguntas
"¿Puedo hacer algo al respecto?" y “¿Es relevante para el sistema y sus objetivos?” Si la
respuesta es "no" a la primera pregunta pero "sí" a la segunda, entonces "eso" es parte del
entorno. La siguiente tabla muestra cómo distinguir un sistema de su entorno:
¿Es relevante para el sistema?

sí No
Sí Sistema ¿Pueden Irrelevante

los diseñadores o administradores del sistema controlarlo?
Sin Medio Ambiente Medio Ambiente
El “entorno irrelevante” incluye todas las cosas que no influyen en el sistema y que no
importan. Para un director de proyecto, el planeta Júpiter está en el entorno irrelevante, a
menos que su proyecto sea enviar una sonda espacial allí, en cuyo caso Júpiter es
relevante y, por lo tanto, parte del entorno del proyecto. De ahora en adelante, la mención
del medio ambiente siempre se referirá al medio ambiente relevante—
factores que importan y afectan al sistema de alguna manera, pero con los que hay que
vivir.
Estructura del sistema
Los elementos y subsistemas están vinculados entre sí por relaciones. La forma que
adoptan las relaciones se denomina estructura del sistema. El funcionamiento y la eficacia
de un sistema están determinados en gran medida por la "adecuación" de la estructura al
objetivo o propósito del sistema. La mayoría de los sistemas complejos tienen estructuras
jerárquicas que consisten en niveles organizados de subelementos dentro de elementos,
elementos dentro de subsistemas, etc.
La Figura 2.2 es un ejemplo de una estructura jerárquica. Muestra un proyecto como
una jerarquía de tareas y responsabilidades. El elemento X representa todo el proyecto;
los elementos A, B y C son áreas de trabajo o divisiones de gestión en el proyecto; los
elementos a a g son tareas de trabajo específicas. La estructura implica que las tareas a,
b y c están incluidas en la división de gestión A, las tareas d y e están en la división B, y
así sucesivamente. Esta estructura se denomina estructura de descomposición del trabajo
y se explica con más detalle en el Capítulo 5.
Ver Capítulo 5
Entradas, Proceso, Salidas, Interfaces
Figura 2.2 Una forma de conceptualizar la estructura del proyecto.

Los sistemas logran metas y objetivos al convertir entradas en salidas a través de un proceso
definido . Esto se ilustra en la Figura 2.3. Los productos representan el resultado final de un
sistema y, en general, el propósito por el cual existe el sistema. Todos los sistemas tienen
múltiples salidas, incluidas las deseables que contribuyen a los objetivos del sistema, las
neutrales y las indeseables o inútiles que restan valor a los objetivos del sistema y/o tienen un
impacto negativo en el medio ambiente. Los subsistemas y la mayoría de los elementos
también tienen entradas y salidas.
Figura 2.3 Relación entrada-proceso-salida.
Las entradas son las materias primas, los recursos o los pasos necesarios para que el
sistema funcione y produzca salidas. Incluyen factores controlables como mano de obra,
materiales, información, capital, energía e instalaciones, así como factores incontrolables
como el clima y los fenómenos naturales (es decir, el medio ambiente). Las entradas que se
originan en el propio sistema se denominan retroalimentación. Por ejemplo, todos los sistemas
producen información; el uso de esa información para guiar el comportamiento del sistema se
denomina entrada de retroalimentación.
El proceso (también denominado función) es el medio por el cual el sistema convierte o
transforma físicamente las entradas en salidas. Un aspecto importante del diseño del sistema
es crear un proceso que produzca efectivamente los resultados deseados y cumpla con los
objetivos del sistema, pero que minimice el consumo de insumos y la producción de productos
inútiles.
En una estructura jerárquica donde los sistemas se dividen en subsistemas, cada uno de
los subsistemas tiene sus propias entradas, procesos y salidas que están interconectados de
alguna manera. En la Figura 2.2, cada uno de los elementos del proyecto genera productos,
algunos de los cuales se convierten en insumos para otros elementos. Dos elementos en los
que la salida de uno se convierte en la entrada del otro se dice que interactúan.
Restricciones y conflictos
Todos los sistemas tienen restricciones o limitaciones que inhiben su capacidad para alcanzar
metas y objetivos. A menudo, las limitaciones las impone el entorno. El tiempo y el dinero son
dos restricciones universales en los proyectos.
En los sistemas creados por humanos, y especialmente en los proyectos, los objetivos de
los subsistemas a veces están en conflicto, lo que reduce las posibilidades de que ellos o la
meta del sistema general se realicen alguna vez. La eliminación del conflicto de los objetivos
para permitir el cumplimiento de la meta del sistema general se denomina integración.
Integración
Para que un sistema logre su objetivo, todos sus elementos, el “conjunto de partes”, deben
funcionar al unísono. El diseño, la implementación y la operación de un sistema que logre sus
objetivos y requisitos preespecificados a través del funcionamiento coordinado (llamado "sin
costuras") de sus elementos y subsistemas se denomina integración del sistema. La gestión
de proyectos busca integrar tareas y recursos para lograr los objetivos del proyecto. En los
proyectos tecnológicos, la gestión de proyectos también aborda la integración de los
componentes y módulos físicos que componen el producto final del proyecto. El tema de la
integración de sistemas se cubre en el Capítulo 14.
Ver Capítulo 14
Sistemas abiertos y Sistemas cerrados
Los sistemas se pueden clasificar en cerrados o abiertos. Un sistema cerrado es aquel que se
considera autónomo, y el "pensamiento de sistemas cerrados" significa centrarse en el
funcionamiento, la estructura y los procesos internos de un sistema sin tener en cuenta el
entorno. Para algunos tipos de sistemas se aplica el pensamiento de sistema cerrado: para
comprender cómo funciona una máquina, solo necesita estudiar la máquina, sus componentes
y nada más. Esto no significa que el entorno no afecte al sistema, sino que la persona que
observa el sistema tiene
optado por ignorar el medio ambiente. Para analizar o mejorar el diseño de muchos tipos de
sistemas mecánicos, el pensamiento de sistema cerrado funciona bastante bien.
Pero, ¿qué pasa con los sistemas que interactúan y deben adaptarse al medio ambiente?
Estos son sistemas abiertos. Para comprender su comportamiento y funcionamiento, no se
puede ignorar el entorno. Dado que los sistemas mecánicos dependen de los recursos del
medio ambiente e inyectan subproductos (por ejemplo, contaminantes), en muchos casos
también deben tratarse como sistemas abiertos. De hecho, cualquier sistema que deba ser
adaptable al entorno, incluidos los proyectos, debe tratarse como un sistema abierto.
4
Organizaciones y Medio Ambiente
Como sistemas abiertos, las organizaciones humanas interactúan con las partes interesadas en
el medio ambiente (clientes, proveedores, sindicatos, accionistas, gobiernos, etc.) y dependen
del medio ambiente para obtener insumos de energía, información y material. A su vez, exportan
al medio ambiente productos, servicios y desechos (representados en la Figura 2.4).
Como sistema abierto, cualquier organización debe elegir objetivos y realizar sus operaciones
respetando las oportunidades que se presentan y las limitaciones impuestas por el entorno.
Cleland y King llaman a esto el "problema ambiental", lo que significa que un gerente debe:
5
1. apreciar la necesidad de evaluar las fuerzas en el entorno 2.

comprender las fuerzas que afectan significativamente a la organización, e 3.
integrar estas fuerzas en las metas, objetivos y objetivos de la organización
operaciones.
En la medida en que todo proyecto está influenciado por fuerzas externas, el director del
proyecto debe tratar de comprender estas fuerzas y, una vez hecho esto, ser capaz de guiar el
proyecto hacia su objetivo. Un proyecto que esté predominantemente influenciado por fuerzas
divergentes en el entorno será difícil de controlar y probablemente fracasará.
Sistemas naturales y sistemas creados por el hombre

Figura 2.4 Organización como un sistema de entrada-salida.
Los sistemas también se pueden clasificar como naturales o creados por el hombre. Sistemas
naturales originados por procesos naturales (por ejemplo, organismos y sistemas planetarios). Los
sistemas creados por humanos están diseñados y operados por personas (por ejemplo, sistemas
de comunicación y organizaciones humanas). Los proyectos son sistemas hechos por humanos
(organizaciones) creados con el propósito de crear otros sistemas hechos por humanos.
Los sistemas naturales pueden verse alterados o entrelazados con sistemas creados por el
hombre. Un ejemplo es la alteración de un sistema fluvial y la formación de un lago mediante la
construcción de una represa; otra es la alteración de la composición de la atmósfera y el ecosistema
a través del CO2 introducido por máquinas hechas por el hombre.
Los sistemas creados por el hombre están integrados y utilizan insumos de los sistemas
naturales, y ambos sistemas interactúan de manera importante y significativa. En los últimos años,
la aparición de sistemas humanos a gran escala ha tenido un impacto significativo, en su mayoría
indeseable, en el mundo natural. Los ejemplos incluyen el calentamiento global, la lluvia ácida y la
contaminación tóxica de los sistemas de agua. Tales consecuencias, denominadas “efectos
secundarios”, surgen en gran medida porque los diseñadores y usuarios de sistemas no consideran
(o eligen ignorar) los impactos de los sistemas creados por el hombre en el medio ambiente natural.
2.3 Enfoque de sistemas
El enfoque de sistemas es una forma de visualizar y analizar cosas físicas y sistemas

conceptuales, pero más que eso, es un enfoque para hacer cosas: un marco para abstraer
problemas, resolver problemas y tomar decisiones.
Marco de enfoque de sistemas
El marco del enfoque de sistemas utiliza conceptos de sistemas tales como metas y
objetivos, subsistemas, elementos, relaciones, integración y entorno. Reconoce formalmente
que el comportamiento de cualquier elemento puede afectar a otros elementos y ningún
elemento individual puede funcionar de manera efectiva sin la ayuda de los demás. Este
reconocimiento de interfaces, interdependencia y causa-efecto entre elementos es lo que
6
más distingue al enfoque de sistemas.
Los gerentes que adoptan el enfoque de sistemas reconocen la multitud de "elementos"
en los sistemas que administran y los problemas que necesitan resolver, las relaciones entre
los elementos y las influencias recíprocas entre los sistemas creados por humanos y el
medio ambiente. Como resultado, pueden comprender mejor la magnitud total de un
problema y anticipar las consecuencias de sus acciones. Esto reduce las posibilidades de
que se pasen por alto elementos importantes de una situación o las consecuencias de las
acciones.
El enfoque de sistemas mantiene la atención en el panorama general y el objetivo final;
permite centrarse en las partes del sistema, pero sólo en relación con las contribuciones de
las partes al todo. Por ejemplo, un sistema universitario puede verse como elementos
separados de estudiantes, profesores, administradores y ex alumnos, y es posible tomar
medidas con respecto a cualquiera de ellos ignorando los impactos sobre los demás y el
medio ambiente. Pero las acciones que se enfocan exclusivamente en partes del sistema
probablemente no sean óptimas para el sistema total porque ignoran las repercusiones
negativas en otras partes del sistema. Por ejemplo, aunque reducir la contratación de
profesores reduce los costos, también puede conducir a clases más grandes y hacinamiento
en las aulas, menos tiempo de los profesores para la investigación, menos becas de investigación, menor
a la universidad y, en última instancia, menores inscripciones y menos ingresos. De manera

similar, promulgar leyes es una forma de reducir la contaminación del aire, pero las leyes que
restringen la industria pueden dañar las economías locales. Cada problema está
inextricablemente unido al medio ambiente, y los intentos de resolverlo pueden causar otros
7
problemas. Churchman llama a esto la “falacia ambiental”.
Abundan los ejemplos de situaciones en las que las soluciones para una parte del sistema
han llevado a problemas peores para el conjunto. Estos incluyen tratar de reducir la congestión
del tráfico mediante la construcción de más carreteras, tratar de eliminar el abuso de drogas al
prohibir la venta y el consumo de drogas y tratar de aumentar el atractivo de las áreas silvestres
mediante la construcción de complejos turísticos en los parques nacionales. Las consecuencias
negativas de estos intentos de resolución de problemas son bien conocidas. El enfoque de
sistemas trata de evitar la falacia ambiental.
8
Forma Ordenada de Tasación
El enfoque de sistemas es una metodología para resolver problemas y administrar sistemas.

Por su naturaleza holística, evita abordar los problemas de manera limitada y frontal. Dice:
"Retrocedamos y veamos esta situación desde todos los ángulos". El solucionador de
problemas hace esto teniendo en cuenta los conceptos del sistema discutidos, a saber:
1. Las metas y objetivos del sistema.

2. El entorno del sistema.
3. Los recursos y limitaciones del sistema.
4. Los elementos del sistema, sus funciones, atributos y desempeño
medidas.
5. La interfaz e interacción entre los elementos.

6. La gestión del sistema.
El enfoque de sistemas exige un pensamiento realista sobre las metas y objetivos del sistema
y las formas reales de medirlos. La gestión de proyectos utiliza este tipo de pensamiento:
comienza con la misión o los objetivos del sistema y, a partir de ahí, organiza y dirige todo el
trabajo posterior para lograr esos objetivos. El objetivo declarado debe ser preciso y
mensurable en términos de criterios de rendimiento específicos (los requisitos del sistema).
Los criterios son la base para
clasificar soluciones alternativas o cursos de acción para un problema. En un proyecto, los

criterios para el artículo final se denominan requisitos y especificaciones del usuario , que se
explican en capítulos posteriores.
También se debe identificar el entorno del sistema (otros sistemas, grupos o personas y
sistemas naturales que afectan o son afectados por el sistema), lo que no es fácil porque las
fuerzas externas a veces están ocultas y actúan de manera insidiosa.
Mirando hacia el futuro, deben plantearse preguntas sobre los posibles cambios o innovaciones
en el entorno y cómo afectarán al sistema. El gerente del proyecto debe preguntarse, ¿qué
puede suceder en el “exterior” que afectará el proyecto y sus resultados?
También se deben identificar los recursos que se utilizarán para lograr las metas del sistema.
Estos son los activos o los medios que el sistema utiliza e influye en su beneficio; incluyen
capital, mano de obra, materiales, instalaciones y equipo. La mayoría de los recursos del
sistema son agotables. El sistema es libre de utilizarlos solo mientras estén disponibles. Cuando
los recursos se agotan, se convierten en limitaciones.
En el enfoque de sistemas, el director del proyecto considera los recursos necesarios y
disponibles para el proyecto.
El enfoque de sistemas identifica los elementos clave del sistema. En un proyecto, en realidad
hay dos sistemas, el producido por el proyecto (este es el resultado final del proyecto o elemento
final) y el que produce el elemento final (este es el proyecto en sí). Definir estos implica definir,
por un lado, los subsistemas, componentes y partes del sistema final de hardware o software
que se está produciendo y, por otro lado, las tareas de trabajo, los recursos, la organización y
los procedimientos del proyecto. Este tema se desarrolla en el Capítulo 4.
Ver Capítulo 4
La salida de un sistema resulta no solo de los elementos individuales, sino también de la

forma en que interactúan los elementos. Por lo tanto, diseñar un nuevo sistema o resolver
problemas en un sistema natural o creado por el hombre requiere comprender la forma en que
los elementos interactúan. Los diseñadores usan "modelos" del sistema para ayudar a
comprender cómo interactúan los elementos y cómo la alteración de los elementos y sus
relaciones impactan el comportamiento y los resultados del sistema.
Finalmente, el enfoque de sistemas presta atención explícita a la gestión de los
sistema, es decir, a su planificación y control, teniendo en cuenta sus objetivos, entorno y

limitaciones, recursos, etc. Este es precisamente el papel de la gestión de proyectos.
Los conceptos anteriores no se abordan necesariamente en la secuencia en que se enumeran.

En realidad, es posible que sea necesario tratar cada concepto varias veces antes de que se
describa completamente y se defina con claridad. Más importante aún, cada concepto sirve para
sugerir numerosas preguntas abiertas que ayudan a investigar los 9 ¿Cuáles son las metas, objetivos
¿Qué funciones
y criterios?
debe¿Cuáles
realizar son
cadalosuno?
elementos? sistema: ¿Cuáles son las relaciones entre ellos?
¿Cuáles son los recursos? ¿Cuáles son las compensaciones entre los recursos?
Modelos de sistemas
Los pensadores sistémicos usan "modelos" para ayudar a comprender los sistemas y evaluar planes
y soluciones alternativas frente a los objetivos. Un modelo es una representación simplificada de un
sistema; abstrae las características esenciales del sistema bajo estudio. Puede ser un modelo físico,
una formulación matemática, una simulación por computadora o una simple lista de verificación. Un
ejemplo de un modelo físico es un modelo de avión. Es una abstracción reducida del sistema real.
Incluye algunos aspectos del sistema (configuración y forma de los componentes exteriores) y
excluye otros (componentes interiores y tripulación). Otro tipo de modelo es un modelo conceptual;
representa los elementos, la estructura y los flujos de un sistema. El modelo conceptual de la figura
2.5, por ejemplo, ayuda a los demógrafos a comprender las relaciones entre los elementos que
contribuyen al tamaño de la población ya hacer predicciones.
10
Los modelos se utilizan para realizar experimentos y pruebas. Muchos sistemas hechos por
humanos son demasiado caros o arriesgados para hacer experimentos de la "vida real". El modelo
permite evaluar varias alternativas y sus consecuencias antes de comprometerse con una decisión.
Los ingenieros utilizan modelos de aviones en pruebas de túnel de viento, por ejemplo, para probar
alternativas de diseño y medir el efecto de diferentes parámetros de diseño en el rendimiento del
avión. Un buen modelo permite a los diseñadores y analistas hacer preguntas "qué pasaría si" y
explorar los efectos de alterar las diversas entradas. Tiene en cuenta los requisitos, elementos
relevantes, recursos y limitaciones, y permite comparar las consecuencias de diferentes alternativas.
en términos de costos y beneficios. Los modelos empleados para el aseguramiento de la calidad

se analizan en el Capítulo 9.
Ver Capítulo 9
Ciclos de vida de los sistemas
Figura 2.5 Un modelo de sector de población generalizado.
Los sistemas naturales y creados por el hombre cambian con el tiempo de una manera que tiende
a ser sistemática y evolutiva, y tipos de sistemas similares siguen ciclos de evolución similares.
Un ciclo básico, el de todos los organismos, es el patrón de concepción, nacimiento, crecimiento,
madurez, senectud y muerte. Cada uno de estos puede considerarse como una "etapa" o evento
de la vida. Históricamente, incluso las civilizaciones y sociedades han seguido este patrón. Los
sistemas electromecánicos no vivos también siguen un ciclo con las etapas de diseño, fabricación,
instalación, quemado, operación normal y deterioro u obsolescencia. De manera similar, todos los
productos siguen un ciclo: el "ciclo de vida del producto", que consta de las etapas de concepción,
diseño, desarrollo, producción, lanzamiento al mercado, captura de participación en el mercado,
luego declive y
discontinuación. Los productos como los teléfonos celulares pueden tener ciclos de vida de solo meses; otros
11 Como
(Kool-Aid y Levi's jeans) tienen ciclos de décadas.
mencionados en el Capítulo 1, prácticamente todos los sistemas creados por humanos comienzan como proyectos,
y la mayoría de los proyectos también siguen un ciclo llamado ciclo de vida del proyecto. 12 Esto es
discutido en el Capítulo 3.
Ver Capítulo 3
2.4 Ingeniería de Sistemas
La ingeniería de sistemas, una aplicación del enfoque de sistemas, se define como “la
ciencia del diseño de sistemas complejos en su totalidad para asegurar que los
subsistemas que componen el sistema se diseñen, ajusten, verifiquen y operen de la
13
manera más eficiente”. Se refiere a la concepción,
diseño y desarrollo de un sistema complejo en el que los componentes mismos deben
diseñarse, desarrollarse e integrarse juntos para cumplir los objetivos del sistema. La
ingeniería de sistemas es una forma de crear un sistema completo y dar cuenta de todo
su ciclo de vida, incluida la operación y el desmantelamiento, durante su concepción y
diseño iniciales.
Todos los sistemas van
Un ejemplo de ingeniería de sistemas es el diseño y operación de un vehículo espacial.

La expresión "todos los sistemas funcionan", popularizada durante los primeros vuelos
espaciales de EE. UU., significa que el sistema general de millones de componentes que
componen el vehículo espacial y sus sistemas de apoyo, y los cientos de personas en
sus equipos técnicos y de gestión, está listo. “ir” para lograr los objetivos de la misión.
Para llegar al punto de que “todos los sistemas funcionan”, los planificadores primero
deben haber definido el sistema general y sus objetivos. Los diseñadores deben haber
analizado los requisitos del sistema y desglosarlos en requisitos específicos y detallados,
y haber diseñado los componentes y subsistemas que cumplen con los requisitos. Luego
deben haber construido y combinado los componentes en subsistemas, y el subsistema
en el sistema total de vehículos espaciales, propulsores de cohetes, instalaciones de
lanzamiento, apoyo en tierra, selección y capacitación de la tripulación, y capacidad
técnica y de gestión. Al final, a cada componente y persona se le debe asignar un rol e
integrarse en un subsistema que se ha integrado en el sistema general.
La ingeniería de sistemas se aplica a cualquier sistema (hardware o software) que
deba desarrollarse (tal vez desde cero), implementarse y operarse para cumplir algún
propósito futuro inmediato o continuo. Se pueden encontrar fácilmente ejemplos en el
diseño e implementación de sistemas locales, nacionales y globales para comunicación, transporte,

purificación y suministro de agua, generación y transmisión de energía, investigación y defensa.
Resumen14
La ingeniería de sistemas se puede describir en términos de las tres dimensiones ilustradas en la figura
2.6.
Primero, es un esfuerzo multidisciplinario. Los ingenieros de sistemas (partes responsables de la
supervisión del diseño y la construcción del sistema) trabajan con las partes interesadas del sistema para
determinar sus necesidades y lo que debe hacer el sistema para satisfacerlas. Una parte interesada es
cualquier individuo o grupo que afecta o es afectado por el sistema; las principales partes interesadas son
los clientes, los constructores y los usuarios finales.
Los clientes financian y son dueños del sistema; los constructores lo diseñan y lo crean; los usuarios lo
operan y lo mantienen. Los objetivos y necesidades de las partes interesadas son la base para determinar
los requisitos del sistema que especifican lo que hará el sistema. La práctica de involucrar a las partes
interesadas clave en las primeras fases de la concepción y el desarrollo del sistema se denomina
"ingeniería concurrente", que se analiza en los capítulos 4 y 14.
Consulte el Capítulo 4 y el Capítulo 14
En segundo lugar, la ingeniería de sistemas aborda todos los aspectos del sistema, comenzando con
el sistema completo y terminando con sus elementos individuales. Los elementos, módulos y subsistemas
del sistema están diseñados para realizar las funciones necesarias para satisfacer los objetivos y requisitos
de todo el sistema. Este aspecto de la ingeniería de sistemas se centra en cómo debe funcionar el sistema
para cumplir con los requisitos. Por supuesto, ninguno de los elementos y subsistemas funciona de forma
independiente. Todos dependen de las salidas de otras funciones y, a su vez, proporcionan entradas a
otras más; en una palabra, interactúan. La ingeniería de sistemas aborda cómo deben interactuar y las
interacciones necesarias entre ellos.
Figura 2.6 Dimensiones de la ingeniería de sistemas.
Finalmente, en la creación y desarrollo del sistema, la ingeniería de sistemas

también tiene en cuenta cómo se producirá, operará, mantendrá y finalmente eliminará
el sistema: el ciclo de vida completo del sistema, de la cuna a la tumba. Esto ayuda a
asegurar que el sistema será económico de desarrollar, construir, operar y mantener,
y amigable para los usuarios y el medio ambiente. Un enfoque de equipo
multidisciplinario que involucre a todos los actores del sistema promueve este tipo de
pensamiento de ciclo de vida.
Una vez que los ingenieros de sistemas han aprendido lo que quieren las partes
interesadas y han definido los objetivos y requisitos del sistema, buscan formas de
cumplir con los requisitos. Esto implica investigación, análisis y estudios de enfoques
alternativos para el diseño del sistema y los costos, cronogramas, riesgos y beneficios
estimados asociados con cada uno. Dice Brooks, "La parte más difícil de construir un
[el sistema] está decidiendo precisamente qué construir. Ninguna otra parte del trabajo conceptual es tan
difícil como establecer los requisitos técnicos detallados [y] ninguna otra parte del trabajo paraliza tanto el
sistema resultante si se hace mal. Ninguna otra parte es más difícil de rectificar después”. 15
Ejemplo: Sistema de Automatización Avanzada16
La pieza central del programa de la Administración Federal de Aviación (FAA) para modernizar el
sistema de control de tráfico aéreo fue el Sistema de Automatización Avanzada (AAS), que
proporcionaría a los controladores nuevas pantallas y equipos informáticos para procesar datos de
vuelo y radar. La FAA otorgó el contrato de AAS a IBM luego de una competencia de diseño de 4
años.
Los requisitos de la FAA inicialmente llenaron un libro grueso, pero a medida que avanzaba el
programa siguieron aumentando y finalmente crecieron hasta convertirse en una pila de 20 pies de altura.
A medida que crecía la cantidad de requisitos, también lo hacían los retrasos en los programas, los
costos y las tensiones entre la FAA e IBM. El Congreso se opuso, y después de 10 años y un
estimado de $1.5 mil millones canceló el programa.
Obtener las expectativas y necesidades de los operadores y usuarios y luego traducirlas en
requisitos medibles puede ser difícil para los ingenieros, razón por la cual los equipos
multidisciplinarios a veces incluyen conductistas y psicólogos. Desarrollar la cabina de vuelo para
un avión comercial, por ejemplo, incluiría las sugerencias de los pilotos, las aerolíneas, las
asociaciones de pilotos y los expertos en factores humanos. Una forma común de obtener respuestas
o sugerencias sobre un diseño propuesto es que los usuarios prueben una maqueta o un simulador
del sistema.
17
Modularización: Ciclo Iterativo de Análisis-Síntesis-Evaluación
El proceso de creación de un concepto de sistema es una serie de pasos para definir los subsistemas y
elementos que comprenderán el sistema. El proceso está ilustrado por el “modelo en V” de Forsberg y
18
Implica
Mooz en la figura 2.7. (1) análisis de arriba hacia abajo de los detalles ciclos
(es decir, iterativos de del
descomposición
sistema en partes más pequeñas),
(2) síntesis de abajo hacia arriba (construir e integrar las partes en partes sucesivamente
más grandes), y (3) evaluación (comprobar que los resultados cumplan con los requisitos).
Los sistemas se diseñan y ensamblan a partir de subsistemas que a su vez se diseñan
y ensamblan a partir de subsistemas, y así sucesivamente. La práctica, llamada
modularización, es lo que hace factible y práctico el diseño, ensamblaje y operación de
sistemas complejos. Herbert Simon da el ejemplo de un relojero que ensambla un reloj de
100 piezas. El proceso requiere concentración y requiere mucho tiempo y es costoso. Si el
reloj necesita reparación, encontrar y solucionar el problema puede ser difícil. Si en cambio
el reloj estuviera compuesto por diez módulos, cada uno con diez piezas, el montaje sería
sencillo. Si el reloj presenta algún problema, la reparación será simple: simplemente
identifique el módulo con el mal funcionamiento y reemplácelo.
19
Figura 2.7 Modelo en V de Forsberg y Mooz.
Fuente: Adoptado de Forsberg K. y Mooz H. en Ingeniería de requisitos de software, 2.ª ed., Taylor R.,
Dorfman M. y Davis A. (eds). Los Alamitos, CA: IEEE Computer Society Press; 1997, págs. 44–77.
El trazo de arriba hacia abajo de la V representa la subdivisión de las funciones del

sistema en subfunciones y requisitos. En cada nivel inferior se repite el proceso de trabajar
con los clientes para definir los requisitos, excepto que el "cliente" se convierte en la función
del siguiente nivel superior y la pregunta es: "¿Qué
deben hacer las funciones de nivel inferior para cumplir con los requisitos de la función de nivel
superior? De esta manera, se definen los requisitos para las funciones en todos los niveles.
Los sistemas se diseñan mediante el diseño de subsistemas o módulos, cada uno de los cuales
realiza una función necesaria del sistema. Las funciones son los medios por los cuales un sistema
cumple con sus objetivos y requisitos. En los sistemas cotidianos es fácil identificar los módulos y
las funciones que realizan. Una computadora de escritorio está modularizada casi por completo:
tiene un procesador y controladores, unidades y dispositivos periféricos, cada uno de los cuales
realiza una función especializada, como procesamiento de datos, almacenamiento de datos y
procesamiento de entrada/salida.
La forma en que las funciones del sistema se agrupan en módulos se denomina arquitectura
del sistema. La arquitectura de un avión es un ejemplo: un avión debe realizar varias funciones
importantes, incluidas la propulsión, la sustentación y el almacenamiento de la carga útil; los
módulos visiblemente familiares de motores, alas y fuselaje, respectivamente, cumplen estas
funciones. Pero cada función es en sí misma un compuesto de varias subfunciones, por lo que
cada módulo se compone de varios submódulos. Un ala, por ejemplo, se subdivide en alerones,
flaps, spoilers, etc., cada uno de los cuales realiza una función aerodinámica específica.
El trazo ascendente de la V representa la evaluación de "alternativas de diseño" para satisfacer

los requisitos, la implementación de decisiones de diseño, la conversión de diseños en partes
físicas, la integración de las partes y la verificación de que las partes integradas cumplen con los
requisitos. Las alternativas de diseño son las posibles soluciones a los problemas; son los cursos
de acción para cumplir con los requisitos; en última instancia, aparecen en el sistema final como
piezas de hardware y software. Las alternativas elegidas dan como resultado la adquisición o el
diseño y la construcción de componentes. Los componentes se verifican individualmente y luego
se ensamblan en módulos; los módulos se prueban, luego se combinan con otros y se vuelven a
probar.
Si las pruebas revelan que las partes o los módulos no cumplen con los requisitos, entonces el
proceso vuelve a la carrera descendente de la V para determinar por qué, y se repite el ciclo de
análisis, síntesis y evaluación. Como lo ilustran las muchas flechas discontinuas en la Figura 2.7,
el proceso avanza y retrocede dentro de cada trazo de arriba hacia abajo/de abajo hacia arriba; a
veces, durante la carrera ascendente, retrocede y vuelve a la carrera descendente.
Una regla del enfoque de sistemas es “¡No se apresure a buscar soluciones! Busque
alternativas”. Los equipos multidisciplinarios son buenos para considerar soluciones alternativas;
combinan el conocimiento de expertos en áreas dispares y pueden
generar alternativas que trascienden el área de especialización de cualquier persona o campo.

El diseño y desarrollo de sistemas técnicos complejos puede resultar molesto, pero la
ingeniería de sistemas ofrece una manera de hacerlo. En la práctica, la ingeniería de sistemas
sigue un proceso muy similar al ciclo de vida del proyecto, descrito en el Capítulo 3, y emplea
prácticas para definir sistemas, descritas en el Capítulo 4. Pero mientras que el ciclo de vida del
proyecto se aplica a proyectos genéricos, la ingeniería de sistemas se aplica de manera más
específica. a proyectos complejos, generalmente técnicos. Los pasos y herramientas que
caracterizan la ingeniería de sistemas se tratan en el Apéndice A del Capítulo 4.
Ver Capítulo 4
2.5 Gestión de proyectos: un enfoque de sistemas 20
La gestión de proyectos es un enfoque de sistemas para la gestión: está orientada al sistema

total y enfatiza el logro de la misión y los objetivos generales del proyecto; enfatiza las decisiones
que optimizan el proyecto general en lugar de los elementos o subsistemas del proyecto; y
reconoce la interacción y la sinergia entre los elementos del proyecto: que los resultados de un
elemento proporcionan insumos a otros elementos. El director del proyecto reconoce las
interacciones y las interdependencias entre los elementos del proyecto y con el entorno, y trabaja
para garantizar que las organizaciones, las responsabilidades, el conocimiento y los datos se
integren para lograr los objetivos generales del proyecto. Esto contrasta con la visión gerencial
más típica, que se enfoca estrechamente en funciones y tareas individuales y en el desempeño
de departamentos individuales, incluso a expensas de la organización total.
En Winning at Project Management, autor Robert Gilbreath 21 describe la
manera “correcta” de visualizar un proyecto. Desde la perspectiva de una persona ajena, dice,
un proyecto puede parecer algo sin partes discernibles separadas, como un barril que contiene
miles de lombrices de tierra. Obviamente, si tiene que administrar el proyecto, esa perspectiva no
es muy útil y necesita otra perspectiva, una que implica subdividir el continuo en una colección
de elementos y definir las características de cada uno. 22 Los buenos gerentes de proyecto, dice
Gilbreath, subdividen conceptualmente el proyecto
estéenbien
partes
administrada.
y se aseguran
El gerente
de quedel
cada
proyecto
parte
conoce todas las partes del proyecto y cómo cada una impacta a las demás y al proyecto en
general.
Gilbreath analiza otra característica de los gerentes de proyecto: la capacidad de "cambiar el

enfoque", para acercar el rendimiento de elementos discretos, luego alejar y verificar la dirección
y el rendimiento del proyecto en general. La vista de alejamiento es esencial porque le permite al
director del proyecto dirigir el proyecto hacia sus objetivos y no obsesionarse con las piezas. ser
23
una persona de visión general que sabe cómo En
equilibrar
otras palabras,
el enfoque
el entre
director
losdel
elementos
proyectotécnicos
necesita
del proyecto y los aspectos administrativos de los cronogramas, presupuestos y relaciones
humanas. La capacidad de acercar y alejar, para ver y saber qué es
importante para el panorama general: esa es la esencia del enfoque de sistemas.

Ya sea que lo llame o no el "enfoque de sistemas", el punto es que, al administrar un
proyecto, es útil pensar en un proyecto como un sistema.
2.6 Resumen
Un sistema es un ensamblaje de partes donde (1) las partes se ven afectadas por
estar en el sistema, (2) el ensamblaje hace algo y (3) el ensamblaje tiene un interés
particular. Lo que se llama “el sistema” depende del punto de vista y propósito de
cada uno. Los proyectos son sistemas creados con el propósito de hacer sistemas.
El pensamiento sistémico es una forma de abordar fenómenos complejos. Imparte
la capacidad de discernir un grado de orden y estructura en una situación
aparentemente confusa o caótica. El pensamiento sistémico incluye el "enfoque de
sistemas", que es una forma de conceptualizar entidades físicas y abordar problemas.
Los componentes principales del enfoque de sistemas son (1) los objetivos y los
criterios de desempeño del sistema, (2) el entorno y las restricciones del sistema, (3)
los recursos del sistema, (4) los elementos del sistema, sus funciones , atributos y
medidas de rendimiento, (5) la interacción entre los elementos, y (6) la gestión del
sistema. Para el desarrollo y operación de grandes sistemas técnicos, el enfoque de
sistemas se implementa a través de la metodología de ingeniería de sistemas.
La Parte I de este libro le ha dado una visión general de la gestión de proyectos.

Los proyectos tienen una duración finita: tienen un comienzo y un final. Lo que
sucede en el medio, las etapas de tareas y actividades, tiende a ser notablemente
similar, independientemente del tipo de proyecto. Estas etapas son análogas a las
etapas del ciclo de vida del sistema y se mencionaron en los ejemplos del Capítulo
1. La Parte II analiza estas etapas y describe un marco para llevar a cabo proyectos:
el ciclo de desarrollo de sistemas.
1. ¿Qué distingue al pensamiento sistémico del pensamiento analítico? ¿Sistemas pensando

en algo nuevo o es solo otra perspectiva?
Explique.
2. Defina "sistema". ¿Qué características notables le permiten ver algo como un sistema?
Describa brevemente el sistema legal o educativo estadounidense en términos de estas
características.
3. ¿Cómo pueden varias personas que miran la misma cosa ver el "sistema" en ella?
¿diferentemente?
4. Defina los siguientes conceptos y explique cómo encajan en el pensamiento sistémico:

objetivos, elementos, subsistemas, atributos, entorno, límites, estructura, entradas, salidas,
procesos y restricciones.
5. Describir la diferencia entre sistemas abiertos y cerrados, y entre sistemas naturales y
creados por el hombre. ¿Todos los sistemas naturales son sistemas abiertos?
6. ¿Es un vehículo espacial un sistema abierto? ¿Es una organización un sistema abierto?
Explique.
7. Describa el enfoque de sistemas. ¿Dónde se aplica el enfoque de sistemas?
Explique en una oración lo que hace un gerente en el enfoque de sistemas que no podría
hacer de otra manera.
8. ¿Qué es la “falacia ambiental”?
9. ¿Qué cosas tiene en cuenta el solucionador de problemas al aplicar el
¿enfoque de sistemas?
10. Describa cómo los siguientes elementos del enfoque de sistemas se aplican a los proyectos
y la gestión de proyectos: objetivos, entorno, recursos, subsistemas y gestión.
11. Dé algunos ejemplos de modelos físicos; de modelos gráficos; de modelos matemáticos.
12. ¿Qué es el ciclo de vida de los sistemas? ¿Qué es el ciclo de desarrollo de sistemas?
13. Analice la dimensión de la ingeniería de sistemas en la figura 2.6.
14. ¿Qué es la modularización? ¿Cuáles son sus beneficios en el diseño del sistema y
¿operación?
15. En ingeniería de sistemas la primera etapa es la identificación. Identificacion de
¿qué?
16. ¿Quiénes son los interesados en la ingeniería de sistemas?
17. ¿Qué son los requisitos? ¿Qué aspectos del sistema o parte interesada
necesidades deben incorporar los requisitos?
18. Distinguir los requisitos de las partes interesadas y los requisitos del sistema.
19. ¿Por qué la gestión de proyectos es un enfoque de sistemas?
20. ¿Cuál es la relevancia del enfoque de sistemas para la gestión de proyectos?
1. Conceptualice la organización del proyecto (el equipo del proyecto y la organización

principal del equipo) que está estudiando como un sistema. ¿Cuáles son los
elementos, atributos, entorno, etc.? ¿Cuáles son sus subsistemas internos:
desglose funcional y subsistemas de jerarquía gerencial? ¿Cuál es el entorno
relevante? ¿Quiénes son los que toman las decisiones?
2. Describa el papel del director del proyecto con respecto a estos subsistemas, tanto
internos como externos. ¿Cuál es la naturaleza de sus responsabilidades en estos
subsistemas? ¿Qué tan consciente es el gerente del proyecto del “entorno” del
proyecto y qué hace él o ella que refleja este conocimiento?
3. Ahora, conceptualice el resultado o el elemento final del proyecto como un sistema.

Una vez más, concéntrese en los elementos, las relaciones, los atributos, los
subsistemas, el entorno, etc. Todos los proyectos, ya sea que estén dirigidos a
fabricar un producto físico (p. ej., una computadora, una estación espacial, un
rascacielos, un informe de investigación) o un servicio (p. ej., dar consultas y
consejos), se dedican a producir sistemas. Este ejercicio le ayudará a entender
mejor lo que está haciendo el proyecto. También es una buena preparación para
los temas del próximo capítulo.
4. Si el proyecto de estudio implica ingeniería o integración de muchos componentes,
¿se utilizó el proceso de ingeniería de sistemas? ¿Hay una sección, departamento
o tarea en el proyecto llamada ingeniería de sistemas? Si es así, elabore. ¿Hay
funciones o fases del proyecto que parecen parecerse al proceso de ingeniería de
sistemas?
5. Como se describe en este capítulo, además del elemento final principal o sistema
operativo (es decir, el objetivo de salida del proyecto), la ingeniería de sistemas
también aborda el sistema de soporte, el sistema que respalda la instalación,
operación, mantenimiento, evaluación y mejora. del sistema operativo. Describir el
sistema de apoyo en el proyecto de estudio y su desarrollo.
6. ¿Se definieron claramente los requisitos de las partes interesadas al comienzo del proyecto?
¿Se definieron claramente los requisitos del sistema? ¿Qué son los requerimientos? En su
opinión, ¿se identificaron e involucraron a las partes interesadas en las primeras etapas del
proyecto? ¿Se identificaron y abordaron sus necesidades?
¿Entregó el proyecto un sistema que satisfizo sus necesidades?
Caso 2.1 Distrito Sanitario del Condado de Glades
El condado de Glades es una región de la Costa del Golfo con una población de 600.000 habitantes.
Alrededor del 90 por ciento de la población se encuentra en y cerca de la ciudad de Sitkus.
Los principales atractivos de la zona son sus limpias playas de arena y la pesca cercana. Los centros
turísticos, los restaurantes, los hoteles, las tiendas minoristas y la economía del condado de Sitkus/
Glades en general dependen de estas atracciones para los dólares de los turistas.
En la última década, el condado de Glades ha experimentado una casi duplicación de la población
y la industria. Un resultado ha sido el aumento notable en el nivel de contaminación del agua a lo
largo de la costa debido principalmente al aumento de aguas residuales sin tratar vertidas por el
condado de Glades en el Golfo. Por lo general, el sistema de alcantarillado del condado de Glades
dirige los desechos efluentes a través de plantas de filtración antes de bombearlos al Golfo. Aunque
el Distrito Sanitario del Condado de Glades (GCSD) generalmente puede manejar las aguas
residuales del condado, durante las fuertes lluvias, la escorrentía de las superficies pavimentadas
excede la capacidad del alcantarillado y debe desviarse más allá de las plantas de filtración y
directamente hacia el Golfo. Después de las fuertes lluvias, las playas están llenas de peces muertos
y escombros. El comercio pesquero del Golfo también se ve afectado ya que la contaminación
ahuyenta a los peces deseables. Recientemente, el nivel de contaminación del agua se ha vuelto lo
suficientemente alto como para dañar tanto el comercio turístico como el pesquero. Además de la
contaminación costera, también existe la preocupación de que, a medida que la población continúa
aumentando, la principal fuente de agua dulce del condado, el río Glades, también se contaminará.
El GCSD recibió el mandato de preparar un programa integral de gestión de aguas residuales

que revertirá la tendencia de la contaminación a lo largo de la Costa del Golfo y manejará el aumento
esperado en los desechos efluentes durante los próximos 20 años. Aunque aún no se especifica, se
sabe que el programa
incluir nuevas alcantarillas, plantas de filtración y leyes más estrictas contra la

contaminación. Como primer paso, GCSD debe establecer la dirección general y la misión de la
programa.
Preguntas
Responda las siguientes preguntas (dada la información limitada, está bien adelantar
algunas conjeturas lógicas; si no puede responder una pregunta por falta de información,
indique cómo y dónde, como ingeniero de sistemas, la obtendría):
1. ¿Qué es el sistema? ¿Cuáles son sus elementos y subsistemas clave?

¿Qué son los límites y cómo se determinan? ¿Qué es el medio ambiente?
2. ¿Quiénes son los que toman las decisiones?
3. ¿Cuál es el problema? Formularlo cuidadosamente.

4. Definir el objetivo general del programa de gestión de aguas residuales. Debido
a que el programa tiene un amplio alcance, debe dividirlo en varios subobjetivos.
5. Definir los criterios o medidas de desempeño que se utilizarán para determinar

si se están cumpliendo los objetivos del programa.
Especifique varios criterios para cada subobjetivo. En la medida de lo posible,
los criterios deben ser cuantitativos, aunque también deben incluirse algunas
medidas cualitativas. ¿Cómo sabrá si los criterios que define son los
apropiados para usar?
6. ¿Cuáles son los recursos y las limitaciones?
7. Explique los tipos de alternativas y el rango de soluciones para resolver el

problema.
8. Discuta algunas técnicas que podrían usarse para ayudar a evaluar qué
alternativas son las mejores.
Caso 2.2 Vida y muerte de una aeronave

Projecto de desarrollo
Law y Callon 24 describen la historia de un gran proyecto aeroespacial británico

en términos de dos entidades: el sistema global y el proyecto en sí. El sistema
global comprendía partes y organizaciones fuera del proyecto que tenían un
interés en el proyecto; el proyecto comprendió todo dentro del proyecto, incluido
todo el trabajo y las organizaciones contratadas para hacerlo.
El Sistema Global
Los principales interesados en el sistema global fueron:
1. La Royal Air Force (RAF), que inició el proyecto con una solicitud de un nuevo
avión supersónico con capacidad de despegue corto.
El avión sería un "caza de reconocimiento y ataque táctico" llamado TSR.
2. Ministerio de Defensa (MOD), que quería un avión que se ajustara mejor a las
necesidades de defensa generales actuales de la nación.
3. El Tesoro, que quería un avión económico que fuera atractivo para el mercado
para la venta fuera del Reino Unido, como para la Royal Australian Air Force
(RAAF).
4. La Royal Navy, que quería comprar un avión diferente pero estaba
bajo presión de MOD para comprar el TSR.
5. El Ministerio de Abastecimiento (MOS), que quería un avión que sería producido
por un consorcio de varios fabricantes de fuselajes y motores del Reino Unido.
Como es típico en la mayoría de los proyectos, cada parte interesada en el sistema

global conceptualizó el proyecto de manera diferente: para la RAF y el MOD, produciría
un avión para una misión específica; al Tesoro encajaría el presupuesto de defensa y
generaría ingresos; para la Marina era una amenaza competitiva para el avión que
realmente querían; y para el MOS era un instrumento de política industrial. Las partes
tenían distintas razones para aportar recursos y apoyo: algunas eran económicas (a
cambio de los fondos, se construiría un avión); algunos políticos (a cambio de una
necesidad demostrada, las objeciones de la Armada serían anuladas); algunos técnicos
(a cambio del esfuerzo técnico y de ingeniería, la aeronave cumpliría con los requisitos
de rendimiento de la RAF); y algunos industriales (a cambio de contratos, se consolidaría
la industria aeronáutica).
El proyecto
El Tesoro no aprobaría la financiación del proyecto hasta que se definieran el
diseño básico, el fabricante, el costo y la fecha de entrega de la aeronave. La
RAF y el MOD enviaron solicitudes a la industria aeronáutica de ideas de diseño
y seleccionaron dos fabricantes; Vickers Corp. e English Electric (EE).
Favorecieron a Vickers por su capacidad de integración (combinando aviones,
motores, armamentos y equipos de apoyo en un solo paquete de armas), pero
también les gustó EE por su experiencia en el diseño de aviones supersónicos.
Entonces decidieron contratar a ambas compañías y adoptar un diseño que
utilizaría características de ambas. La idea fue aprobada por todas las demás
partes del sistema global y se liberaron los fondos para el proyecto.
El proyecto creció a medida que Vickers y EE contrataron subcontratistas y
ampliaron sus equipos de diseño, producción y gestión. Las dos empresas y
varios otros contratistas se fusionaron para formar una nueva organización única
llamada British Aircraft Corporation (BAC).
Relaciones entre el Sistema Global y el

Proyecto
A medida que el proyecto creció, también lo hicieron los problemas entre él y el sistema global.
MOS quería un control centralizado sobre todos los aspectos del proyecto y todas las
transacciones entre el proyecto y las partes interesadas en el sistema global.
Aunque BAC era el contratista principal y aparentemente responsable de administrar el
proyecto, MOS no le conferiría la autoridad administrativa necesaria. Más bien, MOS formó
una serie de comités con miembros del sistema global y les dio la responsabilidad principal de
administrar el proyecto. Esto generó serios problemas:
1. Los comités podían tomar o vetar decisiones importantes relacionadas con el

proyecto. Ellos, no BAC, otorgaron importantes contratos; cuando la RAF quiso
cambiar sus requisitos, consultó con los comités, no con BAC.
2. Los comités a menudo carecían de suficiente información o conocimiento.

Los comités técnicos tomaron decisiones sin tener en cuenta los costos; los comités
de costes tomaban decisiones sin tener en cuenta las realidades técnicas.
Decisiones enfocadas en aspectos particulares del proyecto; rara vez tuvieron en
cuenta los impactos en otras partes del proyecto o en el proyecto en su conjunto.
Creció la desconfianza entre BAC y MOS; ninguno fue capaz de integrar de manera efectiva
los recursos, la información y las decisiones que fluyen entre las partes en el proyecto y el
sistema global. Los subcontratistas se volvieron difíciles de controlar. Muchos ignoraron a BAC
y trabajaron solo con MOS y RAF para obtener un trato favorable.
Sistema global remodelado
Todos sabían que el proyecto estaba en problemas. Los costos del proyecto
se duplicaron. Uno de los motores de prueba explotó y la RAF reconoció que
llevaría años comprender la causa. Además, la RAAF anunció que no
ordenaría el TSR, sino que compraría el F-111 fabricado en EE. UU. La
oposición al proyecto creció y en las próximas elecciones generales, el
Partido Laborista prometió que, de ser elegido, revisaría el proyecto. Cuando
ganó el Partido Laborista, inmediatamente comenzó una evaluación del
proyecto, que incluía comparar el TSR con el F-111, que ahora se considera
una alternativa al TSR. A medida que continuaron los sobrecostos y los
retrasos en los cronogramas, MOS retiró lentamente el apoyo. Luego, la RAF
retiró su apoyo cuando descubrió que el F-111, que ya estaba en producción,
cumpliría con todos sus requisitos. El proyecto fue cancelado.
Preguntas
1. En esta historia clínica, ¿qué es el “sistema”? ¿Cuáles son sus elementos?

¿Qué es el “ambiente”? ¿Cuáles son los elementos de la
¿ambiente?
2. Describir la interacción entre el sistema y su entorno.

3. ¿Cree que las decisiones importantes que se toman en este proyecto representan un
“pensamiento sistémico”? Explique.
4. Comente el concepto de “integración” en el proyecto. ¿Cómo se integraron
o no los aspectos del proyecto?
5. ¿Cuáles son los principales factores que contribuyeron a la cancelación del
proyecto? ¿Cuál de estos factores caracterizaría como gestión de proyectos?
25
Caso 2.3 Proyecto de extensión de la línea Jubilee
El Proyecto de extensión de la línea Jubilee (JLEP) fue una expansión del sistema
subterráneo de Londres (LU). Expandió LU a través de seis distritos de Londres,
uniendo Westminster con Docklands y Stratford. El proyecto en realidad comprendía
30 proyectos (es decir, era un “programa”) que incluía 22 km de túneles, cinco cruces
submarinos, 11 nuevas estaciones y complejas instalaciones de maquinaria y equipo.
En todas partes había que tener cuidado para garantizar la seguridad de más de 30
edificios en el centro de Londres. JLEP en muchos aspectos refleja otro gran proyecto
subterráneo: el Big Dig de Boston (véanse los Casos 9.1 y 15.3).
Iniciado en 1993 por un costo estimado de £2.1 mil millones, JLEP se completó en
Diciembre de 1999, 20 meses de retraso y más de 1400 millones de libras esterlinas por
encima del presupuesto (en ese momento, el proyecto más caro del mundo). Cuatro eventos
importantes contribuyeron a los sobrecostos:
26
• Paro laboral para asegurar financiamiento del sector

privado. • Colapso de túneles expresos en el aeropuerto de Heathrow, que utilizaba el
mismo método de construcción de túneles en JLEP y requería una revisión
completa de la seguridad del método.
• Fallo del nuevo sistema de señalización. •

Decisión de ubicar el Millennium Dome en Greenwich, para lo cual JLE
iba a ser una fuente importante de acceso.
Otros contribuyentes fueron las diferencias en los contratos y las ambigüedades resultantes
sobre las funciones y responsabilidades de las partes involucradas. Se utilizaron dos tipos
de contratos; uno se basó en calendarios de pago e hitos, el otro en especificaciones de
diseño y desempeño. Estas diferencias luego resultaron incompatibles.
JLEP requirió cambios de diseño significativos a lo largo del proyecto; muchos de ellos
estaban mal controlados y gestionados o fueron aprobados a posteriori.
Las diferencias entre los primeros diseños propuestos y los dibujos de diseño de trabajo se
comunicaron de manera deficiente, y muchos diseños fueron "congelados" por grupos de
ingeniería y arquitectura a pesar de que los elementos del diseño aún estaban en la etapa
conceptual. Los contratistas de construcción participaron mínimamente en el diseño. El
equipo del proyecto enfrentó presiones políticas para completar JLE a tiempo para que
sirviera como enlace de transporte principal al Millennium Dome, que en ese momento
estaba en construcción. En consecuencia, fijó un plazo demasiado ambicioso para el
proyecto de 53 meses.
El proyecto fue administrado a través del director del proyecto, el gerente del proyecto y
un gran equipo de proyecto. Los contratistas se eligieron de forma independiente y no se
definieron las interfaces entre ellos. Esto generó confusión y dejó al equipo del proyecto con
la importante tarea de administrar todas las interfaces de los contratistas y coordinar su

trabajo. Los cambios sustanciales en el diseño y la falta de objetivos e hitos claros generaron
dificultades para monitorear el progreso y aplicar el sistema de pago por hitos.
La gerencia del metro de Londres trató a JLE como un "agregado" a la

línea ferroviaria existente, es decir, trató a JLE como casi independiente de las líneas
de transporte existentes y los sistemas de comunicación a los que estaría vinculado.
De hecho, el equipo del proyecto consideró que las líneas LU existentes no tenían
nada que ver con ellas. A pesar del hecho de que JLE aumentaría sustancialmente el
tamaño del sistema LU, e impactaría el sistema y se vería afectado por él, la gerencia
de LU vio a JLEP simplemente como un proyecto de construcción cuya operación
final sería independiente del sistema LU general. Solo se presupuestó una cantidad
relativamente pequeña para otras partes de LU para manejar el aumento del tráfico
de pasajeros como resultado de JLE. La planificación inicial de JLE no abordó
completamente los problemas operativos, y fue más de un año después de que
comenzó el proyecto que se abordó por primera vez un plan para la operación de
JLE. El proyecto estaba originalmente programado para estar "en línea" de una sola
vez; solo mucho más tarde, después de los contratiempos, se decidió que JLE abriría de manera gradu
JLEP se completó sin víctimas fatales y ha tenido éxito en aliviar la congestión;
varias de sus estaciones han recibido premios por diseño arquitectónico; y JLE es
citado como contribuyente al éxito de los Juegos Olímpicos de Londres 2012. Pero
se completó por 3.500 millones de libras esterlinas en lugar de los 2.100 millones de
libras esterlinas presupuestados y en 73 meses en lugar de los 53 meses planificados,
a pesar de una reducción sustancial en su alcance (reemplazando un sistema de
señalización de nueva tecnología previsto con un sistema tradicional).
Preguntas
1. El caso ilustra una situación en la que es necesario el enfoque de sistemas para el

diseño y la gestión. ¿Por qué es necesario?
2. ¿Hay evidencia en el caso que demuestre que los planificadores y la gerencia de JLE
usaron el enfoque de sistemas o la ingeniería de sistemas? En su discusión,
considere lo siguiente: JLE como un "sistema", identificación de las partes interesadas
e identificación de necesidades, definición de requisitos, gestión de interfaz y
operación del sistema.
Caso 2.4 Sistema de Operaciones de Tránsito del Condado

27
de Santa Clara y Proyecto de Coordinación de Señales
La infraestructura vial del condado de Santa Clara consta de (1) autopistas administradas por el
estado de California, (2) calles y autopistas de la ciudad administradas por municipios individuales
y (3) autopistas de acceso limitado e intersecciones señalizadas administradas por el condado.
El condado realizó un estudio de la viabilidad de integrar todas estas operaciones de tráfico y
sistemas de señalización en un Sistema de Transporte Inteligente (ITS). El ITS mejoraría el
Centro de Operaciones de Tránsito del condado, el sistema de semáforos, las comunicaciones
y la vigilancia de intersecciones, y proporcionaría enlaces de comunicación con los centros de
control municipal. El estudio identificó interfaces entre los sistemas dispares y describió la
arquitectura ITS. El proyecto comenzó en 1998 y dentro del presupuesto legislado y el plazo de
7 años, el ITS estaba en pleno funcionamiento.
Entre los desafíos experimentados durante el proyecto se encuentran:

• Cambios rápidos en la tecnología de videocámaras y transmisión de video

para la vigilancia del tráfico.
• Disponibilidad de nuevas tecnologías para permitir la transición de los sistemas de

comunicación ITS y señalización de tráfico del protocolo de Internet analógico al digital.
• El “punto.com” auge, que afectó el suministro de cableado de fibra óptica y generó un

cronograma de entrega de 18 meses y una potencial duplicación de
costos
Un análisis post-hoc del proyecto realizado por el INCOSE Transporte

El grupo de trabajo concluyó que la dirección del proyecto había tomado las siguientes medidas
importantes:
• Creó una declaración clara del concepto operativo. • Requisitos

del sistema desarrollado. • Controlé la revisión de los requisitos
durante las fases de diseño y construcción para adaptarse a los cambios en la tecnología.
• Claramente definidas durante la etapa de diseño las pruebas de verificación
necesarios para la aceptación de los subsistemas.

• Definió al principio del proyecto las medidas de rendimiento que se utilizarán en
validación del sistema.
El grupo INCOSE también concluyó que la dirección del proyecto había utilizado eficazmente la
planificación de la gestión de riesgos, especialmente en relación con posibles retrasos en la
entrega debido a la escasez de cable de fibra óptica. Poco después de que se declararan fijos
los requisitos de comunicaciones, el cliente inició la adquisición del cable de fibra y los procesos
para incorporar el cable en los contratos de construcción.
Durante el diseño y la implementación del sistema, el personal senior (tanto del cliente como
del consultor) revisó los requisitos del usuario y revisó el concepto de diseño, lo que eliminó los
sesgos tecnológicos en los requisitos y permitió acomodar revisiones posteriores en la tecnología.
Doce años después del inicio del proyecto, los protocolos de comunicación habían cambiado.
Sin embargo, la modularidad del diseño del sistema permitió actualizar el sistema en etapas sin
cambiar el equipo o el subsuelo.
infraestructura de comunicaciones.
Pregunta
Aunque el equipo del proyecto no se propuso intencionalmente seguir el enfoque

de sistemas, mucho de lo que hizo, de hecho, se ajustó a las prácticas de ingeniería
de sistemas. Compare la información limitada proporcionada sobre el proyecto con
los conceptos de ingeniería de sistemas y el modelo V descritos en el capítulo.
Notas finales
1. Naughton J. y Peters G. Rendimiento de los sistemas: factores humanos y fallas de los sistemas. Milton Keynes,
Reino Unido: Universidad Abierta; 1976, págs. 8–12.
2. Ibid., 11. Se pueden percibir innumerables sistemas de cualquier entidad. K. Boulding, en El mundo como
Total System (Beverly Hills, CA: Sage, 1985) describe el mundo como físico, biológico, social, económico,
sistemas políticos, de comunicación y de evaluación.
3. Schoderbek P., Kefalas A. y Schoderbek C. Sistemas de gestión: consideraciones conceptuales. Dallas:
publicaciones comerciales; 1975, págs. 7 y 8.
4. Kast F. y Rosenzweig J. La visión moderna: un enfoque de sistemas. En Beishon J. y Peters G. (eds),
Comportamiento de los sistemas, 2ª ed. Londres, Reino Unido: Harper & Row; 1976, págs. 19–25.
5. Cleland D. y King W. Management: un enfoque de sistemas. Nueva York, NY: McGraw-Hill; 1972, pág. 89.
6. Churchman CW El enfoque de sistemas y sus enemigos. Nueva York, NY: Libros básicos, 1979.
7. Ibíd., págs. 4 y 5.
8. Gran parte de la discusión en esta sección se basa en Churchman CW The Systems Approach. Nueva York:
dell; 1968, págs. 30–39.
9. Thome P. y Willard R. El enfoque de sistemas: un concepto unificado de planificación. En Optner S. (ed.),
Análisis de sistemas. Harmondsworth, Reino Unido: Penguin Books; 1973, pág. 212.
10. Hamilton H. Simulación de sistemas para análisis regional. Cambridge, MA: La prensa del MIT; 1972.
11. El ciclo de vida de los productos tecnológicos es descrito con elocuencia por Foster R. en Innovation: The Attacker's
Ventaja. Nueva York, NY: Summit Books; 1986.
12. Como lenguaje común, el término ciclo de vida del proyecto es un reconocimiento de que todos los proyectos tienden a seguir un
secuencia de actividades, de principio a fin. Como todo proyecto, sin embargo, tiene un comienzo y un final, al referirse
a un proyecto en particular, el término más preciso es duración del proyecto.
13. Jenkins G. El enfoque de sistemas. En Beishan J. y Peters G. (eds), Systems Behavior, 2ª ed. Londres,
Reino Unido: Harper and Row; 1976, pág. 82.
14. Auyang S. Ingeniería: una frontera sin fin. Cambridge, MA: Prensa de la Universidad de Harvard; 2004, págs. 175–
189.
15. Brooks F. El mes del hombre mítico. Lectura, MA: Addison Wesley; 1995, pág. 199.
16. Auyang, Engineering—An Endless Frontier, pág. 183.
17. Ibíd., págs. 192–197.
18. Forsberg K. y Mooz H. En Taylor R., Dorfman M. y Davis A. (eds), Requisitos de software
Ingeniería, 2ª ed. Los Alamitos, CA: IEEE Computer Society Press; 1997, págs. 44 a 77; modelo V adaptado
de la reimpresión en Auyang, Engineering—An Endless Frontier, pág. 197.
19. Herbert Simon, citado en Auyang, Engineering—An Endless Frontier, pág. 194.
20. Cleland y King, Management: A Systems Approach, págs. 171–173; y Johnson R., Kast K. y
Rosenzweig J. The Theory and Management of Systems, 3.ª ed. Nueva York, NY: McGraw-Hill; 1973, págs.
135–136.
21. Gilbreath R. Ganar en Gestión de Proyectos. Nueva York, NY: John Wiley and Sons; 1986.
22. Ibíd., págs. 95 y 96.
23. Ibíd., págs. 98–102.
24. De Law J. y Callon M. The Life and Death of an Aircraft: A Network Analysis of Technical Change.
En Bijker W. y Law J. (eds), Shaping Society/ Building Technology. Cambridge, MA: Prensa del MIT; 1992.
25. La información para este caso se deriva de tres fuentes, todas descargadas el 30 de octubre de 2014: (1) Perfil del proyecto,
Extensión Línea Jubileo. Centro Omega, University College London (sin fecha),
http://www.omegacentre.bartlett.ucl.ac.uk/studies/cases/pdf/UK_JLE_PROFILE_120909.pdf; (2) Jubileo
Línea Extensión, Londres, Reino Unido

(no fecha),
http://www.omegacentre.bartlett.ucl.ac.uk/studies/cases/pdf/UK_JLE_2P_080911.pdf; y (3) Sistemas
Estudio de caso de ingeniería # 8 Extensión de la línea Jubilee, Ingeniería de sistemas en proyectos de transporte: A
Biblioteca de Caso Estudios, Grupo de Trabajo de Transporte INCOSE, 2013,
http://www.incose.org/practice/techactivities/wg/transport/docs/CaseStudyLibrary_6_0.pdf.
26. Mitchell, B. Extensión de la línea Jubilee: desde la concepción hasta la finalización. Londres, Reino Unido: Thomas Telford
Publicación; 2003.
27. Adaptado del Estudio de Caso de Ingeniería de Sistemas # 7 Sistema de Operaciones de Tráfico del Condado de Santa Clara y
Proyecto de coordinación de señales, Ingeniería de sistemas en proyectos de transporte: una biblioteca de estudios de casos,
INCOSE Transportación Laboral Grupo, 2013,
http://www.omegacentre.bartlett.ucl.ac.uk/studies/cases/pdf/UK_JLE_2P_080911.pdf; descargado oct.
30, 2014.
Parte II
Ciclo de vida del proyecto
La mayoría de los sistemas pasan por una serie de etapas de desarrollo. En los sistemas
creados por humanos, las etapas de desarrollo siguen una secuencia lógica e intencional de
actividades prescritas denominada ciclo de desarrollo de sistemas. La gestión de proyectos
ocurre dentro de este ciclo y es la función responsable de planificar las actividades de trabajo y
organizar y guiar su ejecución. Los dos capítulos de esta sección introducen el ciclo de desarrollo
de sistemas y describen sus dos primeras fases, concepción y definición.
Capítulo 3
Ciclo de Vida del Proyecto y Proyecto
Concepción
Hay … tiempo de nacer, y tiempo de morir; tiempo de plantar, y tiempo de segar; un tiempo para matar, y un
tiempo de sanar; tiempo de destruir, y tiempo de edificar…
—Eclesiastés 3:1
Una característica del enfoque de sistemas es el concepto de “ciclo de vida”, el patrón

básico de cambio que ocurre a lo largo de la vida de un sistema. El enfoque de sistemas
explica esto de dos maneras: (1) reconocer el proceso natural que ocurre en todos los
sistemas dinámicos: el nacimiento, el crecimiento, la madurez y la muerte, y (2) incorporar
ese proceso en la planificación y gestión de los sistemas. La práctica de la gestión de
proyectos hace ambas cosas.
El proceso de desarrollo, implementación y operación de cualquier sistema creado por
humanos sigue una secuencia lógica de fases denominada ciclo de desarrollo de sistemas.
Los proyectos también siguen una secuencia de fases de principio a fin denominada ciclo de
vida del proyecto. Este capítulo describe el desarrollo del sistema y los ciclos de vida del
proyecto y la primera fase de ambos. El próximo capítulo cubre la segunda fase; los capítulos
siguientes cubren los demás.
3.1 Ciclo de vida del proyecto
Los sistemas son dinámicos, cambian con el tiempo. El cambio tiende a seguir un patrón distinto
que se repite una y otra vez. En el Capítulo 2 se mencionó el ciclo de vida de los organismos:
nacimiento, crecimiento, madurez, senectud y muerte, y su similitud con los ciclos de los productos
y sistemas creados por el hombre.
Ver Capítulo 2
Los proyectos siguen un ciclo llamado ciclo de vida del proyecto. Cada proyecto tiene un punto
de partida y avanza hacia una conclusión predeterminada; durante este tiempo, la actividad en el
proyecto sigue creciendo, alcanza un pico y luego declina, el patrón que se muestra en la curva
inferior de la Figura 3.1 (las “curvas superiores” muestran la actividad acumulada). La actividad o
el esfuerzo se pueden medir de varias maneras, como la cantidad de dinero que se gasta en el
proyecto, la cantidad de personas que trabajan en él, la cantidad de materiales que se usan, etc.
Además de los cambios en el nivel de actividad, la naturaleza y el énfasis de la actividad también

cambian, al igual que las personas involucradas. Por ejemplo, los clientes y los planificadores son
muy activos al principio del proyecto; luego los diseñadores, constructores e implementadores se
hacen cargo, y al final, los usuarios y operadores se hacen cargo.
La gestión del ciclo de vida del proyecto requiere un tratamiento especial. A diferencia de las
operaciones repetitivas que no son de proyectos, donde todo tiende a ser algo familiar y estable,
muchas cosas en los proyectos (recursos, cronogramas, tareas de trabajo, etc.) no son familiares
o están en un estado de cambio constante. Mucho de lo que se hace en un proyecto puede
considerarse no repetitivo o no rutinario. Los cronogramas de trabajo, los presupuestos y las tareas
deben adaptarse para adaptarse a cada fase y etapa del ciclo de vida del proyecto. Los obstáculos
imprevistos pueden ocasionar incumplimiento de plazos, sobrecostos y un desempeño deficiente del proyecto.
Los gerentes deben tratar de anticipar los problemas, planificarlos y ajustar las actividades y
cambiar los recursos para mitigarlos o superarlos.
Figura 3.1 Nivel de esfuerzo durante el ciclo de vida del proyecto.

3.2 Ciclo de desarrollo de sistemas
El ciclo de vida del proyecto es parte de un ciclo de vida más grande llamado ciclo de desarrollo de
sistemas (SDC). Prácticamente todos los sistemas creados por el hombre siguen las cuatro fases de
este ciclo (Figura 3.2):
1. Fase de concepción (Fase A)

2. Fase de definición (Fase B)
3. Fase de ejecución (Fase C)
4. Fase de operación (Fase D)
El ciclo de vida del proyecto generalmente abarca las Fases A, B y C: concepción, definición y
ejecución. Cuando finaliza la Fase C, también finaliza el proyecto. En ese momento el sistema entra
en la Fase D, operación; el sistema pasa de ser el elemento final de un proyecto a una entidad
operativa.
Fase A: Concepción
Cada proyecto es un intento de resolver un problema, y un primer paso para resolver el problema es
reconocer que el problema existe. Después de eso, la persona que enfrenta el problema (el cliente y
los usuarios) busca a alguien que pueda ayudar. Los pasos que toman (solicitar contratistas que
puedan hacer el trabajo, evaluar sus propuestas y llegar a un acuerdo) forman parte del proceso de
gestión de adquisiciones .
Si la organización del cliente tiene un grupo interno capaz de hacer el trabajo, recurre a ellos. De
lo contrario, recurre a contratistas externos, posiblemente enviándoles una solicitud formal de ayuda
denominada solicitud de propuesta o RFP. Cada contratista examina el problema, los objetivos y los
requisitos del cliente según lo establecido en la RFP y determina la viabilidad técnica y económica
de emprender el proyecto. Si el contratista decide responder a la solicitud, presenta al cliente una
propuesta de solución (concepto de sistema) en una propuesta o carta de interés.
A continuación, el cliente examina las propuestas y hace una elección. El resultado es un

acuerdo formal entre el cliente y el contratista elegido. La mayoría de las ideas o

propuestas nunca pasan de la Fase A; los problemas abordados se juzgan como
insignificantes, o la propuesta como impracticable, inviable o carente de beneficios que
justifiquen el financiamiento y los recursos. Los pocos que se aprueban y llegan a un
acuerdo de contrato pasan a la Fase B.
Figura 3.2 Modelo de cuatro fases y etapas del ciclo de desarrollo de sistemas. El ciclo de vida del proyecto son las Fases A,
B y C.
Fase B: Definición
Habiendo llegado a un acuerdo con el cliente, el contratista comienza un análisis

detallado del concepto del sistema, durante el cual define los requisitos que debe
cumplir el sistema para satisfacer las necesidades del cliente, y las funciones y
elementos que debe poseer el sistema para cumplir con esos requisitos. Esta definición
da como resultado un diseño preliminar para el sistema. A medida que continúa el
proceso, se determinan los principales subsistemas, componentes y sistemas de
soporte del sistema propuesto, así como los recursos, costos y cronogramas necesarios
para construir el sistema. Mientras tanto, la gestión de proyectos ensambla un plan
integral del proyecto que define las actividades, los cronogramas, los presupuestos y los recursos par
implementar el sistema. La alta gerencia del contratista revisa el plan para verificar su
aceptabilidad y luego lo envía al cliente, quien también lo revisa para verificar su
aceptabilidad.
En algunas industrias, las tareas de las Fases A y B se denominan “front-end”.
loading” (FEL) o “planificación inicial”, que se refiere a todo lo que sucede en el proyecto
antes de la ejecución del trabajo en la Fase C. FEL se analiza en el Capítulo 4.
Ver Capítulo 4
Fase C: Ejecución
La fase de ejecución es cuando se pone en práctica el trabajo especificado en el plan del

proyecto; a veces se denomina fase de "adquisición" porque el usuario adquiere el sistema
al final de la fase y en ese momento se adquiere la mayoría de los recursos del sistema. La
fase de ejecución a menudo incluye las etapas de "diseño", "producción" e "implementación",
que se refieren a la progresión a través de la cual un sistema pasa de ser una idea a un
artículo final físico terminado. Todos los sistemas se componen de elementos dispuestos
en alguna configuración, patrón o estructura, y es en la etapa de diseño que se definen los
elementos y la configuración necesarios para que el sistema cumpla con los requisitos.
Después del diseño, el sistema entra en producción , donde se construye como un artículo
único o como un artículo producido en masa. Durante la fase de ejecución se implementa
el sistema; se instala y se convierte en parte del entorno del usuario.
Fase D: Operación
En la fase de operación se despliega el sistema; el cliente se hace cargo de operar el

sistema y mantenerlo. Para sistemas tales como productos y equipos que las personas
usan y en los que confían diariamente, la Fase D puede durar años o décadas, en cuyo
caso la fase incluye no solo la operación y el mantenimiento del sistema, sino también la
mejora y mejora para mantener el sistema viable y útil. . Cada
el sistema eventualmente sobrevive a sus propósitos o simplemente se desgasta. Cuando eso

sucede, hay dos opciones: desechar el sistema o modificarlo para que siga siendo útil; en este
último caso la “modificación” se convierte en un nuevo concepto de sistema, el comienzo de un
nuevo COSUDE y un nuevo proyecto.
Para algunos sistemas, la Fase D es breve o inexistente: los ejemplos son una campaña
política, un concierto de rock y una ceremonia de gala (el proyecto finaliza el día de las elecciones
1
o al finalizar el concierto o la ceremonia).
Prácticamente todos los proyectos avanzan a través de las Fases A, B y C, aunque no
necesariamente a través de las etapas que se muestran en la Figura 3.2. En algunos proyectos,
ciertas etapas reciben poco énfasis o se omiten por completo; muchos proyectos, sin embargo,
pasan por todas las etapas, aunque sea de manera informal. Por ejemplo, aunque no todos los
proyectos requieren la preparación de una propuesta, todos los proyectos comienzan con una
propuesta de alguien. De manera similar, aunque muchos proyectos no involucran “producción”,
todos los proyectos involucran la producción de algo, aunque solo sea información. Muchos
proyectos siguen un patrón similar al ciclo de la Figura 3.2. Los siguientes dos ejemplos ilustran.
Ejemplo 3.1: Ciclo de desarrollo de nuevos productos

en Jamal 2
Jamal Industries es una empresa manufacturera de tamaño mediano que produce

productos para los principales minoristas bajo las propias etiquetas del minorista, como
Sears y True Value. Desarrolla y produce sus productos en las fases de iniciación,
factibilidad, análisis, diseño y fabricación. Jamal inicia e implementa la mayoría de los
proyectos internamente, aunque a veces subcontrata el trabajo de desarrollo y fabricación.
Este ejemplo es un caso así.
Un competidor había introducido un temporizador computarizado que tendría un gran
impacto en la participación de mercado de Jamal. Para examinar la viabilidad de lanzar un
nuevo producto, los ingenieros de Jamal analizaron muestras del dispositivo de la
competencia para ver si podían desarrollar rápidamente su propia versión. El análisis se
centró en si un dispositivo tan bueno o mejor podría fabricarse y venderse bajo las marcas
privadas de los minoristas por un 20 por ciento menos que el precio de la competencia.
Como alternativa, Jamal podría buscar otra distribución
canales para vender el producto bajo su propia etiqueta. El estudio de factibilidad

indicó que la primera alternativa no era factible, aunque la segunda —vender el
producto bajo su propia etiqueta— sí lo era.
Se realizó un análisis en profundidad para determinar cómo Jamal podría
subcontratar el trabajo para evitar una inversión de capital que no podía pagar. El
director de investigación, que se desempeñó como gerente del proyecto, y su
personal de ingeniería analizaron las alternativas de contratación y decidieron
contratar a un contratista general para diseñar y fabricar el producto. Identificaron a
un contratista extranjero que podría fabricar un cronómetro superior que Jamal podría
comercializar a un precio $12 más bajo que el de la competencia. La mayor parte de
la planificación, programación y presupuestación asociada con el proyecto se delegó al contratista.
En un año, el producto fue diseñado, fabricado, distribuido y en
historias.
El contratista continuará produciendo el dispositivo mientras Jamal lo comercialice.

El equipo de diseño de Jamal fue transferido a otros proyectos, aunque el director
de investigación continúa supervisando al contratista para garantizar que se
mantengan los estándares de calidad.
Ejemplo 3.2: Ciclo de desarrollo de sistemas de

software en Microsoft 3
El desarrollo de software nuevo en Microsoft suele seguir las fases de planificación,

desarrollo y estabilización, aunque algunas de las fases pasan por una serie de
iteraciones.
La fase de planificación produce una declaración de visión, un documento de
especificaciones y planes de marketing, integrando componentes de otros productos,
pruebas y documentación. La fase dura de 3 a 12 meses dependiendo de si el
producto es nuevo o una actualización. La declaración de visión guía el proyecto; es
una breve declaración sobre los objetivos, el enfoque y las prioridades del producto.
El documento de especificaciones es una declaración preliminar de las características
y el empaque del producto. El documento comienza pequeño (a veces se puede
describir en una sola oración) pero se expande a medida que el proyecto
progresa El documento y los planes se combinan con estimaciones de tiempo para

crear un cronograma del proyecto. La fase concluye cuando la gerencia aprueba los
planes y el cronograma.
La fase de desarrollo se subdivide nominalmente en cuatro subfases con tres hitos
internos de lanzamiento de productos. Cada subfase está programada para ejecutarse
durante 2 a 3 meses, lo que incluye márgenes de tiempo para acomodar problemas
imprevistos y permitir que la subfase se complete en la fecha del hito. Las primeras tres
subfases están dedicadas al desarrollo y la codificación, las pruebas de errores y
funcionalidades, y la documentación de las características del producto. El objetivo de
cada subfase es cumplir con los requisitos para un conjunto de funciones del producto
que estaría completamente listo para "enviarse", aunque el envío aún no es posible
porque las funciones aún no se han integrado en el producto. En el caso de que un
competidor amenace con lanzar un producto similar, la tercera o incluso la segunda
subfase se puede omitir para reducir de 4 a 6 semanas del proceso de desarrollo. El
producto tendría menos funciones, pero superaría a la competencia en su lanzamiento.
Durante la cuarta subfase, las características del producto se prueban y depuran más y
se impone una congelación, lo que significa que no se pueden introducir cambios
importantes a partir de entonces. Esto permite que el grupo educativo escriba la
documentación que corresponderá con precisión al producto cuando se lance. Las
subfases de la fase de desarrollo son una variación del enfoque "ágil" para el desarrollo
del sistema, descrito en el Capítulo 13.
Ver Capítulo 13
En la última fase, la estabilización, se combinan y prueban todas las características

desarrolladas en la fase anterior. “Lanzamiento de cero errores” ocurre cuando se
corrigen todos los errores o se eliminan del producto las características con errores
restantes (para ser corregidos más tarde e incluidos en versiones posteriores del
producto). Esta fase concluye con el lanzamiento de un disco "maestro de oro" del que
la fabricación hará copias. El proyecto concluye con una reunión del equipo del proyecto
para revisar el proyecto y lo que se aprendió de él.
La mayoría de las empresas orientadas a proyectos emprenden proyectos de la manera que

mejor se adapte a ellos, y prescriben o exigen formas de administrar y realizar tareas en esos
proyectos; es decir, crean su propia metodología de proyectos. Los dos ejemplos anteriores
ilustran tales metodologías de proyectos “de cosecha propia”. A lo largo de este libro nos
referiremos repetidamente a la metodología que abarca las fases A a C en la Figura 3.2.
Usamos esta metodología no porque sea siempre la mejor, sino porque transmite un patrón
común que es muy similar a las metodologías que hemos visto en muchas empresas. Otra
metodología similar a la Figura 3.2 es el proceso de ingeniería de sistemas; este proceso,
que se relaciona con las herramientas y los temas discutidos en el Capítulo 4, se describe
en el Apéndice del Capítulo 4 . Otras metodologías se discuten en el Capítulo 17.
Planificación de proyectos por fases y seguimiento rápido
Las fases y etapas del ciclo de vida de un proyecto a veces se llevan a cabo de forma
escalonada, lo que se denomina planificación de proyecto por fases o activación del
proyecto. Al final de cada fase, se evalúan los objetivos, costos y resultados del proyecto, y
se toma la decisión de continuar, suspender o cancelar el proyecto. Los recursos se
comprometen solo después de una revisión por parte de la dirección. Esto se desarrolla en el Capítulo 4.
Ver Capítulo 4
Las fases del proyecto, tal como se describen, no siempre se realizan en una secuencia
discreta, sino que se pueden superponer en una práctica denominada seguimiento rápido.
Antes de que se complete la Fase B, se inician los elementos de la Fase C; antes de que
se complete la Fase C, se inician partes de la Fase D. El seguimiento rápido comprime el
tiempo de desarrollo e implementación de sistemas, aunque presenta el riesgo de pasar
por alto o definir mal las tareas y tener que repetirlas o deshacerlas.
En los proyectos que utilizan la denominada metodología ágil se repiten algunas fases.
La fase de ejecución y, a veces, también la fase de definición se repiten en ciclos, cada
ciclo destinado a refinar, mejorar o construir sobre los resultados del ciclo anterior. Agile se
trata en el Capítulo 13.
Ver Capítulo 13
Partes interesadas
La COSUDE tiene muchas partes interesadas (actores y partes interesadas). Los principales grupos
de interés son:
1. Clientes del sistema (compradores, clientes o propietarios), incluidos:
una. Gestión de clientes b.

Usuarios y operadores
2. Contratistas del sistema (la organización de desarrollo de sistemas (SDO), desarrollador,

promotor o consultor), incluidos:
a. Alta dirección del contratista (gerentes corporativos y funcionales) b. Gestión

del proyecto (director del proyecto y personal) c. Los "hacedores": profesionales,
comerciantes, ensambladores y otros trabajadores
Los clientes son las personas o grupos para quienes se realiza el proyecto y quienes adquirirán y/u
operarán el sistema cuando esté terminado. La gestión de clientes paga y toma decisiones sobre el
proyecto; los usuarios y operadores utilizarán, mantendrán o, de otra manera, serán los destinatarios
del artículo final del proyecto. Es importante identificar a los usuarios reales ya que, en última
instancia, es para ellos que se crea el producto final. Los términos cliente y usuario se usan
indistintamente, pero es importante tener en cuenta la distinción entre ellos:
• El cliente (propietario, comprador, patrocinador) paga por el sistema. •

Los usuarios lo utilizan y operan.
El contratista o desarrollador o consultor es la parte que estudia, diseña, desarrolla, construye e

instala el sistema. El contratista suele ser externo a la organización del cliente, aunque, por
supuesto, bien podría residir dentro de la misma organización, como es el caso de los grupos
internos de consultoría/apoyo. Desde el
contratista suele ser una organización, a veces se le denomina organización de desarrollo de sistemas
(SDO).
Debido a que en la mayoría de los casos el cliente le paga al contratista para realizar el proyecto,
piense en el cliente como el comprador y el contratista como el vendedor. Estos términos tienen sentido
cuando se piensa en un proyecto en el contexto de un contrato entre dos partes, en el que una (el
contratista-vendedor) acuerda prestar servicios a cambio del pago de otra (el usuario-comprador). El
director de proyecto suele trabajar para el contratista, aunque el cliente también puede tener un director
de proyecto.
Además de estos, el ciclo de vida involucra a otras partes clave: individuos, grupos y organizaciones
con intereses creados y/o influencia en la realización del proyecto. Cualquiera que se vea afectado por el
proyecto, perciba que se ve afectado por él o que potencialmente pueda alterar su resultado es un
interesado. Las partes interesadas del proyecto se analizan a lo largo del libro y con algo de profundidad
en los capítulos 15 y 17.
El resto de este capítulo se centrará en la primera fase del ciclo de vida del proyecto y cómo se
conciben y comienzan los proyectos. Para proyectos contratados externamente, la mayor parte de lo que
sucede en esta fase es parte de lo que se denomina el proceso de gestión de adquisiciones .

3.3 Fase A: Concepción
La fase de concepción comprende nominalmente dos etapas. El primero, iniciación del proyecto,
establece que existe una “necesidad” o problema y que vale la pena investigar. El segundo, la
factibilidad del proyecto, es una investigación detallada de la necesidad o problema, una
formulación de posibles alternativas de solución y la selección de una. La fase finaliza con un
acuerdo de que un contratista elegido proporcionará una solución específica al cliente.
Inicio del proyecto
4
El proceso comienza cuando el cliente o usuario percibe una necesidad; es decir, reconoce
un problema u oportunidad y, posiblemente, formas de abordarlo. A veces la necesidad se
expresa como una visión.
Ejemplo 3.3: Declaración de visión en Microsoft 5
Como se mencionó en el Ejemplo 3.2, cada proyecto de desarrollo de nuevos productos

en Microsoft comienza con una breve declaración sobre un producto y sus objetivos,
llamada declaración de visión. Para una versión reciente de Excel, solo tenía cinco páginas.
El propósito de la declaración de visión es comunicar el concepto y los requisitos del
producto al equipo de desarrollo, a otros grupos de productos y a la gerencia. En Microsoft,
la visión incluye un resumen ejecutivo con un objetivo de una oración, una lista que
especifica lo que el producto hará y no hará, y las definiciones del cliente típico y la
competencia. Podría describir las características y prioridades del producto con suficiente
detalle para comenzar a preparar cronogramas para el desarrollo, las pruebas, la
educación del usuario y la preparación de versiones del producto en inglés y no inglés.
También puede enumerar los requisitos para el sistema operativo, la memoria, el espacio
en disco, la velocidad del procesador, los gráficos y las dependencias de los controladores
y componentes de la impresora. El comunicado informa
todos sobre lo que harán y no harán, y les da una visión general común.
Más allá de percibir la necesidad, el inicio del proyecto requiere probar que la
necesidad es significativa y puede satisfacerse a un costo práctico. Es fácil identificar
problemas y pensar en soluciones, pero la mayoría de las ideas son efímeras y no
valen mucho. Si un cliente decide tomar una idea más allá de la especulación, podría
tomar la ruta "rápida y sucia" y simplemente aceptar la primera solución que se
presente; o podría emprender un enfoque más prolongado, aunque sistemático y
completo, y considerar solo ideas con un grado razonablemente alto de éxito o retorno
de la inversión. Para seleccionar las pocas buenas ideas, la organización del cliente
lleva a cabo una breve investigación inicial.
Investigación inicial
Muchos usuarios saben que existe un problema pero no saben qué es ni cómo
explicarlo. Antes de comprometer recursos para un estudio completo, el usuario
realiza una breve investigación interna para aclarar el problema y evaluar posibles soluciones.
La investigación comienza con la búsqueda de hechos: entrevistas a gerentes y
usuarios, recopilación de datos y revisión de la documentación existente. Se formula
una declaración clara del problema, se definen los objetivos y se compila una lista de
posibles soluciones alternativas. La investigación se enfoca en los elementos del
problema, incluyendo:
• El entorno • Las
necesidades, síntomas, definición del problema y objetivos •
Soluciones preliminares y costos estimados, beneficios, fortalezas y
debilidades de cada uno
• Personas y organizaciones afectadas.
Con base en la investigación, el cliente decide si continúa o no con la idea. La mayoría

de las ideas nunca van más allá, y es obvio por qué: hay un sinfín de ideas sobre las
necesidades y las posibles soluciones, pero los recursos son escasos y
las organizaciones pueden comprometerse solo con aquellas pocas comparativas que brindan la mayor
cantidad de beneficios y tienen las mejores posibilidades de éxito. Para aprobar el concepto para su
posterior estudio, el cliente debe estar convencido de que la idea:
• Se adapta a una necesidad real y hay fondos disponibles para apoyarla. •

Tiene suficiente prioridad en relación con otras ideas. • Tiene un valor particular
en términos de, por ejemplo, la aplicación de nuevas tecnologías, la mejora de la reputación, el
aumento de la participación en el mercado o el aumento de las ganancias.
• Es consistente con las metas y recursos de la organización.
Con respecto a la última viñeta, algunas organizaciones evalúan previamente los proyectos propuestos y
consideran para un análisis más detallado solo aquellos que se alinean con las metas organizacionales y
los recursos disponibles. La preselección es un aspecto de la gestión de la cartera de proyectos, discutido
en el Capítulo 18.
Ver Capítulo 18
La investigación inicial generalmente la realiza el cliente y es breve, ya que requiere unos días o
semanas como máximo. A veces llamada Etapa de Idea o Etapa de Prefactibilidad, su propósito es
determinar si la idea merece un estudio más profundo; si lo hace, entonces se convierte en un “proyecto
potencial” y se aprueba para la siguiente etapa, la factibilidad.
3.4 Viabilidad del proyecto
La evaluación de factibilidad es el proceso de estudiar una necesidad, un problema y una

solución con suficiente detalle para determinar si una idea es económicamente viable y vale la
pena desarrollarla. La investigación inicial es una forma de estudio de viabilidad, un estudio de
prefactibilidad , que suele ser bastante superficial y, por lo tanto, insuficiente para
comprometerse con un proyecto. Un estudio de factibilidad es un estudio más extenso y
riguroso que considera soluciones alternativas (conceptos de sistema) y los beneficios y costos
de cada una. El cliente suele realizar el estudio de viabilidad, pero contratará a un tercero
(contratista) para que lo haga si el estudio requiere conocimientos especiales. La decisión de
construir un nuevo aeropuerto, una planta de energía, una carretera o un túnel son ejemplos
en los que los estudios de factibilidad son realizados por contratistas y son en sí mismos proyectos grandes y
Cuando existe una cantidad de alternativas para el proyecto, la factibilidad puede depender
del costo del ciclo de vida (LCC) del sistema final, que es el costo total del sistema durante
toda su vida útil, incluida la instalación, operación y eliminación. Para los sistemas que deben
desarrollarse recientemente, el costo incluye todos los costos asociados con todas las fases
del SDC: concepción, definición, ejecución y operación. El tema de LCC se trata en el Capítulo
8.
Ver Capítulo 8
Algunos proyectos involucran múltiples estudios de factibilidad. Los proyectos de

investigación y desarrollo de productos suelen tener una viabilidad técnica (evaluar el riesgo
de que la tecnología no funcione) y otra comercial (evaluar el riesgo de que el producto fracase
en el mercado). Otro asunto relacionado con la viabilidad es la cuestión de cómo se financiará
el proyecto y se cubrirán sus gastos a lo largo del ciclo de vida del proyecto. El financiamiento
de proyectos es un tema en sí mismo y está más allá del alcance de este libro, sin embargo,
es de gran importancia y, con bastante frecuencia, el factor decisivo en la aprobación del
proyecto. En otras palabras, la viabilidad de un proyecto puede tener menos que ver con el
mérito técnico o comercial del proyecto que con los fondos disponibles para el proyecto en
comparación con otros proyectos bajo consideración. Para proyectos grandes, el plan de
ejecución (ver Capítulo 5) debe
incluir una sección sobre financiamiento de proyectos que aborde los arreglos de financiamiento
y los medios para controlar el flujo de caja y administrar el dinero.
Ver Capítulo 5
Si el estudio de factibilidad indica que el concepto es viable, sucede una de dos cosas (Figura
3.3). Tema A: si el concepto es algo que el cliente puede manejar por sí mismo, se pasa a un
grupo interno para su desarrollo y ejecución; Tema B: si el concepto no se puede ejecutar
internamente, se entrega a contratistas externos (SDO). Compañías como Boeing, Microsoft y
Toyota rutinariamente realizan estudios de factibilidad para nuevos productos y luego entregan
los conceptos aprobados a sus propios equipos para el diseño, desarrollo y producción de los
productos. Pero compañías como Ritz-Carlton y Swisshotel, después de decidir construir un hotel
en un lugar específico, contratan contratistas externos para ejecutar el proyecto. En el último
caso, solicitan propuestas y ofertas de varios contratistas con un documento RFP (descrito en la
siguiente sección) y seleccionan la mejor.
Cada contratista que compita por el proyecto debe realizar su propio estudio de factibilidad
para evaluar los méritos del proyecto y si desea o no participar. Si un contratista decide seguir
adelante, investigará posibles soluciones alternativas (conceptos de sistema) al problema del
cliente, elegirá una y la describirá en una propuesta. Esto se llama el “proceso de preparación de
la propuesta”. Al recibir las propuestas, el cliente las revisa y selecciona la que mejor se ajusta a
los criterios de selección, es decir, es la “más factible”.
Figura 3.3 Estudio de factibilidad como parte de la fase de concepción.
En resumen, la factibilidad del proyecto implica múltiples estudios y decisiones: el

cliente evalúa la "factibilidad" de financiar el proyecto; el contratista determinando la
“viabilidad” de ganar el contrato; el contratista concibiendo soluciones alternativas y
eligiendo la “más factible” para proponer; y el cliente evaluando las soluciones
propuestas y eligiendo la “más factible” de comprar.
Cuando el cliente llega a un acuerdo con un contratista, el proyecto avanza a la Fase
B.
A veces, los contratistas deciden no preparar propuestas porque no tienen
soluciones que generen ganancias o se ajusten a la solicitud del cliente. A veces los
clientes concluyen que ninguna de las propuestas cumple con los requisitos. De
cualquier manera, el concepto se juzga como “no factible” y el proceso termina ahí.
Solicitud de propuesta
La RFP—solicitud de propuesta (o solicitud de oferta, solicitud de cotización, invitación a ofertar (IFB) o
término similar) es un documento que el 6cliente

problemas,
envía aobjetivos,
los contratistas
requisitos
potenciales
y el deseo
explicando
del cliente
losde
contratar a alguien; también puede indicar lo que el cliente quiere ver en la propuesta (requisitos de la
propuesta) y cómo se seleccionará la propuesta ganadora (criterios de evaluación de la propuesta) (ver
Figura 3.4). El proceso para seleccionar la mejor propuesta se describe más adelante y en el Capítulo 18.
Ver Capítulo 18
Un propósito de la RFP es describir la necesidad, el problema o la idea del usuario; otro es solicitar
sugerencias (propuestas) de soluciones, generalmente con la intención de otorgar un contrato. El cliente
puede enviar RFP a contratistas en su propia lista de postores, una lista de contratistas precalificados, o
también puede distribuir RFP a un mercado más amplio a través de Internet utilizando "herramientas de
abastecimiento en línea" comerciales. Por lo tanto, los contratistas se enteran de los próximos trabajos ya
sea al recibir RFP directamente de los clientes o escaneando boletines y boletines en línea y solicitando
RFP.
Por ejemplo, Commerce Business Daily es una publicación web que brinda una sinopsis de todos los
trabajos federales de EE. UU. superiores a $ 10,000. Las empresas escanean los trabajos y solicitan RFP
para aquellos en los que podrían estar interesados en ofertar.
A menudo, el cliente precederá a la RFP con una Solicitud de calificaciones o RFQ, que es una
solicitud para que los contratistas describan sus calificaciones. El cliente envía RFP solo a los contratistas
que se consideran calificados para el trabajo.
Figura 3.4 Contenido de una Solicitud de Propuesta.
Por lo general, el cliente obtiene exactamente lo que pide, y las fallas posteriores del
proyecto pueden atribuirse a una RFP deficiente. La RFP debe ser clara, concisa y completa:
cuando lo es, el cliente puede esperar que los contratistas respondan con propuestas claras,
concisas y completas; cuando no lo es, el cliente puede esperar propuestas en especie.
En última instancia, la capacidad de los contratistas para desarrollar soluciones que se
adapten de manera única a las necesidades del cliente dependerá en parte de su comprensión
de los requisitos especificados en la RFP. De manera similar, la capacidad del cliente para
seleccionar un contratista que esté calificado y tenga la mejor propuesta dependerá de la
información provista en la RFP. El Apéndice A al final del libro es un ejemplo de RFP.
Ver Apéndice A
Cada contratista competidor debe considerar su capacidad de preparar una propuesta

ganadora y, en caso de ganar el contrato, de realizar el trabajo propuesto.
Entre las consideraciones están:
• ¿Los competidores ya tienen una ventaja inicial?

• ¿Tiene el contratista suficiente dinero, instalaciones y recursos para invertir en el

proyecto? • ¿Podría el desempeño del proyecto mejorar (o dañar) la
¿reputación?
• Otras consideraciones similares a los criterios empleados por el cliente en la
investigación inicial.
A veces, un contratista presenta una propuesta sabiendo muy bien que no es posible que
gane el proyecto, y lo hace para mantener su relación con el cliente, permanecer en la lista de
licitadores del cliente o mantener el campo competitivo. A veces, un cliente envía una RFP sin
intención de firmar con un contratista, simplemente para recopilar ideas; obviamente, una
situación de la que los contratistas encuestados deben tener cuidado.
Los contratistas también pueden enviar propuestas a clientes potenciales sin una RFP.
Cada vez que un desarrollador cree que tiene un sistema o una solución que satisface una
necesidad o resuelve un problema, el director del proyecto trabaja con su departamento de
marketing para identificar posibles clientes a los que podrían enviar propuestas no solicitadas
que describan las ventajas del nuevo sistema. Las propuestas no solicitadas también se
envían a clientes actuales para un posible trabajo de seguimiento en proyectos actuales.
El estudio de factibilidad
Como se mencionó, un estudio de factibilidad se puede realizar en múltiples momentos y con

diferentes partes en un proyecto: como mínimo, el cliente realiza un estudio para determinar
si vale la pena respaldar el proyecto; si el trabajo del proyecto se va a realizar externamente,
el contratista también realiza uno para determinar si vale la pena continuar con el trabajo. En
esta sección consideramos esto último, aunque los mismos pasos se aplicarían por igual al
cliente oa cualquiera que realice un estudio de factibilidad.
La declaración del problema tal como se define en la RFP es frecuentemente incompleta,
vaga o incluso incorrecta. Si se ha recibido una RFP, es probable que contenga dicha
declaración. Por lo tanto, uno de los primeros pasos del contratista al responder a una RFP
es desarrollar una definición del problema que sea más concisa, precisa y completa que la de
la RFP.
La principal fuente de información sobre el problema son las entrevistas y
información documentada proporcionada por el cliente y usuario. Por lo tanto, es importante que el contratista
identifique quién es realmente el usuario . Sorprendentemente, esto no siempre es obvio. El usuario real, la
parte que operará, mantendrá o será el principal beneficiario del sistema, a menudo se confunde con
personas que solo representan al usuario. Si el cliente es una organización, el contratista debe determinar
las personas cuyas necesidades se van a satisfacer. El contratista debe ser
trabajando en estrecha colaboración con el usuario durante todo el estudio de viabilidad, por lo que es
importante encontrar usuarios que estén familiarizados tanto con el problema como con el funcionamiento
de la organización. A veces, sin embargo, la RFP especifica que para que la competencia sea “justa”, el
cliente mantendrá una relación “de plena competencia” con los contratistas de la competencia. Incluso
entonces, sin embargo, a los contratistas generalmente se les permite hacer consultas o buscar información
adicional de una persona de contacto del cliente.
El estudio de factibilidad a veces da como resultado un documento llamado “caso comercial”.
El caso de negocios
El documento de caso de negocio evalúa el valor y los riesgos (viabilidad) de un proyecto en una etapa
temprana e intenta convencer al cliente/patrocinador para que autorice y lleve a cabo el proyecto. A veces
se utiliza para obtener financiación para el proyecto de los bancos comerciales (un caso de negocio
financiable). En el proceso de elegir entre proyectos, algunas empresas utilizan el caso de negocio para
comparar el valor y los riesgos asociados con un proyecto con los de otros proyectos. Esto se analiza en el
Capítulo 18.
Ver Capítulo 18
El contenido del caso comercial se basa en los resultados de un estudio de factibilidad; si el estudio de
factibilidad indica que el proyecto es viable, entonces se escribe el caso de negocios para justificar el
proyecto. Mientras que el informe final de un estudio de viabilidad compara soluciones alternativas, el caso
de negocio trata de justificar la alternativa elegida.
Un caso de negocios generalmente incluye:
• Análisis de costo-beneficio: costos estimados del proyecto en comparación con los beneficios
• Duración estimada del proyecto (cuando el rendimiento financiero depende de la

cronograma)
• Aspectos financieros tales como el enfoque de financiamiento •

Riesgos, problemas y un plan preliminar de gestión de riesgos • Supuestos.
El caso de negocios contiene estimaciones de costos y beneficios, aunque en algunos casos estas estimaciones
se actualizan a medida que el proyecto avanza en sus primeras fases.
Por ejemplo, la metodología PRINCE2 especifica el desarrollo de un esquema de caso de negocio al inicio del
proyecto y, posteriormente, la revisión y actualización de estas estimaciones después de cada fase del proyecto.
En algunos megaproyectos industriales, las dos primeras fases de un proyecto se denominan FEL-1 (Front-End
Loading-One) y FEL-2; FEL-1 concluye con un caso comercial preliminar, FEL-2 con un caso comercial detallado
y verificado .
A veces, el caso comercial se incluye como parte de un informe de factibilidad más completo que, además
de argumentar el caso comercial, aborda los aspectos técnicos, ambientales, financieros y de otro tipo del
proyecto con mayor detalle que un caso comercial típico.
Definición de necesidades
Los problemas se originan a partir de las necesidades (Definición: un problema es una necesidad insatisfecha),
al igual que las soluciones (Definición: una solución es una forma de satisfacer una necesidad), por lo que es
importante que la solución adoptada para el proyecto responda a las necesidades adecuadas.
Por lo tanto, la realización de un estudio de factibilidad y la preparación de una propuesta deben comenzar con la
7
sugiere los siguientes pasos:
definición de las necesidades del usuario. Marco J. Davidson
1. Pida al usuario que indique las necesidades lo más claramente posible.

Haga al usuario un conjunto completo de preguntas para obtener más información sobre las necesidades. Para
ejemplo:
¿Son estas necesidades reales o hay otras más fundamentales?
¿Son lo suficientemente importantes como para perseguirlos?
¿Somos capaces de satisfacer estas necesidades, o hay alguien mejor

adecuado?
Si las necesidades se satisfacen, ¿darán lugar a otras necesidades?

¿Satisfacer estas necesidades también satisfará otras necesidades?
¿Qué efecto tienen las necesidades insatisfechas en la organización y el
¿usuario?
¿Qué otras partes se ven afectadas por estas necesidades y cómo reaccionarán a
nuestros esfuerzos?
2. Realizar investigaciones para comprender mejor las necesidades. “Investigar” significa sondear
para recopilar la información necesaria para comprender mejor las necesidades, definir el
problema y proponer soluciones. Las fuentes de información incluyen entrevistas, informes,
memorandos, observación, modelos y análisis de datos técnicos y resultados de pruebas
empíricas.
3. Con base en la información de los Pasos 2 y 3, reformule y documente las necesidades.
4. Dar las necesidades replanteadas al usuario.
Los pasos se repiten tantas veces como sea necesario, concluyendo con una declaración de necesidades
que el usuario acepta como la mejor representación de sus intereses (en lugar de los intereses del
contratista o de otras partes).
Dado que cada proyecto es un esfuerzo para satisfacer las necesidades, es necesaria una declaración
de necesidades clara, bien expresada y correcta para evitar un proyecto que sea confuso o irrelevante.
Pero lograr tal declaración de necesidades no es fácil. Frame describe lo siguiente
8
aspectos problemáticos.
• Algunas necesidades cambian constantemente. Son un blanco en movimiento; por lo tanto, para
cada necesidad se debe hacer la pregunta "¿Es probable que esto cambie?" Cuando la respuesta
es sí, las soluciones y los planes de proyectos que abordan la necesidad deben ser flexibles y
fáciles de cambiar. • Se confunden soluciones con necesidades. En lugar de declarar una
necesidad, el usuario o contratista declara una solución. Por ejemplo, la afirmación “Necesitamos
un nuevo edificio” es una solución, no la necesidad. Es cierto que tal vez se requiera un nuevo
edificio, pero un edificio es solo una de las muchas formas de satisfacer la necesidad de, por
ejemplo, superar la escasez de espacio.
• Las necesidades identificadas son para el usuario equivocado. ¿Quién es el usuario? ¿Es la parte
que realmente siente la necesidad y se ve más afectada por ella, o es la parte
¿ Quién paga para resolverlo? Por lo general, son diferentes. La declaración de necesidades debe
reflejar la opinión de la parte a la que se dirigirá la solución: el usuario. No se conforme con que
una de las partes le diga la necesidad de la otra. Hable también con la otra parte. • Hay más de un
usuario y sus necesidades difieren. El usuario encarna varias partes, todas con necesidades
válidas. La pregunta es "¿Se pueden abordar todas sus necesidades?" Dados múltiples usuarios, se
debe intentar organizar, clasificar y priorizar sus necesidades.
• Las necesidades del usuario son distorsionadas por los “expertos”. Sin darse cuenta o
intencionalmente, el contratista lleva al usuario a una definición distorsionada de las necesidades.
El cliente debe tener cuidado de que el contratista pueda:
1. Ampliar la lista de necesidades para que sea mucho más amplia de lo que pensaba el usuario.
Esto aumenta el tamaño del problema y, como era de esperar, el trabajo facturable del
contratista.
2. Replantear las necesidades en términos de lo que él, el contratista, está mejor preparado para
hacer. El contratista satisface fácilmente las necesidades establecidas, pero las necesidades
del usuario quedan sin atender.
3. No pedir sino exponer las necesidades del usuario (porque, al fin y al cabo, el
el contratista es el experto).
A veces, los usuarios se resisten a aclarar sus necesidades y esperan que el contratista lo haga por ellos. El
contratista debe involucrar al usuario y asegurarse de que las dos partes trabajen juntas hasta llegar a una
declaración acordada de las necesidades del usuario. El proceso ayuda tanto a comprender mejor las
necesidades y los problemas, como a asegurar que la solución adoptada es la correcta.
Definición de requisitos de usuario
Conversación entre un usuario y un contratista:
USUARIO: “Usted instaló mi computadora. ¿Por qué no instalaste el enrutador de red?

¿también?"
CONTRATISTA: “Usted dijo que quería que le instalaran la computadora”.

USUARIO: “Pero la computadora no será de mucha utilidad sin un enrutador”.

CONTRATISTA: “Usted dijo que quería que le instalaran la computadora . hice justo lo que tu
solicitado."
Otro intercambio:
CONTRATISTA: “La iluminación para la ampliación de la oficina está terminada. Como acordamos,
conecté 20 luces de techo”.
USUARIO: “Pero la habitación parece un poco oscura”.
CONTRATISTA: “Dijiste que querías 20 luces”.

USUARIO: “Sí, pero dijiste que la habitación estaría iluminada. no lo es.
Ambos casos ilustran los desacuerdos entre el usuario y el contratista sobre los resultados finales.
Malentendidos como estos retrasan la finalización del proyecto, aumentan los costos y, a veces, se
convierten en disputas legales que ponen el resultado en manos de los tribunales.
El problema es la falta de requisitos claros para el usuario. Los requisitos del usuario deben describir
en términos inequívocos lo que el usuario desea en la solución final. Derivados de las necesidades
del usuario, los requisitos son la medida por la cual el usuario determina si el resultado final o la
solución es aceptable o no. Formalmente documentados, son las medidas de calidad del proyecto.
En los ejemplos anteriores, incluirían las funciones que deben cumplir el sistema informático
instalado y la iluminación superior.
Idealmente, los requisitos del usuario abordan las necesidades no solo de los usuarios, sino
también de los constructores, proveedores y otras partes interesadas que se beneficiarán,
administrarán, mantendrán o se verán afectados por el sistema. Quizás obvio, los requisitos del
usuario se establecen en el idioma de los usuarios y otras partes interesadas. El proyecto no debe
comenzar hasta que los requisitos se hayan combinado en una lista de requisitos del usuario y el
cliente y el contratista acuerden que la lista está completa.
A menudo, los usuarios no entienden la necesidad y la importancia de buenos requisitos; por lo
tanto, es responsabilidad del director del proyecto asegurarse de que los requisitos sean completos,
claros y precisos. Cuando se completa el proyecto y el contratista dice "Esto es lo que ordenó", el
usuario debería poder decir "Sí, satisface todos mis requisitos".
Hay muchos tipos de requisitos del usuario. Algunos dan cuenta de los objetivos, el ciclo de vida
y los modos operativos del sistema, otros de las limitaciones e interfaces.
con otros sistemas.
Requisitos para Objetivos y Ciclo de Vida
Cada proyecto y el sistema de artículo final al que se dirige comienzan con una declaración de objetivos
que elaboran las necesidades y proporcionan la base para definir los requisitos. Considere el ejemplo de
SpaceShipOne del Capítulo 1. La necesidad: “un vehículo reutilizable para tres personas que se pueda
lanzar al espacio dos veces en un período de 2 semanas” se puede definir en términos del siguiente
conjunto de objetivos:
Ver Capítulo 1
Desarrollar una nave espacial que pueda:
1 alcanzar una altitud mínima de 100 km (donde comienza el "espacio") 2 ser

reutilizado (lanzado) cada 2 semanas 3 transportar a tres personas.
Luego, cada objetivo se elabora en términos de un conjunto de requisitos. Los requisitos deben tener en
cuenta lo que los usuarios y otras partes interesadas piensen que será significativo a lo largo del ciclo de
vida esperado del sistema, de la cuna a la tumba, lo que significa que deben incorporar cuestiones sobre
cómo se desarrollará, construirá, usará, comercializará, financiará el sistema. mantenida y desechada.
Requisitos para los modos operativos
En este pensamiento de ciclo de vida se incluyen las diferentes formas y tipos de entornos en los que se
usará u operará el sistema, denominados modos operativos. Por ejemplo, los modos para la nave espacial
reutilizable mencionada anteriormente incluyen:
• Modo de vuelo
- Lanzamiento e impulso en el espacio.

- En el espacio
- Regreso del espacio

- Aterrizaje
• Modo de vuelta entre vuelos • Modo de

entrenamiento de la tripulación • Modo de
transporte terrestre • Modo de mantenimiento
y prueba
Se espera que el sistema realice diferentes funciones y satisfaga diferentes condiciones en cada
uno de los modos, y estas funciones y condiciones deben especificarse en los requisitos.
Requisitos para restricciones e interfaces

Todo sistema está sujeto a limitaciones impuestas por el entorno y otros sistemas con los que
debe interactuar. Estos incluyen políticas, procedimientos y estándares obligatorios, y límites en
recursos, tiempo, financiación, tecnología y conocimiento. Además, enfrenta restricciones
ambientales que incluyen requisitos tecnológicos, leyes e incluso normas y costumbres sociales.
Por ejemplo, entre numerosas restricciones y sistemas de interfaz, la nave espacial debe cumplir
con las regulaciones de la FAA, los estándares técnicos de la industria aeroespacial y las leyes
locales sobre ruido y contaminación, y debe poder interactuar con los sistemas existentes para el
control del tráfico aéreo y la comunicación.
El sistema actual
Figura 3.5 Esquema del sistema: Flujo de insumos al quirófano.
Conceptualmente, surge una necesidad debido a las insuficiencias del sistema

actual; existe una brecha entre la capacidad del sistema actual y la capacidad
deseada. Un propósito del estudio de factibilidad es comprender y documentar el
sistema actual, incluidas sus entradas, salidas, funciones, flujos, subsistemas,
componentes, relaciones, atributos, recursos y restricciones. El esquema del
sistema en la Figura 3.5, por ejemplo, muestra los elementos y flujos de un sistema
hospitalario; fue desarrollado en un proyecto para reducir el costo de los insumos
en el quirófano. Por supuesto, a veces surgen necesidades simplemente porque no
existe un sistema actual. Ese sería el caso de SpaceShipOne.
Análisis de Soluciones Alternativas
A través del proceso de definición y documentación de necesidades, requisitos y la

sistema actual, el contratista desarrolla una buena comprensión del problema y es capaz de
delimitar el alcance de las formas alternativas para resolverlo. El contratista comienza a
desarrollar soluciones alternativas de alto nivel (a nivel del sistema) para el problema a partir
de estudios y modelos que toman en cuenta lo que debe hacer el sistema (requisitos del
usuario), cómo se puede hacer (consideraciones técnicas) y qué hará. costo (consideraciones
económicas). Las soluciones pueden incluir nuevos sistemas desarrollados desde cero o
modificaciones de sistemas estándar y tecnología existente. Un buen gestor de proyectos
fomenta la creatividad y el libre flujo de ideas en la búsqueda de soluciones.
Las soluciones alternativas se analizan en cuanto a su capacidad para satisfacer los

objetivos y los requisitos del usuario dentro de los recursos disponibles y las restricciones
impuestas. Se elige la mejor solución y se propone al cliente. El siguiente ejemplo ilustra.
Ejemplo 3.4: Requisitos del usuario y

solución factible para el proyecto X-Prize
La competencia X-Prize descrita en el Capítulo 1 requería desarrollar un sistema

completo que cumpliera con numerosos requisitos relacionados con todo lo necesario
para diseñar, construir y operar una nave espacial. Entre los numerosos requisitos de
los usuarios para la nave espacial se encuentran:
Ver Capítulo 1
• Ascienda a una altitud de al menos 100 km

• Lleve a tres personas • Proporcione un
vuelo seguro y cómodo • Sea relativamente
económico de diseñar, construir y lanzar • Tener un tiempo
máximo de “retorno” para la reutilización dentro de un máximo de 2
semanas.
Asociados con cada uno de estos requisitos hay muchas cuestiones, problemas y
soluciones alternativas. Una cuestión que afecta a todos los requisitos es la
pregunta básica de cómo, exactamente, llevas a las personas al espacio y luego regresan a casa de
manera segura?
Las alternativas son:
1. Llegar al espacio
una. Lanzar una nave espacial desde lo alto de un cohete

propulsor b. Lanzar nave espacial desde un avión de alto vuelo
2. Estar en el espacio
una. Entrar en órbita

terrestre b. No entres en órbita terrestre
3. Volviendo a la Tierra
una. Seguir un amplio arco parabólico

b. Sigue un arco angosto que va casi recto hacia arriba y casi recto hacia abajo
4. Aterrizaje
una. Aterrizar en una “zona” usando un paracaídas

b. Aterrizar en un aeropuerto como un avión
Después de considerar los requisitos y limitaciones, el diseñador Burt Rutan eligió la combinación de
alternativas 1-b, 2-b, 3-b, 4-b: lanzar la nave espacial desde un avión de alto vuelo, no entrar en órbita,
seguir una parabólica estrecha trayectoria hacia arriba y hacia abajo, y aterriza como un avión. La
elección de estas alternativas involucró un análisis de costo, riesgo, tecnología, tiempo y capacidad
para cumplir con los requisitos.
Impacto medioambiental
Parte de la viabilidad de un proyecto es determinar el sistema del proyecto o del elemento final.
impacto en el entorno natural. En 1969, EE. UU. promulgó una legislación que exige que todos los
proyectos que reciben financiamiento o licencias federales deben evaluar e informar sobre los impactos
ambientales del proyecto en una Declaración de Impacto Ambiental (EIS).
Desde entonces, Canadá, Australia, Nueva Zelanda, Japón, países de la Unión Europea y otros han
ratificado leyes que requieren Evaluaciones de Impacto Ambiental (EIA).
El contenido de la EIS varía según el estado, el país y la región, pero por lo general incluye:
1. Un resumen de los planes de manejo y/o desarrollo propuestos 2. Sitios y

tecnologías alternativos para el proyecto propuesto 3. Una descripción del sitio
existente del proyecto y el área circundante 4. Impactos potenciales del proyecto,
tales como:
• Calidad del aire, suelo, cuencas hidrográficas, humedales, planicies

de inundación • Pesca; plantas sensibles; sensibles, en peligro o amenazadas
especies
• Recursos paisajísticos; experiencias sociales y estéticas •
Recursos patrimoniales (sitios, estructuras, edificios, distritos, objetos) • Recursos
históricos (tala, ganadería, pastoreo, minería, recreación)
5. Impactos adversos que no se pueden evitar 6.

Impactos a largo plazo sobre los recursos 7. Formas
de prevenir, minimizar o compensar los impactos; maneras de monitorear
impactos
El EIS es seguido por una serie de revisiones públicas y audiencias para discutir los hallazgos y
determinar las acciones de seguimiento, especialmente en relación con la última viñeta anterior. Dado
que los resultados de la EIS a menudo afectan el plan del proyecto y el diseño del sistema, los
administradores y partidarios del proyecto deben tratar de desarrollar una relación de trabajo positiva con
el equipo de evaluación ambiental.
Sustentabilidad
En las últimas décadas, el aumento del consumo de energía y el uso de fuentes no renovables
ha provocado efectos ambientales nocivos como la destrucción del hábitat, la pérdida de biodiversidad, la
desertificación y la emisión de gases de efecto invernadero. Los propios proyectos y los productos finales
que producen contribuyen significativamente a tales efectos. En consecuencia, una forma de mitigar el daño
es diseñar y construir productos, y gestionar los proyectos que lo hacen, teniendo en cuenta la sostenibilidad.
Muchas industrias han tomado medidas para incorporar la responsabilidad ambiental y social en el papel
de la gestión de proyectos. Por ejemplo, la industria de la construcción ha creado pautas (a veces por
mandato del gobierno) para diseñar y construir edificios (los llamados "diseño para el medio ambiente" y
"construcción ecológica", respectivamente) para reducir la contaminación del aire y el agua, los desechos de
los vertederos y las emisiones de carbono. . Como ejemplos, las pautas de diseño de edificios en el Reino
Unido exigen el uso de:
• Sistemas de ventilación pasiva •

Sistemas de recuperación de calor para todo el
edificio • Materiales renovables/reciclados •
Materiales sin efectos nocivos para el medio ambiente y eficiencia energética en términos de
fabricación, uso y eliminación.
Las pautas de construcción en los EE. UU. incluyen:
• Reducir los residuos de vertedero: triturar/reutilizar agregados (piedra, etc.); utilizar proveedores que
acepten devoluciones/cambios, reutilizar embalajes y utilizar productos de construcción recuperados/
reciclados.
• Minimizar el polvo del hormigón/mortero; evitar la contaminación del aire/agua. •
Usar madera y productos de madera con el Forest Stewardship Council's
marca comercial.
• Usar formas de construcción de bajo consumo de energía para minimizar el CO2 de las actividades
del sitio. • Reduzca los viajes hacia/desde el sitio y use proveedores locales para reducir el transporte
CO2.
En los EE. UU., el programa de certificación LEED (Liderazgo en Diseño Ambiental y Energético) ha creado
estándares de diseño y desarrollo de edificios sostenibles. Los estándares incluyen muchas de las pautas
enumeradas anteriormente, así como
9
como:
• Instalación de ventanas que proporcionen abundante aire fresco y luz natural. • Selección del
sitio: no construya en tierras de cultivo de primera calidad ni demasiado cerca de una zona amenazada.
hábitat de los animales
• Construir cerca de alternativas de transporte y a poca distancia de diez

servicios basicos.
Las cuestiones de sostenibilidad surgen a lo largo del ciclo de vida del proyecto: en el inicio, la viabilidad y la
definición del proyecto; en la RFP, propuesta, contrato, requisitos y plan de proyecto; en análisis de riesgos;
y en la ejecución de proyectos. Aunque en algunos casos los gerentes de proyecto tienen poca capacidad
para influir en tales asuntos, en otros la tienen; pueden influir en los diseñadores del artículo final y seleccionar
a los contratistas y proveedores correctos con el objetivo de la sostenibilidad y minimizar el 10 El plan del
proyecto debe garantizar mínimamente el impacto ambiental del proyecto. que el proyecto y sus resultados
federales; donde las leyes son inadecuadas, los gerentes

cumplande
con
proyecto
las leyes
pueden
ambientales
tomar la
locales,
iniciativa.
estatales y
El resultado del estudio de factibilidad es una declaración del problema, una lista de necesidades y
requisitos del usuario, una descripción de la situación actual y una solución preferida y las razones para su
selección. El estudio de factibilidad, cuando se combina con el plan del proyecto, el precio de la oferta y las
calificaciones del contratista, forman la propuesta del proyecto.
3.5 La propuesta de proyecto
11
Preparación de propuestas
La propuesta le dice al cliente lo que pretende hacer un contratista; es la base para seleccionar al
contratista del proyecto. El esfuerzo de preparar la propuesta es en sí mismo un proyecto y, por
tanto, debe gestionarse como tal. Dado que la preparación de una propuesta a veces implica mucho
tiempo y dinero, por lo general requiere la autorización de la alta dirección. Previa autorización, la
gerencia identifica a una persona técnicamente competente para supervisar la preparación de la
propuesta; a menudo, esta persona se convierte en el director del proyecto si se gana el contrato.
Ella podría ser completamente responsable de administrar el esfuerzo de preparación de la
propuesta o, alternativamente, trabajar con otro gerente que se especialice en realizar actividades
relacionadas con la propuesta.
El director del proyecto selecciona el equipo del proyecto, o parte de él, para ayudar a preparar la
propuesta; por lo general, la mayor parte del equipo del proyecto no se especifica hasta después de la
se gana el contrato.
El director del proyecto revisa los requisitos de la RFP y prepara un resumen detallado del
proyecto propuesto. Este resumen guía el esfuerzo y evita que el enfoque se desplace hacia
consideraciones técnicas o administrativas irrelevantes.
El equipo del proyecto describe el trabajo a realizar para la solución identificada en el estudio de
factibilidad y prepara una declaración de trabajo o SOW. El SOW incluirá el sistema y los objetivos
del proyecto, la solución técnica, los requisitos de alto nivel y las principales áreas de trabajo
requeridas para entregar la solución. Si aparecía un SOW en la RFP (por ejemplo, la Figura 3.4) ,
entonces el SOW en la propuesta podría repetirlo, pero también debería incluir nueva información
recopilada durante el estudio de factibilidad y detalles sobre la solución elegida. En los casos en
que el contratista cree que la SOW en el
RFP es inexacto o incorrecto, el contratista debe indicarlo en la propuesta.

Durante la preparación de la propuesta, el equipo del proyecto debe pensar en todo el proyecto
y preparar un plan de proyecto rudimentario que abordará los problemas de tiempo, costo y
rendimiento del proyecto. Utiliza una estructura de desglose del trabajo (WBS) para
determinar las tareas necesarias para lograr los requisitos y preparar un cronograma y una
estimación de costos (temas discutidos en capítulos posteriores). La propuesta a veces
incluye la WBS, el cronograma y un desglose de costos que muestra cómo se derivó el
precio del proyecto. Cuando se proponen múltiples soluciones, se incluye un esquema
aproximado de cada una.
La propuesta es un dispositivo de venta y, si se acepta, también un contrato: una buena
propuesta no solo proporciona el precio, el cronograma y otros detalles, sino que convence
al cliente de que el contratista es competente y capaz de realizar el trabajo.
Todos los departamentos funcionales de la organización del contratista que puedan
proporcionar información relevante deben ayudar con la propuesta. Esto aumenta la precisión
de las estimaciones de la propuesta y crea el compromiso de los grupos que luego trabajarán
en el proyecto.
Mientras se prepara la propuesta, el contratista debe establecer un diálogo con el cliente
para determinar qué soluciones prefiere y qué requisitos son dominantes entre tiempo, costo
y desempeño. Incluso cuando la RFP es clara, esto ayudará a garantizar que la propuesta
se ajuste a las especificaciones de la RFP y satisfaga los requisitos del usuario. La
preparación de propuestas puede ser iterativa: la aceptación de una propuesta conduce a la
preparación de otra propuesta más detallada, como se ilustra a continuación.
Ejemplo 3.5: Redacción de propuestas para

proyectos inmobiliarios en Cwutzrite Company
El departamento inmobiliario de Wutzrite Company ayuda a los clientes a elegir entre

alternativas de inversión inmobiliaria. Se programa una reunión con el cliente para
definir el “problema” de inversión y las metas del cliente; el cliente y varios empleados
de Wutzrite intercambian ideas para obtener una definición clara y precisa del problema.
Posteriormente, un director de proyecto prepara una propuesta para el cliente que
incluye el enunciado del problema, una solución propuesta y el precio.
Las propuestas que involucran el desarrollo del sitio o el diseño y construcción de un
edificio incluyen un estudio de factibilidad; para las propuestas que implican solo
evaluar, mejorar o determinar el valor de un sitio, no se necesita un estudio de
factibilidad. Si al cliente le gusta la propuesta, el director prepara una segunda,
propuesta más detallada que incluye una EDT y cronograma actualizado. Si el cliente lo
aprueba, la segunda propuesta se convierte en el plan de proyecto de alto nivel.
Especifica las tareas a realizar y las fechas previstas, y es la base para la asignación de
personal al proyecto.
La aprobación de la segunda propuesta generalmente requiere un estudio de
factibilidad, un estudio demográfico y un análisis de las ramificaciones financieras,
fiscales y contables de la solución recomendada; los resultados se combinan y se envían
al cliente en una tercera propuesta que sugiere cursos de acción particulares con respecto
a la solución.
El estudio de viabilidad y la preparación de la propuesta pueden tardar semanas o meses

en completarse. Si bien se debe dedicar suficiente tiempo para producir una buena propuesta,
no se debe gastar tanto tiempo que se vuelva excesivamente lento o costoso. Una buena regla
general es: ¡No intente hacer todo el proyecto mientras prepara la propuesta! En algunos
proyectos técnicos, esto puede ser inevitable ya que la propuesta incluye una demostración a
gran escala de la solución propuesta.
Desarrollar el sistema para demostración puede ser en sí mismo equivalente a un proyecto de
buen tamaño.
Para asegurarse de que nada se pase por alto en la preparación de la propuesta, los
gerentes de proyecto generalmente emplean listas de verificación que, con los años, crecen
para acumular todos los elementos importantes de una propuesta, incluidas, por ejemplo,
consideraciones clave para el diseño, ensamblaje, prueba, envío, documentación, instalaciones,
subcontratistas, suministros, viajes, tarifas de mano de obra, capacitación y pago. Antes de
que la propuesta pueda presentarse al cliente, la alta dirección del contratista debe ser
informada sobre el alcance del proyecto, los recursos necesarios, el precio, etc., y aprobarlo.
Las propuestas varían en longitud desde unas pocas páginas hasta varios cientos. El
contenido varía según, por ejemplo, el formato preferido por el cliente, la relación entre el
cliente y el contratista, la complejidad técnica del trabajo y si la propuesta fue solicitada o no
solicitada. La Figura 3.6 muestra los ingredientes principales de una propuesta típica. 12 Si la
debe cumplir exactamente
propuesta
con los
se requisitos
prepara enderespuesta
la propuesta
a una
o las
RFP,
pautas
su contenido.
establecidas
y el en
formato
la
RFP. El Apéndice B al final del libro es la propuesta para el proyecto LOGON preparado por
Iron Butterfly Company.
Figura 3.6 Contenido de una propuesta.
Ver Apéndice A
La cantidad que gasta un contratista en la preparación de propuestas y la proporción de contratos

que gana afectan significativamente los gastos generales de la empresa, ya que los gastos de
preparación de propuestas deben imputarse a los gastos generales. Solo en casos excepcionales,
como los contratos de defensa importantes, se reembolsa a los contratistas ganadores por la propuesta.
gastos.
Selección de la propuesta ganadora

Al recibir propuestas de varios contratistas, el cliente las evalúa y compara. Seleccionar la mejor
propuesta, llegar a un acuerdo con el contratista y comprometer fondos son parte del proceso de
“selección de proyectos”.
La mayoría de las empresas siguen un procedimiento prescrito para evaluar y comparar propuestas.
Cuando la selección implica evaluar cada proyecto propuesto por su contribución a una cartera de
proyectos, el procedimiento es más complicado e incluye evaluar la contribución del proyecto a los
objetivos estratégicos de la empresa, los recursos que implicará y sus beneficios financieros
comparativos. Los temas de selección de proyectos y carteras de proyectos son amplios; los lectores
interesados deben ver el Capítulo 18 donde se tratan en profundidad. Aquí damos una breve
descripción del proceso de selección de proyectos.
Ver Capítulo 18
En general, la selección de proyectos se basa en la consideración de los siguientes criterios (a

veces proporcionados a los contratistas en la RFP):
• Precio del
proyecto • Capacidad del contratista para satisfacer las necesidades establecidas (solución o técnica
enfoque) •
Retorno de la inversión •
Plan y gestión del proyecto •

Calificaciones y reputación del contratista •
Probabilidad de éxito o fracaso (riesgos) • Adaptación
a los recursos y la capacidad tecnológica del contratista.
El cliente puede suponer que un contratista competente con un buen plan hará un buen trabajo y, por
lo tanto, seleccionar al contratista con las mejores calificaciones o el mejor plan en lugar de la solución
propuesta o el enfoque técnico. Por lo tanto, cada propuesta debe incluir un plan de proyecto
rudimentario que muestre las actividades clave, las fechas de inicio y finalización y los entregables de
cada una. Los contenidos del plan y los métodos para preparar el plan se analizan en los Capítulos 5
a 10.
Ver capítulos 5 a 10
La selección de la mejor propuesta a menudo comienza con la preselección de las propuestas y el

rechazo de las que no cumplen con ciertos requisitos límite, como un precio demasiado alto, una tasa
de rendimiento demasiado baja o una experiencia insuficiente del contratista.
Las propuestas que sobreviven a la preselección se someten a un escrutinio más detallado: un
método de evaluación común, llamado calificación simple, emplea propuestas de calificación de
acuerdo con varios criterios de evaluación en una lista de verificación. Cada propuesta recibe una
puntuación sj para cada criterio j. La puntuación global de la propuesta es la suma de las puntuaciones
de todos los criterios,
La propuesta que recibe la puntuación general más alta gana.

Una limitación del método es que todos los criterios de evaluación se tratan como
igualmente importante. Cuando algunos criterios son claramente más importantes que otros, se utiliza
un método llamado calificación ponderada en el que la importancia relativa de cada criterio j se indica
con un peso asignado wj. Una vez que se ha puntuado un criterio dado, la puntuación se multiplica por
el peso del criterio, sj · wj. La puntuación global de la propuesta es la suma de los sj · wj. Para todos
los criterios,
Los procedimientos para los dos métodos se ilustran en el ejemplo 3.6.
Ejemplo 3.6: Evaluación de las propuestas en la

empresa MPD
En respuesta a su RFP para el proyecto LOGON (Apéndice A, final del libro), MPD Company
recibió propuestas de tres contratistas: Iron Butterfly Contractors, Inc.; Compañía de pelota baja;
y Modicum Associates. Cada propuesta fue revisada y calificada por un grupo de gerentes de
operaciones en MPD en cinco criterios utilizando la siguiente escala de cuatro puntos:
Criterios 1 2 3 4
Enfoque de solución técnica Pobre Adecuado Bueno Excelente
Precio del contrato >1,8 1,6–1,8 1,4–1,6 <1,4
Organización y gestión de proyectos Pobre Adecuado Bueno Excelente

Probabilidad de cumplir con los objetivos de costo/calendario Pobre Adecuado Bueno Excelente
Reputación del contratista Pobre Adecuado Bueno Excelente
Clasificación sencilla
Los resultados de las evaluaciones de las tres propuestas fueron los siguientes:
Puntuaciones
Hierro
Criterios Módica de bola baja
Mariposa
Enfoque de solución técnica 3 1 4
Precio del contrato 4 4 1
Organización/gestión de proyectos 4 2 3
Probabilidad de cumplir con el costo/horario 3 2 4

objetivos
Reputación del contratista 3 3 4
Suma 17 12 dieciséis
Basado en la suma de calificaciones simples, Iron Butterfly fue calificado como el mejor.
Calificación ponderada
Usando la calificación simple, Lowball fue claramente el peor, pero Iron Butterfly
y Modicum se consideraron demasiado cercanos para diferenciarlos. El grupo de calificación
luego decidió mirar los criterios más de cerca y asignar pesos a los
criterios basados en su importancia relativa:
Criterios Peso
Enfoque de solución técnica 0.25
Precio del contrato 0.25
Organización y gestión de proyectos 0.20
Probabilidad de cumplir con los objetivos de costo/calendario 0.15
Reputación del contratista 0.15
1.00
Teniendo en cuenta los pesos, las propuestas puntuaron de la siguiente manera:
Usando la suma de las calificaciones ponderadas, Iron Butterfly es claramente superior

propuesta.
La evaluación de las propuestas también podría incluir la evaluación del riesgo del proyecto, especialmente
cuando las soluciones propuestas y los niveles de riesgo asociados difieren significativamente
entre propuestas. Los métodos para identificar y evaluar los riesgos se analizan en el Capítulo 10.
Ver Capítulo 10
A veces, la adjudicación del contrato depende más de las calificaciones del contratista
13
que en la solución propuesta. Entre los factores que el cliente podría considerar están:
• ¿Es el contratista lo suficientemente grande o está adecuadamente financiado para

realizar el proyecto? • ¿Tiene un buen historial con este tipo de proyectos? • ¿Tiene
buena reputación en la industria? • ¿Ha estado involucrado en litigios y arbitrajes? •
¿Será accesible su gestión? • ¿Tiene ISO 9000, ISO 14000 u otra certificación? •
¿Será probable que la relación con el contratista sea amistosa o delicada?
Se notifica a los finalistas de la propuesta y se les puede solicitar que proporcionen más datos o
que hagan presentaciones o demostraciones en vivo de su solución o sistema propuesto. Si varios
contratistas reciben calificaciones cercanas o algunos aspectos de sus propuestas no están
especificados o son cuestionables, entonces las partes deben negociar para llegar a un acuerdo
sobre los términos finales. Si ninguna de las propuestas es aceptable o los estudios de factibilidad
muestran que el proyecto sería demasiado costoso, arriesgado o llevaría mucho tiempo o no
brindaría los beneficios adecuados, el proceso termina y nadie obtiene un contrato.
Cuando un contratista no obtiene el trabajo, una buena práctica es realizar una propuesta “post
mortem” para determinar por qué no, las lecciones aprendidas y qué haría diferente la próxima vez.
Iniciación del proyecto: variaciones sobre un tema
Los proyectos se inician en respuesta a una necesidad, pero no siempre implican una RFP o
incluso una propuesta. El proceso de RFP/propuesta descrito se aplica en gran medida a proyectos
en los que el trabajo se subcontrata; es decir, cuando el cliente y el contratista no están en la
misma organización. Para proyectos internos: proyectos en los que la organización tiene la
capacidad de realizar el trabajo por sí misma, la iniciación
podría suceder con el estudio de caso de negocios descrito anteriormente. Ejemplos comunes
de esto son los proyectos de desarrollo de productos (PD) y TI, dos áreas en las que las
empresas a menudo exhiben una destreza interna significativa. En PD, la "necesidad" se
manifiesta como el deseo o el mandato de llenar un nicho de mercado percibido o responder a
una amenaza competitiva. El estudio de caso de negocios aborda el mercado, la competencia,
el producto propuesto, el riesgo, el costo y los beneficios, y argumenta a favor del lanzamiento
de un nuevo esfuerzo de DP. Si se aprueba el caso, el proyecto se entrega al departamento de
PD para comenzar a trabajar. Por lo tanto, el estudio de caso empresarial tiene un doble
propósito: es el estudio de factibilidad y la propuesta combinados. Los proyectos de TI son
igualmente iniciados por estudios de casos de negocios.
El departamento que haría el proyecto si fuera aprobado (PD o TI) prepara el estudio de caso
de negocios y argumenta a favor del producto final o la solución propuesta. La aprobación o
denegación del proyecto implica calificar el caso frente a casos en competencia en términos de
los recursos necesarios, los beneficios en comparación con los objetivos y la prioridad de las
necesidades: el proceso de selección descrito en el Capítulo 18. Si se aprueba el proyecto, se
crea un acta de constitución del proyecto, como se describe en el Capítulo 4.
El proceso de RFP/propuesta como se describe representa proyectos con relativamente

pocas partes interesadas o un único cliente claramente identificado y sus posibles contratistas.
En grandes proyectos técnicos que involucran a muchas partes interesadas, el proceso es más
prolongado. Los ejemplos incluyen proyectos de infraestructura y sistemas de transporte (Boston
Big Dig, Delhi Metro, sistemas de telecomunicaciones, Chunnel), sistemas técnicos en los que
los subsistemas y componentes deben desarrollarse desde cero (aviones comerciales,
SpaceShipOne, dispositivos médicos) y desarrollos inmobiliarios a gran escala (resorts ,
aeropuertos, comunidades planificadas).
En tales casos, donde es más difícil definir las partes interesadas y reunirse
sus necesidades múltiples y, a veces, contradictorias: el proceso de RFP/propuesta incluye un

componente "inicial" para identificar a las partes interesadas importantes e incorporar sus
necesidades en una lista de requisitos de las partes interesadas. El contratista que reúne los
requisitos de las partes interesadas puede ser contratado únicamente para ese propósito y no
ser el mismo contratista que realizará el trabajo del proyecto. Una vez que se han identificado
las partes interesadas y sus necesidades, se solicitan otros contratistas
para revisar los requisitos y sugerir soluciones, posiblemente a través del proceso de
RFP/propuesta. El proceso de identificar a las partes interesadas y sus requisitos es
un esfuerzo de ingeniería de sistemas que tiene en cuenta los efectos de largo
alcance del sistema y las muchas partes interesadas que tocarán (o serán tocadas
por) el sistema resultante a lo largo de su ciclo de vida.
3.6 Contratación de proyectos
Proceso y entorno de contratación14
La contratación es omnipresente en la gestión de proyectos, ya que todo el trabajo se realiza

de acuerdo con contratos formales o informales. Incluso en proyectos internos donde no hay
contrato, existe un acuerdo entre los grupos de usuarios y desarrolladores sobre el trabajo a
realizar para cumplir con los objetivos y requisitos especificados previamente.
La mayoría de los proyectos, incluso los internos, involucran cierto grado de contratación
legal externa porque el cliente a menudo debe contratar a alguien externo para realizar al
menos parte del trabajo. En muchos proyectos, todo en el proyecto es realizado o
proporcionado por organizaciones externas. Como ilustra la Figura 3.7 , estas “organizaciones
externas” pueden estar vinculadas por numerosos acuerdos contractuales. El cliente puede
contratar a una parte principal (contratista principal o SDO) para supervisar todo el proyecto;
a su vez, esta parte podría contratar a otras partes (subcontratistas, consultores, proveedores
de materiales y mano de obra contratada (profesionales sindicales)) para que sean
responsables de partes del proyecto; estas partes podrían entonces contratar con otras más.
El proceso de RFP/ propuesta aborda la cuestión de quién hará el trabajo, no solo para el
cliente sino también para cualquier parte que busque contratar a otra para que haga el trabajo.
Ya sea el cliente, el contratista principal u otra empresa en el futuro, cada uno sigue un
proceso idéntico o análogo al proceso de RFP/propuesta para documentar sus necesidades,
solicitar ideas y elegir entre posibles contratistas. Por lo tanto, cualquier contratista que ceda
partes del trabajo a subcontratistas o adquiera materiales o servicios de proveedores seguirá
el proceso de RFP/propuesta para identificar y elegir a los subcontratistas y proveedores más
calificados. Así como el cliente sigue el proceso para contratar a un contratista, el contratista
lo sigue para contratar subcontratistas y así sucesivamente.
Figura 3.7 Partes contratantes en un proyecto.
El esfuerzo requerido para revisar y contratar subcontratistas calificados puede llevar

mucho tiempo, especialmente en proyectos internacionales, por lo que se debe asignar tiempo
adicional en el cronograma del proyecto. De lo contrario, el proceso de selección de
subcontratistas puede retrasar el inicio de partes del proyecto y luego hacer que todo el
proyecto se retrase.
El cliente debe tratar de mantener una medida de control sobre el trabajo contratado.
Con ese fin, el contrato debe especificar claramente las áreas del proyecto sobre las cuales el
cliente tiene la máxima autoridad para la supervisión y las decisiones, y el papel del cliente en
el seguimiento del progreso del proyecto. Desde el momento en que se firma el contrato hasta
que se cierra o finaliza el proyecto, se debe administrar el acuerdo contractual, lo que significa
mantener el acuerdo actualizado con respecto a los cambios continuos en el proyecto, las
necesidades del cliente y el la capacidad del contratista y verificar que todo el trabajo se ajuste
al acuerdo.
15
Este proceso, llamado administración de contratos, se analiza en el Capítulo 11.
Ver Capítulo 11
Subcontratación
dieciséis
Cada parte en la Figura 3.7 debe decidir qué partes del proyecto hará ella misma y qué
partes contratará a otros. Algunos contratistas hacen el trabajo; unos contratan a otros para
que lo hagan, es decir, subcontratan. Por ejemplo, un cliente contrata a un contratista general
o principal para administrar un proyecto de construcción y, quizás, para ensamblar la
estructura del edificio, pero luego el contratista contrata a otras empresas para trabajos
especializados como cableado, plomería, ventilación y detalles interiores.
Ejemplo 3.7: Contratos de proyecto en construcción
Los grandes proyectos de construcción a menudo aparecen en las noticias, a veces

debido a problemas debido a sobrecostos o retrasos en el cronograma. Aunque se
citan muchos factores (problemas sindicales, escasez de materiales, clima e inflación),
la causa suele ser una mala gestión y falta de control.
A menudo, el director del proyecto es el arquitecto, el ingeniero o el contratista principal
del constructor. Esto funciona en trabajos de construcción pequeños, pero no en
trabajos grandes porque los diseñadores y los contratistas representan intereses separados.
Cuando las cosas van mal y surgen discusiones, ambos tienden a ser egoístas y no
hay nadie que sea imparcial y pueda reconciliar las diferencias en el mejor interés del
cliente (propietario o desarrollador).
Un mejor arreglo es cuando el cliente designa a un gerente de proyecto de
construcción independiente para que represente sus intereses durante todo el proceso
de diseño y construcción. La Figura 3.8 muestra dos formas posibles de organizar esto,
EPCM y EPC ("Gestión de Ingeniería, Adquisiciones y Construcción" vs. "Ingeniería,
Adquisiciones y Construcción"). En la figura, EPCM y EPC representan al gerente de
proyecto independiente. En el caso de EPCM, el cliente contrata directamente con el
diseñador y el contratista de obras; en el caso de EPC, el gerente de proyecto
independiente hace esto. En cualquier caso, la posición central del director del proyecto
en la organización del proyecto le permite supervisar y coordinar todas las tareas de
diseño y construcción de acuerdo con los objetivos del cliente.
La función principal del gerente de proyecto de EPCM es garantizar que los diseños
estén dentro de los costos permitidos y los requisitos de construcción del cliente, y que
el trabajo del constructor se ejecute de acuerdo con las especificaciones del contrato y
a un precio justo. El gerente del proyecto está involucrado en todo: supervisa el diseño
preliminar, subcontrata y controla el trabajo en el sitio de acuerdo con las especificaciones
de diseño, el cronograma, el presupuesto y las reglas de seguridad. Aunque el cliente
firma contratos con el diseñador y el constructor, el director del proyecto actúa como
agente del cliente para facilitar las relaciones entre las partes.
Un gerente de proyecto de EPC actúa de la misma manera que en EPCM, sin

embargo, al haber contratado directamente al diseñador y al constructor, el gerente de
proyecto de EPC tiene plena autoridad y responsabilidad por todos los elementos del
diseño y la construcción de la estructura, generalmente como una instalación “llave en mano”.
Como consecuencia, el cliente está mucho menos involucrado en el proyecto que en el
caso de EPCM.
Figura 3.8 Tipos alternativos de gerente de proyecto en un proyecto de construcción.
Incluso un contratista que podría ser capaz de hacer todo el trabajo por sí mismo puede optar
por subcontratar porque tiene una capacidad limitada o cree que un subcontratista podría
hacer el trabajo a un costo menor o con menos riesgo. Para proyectos de desarrollo de gran escala
sistemas, el contratista principal generalmente diseñará el sistema general y los principales

subsistemas, y producirá algunos elementos del propio sistema, pero subcontratará la
producción de todos los demás. En proyectos donde se subcontratarán porciones significativas
del trabajo del proyecto, el cliente a menudo exige el alcance del trabajo subcontratado y los
criterios para la selección de contratistas adecuados o
proveedores.
Por lo general, las obligaciones en los subcontratos existen únicamente entre un contratista
y un subcontratista. Eso significa, por ejemplo, que el contratista (no el cliente) es responsable
de garantizar que un subcontratista realice el trabajo de acuerdo con los requisitos, y el
contratista (no el cliente) está obligado a pagar por el trabajo subcontratado. El contratista
también es responsable de la calidad de los materiales, equipos o componentes entregados y
de la inspección en las instalaciones externas del subcontratista. Del mismo modo, cualquier
comunicación sobre los cambios de los requisitos del cliente se canaliza a través del contratista
al subcontratista. (Sin embargo, si usted es un subcontratista y tiene problemas para que le
paguen, puede apelar directamente al cliente para presionar al contratista para que le pague).
El trabajo que se contrata, subcontrata o adquiere de proveedores se denomina bienes,

trabajo y servicios "adquiridos". Como todo lo demás en los proyectos, el trabajo adquirido
debe planificarse, programarse, presupuestarse y controlarse: debe gestionarse. Llamada
gestión de adquisiciones, esto se describe en el Capítulo 5.
Ver Capítulo 5
17
Negociación de contrato
La negociación del contrato es el proceso de aclarar los términos técnicos o de otro tipo en el
contrato y llegar a un acuerdo sobre el tiempo, el cronograma y las obligaciones de desempeño.
La negociación no es necesaria para proyectos estandarizados para los cuales los términos
son simples y los costos bastante conocidos, pero sí para sistemas complejos que requieren
trabajo de desarrollo o son algo riesgosos. De hecho, cuando se envía una IFB (invitación a
licitación) para un artículo estándar o bien definido y el precio es el único criterio, la negociación
sería poco ética y no está permitida. Diferentes acuerdos contractuales ofrecen ventajas para
el cliente y el contratista, dependiendo de la
naturaleza del proyecto. Estos acuerdos se discuten en el Apéndice de este capítulo; son,
brevemente:
• Contrato de Precio Fijo: El precio pagado por el cliente por el proyecto es fijo
independientemente de los costos incurridos por el contratista. El cliente sabe lo que
costará el proyecto.
• Contrato Cost-Plus: El precio pagado se basa en los costos incurridos en el proyecto
más la tarifa del contratista. El contratista tiene la seguridad de que sus costos serán
cubiertos.
• Contrato de Incentivo: El monto pagado depende del desempeño del contratista en
comparación con el precio objetivo, cronograma o especificación técnica. El
contratista recibe una bonificación por exceder la meta o debe pagar una multa por
no cumplirla.
El tipo específico de acuerdo contractual entre el cliente y el contratista principal determina el

tipo de acuerdo negociado con los subcontratistas. Si el acuerdo de contrato principal es de
precio fijo (FP), entonces los acuerdos de subcontrato también deben ser FP, de lo contrario,
el contratista principal corre el riesgo de que los subcontratistas le cobren más de lo que
recibirá del cliente. Si el contrato principal es de costo adicional o de incentivo, el contratista
tiene libertad para utilizar cualquier tipo de acuerdo para los subcontratos.
La negociación es la última actividad antes de llegar a un acuerdo de contrato, pero el

proceso de negociación a menudo comienza antes durante la preparación de la propuesta
porque los términos de la propuesta y el contrato deben ser mutuamente coherentes y
aceptables tanto para el cliente como para el contratista. Durante la negociación, los términos
de la propuesta relacionados con las especificaciones, los cronogramas y el precio se
convierten en acuerdos contractuales legales. El rendimiento, el cronograma y el costo están
interrelacionados, y se debe llegar a un acuerdo de "paquete" en el que los tres parámetros
sean aceptables para ambas partes. La negociación final es la última oportunidad formal para
corregir las percepciones erróneas que podrían haberse deslizado durante el proceso de RFP/propuesta.
(Los clientes siempre están negociando, de manera informal, para obtener un mejor trato,
incluso después de que el proyecto está en marcha. El contratista siempre debe tener cuidado
de decir y escribir cualquier cosa que pueda interpretarse como una promesa de entregar
más de lo especificado en el contrato). En situaciones altamente competitivas, el cliente
intentará enfrentar a los contratistas entre sí, buscando elevar las especificaciones de desempeño.
mientras acorta el horario y disminuye el precio.

A lo largo de la negociación, el director del proyecto insiste en los méritos de su propuesta.
Su objetivo es obtener el mejor acuerdo posible para su empresa. Al contrarrestar las objeciones de
los clientes a la propuesta, la mejor defensa del gerente de proyecto es un plan de proyecto bien
pensado que muestre lo que se puede o se debe hacer para lograr los resultados deseados. Los
detalles del plan se utilizan para definir qué partes del horario, trabajo o precio son relativamente "fijas"
y cuáles son flexibles y se pueden negociar.
Para poder negociar desde una posición competitiva y de conocimiento, el director del proyecto
debe aprender tanto como sea posible sobre el cliente y la competencia. Debe determinar si el cliente
está bajo presión para tomar una decisión en particular, enfrenta una fecha límite fiscal inminente o si
históricamente ha mostrado preferencia por un enfoque o contratista en particular sobre otros. El
director del proyecto también debe conocer a la competencia: su enfoque probable del problema, los
costos y las ventajas y desventajas competitivas. Ella aprende esto de información histórica, material
publicado o empleados que alguna vez trabajaron para la competencia. (Confiar en la última fuente es
éticamente cuestionable y, por supuesto, va en contra del contratista cada vez que los competidores
contratan a sus empleados).
Para poder negociar compensaciones, el director del proyecto debe estar íntimamente familiarizado
con los detalles técnicos del diseño del sistema y los costos relacionados. A veces, el contrato incluirá
cláusulas de incentivo o penalización como incentivos para completar el proyecto antes de una fecha
determinada o por debajo de un costo determinado. Para negociar de manera competente tales
cláusulas, el gerente del proyecto debe estar familiarizado con el cronograma del proyecto y las
compensaciones de tiempo y costo.
El contrato firmado se convierte en el acuerdo vinculante para el proyecto. Cualquier cambio

posterior debe seguir los procedimientos de cambio formales, incluidos los avisos de cambio, las
revisiones, las aprobaciones de los clientes y, a veces, la renegociación del contrato, temas que se
analizan en el Capítulo 11.
Ver Capítulo 11
Declaración de contrato de trabajo y solicitudes de trabajo
El contrato contiene un SOW que es similar al SOW en la propuesta o el

RFP original, o es una reformulación de cualquiera para reflejar el acuerdo negociado.

Esta llamada declaración de trabajo del contrato (CSOW) define el desempeño esperado del
proyecto en términos del alcance del trabajo, los requisitos, los resultados finales, los
cronogramas, los costos, etc. El CSOW especifica las condiciones bajo las cuales los
entregables o resultados finales serán aceptados por el cliente. Si no se establecen claramente
estas condiciones, se pueden generar disputas posteriores y demoras en la finalización del
proyecto.
Los contratos con proveedores y subcontratistas también incluyen una CSOW, además de
las responsabilidades y obligaciones de cada parte. Los contratos de artículos adquiridos
incluyen especificaciones, cantidades, cronogramas de entrega, costos, cronogramas de pago
y formas de manejar cambios o variaciones.
Cuando el cliente y el contratista acuerdan el CSOW, el proyecto se considera "aprobado" y
listo para funcionar. Sin embargo, antes de que el trabajo pueda comenzar realmente, debe
dividirse entre los departamentos involucrados y los subcontratistas del SDO, y los requisitos
especificados en el CSOW deben traducirse a una terminología que las personas de estos
grupos entiendan. Las traducciones, dirigidas a los grupos que realizarán el trabajo, deben ser
interpretaciones idénticas de los requisitos y alcance del trabajo especificados en la CSOW. El
documento que contiene el SOW para cada grupo de trabajo se denomina solicitud de trabajo
u orden de trabajo. Su propósito es describir a cada parte el trabajo que se espera de ella y
autorizar el comienzo del trabajo. Este tema se analiza con más detalle en el Capítulo 11.
Ver Capítulo 11
La firma del contrato del proyecto marca la finalización de la Fase A y la autorización para
comenzar el proyecto y pasar a la Fase B. Los pasos de la Fase A se resumen en la Figura 3.9.
Figura 3.9 Iniciación del proyecto, preparación de la propuesta y proceso de autorización del proyecto.
El proceso de iniciar proyectos, preparar propuestas y negociar y finalizar contratos

a menudo implica circunvoluciones que posiblemente no puedan cubrirse en un
capítulo. La siguiente historia ilustra.
Ejemplo 3.8: Propuesta para la nave espacial Apolo 18
El programa espacial estadounidense para llevar seres humanos a la luna

involucró miles de contratos otorgados por la NASA en concursos separados. Los
contratos más grandes fueron para los componentes más grandes, a saber, la
nave espacial Apolo, el módulo de aterrizaje lunar y la primera, segunda y tercera etapa del
cohete que impulsaría la nave espacial y el módulo de aterrizaje a la luna. Harrison

Storms era vicepresidente de la División Espacial (NA) de la Aviación de América del
Norte en Los Ángeles cuando la NASA abrió la licitación para la nave espacial Apolo.
Su división ya había estado trabajando febrilmente para resolver problemas técnicos
difíciles para una propuesta para construir la segunda etapa del cohete. Los requisitos
técnicos eran tan exigentes que solo un puñado de contratistas se mantuvo en la
competencia. La mayoría de los gerentes en medio de un esfuerzo tan grande se habrían
considerado ya sobreexigidos, pero Storms no: él quería ir tras el contrato del gran
premio : el contrato de la nave espacial Apolo.
La nave espacial Apolo contendría sistemas de soporte vital, guía y navegación (que en
última instancia comprenderían más de 2 millones de piezas) y llevaría a tres hombres a
la luna y de regreso. El problema era que NA nunca antes había construido una nave
espacial y sería costoso aprender cómo hacerlo. Storms reunió a su mejor gente y preparó
una presentación para el presidente y fundador de la compañía, el viejo Kindleburger
"holandés", argumentando que NA debería preparar una propuesta para Apollo. Dutch se
mostró escéptico, pero prometió un apoyo de $ 1 millón.
Storms sabía que eso no sería suficiente, pero lo tomó de todos modos. Ahora NA
ofertaría tanto por la segunda etapa como por Apollo (Figura 3.10).
La RFP para Apollo permitió a los contratistas competidores 10 semanas para presentar
sus propuestas. Tres competidores ya habían realizado estudios Apollo y tenían una
ventaja de 12 meses; uno ya había asignado a 300 personas para trabajar en el concepto,
gastó $ 3 millones y preparó un informe de 900 páginas. En ofertas grandes como esta,
las empresas se asocian para agregar fuerza a la propuesta, pero todos los grandes
contratistas aeroespaciales ya se habían unido y NA se quedó sola.
Nadie creía que el equipo de propuesta de Storms tuviera una oportunidad, incluido el
presidente de la empresa.
El equipo de Storm trabajó febrilmente, de 7 am a 11 pm. Alimentando su información
había decenas de ingenieros en talleres, oficinas, laboratorios y túneles de viento en toda
la empresa; para supervisarlos, Storms eligió a los mejores líderes de NA que pudo
encontrar: personas inteligentes y prácticas con una sólida experiencia que los demás
admiraban.
Llegaron buenas noticias: la NASA anunció que NA había sido elegido contratista
principal para la segunda etapa. Pero el júbilo se transformó en pesimismo por las
perspectivas de ganar también a Apolo; prácticamente nadie sintió que la NASA
adjudicar dos importantes contratos para el programa lunar a la misma empresa.

Hace tiempo que se superó el millón de dólares asignado, tal vez tres veces, pero
nadie lo sabía. En aquel entonces, las declaraciones de costos tenían un retraso de 30
a 60 días con respecto a la facturación, y Storms apostó a que la NASA recibiría la
propuesta antes de que su jefe viera la factura final. Con menos de 6 semanas para el
final, eligió a John Paup como gerente del programa Apollo, alguien que pensó que era
perfecto para el papel, una "persona ingeniosa y atractiva" que entendía la tecnología.
Durante el mes siguiente, Paup escuchó presentaciones 18 horas al día, durmió en un
catre y comió de máquinas expendedoras. Todas las mañanas reunía a su equipo para
una reunión de pie; cualquiera que no estuviera allí a las 7:45 estaba bloqueado. Sin
café, sin asientos, quería escuchar los problemas y cómo se solucionaría cada uno dentro de las 24 horas.
La propuesta era de tamaño enciclopédico y la NASA quería que se enviaran docenas
de copias a más tardar a las 5:00 p. m. dos días antes de la presentación. Todo el
paquete, que pesaba 100 libras, se entregó en mano justo debajo del alambre. Al día
siguiente, Paup y su equipo, con aspecto de zombis por la falta de sueño, abordaron el
avión de la empresa para la presentación ante la NASA en Virginia. Cada empresa tuvo
60 minutos para presentar su propuesta a un equipo de evaluación de 75 ingenieros de
primer nivel, algunos de ellos leyendas. Sin desanimarse, Paup alcanzó todos los puntos
altos de la presentación y terminó 10 minutos antes.
Figura 3.10 Cohete lunar Apolo/Saturno y componentes norteamericanos.
Imagen cortesía de la NASA.
Días después, Storms recibió un telegrama: la NASA quería saber cómo, dado el
contrato de segunda etapa de NA, ¿podría manejar también a Apolo? La respuesta
escrita era demasiado larga para telegrafiarla, por lo que Storms y Paup se subieron
a un avión para entregarla personalmente. Esto violó una regla no escrita de que un
contratista no se reúne con el cliente para evaluar la propuesta. Pero Storms tenía
poco respeto por tales reglas, especialmente con tanto en juego.
Mientras tanto, la sede de NA había determinado que la propuesta costaba cinco
veces el millón de dólares asignado y estaba furiosa. Pero decir que el exceso valió
la pena sería quedarse corto. North American ganó el contrato, aunque se
necesitaría un año más para formalizar los detalles: a cambio de una
costo objetivo de $ 884 millones y una tarifa de $ 50 millones, NA debía entregar varias
maquetas, versiones de prueba y naves espaciales Apolo listas para volar (Figura
3.11). Los riesgos de enviar humanos a la luna eran abrumadores, por lo que el contrato
era de costo adicional. Cuando el programa lunar terminó 10 años después con el
regreso de la séptima tripulación de la luna, NA, como contratista principal, había
ganado $ 4.4 mil millones, más de $ 27 mil millones en dólares de 2015.
Figura 3.11 Nave espacial Apolo.
Foto cortesía de la NASA.

3.7 Resumen
El ciclo de desarrollo de sistemas se puede dividir en cuatro fases: concepción,
definición, ejecución y operación. Las primeras tres fases constituyen el ciclo de vida
del proyecto.
La fase uno, concepción, incluye la formulación del problema, la definición de
necesidades y requisitos del usuario, la evaluación de soluciones alternativas y la
preparación de una propuesta para llevar a cabo el proyecto. Al comienzo de esta
fase, la mayoría de las actividades están en manos del cliente; al final de la fase, el
contratista o desarrollador del sistema se ha hecho cargo de las actividades. La
relación entre el cliente y el contratista se inicia y cimenta a través del proceso de
RFP/propuesta y la negociación del contrato.
La fase A es la parte "fundamental" del ciclo de desarrollo de sistemas; establece
las necesidades, objetivos, requisitos, restricciones, acuerdos y patrones de
comunicación sobre los que se construyen las fases restantes. Es una fase crucial y
el lugar donde, a menudo, se plantan las semillas del éxito o fracaso del proyecto.
Apéndice: Tipos de Contratos

Un contrato es un acuerdo entre dos partes en el que una de las partes (el vendedor, el contratista del
proyecto) se compromete a realizar un servicio para otra (el comprador, el cliente o el consumidor),
generalmente a cambio de un pago.
Los requisitos sobre el servicio y el pago se explican claramente en el
contrato, que típicamente incluye lo siguiente:
• Alcance del trabajo a realizar o elementos a vender, incluidos elementos de apoyo y auxiliares
(paralelos), como manuales, documentación y capacitación. Todas las especificaciones y normas
a las que se hace referencia se consideran parte del
contrato.
• Deberes del contratista en la prestación de la obra o elementos. • Horario

permitido. • Obligaciones del cliente con respecto a los pagos (incluido un
cronograma de
hitos). • Cómo
se manejarán los cambios al contrato y las disputas. • Cómo se manejarán los
riesgos, incluidas las garantías, sanciones o
bonificaciones/incentivos.
Los diferentes tipos de contratos brindan diferentes ventajas para el cliente y el contratista, según el riesgo
del proyecto y la dificultad para estimar los costos. Cada parte trata de negociar el tipo de contrato y los
términos que mejor sirven a sus propios intereses.
Los dos tipos fundamentales de contratos son el precio fijo y el costo adicional. En el contrato de precio
fijo, el precio se acuerda y permanece fijo mientras no haya cambios en el alcance del proyecto o las
disposiciones del acuerdo. En el contrato de costo más (o reembolso de costo) , el contratista es
reembolsado por todos o algunos de los gastos incurridos durante el proyecto, y como resultado, el precio
final se desconoce hasta que se completa el proyecto. Dentro de estos dos tipos hay varias variaciones,
incluidas algunas con incentivos para que el contratista cumpla con los costos, el tiempo o
19
objetivos de rendimiento.
La mayoría de los proyectos involucran múltiples contratistas y, por lo tanto, múltiples contratos y un
combinación de tipos de contrato, por ejemplo, costo adicional para ingeniería y diseño, y precio fijo
para construcción. Esta suele ser una buena manera de contratar trabajo para proyectos, especialmente
para proyectos grandes.
Variables
Las variables especificadas en un contrato pueden incluir las siguientes:
cex Costo objetivo (esperado) y costo real del proyecto en circunstancias normales.
y “Costo” representa el dinero gastado por el contratista en la realización del trabajo.
caca
Tarifa Monto pagado al contratista además de los costos reembolsables.

El precio que el cliente paga por el proyecto. El precio incluye los costos reembolsables (o
Precio un porcentaje de los mismos) incurridos por el contratista, más los honorarios del contratista.
Contratos de precio fijo
Contrato de precio fijo
Bajo un precio fijo (FP) o un acuerdo de “suma global”, el contratista se compromete a realizar todo el
trabajo a un precio fijo. El contratista debe tener cuidado al estimar el costo objetivo porque, una vez
acordado, el precio no se ajustará. Si el contratista en la etapa de licitación estima que el costo objetivo
es demasiado bajo, podría ganar el trabajo pero no obtener ganancias; si sobreestima, puede perder
el trabajo ante un postor con un precio más bajo.
Ejemplo A1: Contrato de precio fijo
Acuerdo de contrato:
Costo estimado, Cex = $100,000

Tarifa = $ 10,000
Precio = $110,000
No importa lo que el proyecto realmente termine costando (Cac), el precio para el cliente sigue
siendo de $110,000.
Cuando el trabajo del proyecto es sencillo y se puede especificar en detalle, todo el mundo prefiere
este tipo de contrato. A los clientes les gusta porque están menos preocupados por los costos del
proyecto. A los contratistas les gusta porque los clientes tienden a solicitar menos cambios en el contrato.
La desventaja de un contrato de FP es que puede ser más difícil y costoso de preparar. El contratista
corre el riesgo de subestimar el costo y perder dinero en el proyecto, lo que podría motivarlo a aumentar
el precio de la oferta o tomar atajos (usar materiales de calidad más económica, realizar mano de obra
marginal o extender la fecha de finalización) durante el proyecto para reducir los costos. Para
contrarrestar esto, el cliente puede especificar en el contrato especificaciones rígidas del artículo final y
fechas de finalización, y supervisar de cerca el trabajo. Sin embargo, si el proyecto se mete en serios
problemas, lleva al contratista a la bancarrota y deja el proyecto incompleto, el cliente puede estar sujeto
a litigios por parte de otras partes interesadas.
Los contratos de precio fijo no funcionan bien en proyectos de alto riesgo. Los patrocinadores de
proyectos a menudo imponen un contrato de PF, pensando que transfiere el riesgo de sobrecostos al
contratista. A veces sí, pero cuando un proyecto grande tiene problemas y el contratista no puede
absorber las pérdidas, el patrocinador tendrá que seguir pagando para mantener el proyecto.
Los contratos de FP pueden ser miopes. El éxito de un proyecto a menudo depende del rendimiento
del artículo final mucho después de que se complete el proyecto, sin embargo, el "precio fijo" puede
obligar a los contratistas a desechar cosas (tomar atajos) que disminuyen ese rendimiento.
Precio Fijo con Redeterminación 20
Los proyectos con plazos de entrega prolongados, como la construcción o la producción, tienen
disposiciones de escalada de contrato que protegen al contratista contra aumentos en los materiales,
las tarifas de mano de obra o los costos generales. Por ejemplo, el precio del contrato puede estar vinculado a un
índice de inflación y ser ajustado en el advenimiento de la inflación, o puede ser redeterminado a medida que se
conocen los costos reales. En el último caso, el precio inicial se negocia con la estipulación de que se volverá a
determinar más tarde para reflejar con precisión los datos de costos reales. Hay una variedad de contratos de
redeterminación: algunos establecen un precio máximo para el contrato y permiten solo ajustes a la baja, otros
permiten ajustes al alza ya la baja; algunos establecen un reajuste al final del proyecto, otros permiten múltiples
reajustes periódicos. Los contratos de redeterminación son apropiados cuando los esfuerzos de diseño son difíciles
de especificar o el precio final no puede estimarse por falta de datos de costos precisos. El precio redeterminado
puede aplicarse a artículos futuros y artículos ya producidos.
Debido a que el único requisito para renegociar el precio es corroborar los datos de costos, los contratos
redeterminados tienden a inducir ineficiencias. Después de negociar un precio inicial bajo, el contratista puede
producir algunos artículos y luego “descubrir” que los costos son mucho más altos de lo esperado. El contrato se
convierte así en un tipo de contrato de “costo más margen” y está sujeto a abusos.
Cualquier contrato en el que se reembolsan todos los costos se denomina "costo reembolsable".
contrato; estos incluyen los contratos de incentivos y de costo incrementado que se analizan a continuación.
Contratos Cost-Plus
En proyectos complejos, inciertos o riesgosos donde es difícil estimar con precisión los costos del proyecto, los
contratos de tipo costo incrementado permiten que el trabajo comience antes de que los costos estén completamente
determinados.
Costo más tarifa fija (CPFF)
Bajo un contrato CPFF, al contratista se le reembolsan todos los costos directos permitidos más una cantidad fija
adicional para cubrir los gastos generales y las ganancias. Este contrato se justifica cuando los costos no pueden
estimarse con precisión o aumentan debido a cambios en el alcance del proyecto o factores fuera del control de
cualquiera. Independientemente del costo real, la tarifa del contratista sigue siendo la misma, generalmente calculada
como un porcentaje del costo objetivo o estimado, Cex.

Ejemplo A2: Contrato de Costo Más Tarifa Fija

Tarifa = $ 10,000
Precio objetivo = $110,000
Además de la tarifa, el cliente pagará todos los costos permitidos (quizás "todos" los
costos, Cac). Así, si el proyecto termina costando Cac = $200 000, el precio para el
cliente es de $210 000.
A diferencia de los contratos FP, los acuerdos CPFF imponen la carga del riesgo al
cliente. El cliente no conoce el precio del proyecto hasta el final del proyecto, y el
contratista tiene pocos incentivos para controlar los costos o hacer algo más allá de los
requisitos mínimos, ya que se le paga la misma tarifa independientemente. Un factor
importante que motiva al contratista a controlar los costos y los cronogramas es el efecto
negativo de los sobrecostos en su reputación. Otra es que mientras la mano de obra y las
instalaciones del contratista estén ocupadas, no puede trabajar en otros proyectos.
La “ganancia” del contratista es aparentemente la tarifa por encima del costo, aunque,
en realidad, eso podría ser solo la punta del iceberg, ya que el contratista puede
beneficiarse de casi cualquier cosa: materiales, servicios, viajes, etc. Un contratista podría
especificar un “tarifa” de $10 millones pero luego gana otros $100 millones de las tarifas
agregadas a los materiales y servicios. El cliente conocerá estos costos adicionales solo
a través de la auditoría del proyecto. Los contratistas a veces argumentan que los costos
en un acuerdo CPFF son propietarios, sin embargo, eso no tiene sentido y el cliente
necesita un buen auditor para verificar cada costo durante el proyecto y antes de que se
le pague al contratista. El cliente también puede especificar quién será el director del
proyecto o asignar su propio director de proyecto para trabajar junto con el proyecto del contratista.
gerente.
A pesar de los riesgos, el cliente podría tener que recurrir a un contrato CPFF solo para
atraer contratistas. CPFF es el contrato de elección cuando el proyecto implica un alto
riesgo o los costos son difíciles de estimar.
Precio Máximo Garantizado
Con un CPFF, el precio final se desconoce hasta que se completa el proyecto y se contabilizan
los costos, por lo que un acuerdo más atractivo para los clientes es el contrato de precio
máximo garantizado (GMP), que es un contrato CPFF con un precio tope. El monto de GMP
se negocia y el cliente acepta pagar los costos reales del proyecto hasta el GMP; por costos
más allá de eso, el contratista es responsable. El GMP incluye la tarifa del contratista, que
puede ser fija o un porcentaje de los costos.
Suponga que la tarifa se fija en $10 000 y el GMP en $110 000. Si Cac termina en $80 000,
el cliente le paga al contratista $80 000 + $10 000 = $90 000. Si Cac es de $200 000, el cliente
paga el GMP, $110 000, y el contratista incurre en una pérdida de $90 000.
Contrato de tiempo y materiales
Un contrato de tiempo y materiales (TM) es un acuerdo simple que reembolsa al contratista

los costos de mano de obra y materiales incurridos en el proyecto. Establece el pago de las
horas de mano de obra directa a una tarifa por hora que incluye los costos de mano de obra
directa, los costos indirectos y las ganancias. En ocasiones se establece un precio tope que
puede ser superado, según convenio. Los cargos por consultores privados y los servicios de
electricistas, carpinteros, mecánicos, etc., generalmente se basan en TM.
Contratos de incentivos
Cuando un contratista no está dispuesto a celebrar un acuerdo de FP y el cliente no quiere un

contrato de CPFF, una alternativa es un acuerdo de incentivos . Esto tiene características de
ambos tipos de contratos: es similar a CPFF en que los costos se reembolsan, pero el monto
reembolsado se basa en ahorros compartidos, es decir, cualquier ahorro de Cac que sea
menor que Cex se divide entre las partes.
La división de participación está determinada por la relación de costos compartidos (CSR).
Un CSR de 80/20, por ejemplo, significa que el cliente y el contratista dividen los costos 80/20.
Esto alienta al contratista a mantener los costos bajos porque paga 20 centavos por cada
dólar gastado por encima de Cex pero gana 20 centavos más por cada dólar ahorrado por debajo
Cex. Como incentivo adicional para reducir los costos, la proporción podría modificarse para costos
superiores a Cex , de modo que el contratista deba pagar un porcentaje más alto. El contrato atrae
a ambas partes ya que el contratista puede obtener mayores ganancias y el cliente pagar un precio
más bajo.
Contrato de tarifa de incentivo de costo más (CPIF)
En un contrato CPIF, el precio del proyecto se basa parcialmente en un porcentaje del costo real,
Cac, y el CSR. El contrato especifica los costos objetivo, Cex y el CSR, que especifica cómo se
dividirán los ahorros o sobrecostos entre el cliente y el contratista.
Ejemplo A3: Contrato de tarifa de incentivo de costo más
Costo estimado = Costo objetivo = Cex = $100,000

Tarifa = $ 10,000

Costo compartido: CSR = 50/50
CSR de m/ n (m + n = 100) significa que por cualquier diferencia entre el costo objetivo y el
real, el cliente obtiene m por ciento de cualquier ahorro y paga m por ciento de cualquier
exceso. El precio se calcula como
Bajo costo objetivo: Precio = Cac + (Cex ÿ Cac) x n+ Tarifa

Sobre el costo objetivo: Precio = Cex + (Cex ÿ Cac) x m+ Tarifa
El incentivo es que el contratista mantenga los costos por debajo de $100,000. Suponga que
Cac es $80,000 ($20,000 bajo Cex).
Precio = $80 000 + ($20 000)(0,50) + 10 000 = $100 000
El cliente ahorra $10 000 en el precio y el contratista gana un bono de $10 000.
El cliente debe estar atento para asegurarse de que el incentivo no lleve al contratista a
“tomar atajos” en el trabajo y los materiales.
Ahora suponga que Cac es $200,000 ($100,000 sobre Cex).
Precio = $100 000 + ($100 000)(0,50) + $10 000 = $160 000 El

contratista tiene $200 000 ÿ $160 000 = $40 000 en números rojos.
Una variación de CPIF tiene un precio máximo garantizado: GMP. Para continuar con la ilustración
anterior, suponga que el GMP es de $130 000. Si Cac es $200 000, el cliente paga sólo $130 000, el
GMP. Con el GMP, el contratista tiene $200,000 – $130,000 = $70,000 en números rojos.
Por lo general, se utilizan dos CSR, uno diferente para cada uno por debajo del objetivo y uno por encima del
objetivo. Véase la pregunta de repaso 27 al final del capítulo.
Contrato de tarifa de incentivo de precio fijo
Un contrato de tarifa de incentivo de precio fijo (FPIF) es similar a un contrato CPIF pero tiene un límite tanto
en el precio (GMP) como en la ganancia. El contratista negocia realizar el trabajo por un precio objetivo
basado en un costo objetivo (Cex) más una tarifa, y por un GMP y una ganancia máxima. Si el costo del
proyecto termina siendo menor que el costo objetivo, el contratista puede obtener una mayor ganancia, pero
solo hasta el máximo. Si hay un sobrecosto, el contratista tendrá que absorber parte o gran parte de él.
Ejemplo A4 Contrato de tarifa de incentivo de precio fijo

Tarifa = $ 10,000

GMP = $125 000 (tarifa + reembolso), el cliente no pagará más de este Beneficio máximo = $15 000, el beneficio del contratista
no puede exceder este
Costo compartido: CSR = 50/50, por lo tanto:
• Si Cac < $100,000, el cliente reembolsará Cac más 50 adicionales

por ciento del monto por debajo de $100,000, siempre que el monto adicional no
exceda los $5,000.
• Si Cac > $100,000, el cliente reembolsará $100,000 más un 50 por ciento adicional del
monto superior a $100,000, pero el precio no puede exceder los $125,000.
Una vez más, el incentivo es que el contratista mantenga los costos bajos y no supere los
$100,000. Sin embargo, debido a que el contratista no puede obtener una ganancia de más
de $15,000, hay pocos incentivos para que el contratista tome atajos para aumentar la
ganancia. Suponga que Cac es $80,000 ($20,000 bajo Cex). El contratista recibe un pago de
$80 000 más la tarifa de $10 000, más $5000 adicionales por el ahorro de costos (50 por
ciento de los $20 000 ahorrados son $10 000, de los cuales solo se permiten $5000 porque la
ganancia máxima permitida es de $15 000). Precio total al cliente: $95,000, un ahorro de
$15,000 del precio objetivo.
Supongamos que Cac es de $200 000 ($100 000 sobre Cex). El cincuenta por ciento del
sobrecosto es de $50,000; eso más la tarifa más $100,000 es $160,000. Pero el GMP
especificado es de $125 000, que es todo lo que paga el cliente. El contratista sufre una
pérdida de $200,000 – $125,000 = $75,000.
Los contratos FPIF no son verdaderos contratos de precio fijo. Invitan a un contratista a negociar un
Cex alto poco realista para que se puedan obtener ganancias adicionales a través de las funciones
de incentivo. Pero a diferencia de los contratos de costo adicional, brindan cierta seguridad sobre un
precio máximo y cierta protección contra el contratista que toma atajos para obtener una gran
ganancia. Los contratos FPIF se aplican a proyectos de larga duración o de gran producción. No se
aplican a I+D ni a otros proyectos en los que el coste objetivo sea difícil o imposible de estimar.
21
Otros Contratos de Incentivos
Los incentivos se pueden aplicar a los horarios y el rendimiento, así como al costo o al precio.
Al igual que los contratos CPIF y FPIF, estos acuerdos especifican las fechas de finalización del
proyecto objetivo o los parámetros de rendimiento objetivo para el artículo final. El precio final del
proyecto “premia” al contratista por exceder el objetivo o
“penaliza” al contratista por perder el objetivo.

Los acuerdos de incentivos a veces tienen efectos negativos, como incentivos de costos
lo que lleva a un retraso en el cronograma. Para compensar esto existen los llamados incentivos múltiples .
contratos que recompensan a los contratistas por lograr objetivos asociados con múltiples
criterios como el cronograma, el costo y el desempeño. Pesos de tarifa asignados a la
se utilizan criterios para determinar la cantidad de "cambio de tarifa" asignada a cada
criterio. Considere el ejemplo que se muestra a continuación, donde la estructura de tarifas es similar a
el ejemplo de CPIF. Aquí la "variación de la tarifa" (Fmin a Fmax) está entre el 2 por ciento y el 14 por ciento.
22
por ciento, o 12 por ciento.
Cex = $100,000
Fex = $8 (8%)
Fmáx = $14 (14%)
Fmin = $2 (2%)
La oscilación de la tarifa del 12 por ciento se divide luego entre los criterios; por ejemplo:
Criterio Peso Cambio de tarifa
Rendimiento (x) 0.5 6%
Costo (año) 0.25 3%
Horario (z) 0.25 3%
Total 1.00 12%
En los contratos de ingeniería, por lo general se le da el mayor peso al desempeño,

seguido del cronograma y el costo. Para evaluar el desempeño, varias medidas pueden ser
utilizados a la vez, como precisión, alcance, confiabilidad y velocidad; se diseña un índice así
todas las medidas se pueden representar mediante un único factor de rendimiento.
En este ejemplo, al rendimiento se le asigna un peso de 0,5, lo que genera una ganancia
oscilación del 6 por ciento; el cronograma y el costo tienen pesos de 0.25, por lo que cada uno tiene
una oscilación de beneficios del 3 por ciento. El porcentaje de beneficio se calcula en función de la
tres criterios según la fórmula
P = (8 + x + y + z)% (Cex).
Los valores de x, y y z, determinados al final del proyecto, se basarían en la

curvas en la Figura 3.12.
Figura 3.12 Contrato de incentivos múltiples.
Dado que los múltiples criterios en este tipo de contrato tienden a estar interrelacionados (por
ejemplo, se pueden cumplir los objetivos de desempeño, pero con mayor tiempo y costo), la
terminología y los cálculos involucrados en la estructuración del contrato tienden a ser complicados;
por lo tanto, este tipo de contrato rara vez se utiliza.
1. ¿Cómo se inician los proyectos? Describa el proceso.

2. ¿Qué factores determinan si una idea debe investigarse o no?
3. ¿Quién es el usuario en el proceso de desarrollo de sistemas? Quien es el
¿contratista?
4. Además del usuario y el contratista, ¿qué otras partes están involucradas en

el ciclo de desarrollo de sistemas? Dar ejemplos de proyectos particulares.
5. ¿Qué implica el término “aceleración”?
6. ¿Cómo se involucra el contratista (SDO) en un proyecto?
7. ¿Cuál es el papel de una RFP? Describir el contenido de una RFP.
8. ¿Qué es un estudio de factibilidad? Describa su contenido y propósito.

9. ¿Cuáles son las necesidades de los usuarios? Describir el proceso de definición de las necesidades del usuario y
los problemas encontrados.

10. ¿Cuáles son los requisitos del usuario? ¿En qué se diferencian de las necesidades del usuario?
11. ¿Quién prepara la propuesta? Describa el proceso de preparación de la propuesta.

12. ¿Qué es la declaración de trabajo (SOW)? ¿En qué documentos
SOW aparecer?
13. Describa el contenido de la propuesta.
14. ¿Cómo se selecciona la mejor propuesta? Describir el proceso y los criterios.
usó.
15. Tres propuestas (W, X e Y) han sido calificadas en seis criterios de la siguiente manera:
1 = malo, 2 = regular, 3 = bueno. Elige entre las tres propuestas
utilizando (a) el método de calificación simple y (b) el método de calificación ponderada.
Criterios Peso WXY

Atención a la calidad 0.25 2 13
Costo 0.20 3 31
Plan de proyecto 0.20 2 21
Organización del proyecto 0.15 3 23

Probabilidad de éxito 0.10 2 33
credenciales del contratista 0.10 2 23
16. ¿Qué calificaciones de contratista podría buscar el cliente en una propuesta? ¿Qué más
sobre el contratista podría buscar el cliente?
17. ¿Qué partes se consideran subcontratistas en un proyecto?
18. Discuta el propósito de un estudio de caso de negocios para proyectos internos. Qué
¿Incluye el estudio y quién lo prepara?
19. ¿Cómo se adapta el proceso de RFP/propuesta a grandes proyectos que potencialmente
tienen numerosos interesados pero inicialmente solo se han identificado unos pocos?
20. Al subcontratar el trabajo, ¿el cliente renuncia a todo control sobre

el proyecto al contratista? Explique.
21. ¿Cómo puede un contratista ser tanto el remitente como el receptor de las RFP? es decir,
¿cómo puede preparar y presentar propuestas, y recibir y revisar propuestas?
22. Cuando un contratista contrate a un subcontratista, ¿a quién corresponde el subcontratista?

obligado: ¿el cliente usuario final o el contratista?
23. ¿Qué debe saber el director del proyecto para poder negociar un contrato de manera
efectiva? Considere aspectos del cliente, la competencia y el contenido técnico de la
propuesta.
24. Discutir la diferencia entre SOW, CSOW y solicitud de trabajo o
orden de trabajo.
25. Describa los diferentes tipos de contratos (consulte el capítulo Apéndice).

¿Cuáles son las ventajas y desventajas relativas de cada uno para el cliente y el contratista?
26. Un cliente acusa a un director de proyecto de sobrecostos y retraso en la entrega. ¿Por qué
es relevante si la relación entre el cliente y el director del proyecto se rige por un contrato
EPC o EPCM?
27. Consulte los problemas de ejemplo CPIF y FPIF en los Ejemplos A.3 y A.4
en el capítulo Apéndice.
una. Tanto en el caso de CPIF como en el de FPIF, ¿cuál es el precio si Cac = $90 000?
¿Cuál es la ganancia del contratista?
b. En ambos casos cuál es el precio si Cac = $160,000. Cuál es el
¿lucro?
C. Por lo general, se utilizan dos CSR, uno diferente cada uno para las
insuficiencias y los excesos. ¿Cuáles son las respuestas a (a) y (b)
si el CSR es 70/30 para insuficiencias y 80/20 para excesos?
Según corresponda, responda las preguntas 1 a 14 con respecto a su proyecto. También

responda las siguientes preguntas: ¿Cómo se negocian los contratos y quién está involucrado
en la negociación? ¿Qué tipo de contratos se utilizan en el proyecto?
Caso 3.1 Centro Médico de la Universidad de la Costa Oeste
El Centro Médico de la Universidad de la Costa Oeste (WCMC, por sus siglas en inglés)
es un gran hospital de enseñanza e investigación con una reputación nacional por su
excelencia en la práctica, la educación y la investigación de la atención de la salud.
Buscando mantener esa reputación, la junta ejecutiva senior decidió instalar un sistema
integral de diagnóstico médico. El sistema estaría vinculado a los servidores de WCMC y
estaría disponible para los médicos desde sus hogares y oficinas a través de Internet. Al
hacer clic en los íconos para acceder a un área de especialidad médica y luego ingresar
las respuestas a las consultas sobre los síntomas y el historial médico de un paciente, un
médico podría recibir una lista de diagnósticos con estadísticas asociadas.
La junta directiva envió un cuestionario a cada departamento preguntando a los
gerentes sobre las necesidades de sus áreas y cómo creían que el sistema podría mejorar
el desempeño de los médicos. La mayoría de los gerentes respondieron que el sistema
ahorraría tiempo a los médicos y mejoraría el desempeño. El grupo de tecnología de la
información (TI) del hospital fue asignado para evaluar el costo y la factibilidad de
implementar el sistema. Entrevistaron a gerentes de WCMC y varios proveedores de
software de diagnóstico. El estudio mostró un gran entusiasmo entre los gerentes y una
larga lista de beneficios potenciales. Con base en el estudio de factibilidad, la junta aprobó
el sistema.
El gerente de TI invitó a tres firmas consultoras muy conocidas que se especializaban
en sistemas de diagnóstico médico para dar presentaciones y luego contrató a una para
que ayudara a su grupo a seleccionar e integrar varios paquetes de software en un solo
sistema de diagnóstico completo.
Un año y millones de dólares más tarde, el proyecto se completó, pero 6

meses después quedó claro que el sistema era un fracaso. Aunque hizo todo
lo que prometieron los consultores y proveedores de software, pocos médicos
lo usaron; de los que lo hicieron, muchos se quejaron de que los “beneficios”
eran irrelevantes y que faltaban características del sistema que les hubiera
gustado.
Preguntas
1. ¿Por qué fracasó el sistema?

2. ¿Cuál fue la causa probable de su falta de uso?
3. ¿Qué pasos o procedimientos se manejaron mal en la fase de concepción
del proyecto?
Caso 3.2 X-Philes Data Management Corporation:

Asuntos de RFP
X-philes Data Management (XDM) Corporation (lema: "La verdad está ahí fuera")
se está preparando para subcontratar trabajo para dos grandes proyectos: Scully y
Mulder. Los proyectos son comparables en términos de tamaño, requisitos técnicos
y tiempo de finalización estimado, pero son independientes y serán realizados por
equipos de proyecto separados.
Dos gerentes en XDM, cada uno asignado a Scully y Mulder, preparan RFP para
los proyectos y los envían a varios contratistas. La RFP para Scully incluye lo
siguiente: una SOW que especifica los requisitos de rendimiento y calidad del
sistema, el precio máximo, el plazo de finalización y las condiciones del contrato;
una cláusula de incentivos que establezca que el contratista recibirá una bonificación
por exceder los requisitos mínimos de calidad y terminar el proyecto antes de
tiempo, o será penalizado por la mala calidad y la terminación tardía; y un requisito
de que el contratista presente informes de estado mensuales detallados que
muestren el progreso en las medidas clave de calidad. La RFP para Mulder incluye
una SOW breve, un presupuesto máximo y la fecha de finalización deseada.
Con base en las propuestas recibidas en respuesta a las RFP, los gerentes
responsable de que Scully y Mulder seleccionen cada uno un contratista. Ninguno de los
gerentes sabe que seleccionaron al mismo contratista, Yrisket Systems. El gerente de Scully
elige a Yrisket porque su precio de oferta está algo por debajo del límite presupuestario y su
reputación en el negocio es buena. El gerente de Mulder elige a Yrisket por razones similares:
buen precio y reputación. Al preparar la propuesta de Scully, los gerentes de Yrisket tuvieron
que trabajar duro para cumplir con el precio máximo especificado en la RFP, pero sintieron que
haciendo un trabajo de calidad podrían obtener una buena ganancia del incentivo ofrecido.
Unos meses después de que los proyectos estuvieran en marcha, algunos de los empleados
de Yrisket renunciaron. Para cumplir con sus compromisos con ambos proyectos, los
trabajadores de Yrisket tienen que trabajar muchas horas y los fines de semana. Sin embargo,
es evidente que estos esfuerzos adicionales podrían no ser suficientes, especialmente porque
Yrisket tiene un contrato con otro cliente y debe comenzar a trabajar pronto.
Preguntas
1. ¿Qué crees que pasará?

2. ¿Cómo cree que afectará a Mulder la crisis que enfrenta Yrisket?
y los proyectos de Scully? Los dos proyectos son muy similares, pero ¿usted
espera que Yrisket los trate de la misma manera?
Caso 3.3 Evaluación de la propuesta para Apollo

nave espacial 23
Se presentaron cinco propuestas a la NASA para diseñar y construir el Apolo

astronave. Una junta de evaluación de más de 100 especialistas revisó la
propuestas y las clasificó de la siguiente manera (máximo = 10)
Técnico Negocio
Técnico Ponderado
Acercarse Fuerza
Calificación totales (40%)
(30%) (30%)
Compañía Martín 5.58 6.63 8.09 6.90
General
Dinámica 5.27 5.35 8.52 6.59
Astronáutica
norteamericano
5.09 6.66 7.59 6.56
Aviación
Energia General
5.16 5.60 7.99 6.42
Compañía
McDonnell
Aeronave 5.53 5.67 7.62 6.41
Corporación
La junta recomendó inequívocamente a la alta dirección de la NASA que se

adjudicara el contrato a Martin, pero sugirió a North American como la siguiente
mejor alternativa en función de la experiencia de NA en el desarrollo de
aeronaves militares y de investigación de alto rendimiento. Esta experiencia
(calificación técnica) impresionó lo suficiente a la junta que puso a NA por
delante de General Dynamics, a pesar de las calificaciones más bajas de NA en
enfoque técnico (diseño de la cápsula espacial) y solidez empresarial (organización y gestión).
La junta mencionó que cualquier deficiencia en el enfoque técnico de NA podría
corregirse mediante un esfuerzo de diseño adicional. Al ver las recomendaciones
de la junta, y consciente de la larga y estrecha asociación de NA con NACA (la
agencia predecesora de la NASA), la alta gerencia de la NASA seleccionó de
inmediato a North American.
Preguntas
1. ¿Cómo se determinaron los puntos en la columna "Total ponderado"?

Muestre los cálculos.
2. North American ocupó el tercer lugar entre cinco contratistas en la columna Total
ponderado, pero se adjudicó el contrato. ¿Cómo pasó eso?
¿Cuáles son las lecciones de este ejemplo?
Caso 3.4 Error de contrato en Polanski Developers
LaPage Power Company necesitaba actualizar el sistema de extinción de incendios para la

sala de control de una planta de energía nuclear. Seleccionó a Polanski Developers Company
porque Polanski era el único contratista dispuesto a hacer el trabajo por un contrato de precio
fijo. El precio de $ 11 millones de Polanski se basó en su costo estimado de $ 9,5 millones
para el trabajo y los materiales, y una tarifa de $ 1,5 millones.
Los gerentes de Polanski sintieron que la tarifa era lo suficientemente alta como para
proporcionar una amplia ganancia y absorber cualquier dificultad laboral imprevista. La
actualización requeriría una interfaz con muchos sistemas de seguridad de la planta, algunos
que datan de cuando la planta abrió en 1985 y otros que se han actualizado muchas veces desde entonces.
Las interfaces con otros sistemas harían que la actualización fuera compleja y desafiante.
Polanski se anticipó a esto, y para reducir el riesgo de un sobrecosto contrató a Moreland
Systems, una empresa con gran experiencia en plantas de energía nuclear. Moreland sería
responsable de prácticamente todo el diseño e instalación del sistema real. Dijo Billy Chester,
gerente de proyectos de Moreland, "Nunca se sabe lo que encontrará en este tipo de
proyectos". Le dijo a Polanski que Moreland aceptaría el trabajo, pero
únicamente sobre la base de costo más margen. El contrato de CPFF especificó un precio objetivo
de $ 10 millones utilizando el costo estimado de $ 9,5 millones de Polanski y una tarifa de $ 500,000.
Polanski estuvo de acuerdo.
Cuando se completó el proyecto, después de haber encontrado varios problemas imprevistos, la

factura de Moreland fue de $ 14,5 millones. El contrato de CPFF había especificado auditorías
periódicas de los costos de Moreland, pero nunca se realizó ninguna.
Discuta las consecuencias financieras para Polanski, Moreland y LaPage.

¿Qué debería haber hecho Polanski que pudiera haber alterado las consecuencias?
¿Cómo depende la elección del tipo de contrato de los riesgos involucrados?
Notas finales
1. Podría argumentarse que la Fase D en un proyecto de campaña electoral se extenderá si el candidato es
electo, con lo cual la fase de “operación” representa el período político completo del funcionario electo, pero
sería estirar la analogía.
2. Basado en información recopilada y documentada por Cary Morgen a partir de entrevistas con gerentes de
Industrias Jamal (caso real, nombre ficticio).
3. Cusumano M. y Selby R. Microsoft Secrets. Nueva York, Nueva York: Prensa libre; 1995, pág. 210.
4. Una necesidad es un juicio de valor de que existe un problema. Diferentes partes en una situación idéntica pueden
percibir la situación de manera diferente; en consecuencia, siempre se identifica una necesidad con respecto a un
parte en particular, por ejemplo, el usuario. Véase McKillip J. Need Analysis: Tools for the Human Services and
Educación. Newbury Park, CA: Publicaciones Sage; 1987.
5. Cusumano y Selby, Secretos de Microsoft. pags. 210.
6. En los EE. UU., una solicitud de cotización o invitación a licitar (IFB, por sus siglas en inglés) comúnmente sugiere que la selección de un
contratista se basará principalmente en el precio; en una RFP, la naturaleza de la solución y la competencia del contratista son tan o
más importantes que el precio. En otras partes del mundo, la propuesta de términos y la oferta a menudo
se usan indistintamente, siendo una oferta el equivalente de una propuesta completa.
7. Adaptado de Frame JD Management Projects in Organizations. San Francisco, CA: Jossey-Bass; 1987, págs.
109–110.
8. Ibíd., págs. 111–126.
9. Sundblad D. "Sostenible Construcción Técnicas.”

http://greenliving.lovetoknow.com/Sustainable_Construction_Techniques, Consultado el 12 de noviembre de 2014.
10. Hamilton G., Byatt G. y Hodgkinson J. "Cómo los gerentes de proyecto pueden ayudar a sus empresas a 'volverse ecológicas': los
gerentes de programas y proyectos pueden contribuir a la sostenibilidad". CIO, 2 de noviembre de 2010.
http://www.cio.com.au/article/366509/how_project_managers_can_help_their_companies_go_green_/,
consultado el 14 de noviembre de 2014.
11. Hajek VG Gestión de Proyectos de Ingeniería, 3ra ed. Nueva York, NY: McGraw-Hill; 1984, págs. 39 a 57;
Rosenau MD Gestión exitosa de proyectos. Belmont, CA: aprendizaje de por vida; 1981, págs. 21–32.
12. Roman D. Gestión de proyectos: un enfoque de sistemas. Nueva York, Nueva York: Elsevier; 1986, págs. 67–72; Estuardo R.
y Stewart A. Preparación de propuestas. Nueva York, NY: John Wiley and Sons; 1984.
13. Murphy O. Gestión de proyectos internacionales. Mason, OH: Thompson; 2005, págs. 159–161.
14. Esta sección ofrece una descripción general de las cuestiones importantes de contratación. No tiene la intención de proporcionar
asesoramiento sobre contratos; para eso necesita un abogado o especialista en contratos.
15. La gestión del proceso completo de contratación del proyecto, incluido qué y dónde contratar, solicitar y evaluar propuestas,
llegar a un acuerdo de contrato y administrar el contrato se denomina “supervisión del contrato”. Véase Hirsch W. The Contracts
Management Deskbook, edición revisada. Nuevo
York, NY: Asociación Estadounidense de Administración; 1986, Capítulo 6.
16. Ibíd., págs. 290–315.
17. Ver Hajek, Gestión de Proyectos de Ingeniería. Capítulos 8 y 9; y Rosenau, Proyecto Exitoso
Gestión, págs. 34–41.
18. La fuente principal de este ejemplo es Gray M. Angle of Attack: Harrison Storms and the Race to the Moon.
Nueva York, NY: WW Norton; 1992, págs. 87 a 116; la otra fuente es Brooks C., Grimwood J. y Swenson,
Jr., L. Carros para Apolo: una historia de la nave espacial lunar tripulada. Washington, DC: científico de la NASA
y Oficina de Información Técnica, SP-4205; 1979, secciones 2.5 y 4.2.
19. Se proporciona una descripción completa de los contratos en Hirsch W. The Contracts Management Deskbook, revisado
ed. Nueva York, Nueva York: Amocom; 1986, págs. 43–75. Para contratos de construcción: Furst S. y Ramsey V. (eds)
Keating sobre los contratos de construcción, 8ª ed. Londres: Sweet y Maxwell; 2006.
20. Hajek, Gestión de proyectos de ingeniería, págs. 82–83.
21. Miller R. Programación, costo y control de ganancias con PERT. Nueva York, NY: McGraw-Hill; 1963, págs. 173–184.
22. Ejemplo de ibíd., 174-175.
23. Brooks, Grimwood y Swenson, Chariots for Apollo, capítulos 2–5.

Capítulo 4
Definición de Proyecto y Sistema
Definición
Cuando una puerta se cierra, otra se abre.
—Cervantes, Don Quijote
Si lo construyes, ellos vendrán.
-Campo de sueños
El resultado de la Fase A es un concepto de sistemas formalizado que incluye (1) una

formulación clara del problema y una lista de los requisitos del usuario, (2) una solución de
sistemas rudimentaria pero bien conceptualizada, (3) un plan elemental en la propuesta del
proyecto y (4) un acuerdo entre el cliente y el contratista sobre todos estos. El proyecto
ahora está listo para pasar a las fases "media" y "posterior" del ciclo de desarrollo de
sistemas y hacer realidad el concepto de sistemas.
Gran parte de este y del capítulo anterior se refieren a la conceptualización y definición
del “sistema”, el elemento final del proyecto. Este es también un impulso importante de la
metodología de ingeniería de sistemas, que a menudo se aplica a proyectos que involucran
a más partes interesadas, mayor complejidad técnica, mayor riesgo y tienen consecuencias
de mayor alcance que otros proyectos. Se alienta a los lectores interesados a consultar el
Apéndice A al final del capítulo para obtener información adicional sobre ingeniería de sistemas.
métodos y herramientas.
4.1 Fase B: Definición

Como muestra la Figura 4.1 , con la aprobación del proyecto en la Fase A, el impulso del
esfuerzo ahora pasa a la definición, diseño, producción e implementación de la solución. La
mayor parte del esfuerzo en la Fase A se dedicó a investigar el problema : ¿qué es, es
importante, debe resolverse y puede resolverse de manera aceptable? Ahora en la Fase B,
Definición, se analiza la solución: se analiza y se define lo suficiente como para que los
diseñadores y constructores puedan producir un sistema que satisfaga las necesidades del
cliente.
El principio subyacente detrás de la Fase B, Definición, es, simplemente, prepararse lo
mejor que pueda para lo que pretende hacer antes de comenzar a hacerlo. La definición dice
“Piense en lo que quiere que suceda y cuál es la mejor manera de hacer que suceda; ¡no
salte y comience!” La definición es importante porque sus resultados dictan lo que sucederá
en el futuro. En la fase de definición, antes de que se definan las cosas y se establezcan los
planes, los planificadores todavía tienen una amplia libertad para tomar decisiones y la
capacidad de influir en los resultados del proyecto. Las cosas todavía son fáciles de cambiar
porque las "cosas" son solo planes. Más adelante en el proyecto, después de que se
establecen los planes y el trabajo está en marcha, las cosas son difíciles de cambiar porque
las "cosas" incluyen el trabajo ya realizado o con el que se ha comprometido por completo.
En algún momento el proyecto se atascará de acuerdo con las decisiones ya tomadas,
incluso las malas. Por ejemplo, es fácil decidir en Definición si un edificio tendrá 5, 10 o 15
pisos. Pero una vez que decidas 10 pisos, después de que se hayan construido 8 pisos, no
puedes cambiar la decisión a 5 pisos (sin derribar 3 pisos) o a 15 pisos (si los cimientos se construyeron sol
Figura 4.1 Modelo de cuatro fases del ciclo de desarrollo del sistema.
Esto se ilustra mediante tres curvas en la figura 4.2. Al principio del proyecto es fácil
tomar decisiones que afectarán el resultado del proyecto y el costo de cambiar esas
decisiones es pequeño. Al principio se habrá gastado muy poco (costo acumulativo), por lo
que también es fácil cancelar el proyecto en ese momento. Sin embargo, a medida que
avanza el proyecto, y especialmente después de que entra en Ejecución, el costo acumulado
aumenta drásticamente. Entonces no es tan fácil cancelar el proyecto debido al alto costo
irrecuperable. Tampoco es tan fácil cambiar decisiones (pasar de 10 pisos a 5 o 15 pisos)
porque ya se ha hecho mucho y es costoso rehacerlo, deshacerlo o alterarlo.
La definición es esa fase en la que las ideas y los planes se aclaran completamente antes
de que se hagan los compromisos finales y comience el trabajo. El eje de la fase es doble:
definición del proyecto y definición del sistema.
Definición de Proyecto vs. Definición de Sistema
Hay dos formas de ver un proyecto: una es ver el producto final o el resultado del proyecto,
la otra es ver el esfuerzo dirigido a lograr ese resultado. Es necesario mirar a ambos: si se
enfoca demasiado en el artículo final y muy poco en el
esfuerzo, el proyecto tendrá problemas por falta de preparación y coordinación de recursos, costos
y cronogramas; si se enfoca principalmente en el esfuerzo y menos en el producto final, el proyecto
tendrá problemas, esta vez por no cumplir con los requisitos del usuario. La definición del sistema y
la definición del proyecto son igualmente importantes.
La definición del sistema tiene como objetivo lograr una buena comprensión de lo que debe hacer el
artículo final para satisfacer los requisitos del usuario; la definición del proyecto tiene como objetivo
especificar lo que el equipo del proyecto debe hacer en el proyecto para producir el artículo final. Si
bien no es sorprendente que gran parte de la literatura sobre gestión de proyectos se preocupe por
la definición del proyecto, es sorprendente la poca atención que presta a la definición del sistema.
La definición del sistema comienza con la definición de las necesidades y requisitos del usuario;
la definición del proyecto comienza con el tratamiento de esos requisitos en la propuesta del proyecto.
Por lo tanto, parte del trabajo de definición necesario para el proyecto se inicia en la Fase A. La Fase
B continúa con este trabajo de definición y concluye con un conjunto de especificaciones del sistema
y un plan del proyecto: un conjunto completo de todo lo necesario para ejecutar el proyecto en la
Fase C.
Figura 4.2 Costos del proyecto y capacidad para influir en los resultados frente a la fase del proyecto.
Comienzo del proyecto
El proyecto comienza formalmente con una reunión inicial: la primera reunión formal del equipo del proyecto
y las partes interesadas clave. El propósito de la reunión es anunciar que el proyecto está a punto de
comenzar, comunicar de qué se trata el proyecto, desarrollar expectativas comunes y generar entusiasmo
y compromiso con los objetivos y entregables del proyecto. El director del proyecto planifica y dirige la
reunión.
Los asistentes incluyen el equipo del proyecto (o, si es demasiado grande, solo los gerentes, los líderes del
equipo y el personal del proyecto), los colaboradores y otras personas que deberían saber que el proyecto
está a punto de comenzar. Para un proyecto de múltiples ubicaciones, múltiples inicios en cada ubicación o
podría ser necesaria una videoconferencia o una conferencia telefónica. El inicio dura de 1,5 a
2 horas y es principalmente una presentación formal con preguntas y respuestas al final.
Los asistentes invitados deben ser notificados formalmente con anticipación y se les debe
proporcionar información sobre la agenda de la reunión, una lista de los participantes invitados
y sus funciones en el proyecto, y un plan de proyecto rudimentario. La reunión presenta a los
siguientes: el director del proyecto; el proyecto SOW, metas y entregables; el plan propuesto:
presupuesto, cronograma, principales paquetes de trabajo; limitaciones y riesgos; el cliente,
otras partes interesadas clave y sus necesidades y requisitos; la organización del proyecto y los
miembros clave del equipo; y los próximos pasos inmediatos y quién debe hacer qué. Mucha
de esta información habrá sido elaborada para la propuesta del proyecto; si no, el director del
proyecto y el equipo del proyecto deben prepararlo antes de la reunión.
Todo proyecto debe comenzar con una reunión inicial. Para un proyecto grande, el esfuerzo
de preparación de la propuesta debe estar precedido por una reunión inicial; De manera similar,
cada fase del proyecto debe iniciarse con un puntapié inicial.
El kickoff tiene como objetivo brindar información, no llegar a un consenso de opinión,
desarrollar relaciones de trabajo o establecer pautas para que los miembros del equipo puedan
trabajar juntos. Este último es el objetivo de la formación de equipos, para lo cual se deben
realizar reuniones posteriores poco después del saque inicial. La creación de equipos se analiza
en el Capítulo 16.
Ver Capítulo 16
Nombre del proyecto
El nombre del proyecto es a menudo lo primero que la gente escucha sobre el proyecto, a
una explicación adjunta. prácticamente todamenudo
la comunicación
1 El nombre
y persisten
aparecerátanto
unacomo
y otraelvez
proyecto,
sin
y tal vez más. Un nombre elegido sin cuidado puede causar malentendidos o una mirada en
blanco sobre el proyecto; puede hacer que la gente confunda el proyecto con otros proyectos;
y puede influir en la forma en que reaccionan al proyecto. A menos que la intención sea ofuscar
el propósito del proyecto (“Distrito de Ingeniería de Manhattan”—el proyecto de la bomba
atómica; “Have Blue”—el proyecto del caza furtivo F-117), el nombre debe
sugerir claramente de qué se trata el proyecto.

Deben evitarse los nombres ingeniosos o lindos; tienden a ser ambiguos y, a veces,
molestos. Todos los proyectos pueden adquirir apodos, que tienden a indicar cómo se siente
la gente sobre el proyecto ("Proyecto del infierno"), pero no mucho más. Sin embargo, si el
apodo gana un uso generalizado, a veces lo sensato es adoptarlo formalmente. (La Arteria
Central/Túnel de Boston se convirtió en la “Gran Excavación”, que no debe confundirse con
la “Gran Excavación” de Canadá, el Proyecto de Revitalización Urbana del Lago Wascana en
Saskatchewan. El proyecto de investigación geológica de la década de 1960 para perforar la
corteza terrestre hasta la discontinuidad de Mohorovicic se llamó Proyecto Mohole, pero a
medida que aumentaban los problemas políticos y técnicos, se conoció como "Proyecto
Nohole"). Un proyecto a menudo recibe el nombre de un lugar, una persona o el elemento
final que crea (Torres Petronas; Bandra-Worli Sea Link Bridge) , y para elementos finales con
nombres largos, está bien adoptar un acrónimo (BWSL), aunque siempre es una buena idea
verificar primero el acrónimo del nombre del proyecto antes de mantener el nombre; un
proyecto serio no debería hacer reír a la gente cada vez que ven sus siglas (Automated
Network for Uniform Security).
La definición del proyecto aborda la pregunta: ¿Qué debe hacer el proyecto para entregar el
concepto del sistema y satisfacer los requisitos del usuario y del sistema? La definición del
proyecto y la definición del sistema ocurren simultáneamente e interactivamente. El trabajo a
realizar según lo establecido en el plan del proyecto debe cumplir con los requisitos del sistema,
pero los requisitos del sistema deben ajustarse a los métodos de trabajo, presupuestos y
cronogramas especificados en el plan del proyecto.
Planificación detallada del proyecto
Antes de la Fase B, ya se habrá realizado una parte de la definición del proyecto: como mínimo,
se necesitaba alguna definición del proyecto en la Fase A para preparar la propuesta del
proyecto. Pero ese esfuerzo de definición habrá resultado, en el mejor de los casos, en un
esbozo de lo que está por venir. Durante la Fase B, ese esquema debe ampliarse y elaborarse
en detalle. El renovado esfuerzo de definición implicará la identificación de las tareas de trabajo
y los recursos necesarios, la creación de cronogramas, presupuestos y sistemas de control de
costos, y el equipo del proyecto, sus líderes, subcontratistas y personal de apoyo.
El equipo del proyecto comienza a evolucionar a partir del grupo esquelético que preparó la
propuesta, a veces en forma de cascada: el gerente del proyecto selecciona a los líderes del
equipo que, a su vez, ocupan los puestos del equipo debajo de ellos. El gerente del proyecto
negocia con los gerentes funcionales para obtener individuos específicos o personas con la
experiencia necesaria asignada al proyecto. A veces busca la aprobación del cliente al agregar
miembros al equipo del proyecto, lo cual es recomendable cuando el cliente debe trabajar en
estrecha colaboración con el equipo o cuando el cliente pueda tener una objeción. Una buena
relación entre el cliente y el equipo del proyecto es crucial para mantener una relación saludable
entre el cliente y el contratista.
Plan de Ejecución del Proyecto
A medida que se reúnen los miembros clave del equipo del proyecto, comienzan a preparar el
plan detallado del proyecto—el “plan de ejecución”. La audiencia del plan de ejecución es quienquiera
que vaya a realizar el proyecto, por lo que el plan debe abordar todo lo que necesiten saber,
incluidos, por ejemplo:
• Una declaración de alcance o SOW que incluye requisitos de usuario de alto nivel y requisitos
del sistema. • Estructura de desglose del trabajo y paquetes de trabajo o tareas. •
Organización del proyecto y asignación de responsabilidades. • Asignación de personal clave
a paquetes de trabajo. • Cronogramas de proyectos que muestren eventos, hitos o puntos de
acción crítica. • Presupuesto y asignación a paquetes de trabajo. • Plan de calidad para
monitorear y aceptar los entregables del proyecto, incluyendo
plano de
prueba • Plan de riesgos y medidas de contingencia o mitigación.
• Plan de adquisiciones. • Plan de revisión del trabajo. • Plan de
control de cambios. • Plan de implementación para guiar la
conversión o adopción de entregables. • Política/plan de salud,
seguridad y medio ambiente (HSE).
El plan de ejecución se describe con más detalle en el Capítulo 5, y los elementos del plan se
describen a lo largo del libro. Con respecto al último elemento anterior, HSE, tal vez sea obvio que
la gestión del proyecto es responsable de proteger al equipo del proyecto, a las partes interesadas
y a la sociedad de lesiones durante el proyecto y de los peligros para la salud a largo plazo
asociados con el proyecto y sus resultados. Como mínimo, el plan del proyecto debe abordar
medidas para protegerse contra accidentes y peligros para la salud según se requiera para cumplir
con los estándares de la industria y las leyes y regulaciones municipales, estatales y federales y,
además, para cumplir con las circunstancias únicas de las políticas de la Compañía con respecto a
proyecto.2 HSE. incluido o mencionado en el plan del proyecto, y el gerente del proyecto es
responsable de garantizar que se implementen las políticas, que se definan las funciones y
responsabilidades específicas de HSE y que el personal reciba la capacitación adecuada en H&S.
3
Los peligros significativos que no pueden eliminarse
deben incluirse en el plan de gestión de riesgos. La preparación del HSE incluye la consideración
de asuntos ambientales y de sustentabilidad como se discutió en
Capítulo 3.
Ver Capítulo 5
Ver Capítulo 3
Todos los elementos del plan de ejecución deben estar integrados; cada uno debe estar vinculado, ser
compatible y apoyar a los demás. Los detalles de estos elementos se discuten en la Parte III, comenzando
con el próximo capítulo. El Apéndice C al final del libro es un plan de ejecución de proyecto de muestra.
En proyectos grandes, la planificación se divide en subplanes creados por miembros subordinados del
equipo del proyecto. El gerente del proyecto coordina y supervisa sus esfuerzos para garantizar que los
subplanes sean completos y se unan. El plan final es revisado para su aprobación por la alta dirección del
contratista y el cliente.
La alta dirección del contratista se asegura de que el plan se ajuste a los proyectos y capacidades
existentes y futuros, y el cliente se asegura de que se ajuste a los requisitos del usuario y las condiciones
establecidas en el contrato.
Ansiosos por poner en marcha el proyecto, muchos contratistas se saltan la revisión del plan del
proyecto con el cliente. Esto es miope ya que el plan puede contener elementos a los que el cliente se
opone. A menudo, el proyecto se lleva a cabo y se implementa dentro de la organización del cliente, por
lo que todo en el plan debe encajar: el cronograma del proyecto debe ajustarse al cronograma del cliente;
los requisitos de flujo de efectivo del proyecto deben ajustarse al cronograma de pagos del cliente; el
personal y los procedimientos del contratista deben complementar los del cliente; y los materiales y
métodos de trabajo deben ser aceptables para el cliente.
Una vez que la gerencia y el cliente han aprobado el plan del proyecto y las especificaciones del
sistema, el equipo del proyecto centra su atención en el diseño detallado y la construcción del sistema;
esto es lo que sucede en la Fase C, como se cubre en los Capítulos 11 y 12. Sin embargo, como se
explicará más adelante, la planificación del proyecto nunca se detiene; continúa durante todo el ciclo de
vida del proyecto.

4.3 Planificación de proyectos por fases (ondas continuas)
Un objetivo importante de la Fase B es desarrollar el plan del proyecto, pero rara vez
produce un plan completo y detallado para todo el proyecto. El hecho es que, a pesar
de todo el esfuerzo dedicado a la planificación en la Fase B, a menudo el plan se
desarrolla en fases, no todas a la vez. Al comienzo de un proyecto hay demasiadas
incógnitas y es imposible especificar exactamente qué ocurrirá o debería ocurrir en
todo el proyecto. Solo a medida que avanza el proyecto y disminuyen las incógnitas,
se pueden completar los detalles en el plan. La situación es análoga a planificar una
ruta fuera de la carretera hacia algún destino, pero sin el beneficio de conocer los
obstáculos. Dado que solo puede ver el paisaje directamente delante, solo puede
planificar la primera parte de la ruta en detalle; más allá de eso, la ruta es vaga. Esto
está representado por la Fase I en la Figura 4.3a. A medida que avanza en la Fase I,
ve más obstáculos por delante, lo que le permite planificar la siguiente parte de la
ruta, la Fase II (b). El proceso continúa, completando los detalles de la ruta, fase por
fase, hasta llegar al destino (c y d).
Figura 4.3 Planificación de proyectos por etapas.
Al inicio de un proyecto, el cliente quiere saber el costo del proyecto y la fecha de

finalización, que se puede estimar mediante la preparación de un plan aproximado inicial.
Aunque gran parte del plan inicial es algo vago (análogo a la mancha sombreada en la
Figura 4.3), el plan suele ser suficiente para permitir a los gerentes estimar los recursos,
el tiempo y el costo del proyecto. A medida que el proyecto se pone en marcha, se
crean planes más detallados, pero solo para la fase más inmediata del proyecto (línea
de puntos, Figura 4.3). Mientras que el plan inicial se basó en información de proyectos,
estimaciones y pronósticos similares, las partes detalladas del plan se basan en hechos
sobre el próximo trabajo, hechos que se identifican a medida que se acerca el trabajo.
Para proyectos muy singulares, el plan aproximado inicial debe verse como eso: un
una indicación aproximada de los entregables del proyecto, el costo y la fecha de entrega, pero
no necesariamente un compromiso. Ese plan se preparó por primera vez durante el estudio de
factibilidad o el estudio de caso de negocios, pero a medida que avanza el proyecto, se
reemplaza con planes más detallados y tareas y cronogramas de trabajo más específicos. Solo
para la fase más inmediata donde el "terreno" es claramente visible es posible crear un plan
detallado y comprometerse con el trabajo, las fechas y los costos. La aplicación de esta
planificación de onda continua es una característica importante de los proyectos ágiles, que se
describe en el Capítulo 13.
Ver Capítulo 13
En algunos proyectos, cada fase concluye con un hito o puerta de entrada en la que el
cliente o los gerentes ejecutivos revisan los entregables y el desempeño del proyecto; si están
satisfechos, aprueban los entregables y pagan por el trabajo realizado hasta el momento. Al
mismo tiempo, revisan el plan detallado para la siguiente fase y evalúan los costos, riesgos,
etc. del plan de alto nivel actualizado para el resto del proyecto. Tenga en cuenta que esto
requiere que el plan para cada fase se prepare en gran medida en la fase anterior , como se
ilustra en la Figura 4.4. Si están satisfechos con el plan, autorizan que el proyecto pase a la
siguiente fase. Si se va a terminar un proyecto, eso sucede solo al final de una fase; la
terminación antes de esa fecha ocurre solo como resultado de eventos imprevistos externos al
proyecto.
Figura 4.4 Planificación detallada para cada fase del proyecto.
Fuente: Adaptado de Steyn H. (ed.) Project Management–A Multi-Disciplinary Approach. Pretoria: FPM
Publicación; 2003, pág. 27
En algunas organizaciones, este proceso de revisión de "fase inicial" es una mera

formalidad y un "sello de goma" para pasar a la siguiente fase. Sin embargo, más a menudo
cumple un propósito importante, en algunos casos con implicaciones estratégicas. Por
ejemplo, cada revisión de puerta de fase puede resultar en:
(a) Luz verde: todas las partes interesadas relevantes están satisfechas con el trabajo
realizado hasta el momento. Asimismo, aceptan los planes para el resto del proyecto
y que los riesgos identificados y el impacto comercial del proyecto justifican continuar
con el proyecto. El proyecto está autorizado para pasar a la siguiente fase.
(b) Luz amarilla: las partes interesadas sienten que el impacto comercial del proyecto
justifica continuar con el proyecto, pero no sienten que se cumplieron los objetivos
de la fase anterior o que los planes para el resto del proyecto son adecuados.
El equipo del proyecto debe rehacer parte o la totalidad de la fase anterior y/o
mejorar el plan. (c) Luz roja: debido a cambios en el entorno comercial, riesgos
o resultados decepcionantes de la fase anterior, las partes interesadas consideran
que el impacto comercial del proyecto es insuficiente. El proyecto se da por
terminado. Si existe la posibilidad de que las condiciones mejoren más adelante,
el proyecto se puede “congelar” para su reconsideración posterior.
En empresas que realizan múltiples proyectos simultáneos, las revisiones de puerta

de fase a veces se utilizan para comparar los proyectos: sus beneficios, requisitos de
recursos y rendimiento relativo, y para determinar cuál obtiene la luz verde, amarilla o
roja; esto se analiza en el Capítulo 18. El enfoque por etapas para la planificación y
aprobación de proyectos se ilustra con Mary y Peter.
Ver Capítulo 18
'
Ejemplo 4.1: María y PedroCasa Nueva
Mary y Peter compran una propiedad para construir una nueva casa. Se acercan
a NewHome Construction y le describen a Paul, el propietario, lo que tienen en
mente. Entre otras cosas, quieren saber cuánto costaría. Habiendo estado en el
negocio durante varios años, Paul tiene una idea del costo, pero se resiste a
cotizar un precio fijo ya que no conoce muy bien a Mary y Peter y si sus gustos
son baratos o caros. Además, desconfía de los posibles costos ocultos derivados,
por ejemplo, de las malas condiciones del suelo del sitio. Por lo tanto, ofrece una
gama de posibles precios en función de los pies cuadrados estimados de la casa
y una estimación de cuándo se completará la casa. Nadie se ha comprometido
todavía. Sobre la pregunta, “¿A dónde vamos desde aquí?” Paul responde que la
primera fase es hacer un diseño de concepto, después de lo cual entregará los
bocetos de la casa. También describe las otras fases del proyecto que prevé y los
entregables, el cronograma aproximado y el costo aproximado para cada una.
Mary y Peter firman un contrato para que Paul proporcione un diseño preliminar
y bocetos. El contrato especifica cuándo verán el diseño y los bocetos, qué

incluirán y excluirán los bocetos, y cuánto costarán. En el plazo de un mes reciben
y aprueban el diseño y los bocetos.
Paul ahora les presenta un segundo contrato, esta vez para el diseño detallado
que incluye dibujos que el equipo de construcción usará para construir la casa. Al
igual que la primera fase, el contrato especifica los entregables (dibujos), la fecha
de entrega y el precio. Unos meses más tarde, Mary y Peter aprueban los planos
y comienza la construcción.
Paul señala que el trabajo de construcción también se hará por fases, aunque
ahora, dice, hay suficiente información sobre el proyecto y su costo para que solo
se necesite un contrato. Les muestra el contrato, que enumera las fases restantes
del proyecto e incluye un período de garantía (después de la finalización de la
construcción) durante el cual NewHome reparará cualquier defecto sin cargo. El
contrato indica hitos y entregables para cada una de las fases y especifica que se
deberá realizar un pago al alcanzar cada hito. Antes de cada pago, Mary y Peter
tendrán la oportunidad de inspeccionar el trabajo y verificar que se haya completado
y cumpla con los estándares de mano de obra especificados en el contrato.
Este ejemplo ilustra los beneficios de la planificación del proyecto por etapas: al
principio, NewHome no tiene que comprometerse con el costo de construir una
estructura aún no definida, y durante el proyecto, Mary y Peter no tienen que
comprometerse a trabajar más allá de una sola fase. (de hecho, al finalizar
cualquier fase contratada pueden retirarse del proyecto). Los pagos de hitos
mejoran el flujo de efectivo de NewHome y reducen los pagos de intereses sobre
el dinero para la construcción prestado por el banco. También brindan a NewHome
cierta protección contra deudas incobrables: si Mary y Peter no cumplen con un
pago importante, NewHome simplemente deja de trabajar.
Las fases del proyecto forman la base de las metodologías del proyecto y la selección
de fases, como se analiza en los capítulos 17 y 18. En las organizaciones que tienen
metodologías de proyecto, los gerentes de proyecto siguen la secuencia prescrita de
fases estándar para planificar y ejecutar proyectos.
Carta del proyecto
El acta de constitución del proyecto es una proclamación de que la dirección ha aprobado un proyecto.
Para algunos proyectos, se crea una vez, luego de un estudio de factibilidad o aceptación de una propuesta;
para otros, se crea y se expande en múltiples puntos durante las fases de concepción y definición. Para los
proyectos internos , la carta tiene el propósito de anunciar y autorizar formalmente el inicio del proyecto. Para
proyectos externos , ese propósito se cumple mediante un contrato, por lo que, en general, no se requiere un
estatuto.
El estatuto describe el proyecto a las partes interesadas en la organización y establece la autoridad del
gerente del proyecto para organizar y hacer uso de los recursos; por lo tanto, debe estar firmado por al menos
un gerente ejecutivo. Incluye toda la información necesaria para dar al lector una buena visión general del
proyecto. A menudo, la carta contiene secciones similares al plan del proyecto. A veces es el plan del proyecto,
aunque comúnmente es algo breve y proporciona solo una descripción general del plan de ejecución descrito
anteriormente.
Para cualquier proyecto de tamaño razonable, el acta de constitución del proyecto se desarrolla después de
una planificación previa y un estudio de viabilidad. En grandes proyectos llevados a cabo en fases (por ejemplo,
FEL, descrito más adelante), se crea un estatuto y se utiliza para autorizar cada fase.
La metodología PRINCE2 prescribe tres estatutos: uno (llamado "mandato") autoriza la primera etapa, previa al
proyecto, del proyecto; otro (un “breve”) autoriza la segunda, etapa de iniciación; y un conjunto final de
documentos ("documentación de inicio del proyecto") autoriza las etapas posteriores.
Para un proyecto pequeño o una fase inicial de un proyecto, la carta puede ser un documento breve que
simplemente indique la aprobación del proyecto o la fase. Para la mayoría de los proyectos, sin embargo, es
más completo y puede incluir lo siguiente:
• Visión, propósito, beneficios del proyecto; problema resolverá u oportunidad lo hará

explotar.
• Justificación del proyecto (caso de negocio y análisis de impacto ambiental)
recomendaciones).
• Enfoque a seguir. • Declaración

del alcance del proyecto. •
Principales entregables, criterios de aceptación, responsables de
aceptación. •
Clientes y partes interesadas clave. •
Identificación del director del proyecto y su autoridad y responsabilidades. • Identificación de otros
tomadores de decisiones, su autoridad, responsabilidades y relaciones de reporte. • Listado de
recursos, incluido el personal del equipo del proyecto, la capacitación requerida,
subcontratistas, etc. •
Organización del proyecto y estructura de desglose del trabajo. •

Resumen del presupuesto del proyecto y plan de flujo de caja. •
Calendario maestro, fases del proyecto, hitos clave, fechas de vencimiento previstas. •
Riesgos y problemas percibidos. • Planes de: adquisiciones: seguridad, salud, protección
ambiental;
comunicación.
• Procedimientos de control.
A pesar de las similitudes, el acta de constitución del proyecto y el plan de ejecución difieren en dos formas
importantes. Primero, el propósito de la carta es describir, justificar y autorizar el proyecto; el propósito del
plan de ejecución es dar dirección a las partes interesadas que trabajan en el proyecto. Esto conduce a
grandes diferencias en el contenido de cada uno y, por lo general, a un plan de ejecución que es
sustancialmente más largo, más detallado y completo que el estatuto.
4
Carga frontal
Una variación de la planificación y aprobación de proyectos por etapas utilizada por algunas industrias
(química, mineral, petróleo y gas) en importantes proyectos de infraestructura industrial (que por lo general
cuestan más de mil millones de dólares) es el enfoque de "carga frontal" (FEL). FEL superpone las fases de
Concepción y Definición de la Figura 4.1 e incluye toda la recopilación de datos, el análisis y la documentación
necesarios para justificar y lanzar un proyecto. Se divide en tres fases, FEL-1, FEL-2 y FEL-3.
FEL-1, llamado "Identificación de oportunidades", es la generación de ideas y

fase de evaluación; se corresponde en cierto modo con la “etapa previa al proyecto” en la

metodología PRINCE2. El proyecto propuesto compite con otros proyectos para recibir
financiamiento, por lo tanto, el objetivo de FEL-1 es confirmar que el proyecto es compatible con
la estrategia organizacional y es un "proyecto preferido" (discutido en el Capítulo 18). El resultado
de FEL-1 es un caso comercial preliminar que confirma la viabilidad de la inversión de capital
propuesta.
Ver Capítulo 18
FEL-2 tiene diferentes nombres según la industria, por ejemplo, "planificación comercial",
"estudio de concepto" y "evaluación". En esta fase se “da forma” al proyecto en términos de
alcance, selección de tecnología y estrategia de ejecución. El resultado de FEL-2 es un caso de
negocios detallado, así como una declaración de alcance que permite pronósticos confiables de
costos y cronogramas. Por lo general, solo se incurre en el 1 por ciento de los costos totales del
proyecto durante FEL-1 y FEL-2.
FEL-3 es una "definición de proyecto" e incluye la preparación de un plan de ejecución de
proyecto detallado, un diseño conceptual avanzado y un diseño de sistema detallado (que en la
metodología de la Figura 4.1 se ubica como la primera etapa de Ejecución).
FEL-3 a menudo se divide en subfases que se conocen como "planificación de instalaciones/
planificación de ejecución", "prefactibilidad/factibilidad" y "selección/FEED (diseño de ingeniería
de front-end)". El resultado de FEL-3 es un plan de ejecución del proyecto, un diseño conceptual
(listo para los detalles), un plan de ingeniería básico y un acta de constitución detallada del
proyecto. Al final de FEL-3, normalmente se gasta del 3 al 5 por ciento del costo total del proyecto,
una cantidad relativamente pequeña para garantizar que los riesgos del proyecto sean aceptables
antes de comprometer la financiación total del proyecto.
Cada fase de FEL va seguida de una puerta: FEL-1 para evaluar la solidez del caso de
negocio, FEL-2 para evaluar la integridad de la definición del alcance y FEL-3 para determinar si
el proyecto está listo para ejecutarse. Dado que FEL-3 es la parte más costosa de FEL, no se
lleva a cabo a menos que el proyecto ya haya sido aprobado.
La decisión de aprobación del proyecto ocurre en la puerta FEL-2, lo que significa que la fase
FEL-2 debe ser muy exhaustiva y abordar todos los factores importantes en la decisión. La
cancelación del proyecto en la puerta FEL-3 ocurre raramente y solo con cambios en el entorno
del proyecto (caída brusca del mercado, recesión comercial, abandono de un socio comercial
importante).
Además de la definición del proyecto, FEL también aborda la definición del sistema, que se describe a continuación.
4.4 Definición del sistema
Los sistemas se definen a partir de sus requisitos. Por lo tanto, los requisitos son el punto de
partida para todos los proyectos de desarrollo de sistemas y la base para la planificación de
proyectos. Cada requisito afecta el alcance y la complejidad del artículo final, lo que a su vez
afecta el esfuerzo, el tiempo, el costo y el riesgo del trabajo del proyecto. A menos que los
requisitos estén claramente definidos y acordados, será imposible conceptualizar completamente
el producto final y crear un plan de proyecto viable. Con el contrato firmado y el proyecto a punto
de ponerse en marcha, se deben revisar los requisitos del usuario definidos en Concepción y
eliminar las lagunas y ambigüedades.
Requisitos del usuario revisados
Para productos y sistemas en mercados competitivos, los requisitos del usuario se enmarcan
inicialmente en términos generales; por ejemplo, supere al F-22, sepa mejor que la carne seca
de Joe, obtenga al menos una tasa de rendimiento del 20 por ciento o actualice a la última
versión del software. Los requisitos generales como estos deben ampliarse antes de que se
pueda iniciar un trabajo de desarrollo serio y la planificación del proyecto. Como se muestra en
el siguiente ejemplo, una definición deficiente de los requisitos puede llevar al fracaso del proyecto.
Ejemplo 4.2: Requisitos del usuario para el

desarrollo de productos
El grupo de marketing de un fabricante de electrodomésticos de cocina redactó los

requisitos para un nuevo procesador de alimentos. Los requisitos especificaban el tamaño
general, el peso, el uso, el precio y el volumen de ventas del producto propuesto, pero
nada sobre el rendimiento del producto, que el grupo de diseño de ingeniería estableció al
estudiar los productos de la competencia. El procesador de alimentos, tal como se
desarrolló, cumplió con todos los requisitos establecidos por marketing e ingeniería, pero
quedó obsoleto incluso antes de su lanzamiento porque los competidores habían lanzado productos mejores.
adecuado a las necesidades del cliente. Al definir el producto, tanto el grupo de marketing
como el de ingeniería ignoraron los requisitos del usuario para el procesador de alimentos,
es decir, los requisitos especificados por los usuarios reales.
Definir requisitos completos y precisos no es fácil. Entre los problemas

son:
• Los requisitos deben incorporar información no solo del usuario sino también de áreas
funcionales como marketing, ingeniería, fabricación y partes interesadas externas.
• La información necesaria para definir los requisitos no siempre está disponible cuando
se produce la definición, por lo que es fácil pasar por alto los requisitos necesarios o
incluir los innecesarios.
• Los requisitos incluyen términos vagos que no se pueden medir con precisión
(por ejemplo, “moderno” o “de bajo costo”).
• El usuario o el contratista no pueden describir adecuadamente los requisitos porque el

resultado final es complejo, abstracto o artístico. • El cliente o contratista define
intencionalmente los requisitos en términos ambiguos para permitir la libertad en los
resultados más adelante en el proyecto.
Problemas como estos dan como resultado una planificación del proyecto confusa y, más
tarde, disputas entre el cliente y el contratista sobre si el resultado final cumplió con los requisitos.
5
requisitos Los siguientes pasos pueden reducir tales problemas.
• Convencer a los grupos de usuarios y contratistas de la importancia de una definición

clara y completa de los requisitos. Los usuarios y contratistas a menudo son reacios a
dedicar el tiempo necesario para definir requisitos claros y completos. • Verifique si
hay ambigüedades y redefina los requisitos para que no quede ninguno. • Aumentar
los requisitos escritos con ayudas no verbales como imágenes, esquemas, gráficos y
modelos visuales o funcionales. • Evitar la especificación rígida de requisitos que
probablemente cambien debido a
incertidumbre o entorno cambiante.

• Tratar cada requisito como un compromiso al que tanto el usuario como el
el contratista está de acuerdo y firma.

• Después de que comience el proyecto, controle los requisitos y resista los intentos de
cámbialos.
• Utilizar un sistema de control de cambios para evaluar la necesidad y el impacto de los cambios
antes de decidir si se aprueban o no.
Los requisitos detallados del usuario provienen de una fuente: el usuario. El director del proyecto, sin
embargo, no debe aceptar cualquier requisito proporcionado por el usuario, sino que debe ofrecer
asistencia para definirlos. Así como los usuarios a veces requieren ayuda para comprender el problema
o la necesidad, también pueden necesitar ayuda para especificar sus requisitos. Es posible que no
entiendan el costo, el cronograma u otras ramificaciones de los requisitos, o lo que será necesario para
cumplirlos.
Para la mayoría de los proyectos, la lista de requisitos de usuario de alto nivel (resumen o viñetas)
debe caber en una página para una fácil referencia. Al principio del proyecto, el contratista se referirá a
la lista cuando prepare la declaración del alcance del proyecto; al final del proyecto, el cliente lo
consultará para determinar la aceptabilidad de los resultados del proyecto y los elementos finales.
La definición preliminar de los requisitos del usuario ocurre durante el estudio de factibilidad y la
preparación de la propuesta, y se incluye un resumen de los requisitos del usuario en el contrato. En los
sistemas simples, los requisitos del usuario rara vez superan unas pocas líneas o una página. En
sistemas grandes, sin embargo, pueden llenar volúmenes. Un ejemplo de lo primero son los requisitos
del usuario para un contrato para realizar un seminario de gestión de 1 día; un ejemplo de esto último
son los requisitos de los usuarios para el Proyecto Delta de 9 años y multimillonario para evitar que el
Mar del Norte inunde los Países Bajos.
Requisitos del sistema
Un impulso importante de la Fase B es traducir los requisitos del usuario en requisitos del sistema. Los
requisitos del sistema están orientados hacia la solución; especifican el enfoque y los objetivos del
contratista para satisfacer las necesidades como se detalla en los requisitos del usuario. Pero más allá
de cumplir con los requisitos del usuario, un proyecto también debe cumplir con las necesidades del
contratista. Por ejemplo, además de ser rentable, el contratista puede especificar requisitos para
mantener ocupados a los trabajadores calificados y las costosas instalaciones de producción.
Los requisitos del sistema definen el enfoque del sistema o de la solución, incluidas las funciones principales,
la arquitectura del sistema y el elemento final resultante (sistema, solución o producto), y proporcionan un
entendimiento común entre los miembros del equipo del proyecto sobre lo que se debe hacer en el proyecto.
Mientras que los requisitos del usuario representan la perspectiva del usuario, los requisitos del sistema se
derivan de la perspectiva del contratista.
Indican lo que los sistemas deben hacer para satisfacer los requisitos del usuario. Los siguientes son ejemplos
que contrastan los requisitos del usuario y los requisitos del sistema:
Requisitos del usuario 1. Los requisitos del sistema abordarán

El vehículo debe acelerar de 0 a 60 mph en diez
Tamaño y peso del vehículo, potencia del
segundos y acomodar a seis personas.
motor, tipo de transmisión.
2. La casa debe acomodar a una familia de cuatro.

Número y tamaño de las habitaciones.
Calidad y gasto de materiales y elementos

3. La casa debe ser lujosa.
decorativos.
4. La estación espacial debe generar

Tipo y capacidad de kilovatios del equipo de
electricidad para soporte vital,
generación de energía; tecnología para operación
fabricación y equipos experimentales.
primaria y operación de respaldo.
Diseño de configuración y superficies externas;

5. Las aeronaves deben ser "sigilosas". tipos de materiales; uso de componentes existentes
o desarrollados recientemente.
Los requisitos del sistema especifican lo que los diseñadores y constructores del proyecto deben abordar al
diseñar y construir el artículo final. Lo siguiente ilustra esto para el proyecto X-Prize/SpaceShipOne presentado
en el Capítulo 1.
Ver Capítulo 1
Ejemplo 4.3: Requisitos del sistema de alto nivel para

la nave espacial
A continuación se presentan cinco requisitos de usuario para la nave espacial, cada uno seguido de uno o
más requisitos del sistema. El primero especifica los requisitos del usuario, el segundo lo que debe
hacer la nave espacial y sus subsistemas y componentes para satisfacer esos requisitos.
1. Alcanzar una altitud de al menos 100 km:
1.1 El motor debe proporcionar suficiente empuje (es decir, ser potente
suficiente)
1.2 El motor debe funcionar lo suficiente
1.3 El vehículo debe ser liviano
2. Capacidad para tres personas:
2.1 La cabina debe ser lo suficientemente grande
3. Vuelo cómodo:
3.1 La temperatura de la cabina debe permanecer en un nivel cómodo

3.2 La presión de la cabina debe permanecer en un nivel cómodo 3.3 La
fuerza de aceleración del vehículo no debe exceder cierto nivel 3.4 La
cabina debe tener suficiente espacio para moverse
4. Diseño, construcción y lanzamiento relativamente económicos:
4.1 El combustible y el procedimiento de manejo del combustible deben

ser económicos 4.2 Los materiales estructurales del vehículo deben ser
económicos 4.3 Siempre que sea posible, utiliza tecnología y sistemas disponibles
en el mercado 4.4 Requiere pocas personas para mantener el vehículo
5. Capaz de ser "cambiado" en un máximo de 2 semanas:
5.1 Reparación/sustitución mínima de piezas/módulos entre

vuelos
5.2 Tiempo mínimo de repostaje 5.3
Tiempo mínimo de limpieza de cabina
Tenga en cuenta que los requisitos del sistema especifican "qué" debe hacer el
sistema, no "cómo" lo hará. Dicen, por ejemplo, “el motor debe generar suficiente empuje
para impulsar la nave espacial a 100 km. antes de que se quede sin combustible”, pero no cómo.
Abordar el “cómo” viene después.
Definir los requisitos lo suficiente como para que los diseñadores sepan por qué se esfuerzan
se denomina análisis de requisitos. El resultado del análisis de requisitos es una lista completa
de requisitos funcionales.
Requerimientos funcionales
Los requisitos funcionales especifican las funciones que el nuevo sistema debe poder realizar
para cumplir con los requisitos del usuario. Por ejemplo, las funciones de la nave espacial
incluyen propulsión, manejo y maniobrabilidad, habitabilidad humana, seguridad y apoyo y
mantenimiento. La herramienta común para identificar los requisitos funcionales de un sistema
complejo es el diagrama de bloques de flujo funcional, FFBD, que se describe en el Apéndice A
de este capítulo. Deben identificarse todas las funciones significativas para el sistema, sus
subsistemas, componentes e interfaces, incluido el soporte y el mantenimiento. La mayoría de
los sistemas realizan varias funciones básicas, cada una de las cuales tiene numerosas
subfunciones.
Asociados con cada requisito funcional hay objetivos o requisitos de rendimiento. Estos
especifican en términos técnicos, por ejemplo, dimensiones físicas, millas por hora, radio de
giro, decibeles de sonido, aceleración, porcentaje de eficiencia, temperatura de operación, costo
de operación, los requisitos objetivo que la función debe satisfacer, así como las pruebas,
procedimientos y medidas. que se utilizará para demostrar que se han cumplido los objetivos.
El equipo del proyecto se refiere a estos requisitos de desempeño en el diseño o compra de
componentes para el sistema.
Además, se pueden imponer otros requisitos al sistema en general o a subsistemas y
6
componentes específicos. Los siguientes son típicos:
1. Compatibilidad. Capacidad de los subsistemas para integrarse en todo el sistema o

entorno y contribuir a los objetivos de todo el sistema.
2. Comunidad. Habilidad de un componente para usarse indistintamente con un tipo de

componente existente pero diferente. Un sistema de “alta similitud” contiene muchos
componentes listos para usar (OTS, por sus siglas en inglés); uno de "baja similitud" tiene
muchos que deben ser desarrollados recientemente.
3. Rentabilidad. Costo total del sistema si se adopta un diseño particular. Esto incluye el costo
del diseño, así como el costo de implementar y operar el diseño para lograr un nivel de
beneficio determinado.
4. Confiabilidad. Capacidad del sistema o componente para funcionar a un nivel determinado o
durante un período de tiempo determinado antes de fallar.
5. Mantenibilidad. Capacidad del sistema para ser reparado dentro de un cierto
período de tiempo (es decir, la facilidad con la que se puede reparar).
6. Testabilidad. Grado en que el sistema puede ser probado sistemáticamente y
medido por sus capacidades de rendimiento.
7. Disponibilidad. Grado en el que se puede esperar que el sistema funcione
cuando sea necesario.
8. Usabilidad. Cantidad de esfuerzo físico o tensión, habilidad técnica, entrenamiento o

habilidad requerida para operar y mantener el sistema.
9. Robustez. Capacidad del sistema para sobrevivir en un entorno hostil.
10. Capacidad de expansión. Capacidad del sistema para expandirse fácilmente para incluir
nuevas funciones o adaptarse a nuevas condiciones.
Estos requisitos a veces se denominan requisitos "no funcionales" (!) porque no están vinculados
a funciones particulares y se desean para todo el sistema y sus componentes.
Requerimientos Prioridad y Margen
Dos propiedades de cada requisito son su prioridad y margen. La prioridad de un requisito es,
simplemente, la importancia relativa del requisito. Cuando varios requisitos entran en conflicto y no se
pueden cumplir todos, la prioridad determina cuáles se cumplirán y cuáles no. Supongamos que se
especifica que un producto funcione de cierta manera y tenga una altura máxima particular, pero el
rendimiento tiene prioridad. Saber esto será útil para el equipo de diseño si luego determina que para
lograr el rendimiento especificado, el requisito de altura debe
ser superado.
Relacionado con la prioridad está el margen de un requerimiento—la cantidad por la cual el
requerimiento puede variar. Por ejemplo, el requisito “altura máxima de cuatro pies; margen de
dos pulgadas” les dice a los diseñadores que en caso de que deban exceder el requisito de
altura, tienen como máximo dos pulgadas más.
Estructura de desglose de requisitos
Durante el análisis de requisitos, las funciones del sistema se clasifican y asignan a grupos
lógicos. La estructura de desglose de requisitos (RBS) en la Figura 4.5 es un ejemplo simplificado
que muestra formas de agrupar requisitos. La RBS debe incluir todos los requisitos funcionales
identificados; en sistemas grandes, estos pueden contarse por cientos o incluso miles.
El propósito de la RBS es proporcionar una referencia común para todos los que trabajan en
el proyecto. A menudo, un requisito pertenecerá a múltiples componentes del sistema, lo que
significa que varios equipos de proyecto trabajarán para cumplir con ese requisito. El RBS
permite que estos equipos coordinen esfuerzos y eviten omisiones o duplicaciones.
Los requisitos del sistema brindan una dirección general para el proyecto, pero son de alto
nivel y no lo suficientemente detallados como para decirle al equipo del proyecto qué debe
diseñar, construir o comprar para crear el sistema del elemento final. En cada uno de los
requisitos se deben poner estipulaciones; estas se denominan especificaciones del sistema.
Figura 4.5 Estructura de desglose de requisitos.
Especificaciones del Sistema
Las especificaciones del sistema se derivan de los requisitos del sistema. Definen el artículo final y
sus subsistemas, componentes y procesos con suficiente profundidad para que el equipo del
proyecto pueda diseñar, construir y/o comprar esos subsistemas y componentes.
Las especificaciones del sistema son la base para las especificaciones de los subsistemas de
nivel inferior, que son la base para las especificaciones de incluso los subsistemas de nivel inferior.
A partir de la especificación del sistema para un automóvil nuevo, por ejemplo, se derivan las
especificaciones para el tren de transmisión, la suspensión, el sistema de dirección, el sistema de
frenos, etc. del automóvil. Las especificaciones para estos componentes de nivel inferior normalmente
toman la forma de un dibujo o, para un artículo comercialmente disponible “listo para usar” (OTS),
un número de catálogo.
Ejemplo 4.4: Especificaciones del sistema para nave espacial
La progresión de los requisitos del usuario a los requisitos del sistema y de los
requisitos del sistema a las especificaciones del sistema se ilustra en la Figura 4.6. En
la parte superior, el requisito del sistema "El motor debe proporcionar suficiente
empuje" se deriva del requisito del usuario "La nave espacial debe alcanzar los 100
km"; a su vez, la especificación del sistema "El motor debe proporcionar un empuje de
ÿ 88 kN" se deriva del requisito del sistema "El motor debe proporcionar suficiente
empuje". (Tenga en cuenta que kN o kilo newton es una medida de fuerza). Las
especificaciones del sistema le indican al equipo del proyecto lo que debe hacer y los
objetivos que debe cumplir. Por ejemplo, además de que el motor tenga un empuje
específico, otra especificación, 4.1.1, dice que el motor quemará óxido nítrico y caucho.
Dado que no hay motores OTS que hagan esto, esto significa que el equipo tendrá que
diseñar y construir uno desde cero. Las flechas múltiples para cada especificación en
la última columna indican que cada especificación debe satisfacer múltiples requisitos.
Figura 4.6 Relaciones entre los requisitos del usuario, los requisitos del sistema y las especificaciones del sistema para
la nave espacial.
Trazabilidad
Desarrollar especificaciones claras es importante, pero también lo es hacer un seguimiento de sus

relaciones entre sí y con los requisitos del sistema. A lo largo del ciclo de desarrollo de sistemas, se
realizarán numerosos cambios y compensaciones en los requisitos, cada uno de los cuales tendrá un
impacto en múltiples especificaciones.
Por ejemplo, alterar el peso de la nave espacial (Figura 4.6, requisito del sistema 1.3) afectará la
altitud de lanzamiento requerida de la nave espacial (especificación 1.20.1) y el empuje y tiempo de
combustión requeridos del motor (1.1.1 y 1.2.1). Debido a que el peso afecta muchas de las
especificaciones, un diseñador no puede ser arrogante al hacer algo que pueda alterarlo. Cualquier
decisión que afecte el peso debe evaluarse por el impacto que tendrá en las especificaciones para el
lanzamiento y el motor del cohete. La capacidad de rastrear los efectos de los cambios en algunas
especificaciones y requisitos a otros se denomina "trazabilidad". Una herramienta útil para este propósito
es la matriz de trazabilidad, descrita en el Apéndice A de este capítulo. El proceso de administrar todo
esto: identificar especificaciones, vincularlas a componentes físicos, rastrear los impactos de los cambios
y controlar los cambios para que se cumplan los requisitos y no entren en conflicto se denomina
administración de configuración y control de cambios, que se analizan en los capítulos 9 y 11.
Las especificaciones del sistema son los criterios que guiarán el trabajo real del proyecto; están
escritos por y para especialistas en la materia del proyecto (analistas de sistemas, programadores,
ingenieros, diseñadores de productos y procesos, consultores, etc.) y abordan todas las áreas del
proyecto: diseño, fabricación, instalación, operación y mantenimiento. Las especificaciones del sistema
deben establecerse para cumplir, pero no exceder , las especificaciones de referencia del cliente, que
son especificaciones de alto nivel que el cliente puede entender. Esta es una forma de evitar el
“desplazamiento del alcance”, es decir, el crecimiento de los requisitos del proyecto que hace que los
presupuestos y los cronogramas del proyecto también crezcan.
Pruebas iterativas de diseño y creación rápida de prototipos

La definición de requisitos y especificaciones, y el diseño y las pruebas del sistema

generalmente ocurren de manera iterativa, particularmente cuando el elemento final del
proyecto es complejo. Los requisitos no pueden definirse completamente sin una cierta
cantidad de trabajo de diseño previo, y el trabajo de diseño no puede completarse sin una
cierta cantidad de fabricación y pruebas previas. El proceso general generalmente cae en
cascada, como se ilustra en la Figura 4.7, con bucles ocasionales y pasos repetidos.
El trabajo que fluye de una etapa a otra como este se llama proceso en cascada. Para
evaluar y modificar las especificaciones, a menudo se utiliza un prototipo . Un prototipo es
un modelo de funcionamiento temprano de un sistema o componente creado con el fin de
demostrar el rendimiento, la funcionalidad o la viabilidad. Se construye de acuerdo con las
especificaciones iniciales y luego se prueba; si, con base en las pruebas, se modifican las
especificaciones, entonces el prototipo se modifica y se vuelve a probar. Este proceso
garantiza que el diseño básico del sistema sea compatible con las especificaciones del sistema.
Figura 4.7 Ciclo de desarrollo iterativo (proceso en cascada) para sistemas complejos.
Puede ser difícil conceptualizar el sistema cuando no existe un sistema como el

que se va a desarrollar. El sistema que el cliente “ve” puede ser muy diferente del que
imagina el desarrollador, pero sin un modelo físico o funcional, la diferencia puede no
ser evidente. Requerir que el cliente especifique y apruebe los requisitos al principio
del proyecto solo intensifica el problema. Obliga al cliente y al desarrollador a
comprometerse con las decisiones antes de llegar a un entendimiento mutuo sobre
los requisitos.
En un proceso llamado creación rápida de prototipos, se produce un modelo
rudimentario e intencionalmente incompleto del producto que inicialmente es algo
clave del sistema.
simple yno
económico
es el sistema
. 7 Elcompleto,
modelo dey es
prototipo
algo fácil
rápido
de crear
(RP) yrepresenta
modificar. partes
El
cliente experimenta con el RP para evaluar la funcionalidad del sistema y determinar
las modificaciones o adiciones necesarias. Después de algunas iteraciones de
experimentación y modificación de requisitos, los requisitos finales y el concepto de
diseño se confirman. En el desarrollo de software, el RP puede ser una serie de
pantallas o ventanas con consultas para permitir que un usuario “sienta” cómo sería el
sistema. Los arquitectos utilizan modelos a escala física de edificios con el mismo
propósito.
Saben que un modelo físico siempre es mejor que un dibujo o una lista de requisitos
para transmitir el aspecto, la sensación y la funcionalidad de un diseño. Los dibujos y
requisitos le dicen al equipo de desarrollo lo que se espera, pero el proceso de RP
garantiza que los dibujos y requisitos se finalicen solo después de que el cliente los
haya aceptado tal como los representa el modelo de RP.
Normalmente, el proceso de RP no acelerará la fase de definición; en cambio,
podría alargarlo. Es probable que el primer modelo de RP sea incorrecto, aunque
permitirá que el cliente y el desarrollador experimenten, aprendan y finalmente
seleccionen los requisitos óptimos. Los modelos y maquetas de RP se utilizan, por
ejemplo, para demostrar la forma y la funcionalidad de las formas y tamaños de los
paneles de control utilizados en plantas y equipos, y para diseñar los diseños interiores
de automóviles y cabinas de aviones.
Gestión de proyectos ágiles
El enfoque en cascada de la figura 4.7 (y, en general, las fases de A, B y C en

La Figura 4.1) se aplica a proyectos en los que los requisitos se pueden definir al principio
del proyecto y no cambiarán después. Tales situaciones son como una cascada: los
proyectos se mueven "hacia abajo" de una etapa a la siguiente. Pero también como una
cascada, es difícil ir hacia el otro lado, lo cual es análogo a lo que sucede cuando hay que
repetir las etapas de un proyecto. Cuando los requisitos de un proyecto no se pueden
definir completamente desde el principio o cambiarán significativamente, entonces se
deben repetir los pasos del proyecto. El proceso en cascada puede acomodar esto (las
flechas hacia atrás en la Figura 4.7), aunque no de manera muy efectiva, porque alterar
los requisitos a mitad de camino es costoso y requiere mucho tiempo. Waterfall se aplica
a proyectos en los que los requisitos pueden y deben definirse con anticipación (por
ejemplo, diseñar y construir un nuevo edificio o avión); para proyectos en los que los
requisitos no se pueden definir o cambiarán con certeza (por ejemplo, algunos proyectos
de software), los llamados métodos ágiles son mejores.
En la gestión ágil de proyectos, el proyecto se divide en una secuencia de pequeños
esfuerzos iterativos, cada uno de los cuales está a cargo de un equipo dedicado a cumplir
un conjunto limitado de requisitos y lanzar una solución o un resultado parcial. El sistema
de artículo final se desarrolla en una serie de iteraciones rápidas, donde, en efecto, se
repiten las etapas de definición, diseño, desarrollo y prueba. Cada iteración (llamada
"sprint" porque es corta, un mes o menos) ofrece un resultado parcial pero independiente
y completamente funcional. En cualquier momento en que finalice el proyecto, el cliente se
queda con los resultados utilizables producidos hasta ese momento. La gestión ágil de
proyectos es el tema del Capítulo 13.
Ver Capítulo 13
Participación del equipo en la definición
A medida que se desarrollan los requisitos y el plan del proyecto, surgen preguntas:
"¿Cómo sabe cuándo se completaron los requisitos?" y "¿Cómo mantienes a todos en el
proyecto enfocados en esos requisitos?" El problema es especialmente complicado cuando
el proyecto involucra a numerosas personas y equipos, y se extiende por meses o años.
Parte de la respuesta es: hacer que la definición del sistema y del proyecto sea un esfuerzo
de equipo que incorpore las perspectivas de todos los que tienen o
tendrá una participación significativa en el proyecto: clientes, proveedores, áreas

funcionales como ingeniería, marketing, fabricación, servicio al cliente y compras, y
usuarios y operadores. Cuanto más participen estos individuos y grupos en la definición
de los requisitos y el plan del proyecto, mejor el plan del proyecto tendrá en cuenta los
requisitos y las necesidades e intereses de todas las partes interesadas a lo largo del ciclo
de vida del sistema. Todos en el proyecto deben trabajar con el mismo conjunto de
requisitos: un documento de requisitos maestros, RBS o equivalente. Cualquier requisito
adicional necesario debe derivarse de este documento maestro y ser compatible con él.
En proyectos de desarrollo de productos, una buena forma de generar requisitos de

productos es en un taller externo para todas las partes interesadas clave del proyecto,
incluidos grupos funcionales, usuarios y proveedores. Comenzando con una lista de
necesidades o requisitos del cliente, el equipo desarrolla los requisitos del sistema (o, a
falta de requisitos de usuario adecuados, también los desarrolla). Para sistemas complejos,
un mejor enfoque es crear un equipo compuesto por todas las partes interesadas clave
con el fin de definir los requisitos. El término para esto es ingeniería concurrente, lo que
implica los esfuerzos combinados de las partes interesadas clave para definir los requisitos
para la satisfacción de todos. El término es algo engañoso porque la ingeniería concurrente
implica no solo ingeniería, sino también marketing, compras, finanzas, calidad y
más.
Los equipos de ingeniería concurrentes a veces se denominan equipos de diseño y

construcción porque combinan los intereses y la participación de diseñadores y
constructores en un solo esfuerzo.
8
Ejemplo 4.5: Equipos de diseño y construcción en Boeing
En un momento en la fábrica de Boeing, la planta de producción estaba ubicada en

el piso principal y el grupo de ingeniería estaba arriba. Cada vez que ocurría un
problema en la planta, los ingenieros simplemente bajaban para echar un vistazo.
Hoy, Boeing emplea a muchos miles de personas en varios lugares, y una interacción
tan fácil no es posible. Al igual que otras grandes corporaciones, a medida que
Boeing creció, sus unidades de finanzas, ingeniería, fabricación y planificación se
convirtieron en "silos", cada uno con fuertes intereses propios y poca interacción con el resto.
otros. En el desarrollo del avión comercial 777, Boeing quería cambiar eso e
implementó el concepto de "equipo de diseño y construcción" o DBT. Cada DBT
incluye representantes de todas las unidades funcionales involucradas, las aerolíneas
clientes y los principales proveedores. El concepto surgió de una pregunta: "¿Cómo
hacemos un mejor avión?" La respuesta requería no solo una buena comprensión del
diseño y la fabricación de aeronaves, sino también conocimiento de las operaciones y
el mantenimiento de las aeronaves. Para capturar dicho conocimiento, los clientes,
fabricantes y diseñadores se unieron al principio del proyecto para discutir formas de
incorporar todos sus objetivos en el diseño de la aeronave.
La formación de DBT reflejó el desglose físico de los principales subsistemas y
subcomponentes del avión. Por ejemplo, el ala se dividió en subsistemas principales,
como el borde de ataque y el borde de salida del ala, y luego se dividió en componentes
como el flap interno, el flap externo y los alerones; la responsabilidad de cada
subsistema y componente estaba a cargo de un DBT.
El proyecto requería 250 DBT, cada uno con 10 a 20 miembros y funcionaba como
una pequeña empresa. Los equipos se reunían dos veces por semana durante unas
pocas horas, siguiendo una agenda preestablecida coordinada por un líder de equipo.
El concepto de tener tanta gente en las reuniones de diseño (personas de aerolíneas,
finanzas, producción y calidad) era totalmente nuevo, pero con tanta gente
representando tantos intereses, en realidad había pocos conflictos.
Dado que la mayoría de los componentes en un avión interactúan (interfaz) con
muchos otros, la mayoría de los participantes en el programa tuvieron que ser
asignados a múltiples DBT (para asegurar que sus componentes funcionaran con
otros componentes de DBT). El representante de fabricación, por ejemplo, pertenecía
a 27. Su deber era decirles a los ingenieros lo que sucedería cuando sus elegantes
diseños se encontraran con las realidades del metal, los procesos de fabricación y los
trabajadores de la línea de ensamblaje y mantenimiento, y ofreció sugerencias que
mejorarían el diseño del avión. mantenimiento. Una sugerencia se refería a la cubierta
del puntal que sujeta el motor al ala. El pasaje contendría una gran cantidad de
componentes eléctricos e hidráulicos a los que el personal de mantenimiento tendría
que acceder, pero los ingenieros no se habían dado cuenta de que la reparación de
los componentes requeriría la eliminación de todo el pasaje. Sin embargo, el
representante de fabricación se dio cuenta y sugirió agregar dos puertas grandes,
uno a cada lado de la pasarela. Esto mejoró el acceso a los componentes del
interior y simplificó enormemente su reparación.
Los equipos de ingeniería concurrentes se analizan con más detalle en el Capítulo

14. Otra práctica para definir requisitos y mantener el proyecto centrado en ellos es el
despliegue de funciones de calidad (QFD). Esto se trata en el Apéndice B de este capítulo.
Ver Capítulo 14
4.5 Resumen
Hay buenas razones por las que el enfoque del ciclo de vida del proyecto se utiliza en tantos
tipos de proyectos. En primer lugar, hace hincapié en la planificación, revisión y autorización
continuas. En cada etapa, los resultados se examinan y se utilizan como base para las
decisiones y la planificación de las etapas posteriores. En segundo lugar, el proceso está
orientado a objetivos: se esfuerza por mantener el enfoque en los requisitos del usuario y los
objetivos del sistema. Los errores y problemas se detectan a tiempo y se corrigen antes de
que se salgan de control; si el entorno cambia, se pueden tomar medidas oportunas para
modificar el sistema o terminar el proyecto. En tercer lugar, los requisitos del usuario y los
requisitos del sistema siempre están a la vista y las actividades se realizan de modo que estén
coordinadas y ocurran en el momento adecuado y en la secuencia correcta.
Las fases iniciales de un proyecto (conceptualización y definición) son importantes para la
viabilidad y el éxito del proyecto. Lo que sorprende es la poca atención que se le da a la
definición de los requisitos del usuario y de los sistemas en tantos proyectos, y el ímpetu para
comenzar a preparar un plan sin siquiera saber cuál se supone que será el resultado final del
proyecto. La definición del proyecto y la definición del sistema van de la mano; sólo en los
casos en que hay mucha libertad en términos de lo que quiere el cliente, cuándo lo quiere y
cuánto está dispuesto a pagar, un proyecto puede tener éxito en ausencia de buenos requisitos.
En el caso más habitual (el cliente es más exigente y el cronograma y el presupuesto están
limitados), el éxito se basa en una descripción bien definida de lo que debe ser y hacer el
resultado final: los requisitos del usuario y los requisitos del sistema.
9
Apéndice A: Etapas de la Ingeniería de Sistemas
La metodología de ingeniería de sistemas descrita en el Capítulo 2 sigue una serie de etapas

que son muy parecidas a las del ciclo de vida del proyecto y el ciclo de desarrollo de sistemas.
Un nombre inapropiado, realmente, la ingeniería de sistemas no es "ingeniería" en el mismo
contexto que otras disciplinas de ingeniería. Más bien, como se describió anteriormente, es un
proceso lógico empleado en la evolución de un sistema desde el punto en que se identifica por
primera vez una necesidad, a través de la planificación, el diseño, la construcción y la
implementación y operación final del sistema por parte de un usuario. El proceso, descrito en la
Figura 4.8, tiene dos partes, una asociada con el desarrollo y producción del sistema (Etapas 1
a 4), la otra con la utilización del sistema (Etapa 5).
Ver Capítulo 2
10
Etapa 1. Identificación de Necesidades y Diseño Conceptual
Las tareas principales de esta etapa, que son análogas a la Fase A del ciclo de vida del
proyecto, son definir las necesidades y los requisitos de las partes interesadas, realizar un
análisis de factibilidad y realizar un análisis de requisitos de alto nivel, una síntesis a nivel del
sistema y una revisión del diseño del sistema. El resultado de esta etapa es un diseño de "línea
de base funcional": una lista de requisitos de alto nivel y funciones de alto nivel del sistema de
artículo final previsto.
Identificación de partes interesadas y necesidades

Figura 4.8 Etapas del proceso de ingeniería de sistemas.
La ingeniería de sistemas se ocupa de problemas mal definidos. El cliente puede sentir que algo anda
mal, o que se requiere algo nuevo, pero no tiene claro el origen del problema o la necesidad, o cómo
debería verse o hacer el sistema. A veces ni siquiera está claro quién tiene el problema o la necesidad. El
primer paso en la ingeniería de sistemas es identificar las partes que se verán afectadas o que podrán
afectar el sistema. Incluso identificar al “cliente” no es trivial; puede ser una organización, pero dentro de
la organización solo ciertas partes tendrán la autoridad para tomar decisiones relacionadas con el sistema,
o lo usarán, operarán o se verán afectadas por él. Estas partes deben ser seleccionadas e identificadas
sus necesidades.
El desarrollo de una concepción clara de la necesidad o problema comienza por hacer preguntas
básicas: 11
1. ¿Cómo surgió el problema o la necesidad?

2. ¿Quién cree que es un problema o siente la necesidad?
3. ¿Es este el problema o la necesidad raíz, o es una manifestación de un problema más profundo?
¿problema?
4. ¿Por qué es importante una solución? ¿Cuánto dinero (o tiempo, etc.) ahorrará? ¿Cuál es el
valor del sistema que resolverá el problema?
5. ¿Qué tan importante es la necesidad? ¿Se aplicarían mejor los recursos a otro
¿necesitar?
Las respuestas a estas preguntas conducen a una descripción preliminar de un sistema que aborda
la necesidad o el problema, incluido su rendimiento, costo y cronograma esperados. El cliente revisa la
descripción y quizás redefine la necesidad, en cuyo caso el contratista debe redefinir la descripción del
sistema. El proceso continúa de un lado a otro hasta que las partes acuerdan la definición de necesidad
y el sistema propuesto.
Definición de requisitos
Los requisitos de alto nivel especifican todo lo importante sobre el sistema: sus objetivos, ciclo de vida,
modos operativos, restricciones e interfaces con otros sistemas. Como se discutió anteriormente, deben
abordar a todas las partes interesadas (productores, proveedores, operadores y otros que en última
instancia usarán y se beneficiarán, administrarán, mantendrán y de otra manera impactarán o serán
impactados por el sistema) y reflejar sus intereses y perspectivas: por ejemplo , clientes corporativos
interesados en el mercado, la capacidad y los costos operativos y de capital del sistema; operadores
interesados en su desempeño, durabilidad, confiabilidad, disponibilidad de repuestos, etc.; y usuarios
que se preocupan por su comodidad, seguridad y usabilidad.
En la práctica de la ingeniería de sistemas, los requisitos iniciales se expresan en el idioma de las

partes interesadas y se compilan en una lista denominada documento de requisitos de las partes
interesadas (o usuarios) (SRD). Cualquiera que lea el SRD debe poder comprender fácilmente la misión
y la aplicación del sistema previsto. El proyecto no debe iniciarse hasta que los principales interesados
hayan revisado y aprobado el SRD.
Ejemplo A4.1 SRD para la nave espacial 12

Como ejemplo, revisemos el proyecto X-Prize/SpaceShipOne descrito en el Capítulo 1. Los

criterios de la competencia eran enviar un vehículo reutilizable capaz de transportar a tres personas
al espacio dos veces en 2 semanas. Además de ganar el X-Prize, un objetivo del desarrollador
Burt Rutan y el cliente Sir Richard Branson era desarrollar tecnología que permitiera el turismo
espacial de bajo costo. Entre las limitaciones se encontraban un presupuesto relativamente
pequeño y una empresa de desarrollo pequeña con recursos limitados. Por lo tanto, el SRD
incluiría el desarrollo de una nave espacial con los siguientes requisitos:
Ver Capítulo 1
1. Puede alcanzar una altitud mínima de 100 km.

2. Lleva tres personas.
3. Proporciona un vuelo cómodo.
4. Es relativamente económico de diseñar, construir y lanzar.
5. Se puede cambiar en 2 semanas o menos.
6. Es intrínsecamente seguro de operar.
Factibilidad
El siguiente paso es identificar formas alternativas de alto nivel (nivel de sistema) para satisfacer las
necesidades, objetivos, restricciones y requisitos. Las alternativas se evalúan en términos de costos,
riesgos, efectividad y beneficios mediante estudios y modelos; se recomiendan las soluciones más
viables a los clientes y seguidores.
Análisis de requerimientos
Con la aprobación del proyecto y las alternativas a nivel del sistema, el siguiente paso es especificar qué
debe hacer el sistema para poder cumplir con los requisitos del SRD.
Por ejemplo, el requisito de las partes interesadas de que la nave espacial “brinde un vuelo cómodo”
implica requisitos del sistema de que la cabina de la nave espacial
la temperatura, la humedad y la presión permanecen en niveles "cómodos" durante todo

el vuelo. Esto implica que la nave espacial estará equipada para realizar las funciones
necesarias para que esto suceda. Mientras que el SRD especifica el sistema en términos
de los deseos o necesidades de las partes interesadas, los requisitos del sistema le
indican al diseñador las funciones que debe realizar el sistema y las características físicas
que debe poseer para cumplir con el SRD. Este proceso de definición de requisitos,
llamado análisis de requisitos, da como resultado un documento llamado especificación
del sistema, que se describe más adelante. El análisis de requisitos para sistemas físicos
aborda tres tipos de requisitos: funcionales, de rendimiento y de verificación.
Requerimientos funcionales
Figura 4.9 FFBD para descomponer funciones de nivel de sistema en funciones de nivel inferior.
Los requisitos funcionales especifican las funciones que debe realizar el nuevo sistema
para cumplir con todos los requisitos del SRD, incluidos los de soporte del sistema,
operación y mantenimiento. Una herramienta popular para analizar y definir requisitos

funcionales es el diagrama de bloques de flujo funcional, FFBD, ilustrado en la Figura 4.9.
Cada bloque representa una función que el sistema debe realizar para satisfacer los requisitos.
Como se ilustra, cada función se define con mayor detalle al descomponerla en subfunciones;
por ejemplo, como se muestra, la función 3 se compone lógicamente de cinco subfunciones,
3.1 a 3.5. En la etapa de diseño conceptual, la descomposición de funciones en subfunciones
más pequeñas y mejor definidas avanza solo al siguiente nivel (por ejemplo, subdivide la
función 3 en 3.1–3.5). Posteriormente, en la etapa de diseño preliminar, la descomposición se
reanudará y continuará hasta el nivel necesario para llegar a la mejor definición de requisitos
posible. En la figura, esto se muestra al descomponer la función 3.5 en las funciones 3.5.1–
3.5.4.
Observe el esquema de numeración utilizado en la figura 4.9: todas y cada una de las
funciones tienen un identificador único que permite rastrearlas hasta la función original a nivel
del sistema; por ejemplo, la función 3.5.4 contribuye a la función 3.5, que contribuye a la función 3.
Esta “trazabilidad” de las funciones es fundamental porque a lo largo del ciclo de vida del
sistema se realizarán numerosos cambios en los componentes y funciones, y para cada
cambio es necesario conocer el impacto en las funciones de nivel superior e inferior. Esto
ayuda a prevenir errores que podrían conducir a problemas posteriores. Por ejemplo, los
tanques criogénicos de la nave espacial Apolo 13 se diseñaron originalmente para operar a
28 voltios. Posteriormente, el diseño de la nave espacial requería que ciertos controles se
cambiaran a 65 voltios. Esto implicó cambios en numerosos componentes, incluidos los
tanques criogénicos, pero de alguna manera se perdió el vínculo entre los tanques y los
controles, y los cambios nunca se realizaron. Durante la misión, este error provocó la explosión
de un tanque, lo que arruinó la misión y casi costó la vida a los tres astronautas.
Ejemplo A4.2: Desglose de requisitos

funcionales para la nave espacial
La figura 4.10 muestra una parte del FFBD para la nave espacial y la descomposición
de las funciones a nivel del sistema que abordan los requisitos 3 y 5 de las partes
interesadas. Las otras funciones a nivel del sistema también se descompondrán.
Figura 4.10 Desglose de funciones a nivel de sistema para nave espacial.
Requisitos de desempeño y verificación
Asociados con cada requisito funcional están los requisitos de desempeño y los requisitos de
verificación. Mientras que un requisito funcional establece lo que debe hacer el sistema, un requisito
de desempeño establece qué tan bien debe hacerlo.
Los requisitos de desempeño generalmente se especifican en parámetros físicos como velocidad,
aceleración, peso, precisión, potencia, fuerza o tiempo. Son los objetivos en los que los diseñadores
ponen sus miras. Por ejemplo, el requisito de las partes interesadas "proporcionar un vuelo cómodo"
tiene muchos requisitos funcionales, incluidos algunos para la temperatura y la presión de la cabina.
Los requisitos de rendimiento asociados para estos podrían ser:
1. Temperatura de la cabina: 75–85 grados F

2. Presión de la cabina: 4,2–3,2 psi.
Acompañando a cada requisito de desempeño hay un conjunto de requisitos de

verificación; estos especifican procedimientos, medidas y pruebas para verificar que se ha
cumplido el requisito de desempeño. Por ejemplo, los requisitos de verificación especificarían
los tipos de pruebas para demostrar que la temperatura y la presión de la cabina
permanecerán en los niveles de rendimiento requeridos durante los vuelos espaciales.
Síntesis
Hasta ahora, el proceso de ingeniería de sistemas se ha centrado en el análisis de arriba
hacia abajo, lo que da como resultado una gran lista de requisitos funcionales, de
rendimiento y de verificación. El siguiente paso, la síntesis, analiza las relaciones entre los
requisitos a nivel del sistema y las formas alternativas de satisfacer los requisitos. Una
pregunta es, ¿pueden satisfacerse estos requisitos usando los existentes, "listos para usar"?
(OTS) diseños y productos, o será necesario emplear nuevos y diferentes diseños o
tecnologías? Un artículo OTS es uno que se puede comprar o construir fácilmente; si
cumple con los requisitos, un artículo OTS a menudo es preferible a uno de nuevo diseño
porque está fácilmente disponible y, por lo general, es menos costoso. A veces no hay un
elemento OTS y crear un nuevo diseño que cumpla con los requisitos sería demasiado
costoso, arriesgado o llevaría mucho tiempo; en tales casos, los requisitos deben ser
revisados.
El resultado de la síntesis se denomina "especificación del sistema", que es una lista
completa de todas las funciones que el nuevo sistema debe satisfacer más una solución
firme o tentativa (a desarrollar o comprar) para cada función. La especificación del sistema
sirve como guía para los diseñadores en las últimas etapas del diseño preliminar y detallado
del sistema.
Ejemplo A4.3: Especificación del sistema para motor de

nave espacial
Se debe tomar una decisión sobre el tipo de motor de cohete que tendrá la nave
espacial. Entre los requisitos funcionales para el motor se encuentran:
1.1 Debe proporcionar un empuje de x 4.1 El
costo del combustible y el manejo del combustible deben ser económicos 5.3 El
procedimiento de recarga de combustible debe ser simple 6.1 El combustible, el
sistema de combustible y el combustible deben ser intrínsecamente seguros
Una verificación de los motores de cohetes OTS existentes utilizados para lanzar
satélites muestra que ninguno cumple con los requisitos; todos son demasiado costosos
de alimentar y operar y son algo peligrosos. Por lo tanto, se debe desarrollar un nuevo
motor de cohete, uno que sea simple y económico de alimentar y operar, seguro y que
proporcione el empuje necesario. Los experimentos revelan una solución prometedora:
un motor que utiliza caucho ordinario como combustible y óxido nitroso (gas hilarante)
como oxidante; ambos materiales son estables, seguros, económicos y fáciles de
manipular. Se toma la decisión de adoptar la tecnología y diseñar y construir un motor
completamente nuevo. Por lo tanto, una especificación del sistema para la nave espacial
(de muchos cientos) es que el motor del cohete quema óxido nitroso y caucho.
La especificación del sistema se revisa y compara con los requisitos funcionales en una
reunión formal. Cuando se aprueba, se convierte en la "línea de base funcional" o plantilla
para todo el trabajo de diseño posterior.
13
Etapa 2. Diseño Preliminar
El propósito de la etapa de diseño preliminar es traducir los requisitos funcionales a nivel del
sistema en requisitos de diseño para los subsistemas. Esta etapa se corresponde
aproximadamente con la Fase B. Se realizan estudios de los elementos de alto nivel que
componen el sistema y los requisitos a nivel del sistema se asignan entre los subsistemas.
Funciones de los Subsistemas
El proceso FFBD, como se ilustra en la figura 4.10 , ahora se repite para descomponer las
funciones a nivel de sistema en funciones a nivel de subsistema y, como antes, para definir
requisitos funcionales, de rendimiento y de prueba para cada bloque funcional. Las

funciones se descomponen al nivel necesario para definir completamente cada
subsistema y permitir decisiones sobre si cada función puede cumplirse con un
diseño o producto OTS, o si debe diseñarse y construirse desde cero. En el diseño
preliminar, hay un cambio sutil en el enfoque de lo que hará el sistema a cómo lo
hará. El cambio es del diseño funcional al diseño físico .
Ejemplo A4.4 Descomposición de funciones

en subfunciones
La Figura 4.11 muestra el FFBD para la función 5.5, acoplando (fijando) la

nave espacial con el vehículo de lanzamiento. Este requisito se deriva del
requisito a nivel del sistema de "respuesta en 2 semanas o menos".
Figura 4.11 FFBD para acoplar SpaceShipOne y White Knight.
Supongamos que el requisito de rendimiento para acoplar la nave espacial con la parte
más vulnerable de la nave nodriza se establece en 10 horas. Habiendo descompuesto la
función en todas las subfunciones del procedimiento, los planificadores pueden establecer
los requisitos de tiempo para las subfunciones de modo que el procedimiento de
emparejamiento general no supere las 10 horas.
Agrupación de Funciones: Elementos de Arquitectura y Configuración
El siguiente paso es agrupar las funciones y requisitos identificados de acuerdo con la

arquitectura física del sistema. En general, el término "arquitectura" se refiere a los componentes
principales de un sistema y cómo se configuran o organizan para
satisfacer las funciones del sistema; por ejemplo, la arquitectura que la mayoría de la gente tiene en
mente para una bicicleta es:
• Componentes principales: dos ruedas, cuadro, asiento, pedales y cadena, manillar. •

Configuración: ruedas unidas en los extremos del marco; la rueda delantera gira sobre el bastidor;
asiento montado sobre bastidor entre ruedas; pedales unidos al marco, unidos por cadena a
la rueda trasera; etc.
A veces la arquitectura “se ve bien”, a veces no. A menudo, para satisfacer requisitos únicos, los
diseñadores se ven obligados a desviarse de la arquitectura común, y el resultado es una arquitectura
de "aspecto divertido".
Ejemplo A4.5: Arquitectura de la nave espacial
La nave espacial tendrá características de avión de un fuselaje y alas, pero también características
de una nave espacial de un motor de cohete y la capacidad de maniobrar en el espacio.
A diferencia de un avión en el que la cabina y las paredes del fuselaje son iguales, la cabina de
una nave espacial es un "recipiente a presión" separado instalado dentro del fuselaje.
La arquitectura de la nave espacial incluirá los siguientes subsistemas:
• Fuselaje: estructura que contiene o está unida a otros subsistemas (recipiente a presión
de cabina, hidráulica, aviónica, motor, sistema de combustible, alas, etc.). • Recipiente
a presión de cabina: contiene asientos, espacio de almacenamiento, instrumentos y
controles de vuelo, y sistema de control ambiental. • Motor del cohete: sistema de
propulsión principal, sistema de combustible, controles del motor. • Aviónica: electrónica de
aviación; computadoras, subsistemas de comunicación, navegación, controles de vuelo,
sistema de energía auxiliar,
etc.
• Superficies aerodinámicas/alas: alas principales, cola y actuadores hidráulicos/electrónicos.
• Tren de aterrizaje: puertas de tren, tirantes, patines o llantas, frenos.
Cada subsistema principal realizará una función principal o un conjunto de funciones a nivel del sistema.
funciones como se enumeran en la línea de base funcional. A partir de este momento, cada
uno de estos subsistemas se denominará elemento de configuración o CI. En general, un CI
es un subsistema o componente cuyo historial se documenta y supervisa a lo largo del ciclo
de vida completo del sistema: su diseño, producción y uso.
El propósito de esta documentación y seguimiento (es decir, la gestión de la configuración)
es garantizar que los cambios en el diseño, la producción o el uso del CI no alteren ni
degraden su capacidad para cumplir con los requisitos funcionales. La gestión de la
configuración utiliza la "trazabilidad" para evitar problemas como el cambio de voltaje que
causó el accidente del Apolo 13 mencionado anteriormente. Se refiere no solo a los
principales subsistemas, sino también a cualquier elemento identificado como crítico para el
rendimiento, riesgoso o costoso.
Asignación de requisitos
A partir de este punto, el diseño consta de (1) una lista de requisitos funcionales y (2) un
diseño de alto nivel del sistema: el subsistema principal o CI (la arquitectura del sistema). El
siguiente paso es “asignar” los requisitos funcionales a los CI, lo que significa asignar la
responsabilidad de cada requisito funcional a uno o más de los CI. El propósito aquí es
garantizar que todos los requisitos funcionales sean abordados (y, con suerte, satisfechos)
por al menos uno de los subsistemas o CI. Las asignaciones resultantes se muestran en
una “matriz de asignación” o “matriz de trazabilidad”: mostradas en la Figura 4.12, las
columnas de la matriz son los subsistemas responsables de cumplir con los requisitos; las
filas de la matriz son los requisitos que deben cumplir los subsistemas.
Con esta asignación se acelera la transición de funciones a elementos físicos.

Dado que cada uno de los CI representa algo que en última instancia será un elemento
físico: una pieza de hardware, software o ambos, la asignación de requisitos funcionales a
los CI representa una transición en el pensamiento de lo que se debe hacer (por ejemplo,
viajar 100 km sobre la Tierra) a cómo se hará (con una nave espacial que tiene fuselaje,
cabina, alas y motor, configurada de cierta manera).
Observe en la Figura 4.12 que la responsabilidad de algunos requisitos es compartida
por más de un CI. Por ejemplo, el peso del sistema (requisito 1.5) es compartido por todos
los CI. Es decir, el peso de la nave espacial es la suma de los
pesos de todos los CI, y si el peso de alguno cambia, también cambia el peso de la
nave espacial. Si el peso máximo cargado de la nave espacial se establece en
3.600 kg, los IC deben diseñarse de manera que todos ellos combinados no
excedan ese peso.
Figura 4.12 Matriz de asignación o trazabilidad.
Fuente: Adaptado de Falconbridge R. y Ryan M. Managing Complex Technical Projects. Boston: Artech;
2003, pág. 78.
Ejemplo A4.6: Asignación de peso entre CI

Pregunta: ¿Cómo se diseñan y desarrollan todos los CI para que al final el
peso total (requisito compartido) no supere los 3600 kg? Responder:
calcule el porcentaje del peso total de la nave espacial que debe tener en cuenta cada
CI y configúrelo como el peso de diseño "objetivo" para el CI. Por ejemplo, asigne,
digamos, el 30 por ciento del peso total del sistema al fuselaje y el contenido, el 20 por
ciento al motor, el 20 por ciento a las alas, el 10 por ciento a la aviónica y el 10 por ciento
a todo lo demás. Por lo tanto, el peso objetivo del fuselaje sería 0,30 x 3600 kg = 1080
kg, el peso objetivo del motor es 0,20 x 3600 kg = 720 kg, y así sucesivamente. Dado
que lograr los objetivos es fundamental, cada uno se designa como una Medida de
rendimiento técnico, o TPM, lo que significa que, a medida que se diseñan los CI, sus
pesos estimados y reales se comparan cuidadosamente con los objetivos. Si durante el
proyecto queda claro que no se puede lograr un objetivo (como seguramente sucederá),
entonces se reajustan las asignaciones. Si, por ejemplo, el peso del motor no puede
mantenerse en su objetivo sino que debe aumentarse en 30 kg, entonces los pesos
asignados para otros subsistemas deben reducirse correspondientemente o el peso
objetivo de la nave espacial debe aumentarse en 30 kg. A lo largo del proceso de diseño,
será necesario ajustar los objetivos y las asignaciones de CI según lo guíe el proceso
TPM. Este proceso se describe en el Capítulo 11.
Ver Capítulo 11
Interfaces
Ninguno de los subsistemas funciona de forma independiente; todos dependen de las salidas
de otras funciones y, a su vez, proporcionan entradas a otras más; en una palabra, interactúan.
Parte del proceso de diseño preliminar es identificar todas las interfaces en el sistema y
establecer requisitos para las interfaces. Una fuente principal de información sobre las
interfaces son los FFBD. Por ejemplo, el FFBD de la figura 4.11 muestra que la función 5.5
recibe información de las funciones 5.3, 5.4 y 4.6.6 y proporciona información a las funciones
8.6.3 y 9.3. Cada flecha representa una interfaz y el "flujo" de algo entre funciones. La “cosa”
que fluye puede ser:
• Físico: conexiones mecánicas, uniones y soportes físicos, tuberías.

• Electrónica: señales analógicas o digitales.

• Eléctrico—energía eléctrica. • Hidráulica/
neumática—líquida o gas. • Software—datos.
• Ambiente—temperatura, presión, humedad, radiación, magnetismo. • De

procedimiento: finalización de un paso de procedimiento para que pueda realizarse otro paso siguiente.
empezar.
La identificación de las interfaces es necesaria para establecer requisitos sobre las entradas y
salidas de cada subsistema y elemento. Por ejemplo, dado que el fuselaje de la nave espacial
contiene el motor y también soporta las alas, ni las alas ni el motor pueden diseñarse sin considerar
también el diseño del fuselaje, y viceversa. Los requisitos para cada interfaz (p. ej., flujo máximo o
mínimo permitido o resistencia física) los establece un equipo de diseño que incluye representantes
de los subsistemas a ambos lados de la interfaz.
Síntesis y Evaluación
Diseñar cada uno de los CI y sus subsistemas y elementos implica elegir entre alternativas de
diseño y, nuevamente, decidir si comprar o modificar un diseño o producto OTS, o desarrollar un
nuevo diseño desde cero. Se comprará un diseño o producto OTS que cumpla con todos o la
mayoría de los requisitos para un IC y no sea demasiado costoso; de lo contrario, el CI debe
diseñarse desde cero.
La selección de alternativas en la etapa de diseño preliminar debe considerar la síntesis de los
componentes: los impactos de cada decisión de diseño sobre otros componentes y el sistema en
general. El siguiente es un ejemplo.
Ejemplo A4.7: Compensaciones en el diseño del tamaño de la cabina
El requisito de peso para una nave espacial es un gran problema porque cuanto mayor es el
peso, más empuje (potencia) requiere el motor del cohete para impulsar el vehículo al
espacio y mayor es la capacidad de carga de la nave nodriza para llevarlo en alto. En algún
punto temprano en el diseño conceptual, el
se establecerá el peso máximo y, a partir de entonces, se hará todo lo posible para encontrar
formas de reducirlo. Considere a continuación algunas decisiones de compensación que
enfrentan los diseñadores.
¿Qué tan grande debe ser la cabina? En general, la cabina debe tener suficiente espacio
para tres personas, instrumentos y controles y estiba; una cabina más grande sería más cómoda
para los ocupantes pero también pesaría más. Supongamos que se elige una cabina de
volumen m , lo que dará como resultado un peso estimado de w para la nave espacial. Suponga
también que para propulsar un vehículo de peso w al espacio se requerirá un motor de cohete
con un empuje de y (Figura 4.13, diagramas superiores). Tenga en cuenta que si se aumenta el
tamaño de la cabina, también se debe aumentar el empuje del motor del cohete, a menos que
se pueda reducir el peso en algún otro lugar de la nave espacial.
Figura 4.13 Impacto del tamaño de la cabina en el peso del vehículo, el empuje del cohete y el tren de aterrizaje.
Ahora considere el impacto del peso del vehículo en otra decisión: el tren de aterrizaje.
Cuanto más pesa el vehículo, más fuerte es la marcha requerida; pero, siendo todo lo
demás igual, cuanto más fuerte es el engranaje, más pesado es el engranaje. Si el peso
de un tren de aterrizaje con ruedas típico, lo suficientemente fuerte como para soportar el
vehículo, se considera demasiado alto, entonces se debe considerar una alternativa,
como un patín (Figura 4.13, abajo). El patín no tiene ruedas y pesa menos que un
engranaje con ruedas. Si el patín cumple con otros requisitos funcionales, entonces se
elegiría sobre un tren de aterrizaje con ruedas.
Tales decisiones de compensación serán necesarias para todos los CI y otros componentes.
A medida que se toman decisiones, evoluciona un diseño que cumple con los requisitos. Se
establece la forma y configuración de los CIs, y comienza a tomar forma la apariencia física del
sistema. Al final de la etapa de diseño preliminar, se habrá establecido la arquitectura del
sistema y se habrán asignado todos los requisitos a nivel del sistema entre los principales
subsistemas (CI). Combinados, la arquitectura y los requisitos asignados forman el diseño de
"línea de base asignada" (ver ejemplo, Figura 4.14).
Figura 4.14 Representación pictórica de los principales subsistemas (CI) y diseño de referencia asignado. (El gracioso
La arquitectura “mirando” se deriva de que la nave espacial tiene que cumplir con muchos requisitos. Al volver a entrar, las alas
girar hacia arriba, convirtiendo a la nave espacial en un gran freno de aire que flota hacia la Tierra como un volante, evitando
así la alta velocidad y la alta temperatura. Más cerca del suelo, las alas se inclinan hacia atrás y el barco se desliza hasta aterrizar).
Etapa 3. Diseño detallado y desarrollo del sistema
La etapa de diseño detallado implica una descripción más detallada de los subsistemas,
ensamblajes, componentes y partes del sistema principal y los elementos de apoyo. Corresponde
aproximadamente a las tareas realizadas en la Fase B y en las primeras Fase C.
Todo hasta este punto ha sido de naturaleza analítica. Con un diseño detallado, el proceso de
desarrollo pasa de “conceptos en papel o computadora” (SRD, especificaciones del sistema,
FFBD) a un diseño que está listo para construir. Se toman decisiones sobre si los subsistemas y
componentes funcionarán manual o automáticamente; si los componentes serán electrónicos,
mecánicos o hidráulicos;
si la entrada-salida será manual, mecánica, electrónica, etc.

Los componentes OTS disponibles se seleccionan sobre la base de encuestas o pruebas de
laboratorio, y los componentes recién desarrollados se prueban experimentalmente utilizando
modelos que permiten verificar los diseños por ensayo y error. Los modelos o maquetas de
componentes ("placas de prueba") se utilizan para desarrollar piezas de equipo que posteriormente
se acoplarán e integrarán en el sistema general. Se ensambla un prototipo (un sistema casi completo)
con el fin de realizar pruebas de desarrollo y evaluar el sistema general en términos de satisfacción
de los requisitos. En el Capítulo 9 se describen diferentes tipos de modelos y maquetas para pruebas .
Ver Capítulo 9
14
Las pruebas y la evaluación del desarrollo y diseño del sistema incluyen:
1. Comprobación del funcionamiento de los subsistemas cuando se combinan en el completo

sistema.
2. Evaluar la validez de los supuestos de diseño.
3. Prestar mucha atención a las interfaces:
a.retroalimentación y “conversación cruzada” entre

subsistemas. b.ajustes y calibraciones. c. capacidad de
servicio y mantenimiento.
El sistema se comprueba bajo una variedad de condiciones y modos operativos.

Los problemas que antes se pasaban por alto a menudo salen a la luz durante estas pruebas. Los
diseños se modifican para eliminar deficiencias, o para corregirlas, y mejorar el sistema.
Ejemplo A4.8: Prueba de SpaceShipOne
Numerosas pruebas en tierra y en vuelo de SpaceShipOne dieron como resultado cambios;

por ejemplo:
• En un vuelo de prueba, la nave espacial comenzó a cabecear violentamente y solo con

Gran dificultad tuvo el piloto para recuperar el control. Los ingenieros diagnosticaron
que la causa era una cola demasiado pequeña, que rediseñaron rápidamente. (El
problema era que la pequeña empresa no tenía un túnel de viento para probarlo. Sin
inmutarse, montaron el ensamble de cola en una camioneta Ford y lo revisaron
corriendo arriba y abajo de la pista).
• El patín de punta mostró un desgaste excesivo después de las pruebas y tuvo que ser
reemplazado por uno con un material más fuerte.
Cuando no hay suficiente tiempo o dinero para construir maquetas de prueba, los primeros modelos
fabricados se someten a pruebas y evaluación de diseño.
Gradualmente, a medida que se realizan modificaciones y se aprueba el diseño, comienza la
producción a gran escala. Las pruebas de diseño y desarrollo se eliminan gradualmente y se
reemplazan con control de calidad para garantizar que el sistema del artículo final, tal como se produce,
se ajuste a las especificaciones de diseño.
En este momento, también se abordan los métodos, los recursos y la capacidad para producir el
sistema (diseño del proceso). Esto implica el diseño de instalaciones y procesos de fabricación nuevos
(o el rediseño de los antiguos), la selección de materiales y piezas de equipo específicos, y la
preparación para el control de producción, pruebas de calidad, herramientas de fabricación, transporte
de productos, contratación y capacitación de personal, y recopilación de datos y Procesando.
Etapa 4. Fabricación, Construcción y/o Producción del Sistema
De manera análoga a la última parte de la Fase C, en la Etapa 4 el sistema es (1) producido en masa,
(2) producido en cantidades limitadas con diferentes características, o (3) construido como un solo
elemento. Esta etapa comienza tan pronto como el diseño es aprobado y “congelado”.
La etapa implica la adquisición de materiales y el control de la producción/construcción para mantener
el rendimiento, la calidad, la confiabilidad, la seguridad y otros requisitos.
Etapa 5. Operación y Soporte del Sistema

La etapa 5 completa el proceso de ingeniería de sistemas. De manera análoga a la Fase D,

el cliente mantiene y opera el sistema hasta que se desgasta o se vuelve obsoleto. El
desarrollador del sistema puede continuar brindando soporte al sistema de varias maneras:
ayudando a implementar, instalar y verificar el sistema; ayudar en la operación diaria o servicio
de campo y soporte de mantenimiento; modificar o mejorar el sistema para asegurar la
satisfacción continua; o brindar apoyo para el cierre, la eliminación gradual y la eliminación
del sistema al final de su ciclo de vida. La última forma, el cierre y eliminación del sistema, es
una consideración importante en el diseño y operación de sistemas que tienen el potencial de
degradar el medio ambiente circundante. El diseño de reactores nucleares y minas de metales
y carbón, por ejemplo, debe tener en cuenta la forma en que se apagará cada uno. Su cierre
debe incluir medidas para restaurar la tierra, limpiar los desechos y eliminar las toxinas del
suelo y el agua, lo que puede ser costoso, llevar mucho tiempo y extender el ciclo de vida del
sistema por años o décadas.
Ejemplo A4.9: Ciclo de vida de SpaceShipOne
El desarrollo preliminar de SS1 y sus sistemas de soporte comenzó en 1999, y el

desarrollo completo comenzó en abril de 2001, aunque en total secreto. Exactamente 2
años después, Dick Rutan anunció sus intenciones de capturar el X-Prize y comenzaron
las pruebas de vuelo (Figura 4.15).
Figura 4.15 SS1 debajo de la nave nodriza White Knight.
Foto cortesía de John Nicolás
En mayo de 2004, Mike Melville pilotó la nave en una prueba de más de 100 km,
lo que lo convirtió en el primer astronauta civil del mundo. El 29 de octubre volvió a
volar SS1 al espacio, y menos de 2 semanas después lo hizo también el piloto Brian
Binney, ganando el X-Prize de $10 millones para el equipo SS1 (Figura 4.16). Hoy
SS1 se exhibe en el Museo Smithsonian del Aire y el Espacio en Washington, DC
Desde entonces, se han desarrollado una nave espacial más grande, SS2, y una
nave nodriza más grande, WK2, para uso de la "línea espacial" comercial de Sir Richard Branson.
Virgin Galactic, que espera eventualmente operar una flota de ellos.
Figura 4.16 Diseñador Burt Rutan (centro) y pilotos Mike Melville (izquierda) y Brian Binney.
Foto cortesía de John Nicholas.
Apéndice B: Despliegue de la función de calidad 15
QFD es una metodología para definir requisitos y, específicamente, para traducir las
necesidades del cliente en características del sistema o producto, y especificar los procesos
y tareas necesarias para producir el sistema o producto. Como se demostró en numerosas
aplicaciones, QFD no solo produce resultados finales que satisfacen las necesidades del
cliente, sino que lo hace en menos tiempo y a un costo menor que las metodologías de
desarrollo tradicionales. QFD fue desarrollado por Kobe Shipyards de Mitsubishi en 1972,
adoptado por Toyota en 1978 y desde entonces ha sido implementado por empresas de todo
el mundo.
dieciséis
Casa de la Calidad
QFD exige que el equipo del proyecto articule los medios por los cuales el producto o sistema
que se está diseñando cumplirá con los requisitos del cliente. El proceso comienza con las
necesidades del mercado o los requisitos del cliente y luego utiliza una matriz de planificación
llamada Casa de la Calidad para traducir las necesidades o requisitos en requisitos técnicos.
La estructura de la casa se muestra en la Figura 4.17.
• El lado izquierdo de la matriz enumera "lo que" el cliente necesita o requiere. •

La parte superior de la matriz enumera los atributos de diseño o los requisitos técnicos
del producto; estos son "cómo" el producto puede cumplir con los requisitos del
cliente.
• Las secciones adicionales en los lados superior, derecho e inferior muestran las
correlaciones entre los requisitos, las comparaciones con los competidores, las
evaluaciones técnicas y los valores objetivo.
Figura 4.17 Estructura de la casa de la calidad.
Las características de la casa de la calidad se ilustran en el Ejemplo A4.10.
Ejemplo A4.10: House of Quality para un interruptor

de control remoto de TV
La figura 4.18 es una parte de la matriz de la casa de la calidad para el diseño de un

interruptor de control remoto (RC) de televisión. La casa se interpreta de la siguiente manera:
• Filas (Requisitos del cliente): son lo que los clientes consideran importante sobre
el producto. Son el producto “qué es”. • Importancia para el cliente: Los requisitos
se han ordenado por rango 1–
6 por preferencia del cliente; “botones multifunción” tiene la calificación más

alta; “RC fácil de ver/encontrar” el más bajo.
• Columnas (Requisitos técnicos): Son los requisitos o atributos del producto,
las formas en que el producto cumple con los requisitos del cliente. Son los
“cómos” del producto. • Matriz central: Contiene símbolos que muestran la
fuerza de la relación entre los qué y los cómo (fuerte positivo, positivo,
negativo, fuerte negativo). Por ejemplo, “botones fáciles de ver” tiene una
fuerte relación positiva con el tamaño y el color de los botones, y una
relación positiva con el tamaño del chasis del control remoto. Tenga en
cuenta que cada relación tiene una ponderación numérica (pequeño = 1,
medio = 3, fuerte = 9). • Ponderación de importancia: los pesos de los
símbolos en cada columna se suman para determinar la importancia relativa
de los atributos técnicos. Así, el atributo técnico más importante son las
“dimensiones del RC” (peso = 9 + 3 + 1 + 9 = 22), seguido del “tamaño de
los botones” y el “color del chasis del RC” (9 + 3 = 12 cada uno) .
Figura 4.18 Casa de calidad para interruptor de control remoto de televisión.
• Techo a dos aguas: Contiene las correlaciones entre los atributos técnicos.
Por ejemplo, "dimensiones del chasis RC" tiene una fuerte correlación positiva
con "tamaño de los botones" y "número de botones"; El "tamaño de los
botones" tiene una fuerte correlación negativa con el "número de botones" (los
botones más pequeños permiten más botones; los botones más grandes
permiten menos).
• Valores objetivo: Las descripciones numéricas o cualitativas (en el “sótano” de
la casa) son objetivos de diseño establecidos para los atributos técnicos. Un
objetivo del diseño, por ejemplo, es mantener las dimensiones del RC dentro
de "6 × 18 × 2 cm". • Valoración técnica: El gráfico (en el “subsótano”)
compara la
empresa (x = “nosotros”) frente a dos de sus competidores, A y B, en los atributos

técnicos. Por ejemplo, el producto actual de la compañía funciona relativamente
mal en los atributos de las dimensiones del control remoto y el color de los
botones, pero le va bien en el color del chasis y el mecanismo de retorno. Estas
evaluaciones se basan en los resultados de las pruebas y las opiniones de los
ingenieros. • Evaluación competitiva: el gráfico de la derecha califica a la empresa
ya sus competidores en términos de requisitos del cliente. Estas calificaciones
se basan en encuestas de clientes. Por ejemplo, los clientes piensan que a la
compañía le va mejor en términos de que el RC sea “atractivo”, pero peor en
términos de que sea “fácil de sostener”.
La casa de la calidad sugiere áreas en las que los diseñadores pueden enfocarse para
ganar un nicho de mercado. Por ejemplo, la calificación a la derecha en la Figura 4.18
indica que ninguna empresa lo hace particularmente bien en términos de "botones fáciles
de ver" a pesar de que los clientes clasifican ese requisito en segundo lugar en importancia.
Un requisito de que los clientes tengan una clasificación alta, pero en el que todas las
empresas tengan una clasificación baja, sugiere una característica que podría explotarse
para mejorar la posición competitiva de una empresa. La empresa que fabrica el control
remoto, por ejemplo, podría intentar mejorar la visibilidad de los botones aumentando su
tamaño y/o usando colores brillantes.
La casa proporciona una forma sistemática de organizar, analizar y comparar los cómos con
los qués, y evita que se pasen por alto las cosas. Justifica dónde dedicar tiempo y dinero, y
dónde abstenerse de sumar recursos.
Aún así, los resultados de QFD son tan buenos como los datos que ingresan a la casa. Como
mínimo, las evaluaciones competitivas requieren dos perspectivas: los puntos de vista de los
clientes con respecto a cómo se compara el producto con la competencia, y los puntos de vista
de los ingenieros y técnicos con respecto a qué tan bien el producto cumple objetivamente con
los requisitos técnicos. Los datos provienen de muchas fuentes, incluidos grupos focales,
pruebas de productos de la competencia e informes publicados.
Un aspecto importante de la definición de requisitos es determinar las prioridades: distinguir
entre los pocos aspectos críticos y los muchos aspectos triviales del sistema del artículo final
para garantizar que los críticos se realicen correctamente. Como ejemplo, una impresora de
computadora puede tener hasta 30 características de diseño diferentes que afectan
calidad de impresión, pero la característica más importante es el proceso de fusión del tóner
derretido en la página, que es una función de la combinación correcta de temperatura, presión y
tiempo. Centrarse en la temperatura, la presión y el tiempo reduce el énfasis del diseño a los
relativamente pocos parámetros técnicos de mayor importancia para el rendimiento. Estos
parámetros se convierten en aquellos para los que los diseñadores buscan los valores "óptimos".
Una vez que se han establecido los valores óptimos, el análisis avanza para identificar factores
importantes en el proceso de fabricación necesarios para lograr los requisitos de diseño. La casa
de la calidad es solo el primero de varios pasos en el proceso QFD que conduce a un plan de
proyecto.
Proceso QFD17
El proceso QFD emplea una serie de matrices en un enfoque de varias fases para la planificación
de proyectos. El proceso, que se muestra en la Figura 4.19, utiliza cuatro matrices que
corresponden a cuatro fases del proyecto: planificación del proyecto, diseño del producto,
planificación del proceso y planificación del control del proceso. Las fases (números dentro de un
círculo) son las siguientes.
1. Cree la matriz de la “casa de la calidad” (A). Esta matriz convierte al cliente

necesidades o requisitos en requisitos técnicos.
2. Desarrollar una versión inicial del plan del proyecto basado en los requisitos de calidad
de la casa. La matriz de la casa no tiene que ser completada; Comience con un plan
rudimentario utilizando la información disponible en la matriz de la casa, luego amplíe el
plan a medida que surjan nuevos requisitos en la versión actualizada.
matriz.
3. Cree la matriz de diseño (B). Esta matriz convierte los requisitos técnicos de la matriz de
la casa en características y requisitos de diseño del producto.
4. Cree la matriz de proceso (C). Esta matriz convierte las características y requisitos de
diseño de la matriz de diseño en pasos de proceso o requisitos de producción.
5. Cree la matriz de control (D). Esta matriz convierte los pasos del proceso o los requisitos
de producción de la matriz del proceso en procedimientos de seguimiento y control del
proceso.
6. Refinar el plan del proyecto para incorporar aspectos del diseño, proceso y
matrices de control.
Las matrices resaltan la información necesaria para tomar decisiones sobre la definición, el
diseño, la producción y la entrega del producto, y vinculan los requisitos de trabajo en las cuatro
fases para que las necesidades del cliente y los requisitos técnicos, tal como se definen al
principio del proceso, se traduzcan sin distorsiones en características de diseño. y requisitos de
producción. Como se muestra en la Figura 4.19, el enlace se produce tomando los requisitos o
pasos de la parte superior de una matriz y colocándolos en el lado izquierdo de la matriz en la
siguiente fase. Esta vinculación de matrices garantiza la trazabilidad (otra vez esa palabra): que
cualquier actividad del proyecto pueda rastrearse hasta la necesidad o requisito del cliente que
cumple y, a la inversa, que cada necesidad y requisito del cliente pueda rastrearse hasta las
actividades necesarias del proyecto. Dicho de otra manera, QFD garantiza que cada actividad
cumpla con un requisito y que cada requisito sea atendido por al menos una actividad. El
resultado es un plan donde cada tarea a lo largo del proyecto se integra con los requisitos
técnicos enumerados en la matriz original de la casa. El siguiente capítulo describe otros
aspectos de un plan de proyecto integrado.
Figura 4.19 Enfoque QFD multifase, multimatriz.
El tiempo adicional requerido por el proceso QFD para producir un plan de proyecto y un
diseño de producto inicial se compensa con el tiempo reducido para producir el diseño final
porque se necesitan menos rediseños y menos cambios de ingeniería después de que el
producto entra en producción.
Ejemplo A4.11: Desarrollo de Chrysler de la línea de

automóviles
18 LH
Chrysler aplicó por primera vez QFD en el diseño y desarrollo de sus autos con plataforma
LH (Chrysler Concorde y Dodge Intrepid). Al principio de la etapa de concepto del
producto, se formó un equipo de programa para establecer las pautas generales de
diseño. El equipo del programa asignó la responsabilidad de los diferentes principales automóviles
sistemas a diferentes grupos de diseño (al igual que Boeing en sus equipos), y cada grupo
estableció un equipo QFD para determinar los requisitos a nivel del sistema. Una vez que
se establecieron los requisitos, se formaron grupos más pequeños para enfocarse en
diseñar los componentes dentro del sistema.
La metodología QFD fue parte de un esfuerzo de ingeniería concurrente más amplio
que arrojó resultados impresionantes: el ciclo de diseño total de LH tomó 36 meses en
comparación con los 54 a 62 meses históricos; los autos prototipo estuvieron listos 95
semanas antes del lanzamiento de la producción frente a las 60 semanas tradicionales; y
el programa requirió 740 personas en comparación con las 1.600 personas habituales.
Los autos recibieron numerosos premios y menciones de revistas por su excelencia en el diseño.
1. ¿Cuándo se involucra el director del proyecto en el proyecto?

2. ¿Cuál es el propósito de la reunión inicial? ¿Cuándo se celebra la reunión y quién la dirige?
3. ¿Cómo se crea el equipo del proyecto?

4. Describa brevemente el contenido de un plan de ejecución del proyecto.
5. Describa la planificación del proyecto por etapas.
6. ¿Cuáles son los requisitos del usuario, los requisitos del sistema y las especificaciones del
sistema? Dar ejemplos. ¿Como están relacionados?
7. ¿Qué son los requisitos funcionales? ¿Qué son los requisitos de rendimiento?
Dar ejemplos.
8. ¿Qué son los “requisitos no funcionales”? Dar ejemplos.
9. Describa el proceso de desarrollo de los requisitos del usuario y del sistema.
especificaciones.
10. ¿Qué problemas están asociados con la definición de requisitos? ¿Cuáles son las formas de
minimizar estos problemas?
11. ¿Cuál es el propósito de especificar prioridades y márgenes en la definición de requisitos?
12. Describa la ingeniería concurrente.

13. Describa las etapas de la ingeniería de sistemas en la figura 4.8. Piense en algunos proyectos
y describa las etapas de la ingeniería de sistemas en estos proyectos.
14. Distinguir los siguientes: requisitos funcionales, requisitos de desempeño y requisitos de
verificación. Dé un ejemplo de un requisito funcional y sus requisitos de desempeño y
verificación asociados.
15. ¿Qué significa el término “trazabilidad”?

16. Piense en un sistema simple como una trampa para ratones, un dispensador de cinta adhesiva o un abrelatas.
Dibuje un diagrama de bloques de flujo funcional simple de alto nivel para ello. Si es posible,
descomponga cada una de las funciones en subfunciones.
17. Defina brevemente el propósito del despliegue de la función de calidad (QFD).
18. ¿Cuál es el origen de las necesidades o requerimientos del cliente que aparecen en el
casa de calidad?
19. Piense en lo siguiente o use cualquier material de investigación del consumidor

disponible para definir las necesidades o requisitos del cliente para lo siguiente:
una. Un “buen” curso

universitario. b. Tostadora (u otro electrodoméstico de su
elección). C. Telefono celular. d. Taza de café para tu coche.
Para cada uno, defina un conjunto correspondiente de características físicas o

técnicas. Utilizando el formato de la Figura 4.20 , construya una matriz de casa de
calidad y muestre la relación entre las características técnicas y los requisitos del
cliente. Utilice la matriz en cada caso para “diseñar” o sugerir cómo sería o se
vería el producto o servicio ideal.
20. ¿Cuál es el propósito del acta de constitución del proyecto? Qué está incluido en el
¿carta?
21. ¿A qué situaciones se aplica la gestión ágil de proyectos? ¿En qué se diferencia
Agile de “cascada”?
Figura 4.20 Matriz QFD para la Pregunta 19.

1. ¿Tuvo el proyecto una reunión inicial? ¿Que paso ahi?

2. ¿Cómo se involucró el director del proyecto en el proyecto? ¿Fue seleccionada
como gerente de proyecto antes o después de que se completara la propuesta?
3. ¿Cómo se formó el equipo del proyecto?
4. ¿Había requisitos de los usuarios? ¿Cómo se definieron? ¿Eran requisitos “bien
definidos”?
5. ¿Había algún requisito del sistema? ¿Fueron claros y utilizados por el equipo del
proyecto?
6. ¿Hubo especificaciones del sistema y requisitos de rendimiento? Si no, ¿cómo supo
el equipo del proyecto lo que se requería del artículo final?
7. ¿El proyecto tenía un plan de ejecución del proyecto? En caso afirmativo, describa
el contenido. Si no, ¿cómo supo el equipo lo que se suponía que debían hacer
(tareas, horarios, responsabilidades, etc.)?
8. Describa el proceso de creación del plan del proyecto.
9. ¿Participaron diferentes partes interesadas en la definición de los requisitos y
crear el plan del proyecto?
10. ¿Se usó QFD o un proceso similar para definir los requisitos y/o crear el plan del
proyecto?
11. ¿Cuál es su impresión general sobre qué tan bien se llevó a cabo la fase de
definición en el proyecto y sobre la calidad de los requisitos del sistema y el plan
del proyecto?
Caso 4.1 Star-Board Construction y Santaro

Associates: Requisitos SNAFU
Star-Board Construction (SBC) es el contratista principal de un gran proyecto de

rascacielos en el centro de Manhattan. SBC está trabajando directamente desde dibujos
recibido del arquitecto, Santaro Associates (SA). Robert Santaro, propietario y

arquitecto jefe de SA, vio este edificio como similar a otros que había diseñado. Sin
embargo, una diferencia entre este edificio y los demás que pasó por alto fue el frente
del edificio, que consistía en grandes losas de granito, losas mucho más grandes que
cualquier cosa con la que él o SBC tuvieran experiencia previa.
A la mitad del proyecto, Kent Star, gerente de proyectos de SBC, comenzó a recibir
informes del superintendente de su sitio sobre problemas recurrentes con la instalación
de ventanas. Las ventanas son unidades prefabricadas según especificaciones de SA.
El revestimiento de granito del edificio debía instalarse de acuerdo con especificaciones
que permitieran variaciones dimensionales en las unidades de ventana. El arquitecto
proporcionó la especificación de que la tolerancia para cada espacio de la ventana
debe ser de 1/2 pulgada (es decir, el espacio de la ventana entre las losas de granito
puede variar tanto como 1/4 de pulgada más grande o más pequeño que el valor
especificado). Esto creó un problema para el equipo de construcción, que encontró
que las losas de granito eran demasiado grandes para instalarlas con tanta precisión.
Como resultado, el espacio entre las losas suele ser demasiado pequeño, lo que
dificulta o imposibilita la instalación de unidades de ventana. La mayoría de las 2000
unidades de ventanas para el edificio ya se han fabricado, por lo que es demasiado
tarde para cambiar sus especificaciones, y la mayoría de las losas de granito se han colgado en el edific
El único recurso para instalar unidades de ventana en espacios reducidos es moler el
granito. Va a ser muy costoso y ciertamente retrasará la finalización del edificio.
Pregunta
¿Qué pasos o acciones deberían haber tomado el arquitecto y el contratista antes de

comprometerse con las especificaciones de las unidades de ventana y el espacio entre las
losas de granito que habrían evitado este problema?
Caso 4.2 Revcon Products y Welbar, Inc.:

comunicación cliente-contratista
Revcon Products fabrica válvulas para controlar el nivel de agua en tanques industriales. Se
había concentrado en productos para la industria de la construcción (válvulas para tanques
recién instalados), pero ahora quiere ingresar al mercado de reemplazo mucho más grande
y lucrativo. Mientras que la demanda anual de válvulas nuevas es de alrededor de 100.000,
es de alrededor de 1 millón para válvulas de reemplazo. La compañía imaginó una nueva
válvula, la válvula Millennium, como una forma de obtener una participación en el mercado
de reemplazo de válvulas de tanque. El objetivo de Revcon era diseñar y producir la válvula
Millennium para que tuviera una calidad superior y un costo más bajo que la competencia.
Revcon decidió subcontratar el desarrollo y diseño de la nueva válvula. Elaboró una RFP con
los siguientes objetivos y requisitos:
Objetivos del producto:
• Diseño innovador para distinguir la válvula Millennium de las válvulas de la

competencia. • Precio competitivo pero ofrece mayor valor.
Requisitos del mercado (usuario):

• Facilidad de instalación
• No obstruye •
Funcionamiento
silencioso • Facilidad de ajuste del
nivel de agua • Altura ajustable.
Revcon envió la RFP a cuatro empresas de diseño y seleccionó a Welbar, Inc., principalmente
por ser el postor con la oferta más baja. La propuesta de Welbar fue redactada por sus
departamentos de ventas y marketing y revisada por la alta gerencia, pero sin aportes de
diseñadores industriales, ingenieros o cualquier otra persona que trabajaría en el proyecto.
Welbar no tenía experiencia previa con válvulas de agua industriales, pero su equipo de ventas
vio a Millennium como una oportunidad para obtener ganancias y alinearse con un importante
fabricante de equipos. El departamento de marketing preparó estimaciones de tiempo y costo
utilizando tareas estándar y paquetes de trabajo de propuestas para proyectos antiguos.
El equipo de diseño de Welbar para el proyecto Millennium Valve estuvo encabezado por
Karl Fitch, un ingeniero experimentado, e incluyó dos diseñadores industriales y dos ingenieros.
Su primera tarea fue investigar el mercado de válvulas y hablar con contratistas, plomeros y
minoristas. Karl revisó la propuesta de Welbar y concluyó que había omitido varios pasos
críticos y que su costo estaba sustancialmente subestimado.
Karl dividió el proyecto en pequeños paquetes de trabajo y preparó un diagrama de Gantt.

Durante el proyecto, el concepto de diseño, las tareas de trabajo y el cronograma tuvieron que
cambiarse muchas veces. Los ingenieros de Welbar estaban frustrados por la insistencia
constante de Revcon en que la válvula fuera de bajo precio y tuviera una superioridad funcional,
y que el proyecto fuera rápido y de bajo costo. Durante el proyecto, los ingenieros de Welbar
aprendieron que diseñar una válvula de este tipo requería más recursos de los presupuestados.
Debido a todos los cambios, Welbar excedió el presupuesto y tuvo que solicitar fondos
adicionales de Revcon cuatro veces. Se produjo un problema importante cuando Welbar entregó
un prototipo a Revcon. Debido a que la descripción del prototipo en la propuesta era vaga,
Revcon esperaba que el prototipo fuera un producto casi terminado, mientras que Welbar lo
entendió como un modelo de trabajo simple para demostrar la funcionalidad. Welbar tuvo que
gastar más tiempo y dinero para traer el
prototipo a la altura de las expectativas de Revcon. Para compensar, Welbar abarrotó

las etapas del proyecto. Cuando la etapa de diseño se retrasó debido al prototipo,
siguió adelante y preparó modelos listos para la producción. El prototipo terminado
demostró más tarde que los modelos de producción no se podían producir.
Finalmente, Welbar diseñó una válvula verdaderamente innovadora; sin embargo,

el diseño requeriría una remodelación sustancial de la fábrica y su producción costaría
un 50 por ciento más de lo esperado. Al final, Revcon invirtió el doble de tiempo y
dinero en desarrollo de lo esperado. Debido a eso, el producto no podía tener un
precio lo suficientemente bajo como para ser competitivo.
Pregunta
¿Qué pasó con este proyecto? ¿Cuáles son los factores que contribuyeron a que Revcon
no obtuviera el producto que deseaba? Para cada factor, discuta lo que podría haberse
hecho de manera diferente.
Caso 4.3 Lavasoft.Com: Interpretación de los

requisitos del cliente
Lavasoft Company está desarrollando un nuevo software de sitio web para un cliente
corporativo. El proyecto comienza cuando algunos miembros del personal de Lavasoft se
reúnen con el cliente para crear una lista de necesidades y requisitos del usuario, que
luego entregan al equipo de diseño de Lavasoft.
La directora del proyecto, Lakshmi Sihgh, siente que el tipo de sistema que mejor se
adapta a las necesidades del usuario es más o menos obvio y, para abordar las
necesidades, crea algunos puntos y diagramas de flujo. Luego los presenta al equipo de
diseño y pregunta si alguien tiene preguntas. A algunas personas les preocupa que el
enfoque establecido en las viñetas y los gráficos sea demasiado vago, pero Lakshmi les
asegura que la vaguedad disminuirá a medida que se definan los detalles del sistema.
Para reducir la interferencia externa, el equipo trabaja relativamente aislado de otros

equipos de desarrollo de la empresa. Diariamente, el equipo se ve obligado a interpretar
las viñetas y los gráficos de alto nivel y a tomar decisiones de diseño. Siempre que hay
desacuerdo sobre la interpretación, Lakshmi toma la decisión. El equipo crea una lista de
especificaciones detalladas del sistema y el proyecto se considera según lo programado.
Sin embargo, al trabajar según las especificaciones, surgen problemas relacionados con
la compatibilidad del sistema.
con el sitio existente del cliente. Además, algunas de las especificaciones requieren
experiencia técnica de la que carece el equipo. Además, en una revisión de las necesidades
originales del usuario, el equipo descubre que algunas especificaciones no están relacionadas
con las necesidades y que para algunas necesidades no hay especificaciones.
El equipo elimina algunas especificaciones y agrega otras nuevas. Esto requiere eliminar
parte del código existente, escribir código nuevo y volver a probar el sistema, lo que retrasa
el proyecto. Crece la resistencia a cambiar aún más las especificaciones, ya que eso
requeriría aún más recodificación y retrasaría aún más el proyecto. Lakshmi agrega personas
para que el proyecto vuelva a estar a tiempo. Finalmente el sistema está listo para su
instalación, aunque lleva 2 meses de retraso. Debido a las personas adicionales agregadas
al personal del proyecto, Lavasoft no obtiene ganancias. Debido a que las especificaciones
eran incorrectas, el sistema no es totalmente compatible con el sitio web del cliente y Lavasoft
debe continuar trabajando en él e introducir "arreglos".
Preguntas
1. ¿Qué salió mal con el proyecto?
2. ¿Dónde se cometieron errores inicialmente en el proyecto?
3. ¿Cómo se permitió que los problemas persistieran y no se corrigieran durante tanto tiempo?
¿largo?
Caso 4.4 Mina de oro propuesta en Canadá: planificación

del proyecto por etapas
12 de julio de 2006: la firma de Peter adquiere los derechos de un yacimiento mineral en la región del
Escudo Canadiense. La firma está considerando desarrollar una nueva mina allí, y Peter es responsable
de proponer un plan de proyecto a la junta directiva en septiembre.
La mina tardará algunos años en alcanzar la plena producción y existe mucha incertidumbre en cuanto al
precio del oro cuando eso suceda. Peter incluye en su propuesta una historia del precio del oro (Figura
4.21).
2 de agosto de 2006: Peter se reúne con Bruce, un ingeniero de minas con 20 años de experiencia en
minas de oro australianas, y con Sam, un geólogo que hace unos años realizó trabajos de exploración en
depósitos de oro en la región del Escudo Canadiense. Discuten hechos conocidos sobre el yacimiento
mineral, la probabilidad de fenómenos geológicos imprevistos que podrían poner en peligro el desarrollo
de la mina, las cifras de producción que podrían lograrse y los costos de producción y los problemas
técnicos que podrían surgir al extraer oro del mineral. Un cálculo rápido muestra que 300 000 onzas de
oro al año a $700 la onza serían muy lucrativas, pero una cifra de 150 000 onzas a $400 la onza, dentro
de 3 años, generaría grandes pérdidas que podrían arruinar a la empresa.

Sin embargo, la información actual sobre el yacimiento es inadecuada y será

necesario perforar pozos de exploración para aprender más sobre la geología
general del área.
Figura 4.21 Precio del oro.
Peter resume: “Hasta donde sabemos, podríamos producir entre 150 000 y 300
000 onzas al año. El costo de capital para desarrollar el pozo será de $150
millones a $260 millones de dólares, y los costos operativos anuales podrían ser
de $60 millones a $100 millones. La exploración para proporcionar información
sobre el cuerpo de mineral requeriría perforar 200 pozos de exploración a un costo
de entre $ 1,2 millones y $ 1,6 millones. Las muestras de roca de estos pozos se
analizarán en un laboratorio para determinar el contenido de oro”.
Peter le indica a Sam que revise los datos de su trabajo de exploración anterior
y que prepare un informe de sus recomendaciones con respecto a la exploración
futura. Está autorizado a gastar no más de $25,000 en este “ejercicio en papel”.
Acuerdan que, si los pozos de exploración arrojan buenos resultados, se perforará
un "pozo de demostración" para sacar una muestra de 30,000 toneladas de mineral.
ser procesado para extraer oro. Los resultados de esta demostración aumentarían
la confianza sobre la cantidad de oro presente, reducirían la incertidumbre sobre
el procesamiento del mineral y proporcionarían una buena indicación de los
rendimientos potenciales. Estiman que el pozo de demostración y el análisis
costarían entre $18 y $25 millones, parte de los cuales, sin embargo, podrían
deducirse del costo de la mina completa, en caso de que siguiera adelante. Solo
si estos resultados son positivos, y el precio del oro es relativamente alto y estable
en esa etapa, se autorizaría el desarrollo completo del eje.
Preguntas
1. Enumere las fases del proyecto e indique el costo mínimo y máximo de cada
fase según lo previsto en agosto de 2006.
2. “Si bien las estimaciones para el futuro distante son muy 'amplias', siempre
es posible hacer estimaciones relativamente precisas para la fase inminente
de un proyecto”. Explique.
3. Describa cómo cada una de las fases del proyecto propuesto ayudará a
reducir el riesgo del proyecto.
4. Comente sobre el problema de que, una vez que se ha asignado el dinero al
proceso, las personas pueden “engancharse” al proyecto y tener la tentación
de seguir adelante a pesar de los altos riesgos.
5. ¿Cómo determinaría el valor de estimaciones precisas para el
cantidad de onzas que se podrían extraer y por costos?
6. ¿Confiaría en alguna tasa interna de retorno o valor presente neto

estimaciones en este momento?
Consulte el Caso 2.4, Proyecto de Coordinación de

Señales y Sistema de Operaciones de Tránsito del
Condado de Santa Clara
Ver Capítulo 2
Pregunta
El grupo INCOSE determinó que una matriz de trazabilidad de requisitos, que no

se usó en el proyecto, podría haber ayudado, si se hubiera usado, en la toma de
decisiones relacionadas con la tecnología durante la construcción y reducido el
número de solicitudes de cambio. Con base en la información limitada
proporcionada en el caso, discuta la aplicabilidad de la matriz de trazabilidad a este proyecto.
Notas finales
1. Para obtener consejos sobre la denominación de proyectos, consulte Gause D. y Weinberg G. Exploring Requirements: Quality Before
Diseño. Nueva York, Nueva York: Dorset House; 1989, págs. 128–134.
2. Plan de estudios APMP, 3.1 ed. Buckinghamshire, Reino Unido: Asociación para la Gestión de Proyectos; 2012.
3. Kay R. Una cartilla de APMP. lul.com autoedición; 2010.
4. Esta sección está adaptada de Merrow E. Industrial Megaprojects. Hoboken, Nueva Jersey: John Wiley; 2011.
5. Consulte Frame JD Gestión de proyectos en organizaciones. San Francisco, CA: Jossey-Bass; 1988, págs. 146–151.
6. Hajek V. Gestión de Proyectos de Ingeniería, 3ª ed. Nueva York, NY: McGraw-Hill; 1984, págs. 35–37;
Whitten N. Gestión de proyectos de desarrollo de software, 2ª ed. Nueva York, NY: John Wiley & Sons; 1995,
págs. 250–255.
7. Connell J. y Shafer L. Prototipado rápido estructurado. Upper Saddle River, Nueva Jersey: Yourdan Press/Prentice
Sala; 1989.
8. Porciones adaptadas de Sabbagh K. Twenty-First Century Jet: The Making and Marketing of the Boeing
777. Nueva York, NY: Scribner; 1996.
9. Fuentes: (1) Falconbridge RI y Ryan M. Gestión de proyectos técnicos complejos: A Systems
Enfoque de ingeniería. Boston, MA: Casa de Artech; 2003, págs. 9 a 93; (2) Blanchard B. y Fabrycky W.
Ingeniería y Análisis de Sistemas. Upper Saddle River, Nueva Jersey: Prentice Hall; 1981, págs. 18 a 52; (3) Castaño H.
Métodos de Ingeniería de Sistemas. Nueva York, NY: John Wiley & Sons; 1967, págs. 1 a 41; (4) Jenkins G. El
Enfoque de sistemas. En Beishon J. y Peters G. (eds), Systems Behavior, 2ª ed. Londres, Reino Unido: Harper &
Fila; 1976, págs. 78–101.
10. Falconbridge y Ryan, Gestión de proyectos técnicos complejos, págs. 29–65.
11. Jenkins, El enfoque de sistemas, pág. 88.
12. Los ejemplos de SpaceShipOne (SS1) en este libro ilustran conceptos. Si bien hay mucho de hecho
información sobre el proyecto disponible de fuentes publicadas, información sobre el diseño real y
El desarrollo de la nave espacial es confidencial. SS1, el X-Prize y las partes interesadas descritas son reales, sin embargo, por falta
de información, partes de este y los ejemplos posteriores son hipotéticos.
La información para este y otros ejemplos de SS1 se extrae de artículos de noticias y del sitio web de SS1 en
Compuestos escalados, www.scaled.com/projects/tierone/index.htm.
13. Adaptado de Falconbridge y Ryan, Managing Complex Technical Projects, págs. 67–96.
14. Chestnut, Métodos de Ingeniería de Sistemas, p. 33.
15. Fuentes para esta sección: Bounds G., Yorks L., Adams M. y Ranney G. Beyond Total Quality
Administración. Nueva York, NY: McGraw-Hill; 1994, págs. 275–282; Hauser J. y Clausing D. La casa de
calidad. Revista de Negocios de Harvard; Mayo–junio de 1988: 63–73.
16. Partes de esta sección adoptadas de Nicholas J. Competitive Manufacturing Management. cresta de rebabas,
IL: Irwin/McGraw-Hill; 1998, págs. 428–434.
17. Véase Bicknell B. y Bicknell K. La hoja de ruta hacia el éxito repetible: uso de QFD para implementar el cambio.
Boca Ratón, FL: CRC Press; 1995, págs. 97–110.
18. Lockamy A. y Khurana A. Despliegue de la función de calidad: un estudio de caso. Producción e Inventario
Revista de gestión 36 (2); 1995: 56–59.

Parte III
Sistemas y Procedimientos de
Planificación y Control
La gestión de proyectos se extiende más allá de definir los objetivos del proyecto y
requisitos; implica formar una organización de proyecto, identificar las tareas necesarias y
los recursos para realizarlas, y proporcionar liderazgo para realizar las tareas. Los objetivos
generales del proyecto y los requisitos del sistema deben articularse en planes, cronogramas
y presupuestos detallados para lograr los objetivos y requisitos. Entonces se necesitan
métodos para asegurarse de que los planes y programas se lleven a cabo según lo previsto.
A lo largo de los años, se ha desarrollado una impresionante colección de métodos para

ayudar a los gerentes de proyectos a definir, planificar y dirigir el trabajo del proyecto. Los
siguientes nueve capítulos describen estos métodos, que incluyen técnicas y procedimientos
para especificar, programar y presupuestar actividades del proyecto, evaluar riesgos,
monitorear y controlar el trabajo, y organizar y mantener registros para lograr los requisitos
de calidad, tiempo y costo del proyecto.
Los procedimientos deben llevarse a cabo dentro de un marco para garantizar que todo
lo que se haga se tenga en cuenta, se organice y se ejecute correctamente. Estos marcos
y las estructuras, actividades y sistemas que los componen (estructuras de desglose del
trabajo, sistemas de contabilidad de costos, sistemas de información y muchos otros) se
describen en esta sección del libro.
Capítulo 5
Técnicas básicas de planificación de proyectos
Las pulgas grandes tienen pulgas más pequeñas en la espalda para morderlas.
Y estas pulgas tienen pulgas más

pequeñas Y así ad infinitum.
-Jonathan Swift
Cada proyecto es algo único porque está dirigido a un producto final o resultado que es de
alguna manera único. Debido a su singularidad, las preguntas básicas sobre el proyecto
deben abordarse y responderse antes de que pueda comenzar el trabajo.
Responder satisfactoriamente a estas preguntas para que el proyecto logre sus objetivos es
la función de la planificación del proyecto.
La gestión de proyectos se puede dividir ampliamente en dos partes: (1) en las fases de
concepción y definición, preparar un plan que especifique los requisitos del proyecto, tareas
de trabajo, responsabilidades, cronogramas y presupuestos; (2) durante la fase de ejecución,
ejecutar el trabajo en el plan y hacer un seguimiento del progreso con respecto al plan. Este
capítulo ofrece una descripción general de la primera parte y cubre los temas del alcance y la
definición del trabajo, la programación elemental y la gestión de adquisiciones.
5.1 Pasos de planificación
Después de recibir una necesidad comercial, una solicitud de contrato o una RFP, la alta dirección
libera fondos para preparar un plan inicial, un cronograma y una estimación de costos para la propuesta
del proyecto. La aprobación del proyecto y la firma del contrato autorizan el inicio del proyecto,
comenzando con la definición de los requisitos del sistema y la preparación de un plan de ejecución
del proyecto. Para proyectos internos, se envía un acta de constitución del proyecto a las partes
interesadas para anunciar y describir el proyecto.
El gerente del proyecto, si aún no está asignado o involucrado, ahora está identificado para
supervisar el proceso de planificación y producir un plan que desarrolle los planes anteriores preparados
para la propuesta, el estudio de caso comercial o la carta.
Debido a que cada proyecto es único, nunca hay una forma establecida a priori sobre cómo se
debe hacer el proyecto. Cada proyecto plantea nuevas preguntas sobre qué, cómo, por quién, en qué
orden, por cuánto y para cuándo, y el propósito de la planificación es responderlas. El proceso de
planificación responde a las preguntas en los siguientes pasos:
1. ¿Cuál es el resultado final deseado?
Definir los objetivos del proyecto, el alcance y los requisitos del sistema. Estos especifican
los entregables del proyecto, los elementos finales y otros resultados buscados, así como los
objetivos de tiempo, costo y desempeño.
2. ¿Cómo se logrará el resultado?
Definir las actividades de trabajo, tareas o trabajos a realizar para lograr los objetivos y
requisitos. Estas actividades incluyen todo lo necesario para crear y entregar el artículo final
o los entregables, incluidas las actividades de planificación, control y administración.
3. ¿Quién lo hará?
Especifique la organización del proyecto: las personas o departamentos, subcontratistas y

gerentes que realizarán y administrarán el trabajo, y especifique sus responsabilidades.
4. ¿Cuándo y en qué orden?
Cree un cronograma que muestre la sincronización de las actividades de trabajo, los plazos y
fechas hito.
5. ¿Cuánto?
Cree un presupuesto y un plan de recursos para financiar y apoyar el proyecto.

6. ¿Qué tan bien?
Especifique un método para rastrear y controlar el trabajo del proyecto, que es necesario
para que el proyecto se ajuste a la programación, el presupuesto y los requisitos del
usuario y del sistema.
Este capítulo y los siguientes siete capítulos analizan estos pasos en detalle.
5.2 El Plan de Ejecución del Proyecto
La planificación del proyecto comienza temprano en el ciclo de vida del proyecto, en la mayoría de los casos con
la preparación de la propuesta. Mientras se prepara la propuesta, se organiza un equipo de proyecto rudimentario,
y el equipo prepara un breve plan resumido para incluirlo en la propuesta. Preparan este plan utilizando los mismos
procedimientos, aunque más abreviados, que se utilizan para desarrollar planes de ejecución de proyectos más
elaborados y detallados. La diferencia entre un plan de resumen de propuesta y un plan de ejecución de proyecto
es que el primero está dirigido al cliente, mientras que el segundo está dirigido al 1 El esfuerzo de planificación en
la preparación de la propuesta está dirigido al equipo del proyecto. estimar la duración del proyecto, el costo y los
el proyecto y el precio
recursos
para que
necesarios.
el clienteEl
pueda
plan tomar
de resumen
una decisión.
de la propuesta incluye la información suficiente sobre
Por el contrario, el plan de ejecución del proyecto establece los detalles del proyecto que servirán como hoja
de ruta para guiar al equipo del proyecto a lo largo de la ejecución del proyecto. Como se mencionó en el Capítulo
4, por lo general el plan contiene detalles solo para la próxima fase inmediata del proyecto, sobre la cual se sabe
más.
Ver Capítulo 4
Los detalles de las fases posteriores del proyecto se completan más adelante a medida que se dispone de más
información.
Contenido de los Planes de Ejecución
El contenido de los planes de ejecución varía según el tamaño, la complejidad y la naturaleza del proyecto. La
Figura 5.1 muestra una plantilla para un plan típico como se describe en el Capítulo 4.
2
Según el cliente y el tipo de contrato del proyecto, el plan puede requerir elementos adicionales
que no se describen aquí; en proyectos pequeños o de bajo costo, es3posible

elementos,
pasarteniendo
por alto algunos
cuidado de los
no pasar
por alto los cruciales. Es una buena práctica revisar cuidadosamente cada elemento de la plantilla, incluso si
solo para verificar que algunos son “N/A” (no aplica). Un plan de ejecución de proyecto de
ejemplo para el proyecto LOGON se encuentra al final del libro en el Apéndice C.
Ver Apéndice C
Es posible que observe similitudes entre las secciones del plan y los contenidos de la
propuesta que se describen en la Figura 3.6. Aunque el formato es diferente, hay similitudes.
A veces, la propuesta, después de la revisión para reflejar actualizaciones, acuerdos y
especificaciones del contrato, se convierte en el plan de ejecución del proyecto. Sin embargo,
con más frecuencia, la propuesta sirve como esquema para el plan de ejecución, y el plan de
ejecución es más amplio que la propuesta. Debido a que la audiencia principal del plan de
ejecución es el equipo del proyecto y no el cliente, las secciones sobre definición de trabajo,
cronograma y presupuesto en el plan son mucho más detalladas que en la propuesta.
Figura 5.1 Plantilla para el Plan de Ejecución del Proyecto.
Como se ilustra en el siguiente ejemplo, a veces el desarrollo del proyecto

El plan de ejecución es un proceso evolutivo y multifuncional.
Ejemplo 5.1: Desarrollo de un plan de proyecto para el

proyecto LOGON en Iron Butterfly Company
Iron Butterfly Company (IBC) es una empresa mediana de ingeniería y

fabricación que se especializa en sistemas de almacenamiento y manejo de
materiales. Compra la mayoría de los subsistemas y componentes para su producto.
sistemas de proveedores y luego los combina para cumplir con los requisitos del cliente.
MPD Company adjudicó a la empresa un gran contrato para un sistema para colocar,
almacenar, recuperar y enrutar contenedores de envío.
El sistema, llamado Logistical Online System, LOGON, se desarrollará e instalará en el
centro de distribución de MPD en Chicago. Iron Butterfly es responsable del diseño,
montaje e instalación del sistema. Dos de sus contratistas, CRC y CreativeRobotics,
proporcionarán los sistemas informáticos y robóticos, además de asistencia con su
instalación y verificación. Frank Wesley es el gerente de proyectos de IBC encargado de
preparar la propuesta.
La mayor parte del plan de ejecución del proyecto para LOGON se originó en la
propuesta de proyecto de IBC. Al preparar la propuesta, los ingenieros de IBC, CRC y
CreativeRobotics trabajaron juntos para diseñar un sistema que cubriera todos los requisitos
de MPD. El diseño incluía esquemas, especificaciones operativas y una lista de materiales.
Los gerentes de diseño de CRC y CreativeRobotics calcularon la experiencia laboral
necesaria y los costos de las piezas y la mano de obra. Frank Wesley y sus ingenieros
prepararon una estructura de desglose del trabajo y estimaciones del tiempo y los costos
de IBC. Luego los combinó con los estimados de CRC y CreativeRobotics para llegar a un
plan general, cronograma y precio para la propuesta.
Después de ganar el contrato, Frank se reunió con su ingeniero de proyecto y los

gerentes de los departamentos de fabricación, software y compras para revisar el diseño,
el plan del proyecto, los costos y los cronogramas, y preparar un plan de ejecución
detallado. Este plan contenía información similar a la propuesta, pero se actualizó y amplió
para incluir cronogramas de materiales y piezas adquiridos, planes para la distribución de
la mano de obra en las tareas de trabajo, una matriz de responsabilidad de tareas, una
EDT detallada y el presupuesto asociado, y un cronograma maestro.
En el proyecto LOGON, el plan de ejecución evolucionó por etapas: se creó inicialmente

durante la preparación de la propuesta, pero luego se amplió y modificó después de la firma del
contrato. En muchos proyectos, sin embargo, particularmente para sistemas grandes y complejos,
la propuesta sirve solo como referencia y la mayor parte de la planificación del proyecto ocurre
después de la firma del contrato (es decir, en la fase de definición). A menudo, la planificación
de proyectos es en sí misma un esfuerzo significativo que requiere mucho tiempo y mano de obra.
Aprendiendo de Proyectos Pasados
A menudo, las organizaciones abordan cada proyecto como demasiado único e ignoran
las lecciones de la historia: los errores, las soluciones y las lecciones aprendidas del pasado.4
Ningún proyecto es totalmente único, por lo que al desarrollar el plan del proyecto tiene
sentido referirse a proyectos similares anteriores, sus planes, procedimientos, éxitos y fracasos.
Idealmente, el director del proyecto cuenta con asistencia de planificación en forma de
lecciones aprendidas, mejores prácticas, metodologías y plantillas sugeridas, e incluso
consultas basadas en la experiencia de proyectos anteriores. En algunos casos, esta
asistencia proviene de la oficina de gestión de proyectos (PMO), descrita en el Capítulo 17.
Las lecciones aprendidas y las mejores prácticas se compilan a partir del resumen posterior
al proyecto o de las autopsias del proyecto de proyectos anteriores; estos son informes
retrospectivos formales creados al final del proyecto que describen lo que salió bien, lo que
salió mal y las lecciones derivadas de la experiencia del proyecto (descrito en el Capítulo 12).
Proporcionan una guía útil para planificar proyectos futuros y ayudan a los gerentes a evitar
reinventar la rueda y repetir errores.
Ver Capítulo 17
Ver Capítulo 12
5.3 Alcance y Declaración de Trabajo
La planificación del proyecto comienza con la definición de los objetivos, entregables y tareas
principales del proyecto; en combinación, estos determinan el tamaño total del proyecto y el
rango o extensión del trabajo que abarca, el concepto de alcance del proyecto.
La determinación del alcance del proyecto ocurre durante la concepción del proyecto, primero
cuando se inicia el proyecto y durante la preparación de la RFP y la propuesta, y nuevamente
durante la definición del proyecto. En cada caso, las necesidades y los requisitos del usuario se
comparan con las limitaciones de tiempo, costo, recursos y tecnología para determinar qué debe
y puede abarcar el proyecto. El proceso de establecer el alcance del proyecto se denomina
definición del alcance.
Definicion del alcance
La definición del alcance implica especificar la amplitud del proyecto y el alcance total de sus
productos, resultados finales o entregables. Los elementos finales definidos que serán producidos
o entregados por el proyecto se denominan "inclusiones", lo que significa que están incluidos en
el proyecto. Para garantizar la claridad, también se definen los elementos, condiciones o
resultados que no se incluirán en el proyecto, es decir, “exclusiones”; por ejemplo, un proyecto
para construir un edificio puede excluir el paisajismo y la decoración interior del edificio. Distinguir
entre inclusiones (responsabilidades del contratista) y exclusiones (posibles responsabilidades
del cliente) evita malentendidos y falsas expectativas.
La definición del alcance se enfoca principalmente en determinar los resultados y los

entregables, no en el tiempo y el costo. Por supuesto, el tiempo y el costo delimitan o dictan los
entregables potenciales; como tales, en la definición del alcance deben considerarse como
“restricciones”.
El resultado de la definición del alcance es una declaración del alcance que describe los
principales entregables del proyecto, los criterios para la aceptación de los entregables, los
supuestos y las restricciones (para brindar una justificación de por qué el proyecto tiene estos
entregables y no otros), las funciones que debe cumplir los entregables, breves antecedentes
sobre el problema que se aborda o la oportunidad que se aprovecha, los objetivos del proyecto, los
requisitos del usuario o las especificaciones de alto nivel, y las tareas del proyecto de alto nivel o las
principales áreas de trabajo. La información de entrada para la definición del alcance incluye un conjunto
de necesidades y requisitos del usuario, un caso comercial u otra expresión de necesidades, y
restricciones y suposiciones; idealmente, los principales subsistemas y componentes del artículo final
habrán sido identificados y también servirán como insumos.
Se indica todo lo que debe incluirse en el proyecto o contrato, incluido el soporte y los elementos
secundarios, así como el trabajo o los entregables que no deben incluirse en el proyecto (exclusiones).
La declaración del alcance a veces también enumera los resultados o las consecuencias que deben
evitarse, como la publicidad negativa, la interferencia con otros sistemas, la contaminación o el daño al
medio ambiente natural. En lugar de repetir los requisitos y especificaciones detallados, la declaración
del alcance normalmente se refiere o incorpora otros documentos que los contienen.
Para un proyecto único, la declaración de alcance preliminar definida durante el inicio del proyecto
puede ser algo vaga; sin embargo, debe ampliarse y aclararse durante la definición del proyecto a medida
que se desarrollan los planes detallados para la primera fase del proyecto. Para los programas, se
desarrollan declaraciones de alcance separadas para el programa general y los proyectos individuales
que componen el programa.
Una vez que se ha aprobado la declaración del alcance, se convierte en un documento controlado
que solo se puede modificar a través de un proceso de cambio formal (Capítulos 9 y 11).
Ejemplo 5.2: Declaración de Alcance del

Proyecto LOGON
La RFP para el proyecto LOGON (consulte el Apéndice A al final de este libro) enviada por Midwest
Parcel Distribution Company (MPD) especifica: “El contratista será responsable de proporcionar
experiencia, mano de obra, materiales, herramientas, supervisión y servicios para la completa
diseño, desarrollo, instalación, verificación y servicios relacionados para la plena capacidad
operativa del sistema LOGON”. También especifica el rendimiento técnico.
requisitos para el sistema, así como las exclusiones del proyecto, es decir, "La eliminación
del equipo de almacenamiento, colocación y recuperación existente se realizará bajo un
contrato por separado".
Al recibir la RFP, Iron Butterfly Company (IBC), uno de los contratistas que la
propusieron, decidió que la mejor manera de satisfacer las necesidades de MPD era con
un sistema que emplea unidades transportadoras robóticas para colocar y recuperar
contenedores según las instrucciones de un sistema de red neuronal. IBC analizó los
requisitos técnicos y presupuestarios de MPD y, después de un esfuerzo preliminar de
diseño del sistema, creó la siguiente declaración de alcance para su propuesta LOGON:
1. Antecedentes del proyecto: una breve descripción de las instalaciones de

distribución de MPD en Chicago y del propósito y los objetivos del sistema LOGON.
2. Descripción del trabajo a realizar: diseño, fabricación, instalación, prueba y

verificación de un sistema de transporte, almacenamiento y base de datos para la
colocación, almacenamiento y recuperación automática de contenedores de envío
estandarizados.
3. Entregables y principales áreas de trabajo:
una. Sistema general: crea un diseño básico. Requisitos de referencia

A y B.
b. Racks y sistema de cangilones de almacenamiento (denominado

“Hardware A”): desarrollar un diseño detallado. El sistema de cubos de
almacenamiento es el Modelo IBS05 adaptado a los requisitos C.1 a
E.14. C. Unidades transportadoras robóticas y sistema de seguimiento
(denominado “Hardware B”): desarrollar un diseño detallado. RBU es el
modelo IBR04 modificado para cumplir con los requisitos F.1 a G.13. d.
Sistema de red neuronal, base de datos y controlador robótico: desarrollo
de especificaciones de software. Consulte los requisitos H.1 a H.9 y K.3.
mi. Hardware A y Hardware B: adquisición de software, subensamblajes y

componentes. Requisitos de referencia K.1 a L.9.
F. Hardware A y Hardware B: fabricar en el sitio de IBC. Referencia

requisito m
gramo. Sistema general: instalación y verificación en el sitio de MPD. Requisito
de referencia Y.
Los elementos (a) a (g) anteriores representan entregables para diferentes etapas del proyecto;
asociados con cada uno hay requisitos específicos (es decir, "requisitos de referencia")
enumerados en documentos separados adjuntos a la declaración de alcance. Por ejemplo, los
diseños detallados señalados en los puntos 3(b) y 3(c) incluyen una referencia a los requisitos
C.1 a E.14 y F.1 a G.13.
Los requisitos deben ser lo suficientemente completos para permitir que los subcontratistas
produzcan los sistemas y componentes especificados. En otros lugares, la declaración del
alcance enumera las exclusiones del proyecto como se indica en la RFP o identificada por IBC.
La declaración del alcance es el documento de referencia para todos los interesados en el proyecto;
se convierte en la base para tomar decisiones sobre los recursos necesarios para el proyecto y, más
adelante, determinar si los cambios requeridos o solicitados en las tareas de trabajo y los entregables
se encuentran dentro del alcance del proyecto acordado. Una tendencia común en los proyectos es el
aumento del alcance, lo que significa que el proyecto sigue creciendo debido a los cambios en la
cantidad y/o el tamaño de los entregables. El desplazamiento del alcance, si no se controla, puede
conducir a presupuestos y cronogramas de proyectos fuera de control.
La declaración del alcance aparece en muchos lugares: propuestas de proyectos, estatutos y
planes A menudo, la declaración de alcance se incorpora a la declaración de trabajo.
Declaración de trabajo
La declaración de trabajo es una descripción del proyecto; incluye una declaración de alcance, pero a
menudo va mucho más allá. Describe, por ejemplo: especificaciones y requisitos de entrega;
cronogramas de entrega; procedimientos de gestión para la comunicación, planificación y manejo de
riesgos y cambios; presupuesto del proyecto; y personal clave responsable de tareas administrativas
y laborales. Como tal, el SOW es efectivamente una versión de alto nivel del plan de ejecución del
proyecto.
El término SOW y su uso se asocian comúnmente con contratos
proyectos, y el SOW aparece en los documentos asociados con el proceso de contratación o

adquisición. La RFP, la propuesta, el contrato y el plan de ejecución del proyecto contienen
SOW, cada una de las cuales es una versión actualizada, ampliada o más refinada del SOW
del documento anterior. El acta de constitución del proyecto descrita en el Capítulo 4 también
podría contener un SOW.
5.4 Definición de trabajo
Una vez que se han establecido los objetivos y entregables del proyecto en la declaración del alcance,
el siguiente paso es traducirlos en actividades de trabajo específicas y bien definidas; es decir, especificar
las tareas y trabajos que debe realizar el equipo del proyecto. Particularmente para proyectos grandes y
únicos, es fácil pasar por alto o duplicar actividades. Para asegurar que cada actividad necesaria se
identifique y defina claramente, y que no se pierda ninguna actividad, se utiliza un procedimiento
denominado "estructura de descomposición del trabajo".
Estructura de desglose del trabajo
Los proyectos complejos constan de numerosos subproyectos más pequeños, tareas interrelacionadas
y elementos de trabajo. Como alude la rima al comienzo del capítulo, el principal resultado final o
entregable de un proyecto puede considerarse como un sistema que consiste en subsistemas, que a su
vez consisten en componentes, y así sucesivamente. El método para subdividir el proyecto general en
elementos más pequeños se denomina estructura de descomposición del trabajo o EDT, y su propósito
es dividir el proyecto total en "piezas de trabajo" denominadas paquetes de trabajo. Dividir el proyecto
en paquetes de trabajo ayuda a preparar cronogramas y presupuestos y a asignar responsabilidades de
gestión y tareas.
La creación de una WBS comienza con la división del proyecto total en categorías principales.
Estas categorías luego se dividen en subcategorías que, a su vez, se subdividen cada una. Con este
desglose nivel por nivel, el alcance y la complejidad de los elementos de trabajo en cada nivel del
desglose se reducen. El objetivo es reducir el proyecto a muchos elementos de trabajo pequeños, cada
uno tan claramente definido que el proyecto se puede planificar, presupuestar, programar y monitorear
fácilmente.
Una EDT típica consta de los siguientes cuatro niveles:
Nivel Descripción del elemento

1 Proyecto
2 subproyecto
3 Paquete de trabajo
4 Actividad
El nivel 1 es el proyecto total. El nivel 2 es el proyecto dividido en varios elementos principales o subproyectos
(generalmente de cuatro a diez). Estos subproyectos deben ajustarse a los entregables o áreas de trabajo
especificados en la declaración del alcance, y todos ellos, cuando se combinan, deben comprender el alcance
total del proyecto. Cada subproyecto se desglosa en actividades en el Nivel 3. Si es necesario un desglose
adicional, se realiza en el Nivel 4. Cuando el proyecto es parte de un programa, se agrega un quinto nivel en
la parte superior y los niveles se vuelven a numerar: Nivel 1 es el programa, Nivel 2 el proyecto, y así
sucesivamente.
Cuando se completa el proceso, las tareas en los niveles inferiores, cualquiera que sean los niveles, se
denominan paquetes de trabajo. En la tabla anterior, el término "paquete de trabajo" aparece en el Nivel 3,
pero eso es solo para ilustración. Más adelante en el proceso de planificación, los paquetes de trabajo más
grandes pueden subdividirse en actividades o tareas más detalladas,
El número real de niveles en la EDT varía según el proyecto, al igual que los nombres reales de las
descripciones de los elementos en cada nivel. (El nivel y los nombres a menudo son prescritos por la
metodología del proyecto en uso). La Figura 5.2 muestra una EDT típica.
Tenga en cuenta los diferentes niveles y descripciones para cada elemento de trabajo.
Figura 5.2 Elementos de una EDT.
El proceso de la EDT ocurre de forma algo natural, comenzando con la lista de requisitos del usuario y del sistema.
Estos requisitos sugieren el sistema principal, el elemento final o los entregables del proyecto y los principales subsistemas
y componentes; también sugieren cuáles de estos resultados se cumplirán externamente (por proveedores/subcontratistas)
y cuáles internamente. Estos subsistemas y componentes principales son recuadros en la EDT. Esas cajas luego se
subdividen lógicamente en componentes más pequeños del sistema y las tareas de trabajo para crearlos o adquirirlos.
Para proyectos técnicos y de ingeniería, la EDT debe incluir todos los elementos de configuración (CI) y los componentes
principales del sistema, así como las tareas de trabajo para diseñarlos, desarrollarlos, construirlos y probarlos. 5
La EDT se convierte en la base para la asignación de la responsabilidad del proyecto y la

contratación. Para el trabajo contratado, la responsabilidad de cada subproyecto o actividad se
asigna a un subcontratista a través de un acuerdo de contrato entre el subcontratista y el director
del proyecto. Para proyectos internos, la responsabilidad de cada subproyecto o actividad se
asigna a un departamento interno, a través de un acuerdo formal entre el director del departamento
y el director del proyecto.
Para evitar una complejidad innecesaria, se debe limitar el número de niveles en la EDT. Una
EDT de cinco niveles puede ser apropiada para proyectos grandes, pero para la mayoría de los
proyectos pequeños es adecuada una EDT de tres niveles. Para ayudar a organizar y rastrear las
actividades del proyecto, cada elemento de trabajo está codificado con un identificador o número único.
Por lo general, el número de cada nivel se basa en el número del siguiente nivel superior.
En la Figura 5.2 , el Proyecto “01” tiene seis categorías numeradas del 01–01 al 01–06; entonces,
por ejemplo, la categoría 01–06 tiene siete tareas numeradas del 01–06–100 al 01–06–700. El
director del proyecto establece el esquema de numeración.
La Figura 5.3 ilustra formas de crear la WBS para construir una casa. La parte superior de la
figura muestra el elemento final principal del proyecto (Nivel 1) y las principales categorías de
trabajo (Nivel 2) necesarias para construirlo. En su mayor parte, los elementos del Nivel 2 son
piezas físicas o componentes de la casa. En otras palabras, identifican los entregables o productos
a producir. Esto se denomina EDT orientada al producto. Al subdividir un proyecto de esta manera,
de acuerdo con los productos físicos o entregables, es fácil adjuntar requisitos de rendimiento,
costo y tiempo a cada elemento y asignar la responsabilidad de cumplirlos. Eso es,
crear una WBS de esta manera ayuda a preparar otras partes del plan, incluido el
presupuesto y el cronograma del proyecto. La parte inferior de la Figura 5.3 muestra cómo
la WBS orientada al producto se subdividiría en cuatro niveles.
Figura 5.3 Ejemplo de una EDT para la construcción de una casa.
A veces, la WBS o partes de ella están orientadas a la función o a la tarea (en lugar de
estar orientadas al producto). Por ejemplo, la parte central de la Figura 5.3 muestra el
proyecto subdividido según las funciones de trabajo (por ejemplo, carpintería y plomería),
no los entregables. Las funciones o tareas tales como administración y gastos generales,
diseño, ingeniería, capacitación e inspección que se aplican a múltiples entregables oa la
integración de múltiples entregables deben identificarse como paquetes de trabajo separados.
Si la WBS utiliza productos, funcionales, geográficos, basados en tareas u otros
el desglose es una cuestión de preferencia, o está estipulado por la metodología de proyecto de

la organización o las plantillas WBS.
Durante el proceso de la EDT, las preguntas "¿Qué más se necesita?" y "¿Qué sigue?"
constantemente se les pregunta. Los elementos complementarios o perdidos se identifican y se
agregan a la WBS en los niveles apropiados. Por ejemplo, la EDT de la Figura 5.3 no incluye
planos, presupuestos ni cronogramas de trabajo, aunque la casa no se puede construir sin ellos.
Estos son entregables asociados con la planificación del proyecto y el diseño de la casa, que
podrían incluirse en la EDT ampliando el Nivel 2 e insertando categorías para "Diseño" y
"Gestión del proyecto", y luego en el Nivel 3 insertando "planos" en Diseño y “presupuesto y
cronogramas de trabajo” en Gestión de Proyectos, respectivamente.
En algún lugar de la WBS, también se deben incluir consideraciones tales como la ubicación
del sitio, permisos y licencias, impactos ambientales, etc. Como se describe más adelante, la
WBS también debe reflejar cualquier bien, material o producto adquirido (contratado, subcontratado).
servicios.
Figura 5.4 WBS para proyecto de nave espacial.
El concepto de trazabilidad, mencionado en el Capítulo 4, también se aplica a la EDT.

Una prueba de integridad de la EDT es comparar la lista de objetivos del proyecto y los
requisitos de alto nivel con los paquetes de trabajo de la EDT. Cada objetivo y requisito
debe ser rastreable a por lo menos un paquete de trabajo. Si un objetivo o requisito no se
puede rastrear hasta un paquete de trabajo, es probable que no se cumpla.
Lo contrario también se aplica: cada paquete de trabajo debe ser rastreable al menos a
un objetivo o requisito de alto nivel. Si no puede ser, la pregunta es, ¿por qué está ahí?
Ver Capítulo 4
La Figura 5.4 ejemplifica la WBS para un gran proyecto de ingeniería donde el principal
entregable y muchos de sus subsistemas y componentes deben desarrollarse, construirse,

integrarse y probarse desde cero. Tenga en cuenta que algunas partes están orientadas al producto
(vehículo, instalaciones), mientras que otras están orientadas a la función (prueba/evaluación,
gestión de proyectos/ingeniería de sistemas).
Cuanto más grande y menos estandarizado sea el proyecto, más fácil será pasar algo por alto y
más valioso será el proceso de la EDT para evitarlo. En proyectos grandes, la EDT inicial suele ser
bastante tosca y muestra solo los principales productos o funciones de trabajo y los aspectos de
cada uno que se asignarán a contratistas específicos.
Sin embargo, antes de que comience el trabajo, los detalles de cada producto o función deben
desarrollarse más completamente en la EDT.
Ejemplo 5.3: Proceso de Desarrollo de la EDT

para el Proyecto LOGON
El director del proyecto y el personal se reúnen varias veces en sesiones de intercambio de

ideas para crear la WBS para LOGON, primero durante la preparación de la propuesta para
clasificar los entregables clave y definir el alcance del proyecto, luego durante la definición
del proyecto para actualizar la WBS y desglosar los paquetes de trabajo con mayor detalle.
En la primera reunión, "desglosan" las principales categorías de trabajo y entregables en el
desglose del Nivel 2 del SOW (descrito en el Ejemplo 5.2) y los requisitos, e identifican las
áreas funcionales responsables.
Después de la firma del contrato, el gerente del proyecto se reúne con los gerentes de las
áreas funcionales que contribuirán a los entregables en el desglose del Nivel 2. Estos
gerentes luego se reúnen con sus supervisores y personal técnico para preparar un desglose
de Nivel 3. Cuando sea necesario, los supervisores preparan un desglose de Nivel 4.
La Figura 5.5 muestra una EDT que está parcialmente orientada a funciones (diseño
básico, adquisición, etc.) y parcialmente orientada a productos (Hardware Parte A, Hardware
Parte B, software, etc.). Cuando fue necesario, los artículos de nivel 2 se han subdividido en
artículos de nivel 3 y los artículos de nivel 3 en artículos de nivel 4. Los cuadros en la parte
inferior de las ramas son "paquetes de trabajo", indicados por letras entre paréntesis. Observe
que los paquetes de trabajo están en diferentes niveles de la EDT; esto se debe a que cada
rama de la EDT se desarrolla por separado.
Figura 5.5 Estructura de descomposición del trabajo para el proyecto LOGON. Los paquetes de trabajo tienen letras de la H a la
Paquetes de trabajo
¿Hasta dónde llega el desglose? Simplemente, en la medida de lo necesario para definir

completamente todo el trabajo necesario para el proyecto. El trabajo en cada “casilla” o elemento
de la EDT debe estar “bien definido”; si no es así, la caja debe subdividirse en cajas más pequeñas.
Para que una caja esté “bien definida”, debe incluir lo siguiente:
1. SOW integral: tarea o actividad de trabajo a realizar.

2. Requerimientos de recursos: mano de obra, equipo, instalaciones y materiales necesarios
para la tarea
3. Tiempo: tiempo estimado para realizar la tarea.
4. Costos: recurso estimado, gestión y gastos relacionados con la tarea.
5. Responsabilidad: partes, individuos o puestos de trabajo responsables de hacer
y/o aprobar la tarea.

6. Resultados: requisitos, especificaciones y entregables asociados, final
elementos o resultados de la tarea.
7. Entradas: condiciones previas o previas necesarias para comenzar la tarea.
8. Garantía de calidad: condiciones de entrada, proceso y salida a las que debe ajustarse la
tarea; como se especifica en el plan de calidad.
9. Riesgo. incertidumbres sobre el tiempo, el costo y los recursos asociados con la
tarea.
10. Otros: información adicional según sea necesario.
Estas propiedades se resumen en la figura 5.6. Si alguno de ellos no se puede definir para un cuadro
determinado, entonces la tarea o el producto en el cuadro es demasiado amplio y debe desglosarse
aún más. Cuando todas o la mayoría de las propiedades se pueden definir para un cuadro o elemento,
el elemento se considera "bien definido" y, por definición, un paquete de trabajo.
Figura 5.6 Propiedades de un paquete de trabajo.
Pero el nivel de interrupción del trabajo no debe continuar hasta el punto de resultar en un
número innecesariamente grande de paquetes de trabajo. Durante el proyecto, cada paquete de trabajo
se convierte en el punto focal para la planificación y el control y, como tal, implica papeleo, cronogramas,
presupuestos, etc. Por lo tanto, cuantos más paquetes de trabajo, más tiempo y costo se necesitan
para administrarlos.
Plantillas de EDT
Una empresa que rutinariamente realiza tipos de proyectos similares podría utilizar una "plantilla"
estandarizada de WBS en el Nivel 2 o Nivel 3. La plantilla se basa en la experiencia de haber realizado
muchos de esos tipos de proyectos. En algunas empresas, la oficina de gestión de proyectos (PMO)
crea y mantiene la plantilla.
Sin embargo, incluso con una plantilla, es bueno recordar que cada proyecto es algo único y que tal
singularidad puede no ser evidente hasta el Nivel 3 o 4. Por lo tanto, la WBS para un proyecto nunca
debe ser una mera plantilla o una copia completa de la WBS de otro proyecto, sin importar cuán
similares puedan parecer los proyectos. En ninguna parte es más apropiado el dicho “el diablo está en
los detalles” que en los proyectos, y la WBS es la herramienta para identificar los detalles en los que el
diablo podría estar escondido. Para reducir los descuidos, es una buena práctica tener dos o más
equipos, cada uno de los cuales crea una EDT y luego combinarlos en uno.
Idealmente, los paquetes de trabajo representan trabajos de aproximadamente la misma magnitud

de esfuerzo y de costo relativamente pequeño y de corta duración en comparación con el proyecto
total. Por ejemplo, las pautas del DOD/NASA especifican que los paquetes de trabajo deben tener una
duración máxima de 3 meses y no exceder el costo de $100,000. Estas son simplemente pautas. El
costo y la duración del paquete de trabajo pueden depender de muchos factores, como el tamaño del
proyecto (los proyectos más pequeños tienen paquetes de trabajo más pequeños).
Cada paquete de trabajo representa un contrato o acuerdo con un subcontratista, proveedor o
unidad funcional interna. Aunque varias unidades funcionales o subcontratadas pueden compartir la
responsabilidad de un paquete de trabajo, lo ideal es que un paquete de trabajo tenga solo una parte
responsable.
Ejemplo 5.4: Definición de paquete de trabajo para el

proyecto LOGON
El proyecto LOGON se dividió en 19 paquetes de trabajo: los recuadros con letras de la H a la Z

en la Figura 5.5. A continuación se muestra un ejemplo de las propiedades de un paquete de
trabajo típico, Paquete de trabajo X: prueba de hardware. Observe cómo las propiedades
definidas corresponden a las enumeradas en la Figura 5.6.
1. Declaración de trabajo: realizar verificación, prueba operativa y correcciones según

sea necesario para la aprobación de la firma de cuatro Batman
unidades transportadoras, Modelo IBR04.
2. Requerimientos de recursos: mano de obra (compromiso FT, 3 semanas): prueba

gerente, dos ingenieros de prueba, tres técnicos.
Materiales adquiridos: pista para maqueta; todos los demás materiales en
mano.
Instalación: sala de pruebas número 2 en Iron Butterfly durante 3 semanas.

3. Tiempo: 3 semanas programadas; (tiempo crítico) comienza el 2 de diciembre; finalizar
23 de diciembre.
4. Costos (Cuenta de control RX0522):
Mano de obra:
Gerente, 75hrs + 25% OH = $9,750
Ingenieros, 1125 hrs + 25% OH = $135,000
Técnicos, 1125 hrs + 25% OH = $112,500

Material: $70,000
Total parcial $327,250
10% gastos generales y administrativos

$32,725
Total $359,975
5. Responsabilidad: supervisar las pruebas: BJ, gerente de ensamblaje robótico.

Aprobar los resultados de las pruebas: OB, gerente del Departamento de Fabricación.
Notificar estado de prueba y resultados: JM, ingeniero de proyecto; FWN, sitio
operaciones.
6. Entregables: cuatro robots Batman probados y aprobados
transportadores, Modelo IBR04. Consulte las especificaciones.
7. Entradas: predecesor: montaje del transportador robótico de Batman (trabajo
paquete V). Condiciones previas: configuración de la sala de pruebas para el transportador robótico.
8. Garantía de calidad: consulte las condiciones de entrada, proceso y salida para

paquete de trabajo X en el plan de calidad LOGON.
9. Riesgo: RBU fallará en los requisitos de prueba debido a
problemas/errores de montaje/integración. Probabilidad: baja. Contingencia
reserva: semana adicional incluida en el horario.
10. Especificaciones: consulte el documento de prueba 2307 y el contrato LOGON

hojas de especificaciones 28 y 41.
11. Órdenes de trabajo: ninguna, pendiente.

12. Subcontratos/órdenes de compra: sin subcontratos; PO 8967–8987 para
pruebas de seguimiento
Un paquete de trabajo que produce un producto físico o entregable tangible como en el ejemplo debe incluir
fechas específicas de inicio y finalización para el paquete de trabajo.
Proceso WBS y el Plan Integrado del Proyecto
En un plan de proyecto integrado, los elementos del plan (requisitos, tareas de trabajo, cronogramas,
presupuestos, riesgo, calidad, comunicaciones, adquisiciones, etc.) están interconectados. Una vez creado,
dicho plan proporciona a los gerentes una variedad de formas de realizar un seguimiento del proyecto y
evaluar el impacto de las acciones o problemas con algunos elementos del plan en los otros elementos.
Para describir mejor qué es un plan integrado, podemos compararlo con lo que no es, que sería: una
lista de paquetes de trabajo o tareas generadas sin tener en cuenta los requisitos del usuario; un
presupuesto que no tiene en cuenta los recursos necesarios para las tareas del proyecto; y un cronograma
en el que las tareas no coinciden con las tareas de la EDT o el presupuesto. Para el observador externo,
parecería que cuatro personas que nunca se hablaban habían elaborado, respectivamente, una lista de
tareas de trabajo, una lista de recursos necesarios, un cronograma y un presupuesto. Sorprendentemente,
esa es a veces la forma en que se crean los planes, con el resultado de que los requisitos, las tareas, los
recursos, los cronogramas, los presupuestos, etc., son aparentemente independientes y no están
relacionados.
Una característica notable de un plan de proyecto integrado es que la misma lista de paquetes de trabajo
o tareas reaparece en diferentes elementos del plan. La lista de tareas de trabajo desarrolladas en la WBS
aparece en cronogramas, presupuestos y la mayoría de los demás elementos del plan.
El proceso de creación de la WBS y la lista resultante de paquetes de trabajo integra varios elementos
del plan del proyecto y el control del proyecto en varios
6 maneras:
1. Los gerentes, subcontratistas y otros responsables del proyecto se identifican durante el

proceso de la EDT y participan en la definición del trabajo.
Su participación ayuda a garantizar la integridad de la definición del trabajo y gana su
compromiso con ese trabajo.
2. Los paquetes de trabajo en cada fase están lógicamente relacionados con los de las fases
anteriores y posteriores; esto garantiza que se cumplan los requisitos anteriores y que no se
pase por alto ningún paso.
3. Los paquetes de trabajo identificados en la EDT se convierten en la base de los presupuestos
y cronogramas. El presupuesto del proyecto es la suma de los presupuestos de los paquetes
de trabajo más los gastos generales e indirectos. El cronograma del proyecto es un compuesto
de los cronogramas de los paquetes de trabajo.
4. La organización del proyecto se forma en torno a los paquetes de trabajo, con recursos y
responsabilidad de gestión asignados a cada paquete de trabajo.
5. El proyecto se gestiona mediante la gestión de personas que trabajan en los paquetes de
trabajo individuales.
6. El proyecto se controla controlando los paquetes de trabajo. Durante la ejecución del proyecto,
el trabajo completado y los costos acumulados se comparan con los cronogramas y
presupuestos de los paquetes de trabajo, lo que sugiere qué paquetes de trabajo necesitan
una acción correctiva.
El plan de proyecto integrado es un enfoque de sistemas para la gestión: el reconocimiento de que un

proyecto es un sistema de elementos de trabajo interrelacionados que deben definirse, presupuestarse,
programarse y controlarse.
5.5 Organización del proyecto y responsabilidades
Integración de WBS y Organización de Proyectos
Durante el proceso de la EDT, cada paquete de trabajo se asocia con el área de la

organización del proyecto que tendrá la responsabilidad funcional o presupuestaria del mismo.
Un ejemplo es el proyecto LOGON y su contratista, Iron Butterfly Company, representado
en la Figura 5.7: a la izquierda está la estructura organizativa de la empresa; en la parte
superior está el proyecto WBS. Para el trabajo de proyecto contratado (realizado por partes
externas), la estructura organizativa de la izquierda mostraría contratistas y proveedores
en lugar de departamentos. La casilla en la intersección de cada departamento y paquete
de trabajo significa una cuenta de control o cuenta de costos. Cada cuenta representa la
asignación de responsabilidad para una tarea o paquete de trabajo en particular o parte de
uno a un departamento. Al igual que un paquete de trabajo, incluye un cronograma y un
presupuesto, necesidades de recursos, entregables,
Figura 5.7 Integración de WBS y organización de proyectos.
requisitos, y el gerente o supervisor responsable de ello. Cada cuenta de control integra la

WBS con la organización del proyecto y representa un acuerdo o contrato con
departamentos o subcontratistas para cumplir con los requisitos del paquete de trabajo.
Las cuentas de control se describen con más detalle en el Capítulo 8.
Ver Capítulo 8
Matriz de responsabilidad
Las personas responsables de los paquetes de trabajo se muestran en un gráfico llamado

matriz de responsabilidad o matriz de asignación. La Figura 5.8 muestra la matriz de
responsabilidad del proyecto LOGON. Las filas representan los paquetes de trabajo o las
principales tareas y actividades del proyecto identificadas en la EDT. Las columnas representan el
personas, grupos, departamentos o contratistas responsables de ellos, y también puede

incluir otras partes interesadas que necesitan ser notificadas sobre asuntos del proyecto. Las
letras dentro de la matriz simbolizan el tipo de responsabilidad: primaria (responsabilidad
final del paquete de trabajo); secundario (asistencia o ayuda); notificación (debe ser notificado
sobre el estado del paquete de trabajo); y aprobación (tiene autoridad para aprobar o rechazar
los entregables del paquete de trabajo). (Por esta razón, la matriz también se denomina
gráfico RACI: responsable, responsable, consultado e informado). Tenga en cuenta que para
cada tarea se asigna la responsabilidad principal a una y solo una persona. La matriz también
se puede utilizar para indicar quién hará el trabajo y cualquier otro tipo de responsabilidad
concebible.
Desde la matriz, todos los asociados con el proyecto pueden ver fácilmente quién es
responsable de qué. Esto ayuda a evitar que las personas eludan la responsabilidad y "se
pasen la pelota".
Para garantizar que todos sepan lo que se espera de ellos y lo que pueden esperar de los
demás, las personas, grupos o empresas identificados en la matriz deben revisar y aceptar
las responsabilidades. Las asignaciones en la matriz se pueden esbozar durante la
concepción del proyecto y luego se pueden detallar y reafirmar durante una sesión de trabajo
en equipo que se lleva a cabo después del inicio del proyecto. La creación de equipos se
describe en el Capítulo 16.
Ver Capítulo 16
5.6 Programación
El siguiente paso lógico después de la definición de los requisitos y la definición del trabajo es
programar las tareas de trabajo del proyecto. Un cronograma de proyecto muestra el tiempo para
las tareas de trabajo y cuándo deben ocurrir eventos específicos e hitos del proyecto.
Eventos e hitos
Los planes de proyecto son similares a las hojas de ruta: muestran no solo cómo llegar a donde
quieres ir, sino también el progreso que has logrado en el camino. Los paquetes de trabajo son lo
que debes hacer; combinados con el cronograma, son el camino hacia las metas del proyecto. A
lo largo de ese camino hay señales llamadas eventos e hitos que muestran cuánto has progresado.
Superar el último evento significa haber llegado al destino final: la finalización del proyecto.
Los eventos e hitos no deben confundirse con paquetes de trabajo, actividades u otros tipos de
tareas. Una tarea o paquete de trabajo es el trabajo real planificado o realizado y representa el
proceso de hacer algo (como conducir un automóvil para llegar a algún lugar); consume recursos
y tiempo. Por el contrario, un evento significa un momento en el tiempo, el instante en que sucede
algo. En un proyecto, los eventos representan el inicio o el final de algo (equivale a comenzar un
viaje o llegar a un destino intermedio). En la mayoría de los cronogramas de proyectos, cada tarea
se representa como un segmento de línea; los dos extremos del segmento de línea representan
los eventos de inicio y finalización de la tarea. Por ejemplo, en la Figura 5.9 , el segmento de línea
etiquetado como “Tarea A” representa el tiempo para realizar la Tarea A; los eventos 1 y 2
representan los momentos en que se inicia y finaliza la Tarea A, respectivamente. En los
cronogramas de proyectos, cada evento se adjunta a una fecha de calendario específica (día, mes
y año).
Figura 5.8 Ejemplo de matriz de responsabilidad para el proyecto LOGON (con iniciales de las personas responsables).
Figura 5.9 Relación entre tareas y eventos.

Dos tipos de eventos en los proyectos son la interfaz y el hito. 7 Un evento de interfaz denota
la finalización de una tarea y el inicio simultáneo de una o más tareas subsiguientes. El evento
4 en la figura 5.9 es un evento de interfaz. Un evento de interfaz a menudo representa un
cambio en la responsabilidad: un individuo o grupo completa una tarea y otro individuo o grupo
comienza la siguiente tarea. Significa la aprobación de la tarea recién completada y la disposición
para comenzar las tareas subsiguientes.
Un hito representa un evento importante del proyecto, como la finalización de una fase o
varias tareas críticas o difíciles, una aprobación importante o la disponibilidad de recursos
cruciales. Los hitos significan progreso y, como tales, son medidas importantes. A menudo, las
aprobaciones de los requisitos del sistema, el diseño preliminar, el diseño detallado o la
finalización de pruebas importantes se consideran hitos; significan que el proyecto está listo
para pasar a la siguiente fase del ciclo de desarrollo de sistemas. El incumplimiento de un hito
suele ser un mal presagio seguido de cambios en el presupuesto y el cronograma.
Tipos de Horarios
Dos tipos comunes de cronogramas son el cronograma del proyecto y el cronograma de tareas.
Los directores de proyecto y la alta dirección utilizan el cronograma del proyecto ( maestro del
proyecto o cronograma de ejecución ) para planificar y revisar todo el proyecto. Este cronograma
muestra todas las actividades principales del proyecto, pero no muchos detalles sobre cada
una. Primero se desarrolla durante el inicio del proyecto y luego se refina. Los gerentes
desarrollan el cronograma del proyecto de manera descendente, programando primero las
tareas identificadas en la EDT o en la declaración del alcance. Posteriormente, refinan el
cronograma de forma ascendente, teniendo en cuenta los cronogramas de tareas más detallados
desarrollados por los gerentes funcionales. Cuando el proyecto se realiza en fases, el
cronograma de cada fase debe ser lo suficientemente detallado para permitir que la gerencia
autorice el inicio del trabajo en esa fase.
Un cronograma de actividades muestra las actividades o tareas específicas necesarias para
completar un paquete de trabajo. Está creado para las personas que trabajan en las actividades
y permite que los gerentes y supervisores de nivel inferior se concentren en esas actividades y
no se distraigan con otras personas con las que no interactúan. Los cronogramas de actividades
son preparados por gerentes funcionales o subcontratistas, pero incorporan interfaz
e hitos como se especifica en el cronograma maestro del proyecto. Los cronogramas de

proyectos y actividades se preparan y muestran de muchas maneras, incluso con diagramas
de Gantt.
5.7 Gráficos de planificación y programación
Diagramas de Gantt
La técnica de programación más simple y común es el gráfico de Gantt o gráfico de barras,

llamado así por el consultor de gestión Henry L. Gantt (1861-1919).
Durante la Primera Guerra Mundial, Gantt trabajó con el Ejército de los EE. UU. para encontrar
una manera de representar visualmente el estado del programa de municiones. Se dio cuenta
de que el tiempo era un denominador común para la mayoría de los elementos de un plan de
programa y que sería fácil evaluar el progreso al ver el estado de cada elemento con respecto
al tiempo. Su enfoque, que llegó a llevar su nombre, fue ampliamente adoptado en la industria.
Figura 5.10 Diagrama de Gantt para el proyecto LOGON.
El gráfico consta de una escala horizontal dividida en unidades de tiempo (días, semanas o
meses) y una escala vertical que muestra los elementos de trabajo (tareas, actividades o trabajo).
paquetes La figura 5.10 muestra el diagrama de Gantt para paquetes de trabajo en el proyecto
LOGON. En el lado izquierdo se enumeran los paquetes de trabajo y en la parte inferior se
encuentran las semanas laborales. Los tiempos de inicio y finalización de los paquetes están
indicados por el inicio y el final de cada barra.
La preparación del diagrama de Gantt se produce después de que un análisis WBS haya
identificado los paquetes de trabajo u otras tareas. Durante el análisis de la WBS, el gerente
funcional, el contratista u otros responsables de un paquete de trabajo estiman su tiempo y los
requisitos previos. Luego, los elementos de trabajo se enumeran en secuencia de tiempo,
teniendo en cuenta qué elementos deben completarse antes de que otros puedan comenzar.
Como ejemplo, considere cómo se programan los primeros nueve elementos de trabajo
en la Figura 5.9 (paquetes de trabajo H a P). En cada proyecto existe una relación de
precedencia entre las tareas (algunas tareas deben completarse antes de que otras
puedan comenzar), y esta relación debe determinarse antes de programar las tareas.
Estas son las entradas "predecesoras" mencionadas anteriormente en la discusión de la
definición del paquete de trabajo. Suponga que durante el análisis de la WBS para
LOGON se determinó que antes de que pudieran iniciarse las tareas de trabajo I y J, la
tarea H tenía que completarse; que antes de que pudieran iniciarse las tareas K, L y M, la
tarea J tenía que completarse; y que antes de que pudieran comenzar las tareas N, O y
P, la tarea I tenía que completarse.
Antes de que estos puedan ser iniciados... esto debe ser completado
yo, j H
N, O, P 1
k, l, m j
Figura 5.11 Configuración de un diagrama de Gantt.
Esta lógica de secuenciación se utiliza para crear el diagrama de Gantt. Por lo tanto, como se muestra en la
figura 5.11 (y dados los tiempos que se muestran para los paquetes de trabajo), solo después de que se haya
completado la tarea H, es decir, después de la semana 10, se pueden iniciar las tareas I y J; solo después de
que se haya completado la tarea J, después de la semana 16, se pueden iniciar las tareas K, L y M; y, solo
después de que se haya completado la tarea I, después de la semana 18, se pueden iniciar las tareas N, O y P.
A medida que se agrega cada nueva tarea de trabajo al gráfico, se tiene cuidado de ubicarla después de
completar todas las tareas de trabajo anteriores. Este ejemplo utiliza paquetes de trabajo como las tareas que
se programan, pero de hecho se puede programar cualquier unidad de trabajo.
Una vez que el proyecto está en marcha, el diagrama de Gantt se convierte en una herramienta para
evaluar el estado de los elementos de trabajo individuales y del proyecto en su conjunto. La figura 5.12
muestra el progreso a partir de la "fecha de estado", la semana 20. La parte gruesa de las barras indica la
cantidad de trabajo que se ha completado. La parte más delgada de las barras representa el trabajo inconcluso
o por comenzar. Este método es algo efectivo para mostrar cuáles de las tareas de trabajo están atrasadas o
adelantadas con respecto al cronograma.
Por ejemplo, a partir de la semana 20, la tarea N está programada, la tarea O está adelantada y las
tareas K, L, M, P y Q están retrasadas; L es el más atrasado porque debería haberse completado pero
aún no se ha iniciado.
Cuando el diagrama de Gantt se usa así para monitorear el progreso, la información que refleja debe
ser lo más actual posible y el diagrama debe actualizarse diariamente o al menos semanalmente. El
seguimiento del progreso es importante para identificar y corregir problemas. Publicar progresos como
este es una buena manera de mantener motivado al equipo.
Jerarquía de Horarios
Para proyectos grandes con muchos elementos de trabajo, se utiliza una jerarquía de cronogramas,
como se ilustra en los tres niveles de la Figura 5.13. El cronograma superior o de nivel de proyecto
muestra los subproyectos dentro de un proyecto, el cronograma de nivel intermedio muestra las
principales actividades dentro de un subproyecto, y el inferior o el nivel de tareas muestra paquetes de
trabajo o tareas más pequeñas dentro de una actividad. Los hitos y las fechas objetivo se pueden
mostrar en cualquier nivel.
Cada programa de nivel amplía los detalles del programa en el nivel superior.
Los cronogramas de nivel intermedio e inferior se utilizan para que los gerentes funcionales y de
proyecto planifiquen las asignaciones de mano de obra y recursos. Los cronogramas de nivel inferior
son los más detallados y muestran los cronogramas diarios (e incluso por hora) de las tareas dentro de
los paquetes de trabajo. Estos son utilizados por los líderes de paquetes de trabajo y corresponden a
los programas de tareas mencionados anteriormente. La figura 5.14 es un cronograma de varios niveles,
que muestra tanto el proyecto de nivel superior
Figura 5.12 Diagrama de Gantt para el proyecto LOGON que muestra el progreso del trabajo hasta la semana 20.
Figura 5.13 Una jerarquía de horarios.

Figura 5.14 Horario multinivel.
actividades (indicadas por barras de "resumen"), así como las tareas detalladas dentro de cada actividad (indicadas por
barras de "actividad").
Como regla general, los cronogramas de nivel inferior y más detallados se crean más cerca de cuando se necesitan y
cuando se conocen mejor dichos detalles: el enfoque de planificación por etapas en la Figura 4.2.
Desventajas de los diagramas de Gantt
Una desventaja del diagrama de Gantt es que no muestra necesariamente los efectos de un elemento de trabajo que se
retrasa en otros elementos de trabajo. Como se ha descrito, algunos elementos de trabajo dependen de otros antes de
que puedan comenzar; si esos otros se retrasan, también lo harán otros y, posiblemente, todo el proyecto.
Los diagramas de Gantt por sí solos no proporcionan ninguna forma de determinar cómo funcionan los retrasos en algunos
elementos impactan otros elementos y el proyecto.

5.8 Línea de Saldo (Método de Programación Lineal)
Si bien los proyectos son, por definición, esfuerzos únicos y de una sola vez, a veces
contienen actividades de trabajo repetitivas. Los ejemplos incluyen la construcción de numerosas torres para
una nueva línea de transmisión, la construcción de múltiples unidades de vivienda en gran medida idénticas,
y la construcción de un edificio de varios pisos. Un método para planificar y controlar estos
actividades repetitivas es la línea de balance—LOB (también llamada Programación Lineal)
Método porque a menudo se usa en "proyectos lineales" como carreteras y
tuberías donde la ubicación física del trabajo se puede representar en términos de
millas o kilómetros).
Ejemplo 5.5: Grúas para la Construcción
Un proveedor de grúas de construcción debe entregar un total de 12 grúas según

al cronograma de la Tabla 5.1. Antes de la entrega, se debe realizar un conjunto de actividades
completado para cada grúa. Estos se muestran como actividades A–F en el Gantt
gráfico de la figura 5.15.
Tabla 5.1 Cronograma de Entrega de Grúas
Semana Fecha Cantidad de entrega Cantidad de entrega acumulada
1 febrero 7 1 1
2 14 de febrero 2 3
3 febrero 21 4 7
4 febrero 28 5 12
Supongamos que miramos solo las entregas el 14 de febrero; de acuerdo con la Tabla 5.1,
para entonces se debe entregar un total de tres grúas. La pregunta es, ¿hasta dónde
¿Deberían estar todas las demás actividades para entonces? Por ejemplo, cuantos
unidades de potencia (actividad B) deben comprarse para entonces (suponiendo que una unidad de potencia
por grúa), cuántos componentes se adquirieron, etc.

De acuerdo con la Figura 5.15, se debe comprar una unidad de potencia 2 semanas antes de
la entrega de una grúa. Ahora, mire la columna de la derecha de la Tabla 5.1; descender 2
semanas desde el 14 de febrero muestra el número 12: esto significa que se deben comprar
12 unidades de potencia antes del 14 de febrero. Dado que las actividades A y C deben
completarse 3 semanas antes de la entrega de la grúa (Figura 5.15), vemos, refiriéndose a la
Tabla 5.1, que se deben adquirir 12 juegos de “otros componentes” (actividad C) y se deben
fabricar 12 juegos de componentes estructurales (actividad A) para el 14 de febrero. De la
misma manera, ya que los operadores deben estar capacitados (actividad E) 1 semana antes
de la entrega, bajando 1 semana desde el 14 de febrero en la Tabla 5.1 muestra que siete
operadores deben estar capacitados para el 14 de febrero.
Del mismo modo, vemos que siete grúas (actividad D) deben ensamblarse antes del 14 de
febrero. Además, dado que las pruebas con operadores (actividad F) implican un tiempo de
entrega cero, tres pruebas deben completarse para entonces.
Figura 5.15 Diagrama de Gantt de tareas para la entrega de una grúa.
La figura 5.16 resume la LOB: la cantidad de entregables (unidades completadas) por

actividad al 14 de febrero. Para el centro de costos, la función o el proveedor responsable de
cada actividad, la LOB brinda la información necesaria para estimar los recursos necesarios y
planificar el trabajo.
Una alternativa a la Figura 5.16 es un diagrama que muestra el número de unidades que
debe completar una actividad específica por período de tiempo. Por ejemplo, la figura 5.17
muestra fechas y cantidades de componentes estructurales fabricados (actividad A) y grúas
ensambladas (actividad D). El mismo tipo de figura se puede usar para monitorear las unidades
reales completadas y rastrear el progreso en comparación con lo planificado.
unidades.
Figura 5.16 Número de entregables requeridos al 14 de febrero por tipo de actividad.

Figura 5.17 Presentación alternativa de un programa de línea de saldo.

8
5.9 Gestión de adquisiciones
La mayoría de los proyectos implican la adquisición de bienes, materiales y trabajo subcontratado.
De hecho, en algunos proyectos todo se “adquiere” y prácticamente nada se hace o produce
“internamente”. Si el trabajo del proyecto debe realizarse internamente o adquirirse de terceros es el
resultado de un análisis de fabricación o compra del artículo final, los subsistemas, los componentes,
los servicios u otros entregables del proyecto, y de los paquetes de trabajo y las tareas identificadas
en la WBS. .
Ciertamente, la gestión de los materiales adquiridos y el trabajo subcontratado es tan importante
para el proyecto como el trabajo realizado internamente: los elementos adquiridos que exceden el
presupuesto o el cronograma, o no cumplen con los requisitos, causan sobrecostos y sobrecostos en
el cronograma de todo el proyecto.
El papel de la gestión de adquisiciones es ayudar a la planificación y el control de lo siguiente:
9
1. Equipos, materiales o componentes diseñados y construidos por proveedores específicamente

para el proyecto. Estos artículos adquiridos pueden involucrar partes o paquetes de trabajo
completos (por ejemplo, trabajo de diseño, estudio ambiental, análisis de suelos). Las partes
principales de un proyecto pueden subcontratarse por completo en un acuerdo "llave en
mano" (es decir, los subcontratistas diseñan, construyen e instalan por completo los equipos
o componentes principales para el artículo final del proyecto).
2. Equipos y componentes listos para usar (OTS) suministrados por proveedores .
Estos representan productos que están fácilmente disponibles y que no se producen
específicamente para el proyecto.
3. Materiales a granel (cemento, tubería o armazón de metal, alambre, piedra, tubería, etc.)
4. Consumibles (clavos, pernos, remaches, combustible) o herramientas para la construcción o
fabricación.
5. Equipo para construcción o fabricación que no sea propiedad del contratista; incluye grúas,
soportes, andamios y equipos para talleres, soldadura y pruebas.
6. Equipo administrativo que aún no sea propiedad del contratista; incluye computadoras e
instalaciones y equipo de la oficina del proyecto.
Para simplificar, agrupamos estos artículos aquí y nos referimos a ellos como bienes, trabajo o servicios
adquiridos (GWS). Bienes se refiere a materias primas o artículos producidos; trabajo significa mano de
obra contratada; y servicios incluye consultoría.
El término “adquisición” representa actividades relacionadas con artículos comprados o subcontratados,
aunque también se utilizan otros términos, pero con las siguientes distinciones: mientras que “adquisición”
se refiere a la compra de un sistema complejo completo que no está bien definido (incluido su diseño,
desarrollo, puesta en marcha y producción), y “compra” se refiere a la compra de un artículo o pieza
estandarizados (listos para usar) , “adquisición” se refiere a la compra de un componente o subsistema
(menos de la totalidad sistema)—incluyendo su diseño y/o producción—según especificaciones
proporcionadas por el cliente. Por lo tanto, sería apropiado decir la "adquisición de una planta de energía
nuclear", la "adquisición de un dispositivo de seguridad de apagado automático" y "la compra de un lote
de clavos estándar de una pulgada".
La gestión de adquisiciones incluye casi todo lo relacionado con la contratación y la administración de

contratos: solicitud de ofertas y selección de contratistas, establecimiento de contratos legalmente
vinculantes entre las partes, gestión de la ejecución de los contratos y cierre de contratos. Los primeros
de estos temas se cubrirán aquí y los demás en los capítulos 11 y 12.
Solicitud y evaluación de ofertas
Una vez que se toma la decisión de adquirir GWS, se solicita a los proveedores potenciales que presenten
ofertas o propuestas. Un cliente que tiene una relación a largo plazo con un proveedor o contratista,
especialmente uno con habilidades o capacidades únicas, generalmente se acercará al contratista y
negociará un contrato. Esto se denomina contratación exclusiva porque solo se considera un contratista
para el contrato. Cuando el alcance del proyecto es algo simple y los requisitos están bien definidos, el
cliente puede anunciar ofertas en línea y otros medios mediante una RFP o RFQ (Solicitud de cotización,
una cotización de precio simple). Para un sistema grande y algo indefinido que requiere trabajo de diseño
u otro aporte intelectual, se envía una RFP o IFB (información para la oferta) a una lista corta de
proveedores calificados. La RFP o
La IFB puede estar precedida por una RFI, una solicitud de información para determinar si el
contratista está calificado y se le debe enviar una RFP. A veces, la RFP va acompañada de una
conferencia de licitadores o contratistas para explicar los antecedentes y el alcance del proyecto,
la documentación requerida de los contratistas y los requisitos contractuales. La aceptación de
una oferta dará lugar a un contrato formal con el contenido y las condiciones descritas en el
Capítulo 3. Cuando el artículo adquirido sea hardware, el contrato debe especificar en qué
momento el proveedor ya no es responsable de los daños y el comprador se hace responsable.
Los tipos básicos de contratos se describen en el Capítulo 3, aunque ciertas industrias

requieren formatos de contrato específicos. 10 La gestión de adquisiciones
especializada queesrequiere
una función
habilidades
de administración legal y de contratos; en algunos
organizaciones una división de compras especializada lo maneja. 11
Ver Capítulo 3
Planificación y programación de adquisiciones
El primer paso en la planificación de adquisiciones es estimar los artículos adquiridos, la mano

de obra o los servicios necesarios para el proyecto. Asociados con cada paquete de trabajo se
obtienen los requisitos de GWS, algunos de los cuales se compartirán con otros paquetes de
trabajo. Los artículos que se adquirirán se identifican durante el proceso de la WBS, ya sea por
la planificación del trabajo y los recursos necesarios para paquetes de trabajo particulares, o por
saber que los paquetes de trabajo completos se deben subcontratar. En el primer caso, los
gerentes responsables de cada paquete de trabajo identifican el GWS dentro del paquete que se
debe adquirir (por ejemplo, el paquete de trabajo "ala de construcción" requerirá la adquisición
de fibra de vidrio, aluminio y otros materiales de los proveedores); en el último caso, los gerentes
reconocerán que ciertas partes (a veces significativas) del proyecto (paquetes de trabajo
completos ) deberán subcontratarse (por ejemplo, el paquete de trabajo "desarrollar un motor
cohete" requerirá desarrollo, fabricación y prueba, todo para ser proporcionada por los contratistas).
Asociado con cada artículo adquirido hay un cronograma que especifica cuándo se necesita
el artículo y cuándo deben comenzar las actividades de adquisición. Todo lo que se adquirirá en
el proyecto debe programarse con anticipación para permitir suficiente tiempo para llevar a cabo la
RFP/propuesta/proceso de selección de proveedores (descrito en el Capítulo 3), y para que los

proveedores entreguen (o diseñen, construyan y luego entreguen) los artículos en los momentos
necesarios. La figura 5.18 muestra las consideraciones al programar un artículo de GWS adquirido.
El cronograma se prepara trabajando hacia atrás, comenzando con el evento 10, la fecha en que
el artículo debe estar disponible para el proyecto. Este cronograma luego se integra con el
cronograma del proyecto para garantizar que el proceso de adquisición se realice con suficiente
anticipación para que el artículo esté disponible cuando se necesite. Este procedimiento se repite
para programar todos los artículos de GWS adquiridos.
Figura 5.18 Cronograma de actividades de adquisiciones.
Fuente: Adaptado de Joy P. Total Project Management. Nueva Delhi: Macmillan India Limited; 1993, pág. 383.
Por supuesto, la preparación de dicho calendario requiere conocer los plazos de entrega de
cada una de las actividades de adquisición: el tiempo necesario para que, por ejemplo, los
proveedores y subcontratistas preparen propuestas, el director del proyecto evalúe las propuestas
y emita contratos y órdenes de trabajo, y los proveedores/subcontratistas a
cumplir con las órdenes de trabajo (lo que podría implicar su diseño, construcción y prueba de
equipos o componentes). No es raro, especialmente en proyectos internacionales, que estos
tiempos se subestimen enormemente y, en consecuencia, el proyecto se retrase.
El cronograma de la Figura 5.18 comienza en el punto donde se identificaron los requisitos de

GWS. Sin embargo, para llegar a ese punto, primero se deben haber definido los requisitos y
especificaciones del sistema, otra razón para prestar especial atención a la definición del sistema
en el ciclo de vida del proyecto.
Los GWS adquiridos requieren el mismo tratamiento en la planificación del proyecto que los
aspectos internos del proyecto; por lo tanto, asuntos como la responsabilidad, el presupuesto, la
calidad y el riesgo de los artículos adquiridos también deben abordarse en el plan, temas que se
discutirán en capítulos posteriores.
Plan Logístico
La logística se relaciona con el transporte y almacenamiento de materiales. En proyectos que

son intensivos en materiales, la carga, descarga, transporte, inspección, autorizaciones y
aprobaciones, y el almacenamiento de materiales pueden ser problemas importantes. Por
ejemplo, considere un gran proyecto de construcción y la importancia de programar la llegada de
los materiales (acero, tuberías, losas de concreto) para que coincida con el momento en que se
necesitarán esos materiales para el edificio. Obviamente los materiales no pueden llegar tarde
porque eso retrasará el proyecto. Pero igualmente grave es cuando los materiales llegan antes de tiempo.
¿Dónde los pones ? ¿Dónde pones el camión que los trae? En áreas urbanas congestionadas
simplemente no hay espacio; cuando lo hay, los materiales entregados antes de tiempo están
sujetos a daño, deterioro y robo. Siempre que no se pueda programar que los artículos de GWS
lleguen justo a tiempo, se deben hacer provisiones para almacenarlos y protegerlos, lo que en
proyectos grandes puede ser muy costoso.
5.10 Resumen
El propósito de la planificación de proyectos es determinar la forma en que se lograrán los objetivos
del proyecto: qué se debe hacer, por quién, cuándo y por cuánto.
El enunciado del alcance del proyecto y la EDT son formas en que los gerentes y planificadores
responden a la pregunta "¿Qué se debe hacer?" La declaración del alcance describe las principales
áreas de trabajo a realizar y los entregables o elementos finales. Aparece comúnmente en dos lugares,
el SOW o la carta del proyecto. El SOW es una descripción resumida del proyecto utilizado para el
trabajo contratado; aparece en la RFP, propuesta, contrato y plan de ejecución del proyecto. El estatuto
es un documento utilizado para proyectos internos para describir, anunciar y autorizar formalmente el
proyecto.
El proceso WBS subdivide el proyecto en paquetes de trabajo u otros elementos de trabajo, cada
uno de los cuales es lo suficientemente pequeño como para comprenderlo, planificarlo y controlarlo bien.
La mayoría de los elementos y funciones de la gestión de proyectos (programación, presupuestación,
asignación de recursos, seguimiento y control) se llevan a cabo posteriormente con referencia a la
EDT y los paquetes de trabajo.
La matriz de responsabilidad integra la organización del proyecto con la EDT; prescribe qué
unidades e individuos, tanto internos como subcontratistas, tienen la responsabilidad del proyecto y el
tipo de responsabilidad para cada uno. Es valioso para lograr el consenso, garantizar la rendición de
cuentas y reducir los conflictos entre los participantes del proyecto.
Los cronogramas del proyecto muestran el tiempo de trabajo y son la base para la asignación de
recursos y el seguimiento del desempeño. Dependiendo de la cantidad de detalles requeridos, se
utilizan diferentes tipos de cronogramas: los cronogramas a nivel de proyecto muestran solo tareas y
paquetes de trabajo de alto nivel; los cronogramas a nivel de tarea muestran las tareas necesarias
para completar paquetes de trabajo individuales. La forma más común de programación es el diagrama
de Gantt. Como dispositivo de planificación visual, es efectivo para mostrar cuándo se debe realizar el
trabajo y si los elementos del trabajo están atrasados o adelantados con respecto al cronograma.
Los planes del proyecto deben dar cuenta de todos los recursos y el trabajo necesarios para el
proyecto, incluidos los adquiridos (proporcionados por proveedores y contratistas). Los artículos
adquiridos y el proceso de adquisición deben incluirse en todos los elementos del plan del proyecto: la
WBS, el cronograma, la matriz de responsabilidad, el presupuesto, etc.
Los conceptos y técnicas de este capítulo son herramientas fundamentales para la planificación y la
programación. Los siguientes capítulos analizan técnicas adicionales para la planificación y la
programación. Los capítulos posteriores abordan el papel de la WBS, los paquetes de trabajo y los
cronogramas en la estimación de costos, la elaboración de presupuestos y el control de proyectos.
1. ¿Qué preguntas deben responderse cada vez que se planifica un nuevo proyecto?
¿Cuáles son los pasos en el proceso de planificación que responden a estas preguntas?
2. ¿Cuál es el propósito de un plan de ejecución del proyecto? ¿En qué etapa de la

proyecto debe prepararse este plan?
3. ¿Se puede emprender un proyecto sin un plan de ejecución? ¿Cuáles son las posibles
consecuencias?
4. ¿Qué aspectos del plan de ejecución podrían eliminarse para proyectos con
presupuestos pequeños? ¿Cuáles podrían eliminarse para proyectos de corta duración
(unas pocas semanas o meses) con relativamente pocas tareas?
5. A menudo se deja fuera del plan de ejecución del proyecto una sección para abordar el
“Riesgo y la incertidumbre”. ¿Cuáles son los peligros potenciales de hacer esto?
6. ¿Cuál es el propósito del enunciado del alcance del proyecto? ¿Qué información se
utiliza para crear la declaración de alcance? ¿Cómo se refleja el alcance en el
EDT?
7. ¿Qué es la declaración de trabajo? ¿En qué documentos la SOW
¿Aparecer?
8. ¿Cuáles son las diferencias y similitudes entre el SOW y el proyecto?

¿carta?
9. Piense en un esfuerzo algo complicado con el que esté familiarizado y desarrolle una
EDT para ello. (Ejemplos: boda, reunión de la escuela secundaria, encuesta de
cuestionario, película o obra de teatro, etc.). Ahora repita para un trabajo complicado
con el que no esté familiarizado. ¿En qué momento necesita ayuda de “gerentes
funcionales” o especialistas para continuar con la avería?
10. ¿Cómo sabe en una WBS cuando ha alcanzado un nivel en el que no es necesario un
mayor desglose?
11. ¿Podría la EDT de la Figura 5.5 haber comenzado con diferentes elementos de Nivel 2
y aun así dar como resultado los mismos paquetes de trabajo? En general, ¿diferentes
enfoques de WBS pueden dar resultados similares?
12. ¿De qué manera es importante la WBS para los gerentes de proyectos?
13. ¿Cuál es el papel de los gerentes funcionales en el desarrollo de una EDT?
14. ¿Cuál es el impacto de alterar la WBS después de que el proyecto haya comenzado?
15. ¿Qué debe incluir un paquete de trabajo “bien definido”?
16. ¿Cuál es la relación entre la WBS y la estructura de la organización?
En esta relación, ¿cuál es el significado de una “cuenta de control”?
17. La figura 5.8 muestra algunos posibles tipos de responsabilidades que podrían
indicado en una matriz de responsabilidad. ¿Qué otro tipo de responsabilidades
o deberes podrían ser indicados?
18. Construya una matriz de responsabilidad usando la EDT que desarrolló en

pregunta 9. Al hacer esto, considere la organización del proyecto y la
personal directivo/técnico a asignar y sus funciones.
19. ¿Qué función cumple la matriz de responsabilidades en el control de proyectos?
20. ¿Podría una matriz de responsabilidad parecer amenazante para los gerentes y otros?
¿Por qué?
21. Distinguir un evento de una actividad. ¿Qué problemas pueden surgir si las personas
en un proyecto confundir estos términos?
22. Distinga un evento de interfaz de un evento de hito. Dar algo
ejemplos de cada uno. ¿Cuándo un evento de interfaz es también un evento de hito?
23. ¿Cómo se preparan los cronogramas a nivel de proyecto y de tarea? Cuál es el
relación entre ellos? ¿Quién los prepara?
24. Construya un diagrama de Gantt similar al de la Figura 5.10 usando el
siguientes datos:
Tarea Hora de inicio (semanas) Duración (semanas)

A 0 5
B 6 3
C 7 4
D 7 9
mi 8 2
F 9 8
GRAMO 12 7
¿Cuándo se completará la tarea G?

25. ¿Cómo se debe cambiar el diagrama de Gantt que dibujó en el problema 24 si le dijeron
que C y D no podían comenzar hasta que B se completara, y que G no podía comenzar
hasta que C se completara? ¿Qué sucede con el tiempo de finalización del proyecto?
26. ¿El diagrama de Gantt es adecuado para planificar y controlar pequeños proyectos?
27. En una jerarquía de horarios, ¿cómo afecta el cambio de un horario en un nivel a los
horarios en otros niveles?
28. ¿Cómo decide cuándo es necesario más de un nivel de programación?

29. Si se utiliza una jerarquía de cronogramas en la planificación de proyectos, explique si
también debería haber una jerarquía de planes correspondiente.
30. ¿Qué aspectos del proyecto se incluyen en la “gestión de adquisiciones”? ¿Por qué la
gestión de artículos adquiridos es tan importante para el éxito del proyecto como la
gestión de artículos internos? ¿Cuáles son los problemas en la programación de
artículos adquiridos?
31. Considere esta afirmación: La gestión de artículos adquiridos puede presentar mayores
dificultades que la gestión de artículos internos. ¿Está de acuerdo o en desacuerdo y
por qué?
1. Describa el plan de ejecución del proyecto para su proyecto (el plan desarrollado al inicio
del proyecto). ¿Cuál es el contenido? Muestre un plan de ejecución típico.
2. ¿Quién preparó el plan?

3. ¿En qué momento del proyecto se preparó el plan?
4. ¿Cuál es la relación entre el plan de ejecución y el proyecto?
¿propuesta? ¿El plan se derivó de la propuesta?
5. ¿Existe una declaración del alcance del proyecto? ¿Quién lo preparó? ¿Las principales
áreas de trabajo y entregables del proyecto corresponden a la declaración del alcance?
6. ¿Existe un SOW o una carta del proyecto? Describa su propósito y contenido.
7. ¿Cómo, cuándo y quién preparó la estructura de desglose del trabajo (EDT)? Describa el
proceso utilizado en la preparación de la EDT.
8. ¿En qué parte de la EDT se incluye la gestión de proyectos?
9. ¿Se utilizó el concepto de paquete de trabajo? Si es así, describe qué obra
El paquete incluye. ¿Cómo se definen los paquetes de trabajo?
10. ¿Cómo se manejaron en la WBS las actividades en curso, como la administración, la
supervisión, la inspección y el mantenimiento? ¿Había un paquete de trabajo para cada
uno?
11. ¿Cómo se asignaron las responsabilidades en la WBS a la organización del proyecto (es
decir, cómo se involucraron las áreas funcionales en el proyecto)?
12. ¿Cómo se asignaron las personas al proyecto? Describa el proceso.

13. ¿Se utilizó una matriz de responsabilidad? Muestre un ejemplo.
14. ¿Cómo se transfirieron las actividades de la EDT a un cronograma? ¿Cómo se estimaron
los tiempos? ¿Quién preparó los horarios?

15. Muestre ejemplos de cronogramas a nivel de proyecto y de tarea. ¿Quién preparó cada
uno? ¿Cómo se verificaron e integraron?
16. ¿Cuáles son los GWS adquiridos en el proyecto? ¿Se gestionaron estos elementos de
manera diferente a los aspectos internos del proyecto? ¿Cómo se identificaron primero y
luego se integraron en el plan del proyecto? Hizo artículos adquiridos
plantea alguna dificultad al proyecto?
's
Caso 5.1 Empresa constructora de presas:
Sean WBS
Sean Shawn fue nombrado recientemente planificador de proyectos en Barrage

Construction, una empresa que se especializa en garajes hechos a la medida. Trabajó
durante 2 años en el departamento de recursos humanos mientras completaba su MBA
y ahora tiene un escritorio en la oficina de proyectos recién creada. Barrage está
considerando diversificarse para construir garajes estándar para dos y tres autos, así
como sus garajes personalizados habituales, y le pidió a Sean que determinara la
viabilidad de ingresar a este mercado. Al hojear un libro sobre gestión de proyectos,
descubrió el concepto WBS y decidió que sería útil para desarrollar estimaciones de
costos para los talleres estándar. Nunca había trabajado en un proyecto de construcción
de garajes, pero sentía que conocía el proceso lo suficientemente bien por haber
hablado con los empleados de la empresa. Se sentó y dibujó la EDT en la Figura 5.19.
Para estimar los costos de cada categoría de trabajo en la WBS, revisó los registros de
costos de la empresa de tres proyectos recientes de garajes para dos autos que pensó
que eran similares a los garajes estándar, calculó el promedio y luego repartió los
costos entre las categorías en la WBS. La compañía no tenía registros de costos reales
para un garaje para tres autos, por lo que, como estimación, aumentó la estimación
para el garaje para dos autos en un 50 por ciento. Cuando sumó los costos de todas
las categorías, llegó a un total de $43,000 por un garaje para dos autos y $64,500 por
un garaje para tres autos. En comparación con los competidores, descubrió que estos
costos eran un 10 por ciento más altos que sus precios. Sin embargo, debido a que
sus estimaciones se habían basado en garajes personalizados, creía que podrían ser
al menos un 20 por ciento más altas que las de los garajes estándar. Por lo tanto,
redujo su estimación en un 20 por ciento y concluyó que Barrage podría fijar precios
competitivos para sus garajes y aun así obtener una ganancia del 10 por ciento.
Figura 5.19 Proyecto de garaje de Sean EDT.

Pregunta
¿Cuál es su opinión sobre el enfoque de Sean para crear una WBS y estimar los costos del proyecto?
Por favor elabora.
'
Caso 5.2 Startrek Enterprises, Inc.: Proyecto
Plan Deva
Deva Patel, gerente de proyectos de Startrek Enterprises, Inc., está planificando y coordinando la
mudanza de la empresa a un nuevo edificio actualmente en construcción. Deva quiere que la
mudanza comience tan pronto como el edificio esté listo para la ocupación estimada del 1 de junio,
todavía faltan 2 meses. Toda la mudanza, que afectará a cuatro departamentos y 600 personas, se
completará en 1 semana. Debido a que el tiempo es crítico, Deva comienza su planificación
preparando un diagrama de Gantt. A nivel de proyecto, dibuja una barra de 1 semana (7 días) de
duración, luego la subdivide en tres categorías principales: (1) empacar suministros de oficina,
equipos y muebles (3 días asignados); (2) mover todo (2 días asignados); y (3) desempaquetarlo y
organizarlo en una nueva ubicación (2 días). Luego, estima la cantidad total de cajas, equipos y
muebles que deberán trasladarse en 2 días, entrega el presupuesto a un contratista de mudanzas y
recibe una cotización. Para ayudar a empacar y desempacar cajas y equipos, Deva tiene la intención
de contratar trabajadores temporales. Calcula el número de trabajadores necesarios, se lo da a una
agencia de trabajo temporal y recibe una cotización.
Deva le muestra el plan completo a su gerente y le pide que lo revise.

El plan consiste en el diagrama de Gantt y un presupuesto que se basa en gran medida en las
cotizaciones de precios de la empresa de mudanzas y la agencia de trabajo temporal.
Preguntas
1. ¿Qué piensa sobre el enfoque de Deva para programar el trabajo y estimar

los costos?
2. Si usted fuera el gerente de Deva, ¿consideraría que su plan es integral?
3. ¿Cómo prepararía un plan para la mudanza y qué incluiría su plan?
'
Caso 5.3 GualterioPlan de proyecto
A Walter se le acaba de asignar la gestión de un proyecto: su primera experiencia

como director de proyectos. El proyecto implica desarrollar un artículo final que debe
cumplir con una larga lista de requisitos, pero después de revisar la SOW del proyecto
y la lista de requisitos, lo primero que Walter se pregunta es quién estará en su
equipo de proyecto. Le pregunta a su gerente, quien le da los nombres de tres
personas en el departamento que están disponibles para trabajar en el proyecto.
A continuación, Walter empieza a pensar en lo que hará cada una de las tres
personas del equipo. Él siente que para que un proyecto tenga éxito, los miembros
del equipo deben ser asignados a las tareas para las que están más calificados o
tienen más experiencia. Ya que ha trabajado con la gente antes, sabe un poco acerca
de su experiencia individual. Se sienta a preparar una lista de tareas para cada
persona; a medida que considera a cada persona, piensa en las cosas que deben
hacerse en el proyecto y selecciona aquellas que cree que se adaptan mejor a la
persona. Cuando termina de crear las listas, ve que la persona A tiene 11 tareas,
mientras que las personas B y C tienen 4 tareas y 5 tareas, respectivamente. A
equilibrar la carga de trabajo, toma cuatro de las tareas de la persona A y las divide entre las
otras dos. Está contento porque siente que con siete, seis y siete tareas, respectivamente,
los miembros del equipo tendrán aproximadamente la misma cantidad de trabajo.
Luego, en cada lista, ordena las tareas en la secuencia aproximada en que deben
realizarse.
Al día siguiente, Walter se reúne con el equipo y les entrega las listas de tareas. Les pide
que estimen el tiempo que necesitarán para hacer cada una de las tareas y que se reúnan
como grupo para averiguar cómo se interrelacionan sus tareas y crear un diagrama de Gantt.
Siente que al exigir a los miembros del equipo que estimen los tiempos de las tareas y creen
su propio cronograma, las estimaciones y el cronograma serán realistas y reflejarán con
precisión el cronograma del proyecto.
Walter se detiene en la oficina de su gerente y le informa con entusiasmo que su "plan de
proyecto" estará disponible pronto, y consistirá en un diagrama de Gantt y listas de
responsabilidades para los miembros del equipo del proyecto.
Preguntas
1. Analice el enfoque de Walter para (a) definir el trabajo (crear listas de tareas), (b) crear
el cronograma y (c) asignar responsabilidades.
2. ¿Qué piensas del enfoque de Walter para “equilibrar el
carga de trabajo” entre los miembros del equipo?
3. ¿Cree que el diagrama de Gantt reflejará de manera realista el trabajo que debe
realizarse en el proyecto? ¿Cree que el proyecto podrá satisfacer el SOW y los
requisitos?
4. ¿De qué otra forma podría haber actuado Walter para definir las tareas de trabajo, crear
el cronograma y asignar responsabilidades?
Caso 5.4 Planificación de la implementación de

Boca en Kulczyÿski Productos
Tomasz Grabowski acaba de ser contratado como director de proyectos de TI en Kulczyÿski

Products. Su primer proyecto es instalar el nuevo Boca Business System.
Este es su primer puesto gerencial, pero con 4 años de experiencia en TI se siente seguro de que
puede hacer un buen trabajo. Dirigirá un equipo de hasta 12 profesionales de TI, 9 de Kulczyÿski y
3 de Boca Systems, el contratista de software. Hasta ahora, solo 3 miembros del equipo de
Kulczyÿski han sido asignados al proyecto.
Para planificar el proyecto, prepara una lista detallada de las tareas que cree que deben
realizarse, que se muestran a continuación. Está orgulloso de la lista y cree que es bastante
completa.
Lista de tareas
1. Identificar los recursos a monitorear.

2. Definir usuarios y flujo de trabajo.
3. Identifique las fuentes de eventos por tipo de recurso.
4. Definir la relación entre los recursos y los sistemas empresariales.
5. Identificar a los miembros del equipo de implementación.
6. Solicite el hardware del servidor para la producción, así como para la prueba/calidad
garantía.
7. Solicite máquinas de consola.

8. Ordene el software de requisito previo.
9. Instale los servidores de prueba y control de calidad y el software de requisitos previos.
10. Instale máquinas de consola y software de requisitos previos.
11. Instale Boca Business Systems Manager en máquinas de consola.

12. Instale los servidores de producción y el software de requisitos previos.
13. Instale máquinas de consola y software de requisitos previos.
14. Configure el servidor Boca Console y verifique la conectividad.
15. Para cada tipo de recurso, realice las siguientes tareas:
una. Ampliar el modelo de datos. b.
Configure la ubicación de la instancia. C. Configure
la regla Boca Enterprise Console para enviar eventos. d. Asocia tareas y URL con
tipos de objetos. mi. Configure el filtrado, si corresponde. F. Verifique el flujo de
eventos.
16. Para cada interfaz del sistema empresarial, realice las siguientes tareas:
una. Pruebe el archivo de Automated Business Systems y las definiciones XML para
verificar la inclusión y ubicación de recursos. b. Crear bases de datos en el

servidor de historial. C. Configure y pruebe trabajos en el servidor de la base de datos
para producir la copia de seguridad de la base de datos. d. Configurar y probar
trabajos para copiar bases de datos de respaldo en el
servidor de historial
mi. Configurar y probar trabajos para replicar eventos en el historial

servidor.
F. Instale su procesador de solicitudes en el servidor de base de datos de Boca

Business Systems Manager para que lo use la función de procesamiento de
solicitudes de problemas y cambios.
gramo. Opcional: actualice la tabla de configuración del sistema para reflejar los
nombres de los procesadores de solicitudes junto con las opciones de
procesamiento para los procesadores de solicitudes. H. Opcional: actualice la
tabla TLAP para especificar opciones de recursos para la creación de tickets de
problemas.
17. Considere capacitar a un grupo clave y pídales que capaciten a sus compañeros.
una. Evaluar la adición y eliminación de ID de usuario.
b. Establecer una relación entre Boca Business Systems Manager y la gestión del
cambio. Supervise el rendimiento del sistema y ajuste el hardware según sea
necesario. C. Empleos del servidor SQL de Boca Business Systems Manager.
El proyecto comenzará en marzo y finalizará el 31 de noviembre. Tomasz no está acostumbrado a

trabajar de acuerdo con los cronogramas, pero el gerente del departamento dice que debe preparar
uno para asegurarse de que el proyecto pueda realizarse a tiempo.
Para el cronograma, Tomasz decide crear una "línea de tiempo" similar a la que vio en un proyecto
anterior. Toma esa línea de tiempo y la modifica para mostrar 11 “categorías de trabajo” que cree que
representan el proyecto Boca. Luego estima cuánto tiempo tomará cada categoría de trabajo al medio
mes más cercano. Al organizar las categorías y los tiempos en la línea de tiempo, Tomasz descubre
que el proyecto terminará en enero, que es demasiado tarde. Revisa las estimaciones y reduce varias
de ellas lo suficiente como para acortar el plazo en 2 meses. La Figura 5.20 es la línea de tiempo
terminada.
Figura 5.20 Cronograma del Proyecto de Implementación de Boca.
Tomasz tiene la intención de asignar la responsabilidad de la siguiente manera:
• El Equipo de Boca es responsable de todo lo que está en la lista de tareas con el

palabra "Boca".
• El equipo Kulczyn'ski es responsable de todo lo demás en la lista.
Justo antes de que comience el proyecto, Tomasz entrega a Boca Team y Kulczyn'ski Team
una copia de la lista de tareas y el cronograma. Él les explica: “Aquí está la lista de lo que
tenemos que hacer. Si puede hacer todo dentro del cronograma, deberíamos poder cumplir
con la fecha límite del proyecto”.
Comenta sobre el “plan” de Tomasz.
Notas finales
1. Algunas organizaciones utilizan el término “carta del proyecto” para referirse a un “plan de ejecución”. Preferimos el uso más
común, es decir, la carta es un documento algo breve para anunciar y autorizar la decisión de emprender un proyecto, mientras
que el plan de ejecución es un documento completo que guiará la
equipo del proyecto a través de la ejecución del proyecto.
2. El contenido de los planes de ejecución se enumeran en Cleland DI y King WR Systems Analysis and Project
Gestión, 3ª ed. Nueva York, NY: McGraw-Hill; 1983, págs. 461–469; Allen J. y Lientz BP Systems
en acción. Santa Mónica, CA: Goodyear; 1978, pág. 95; Kerzner H. Gestión de proyectos, 10ª ed. Nuevo
York, Nueva York: Wiley; 2009, págs. 459–463.
3. Véase, por ejemplo, Cleland y King, Systems Analysis and Project Management, págs. 461–469.
4. Seymour Sarason en La creación de escenarios y las sociedades del futuro (San Francisco: Jossey-Bass; 1972)
argumenta la importancia de conocer los inicios, orígenes e historia de cualquier nuevo “escenario” antes de iniciar el trabajo;
especialmente importante es anticipar y prepararse para posibles luchas, obstáculos y
conflictos que se van a encontrar.
5. En los proyectos técnicos, los subsistemas y componentes, los "elementos de configuración" (CI), se identifican
durante los estudios preliminares de diseño en ingeniería de sistemas, descritos en el Capítulo 2.
6. Cleland y King, Análisis de sistemas y gestión de proyectos, pág. 258.
7. Archibald R. Gestión de programas y proyectos de alta tecnología. Nueva York, NY: John Wiley & Sons;
1976, págs. 65, 156.
8. Partes de esta sección adoptadas de Joy PK Total Project Management. Delhi: Macmillan India
Limitado; 1998, págs. 378–400.
9. Ibíd., págs. 378–380.
10. Ejemplos: NEC o New Engineering Contract, The Institution of Civil Engineers, The Engineering and
Contrato de construcción. Londres: Thomas Telford; 1995; y FIDIC, Federación Internacional de
Ingenieros consultores, Lausana, Suiza, http://www1.fidic.org.
11. Ver Whittaker R. Project Management in the Process Industries. Nueva York, NY: John Wiley & Sons; 1995.
Capítulo 6
Planificación del cronograma del proyecto y
Redes
No siempre puedes conseguir lo que quieres.
-Rocas rodantes
La programación de proyectos es más que simplemente mostrar tareas en un diagrama de Gantt. Es una
parte integral de la planificación del proyecto, un proceso a veces de prueba y error de ajuste de las tareas
de trabajo para satisfacer las limitaciones de recursos mientras se intenta cumplir con los plazos del proyecto.
Un diagrama de Gantt es bueno para comunicar el cronograma del proyecto, sin embargo, como herramienta
de planificación, es limitado porque no muestra explícitamente el impacto de retrasar actividades o cambiar
recursos en el proyecto general. Los métodos de red descritos en este capítulo no tienen esta limitación;
muestran claramente lo que sucede con el proyecto cuando se modifican los recursos o se retrasan las
actividades. Este capítulo y el siguiente analizan los enfoques basados en redes más utilizados para la
programación y planificación de proyectos.
6.1 Diagramas de red

Un diagrama de red muestra las actividades o tareas del proyecto y sus relaciones lógicas, es decir, las
relaciones de precedencia o dependencias entre las tareas.
La Figura 6.1 es un diagrama de red para “levantarse por la mañana y vestirse” (para un hombre). Los
recuadros representan actividades o tareas, y las flechas entre ellos muestran el orden en que deben
ocurrir, por ejemplo, ponerse la camisa antes de la corbata, ponerse los pantalones y los calcetines antes
que los zapatos, etc. (El diagrama de la Figura 6.1 tiene, por supuesto, fines ilustrativos). solamente;
¡cualquier intento de la vida real de planificar el trabajo con tanto detalle sería una microgestión y una
verdadera pérdida de tiempo!) Por lo general, las casillas en la red serían las actividades o paquetes de
trabajo definidos en la estructura de desglose del trabajo (EDT). Sin embargo, según el detalle deseado,
pueden representar cualquier nivel de trabajo, incluidos proyectos en un programa, subproyectos que
pertenecen a un proyecto o paquetes de trabajo en un proyecto, subproyecto o instalación específica.
Ver Capítulo 5
Las redes también muestran eventos. Como se describe en el Capítulo 5, un evento representa un
instante en el tiempo, un “anuncio” de que algo ha sucedido o sucederá.
Por lo general, significa el comienzo de una actividad o el final de una actividad. Una actividad de muy corta
duración también puede ser considerada como un evento. Un evento importante como la finalización de una
fase del proyecto es un hito.
Consulte el Apéndice A de este capítulo .
Dos métodos para construir diagramas de red son la actividad en el nodo (AON), también llamado
método de diagramación de precedencia (PDM), y la actividad en la flecha (AOA). Nuestra discusión se
centrará en el método AON más utilizado.
El método AOA se aborda en el Apéndice A de este capítulo.
Figura 6.1 Diagrama de red para levantarse y vestirse.
Diagramas de actividad en el nodo (AON) (o PDM)
La figura 6.2 muestra una actividad representada en el método AON. Cada nodo (caja) en la red
es una actividad; dentro del nodo se muestra información sobre la actividad, como su duración,
hora de inicio y hora de finalización.
Para construir una red AON, comience dibujando la primera actividad en el proyecto (por
ejemplo, "despertar"). Desde esta actividad, dibuje flechas hacia las actividades que suceden a
continuación. Como se muestra en la Figura 6.1, las actividades se agregan una tras otra, en
secuencia o en paralelo.
Pero antes de que pueda crear una red, primero debe conocer las relaciones de dependencia
entre las actividades. Para cada actividad necesita saber, por ejemplo:
• ¿Qué actividades son sus antecesoras? •

¿Qué actividades son sus sucesoras? •
¿Qué actividades se pueden hacer al mismo tiempo?
En una red, cada actividad, excepto la primera, tiene predecesores, o actividades que deben
completarse antes que ella; en la Figura 6.1, por ejemplo, “ponerse la camisa” es un antecesor de
“ponerse la corbata”. De manera similar, cada actividad, excepto la última, tiene sucesores, que
son actividades que no pueden comenzar hasta que la actividad actual finalice.
terminado; por ejemplo, "ponerse la corbata" es un sucesor de "ponerse la camisa".
Figura 6.2 Presentación AON para una actividad y sus eventos de inicio y finalización.
Es importante distinguir las relaciones de dependencia obligatorias y discrecionales :
• Obligatorio: la secuencia de dos actividades (cuya actividad debe preceder a la otra) no se

puede invertir. La relación entre “ponerse los calcetines” y “ponerse los zapatos” en la Figura
6.1 es un ejemplo. • Discrecional: la secuencia es una cuestión de elección. Por ejemplo,
"secar, cepillar el cabello" y "ponerse la chaqueta" se pueden hacer en cualquier orden. A veces
se puede eliminar una dependencia discrecional y superponer actividades para acelerar el
proyecto. Esto se llama seguimiento rápido.
En otro tipo de dependencia, llamada dependencia externa , una actividad depende de algún evento
o actividad que no está en la red. Por ejemplo, en la Figura 6.1 , la actividad "tomar paraguas" podría
incluirse al final de la red; dependería de un factor externo, el “pronóstico de lluvia”.
A veces, solo se utilizan los predecesores inmediatos para construir la red.

Un predecesor inmediato es una actividad que precede inmediatamente a otra actividad. Por ejemplo,
"despertar" y "desvestirse" son predecesores de "tomar una ducha", pero solo "desvestirse" es un
predecesor inmediato. (La lógica es que para “desvestirse” primero hay que “despertarse”). Dada la
información sobre los predecesores inmediatos, es fácil construir una red. Por ejemplo, la red de la
figura 6.1 se puede construir a partir de la información de la tabla 6.1. Comience con la primera
actividad del proyecto (la que se encuentra en la Tabla 6.1 sin un antecesor inmediato): "desnúdese",
luego conéctela a la actividad que tiene "desnúdese" como actividad principal .
antecesor inmediato, que es “ducharse”. Luego viene "ponerse la ropa interior"
y “secar, cepillar el cabello” ya que “tomar una ducha” es su antecesor inmediato.
Continuando de esta manera, el resultado es el diagrama de la figura 6.1.
Una vez que se construye la red, es fácil ver qué actividades son secuenciales
y cuales son paralelas. Actividades que tienen una relación predecesor-sucesor
(uno sigue al otro) se denominan actividades secuenciales ; “dúchate”, “ponte
ropa interior” y “ponerse la camisa” son ejemplos. Dos o más actividades independientes.
que se pueden realizar al mismo tiempo se denominan actividades paralelas . "Poner
camisa”, “ponerse los pantalones”, “secar, cepillar el cabello” y “ponerse los calcetines” son actividades paralelas
porque se pueden hacer todos al mismo tiempo o en cualquier orden. Una vez que la red
se ha completado, verifique que las relaciones entre las actividades estén completas
y consistencia lógica.
Otro ejemplo se da en la Tabla 6.2. El diagrama de red para este proyecto,
que se muestra en la Figura 6.3, comienza en la Actividad A (sin predecesores inmediatos). Ya que
Las actividades B y C tienen a A como su antecesor inmediato común, ambas son
conectado directamente a A. Entonces, debido a que D tiene dos predecesores inmediatos, B y
C, está conectado a ambos; de manera similar, también lo es la Actividad E. Cada nodo está etiquetado
identificar la actividad y su duración.
Cuadro 6.1 Actividades y predecesores inmediatos
Actividad Predecesores inmediatos Duración (segundos)

Desvestirse – 60
Tomar una ducha Desvestirse 600
ponte ropa interior Tomar una ducha 40
Secar, peinar el cabello Tomar una ducha 350
ponte la camisa ponte ropa interior 150
ponte los pantalones ponte ropa interior 60
ponte calcetines ponte ropa interior 45
ponerse corbata ponte la camisa 150
Ponte zapatos {Ponte los pantalones 100
{ Ponerse calcetines
ponte la chaqueta { Ponerse la corbata 10

{ Ponte zapatos
{ Secar, peinar el cabello
En general, la buena práctica dicta que una red siempre debe tener solo una
nodo de "inicio" y uno de "final", cada uno en un solo lugar en la red para representar el
inicio y fin del proyecto. Siempre que un proyecto tenga varios nodos al principio o
extremo de la red, entonces se debe insertar un solo nodo antes o después de ellos,
respectivamente. En la Figura 6.3, por ejemplo, un solo nodo final (con cero implícito
duración) se ha insertado después de las actividades D y E. Sin este nodo, el
el entendimiento erróneo podría ser que el proyecto finaliza al completar cualquiera de los dos
Actividad D o Actividad E. El nodo "fin" significa que el proyecto termina cuando ambos
D y E están completos.
Cuadro 6.2 Actividades y predecesores inmediatos
Actividad Predecesor inmediato

A –
B A
C A
D ANTES DE CRISTO
mi ANTES DE CRISTO
Figura 6.3 Diagrama AON correspondiente al proyecto de la Tabla 6.2.
Como ejemplo final, la Tabla 6.3 muestra los predecesores inmediatos de la

Proyecto LOGON usando paquetes de trabajo de la WBS en el Capítulo 5. Figura 6.4
muestra la red correspondiente.
Ver Capítulo 5
Las tablas 6.1, 6.2 y 6.3 para los ejemplos muestran solo los predecesores inmediatos de cada
actividad. Si bien hubiera estado bien mostrar todos los predecesores de cada actividad en estas
tablas, hubiera sido innecesario. Por ejemplo, si la tabla 6.2 hubiera mostrado todos los predecesores
de la actividad D (A, B y C), habría sido correcto pero también innecesario porque A es el predecesor
de B y C y, por lo tanto, enumerar A habría sido redundante. . El punto: una vez que las
dependencias se han verificado a fondo, solo se necesitan conocer los predecesores inmediatos
de cada actividad para construir una red.
Creación de una red de proyecto
Una red de proyecto se crea utilizando una lista de actividades de la EDT y sus predecesores. Si
se hace a mano, el proceso es de prueba y error y es posible que la red deba volver a dibujarse
varias veces antes de que sea correcta. Incluso si se hace por computadora, una buena práctica es
primero esbozar la red a mano para crear una red inicial ("de grano grueso") y luego ingresar los
datos en una computadora. Esto le da al director del proyecto una "sensación" intuitiva del proyecto.
Las actividades se pueden agrupar en subredes de nivel superior que representan, por ejemplo,
subproyectos, paquetes de trabajo o fases del proyecto. Las fases del proyecto normalmente se
llevan a cabo en serie, aunque, como se mencionó, las dependencias discrecionales se pueden
eliminar para que las fases se superpongan y se aceleren. Sin embargo, incluso cuando las fases
se superponen, sigue siendo necesario definir sus puntos de inicio y fin para que las fases puedan
ser autorizadas y los pagos por hitos aprobados.
Tabla 6.3 Actividades y predecesores inmediatos del proyecto LOGON
Descripción Predecesores inmediatos Duración (Semanas)

– 10
Diseño básico
Diseño de hardware para A H 8

Diseño de hardware para B H 6
Dibujos para B j 4
Especi fi caciones de software j 2
Compra de piezas para B j 4
Compra de piezas para A yo 4
Dibujos para A yo 5
Planos de instalación yo, j 5
Compras de software L 5
Entrega de piezas para B METRO 5
Entrega de piezas para A norte 3
Entrega de mercancías blandas q 3
Montaje de A O, S 1
Montaje de B k, r 5
Prueba A tu 2
Prueba B V 3
Instalación final P, W, X 8
F inalsystemtest Y, T 6
*
Paquetes de trabajo de WBS, figura 5.5.
Figura 6.4 Diagrama de red para el proyecto LOGON.
En proyectos extensos, la red puede mostrar actividades detalladas solo para las primeras fases y grupos aproximados
de actividades para las fases posteriores. A medida que una fase avanza hacia su finalización, se agregan detalles de las
actividades en la siguiente fase. Este enfoque por fases (llamado planificación de ondas continuas o elaboración
progresiva) reduce la complejidad de la red para un proyecto grande.
El software de computadora para crear redes es una conveniencia en proyectos pequeños pero una necesidad en
proyectos grandes. La red resultante debe revisarse en busca de precisión, omisiones y errores. Como regla general, la
red debe crearse solo después de que se haya desarrollado una declaración de alcance y una WBS adecuadas (es decir,
la lista de tareas de trabajo debe crearse antes, no mientras, se crea la red).
Posteriormente se puede desarrollar un diagrama de Gantt, como se explica más adelante.

6.2 La ruta crítica

Las redes de proyectos son herramientas importantes para la planificación y el control de
proyectos. Son útiles para determinar cuánto tiempo llevará el proyecto (la duración
esperada del proyecto), cuándo se debe programar el inicio y el final de cada actividad y
la probabilidad de completar un proyecto a tiempo.
En general, la duración esperada del proyecto, Te, se determina encontrando el
camino más largo a través de la red. Un “camino” es cualquier ruta compuesta por una o
más actividades conectadas en secuencia. La ruta más larga en la red desde el nodo
inicial hasta el nodo final se denomina ruta crítica y su longitud es la duración esperada
del proyecto. Si alguna actividad que forma parte de la ruta crítica (llamada actividad
crítica) demora más de lo planificado (debido a retrasos, interrupciones, falta de recursos,
etc.), todo el proyecto demorará más de lo planificado.
Figura 6.5 Red para el proyecto ROSEBUD.

Este concepto se ilustra en el siguiente ejemplo. La firma de Kelly, Applebaum, Nuzzo y

Earl, Assoc. (KANE) está trabajando en el proyecto Robotics Self Budgeting (ROSEBUD). La
figura 6.5 muestra la red. (Las partes (a) y (b) de la Figura 6.5 son muy similares; por ahora
mire solo (a).) La primera fase del proyecto es el diseño de sistemas (Actividad J), seguida por
las fases simultáneas de (1) compra, ensamblaje e instalación (Actividades M–V–Y), y (2)
especificación y compra de software (L–Q). Estas dos fases son seguidas por la última fase
del proyecto, prueba del sistema y prueba del usuario (W–X).
¿Cuánto tiempo llevará este proyecto? La primera actividad, J, toma 6 semanas; una vez
que se ha completado J, pueden comenzar las actividades en los caminos M–V–Y y L–Q. Las
actividades en la ruta M–V–Y tomarán 4 + 6 + 8 = 18 semanas, y las actividades en la ruta L–
Q tomarán 2 + 8 = 10 semanas. Debido a que la actividad J toma 6 semanas, la ruta M–V–Y
se completará en 6 + 18 = 24 semanas, y la ruta L–Q se completará en 6 + 10 = 16 semanas.
El diagrama implica que para que comience la Actividad W, tanto la Actividad Y como la
Actividad Q deben terminar. Por lo tanto, lo más temprano que puede comenzar la Actividad
W es después de 24 semanas. La actividad W se completará 1 semana después y la actividad
X se completará 1 semana después. Por lo tanto, la duración del proyecto ROSEBUD (indicada
como Te) es Te = 24 + 1 + 1 = 26 semanas.
Observe de nuevo en la figura 6.5(a) que hay dos caminos desde el nodo inicial (J) hasta
el nodo final (X). El camino más corto J–L–Q–W–X es de 18 semanas; el camino más largo,
J–M–V–Y–W–X, es de 26 semanas. En general, la ruta más larga, llamada ruta crítica, da la
duración del proyecto. La ruta crítica está resaltada en la figura; las actividades con los
recuadros "enmarcados" más oscuros son críticas.
Si es necesario reducir la duración del proyecto, cualquier esfuerzo de reducción (por
ejemplo, reducir el tiempo de una actividad) debe ocurrir en la ruta crítica.
Acortar cualquier actividad crítica en, digamos, 1 semana tendría el efecto de acortar la
duración del proyecto en 1 semana. Por el contrario, acortar las actividades que no están en
la ruta crítica no tendría ningún efecto sobre la duración del proyecto. Por ejemplo, si L o Q se
hubieran reducido en 1 semana, entonces la actividad Q se completaría en la semana 15 en
lugar de la semana 16; pero dado que la actividad W aún debe esperar hasta que finalice la
actividad Y, lo que no ocurrirá hasta después de la semana 24, no habría cambios en la
duración del proyecto.
Como se mencionó, la ruta crítica es importante por otra razón: cualquier retraso entre las
actividades en la ruta crítica resultará en un retraso en el proyecto.
terminación. Si alguna actividad crítica se retrasa, digamos, 1 semana, la finalización del proyecto se
retrasará 1 semana. Tenga en cuenta, sin embargo, que las actividades no críticas se pueden retrasar
un poco desde sus fechas más tempranas posibles sin retrasar el proyecto. De hecho, en el ejemplo,
las actividades no críticas L y Q se pueden retrasar hasta 8 semanas. Esto se debe a que normalmente
se completarán en 16 semanas, que es 8 semanas antes de que se completen las actividades en la
ruta M–V–Y, a las 24 semanas. En otras palabras, aunque las actividades en la ruta L-Q se pueden
completar a las 16 semanas, está bien si se completan a las 24 semanas. Por lo tanto, la ruta crítica
le muestra al gerente del proyecto qué actividades son más críticas para completar el proyecto a
tiempo. Para evitar retrasos, el director del proyecto debe centrarse en las actividades críticas.
Aunque la ruta crítica es importante, eso no significa que el director del proyecto pueda ignorar las
actividades no críticas. Cada vez que se retrasa una actividad no crítica, el camino al que pertenece
se alarga. Cuando la longitud de una ruta no crítica crece hasta exceder la ruta crítica, la ruta no
crítica anterior se vuelve crítica y la 1 Esta ruta crítica (antigua) ¡no crítica! En otras palabras, la ruta
cambia. el cambio puede ocurrir sin previo aviso y dejar al director del proyecto centrado en lascrítica
actividades equivocadas. Una solución es proporcionar señales de advertencia cuando las actividades
no críticas corren el riesgo de volverse críticas; esto se hace en el método de la cadena crítica ,
Ver Capítulo 7
La Figura 6.5(b) ilustra una actividad que “abarca” muchas otras actividades, llamada hamaca. La
actividad "Supervisar el progreso" es una hamaca porque cubre todas las actividades del proyecto
excepto "Prueba de usuario", lo que implica que el director del proyecto es responsable de supervisar
el progreso de cada actividad excepto "Prueba de usuario". La duración de una hamaca está
determinada por la duración de la ruta más larga de actividades sobre las que se extiende; en la
Figura 6.5(b) esto es 6 + 4 + 6 + 8 +1 = 25 semanas.
Tenga en cuenta, sin embargo, que aunque una hamaca se extiende por una parte del camino más
largo, no se considera una actividad crítica. (El término "hamaca" también se usa para describir una
actividad resumida; por ejemplo, un conjunto de actividades agregadas en un paquete de trabajo).
Un ejemplo final es la figura 6.6. Esta red tiene cuatro rutas que van desde el nodo inicial H hasta
el nodo final Z:
una.
H–J–P–Y–Z 35 semanas
b. H–J–K–V–X–Y–Z 42 semanas
C. H–J–M–R–V–X–Y–Z 47 semanas
d. H–J–L–Q–T–Z 32 semanas
Figura 6.6 Red de ejemplo que muestra la ruta crítica (creada con Project Scheduler 8.5).
El más largo de los cuatro caminos es el Camino c (indicado por los cuadros "sombreados");
por lo tanto, c es la ruta crítica y Te = 47. (En la Figura 6.6, observe la flecha entre X
y Z es innecesario: si Z sigue a Y e Y sigue a X, no hace falta decir que

¡Z debe seguir a X!)
Rutas Críticas Múltiples
¿Puede un proyecto tener más de una ruta crítica? En una palabra: sí. supongamos que
la duración de la Actividad L en la Figura 6.6 fue de 17 semanas en lugar de 2 semanas. En ese caso
las duraciones de la vía M–R–V–X–Y y la vía L–Q–T serían ambas de 25 semanas.
El proyecto tendría dos caminos críticos, ambos con una duración de 47 semanas, y el
el proyecto se retrasaría si ocurriera un retraso en cualquiera de las rutas críticas. Si,
sin embargo, la duración del proyecto tuvo que acortarse a menos de 47 semanas, sería
entonces será necesario acortar ambas rutas críticas.

Tiempos Tempranos: Comienzo Temprano (ES) y Fin Temprano (EF)
La programación de cada actividad en un proyecto implica, como mínimo, especificar cuándo se

debe iniciar y finalizar la actividad. El procedimiento de programación depende de si se supone que
el proyecto comenzará "en el Tiempo 0" o "en el Día 1". Hace la diferencia. El procedimiento que se
describe a continuación se basa en la suposición más común de "Tiempo 0"; El Apéndice B de este
capítulo describe la programación bajo el supuesto del "Día 1".
La fórmula para calcular el tiempo de finalización dada la hora de inicio y la duración es:
Hora de finalización = Hora de inicio + Duración
Estos tiempos de inicio y finalización de una actividad se representan en la red como "tiempos
tempranos": (1) el tiempo de inicio temprano (ES) y (2) el tiempo de finalización temprano (EF). Estos
tiempos representan los tiempos más tempranos posibles en que la actividad puede comenzar y
completarse.
Figura 6.7 Ejemplo de red que muestra ESs y EFs.
Pero el ES de una actividad depende de los EF de su predecesor inmediato, que se encuentra

sumando las duraciones de todas las actividades predecesoras junto con
el camino que conduce a la actividad en cuestión. Cuando una actividad tiene más de un predecesor inmediato,
el ES de la actividad estará determinado por el predecesor inmediato que tenga el último EF.
Todo esto se muestra en la Figura 6.7. Suponga que el ES para la primera actividad, H, es 0 (lo que significa
que el proyecto comienza en el momento 0). Dado que la duración de la actividad H es de 10 semanas, su
finalización anticipada, EF, debe ser la semana 10. Esto se determinó a partir de la fórmula
EF = ES + Duración
En la Figura 6.7, ES se muestra en la esquina superior izquierda de cada nodo y EF en la esquina superior
derecha.
Dado que el EF de la actividad H es la semana 10, el ES de la actividad J será la semana 10 y su EF será la
semana 16. La actividad J es el único predecesor inmediato de las actividades K, M y L, por lo que el ES de las
actividades K, M y L será la semana 16. La actividad V tiene dos actividades predecesoras inmediatas, K y R, lo
que significa que no puede comenzar hasta que se hayan completado ambas. El EF para la Actividad K es la
longitud del camino H–J–K, o 10 + 6 + 4 = 20; el EF para la Actividad R es la longitud del camino H–J–M–R o 10
+ 6 + 4 + 5 = 25. El ES para la Actividad V dependerá del EF posterior de sus dos actividades predecesoras
inmediatas, que es R Por lo tanto, ES para la actividad V es la semana 25.
Lo mismo sucede en la Actividad P: tiene dos actividades predecesoras inmediatas, I y J. Dado que el EF de
la Actividad I es 18 y el ES de la Actividad J es 16, el ES de la Actividad P debe ser la Semana 18. La Actividad
Y tiene tres actividades predecesoras inmediatas, W, P y X; La actividad X tiene el último EF, 33, por lo que el
ES para la actividad Y es la semana 33. Finalmente, el ES para la actividad Z es 41, el último EF de sus
actividades predecesoras inmediatas y Y y T. El EF de la actividad Z es la semana 47, que da la duración
esperada del proyecto, Te, 47 semanas.
En resumen, los ES y los EF se calculan haciendo un "paso hacia adelante" a través de la red. Cuando una
actividad tiene solo un predecesor inmediato, su ES es simplemente el EF del predecesor. Cuando una actividad
tiene varios predecesores inmediatos, su ES se basa en el último EF de todos los predecesores inmediatos.
Horas tardías: inicio tardío (LS) y finalización tardía (LF)
Como se discutió anteriormente, una actividad no crítica se puede retrasar sin retrasar la
proyecto; la pregunta es, ¿cuánto se puede retrasar? Para responder eso, debemos determinar los "tiempos
tardíos", es decir, los últimos tiempos permitidos en que se puede iniciar y terminar una actividad sin retrasar
la finalización del proyecto. Al igual que el ES y el EF, cada actividad tiene una hora de inicio tardía , LS, y
una hora de finalización tardía , LF.
Consulte la Figura 6.8. LS se muestra en la parte inferior izquierda de cada nodo, LF en la parte inferior
derecha.
Para determinar los tiempos de retraso, comience asignando una fecha de finalización objetivo, Ts, al
último nodo de la red. Para los proyectos que deben completarse lo antes posible, la fecha de Ts es la misma
que la Te calculada en un paso adelante: la EF de la última actividad. Para proyectos con una fecha de
vencimiento establecida por el cliente o el patrocinador, Ts es la fecha de vencimiento, no el valor de Te
calculado .
Para determinar los tiempos atrasados, comience en la última actividad en la red y haga un "paso hacia
atrás" a través de la red usando la fórmula:
LS = LF - Duración
En la Figura 6.8, comience con la Actividad Z. Si Ts es 47 semanas, entonces LF para la Actividad Z es

47 y LS es 47 – 6 = 41; es decir, la actividad Z debe comenzar en la semana 41 para que el proyecto finalice
en la semana 47. Continuando hacia atrás, para la actividad Y y la actividad T, el LF es 41 semanas y el LS
para Y es 41 – 8 = 33. Continúe retrocediendo así hasta cada camino, calculando LF y LS para cada actividad.
Figura 6.8 Ejemplo de red que muestra LF y LS.
Cada vez que encontramos una actividad que tiene múltiples caminos que conducen a ella (es decir,
tiene múltiples sucesores inmediatos), es el EF más antiguo (o más pequeño) de los sucesores inmediatos
lo que determina el LF de la actividad. Por ejemplo, la Actividad J tiene cuatro caminos que conducen de
regreso a ella (cuatro actividades sucesoras inmediatas):
• LF para la actividad P = 33 semanas (porque LS para la actividad Y es la semana 33); de este modo
LS para P es 33 – 5 = 28
• LF para la actividad K = 25 semanas (porque LS para la actividad V es la semana 25); de este modo
LS para K es 25 – 4 = 21 semanas
• De manera similar, LF para la Actividad M = 20, entonces LS = 20 – 4 = 16

semanas • LF para la Actividad L = 33, LS = 33 – 2 = 31 semanas.
Dado que el LS más pequeño (el más antiguo) es 16 para la Actividad M, el LF para la Actividad J es 16;
esta es la última hora en que se puede terminar la Actividad J para permitir que todos sus sucesores cumplan
con sus horas de inicio tardías y, por lo tanto, completen el proyecto para la fecha prevista de 47
semanas.
En resumen, los cálculos para LF y LS comienzan en el último nodo de la red del proyecto y van hacia atrás.
Cuando una actividad tiene más de un camino que conduce de regreso a ella, el valor más pequeño (primero) de LS
entre los sucesores inmediatos es la base para determinar el LF de la actividad. Habiendo completado los pases hacia
adelante y hacia atrás a través de la red, ahora tenemos los tiempos programados permitidos más tempranos y más
recientes para cada actividad en la red. Una vez que se han completado los cálculos de los pases hacia adelante y
hacia atrás, las duraciones de las actividades de la hamaca se vuelven evidentes.
Holgura total
Observe que para la mayoría de las actividades de la figura 6.8, los ES y los LS no son los mismos. La diferencia entre
LS y ES (o LF y EF) se denomina holgura total (también llamada "flotación total" o simplemente "holgura" o "flotación")
de una actividad. La holgura es la cantidad de desviación permitida entre el momento en que una actividad debe tener
lugar como muy tarde y cuando puede tener lugar como muy pronto. Es la cantidad de tiempo que se puede retrasar
una actividad sin retrasar el proyecto:
Holgura total = LS – ES
= LF – EF
En la Figura 6.8 , la holgura total para la Actividad H usando tiempos de inicio es 0 – 0 = 0 semanas; para la Actividad
I es 15 – 10 = 5 semanas, y así sucesivamente. Observe que las actividades en la ruta crítica previamente identificada
H –J–M–R–V–X–Y–Z tienen holgura cero; por lo tanto, estas actividades no pueden retrasarse por ninguna cantidad
sin retrasar el proyecto.
(El caso en el que las actividades críticas tienen cierta holgura se analiza más adelante). Las actividades que sí tienen
holgura (que, como resultado, son las actividades no críticas) se pueden retrasar desde sus fechas más tempranas
posibles por su tiempo de holgura sin retrasar la finalización del proyecto. . La holgura total se muestra en la Tabla 6.4.
Cuando las actividades se encuentran en secuencia en un camino, un retraso en las actividades anteriores resultará
en un retraso en las posteriores; esto es el equivalente a reducir la holgura para las actividades restantes. En la figura
6.8, por ejemplo, las actividades L, Q y T se encuentran todas en el mismo camino y todas tienen la misma holgura de
15 semanas. Pero si la actividad L se retrasa 5 semanas, entonces las actividades Q y T también se retrasarán 5
semanas y, por lo tanto, tendrán solo 10 semanas.

de holgura restante, no 15. Si, además, la Actividad Q se retrasa 10 semanas, entonces la

Actividad T no tendrá holgura restante y debe iniciarse inmediatamente después de la finalización
de Q. Habiendo agotado toda su holgura, las Actividades L, Q y T entonces todas se convertirían
en actividades críticas. Una vez que se agota la holgura, las actividades no críticas se convierten
en actividades críticas, lo que significa que cualquier retraso adicional en estas actividades
retrasará la finalización del proyecto.
La implicación práctica de la holgura es que le brinda al gerente de proyecto flexibilidad con
respecto a cuándo exactamente se pueden programar las actividades no críticas: se pueden
programar en cualquier momento, siempre que se encuentre en algún lugar dentro de la holgura
disponible, entre los tiempos ES y LF. Conocer la holgura es importante para administrar la carga
de trabajo de los recursos. Al comenzar algunas actividades lo antes posible y retrasar otras, la
carga de trabajo se puede suavizar; este concepto se discute más adelante. En general, cuando
hay suficientes recursos, las actividades no críticas suelen programarse lo antes posible (sus ES);
esto preserva la holgura y minimiza el riesgo de que actividades no críticas retrasen el proyecto.
(Otro método, llamado cadena crítica y discutido en el Capítulo 7, programa las actividades lo más
tarde posible).
Tenga en cuenta que las decisiones sobre cuándo exactamente programar una actividad
requieren saber tanto la hora tardía como la hora temprana de la actividad. La implicación es que
se debe realizar un análisis de red antes de crear el diagrama de Gantt. La mayoría del software
de gestión de proyectos desarrolla redes y diagramas de Gantt simultáneamente, aunque crean
diagramas de Gantt utilizando los primeros tiempos. Sin embargo, como se discutió, las actividades
no deben programarse necesariamente de acuerdo con los primeros tiempos.
Tabla 6.4 Análisis de tiempo del proyecto LOGON (de la Figura 6.8)
Holgura gratis
Mientras que la holgura total se refiere a la cantidad de tiempo que se puede retrasar una
actividad sin retrasar el proyecto, el término holgura libre se refiere al tiempo que se puede
retrasar una actividad sin retrasar el inicio de ninguna actividad sucesora. La holgura libre de
una actividad está determinada por la fórmula:
Holgura libre para actividad = ES (primer sucesor) – EF (actividad)
Por ejemplo, en la figura 6.8 , la actividad I tiene una holgura total de 5 semanas pero una
holgura libre de 0 semanas porque cualquier retraso retrasará el inicio de las actividades N, O y P.
La actividad O, por otro lado, tiene holgura libre de 2 semanas porque su EF de 23 puede
retrasarse a 25 sin retrasar el ES de su sucesor, Activity U, que es 25.

Conociendo la holgura libre, los gerentes pueden identificar fácilmente las actividades en las que las fallas
impactan inmediatamente en otras actividades. Cuando una actividad tiene holgura libre cero, cualquier
deslizamiento hará que al menos otra actividad también se deslice. Si, por ejemplo, la Actividad L se retrasa,
también lo harán Q y T, y los equipos que trabajan en Q y T (especificados en la matriz de responsabilidad)
deben ser notificados del retraso.
Al igual que con la holgura total, la cantidad de holgura libre disponible para una actividad asume que la
actividad comienza en su hora ES. Por lo tanto, la holgura gratuita para la Actividad O es de 2 semanas,
siempre que la Actividad I, su predecesora inmediata, se complete en EF = 18. Si la Actividad I se retrasa en
cualquier cantidad, entonces la holgura gratuita de la Actividad O se reducirá en esa cantidad.
la misma cantidad.
La holgura gratuita es importante porque muchas actividades están programadas para comenzar lo antes
posible y los recursos están reservados para estar disponibles en estas fechas. Si una actividad se retrasa,
puede retrasar otras actividades e interrumpir los horarios de todos los que planearon trabajar en esas
actividades. Además, estos retrasos amplían el período durante el cual se necesitan los recursos (por ejemplo,
equipos contratados a una tarifa diaria o por hora) y pueden dar lugar a sobrecostos.
La Tabla 6.4 resume estos conceptos, mostrando ES, LS, EF y LF, y la holgura total y libre para el proyecto
LOGON en la Figura 6.8. Observe que para las actividades en la ruta crítica, los tiempos de holgura total y de
holgura libre son cero.
El efecto de la fecha de vencimiento del proyecto
Al analizar la holgura total, asumimos que la fecha de finalización objetivo, Ts, era la misma que la fecha de
finalización esperada más temprana, Te. Pero, de hecho, la fecha de finalización objetivo se puede establecer
para que sea posterior o anterior a Te para reflejar los deseos de un cliente o partidario.
Establecer la fecha objetivo después de Te tiene el efecto de aumentar la holgura total para cada actividad
en el proyecto en la cantidad Ts – Te. Aunque ya no es cero, la holgura en la ruta crítica seguirá siendo la
holgura más pequeña en cualquier parte de la red. Por ejemplo, si la fecha objetivo de finalización del proyecto
en la figura 6.8 se aumentara a Ts = 50 semanas, entonces la holgura total en la tabla 6.4 sería 50 – 47 = 3
semanas para todas las actividades críticas y 3 semanas adicionales para todas las no críticas.
actividades.
Si Ts se establece antes que Te, los tiempos de holgura totales en todo el proyecto se reducirán en la
cantidad Ts – Te y las actividades a lo largo de la ruta crítica tendrán tiempos de holgura negativos . El
tamaño de esta holgura negativa es la cantidad de tiempo que se debe reducir la duración del proyecto
para cumplir con la fecha objetivo del cliente.
(Tenga en cuenta que la modificación de Ts no influye en los tiempos de holgura libres: estos dependen
de los tiempos de inicio temprano y finalización temprana, los cuales se ven afectados por la misma
cantidad al cambiar Ts).
En general, los proyectos deben completarse lo antes posible o en una fecha de vencimiento
predeterminada. Para los proyectos que deben completarse lo antes posible, el administrador del proyecto
realiza un cálculo de avance a través de la red y luego se compromete con el Te resultante. Para los
proyectos que deben cumplir con una fecha de vencimiento predeterminada, el gerente del proyecto
sustituye Ts en el último evento, luego trabaja hacia atrás a través de la red, notando la factibilidad de
acelerar las actividades en el proyecto para eliminar los tiempos de holgura negativos en la ruta crítica.
6.3 Conversión a cronogramas de calendario de Gantt
El uso de información de tablas como las Tablas 6.2 o 6.3 para crear una red con horas de
inicio y finalización de actividades es un procedimiento simple que no requiere decisiones de
gestión y puede ser realizado fácilmente por software de computadora. Sin embargo, para que
se puedan utilizar, las horas de la red deben convertirse en fechas (día, mes y año) en un
diagrama de Gantt o en un calendario real. Pero convertir los tiempos de la red a un
cronograma de calendario o Gantt no es un procedimiento simple y requiere decisiones de
administración.
Figura 6.9 Cronograma del proyecto LOGON ajustado por feriados y fines de semana.
Para empezar, el cronograma de calendario o de Gantt debe tener en cuenta el tiempo no

laborable , como los fines de semana, los feriados y las vacaciones. La Figura 6.9 muestra el
cronograma del proyecto LOGON producido por el software Microsoft Project e incorpora
tiempo libre para fines de semana y vacaciones.
Además, un cronograma de calendario debe dar cuenta de los asuntos que requieren
análisis y decisiones de gestión; Ejemplos incluyen:
• Restricciones de recursos: un paquete de trabajo se retrasa porque los recursos

necesarios no están disponibles o deben compartirse con otras actividades paralelas.
• Flujo de caja: la adquisición de un equipo costoso debe ser
retrasado para diferir el desembolso de efectivo, mejorar el flujo de efectivo o esperar

una mejora en el tipo de cambio.
• Riesgo de cambios: una actividad de diseño se pospone debido a cambios en el alcance
del proyecto, tecnologías en desarrollo, otras actividades de diseño. • Logística: se
retrasa la adquisición de un artículo voluminoso para la construcción hasta que se disponga
de espacio en el sitio de construcción.
El software de computadora puede generar fácilmente la red del proyecto, el diagrama de Gantt
y el cronograma del calendario, pero a menos que se tengan en cuenta problemas como los
enumerados anteriormente, el cronograma del proyecto será inviable, impracticable o demasiado
riesgoso. El punto es que la programación de proyectos implica más que simplemente crear una
versión generada por computadora de la red del proyecto; requiere análisis y criterio de gestión.
Por lo tanto, el diagrama de Gantt debe crearse solo después de que un análisis de red haya
determinado las fechas tempranas y tardías, y se hayan abordado los problemas y las limitaciones
que rodean al proyecto.
6.4 Reserva de Horario de Gestión

En la práctica común, el tiempo de finalización objetivo contractual o comprometido Ts no es
simplemente el tiempo de finalización estimado Te (más la asignación por tiempo no trabajado), sino
que es un tiempo posterior e incluye una reserva de programación de gestión. Este capítulo ha tratado
los tiempos de las actividades y las duraciones de los proyectos como si fueran fijos. Por supuesto,
cada proyecto es único y, hasta que no se completa, su duración no es más que una estimación (la
mejor suposición). Todas las estimaciones (de proyectos y de las actividades que los componen) están
sujetas a incertidumbre; cuanto más singular es el proyecto, mayor es la incertidumbre. Para tener en
cuenta esa incertidumbre, se agrega una reserva de cronograma de gestión a la duración estimada.
Esta reserva constituye un "amortiguador de seguridad" o "amortiguador de tiempo" para acomodar
cualquier retraso en el proyecto.
Los buffers de tiempo se discuten en el Capítulo 7.
Ver Capítulo 7
6.5 Relaciones alternativas 2

Los procedimientos de programación de red discutidos anteriormente asumen una
relación secuencial en la que el inicio de una actividad se basa en la finalización de sus
predecesores inmediatos. Tal es el caso que se ilustra en el diagrama de la figura 6.10 ,
donde la actividad B comienza al finalizar la actividad A. Esta relación estricta de
comienzo solo cuando los predecesores terminan se denomina fin a comienzo, FS. La
limitación de esta suposición es que excluye ese tipo de tareas que pueden iniciarse
cuando sus predecesoras solo se han completado parcialmente (pero no en su totalidad).
Por ejemplo, cuando una empresa se traslada a una nueva instalación, la actividad
“mudanza de empleados” debería poder comenzar después de que se haya realizado
parte de la actividad “mudanza de muebles”; es decir, “empleados para mudarse” puede
comenzar antes de que se haya completado su antecesor inmediato “muebles para
mudarse”. El método de diagramación de precedencia (PDM) permite esta y otras
situaciones similares. Además de la relación FS habitual, PDM también permite otras
relaciones, como inicio a inicio (SS), fin a fin (FF) y comienzo a fin (SF). También tiene
en cuenta los desfases entre los momentos en que deben iniciarse o finalizarse las
actividades. Estas relaciones se describen a continuación.
Figura 6.10 Ejemplo de relación FS.
Comienzo a Comienzo (SS)
En una relación SS entre dos actividades A y B, el comienzo de B puede ocurrir como

mínimo n días después del comienzo de su predecesor inmediato, A. Esto se representa
en la figura 6.11. El retraso de n días se llama lag. En el caso de aceleración en lugar de
retraso, se usa el adelanto en lugar del atraso (el adelanto es el
negativo matemático de lag).
Figura 6.11 Representación PDM de la relación SS con n días de retraso.
Usando el ejemplo de la Figura 6.10, suponga que la “mudanza de empleados” puede comenzar
5 días después del inicio de la “mudanza de muebles”; el diagrama de red y el diagrama de Gantt
asociado para las dos actividades aparecerían como en la figura 6.12.
Figura 6.12 Ejemplo de relación SS.
Final a Final (FF)
En una relación FF entre dos actividades A y B, B terminará a más tardar n días después de que
termine A. En la Figura 6.13 se muestra una ilustración en la que el acabado de las “líneas de
estacionamiento de pintura” (B) debe ocurrir dentro de los 5 días posteriores al final de la
“colocación de asfalto” (A). Dos o más actividades que deben terminar al mismo tiempo es una
relación FF con retraso cero.
Figura 6.13 Ejemplo de relación FF.
De principio a fin (SF)
En una relación SF, la finalización de la Actividad B debe ocurrir a más tardar n días después del
inicio de la Actividad A. Por ejemplo, "eliminar el sistema antiguo" (B) no puede finalizar hasta 25
días después de "probar el nuevo sistema" (A ) comienza. Esto se muestra en la Figura 6.14.
Figura 6.14 Ejemplo de relación SF.
Fin a comienzo (FS)
En una relación FS, la actividad B puede comenzar como muy pronto n días después de que
termine la actividad A. Por ejemplo, “derribar andamios” (B) no puede comenzar antes de los 5
días posteriores a la terminación de “paredes de yeso” (A). Esto se muestra en la Figura 6.15.
Tenga en cuenta que cuando n = 0, la relación FS se vuelve igual que el método de red AON tradicional
donde el comienzo de un sucesor coincide con la finalización de su último predecesor.
Figura 6.15 Ejemplo de relación FS.
Múltiples relaciones de PDM
Se pueden usar dos relaciones PDM en combinación. Tener tanto SS como FF es un caso
bastante común. Observe en el ejemplo que se muestra en la figura 6.16 que debido a que
B debe terminar a más tardar 10 días después de que termine A, el inicio de B debe ocurrir
en el día 10. Pero suponga que B es una actividad interrumpible (es decir, el trabajo en B
se puede detener y luego se reanuda). En ese caso, B podría comenzar 5 días después del
inicio de A y terminar 10 días después de que termine A. Esto se representa en la Figura
6.17. La suposición es que los 15 días de trabajo para B se realizarán en algún momento
dentro de los 20 días asignados entre los días 5 y 25.
Figura 6.16 Horario de actividad no interrumpible B.

Figura 6.17 Horario de actividad interrumpible B.
Observe que los 20 días asignados para la actividad B le dan a esa actividad dos posibles
valores de holgura, LS – ES = 5 o LF – EF = 0. PDM generalmente observa el valor de holgura
más pequeño, aquí 0.
Ejemplo 6.1: PDM en Proyecto ROSEBUD
La Figura 6.18 muestra el diagrama AON para el proyecto ROSEBUD y la Figura 6.19
muestra la "red de escala temporal" correspondiente, que es una forma de diagrama de
Gantt que muestra explícitamente las dependencias entre las actividades.
Figura 6.18 Diagrama AON para el proyecto ROSEBUD.

Figura 6.19 Red a escala temporal para el proyecto ROSEBUD.
La red ahora se modificará para permitir las siguientes relaciones especiales:
1. La actividad L puede comenzar 3 días después de que comience la actividad G, pero no puede
terminar hasta que G también termine.
2. La Actividad Y puede comenzar 2 días después de que comience la Actividad V, pero no puede
terminarse hasta al menos 6 días después de que termine la V.
3. La actividad W puede comenzar 5 días después de que comience la actividad Y, pero no puede
terminar hasta que Y también termine.
4. La actividad X no se puede iniciar hasta al menos 1 día después de que se complete la actividad W.
acabado.
La red PDM de la Figura 6.20 muestra estas relaciones. La figura 6.21 muestra la red de escala de tiempo
correspondiente asumiendo las primeras fechas de inicio y permitiendo actividades interrumpibles.

Figura 6.20 Red PDM para proyecto ROSEBUD.
Figura 6.21 Red de escala de tiempo para el proyecto ROSEBUD revisado para PDM.
Una red FS tradicional puede manejar relaciones donde FS > 0 mediante la creación de
actividades artificiales, pero no tiene forma de incorporar SS, FF o SF; por lo tanto, la ventaja obvia
de PDM es que permite una mayor flexibilidad de programación. La contrapartida es que las redes
PDM son más complejas y requieren mayor cuidado tanto en su creación como en su interpretación.
Debido a que las actividades no siguen una secuencia ordenada de FS, encontrar la ruta crítica y
los tiempos de holgura tampoco es tan simple.
Las relaciones de precedencia complejas también provocan resultados contrarios a la intuición. Para
ejemplo, en una red simple la forma de reducir el tiempo de finalización del proyecto es reducir la
duración de las actividades en la ruta crítica; Sin embargo, hacer lo mismo en una red PDM no
necesariamente acorta el proyecto. En el ejemplo anterior, la ruta crítica es G–M–V–Y–W–X.
Supongamos que decidimos reducir el tiempo en la Actividad Y. Debido al requisito de precedencia
de que Y no puede terminar antes de 6 días antes de que termine V, la fecha de finalización de Y
no se puede cambiar.
Por lo tanto, cualquier acortamiento de la duración de Y sirve para retrasar la fecha de inicio de Y.
Debido al requisito de precedencia, retroceder la fecha de inicio de Y da como resultado retroceder
la fecha de inicio de W y, como resultado, la fecha de inicio de X. En otras palabras, acortar la
actividad crítica Y en realidad provoca un aumento en la duración del proyecto. .
En general, la interpretación de una red PDM requiere más cuidado que las redes AON
ordinarias. Sin embargo, tal cuidado es relativamente intrascendente cuando la red PDM se crea
con un software de gestión de proyectos.
6.6 Programación con limitaciones de recursos
Si bien la gente piensa que la programación de proyectos significa programar tareas o

actividades de trabajo, es más importante pensar en ello como la programación de recursos.
Esto se debe a que cada actividad requiere recursos: personas, equipos, materiales, capital
de trabajo, etc., y cada vez que se programa una actividad, eso significa que también se
programan los recursos. Hasta ahora hemos asumido que dichos recursos siempre estarán
disponibles cuando se necesiten. Pero, por supuesto, los recursos no siempre están
disponibles, y cuando no lo están, el cronograma debe cambiarse para cuando estén
disponibles. Ahora consideramos la programación de proyectos cuando los recursos están
limitados y el efecto que tiene sobre la carga de trabajo y la duración del proyecto.
Disponibilidad de recursos y duración del proyecto
Muchas veces la disponibilidad de trabajadores calificados, equipo y capital de trabajo dicta si

las actividades pueden programarse en sus primeras horas o deben retrasarse. Esto es
especialmente cierto cuando varias actividades que requieren el mismo recurso se programan
al mismo tiempo. Cuando los recursos no son suficientes para satisfacer las necesidades de
todos ellos, algunas actividades deben retrasarse. La Figura 6.22 ilustra esto: (a) muestra la
red; (b) muestra el cronograma del proyecto, sin contabilizar los recursos. Suponga que las
actividades B y C requieren el mismo recurso, pero el recurso solo puede ser utilizado por una
de ellas a la vez. En ese caso, el cronograma debe ser revisado; (c) muestra dos alternativas.
Figura 6.22 El efecto de un recurso restringido en el cronograma.
En general, los proyectos tienden a tener limitaciones de recursos o de tiempo.

En un proyecto con recursos limitados, los recursos están limitados de alguna manera y la fecha de
finalización del proyecto está determinada por la disponibilidad de esos recursos.
La figura 6.22 es un ejemplo. En un proyecto con limitaciones de tiempo, la fecha de finalización del
proyecto es fija y se deben encontrar recursos suficientes para cumplir con esa fecha. Es posible que
un proyecto que tenga limitaciones de recursos y de tiempo no pueda cumplir con la fecha de
finalización prevista.
Asignación de recursos, carga de trabajo y carga de recursos
Los términos asignación de recursos, carga de trabajo y carga de recursos transmiten conceptos
relacionados pero diferentes. La asignación de recursos se refiere a la asignación de uno o más recursos
a una actividad o proyecto. La carga de trabajo se refiere a la cantidad de trabajo impuesto a un

recurso. La carga de recursos se refiere a la cantidad de un recurso en particular necesario para
realizar todas las actividades en un proyecto al que se asigna el recurso. Para un recurso
individual (como una persona), la carga de trabajo se puede especificar como un porcentaje del
potencial de carga de trabajo total del recurso o, más comúnmente, en unidades como horas de
trabajo. Para una instalación o categoría laboral (como un departamento de trabajadores con
habilidades específicas), la carga de trabajo se especifica en términos de número de trabajadores.
Dado que las personas en una categoría laboral (como "programador de computadoras") rara vez
tienen exactamente las mismas habilidades, normalmente es mejor asignar una persona específica
(un programador específico) en lugar de una categoría laboral a una actividad. La suposición
habitual al asignar personas de una categoría laboral es que todos en la categoría son igualmente
capaces; a menudo, sin embargo, después de que comienza el trabajo se hace evidente que no
todos son iguales.
La carga de trabajo que una persona puede manejar en un año se calcula como el número de
días laborables (excluidos los días festivos y todos los tipos de licencia) multiplicado por el
número de horas productivas (laborales) por día. Muchas empresas tienen pautas que restringen
la cantidad de horas que una persona debe trabajar en proyectos por semana, mes o año. En
una organización matricial, los gerentes funcionales son responsables de garantizar que el tiempo
de cada trabajador sea bien utilizado y que su carga de trabajo no exceda el máximo recomendado.
La carga de trabajo es siempre desde la perspectiva del recurso en particular; la carga, por el
contrario, es desde la perspectiva del proyecto. Es la cantidad de horas, personas u otras
unidades de un recurso en particular que se necesitan en un momento dado en un proyecto (o
en varios proyectos simultáneos). La carga de recursos es importante ya que prácticamente
todos los recursos son finitos y muchos son escasos. Así, la carga de recursos (cantidad total del
recurso necesario para un proyecto o proyectos en un momento dado) no puede exceder la
cantidad disponible. Cuando los recursos son escasos, su asignación está restringida y, a veces,
las actividades de un proyecto deben reprogramarse para adaptarse a la escasez. El ejemplo de
la figura 6.22 era uno de esos casos: las actividades B y C requieren el mismo recurso, pero el
recurso no se puede usar en ambas al mismo tiempo.
Los recursos disponibles en cantidad suficiente no plantean un problema y se pueden ignorar
para fines de programación (el aire es un ejemplo, a menos que el proyecto se lleve a cabo bajo
el agua o en el espacio exterior donde el aire es limitado).
Las siguientes secciones consideran dos casos donde el cronograma del proyecto debe ser
modificado para acomodar los recursos. El primero se denomina nivelación de recursos

en un proyecto con limitaciones de tiempo. En este caso, hay suficiente recurso para
completar el proyecto a tiempo; sin embargo, la cantidad del recurso necesario fluctúa a lo
largo del proyecto, lo que dificulta la gestión del recurso. El objetivo de la nivelación de
recursos es nivelar la cantidad del recurso necesario a lo largo del proyecto. El segundo
caso es la situación mencionada anteriormente, el proyecto con recursos limitados: no
tener suficientes recursos para realizar múltiples actividades al mismo tiempo.
Nivelación de un proyecto con limitaciones de tiempo
Debido a que la carga de un recurso en particular depende de la cantidad del recurso que
necesitan las actividades del proyecto y las fechas de inicio y finalización de esas
actividades, la carga de un recurso en particular tiende a variar a lo largo de un proyecto.
Un patrón común de carga de recursos en un proyecto es una acumulación constante en
la cantidad del recurso necesario, un pico y luego una disminución gradual. Por lo tanto,
se necesita relativamente poco del recurso al principio y al final del proyecto, pero se
necesita mucho en el medio. Este patrón es problemático para los gerentes funcionales
que son responsables de un grupo estable y uniforme de trabajadores y equipos porque da
como resultado que el grupo tenga poco trabajo o exceso de trabajo. Sin duda, sería mejor
una carga de trabajo relativamente uniforme en el grupo de recursos. Este es el propósito
de la nivelación de recursos: alterar el cronograma de las actividades individuales del
proyecto de modo que la carga de trabajo resultante para un recurso requerido sea algo
uniforme a lo largo del proyecto.
Figura 6.23 Horario y carga de trabajadores correspondiente para el proyecto LOGON.
La figura 6.23 muestra la carga de un recurso para el proyecto LOGON; el recurso es una
habilidad u oficio en particular (programador, trabajador del acero, etc.). La carga, en la parte
inferior de la Figura 6.23, se crea a partir del cronograma, en la parte superior de la Figura 6.23,
y los requisitos de mano de obra semanales de la Tabla 6.5; muestra semana a semana el
número de trabajadores necesarios en el proyecto. Por ejemplo, para las primeras 10 semanas
solo se programa la actividad H, por lo que la carga para esas semanas se mantiene en cinco
trabajadores (el requisito semanal para H). Durante las próximas 6 semanas, se programan las
actividades I y J, por lo que la carga se convierte en 4 + 8 = 12, y así sucesivamente.
Tabla 6.5 Requisitos laborales semanales del proyecto LOGON

Figura 6.24 Carga de trabajadores suavizada para el proyecto LOGON.
En la Figura 6.23, puede ver que la carga para el proyecto LOGON podría plantear un
problema porque fluctúa mucho, variando desde un máximo de 23 trabajadores en la
Semana 26 hasta cero trabajadores en las Semanas 24 y 25 (ya que las actividades R, S
y T están subcontratados y no requieren ningún trabajador). El problema que enfrenta el
gerente que asigna estos trabajadores a LOGON es qué hacer con el exceso de
trabajadores en períodos lentos y dónde obtener trabajadores adicionales en períodos pico.
Una forma de manejar el problema es ajustar la carga del trabajador para que esté más "nivelada".
Esto se hace haciendo “malabares” con las actividades, aprovechando los tiempos de inactividad y
retrasando las actividades no críticas después de sus primeros tiempos para reducir los picos de carga de
trabajo y llenar los valles de carga de trabajo. Por ejemplo, la carga de trabajo algo suavizada en la Figura
6.24 se logra retrasando las actividades P (y por lo tanto Q) por 2 semanas y U (y por lo tanto W) por 5
semanas.
Aunque la nivelación de recursos suele ser necesaria para reducir las fluctuaciones de la carga de
trabajo, aumenta potencialmente el riesgo de retrasos en los proyectos porque reduce el tiempo de inactividad.
Menos tiempo de inactividad significa mayor riesgo de que una actividad no se complete en la fecha de
finalización programada. En la Figura 6.24 , el retraso de las actividades U y W las hace críticas (no queda
holgura), por lo que cualquier retraso en cualquiera de ellas retrasará el proyecto.
División de actividades, tareas múltiples y puntos de entrega
En el ejemplo anterior, se podría haber logrado una carga aún más uniforme si las actividades se dividieran
y las piezas se programaran en diferentes momentos. Que esto sea factible depende de si un trabajo, una
vez iniciado, puede interrumpirse y reiniciarse más tarde. Como se discutió anteriormente, las actividades
del proyecto y los paquetes de trabajo se definen durante el proceso de la EDT, y estas actividades se
convierten en la base para establecer cronogramas, presupuestos, etc. Una vez que se ha definido una
"actividad" en la WBS, no se puede "dividir" arbitrariamente más adelante.
Figura 6.25 El efecto de dividir una actividad sobre la duración.

Si bien la división de actividades puede conducir a una carga más uniforme, la desventaja
es que puede generar una pérdida de tiempo y una mayor duración de las actividades. La
figura 6.25 ilustra cómo sucede esto. Ininterrumpidamente, la actividad comienza lentamente,
pero luego cobra impulso a medida que avanza. Dividido en pedazos, cada pedazo comienza
lentamente y nunca toma impulso. La suma de las duraciones de las piezas en (b) excede la
duración en (a). El efecto, conocido como multitarea, conduce a un ritmo de trabajo más
lento en promedio y prolonga la duración de la actividad. La moraleja es que, una vez que
se ha iniciado una actividad, por lo general es mejor terminarla sin interrupciones.
La multitarea, en la que el trabajo se detiene y luego se reanuda, no debe confundirse
con el trabajo que continúa sin interrupciones pero que tiene múltiples puntos de entrega. El
concepto de traspaso se ilustra en la Figura 6.26 , donde las actividades de diseño y
construcción se llevan a cabo sin interrupciones, aunque múltiples puntos de traspaso
(llamados "escalones") permiten que la actividad de construcción comience y continúe mucho
antes que la actividad de diseño completa (que abarca el Diseño A). + Diseño B + Diseño C)
se completa. Aunque las actividades parecen estar divididas (Diseño A, Diseño B, Diseño
C), en realidad no lo están, ya que no hay un desfase de tiempo entre ellas. El método acorta
la duración del proyecto y facilita la interacción entre diseñadores y constructores.
Figura 6.26 Múltiples puntos de entrega de una actividad ininterrumpida.
Nivelación de múltiples recursos
La nivelación es fácil para un solo recurso, pero puede ser difícil para varios recursos simultáneos.
Debido a que los paquetes de trabajo generalmente requieren recursos de más de una unidad funcional
o subcontratista, un cronograma que proporciona una carga nivelada para una unidad puede causar
sobrecarga o situaciones difíciles de administrar para otras. Por ejemplo, con base en los requisitos de
equipo semanales para LOGON que se muestran en la Tabla 6.5, el programa que proporciona la carga
de trabajadores algo nivelada en la Figura 6.24 produce la carga de equipo errática que se muestra en
la Figura 6.27. Un intento de nivelar la carga del equipo ajustando o retrasando las actividades
interrumpirá la carga de los trabajadores. Como puede verificar, el programa de la figura 6.23 que
produce la carga errática para los trabajadores produce una carga relativamente nivelada para el equipo.
Es imposible nivelar completamente la carga de todos los recursos a la vez. Los mejores resultados
surgen de aplicar el equivalente de programación del “óptimo de Pareto”; es decir, programe actividades
en el mejor interés del proyecto mientras trata de minimizar la cantidad de conflictos y problemas en los
departamentos y contratistas que suministran los recursos. Al considerar múltiples recursos
simultáneamente, concéntrese en nivelar los recursos "prioritarios", aquellos en los que las cargas
irregulares son las más costosas para la organización o desmoralizadoras para los trabajadores. Los
costos financieros y sociales asociados con la contratación, las horas extra y los despidos a menudo
dictan que se dé la máxima prioridad a los "recursos humanos", los trabajadores. Muchos paquetes de
software de proyectos realizan análisis de programación que permiten la nivelación simultánea de
múltiples recursos.
Retrasar las actividades es un método para nivelar los recursos; otros son para:
• Eliminar algunos segmentos de trabajo o actividades (reducir el alcance del

proyecto). • Recursos de sustitución. • Sustitución de actividades por actividades que
consuman menos recursos.
Por ejemplo, cuando los trabajadores más calificados no estén disponibles, elimine el trabajo que
requiere su experiencia o utilice trabajadores menos calificados. Estas opciones, sin embargo, podrían
comprometer el alcance o la calidad del trabajo y aumentar la
riesgo de que el proyecto no cumpla con los requisitos.
Figura 6.27 Carga de equipos para el proyecto LOGON.
Nivelación de un proyecto con recursos limitados
¿Qué sucede cuando la cantidad de personal, piezas de equipo o capital de trabajo disponible
restringe el cronograma? Este es un proyecto con recursos limitados.
Las actividades en el proyecto se deben programar de manera que la carga de un recurso en
particular al proyecto no exceda el máximo disponible. El enfoque difiere de la nivelación de recursos
con restricciones de tiempo porque el problema es el requisito máximo del recurso, no su variabilidad
de carga . A medida que se programe cada actividad, la suma de sus recursos requeridos más los
recursos requeridos para las actividades ya programadas al mismo tiempo debe compararse con el
máximo. El problema va más allá de la simple nivelación de recursos; implica reprogramar trabajos
o retrasarlos hasta que los recursos estén disponibles.
En el proyecto LOGON, por ejemplo, suponga que solo 14 trabajadores están disponibles en una
semana determinada. El programa "nivelado" en la Figura 6.24 da como resultado un máximo
carga de 15 trabajadores. En este caso, no es posible reducir la carga máxima a menos

de 15 y aun así completar el proyecto en 47 semanas. Para reducir la carga al máximo
de 14 trabajadores, algunas actividades deberán retrasarse más allá de sus fechas de
inicio tardías, lo que retrasará el proyecto. Con un problema como este algo tiene que
ceder, ya que no es factible satisfacer tanto la restricción de recursos como el plazo del
proyecto de 47 semanas. La figura 6.28 muestra un horario que satisface la restricción
de 14 trabajadores. Se determinó por prueba y error, asegurándose de no violar los
requisitos de precedencia ni el límite de 14 trabajadores. Observe que el proyecto ahora
requiere 50 semanas para completarse porque la Actividad X tuvo que retrasarse 3
semanas más allá de su fecha de inicio tardía.
Figura 6.28 Programación y carga de trabajadores correspondiente para el proyecto LOGON con restricción de 14 trabajadores.
Como muestra el ejemplo, un recurso necesario para múltiples actividades puede

dictar la duración del proyecto y anular el tiempo de la ruta crítica. Considere otro ejemplo
del proyecto LOGON. Suponga que un recurso importante del proyecto es un recurso técnico.
inspector que tiene las habilidades para inspeccionar y aprobar una variedad de actividades.
Sin embargo, su trabajo es exigente, lo que le impide trabajar en más de una actividad a la
vez. Suponga que las actividades en las que trabajará son H, J, P, K, L, V y X. Estas
actividades se destacan en la figura 6.29. Debido a que solo puede trabajar en ellos uno a
la vez, las actividades deben programarse secuencialmente.
La suma de las duraciones de estas actividades da el tiempo requerido para que ella las
inspeccione todas, 35 semanas. Agregue a esto los tiempos de las dos últimas actividades,
Y y Z, y el total es de 49 semanas. Por lo tanto, la duración del proyecto será de 49 semanas,
no de 47 semanas como lo determina la ruta crítica.
Figura 6.29 Actividades en el proyecto LOGON involucrando el recurso de inspector técnico.
Goldratt llama a la ruta que conecta las actividades que requieren el mismo recurso
restringido la cadena crítica (aquí, H–J–P–K–L–V–X más Y y Z) y 3 Back in Figure la
crítica (H– J–M–R–V–X–Y–Z). 6.22, la ruta crítica es A–C–D pero la cadena
distingue
críticade
eslaA–C–
ruta
B–D o A–B–C–D.
La importancia de esto es que cuando las actividades se deben realizar secuencialmente
debido a un recurso limitado, y cuando la suma de las duraciones de esas actividades, la
cadena crítica, excede la longitud de la ruta crítica, es la cadena crítica, no la ruta crítica . —
que establece la duración del proyecto. esto es mas
Ver Capítulo 7
La programación con recursos limitados implica decisiones sobre qué actividades se

pueden programar inmediatamente y recibir recursos, y cuáles se deben retrasar hasta que
los recursos estén disponibles. El software de gestión de proyectos utiliza procedimientos
basados en reglas simples (llamadas heurísticas) para programar con recursos limitados;
algunos de estos se discuten en el próximo capítulo.
El problema de recursos limitados también ocurre en organizaciones de proyectos
múltiples que extraen recursos de un fondo común. Para programar actividades para
cualquier proyecto, los gerentes deben dar cuenta de los recursos requeridos por otros
proyectos concurrentes. El resultado es que los cronogramas de algunos proyectos están
determinados en parte por cuándo se liberarán los recursos de otros proyectos de mayor prioridad.
6.7 Críticas a los métodos de red

Los métodos de red han sido criticados porque incorporan supuestos y producen resultados
que a veces no son realistas. Por ejemplo, asumen que un proyecto puede definirse
completamente por adelantado en términos de actividades identificables con relaciones de
precedencia conocidas. En muchos proyectos, sin embargo, no todas las tareas de trabajo
pueden anticiparse o definirse claramente al comienzo. Más bien, el proyecto “evoluciona” a
medida que avanza. Pero este es un problema con la planificación del alcance y la definición
de actividades, que afecta a todos los métodos de programación, no solo a las redes.
Un problema relacionado es que las actividades y duraciones en un programa a veces
requieren modificaciones periódicas; esto sucede cuando hay demasiadas actividades en la
red y no todas están bien definidas. Este problema se puede abordar creando inicialmente un
cronograma "aproximado" y luego desarrollando cronogramas más detallados en un enfoque
por etapas (discutido en el Capítulo 4) y evitando la "proliferación" de actividades, es decir,
manteniendo el número de actividades en el cronograma para un mínimo como se prescribe
en las pautas de definición de trabajo en el Capítulo 5.
Ver Capítulo 4 y 5
Otra crítica se relaciona con el hecho de que debido a que a veces es difícil demarcar una
actividad de la siguiente, el límite que separa las actividades es más o menos arbitrario. Esto
significa que los sucesores a veces se pueden iniciar antes de que se terminen los
predecesores, y los dos se "superponen" en la secuencia. Pero nuevamente, esto no es
realmente un problema ya que PDM permite la superposición de actividades y los puntos de
traspaso para tratar las actividades como si se superpusieran.
En resumen, las carencias de las redes son en realidad carencias en la definición del
proyecto. Se puede argumentar (e innumerables gerentes de proyectos lo atestiguan) que los
métodos de red, aunque no son perfectos, ofrecen un buen enfoque para analizar y crear
cronogramas de proyectos.
6.8 Resumen
La ventaja de las redes es que muestran claramente las interdependencias de las actividades
del proyecto y muestran el impacto de programación que tienen las actividades entre sí.
Esta función permite a los planificadores determinar las actividades críticas y los tiempos de
inactividad, lo cual es importante para la planificación y el control del proyecto. El
conocimiento de las actividades críticas les dice a los gerentes dónde enfocarse; el
conocimiento de la holgura les permite abordar los problemas de requisitos de recursos no
uniformes y recursos limitados. El método PDM da cuenta de una variedad de relaciones
entre las actividades del proyecto para reflejar mejor las realidades del trabajo del proyecto.
El siguiente capítulo describe otros métodos de programación de redes conocidos y más
avanzados: PERT, simulación, análisis de compensación de costo-tiempo (CPM) y gestión
de proyectos de cadena crítica (CCPM).
Lista resumida de símbolos
T mi Duración esperada del proyecto: la duración esperada del proyecto.
Fecha objetivo de finalización del proyecto: la fecha contratada o comprometida para la finalización
T s
del proyecto.
Comienzo anticipado de una actividad: el momento más temprano factible en que se puede iniciar
ES
una actividad.
Finalización anticipada de una actividad: el tiempo más temprano factible en que se puede completar
FE
una actividad.
Comienzo tardío: el último tiempo permitido en que se puede iniciar una actividad para completar el
LS
proyecto según lo previsto.
Finalización tardía: el último tiempo permitido en que se puede completar una actividad para
LF
completar el proyecto según lo previsto.
Duración de la actividad: la estimación más probable o mejor del tiempo para completar una actividad.
t
FS = Fin a inicio: una actividad puede comenzar no antes de n días después de que haya terminado
norte
su predecesor inmediato.
ES = Inicio a inicio: una actividad no puede comenzar antes de n días después del inicio de su predecesor
norte
inmediato.
SF = Comienzo a fin: una actividad puede finalizar a más tardar n días después de que haya
norte
comenzado su predecesor inmediato.
FF = De fin a fin: una actividad puede finalizar a más tardar n días después de que haya finalizado su
norte
predecesor inmediato.
Problema de ilustración de resumen

Apéndice A: diagramas AOA

El capítulo describió el método AON de diagramación de redes. Otro método de
diagramación es la actividad en flecha (AOA) o técnica de diagramación de flechas .
La principal característica que distingue a AOA de AON es la forma en que se indican
las actividades y los eventos en la red. La Figura 6.30 muestra la representación AOA
para una actividad y sus eventos.
El método AOA representa cada actividad como un segmento de línea dirigida (una
flecha) entre dos nodos (o círculos). Como se muestra en la Figura 6.30, los nodos
representan los eventos de inicio y finalización de la actividad, y la flecha en medio
representa la actividad misma. El número dentro de cada nodo simplemente identifica
el evento. Cada evento debe tener su propio número único. En el ejemplo, los números
14 y 15 se eligieron arbitrariamente. El nodo 14 significa "iniciar la actividad Y" y el
nodo 15 significa "terminar la actividad Y".
La longitud de la línea de flechas no tiene importancia en AOA. Al igual que en las
redes AON, una red AOA debe tener solo un evento de origen y un evento de terminal .
Todas las flechas deben apuntar generalmente hacia el extremo derecho de la red; las
flechas no pueden retroceder.4
Figura 6.30 Representación AOA para una actividad y sus eventos de inicio y finalización.
Al igual que en el método AON, las actividades siguen un orden secuencial definido
por sus predecesores inmediatos. Cuando una actividad tiene más de un predecesor
inmediato, la red debe demostrar que puede iniciarse solo después de que se hayan
completado todos sus predecesores inmediatos. Este es el propósito de un tipo especial
de actividad llamado “ficticio”.
Actividades ficticias
Se utiliza una actividad ficticia para ilustrar las relaciones de precedencia en las redes AOA.
Sirve solo como un "conector", no es una actividad "real" y no representa ni trabajo ni tiempo. El
siguiente ejemplo demuestra la necesidad de actividades ficticias en una red AOA. 5
Un ingeniero decide escribir un nuevo programa de computadora y comprar una nueva

computadora para ejecutarlo. Las actividades y sus dependencias se ilustran en la red AON en la
Figura 6.31. Las dependencias son:
1. Pague la computadora después de comprarla.

2. Instale el programa de computadora después de escribir el programa y después de comprar
el ordenador.
Figura 6.31 Diagrama AON.
Figura 6.32 Figura 6.31 convertida a diagrama AOA.
La red AOA para este proyecto se muestra en la Figura 6.32. Tenga en cuenta que para mostrar
las dependencias "instalar programa" después de "comprar computadora" y "escribir
programa de computadora” requiere una actividad ficticia (la flecha discontinua) entre el
nodo V y el nodo Y. Este programa ficticio vincula “instalar programa” con sus dos
predecesores inmediatos, “comprar computadora” y “escribir programa de computadora”.
Observe que la red general tiene solo un nodo de "Inicio" y un nodo de "Fin".
AON frente a AOA
Dado que las redes AON no requieren el uso de maniquíes, son más fáciles de construir
e interpretar que las redes AOA; como consecuencia, son más populares. Pero debido a
que los diagramas AOA usan segmentos de línea (las flechas) para representar el flujo
de trabajo y tiempo, se pueden convertir fácilmente en redes escaladas en el tiempo que
parecen diagramas de Gantt. Algunos paquetes de software de proyectos crean redes
escaladas en el tiempo y otros crean diagramas de red AOA y AON. Para un proyecto en
particular, solo se debe usar un método de red.
Apéndice B: Método de programación alternativo: Proyecto

Comienza en el día 1
La técnica de programación ilustrada en este capítulo es el enfoque habitual para introducir

la programación de red. Asume que el proyecto comienza en el tiempo cero y que una
actividad sucesora comienza inmediatamente después de completar todas sus predecesoras.
El método es simple y es matemáticamente correcto.
Sin embargo, algunos gerentes argumentan que, a efectos prácticos, el método es
incorrecto. Los gerentes de proyecto hablan del “primer día” del proyecto, no del “día cero”.
Por lo tanto, dicen, la hora de inicio del proyecto debe indicarse como el Día 1, no el Día 0.
Además, siempre que las actividades estén en serie, cada actividad sucesora comienza en
el período posterior a la finalización de sus predecesoras, no al mismo tiempo. Por lo tanto,
la red mostraría la hora de inicio anticipado de una actividad como el día (o semana)
posterior al día (o semana) de finalización anticipada de su último predecesor.
Siendo realistas, este enfoque tiene sentido.
Como ejemplo, consulte la Figura 6.33, que es la Figura 6.8 revisada para los supuestos
del "Día 1". La actividad H es la primera actividad del proyecto y dura 10 días. Usando el
esquema del Día 1, para la Actividad H ES = 1. Al hacer que el avance pase a través de la
red, computacionalmente EF = ES + Duración – 1. Esto, EF = 1 + 10 –1 = 10. El ES para
los sucesores de la Actividad H, Actividad I y Actividad J, es al día siguiente , es decir, ES
= 11.
Figura 6.33 Figura 6.8 ajustada por el supuesto del “Día 1”.
El uso de las suposiciones, por supuesto, también afecta los últimos tiempos. Haciendo
el paso hacia atrás a través de la red, LS = LF – Duración + 1. Así, para la Actividad I con
duración 8, si LF = 18 entonces LS = 18 – 8 + 1 = 11. El antecesor inmediato de la
Actividad I, la Actividad H, debe terminar el día anterior a este, entonces LF = 10 para Actividad
h
El esquema del Día 1 no afecta el cálculo de la holgura total, que sigue siendo la
simple diferencia entre las horas de inicio tempranas y tardías o las horas de finalización
tempranas y tardías. Sin embargo, cambia el cálculo de la holgura libre:
Holgura libre para una actividad = ES (primer sucesor) – EF (actividad) – 1
El software de programación de gestión de proyectos utiliza fechas reales, no tiempos

transcurridos, y el inicio del proyecto se indicará mediante la fecha del primer día (o semana)
del proyecto. En toda la red, las fechas de inicio de las actividades sucesoras se mostrarán
como el siguiente período (día o semana) después de las fechas de finalización de sus sucesores.
Preguntas y problemas de revisión
1. ¿Cuáles son las ventajas de las redes sobre los diagramas de Gantt?
2. Dibuja un diagrama de red de tus estudios universitarios, comenzando con la inscripción
y terminando con la graduación. Indique los cursos, proyectos y exámenes, así como las
relaciones de precedencia en su caso.
3. ¿Cómo se usa una WBS para crear una red y qué papel juega una declaración de
alcance?
4. ¿Se puede crear un diagrama de Gantt a partir de una red? se puede crear una red
de un diagrama de Gantt? ¿Cuál es la forma preferida? Explique.

5. ¿Por qué es vital conocer la ruta crítica? Explicar las diferentes formas en que se utiliza
la ruta crítica en el análisis de redes y la planificación de proyectos.
6. Explique la diferencia entre holgura total y libre.
7. Explique la diferencia entre ES, EF, LS y LF.
8. Considere cada uno de los siguientes proyectos:
una. Redactar y enviar una carta a un viejo amigo. b. Preparar

una comida de cinco platos (usted especifica el curso y los platos
servido).
C. Planificación de una boda para 500
personas. d. La construcción de una terraza
para su hogar. mi. Planificación, promoción y dirección de un
concierto de rock. F. Mudarse a otra casa o departamento. gramo.
Desarrollar, promover, fabricar y distribuir un nuevo alimento envasado. H.
Desarrollar e instalar un sistema de información computarizado, tanto
hardware como software.
i. Remodelación de un baño. j.
Añadir un dormitorio a una casa.
Ahora, responda las siguientes preguntas para cada proyecto:
1. Usando su experiencia o imaginación, cree una EDT.

2. Listar las actividades o paquetes de trabajo.

3. Muestre los predecesores inmediatos de cada actividad.
4. Dibuje el diagrama de red (usando el esquema AON).
9. Dibuje los diagramas de red AON para los siguientes cuatro proyectos:
1.

A –
B A
C A
D B
mi D
F D
GRAMO D
H E, F, G
2.

A –
B A
C A
D B
mi B
F C
GRAMO D
H D
yo GRAMO
j E, F, H, I
3.

A –
B A
C –
D –
mi D
F B, C, E
4.

A –
B –
C –
D C
mi A
F B
GRAMO mi
H F, G, J
yo A
j yo
10. Consulte la Figura 6.1 en el texto.
una. Si la persona quiere dormir más despertándose más tarde, ¿cuál

de los siguientes pasos sería útil?
i. Ponte los calcetines más rápido.
ii. Poner la corbata en el bolsillo para ponérsela más tarde.
iii. Ponte los zapatos más rápido.
IV. Compra un secador de pelo que funcione más rápido.
b. Calcule la flotación total y la flotación libre de la actividad “Póngase

medias."
11. Elimine los predecesores redundantes de las siguientes listas para que solo
quedan predecesores inmediatos.
una.
Actividad Predecesor
A –
B –
C –
D B
mi C
F A
GRAMO
B, D, C, E
H A, B, C, D, E, F, G
b. Actividad Predecesor
A –
B A
C A
D un, b
mi un, b
F A, C
GRAMO
ABCDEF
H A, B, C, D, E, G
C. Actividad Predecesor
A –
B –
C A
D A
mi B
F B
GRAMO
A, C
H A, B, D, E
1 B, F
j C, D, E, F, G, H, I
12. Use la Figura 6.5 (a) y (b) para dibujar diagramas de Gantt para ROSEBUD
proyecto.
13. Algunos proyectos tienen una fecha de vencimiento fija, mientras que otros deben terminarse
lo antes posible y el director del proyecto solo se compromete en la fecha de finalización
una vez que ella y su equipo de gestión del proyecto han programado el proyecto. Explique
cómo difiere el pase hacia atrás para estos dos tipos de proyectos.
14. Explique cómo es posible que pueda haber holgura en la ruta crítica.
¿Cuál es la implicación de la holgura negativa en la ruta crítica?
15. En el desarrollo de un sistema complejo nuevo (el primero de su tipo), el diseño de un
determinado subsistema tiene mucha holgura. Hay suficientes recursos disponibles para
un comienzo temprano o tardío. Discuta los pros y los contras de los comienzos tempranos
y tardíos. Considere el riesgo de retrasar el proyecto, el riesgo de cambios en el diseño, el
enfoque de gestión, el flujo de caja y cualquier otro factor que se le ocurra. 6 16. ¿Qué
limitaciones de las redes AON simples supera PDM? Qué
limitaciones no supera?
17. Dar ejemplos de aplicaciones de PDM. Tome un proyecto con el que esté familiarizado (o
inventa uno) y cree una red PDM.
18. Para la red PDM de la figura 6.20, calcule ES, EF, LS y LF para todos
actividades.
19. Para producir un manual, John tiene que escribir el texto, después de lo cual Ann tiene que
dibujar bocetos y componer el documento. John puede comenzar con cualquier sección del
libro (es decir, no tiene que comenzar con la Sección 1). El trabajo tiene que ser hecho
dentro de los 95 días. El siguiente diagrama de red muestra las relaciones de precedencia
y la duración de cada actividad.
Dibuje un diagrama de Gantt para mostrar cómo se puede hacer el trabajo dentro de los 95 días.
Tenga en cuenta que tanto John como Ann solo pueden atender una tarea a la vez.
7
20. ¿Por qué se prefiere nivelar los recursos a una gran fluctuación de la carga de trabajo?
¿Qué resultado negativo podría causar la nivelación de recursos?
21. Describa cómo la nivelación de recursos de un proyecto con recursos limitados difiere de la
nivelación de recursos en un proyecto con limitaciones de tiempo.
22. Los requisitos para analistas de sistemas y programadores para el proyecto GUMBY son los
siguientes:
una. Calcule ESs, LSs y tiempos de holgura totales. b.

Luego muestre las cargas de recursos separadas para analistas de sistemas y
programadores, suponiendo tiempos de inicio tempranos.
C. Suponga que la disponibilidad máxima semanal es de ocho analistas de sistemas y
cinco programadores. ¿Se pueden programar actividades para satisfacer estas
restricciones sin retrasar el proyecto?
23. Nivele los recursos para un proyecto con el diagrama de carga de trabajo a continuación. En
En el diagrama de fase temporal en la parte superior de la figura, las líneas punteadas indican
holgura. 8 Discuta los pros y los contras de las alternativas disponibles.
24. Discuta las implicaciones de la asignación de recursos para las organizaciones involucradas
en múltiples proyectos.
25. Demuestre que el programa de la figura 6.23 (que produjo una carga errática para los
trabajadores) produce una carga más equilibrada para el equipo que la que se muestra en la
figura 6.27.
26. Suponga que en la figura 6.20 todo es igual excepto que la actividad Y puede comenzar 4 días
después de que comience la actividad V, pero no puede terminar hasta 6 días después de
que termine la actividad V. Muestre cómo cambia esto los valores de ES, EF, LS y LF.
27. Para cada una de las siguientes tablas predecesoras:
• Dibujar una red AON correspondiente.

• Calcule ES y EF para cada actividad.

• Calcule LS y LF para cada actividad. Encuentre la ruta crítica.
• Determinar la holgura total y la holgura libre.
una.
Actividad Predecesor Duración
A 6
B 3
C A 9
D B 5
mi B 4
F D 2
GRAMO mi 8
b. Actividad Predecesor Duración

A 3
B A 8
C B 9
D C 3
mi B 2
F E, H 4
GRAMO A 6
H GRAMO 5
j D, F 1
C. Actividad Predecesor Duración

A 9
B A 2
C 8
D C 8
mi B, D 7
F mi 4
GRAMO C 4
H B, D, G 3
j 6
k j 10
METRO
GK 3
norte H, M 6
d. Actividad A Predecesor Duración

10
B A, E 9
C segundo, norte 15
D C 7
mi 5
F A, E 6
GRAMO
k, f 7
H GRAMO 12
j 12
k E, J 4
L k, f 11
METRO L 8
norte
E, J 7
1. ¿Se utilizaron redes para la programación? Si es así, describa las redes. Mostrar ejemplos.
¿Qué tipo de sistema de software de computadora se usó para crearlos y mantenerlos?
¿Quién era responsable de las entradas y operaciones del sistema? Describir las capacidades
del sistema de software.
2. ¿En qué momento del proyecto se crearon las redes? Cuando estuvieron
¿actualizado?
3. ¿Se utilizó software de programación?

4. ¿Qué se usó primero para desarrollar el cronograma: (a) una tabla como la Tabla 6.3, (b) un
diagrama de red, o (c) se dibujó primero el diagrama de Gantt? Comente el método utilizado.
5. ¿Se realizó toda la planificación detallada por adelantado o fue un enfoque por etapas?
¿seguido?
6. ¿Cómo se determinó e incluyó la reserva de horario en el horario?
7. ¿Se hizo visible la carga de trabajo sobre los recursos?
8. Si el proyecto se realizó dentro de una estructura matricial, ¿cómo se llevó a cabo la

comunicación entre los gerentes funcionales y de proyecto?
9. ¿El(los) gerente(s) funcional(es) asumió(n) la responsabilidad de la carga de trabajo en
¿recursos?
10. ¿Se realizó la nivelación de recursos?

11. ¿Hubo alguna queja sobre cargas de trabajo poco realistas?
6.1 Proyecto
9 Diagrama
de construcción
de red para un caso grande
La siguiente tabla enumera las actividades para construir un puente sobre una línea ferroviaria
operativa, similar al puente descrito en el Caso 10.3.
Actividad Duración
No. Descripción de la actividad (Meses) Predecesores
2 -
Una investigación detallada del sitio y una encuesta.
B Planificación detallada 6 A
C Diseño detallado 6 B
D Preparación del sitio 4 C
mi Reubicar servicios 3 C
F Realinear la electrificación de las vías aéreas 4 C, E
GRAMO
Construcción de vías de acceso y rampas. 1 D
H Pilotaje 2 GRAMO
j Construir cimientos y estribos. 3 H
k Construir soportes temporales para 2 F, G

soporte de la plataforma del puente durante la construcción
L Planificación de la fabricación de acero estructural. 2 C

componentes
Fabricar acero estructural
METRO 2 L
componentes (fuera del sitio)
norte
Transporte de componentes de acero estructural 1 METRO
y erigir en el sitio
PAGS
Levantar pilones y rellenar con hormigón. 2 j
Construya la cubierta del vano principal sobre elementos prefabricados

q 3 H, K, N, P
vigas de concreto
Instale tirantes y levante el puente

R 3 q
cubierta de soportes temporales
S Eliminar soportes temporales 1 R

T Instalación de sistema eléctrico 1 S
tu Pavimentación de carreteras (pavimentación) 2 S
V Acabados y accesorios 2 T, tu
W Puesta en servicio: transición 1 V
X Ceremonia y entrega formal 1 W
Y aprobación del proyecto 1 X
Z Cierre administrativo 1 W
0
Automóvil club británico
Fin del proyecto Y, Z
(hito)
(hito)
1. Construya un diagrama de red para el proyecto.

2. Hacer cálculos de pases hacia adelante y hacia atrás para indicar tiempos de inicio y
finalización tempranos y tardíos.
3. Indicar la ruta crítica.

4. Indicar la holgura total y libre de cada actividad.
5. Los siguientes recursos son necesarios para realizar las actividades.
Asignar los recursos a las actividades e indicar la carga de trabajo en
Los recursos. Si es necesario, ajuste el horario.
Nº de Recursos
Descripción de la actividad
actividad
A Investigación y estudio detallados Agrimensores, Ingeniería,

del sitio Gerente de proyecto
Gerente de proyecto,
B Planificación detallada Ingeniería, Construcción,
Contratistas
C Diseño detallado Ingeniería
D Preparación del sitio Construcción
mi Reubicar servicios Ingeniería
F Realinear la electrificación
de las vías aéreas Ingeniería, Contratistas
G Construcción de vías de acceso y rampas Construcción

H Pilotaje Construcción, Contratistas
Construir cimientos y estribos.
j Ingeniería, Construcción
Construya soportes temporales para

k soportar la plataforma del puente durante Ingeniería, Construcción
construcción
L Planificación de la fabricación de componentes

Ingeniería, Fabricante
de acero estructural.
Fabricación de componentes de
METRO
Ingeniería, Fabricante
acero estructural (fuera del sitio)
Transportar componentes de
norte
Transportista, Ingeniería
acero estructural y montarlos en el sitio
PAGS
Levantar pilones y rellenar con hormigón Construcción, Ingeniería
Construya la cubierta del vano principal sobre
q Ingeniería en Construcción
vigas de hormigón prefabricado
R Instale tirantes y levante el puente

Ingeniería en Construcción
cubierta de soportes temporales
S Eliminar soportes temporales Ingeniería en Construcción
T Instalación de sistema eléctrico Ingeniería en Construcción
tu Pavimentación de carreteras (pavimentación) Contratista, Ingeniería
V Acabados y accesorios Contratistas, Ingeniería
w Puesta en servicio - transición Ingeniería, Construcción,
Contratistas
X Ceremonia y entrega formal Ingeniería, Construcción,
Contratistas
Y Gerente de proyecto,
aprobación del proyecto
Ingeniería
Z Cierre administrativo Ingeniería
Automóvil club británico
Fin del proyecto Gerente de proyecto
Caso 6.2 Melbourne Construction Company, A
Bill Asher, planificador de Melbourne Construction Company, ha creado un

red de actividades para un proyecto hotelero que la empresa está planeando. Figura 6.34
muestra parte de la red y el número de días Factura estimada para cada
actividad. ¿Cuáles son las horas de inicio y finalización temprano y tardío para todos los
¿actividades? ¿Qué es lo más pronto que se completará esta parte del proyecto?
Figura 6.34 Red parcial para proyecto de construcción de hotel.
Los planificadores de proyectos a menudo se enfrentan a la incorporación de

restricciones que se originan fuera del proyecto. Por ejemplo, es posible que los materiales
no lleguen o que un contratista no esté listo hasta una fecha determinada, lo que impone
una restricción sobre cuándo puede comenzar el trabajo: una fecha de inicio no anterior a (SNET).
En otras ocasiones, un cliente, un inspector u otra persona requerirá que el trabajo se
complete en una fecha determinada, una fecha de finalización no posterior a (FNLT).
Bill se enfrenta a una situación así. Se le ha informado que los tableros de drywall no
llegarán al sitio hasta el día 15, es decir, Drywall tiene una fecha SNET de 15. ¿Qué
efecto tendrá este retraso en el proyecto?
Además, la propietaria de Melbourne Construction, Naomi Watts, quiere darle al
propietario del hotel un recorrido por el edificio, pero no antes de que se hayan imprimado
todas las paredes. Ha programado la gira el día 29, lo que impone un FNLT del día 28 en
Primer. Bill ahora enfrenta este requisito más la restricción de entrega de paneles de yeso.
¿Es posible terminar esta parte del proyecto?
el día 28? Si no, ¿qué ajustes se deben hacer en el trabajo para que puedan serlo? Bill se
reunirá con Naomi para discutir la situación.
Caso 6.3 Compañía Constructora de Melbourne, B
Una forma de acelerar un proyecto es acelerar las actividades en el camino crítico (discutido
en el Capítulo 7); otra es superponer actividades. Consulte el Caso 6.2, Melbourne
Construction Company, A: el diagrama de red de la Figura 6.34 asume relaciones de principio
a fin (o FS, lo que significa que los sucesores comienzan solo cuando finalizan los
predecesores) para las actividades de un piso del hotel.
Pero cada piso es lo suficientemente grande como para que la tripulación de una actividad
pueda comenzar cuando la tripulación de sus actividades predecesoras solo se completa
parcialmente (esto se denomina relación de inicio a inicio o SS, lo que significa que el inicio
de una actividad se retrasa con respecto al inicio de otra). sus predecesores por una cantidad
específica). En otras palabras, las actividades en secuencia pueden superponerse. Por lo
general, se utiliza un retraso de SS cuando las actividades sucesoras son más lentas que las
actividades predecesoras inmediatas (por lo que los sucesores no "alcanzarán" a los
predecesores y tendrán que esperar por ellos). Este es el caso de las actividades de plomería
y cableado que suceden a Frame in, por lo que Bill asigna un retraso de SS de 3 días entre
Frame in y Plumbing and Wiring (lo que significa que plomería y cableado puede comenzar 3
días después de que comience Frame in); él hace lo mismo para Cable, Teléfono y Sonido.
También es el caso de la instalación de paneles de yeso, que es más lenta que sus
predecesores inmediatos, por lo que Bill asigna un retraso de SS de 4 días entre la instalación
de paneles de yeso y sus predecesores. Esto se muestra en la Figura 6.35.
Ver Capítulo 7
Figura 6.35 Red con retardos insertados.
Cuando las actividades deben superponerse pero las sucesoras son más rápidas que
las actividades predecesoras, se puede utilizar un retraso de fin a fin (FF). Primer es más
rápido que Drywall, por lo que Bill inserta un retraso FF de 3 días entre ellos (es decir,
Primer debe terminar no antes de 3 días antes de que termine Drywall). Esto también se
muestra en la figura 6.35.
1. Compare el diagrama de Gantt usando la relación FS original con el diagrama

de Gantt usando los retrasos SS y FF. ¿En cuánto aceleran los retrasos el
proyecto? El cable, el teléfono y el sonido toman menos tiempo que Frame in;
¿Qué problema potencial podría ocurrir al superponerlos con Frame in?
2. Consulte el Caso 6.2, Melbourne Construction Company, A. Dado que la

entrega de paneles de yeso no se realizará hasta el día 15 y Naomi programó
un recorrido para el día 29, ¿cuál es el efecto de los retrasos SS y FF? ¿Podrá
Naomi realizar su gira según lo planeado?
Caso 6.4 Compañía Constructora de Melbourne, C
Bill Asher, programador de Melbourne Construction Company, ha creado una red de actividades
para un hotel boutique de tres pisos que la empresa planea construir en la península de
Mornington. Bill identificó siete actividades principales para cada piso. La figura 6.36 muestra la
red de actividades para los tres pisos y el número de días que estimó para cada actividad. Cada
actividad será realizada por un subcontratista diferente; como se muestra en la red, al completar
el trabajo en un piso, el subcontratista se mueve al siguiente piso.
1. ¿Qué es la ruta crítica? Según las estimaciones de Bill, ¿cuánto tiempo llevará
completar los tres pisos?
2. Los tiempos de actividad que se muestran en la Figura 6.36 se basan en las
estimaciones de Bill del total de horas de trabajo por actividad y una jornada laboral de 8 horas.
Por ejemplo, Bill estimó que Frame in requerirá 40 horas de mano de obra; dado un
día de 8 horas, obtuvo 5 días. Por lo tanto, todos los tiempos en la Figura 6.36
asumen que los subcontratistas asignan un “equipo” de un trabajador a cada actividad.
De acuerdo con estas estimaciones de tiempo, debería tomar 54 días completar cada
piso. Su jefa, Naomi Watts, dice que 54 días por piso es demasiado tiempo y que
para completar el proyecto a tiempo cada piso no debería tomar más de 35 días.
Figura 6.36 Red para tres plantas.
Mirando las siete actividades por piso, Bill ve que los 35 días por piso podrían lograrse si
cada actividad no tomara más de 5 días. Tiene la intención de señalar esto a sus
subcontratistas.
una. Las estimaciones de Bill suponen un trabajador por actividad. ¿Cuántos

trabajadores (el tamaño de la cuadrilla) deben asignar los contratistas a cada
actividad para que cada una tome como máximo 5 días?
b. Dado el aumento del tamaño de la cuadrilla, ¿cuánto tiempo llevará completar el
proyecto? Suponga que la duración de un día fraccionario calculado siempre se
redondea hacia arriba.
Notas finales
1. Duncan WR (ed.). Una guía para el cuerpo de conocimiento de la dirección de proyectos. Newton Square, Pensilvania: Proyecto
Comité de Normas del Instituto de Gestión; 1996. La definición de la ruta crítica en ediciones posteriores de
este documento no dice que la ruta crítica puede cambiar; eso no altera el hecho de que lo hace.
2. Para obtener más información sobre la programación de PDM, consulte Gestión de proyectos de Dreger JB: programación eficaz. Nueva York,
Nueva York: Van Nostrand Reinhold; 1992.
3. Cadena crítica EM de Goldratt. Gran Barrington, MA: North River Press; 1997.
4. Los bucles están permitidos en una forma especial de análisis de red llamada GERT.
5. Adaptado de Gordon GD y Villoria RL Network-based Management Systems (PERT/ CPM). Nuevo
York, Nueva York: John Wiley & Sons; 1967.
6. Steyn H. (editor). Gestión de proyectos: un enfoque multidisciplinario. Pretoria: Editorial FPM; 2003.
Reproducido con autorización.
7. Ibíd.
8. Ibíd.
9. Ibíd.
Capítulo 7
Programación y análisis de redes de
proyectos avanzados
Mire debajo de la superficie: nunca deje que las cualidades intrínsecas o el valor de una cosa se le escapen.
—Marco Aurelio, Meditaciones
Los métodos de programación discutidos en el Capítulo 6 asumen que los tiempos de

actividad son conocidos y fijos, aunque en realidad son estimados y variables. Este
capítulo analiza las implicaciones de los tiempos de actividad variables en los cronogramas
del proyecto y los métodos para manejar la incertidumbre en las fechas de finalización del
proyecto, a saber, PERT y Critical Chain. También cubre métodos para reducir la duración
del proyecto, comenzando con CPM.
7.1 Compensación de CPM y tiempo-costo
El método de la ruta crítica (CPM) es una forma de reducir la duración del proyecto
mediante la asignación de recursos entre actividades al menor costo. Desarrollado en 1957
por DuPont Company, Remington Rand y Mauchy Associates para la construcción de
plantas de DuPont, es un procedimiento matemático para estimar la compensación entre
1
la duración y el costo del proyecto.
2
Ejemplo 7.1: La casa construida en menos de 4 horas
Con recursos prácticamente ilimitados y una planificación y un control meticulosos,

un proyecto se puede realizar muy rápido. El 13 de marzo de 1999, el Capítulo de
Hábitat para la Humanidad de Manukau, Nueva Zelanda (una organización sin fines
de lucro dedicada a eliminar las viviendas pobres) estableció un récord para construir
una casa: 3 horas y 45 minutos.
Las especificaciones del proyecto incluían la construcción de una casa de cuatro
habitaciones sobre una base sólida (Figura 7.1). Incorporó paneles de pared
prefabricados, piso de madera, techos de hierro, techos, cubiertas y escalones. Las
puertas, las ventanas, el baño, el inodoro, la plomería y el sistema eléctrico tenían
que estar instalados y listos para usar; había que pintar paredes, techos y marcos de
ventanas; y hubo que instalar alfombras y cortinas. Las especificaciones también
incluían un camino a la puerta principal, un buzón, un tendedero instalado, una cerca
de madera alrededor del patio, tres árboles plantados y un césped nivelado con
césped. Los nuevos propietarios, el Sr. y la Sra. Suafoa, observaron la construcción
con sus cuatro hijos mientras CNN filmaba el evento. Se inspeccionó la casa, se
cumplieron todos los códigos de construcción locales y se entregaron las llaves a la familia.
Figura 7.1 La casa construida en menos de 4 horas.
Foto cortesía de Hábitat para la Humanidad.
¿Qué hizo posible la pronta finalización? Primero fueron abundantes recursos:

150 personas, en su mayoría voluntarios. El segundo fue una preparación exhaustiva
y meticulosa: 14 meses de planificación, incluidas muchas iteraciones de análisis de
red. El plan detallado se registró en hojas de tareas especiales para que los líderes
de equipo pudieran pasar tareas de uno a otro sin
deliberación. Con tanta gente y elementos de construcción en el sitio, el espacio de
trabajo era escaso. Se proporcionó una grúa para levantar el marco de madera del
techo sobre la estructura de la pared. El tercero fue un método computarizado
sistemático para planificar, monitorear y controlar el proyecto que incluía el método
de la cadena crítica y los amortiguadores de tiempo (explicados más adelante). Se
estimó que la tarea de instalación del baño tomaría 30 minutos, pero tomó 1 hora; el
exceso de 30 minutos se absorbió en la reserva del proyecto. Finalmente, el proyecto
hizo uso de tecnología adecuada, incluyendo paredes y componentes prefabricados.
Relación tiempo-costo
CPM asume que el tiempo para realizar una actividad de proyecto varía dependiendo de la
cantidad de recursos aplicados; a medida que se aplican más recursos (mano de obra, equipo,
etc.) a actividades particulares, la duración del proyecto se acorta. Agregar recursos acelera el
proyecto, pero también aumenta el costo del proyecto. Un elemento importante del costo del
proyecto es la mano de obra: un proyecto puede acelerarse agregando más mano de obra o
trabajando horas extras, pero de cualquier manera el costo aumenta.
Por lo general, el trabajo en cualquier actividad dada en un proyecto se realiza a un ritmo de
trabajo normal (usual y acostumbrado). Este es el punto “normal” que se muestra en la Figura 7.2.
Asociado a este ritmo está el tiempo normal, Tn, que es el tiempo que tardará la actividad en
condiciones normales de trabajo, y el coste normal, Cn, que es el coste de realizar la actividad
en el tiempo normal. (Se supone que el ritmo normal es el más eficiente y, por lo tanto, el menos
costoso . Extender el tiempo más allá del ritmo normal no producirá ahorros adicionales).
Figura 7.2 Relación tiempo-costo para una actividad.
Para reducir el tiempo para completar la actividad, se aplican más recursos en forma de personal
adicional o de horas extras. A medida que se aplican más recursos, la duración se acorta pero el
costo aumenta. Cuando se aplica el máximo esfuerzo para que la actividad pueda completarse en
el menor tiempo posible, se dice que la actividad se bloquea. La condición de choque (ver Figura
7.2) representa no solo la duración más corta, sino también la más costosa . (Para algunas
actividades, denominadas de proceso limitado, no existe una compensación entre el tiempo y el
costo, ya que requieren un tiempo específico que permanece constante independientemente de los
recursos. La fermentación del vino o el curado del concreto son ejemplos).
Como se ilustra en la Figura 7.2, los puntos para completar una actividad en condiciones
normales y condiciones de choque definen dos extremos teóricos. La línea que conecta los puntos,
llamada pendiente de costo, representa la relación tiempo-costo o la compensación marginal de

tiempo-costo para la actividad. La línea de costo-tiempo para cada actividad es única y puede ser
lineal, curvilínea (cóncava o convexa) o una función escalonada. Por lo general, se desconoce la
naturaleza de la relación tiempo-costo real; por lo tanto, a menudo se supone que es lineal,
3
en cuyo caso la fórmula para la pendiente del costo
es
donde Cc y Cn son los costos normales y de choque, respectivamente, y Tc y Tn son los tiempos
normales y de choque de la actividad. La pendiente de costo es cuánto costaría acelerar o ralentizar
la actividad.
Usando la fórmula, la pendiente del costo de la actividad en la Figura 7.2 es de $3K por semana.
Por lo tanto, por cada semana que se reduzca la duración de la actividad del tiempo normal de 8
semanas, el costo aumentará en $3K. Completar la actividad 1 semana antes (de 8 semanas a 7
semanas) alteraría el costo del costo normal de $9K al costo "acelerado" de $9K + $3K = $12K;
completarlo otra semana antes (en 6 semanas) aumentaría el costo a $12K + $3K = $15K;
completarlo una semana más antes (en 5 semanas) aumentaría el costo a $18K. De acuerdo con
la Figura 7.2, este último paso pone la actividad en el punto de choque, la duración más corta de la
actividad.
Reducción de la duración del proyecto: acorte la ruta crítica
El concepto de pendiente de costo se puede utilizar para determinar la forma menos

costosa de acortar un proyecto. La Figura 7.3 ilustra esto con un ejemplo. Comience con
el cronograma preliminar del proyecto asumiendo un ritmo normal para todas las
actividades; por lo tanto, el proyecto de la figura puede completarse en 22 semanas con
un gasto de $55 000. Supongamos que queremos acortar la duración del proyecto.
Recuerde del Capítulo 6 que la duración del proyecto es la longitud de la ruta crítica. En
general, para acortar el proyecto, se debe acortar la ruta crítica. Debido a que la ruta
crítica A–D–G es la ruta más larga (22 semanas), para acortar el proyecto es necesario
acortar una actividad crítica, ya sea A, D o G. Reducir una actividad aumenta su costo,
pero debido a que la reducción se puede realizar en cualquier parte de la ruta crítica, el
aumento se minimiza seleccionando la actividad con la menor pendiente de costo, que es la Actividad A.
Reducir A en 1 semana acorta la duración del proyecto a 21 semanas y agrega $2K (la
pendiente de costo de A) al costo del proyecto, llevándolo a $55K + $2K = $57K. Este
paso no cambia la ruta crítica, por lo que, si es necesario, se puede recortar una semana
adicional de A para reducir la duración del proyecto a 20 semanas por un costo de $57K
+ $2K = $59K.
Ver Capítulo 6
En general, cada vez que se acorta una actividad, es necesario verificar si hay cambios
en la ruta crítica. Por ejemplo, como muestra la red superior de la Figura 7.4 , el
acortamiento de A consume toda la holgura en la Ruta B–E y el proyecto ahora tiene dos
rutas críticas: A–D–G y B–E–G. Cualquier reducción adicional en la duración del proyecto
debe hacerse acortando ambos caminos porque acortar solo uno dejaría el otro en 20
semanas. La forma menos costosa de reducir el proyecto a 19 semanas es reducir tanto
A como E en 1 semana, como se muestra en la figura 7.4(b). El costo adicional es $2K
para A y $2K para E, por lo que el costo del proyecto resultante aumentaría a $59K + $2K
+ $2K = $63K. Este último paso reduce A a 6 semanas, su tiempo de choque, por lo que
no se pueden hacer más reducciones a A.
Si se desea una mayor reducción en la duración del proyecto, la forma menos costosa
de acortar ambas rutas es reducir G. De hecho, debido a que la holgura en la ruta no
crítica C-F es de 3 semanas y la duración del choque para G es de 2 semanas. (cual
significa que, si se desea, se pueden quitar 3 semanas de G), el proyecto se puede

reducir a 16 semanas acortando G en 3 semanas como se indica en la Figura 7.4(c). Esto
agrega $5K por semana, o 3 × $5K = $15K, al costo del proyecto. Con este último paso,
toda la holgura se agota en la ruta C–F y todas las rutas de la red (A–C–F, A–D–G y B–
E–G) se vuelven críticas.
Cualquier reducción adicional deseada en el proyecto debe acortar las tres rutas
críticas (A–C–F, A–D–G y B–E–G). Como quizás desee verificar, la forma más económica
de reducir el proyecto a 15 semanas es reducir 1 semana cada uno de E, D y C, lo que
eleva el costo del proyecto a $86K. Este paso reduce el tiempo de C a su tiempo de
choque, la duración más corta posible del proyecto. La secuencia de pasos se resume en
la Tabla 7.1.
Figura 7.3 Intercambio de costo-tiempo para una red de ejemplo.

Figura 7.4 Reducción de la duración del proyecto.
Cuadro 7.1 Reducción de la duración y aumento de los costos asociados
Actividades en CP con Costo Mínimo Costo del Proyecto

Paso Duración (Te,
semanas) Pendiente (K$)
1* 22 $55
2 21 $2 $55 + $2 = $57
3 20 $2 $57 + $2 = $59
4 19 A ($2), E ($2) $59 + $2 + $2 = $63
5, 6, $63 + $5 + $5 + $5 =
18, 17, 16 $5
7 $78
$78 + $2 + $5 + $1 =
8 15 E ($2), D ($5), C ($1) $86
* duración y coste en condiciones normales
Bloqueo del proyecto: duración más corta del proyecto
El procedimiento de tiempo-costo descrito determina qué actividades acelerar, paso a paso, para
reducir la duración del proyecto. Este procedimiento paso a paso eventualmente conducirá a la
duración más corta del proyecto y su costo asociado. Sin embargo, si queremos encontrar
directamente la duración más corta del proyecto y evitar los pasos intermedios, un procedimiento
más simple es bloquear simultáneamente todas las actividades a la vez. Esto, como muestra la
Figura 7.5 , también arroja una duración del proyecto de 15 semanas.
Sin embargo, el costo de bloquear todas las actividades, $104 000 (tabla en la figura 7.3) es
artificialmente alto porque, como se mostrará, no es necesario bloquear todas las actividades para
terminar el proyecto en el menor tiempo posible.
La duración del proyecto de 15 semanas es el tiempo a lo largo de la ruta crítica. Debido a que
la ruta crítica es la ruta más larga, otras rutas (no críticas) son de menor duración y, en consecuencia,
no tienen influencia en la duración del proyecto. Por lo tanto, es posible “estirar” o aumentar
cualquier actividad no crítica en cierta cantidad sin alargar el proyecto. De hecho, las actividades
no críticas se pueden estirar hasta que se agote toda la holgura de la red.
Figura 7.5 Red de ejemplo usando tiempos de caída.
Así como reducir el tiempo de una actividad desde el tiempo normal aumenta su costo,
extender su tiempo desde el tiempo de choque reduce su costo. Como resultado, al
extender las actividades no críticas, se puede reducir el costo total del proyecto de $104
000. Para hacerlo, comience con aquellas actividades no críticas que generarán los
mayores ahorros, aquellas con la mayor pendiente de costo. Observe en la figura 7.5(a)
que debido a que la ruta B-E-G tiene una holgura de 5 semanas, las actividades a lo largo
de esta ruta pueden extenderse hasta 5 semanas sin extender el proyecto. Se pueden
agregar tres semanas a la Actividad B (llevándola a la duración normal de 8 semanas) sin
alargar el proyecto. Además, se pueden agregar 2 semanas a E y 1 semana a D, ambos
sin cambiar la duración del proyecto. El costo final del proyecto se calcula restando los
ahorros obtenidos al extender B por 3 semanas, E por 2 semanas y D por 1 semana. desde el accidente
costo.
$104K—3($3K)—2($2K)—1($5K) = $86K
En general, para obtener la duración más corta del proyecto (lo que se denomina "crashing the project"),
primero bloquee todas las actividades, luego extienda las actividades no críticas con las mayores pendientes
de costo para agotar la holgura disponible y obtener los mayores ahorros de costos. Una actividad puede
extenderse hasta su duración normal, que se supone que es su tiempo menos costoso (Figura 7.2).
Costo total del proyecto
El análisis anterior se ocupó solo de los costos directos : costos inmediatamente asociados con actividades
individuales que aumentan directamente a medida que se les agregan recursos.
Pero más allá de los costos directos, el costo de realizar un proyecto también incluye costos indirectos , como
cargos administrativos y generales. (La distinción entre costos directos e indirectos se desarrolla en el próximo
capítulo). Por lo general, los costos indirectos son una función y son proporcionales a la duración del proyecto.
En otras palabras, los costos indirectos, a diferencia de los costos directos, disminuyen a medida que
disminuye la duración del proyecto.
La función matemática para el costo indirecto se puede derivar por estimación. Como ilustración, suponga
que los costos indirectos en el ejemplo anterior se aproximan mediante la fórmula
Costo indirecto = $10K + $3K(Te)
donde Te es la duración esperada del proyecto en semanas. La figura 7.6 muestra esto en la línea de costos
indirectos. También muestra el costo total del proyecto, que es la suma de los costos directos e indirectos.
Observe en la figura que al combinar los costos directos y los costos indirectos es posible determinar la
duración del proyecto que da el costo total más bajo del proyecto. Como muestra la Figura 7.6 , desde el
punto de vista de los costos, 20 semanas es la duración “óptima” del proyecto.
Además de los costos directos e indirectos, otros costos que influyen en el costo total del proyecto (y, por
lo tanto, en el Te óptimo) son los incentivos contractuales , como las multas o los pagos de bonificaciones.
Como se describe en el Apéndice de
Según el Capítulo 3, un cargo de penalización es una tarifa que se le impone al contratista

por no completar un proyecto a tiempo, y un pago de bonificación es una recompensa o un
incentivo en efectivo por completarlo antes de tiempo.
Ver Apéndice, Capítulo 3
Supongamos que en el ejemplo anterior el contrato especifica un objetivo de finalización para

la semana 18, con una bonificación de $2K por semana por terminar antes de las 18 semanas
y una penalización de $1K por semana por terminar después de las 18 semanas. La figura 7.7
muestra la influencia de estos incentivos en el costo total del proyecto. Tenga en cuenta que
incluso con incentivos, la duración óptima (para el contratista) es de 19 o 20 semanas, no las 18
semanas contractuales. Este ejemplo revela que un acuerdo de incentivo formal por sí solo no
es necesariamente suficiente para influir en el desempeño. Para que el incentivo motive al
contratista debe tener “dientes”; es decir, debe ser de suficiente magnitud con respecto a otros
costos del proyecto para afectar el desempeño del contratista.
Si la sanción se hubiera aumentado a $3K (en lugar de $1K) por semana por terminar después
de 18 semanas, la duración óptima del contratista habría cambiado a 16 semanas.
7.2 Variabilidad de la duración de la actividad
Suponga que está conduciendo hacia algún lugar y la Figura 7.8 muestra el
tiempo estimado que le llevará llegar allí. Si todo va bien (sin tráfico ni problemas
mecánicos), llegará en el menor tiempo posible: la "Duración optimista". Sin
embargo, lo más probable es que le lleve más tiempo: la "Duración más
probable" de 30 minutos. Por supuesto, podría tomar más tiempo que esto,
digamos, cuando el tráfico es
Figura 7.6 Compensación total de tiempo y costo para el proyecto.

Figura 7.7 Compensación de costo-tiempo para el proyecto con incentivos.
congestionado o, peor aún, te metes en un accidente. Observe en la figura que el área

debajo de la curva a la izquierda de la duración más probable es mucho menor que a la
derecha. Esto indica que las posibilidades de llegar más tarde que el tiempo más probable
son mayores que las posibilidades de llegar antes.
Figura 7.8 Variabilidad de la duración de la actividad.
Al igual que su tiempo de viaje, las duraciones de las actividades en un proyecto son
variables. La pregunta es, dado que no puede decir con seguridad cuánto tiempo tomará cada
actividad, ¿cómo puede decir cuándo se completará el proyecto?
Los enfoques de programación discutidos en el Capítulo 6 y la sección anterior sobre el
equilibrio entre tiempo y costo ignoran la variabilidad y suponen que las duraciones de las
actividades son constantes; esto se llama el enfoque determinista . En las siguientes secciones
consideramos lo que sucede cuando se asume que las duraciones de las actividades son
variables; esto se llama el enfoque estocástico .
Ver Capítulo 6
Efectos de variabilidad en una red de proyecto
La figura 7.8 se relaciona con una sola actividad. En un proyecto, algunas actividades se
completarán antes de lo esperado, otras más tarde. Sin embargo, cuando las actividades se
combinan en una red, las actividades tempranas y tardías no se promedian: en
En general, son solo las actividades tardías las que afectan la finalización del proyecto. Esta es una de
las razones por las que los proyectos tienden a tardar más de lo estimado.
Considere, por ejemplo, la Actividad A en la Figura 7.9. Si la actividad A toma más tiempo de lo
planeado, retrasaría la actividad B, lo que a su vez retrasaría las actividades C y D y, por lo tanto, la
finalización del proyecto. Sin embargo, suponga que la actividad A se termina antes de lo planeado. En
ese caso, ¿la actividad B comenzará antes? No necesariamente. Los recursos necesarios para la
Actividad B (personas y equipos) probablemente tendrán otros compromisos, lo que impediría que la
Actividad B comience antes de la fecha de inicio programada.
Considere un segundo ejemplo. La mayoría de las redes de proyectos constan de varias rutas que se
fusionan en una ruta crítica. La figura 7.10(a) ilustra un proyecto con dos rutas críticas, cada una con un
50 por ciento de posibilidades de terminar a tiempo. La probabilidad de que el proyecto termine a tiempo
es la probabilidad de que ambos caminos terminen a tiempo, o 0,5 × 0,5 = 0,25 o 25 por ciento. La figura
7.10(b) muestra la fusión de cinco caminos (que es típico de lo que sucede cerca del final de las redes del
proyecto), cada uno con un 50 por ciento de probabilidad de terminar a tiempo. La probabilidad de terminar
el proyecto a tiempo es ahora (0.5) sesgo de punto de fusión.
5
o alrededor del 3 por ciento. Este efecto se llama sesgo de fusión o
Figura 7.9 Actividades retrasadas si la actividad A se retrasa.

Figura 7.10 Actividades retrasadas donde los caminos se unen. (a) Dos caminos que se fusionan, cada uno con un 50 por ciento de posibilidades
de llegar a tiempo; (b) Cinco caminos que se fusionan, cada uno con un 50 por ciento de posibilidades de llegar a tiempo.
El Capítulo 6 abordó el hecho de que la ruta crítica no es necesariamente estable, pero puede
cambiar si las actividades no críticas toman más tiempo de lo planeado o si las actividades críticas
toman menos tiempo de lo planeado. Cualquiera de los casos puede resultar en que el proyecto se retrase.
Ver Capítulo 6
Se han desarrollado varios métodos para ayudar a lidiar con la incertidumbre acerca de cuándo se
completará un proyecto. Estos se abordan en las siguientes secciones, comenzando con PERT.
7.3 Pertenencia
El método PERT fue desarrollado para su aplicación en proyectos con duraciones de actividad
inciertas. Se originó durante el programa del Sistema de Misiles Polaris de la Marina de los
EE. UU., un ejemplo de un programa complejo de investigación y desarrollo con mucha
incertidumbre con respecto al tipo de investigación a realizar, las etapas de desarrollo
necesarias y qué tan rápido se pueden completar. Proyectos como este se definen al mismo
tiempo que se desarrollan los desarrollos tecnológicos y antes de que se hayan identificado
muchos de los problemas en tecnología, materiales y procesos. La duración del proyecto es
incierta y existe un gran riesgo de que exceda el tiempo de finalización previsto.
Para brindar mayor certeza al estimar la duración del programa Polaris, en 1958 se formó
un equipo de investigación de operaciones con representantes de la Oficina de Proyectos
Especiales de la Marina, la firma consultora de Booz, Allen y Hamilton, y el contratista principal
Lockheed Missile Systems. Idearon un método llamado PERT (Técnica de revisión y evaluación
de programas) que proporcionaría información sobre la probabilidad de terminar un proyecto
4 PERT es una herramienta
en un tiempo determinado. no para programar, per se, sino para analizar la red del proyecto (y
los horarios resultantes de la red).
Tres estimaciones de tiempo
Los métodos de red discutidos en el Capítulo 6 determinan la ruta crítica y los tiempos de
holgura utilizando las mejores estimaciones para la duración de la actividad. PERT, sin
embargo, aborda la incertidumbre en las duraciones mediante el uso de tres estimaciones de
tiempo para la duración de la actividad : optimista, más probable y pesimista. Presumiblemente,
las estimaciones se obtienen de las personas más informadas sobre las dificultades que
probablemente se encontrarán y la posible variabilidad en el tiempo; por lo general, son
expertos estimadores o las personas que realizarán o administrarán la actividad.
Ver Capítulo 6
Las tres estimaciones se utilizan para calcular el tiempo esperado para una actividad. El
rango entre las estimaciones optimistas y pesimistas es una medida de variabilidad que
permite hacer inferencias estadísticas sobre la probabilidad de que los eventos del proyecto
sucedan en un momento determinado.
Como se ve en la figura 7.11 , el tiempo optimista, a, es el tiempo mínimo para una
actividad: la situación en la que todo va bien y hay pocas esperanzas de terminar antes. Se
asume un nivel normal de esfuerzo sin personal adicional. El tiempo más probable , m, es
el tiempo que ocurriría con mayor frecuencia si se repitiera la actividad. Finalmente, el
tiempo pesimista , b, es el tiempo más largo para la actividad, la situación en la que se
encuentra la mala suerte en cada paso; incluye solo problemas probables en el trabajo y
eventos no muy improbables, como desastres naturales.
Las tres estimaciones de la Figura 7.11 están relacionadas en forma de una distribución
de probabilidad Beta con los parámetros ayb como puntos finales y m , el valor más
frecuente. Se usa la distribución Beta porque es unimodal (tiene un solo valor máximo) y
no es necesariamente simétrica, propiedades que parecen deseables para una distribución
de duraciones de actividad. Tenga en cuenta que mientras que la distribución de la figura
7.8 no tenía un punto final en el lado derecho, la curva de la figura 7.11 excluye eventos
muy improbables y tiene un punto final b.
Figura 7.11 Estimación de la duración de la actividad.
Con base en esta distribución y las tres estimaciones de tiempo, el tiempo medio o esperado , te, y
la varianza, V, de cada actividad se calculan con las siguientes fórmulas:
Como V = ÿ 2
, donde ÿ = desviación estándar,
ÿ = (b – a) /6
El tiempo esperado, te, representa el punto en la distribución de la Figura 7.11 con una
probabilidad de 50-50 de que la actividad se complete antes o después de te. En la figura
La varianza, V, es una medida de la variabilidad en la duración de la actividad:
Cuanto mayor sea V, menos confiable te y mayor será la probabilidad de que la actividad se
complete mucho antes o mucho más tarde que te. Esto simplemente refleja que cuanto más
separados estén ayb , más dispersa será la distribución y mayor será la probabilidad de que el
tiempo real difiera significativamente del tiempo esperado. En un trabajo de rutina (repetitivo),
las estimaciones de a y b son cercanas entre sí, V es pequeña y te es más probable.
Probabilidad de terminar en una fecha de finalización objetivo
El tiempo esperado, te, se usa de la misma manera que se usó la duración estimada de la
actividad en las redes determinísticas del Capítulo 6. Debido a que estadísticamente el tiempo
esperado de una secuencia de actividades independientes es la suma de sus tiempos
esperados individuales, la duración esperada del proyecto, Te, es la suma de las duraciones
esperadas de las actividades a lo largo de la ruta crítica; eso es
donde cada te es el tiempo esperado de una actividad en la ruta crítica.

PERT es un enfoque estocástico; por lo tanto, la duración del proyecto no se considera un
punto sino una estimación sujeta a incertidumbre debido a las incertidumbres de
la duración de las actividades a lo largo de la ruta crítica. Dado que la duración del proyecto Te se
calcula como la suma de las duraciones esperadas de las actividades, se deduce que Te también
es un tiempo esperado. La duración del proyecto se puede considerar como una distribución de
probabilidad con un promedio de Te. Por lo tanto, la probabilidad de completar el proyecto antes
de Te es del 50 por ciento, al igual que la probabilidad de completarlo después de Te.
La variación en la distribución de la duración del proyecto se calcula como la suma de las
variaciones de las duraciones de las actividades a lo largo de la ruta crítica:
donde V es la varianza de una actividad en el camino crítico.

Estos conceptos se ilustran en la red AOA en la figura 7.12.
Figura 7.12 Red PERT con duraciones de actividad esperadas y variaciones de actividad.
Se supone que la distribución de la duración de los proyectos es la curva normal y familiar en

forma de campana. Dada esta suposición, es fácil determinar la probabilidad de
cumplir con cualquier fecha de finalización objetivo del proyecto especificado Ts.
Como ejemplos, considere dos preguntas sobre el proyecto que se muestra en la Figura 7.12: (1) ¿Cuál es la
probabilidad de completar el proyecto en 27 días? (2) Si queremos estar 95 por ciento seguros de comprometernos
con la duración del proyecto, ¿qué duración debemos citar? Para responder a estas preguntas, invocamos la
suposición de que la distribución de la duración del proyecto es una distribución normal estándar y comenzamos
determinando el número de desviaciones estándar, z, que separan Ts de la duración esperada del proyecto, Te. La
fórmula para el cálculo es:
Para responder a la pregunta 1, utilice Ts = 27 días. A partir de la red, la duración esperada del proyecto, Te, se
calcula como 29 días. Por lo tanto
La probabilidad de completar el proyecto dentro de los 27 días es igual al área bajo la curva normal a la izquierda de
z = –0.82. Con referencia a la Tabla 7.2(a), la probabilidad es de alrededor del 21 por ciento.
Para responder la pregunta 2 (duración con un 95 por ciento de certeza): usando la Tabla 7.2(b),
para una probabilidad de 0,95 el valor z es 1,6. Como antes, calculamos
Tabla 7.2 Función de distribución normal para completar un proyecto por tiempo Ts
[a] Probabilidad de que el proyecto se complete antes de la duración esperada (el proyecto probablemente terminará
tarde si se compromete a la fecha Ts ) duración.

Valor Z Probabilidad Valor Z Probabilidad

0 .50 ÿ1,2 .12
ÿ0,1 .46 ÿ1,3 .10
ÿ0,2 .42 ÿ1,4 .08
ÿ0,3 .38 ÿ1,5 .07
ÿ0,4 .34 ÿ1,6 .05
ÿ0,5 .31 ÿ1,7 .04
ÿ0,6 .27 ÿ1,8 .04
ÿ0,7 .24 ÿ1,9 .03
ÿ0,8 .21 ÿ2,0 .02
ÿ0,9 .18 ÿ2,1 .02
ÿ1,0 .dieciséis ÿ2,2 .01
ÿ1,1 .14 ÿ2,3 .01
[b] Probabilidad de que el proyecto se complete más tarde de la duración prevista

(el proyecto probablemente terminará antes si se compromete con la fecha Ts ).
Valor Z Probabilidad Valor Z Probabilidad

0.0 .50 1.2 .88
0.1 .54 1.3 .90
0.2 .58 1.4 .92
0.3 .61 1.5 .93
0.4 .66 1.6 .95
0.5 .69 1.7 .96
0.6 .72 1.8 .96
0.7 .76 1.9 .97
0.8 .79 2.0 .98

0.9 .82 2.1 .98
1.0 .83 2.2 .99
1.1 .86 2.3 .99
En otras palabras, es "altamente probable" (95 por ciento probable) que el proyecto sea
completado dentro de los 33 días. Tenga en cuenta que dado que estamos trabajando con valores que son
meras estimaciones, no tiene sentido calcular cifras de gran precisión.
Caminos casi críticos
El procedimiento PERT ha sido criticado por proporcionar resultados demasiado optimistas, un

crítica justificada ya que no tiene en cuenta el efecto del sesgo del punto de fusión.
Por ejemplo, la Figura 7.12 tiene dos caminos que son “casi críticos” en longitud. los
la varianza de estos caminos es lo suficientemente grande como para que cualquiera de los dos pueda volverse crítico fácilmente por
superando los 29 días de la ruta crítica original. De hecho, como usted puede desear
verificar mediante el procedimiento estadístico descrito anteriormente, la probabilidad de no
completar la Ruta (a) (A–F–J) y la Ruta (e) (D–E–H–I–K) dentro de los 29 días es 34
por ciento y 29 por ciento, respectivamente. Así que hay más que una pequeña posibilidad de que
estos caminos podrían volverse críticos. La advertencia es: no sobreenfatice la
camino crítico e ignorar los caminos casi críticos, caminos que podrían por sí mismos
volverse críticos y poner en peligro la fecha de finalización del proyecto.
Además, la probabilidad del 50 por ciento de completar el proyecto dentro de 29
días, como se presume con la distribución normal, es demasiado optimista. porque todos
Las actividades en la red deben completarse antes de que se complete el proyecto, el
probabilidad de completar el proyecto dentro de 29 días es la misma que la probabilidad
de completar los cinco caminos en 29 días. Aunque la probabilidad de
completar las Rutas (b) y (d) dentro de los 29 días está cerca del 100 por ciento, el
probabilidades de completar las Rutas (a) y (e) dentro de ese tiempo es 66 por ciento y 71 por ciento
por ciento, respectivamente, y la probabilidad de completar (c), la ruta crítica, es 50
por ciento. Entonces, la posibilidad de completar todos los caminos dentro de los 29 días es el producto de la
probabilidades 1,0 × 1,0 × 0,66 × 0,71 × 0,5, o menos del 25 por ciento.
Cumplir la fecha objetivo

Claramente, una forma de aumentar la confianza en el cumplimiento de una fecha objetivo es retrasarla,
pero cuando la fecha objetivo no se puede retrasar, la alternativa es revisar la red del proyecto y acortar las
rutas críticas y casi críticas. Las posibles formas de hacer esto incluyen: 5
1. Busque oportunidades para acelerar (superponer) actividades en la ruta crítica, lo que implica
programar una actividad para que comience antes de que se completen sus predecesoras. Una
alternativa es dividir las predecesoras en subactividades y comenzar la sucesora cuando solo se
hayan completado algunas de las subactividades predecesoras.
2. Agregar recursos a actividades críticas y casi críticas mediante la transferencia de recursos de

actividades con grandes tiempos de inactividad.
3. Sustituya las actividades que consumen mucho tiempo por otras que lo requieran menos, o elimine
actividades que no son absolutamente necesarias.
Cada uno de estos tiene inconvenientes. El seguimiento rápido aumenta los riesgos de cometer errores y
tener que repetir actividades. Agregar recursos para acelerar las actividades aumenta el costo, y transferirlos
entre actividades requiere cambiar los planes y los cronogramas, aumenta los costos administrativos y
molesta a los gerentes funcionales que suministran los recursos. La última alternativa, la sustitución o
eliminación de actividades, compromete el desempeño del proyecto, especialmente cuando se trata de hacer
“recortes” o utilizar materiales de peor calidad o mano de obra menos calificada.
6
Críticas al PERT
El método PERT ha sido criticado por sus deficiencias. Por ejemplo, ignora el comportamiento humano y
supone que una actividad comenzará tan pronto como se completen las actividades anteriores, ignorando
que es posible que los recursos no estén disponibles o que las personas procrastinen. Además, supone que
las duraciones de las actividades son independientes, aunque a menudo no lo son. Cada vez que se
transfieren recursos de una actividad a otra, se modifica la duración de ambas actividades.
PERT también supone que tres estimaciones de actividad son mejores que una. Sin embargo, a menos
que se basen en buenos datos históricos, las tres estimaciones siguen siendo conjeturas, que podrían no
mejorar con una sola "mejor" conjetura. Una ventaja de la
La estimación pesimista, sin embargo, es que permite la posibilidad de contratiempos, que una sola
estimación no puede.
La precisión de las estimaciones a menudo depende de la experiencia. Siempre que se pueda
formar una base de datos basada en la experiencia de actividades similares de proyectos anteriores,
se puede desarrollar un "historial" para cada tipo de actividad que se puede usar para estimar la
duración de futuras actividades similares. De hecho, la confianza en buenos datos históricos para
estimar los tiempos hace que el método PERT sea más apropiado para proyectos que son algo
"repetibles" y menos para los primeros proyectos de su tipo. Debido a esto, el método PERT tiende a
usarse en proyectos de construcción e ingeniería estandarizados, pero rara vez en otros lugares.
Algunas de las deficiencias de PERT se abordan mediante simulación.
Simulación Monte Carlo de una red PERT
La simulación por computadora de Monte Carlo es un procedimiento que tiene en cuenta los efectos de
las rutas casi críticas y el sesgo del punto de fusión. La ruta crítica se calcula a partir de las duraciones
de las actividades que se seleccionan aleatoriamente de las distribuciones de probabilidad.
El procedimiento se repite miles de veces para generar una distribución de duraciones de proyectos.
Brinda un "tiempo esperado" y una desviación estándar para la duración del proyecto que es más
confiable y precisa que los simples cálculos PERT; también da las probabilidades de que otros caminos
se vuelvan críticos. 7 La simulación permite el uso de una variedad de distribuciones de probabilidad
además de Beta, incluidas distribuciones basadas en datos empíricos. Como resultado, las
duraciones de proyecto generadas representan con mayor precisión el rango de duraciones esperadas
que el método PERT de red única.
La simulación también puede evitar algunas limitaciones de los supuestos PERT, como la
independencia de la duración de las actividades y la normalidad de la distribución de la duración del
proyecto. El siguiente ejemplo de Evans y Olson ilustra el uso de
simulación para evaluar la probabilidad de tiempo de finalización del proyecto.8
Ejemplo 7.2: Simulación para determinar la

duración del proyecto
Consulte las actividades del proyecto y las estimaciones de tiempo en la Tabla 7.3 y la red
del proyecto en la Figura 7.13.
La ruta crítica es B–F–G–H–I–K–M–O–P–Q; sumando te y V en esto
path da una duración del proyecto de 147,5 días con una varianza de 56,63.
Suponga que el cliente desea que el proyecto se complete en 140 días.
Usando el método PERT, la probabilidad de completar el proyecto dentro de 140 días se
encuentra a partir de
Con referencia a la Tabla 7.2, la probabilidad es de alrededor del 16 por ciento.
Cuadro 7.3 Actividades y estimaciones de tiempo

Figura 7.13 Red del proyecto.
El uso del programa de simulación Crystal Ball para generar los tiempos
de finalización de 1000 réplicas del proyecto produce la distribución de la Figura
7.14. (También se pueden usar varios otros programas como Risksim, @Risk,
9
Arena y Simul-8).
Figura 7.14 Resultados de la simulación Crystal Ball para los tiempos de finalización del proyecto.
La distribución de la simulación tiene una media de 155 días y da una probabilidad

de completar el proyecto en 140 días de alrededor del 6,9 por ciento (la suma de las
probabilidades a la izquierda de 140 en la figura 7.14). Por lo tanto, es poco probable
que el proyecto se termine en menos de 140 días, y solo un 50 por ciento de
probabilidad de que se complete en 155 días, que es 7,5 días más que la estimación
PERT de 147,5 días.
La simulación proporciona resultados más realistas que PERT porque compensa las rutas
no críticas que pueden volverse críticas. Pero como PERT, es simplemente un método
para analizar horarios, no para crearlos. Es una herramienta de análisis "mejor" que PERT
pero, como PERT, no elimina la incertidumbre asociada con la programación ni especifica
qué hacer para reducir el riesgo del proyecto; se necesitan otras herramientas para eso,
como se discutió en el Capítulo 10.
Ver Capítulo 10
Por qué los proyectos a menudo se retrasan
El gerente del proyecto podría enfrentar un riesgo considerable al comprometerse con una fecha de vencimiento
basada únicamente en la duración de la ruta crítica. Por ejemplo, se utilizó una simulación de Monte Carlo para
calcular la probabilidad de terminar un proyecto dadas las duraciones de las actividades de la ruta crítica que se
muestran en la figura 7.15. La longitud de la ruta crítica más probable es de 130 días, pero la simulación revela
que la posibilidad de terminar el proyecto en ese tiempo es solo del 15 por ciento. Además, esta simulación se
aplicó solo a la ruta crítica y no tuvo en cuenta las rutas no críticas que podrían volverse críticas, lo que reduciría
aún más la probabilidad. Si bien los valores m individuales pueden considerarse "realistas", ¡la suma de los
valores m no es realista en absoluto! El director del proyecto enfrenta un riesgo similar cuando se compromete
con un costo de proyecto que es la suma de las estimaciones de costos de actividad más probables. Muchos
gerentes de proyectos estiman la duración y el costo del proyecto simplemente sumando las estimaciones más
probables de la duración y los costos de las actividades, una de las razones por las que los proyectos superan
las fechas de vencimiento y los presupuestos.
Otra razón para los excesos es el comportamiento humano. Durante la etapa de factibilidad o propuesta
(licitación) del proyecto, los campeones y partidarios trabajan arduamente para “vender” el proyecto. Todo el
mundo es optimista, lo cual es necesario para ganar la aceptación de las partes interesadas, pero también lleva
a subestimar la duración y el costo del proyecto. El Túnel del Canal ("Channel") es un ejemplo. Originalmente se
dijo que 30 millones de personas y 100 millones de toneladas de carga se transportarían a través del Chunnel
por año, afirmación que resultó ligeramente exagerada ya que en los primeros 5 años las cifras reales fueron de
28 millones de personas y 12 millones de toneladas de carga.
El costo, estimado inicialmente en 7.500 millones de libras esterlinas, finalmente alcanzó los 15.000 millones de
libras esterlinas. Además, el proyecto tardó casi 18 meses más en completarse de lo estimado originalmente.
Figura 7.15 Los resultados de la simulación muestran una baja probabilidad de terminar dentro del tiempo de la ruta crítica.
Generada mediante el software Crystal Ball, asumiendo distribuciones triangulares.

7.4 Asignación de recursos y programación de

proyectos múltiples
Las organizaciones de construcción, consultoría, desarrollo de sistemas y mantenimiento suelen

utilizar un grupo de equipos compartidos y trabajadores calificados de los que se basan todos los
proyectos. Esto también sucede en organizaciones matriciales (Capítulo 14) donde los proyectos
comparten recursos de los mismos departamentos funcionales. Esta sección aborda el tema de
la programación de múltiples proyectos que comparten recursos limitados.
Ver Capítulo 14
Los proyectos múltiples que comparten recursos deben planificarse y programarse de manera
que en combinación no excedan los recursos disponibles en los grupos compartidos.
Aunque estos proyectos pueden considerarse independientes en todos los demás aspectos, en
lo que respecta a sus recursos compartidos, son interdependientes.
Como era de esperar, el problema de programar múltiples proyectos concurrentes es análogo
a programar múltiples actividades concurrentes dentro de un solo proyecto, pero con
modificaciones para tener en cuenta los problemas económicos, técnicos y organizativos que
surgen cuando se trata de múltiples proyectos (ver Capítulo 18). .
Ver Capítulo 18
En primer lugar, cada proyecto tiene su propia fecha de finalización objetivo y todos los
proyectos deben programarse para finalizar lo más cerca posible de esas fechas para evitar
pagos diferidos, costos de penalización o pérdida de ventas e ingresos. Además, cuando los
proyectos son interdependientes, los retrasos en un proyecto pueden tener un efecto dominó en
los demás; el retraso de un proyecto de desarrollo y lanzamiento de un satélite provocará el
posterior retraso de un proyecto de telecomunicaciones. En cualquier caso, la programación de
múltiples proyectos requiere primero determinar la prioridad relativa entre los proyectos para
determinar qué proyecto debe obtener los primeros recursos en recursos escasos.
Porque la mayoría de las organizaciones prefieren mantener un nivel uniforme de personal
y otros recursos, los cronogramas combinados para múltiples proyectos resultan idealmente en una
carga uniforme de esos recursos. En otras palabras, la carga de recursos para los proyectos
combinados es idealmente plana. En teoría, los proyectos se programan de tal manera que, a medida
que se liberan recursos de un proyecto, se asignan a otros. Esto minimiza los costos asociados con
la contratación, los despidos y los trabajadores e instalaciones inactivos, y ayuda a mantener la moral
de los trabajadores y el uso eficiente de los recursos.
Cuando muchas actividades o proyectos están listos para comenzar y todos requieren el mismo
recurso, la pregunta es, ¿a qué actividades o proyectos se debe asignar el recurso? Cuando 10
actividades están listas para comenzar, el número de secuencias posibles para realizarlas es 10, o
más de 3,6 millones. Si n actividades están listas para comenzar y todas ellas requieren m recursos,
el número de cronogramas posibles sería (n!)m. La optimización usando polinomios normales
generalmente no es factible (el problema es "NP difícil"). Los métodos heurísticos, por otro lado,
proporcionan soluciones simples y aceptables.
Métodos heurísticos para la asignación de recursos
Un método heurístico es un procedimiento basado en una regla simple. Los métodos heurísticos para
asignar recursos a proyectos a menudo emplean reglas de prioridad o reglas de despacho. Si bien
estos métodos no producen horarios óptimos, sí producen horarios "suficientemente buenos" para la
mayoría de las situaciones.
Los métodos heurísticos comienzan con tiempos tempranos y tardíos determinados por los
métodos de red tradicionales, y luego analizan el cronograma de los recursos requeridos (es decir, la
carga de recursos). Cada vez que un requisito de recurso excede la restricción, la heurística determina
qué actividad obtiene alta prioridad y recibe el recurso. Las reglas heurísticas más comunes para
determinar la prioridad de programación
son:
una. Lo antes posible: se da prioridad a las actividades que se pueden iniciar antes
sobre (o programado antes de) aquellos que se pueden iniciar más tarde.
b. Lo más tarde posible: las actividades que pueden terminarse más tarde tienen menor
prioridad que las que deben terminarse antes. C. La mayoría de los recursos: las actividades
que requieren más recursos tienen prioridad sobre las que requieren menos recursos.
d. Tiempo de tarea más corto: las actividades de duración más corta tienen prioridad sobre las
de duración más larga (a veces denominadas duración de actividad más corta, tiempo de
procesamiento más corto o tiempo de operación más corto). mi. Menos holgura: las
actividades con menos holgura tienen prioridad sobre aquellas con más holgura; Por lo tanto,
las actividades de la ruta crítica tienen la máxima prioridad. (Esta regla también se conoce
como tiempo de inactividad restante).
F. Primero en llegar, primero en ser atendido: se da prioridad a las actividades que llegan
antes o requieren el recurso antes.
gramo. Fecha de vencimiento más temprana: cuando un recurso se va a asignar a más de un
proyecto, se da prioridad al proyecto con la fecha de finalización prevista más temprana.
Alternativamente, se da prioridad a la actividad con la siguiente operación más temprana .
Todas las reglas de prioridad están subordinadas a los requisitos de precedencia; es decir, sin
importar la regla, el cronograma resultante no debe violar las relaciones predecesor-sucesor. La
mayoría del software de gestión de proyectos emplea alguna combinación de estas reglas (por
ejemplo, usar "el tiempo de tarea más corto" y luego usar "lo antes posible" como desempate). La
Figura 7.16 muestra ejemplos de la aplicación de las reglas anteriores a a e en la asignación de
trabajadores a las actividades y sus impactos en el cronograma del proyecto dada una restricción de
diez trabajadores por semana como máximo.
Como muestra la figura 7.16 , las reglas arrojan resultados diferentes, algunos mejores que otros.
En general, con la regla de lo más tarde posible , todo ocurre en su última fecha; el inconveniente
de esto es que un retraso en cualquier actividad retrasará el proyecto. Por el contrario, la regla de
menor holgura es buena porque reduce el riesgo de que las actividades no críticas retrasen las
críticas.
La regla del tiempo de tarea más corto es buena cuando se deben ejecutar varios proyectos a la
vez, ya que permite que las personas responsables de las actividades exitosas las realicen antes.
La figura 7.17 muestra lo que sucede cuando las actividades se programan (a) primero la tarea más
larga versus (b) primero la tarea más corta. Como se representa por el área debajo de las barras, el
tiempo total de espera en (b) es mucho menor que en (a). La regla dice: cuando tengas varias cosas
que hacer, haz primero las más cortas.
El objetivo típico de la programación es completar el proyecto en la fecha de finalización prevista;
a veces eso no es posible, independientemente de la regla de prioridad. Por ejemplo, suponga que
la fecha de finalización prevista para el proyecto de la figura 7.16 es de 9 semanas, la
longitud del camino crítico. Dado el nivel de recursos limitados de diez trabajadores, ninguna de
las heurísticas del ejemplo cumple este objetivo, aunque una de ellas ("lo más tarde posible") da
como resultado una finalización de 10 semanas.
7.5 Teoría de Restricciones y Método de Cadena Crítica 10
La teoría de las restricciones (TOC) es un enfoque de sistemas para mejorar el rendimiento de

11
los sistemas empresariales. objetivo y que a
Una
menudo
premisa
sólo
deun
TOC
elemento
es quedel
cada
sistema,
sistema
llamado
tiene un
restricción del sistema, limita el logro de ese objetivo.
La aplicación de TOC a la programación y el control de proyectos se denomina gestión de

proyectos de cadena crítica (CCPM) o método de cadena crítica (CCM). La restricción para un
proyecto individual es su duración o fecha de vencimiento, y CCPM tiene como objetivo
12
reducir esa duración y proporcionar una fecha de finalización del proyecto más predecible.
CCPM da cuenta tanto de la naturaleza estocástica de la duración de las actividades como del
impacto del comportamiento humano en la programación y ejecución del proyecto. Se puede
13
aplicar a proyectos individuales o a múltiples proyectos simultáneos.
Compromiso con las fechas de vencimiento
Con los métodos tradicionales, las personas que trabajan en cada actividad del proyecto deben
comprometerse a completar la actividad en una fecha determinada, aunque la duración de la
actividad sea incierta. Puede haber penalizaciones por terminar tarde o recompensas por terminar
temprano, pero por temor a terminar tarde, las personas responsables de una actividad a menudo
brindan una estimación de tiempo pesimista o "rellenada". Aunque este comportamiento es
bastante normal, resulta
Figura 7.16 Resultados de varias reglas de prioridad sobre el cronograma y los tiempos de finalización del proyecto.
Figura 7.17 La regla del tiempo de tarea más corto reduce el tiempo de espera. (a) La tarea más larga primero. (b) Primero la tarea más corta.
en todas partes en duraciones de actividad estimadas infladas y, por lo tanto, proyectos de mayor
duración. El enfoque de CCPM para evitar el relleno de tiempo es simplemente este: mientras que el
gerente del proyecto obviamente necesita comprometerse con una fecha de vencimiento del proyecto,
las personas responsables de las actividades individuales del proyecto no están obligadas a
comprometerse con las fechas de vencimiento. Se les anima a trabajar en serio, pero no se les fija una fecha límite.
Al solicitar estimaciones de tiempo, se pide a todos que proporcionen el tiempo más "realista", es
decir, el tiempo con un 90 por ciento de posibilidades de que se logre. Luego, este tiempo se reduce
a la mitad para obtener una estimación “agresiva”, que elimina cualquier relleno por contingencia. (Sin
embargo, debe tenerse en cuenta que cada vez que los miembros del proyecto brindan estimaciones
"agresivas" (sin relleno), el gerente no las reduce a la mitad). Las estimaciones realistas y agresivas
brindan la base para estimar la cantidad de "amortiguación" requerida para proteger el proyecto en su
conjunto contra retrasos.
Amortiguador de proyecto y amortiguadores de alimentación
Para protegerse contra retrasos, se coloca un búfer de proyecto (tiempo de contingencia) al final del
proyecto. La fecha al final del búfer es la fecha en la que el director del proyecto se compromete a
completar el proyecto. (Como se mencionó, el gerente del proyecto se compromete con una fecha
para el proyecto, pero las personas responsables de las actividades individuales del proyecto no se
comprometen con las fechas; solo intentan completar sus actividades rápidamente). buffer alargar la
duración del proyecto? La respuesta es no, porque las estimaciones de tiempo agresivas que se
utilizan para las actividades del proyecto son un 50 por ciento más cortas que las estimaciones
“realistas” pero ampliadas.
Dividir la estimación realista por dos da como resultado dos estimaciones: una, una estimación
agresiva de la duración, la otra una estimación del "relleno" que se incluyó en la estimación realista
original. Sumar las estimaciones de relleno para todas las actividades para formar la reserva del
proyecto y poner la reserva al final del proyecto tendrá en cuenta cualquier retraso en la actividad.
Para ilustrar, considere el proyecto que se muestra en la Tabla 7.4 y la Figura 7.18. La ruta crítica,
P–Q–R–Z, tiene una duración de 32 semanas. Ahora mire la Figura 7.19 donde la duración de las
actividades se ha reducido a la mitad. Las 16 semanas (4+6+4+2) recortadas de la ruta crítica P–Q–
R–Z se convierten en el amortiguador del proyecto. Nótese también en la Figura 7.19 la presencia de
un amortiguador de alimentación, que es el número de semanas retiradas del
camino no crítico S-T, 12 semanas (2+10). En general, CCPM pide un solo proyecto
búfer al final de la ruta crítica, así como un búfer de alimentación ubicado donde sea
una ruta no crítica alimenta la ruta crítica. El tampón de alimentación protege contra
retrasos en actividades no críticas.
Si bien los amortiguadores de proyecto y los amortiguadores de alimentación se parecen a la holgura, son
no flojo Mientras que con los métodos tradicionales las actividades se programan tan pronto como
posible y se puede usar la holgura para retrasar actividades cuando sea necesario, en CCPM todos
las actividades están planificadas para comenzar lo más tarde posible, pero con amortiguadores. (Como se discutio
más tarde, sin embargo, durante la ejecución, las actividades críticas se inician lo antes posible
para aprovechar las ganancias de las actividades completadas antes de tiempo). Los amortiguadores "pertenecen"
al gerente del proyecto, y solo ella puede asignarles tiempo; esta voluntad
ocurrir siempre que una actividad exceda su duración planificada.
Tabla 7.4 Actividades para el Proyecto de Desarrollo de Sistemas Pequeños
Descripción de la actividad (de Actividad Duración

Recursos
EDT) Código (Días)
8 Equipo de diseño
Subsistema de diseño A PAGS
Fabricación Subsistema A q 12 Técnico
Subsistema de prueba A R 8 equipo de prueba
S 4 Equipo de diseño
Subsistema de diseño B
B
Construir subsistema B T 20 Técnico
Montaje de los subsistemas A y B Z 4 Técnico

Figura 7.18 (a) Redes para actividades en la Tabla 7.4; (b) Red de escala de tiempo para actividades en la Tabla 7.4.
Figura 7.19 Cronograma con reservas de contingencia asignadas al gerente del proyecto.
Pero el tamaño del búfer del proyecto puede ser sustancialmente menor que la suma de los
rellenos de actividad que se eliminaron. Hay dos razones. Primero está el efecto matemático,
bien conocido en la gestión de riesgos, llamado agregación, que dice que la incertidumbre de
terminar un proyecto a tiempo es mucho menor que la suma de las incertidumbres de terminar
a tiempo las tareas individuales dentro de ese proyecto.
Debido al efecto de agregación, los rellenos eliminados de las duraciones de actividades
individuales se pueden reemplazar por un búfer de proyecto que es mucho más pequeño que la
suma de todos los rellenos eliminados.
La segunda razón por la que se puede reducir el tamaño del búfer del proyecto proviene de la
el anverso de la Ley de Parkinson, que establece que “el trabajo se expande para llenar el tiempo
disponible”. Quitar el relleno de cada actividad crea una sensación de urgencia; las personas
tienen menos tiempo para hacer el trabajo, por lo que tienden a trabajar más rápido que cuando
tienen más tiempo. Por estas razones, el tamaño del búfer del proyecto se puede reducir en un
50 por ciento. Esto se muestra en la Figura 7.20.
El director del proyecto se compromete a completar el proyecto en o antes de la fecha de
finalización del buffer del proyecto, semana 28, aunque el equipo del proyecto trabaja para
completar el proyecto en la fecha de inicio del buffer del proyecto, semana 20 o antes. , existe
una alta probabilidad de que este proyecto se complete en menos de 28 semanas. Con el método
de la ruta crítica, existe una alta probabilidad de que el proyecto se complete después de la
duración de la ruta crítica de 32 semanas.
Figura 7.20 Cronograma con tamaños de búfer reducidos.
Cadena Crítica
Sin embargo, la figura 7.20 revela un problema potencial: las actividades Q y T usan el mismo
recurso (el "técnico"). Suponga que el técnico puede trabajar en una sola actividad a la vez. Para
permitir eso, el cronograma se ajusta como se muestra en la Figura 7.21 (Poner la Actividad Q
antes de T es otro cronograma posible). En el cronograma ajustado, la ruta S–T–Q–R–Z se
denomina cadena crítica, definida como la ruta que conecta actividades que requieren el mismo
recurso. La cadena crítica no es necesariamente la ruta más larga a través de la red, aunque
cada vez que la longitud de la cadena crítica más los búfer excede la longitud de la ruta crítica, la
cadena crítica, y no la ruta crítica, determina la duración del proyecto.
Los métodos de red tradicionales abordan los problemas de conflicto de recursos por medio de
nivelación de recursos, aunque el resultado no será necesariamente el mismo que con

CCPM ya que resuelven estos conflictos a partir de un cronograma inicial y utilizan la
holgura disponible. En CCPM, los conflictos de recursos se resuelven durante el proceso de
programación inicial y las dependencias de recursos se tratan a priori.
Tenga en cuenta que el búfer de alimentación, FB, es de 4 semanas, no de 2. La razón
es que sigue solo una actividad, P, y por lo tanto, el efecto de agregación no se aplica.
En última instancia, el tamaño del colchón queda a discreción del administrador y es lo que
ella decida.
Si el cronograma no cumple con una fecha de vencimiento predeterminada o si la alta
gerencia quiere que el proyecto se complete antes, se deben agregar recursos adicionales.
Pero agregar personas y otros recursos es costoso y, a menudo, disruptivo; por lo tanto,
CCPM primero intenta hacer pleno uso de los recursos disponibles en ese momento.
Amortiguadores de recursos: capitalización de terminar el trabajo antes de

Planificado
Figura 7.21 Horario ajustado para que cada recurso realice solo una tarea a la vez.
Anteriormente se mencionó el hecho de que cada vez que las actividades terminan tarde,
sus sucesores comienzan tarde, pero cuando terminan temprano, sus sucesores no
necesariamente comienzan temprano. Los recursos (personas y equipos) que han sido
preprogramados a menudo no están disponibles para comenzar antes porque están
ocupados con otra cosa. Como consecuencia, cada vez que se producen retrasos, el
proyecto se retrasa; cada vez que se producen ganancias (los predecesores terminan antes
de lo programado), ¡no hay diferencia!
Figura 7.22 Amortiguadores de recursos que brindan una cuenta regresiva sobre cuándo comenzar las actividades críticas.
En CCPM, el equipo del proyecto puede sacar provecho de los predecesores que finalizan antes de
tiempo mediante el uso de reservas de recursos. A diferencia de los amortiguadores de proyectos y de
alimentación, los amortiguadores de recursos no agregan tiempo al cronograma. Un búfer de recursos es
una señal de cuenta regresiva o advertencia para alertar a los recursos de que una actividad en la cadena
crítica posiblemente terminará antes de lo planeado y que deben estar preparados para comenzar
temprano. En una carrera de relevos de maratón, cada corredor está preparado para aceptar el testigo
del corredor anterior, independientemente de cuándo llegue este último; asimismo, los recursos de la
cadena crítica están preparados para comenzar a trabajar tan pronto como los antecesores terminen su
trabajo, independientemente del cronograma. En la práctica, un búfer de recursos puede tomar la forma
de una serie de correos electrónicos u otros mensajes a los recursos, contando el tiempo restante antes
de que deban estar listos para iniciar una actividad. Las ubicaciones de las reservas de recursos se
ilustran en la Figura 7.22.
Tenga en cuenta que los amortiguadores de recursos se insertan solo en la cadena crítica, ya que los
amortiguadores de alimentación pueden manejar adecuadamente la incertidumbre en las rutas no críticas.
Tenga en cuenta también que no hay un búfer de recursos entre la Actividad T y la Actividad Q, ya que el
mismo recurso (técnico) hace ambas cosas y, obviamente, no necesita notificación sobre cuándo
terminará la Actividad Q y debe comenzar la Actividad T.
Búferes de hitos
A veces, los plazos de los hitos se establecen en momentos intermedios del proyecto, como las fechas
de finalización programadas para las fases del proyecto. En ese caso , se inserta un búfer de hitos antes
de cada hito. Cuando se utilizan búferes de hitos, el tamaño
de la reserva del proyecto se reduce; en efecto, la reserva del proyecto se divide entre las reservas del hito. Los
diferentes tipos de amortiguadores se resumen en la Tabla 7.5.
Dimensionamiento de tampones
CCPM depende en gran medida del proyecto y de los amortiguadores de alimentación, por lo que es importante
que tengan el tamaño correcto. Goldratt sugiere que la duración de las actividades se reduzca en un 50 por ciento
14
y que el búfer del proyecto sea la mitad de la duración de la ruta más larga resultante.
Este método, que reduce la duración del proyecto en un 25 por ciento, se ilustró en la Figura 7.19 y se conoce
como el método del "50 por ciento de la cadena" y "cortar y pegar".
Cuando una ruta consta de muchas actividades, incluso un búfer del 50 por ciento de la longitud de la ruta 15
demasiado grande. método,

Newbold
donde elpropone
tamañoque
del la
colchón
raíz cuadrada
se establece
de la en
suma
la raíz
de los
cuadrada
cuadrados
de la(SSQ)
suma es
de los
cuadrados de las diferencias entre la duración de bajo riesgo y la duración media para cada
tarea a lo largo de la ruta más larga que conduce al búfer. 16 Otros han sugerido métodos adicionales. 17
Cuadro 7.5 Resumen de tipos de zonas de amortiguamiento para un solo proyecto
Buffer
Función del búfer
Escribe
Compuesto por reservas de contingencia agregadas tomadas de actividades en la cadena crítica;

Búfer de
proporciona una reserva de contingencia entre la fecha de finalización más temprana posible y la
proyecto
fecha comprometida.
Hito Similar a un búfer de proyecto, pero se utiliza cuando una fase del proyecto o un búfer de hito tiene una
fecha de vencimiento fija.
Compuesto por contingencias agregadas tomadas de caminos no críticos; estabiliza la cadena

Amortiguador de
crítica al evitar que las actividades no críticas retrasen las actividades críticas.
alimentación
Una alerta temprana o "cuenta regresiva" para el inicio de una actividad crítica que garantiza que
Búfer de los recursos estén listos para trabajar en la cadena crítica tan pronto como se hayan completado
recursos todas las actividades anteriores.
Relleno, multitarea y procrastinación
Los proyectos toman más tiempo del necesario por muchas razones. En primer lugar, como ya se
dijo, las personas aumentan sus estimaciones de tiempo y el efecto de esto empeora a medida que
cada gerente en la WBS aumenta el relleno. Si la persona responsable de una actividad aumenta
el tiempo en un 10 por ciento y cada persona que está más arriba en la EDT también lo aumenta
en un 10 por ciento, el relleno a nivel de proyecto para una EDT de nivel n sería (1.1)EDT
n . Para
de cinco
una
niveles, esto arroja una contingencia total del 60 por ciento; si cada uno rellena el 15 por ciento, la
contingencia total sería del 101 por ciento.
Figura 7.23 Efecto de la multitarea en los tiempos transcurridos y de finalización.
En segundo lugar, las personas realizan múltiples tareas. Por ejemplo, un contratista tiene tres
proyectos independientes, X, Y y Z, cada uno con una duración prevista de 10 semanas. El
contratista está ansioso por terminarlos todos lo antes posible, por lo que divide cada uno en partes
pequeñas para que, en cierto sentido, pueda trabajar en todos a la vez. Pero al hacerlo, en realidad
retrasa la finalización de dos de los proyectos. Si hubiera programado los proyectos secuencialmente
X primero, Y segundo y Z último, sin interrupción, entonces, como se muestra en la figura 7.21(a),
terminaría X en la semana 10, Y en la semana 20 y Z en la semana 30. Pero cuando divide los
proyectos en segmentos de, digamos, períodos de 5 semanas y alterna el trabajo entre ellos,
aumenta el tiempo transcurrido para cada proyecto de 10 semanas a 20 semanas. Como se ilustra
en la Figura 7.23(b), el resultado
es que dos de los proyectos se retrasan: X termina en la semana 20 y Y termina en la semana 25.
En general, cuanto más se desglosan y entremezclan las actividades o proyectos con otros
proyectos, mayor es el tiempo transcurrido para terminar cualquiera de ellos.
Figura 7.24 Síndrome de los estudiantes (a) en una producción y (b) en un proyecto.
Para agravar el efecto, la multitarea impide que las personas obtengan el impulso que tendrían
si se concentraran ininterrumpidamente en una sola tarea, como se ilustra en la Figura 6.25. Se
debe evitar la multitarea. Al concentrarse en una sola actividad a la vez, cada actividad se completa
antes, las actividades sucesoras comienzan antes y el proyecto finaliza antes.
Una tercera razón por la que los proyectos tardan más de lo necesario es que las personas
postergan y desperdician la holgura disponible.
programados, uno18 Ante la posibilidad
temprano demuchas
y otro tardío, elegir entre dos horarios
personas eligen el
tardío; esto elimina automáticamente la holgura, coloca las actividades en la ruta crítica y aumenta
la probabilidad de retraso en el proyecto. Además, cada vez que las personas perciben holgura,
están menos motivadas para completar una actividad antes de tiempo. El efecto se llama el
"síndrome de los estudiantes", y hace alusión al entusiasmo inicial de los estudiantes por un nuevo
curso que pronto se desvanece y no se reanuda hasta justo antes del examen final. Un efecto
similar ocurre en entornos de producción y proyectos, como se muestra en la Figura 7.24.
Acortar la duración de las actividades y programar las actividades lo más tarde posible (con
amortiguadores) reduce la tendencia a procrastinar.
Gestión de búfer para el control de proyectos
Todas las actividades de un proyecto están vinculadas a un amortiguador: las actividades de la

cadena crítica están vinculadas al amortiguador del proyecto y todas las demás a los amortiguadores
de alimentación. Durante la ejecución del proyecto, esos amortiguadores se monitorean para predecir
la fecha de finalización del proyecto y evaluar el riesgo de no cumplir con la fecha de vencimiento. La
cantidad de búfer "consumido" se determina cada día simplemente preguntando a las personas que
trabajan en actividades la duración restante esperada y calculando en qué medida esa duración
supera la estimación agresiva y, por lo tanto, consume (penetra) el búfer. Siempre que los retrasos
consuman menos tiempo del que tiene el búfer, el proyecto estará a tiempo; si consumen más tiempo
del que tiene el búfer, el proyecto se retrasará. El consumo de tampones también proporciona una
forma clara y objetiva de determinar las prioridades.
Cuando se requiere que alguien trabaje en más de una actividad, el búfer más consumido indica
qué actividad tiene la prioridad más alta. La gestión de búfer se trata más detalladamente en el
Capítulo 11.
Ver Capítulo 11
Desafío de CCPM: Cambio de comportamiento
Una creencia en la mayoría de las organizaciones de proyectos es que debido a que el director del
proyecto tiene que comprometerse con la fecha de vencimiento, todos en el proyecto también deben
comprometerse con las fechas de vencimiento. En CCPM, la premisa es que solo el gerente del
proyecto debe comprometerse con una fecha de finalización; todos los demás trabajan hacia
estimaciones realistas (relativamente "agresivas"). Si bien lograr que todos acepten esta premisa en
proyectos pequeños puede ser relativamente fácil, ese no es el caso para proyectos grandes. Dado
que la mayoría de las personas están acostumbradas a trabajar con fechas límite, esto requiere nada
menos que un cambio cultural y de comportamiento en todos los niveles de la organización, incluida la alta dirección.
Los altos directivos y los clientes que no comprendan los principios de CCPM intentarán sortearlos.
Soporte de software para CCPM19

Muchos paquetes de software de gestión de proyectos incluyen provisión para CCPM, y

aunque muchos otros requieren complementos para hacerlos compatibles con CCPM.
Por ejemplo, el software Sciforma™ y Concerto™ es totalmente compatible con CCPM,
pero MSProject solo lo admite con el complemento Prochain™.
7.6 Método TOC para asignar recursos a múltiples

20
proyectos
Tanto como el 90 por ciento (por valor) de todos los proyectos se llevan a cabo en proyectos
entornos. múltiples 21 La teoría de las restricciones (TOC) proporciona un procedimiento de
cinco pasos para programar el inicio de nuevos proyectos a fin de maximizar el número de proyectos
de una organización puede manejar al mismo tiempo.
Paso 1: identificar la restricción
¿Qué impide que una empresa haga más proyectos? Si la empresa tiene pocos proyectos en los
libros de pedidos, la restricción podría ser una cuota de mercado limitada o el tamaño del mercado.
Pero si tiene más demanda de proyectos que capacidad para hacerlos, la restricción es cualquier
cosa que reduzca la velocidad a la que se completan los proyectos (tasa de flujo) por debajo del
máximo; la restricción más común es un recurso altamente cargado o multitarea.
Los entornos de producción, como los "talleres de trabajo" de fabricación, utilizan reglas de
prioridad (discutidas anteriormente) para seleccionar el siguiente trabajo al que se debe asignar un
recurso (generalmente una máquina). En los talleres de trabajo es fácil identificar la restricción: es
la máquina delante de la cual se acumulan las colas de trabajo. Tal recurso, la restricción del
sistema, se denomina "recurso de tambor" porque establece el tono o el ritmo de todo lo que fluye
a través del proceso. La filosofía TOC enfatiza la importancia de mantener ocupado el recurso
restringido (tambor), evitando que el hambre y el bloqueo reduzcan el flujo. Para garantizar esto, se
utilizan tampones de tambor . La aplicación del búfer de tambor a la gestión de proyectos se
describe en otra parte.
Sin embargo, la experiencia con la implementación de la teoría de las restricciones sugiere que,
si bien un recurso específico puede identificarse como la restricción en un entorno de múltiples
proyectos, a menudo la restricción real es algo diferente a ese recurso. En la práctica, las
restricciones identificadas pueden ser diferentes para la planificación de un conjunto de proyectos
que para su ejecución. Tales restricciones típicas se discuten a continuación.
En una secuencia de actividades, independientemente de la restricción real, una actividad cercana

22 Para
el final de un proyecto puede elegirse como un sustituto de la restricción. Al planificar un conjunto de
proyectos, se puede utilizar una regla relativa a la programación de esta actividad como sustituto de la restricción
del conjunto de proyectos. Por ejemplo, en una empresa de electrónica que lleva a cabo múltiples proyectos
simultáneos, todos los proyectos deben pasar por una "integración final" justo antes del cierre, y se identificó a
un ingeniero especialista con una gran carga de trabajo como la limitación de recursos. Sin embargo, en lugar de
usar ese recurso para escalonar proyectos, se decidió usar la regla de solo tres proyectos en la integración final
a la vez. En la Figura 7.25, las actividades sombreadas representan la integración final en nueve proyectos. Para
garantizar que siempre haya tres proyectos en la integración final: el Proyecto 4 comienza la integración final tan
pronto como el Proyecto 1 completa la integración final, el Proyecto 5 comienza la integración final tan pronto
como el Proyecto 2 completa la integración final, y así sucesivamente. Esto escalona el trabajo en todos los
recursos a través de la subordinación de los cronogramas de proyectos individuales, como se explica en el Paso
3 a continuación. Para ejecutar el conjunto de proyectos, la restricción típica es el tiempo disponible para que los
gerentes apoyen los proyectos.
Figura 7.25 Solo tres proyectos en integración final en cualquier momento.
Paso 2: Decida cómo explotar (utilizar) la restricción
La regla "solo tres proyectos en integración final" permite a la empresa explotar la restricción de integración final
para fines de planificación de proyectos. Combinando el

la fecha programada para cuando un proyecto debe comenzar la integración final con la duración del
proyecto determina cuándo debe iniciarse el proyecto. Cuando una tarea de integración no puede
comenzar de acuerdo con la regla, o el trabajo debe esperar a una tarea de integración, la duración
de las tareas de integración se ajusta para permitir el escalonamiento apropiado de la liberación del
proyecto.
En el caso de que la integración final de un proyecto se complete antes de tiempo, las reservas
de recursos (discutidas anteriormente) garantizarán que los proyectos subsiguientes puedan
comenzar antes.
Debido a que se está trabajando en menos proyectos, escalonarlos de esta manera reduce la
carga de trabajo en la mayoría de los recursos, reduce la multitarea entre proyectos, mejora el flujo
de proyectos (es decir, la velocidad a la que se completan los proyectos) y garantiza que los
compromisos con los clientes se cumplan.
Si la restricción para ejecutar (en lugar de liberar) el conjunto de proyectos es el tiempo disponible
para que los gerentes respalden los proyectos, entonces se deben tomar medidas para asegurar que
ese tiempo esté disponible. Si la falta de tiempo de gestión restringe el flujo de proyectos, entonces
esta restricción debe eliminarse.
Paso 3: Subordinar todo lo demás a las decisiones relativas

a la restricción
Durante la programación, la liberación de proyectos (autorización) se basa en la carga de la

restricción. Si la empresa decide que debe tener solo tres proyectos en la fase final de integración, la
restricción de proxy es la regla "tres proyectos en la fase final de integración". Cada nuevo proyecto
se ubicaría para comenzar la integración final en cualquier momento que sea necesario para
mantener ese máximo de tres proyectos. Los cronogramas de los proyectos individuales están, por
lo tanto, subordinados al cronograma de la restricción multiproyecto, es decir, la regla sobre el
número de proyectos en la fase de integración. El proyecto con el mayor riesgo de perder su fecha
de vencimiento se programaría para comenzar primero, según lo indica su estado de reserva del
proyecto. La utilización de todos los recursos para el conjunto de proyectos también está subordinada
al cronograma, y las personas no realizan múltiples tareas.
Si la restricción para la ejecución del proyecto es el tiempo disponible para el apoyo de la gestión,
entonces todo el resto del trabajo que deben realizar los gerentes debe estar subordinado
a esta función de apoyo.
Paso 4: Elevar la restricción
La restricción se “eleva” proporcionando capacidad adicional. Elevar la restricción implica, por ejemplo,
aumentar la capacidad para aumentar el número de proyectos en integración final de tres a cuatro. Por
lo general, implica medidas costosas, como la construcción de nuevas instalaciones y la contratación
y capacitación de personas adicionales. Los pasos 2 y 3, por lo tanto, aseguran que la capacidad
existente se utilice de manera efectiva antes de que el dinero se destine a adquirir recursos adicionales.
Si la restricción es el tiempo de gestión disponible para el apoyo al proyecto, entonces el sistema

de gestión debe simplificarse para mejorar su eficacia en el desempeño de las funciones de apoyo.
En entornos de múltiples proyectos, los búferes de recursos tienen menos utilidad. Los recursos se
dedican a proyectos individuales; no están disponibles cuando se completa una tarea. Simplemente
comienzan a trabajar en la siguiente tarea, incluso si tienen que esperar un rato antes de comenzar.
En realidad, es deseable que estén inactivos entre proyectos: para maximizar el flujo de proyectos, los
recursos deben esperar para trabajar; el trabajo no debe esperar a los recursos.
De esta forma, es posible que todas las actividades (incluidas las que se encuentran en rutas no
críticas) puedan comenzar tan pronto como se completen las actividades predecesoras. Supervisar las
reservas del proyecto es todo lo que se necesita para mantener los proyectos en marcha (como se
ilustra en el Capítulo 11, Ejemplo 11.3). El seguimiento de los búferes del proyecto simplifica el proceso
de seguimiento y control durante la ejecución del proyecto, alivia la carga de trabajo de los gerentes y
aumenta el tiempo disponible para respaldar otros proyectos. A su vez, esto eleva la restricción para la
ejecución del proyecto: el tiempo que los gerentes tienen disponible para tomar mejores decisiones
sobre el proyecto.
Ver Capítulo 11
Paso 5: Regrese al Paso 1

Agregar recursos podría eliminar la restricción, en cuyo caso se identificaría una nueva restricción y se repetiría
el proceso. A veces, sin embargo, la nueva restricción sería demasiado disruptiva, en cuyo caso se permite
que la restricción existente permanezca y no se eleve.
Discusión
Una empresa ha aplicado el método TOC para gestionar varios proyectos utilizando solo tres reglas:
Regla 1: Durante la planificación, escalonar el lanzamiento de proyectos.

Regla 2: planifique duraciones agresivas de proyectos utilizando amortiguadores de proyectos de solo
un tercio de la longitud de la cadena crítica.
Regla 3: Durante la ejecución (a) asegúrese de que las actividades se ejecuten de acuerdo con las
prioridades indicadas por el estado del búfer (Capítulo 11, Ejemplo 11.3) y (b) minimice el consumo
23
del búfer realizando todas las tareas lo antes posible.
¿Qué tan buena es la heurística TOC para la planificación en comparación con las reglas de prioridad
tradicionales? La respuesta es algo equívoca. Para algunos proyectos simples, los resultados son los mismos.
Un experimento exploratorio en el que se comparó TOC con la regla de menor holgura utilizada con frecuencia
mostró que TOC dio mejores resultados, pero otro arrojó resultados más pobres.2425laAunque
lógica yTOC
parece
se basa
teneren
sentido, la verificación en la prácticalorequeriría

diferentes, que aún noinvestigación
se ha hecho.empírica de una variedad de entornos industriales
7.7 Discusión y Resumen

Este capítulo ha cubierto los métodos de programación de proyectos que abordan las limitaciones de
tiempo, las limitaciones de recursos, la incertidumbre acerca de la duración de las actividades y los
proyectos, y los múltiples proyectos que comparten recursos. Los métodos ofrecen formas de acelerar
los proyectos y reducir la incertidumbre sobre las fechas de finalización, aunque, a diferencia de las
técnicas más simples, como los diagramas de Gantt y las redes de ruta crítica, han ganado una
menor aceptación y se aplican principalmente en industrias relativamente sofisticadas. Todos los
métodos tienen limitaciones, pero todos tienen méritos.
• CPM permite a los gerentes determinar la forma menos costosa de reducir la duración del
proyecto para completar el proyecto en una fecha de vencimiento o en el menor tiempo posible.
tiempo.
• PERT permite a los gerentes estimar la probabilidad de terminar un proyecto en una fecha
predeterminada. Pero el método considera solo la ruta crítica actual e ignora las rutas no
críticas que podrían volverse críticas.
La simulación de Monte Carlo supera esta limitación al tener en cuenta la posibilidad de que
cualquier ruta se vuelva crítica.
• El método de la cadena crítica, CCPM, basado en la teoría de las restricciones (TOC), tiene
como objetivo reducir la duración del proyecto. Usando buffers de tiempo, transforma un
problema estocástico en uno determinista más simple. A diferencia de CPM, en el que las
actividades no críticas se programan lo antes posible, CCPM las programa lo más tarde
posible pero con reservas. Con otros métodos, la variabilidad en la duración de las
actividades puede provocar cambios en la ruta crítica sin previo aviso, pero los
amortiguadores en CCPM brindan una estabilidad relativa a la cadena crítica: la ruta que
conecta las actividades que requieren el mismo recurso limitado. CCPM ofrece una forma
práctica y relativamente simple de programar proyectos, pero requiere un cambio en el
comportamiento humano, ya que solo el gerente del proyecto y nadie más debe
comprometerse con las fechas de vencimiento.
Muchos gerentes encuentran ese concepto difícil de tragar.
• La programación de múltiples proyectos presenta los desafíos de asignar recursos escasos a
proyectos simultáneos. La forma tradicional de asignar recursos
entre proyectos (y entre actividades dentro de proyectos) es usar reglas de

prioridad. La forma TOC tiene como objetivo permitir tantos proyectos
simultáneos como sea posible al mejorar el flujo de proyectos a través del
sistema. • Todos los métodos anteriores están soportados por software comercial,
lo que simplifica su aplicación y elimina las dificultades computacionales. Pero
como ocurre con todos los métodos de gestión, la aplicación adecuada de las
técnicas supone una sólida comprensión de los principios que las sustentan y la
aceptación por parte de la dirección.
Lista resumida de símbolos

norte
Número de actividades en la ruta crítica.
Costo de actividad normal: El costo directo de completar una actividad bajo un esfuerzo de trabajo
Cn normal; por lo general, el costo más bajo para completar una actividad.
Costo de actividad de choque: El costo directo de completar una actividad bajo un esfuerzo de
CC
trabajo de choque; por lo general, el costo más alto para completar una actividad.
Duración de la actividad normal: El tiempo esperado para completar una actividad bajo un esfuerzo
Tennesse
de trabajo normal; por lo general, se supone que es el tiempo más largo que tomará el trabajo.
Duración de la actividad del choque: El tiempo esperado para completar una actividad bajo un
tc esfuerzo de trabajo del choque; el menor tiempo posible en el que se puede completar una
actividad.
Duración esperada de la actividad: en PERT, el tiempo medio para completar una actividad, basado
te en estimaciones optimistas (a), más probables (m) y pesimistas (b) de la duración de la actividad.
Duración esperada del proyecto: la probabilidad de que el proyecto finalice antes de Te esta vez es
del 50 por ciento y la probabilidad de que tarde más es del 50 por ciento.
Ts Tiempo objetivo de finalización del proyecto: un tiempo especificado para la finalización del proyecto.
V Varianza de una Actividad: La variabilidad en la duración esperada de la actividad.
Varianza de la Duración del Proyecto: La variabilidad en la duración esperada del proyecto.

Vicepresidente
1. Defina el esfuerzo de choque y el esfuerzo normal en términos del costo y el tiempo que
representar. ¿Cuándo se colapsaría un proyecto?
2. ¿En qué se diferencian CPM y PERT? ¿Cómo son iguales?
3. ¿Qué representa la pendiente del costo?
4. La pendiente del costo siempre tiene un valor negativo. ¿Qué indica esto?
5. El análisis de compensación de costos de tiempo se ocupa solo de los costos directos.
¿Qué distingue estos costos de los costos indirectos? Dé ejemplos de costos directos
e indirectos.
6. ¿Cuáles son las críticas a CPM? ¿Cómo y dónde se limita el CPM en su
¿solicitud?
7. La red del proyecto y los costos asociados (T en días, C en $1,000s) son
mostrado a continuación.
una. Verifique que la duración normal sea de 22 días y que el costo directo
es $3,050.
b. ¿Cuál es la forma menos costosa de reducir la duración del proyecto a 21 días? ¿Cuál
es el costo del proyecto? C. ¿Cuál es la forma menos costosa de reducir la duración a
20 días?
¿Cuál es el costo del proyecto?
d. Ahora, ¿qué es lo más pronto que se puede completar el proyecto y cuál es la forma
menos costosa de hacerlo? ¿Cuál es el costo del proyecto?
8. La red del proyecto y los costos asociados (T en días, C en $1,000s) son

mostrado a continuación.
una. ¿Qué es lo más pronto que se puede completar el proyecto en condiciones normales?
¿condiciones? ¿Cuál es el costo directo?
b. ¿Cuál es la forma menos costosa de reducir la duración del proyecto en 2 días? ¿Cuál
es el costo del proyecto? C. ¿Qué es lo más pronto que se puede completar el proyecto
y cuál es la forma menos costosa de hacerlo? ¿Cuál es el costo del proyecto?
9. La siguiente tabla da información sobre un proyecto (T en días, C en

$1,000s):
una. Dibujar el diagrama de red. En condiciones normales, ¿qué es lo más pronto

que se puede completar el proyecto? ¿Cuál es el costo directo?
¿Qué es la ruta crítica? b.
¿Cuál es el costo del proyecto si se completa 1 día antes?
¿Dos días antes? C.
¿Qué es lo más pronto que se puede completar el proyecto? ¿Cuál es el costo más
bajo para completarlo en este tiempo? d. Si los costos generales (indirectos) son
de $20 000 por día, ¿para qué duración del proyecto los costos totales del proyecto
(directos + indirectos) son los más bajos?
10. ¿Alguna vez la variabilidad en el tiempo estimado le ha hecho llegar tarde a una cita?
Describir.
11. Un oficial de adquisiciones encuentra que el tiempo de entrega de un artículo específico
nunca se entrega en menos de 5 días. El peor de los casos es que el artículo tarde 30 días
en llegar. Un plazo de entrega de 10 días es el más frecuente.
una. Calcular el tiempo de entrega esperado b.

¿Qué estimación daría para su varianza? C. ¿Qué factores
tomaría en cuenta al decidir la cantidad de tiempo para permitir el artículo en el plan
del proyecto?
12. Las siguientes tablas muestran los predecesores inmediatos y a, m, b para cada actividad
en los dos proyectos. Para cada proyecto calcular:
una. te y V para cada actividad

b. ES, EF, LS y LF para cada actividad.

C. Te y Vp para el proyecto.
Actividad Antecesores amb

A - 7 9 11
B A 1 2 3
C A 7 8 9
D B 2 5 11
mi C 2 3 4
F C 14 8
GRAMO
D, E 6 7 8
H F, E 2 6 9
Actividad Antecesores amb
A - 24 6
B - 2 2 3
C - 48 10
D A 46 7
mi un, b 7 9 12
F D, E 1 2 3
GRAMO C 2 3 4
H F, E 2 6 9
13. Consulte la primera red en el problema anterior.
una. ¿Qué es P(Te< 23)?

b. ¿Qué es P(Te< 32)?
C. Para lo que Ts es la probabilidad del 95 por ciento de que el proyecto sea
¿terminado?
14. Para la red de la figura 7.12, ¿cuál es la probabilidad de completar

cada uno de los cinco caminos dentro de 30 días? ¿Cuál es la probabilidad de
completarlos todos dentro de los 30 días?
15. ¿Cómo usaría los amortiguadores para asegurarse de llegar a tiempo a
¿equipo? ¿Qué factores tendría en cuenta al tomar una decisión sobre el tamaño de la
reserva?
16. Explique con sus propias palabras cómo el principio de agregación juega un papel
en la reducción de la duración del proyecto.
17. El siguiente diagrama se dibujó antes de que quedara claro que Mary tendría que
realizar tanto la Actividad B como la Actividad F.
una. Al darse cuenta de que María tiene que hacer las dos tareas, indique dos
posibles cadenas críticas. b. Reprograme el trabajo e indique la posición y el
tamaño del búfer de alimentación.
18. Consulte la red en la Pregunta 19 en las Preguntas y problemas de repaso del Capítulo
6.
Ver Capítulo 6
una. Indique la cadena crítica en el diagrama. b.

Suponga que el cronograma usa duraciones de las cuales se ha eliminado
cualquier contingencia (relleno). Inserte un búfer de proyecto y búferes de
alimentación según sea necesario.
19. Consulte la Figura 7.22. Programar la Actividad T antes de la Actividad Q también

habría sido una forma de resolver la contingencia de recursos. Explique por qué esto
No se seleccionó la alternativa.
20. Considere los datos sobre las actividades del proyecto que se dan en la siguiente tabla.
una. Programe el trabajo de tal manera que cada persona siempre tenga
solo una tarea a realizar (no reduzca la duración de
actividades o insertar tampones todavía).
b. Indicar la cadena crítica.
C. Indique dónde deben insertarse los amortiguadores de alimentación.

d. ¿Cuál es la diferencia entre las longitudes de la ruta crítica y la
cadena crítica?
Actividad Predecesor(es) Duración (Días) Recursos

A - 2 John
B A 3 demandar
C - 3 su y juan
D C 2 Alabama
mi D, J 3 su y al
F E, B 2 John
GRAMO F 2 Ana
H - 4 demandar
j H 2 Alabama
21. Discutir la diferencia entre la ingeniería concurrente de vía rápida,

y chocando
22. Escriba un ensayo sobre las razones por las que los proyectos a menudo se retrasan.
23. Discuta las implicaciones que el trabajo subcontratado tendría en

implementando CCPM.
24. Discutir las implicaciones de la asignación de recursos para las organizaciones involucradas
en múltiples proyectos.
25. Vuelva a consultar la pregunta 18:
una. Use la regla del tiempo de tarea más corto para resolver el problema y dibuje un
Gráfico de gantt.
b. Aplique la regla de menor holgura para resolver el problema y dibuje un Gantt

cuadro.
C. Aplique los primeros tres de los cinco pasos de TOC (sección 7.6) al problema y dibuje
un diagrama de Gantt. d. ¿Quién sería el “recurso del tambor”?
mi. ¿Cómo son los días que Ann no tiene trabajo que hacer en este proyecto?
relacionarse con TOC Paso
3? F. Suponga que las dos personas en este problema también trabajan en varios otros
proyectos, y la política es usar la regla de tiempo de tarea más corto y las prioridades
relativas de los proyectos para decidir en qué actividad debe trabajar un recurso. ¿Qué
regla (menor tiempo de tarea o mayor prioridad de proyecto) debería tener preferencia?
Conversar.
26. En un entorno de proyectos múltiples, el recurso de tambor tiene un cierto "estatus" ya que el
trabajo realizado por otros recursos (y las necesidades de otros recursos) están subordinados a
él. En una empresa la gerencia puso una bandera en un centro de trabajo para indicar que era el
recurso bidón. Una mejora (TOC Paso 4) eliminó este centro de trabajo como la restricción y la
bandera se movió a otro lugar a la nueva restricción. Las personas que trabajaban en el centro
original se sintieron decepcionadas y protestaron. ¿Cómo sugiere que la gerencia debe manejar
este problema?
1. En el proyecto que estás estudiando, discute cuál de los siguientes tipos de

se realizaron analisis:
una. IMPERTINENTE
b. Análisis de compensación CPM/tiempo-

costo c. Programación con limitaciones de
recursos d. CCPM
2. Discuta cómo se aplicaron y muestre ejemplos. Discuta aquellas aplicaciones que no se

aplicaron pero que parecen especialmente aplicables al proyecto.
3. ¿Cómo califica el riesgo de no terminar a tiempo y cuáles son los factores que contribuyen
a este riesgo?
4. ¿Se requirió que las personas (además del gerente del proyecto) hicieran compromisos
sobre la duración de las actividades? Comente la posibilidad de cambiar este
comportamiento.
Caso 7.1 Contratistas Bridgecon
Bridgecon Construction Company se especializa en el detalle, diseño y construcción de

puentes de acero y hormigón. La primera fase de la metodología de gestión de proyectos de
la empresa, Iniciación, incluye la identificación de oportunidades de proyectos y la evaluación
de los riesgos de cada proyecto y la alineación con los objetivos estratégicos. El departamento
de marketing de Bridgecon identificó una oportunidad: un conocido arquitecto de puentes
completó recientemente el diseño conceptual de un puente atirantado destinado a cruzar
líneas ferroviarias electrificadas. Los altos directivos sintieron que la empresa podía manejar
el proyecto y decidieron seguir adelante; esto marcó el final de la primera fase.
Luego, el proyecto ingresa a la segunda fase, Estimación, que incluye visitas al sitio por
parte del equipo de estimación, revisión de los recursos y habilidades disponibles,
evaluación detallada de riesgos y preparación de un plan preliminar para el diseño
detallado, adquisición, logística y construcción. La fase incluye las actividades A y B de la
Tabla 7.6, que son necesarias para preparar la oferta para la construcción del puente. La
fase concluye con una presentación al cliente, la autoridad ferroviaria.
El gerente del proyecto y el equipo de estimación se reúnen con el arquitecto y los

ingenieros estructurales que produjeron el diseño conceptual para familiarizarse con el
diseño. Luego se reúnen con subcontratistas que podrían elegir para construir los pilotes y
fabricar componentes de acero.
Después de estas reuniones, se completan la “Estimación de la duración inicial” y la
“Estimación del costo inicial”, como se indica en la Tabla 7.6.
La RFP para la construcción del puente dice que la aceptación del plan por parte de la
autoridad ferroviaria es un criterio para seleccionar un contratista. Desde el principio se
hace evidente que a partir de la actividad D y hasta la finalización de la actividad S, la
operación de una de las líneas ferroviarias debajo del puente se verá afectada, aunque
una discusión informal con la autoridad ferroviaria indica que eso podría ser aceptable. Sin
embargo, durante una reunión posterior, la autoridad ferroviaria expresa su preocupación
de que el deterioro durará 17 semanas y solicita a Bridgecon que encuentre formas de
reducir ese tiempo. El equipo de estimación sugiere las siguientes posibilidades:
• La duración de la actividad N podría reducirse de una semana a media semana

mediante el uso de camiones adicionales. El costo adicional sería de $33,000.
• Se busca un subcontratista alternativo para el pilotaje. Este subcontratista dice que

podrá reducir a la mitad el tiempo de la actividad H por un costo total de $960 000.
Se identifican dos formas de acortar la duración de la actividad D. En primer lugar,

se podrían emplear trabajadores temporales adicionales. Esto reduciría la
duración a 3 semanas y aumentaría el costo a $147,000. En segundo lugar, un
equipo de trabajadores altamente capacitados en este procedimiento (y sus
equipo) podría reasignarse temporalmente de otro proyecto.

Agregar este equipo y trabajadores temporales al equipo original podría
llevar a completar el trabajo en 1 semana.
Tabla 7.6 Actividades para la Construcción del Puente Atirantado
Inicial
Inicial
Costo
Actividad Actividad Descripción Duración Antecesores
Estimar
Estimar
($1,000)
sitio detallado –
A 2 17
investigación y encuesta
B Planificación detallada 6 A dieciséis
C Diseño detallado 6 B 557
D Preparación del sitio 4 C 47
mi Reubicar servicios 3 C 28
F Vuelva a alinear la vía superior 4 650

C, E
electrificación
GRAMO
Camino de acceso y rampa 1 D 63
construcción
H Pilotaje 2 GRAMO 820
Construir cimientos
j 3 H 975
y pilares
Construir temporal
k soportes para apoyar 2 720

F, G
cubierta del puente durante
construcción
Planificación de la fabricación de
L acero estructural 2 C 13
componentes
Fabricación estructural
METRO
componentes de acero (fuera 2 L 1320
del sitio)
Transporte estructural
norte
componentes de acero y 1 METRO 433
erigir en el sitio
Levantar pilones y rellenar 2 840

PAGS
j
con concreto
Construir tramo principal

q cubierta en prefabricado 3 H, K, N, P 2800
vigas de concreto
Instalación de cables atirantados

R y levanta la plataforma del puente 3 q 875
sin apoyos temporales
S Eliminación de temporal 1 R 54
apoya
T Sistema eléctrico 1 S 147

instalación
Pavimentación de carreteras
tu 2 S 142
(pavimentación)
V Acabados y accesorios 2 T, tu 76
W Puesta en marcha - corte 1 V 14

sobre
entrega formal y
X 1 W 9
ceremonia
Y aprobación del proyecto 1 X 1
Z Cierre administrativo 1 W 4
Finalización del proyecto AA (Hito) 0 Y, Z

10621
El gerente del otro proyecto estima que la reasignación

le haría perder una tarifa de incentivo de $ 150,000 por terminar
su proyecto temprano. Los responsables de los dos proyectos coinciden en que, en caso de
se haga la reasignación, el valor de la tarifa de incentivo se reservará
como un costo contra el proyecto del puente atirantado y transferido como un
bono al otro proyecto.
• La duración de la actividad F se puede reducir a 3 semanas pero
aumentar el costo de la actividad a $730,000. Se puede reducir a 2 semanas.
pero costaría $820,000.
• La duración de la actividad Q se puede reducir a 2 semanas, pero la

actividad costaría $2,929,000.
Preguntas
1. Elaborar una lista que muestre los períodos reducidos por deterioro de la
operación ferroviaria y los costos adicionales asociados.
2. Comente las implicaciones que podría tener la colisión en el riesgo
de no cumplir con la fecha de vencimiento comprometida.
Caso 7.2 Proyecto de inicio de sesión
Después de firmar el contrato, la gerencia de Midwest Parcel Distribution (MPD)

descubre que, por muchas razones, sería ventajoso completar el proyecto en 40
semanas. Es demasiado tarde para que MPD “exija” que el contratista Iron Butterfly
lo complete en ese tiempo, pero no obstante analiza la posibilidad con el gerente de
proyecto de Iron Butterfly Company, Frank Wesley. Al revisar el diagrama de red
(abajo, Figura 7.26), Frank verifica la factibilidad de esto y luego les pide a sus
gerentes y personal técnico que le den tres estimaciones de tiempo para cada
actividad en el proyecto. Las estimaciones se dan a continuación en la Tabla 7.7.
Figura 7.26 Proyecto LOGON.

Preguntas
1. ¿Cuál es la probabilidad de terminar dentro de las 40 semanas?

2. ¿Prevé algún riesgo significativo de retraso en los cálculos?
para (1) anterior no se tiene en cuenta?
3. Determinar la duración más probable del proyecto.
Tabla 7.7 Estimaciones de tiempo para el proyecto LOGON
Duración optimista Más probable Duración pesimista

Actividad
(Semanas) Duración (Semanas) (Semanas)
H 10 10 10
yo 8 8 dieciséis
j 1 6 6
k 4 4 4
L 2 2 2
METRO 2 4 5
norte 4 4 10
O 5 5 5
PAGS 5 5 5
q 5 5 5
R 2 5 5
S 3 3 6
T 3 3 3
tu 1 1 2
V 3 5 5
W 2 2 8
X 3 3 3
Y 8 8 8
Z 6 6 6
Z 6 6 6
Caso 7.3 Proyecto de la aldea de Papua Petera
Papua Petroleum Company está construyendo una aldea para apoyar a los trabajadores de
un campo petrolero en Sumatra. El trabajo principal del proyecto incluye cinco paquetes de
trabajo: construcción de carreteras, limpieza del sitio, erección de edificios, erección de una
planta de generación de energía y construcción de un sistema de purificación de agua. La
Figura 7.27 es un diagrama de red de alto nivel para el proyecto. Para explorar formas de
acelerar el proyecto, Papúa pidió a sus contratistas que enviaran información sobre el tiempo
y el costo de las cuadrillas que trabajan hasta tres turnos por día. (La tecnología de
iluminación portátil permitiría que el trabajo continuara durante la noche para el segundo y
tercer turno). Los contratistas respondieron con las siguientes estimaciones, que excluyen
los costos de materiales, suministros, componentes y sistemas que son fijos
independientemente de los tiempos de trabajo.
Figura 7.27 Proyecto de la aldea de Papua Petera.

Paquete de trabajo A: Construir carretera
• Longitud del camino,

10 km • Un turno puede construir 0,1 km de
camino • Costos del primer turno: mano de obra, $4,000/día;
equipo, $8,000/día • Segundo y tercer turno, costo por turno: mano de obra, $6,000; equipo
$9,000/día
Paquete de trabajo B: Sitio limpio
• Usando un turno, el sitio se puede limpiar en 10 días; si dos turnos, 5 días; si

tres turnos, 4 días •
Costos, mano de obra y equipo del primer turno: igual que el paquete de
trabajo A • Segundo y tercer turno, costo por turno: igual que el paquete de trabajo A
Paquete de trabajo C: Edificación de edificios
Se construirán cuarenta edificios de tres modelos estándar, todos del mismo tamaño.
Cada turno puede construir tres edificios por semana. Suponga semanas laborales
de 5 días.
• Costos del primer turno: mano de obra, $4,000/día; equipo,

$1,000/día • Segundo y tercer turno, costo por turno: mano de obra, $6,000; equipo
$1,500/día
Paquete de trabajo D: erigir una planta de generación de energía,

Instalar líneas eléctricas en edificios
El paquete de trabajo tomará 10 semanas; con un segundo turno, tomará 5 semanas.

Suponga 5 días/semana.
• La escasez de mano de obra no permite un tercer

turno • Costos del primer turno: mano de obra, $6,000/día; equipo,
$3,000/día • Segundo turno, costo por turno: mano de obra, $9,000; equipo $4,200/día
Paquete de trabajo E: Construir un sistema de purificación de agua,

Instalar líneas de agua y alcantarillado en edificios
El paquete de trabajo tomará 8 semanas; con un segundo turno tomará 4 semanas.

Suponga 5 días/semana.
• La escasez de mano de obra no permite un tercer

turno • Costos del primer turno: mano de obra, $5,000/día; equipo,
$4,000/día • Segundo turno, costo por turno: mano de obra, $7,500; equipo $5,500/día
Los costos anteriores son todos costos directos. Además, está el costo indirecto: el costo
de gestión y administración del proyecto en general; esto se estima en $ 3,000 / día durante el
tiempo que dure el proyecto.
Dada esta información, Papúa le ha pedido al gerente del proyecto, Abdul Ginting, que
calcule los costos alternativos totales del proyecto y la duración del proyecto para dos casos:
(1) la alternativa de menor costo y cuánto tiempo tomaría el proyecto, y (2) la alternativa de
menor duración del proyecto y cuánto cuánto costaría el proyecto. Abdul está preparando su
análisis y el curso de acción recomendado.
Notas finales
1. CPM apareció por primera vez en el artículo de sus creadores: Kelley J. y Walker M. Critical Path Planning and
Planificación. Conferencia de Informática Conjunta del Este. Boston, MA; 1959, págs. 160–173.
2. Goldratt AY. Instituto, correos electrónicos grupales enviados el 17 y 18 de marzo de 1999; Larry English, Hábitat para
Humanidad, enero de 2007, Pretoria, Sudáfrica; Habitat for Humanity, la casa más rápida del mundo,
consultado en enero de 2007 desde http://www.habitat.org/newsroom/1999archive/insitedoc004016.aspx?
imprimir = verdadero.
3. Para obtener una aproximación por partes de las relaciones no lineales, consulte Wiest J. y Levy F. A Management
Guía de PERT/ CPM: con GERT/ PDM/ DCPM y otras Redes. Englewood Cliffs, Nueva Jersey: Prentice-Hall;
1977, págs. 81–85. La relación entre el número de trabajadores y la duración de la actividad no es lineal; es decir, reducir el número
de trabajadores a la mitad no duplicará el tiempo pero podría aumentarlo, digamos, 50-150
por ciento, dependiendo de la tarea. Ver Brooks F. The Mythical Man Month: Ensayo sobre ingeniería de software.
Lectura, MA: Addison-Wesley; 1995, págs. 13–36.
4. El método apareció por primera vez en el artículo de los creadores de PERT: Malcolm D., Roseboom J., Clark C.
y Fazar W. Aplicación de una técnica para la evaluación de programas de investigación y desarrollo. Operaciones
Investigación 7, núm. 5; 1959, 646–670.
5. Véase Miller R. Schedule, Cost, and Profit Control with PERT. Nueva York, NY: McGraw-Hill; 1963, pág. 58;
Kerzner H. Gestión de proyectos: un enfoque de sistemas para la planificación, programación y control, décimo
ed. New Jersey; 2009, pág. 529
6. Véase Krakowski M. PERT y la Ley de Parkinson. Interfaces 5, núm. 1 de noviembre de 1974; y Vazsonyi A.
L'Historie de la grandeur et de la decadence de la methode PERT. Ciencias de la administración 16, no. 8 de abril
1970 (escrito en inglés). Kerzner, Project Management, describe otros problemas de PERT/CPM.
págs. 519–522; Miller, Schedule, Cost, and Profit Control with PERT, págs. 39–45; y Weist y Levy, A.
Guía de gestión de PERT/ CPM, págs. 57–58, 73, 166–173. Las referencias al comportamiento humano se encuentran en el
literatura de cadena crítica a la que se hace referencia en este capítulo.
7. Véase Métodos de Van Slyke R. Monte Carlo y el problema PERT. Investigación de operaciones 11, no. 5; 1963, 839–
860.
8. Adaptado con autorización de Evans J. y Olson D. Introducción a la simulación y el análisis de riesgos.
Upper Saddle River, Nueva Jersey: Prentice Hall; 1998, pág. 111–120.
9. Crystal Ball es una marca registrada de Decisioneering, Inc.; para obtener información, visite decisioneering.com.
RiskSim es una marca registrada de Treeplan.com; consulte www.treeplan.com. Para @Risk, visite www.palisade.com. Para
Arena, visite www.rockwellautomation.com. Para Simul8, visite www.simul8.com
10. Escuelas Viljoen P. Goldratt, comunicación personal, Pretoria, SA, mayo de 2007, mayo de 2010 y abril de 2015.
11. Goldratt E. ¿Qué es esta cosa llamada teoría de las restricciones y cómo debería implementarse? Nuevo
York: North River Press, Inc. 1990.
12. Pittman P. Gestión de Proyectos: Una Metodología más Efectiva para la Planificación y Control de Proyectos.
Georgia: tesis doctoral, Universidad de Georgia; 1994; Cadena crítica EM de Goldratt . gran barrington,
MA: Prensa del río norte; 1997.
13. Walker E. Planificación y control de proyectos múltiples, simultáneos e independientes en un recurso
Entorno restringido, Georgia: tesis doctoral, Universidad de Georgia; 1998. Un método TOC para
La asignación de recursos a múltiples proyectos se desarrolló en este estudio y posteriormente se ha
desarrollado aún más.
14. Goldratt E. Cadena crítica. Gran Barrington, MA: North River Press; 1997, pág. 156.
15. Herroelen W. y Leus R. Sobre las ventajas y desventajas de la programación en cadena crítica. diario de operaciones
Gestión 2001; (7): 559–577; Leach L. Gestión de proyectos de cadena crítica, 2ª ed. Norwood, Massachusetts:
Artech House, Inc., 2003; Geekie A. y Steyn H. Tamaño de búfer para el método de gestión de proyectos de cadena crítica. SA
Revista de Ingeniería Industrial; 2008; 19(1): 73–88.
16. Newbold R. Gestión de proyectos en el carril rápido: aplicación de la teoría de las restricciones. Nueva York: St.
Prensa de Lucie; 1988.
17. Tukel I., Rom W. y Eksioglu SD Una investigación de las técnicas de dimensionamiento del búfer en la programación de la cadena
crítica. Revista europea de investigación operativa 2006; 172: 401–416; véase también Trietsch D. El efecto
de errores sistémicos en los amortiguadores óptimos del proyecto. Revista Internacional de Gestión de Proyectos, 2005; 23:
267–274; Shou Y. y Yeo K. Estimación de los amortiguadores de proyectos en la gestión de proyectos de cadena crítica.
Actas de la conferencia internacional IEEE sobre gestión de la innovación y la tecnología, 2000:
162–167.
18. Goldratt, Cadena Crítica.
19. Para Prochain, consulte www.prochain.com; para Sciforma, consulte www.sciforma.com; para Concierto, véase
www.realización.com.
20. Escuelas Viljoen P. Goldratt, comunicación personal, Pretoria, SA, mayo de 2007, mayo de 2010 y abril de 2015.
21. Turner JR El manual de gestión basada en proyectos. Londres, Reino Unido: McGraw-Hill; 1993.
22. En Goldratt E. y Cox J. The Goal 4th edn. Gran Barrington, MA: North River Press; 2014; También en
Goldratt E. y Fox R. La carrera. Croton-on-Hudson, Nueva York: North River Press; 1986. La noción de usar
se describe la restricción (tambor) para marcar el ritmo.
23. Adaptado del material de formación de Realización. Consulte www.realization.com.
24. Dass S. y Steyn H. Una evaluación exploratoria de la duración del proyecto en cronogramas de proyectos múltiples donde
los recursos se asignan mediante el método de la teoría de las restricciones. Revista SA de Ingeniería Industrial, 2006;
17(1): 39–54.
25. Cohen I., Mandelbaum A. y Shtub A. Programación y control de proyectos múltiples: un enfoque basado en procesos
estudio comparativo de la metodología de la cadena crítica y algunas alternativas. Diario de gestión de proyectos
2004; 35(2): 39–50.

Capítulo 8
Estimación de costos y elaboración de presupuestos
Las estimaciones de costos, los presupuestos, las EDT, los cronogramas, la calidad y el riesgo están interrelacionados.
Idealmente, las estimaciones de costos se basan en elementos de la EDT y se preparan

para cada paquete de trabajo. Cuando el costo no se puede estimar porque una actividad
es demasiado compleja, la actividad se desglosa aún más hasta que se pueda. Cuando el
trabajo está mal definido o es incierto, la estimación se basa inicialmente en el juicio y luego
se revisa a medida que la información está disponible. Los cronogramas del proyecto dictan
la necesidad de recursos y la tasa de gastos, pero lo contrario también es cierto: las
restricciones sobre los recursos y el capital de trabajo dictan los cronogramas. Es necesario
imponer restricciones prácticas a los costos para crear presupuestos de proyectos realistas;
de no hacerlo, los proyectos se completan a un costo exorbitante o se cancelan
prematuramente debido a la falta de fondos. Ambas ocurrencias son relativamente comunes.
A veces se piensa que la estimación de costos, la presupuestación y el control son
preocupaciones exclusivas de los especialistas en costos, planificadores y contadores, pero
en los proyectos deberían ser preocupaciones de todos. Los participantes del proyecto que
están más cerca de las fuentes de costos (ingenieros, científicos, especialistas en sistemas,
arquitectos u otros) deben participar en el proceso de estimación y presupuestación.
Comúnmente, sin embargo, estas mismas personas desdeñan los presupuestos e ignoran
cómo funcionan o por qué son necesarios.
El director del proyecto, por supuesto, también debe participar. Aunque ella no
necesita ser un mago financiero, necesita ser hábil en la organización y el uso de cifras de
costos. El gerente del proyecto supervisa el proceso de estimación de costos y elaboración
de presupuestos, a menudo con la ayuda de un contador de costos de personal. En la
mayoría de los proyectos técnicos, el ingeniero de costos revisa los entregables y los
requisitos, evalúa el proyecto desde el punto de vista técnico y de costos, y asesora al
gerente del proyecto. La ingeniería de costos se analiza más adelante.
8.1 Estimaciones de costos
La estimación de costos puede sellar el destino financiero del proyecto. Cuando se sobrestiman los costos
del proyecto, el contratista corre el riesgo de perder el trabajo ante un competidor que haga una oferta más baja.
Peor es cuando son subestimados. Una oferta de precio fijo de $50,000 podría ganar el contrato, pero
obviamente el contratista perderá dinero si el proyecto termina costando $80,000. La subestimación a menudo
es accidental, el resultado de ser demasiado optimista, aunque a veces es intencional, el resultado de
esforzarse demasiado para vencer a la competencia. En una práctica llamada aceptación, el contratista
reduce una estimación inicialmente realista lo suficiente como para ganar el contrato, con la esperanza de
reducir costos o renegociar un precio más alto una vez que el trabajo esté en marcha. La práctica es
arriesgada, poco ética y, lamentablemente, relativamente común. En proyectos de gran capital, la tendencia
es subestimar los costos para obtener el financiamiento necesario para lanzar el proyecto, pero luego olvida
la estimación poco después.
Pero una oferta muy baja también puede significar que el contratista tomó atajos en el presupuesto, se
olvidó de incluir cosas o simplemente fue descuidado. Las consecuencias tanto para el cliente como para el
contratista pueden ser desastrosas, desde sufrir pérdidas hasta la bancarrota. Las estimaciones de costos se
utilizan para desarrollar presupuestos. Una vez que comienza el proyecto, los costos reales se comparan con
los costos estimados y presupuestados como una medida del desempeño del proyecto. Sin buenas
estimaciones, es imposible evaluar la eficiencia del trabajo o determinar de antemano cuánto costará el
proyecto al finalizar.
8.2 Aumento de costos
Estimar los costos con precisión puede ser difícil porque el proceso de estimación comienza
en la concepción del proyecto y antes de que se sepa mucho sobre el proyecto. Cuanto menos
definido esté el proyecto, mayores serán las posibilidades de que los costos reales difieran
sustancialmente de los costos estimados. Por regla general, la estimación será demasiado
baja y el proyecto sufrirá un sobrecosto. La cantidad por la cual los costos reales crecen para
exceder las estimaciones iniciales se conoce como escalamiento de costos. Cierta escalada
es normal y hasta un 20 por ciento es común. Por lo general, cuanto más grande y complejo
sea el proyecto, mayor será el potencial de escalamiento. Los costos de la tecnología de punta
y los proyectos de investigación con frecuencia aumentan varios cientos por ciento. El avión
de pasajeros supersónico Concorde superó la estimación original por un factor de cinco, las
plantas de energía nuclear a menudo superan las estimaciones por un factor de dos o tres, y
las naves espaciales de la NASA a veces por un factor de cuatro a cinco.
La Figura 8.1 muestra un gráfico del sobrecosto porcentual frente al año de decisión de
construir 1 El para 111 proyectos relacionados con el transporte que abarcan aproximadamente
80 años. El estudio que informó estos hallazgos también analizó otros 246 proyectos y obtuvo
una imagen similar. Claramente, los sobrecostos han sido y siguen siendo comunes. ¿Cómo
sucede eso? Hay muchas razones.
Figura 8.1 Proyectos versus porcentaje de sobrecosto.
Incertidumbre y falta de información precisa
Mucha de la información necesaria para estimaciones precisas simplemente no está disponible cuando
se estiman los costos por primera vez. En la NASA, por ejemplo, la falta de un diseño de naves espaciales
bien definido y una definición poco clara de los experimentos es la razón principal de los sobrecostos.
Hasta más tarde, cuando se finaliza el diseño y las actividades de trabajo están bien definidas (durante la
fase de definición), se pueden determinar con precisión los costos de materiales y mano de obra. En la
mayoría de los proyectos de investigación y desarrollo, las actividades son impredecibles, de duración
incierta o deben repetirse. No obstante, la gerencia debe esforzarse por obtener el alcance del trabajo, los
objetivos del proyecto y los requisitos más claros y definitivos, ya que sin ellos es casi imposible obtener
estimaciones de costos precisas.
Durante el proyecto, siempre que se cambien los diseños de productos o los cronogramas del proyecto
son necesarios debido a cambios en el concepto del producto, barreras de desarrollo, huelgas,
enredos legales o aumento vertiginoso de salarios y costos de materiales, la estimación del costo del
proyecto también debe actualizarse para que sirva como una línea de base válida para rastrear y
controlar los costos del proyecto.
Para permitir la incertidumbre, se agrega a la estimación original una cantidad llamada fondo de
equivalente presupuestario de la reserva . horario de contingencia
reserva o colchón
o presupuesto
mencionado
. 2 Este
en los
escapítulos
el
anteriores. El monto de la contingencia es proporcional a la incertidumbre de la obra; cuanto mayor es
la incertidumbre, mayor es la contingencia.
El director del proyecto (ya veces el patrocinador del proyecto o el comité directivo) controla la
asignación del fondo de contingencia. El fondo (discutido más adelante en este capítulo) está destinado
principalmente a compensar pequeños sobrecostos que surgen de errores de estimación, omisiones y
cambios menores de diseño y retrasos en el cronograma.
Cada vez que se actualiza la estimación de costos, también se actualiza el fondo de contingencia. El
fondo no es un fondo "para sobornos" y debe eliminarse del presupuesto del proyecto cuando ya no
se necesite según lo previsto; de lo contrario, los costos del proyecto tenderán a aumentar para gastar
lo que quede en el fondo. Las contingencias se discuten más adelante.
Cambios en los requisitos o el diseño
La escalada de costos también se produce debido a la alteración del alcance: cambios discrecionales
y no esenciales realizados en los requisitos y planes del sistema. Estos cambios provienen de un
cambio de mentalidad, no de descuidos, errores o mandatos que los harían imperativos. La tendencia
habitual es que tanto los usuarios como los contratistas deseen modificar los sistemas y procedimientos,
para realizar “mejoras” a lo largo del ciclo de vida del proyecto. Dichos cambios son especialmente
comunes en ausencia de una planificación minuciosa o procedimientos de control estrictos.
Los contratos ocasionalmente incluyen una cláusula de cambio que le permite al cliente realizar
ciertos cambios en los requisitos del contrato, a veces por un pago adicional, a veces no. La cláusula
permite flexibilidad al cliente para incorporar requisitos no previstos en el momento del acuerdo del
contrato original. Puede ejercerse en cualquier momento y el contratista está obligado a cumplir. Sin
embargo, cualquier cambio, por pequeño que sea, provoca una escalada; Es usual
Implica una combinación de rediseño o reorganización del trabajo, adquisición de recursos nuevos
o diferentes, alteración de los planes o deshacer o desechar el trabajo anterior. Cuanto más
avanzado esté el proyecto, más costoso será el cambio. Cuando se acumulan, incluso los
pequeños cambios tienen un efecto sustancial en los cronogramas y costos. Los procedimientos
formales de control de cambios para reducir el número de cambios y contener la escalada se
describen en el Capítulo 11.
Ver Capítulo 11
Factores económicos y sociales
Incluso con buenas estimaciones iniciales y pocos cambios, la escalada de costos ocurre debido
a fuerzas sociales y económicas más allá de la influencia de cualquiera. Las huelgas laborales,
las acciones legales de los grupos de interés, los embargos comerciales y la escasez de
materiales, todos los cuales sirven para sofocar el progreso y aumentar los costos, no pueden
anticiparse con precisión ni incluirse en los planes y presupuestos. Cada vez que se suspende o
interrumpe el trabajo, los costos administrativos y generales continúan aumentando, los intereses
y los costos de arrendamiento sobre el capital y el equipo prestados continúan acumulándose, y
la fecha en que comienza el reembolso y la ganancia obtenida se retrasa. Rara vez se pueden
anticipar tales problemas e incorporar sus impactos en el fondo de contingencia.
Un factor económico que influye en la escalada de costos es la inflación. El contratista podría
compensar este factor inflando el precio del proyecto, aunque la capacidad de hacerlo a menudo
se ve impedida por las acciones de los competidores o las restricciones federales sobre los
aumentos de precios. Se puede obtener cierta protección contra la inflación al incluir cláusulas en
el contrato que permitan aumentos en los costos de materiales y salarios, pero la protección
contrato, no unidimensional; varía según
puede
la mano
ser limitada.
de obra,La
losinflación
materiales
se agrega
y el equipo
al precio
empleados,
del
y según la región geográfica y el país. Los subcontratistas, proveedores y clientes usan diferentes
contratos con diferentes cláusulas de protección contra la inflación que pueden ser ventajosas o
desventajosas para otras partes en el proyecto.
La inflación también provoca dificultades de flujo de efectivo. Incluso cuando un contrato
incluye una cláusula de inflación, el pago de los costos relacionados con la inflación debe estar
vinculado a la publicación de los índices de inflación, que siempre va a la zaga de la inflación. Contratistas
pagan inmediatamente los efectos de la inflación pero no son reembolsados por esos efectos hasta
más tarde.
Las estimaciones de costos generalmente se basan en los precios en el momento de la estimación.

Por lo tanto, siempre que se conozcan las tasas de inflación, las estimaciones deben ajustarse para
proporcionar una línea de base válida a partir de la cual identificar luego las variaciones de costos y
tomar medidas correctivas. En los proyectos a largo plazo, se deben pronosticar las tasas salariales
futuras; esto se hace comenzando con costos salariales estimados en dólares corrientes y luego
aplicando tasas de inflación durante la duración del proyecto.
En los proyectos internacionales, los costos aumentan debido a los cambios en los tipos de cambio.
Cuando los costos se incurren en una moneda pero se pagan en otra, los cambios en el tipo de cambio
harán que cambien los valores relativos de los costos y los pagos, lo que resultará en una escalada de
costos o precios. Este tema se trata en el Capítulo 19.
Ver Capítulo 19
Ineficiencia, mala comunicación y falta de control
La escalada de costos también es el resultado de la ineficiencia en el trabajo, la mala gestión y

planificación, la mala comunicación, la falta de supervisión y el control débil. Especialmente en
proyectos grandes, esto conduce a conflictos, malentendidos, duplicación de esfuerzos y errores. Esta
es una fuente de escalada donde la gerencia tiene una influencia sustancial. La planificación cuidadosa
del trabajo, el seguimiento y la supervisión de las actividades y el control estricto mejoran la eficiencia
y contienen la escalada de costos.
Implicación del ego del estimador
La escalada de costos también resulta de la forma en que las personas estiman. Muchas personas
son demasiado optimistas y habitualmente subestiman el tiempo y el costo, especialmente para
trabajos en los que tienen poca experiencia. ¿Alguna vez ha estimado el tiempo que le llevaría pintar
una habitación o colocar los azulejos en un piso? ¿Cuánto tiempo tomó realmente ?
A veces, por supuesto, sucede lo contrario: preocupados por sobrepasar el presupuesto, lo “rellenan”.
Cuanto más se involucre en el trabajo el ego del perito, más
menos fiable la estimación.
Las empresas evitan el problema empleando estimadores de costos profesionales; estas no

son las mismas personas que harán el trabajo. ¿Recuerda la afirmación anterior acerca de
involucrar a los participantes del proyecto en la planificación del proyecto? Los trabajadores
experimentados suelen ser mejores para estimar el tiempo y los materiales que los costos.
Entonces los hacedores (aquellos que hacen el trabajo) deben definir el trabajo y estimar los
recursos y el tiempo necesarios, pero los profesionales deben estimar el costo. La gente a menudo
confunde la estimación con una meta; piensan que una estimación es lo que debería costar un
trabajo o lo que les han dicho que debería costar, no una predicción honesta de lo que costará .
Una estimación de costos nunca debe basarse en un objetivo u objetivo previamente establecido;
por lo tanto, los estimadores deben posicionarse organizacionalmente para que no se vean
4
obligados a proporcionar los números que alguien quiere.
Contrato de proyecto
el Capítulo 3 describe los méritos relativos de las diferentes formas de contratos; al menos dos de
estos, precio fijo y costo adicional, son relevantes para la escalada de costos del proyecto. Un
acuerdo de precio fijo incentiva al contratista a controlar los costos para mantener los costos
acumulados por debajo del precio contratado. Por el contrario, un contrato estrictamente de costo
incrementado ofrece pocos incentivos para controlar los costos. De hecho, cuando la ganancia se
calcula como un porcentaje de los costos (poco común en estos días), el contratista está motivado
para "permitir" que los costos aumenten y agregar todo tipo de tarifas. Otras formas de acuerdos,
como los contratos de incentivos, permiten aumentos de costos, pero fomentan el control de
costos y brindan motivación para minimizar la escalada.
Ver Capítulo 3
Información y suposiciones
La información y los supuestos a partir de los cuales se realizan las estimaciones siempre deben
cotejarse. ¿Son correctas las suposiciones del cliente y del contratista con respecto a los costos?
¿Todos están de acuerdo en el trabajo, los materiales y otros elementos a
estar cubierto en el presupuesto? ¿Están actualizadas las tasas de costos de mano de obra, materiales, equipos y
servicios? ¿Es precisa la información sobre las instalaciones, equipos, sistemas y servicios disponibles que debe
proporcionar el cliente u otras partes interesadas? Al igual que la declaración del alcance (y tal vez en referencia a ella),
la estimación de costos debe identificar explícitamente todos los elementos de costos utilizados para producir la
estimación.
Sesgo y ambición 5
Finalmente, es parte de la naturaleza humana que los campeones de proyectos sean optimistas sobre sus proyectos.
De hecho, sin campeones, la mayoría de los proyectos nunca comenzarían y todos podrían estar peor. Ese optimismo,
sin embargo, puede llevar a sobreestimar los beneficios y subestimar los costos. Los promotores de grandes proyectos
saben que si un proyecto es lo suficientemente importante, se materializará la financiación suficiente para completarlo,
sin importar el tamaño del sobrecosto.
Ejemplo 8.1: Ampliación del proyecto de enlace

marítimo de Bandra-Worli
Enero de 1999: el gobierno despeja el puente de cable Worli-Bandra
Febrero de 2001: el enlace marítimo Worli-Bandra entra en una etapa crucial

Octubre de 2002: el peaje del enlace marítimo de Bandra-Worli será más costoso
Octubre de 2003: el enlace marítimo Bandra-Worli puede llegar a un callejón sin salida
Enero de 2004—Proyecto de enlace marítimo de Bandra-Worli bajo amenaza
Julio de 2005—Sea Link en problemas por la extensión
Mayo de 2006: el enlace marítimo Bandra-Worli estará listo para 2008
Los titulares de los medios de comunicación locales se refieren a la carretera Bandra-Worli Sea Link (BWSL) y
al puente atirantado en Mumbai, el equivalente en la India al puente Golden Gate de San Francisco y un buen
ejemplo de los problemas de los megaproyectos. El puente de 8 km y sus accesos se doblan 200 metros hacia
el Mar Arábigo para conectar el centro de Mumbai con los suburbios del oeste. El puente redujo el tiempo de
viaje a la mitad, a unos 30 minutos.

El proyecto fue aprobado a principios de 1999 luego de 7 años de estudio; se suponía que comenzaría
en mayo, costaría 650 millones de rupias (US $ 120 millones) y terminaría a mediados de 2001.
Pero el trabajo no comenzó hasta diciembre, y la fecha estimada de finalización ya se había retrasado
hasta mediados de 2002. Luego llegaron los monzones, que casi paralizaron el proyecto en 2000 y
2001. A fines de 2001, el consultor principal del proyecto, Sverdrup, se retiró. por no proporcionar un
"ingeniero de proyecto competente". El reemplazo, Dar Consultants, modificó el diseño del puente y
agregó 2,8 km a su longitud y dividió el puente principal de ocho carriles en dos vías de cuatro carriles.
En enero de 2002, la fecha prevista de finalización se había desplazado a marzo de 2004. En octubre
llegó el anuncio de que los costos del proyecto habían aumentado en 50 millones de rupias; debido a
una “escasez de fondos”, el trabajo tuvo que retrasarse y la fecha de finalización se retrasó hasta
septiembre de 2004. Un año después, los monzones y el mar embravecido detuvieron nuevamente el
trabajo, lo que retrasó la fecha de finalización hasta 2005. Mientras tanto, aumentaron las quejas de los
pescadores preocupados por el la interferencia de link con sus barcos, y de ambientalistas sobre su
daño a la ecología marina. En 2003, las lluvias volvieron a paralizar el proyecto. El contratista principal
del proyecto, Hindustan Construction, solicitó 300 millones de rupias adicionales para cubrir los retrasos
y los cambios de diseño, pero el gobierno se negó y ofreció pagar solo 120 millones de rupias. La
controversia detuvo el proyecto por otro año, aunque finalmente se materializaron los fondos y se
reanudó el proyecto.
En junio de 2005, la fecha de finalización se restableció a septiembre de 2006 y el proyecto costó 1306
millones de rupias. En mayo de 2006, la fecha de finalización se retrasó nuevamente hasta abril de
2008, pero no fue hasta junio de 2009 que se dedicó el puente.
En marzo de 2010, todos los carriles se abrieron al tráfico. Costo estimado: 1600 millones de rupias (336 millones de dólares
estadounidenses).
Como se ilustra, los retrasos en el cronograma y la escalada de costos están inextricablemente conectados.
Los 11 años de historia del proyecto BWSL vieron un retraso en el cronograma de 9 años y un aumento de
costos del 150 por ciento. Los factores que contribuyeron incluyeron incógnitas (clima), cambios en el alcance
y los requisitos (diseño de puentes y carreteras), factores sociales (preocupaciones sobre los medios de
subsistencia y el impacto ambiental), económicos (aumento del valor e interés de la tierra) y administración
(despido de un contratista importante).
8.3 Estimación de costos y el ciclo de desarrollo de

sistemas 6
La estimación de costos del proyecto ocurre a lo largo de todas las fases del ciclo de vida del proyecto.
La primera estimación se realiza durante la concepción del proyecto. Dado que en ese momento se
dispone de muy poca información de costos directos, la estimación es la menos confiable que jamás haya
existido. La incertidumbre sobre el costo y la duración del proyecto puede ser grande, como lo ilustra la
“región de incertidumbre de tiempo-costo” más grande en la Figura 8.2. Cuánto costará realmente el proyecto
y cuánto tiempo realmente tomará son cuestiones muy abiertas. El proyecto se compara con otros proyectos
similares y se hace una estimación basada en los estándares de lo que debería tomar (tiempo de mano de
obra, materiales y equipo) para hacer el trabajo. Cuando no hay proyectos o estándares similares, las
estimaciones iniciales son en gran medida "estimaciones" y pueden terminar no estando cerca de los costos
reales.
Si el proyecto es único y está mal definido, la incertidumbre en las estimaciones de costos a menudo
dicta que los contratos sean del tipo costo más margen. A medida que se definen más aspectos del sistema
y del proyecto, los costos de materiales, los tiempos de mano de obra y las tasas de mano de obra se
pueden precisar y las estimaciones de costos se vuelven más confiables. Cuando el sistema y el proyecto
son bastante rutinarios, las estimaciones son algo más confiables y los contratistas están dispuestos a
aceptar contratos de tipo incentivo o de precio fijo. De hecho, la adjudicación de contratos a veces se
pospone hasta que los diseños están algo completos y es posible realizar estimaciones de costos más
precisas. Por supuesto, esto requiere que los contratistas realicen una gran cantidad de trabajo inicial sin
garantías de que se les adjudicará el trabajo.
Los contratistas obligados a ofertar antes de que puedan obtener estimaciones confiables deben incluir un
monto de contingencia en la estimación para cubrir la incertidumbre.
A medida que el proyecto avanza hacia las fases media y posterior, cuando se completa el trabajo y se
gastan los fondos, las estimaciones de costos se vuelven más seguras. Las regiones de incertidumbre de
costo-tiempo que se reducen en la figura 8.2 ilustran esto. A medida que disminuye la incertidumbre, se
reduce el monto del fondo de contingencia. Una contingencia que comienza en el 15 por ciento de la
estimación base del proyecto podría reducirse a la mitad del proyecto al 8 por ciento, luego al 3 por ciento
en la marca de los tres cuartos y luego al 1 por ciento en la instalación final para cubrir gastos menores.
correcciones al cierre.
Figura 8.2 Gráfico de costo-tiempo que muestra el costo acumulativo del proyecto y las regiones de incertidumbre del costo-tiempo.
Como se discutió en el Capítulo 4, por lo general, un plan detallado se desarrolla solo

para la próxima fase más inmediata del proyecto (plan por etapas o de onda continua), y
ese plan incluirá una estimación de costos y compromisos de costos para la fase. Al
mismo tiempo, se hace todo lo posible por mirar más allá de esa fase y desarrollar una
estimación de costos realista para todo el proyecto.
Ver Capítulo 4
Una vez desarrollada y aprobada, la estimación del proyecto se convierte en el

presupuesto y la línea de base contra la cual se medirá el progreso y el desempeño del
proyecto. Por lo tanto, es una mala práctica seguir cambiando la estimación durante el
proyecto porque eso destruye el propósito de una línea de base: medir el progreso y
controlar los costos. A veces, sin embargo, los factores de escalada hacen que la estimación de referen
obsoletos y exigir revisiones periódicas.

8.4 Proceso de estimación de costos
Estimación versus objetivo o meta
A veces, la palabra "estimar" se confunde con "objetivo" y "objetivo". no debería ser

Mientras que una estimación es un intento de evaluación realista basada en hechos
conocidos sobre el trabajo, los recursos necesarios, las limitaciones y el entorno, un
objetivo o meta es un resultado deseado . Salvo por casualidad, la estimación no será
la misma que el objetivo o la meta. Dicho esto, una vez calculada, la estimación se
puede comparar con un valor u objetivo objetivo, y las actividades de trabajo, los
recursos y los cronogramas se pueden revisar para acercar la estimación al objetivo.
La estimación nunca debe ser un simple complemento del valor objetivo.
Exactitud frente a precisión
La “precisión” representa la cercanía de un valor estimado con el valor real: la precisión

de una estimación de $99 000 para un proyecto que realmente costó $100 000 es muy
buena. Por el contrario, "precisión" es el número de lugares decimales en la estimación.
Una estimación de $75 321 es más precisa que una de $75 000 (aunque tampoco lo es
si el costo real es de $100 000). La exactitud importa más que la precisión: el objetivo
es obtener la estimación más precisa posible.
A veces, la precisión se puede mejorar empleando una estimación de tres puntos,
que combina estimaciones de costos optimistas (a), pesimistas (b) y más probables (m)
para llegar a una estimación de costos esperada, análoga al enfoque PERT para
calculando el tiempo esperado:
Clasificación de actividades de trabajo y costos

El proceso de estimación de costos comienza dividiendo el proyecto en fases de trabajo,

como diseño, desarrollo y fabricación, o en paquetes de trabajo de la EDT. El equipo del
proyecto, incluidos los miembros de las áreas funcionales involucradas y los contratistas, se
reúnen para discutir las fases o paquetes de trabajo y recibir asignaciones específicas.
El equipo busca tareas en el proyecto que sean similares a los diseños existentes y las
prácticas estándar y que puedan adoptarse fácilmente. El trabajo se clasifica como de
desarrollo o como una adaptación de diseños, técnicas o procedimientos existentes y listos
para usar (OTS). El trabajo de desarrollo implica incertidumbre en el diseño, las pruebas y
la fabricación, por lo que la estimación de costos es más difícil en comparación con la
estimación de elementos OTS o el trabajo duplicado, que es sencillo y utiliza precios
conocidos o registros de costos de materiales y mano de obra para sistemas o actividades
similares. Los sobrecostos por trabajo de desarrollo son comunes, especialmente debido a
estimaciones de mano de obra inexactas. Por lo tanto, a menudo es beneficioso hacer uso
de los diseños y la tecnología existentes tanto como sea posible.
Los costos estimados se clasifican en recurrentes y no recurrentes. Los costos recurrentes
ocurren más de una vez y están asociados con actividades que se repiten periódicamente,
como el control de calidad y las pruebas. Los costos no recurrentes ocurren una vez y están
asociados con el desarrollo, la fabricación y las pruebas de artículos únicos o la adquisición
de artículos especiales.
En una forma de organización de proyecto puro, el gerente del proyecto delega la
responsabilidad de estimar a otros, combina sus estimaciones y presenta las cifras finales a
la gerencia. En una organización matricial, la estimación es responsabilidad conjunta de los
gerentes de proyectos y funcionales; el director del proyecto coordina el esfuerzo y acumula
resultados.
Aunque esto tipifica el proceso de estimación, el enfoque real dependerá de la información
disponible y la precisión requerida de la estimación. La mayoría de las estimaciones se
realizan utilizando variantes de cuatro métodos: juicio de expertos, analogía, paramétrico e
ingeniería de costos.
Juicio experto
Un juicio de experto es una estimación proporcionada por un experto, alguien que a partir de
amplitud de experiencia o pericia es capaz de proporcionar una estimación aproximada. Es una

estimación de "asiento de los pantalones" que se utiliza cada vez que la falta de información impide
un análisis de costos más riguroso. La opinión de los expertos generalmente se restringe a las
estimaciones realizadas durante la fase de concepción y para proyectos que están mal definidos o
son únicos y para los cuales no hay proyectos anteriores similares para comparar.
Estimación análoga
Se desarrolla una estimación análoga revisando los costos de proyectos anteriores similares. A
menudo, una estimación de este tipo es útil como una verificación de la realidad relativamente
rápida para las estimaciones derivadas de una planificación detallada. El método se puede utilizar
a cualquier nivel: el costo total del proyecto se puede estimar a partir del costo de un proyecto
análogo; el costo del paquete de trabajo se puede estimar a partir de paquetes de trabajo análogos;
y el costo de la actividad se puede estimar a partir de actividades análogas. El costo de un proyecto
o paquete de trabajo similar se analiza y ajusta por las diferencias entre este y el proyecto o
paquete de trabajo propuesto en términos de escala, ubicaciones, fechas, etc. Si, por ejemplo, el
proyecto de analogía se realizó hace 2 años y el proyecto propuesto comenzará dentro de un año,
el costo del proyecto de analogía debe ajustarse para tener en cuenta la inflación y los cambios de
precios durante el período intermedio de 3 años. Si el proyecto de analogía estaba en California y
el proyecto propuesto estará en Nueva York, la estimación de costos debe tener en cuenta las
diferencias regionales en los costos de mano de obra y materiales. Si la escala (alcance, capacidad
o desempeño) de una actividad propuesta es el doble de la actividad de la analogía, entonces los
costos de la analogía deben "aumentarse". Pero el doble del tamaño no significa el doble del costo,
y la relación tamaño-costo debe determinarse de manera única.
Ejemplo 8.2: Estimación de los costos del proyecto escalando

un proyecto de analogía
Las denominadas industrias de proceso, como la petroquímica, la cervecería y la

farmacéutica, utilizan la siguiente fórmula para estimar los costos de los proyectos propuestos:
Costo (propuesto) = Costo (analogía)[Capacidad (propuesta)/Capacidad 0,75 donde

instalación análoga.
“propuesto”
En lasepráctica,
refiere aeluna
exponente
nueva instalación
varía de 0,35
y “analogía”
a 0,9, según
a una
el (analogía)]
tipo de proceso
y equipo utilizado. 7
Suponga que una planta propuesta debe tener una capacidad de 3,5 millones de cum
(metros cúbicos). Utilizando un proyecto de analogía para una planta con una capacidad de
2,5 millones de cum y un costo de $15 millones, el costo estimado de la planta propuesta es
15 millones de dólares [3,5/2,5] 0,75 = $15 millones [1,2515] = $18,7725 millones
Debido a que el método de analogía implica comparaciones con proyectos similares anteriores,
requiere información existente sobre proyectos anteriores. Las empresas que se toman en serio el
uso del método recopilan documentación de costos y la conservan en una base de datos que clasifica
los costos según el tipo de proyecto, paquete de trabajo, actividad, etc. Cuando se propone un nuevo
proyecto, se accede a la base de datos para obtener detalles de costos sobre proyectos y paquetes
de trabajo similares. Por supuesto, la suposición básica en el método de analogía es que la analogía
escogida es válida; a veces ahí es donde las cosas van mal.
Ejemplo 8.3: Un caso de analogía errónea y costosa 8
En las décadas de 1950 y 1960, cuando las plantas de energía nuclear aparecieron por
primera vez en los EE. UU., General Electric y Westinghouse, los dos contratistas principales,
juntos perdieron mil millones de dólares en menos de 10 años en contratos de precio fijo
porque habían subestimado los costos. Ninguno de los dos esperaba ganar dinero con estos
primeros proyectos, pero ciertamente tampoco habían planeado perder tanto. El error en su
método fue suponer que las plantas de energía nuclear son análogas a las plantas de carbón,
para las cuales los costos marginales en realidad se reducen a medida que las plantas crecen.
Pero las plantas de energía nuclear no son como las plantas de carbón.
Por un lado, requieren más salvaguardias. Cuando una tubería tiene una fuga en una planta
de carbón, el agua se corta y la planta se apaga hasta que se soluciona la fuga. En una planta
nuclear no se puede cerrar el agua ni apagar la planta; el reactor sigue generando calor y si
no se enfría se derrite,
hacer que las tuberías se rompan y la radiación se disperse. El sistema de refrigeración por
agua necesita un sistema de respaldo y el sistema de respaldo necesita un respaldo. Típico
de los sistemas complejos, los costos de las plantas nucleares aumentan exponencialmente
con el tamaño de la planta, pero en los primeros años de la energía nuclear nadie lo sabía.
Estimación paramétrica
Una estimación paramétrica se deriva de una relación matemática empírica.

El método se puede usar con un proyecto de analogía (caso en el Ejemplo 8.3) para escalar los
costos hacia arriba o hacia abajo, o se puede aplicar directamente sin un proyecto de analogía
cuando los costos son una función de los "parámetros" del sistema o del proyecto. Los parámetros
pueden ser características físicas como área, volumen, peso o capacidad, o características de
rendimiento como velocidad, tasa de producción, potencia o fuerza. El método es especialmente
útil cuando las primeras características de diseño se establecen por primera vez y se necesita una
estimación rápidamente.
Ejemplo 8.4: Estimación paramétrica de costos de materiales
Warren Warehousing Company, un contratista de instalaciones, necesita una estimación

rápida del costo del material de una nueva instalación. Los ingenieros de la empresa
investigan la relación entre varios parámetros de construcción y los costos de materiales
para ocho proyectos recientes comparables en términos de arquitectura, diseño y material
de construcción. Usando el método de mínimos cuadrados (un tema tratado en los libros de
texto sobre estadísticas matemáticas), desarrollan el siguiente modelo de regresión múltiple
que relaciona el costo del material (y) con el espacio de piso (x1, en términos de 10,000 pies
cuadrados) y el número de envíos. /muelles de recepción (x2) en un edificio:
y = 201 978 + (41 490)x1 + (17 230)x2
El método de mínimos cuadrados para este modelo indica que el error estándar de la
estimación es pequeño, lo que sugiere que el modelo proporciona estimaciones de costos
algo precisas en comparación con el costo real de cada uno de los
ocho proyectos.
Se está preparando una propuesta para construir una instalación de 300,000 pies cuadrados con
dos muelles. El costo de material estimado usando el modelo es por lo tanto:
y = 201 978 + (41 490)(30) + (17 230)(2) = $1 481 138.
Ingeniería de costos
Una estimación de ingeniería de costos se deriva de un análisis detallado de categorías de costos

individuales en el paquete de trabajo o nivel de actividad. Un enfoque de abajo hacia arriba, proporciona
las estimaciones más precisas de todos los métodos, pero también es el que consume más tiempo. El
método requiere información detallada de definición de trabajo que, a menudo, no está disponible al
principio del proyecto. Primero divide el proyecto en actividades o paquetes de trabajo (por ejemplo, de la
WBS), luego divide cada uno de estos en categorías de costos. Para proyectos pequeños como el Ejemplo
8.5 , el enfoque es simple y directo.
Ejemplo 8.5: Estimación de ingeniería de costos para un

proyecto pequeño
El gerente de proyecto del proyecto DMB está preparando una estimación de costos del proyecto.
Comienza dividiendo el proyecto en ocho paquetes de trabajo y creando un cronograma simple. Tres
grados de mano de obra estarán trabajando en el proyecto; para cada paquete de trabajo, estima el
número necesario de horas de trabajo por semana para cada grado. Las horas por semana por
grado laboral se representan dentro de los cuadros sombreados en la Figura 8.3.
Figura 8.3 Horario que muestra las horas asignadas a los paquetes de trabajo por grado laboral.
Para cada paquete de trabajo, también estima el costo de los materiales, equipos,
suministros, subcontratación, fletes, viajes y otros costos no laborales.
La Tabla 8.1 resume las horas laborales y los costos no laborales. La suma de los
costos no laborales es de $26,500.
Cuadro 8.1 Horas laborales y costos no laborales

Las tarifas por hora para los grados laborales 1, 2 y 3 son $10, $12 y $15, y la
las tasas de gastos generales son 90 por ciento, 100 por ciento y 120 por ciento, respectivamente (las
el monto de los gastos generales se agrega al costo de la mano de obra; determinar las tasas generales es
discutido después). Por lo tanto, los costos relacionados con la mano de obra son:
= $5,795
Grado 1: 305 ($ 10) (100% + 90%)
= $8,400
Grado 2: 350 ($ 12) (100% + 100%)
= $3,300
Grado 3: 100 ($ 15) (100% + 120%)
ps 17,495
La estimación preliminar de los costos laborales y no laborales es de $17 495 + $26 500 =
$43,995. Suponga que la compañía agrega rutinariamente 10 por ciento a todos los proyectos para
cubrir los gastos generales y administrativos; esto pone el costo en $ 43,995 (1.1)
= $48,395. Si el monto de contingencia también es del 10 por ciento, el costo total
el estimado para el proyecto DMB es $48,395(1.1) = $53,235.
En el paquete de trabajo o en un nivel inferior, a veces se derivan estimaciones detalladas

con la ayuda de manuales y tablas de normas. Los manuales de normas contienen tiempo
e información de costos sobre mano de obra y materiales para realizar tareas particulares. En
construcción, por ejemplo, el número de horas de mano de obra para instalar una instalación eléctrica
caja de conexiones o un pie cuadrado de sección de pared son estándares. Para determinar el
costo de mano de obra de instalar cajas de conexiones en un edificio, el estimador multiplica un
estimación del número requerido de cajas, multiplicado por el estándar de mano de obra por caja, y
luego lo multiplica por la tarifa de mano de obra por hora. Para el desarrollo de software la
el estándar de la industria es una persona al año para crear 2000 líneas de código libre de errores.
Para proyectos más grandes, el procedimiento de estimación es aproximadamente el mismo que se
ilustra en el Ejemplo 8.5 , aunque más complicado. Primero, el gerente de cada paquete de trabajo divide el
paquete de trabajo en áreas de trabajo "básicas" como "ingeniería" y "fabricación". Luego, los supervisores
de cada área básica estiman las horas y los materiales necesarios para realizar el trabajo. El supervisor de
ingeniería podría dividir aún más el trabajo en tareas de análisis estructural, análisis por computadora, planos
de diseño e instalación y manuales, y luego, para cada tarea, desarrollar una estimación de la duración y el
grado de trabajo o el nivel de habilidad involucrado. De manera similar, el supervisor de fabricación podría
subdividir el trabajo por materiales (acero, tuberías, cableado), hardware, maquinaria, equipo, seguro, etc.,
y luego estimar cuánto (cantidad, tamaño, longitud, peso, etc.) de cada uno. ser necesario. Las estimaciones
de tiempo y materiales se determinan por referencia a trabajos anteriores similares, manuales de estándares,
documentos de referencia y reglas generales ("una hora por cada línea de código"). Los supervisores envían
sus estimaciones al administrador del paquete de trabajo, quien las verifica, revisa y luego las envía al
administrador del proyecto.
El gerente del proyecto y los estimadores profesionales del personal del proyecto revisan los estimados
de tiempo y materiales presentados para asegurarse de que no se pase por alto o se duplique ningún costo,
todos entendieron lo que estaban estimando, estimaron correctamente 9 Se usaron los métodos y se tuvieron
cuenta los riesgos y incertidumbre. Luego, las estimaciones se agregan como se muestra en la Figuraen8.4 y
se convierten a dólares usando salarios estándar y costos de materiales (actuales o proyectados). Luego, el
director del proyecto agrega los gastos generales de todo el proyecto (para cubrir los costos administrativos
y de gestión del proyecto) y los gastos generales de toda la empresa (para cubrir los gastos generales de la
empresa) para llegar a una estimación de costos para el proyecto total. La acumulación de estimaciones de
paquetes de trabajo (flechas hacia arriba en la Figura 8.4) para derivar la estimación del proyecto se
denomina enfoque "de abajo hacia arriba".
Monto de contingencia
Los montos de contingencia se agregan a las estimaciones para compensar la incertidumbre. Como se
mencionó, cuanto más compleja o mal definida sea la situación, mayor será el monto requerido. Se pueden
desarrollar montos de contingencia para actividades o trabajos individuales.
paquetes, o el proyecto como un todo. La contingencia de la actividad es una cantidad estimada

para dar cuenta de "incógnitas conocidas" en una actividad o paquete de trabajo, es decir, fuentes
de aumentos de costos que podrían o probablemente ocurrirán; incluyen desechos y desechos,
cambios de diseño, aumentos en el alcance, el tamaño o la función del artículo final y retrasos
debido al clima. Posteriormente, cuando se establezca el presupuesto del proyecto, este monto
debe colocarse en un presupuesto especial, subdividido de acuerdo con los paquetes de trabajo
y estrictamente controlado por el gerente del proyecto. Cuando la suma de las contingencias de
la actividad se suma al costo total del proyecto, el resultado es la estimación base del costo del proyecto.
Figura 8.4 El proceso de estimación.
Los gerentes sénior, el gerente del programa o, a veces, el gerente del proyecto agregan otra
cantidad más a la estimación base, una contingencia del proyecto para dar cuenta de " incógnitas
desconocidas": factores externos que afectan los costos del proyecto pero que no se pueden
identificar. Los ejemplos incluyen fluctuaciones imprevistas en los tipos de cambio, escasez de
recursos y cambios en el mercado o la competencia. En proyectos más pequeños, el director del
proyecto controla el uso de la contingencia; en proyectos más grandes, lo hace el programa o la
alta dirección. Agregar la contingencia del proyecto a la estimación base da la estimación del
costo final. Este es el costo más probable para el proyecto.
Además de las contingencias de la actividad y del proyecto, la sociedad podrá destinar una provisión
para cubrir sobrecostos. Esta cantidad, la asignación por sobrecostos, se agrega al costo más probable
para obtener un costo donde, como regla, la probabilidad de excederlo es menor al 10 por ciento. La
asignación de excedentes está controlada por los gerentes corporativos o del programa y, por lo general,
no está disponible para el gerente del proyecto sin aprobación.
De arriba hacia abajo versus de abajo hacia arriba
En general, la estimación se puede hacer de dos maneras: de arriba hacia abajo y de abajo hacia arriba.
Top-down se refiere a estimar el costo mirando el proyecto como un todo. Una estimación de arriba
hacia abajo generalmente se basa en la opinión de un experto o en una analogía con otros proyectos
similares. De abajo hacia arriba se refiere a estimar el costo al observar los elementos del proyecto:
paquetes de trabajo individuales y componentes finales. Los costos de cada paquete de trabajo o
elemento final se estiman por separado y luego se suman para derivar el costo total del proyecto. El
ejemplo 8.5 es un enfoque de abajo hacia arriba; El ejemplo 8.2 es un enfoque de arriba hacia abajo.
Los enfoques se pueden usar en combinación: partes de un proyecto que están bien definidas se pueden
estimar de abajo hacia arriba; otras porciones menos definidas se pueden estimar de arriba hacia abajo.
El costo de cada paquete de trabajo también se puede estimar de cualquier manera: dividiendo el
paquete en pequeños elementos y estimando el costo de cada uno (de abajo hacia arriba) o haciendo
una estimación bruta a partir de la analogía o la opinión de un experto (de arriba hacia abajo). El método
de abajo hacia arriba proporciona mejores estimaciones que el método de arriba hacia abajo, pero
consume más tiempo y requiere más datos.
El uso de top-down o bottom-up se corresponde en cierta medida con el ciclo de vida del proyecto.
En la iniciación del proyecto, la estimación de costos puede consistir en no más que un número
"estadístico" de arriba hacia abajo para sugerir el orden de magnitud del costo del proyecto. La
estimación le da al cliente o contratista una idea aproximada del tamaño del costo, pero el método
implica poco esfuerzo y, en consecuencia, la estimación es de baja precisión; se le atribuye poca
confianza.
A medida que la propuesta se prepara en la fase de concepción, la estimación de costos a menudo

se basa en el método de arriba hacia abajo de observar proyectos anteriores pero análogos y compensar
las diferencias entre ellos y las lecciones aprendidas de ellos.
a ellos. La precisión de la estimación depende de la validez de las analogías y la capacidad de distinguir

diferencias y áreas de incertidumbre.
En la fase de definición (ya veces también en la concepción, dependiendo de cuándo se disponga de
datos confiables), la estimación de costos a menudo se prepara utilizando el enfoque de abajo hacia arriba.
Este método proporciona una estimación bastante precisa, así como las cifras de costos necesarias para
establecer el presupuesto del proyecto y las cuentas de control, que se analizan más adelante.
Conciliación de estimaciones
El director del proyecto presenta la estimación del costo final a la dirección de la empresa junto con las
previsiones que muestran los efectos de los posibles factores de escalamiento, como la inflación y los riesgos.
La gerencia compara la estimación con la estimación bruta, la meta u objetivo establecido por la gerencia o el
cliente, y la acepta o exige una revisión. Si la estimación bruta es mayor, el director del proyecto revisa las
estimaciones del paquete de trabajo en busca de posibles descuidos o exceso de optimismo. Si la estimación
final es mayor, el director del proyecto revisa las estimaciones del paquete de trabajo en busca de supuestos
incorrectos, relleno y otras fuentes de exceso
costo.
Reduciendo costos
¿Qué sucede si se debe reducir la estimación del costo final? Todos en el proyecto querrán retener su parte
del presupuesto y se resistirán a las reducciones de fondos o de personal. Especialmente los no gerentes
(ingenieros, científicos, analistas de sistemas), a menudo inconscientes de las limitaciones, se resistirán a los
recortes. A través de la diplomacia y la negociación, el director del proyecto intenta convencer a todos para
que busquen formas de reducir los costos. De lo contrario, debe convencerlos de que acepten las reducciones
impuestas .
Para reconciliar las diferencias entre las estimaciones brutas y finales, los gerentes a veces ejercen un
recorte general en todas las estimaciones. Esta es una mala práctica porque no tiene en cuenta los errores
de juicio o los costos excesivos por parte de unas pocas unidades. También penaliza injustamente a los
gerentes que trataron de producir
estimados y fueron lo suficientemente honestos como para no aumentarlos. Tales recortes

indiscriminados y generales inducen a todos a aumentar las estimaciones para su propia protección.
Suponga que usted es el director del proyecto y está claro que el presupuesto objetivo de la
alta dirección es simplemente demasiado pequeño para realizar el proyecto. Hay dos cursos de
acción: o emprender el proyecto e intentar de todo corazón cumplir con el presupuesto, o
entregárselo a otro gerente. Si decide lo primero, debe documentar e informar su desacuerdo a la
alta dirección; más tarde, se pueden encontrar formas de reducir los costos y completar el proyecto
dentro del presupuesto. Si el contrato es cost-plus, el riesgo es bajo ya que se reembolsarán los
costos adicionales. Si el contrato es de precio fijo y el presupuesto tiene tan poco financiamiento
que probablemente requiera tomar atajos o detener el proyecto, entonces debe sugerir que se
cancele el proyecto o que se nombre a otra persona como gerente del proyecto. No solo es una
buena práctica comercial, es lo ético que hay que hacer.
8.5 Elementos de Estimaciones y Presupuestos
Tanto los presupuestos como las estimaciones de costos establecen el costo de hacer algo. La diferencia es que la
estimación viene primero y es la base para el presupuesto. Es posible que una estimación deba refinarse muchas
veces, pero una vez aprobada, se convierte en el presupuesto y el monto por el cual la organización y las unidades
de trabajo se comprometen a realizar el trabajo. Es la cantidad acordada de lo que debería costar el trabajo y la
línea de base contra la cual se compararán los gastos reales. Los presupuestos de proyectos y los presupuestos
operativos fiscales son similares; la diferencia es que el primero cubre la vida de un proyecto, el segundo solo un
año a la vez.
Las estimaciones y los presupuestos comparten los siguientes elementos:
• Gasto laboral directo • Gasto
directo no laboral • Gastos generales
• Gastos generales y administrativos
• Utilidad y facturación total.
10
Gasto Laboral Directo
El gasto de mano de obra directa es el cargo de mano de obra para el proyecto. Para cada actividad o paquete de
trabajo se estima el número de personas necesarias en cada grado laboral, y el número de horas o días para cada
uno. Esto da la distribución de horas o días de trabajo requeridos por grado de trabajo. Las horas de trabajo para
los distintos grados se multiplican luego por sus respectivas tarifas salariales. El presupuesto del paquete de trabajo
en la Figura 8.5 muestra las tarifas salariales para tres grados de mano de obra y las horas de mano de obra
asociadas, escalonadas en el tiempo durante un período de 6 meses.
Cuando se espera que la tasa salarial cambie durante el transcurso del trabajo, se utiliza una tasa salarial
promedio ponderada. En la figura 8.5, suponga que se espera que la tarifa inicial de un asistente aumente de $20 a
$25 en los meses 3, 4 y 5. En lugar de $8 000, el costo de mano de obra de un asistente sería 100 ($20) + 100
($25) + 100 ($ 25)
+100 ($25) = $9,500. La tasa de salario promedio sería entonces $9,500/400 horas =
$23.75/hora.
Figura 8.5 Presupuesto típico de 6 meses para un paquete de trabajo.
Gasto Directo No Laboral
El gasto directo no laboral es el gasto total de los cargos no laborales aplicados directamente a la actividad.
Incluye subcontratistas, consultores, viajes, teléfono, tiempo de computadora, costos de materiales, piezas
compradas y fletes. Este gasto está representado en la Figura 8.5 por la línea “otro costo directo”. Los
costos de materiales incluyen asignaciones para desechos y deterioro y deben reflejar los aumentos de
precios anticipados.
Los costos de materiales y los cargos de flete a veces aparecen como elementos de línea separados
llamados materiales directos y gastos generales de materiales, respectivamente; El tiempo de computadora
y los consultores pueden aparecer como apoyo.
Los gastos directos no laborales también incluyen necesidades de instalación y operación, como
manuales de instrucciones y mantenimiento, documentación de ingeniería y programación, planos y
repuestos. Tenga en cuenta que estos son costos
incurridos sólo para un proyecto específico o paquete de trabajo. No se incluyen los costos generales o generales
de hacer negocios, a menos que esos costos estén vinculados únicamente al proyecto específico.
En proyectos más pequeños, los gastos directos no laborales se estiman individualmente para cada paquete
de trabajo. En proyectos más grandes, se aplica una tasa de porcentaje simple para cubrir los costos de viaje y
flete. Por ejemplo, el 5 por ciento del costo de mano de obra directa podría incluirse como gastos de viaje y el 5
por ciento de los costos de materiales como flete. Estos porcentajes se estiman de la misma manera que las
tasas de gastos generales, que se analizan a continuación.
Gastos generales, generales y administrativos
Los gastos directos de mano de obra y materiales se cargan fácilmente a un paquete de trabajo específico, pero
otros gastos no se pueden cargar tan fácilmente a paquetes de trabajo específicos o incluso a proyectos
específicos. Estos gastos, denominados gastos generales o gastos no directos, son los costos de hacer negocios.
Incluyen lo que sea necesario para albergar y apoyar la mano de obra, incluidos los alquileres de edificios, los
servicios públicos, la asistencia administrativa, los seguros y el equipo. Los gastos generales generalmente se
calculan como un porcentaje del costo de mano de obra directa. Con frecuencia, la tasa es del 100 por ciento,
pero varía desde un mínimo del 25 por ciento para las empresas que realizan la mayor parte de su trabajo en el
campo hasta más del 250 por ciento para aquellas con instalaciones, laboratorios y equipos costosos.
La tasa de gastos generales se calcula estimando los gastos generales anuales de la empresa y luego
dividiéndolos por el costo total de mano de obra directa proyectado para el año.
Suponga que se proyecta que los gastos generales totales para el próximo año sean de $180 000. Si los cargos
totales anticipados de mano de obra directa son de $150 000, entonces la tasa de gastos generales que se debe
aplicar es 180 000/150 000 = 1,20. Por lo tanto, por cada $1.00 que se carga a la mano de obra directa, $1.20 se
carga a los gastos generales.
Si bien este es el método de contabilidad tradicional para derivar la tasa de gastos generales, para los
proyectos da como resultado una asignación arbitraria de costos, lo que es contraproducente para el control de
costos del proyecto porque la mayoría de las fuentes de costos generales no están vinculadas a ningún proyecto
en particular. Más apropiado para los proyectos es dividir los gastos generales en dos categorías: gastos
generales directos para los costos que se pueden asignar de manera lógica; y gastos generales indirectos para
los costos que no pueden. Los costos generales directos se pueden atribuir al apoyo de un proyecto o paquete
de trabajo en particular; tal

los costos se asignan solo entre los proyectos o actividades específicos para los que se aplican.
Por ejemplo, el costo general de un departamento que trabaja en cuatro proyectos se reparte
entre los cuatro proyectos en función del porcentaje de tiempo de trabajo que dedica a cada uno.
Los gastos generales del departamento no se asignan a proyectos en los que no está trabajando.
El otro tipo de gastos generales, indirectos, incluye los gastos generales de la corporación.
Normalmente denominados gastos generales y administrativos , o G&A, incluyen impuestos,
financiamiento, costos de multas y garantías, respaldo contable y legal, gastos de propuestas,
mercadeo y promoción, salarios y gastos de la alta gerencia y beneficios para los empleados. Es
posible que estos costos no estén vinculados a ningún proyecto específico, por lo que se asignan
a todos los proyectos, a ciertos proyectos o a partes de ciertos proyectos. Por ejemplo, los gastos
generales a nivel corporativo se asignarían a todos los proyectos, los gastos generales de gestión
de proyectos por proyecto y los gastos generales departamentales a segmentos de proyectos
específicos a los que contribuye un departamento. A menudo, los gastos generales de G&A se
cobran por tiempo, por lo que cuanto mayor sea la duración del proyecto, mayor será el gasto de
G&A para el proyecto.
La manera real en que se distribuyen los costos indirectos varía en la práctica.
El ejemplo de SETI Company en la Tabla 8.2 muestra tres métodos para distribuir los costos
Darsesiguen
cuenta de 11
indirectos entre dos proyectos, MARS y PLUTO. aunque los gastos de toda la empresa
siendo los mismos, el costo de cada proyecto difiere según el método de asignación de costos
indirectos.
Los clientes quieren saber el método de asignación utilizado por sus contratistas y los
contratistas deben conocer el método de asignación utilizado por los subcontratistas. Por
ejemplo, el Método I de la Tabla 8.2 es bueno para el cliente cuando el proyecto es intensivo en
mano de obra directa (DL), pero malo cuando es intensivo en mano de obra directa (DNL). El
Método III es lo contrario y da un costo más bajo cuando el proyecto es relativamente poco
intensivo en mano de obra (es decir, los costos de mano de obra son bajos pero los costos de
materiales y partes son altos). Esto se puede ver comparando MARTE (algo no intensivo en
mano de obra) con PLUTÓN (algo intensivo en mano de obra).
Cuadro 8.2 Ejemplos de prorrateo de costos indirectos
Empresa SETI: toda la empresa (costos indirectos)

Gastos generales (alquiler, servicios públicos, administrativos, maquinaria) OH 120
General (alta dirección, personal, beneficios, etc.) GEORGIA 40

Indirectos Totales 160
Costos del proyecto Proyecto MARS Proyecto PLUTÓN Total
Mano de obra directa (DL) 50 100 150
Directo no laboral (DNL) 40 10 50
90 110 200
Directo Total 200
Directos e Indirectos Totales 360
Algunos métodos para prorratear los costos indirectos:
1. Costos indirectos totales proporcionales a los costos directos totales
Proyecto MARS Proyecto PLUTÓN Total
DL y DNL 90 110 200
OH y G&A 72 88 160
162 198 360
II. OH proporcional a la mano de obra directa únicamente; G&A proporcional a todos los costos directos
MARTE PLUTÓN Total
DL 50 100 150
OH en DL 40 80 120
DNL 40 10 50
G&A en (DL y DNL) 18 22 40
148 212 360
tercero OH proporcional a la mano de obra directa únicamente; G&A proporcional a DL y OH y

DNL
MARTE PLUTÓN Total
DLand OH y DNL 130 190 320
GEORGIA 16.25 23.75 40
146.25 213.75 360
Los gastos generales aparecen en los proyectos de diferentes maneras. Cualquier gasto general
que se pueden rastrear a paquetes de trabajo específicos deben asignarse a ellos directamente.
Estos aparecen en el presupuesto, como se muestra en la Figura 8.5. Gastos generales restantes
que no se pueden rastrear a paquetes de trabajo específicos se asignan a un especial
paquete de trabajo "gastos generales". Esto puede ser un solo paquete de trabajo general para el
proyecto completo, o una serie de paquetes, cada uno vinculado a una etapa o fase individual del
proyecto.
Beneficio y Facturación Total
La ganancia es la cantidad que queda después de que se han restado los gastos del precio
contractual. También puede ser una tarifa fija acordada o un porcentaje de los gastos totales,
determinado, en parte, por el tipo de contrato, como se explica en el Apéndice del Capítulo 3. La
facturación total es la suma de los gastos totales y las ganancias. La facturación total y las ganancias
se incluyen en las estimaciones del proyecto general, grupos de paquetes de trabajo y trabajo
subcontratado. Por lo general, no aparecen en los presupuestos de los elementos de trabajo de
nivel inferior.
Ver Capítulo 3
8.6 Sistemas de contabilidad de costos del proyecto
Un proyecto puede constar de cientos o miles de elementos: trabajadores, materiales e instalaciones,

todos los cuales deben estimarse, presupuestarse y controlarse.
Para acelerar el proceso, reducir la confusión y mejorar la precisión, necesita un sistema que le
ayude a calcular estimaciones, crear, almacenar y procesar presupuestos y realizar un seguimiento
de los costos. Dicho sistema, llamado sistema de contabilidad de costos del proyecto (PCAS), lo
establece inicialmente el director del proyecto, el contador del proyecto o la oficina de gestión del
proyecto (PMO). Si bien el enfoque principal del PCAS está en los costos del proyecto, el sistema
también ayuda a rastrear y controlar los cronogramas y el progreso del trabajo. Cuando el PCAS se
combina con otras funciones de planificación, control y presentación de informes de proyectos, todo
el sistema se denomina sistema de información de gestión de proyectos (PMIS).
El PCAS se utiliza durante todo el ciclo de vida del proyecto. Durante la concepción y definición
del proyecto, acumula estimaciones de costos del paquete de trabajo para producir la estimación de
costos del proyecto. Esta estimación luego se convierte en la base sobre la cual se crean los
presupuestos del proyecto y del paquete de trabajo.
Durante la ejecución del proyecto, el PCAS acumula, acredita e informa los gastos del proyecto y
del paquete de trabajo. Crea presupuestos con fases de tiempo (por ejemplo, la Figura 8.5), que
ayudan a los gerentes a controlar los costos y verificar que el trabajo se haya completado y cobrado.
El sistema también permite revisiones presupuestarias. Las funciones del PCAS se resumen en la
Figura 8.6.
Figura 8.6 Elementos de un sistema de contabilidad de costos de un proyecto.
Ejemplo 8.6: Un Pmis para estimar los

12
requisitos y costos de mano de obra
Sigma Associates es una gran firma de arquitectura/ingeniería que desarrolló su propio

PMIS para ayudar en la estimación, planificación y programación.
En Sigma, el gerente de proyectos comienza cada proyecto potencial creando una
WBS para identificar los principales paquetes de trabajo. Usando un menú en el PMIS,
revisa el historial de paquetes de trabajo similares de proyectos anteriores y el tipo y
la cantidad de mano de obra que requirieron. Al ingresar factores relacionados con el
tamaño del proyecto, los costos de construcción y el tipo de cliente, puede estimar los
requisitos de mano de obra para cada actividad del proyecto. Usando el PMIS, el
gerente de proyecto combina estas estimaciones de mano de obra con los requisitos
de los proyectos existentes para producir un pronóstico de carga de recursos de mano
de obra; esto le permite determinar si hay suficiente mano de obra disponible. Si no es
así, el director del proyecto utiliza el sistema para revisar opciones como modificar el
cronograma, usar horas extra o nivelar los recursos (discutido en el Capítulo 6).
Ver Capítulo 6
La estimación de los requerimientos de mano de obra se entrega al contralor quien, a través del
PMIS, aplica las tarifas horarias existentes o proyectadas a cada actividad. Luego, el contralor
agrega los beneficios de los empleados y los gastos generales de mano de obra para producir una
estimación del costo de mano de obra directa.
Con la información del libro mayor de la empresa, el contralor calcula la tasa de gastos
generales, que utiliza para cobrar al proyecto su parte de los gastos de toda la empresa. Luego usa
el PMIS para resumir todos los gastos estimados y crear un presupuesto estimado del proyecto.
Por último, el contralor analiza el presupuesto estimado junto con el plan de rentabilidad del
proyecto. Si el presupuesto y el plan muestran una utilidad razonable y el contralor y el gerente del
proyecto están de acuerdo con el presupuesto, se acepta el proyecto. Si no, se busca un plan
diferente que mantenga los mismos altos estándares de calidad pero que sea más rentable.
Presupuestos por etapas
El gerente de proyecto necesita una forma de rastrear y controlar dónde se acumulan los gastos, qué tan
bien está progresando el proyecto y dónde se están desarrollando los problemas. Una forma es con un
presupuesto con fases temporales, un método que consolida el presupuesto del proyecto y el cronograma
del proyecto para mostrar la distribución de los costos presupuestados de acuerdo con el cronograma del
proyecto. La Figura 8.5 es un ejemplo; muestra la distribución de costos en un paquete de trabajo durante
los meses 1 a 6. El PCAS genera informes como este para cada paquete de trabajo, lo que permite que
el gerente del proyecto compare los costos presupuestados y los gastos reales mes a mes durante la
duración del proyecto.
Para los proyectos en los que una cantidad sustancial de los costos se originan en artículos o servicios
adquiridos , se prepara un presupuesto especial con fases de tiempo para los bienes, el trabajo y los
servicios adquiridos. En proyectos grandes, este presupuesto está controlado por un gerente de materiales
o compras.
8.7 Presupuestación usando cuentas de control (o de costos)
La presupuestación y el seguimiento de costes en proyectos pequeños se pueden realizar utilizando

un único presupuesto para el proyecto en su conjunto. Este presupuesto, quizás similar al de la Figura
8.5, se usa para comparar los costos reales con los costos presupuestados a lo largo del proyecto.
Sin embargo, en proyectos más grandes, un presupuesto único para todo el proyecto es demasiado
insensible; una vez que el proyecto está en marcha y se acumulan los gastos, sería difícil localizar
rápidamente las fuentes de los sobrecostos. La mejor forma es subdividir el presupuesto del proyecto
en presupuestos más pequeños denominados cuentas de control o cuentas de costos, cada uno de
los cuales representa un paquete de trabajo en la EDT. Los grandes proyectos tienen decenas de
cuentas de control; proyectos muy grandes tienen cientos.
La cuenta de control es el elemento básico de seguimiento del proyecto en el PCAS. Las cuentas
se configuran en una jerarquía, similar o idéntica a la EDT. La cuenta de nivel más bajo suele
corresponder a un paquete de trabajo, aunque cuando el número de paquetes de trabajo es muy
grande, una cuenta puede representar varios paquetes de trabajo combinados. Al igual que los
paquetes de trabajo, cada cuenta puede incluir:
• Una descripción del

trabajo • Un cronograma
• Quién es responsable •
Material, mano de obra y equipo requerido • Un
presupuesto con fases de tiempo.
También se establecen cuentas de control para los costos del proyecto que no se pueden atribuir
fácilmente a ningún paquete de trabajo específico. Por ejemplo, para el dinero asignado a artículos,
materiales o equipos que pueden ser utilizados por cualquier persona o cualquier paquete de trabajo,
o para trabajos como administración, supervisión o inspección que se aplican a todo el proyecto, se
establecen cuentas de control separadas. Estas cuentas generalmente se establecen para la duración
del proyecto o se extienden período por período según sea necesario o se asignen fondos.
Figura 8.7 Integración de la WBS y la estructura de la organización que muestra las cuentas de control. (Vea las Figuras 8.8 a 8.12
para más detalles.)
Con un PCAS y una estructura de cuenta de control, es fácil monitorear el desempeño

de costos para cada paquete de trabajo, grupo de paquetes de trabajo y el proyecto en su
totalidad. Como ejemplo, considere el proyecto Autopresupuestación de Robótica
(ROSEBUD) descrito en el Capítulo 6. La Figura 8.7 muestra la WBS para el proyecto y el
Ver Capítulo 6
organigrama del contratista, KANE & Associates. Los cuadros sombreados representan
ubicaciones de cuentas de control; observe que cada uno representa todo o parte de un
paquete de trabajo del cual es responsable un área funcional. Para el mismo proyecto,
Las figuras 8.8 y 8.9 muestran, respectivamente, las porciones presupuestarias desfasadas en el
tiempo de las cuentas de control para las contribuciones del departamento de programación a los
paquetes de trabajo L y W.
La WBS para ROSEBUD consta de nueve paquetes de trabajo realizados por cuatro
departamentos funcionales, más un paquete de trabajo adicional para la gestión de proyectos.
Durante la fase de estimación, cada departamento presenta una estimación de costos para los
paquetes de trabajo en su parte del proyecto. Tras la aprobación, con adiciones para gastos
generales y G&A, la estimación de cada departamento se convierte en un presupuesto.
En la Figura 8.7, los diez recuadros sombreados representan departamentos/paquetes de trabajo
para los cuales se realizaron estimaciones de costos iniciales y, posteriormente, se establecieron
presupuestos y cuentas de control.
8.8 Resúmenes de costos 13
Con la estructura de cuentas de control que se muestra en la figura 8.7, se pueden

desarrollar cuentas de resumen de alto nivel mediante la consolidación de cuentas de control
para la WBS y las jerarquías organizacionales. Tal consolidación es útil para monitorear el
desempeño de departamentos y segmentos individuales del proyecto. Por ejemplo, la
consolidación de cuentas en la Figura 8.7 de forma horizontal da como resultado una cuenta
de control para cada departamento funcional. La Figura 8.10 muestra esto con el presupuesto
por etapas para el departamento de programación, que suma los presupuestos para los
paquetes de trabajo L y W (Figuras 8.8 y 8.9).
Las cuentas de control también se pueden consolidar verticalmente a través de la EDT.
Esto sería útil para rastrear y controlar paquetes de trabajo individuales, grupos de paquetes
de trabajo o el proyecto como un todo. La Figura 8.12 es el presupuesto por etapas para las
pruebas finales, que es la suma de los presupuestos para los paquetes de trabajo W (Figura
8.9) y X (Figura 8.11).
Figura 8.8 Presupuesto del departamento de programación para el Paquete de trabajo L.
Figura 8.9 Presupuesto del departamento de programación para el paquete de trabajo W.

Figura 8.10 Presupuesto del departamento de programación.

Figura 8.11 Presupuesto para el Paquete de Trabajo X.
Figura 8.12 Resumen de presupuesto para pruebas finales.

Figura 8.13 Agregación de la información de la cuenta de control por proyecto y organización.
El PCAS y la estructura de la cuenta de control permiten resumir los costos de varias

maneras: la Figura 8.13 muestra los montos presupuestados agregados vertical y
horizontalmente, y la Tabla 8.3 muestra los tipos de costos presupuestados resumidos para
los cinco departamentos y nueve paquetes de trabajo en el proyecto ROSEBUD. Por lo
tanto, a través del PCAS y la estructura de cuentas, es fácil identificar las desviaciones de
costos del presupuesto a nivel de proyecto o de empresa, y rastrear fácilmente tales
desviaciones hasta los paquetes de trabajo y los departamentos que las causaron. El capítulo 11 describir
Ver Capítulo 11
8.9 Listas de costos y pronósticos 14
Durante la planificación del proyecto surgen preguntas sobre cómo varían los gastos a lo largo
del proyecto, qué períodos tienen los mayores requisitos de efectivo y cómo se comparan los
gastos con los ingresos. Para responder a estas y otras preguntas similares, es útil anticipar
el “patrón de gastos” estimado como se deriva de las estimaciones de costos del paquete de
trabajo y el cronograma del proyecto. Los siguientes son ejemplos.
Cuadro 8.3 Resumen de costos del proyecto ROSEBUD
Análisis de costos con tiempos de inicio temprano y tardío
Una suposición simplificadora utilizada en la estimación de costos es que los costos en cada
paquete de trabajo se distribuyen uniformemente. Por ejemplo, se supone que un paquete de
trabajo de $22 000 de 2 semanas tiene gastos de $11 000 por semana. Con esta suposición,
es fácil crear un programa de costos que muestre el costo de cada semana de todo el proyecto.
Como ejemplo, mire la Figura 8.14: la red basada en tiempo para el proyecto LOGON que
usa tiempos de inicio anticipados. Luego mire la Tabla 8.4, que enumera los paquetes de
trabajo para LOGON y la información de tiempo y costo asociada. El costo directo semanal de
cada actividad es el costo total dividido por el tiempo; por ejemplo, para la Actividad H, es
$100K/10 semanas = $10K/semana. Usando la red basada en el tiempo, el costo del proyecto
cada semana se puede calcular sumando los costos de todas las actividades programadas en
la semana. El procedimiento es el mismo que se describe en el Capítulo 6
para determinar la carga de recursos. De acuerdo con la Figura 8.14, durante las primeras 10 semanas solo se
programa la Actividad H, por lo que el costo semanal del proyecto se mantiene en $10K.
Durante las próximas 6 semanas se programan las actividades I y J, por lo que el costo semanal es su suma,
$16K + $8K = $24K. Más adelante, en las semanas 17 y 18, se programan cuatro paquetes de trabajo: I, K, L y
J, por lo que el costo semanal es su suma, $8K + $4K + $18K + $21K = $51K. Estos costos semanales, que se
muestran en la tercera columna de la Tabla 8.5, representan el cronograma de costos del proyecto. La cuarta
columna, gasto acumulativo, representa el costo total previsto del proyecto para una semana determinada. Estos
costos se grafican en la Figura 8.15.
Ver Capítulo 6
Usando el mismo procedimiento, los cronogramas y pronósticos de costos del proyecto se pueden preparar
en función de los tiempos de inicio tardíos . La Figura 8.16 es la red basada en el tiempo para el INICIO DE
SESIÓN que utiliza tiempos de inicio tardíos. Las últimas dos columnas de la Tabla 8.5 son los costos acumulados
y semanales de inicio tardío.
Dadas las cifras de costos iniciales y finales en la Tabla 8.5 , es posible analizar los efectos del retraso de las
actividades en los costos del proyecto. Al comparar los costos semanales de las primeras horas de inicio con los
de las últimas horas de inicio en la figura 8.17, la influencia de los cambios de cronograma en los costos del
proyecto es evidente. La región sombreada en la figura superior, la región presupuestaria factible, que se basa
en los gastos acumulados tempranos y tardíos, muestra el rango de presupuestos permisibles por cambios en el
cronograma del proyecto. La parte inferior de la figura muestra el impacto en los costos semanales por el retraso
de las actividades.
Figura 8.14 Red basada en tiempo para el proyecto LOGON usando tiempos de inicio anticipados.
Cuadro 8.4 Actividades, tiempo, costo y requisitos de mano de obra (resultado del análisis de desglose del trabajo)
Tiempo Coste total directo semanal Requisitos laborales semanales

Actividad
(Semanas) ($K) Costo ($K) (Trabajadores)
H 10 100 10 5
1 8 64 8 4
j 6 96 dieciséis 8
k 4 dieciséis 4 2
L 2 36 18 6
METRO 4 84 21 3
norte 4 80 20 CM
0 5 50 10 5
PAGS 5 60 12 6
q 5 80 dieciséis CM
R 5 0 0 0
S 3 0 0 0
T 3 0 0 0
tu 1 14 14 9
V 5 80 dieciséis 14
w 2 24 12 6
X 3 36 12 6
Y 8 104 13 14
Z 6 66 11 5
Costo Directo Total-

$ 990K
Tabla 8.5 Gastos semanales del proyecto LOGON usando tiempos de inicio temprano ($1,000)
Cuando las restricciones de financiamiento restringen los gastos del proyecto, los programas
de costos revelan los lugares donde se debe cambiar el programa. Por ejemplo, la figura 8.17
muestra un gasto semanal máximo de $82 000 en las semanas 18 y 19. Si se impusiera un
tope presupuestario semanal de $60 000 por semana al proyecto, entonces se preferirían los
tiempos de inicio tardíos porque darían como resultado un nivel más alto. perfil de costos y
gastos máximos de solo $54,000. El método para nivelar los recursos discutido en el Capítulo
6 es aplicable para nivelar los costos del proyecto; los costos se tratan como un recurso más.
Ver Capítulo 6
Figura 8.15 Gastos semanales planificados y gastos acumulados del proyecto LOGON.
Figura 8.16 Red basada en el tiempo para el proyecto LOGON que utiliza horas de inicio tardías.
Figura 8.17 Comparación de gastos, inicio temprano versus inicio tardío.
Efecto del tiempo de inicio tardío en el patrimonio neto del proyecto
Debido al valor del dinero en el tiempo, el valor actual neto del trabajo realizado más adelante
en el futuro es menor que el mismo trabajo realizado antes. Por lo tanto, retrasar el trabajo en
un proyecto largo puede generar ahorros sustanciales en el valor presente de los costos del
proyecto. Por ejemplo, suponga que la duración del INICIO DE SESIÓN es de 47 meses (en
lugar de las 47 semanas que se usaban hasta ahora). Si la tasa de interés anual es del 24 por
ciento, compuesta al 2 por ciento mensual, el valor presente del proyecto sería de $649 276.
Esto se calcula utilizando los gastos mensuales de la tabla 8.5 (nuevamente, suponiendo que
las semanas que se muestran son meses) y descontándolos hasta el tiempo cero. Ahora, cuando
en su lugar, se utilizan las horas de inicio tardías, el valor actual es de solo $605 915, un ahorro
de $43 361.
¿Significa esto que las actividades deben retrasarse hasta su fecha de inicio tardía? No
necesariamente. Recuerde, retrasar las actividades consume tiempo de inactividad y deja
menos tiempo para tratar los problemas que podrían retrasar el proyecto. Por lo tanto,
retrasar o no el trabajo también debería depender de la certeza del trabajo. Las actividades
que probablemente no tendrán problemas pueden iniciarse más tarde para aprovechar el
valor del dinero en el tiempo. Las actividades que son menos familiares, como el trabajo
de investigación y desarrollo, deben comenzar antes para mantener la holgura que podría
ser necesaria para absorber retrasos imprevistos. Esto supone el método de la ruta crítica;
CCPM utiliza búferes de recursos, que excluyen la necesidad de holgura. Además, si
retrasar o no el trabajo debe depender del cronograma de pagos del cliente. Si los pagos
están vinculados a los hitos del proyecto, entonces el trabajo vinculado a esos hitos no debe retrasarse.
En el Capítulo
6.
Ver Capítulo 6
Flujo de efectivo
Un problema al que se enfrenta a menudo el director del proyecto es mantener un flujo de

caja positivo, es decir, asegurarse de que las entradas de caja acumuladas (pagos recibidos)
superen las salidas de caja acumuladas (pagos realizados). Idealmente, las diferencias
entre el ingreso y el retiro de efectivo a lo largo del proyecto serán pequeñas. 15 El director
del proyecto debe hacer malabarismos, equilibrando los ingresos del cliente (normalmente
pagos por hitos) u otras fuentes de financiación con los pagos de gastos de mano de obra,
subcontratistas, materiales y equipos. Para ayudar a mantener este equilibrio, el gerente
puede, por ejemplo, aprovechar el tiempo que transcurre entre la adquisición de materiales
y equipos y el momento en que se requieren los pagos correspondientes.
La figura 8.18 muestra un ejemplo de flujo de efectivo pronosticado. Todas las fuentes
de ingresos acordadas contractualmente durante la vida del proyecto se comparan con
todos los gastos previsibles, directos e indirectos, así como con los costos de penalización
o los pagos programados, en caso de que el proyecto se complete tarde. El déficit entre
los ingresos previstos y los gastos estimados representan la cantidad de capital de trabajo
necesario para cumplir con los pagos de los gastos. Con base en este pronóstico, se debe
crear un plan de financiamiento para garantizar que haya suficiente capital de trabajo
disponible durante todo el proyecto.
Como se mencionó, los pagos de los clientes a veces se realizan en hitos vinculados a la
finalización de los entregables o las fases del proyecto. Dichos pagos ayudan al contratista
a cubrir sus costos. Sin embargo, el inconveniente es que, si el proyecto encuentra serios
problemas, un contratista sin escrúpulos, que ya ha recibido varios pagos, puede
simplemente abandonar el trabajo y dejar al cliente en un aprieto.
Una forma en que el cliente puede mantener la "retención" del contratista es retener una
parte significativa del pago acordado, llamado retención de dinero, hasta que todo el trabajo
se complete satisfactoriamente. Otra forma es retener una parte del pago final, denominada
garantía de ejecución, durante un período posterior a la entrega del artículo final hasta que
se hayan rectificado todos los defectos descubiertos por el cliente.
Figura 8.18 Equilibrio de ingresos y gastos del proyecto.

8.10 Costos del ciclo de vida
Los costos del ciclo de vida (LCC) representan todos los costos de un sistema, instalación o
producto a lo largo de su vida, de la cuna a la tumba. El concepto se originó en adquisiciones
militares cuando los gerentes se dieron cuenta de que los costos para desarrollar un sistema
representan solo la punta del iceberg de costos y que los costos de operación (p. ej., consumo
de combustible) y mantenimiento (p. ej., reemplazo de piezas) suelen ser mucho mayores.
Mientras que el énfasis en este capítulo está en los costos del proyecto, es decir, los costos
incurridos durante las fases de definición y ejecución del proyecto , LCC incluye costos para el
resto del ciclo de vida del sistema: la fase de operación, la disposición final del artículo final y, a
veces, la fase de concepción también (iniciación y viabilidad).
Es necesario anticipar el LCC porque los costos influyen en muchas decisiones. Por ejemplo,
suponga que tres contratistas presentan propuestas para construir una planta, y cada propuesta
contiene no solo el costo de construcción de la planta sino también los costos operativos
esperados. Si las ofertas son similares en términos de costos de construcción y características
de la planta, es probable que gane la que tenga los costos operativos más bajos.
Los LCC afectan de manera similar las decisiones relacionadas con los proyectos de
desarrollo, y el análisis económico en los estudios de factibilidad (Capítulo 3) debe considerar
todos los costos de adquisición, operación, mantenimiento y disposición del sistema a desarrollar.
Por ejemplo, la mayoría de los fabricantes aeroespaciales de EE. UU. en la década de 1970
dudaban en desarrollar un avión comercial supersónico debido a preocupaciones sobre el costo
y el impacto ambiental. Se proyectó que los costos para desarrollar y producir la aeronave
serían altos, al igual que los costos de operación y mantenimiento. La cuestión era si suficientes
personas pagarían los altos precios de los boletos necesarios para que las aerolíneas obtuvieran
ganancias y si suficientes aerolíneas comprarían aviones para que los fabricantes ganaran
dinero. En última instancia, muchos sintieron que la respuesta era no en ambos aspectos. El
Congreso de los Estados Unidos canceló los subsidios para desarrollar el avión y el programa
se disolvió. Mientras tanto, los europeos decidieron lo contrario y pasaron a fabricar el Concorde,
del cual solo 14 entraron en servicio. Concorde voló durante casi 27 años y el último se retiró
en 2003. El LCC nunca se recuperó; si los gobiernos de Gran Bretaña y Francia no hubieran
proporcionado subsidios, las aerolíneas y los fabricantes habrían perdido dinero.
Ver Capítulo 3
Las decisiones clave de diseño que afectan la operación y el mantenimiento de un sistema

se toman al principio del ciclo de vida del proyecto, en la concepción y definición. Un producto
con un costo de desarrollo y un precio de compra altos se vuelve más atractivo si se puede
diseñar para que tenga un costo operativo relativamente bajo. Por ejemplo, un vehículo más
eficiente en combustible puede tener un precio más alto que los vehículos menos eficientes,
pero los clientes pagan fácilmente la prima sabiendo que durante la vida útil del vehículo la
recuperarán mediante el ahorro de combustible y una menor contaminación. Por supuesto,
estimar LCC implica hacer suposiciones sobre tecnología, mercado y demanda de productos,
y se basa en costos históricos de sistemas y proyectos similares; aun así, es una forma
sensata de evaluar proyectos, especialmente cuando hay que elegir entre diseños o
propuestas alternativas.
El LCC también debe tener en cuenta el tiempo necesario para desarrollar, construir e
instalar el artículo final, es decir, el tiempo antes de que la instalación o el sistema entre en
funcionamiento o el producto se "lance" al mercado. El tiempo es importante: determina qué
tan pronto el artículo final comenzará a generar ingresos, ganar participación de mercado y
acumular ganancias u otros beneficios. Los costos más altos de acelerar el proyecto se
comparan con los beneficios obtenidos de una finalización anticipada o el lanzamiento del
producto. De igual manera, también se estima el costo de disposición al final del ciclo de
vida; para instalaciones como minas y plantas de energía nuclear que requieren cierre y
rehabilitación después de su vida útil, este costo puede ser sustancial.
El análisis de LCC también es necesario para establecer objetivos de desarrollo y costos
operativos y tomar decisiones de compensación de diseño para lograr esos objetivos.
El siguiente es un ejemplo:
Ejemplo 8.7: Costos del ciclo de vida de una flota

operativa de naves espaciales
Esta ilustración amplía los ejemplos anteriores de SpaceShip One, pero los números
son puramente hipotéticos. Habiendo adquirido la experiencia de SpaceShipOne, se
diseñarán una nave espacial y una nave nodriza más grandes. La nueva nave espacial
llevará un piloto más cuatro pasajeros de pago, llegará tan alto como
120 km, y ser capaz de realizar 20 vuelos por año durante una vida operativa de 5 años.
El costo de desarrollar y producir cuatro de estas naves espaciales y dos naves nodrizas
se estima en $80 millones. Mientras tanto, una encuesta indica que la cantidad de
personas en todo el mundo dispuestas a pagar el precio del boleto de $ 190,000 para
volar en estas naves espaciales es de al menos 1,000 por año.
Se está creando una "línea espacial" que usará y mantendrá las naves espaciales
por un costo inicial de $ 10 millones. Los costos operativos de la línea espacial constan
de dos partes: los costos anuales de las operaciones terrestres (reservas, personal,
instalaciones terrestres, etc.)—$2 millones/año; y costos por vuelo para operaciones de
vuelo (combustible, repuestos, reparaciones, etc., para la nave espacial y la nave
nodriza): $0.4 millones/vuelo. Estos costos se suponen constantes para cada año y
vuelo, aunque de manera realista variarían hacia arriba o hacia abajo según la inflación,
la curva de aprendizaje, la eficiencia y las economías de escala a medida que se
agregan más naves espaciales a la flota. Los ingresos anuales también se suponen
constantes, aunque es probable que crezcan a medida que se pongan en funcionamiento
naves espaciales adicionales. Dados estos costos e ignorando otros factores (por
ejemplo, el valor del dinero en el tiempo), ¿cuál es el LCC para la empresa?
suposiciones
4 naves espaciales a 20 vuelos/año cada una = 80 vuelos/año (320 pasajeros/año, lo

que se encuentra dentro de la demanda anual estimada). 5 años de funcionamiento.
Costos
Desarrollo y fabricación: $80 millones Puesta en marcha

de Spaceline: $10 millones Operaciones en tierra: $2
millones/año Operaciones de vuelo: $0,4 millones/vuelo
Precio del boleto: $ 190,000 (eslogan de marketing: "¡Ahora USTED puede ir al espacio por
menos de $ 200,000!")
Modelo de CCV
LCC ($ millones) = Costo de desarrollo y producción + Costo de puesta en marcha + Costo operativo (5
años) = $80 + $10 + {[5 años x $2] + [5 años x 80 vuelos x $0,4]} = $260 millones Ingresos totales ($
millones) = (5 años x 80 vuelos x 4 pasajeros x $0,190) = $304 millones.
En pocas palabras: suponiendo que las suposiciones sean correctas, los ingresos superarán
los costos en $44 millones.
Todos los números son estimaciones, pero algunos son más seguros que otros. Por
ejemplo, según la experiencia con SpaceShipOne, el costo de desarrollo puede ser bastante
seguro, pero debido a la falta de experiencia operativa a largo plazo, el costo por vuelo es
bastante incierto. Los costos de puesta en marcha y operaciones en tierra, si son análogos a
las operaciones de las aerolíneas, pueden ser algo seguros, aunque la demanda de pasajeros
puede ser bastante incierta.
El modelo LCC juega un papel importante en el diseño y desarrollo del sistema. Según el
modelo, se puede realizar un análisis de sensibilidad para ver qué sucede cuando los costos
aumentan o disminuyen para mostrar el mejor de los casos, el más probable y el peor de los
casos. El modelo también se puede usar para determinar cuánto y en qué combinación deben
variar los costos para que la empresa se vuelva lucrativa (o desastrosa).
El modelo LCC también se utiliza para establecer objetivos de costos. Si se toma la decisión
de continuar con el costo de desarrollo y producción de $80 millones, entonces el proyecto
debe planificarse, presupuestarse y controlarse para mantenerse cerca de esa cantidad. Si el
costo por vuelo se establece en $0.4 millones, el proyecto debe esforzarse por desarrollar
vehículos cuya operación no cueste más que eso. Esto afectará innumerables decisiones de
diseño relacionadas con muchos detalles. Desde el principio, el análisis de diseño debe
considerar las principales alternativas (por ejemplo, transportar cinco o seis pasajeros, no
cuatro) y los costos, ingresos y beneficios esperados para cada uno.
El mejor y único enfoque verdaderamente completo para estimar y analizar

LCC está con un equipo de personas que representan todas las fases del sistema
Ciclo de desarrollo: un equipo multifuncional de diseñadores, constructores, proveedores y

usuarios, es decir, un equipo de ingeniería concurrente. La ingeniería concurrente se analiza
en el Capítulo 14.
Ver Capítulo 14
Impacto de las primeras decisiones sobre los costos del ciclo de vida
La importancia de definir cuidadosamente los requisitos y el sistema de elementos finales y

preparar el plan del proyecto; en otras palabras, prestar especial atención a las decisiones en
las Fases A y B del proyecto se ilustra en la Figura 8.19, que muestra el porcentaje de los
costos del ciclo de vida comprometidos . a versus etapa del proyecto. Por ejemplo, la figura
muestra que alrededor del 80 por ciento del LCC de un producto está determinado por las
decisiones tomadas en las etapas de concepto y diseño del proyecto, mucho antes de que el
producto se fabrique y use. Esto significa que cualquiera que sea el LCC del producto total, el
80 por ciento se basa en las elecciones realizadas en las dos primeras etapas de las 16 , a
proyecto.menos
etapasque
posteriores
esas decisiones
de producción
den cuenta
y operación,
correctamente
el resultado
de lo será
que sucederá
un períodoen el
prolongado de desarrollo de sistemas, retraso en el lanzamiento del producto y altos costos
de producción y operación.
8.11 Resumen
La estimación de costos y el presupuesto son parte del proceso de planificación del proyecto. La
estimación de costos sigue lógicamente el desglose del trabajo y precede a la presupuestación del proyecto.
Las estimaciones de costos precisas son necesarias para establecer presupuestos realistas y
proporcionar estándares contra los cuales medir los costos reales; por lo tanto, son cruciales para el
éxito financiero del proyecto.
Figura 8.19 Porcentaje del costo del ciclo de vida establecido durante las etapas del ciclo de vida del desarrollo de sistemas.
Los costos en los proyectos tienden a aumentar con el tiempo. Definir requisitos claros y tareas de
trabajo, emplear estimadores expertos, ser realista en la estimación y anticipar las causas de la
escalada, como la inflación, ayudan a minimizar la escalada. La precisión de la estimación es en parte
una función de la etapa del ciclo de vida del proyecto durante la cual se preparan las estimaciones;
cuanto más a lo largo de la
ciclo, más fácil es producir estimaciones precisas. Sin embargo, se necesitan estimaciones precisas al
principio del proyecto, y esta precisión se puede mejorar definiendo claramente el alcance y los objetivos
del proyecto, y subdividiéndolo en pequeñas tareas y paquetes de trabajo. En general, cuanto más
pequeño sea el elemento de trabajo que se estima y más estandarizado sea el trabajo, mayor será la
precisión de la estimación. El agregado de las estimaciones de costos para todos los elementos de trabajo
más los costos generales se convierte en la estimación de costos para el proyecto general. Las
estimaciones aprobadas se convierten en presupuestos después de agregar las reservas para
contingencias.
El presupuesto del proyecto se subdivide en presupuestos más pequeños llamados cuentas de control.
Las cuentas de control se derivan de la WBS y de las jerarquías de organización de proyectos y son el
equivalente presupuestario de los paquetes de trabajo. En proyectos grandes, un sistema de contabilidad
de costos del proyecto (PCAS) es útil para agregar estimaciones y mantener un sistema de cuentas de
control para presupuestar y controlar.
Los cronogramas de costos se derivan de presupuestos con fases temporales y muestran el patrón de
costos y gastos a lo largo del proyecto. Se utilizan para identificar los requisitos de efectivo y capital de
trabajo para mano de obra, materiales y equipos.
Los gastos previstos del proyecto y otras salidas de efectivo se comparan con los recibos de pago
programados y las fuentes de ingresos para predecir el flujo de efectivo a lo largo del proyecto. Idealmente,
los gastos y los ingresos están equilibrados para que el contratista pueda mantener un flujo de caja
positivo. Las previsiones se utilizan para preparar un plan que garantice el apoyo financiero adecuado
para el proyecto.
1. ¿Por qué las estimaciones de costos precisas son tan importantes, pero tan difíciles, en la
planificación de proyectos? ¿Cuáles son las implicaciones y consecuencias de sobrestimar los
costos? ¿De subestimar los costos?
2. Defina la escalada de costos. ¿Cuáles son las principales fuentes de aumento de costos?
3. ¿Cuál es el propósito de un fondo de contingencia (reserva de gestión)? Cómo
¿Se utiliza y controla el fondo de contingencia?
4. Describa lo que significa el término “planificación de proyecto por etapas (onda continua)”.
5. ¿Cómo los cambios en los requisitos provocan un aumento de los costos?
6. ¿Cómo influye el tipo de acuerdo contractual en el potencial de aumento de costos?
7. ¿Cuál es la relación entre las fases del ciclo de vida del proyecto y el costo?
¿escalada?
8. ¿Qué son los costos del ciclo de vida y en qué se diferencian de los costos del proyecto?
9. Explique la diferencia entre una estimación de costos y un objetivo de costos. ¿Cuáles son los
problemas de confundir los dos, al usar objetivos de costos como estimaciones de costos?
10. Explique la diferencia entre exactitud y precisión. dar dos

ejemplos que ilustran la diferencia.
11. Para cada uno de los siguientes métodos de estimación, describa brevemente el método, cuándo
se usa y la precisión de la estimación que proporciona:
una. opinión de expertos

b. analogía c.
paramétrico d. ingeniería
de costos.
12. Describa el proceso de uso de la EDT para desarrollar estimaciones de costos. Discuta la estimación
"de arriba hacia abajo" versus "de abajo hacia arriba". ¿Cómo se agregan las estimaciones del
paquete de trabajo en las estimaciones de costos totales del proyecto?
13. ¿Cuál es el papel de las unidades funcionales y subcontratistas en el costo
estimando?
14. Describa los diferentes tipos de montos de contingencia y los propósitos
cada uno sirve.
15. Describa el PCAS. ¿Cuál es su propósito y cómo se utiliza en el proyecto?

¿planificación?
16. ¿Qué es un presupuesto con fases temporales? ¿Cuál es la diferencia entre un presupuesto y una
estimación de costos?
17. Distinga los costos recurrentes de los costos no recurrentes.

18. ¿Cuáles son los seis elementos de costo compartidos por la mayoría de las estimaciones y presupuestos?
19. ¿Cómo se determinan los gastos de mano de obra directa?

20. ¿Qué gastos se incluyen como gastos directos no laborales?
21. ¿Cómo se determina la tasa de gastos generales?
22. ¿Qué es una cuenta de control y qué tipo de información contiene?
¿contener? ¿Cómo encaja una cuenta de control en la estructura del SCP?
23. ¿Cómo se agregan horizontal y verticalmente las cuentas de control? ¿Por qué se agregan así?
24. ¿Cómo se preparan los pronósticos basados en el tiempo y cómo se utilizan?

25. ¿Cuáles son las razones para investigar la influencia de los horarios en
costos del proyecto? ¿Cuál es la región presupuestaria factible?
26. ¿Qué podría pasar si la alta dirección presenta una oferta para un proyecto sin consultar a la
unidad de negocio o departamento que participará en el proyecto?
27. Consulte el Caso 5.1, Barrage Construction Company, en el Capítulo 5. El director del proyecto,
Sean Shawn, empleó la analogía con el método de ajuste para estimar el costo de construir un
garaje para tres automóviles.
Específicamente, comenzó con el costo promedio de un garaje para dos autos, $43,000, y lo
aumentó en un 50 por ciento a $64,500. Comente sobre la probable precisión de la estimación
del garaje para tres autos. Sugiera un enfoque diferente que pueda generar una estimación de
costos más precisa y luego use este enfoque y las cifras inventadas de tiempo y costo para
calcular la estimación.
Argumenta por qué tu estimación es mejor que la de Sean. Consulte el Capítulo 5, Figura 5.19,
para la WBS de Sean.
Ver Capítulo 5
28. El ejemplo de la Tabla 8.2 muestra tres formas posibles de repartir

costes directos totales. Utilizando el mismo ejemplo, supongamos que la no mano de obra directa
(DNL) costo y G&A se desglosan de la siguiente manera:
MARS Directo No Laboral PLUTÓN GEORGIA
Materiales 30 5 Transporte 8
Otro 10 5 Otro 32
40 10 40
Suponiendo que todos los costos restantes que se muestran en la Tabla 8.2 no cambian,
calcule los costos del proyecto para MARS y PLUTO usando la siguiente
reglas de reparto:
una. Los gastos generales (OH) son proporcionales a la mano de obra directa (DL).
b. El flete G&A es proporcional a los materiales.

C. Otros G&A son proporcionales a DL, OH, DNL y flete.
29. El Capítulo 7 discutió el impacto de las actividades de colisión y la relación

de horarios a costo. El método CPM asume que como duración de la actividad
disminuye, el costo directo aumenta debido a los aumentos en los costos directos.
tasas de mano de obra de horas extras. Las tasas de gastos generales también pueden variar, aunque el
tasa de gastos generales es a menudo menor para el trabajo de horas extras. por ejemplo, el
la tasa de gastos generales puede ser del 100 por ciento para el tiempo regular, pero solo del 20 por ciento
por horas extras En ambos casos, la tasa de gastos generales está asociada con el salario
tasa que se está utilizando.
Ver Capítulo 7
Suponga que en el proyecto MARS de la Tabla 8.2, 1000 horas directas de

se requiere mano de obra a $50 por hora, y la tasa de gastos generales asociada es
100 por ciento para el tiempo regular. Ahora suponga que la tasa de gastos generales es 10
el porcentaje y el salario por horas extras es de tiempo y medio. Compara el proyecto
costo si se hiciera en su totalidad a tiempo regular con el costo si se hiciera
enteramente en horas extras. ¿Cuál es menos costoso?
30. Usa la tabla a continuación y la red en la Figura 8.20 para responder preguntas
sobre el proyecto ARGOT:
Tiempo de actividad (semanas) Costo Semanal ($K) Total ($K)

A 4 3 12
B 6 4 24
C 3 5 15
D 4 5 20
mi 8 3 24
F 3 4 12
GRAMO 2 2 4
111
una. Calcule los ES y LS para el proyecto. Supongamos que Ts es el mismo

como la fecha más temprana de finalización del proyecto.
b. Construya una red basada en el tiempo para el proyecto, como la Figura

8.14 (utilice horarios de inicio anticipados).
C. Construya dos diagramas similares a los de la figura 8.15 que muestren

los gastos semanales y acumulativos del proyecto.
Figura 8.20 Red del proyecto ARGOT.
31. Utilizando los datos del problema 30, repita los pasos byc utilizando las horas de inicio tardías.
Luego identifique la región presupuestaria factible utilizando las curvas acumulativas.
32. Explique la retención de dinero y la garantía de cumplimiento.
1. ¿Cómo se estimaron los costos del proyecto? ¿Quien estaba involucrado? Describe el
proceso.
2. ¿Cuándo tuvo lugar la estimación? ¿Cómo se verificaron las estimaciones y
¿acumulado? ¿Cómo se relacionaron con la EDT?
3. ¿Cuáles, si las hubo, fueron las causas principales del aumento de costos en el proyecto?
4. ¿Se realizó un análisis de costos del ciclo de vida? Si es así, ¿quién lo hizo, cuándo y con qué
métodos? ¿Cómo afectó el análisis el diseño, desarrollo y producción de los entregables del
proyecto o el producto final principal?
5. ¿Con qué frecuencia y cuándo se revisaron las estimaciones de costos durante el proyecto?
6. ¿Cómo se determinaron los costos generales? ¿Qué base se utilizó para
establecer tasas de gastos generales?

7. ¿Cómo se contaron las estimaciones para llegar a una estimación del costo total del proyecto?
¿Quien hizo esto?
8. ¿Qué tipo de sistema de contabilidad de costos del proyecto (PCAS) se utilizó? ¿Era manual o
computarizado? Describir el sistema y sus entradas y salidas. ¿Quién mantuvo el sistema?
¿Cómo se utilizó durante el proyecto?
9. Describa el proceso de creación del presupuesto del proyecto. Mostrar una muestra
presupuesto (o parte del mismo).
10. ¿Cómo se manejaron los costos de administración y supervisión en el presupuesto?
11. ¿Se desglosó el presupuesto del proyecto en cuentas de control? Si es así,
una. ¿Cómo se relacionaron con los paquetes de trabajo y la EDT? b. ¿Cómo

estaban vinculados al PCAS?
12. ¿Qué tipo de resúmenes de costos se prepararon? ¿A quién fueron enviados?

¿Cómo se usaron? Muestre algunos ejemplos.
13. ¿Produjo el PCAS cronogramas y pronósticos de costos por fases? Muestre algunos ejemplos.
¿Cómo fueron utilizados por el director del proyecto?
14. ¿Se consideraron los costos del ciclo de vida en el proyecto? Explique.
Caso 8.1 Costos del ciclo de vida de una flota de naves

espaciales turísticas
Al momento de escribir este artículo, Burt Rutan y Sir Richard Branson se habían unido para
formar The Spaceship Company, que desarrollará y fabricará naves espaciales comerciales
(SpaceShipTwo o SS2), aviones de lanzamiento (WhiteKnightTwo o WK2) y equipos de apoyo.
La "línea espacial" de Branson
Virgin Galactic, se encargará de las operaciones de los vuelos turísticos espaciales. Su esperanza
es eventualmente reducir a la mitad el precio inicial propuesto del boleto de $190,000.
No se ha publicado información sobre los costos de desarrollo y operación de la línea espacial

y el equipo, por lo que las cifras utilizadas en este caso son conjeturas.
Consulte el Ejemplo 8.7 para conocer los costos hipotéticos del ciclo de vida de la línea espacial
y la flota de naves espaciales, pero suponga los siguientes cambios en los números:
• cinco naves espaciales, siete pasajeros por nave espacial. •

Costos de desarrollo y fabricación, $120 millones. • Costo de
operaciones de vuelo: $0.5 millones/vuelo. • Precio del boleto:
$190,000 para pasajeros en los primeros 100 vuelos, luego $150,000 para pasajeros en
los siguientes 100 y $100,000 para pasajeros en vuelos posteriores.
Preguntas
1. Suponiendo que todos los demás números del ejemplo 8.7 son iguales, ¿cuál
es la utilidad final de la empresa durante 5 años de operación?
2. Si la meta de ganancias es de $70 millones,
una. ¿Cuál es el costo máximo de desarrollo y producción para la flota?
b. ¿Cuál es el costo operativo máximo por vuelo? (nota: suponga un

costo de desarrollo/producción de $120 millones)?
3. Lluvia de ideas. ¿Cuáles son algunas formas de reducir el costo de desarrollo?

¿Cuáles son algunas posibles decisiones de diseño para la nave espacial y la
nave nodriza que reducirían el costo operativo por vuelo? A continuación,
busque artículos y comunicados de prensa sobre SS2 y WK2 para ver qué han
estado haciendo los desarrolladores, Scaled Composites y The Spaceship
Company, para contener los costos.
17
Caso 8.2 Costos Estimados del Proyecto Chunnel
Antes de que comenzara la construcción del Proyecto del Túnel del Canal de la Mancha
(Chunnel), los bancos que financiaban el proyecto contrataron ingenieros consultores
para revisar las estimaciones de costos preparadas por los contratistas. Los consultores
concluyeron que las estimaciones de excavación de túneles eran un 20 por ciento
demasiado altas. Su análisis se basó en comparaciones de costos de proyectos de
túneles europeos recientes, incluidos 50 túneles ferroviarios alemanes con una longitud
de 400 m a 11 km, hasta el Chunnel, que tendría una longitud de 49 km. Los costos de los túneles variaron
de £ 55 a £ 140 por cum (metro cúbico) de túnel abierto; el costo del Chunnel se estimó en £
181 por cum en el lado británico del canal y £ 203 en el lado francés (la diferencia se debe a
condiciones más difíciles en el lado francés). El Chunnel es en realidad tres túneles
interconectados: uno para los trenes que van en cada dirección y un túnel de servicio más
pequeño entre ellos. Tenga en cuenta, sin embargo, que las estimaciones de costos son por
metro cúbico de túnel, por lo que, presumiblemente, las diferencias en las longitudes y
diámetros de los túneles no son factores importantes. ¿Por qué las estimaciones para el
Chunnel podrían ser mucho más altas per cum que los costos de los proyectos de analogía?
Discutir posibles ajustes lógicos a los costos del proyecto del túnel de analogía para llegar a
una estimación de costos para el Chunnel.
'
Caso 8.3 Fionas Estimación para el Proyecto Gorgy
Fiona McDonald está preparando la estimación de costos para acompañar la propuesta de

licitación de Highwire Systems para el Proyecto Gorgy. Su conjetura aproximada es que el
proyecto debería tomar alrededor de 2 años y costar $3 millones, sin embargo, para ayudar a
preparar la estimación, crea una WBS (Figura 8.21).
Figura 8.21 Proyecto Gorgy.
Ella estima los costos de los tres paquetes de trabajo de la siguiente manera:
Desarrollo $2 millones
Integración $1 millón
Instalación/Prueba $ 1,5 millones
Proyecto $4.5 millones
Aunque la estimación total es un 50 por ciento más que su estimación aproximada, ella cree
que probablemente sea más precisa porque se desarrolló "de abajo hacia arriba".
Le da la estimación a Shireen Ghophal, gerente de contratos de Highwire Systems, quien le
pregunta: "Fiona, ¿cómo llegaste a los costos individuales de los $4,5 millones?". Fiona explica:
“El costo de desarrollo, $ 2 millones, fue simple: lo basé en el número proporcionado en la RFP
de lo que debería costar la parte de desarrollo del proyecto según la experiencia del cliente al
trabajar con desarrolladores en proyectos similares. Además, el número me pareció amplio, y
dado que era la única cifra de costo proporcionada en la RFP, lo consideré como una especie
de mandato para el costo máximo de desarrollo. En cuanto al costo de integración, observé el
hardware y el software del cliente con los que estaríamos trabajando como se indica en la RFP,
y lo comparé con los otros proyectos que habíamos realizado con equipos y sistemas similares
y lo que esos proyectos costo. Finalmente, para la instalación y prueba, revisé seis proyectos
que había completado en los últimos años y sus costos. Los costos de instalación y prueba
oscilaron entre $0,6 y $2 millones, con un promedio de $1,3 millones. Así que $1.5 parecía
razonable”.
Shireen responde: “Bueno, normalmente no cuestiono tu trabajo. Pero, ¿estás seguro de

haber cubierto todo el proyecto en el desglose del trabajo? ¿Los tres paquetes de trabajo
incluyen todo? ¿Y no solemos hacer una visita al sitio para inventariar los equipos y sistemas
del cliente con los que tendremos que trabajar? ¿Confías en la RFP? ¿Saben realmente lo que
tienen?
Y mirando el proyecto, tomará tal vez de 2 a 3 años. Será un gran proyecto.
¿Está seguro de que usted y su personal podrán administrar y coordinar todo por ese costo?
Fiona responde: “Todo está cubierto. En cuanto a la visita al sitio, la propuesta vence la
próxima semana y no tenemos tiempo. Tendremos que ir con lo que dicen en la RFP. En cuanto
a la instalación, según mi experiencia, el costo promedio de instalación/prueba fue de $1.3
millones. Elegí $ 1.5 millones para estar seguro y cubrir cualquier exceso en el costo de
desarrollo ".
Entonces Shireen repite: “¿Y qué pasa con la coordinación y la integración
¿esfuerzo?" a lo que Fiona responde: “Sí, probablemente será enorme, pero estoy bastante
segura de que, si obtenemos el contrato, Highwire me permitirá contratar a unos diez analistas/
ingenieros experimentados adicionales para mi personal administrativo. Como saben, nos hemos
atropellado en nuestros últimos proyectos y he estado discutiendo todo el tiempo que solo
necesito más personas para ayudar a coordinar y mantener las cosas bajo control”.
Shireen sospecha que el enfoque de estimación de costos de Fiona es bastante simplista y

deja un amplio margen de error. Enumere al menos cuatro deficiencias en su enfoque y lugares
donde las estimaciones pueden fallar.
Caso 8.4 Melbourne Construction Company, D
Bill Asher, el perito de Melbourne Construction Company, actualmente está estimando los días
necesarios para instalar los cimientos de la pared en los cimientos de un edificio de hotel. Como
es común para muchas de las actividades en proyectos de construcción, desarrollará la estimación
utilizando estándares de productividad laboral.
Los planos arquitectónicos del hotel indican que el área de contacto de los pies cuadrados
(SFCA, por sus siglas en inglés) para las bases de encofrado es de 13,340 pies cuadrados (1,239
m2 ). La instalación de cimientos se considera "estándar", por lo que Bill se refiere a un manual
de estándares de horas de trabajo para estimar el total de horas de trabajo requeridas para la
tarea. El manual indica que para las zapatas especificadas para el hotel, el estándar es de 0.066
18
horas de mano de obra por SFCA.
1. Dado el estándar SCFA y el SCFA estimado para los cimientos, ¿cuáles son las horas
de mano de obra estimadas para instalar los cimientos?
2. La empresa tiene la intención de asignar diez trabajadores para instalar las zapatas.
Suponiendo una jornada laboral de 8 horas, ¿cuál es la estimación de Bill de la
cantidad de días necesarios para completar esta tarea? (Nota: una suposición aquí es
que por cada trabajador adicional asignado a una tarea, la duración de la tarea
disminuye proporcionalmente. Esta es una suposición importante ya que en muchos
proyectos las duraciones de las tareas no son
proporcional al número de trabajadores. Agregar trabajadores no

necesariamente acortará los tiempos de las tareas e incluso podría aumentarlos).
Notas finales
1. Flyvbjerg B., Bruzelius N. y Rothengatter W. Megaproyectos y riesgo: una anatomía de la ambición.
Cambridge: Prensa de la Universidad de Cambridge; 2003, pág. dieciséis.
2. Véase Archibald RD Gestión de programas y proyectos de alta tecnología. Nueva York, NY: John Wiley &
Hijos; 1976, págs. 167–168.
3. Harrison F. Gestión avanzada de proyectos, Hants, Inglaterra: Gower; 1981, págs. 172-173, da un ejemplo
de una cláusula de escalada.
4. Políticamente, ¿qué tan independientes deben ser los estimadores? Tan independiente, dice DeMarco, que el gerente del proyecto "no
tiene comunicación con el estimador sobre cuán feliz o infeliz está alguien con la estimación". DeMarco T. Proyectos de software de control.
Nueva York, Nueva York: Yourdon Press; 1982, pág. 19
5. Flyvbjerg, Bruzelius y Rothengatter, Megaproyectos y riesgo: una anatomía de la ambición.
6. Harrison, Gestión avanzada de proyectos, págs. 154–161.
7. Dingle J. Gestión de Proyectos: Orientación para Tomadores de Decisiones. Londres: Arnold/John Wiley & Sons;
1997, pág. 105.
8. Pool R. Más allá de la ingeniería: cómo la sociedad da forma a la tecnología. Nueva York, Nueva York: Oxford University Press;
1997; Heppenheimer TA Energía nuclear. Invención y Tecnología Otoño 2002; 18(2): 46–56.
9. Kerzner H. proporciona una discusión completa del procedimiento de revisión de costos .
Enfoque de sistemas para la planificación, programación y control, 10ª ed. Nueva York, Nueva York: Van Nostrand
Reinhold; 2009, págs. 592–595.
10. Ver ibíd., Capítulo 14, para una discusión sobre el costo de la mano de obra en los proyectos.
11. Este ejemplo se deriva de uno similar en Rosenau M. Success Project Management. Belmont, CA:
aprendizaje de por vida; 1981, págs. 89–91.
12. Este ejemplo se deriva de Wilson T. y Stone D. Gestión de proyectos para un estudio de arquitectura.
Contabilidad de Gestión; Octubre de 1980, 25–46.
13. Los tipos de resúmenes de costos utilizados a menudo dependen del tipo disponible en el software, aunque muchos
Los paquetes de software permiten personalizar los informes.
14. Wiest J. y Levy F. Una guía de gestión para PERT/ CPM, 2.ª ed. Upper Saddle River, Nueva Jersey: Prentice Hall;
1977, págs. 90–94.
15. Harrison, Gestión Avanzada de Proyectos, pág. 185, señala que es difícil equilibrar el efectivo en contratos extranjeros
porque “En muchos casos, las ganancias de [negociaciones de divisas] pueden exceder las ganancias del proyecto; [si los fondos] no
se administran de manera efectiva, las pérdidas de los compromisos en moneda extranjera pueden generar grandes pérdidas en un
proyecto y conducir a la bancarrota”.
16. Smith P. y Reinertsen D. Desarrollo de productos en la mitad del tiempo. Nueva York: Van Nostrand Reinhold;
1991, págs. 224 y 225.
17. Fetherston D. El canal. Nueva York, Nueva York: Times Books; 1997, págs. 141 y 142.
18. RS Means Labor Rates for the Construction Industry, 41st edn. Norwell, MA: Medios RS; 2013.
Capítulo 9
Gestión de la calidad del proyecto
He ofendido a Dios ya la humanidad porque mi trabajo no alcanzó la calidad que debería tener.
—Leonardo da Vinci
Además de cumplir con el presupuesto y el cronograma, el éxito del proyecto depende de qué tan
bien cumpla con los requisitos de desempeño. Los requisitos de desempeño generalmente se basan
en las necesidades y expectativas de las partes interesadas del proyecto sobre el funcionamiento y
el desempeño del elemento final o los entregables del proyecto. Un proyecto de “alta calidad” es
aquel que cumple con los requisitos de desempeño, satisface las necesidades y expectativas de
todas las partes interesadas clave y no causa daño en ningún otro lugar.
9.1 El concepto de calidad

En la década de 1950 , la calidad se consideraba el proceso de inspeccionar productos que ya se
habían producido y separar los buenos de los malos. Pero en el entorno empresarial actual, según
se piensa, hay que prevenir defectos y fallas en lugar de inspeccionarlos; es decir, no se puede
corregir un error mediante la inspección. Debe incorporar procesos para garantizar que las cosas se
hagan bien la primera vez, siempre, y una cultura en la que todos se centren en la calidad.
Pero en la búsqueda competitiva, los equipos de proyectos a menudo buscan formas de acelerar
los cronogramas y reducir los costos, aunque esto a veces resulta en reelaboración, errores, mayor
carga de trabajo para el equipo del proyecto y un "derrumbe de la calidad". Se preocupan por reducir
los costos y acortar los cronogramas, a pesar de que "la amargura de la mala calidad perdura mucho
después de que se haya olvidado la dulzura del precio barato y la entrega oportuna".
1
Un ejemplo es el transbordador espacial Challenger. El 28 de enero de 1986, los sellos

defectuosos permitieron que las llamas rompieran la junta del motor de un cohete y encendieran el
tanque de combustible principal poco después del lanzamiento, provocando una explosión y matando
a los siete astronautas a bordo. Si bien los ingenieros habían advertido previamente sobre el riesgo
de que esto sucediera, el lanzamiento se llevó a cabo según lo programado debido a una promesa
a los políticos; en aras de cumplir con un cronograma, la calidad se vio comprometida.
2
El London Tower Bridge, Figura 9.1, ofrece un contraste. Se inauguró en 1894, 4
años tarde y costó casi el doble de las 585.000 libras esterlinas estimadas. Pero más de un siglo
después, ha resistido la prueba del tiempo. Originalmente diseñado y construido para permitir que
los peatones y los vehículos tirados por caballos cruzaran el río Támesis, ahora transporta 10,000
vehículos por día y es una importante atracción turística. Ha sobrevivido a inundaciones y
contaminación, problemas que sus diseñadores originales nunca consideraron. En términos de
tiempo y costo, el proyecto fue un fracaso; en cuanto a calidad ha sido un delirante
éxito.
Figura 9.1 Puente de la Torre de Londres.
Fuente: iStock.
¿Qué es la calidad?
La calidad es cumplir con las especificaciones o los requisitos, pero significa más que eso.
Si bien el cumplimiento de las especificaciones del proyecto generalmente evitará que un
cliente lleve a juicio a un contratista, por sí solo no puede garantizar que el cliente esté
satisfecho con el resultado final o que el contratista reciba agradecimiento o gane negocios repetidos.
Idealmente, un proyecto apunta más allá de las especificaciones y trata de cumplir con las
expectativas del cliente, incluidas las que no están articuladas; su objetivo es deleitar al cliente.
Los gerentes de proyecto a veces asumen, erróneamente, que las necesidades, expectativas
y requisitos del cliente son evidentes o requerirán poco esfuerzo para investigar y especificar.
Aptitud para el Propósito
El término calidad implica que un producto o entregable es adecuado para el propósito

previsto; esto puede implicar una amplia gama de criterios como el rendimiento, la
seguridad, la fiabilidad, la facilidad de manejo, la mantenibilidad, el soporte logístico y la
ausencia de impactos ambientales nocivos. Sin embargo, más allá de la idoneidad, el
cliente también tendrá en cuenta la relación calidad-precio de un producto y si tiene el
precio adecuado para el propósito previsto. Optimizar solo un aspecto de un producto
(idoneidad para el propósito, valor por dinero o beneficio estratégico para la organización)
no necesariamente resultará en un producto óptimo. El gerente de proyecto debe buscar
equilibrar los múltiples aspectos de un producto y definir especificaciones para reflejar ese equilibrio.
Ausencia de Defectos
La calidad también implica la ausencia de defectos, por lo que la gente suele asociar los
términos calidad y defecto. Un defecto es una no conformidad, un problema o error, algo
diferente de lo que el cliente esperaba. Una forma de lograr la calidad es identificar y
corregir tantas no conformidades como sea posible, e identificarlas lo antes posible. En
general, cuanto más tiempo persiste una no conformidad antes de que se descubra, más
costoso es remediarla o eliminarla. Puede ser relativamente fácil y económico reparar un
defecto en un componente, pero generalmente es más costoso repararlo después de que
el componente se haya colocado en un ensamblaje, e incluso más costoso después de que
el ensamblaje se haya incrustado dentro de un sistema. Un defecto es más costoso cuando
causa un mal funcionamiento o una falla del producto o sistema mientras el cliente lo usa.
Pero la "ausencia de defectos" requiere calificación, y la presunción de que cero defectos

equivale a alta calidad no siempre es cierta. Un proyecto de calidad es aquel que satisface
múltiples requisitos, y dedicar demasiada atención a uno en particular, como la eliminación
de todos los defectos, puede restar valor al cumplimiento de otros requisitos. Por ejemplo,
3
importantes. se relacionan con el tiempo,
en la el
mayoría
costo yde
el los
rendimiento.
proyectos Cuando
los requisitos
se debemás
mantener el cronograma, tratar de eliminar todos los defectos puede resultar
excepcionalmente costoso. El cliente puede preferir ceñirse al presupuesto y al cronograma
en lugar de eliminar todos los defectos. De
4 Incluso el
Por supuesto, en algunos casos es necesario tratar de eliminar todos los defectos. la
mayoría de los defectos menores en un sistema de control de tráfico aéreo o en un corazón humano
artificial pueden provocar lesiones o la muerte. El punto es que depende del cliente. A menudo, el
cliente prefiere que un entregable se complete a tiempo, a un costo más bajo y con algunos defectos
menores que completarlo tarde, a un costo más alto, pero sin defectos.
Calidad suficiente
Al eliminar los defectos, se hace hincapié en aquellos que impedirían que el sistema cumpliera con
sus requisitos más importantes. Este es el concepto de "calidad suficientemente buena": el criterio
predeterminado cuando las prioridades en los requisitos de rendimiento, tiempo y costo impiden
cumplir con todos los requisitos y obligan al equipo del proyecto a cumplir solo los más importantes.
Dice Bach, la creación de sistemas “de la mejor calidad posible es una propuesta muy, muy costosa,
[aunque] es posible que los clientes ni siquiera noten la diferencia entre la mejor calidad posible y
bastante buena 5 El cliente, por supuesto, debe ser capaz de juzgar qué es "suficientemente bueno",
problemas,calidad.
costos yy para
cronogramas.
ello debe estar constantemente actualizado sobre el progreso del proyecto,
En el caso ideal, todos en el equipo del proyecto contribuyen a la calidad; cada:
1. Sabe lo que se espera de ella 2. Es

capaz y está dispuesta a cumplir con esas expectativas 3.
Sabe hasta qué punto cumple con las expectativas 4. Tiene la
capacidad y la autoridad para tomar las medidas correctivas necesarias.
Tales condiciones requieren esfuerzos de liderazgo, capacitación y motivación centrados en la

calidad. Sin embargo, una vez que todos comienzan a contribuir, la atención a la calidad debe
volverse automática y requerir poca influencia del gerente del proyecto.
Qué calidad no es
La calidad implica que el producto es apto para el propósito. Pero la idoneidad para el propósito no
se relaciona necesariamente con el costo, la confiabilidad o las características del producto, todo lo cual
consulte el grado del producto. En otras palabras, la calidad y el grado no son lo mismo.
Por ejemplo, las minas de carbón producen diferentes grados de carbón. El grado más alto se
usa en la fabricación de acero, mientras que los grados más bajos se usan en productos químicos
y plantas de energía. A pesar de que el carbón para una planta de energía es de menor grado
que el de la fabricación de acero, es el carbón apropiado y, por lo tanto, de mejor calidad para el
propósito; sería inapropiado y antieconómico utilizar carbón de mayor calidad en las centrales
eléctricas. Por supuesto, las empresas que extraen el carbón deben esforzarse por lograr
procesos de alta calidad para entregar todos los grados de carbón para cumplir con las
especificaciones de todos sus clientes, incluidas las especificaciones de precio y entrega.
Movimientos de Calidad y Progreso
La “revolución de la calidad” comenzó en la década de 1950 en Japón, en parte bajo la influencia

del Dr. W. Edwards Deming, un consultor estadounidense. Propuso una filosofía de calidad que
incluía la mejora continua, la capacitación en habilidades, el liderazgo en todos los niveles, la
eliminación de la dependencia de las inspecciones, la confianza en proveedores de una sola
fuente en lugar de proveedores de muchas fuentes y el uso de técnicas estadísticas. Desde
entonces, han ido y venido otros movimientos de calidad, algunos que podrían describirse como
modas pasajeras. El movimiento más duradero y popular desde la década de 1980 es la gestión
de calidad total (TQM). TQM es un conjunto de técnicas y más: es una mentalidad, un enfoque
ambicioso para mejorar la eficacia y competitividad totales de una organización. Los elementos
clave de TQM son identificar la misión, las metas y los objetivos de la organización, actuar de
manera coherente con esas metas y objetivos y centrarse en la satisfacción del cliente. TQM
involucra a toda la organización, incluidos los equipos de trabajadores de primera línea y el apoyo
visible de la alta dirección. Los problemas de calidad se identifican y resuelven sistemáticamente
para mejorar continuamente los procesos. En los proyectos, este propósito se cumple mediante
revisiones de proyectos y sesiones de cierre, discutidas en este capítulo y en los siguientes.
Complementando TQM es la filosofía de gestión de la producción ajustada (LP).

LP reconoce el hecho de que los problemas de calidad generalmente se originan en "procesos
rotos" y proporciona métodos y herramientas para analizar procesos y exponer y eliminar las
fuentes de desperdicio en los procesos. Incluye métodos relativamente fáciles de implementar
mejorar la calidad y reducir costos y tiempos de entrega. para
El aspecto más difícil de implementar LP es desarrollar una cultura en la que los empleados de
todas partes tengan la autoridad y las habilidades para mejorar continuamente sus procesos, un
concepto inusual para muchas organizaciones. Los principios de LP se originaron en Toyota y se
han adoptado con éxito en todo el mundo. En algunas industrias (por ejemplo, la automotriz y la
electrónica), prácticamente todos los grandes actores han adoptado la producción ajustada. En
entornos de proyectos, los métodos de PL se están aplicando al desarrollo y la construcción de
productos. Algunos de estos métodos se describen en el Capítulo 13.
Ver Capítulo 13
Otro movimiento de calidad llamado Six Sigma se originó en la década de 1980 en Motorola y
luego fue popularizado por General Electric. El término “Six Sigma” se refiere al hecho de que en
una distribución normal, el 99,99966 por ciento de la población se encuentra dentro de ÿ6ÿ a +6ÿ
de la media, donde “ÿ” es la desviación estándar. Si la calidad de un proceso se controla según
el estándar 6ÿ, habría menos de 3,4 partes por millón de defectos en el proceso, ¡casi la
perfección!
Pero el movimiento Six Sigma va más allá de las estadísticas y es una filosofía para reducir la
variabilidad del proceso. Incluye dos procesos de cinco pasos, uno para mejorar los procesos
existentes y otro para diseñar nuevos procesos y productos, ambos dirigidos a niveles de calidad
6ÿ. El primer proceso, llamado DMAIC para Definir, Medir, Analizar, Mejorar y Controlar, involucra
los pasos de definir las mejores acciones para mejorar un proceso, implementar esas acciones,
rastrear los resultados y reducir los defectos para que menos resultados no cumplan con las
especificaciones. .
El segundo proceso se llama DMADV: definir, medir, analizar, diseñar y verificar. En los
proyectos, el enfoque Six Sigma se traduce en la definición de entregables claros que se
relacionan con la misión de la organización y son aprobados por la gerencia. En algunas
empresas el proceso DMAIC es la metodología del proyecto y define las etapas del mismo.
Gestión de la calidad del proyecto
La calidad del proyecto significa la calidad del elemento final, entregable o producto del proyecto.
La calidad del artículo o producto final comienza con requisitos o especificaciones

del sistema claramente definidos y acordados tanto por el contratista como por el
cliente. Si el contratista siente que el cliente ha proporcionado requisitos que no son
realistas, debe revisarlos con el cliente y modificarlos para lograr el resultado final
deseado de manera realista. Las especificaciones acordadas deben reflejar las
expectativas del cliente sobre la idoneidad del producto para el propósito previsto y
cualquier compromiso negociado. Las especificaciones integrales para el entregable
deben incluirse en la definición del alcance del proyecto.
La gestión de la calidad del proyecto incluye procesos de gestión, así como
técnicas para reducir el riesgo de que los productos o entregables no cumplan con
los requisitos. Las siguientes secciones discuten estos procesos y técnicas.
9.2 Procesos de Gestión de la Calidad del Proyecto
La gestión de la calidad del proyecto tiene tres procesos: planificación de la calidad, garantía de la calidad
y control de la calidad (Figura 9.2). La planificación de la calidad guía las futuras actividades de calidad;
establece los requisitos y estándares a cumplir y las acciones necesarias para cumplirlos. El control de
calidad realiza las actividades de calidad planificadas y garantiza que el proyecto utilice los procesos
necesarios para cumplir con los estándares de calidad y los requisitos del artículo final. El control de
calidad garantiza que las actividades de aseguramiento de la calidad se realicen de acuerdo con los
planes de calidad y que se cumplan los requisitos y estándares. Piense en el control de calidad como la
"medicina" para eliminar las no conformidades existentes y en la planificación y el aseguramiento de la
calidad como el "estilo de vida saludable" para prevenir las no conformidades en primer lugar.
Como se muestra en la Figura 9.2, el control de calidad del proyecto vincula la planificación de la
calidad y el aseguramiento de la calidad para asegurar que el aseguramiento de la calidad ocurra de
acuerdo con el plan de calidad. El aseguramiento de la calidad tiene como objetivo garantizar estándares
de calidad apropiados para un proyecto y aprovechar las oportunidades de aprendizaje de los proyectos
terminados para mejorar en proyectos futuros.
Figura 9.2 El proceso de gestión de la calidad del proyecto.
Planeación de calidad
La planificación de la calidad debe proporcionar la confianza de que se ha atendido todo lo

necesario para garantizar la calidad. Tiene dos aspectos: (1) establecer procedimientos y
políticas de gestión de calidad para toda la organización y (2) establecer un plan de calidad
como parte del plan de ejecución de cada proyecto.
La responsabilidad de establecer políticas y procedimientos en toda la organización para
mejorar la calidad del proyecto generalmente recae en los gerentes funcionales,
especialmente en el gerente de calidad. Los proyectos a menudo emplean estándares de
7
calidad que ya existen, como el estándar ISO 9001 (un sistema de gestiónPara
de calidad).
proyectos de
diseño y desarrollo, esta norma prescribe que una organización debe establecer
procedimientos para (a) las etapas de diseño y desarrollo; (b) las revisiones, verificaciones y
validaciones necesarias y adecuadas a cada una de las etapas; y (c) el
responsabilidades y autoridades de las etapas.
Costos de la Calidad
Dado que la calidad siempre está relacionada con el valor del dinero gastado, la planificación de la calidad debe
considerar los costos y beneficios de las actividades de calidad. Se realiza un análisis de costo-beneficio para
evaluar las actividades de calidad propuestas. El dinero gastado en aseguramiento y control de calidad debe
justificarse en términos de ahorros esperados o beneficios de menos o eliminadas no conformidades.
Los costos de la calidad se clasifican en prevención, evaluación y control (costos de conformidad), y falla
interna y falla externa (costos de no conformidad):
1. Prevención: costos de capacitación, revisiones de diseño y actividades dirigidas a

prevención de errores; incluye el costo de la planificación de la calidad.
2. Evaluación y control: costos de evaluar productos y procesos, incluidas revisiones, auditorías, pruebas
e inspecciones de productos.
3. Falla interna: costos asociados con las no conformidades descubiertas por el
productor; incluye los costos de desecho, reelaboración y nueva prueba.

4. Falla externa: costos incurridos como resultado de fallas del producto después de la entrega al cliente;
incluye costos de reemplazos, reparaciones en garantía, responsabilidad, pérdida de ventas y
reputación dañada.
Si bien los costos de la calidad pueden representar tan solo el 2 por ciento de las ganancias para una
empresa con un buen sistema de gestión de calidad, pueden superar el 20 por ciento para una empresa con un
Por gastar
sistema de gestión de calidad deficiente. invertir en un buen sistema, es 8decir, lo tanto,
mástiene sentidodepara
en revisiones
diseño, auditorías, capacitación, modelado y pruebas para gastar menos en fallas internas y externas.
Para proyectos, los costos de prevención, evaluación, control y falla interna se incurren durante el proyecto;
los costos asociados con fallas externas vienen después de que se completa el proyecto. Los costos de
conformidad (prevención, evaluación y control) se encuentran entre los muchos que el gerente del proyecto debe
justificar ante la gerencia y el cliente, e incluirlos en el plan y presupuesto del proyecto.

Plan de Gestión de la Calidad del Proyecto
El plan de gestión de la calidad del proyecto (plan de calidad) es un componente importante del
plan de ejecución del proyecto analizado en el Capítulo 5. Un principio central de lo que se
denomina “calidad por diseño” es que la calidad se puede planificar y que muchos problemas
se pueden prevenir mediante la forma en que está planeado. Por lo tanto, crear un plan de
calidad es importante para la ejecución exitosa de los proyectos.
Ver Capítulo 5
La identificación, programación, presupuestación y asignación de responsabilidad para las

actividades de garantía y control de calidad se realiza utilizando los mismos principios y
métodos que para otras actividades del proyecto, discutidas en los Capítulos 4 a 8. El plan
aborda el enfoque de gestión de calidad del proyecto, indica las partes interesadas involucrados
y cómo el proyecto respondería a cualquier cambio en las necesidades del cliente. Por lo
general, hace referencia a políticas y procedimientos organizacionales relevantes (por ejemplo,
configuración
Consulte los capítulos 4 a 8
sistema de gestión y procedimientos de clasificación de características (ambos discutidos más

adelante) y cómo se implementarían en el proyecto.
Si no se cubre lo suficiente en una metodología de gestión de proyectos, el plan debe indicar
cómo se iniciaría y autorizaría cada una de las fases del proyecto, y cómo se cerrarían las
fases y el proyecto completo.
El plan debe abordar todos los elementos relevantes indicados en la Figura 9.2, incluida la
forma en que el equipo del proyecto se asegurará de que se cumplan los requisitos de calidad
establecidos en las especificaciones y estándares. Esto normalmente puede incluir:
• Todos los modelos que se producirán y probarán, y las especificaciones, procedimientos

e informes de prueba asociados • Inspecciones, equipo requerido para las inspecciones,
calibración de equipo e informes requeridos • Pruebas de aceptación final, incluso cuándo
se llevarán a cabo y se probarán
especificaciones, procedimientos e informes •

Cualquier revisión de diseño requerida, el propósito de cada una, las personas involucradas y los
resultados requeridos • Auditorías
• Listas de verificación
• Técnicas que se utilizarían, por ejemplo, FMEA o gráficos de control.
El plan también puede indicar cómo se manejarían las no conformidades, las quejas de los clientes y las
acciones correctivas. Debe indicar claramente la persona principal responsable de cada tarea y las funciones
y responsabilidades de los demás involucrados. La matriz de responsabilidad discutida en el Capítulo 5 se
puede usar para esto .
objetivo.
Ver Capítulo 5
Seguro de calidad
El aseguramiento de la calidad del proyecto se relaciona con la ejecución del plan de gestión de la calidad del
proyecto y tiene como objetivo reducir los riesgos de no cumplir con las características deseadas o los
requisitos de desempeño de los entregables.
Como se muestra en la Figura 9.2, el aseguramiento de la calidad cubre lo siguiente:
1. Actividades realizadas en un proyecto específico para garantizar que se cumplan los requisitos y
que el proyecto se ejecute de acuerdo con el plan de calidad.
2. Actividades que contribuyan a la mejora continua de los proyectos actuales y futuros ya la madurez
de gestión de proyectos de la organización.
El aseguramiento de la calidad debe proporcionar la confianza de que todo lo necesario está

se está haciendo para asegurar la calidad apropiada de los entregables del proyecto.
Mejora continua y revisiones posteriores a la finalización del proyecto

La mejora continua es la base del progreso: sin ella, la humanidad no habría superado la Edad de Piedra.
Las organizaciones de proyectos se esfuerzan por mejorar continuamente sus operaciones técnicas y
procesos de gestión, en parte, mediante la realización de una revisión formal posterior a la finalización de
cada proyecto. La revisión ocurre al finalizar el proyecto o, mejor, al finalizar cada fase del proyecto. Su
propósito es entender lo que pasó y aprender lecciones que se pueden aplicar a otros proyectos y evitar
repetir errores.
La responsabilidad del gerente del proyecto durante las revisiones es facilitar una discusión franca y
constructiva sobre lo que sucedió, lo que funcionó y lo que no, y asegurarse de que todos los participantes
sean escuchados. La discusión se documenta formalmente y se crea una lista de lecciones aprendidas.
Este proceso, aunque es esencial para la mejora continua, a menudo se descuida porque las personas
pierden interés a medida que el proyecto termina o cuando se ocupan de nuevos proyectos futuros. Como
resultado, las organizaciones repiten errores, reinventan la rueda y no aprenden de sus experiencias.
juegan un papel importante en la gestión del conocimiento, discutido en el Capítulo 17.
9
Las revisiones posteriores a la finalización se cubren más en el Capítulo 12; ellos
Control de calidad
El control de calidad es el proceso continuo de monitorear y evaluar el trabajo, y tomar medidas correctivas
para lograr los resultados de calidad planificados (requisitos y especificaciones). También verifica que las
actividades de aseguramiento de la calidad se realicen según lo especificado en el plan de calidad. El
control de calidad es un aspecto del control del proyecto, un tema del Capítulo 11 pero incluido aquí para
la continuidad.
Ver Capítulo 11
El control de calidad puede contrastarse con la verificación del alcance: mientras que la verificación
del alcance se refiere a la aceptabilidad de los entregables del proyecto por parte del cliente, el control
de calidad se refiere a la conformidad con las especificaciones establecidas por el contratista.
La verificación del alcance incluye verificar la aceptabilidad de las especificaciones y
estándares, pero el control de calidad se refiere a verificar el cumplimiento de las especificaciones y

estándares previamente establecidos.
El proceso de control de calidad incluye inspecciones para verificar que los entregables cumplan con
las especificaciones, además de pruebas de aceptación antes de entregar los entregables al cliente. En
el caso de que una característica menor no cumpla con las especificaciones, el contratista podría solicitar
una exención o desviación. Una exención se aplica a una condición no planificada que se descubre solo
después de que se ha producido el artículo. Autoriza una no conformidad temporal, como un rasguño
descubierto en la pintura de un elemento de hardware. Una desviación también es una desviación
temporal de la especificación, pero se descubre antes de la producción. Por ejemplo, si un material
específico no está disponible temporalmente, el contratista puede solicitar una desviación para permitir
el uso de un material alternativo. Una tercera forma de desviación de la especificación es una modificación;
este es un cambio en la especificación que se considera permanente.
Las actividades de control, como se ilustra en la Figura 9.2 , incluyen tanto actividades de control de
calidad planificadas como resolución de problemas ad hoc. Las actividades planificadas incluyen, por
ejemplo, inspecciones en un sitio de construcción, pruebas en un componente del producto o auditorías
para garantizar que un proveedor esté utilizando los materiales correctos. La resolución de problemas ad
hoc se refiere al manejo de problemas y riesgos a medida que surgen. Las técnicas para el análisis y la
resolución de problemas se discuten más adelante.
El control de calidad no puede ocurrir de forma aislada; debe integrarse con control de alcance,
control de costos, control de progreso y control de riesgos. Así, de la misma manera que el plan de
calidad debe integrarse con otros aspectos del plan del proyecto, el control de calidad debe integrarse
con los demás aspectos del control del proyecto.
Calidad de los artículos adquiridos
Los estándares de la industria establecen los requisitos de calidad para los artículos listos para usar
adquiridos de los proveedores, en cuyo caso el criterio principal para elegir un proveedor es el precio.
Para comprar un lote de artículos estándar, como pernos, el oficial de adquisiciones obtiene cotizaciones
de precios de varios proveedores y elige el más bajo. Cuando llega el lote, un inspector revisa los pernos
para determinar si son aceptables.
Pero para adquirir un sistema o elemento que debe desarrollarse recientemente, es probable que no
exista un estándar de la industria. En ese caso, el comprador tiene que trabajar con el proveedor y
ayudar en la planificación de la garantía y el control de calidad para garantizar que el artículo cumpla con
las especificaciones.
Por supuesto, incluso para la adquisición de artículos estándar, mucho mejor que seleccionar el
proveedor de precio más bajo es seleccionar uno que tenga la capacidad y la disposición comprobadas
para cumplir con los requisitos del contratista, y luego buscar desarrollar una relación a largo plazo
mutuamente beneficiosa con el proveedor. Las dos partes trabajan juntas como socios y comparten la
responsabilidad del éxito de cada uno. Establecer este tipo de relación no siempre es fácil, especialmente
cuando el proveedor es mucho más grande que el contratista o no valora la relación o considera prioritario
el trabajo contratado.
Los contratistas a menudo invierten mucho para asegurarse de que puedan adquirir subsistemas y
componentes de la calidad adecuada. Un contratista a menudo tiene una sección especial de calidad de
proveedores dentro de su división de adquisiciones para administrar el control de calidad de todos sus
artículos adquiridos, incluido su desarrollo y fabricación o construcción. El propósito de esta sección es
asistir en la selección de proveedores, monitorear los procesos de los proveedores para asegurar la calidad
y realizar inspecciones y pruebas de aceptación de los artículos comprados. Otras responsabilidades se
describen a continuación.
Ejemplo 9.1: Empresas que trabajan juntas

para el control y la garantía de calidad
La empresa A desarrolla y fabrica vehículos mineros. Está trabajando en un nuevo vehículo y debe
elegir un proveedor para desarrollar, fabricar y respaldar una transmisión para el vehículo. La sección
de calidad de proveedores y el personal de adquisiciones de la empresa revisan las propuestas de
los proveedores candidatos y seleccionan a la empresa B para que proporcione las transmisiones.
La división de ingeniería de la Compañía A desarrolla una especificación funcional para la transmisión
que incluye características de rendimiento, requisitos de mantenimiento, interfaces con otras partes
del vehículo y requisitos de prueba. Su sección de calidad del proveedor luego trabaja con los
ingenieros de la Compañía B para garantizar que utilizarán los procesos apropiados para el
cumplimiento rentable de la especificación, y que probarán todas las transmisiones de acuerdo con
la especificación funcional de la Compañía A para el cumplimiento del rendimiento antes del envío.
9.3 Técnicas para el aseguramiento de la calidad en el

desarrollo de sistemas
Esta sección explica con más detalle los elementos de la Figura 9.2. En la planificación de proyectos
por fases, la autorización de una fase implica que los planes para la fase han satisfecho criterios
preespecificados, incluido que los planes incluyen medidas suficientes para el aseguramiento de la
calidad. Los desarrolladores de sistemas emplean una variedad de tales medidas, como se analiza
en esta sección.
10
Gestión de la configuración
Durante el diseño y desarrollo de un sistema, se generan grandes cantidades de información para

usar en el proceso de diseño y luego en la fabricación (o construcción), mantenimiento y soporte.
La información puede incluir cientos o miles de documentos (especificaciones, esquemas, dibujos,
etc.), cada uno de los cuales es probable que se modifique de alguna manera durante el proyecto.
Hacer un seguimiento de todos los cambios y saber qué versión es la más actual para cada elemento
puede ser difícil.
Por lo tanto, cualquier proyecto destinado a entregar un producto técnico necesita un sistema o
proceso para mantener y administrar toda la información; tal es el propósito de la gestión de la
configuración.
La gestión de la configuración incluye políticas y procedimientos para monitorear y rastrear la
información y los cambios de diseño, y garantizar que todos los involucrados en el proyecto (y, más
tarde, en la operación del artículo final) tengan la información más actualizada. Las políticas y
procedimientos que forman el sistema de gestión de la configuración para un proyecto deben
incluirse en el plan de calidad. Como ocurre con todos los procedimientos, el mejor sistema de
gestión de la configuración es el que permite el nivel de control deseado y es el más sencillo de
implementar. Los dos aspectos principales de la gestión de la configuración son la identificación de
la configuración y el control de la configuración.
Identificación de configuración
La identificación de la configuración es una parte inherente del diseño de sistemas e implica definir la
estructura general de un sistema y sus subsistemas y componentes.
Mencionado en el Capítulo 2, cualquier subsistema, componente,
Ver Capítulo 2
o la parte que debe ser rastreada y controlada como una entidad individual a lo largo del ciclo de vida
de un sistema se identifica como un elemento de configuración (CI). Un CI puede ser una pieza de
hardware, un manual, una lista de piezas, un paquete de software o incluso un servicio. Cualquier
parte del sistema que se adquiere también se trata como un CI. Se identifican y documentan todas
las características físicas y funcionales que definen y son importantes para el control del IC. En última
instancia, cada elemento funcional y físico del sistema de artículo final debe estar asociado de alguna
manera con un CI, ya sea como un CI por derecho propio o como un componente dentro de un
subsistema que se ha identificado como un CI. Idealmente, cada CI es lo suficientemente pequeño
para ser diseñado, construido y probado por un pequeño
equipo.
La copia maestra (electrónica o en papel) de los documentos de configuración para cada CI se

conservan en una ubicación única y segura (el "centro de configuración") y es administrada por
alguien que no participa en las funciones de diseño, construcción, fabricación o mantenimiento. (La
documentación sobre las premisas de diseño, las suposiciones y los cálculos no se consideran
documentos de configuración y la autoridad de diseño los conserva en otro lugar).
Todas las modificaciones, exenciones o desviaciones de un CI se registran para que todos los
documentos de CI reflejen el estado "tal como está construido" del sistema. En el caso de un producto
a entregar, como un edificio, un barco u otro sistema único en su tipo que se vuelve operativo, la
especificación "tal como está construido" se utilizará más adelante en su operación y mantenimiento.
Cuando se producen unidades múltiples (por ejemplo, automóviles, aviones, electrodomésticos) y se
introducen modificaciones y mejoras con el tiempo, se debe conocer la configuración específica para
cada unidad producida individualmente, lo que requiere que cada CI específico en el producto se
pueda rastrear hasta su “específico”. especificaciones según construcción”. Esto es necesario para
que, por ejemplo, se puedan suministrar las piezas de repuesto, la capacitación y los manuales de
operación correctos, y se puedan rastrear los problemas y
analizados en caso de accidentes, quejas de clientes o reclamaciones relacionadas con

la responsabilidad del producto. Este concepto de “trazabilidad” se introdujo en el
Capítulo 4 y se ilustra en el siguiente ejemplo.
Ver Capítulo 4
Ejemplo 9.2: Trazabilidad y la nave

espacial Apolo 11
Para establecer la confiabilidad de un artículo, se prueban muchas unidades del

artículo hasta que una falla, o se diseña la confiabilidad requerida a través de
métodos de análisis de ingeniería. De todos modos, para garantizar la confiabilidad,
se debe conocer todo sobre el artículo: su proceso de fabricación, la composición
de sus piezas y materiales, e incluso las fuentes de esos materiales. Para la misión
espacial Apolo, el objetivo de lograr el éxito de la misión se fijó en un 99 % y la
capacidad de supervivencia de la tripulación en un 99,9 %. Para cumplir con
objetivos de tan alto nivel, cada CI (subsistema, componente, pieza, etc.) a medida
que avanzaba en el proceso de diseño y fabricación iba acompañado de un paquete
de documentos que establecía su genealogía y pedigrí. El dicho decía: “Si pides
una pieza de madera contrachapada, quieres saber de qué árbol proviene”. Los
pernos de media pulgada para la nave espacial Apolo involucraron un proceso de
fabricación de 11 pasos con pruebas de certificación en cada paso. Cada perno se
sometió a pruebas rigurosas, al igual que las varillas de acero con las que se
fabricaron, los tochos de los que se extruyeron las varillas y los lingotes con los que
se forjaron los tochos. Se documentó todo sobre los procesos y las pruebas de los
pernos, incluido el origen del hierro para los pernos, Minnesota, e incluso la mina y
el pozo de la mina. Este seguimiento y control extremos son necesarios para
garantizar una alta confiabilidad y permitir el diagnóstico de problemas en caso de
que las cosas salgan mal. Sin embargo, tiene un precio, por lo que los pernos
disponibles por 59 centavos en la ferretería cuestan $ 8 o $ 9 cada uno en cohetes
y naves espaciales.
Control de configuración
El tema del control de configuración, el segundo aspecto de la gestión de configuración, se

relaciona más con el control de calidad que con la garantía de calidad, pero lo cubrimos aquí
en aras de la continuidad. El diseño de un sistema normalmente se especifica por medio de
varios documentos, como especificaciones de rendimiento, dibujos, manuales y procedimientos
de prueba que se generan durante el proceso de diseño. A medida que evoluciona el diseño,
estos documentos están sujetos a cambios, por lo que se necesita un esquema para
administrar y realizar un seguimiento de los cambios. Tal es el propósito del control de
configuración.
El control de configuración se basa en los siguientes principios:
1. Cualquier organización o individuo puede solicitar una modificación, renuncia o

desviación.
2. Se documenta el cambio propuesto y su motivación. Existen documentos estándar
para este propósito: para modificaciones, el documento se denomina propuesta de
cambio, solicitud de cambio, orden de cambio u orden de variación.
3. Se evalúa el impacto del cambio propuesto en el rendimiento del sistema, la seguridad
y el medio ambiente; también lo es su impacto en otros elementos de hardware,
software, manuales y métodos de fabricación o construcción y
mantenimiento.
4. Se evalúa la factibilidad del cambio, lo que incluye estimar los recursos necesarios
para implementar el cambio y el impacto del cambio en los cronogramas.
5. El grupo responsable de aprobar o rechazar el cambio es el tablero de configuración

(CB) o un tablero de control de configuración (CCB). La junta generalmente incluye
al diseñador jefe y representantes de fabricación o construcción, mantenimiento y
otras partes interesadas importantes, y a menudo está presidida por el gerente del
proyecto o del programa.
gerente.
6. Una vez aprobado el cambio propuesto, se planifica el trabajo para implementar el
cambio. El plan incluye acciones con respecto a la disposición de todo lo que pueda
verse afectado por el cambio, incluidos repuestos, equipos y procesos para la
fabricación o construcción, y manuales.
y otra documentación.
7. El cambio implementado es monitoreado y controlado para asegurar que
cumple con la propuesta de cambio aprobada.
Las solicitudes de cambio a veces se clasifican como Clase I o Clase II. Las solicitudes de
Clase I pueden ser aprobadas por el contratista o el desarrollador; La clase II debe ser aprobada
por el cliente.
El control de la configuración es un aspecto del control del proyecto y, en particular, del cambio
control, ambos discutidos en el Capítulo 11.
Ver Capítulo 11
Reseñas de diseño
El director del proyecto debe asegurarse de que el diseño propuesto sea aceptable en todos los
aspectos; ese es el propósito de las revisiones de diseño: garantizar que los requisitos y
suposiciones de los usuarios se hayan identificado correctamente y que el diseño propuesto
pueda cumplir con los requisitos de manera adecuada. Las revisiones de diseño (que no deben
confundirse con las revisiones generales de proyectos, descritas en el Capítulo 12) brindan
confirmación de los supuestos de diseño (p. ej., condiciones de carga), datos utilizados en el
proceso de diseño y cálculos de diseño. Idealmente, aseguran que todos los aspectos importantes
del ciclo de vida del artículo final se hayan abordado y no presenten riesgos inaceptables. En
particular, las revisiones revisan los diseños para:
Ver Capítulo 12
1. omisiones o errores
2. Cumplimiento de reglamentos, códigos, especificaciones y estándares 3.

Costo de propiedad 4. Seguridad y responsabilidad del producto 5.
Confiabilidad 6. Disponibilidad 7. Capacidad para ser construido o fabricado
(fabricabilidad)
8. vida útil
9. operabilidad
10. mantenibilidad 11.
derechos de propiedad intelectual 12.
ergonomía.
Las revisiones involucran a representantes de todas las disciplinas, funciones, usuarios que estarán
conectados con el producto a lo largo de su ciclo de vida y, a menudo, diseñadores externos y expertos
en la materia. (Esto se relaciona con la ingeniería concurrente, discutida en los Capítulos 4 y 14). Por
ejemplo, la revisión del diseño de una planta, mina o fábrica química incluiría representantes de:
• La organización que operará la instalación • El área de

soporte técnico que mantendrá la instalación • La empresa constructora • Las áreas
de mercadeo, compras, servicios legales y calidad que ocuparán, harán uso o
tendrán que enfrentar las consecuencias de la instalación
Las revisiones de diseño realizadas al principio de la fase conceptual involucran a representantes de

solo unas pocas funciones; a medida que avanza el proyecto, se involucran representantes de más
funciones. Para el diseño de una pieza o componente simple, una sola revisión al finalizar el diseño pero
antes de la fabricación podría ser suficiente, pero para el diseño de un sistema complejo, sería necesario
convocar varias revisiones en etapas sucesivas del proyecto.
Revisiones formales
Las revisiones formales de diseño son eventos planificados, generalmente presididos por el director del
proyecto o por alguien que no esté directamente involucrado en el diseño del artículo final.
Los proyectos destinados a desarrollar y entregar un producto suelen tener cuatro revisiones:
1. Revisión preliminar del diseño: revisión del diseño funcional para determinar si el concepto
cumple con los requisitos operativos básicos.
2. Revisión crítica del diseño: revisión de los detalles del diseño del hardware y el software para
garantizar que se ajusten a las especificaciones preliminares del diseño.
3. Revisión de la preparación funcional: (solo para productos producidos en masa), evaluación
de pruebas realizadas en artículos producidos antes para verificar la eficacia del proceso de
fabricación.
4. Revisión de la preparación del producto: comparación de los productos fabricados con las
especificaciones para garantizar que los documentos de control de diseño darán como
resultado productos que cumplan con los requisitos.
Las revisiones formales también sirven para otros propósitos: minimizar el riesgo, identificar
incertidumbres, asegurar la integridad técnica y evaluar enfoques de ingeniería alternativos. A diferencia
de las revisiones por pares, las revisiones formales son supervisadas y realizadas por un grupo de
personas externas que utilizan la información acumulada por el equipo del proyecto. Estos extraños
son expertos técnicos que están familiarizados con el producto final y el funcionamiento del proyecto y
la organización del proyecto, pero no están asociados formalmente con la organización del proyecto o
sus contratistas. Dado que una revisión formal puede durar varios días y requerir una preparación y un
escrutinio considerables de los resultados, las tareas y el tiempo necesarios para preparar y realizar la
revisión y obtener las aprobaciones deben incorporarse en el cronograma del proyecto.
Dado que un requisito previo para cada revisión de diseño es la documentación completa del diseño,
la práctica común es convocar una "reunión previa a la revisión" durante la cual el equipo de diseño
proporciona al equipo de revisión una descripción general del diseño propuesto, documentación que
explica las premisas del diseño, la filosofía, los supuestos y cálculos, y especificaciones y planos.
Luego, se le da tiempo al equipo de revisión (generalmente 14 días) para evaluar el diseño y prepararse
para la reunión de revisión formal. El equipo de revisión a veces usa una lista de verificación para
asegurarse de que todo lo importante esté cubierto. En los últimos años, Internet se ha convertido en
un medio eficaz para realizar revisiones de diseño.
12
Reseñas informales de diseño
Aunque las revisiones formales son necesarias, el gerente del proyecto debe alentar
revisiones informales de diseño, que son debates informales entre diseñadores y entre
diseñadores y otras partes interesadas. Las buenas sugerencias pueden originarse en cualquier
lugar, pero depende del diseñador decidir si usarlas o no. Los borradores de diseños, informes y
otros entregables deben compartirse regularmente (e, idealmente, voluntariamente) entre
diseñadores pares y otros para una revisión informal. En una cultura de calidad saludable, los
equipos utilizan la lluvia de ideas para evaluar y editar no solo diseños, sino también informes y
entregables de todo tipo. El principio detrás de la lluvia de ideas es generar libremente tantas
ideas como sea posible y retener cualquier forma de evaluación o crítica hasta que se hayan
generado numerosas ideas. Solo después se evalúan las ideas y se separan las buenas de las
malas.
Ejemplo 9.3: Revisiones formales e internas en

13
el Proyecto Mars Pathfinder
Todos los proyectos importantes de la NASA requieren revisiones formales por parte de "juntas" de revisión externas.
Estas revisiones son cruciales ya que la terminación o continuación de un proyecto puede

depender de los hallazgos de la junta. Para el proyecto Mars Path-finder (ver Ejemplo 11.4,
Capítulo 11) , la junta de revisión estuvo compuesta por 25 consultores y gerentes
experimentados de la NASA y el Jet Propulsion Laboratory (JPL, el sitio responsable de la
mayor parte del trabajo de diseño del Path-finder), ninguno de los cuales se asoció con el
proyecto.
Ver Capítulo 11
La preparación para una revisión formal puede tomar una enorme cantidad de tiempo,
y los gerentes del proyecto Pathfinder estimaron que la preparación para una revisión, la
revisión crítica del diseño, requeriría unas 6 semanas de atención dedicada. Esto desviaría
tiempo de la gestión real del proyecto, lo que, paradójicamente, podría aumentar la
probabilidad de que el proyecto se retrase y no pase la revisión. Para prepararse para la
revisión formal, el director del proyecto, Brian Muirhead, ordenó una revisión interna.
En contraste con las revisiones formales, las revisiones internas por pares abordan una
gama limitada de temas y requieren solo unos pocos días de preparación. El valor de estos
revisiones radica en asegurarse de que todos entiendan las decisiones que se toman, nada
se pasa por alto y el proyecto se mantiene en marcha. Se realizaron más de 100 revisiones
internas durante la fase de desarrollo de 3 años de Pathfinder.
La revisión interna en preparación para la revisión crítica reveló muchos problemas, incluida
la falta de progreso en la definición de las interfaces del sistema, el rápido crecimiento en el
peso del módulo de aterrizaje de Marte y la escasez de buenos ingenieros, y no hizo mucho
para inspirar confianza sobre la capacidad del proyecto para pasar el escrutinio en la revisión
crítica del diseño.
El veredicto de una revisión crítica del diseño es una decisión de todo o nada: el proyecto
pasa o falla. El fracaso inicia una revisión de cancelación que puede resultar en la terminación
del proyecto. Un proyecto como Pathfinder podría cancelarse si excede el presupuesto en tan
solo un 15 por ciento. Más allá de determinar el futuro de un proyecto, las revisiones formales
de diseño tienen otro propósito: darle una patada en los pantalones al proyecto. La preparación
de cada revisión es laboriosa y obliga al equipo del proyecto a tomar decisiones sobre
cuestiones no resueltas. Las revisiones formales se pueden realizar tres o cuatro veces
durante el proyecto.
La junta de revisión crítica del diseño de Pathfinder no estaba contenta con muchos
aspectos del proyecto, pero no recomendó la cancelación del proyecto. Aprobaron el proyecto
pero instruyeron a los gerentes de Pathfinder a ser más críticos con los diseños, centrarse
menos en el rendimiento y más en el costo, y dejar de obsesionarse con las innovaciones
comerciales. Estas recomendaciones luego resultaron útiles y ayudaron a hacer de Pathfinder
uno de los proyectos más exitosos en la historia de la exploración espacial.
Siempre hay más de un medio para un fin, y no se puede esperar que ningún diseñador,
independientemente de su competencia, piense en todos ellos. Los diseñadores maduros aprecian
el proceso de revisión del diseño en términos de la experiencia de trabajo en red, las ideas
innovadoras obtenidas de otros y la reducción de riesgos, pero los diseñadores menos maduros
tienden a sentirse insultados o intimidados por el proceso. Es parte de la naturaleza humana que las
personas se sientan menos entusiasmadas con las ideas de los demás y se resistan a los cambios sugeridos a las p
El proceso de revisión del diseño busca lograr una “calidad adecuada”, un compromiso equilibrado
entre las ideas internas y externas, y abstenerse de criticar o perfeccionar detalles menores.
Auditorias
A diferencia de las revisiones de diseño, que se relacionan específicamente con el diseño de un

producto, las auditorías tienen un alcance amplio e incluyen una variedad de investigaciones y
consultas. El propósito de las auditorías es verificar que los procesos de gestión cumplan con los
procesos, procedimientos y especificaciones prescritos con respecto, por ejemplo, a los
procedimientos de ingeniería de sistemas, sistemas de gestión de configuración, sistemas de
control de inventario y almacenamiento y procedimientos de seguridad. También se utilizan para
verificar que los procesos técnicos , como la soldadura, cumplan con los procedimientos prescritos
y para determinar el estado del proyecto en función de un examen cuidadoso de ciertos aspectos
críticos del trabajo. Cualquier parte interesada senior, como el cliente, el administrador del programa
o el ejecutivo, puede solicitar una auditoría. Al igual que las revisiones formales de diseño, las
auditorías son relativamente formales y normalmente involucran equipos multifuncionales; a
diferencia de las revisiones de diseño donde pueden originarse ideas innovadoras, se enfocan
estrictamente en verificar que los procesos se implementen según lo requerido. El auditor puede
ser un miembro del personal interno o una parte externa, cualquiera que se considere creíble, justo, honesto e imp
La preparación de la auditoría comienza cuando el auditor y la parte interesada que solicitó la
auditoría acuerdan el alcance y el cronograma de la auditoría, y las responsabilidades del equipo
de auditoría. El auditor se prepara para la auditoría compilando listas de verificación y, a veces,
asistiendo a una sesión informativa para aprender sobre el proyecto. Una investigación de auditoría
exhaustiva típica tomará una o dos semanas. Dentro de unos días después de la auditoría, el
auditor prepara un informe que describe las no conformidades encontradas, la importancia de las
no conformidades, las circunstancias bajo las cuales se encontraron y las causas (si se conocen o
pueden determinarse), y sugerencias para acciones correctivas. Si bien el enfoque está en
descubrir las no conformidades, el informe también puede señalar cualquier hallazgo encomiable.
Ejemplo 9.4: Andamios inseguros auditados
El oficial de seguridad de una empresa constructora solicitó una auditoría de seguridad de

los andamios en un sitio de trabajo. Se contrató a un consultor externo para realizar la
auditoría y se utilizó como requisito un estándar del Departamento de Trabajo de los Estados Unidos.
El informe de auditoría, producido 10 días después del inicio de la auditoría, indicó que todos
excepto uno de los procesos seguidos en el diseño y construcción del andamio cumplió
con los requisitos. Sin embargo, el andamio no pasó la auditoría porque no se pudo
producir evidencia escrita sobre la base del andamio para demostrar que un ingeniero
registrado/licenciado lo había encontrado sólido, rígido y capaz de soportar la carga
máxima prevista sin asentamiento o desplazamiento. El trabajo en el sitio se detuvo en
espera de una investigación de ingeniería sobre la base. Posteriormente, la gerencia
ejecutiva solicitó informes de ingeniería sobre la base del andamio de todos los demás
sitios.
Clasificación de Características
Un elemento final o entregable de un proyecto se "especifica" o define en términos de una serie

de características o atributos, incluidas las propiedades funcionales, geométricas, químicas o
físicas. Las características, a menudo especificadas cuantitativamente, generalmente incluyen
tolerancias de aceptabilidad. En un sistema complejo se definen numerosas características en
dibujos y otros documentos. El principio de Pareto (discutido más adelante) establece que la
gran mayoría de los problemas son causados por relativamente pocas fuentes. Por lo tanto, la
forma rentable de abordar el aseguramiento de la calidad es prestar atención a las pocas
características que más impactan en los problemas o fallas de calidad.
Esto no quiere decir que se ignoren otras características, sino que los recursos limitados para
la inspección y las pruebas deben dirigirse primero a aquellos elementos clasificados como
más cruciales o problemáticos.
Las características generalmente se clasifican en cuatro categorías: críticas, mayores,
menores e incidentales (alternativamente, críticas, mayores A, mayores B y menores). La
clasificación crítica se reserva para las características en las que una no conformidad plantearía
riesgos de seguridad o provocaría una falla del sistema. Los planes de calidad a menudo
especifican que los artículos con características críticas estén sujetos a una inspección del 100
por ciento. La clasificación principal es para características en las que la no conformidad
causaría la pérdida de una función principal del entregable. La clasificación menor es para
características en las que la no conformidad conduciría a un pequeño deterioro de la función
oa inconvenientes con la capacidad de fabricación o servicio.
La no conformidad de las características clasificadas como incidentales tendría un efecto
mínimo.
Las clasificaciones son asignadas por los diseñadores de cada sistema en colaboración
con los diseñadores del siguiente sistema de nivel superior y los sistemas de interfaz, y el
personal de fabricación o construcción. Juntos analizan las características de diseño con
respecto a la seguridad y otros requisitos y los clasifican utilizando un conjunto de reglas
básicas.
La clasificación de características no debe confundirse con la clasificación de defectos.
En una estructura soldada, por ejemplo, las características especificadas podrían incluir la
"ausencia de grietas o impurezas" en el metal de soldadura. Una fisura (defecto que podría
causar una falla catastrófica) se clasificaría como “crítica”, mientras que una pequeña
cantidad de impureza en la soldadura (defecto que no afectaría la integridad estructural)
se clasificaría como “menor”.
Las clasificaciones de características a veces se enumeran en un documento separado,
aunque es más práctico mostrarlas directamente en los dibujos y otras especificaciones
utilizando símbolos como "C" para crítica, "Ma" para mayor, "Mi" para menor, etc. La
ausencia de un símbolo normalmente indica la prioridad más baja.
Solo un porcentaje muy pequeño de las características debe clasificarse como crítico. Un
gran porcentaje clasificado como crítico podría ser señal de un mal diseño: cuando todo es
crítico, ¡nada en particular es crítico!
La clasificación de las características sirve como base para las decisiones sobre
modificaciones, exenciones y desviaciones en todos los niveles de un sistema. Por ejemplo,
la clasificación de características para un sistema de nivel superior proporciona orientación
a los diseñadores de los subsistemas y componentes de nivel inferior del sistema. Clasificar
el rendimiento de frenado de un automóvil como crítico (p. ej., un automóvil que viaja a 25
millas por hora debe poder detenerse a 40 pies sobre pavimento seco) indica a los
diseñadores del sistema de frenado que también clasifiquen los componentes del freno como críticos.
El análisis de modo y efecto de falla (FMEA) a veces juega un papel en el proceso de
clasificación.
Modo de Falla y Análisis de Efectos
Un sistema puede fallar como resultado de una variedad de condiciones, como

cortocircuito, agrietamiento, colapso o fusión de sus componentes, o pasos y procedimientos
inadecuados, faltantes o incorrectos en su diseño, producción u operación.
FMEA es una técnica para determinar las condiciones (modos) bajo las cuales un sistema podría fallar
y qué efectos tendrían las fallas identificadas en el rendimiento, la seguridad y el medio ambiente del
sistema.
El procedimiento FMEA se usa normalmente durante las primeras etapas del desarrollo del sistema
e incluye los siguientes pasos:
1. Enumere los componentes relevantes (o artículos/ funciones) del sistema.

2. Identificar todas las formas posibles en que el componente o sistema puede fallar (modos de
falla). Esto lo hace mejor un equipo que hace una lluvia de ideas sobre los modos de falla.
Para cada modo, también se enumeran las causas y condiciones bajo las cuales es probable
que ocurran.
3. Asigne una probabilidad de ocurrencia a cada modo de falla.
4. Describir y evaluar los efectos probables (o impactos) de cada modo de falla en el desempeño
y seguridad del sistema, y en el medio ambiente.
5. Evaluar la severidad o gravedad de los efectos.
6. Calcule la criticidad de cada modo de falla. La criticidad es una función tanto de la probabilidad
de falla como de la gravedad de los efectos.
7. Preparar un plan para eludir el modo de falla, mitigar los efectos de la falla o responder en caso
de que ocurra la falla. Cuando es necesaria la conformidad con una característica específica
para evitar fallas, la característica se clasifica como crítica.
La Tabla 9.1 ilustra: En las columnas "Sev" (severidad), "Prob" (probabilidad) y "Det" (detectabilidad:
¿sería difícil detectar la falla?) cada modo de falla se califica del 1 al 10. RPN (prioridad de riesgo
número) es la criticidad del modo de falla, calculado como:
RPN = Sev × Prob × Det
Luego, los elementos se priorizan por RPN con el RPN más alto primero.
Aunque un fallo por sí solo puede no ser crítico, combinado con otros fallos puede ser muy grave. El
desastre de Chernobyl es un ejemplo en el que una cadena de errores (cada uno de los cuales no es
muy grave) condujo a una falla catastrófica: la fusión de un reactor nuclear. Por lo tanto, FMEA debe
considerar combinaciones de modos de falla, así como modos de falla individuales. Además de su uso
en análisis de diseño e ingeniería, FMEA también se puede usar para identificar problemas que afectan
los costos y cronogramas del proyecto.
y como una herramienta en la gestión de riesgos del proyecto, descrita en el Capítulo 10.
Ver Capítulo 10
Modelado y Prototipado
Los diseñadores utilizan varios tipos de modelos (maquetas físicas a gran escala, modelos a escala, modelos
matemáticos, modelos de simulación por computadora, tableros y prototipos a gran escala) para aprender
cómo se verá y funcionará un producto, sistema o subsistema final. Los modelos y prototipos también se
utilizan en marketing para permitir que los clientes “imaginen” el producto o sistema. Una maqueta de madera
o plástico a escala real de la cabina de un camión o la cabina de un avión, por ejemplo, ayuda al productor a
vender el producto y obtener sugerencias o críticas al respecto.
En los proyectos de desarrollo de productos, los modelos ayudan a reducir el riesgo de incumplimiento de
los requisitos técnicos. La Tabla 9.2 muestra los tipos de modelos construidos y probados en las fases del
proyecto y los tipos de riesgos que eliminan. Los proyectos para el desarrollo de grandes plantas de
procesamiento a menudo usan modelos de manera similar (Cuadro 9.3); los modelos para este tipo de
proyectos suelen comenzar como equipos de laboratorio, pero crecen en sofisticación y capacidad para
permitir una operación piloto que conduce a una planta de demostración que reproduce fielmente la instalación
propuesta.
El tipo de modelo utilizado depende de la información necesaria frente al gasto de crear y utilizar el modelo.
Para un producto pequeño que comprende solo unos pocos componentes, construir y probar un modelo a
gran escala que se parezca mucho al producto final suele ser rentable; para un sistema grande y complejo,
por lo general no lo es y los modelos de simulación por computadora y las maquetas físicas son mejores.
Ejemplo 9.5: Modelado de la forma y el ajuste de los

14
componentes del Boeing 777
Uno de los problemas más generalizados en el desarrollo de aviones grandes es la alineación de un

gran número de piezas y componentes para que no se produzcan interferencias ni espacios entre ellos
durante el montaje. A mediados de la década de 1980 Boeing
invertido en tecnología tridimensional CAD/CAM (diseño asistido por computadora/

fabricación asistida por computadora) que permitiría a los diseñadores ver los componentes
como imágenes sólidas y simular su ensamblaje en subsistemas y sistemas en pantallas de
computadora. Para 1989, Boeing había llegado a la conclusión de que el "preensamblado
digital" de un avión podría reducir significativamente el tiempo y el costo del retrabajo que
Tabla 9.1 Tabla FMEA
suele acompañar a la introducción de un nuevo avión en el mercado. En 1990, Boeing

comenzó a involucrar a clientes, ingenieros de diseño, fabricantes de herramientas,
representantes de fabricación y proveedores en el proceso de diseño de ingeniería
concurrente de su programa 777 twinjet (consulte el Ejemplo 4.5, Capítulo 4). La geometría
física de los componentes del avión se determinó utilizando tecnología CAD/CAM en lugar
de maquetas físicas, que consumen mucho tiempo y son costosas de construir. Esto redujo
los cambios y reelaboraciones en el programa 777 a un 50 por ciento menos que los
programas anteriores.
Ver Capítulo 4
Tabla 9.2 Fases para el Desarrollo de Productos
Objetivos Relacionados
Proyecto
Fase Modelo Construido y Probado para la Eliminación de Riesgos eliminados

Riesgos
Modelos de desarrollo exploratorio

(XDM) (o
Modelos de placa de prueba; Prueba de que el nuevo El riesgo de que el
Concepto dichos modelos podrían concepto sería factible concepto no sea

construirse para todo el sistema factible
o para subsistemas
específicos de alto riesgo
Prueba de que el El riesgo de que el
producto funcione de acuerdo

suscon
especificaciones
el sistema y
e interfaces con interfaz bien otros
con otros
sistemas
sistemas
(forma,
Desarrollo Avanzado
Validación no sería adecuado y función) aceptable
Modelos (ADM)
Ingeniería
Modelos de desarrollo Prueba de confiabilidad, El riesgo de una
Desarrollo (EDM) fabricado a partir de disponibilidad y disponibilidad

los materiales finales previstos mantenibilidad operativa deficiente
Prueba de que el
producto podría El riesgo de

fabricarse de
Modelos de preproducción problemas
Rampa arriba manera confiable
(PPM) imprevistos en
en la planta de
la fabricación
producción y podría
implementarse de manera efectiva
Tabla 9.3 Fases para el Desarrollo de Plantas de Proceso
Fase del proyecto Objetivo
Experimentos
Para probar el concepto básico
de laboratorio
Planta piloto Para aprender cómo funciona el proceso cuando se amplía
Proporcionar insumos para el diseño de la planta final.

Planta de demostración Proporcionar una planta a gran escala que demuestre a los clientes
potenciales la viabilidad económica, así como los aspectos operativos.
Inspección y prueba del sistema
Se realizan una variedad de inspecciones y pruebas para garantizar que los componentes y el
sistema del artículo final cumplan con los requisitos. A menudo, las pruebas se realizan utilizando
modelos y prototipos, especialmente en el desarrollo de nuevos productos y sistemas.
Las pruebas se dividen en tres categorías: pruebas realizadas por el contratista para asegurarse
de que el diseño del sistema (1) cumple con los requisitos del sistema y (2) el productor o
constructor lo sigue, y (3) pruebas realizadas por el cliente y otros para garantizar el sistema
15
cumple con los requisitos del usuario y otros acuerdos contractuales.
La primera categoría de pruebas tiene como objetivo verificar el diseño. Si estas pruebas
revelan un desempeño inadecuado debido a un diseño defectuoso o deficiente, entonces se debe
repetir la etapa de diseño; si revelan problemas debido a requisitos defectuosos, entonces también
se debe repetir la etapa de definición de requisitos. Dado que la repetición de pasos es costosa y
requiere mucho tiempo, las pruebas deben diseñarse para detectar los problemas lo antes posible.
Por supuesto, incluso si el diseño es perfecto, si los constructores reducen los materiales y
procedimientos o no se ajustan al diseño, el sistema será inadecuado; por lo tanto, la segunda
categoría de pruebas es necesaria para verificar que los constructores estén siguiendo
correctamente el diseño y que los materiales y la mano de obra cumplan con las especificaciones.
La última categoría de pruebas consiste en pruebas, revisiones y auditorías realizadas por el
cliente para garantizar que se hayan cumplido los requisitos del usuario y que la documentación
de la prueba sea completa y precisa. Estas pruebas, realizadas por el personal usuario que
operará el sistema, pueden revelar deficiencias de diseño que los diseñadores e ingenieros del
proyecto pasaron por alto.
Las pruebas deben seguir la secuencia de los componentes primero, luego los subsistemas y
luego todo el sistema por último; esto minimizará la necesidad de rediseñar un sistema completo
debido a componentes defectuosos. Cada parte se prueba para garantizar que funcione
individualmente; los componentes formados a partir de las partes se prueban para garantizar que
cada componente funcione; Los subsistemas formados a partir de los componentes se prueban para garantizar
cada subsistema realiza; finalmente, se prueba el sistema completo formado por todos los
subsistemas para garantizar que cumple con los requisitos de rendimiento del usuario.
Las pruebas se realizan contra los objetivos del sistema desarrollados anteriormente, las
especificaciones de los sistemas y los requisitos normales del usuario. A veces, además, se
realizan por encima de las especificaciones para condiciones normales para determinar la capacidad
real o el punto de falla del sistema. En las pruebas de estrés, se aplica una carga de prueba cada
vez más severa al sistema para determinar su capacidad para manejar condiciones más pesadas
de lo probable, a veces hasta que el sistema falla. En las pruebas de fatiga, el sistema se somete
a una carga creciente o ciclos repetidos hasta que falla; esto se hace para determinar la capacidad
última del sistema. Los contratos para proyectos de desarrollo a veces no solo especifican los
requisitos de diseño y los criterios de desempeño, sino también los tipos de pruebas para
verificarlos. A menudo, los criterios y condiciones para las pruebas se especifican en el plan de
calidad.
Inspección de documentación
Los proyectos emplean una variedad de métodos de prueba e inspección para eliminar los defectos
de los documentos y el código. A continuación se ilustra un enfoque utilizado en proyectos de
ingeniería de diseño y desarrollo de software.
Ejemplo 9.6: Proceso de inspección del equipo

dieciséis
El propósito del proceso de inspección del equipo es mejorar la calidad, acortar el tiempo de
desarrollo y reducir los costos al evitar defectos. El equipo de desarrollo se reúne en grupo
para revisar los documentos de requisitos, los documentos de diseño y el código de software.
A los miembros se les asignan roles durante la reunión:
• Moderador: supervisa el procedimiento de inspección y registra los defectos

detectados en el documento o código.
• Lector: lee el documento o código, línea por línea. •
Inspector(es): persona que tiene más conocimiento sobre el documento o código, tiene
la mayor cantidad de información y es más capaz de detectar errores.
• Autor: persona que creó el documento o código.
El autor del documento o código inicia el proceso programando una reunión de

inspección y proporcionando a cada miembro del equipo una copia del documento o
código y cualquier documentación de respaldo al menos 2 días antes de la reunión.
Cada reunión de inspección dura aproximadamente 2 horas, durante las cuales un

equipo promedio puede inspeccionar entre 10 y 15 páginas de texto o 400 líneas de
código. Los defectos se documentan y el equipo decide si se debe volver a reunir una
vez corregidos los defectos. El proceso se considera completo cuando el inspector firma
las correcciones y se aprueba el material.
Para reducir las posibilidades de que otros equipos de proyecto cometan errores
similares, los errores y defectos descubiertos se ingresan en una base de datos para
referencia común.
9.4 Técnicas para el Control de Calidad
El control de calidad implica realizar las tareas definidas en el plan de gestión de calidad y
tomar las medidas correctivas necesarias para asegurar la calidad. Se trata de una variedad
de técnicas, como se analiza a continuación.
Inspección y Pruebas de Aceptación del Producto Final
Mientras que las pruebas de modelos y prototipos brindan información para su uso en el
diseño y desarrollo, las pruebas de aceptación del producto final u otros entregables verifican
que el producto cumple con las especificaciones. Las características clasificadas como
críticas siempre se inspeccionan, pero las clasificadas como menores o incidentales no. En
la producción de automóviles, por ejemplo, se prueba el rendimiento de frenado y dirección
de cada vehículo. Para los productos producidos en masa, algunas unidades pueden estar
sujetas a pruebas destructivas (es decir, probadas hasta que se rompen). Los productos que
se producen de forma única o en lotes pequeños se someten a pruebas no destructivas.
Aunque probar los resultados finales de un proceso de producción no cae dentro del
ámbito de la gestión de la calidad del proyecto per se, cualquier proyecto de desarrollo en el
que el producto resultante se produzca en masa incluiría la especificación de los
procedimientos de prueba y otros procesos de garantía de calidad que se utilizarán en
produciendo ese producto. Los diseñadores de productos que están íntimamente
familiarizados con las características clave del producto y sus componentes son los más
adecuados para especificar las formas de verificar la calidad del producto y sus componentes
después de que comienza la producción. Para los artículos producidos en gran volumen, el
muestreo es una forma común de reducir el costo de la inspección: según los resultados de
probar algunas muestras, la calidad de todo el lote o proceso puede inferirse estadísticamente.
Obviamente, el muestreo es la única opción cuando la prueba destruye el producto.
Herramientas de Control de Calidad

En la década de 1980, Kaoru Ishikawa de la Universidad de Tokio definió las herramientas básicas
del control de calidad. 17 Las herramientas tienen como objetivo identificar las fuentes de defectos
y no conformidades en productos y procesos, pero son aplicables para identificar fuentes y resolver
problemas de todo tipo, incluidos los problemas asociados con los riesgos. Desarrollado en un
entorno de producción (Kawasaki Steel Works), el
18
No obstante, las herramientas discutidas a continuación son aplicables a los proyectos.
Tabla de ejecutar
Un gráfico de ejecución es un gráfico de los resultados observados trazados frente al tiempo para
revelar posibles tendencias o anomalías. El gráfico del índice de desempeño del cronograma
versus el índice de desempeño del costo ilustrado en la figura 11.12 es una forma de gráfico de
ejecución que rastrea el desempeño del proyecto y muestra si está mejorando o empeorando en
términos de cronograma y costo.
Tabla de control
Los gráficos de control se utilizan ampliamente para rastrear y controlar procesos repetitivos y
detectar cambios en los procesos. Para proyectos que incluyan el desarrollo de procesos
productivos, un entregable sería especificar las tablas pertinentes para el control de calidad del
proceso. Los lectores involucrados en proyectos destinados a la entrega de sistemas operativos
repetitivos deben consultar libros sobre técnicas de control estadístico como el Manual de control
de calidad de Juran. 19
Diagrama de Pareto
Vilfredo Pareto, un economista italiano del siglo XIX, formuló la “Ley de Pareto” de distribución del
ingreso, que establece que la distribución del ingreso y la riqueza en un país sigue un patrón
regular: el 80 por ciento de la riqueza es propiedad del 20 por ciento de la población. Desde
entonces, se ha descubierto que este principio, denominado "regla del 80/20", se aplica en principio
a una amplia variedad de situaciones, incluidas las relacionadas con la calidad. Consultor de
calidad Dr. Joseph Juran a fines de la década de 1940
postuló que la gran mayoría de los defectos resultan de relativamente pocas causas; por lo
tanto, por razones económicas, tiene sentido identificar las pocas causas vitales de la
mayoría de los defectos y dirigir el mayor esfuerzo para eliminarlos.
Figura 9.3 Diagrama de Pareto.
La figura 9.3 es un diagrama de Pareto: el histograma en la parte inferior del diagrama

muestra el número de problemas frente a las fuentes de los problemas; la línea diagonal
que cruza la figura es el efecto acumulativo de los problemas (correspondiente a la escala
de la derecha). Como se muestra, el primer tipo de problema representa el 43 por ciento de
todos los problemas; el primero y el segundo combinados representan el 70 por ciento. Por
lo tanto, resolver solo los dos primeros tipos de problemas eliminaría el 70 por ciento de los
problemas.
Diagrama de causa y efecto
Los problemas a menudo se abordan mejor a través de la experiencia colectiva de los equipos de
proyecto. Los miembros del equipo intercambian ideas sobre las causas de un problema, y estas causas
se registran en un diagrama de causa y efecto (CE) (también llamado diagrama de espina de pescado
o diagrama de Ishikawa ), que es un esquema para organizar las causas de un efecto específico en una
manera lógica. La Figura 9.4 muestra un diagrama CE para determinar por qué un sistema de control
funciona mal. A medida que el equipo genera ideas sobre las causas, cada causa se asigna a una rama
específica (p. ej., "procedimientos de montaje" a la rama Calidad de montaje). Los diagramas CE y la
lluvia de ideas se pueden usar de dos maneras: (1) dado un resultado o problema específico o potencial
(efecto), para identificar las posibles causas, y (2) dada una causa, para identificar los resultados
(efectos) que podrían surgir . .
Identificar las causas es un primer paso obvio para resolver los problemas. Los diagramas CE también
se utilizan en el análisis de riesgos, y se da un ejemplo en el Capítulo 10.
Ver Capítulo 10
Otras Herramientas para el Aseguramiento y Control de Calidad
Muchos métodos de planificación y control descritos en otras partes de este libro también se aplican al
control y la garantía de calidad. Por ejemplo, gran parte del esfuerzo de garantía de calidad en un
proyecto de diseño de productos está dirigido a mantener al equipo del proyecto enfocado en los
requisitos del cliente y evitar la distorsión o mala interpretación de esos requisitos a medida que el
proyecto avanza entre etapas, departamentos y personas.
El despliegue de la función de calidad (QFD), discutido en el Capítulo 4, sirve precisamente para ese
propósito. La Medición del rendimiento técnico (TPM), que se analiza en el Capítulo 11, también puede
considerarse una herramienta para el aseguramiento de la calidad.
Las listas de verificación, para preparar planes y realizar inspecciones, pruebas y revisiones de
diseño, y FMEA también son herramientas de calidad; ayudan a evitar que se pasen por alto cuestiones
importantes. Por supuesto, una desventaja de las listas de verificación es que las personas tienden a
confiar demasiado en ellos e ignorar las cosas que no están en la lista. Por lo tanto, el último elemento de
cada lista de verificación debe ser "¡Ahora, enumere todas las cosas importantes posibles que aún no están
en esta lista y verifíquelas también!"
Figura 9.4 Diagrama de causa y efecto (espina de pescado o Ishikawa).

9.5 Resumen
Los cronogramas, presupuestos y gestión de la calidad del proyecto abordan las tres dimensiones de
los objetivos del proyecto: terminar a tiempo y dentro del presupuesto, y satisfacer los requisitos.
La calidad del proyecto da cuenta del cumplimiento de un artículo final con las especificaciones y la
idoneidad para el propósito y las expectativas del cliente. No implica necesariamente el grado más
alto, la mayoría de las características del producto o incluso cero defectos; lo que implica es lo que se
considere "mejor" en términos de las expectativas del cliente sobre el uso previsto del artículo final.
La gestión de la calidad incluye tres procesos: planificación de la calidad, garantía de la calidad y

control de la calidad. La planificación de la calidad es parte de la planificación del proyecto e implica
el establecimiento de estándares y especificaciones que deben cumplirse, la identificación de
actividades relacionadas con la calidad en el proyecto y la programación y presupuestación de estas actividades.
El aseguramiento de la calidad consiste en realizar las actividades de calidad planificadas y garantizar
que el proyecto utilice los recursos necesarios para cumplir con los requisitos.
El control de calidad es el proceso continuo de monitorear y evaluar el trabajo para garantizar la
calidad y tomar medidas correctivas. Es una parte del control del proyecto e incluye inspección, prueba
y resolución de problemas ad hoc.
La gestión de la calidad del proyecto se ha beneficiado de las filosofías de calidad de TQM y Six
Sigma, las cuales enfatizan la mejora continua.
La mejora continua en el entorno de un proyecto está respaldada por el proceso de control de calidad,
las revisiones posteriores al proyecto y las lecciones aprendidas documentadas. También se ha
beneficiado de los métodos estadísticos y las herramientas básicas de resolución de problemas que
se utilizan para la fabricación y la producción. Más allá de estos, sin embargo, la gestión de la calidad
del proyecto se beneficia de las técnicas aplicables a todos los esfuerzos técnicos y de ingeniería,
incluidas las revisiones de diseño, la gestión de la configuración, la clasificación de características,
FMEA, así como la experimentación con modelos y prototipos.
Muchas de las técnicas se aplican también a la gestión de riesgos del proyecto, el tema del próximo
capítulo.
1. Describa su comprensión de "calidad".

2. Un Rolls Royce se considera un vehículo de alta calidad. ¿Es esto siempre cierto?
Considere diferentes usuarios y usos.
3. ¿En qué se diferencia el cumplimiento de las especificaciones de la satisfacción

requisitos?
4. ¿Cuál es la diferencia entre satisfacer los requisitos y la idoneidad para el propósito?
Explique.
5. Explique la diferencia entre calidad y grado.
6. ¿En qué se diferencia el rol del gerente de calidad (un gerente funcional) con respecto
a la planificación de la calidad del del gerente de proyecto?
7. El horario que indica conferencias, exámenes, etc. para un curso universitario puede
considerarse un IC. Explique por qué debe haber una sola copia maestra.
¿Cómo se aplica el mismo principio a un dibujo de ingeniería?
8. Indique para cada uno de los siguientes si desea solicitar una modificación, una
desviación o una exención:
(a) El proveedor de filtros de aceite para un fabricante de automóviles dice que

planea terminar la producción de un filtro para usar en un automóvil que está
en desarrollo.
(b) Un inspector descubrió una torcedura en el acero de refuerzo. Una ingeniera
estructural dice que, si bien el acero no cumplirá con sus dibujos, la torcedura
no tendría un efecto negativo en la resistencia del acero.
(c) Un barco dañado tiene que ser reparado. El revestimiento protector contra
la corrosión especificado no está disponible, aunque hay disponible un
revestimiento más costoso (pero aceptable).
9. Describa las diferencias entre revisiones de diseño y auditorías.

10. Discutir cómo las revisiones de diseño contribuyen al enfoque de concurrente
ingeniería.
11. Explique cómo una tolerancia estrecha en un dibujo de fabricación difiere de la clasificación de la
característica como crítica o importante.
12. Explique cómo la clasificación de características difiere de la clasificación de
defectos
13. Discutir la relación entre la gestión de la calidad del proyecto y
gestión de riesgos del proyecto.
14. Describa cómo FMEA en este capítulo se parece al enfoque de gestión de riesgos descrito en el
Capítulo 10.
15. Realice un análisis FMEA en un hervidor eléctrico con cable y enchufe.
16. ¿En qué se diferencian las pruebas de aceptación del cliente de las pruebas utilizadas para
obtener información de diseño?
17. ¿Cómo esperaría que cambiaran las barras de un diagrama de Pareto como resultado de un
programa de mejora?
18. ¿En qué difiere la información del eje x de un diagrama de Pareto que se usa en el control de
proyectos de la información del eje x de un diagrama de Pareto que se usa para analizar
defectos en un entorno de producción en masa?
19. Describa las ventajas y desventajas de los diagramas CE.
Ver Capítulo 10
1. ¿De qué manera podría descubrir las expectativas del cliente que no se han articulado
explícitamente?
2. Describir el plan de calidad para el proyecto de investigación. Si no hubo ninguno, desarrolle
uno. Incluya todos los aspectos discutidos en la sección sobre el Plan de Gestión de la
Calidad del Proyecto que sean relevantes para el proyecto específico.
3. Discutir cómo se integra (se integraría) el plan de calidad con el cronograma, el presupuesto,
el plan de gestión de riesgos y, si corresponde, con el plan de adquisiciones.
4. Identificar las partidas del presupuesto del proyecto que apuntan a reducir el costo de
fallas
5. Dibuje un diagrama CE y un diagrama de Pareto para ilustrar un problema de gestión de

proyectos que haya experimentado en su proyecto de estudio.
6. Compile una lista de "lecciones aprendidas" para el proyecto e indique cómo estas lecciones
podrían contribuir a futuros proyectos más exitosos.
Caso 9.1 Colapso del panel del techo en el Proyecto

Big Dig
(Para obtener más información sobre el Proyecto Big Dig: Proyecto de Túnel/Arteria Central
de Boston, consulte el Capítulo 15, el Ejemplo 15.4 y el Caso 15.3).
Ver Capítulo 15
Boston, 11 de julio de 2006: cuatro paneles de hormigón que pesaban unas tres toneladas
cada uno cayeron del techo de un túnel Big Dig y aplastaron hasta la muerte a una mujer en
un automóvil. El accidente ocurrió en una sección de 200 pies que conecta la autopista de
peaje de Massachusetts con el túnel Ted Williams. dijo el moderno

Continental Company, el contratista de esa sección del proyecto, “estamos seguros de que nuestro
trabajo cumplió totalmente con los planos y especificaciones provistos por el Proyecto del Túnel de la
Arteria Central. Además, la obra fue inspeccionada y aprobada por el jefe de obra.”
20
Los paneles, instalados en 1999, se sujetan con bandejas de metal aseguradas al techo del túnel
con epoxi y pernos. El sistema de pernos de epoxi es un método probado y verdadero: se perforan
agujeros en el techo de concreto, se limpian y se rellenan con epoxi de alta resistencia; se atornilla un
perno en el orificio; a medida que el epoxi cura, se adhiere al perno. “Esa técnica se usa mucho”, dijo
un ingeniero
21 Para trabajos como este,
profesor del Instituto Tecnológico de Massachusetts. dijo, se agregan
"redundancias" de seguridad, es decir, se usan suficientes anclajes de epoxi y pernos para sostener
los paneles del techo, incluso si algunos fallan. Pero en el túnel conector, sostuvo, se usaron muy
pocas anclas. “No tenían suficiente para llevar la carga. No había lugar para el error”. Agregó, sin
embargo, que la evidencia era preliminar y tal conclusión sería prematura.
Algunos de los pernos en los restos del techo tenían muy poco epoxi y tres de ellos no tenían
ninguno. La investigación del fiscal general del estado, Thomas Reilly, se centra en si el epoxi falló o
si los trabajadores de la construcción que instalaron los pernos hicieron un mal uso u omitieron el
epoxi. Un accidente causado por una instalación incorrecta o errores al mezclar el epoxi, dijo,
implicaría al diseño y los diseñadores del túnel. (El epoxi requiere una mezcla en el lugar antes de su
uso).
Agregó que algunos documentos reflejaban una “disputa sustancial” entre los ingenieros sobre la
idoneidad del sistema de anclaje para soportar el peso de los paneles del techo.
Siete años antes del accidente, el oficial de seguridad John Keaveney escribió un memorando a
uno de sus superiores en el contratista Modern Continental Construction Co. diciendo que no podía
“comprender cómo esta estructura puede resistir el paso del tiempo”. 22 Dijo que sus superiores en
Modern Continental y representantes (B/PB)
del gerente de proyecto
le aseguraron quedeelBig Dig Bechtel/Parsons
sistema Brinckerhoff
había sido probado y
probado. Keaveney le dijo al Boston Globe que comenzó a preocuparse por los paneles del techo
después de que una clase de tercer grado recorriera Big Dig en 1999. Mientras mostraba a la clase
algunos paneles de techo de concreto y señalaba los pernos del techo, una niña preguntó:
¿Esas cosas sostienen el concreto? “Dije, 'Sí, resistirán', pero luego lo pensé”.
Algunos han argumentado que la investigación debería analizar el diseño del túnel: ¿por qué los
paneles de concreto eran tan pesados, con un peso de 2½ a 3 toneladas cada uno? ¿Por qué
estaban allí en absoluto? ¿Y por qué la falla de una sola percha de acero hizo que se derrumbaran
entre seis y diez de los paneles? Los informes de testigos presenciales indican que el accidente
comenzó con un fuerte chasquido cuando una percha de acero cedió, lo que desencadenó una
reacción en cadena que provocó que otras perchas que sostenían una barra de acero de 40 pies
fallaran y enviaran 12 toneladas de concreto a romperse debajo. ¿Las barras estaban mal diseñadas
para manejar el peso?
Los investigadores también están analizando si es posible que se haya utilizado el epoxi
incorrecto.rápido
23 Las facturas
para de 1999
asegurar muestran
los pernos que seen
del techo usó al menos
lugar unaestándar
del epoxi caja de epoxi de secado
especificado por los
diseñadores; este epoxi tiene un 25 por ciento menos de peso que el epoxi estándar.
24
Las cuestiones adicionales planteadas durante la investigación incluyen las siguientes:
• Cambios de diseño que resultaron en el uso de paneles de techo de hormigón más pesados
en el túnel conector que en el túnel Ted Williams.
• Falta de soportes de acero en tramos del techo del túnel conector a los que se podrían
haber conectado los pernos que sujetaban los paneles de hormigón. • Posible daño en el
túnel causado por vibraciones de explosión de la construcción cercana de una torre de
oficinas. • Uso de brocas con punta de diamante, en lugar de brocas de carburo, al taladrar
orificios para los pernos (es posible que el epoxi no se mantenga tan bien en orificios más
lisos perforados con brocas de diamante).
• Impacto del clima frío durante la instalación del sistema de pernos epóxicos.
B/PB, el contratista de gestión del proyecto, dijo en un comunicado: "La determinación de las
causas de esta falla específica requerirá un análisis forense exhaustivo del diseño, los métodos, los
materiales, los procedimientos y la documentación". A medida que los investigadores analizan la
historia del proyecto de $14 mil millones, reaparecen las críticas de que Massachusetts carecía de
una supervisión adecuada de los contratistas privados. B/PB participó tanto en el diseño como en
los esfuerzos de construcción, un acuerdo que, según algunos, puede haber comprometido
vigilancia. “Nadie revisaba las fichas”, dijo un representante de los Estados Unidos.
Escribió un bloguero: “No me gustaría ser el ingeniero registrado cuya firma está en el
diseño. Será su culpa si los materiales y la mano de obra no cumplen con las
especificaciones. Pero quién sabe si es culpa suya. Esto es un gran lío y todos ellos,
ingenieros,
los gerentes, inspectores y evaluadores deben ser investigados”.25
Preguntas
1. En retrospectiva 20-20, dibuje un diagrama CE (espina de pescado,

Ishikawa) para ilustrar posibles causas y efectos. Incluya las posibles
causas mencionadas en el caso. El diagrama debería haber sido
desarrollado antes de la construcción, por lo tanto, también indique otros
posibles modos de falla y otras causas que se le ocurran. ¿Cómo sería
valioso el diagrama (desarrollado después del accidente) durante el litigio?
2. Enumere las características que deberían haber sido clasificadas como críticas.
3. Proponer pautas para un proceso que asegure que el epoxi proporcione

suficiente adherencia al techo de concreto.
4. Explique el papel que debería haber jugado la gestión de la configuración
en la prevención del accidente.
5. ¿Qué papel podría desempeñar el modelado/prototipado, las pruebas de laboratorio, las listas de verificación,
y la formación han jugado?

6. Explique cómo alguien dentro de B/PB sería responsable
independientemente de los resultados de una investigación forense. ¿B/
PB estaría libre de culpa si un subcontratista fuera declarado culpable?
7. ¿Cuáles habrían sido las implicaciones si el ingeniero que firmó un diseño
específico fuera un ingeniero en formación en lugar de un ingeniero
registrado?
8. Comente la relación entre la gestión de la calidad del proyecto y la gestión
del riesgo del proyecto. ¿Cómo podría la gestión de riesgos haber
evitado el accidente? ¿Cómo se relaciona la gestión de calidad del
proyecto con la gestión de costos del proyecto?
9. Comentar el aporte que podría tener la inspección y auditorías
jugó.
Caso 9.2 Copa Mundial de la FIFA Sudáfrica 2010™26
Figura 9.5 Estadio de Ciudad del Cabo utilizado para la Copa Mundial de la FIFA 2010.
Fuente: iStock.
Diez ciudades sudafricanas fueron seleccionadas para albergar los partidos de fútbol
de la Copa Mundial de la FIFA 2010. En algunas ciudades hubo que mejorar los
estadios de fútbol existentes, mientras que en otras hubo que construir estadios nuevos
a un costo aproximado de R17b (aproximadamente US$2,4b). Un estadio central para
los juegos es el recién construido Estadio de Ciudad del Cabo que se muestra en la
Figura 9.5. Los requisitos para los partidos únicos de la FIFA normalmente superan
con creces lo que exigirían los propietarios de los estadios una vez finalizados los
partidos. Por ejemplo, para cada estadio, la FIFA exigió la provisión de 2.000 periodistas
para el partido final, mientras que un partido internacional ordinario atraería solo a
unos 200; normalmente, un estadio requeriría unas diez posiciones de transmisión, pero la FIFA requirió
150. Por lo tanto, tenía sentido diseñar instalaciones para uso normal después de los
juegos y cumplir con los requisitos temporales de la FIFA agregando elementos
temporales llamados "Superposición". La superposición, que se retiraría después del
evento, incluía posiciones adicionales para comentaristas, mesas de prensa, equipos
de seguridad, carpas de hospitalidad y otras, así como numerosos cables adicionales
y otros equipos. Obviamente, fue más fácil diseñar alojamientos para el Overlay en
nuevos estadios "greenfield" que en los estadios existentes que tenían que ser
mejorados.
Los principales interesados en el diseño y la construcción de los estadios se
enumeran en la Tabla 9.4. Estas partes interesadas tenían que interactuar entre sí y
con otras partes, como los servicios de seguridad nacional, la policía, las organizaciones
locales de transporte y los propietarios de terrenos y edificios, incluidas las escuelas.
La publicación de la FIFA “Manual de estadios de fútbol” brinda pautas para

planificar y ejecutar eventos de la FIFA y se actualiza después de cada evento de la
Copa Mundial. Los miembros del COL visitaron Europa varias veces para aprender de
la Copa Mundial de la FIFA 2006 celebrada en Alemania y la Eurocopa 2008 celebrada
en Austria y Suiza. Un miembro del COL comentó que los elementos de la “lista de
deseos” para la Copa del Mundo de 2006 en Alemania se habían convertido en la
norma para la Copa del Mundo de 2010.
Los estadios fueron construidos por empresas designadas por las ciudades
anfitrionas, mientras que los contratistas para la Superposición fueron designados por
el COL. Algunos subcontratos para Overlay estaban controlados por el contratista de
Overlay, mientras que otros, como seguridad, energía eléctrica, electricidad de
respaldo, suministro de agua y drenaje de aguas residuales, estaban controlados por
otras partes. Si bien los contratistas de Overlay informaron al LOC, las ciudades
anfitrionas autorizaron a sus contratistas a hacerse cargo de los espacios para
construir Overlay. Las diferentes partes, el COL y sus contratistas de Overlay, las
ciudades anfitrionas y sus contratistas de estadios, trabajaron en los mismos espacios
y al mismo tiempo, pero con diferentes responsabilidades y estructuras de información.
Esto resultó ser un desafío para coordinar el trabajo y causó algunos conflictos.
Cuando un estadio estaba casi terminado, todas las partes interesadas relevantes
debían asistir a una inspección en el lugar y aceptar la aprobación.
Varios de estos eventos fueron debidamente registrados por actas y fotografías.
grabaciones
Las revisiones de progreso y las auditorías para garantizar que todos los estadios y otros espacios
cumplieran con la normativa de la FIFA fueron realizadas principalmente por el equipo técnico del COL.
La FIFA, el COL y los grupos constituyentes gubernamentales también se reunieron regularmente con
los miembros de las ciudades anfitrionas para evaluarlos y ayudarlos con el cumplimiento de la FIFA.
Estas reuniones fueron presididas por la FIFA, aunque un miembro del equipo técnico comentó más
tarde: “Esto fue un error, el LOC debería haber tomado el control”.
Entre reuniones, las partes interesadas relevantes se reunirían en Johannesburgo y realizarían

“recorridos virtuales” de los sitios; las ciudades anfitrionas presentarían su progreso a través de medios
multimedia, que incluían un enlace satelital con la sede de la FIFA en Zúrich, Suiza. Este proceso
garantizó que las ciudades anfitrionas y sus equipos técnicos estuvieran plenamente conscientes de
los requisitos, y les brindó la oportunidad de discutir cualquier inquietud que tuvieran con los clientes.
Preguntas
1. Dados dos conjuntos de requisitos, uno para los juegos de FIFA y otro para después de los
juegos, ¿cuál sería una forma apropiada de definir “calidad”?
2. Enumere las actividades de gestión de la calidad mencionadas en el caso.
3. (a) Comente sobre las estructuras de informes y la responsabilidad de las auditorías y

revisiones.
(b) ¿Quién debería haber proporcionado garantías de calidad? (c)

¿Qué procesos y técnicas de planificación habrían sido
útil con respecto a las funciones de las diversas partes interesadas?
Cuadro 9.4 Principales interesados en FIFA 2010 y sus funciones
Partes interesadas roles
FIFA (Federación Internacional de

Cliente principal
Asociación de Futbol)
(Francés: Federación
Internacional de Fútbol
Asociación)
Proporcionar infraestructura que incluya

Ciudades anfitrionas y sus planificadores sedes de partidos, sedes de entrenamiento
y carreteras.
Propietarios de estadios (en algunos casos,

los organismos deportivos eran propietarios Clientes con requerimientos respecto a
de los estadios, pero la mayoría eran propiedad sus propiedades
de las ciudades anfitrionas)
Gobierno de SA (Tesoro y
Garantías financieras
Departamento de Deportes)
Equipo de trabajo designado por el Sur Supervisar y controlar las finanzas en

Gobierno Africano en nombre del Gobierno
fútbol sudafricano Organizar la Copa del Mundo en

Asociación (SAFA) nombre de la FIFA
Organizar la Copa del Mundo en nombre

Comité Organizador Local
de SAFA Diseñar, construir y financiar
(LOC)
el Overlay.
Informar a las ciudades anfitrionas

sobre los requisitos de la FIFA y del
gobierno y ayudar con la interpretación
de los requisitos.
Combina las guías técnicas de:
• presentador de televisión
• Titular de los derechos de hospitalidad
• Titulares de los derechos de los
medios de comunicación • Marketing y seguridad
Equipo Técnico LOC (reportando al de la FIFA • Grupos integrantes del COL.

Comité Ejecutivo LOC y
Preparar una Guía Técnica para
Junta) ayudar a los planificadores de la ciudad
anfitriona sobre los requisitos.
Supervisar e informar al LOC

Ejecutivo
Comité y Junta con respecto
a:
• Calidad •
Progreso •
Finanzas
• Cumplimiento de la FIFA.
Diseñadores de estadios y Diseño y construcción de estadios.

empresas constructoras.
Diseño y construcción del recinto

Profesionales de la ciudad anfitriona (alrededores) y del
vías de acceso
Contratistas de superposición
Especificaciones y suministro de
(diseñadores y proveedores), designados por el
elementos de superposición
LOC
4. Comente el problema de personas de diferentes organizaciones que trabajan en el

mismo espacio al mismo tiempo.
Caso 9.3 Adversidad Airbag
Una gestión de calidad insuficiente durante el desarrollo, el lanzamiento y la producción del

producto puede dar lugar a proyectos y programas costosos posteriores para corregir problemas.
Esto es especialmente cierto cuando se trata de elementos críticos para la seguridad. El retiro
global de 2015 de una gran variedad de marcas de automóviles, que afectó a millones de
propietarios, es un ejemplo. El retiro masivo estuvo relacionado con bolsas de aire potencialmente
defectuosas utilizadas por los fabricantes de automóviles luego de informes de que las bolsas
de aire tenían infladores que podían explotar y expulsar fragmentos de metal y plástico hacia
los ocupantes del vehículo. Las bolsas de aire fueron suministradas por Takata Corporation de
Japón, el segundo mayor proveedor mundial de bolsas de aire y cinturones de seguridad. Un
informe del New York Times encontró un total de al menos 139 lesiones reportadas en todos
los fabricantes de automóviles; solo en vehículos Honda se reportaron al menos dos muertos y
30 heridos.
Cuando se anunció la falla por primera vez en 2013, solo seis marcas estaban involucradas,
pero para 2015, una gran variedad de marcas y 34 millones de vehículos solo en los EE. UU.
estaban potencialmente afectados. Se dijo que Takata se estaba acelerando para producir
reemplazos a un ritmo de 10 millones por año.
Inicialmente, se pensó que los propulsores químicos se manipularon y almacenaron
incorrectamente durante el ensamblaje, lo que podría causar que los infladores de metal
explotaran debido a la presión interna extrema. Más tarde, se pensó que el clima húmedo
también había jugado un papel. Takata citó a otros posibles contribuyentes,
incluyendo óxido, soldaduras defectuosas y, al menos en un caso, chicle caído en un

inflador. Los documentos mostraron que en 2002 la planta de Takata en México permitió
una tasa de defectos que era "de seis a ocho veces superior" al límite aceptable, o
aproximadamente de 60 a 80 piezas defectuosas por cada millón de infladores de bolsas
de aire enviados.
Preguntas
1. Explique el papel de la clasificación de las características en la reducción de los costos

de asegurar la calidad.
2. Discuta por qué se debe resistir cualquier presión para apresurar o reducir costos en el
desarrollo de elementos críticos para la seguridad. Enumere los costos específicos
incurridos por los programas de recuperación para retirar los vehículos del uso; incluyen
los costos por (a) la pérdida de la reputación del fabricante de automóviles o de Takata
y las ventas futuras, (b) los litigios entre los fabricantes de automóviles y Takata y (c)
los juicios resultantes de la muerte o lesiones de personas.
3. Discutir procedimientos y pasos específicos en los procesos de diseño y fabricación para
componentes y sistemas críticos para la seguridad, y cómo deben diferir de los
procedimientos y pasos de gestión de calidad para artículos no críticos.
4. ¿Qué técnicas y procedimientos específicos recomendaría para el diseño y la fabricación

de tales artículos críticos para la seguridad?
5. Las especificaciones a menudo establecen que un determinado incidente o evento no
debe ocurrir más de, digamos, una vez en 1 millón o una vez en 10 millones.
Explique por qué las pruebas para garantizar tal requisito son difíciles y costosas.
Notas finales
1. Carruthers M. Principios de Gestión para Proyectos de Calidad. Londres: Prensa internacional de Thompson;
1999.
2. Ibíd.
3. Yourdan E. Rise and Resurrection of the American Programmer. Upper Saddle River, Nueva York: Yourdan
Prensa/Prentice Hall; 1998, págs. 157–181.
4. Crosby P. La calidad es gratis. McGraw-Hill; 1979.
5. Bach J. El desafío del software 'suficientemente bueno'. Programador americano 8(10); 1995: 2-11.
6. Nicholas J. Lean Production for Competitive Advantage: una guía completa de metodologías Lean
y prácticas de gestión. Boca Ratón, FL: CRC/Productivity Press, 2011.
7. Organización Internacional de Sistemas, ISO 9001, Sistemas de Gestión de Calidad—Requisitos. Ginebra,
2015.
8. Crosby, op. cit.
9. Kransdorff A. El papel del análisis posterior al proyecto. La Organización de Aprendizaje 3(1); 1996: 11-15.
10. La norma ISO/CD 10007 ofrece directrices sobre sistemas de gestión de la configuración: Internacional
Organización de estándares, ISO/ CD 10007 Sistemas de gestión de calidad: pautas para la configuración
Administración. Ginebra, 2003.
11. Gray M. Angle of Attack: Harrison Storms and the Race to the Moon. Nueva York: WW Norton; 1997, págs.
170–171.
12. East E., Kirby J. y Perez G. Revisión de diseño mejorada a través de la colaboración web. Diario de
Gestión en Ingeniería. Abril de 2004: 51–55.
13. De Muirhead B. y Simon W. High Velocity Leadership: The Mars Pathfinder Approach to Faster,
Mejor, Más Barato. Nueva York: Harper Business; 1999, págs. 86–89, 178–179.
14. http://www.boeing.com/commercial/777family/pf/pf_computing.html (consultado en agosto de 2006).
15. Cuando se producen múltiples unidades de un sistema, el primer y segundo grupo de pruebas se realizan en un
prototipo. Cuando el sistema es de copia única, el segundo grupo de pruebas ocurre durante la construcción y el diseño
se verifica después.
16. Información para esta solicitud proporcionada por Elisa Denney y Jennifer Brown.
17. Ishikawa K. ¿Qué es el control de calidad? Acantilados de Englewood, Nueva York: Prentice Hall; mil novecientos ochenta y dos.
18. Bamford D. y Greatbanks R. El uso de herramientas y técnicas de gestión de la calidad: un estudio de
aplicación en situaciones cotidianas. Revista Internacional de Gestión de Calidad y Confiabilidad 22(4);
2005.
19. Manual de control de calidad de Juran J. y Gryna F. Juran, 4.ª ed. Nueva York: McGraw-Hill; 1988.
20. Belluck P. y Zezima K. Accidente en Boston's Big Dig mata a mujer en automóvil. New York Times, 12 de julio; 2006.
21. Bradley M. "Fallo de pernos en Big Dig: ¿una anomalía?" Christian Science Monitor, 21 de julio de 2006.
22. Murphy S. Memo advirtió sobre el colapso del techo: el oficial de seguridad temía muertes en el '99, ahora agoniza por
tragedia. Boston Globe, 26 de julio; 2006.
23. El trabajo de Allen S. y Murphy S. Big Dig puede haber usado epoxi incorrecto. Globo de Boston, 3 de mayo de 2007.
24. Drake B. Los investigadores investigan el diseño del túnel de Boston. CENoticias.com Septiembre 1; 2006,
www.cenews.com/article.asp?id=1108; Consultado el 15 de mayo de 2007.
25. Waters P. Foros de física, www.physicsforums.com/showthread.php?t=126374, russ_waters, 17 de julio de
2006, 21.30 horas; consultado el 20 de mayo de 2007.
26. Comunicación personal, Eugene van Vuuren. Miembro del Equipo Técnico LOC. noviembre de 2010.
Capítulo 10
Gestión de riesgos del proyecto
La vida “parece un poco más matemática y regular de lo que es; su exactitud es obvia, pero su inexactitud está oculta; su salvajismo
está al acecho.”
1 —GK Chesterton
Cada proyecto es arriesgado, lo que significa que los resultados del proyecto no resultarán según
lo planeado. El proyecto podría exceder significativamente los objetivos de costo o cronograma, o
el artículo final puede no cumplir con los requisitos. Los resultados del proyecto resultan de muchas
cosas, incluidas algunas que son bastante impredecibles y sobre las cuales los gerentes de
proyecto tienen poco control. El nivel de riesgo está asociado con la certeza de que los resultados
serán los esperados. Los resultados de certeza alta tienen un riesgo bajo; los resultados de baja
certeza tienen un alto riesgo. La certeza se deriva del conocimiento y la experiencia adquiridos en
proyectos anteriores, así como de la capacidad de la gerencia para mitigar los riesgos anticipados
2
y responder a los problemas emergentes.
10.1 Conceptos de riesgo
El riesgo es una función de la singularidad de un proyecto y la experiencia del equipo del proyecto. Cuando
las actividades son rutinarias o se han realizado muchas veces antes, los gerentes pueden anticipar los
riesgos y manipular el diseño del sistema y el plan del proyecto para lograr los resultados deseados. Pero
cuando el trabajo es único o el equipo sin experiencia, los resultados son menos seguros, lo que dificulta
anticipar los problemas o saber cómo evitarlos. Incluso los proyectos de rutina pueden ser riesgosos debido
a factores que surgen recientemente o que están fuera del control de cualquiera.
La noción de riesgo del proyecto implica dos conceptos:
1. La probabilidad de que ocurra algún evento problemático.

2. El impacto del evento si ocurre.
El riesgo es una función conjunta de los dos,
Riesgo = f(probabilidad, impacto)
Por lo general, un proyecto se considerará "arriesgado" siempre que al menos uno (la probabilidad o el
impacto) sea grande. Por ejemplo, un proyecto se considerará arriesgado cuando el impacto potencial sea
la muerte humana o pérdidas financieras masivas, incluso si la probabilidad es pequeña. El riesgo también
puede significar oportunidades, por ejemplo, el potencial de recompensas, ahorros o beneficios adicionales.
Por lo general, sin embargo, la gestión de riesgos se centra en el riesgo de fracaso.
Figura 10.1 Elementos y proceso de gestión de riesgos.
Muchos gerentes están acostumbrados a lidiar con hechos, cifras y números concretos,
por lo que les resulta difícil manejar el concepto de riesgo. Ante la incertidumbre, prefieren
ignorar los problemas, aunque, por supuesto, eso no hace que los problemas desaparezcan.
Aunque el riesgo no se puede eliminar, se puede reducir y preparar planes en caso de

que las cosas salgan mal; este es el propósito de la gestión de riesgos. El proceso y los
elementos de la gestión de riesgos se muestran en la Figura 10.1.
10.2 Identificación de riesgos
Solo puedes gestionar las cosas de las que eres consciente. Así, la gestión de riesgos comienza con la
identificación de los riesgos y la predicción de sus consecuencias.
El riesgo en los proyectos a veces se denomina riesgo de falla, lo que implica que un proyecto puede no
cumplir con los objetivos de cronograma, presupuesto o desempeño técnico por un margen significativo.
Entre las formas de identificar los riesgos del proyecto, una es proceder de acuerdo con la cronología del
proyecto, es decir, observar las fases y etapas del ciclo de vida (factibilidad, negociación del contrato, concepto
del sistema, definición, etc.) e identificar los riesgos en cada uno. . Cada fase presenta obstáculos y problemas
únicos que podrían detener el proyecto de inmediato o provocar un fracaso posterior (como se ilustra en el Capítulo
9, Tabla 9.1).
En los proyectos de desarrollo de productos, el riesgo de falla tiende a ser alto en la etapa inicial del diseño
preliminar, pero disminuye más adelante. Algunos riesgos permanecen en todo momento, como la pérdida de
financiación o compromiso de gestión.
Ver Capítulo 9
El riesgo también se puede identificar por tipo de trabajo o función técnica, como riesgos de ingeniería
asociados con la confiabilidad y mantenibilidad del producto, o riesgos de producción asociados con la capacidad
de fabricación de un producto o la disponibilidad de materias primas.
La identificación de riesgos comienza en la fase de concepción y se enfoca en aquellos factores de riesgo que
dificultarían el proyecto o que estarían destinados al fracaso. Los factores que contribuyen al alto riesgo incluyen:
• Usar un enfoque inusual. • Intentar
desarrollar un sistema mientras se promueve la tecnología al mismo tiempo.

tiempo.
• Desarrollar y probar nuevos equipos, sistemas o procedimientos. • Operar en un entorno
impredecible o variable.
Los factores de alto riesgo deben estudiarse y comprenderse bien antes de que el proyecto pueda llevarse a cabo.
aprobado y fondos comprometidos. Los riesgos identificados en la fase de concepción a menudo se

definen ampliamente y se evalúan subjetivamente, aunque también pueden analizarse utilizando los
métodos que se analizan más adelante. Cuando se están considerando varios proyectos que compiten
entre sí, se realiza una evaluación para decidir cuál de ellos es el mejor, en función de las ventajas y
desventajas de los riesgos, los beneficios y la financiación disponible. 3 La comparación y selección

proyectosdecon
base en criterios como el riesgo se analiza en el Capítulo 18.
Ver Capítulo 18
Fuentes de riesgo
Cualquier factor incierto que pueda influir en el resultado de un proyecto es una fuente de riesgo o peligro
de riesgo. Identificar las fuentes de riesgo implica aprender tanto como sea posible sobre las cosas que
sabe que podrían salir mal y el resultado de cada una, así como tratar de identificar las cosas que aún no
sabe: las "incógnitas desconocidas".
Las fuentes de riesgo en los proyectos se pueden clasificar en riesgos internos y riesgos externos.
Fuentes internas
Estas son fuentes de riesgo que se originan dentro del proyecto y sobre las cuales los gerentes del
proyecto y las partes interesadas tienen cierto control. Se dividen en tres categorías principales: riesgo de
mercado, riesgo de suposiciones y riesgo técnico.
El riesgo de mercado es el riesgo de no satisfacer las necesidades del mercado o los requisitos de
clientes particulares. Las fuentes de riesgo de mercado incluyen:
• Falta de definición adecuada del mercado o de las necesidades del cliente y

requisitos • Falta
de identificación de necesidades y requisitos cambiantes. • Falta de
identificación de productos recién introducidos por los competidores.
El riesgo de mercado proviene de que el desarrollador malinterpreta el entorno del mercado. Se puede
reducir trabajando en estrecha colaboración con el cliente; definir minuciosamente las necesidades y los
requisitos al principio del proyecto; siguiendo de cerca las tendencias y los desarrollos
entre mercados, clientes y competidores; y actualizar los requisitos según sea necesario a lo largo
del proyecto.
El riesgo de supuestos es el riesgo asociado con los numerosos supuestos implícitos o explícitos
realizados en los estudios de factibilidad y los planes del proyecto durante la concepción y definición
del proyecto. Las suposiciones defectuosas, inexactas o inválidas ponen el proyecto en peligro de no
cumplir con los requisitos técnicos, de tiempo o de costo, o de tener efectos secundarios no
anticipados y dañinos.
El riesgo técnico es el riesgo de encontrar problemas técnicos con el producto final o las
actividades del proyecto. (A veces, estos riesgos se enumeran en categorías especiales : los riesgos
de cronograma son los que causan demoras, los riesgos de costo son los que pueden conducir a
sobrecostos, etc.). El riesgo técnico es alto en proyectos que involucran aplicaciones técnicas nuevas
y no probadas, pero es bajo. en proyectos que involucran actividades y tecnologías familiares.
Un enfoque para expresar el riesgo técnico es calificar el elemento final del proyecto o el proceso
primario como alto, medio o bajo de acuerdo con las siguientes características:
4
• Madurez. Cuán experimentado o conocedor es el equipo del proyecto en la tecnología del

proyecto. Un elemento o proceso final que aprovecha la experiencia y el conocimiento
existente es menos riesgoso que uno que es innovador, no probado o de vanguardia. •
Complejidad. Cuántos pasos, elementos o componentes contiene el producto o proceso y
qué tan estrechamente están interrelacionados. Ceteris paribus, un producto o proceso final
con numerosos pasos o componentes interrelacionados es más riesgoso que uno con menos
pasos y relaciones más simples.
• Calidad. ¿Qué tan producible, confiable y comprobable es el producto final o el proceso?

En general, un elemento final o proceso que se ha producido y es confiable y/o comprobable
es menos riesgoso que uno que aún no se ha producido, o cuya confiabilidad o capacidad
de prueba se desconoce. • Concurrencia o Dependencia. ¿En qué medida se superponen
múltiples actividades dependientes en el proyecto? Las actividades realizadas en secuencia
sin superposición son menos riesgosas que las actividades que se superponen (por ejemplo,
el enfoque de etapas discretas es menos riesgoso que el seguimiento rápido).
Una subcategoría de riesgos técnicos son los riesgos para la salud, la seguridad y el medio ambiente;
estos incluyen todos los peligros para los trabajadores del proyecto, la sociedad en general y la
ecología como consecuencia del proyecto. Estos riesgos se derivan de peligros a corto plazo
debido a las condiciones y procedimientos de trabajo, y materiales utilizados en el proyecto, y de
peligros posteriores al proyecto a largo plazo por el funcionamiento, la operación o la mera
existencia del elemento final del proyecto.
Fuentes externas
Estas son fuentes de riesgo que se originan fuera del proyecto y sobre las cuales los gerentes de
proyecto a menudo tienen una capacidad limitada o nula para controlarlas. Incluyen:
• regulaciones gubernamentales
• acciones de los competidores
• tasas de interés y tipos de cambio •
decisiones de la alta gerencia o del cliente con respecto al proyecto, prioridades
dotación de personal o
presupuestos • necesidades y comportamiento del cliente
• relaciones proveedor/subcontratista y quiebras comerciales •

entorno físico (clima, terreno) • disponibilidad de mano de obra
(huelgas y huelgas) • recursos materiales o laborales (escasez) •
control del cliente o subcontratista sobre el trabajo y los recursos
del proyecto.
Otra fuente importante de riesgo son las partes interesadas. Por definición, ya sea que se
encuentren dentro o fuera del proyecto, las partes interesadas se ven afectadas por el proyecto y,
al igual que las fuentes de riesgo enumeradas anteriormente, muchas de ellas pueden influir en
los resultados del proyecto, tanto positiva como negativamente. La identificación y el trabajo con
las partes interesadas se analiza en los Capítulos 15 y 17.
Ver Capítulo 15 y 17
Técnicas de Identificación
Las fuentes de riesgo del proyecto (en lo sucesivo, simplemente "riesgos") se identifican de muchas
maneras; entre ellos se encuentran la analogía del proyecto, las listas de verificación, el análisis WBS,
los diagramas de flujo de procesos, las redes de proyectos, los diagramas de causa-efecto, la lluvia de
ideas y la técnica Delphi.
analogía del proyecto
El método de analogía del proyecto implica examinar los registros, los informes resumidos posteriores a
la finalización y los recuerdos de los miembros del equipo del proyecto de proyectos análogos anteriores
para identificar los riesgos en los próximos proyectos. Cuanto más completa, precisa y bien catalogada
sea la documentación de proyectos pasados y mejor la memoria de las personas, más útiles serán estas
como fuentes para identificar riesgos. Más allá de solo investigar proyectos anteriores, el método requiere
identificar aquellos que son similares en formas significativas al proyecto para el cual se están evaluando
los riesgos. Los métodos de gestión del conocimiento , descritos en el Capítulo 17, promueven el
aprendizaje de proyectos anteriores que pueden ayudar a anticipar riesgos en proyectos nuevos.
Ver Capítulo 17
listas de control
La documentación de proyectos anteriores también se utiliza para crear listas de verificación de fuentes
de riesgo en los proyectos. Una lista de verificación se crea originalmente a partir de las experiencias de
proyectos anteriores y se actualiza a medida que se adquiere nueva experiencia de proyectos recientes.
Las listas de verificación de riesgos pueden pertenecer al proyecto en su totalidad o a fases específicas,
paquetes de trabajo o tareas dentro del proyecto.
Para ilustrar, la lista de verificación en la Tabla 10.1 muestra la gravedad del riesgo asociada con tres
categorías de fuentes de riesgo: (1) estado del plan de implementación, (2) número de interfaces de
módulos y (3) porcentaje de componentes que requieren pruebas. Suponga, por ejemplo, que un próximo
proyecto utilizará un plan estándar, tendrá ocho interfaces de módulos y probará el 16 por ciento de los
componentes del sistema. De acuerdo con la lista de verificación, el proyecto se calificará como bajo,
bajo y medio, respectivamente, para el
tres fuentes de riesgo.
Cuanta más experiencia gana una empresa o un gerente con los proyectos, más
aprender acerca de los riesgos, y más completos pueden hacer las listas de verificación.
A medida que crece la experiencia con los proyectos terminados, las listas de verificación se amplían y
actualizado. Si bien una lista de verificación no puede garantizar que todas las fuentes de riesgo significativas en un
se identificará el proyecto, ayuda a asegurar que los importantes conocidos

no será pasado por alto.
Una variante de la lista de verificación es la matriz de riesgos, una tabla en la que las columnas se
las fases del proyecto y las filas las fuentes de riesgos. Las células de la matriz
indicar la presencia, ausencia o severidad de los riesgos especificados para todas las fases del
proyecto.
Cuadro 10.1 Lista de verificación de riesgos
Fuentes de riesgo Gravedad del riesgo
Estado del plan de implementación
1. No se requiere plan 2. Ninguna
Plan estándar, existente, completo 3. Plan en Bajo
preparación 4. Plan no iniciado Medio
Alto
Número de interfaces entre módulos
1. Menos de 5 Ninguna
2. 5–10 Bajo
3. 11–20 Medio
4. Más de 20 Alto
Porcentaje de componentes del sistema que requieren pruebas

1. 0–1 Ninguna
2. 2–10 Bajo
3. 11–30 Medio
4. Más de 30 Alto
Una desventaja de las listas de verificación de riesgos es que las personas pueden considerar solo los riesgos
enumerados y no considerar ninguno que no esté en la lista. Por lo tanto, las listas de verificación deben ser
complementado con otros métodos.
Estructura de desglose del trabajo (EDT)
Los riesgos se pueden identificar utilizando la EDT. Cada paquete de trabajo se analiza en busca de
posibles obstáculos técnicos o problemas con la administración, los clientes, los proveedores, el equipo o
la disponibilidad de recursos. Se evalúan los riesgos internos en términos de, por ejemplo, complejidad,
madurez, calidad y concurrencia, y los riesgos externos, por ejemplo, depender de un subcontratista para
administrar el paquete de trabajo. El riesgo de cada paquete de trabajo se clasifica como, por ejemplo, alto,
medio o bajo.
Diagrama de flujo del proceso
Los riesgos del proyecto también se pueden identificar a partir de los diagramas de flujo del proceso. Un
diagrama de flujo ilustra los pasos, procedimientos y flujos entre tareas y actividades en un proceso. El
examen de un diagrama de flujo puede identificar posibles puntos problemáticos y áreas de riesgo.
FMEA y HAZOP
El método de análisis de modo y efectos de falla (FMEA) (consulte el Capítulo 9) se puede utilizar para
identificar las condiciones que conducen a la falla del sistema y, por lo tanto, someten al proyecto, a las
personas y al medio ambiente a riesgo. Otro método llamado HAZOP (Hazard and Operability Study) es
una investigación rigurosa de un sistema para evaluar qué sucede cuando se inicia, se apaga o encuentra
problemas. El enfoque del estudio está en el diseño del sistema y los posibles errores, omisiones o peligros
inherentes. Ambos métodos son ampliamente utilizados en proyectos técnicos; HAZOP se usa comúnmente
en industrias de procesos y proyectos de infraestructura.
Ver Capítulo 9
Proyecto Redes y Puntos de Convergencia
De manera similar, los riesgos pueden identificarse mediante el escrutinio de las relaciones de precedencia
y programación concurrente o secuencial de actividades en redes de proyectos (Capítulos 6 y

7). Por ejemplo, el riesgo a veces aumenta en los puntos de fusión de la red donde el trabajo
realizado por diferentes equipos se une y debe integrarse; a veces, solo entonces los problemas
se vuelven evidentes, como subsistemas producidos por dos equipos que no coinciden o no
funcionan correctamente. El riesgo de retraso del proyecto por este llamado “sesgo del punto
de fusión” se analiza en el Capítulo 7.
Ver Capítulo 6 y Capítulo 7
Lluvia de ideas y diagrama de causa y efecto
Los riesgos se pueden identificar a partir de las experiencias colectivas de los miembros del
equipo del proyecto que participan en una sesión de lluvia de ideas para compartir opiniones
sobre posibles fuentes de riesgo en el proyecto y registrarlas en un diagrama de causa y efecto
(CE) como se muestra en la Figura 10.2. La lluvia de ideas y los diagramas CE se utilizan de
dos maneras: (1) dado un resultado potencial identificado (efecto), para identificar las causas
potenciales (fuentes); (2) dada una fuente de riesgo (causa), para identificar los resultados que
podrían producirse (efectos). La figura 10.2 ilustra el primer uso: muestra fuentes potenciales
que conducen al efecto de "retraso en la finalización".
El diagrama de la figura 10.2 se divide en categorías de riesgo genéricas de software,
hardware, etc. (son posibles otras categorías). Cada categoría se subdivide en fuentes de
riesgo más fundamentales. En la Figura 10.2, por ejemplo, la categoría “personal” incluye el
riesgo de “escasez de personal”, que podría deberse a la incapacidad de contratar y capacitar
personal adicional. Las técnicas de análisis relacionadas con la CE se analizan con más detalle
en el Capítulo 9.
Ver Capítulo 9
Para fomentar el pensamiento original y la generación de una lista completa de posibles

riesgos, los riesgos no deben evaluarse durante la lluvia de ideas. Cualquier mención temprana
de que un riesgo es "poco realista" o "imposible" podría conducir a que se descarten algunos
riesgos muy importantes. Por lo tanto, no se deben evaluar los riesgos hasta que se haya
compilado la lista de riesgos.
Figura 10.2 Diagrama de causa y efecto.
Los riesgos relacionados con el producto final del proyecto también pueden descubrirse durante
revisiones de diseño, que se analizan en el Capítulo 9.
Ver Capítulo 9
Técnica Delphi
El término Delphi se refiere a una técnica de encuesta grupal para combinar las opiniones de varias
personas para desarrollar un solo juicio. La técnica comprende una serie de preguntas estructuradas
e informes de retroalimentación. Cada encuestado recibe una serie de preguntas (p. ej., ¿cuáles
son los cinco riesgos más importantes de este proyecto?), para lo cual escribe sus opiniones y
razones. Las respuestas de todos los encuestados son
resumido en un informe que se entrega a todos. Al ver las opiniones de los demás, los
encuestados tienen la oportunidad de modificar sus propias opiniones. Debido a que las
respuestas escritas son anónimas, nadie se siente presionado a conformarse con las
opiniones de los demás. Si las personas cambian de opinión, deben explicar por qué; si no lo
hacen, también deben explicar por qué. El proceso continúa hasta que el grupo llega a una
opinión colectiva. Los estudios han demostrado que la técnica es una forma eficaz de llegar
5
a un consenso.
Síntomas de riesgo y desencadenantes
A medida que se identifican las fuentes y los resultados de cada riesgo, también se identifican
sus síntomas, que son indicadores visibles o señales de advertencia de que el riesgo se está
materializando; estos sirven como disparador para iniciar contramedidas o contingencias
para mitigar o combatir el riesgo. Por ejemplo, para el riesgo de “incumplimiento de los
requisitos técnicos”, un síntoma podría ser “fallo del componente X durante la prueba”; si se
observara ese síntoma, desencadenaría la acción “pasar al plan de diseño B”.
10.3 Evaluación de riesgos
Los riesgos son omnipresentes, pero solo los notables o significativos requieren atención. Si un
riesgo y sus consecuencias son significativos, se deben encontrar formas de evitar o reducir el
riesgo a un nivel aceptable. Lo que se considera "aceptable" depende de la tolerancia al riesgo
de las partes interesadas del proyecto. A menudo, los gerentes con experiencia evitan los
riesgos (son reacios al riesgo) porque entienden los riesgos y sus consecuencias, mientras que
los gerentes con menos experiencia los toman (toleran el riesgo) porque ignoran los riesgos o
sus consecuencias.
Lo que se considera significativo depende de la probabilidad de riesgo, el impacto del riesgo,
y la consecuencia del riesgo.
Probabilidad de riesgo
La probabilidad de riesgo es la probabilidad de que un factor de riesgo realmente se Puede

materialice. 6 expresarse como un valor numérico entre 1,0 (seguro que suceda) y 0 (imposible)
o como una calificación cualitativa como alta, media o baja. Los valores numéricos y las
calificaciones cualitativas a veces se usan indistintamente. La tabla 10.2 muestra un ejemplo:
cuando, por ejemplo, alguien dice: “la probabilidad de este o aquel riesgo es baja”, eso significa
que la probabilidad de que ocurra, según la tabla, es del 20 por ciento o menos.
Pero la tabla 10.2 es solo una ilustración. La asociación entre calificaciones cualitativas y
valores numéricos particulares es subjetiva y depende de la experiencia del equipo del proyecto
y la tolerancia al riesgo de las partes interesadas. Por ejemplo, la Tabla 10.2 podría haber sido
creada para un proyecto con mucho interés económico, en cuyo caso “alto riesgo” equivale a
una probabilidad numérica de más del 50 por ciento. En un proyecto con poco interés
económico, el "alto riesgo" podría equivaler a una probabilidad numérica del 75 por ciento o
más. A menudo, las personas tienen dificultad para ponerse de acuerdo sobre la calificación
cualitativa para un valor numérico de probabilidad dado y viceversa, incluso cuando usan la
misma información o experiencia; esto se describe más adelante en el ejemplo 10.2.
La tabla 10.3 es una lista de verificación de cinco fuentes potenciales de fallas en la computadora.
proyectos de sistemas y probabilidades numéricas asociadas. 7 Por ejemplo, mirando
En la columna MS , la probabilidad de falla para el software existente es baja, pero para el software
de última generación es alta. Para repetir, los valores de probabilidad son ilustrativos y
se adaptará a cada proyecto en función de la experiencia y opinión de
partes interesadas. Una estimación de probabilidad basada en las opiniones de varios individuos.
(suponiendo que todos tengan experiencia relevante) suele ser más válido que uno basado en
sólo unos pocos.
Cuando un proyecto tiene múltiples fuentes de riesgo independientes (como es común) pueden
combinarse en un solo factor de probabilidad compuesto, o CLF. Usando las fuentes
en la Tabla 10.3, el CLF se puede calcular como un promedio ponderado,
donde W1, W2, W3, W4 y W5 tienen cada uno valores de 0 a 1,0 y suman 1,0.
Tabla 10.2 Probabilidad de Riesgo: Calificaciones Cualitativas para Valores Cuantitativos
Cualitativo Numérico
Bajo 0–0,20
Medio 0,21–0,50
Alto 0,51–1,00
Tabla 10.3 Probabilidades de diferentes fuentes de falla

Ejemplo 10.1: Cálculo de CLF

El proyecto ROSEBUD involucra el desarrollo de hardware y software con las siguientes
características: el hardware es existente y de menor complejidad; el software se
desarrollará como un rediseño menor del software actual y es de complejidad moderada;
el rendimiento del sistema general dependerá de qué tan bien se pueda integrar en otro
sistema más grande. Así, de la tabla 10.3, MH = 0,1, CH = 0,3, MS = 0,5, CS = 0,3 y D =
0,5. Si todas las fuentes tienen la misma calificación de 0.2, entonces
La aplicación de este CLF se discutirá en breve.
Tenga en cuenta que el cálculo en la ecuación (10.1) supone que las fuentes de riesgo son
independientes. Si no lo son, si, por ejemplo, la falla debida a la complejidad del software
depende de la falla debida a la complejidad del hardware, entonces las dos probabilidades no pueden
ser resumido. Las fuentes tendrían que combinarse subjetivamente en una fuente ("fallo debido a una
combinación de complejidad de software y hardware") y un valor de probabilidad único asignado según
el juicio.
Una forma de mostrar la interdependencia de los factores de riesgo es con una influencia
8
diagrama, Un ejemplo es la Figura 10.3. Para construir el diagrama, comience con una lista de
riesgos previamente identificados (por ejemplo, de la Figura 10.2) y dibujarlos como se muestra en la
Figura 10.3. Luego mire cada riesgo y pregúntese si está influenciado o tiene influencia sobre cualquiera
de los otros riesgos. Si es así, dibuje flechas entre los riesgos relacionados para indicar la dirección de
la influencia (p. ej., S.1 influye en S.2 e I.2). Para minimizar la confusión, mantenga pequeña la cantidad
de riesgos en el diagrama, alrededor de 15 o menos.
Los riesgos con más conexiones son los más importantes. En la Figura 10.3, estos serían los riesgos
I.2, S.1 y S.2; cada uno está influenciado por otros riesgos, lo que aumenta la probabilidad de falla.
Figura 10.3 Diagrama de influencia.
La probabilidad de riesgo también se ve afectada por el futuro: ceteris paribus, las actividades
planificadas más adelante en el futuro son más riesgosas (tienen mayor probabilidad de fracaso) que aquellas
más cerca de la mano. 9 Esto se debe a que las actividades más lejanas en el futuro tienen mayores
posibilidades de verse influenciadas por incógnitas. Una vez que el proyecto entra en ejecución y avanza
hacia su finalización, la probabilidad de fracaso disminuye. Pero hay una compensación: el riesgo disminuye
a medida que avanza el proyecto, pero lo que está en juego en el proyecto (la cantidad de capital humano y
financiero invertido en él) aumenta. Esto significa que la pérdida incurrida por fallas posteriores en el proyecto
será mucho mayor que la pérdida si se incurre antes.
Impacto del riesgo
¿Qué pasaría si se materializara un peligro de riesgo? El resultado sería un impacto de riesgo. Una
intersección de carretera mal señalizada es un peligro de riesgo; plantea el impacto de riesgo de una colisión
y lesiones personales. El impacto del riesgo en los proyectos se puede especificar en términos de tiempo,
costo, rendimiento, publicidad, contaminación, etc. Por ejemplo, el impacto de la insuficiencia de recursos
podría ser el incumplimiento del cronograma o los requisitos del usuario.
El impacto del riesgo se puede expresar como una calificación cualitativa, como alta, media o baja,
basada en el juicio de un gerente o experto sobre el impacto. Por ejemplo, un riesgo que lleve a un retraso
en el cronograma de 1 mes podría considerarse de "impacto medio", mientras que un retraso de 3 meses o
más podría considerarse de "impacto alto".
Cuadro 10.4 Valores de impacto para diferentes situaciones técnicas, de costo y de tiempo
Impacto Impacto técnico Impacto de los costes

Programar impacto [SI]
Valor [TI] [CI]
Sin aumento de costos; Deslizamiento de horario
0.1 (bajo) Impacto mínimo
dentro del presupuesto insignificante; compensado por el tiempo de holgura
Pequeña reducción de <10% de aumento

0.3 (menor) Menor (< 1 mes)
rendimiento
Reducción
0,5
moderada del Aumento del 10 al 25 % Moderado (1 a 3 meses)
(moderado)
rendimiento
0.7 Reducción
significativa del 25–50% de aumento Significativo (>3 meses)
(importante)
rendimiento
Objetivos técnicos
0.9 (alto) posiblemente no >50% de aumento Grande (inaceptable)
alcanzables
Adaptado de Roetzheim, W. Gestión de proyectos informáticos estructurados. Upper Saddle River, Nueva Jersey: Prentice
Sala; 1988, 23–26.
El impacto del riesgo también se puede expresar como una medida numérica entre 0 y 1,0, donde 0 es
"no grave" y 1,0 es "catastrófico". Nuevamente, la calificación es subjetiva y depende del juicio. La tabla 10.4,
por ejemplo, representa juicios sobre los impactos asociados con varias situaciones técnicas, de costos y de
cronograma, y clasificaciones de valor de impacto sugeridas asociadas con cada una de ellas. 10 Los valores
de impacto de riesgo asignados son en gran medida subjetivos, incluso cuando se derivan
a partir de datos empíricos.
Ejemplo 10.2: Estimación de la probabilidad de riesgo y el

impacto del riesgo en nuevas tecnologías
La evaluación de riesgos en las nuevas tecnologías es, bueno, difícil. El riesgo de un problema grave
puede provenir de una cadena de eventos (por ejemplo, una máquina funciona mal, un sensor no la
detecta, un operador realiza una acción incorrecta), y para asignar la probabilidad del riesgo es
necesario identificar todos los eventos en la cadena. , estimando la probabilidad de cada uno y
combinando las probabilidades.
Los gerentes y diseñadores pueden tratar de pensar en cada evento, pero nunca pueden estar seguros
de no haberse perdido alguno. Cuando un proyecto involucra nuevas tecnologías, las estimaciones son
en gran parte conjeturas. En 1974, el MIT publicó un informe que afirmaba que la probabilidad de
fusión del núcleo de un reactor es una cada 17.000 años. El informe decía que una fusión en una
planta en particular ocurriría solo después de muchos cientos de años de operación, sin embargo,
menos de 5 años después, un reactor en Three Mile Island sufrió una fusión parcial y liberó
radioactividad a la atmósfera.
11
El transbordador espacial es otro caso: la NASA originalmente puso el riesgo de un accidente

catastrófico en 1 en 100.000, pero después del desastre del Challenger lo revisó a 1 en 200. Con la
pérdida adicional de Columbia (la segunda pérdida en 113
misiones) el riesgo real se convirtió en 1 en 56. Los transbordadores originalmente fueron

diseñados para 100 misiones, sin embargo, Columbia se disolvió durante su 26. 12 Pocos
puntos de
datos (cinco transbordadores operativos y 113 misiones durante 20 años) en combinación con
una complejidad increíble hizo imposible predecir con precisión los riesgos para el sistema de
transbordadores, sin embargo, para muchos proyectos, los datos disponibles para estimar las
probabilidades son aún más escasos.
Estimar los impactos es igualmente difícil, y los expertos de diferentes campos, dados hechos
idénticos, a menudo llegan a conclusiones diferentes. En una encuesta que calificó los peligros
de los desechos nucleares usando una escala de 17 puntos, los biólogos lo calificaron 13 La
evaluación
10.1, los geólogos 8.3 y los físicos 7.3. y entrenamiento de riesgos
y nunca depende de la
es completamente cultura
racional;
debido a esto, debe basarse en las opiniones de muchos expertos que representan una variedad
de disciplinas.
Así como se pueden combinar las probabilidades de múltiples riesgos, también se pueden combinar
los impactos de múltiples fuentes de riesgo. Se puede calcular un factor de impacto compuesto (CIF)
usando un promedio ponderado,
donde W1, W2 y W3 tienen valores de 0 a 1,0 y juntos suman 1,0. CIF oscilará entre 0,0 y 1,0, donde 0
significa "sin impacto" y 1,0 significa "el impacto más grave".
Ejemplo 10.3: Cómputo de CIF

Se espera que una falla particular en el proyecto ROSEBUD para cumplir con ciertos objetivos
técnicos afecte mínimamente el desempeño técnico y se corrija dentro de 2 meses a un costo del
20 por ciento. Por lo tanto, de la Tabla 10.4:
TI = 0,1, SI = 0,5, IC = 0,5
Suponga que los criterios más importantes son el desempeño técnico, seguido por el cronograma,
luego el costo y los pesos asignados a los criterios son 0.5, 0.3 y 0.2, respectivamente. Por lo
tanto, de la ecuación (10.2):
CIF = (0,5)(0,1) + (0,3)(0,5) + (0,2)(0,5) = 0,22
La ecuación (10.2) asume que los impactos del riesgo son independientes. Si no lo son, la
ecuación no se aplica y los impactos de valor único deben tratarse en conjunto, siendo un
ejemplo "el impacto de un aumento del 20 por ciento en el costo y un retraso en el cronograma
de 3 meses se califica como 0.6". La aplicación de este CLF se discute en el próximo
sección.
Otra forma de expresar el impacto del riesgo es en términos de lo que se necesitaría para
recuperarse o compensar un impacto no deseado. Por ejemplo, suponga que el uso de una
nueva tecnología presenta el riesgo de no cumplir con los requisitos de desempeño. El plan es
probar la tecnología, pero abandonarla y utilizar un enfoque probado si las primeras pruebas
revelan un rendimiento deficiente. El impacto del riesgo sería el impacto de cambiar de tecnología
en términos de retraso en el cronograma y costo adicional, por ejemplo, 4 meses y $300,000.
El impacto del riesgo debe evaluarse para todo el proyecto y articularse con el supuesto de que no se toman
medidas preventivas o de respuesta. En el caso anterior, $300,000 es el gasto anticipado bajo el supuesto de que
no se hará nada especial para evitar o prevenir la falla de la nueva tecnología. Este impacto evaluado se utilizará
como una medida para evaluar la eficacia de las posibles formas de reducir o prevenir los peligros de riesgo, como
se analiza más adelante. 14
Riesgo Consecuencia
Anteriormente, la noción de riesgo se definió como una función de la probabilidad del riesgo y el
impacto del riesgo; la consideración combinada de ambos se denomina consecuencia del riesgo
o exposición al riesgo.
La forma más común, matemáticamente, de expresar la consecuencia del riesgo es,
Usando la probabilidad previamente calculada (CLF) de 0.34 (Ejemplo 10.1) y el impacto (CIF)
de 0.22 (Ejemplo 10.3), la calificación de la consecuencia del riesgo, RCR, es
RCR = (CLR) × (CIR) (10,4) = (0,34) × (0,22) = 0,078

RCR varía en valor de 0 a 1,0, y un RCR muy pequeño, como 0,0748, podría considerarse
"sin consecuencias". Evaluar los valores de RCR como de consecuencia alta, media o baja
es subjetivo, y el uso principal de RCR es comparar y priorizar los riesgos, para separar
aquellos que probablemente se pueden ignorar (RCR pequeño, consecuencia baja) de
aquellos que se deben tener en cuenta. (RCR grande, consecuencia alta).
La consecuencia del riesgo también se puede expresar de otras maneras. Por ejemplo,
suponga que la probabilidad asociada con un riesgo es de 0.40 y, si el riesgo se materializa,
su impacto estimado sería retrasar el proyecto en 4 meses y aumentar el costo en $300,000.
Las consecuencias del riesgo para el tiempo y el costo son, por lo tanto,
Tiempo de consecuencia de riesgo (RT) = (4 meses)(0,40) = 1,6 meses = 6,4 semanas Costo de consecuencia de riesgo (RC) = ($300 000)(0,40)
= $12 000
Estas son las consecuencias del riesgo de "valor esperado", o cuáles serían los resultados
promedio si la situación se repitiera una gran cantidad de veces. El concepto de valor
esperado se analiza con más detalle en el Apéndice de este capítulo.
Una desventaja de usar el valor esperado es que asume que las personas son “neutrales
al riesgo”, lo cual no es cierto. Por ejemplo, usted podría estar dispuesto a jugar un juego
con un 50 por ciento de posibilidades de perder $10 (es decir, RC = $5), pero aún así lo
jugaría conÿ6unporcentaje
10 de probabilidad de perder $5,000,000 (RC = $5 también)?
La magnitud de las consecuencias, ya sea alta, media o baja, en función de los valores
de probabilidad e impacto especificados, se puede determinar trazando los valores en un
diagrama como el de la Figura 10.4. Así como los valores de probabilidad e impacto son
subjetivos, también lo es el posicionamiento de las isobaras que delimitan las regiones de
alto, mediano y bajo riesgo. Es interesante notar que este método es análogo a los usados
para evaluar proyectos, discutidos en el Capítulo 18; una comparación rápida de la Figura
10.4 y la Figura 18.5 revela lo mismo.
El método también es similar a la técnica de análisis de modo y efecto de falla (FMEA)

discutida en el Capítulo 9. Ambos métodos identifican y analizan las consecuencias del
riesgo, aunque FMEA está dirigido específicamente a los riesgos en los sistemas técnicos.
Figura 10.4 Consecuencia del riesgo en función de la probabilidad y el impacto.
IMPERTINENTE
Los métodos de simulación PERT y Monte-Carlo discutidos en el Capítulo 7 pueden usarse para
tener en cuenta el riesgo en la programación del proyecto y para estimar el tiempo adicional
necesario para compensar los riesgos en el cumplimiento de los plazos del proyecto.
Ver Capítulo 7
El método PERT tiene en cuenta el riesgo mediante el uso de tres estimaciones de tiempo para
cada actividad del proyecto: a, m y b (tiempos optimista, más probable y pesimista, respectivamente).
Un mayor riesgo en una actividad se refleja en una mayor dispersión entre a y b, y especialmente
entre m y b. Para una actividad sin riesgo percibido, a, myb serían idénticos; los peligros de riesgo
identificados se tienen en cuenta elevando los valores de bym o alejando b de m .
Con PERT, recuerde que es el tiempo esperado, no m, la base para la programación

tiempos, donde el tiempo esperado es la media de la distribución Beta,
Por lo tanto, para una actividad particular con valores dados optimistas y más probables (a y m), usar
un valor mayor de b para tener en cuenta un mayor riesgo dará como resultado un valor mayor de te.
Esto lógicamente permite más tiempo para completar la actividad y compensar cualquier riesgo. Además,
sin embargo, el mayor valor de b también da como resultado una mayor variación de tiempo para la
actividad porque
Esta V más grande dará como resultado una variación mayor para el tiempo de finalización del proyecto ,
lo que incitaría al administrador del proyecto cauteloso a agregar un margen de tiempo (o reserva de
cronograma) al cronograma del proyecto.
Prioridad de riesgo
Los proyectos están sujetos a numerosos riesgos, pero solo relativamente pocos pueden ser lo
suficientemente importantes como para merecer atención. Para decidir en qué riesgos enfocarse, la
gerencia puede especificar un nivel de consecuencia de riesgo esperado y abordar solo los riesgos en
ese nivel o superior. Por ejemplo, si el nivel se estableciera como consecuencia de 2 o más días de
retraso en el proyecto, solo se abordarían los riesgos S1, F1, T1, T3, I1, I2 e I3 en la Tabla 10.5 .
En función de las consecuencias de riesgo calculadas, las fuentes de riesgo se pueden enumerar en
un registro de riesgo o en un registro de riesgo, y aquellas con consecuencias de moderadas a altas se
pueden analizar detenidamente. Los miembros del equipo del proyecto, los gerentes, los subcontratistas
y los clientes revisan las fuentes y preparan respuestas apropiadas para ellas. La Tabla 10.6 ilustra un
registro de riesgo de ejemplo que muestra las fuentes de riesgo ordenadas por rango y las medidas de
mitigación.
Una desventaja de usar las consecuencias del valor esperado para priorizar los riesgos es que los
riesgos de muy baja probabilidad pueden ignorarse incluso cuando tienen consecuencias graves o graves.
impacto catastrófico. Supongamos, por ejemplo, que el impacto del fracaso de un proyecto es de 1000
muertes. Si la probabilidad de riesgo es infinitesimal, entonces la consecuencia esperada será muy
pequeña (pequeña probabilidad de muchas muertes) y, por lo tanto, el riesgo relegado a una baja
15
prioridad.
En un sistema complejo con un gran número de relaciones donde fallas conjuntas en varias de ellas
llevarían a la falla del sistema, es común ignorar tales fallas con la esperanza de que no ocurran. Por lo
general, la probabilidad de falla conjunta es muy baja. Sin embargo, muy bajo no es lo mismo que
imposible, y una falla con un impacto terrible nunca debe ignorarse, independientemente de cuán pequeño
sea el valor esperado. Por ejemplo, el accidente de la planta química en Bhopal, India, se ha atribuido a
más de 30 causas separadas, siendo su probabilidad conjunta tan pequeña que va más allá de la
comprensión. Sin embargo, todos ellos sucedieron, provocando un accidente que
dieciséis
provocó entre 1.800 y 10.000 muertos y entre 100.000 y 200.000 heridos.

De manera similar, la fusión nuclear en Chernobyl fue el resultado de seis errores en la acción humana,
cualquiera de los cuales, de haber estado ausente, habría impedido el accidente.
Pero a pesar de la minúscula probabilidad, los seis sucedieron, lo que resultó en un accidente que
inmediatamente causó varias docenas de muertes, varios cientos de hospitalizaciones y 135,000
evacuaciones, además de un estimado de 5,000 a 24,000 muertes por
17
cáncer en la antigua Unión Soviética y muchos más en Europa y Asia.
La lección: cualquier riesgo con un impacto severo nunca debe ignorarse, sin importar cuán pequeña sea
la probabilidad.
Cuadro 10.5 Probabilidad de riesgo, impacto del riesgo y consecuencia del valor esperado
Probabilidad Impacto (yo) Consecuencia: L ×

(L) (%) Días de retraso yo (días)
Software
S1 El diseño no cumple con los 20 10 2

requisitos iniciales
S2 Cambio en los requisitos del usuario 30 5 1.5
Hardware
H1 es 5 0.25
Retraso en el envío de hardware
Hardware incompatible con 5 10 0.5

programa H2
fondos
El proveedor de hardware va a la
F1 5 40 2
bancarrota
Fondos insufi cientes para el personal y

F2 5 15 0.7 5
los proveedores
Personal
T1 Escasez de personal 10 20 2
No puedo contratar/capacitar al
T2 15 10 1.5
personal adicional
T 3 Habilidadestécnicasinsufi cientes 10 30 3
instalación
H ardware incompatible con

I1 5 60 3
sistemas de usuario
Preparación adecuada del sitio del

yo 2 20 10 2
cliente
10.4 Planificación de la respuesta al riesgo
La planificación de la respuesta al riesgo aborda la cuestión de cómo abordar el riesgo. En general,

las formas de enfrentar un riesgo son transferir, evitar, reducir, aceptar o hacer un plan de
contingencia para el mismo.
Riesgo de transferencia
El riesgo se puede transferir entre clientes, contratistas y otras partes utilizando incentivos
contractuales, garantías, sanciones o seguros.
Seguro
El cliente o contratista compra un seguro para protegerse contra una amplia gama de riesgos,
incluidos los asociados con:
• Los daños materiales o personales sufridos como consecuencia de la

proyecto.
• Daños a los materiales durante el tránsito o almacenamiento.
Tabla 10.6 Registro de Riesgos

• Avería o daño del equipo. • Robo de

equipos y materiales. • Enfermedad o
lesión de trabajadores, gerentes y personal. •
Fluctuaciones en los tipos de cambio o “forward cover” (ver Capítulo 19).
Ver Capítulo 19
Trabajo subcontratado
Los riesgos surgen de la incertidumbre sobre cómo abordar un problema o situación.

Una forma de evitar ese riesgo es contratar contratistas que se especialicen en
manejar esos problemas o situaciones. Por ejemplo, para minimizar el riesgo financiero
asociado con el costo de capital de herramientas y equipos para la producción de un
sistema grande y complejo, un fabricante podría subcontratar la producción de los
componentes principales del sistema a proveedores familiarizados con esos
componentes. Esto libera al fabricante del riesgo financiero asociado con las herramientas y el equip
producir estos componentes. Pero como se mencionó, la transferencia de un tipo de riesgo a menudo
significa heredar otro tipo. Por ejemplo, al subcontratar el trabajo de los componentes, el fabricante ahora
debe depender de terceros, lo que aumenta los riesgos asociados con el control de calidad y la
programación. Pero tales riesgos a menudo pueden reducirse mediante una gestión cuidadosa de los
subcontratistas.
tipo de contrato
El riesgo puede transferirse o asignarse mediante el uso de un tipo de contrato adecuado, como se explica
en el Apéndice del Capítulo 3. Cuando la declaración del trabajo es clara e implica poca incertidumbre, el
contratista aceptará fácilmente un contrato de precio fijo . Un ejemplo sería la construcción de un muro
según un plano y especificaciones bien definidos, en cuyo caso el contratista percibe poco riesgo. Sin
embargo, cuando el alcance del trabajo no está claro y el potencial de cambio es grande, es menos
probable que el contratista se comprometa con un precio fijo y asuma el riesgo de un sobrecosto. En tales
casos, el contratista consideraría más apropiado un contrato de costo incrementado , ya que cubre todos
los gastos incurridos durante el proyecto.
Ver Capítulo 3
Mientras que en un contrato de precio fijo el contratista asume la mayor parte del riesgo de sobrecostos,
en un contrato de precio fijo con tarifa de incentivo el contratista acepta aproximadamente el 60 por ciento
del riesgo y el cliente el 40 por ciento. En un contrato de tarifa de costo más incentivo, el contratista asume
alrededor del 40 por ciento, el cliente el 60 por ciento. En un contrato de costo más tarifa fija (CPFF), el
cliente asume la mayor parte o la totalidad del riesgo de sobrecoste.
En proyectos grandes, se utiliza una variedad de contratos según el riesgo asociado con paquetes de
trabajo individuales o entregables. En el proyecto Chunnel, la parte más incierta fue la excavación bajo el
Canal de la Mancha; por lo tanto, esa parte de la obra fue contratada en régimen de CPFF. Los trabajos
eléctricos y mecánicos de los túneles y terminales se percibieron como de bajo riesgo y, por lo tanto, se
realizaron a un precio fijo. La adquisición del material rodante, percibida como un poco más riesgosa,
utilizó un contrato de tarifa de costo más porcentaje.18

No todos los riesgos pueden ser transferidos. Incluso con un contrato de precio fijo
en el que aparentemente el contratista asume el riesgo de sobrecostos, el cliente
incurrirá en daños y dificultades si el proyecto se retrasa o si el contratista se declara en
bancarrota. El proyecto aún debe completarse y alguien tiene que pagar por él. Para
evitar pérdidas, un contratista puede sentirse presionado a tomar atajos, lo que por
supuesto aumenta el riesgo del cliente de recibir un artículo final de calidad inferior a la
media. Para disminuir tales riesgos, el contrato debe estipular estrictas inspecciones de
calidad y sanciones.
Responsabilidad de riesgo
Debe especificarse el individuo o grupo responsable de cada riesgo particular en un

proyecto. Los riesgos pueden transferirse, pero nunca pueden “descargarse” por
completo. Una garantía o garantía especifica el momento o el lugar en el que se
transfiere el riesgo de una parte a otra. Por ejemplo, cuando un artículo se adquiere y
se envía desde el extranjero, el riesgo de daño generalmente permanece con el
vendedor mientras el artículo esté en el barco; tan pronto como se iza sobre la borda
del barco, el riesgo se transfiere al comprador.
Una parte dispuesta a aceptar la responsabilidad de un alto riesgo en un proyecto
normalmente exigirá un alto nivel de autoridad sobre el proyecto. Un cliente que acepte
el riesgo de una mala calidad o de un sobrecoste casi con certeza insistirá en una gran
medida de control sobre los aspectos del proyecto que influyen en la calidad y el costo.
Las partes que corren un alto riesgo generalmente también insistirán en una
compensación para cubrir los riesgos. El contrato CPFF ilustra: el riesgo del contratista
está cubierto por la compensación de todos los gastos, pero el riesgo del cliente está
cubierto por la supervisión de la gerencia del contratista para evitar abusos.
Evite el riesgo
El riesgo se puede evitar con medidas tales como aumentar la supervisión, eliminar las
actividades riesgosas, minimizar la complejidad del sistema, alterar los requisitos de
calidad del artículo final, cambiar los contratistas e incorporar redundancias. Pero los
intentos de evitar el riesgo a menudo implican la adición de innumerables métodos de gestión.
controles y sistemas de seguimiento, que tienden a aumentar la complejidad del sistema y,

perversamente, introducen nuevas fuentes de riesgo. Las medidas para evitar riesgos también
pueden disminuir las oportunidades de rentabilidad. Muchos factores de riesgo pueden evitarse,
pero no todos, especialmente en proyectos complejos o de vanguardia. Los proyectos de
investigación y desarrollo de nuevos productos son inherentemente riesgosos, pero ofrecen un
potencial para obtener enormes beneficios más adelante. Debido a que el tamaño del riesgo a
menudo es proporcional al beneficio potencial, en lugar de evitar el riesgo, es mejor tratar de reducir el riesgo a un n
Reducir el riesgo
19
Entre las formas de reducir el riesgo técnico (su probabilidad, impacto o ambos) se encuentran:
• Emplear el mejor equipo técnico. •

Basar decisiones en modelos y simulaciones de parámetros técnicos clave. • Usar
herramientas maduras de ingeniería de sistemas asistidas por computadora. • Utilice el
desarrollo paralelo en tareas de alto riesgo. • Proporcionar al equipo técnico incentivos
para el éxito. • Contratar especialistas externos para la revisión crítica y la evaluación
del trabajo. • Realizar extensas pruebas y evaluaciones. • Minimizar la complejidad del

sistema. • Utilice márgenes de diseño.
Los dos últimos puntos merecen una explicación más detallada. En general, el riesgo y la
incertidumbre del sistema aumentan con la complejidad del sistema: cuantos más elementos hay
en un sistema y más interconectados están, más probable es que un elemento o una interconexión
salga mal. Por lo tanto, minimizar la complejidad a través de la reorganización y modificación de
elementos en el diseño del producto y las tareas del proyecto reduce el riesgo. Por ejemplo, el
desacoplamiento de actividades y subsistemas, es decir, hacerlos independientes entre sí, evita
que una falla en cualquier actividad o subsistema se propague a otras.
La incorporación de márgenes de diseño en los objetivos de diseño es otra forma de reducir el

20
riesgo asociado con el cumplimiento de los requisitos técnicos. Un margen de diseño es un
valor cuantificado que sirve como un amortiguador de seguridad mantenido en reserva y asignado
por la gerencia. En general, un margen de diseño se incorpora a un requisito por
establecer el valor de diseño objetivo para que sea más rígido o más riguroso que el requisito
de diseño. En particular:
Valor objetivo = Requisito + Margen de diseño
Al esforzarse por cumplir con un valor objetivo que es más rígido que el requisito, se reduce el
riesgo de no cumplir con el requisito.
Ejemplo 10.4: Aplicación de margen de diseño para

la nave espacial
El requisito de peso para el sistema de navegación de la nave espacial es de 90 libras.

Para tener en cuenta la dificultad de cumplir con el requisito (y el riesgo de no cumplirlo),
el margen de diseño se establece en 10 por ciento o 9 libras. Por lo tanto, el peso objetivo
para el sistema de navegación se convierte en 81 libras.
También se aplica un margen de diseño a cada subsistema o componente dentro del
sistema. Si el sistema de navegación se compone completamente de tres subsistemas
principales, A, B y C, entonces los tres juntos deben pesar 81 libras.
Supongamos que C es un artículo OTS con un peso de 1 libra que es fijo y no se puede
reducir. Pero A y B se están desarrollando recientemente, y sus objetivos de diseño se
han fijado en 50 libras para A y 30 libras para B. Suponga que se impone un margen de
diseño del 12 por ciento en ambos subsistemas; por lo tanto, los pesos objetivo para A y
B son 50 (1,0 ÿ 0,12) = 44 libras y 30 (1,0 ÿ0,12) = 26,4 libras, respectivamente.
Los márgenes de diseño brindan a los gerentes e ingenieros una forma de abordar
los problemas en un diseño en evolución. Si el valor objetivo para un subsistema resulta
imposible de cumplir, entonces se pueden reasignar al subsistema partes de los valores
de margen de otros subsistemas o del sistema en general.
Suponga que el subsistema B no puede diseñarse para alcanzar su objetivo de 26,4 lb,
pero el subsistema A puede diseñarse para alcanzar su objetivo; por lo tanto, el objetivo
de B se puede aumentar hasta en 3,6 libras (su valor de margen) a 30 libras; si ese valor
también resulta imposible de cumplir, el objetivo se puede aumentar en otras 6 libras (el
valor del margen original del subsistema A) a 36 libras. Incluso si no se puede alcanzar
ese valor, el objetivo se puede aumentar de nuevo hasta otras 9 libras (el
valor de margen para todo el sistema) a 45 lbs. Incluso con estas adiciones incrementales al valor objetivo inicial
de B, el sistema en general aún cumpliría con el requisito de peso de 90 libras.
Si bien los márgenes de diseño ayudan a reducir el riesgo de no cumplir con los requisitos, alientan a los diseñadores
a exceder los requisitos, por ejemplo, a diseñar sistemas que pesan menos de lo requerido. Por supuesto, los márgenes
deben establecerse cuidadosamente para reducir los riesgos sin aumentar los costos.
Los márgenes de diseño se centran en los riesgos asociados con el cumplimiento de los requisitos técnicos.
21
Entre las formas de reducir los riesgos asociados con los horarios de las reuniones se encuentran:
• Cree un cronograma maestro del proyecto y esfuércese por cumplirlo. • Programe las
tareas más riesgosas lo antes posible para dar tiempo al fracaso
recuperación.
• Mantener un enfoque estrecho en las actividades críticas y casi críticas. •
Ponga a los mejores trabajadores en tareas de tiempo crítico.
• Proporcionar incentivos para el trabajo de horas extras.
• Cambiar las actividades de alto riesgo en la red del proyecto de serie a paralelo. • Organizar el proyecto
con anticipación y dotarlo de personal adecuado. • Proporcionar amortiguadores de alimentación y
proyectos (reservas de contingencia), como se explica en
Capítulo 7.
Ver Capítulo 7
22
Para reducir el riesgo asociado con el cumplimiento de los objetivos presupuestarios o de costos :
• Identificar y monitorear los factores clave de costos. • Utilizar
revisiones y evaluaciones de alternativas de diseño de bajo costo. • Verificar el diseño
y el rendimiento del sistema a través del modelado y la evaluación. • Maximizar el uso de tecnología comprobada
y comercial listo para usar
equipo. •
Proporcionar reservas para contingencias en los presupuestos de los
proyectos. • Realice protoboarding temprano, creación de prototipos y pruebas en riesgos
componentes
La última forma es especialmente poderosa para reducir el riesgo. Las placas de prueba y los prototipos, es
decir, las maquetas y los modelos de prueba, permiten que las ideas se prueben experimentalmente para que
de que se puedan corregir más adelante en una etapa

lostemprana
diseños 23
delEsto
proyecto.
reducecambios
en grande
medida
diseño,
laque
necesidad
pueden
ser costosos. A continuación se ilustran otras formas de reducir el riesgo.
Ejemplo 10.5: Gestión del riesgo de horarios y costos en

24
el aeropuerto de Vancouver
El proyecto de expansión del Aeropuerto Internacional de Vancouver implicó la construcción de un nuevo

edificio terminal internacional (ITB) y una pista paralela. El cronograma para el proyecto de $355 millones
requería la operación total de la ITB en menos de 3,5 años después de la aprobación del proyecto y la
apertura de la nueva pista 5 meses después de eso. El equipo del proyecto identificó los siguientes
riesgos principales para cumplir con el ajustado presupuesto y cronograma
restricciones:
1. Riesgo en la entrega y montaje de acero estructural. Los largos plazos de entrega de las
acerías y las dificultades en la programación del diseño, la fabricación y el montaje hacen
que los grandes proyectos de acero sean riesgosos. Reconociendo esto, el equipo del
proyecto otorgó el contrato de acero estructural muy temprano en el proyecto para permitir
suficiente tiempo para diseñar, adquirir, fabricar y erigir las 10,000 toneladas de acero
requeridas para la ITB. Como resultado, la ITB se completó a tiempo.
2. Riesgo de manipulación de materiales. Se tuvieron que mover millones de metros cúbicos

(cum) de tierra y se requirieron más de 4 millones de cum de arena para las pistas de
aterrizaje y de rodaje de concreto. El equipo del proyecto desarrolló un plan avanzado para
permitir el movimiento coordinado de la tierra de un lugar a otro y utilizó arena local en el

hormigón. Esto ahorró mucho tiempo y dinero, lo que permitió que la pista se completara un
año antes de lo previsto.
3. Riesgo ambiental. Las excavaciones y el transporte de tierra y arena en barcazas amenazaron

la ecología del estuario del río Fraser. Estas
los riesgos se mitigaron mediante la planificación anticipada y la identificación y el

manejo constantes de los problemas a medida que surgían a través de los esfuerzos
cooperativos de todas las partes interesadas.
4. Riesgo de funcionalidad. Debido a que las nuevas tecnologías representan un riesgo,
el equipo del proyecto adoptó la política de usar solo tecnología y componentes
probados (OTS) siempre que sea posible. En consecuencia, todos los sistemas ITB
se instalaron con pocos problemas y estuvieron operativos de acuerdo con el
cronograma.
Una forma adicional de reducir el riesgo de no cumplir con los presupuestos, los cronogramas y
el desempeño técnico es hacer lo que sea necesario para lograr los requisitos. 25 El equipo del
hacerse más allá de los
proyecto
requisitos
puede
establecidos,
estar al tanto
perodeenmuchas
la mayoría
cosasdeque
los casos
podrían
esto
pero
consumirá
nada más.
recursos adicionales y agregará tiempo y costo. A menos que el cliente apruebe el tiempo y el costo
adicional, estas cosas deben evitarse.
Planificación de contingencias
La planificación de contingencia implica anticipar cualquier riesgo que pueda surgir y luego preparar
un curso de acción para enfrentarlo. Se sigue el plan inicial del proyecto, pero a lo largo de la
ejecución se supervisan de cerca los riesgos. En caso de materializarse un riesgo indicado por un
síntoma desencadenante, se adopta la acción de contingencia.
La contingencia puede ser una acción correctiva post-hoc para compensar el impacto del riesgo, una
acción emprendida en paralelo con el plan original o una acción preventiva iniciada por un síntoma
desencadenante para mitigar el impacto del riesgo. Se pueden desarrollar múltiples planes de
contingencia basados en escenarios hipotéticos para los múltiples riesgos.
Aceptar riesgo (no hacer nada)
No todos los impactos son severos. Si el costo de evitar, reducir o transferir la

se estima que el riesgo excede los beneficios, entonces “no hacer nada” podría ser la mejor
alternativa. En la Figura 10.4, la estrategia de no hacer nada se elegiría para los riesgos que
caen en la región de “consecuencias bajas” (excepto cuando el impacto es potencialmente
catastrófico, lo cual está fuera del gráfico). A veces no se puede hacer nada para evitar,
reducir o transferir un riesgo, en cuyo caso se debe aceptar el riesgo, independientemente
de la consecuencia. Afortunadamente tales situaciones son raras.
Responder a un riesgo a veces crea un nuevo riesgo secundario (vea el Ejemplo 11.1 en
el próximo capítulo). Al planificar las respuestas a los riesgos, el equipo de gestión del
proyecto debe verificar dichos riesgos antes de implementar el plan.
Ver Capítulo 11
10.5 Seguimiento y respuesta al riesgo
Los riesgos identificados se documentan y enumeran en el registro de riesgos o en el registro de

riesgos y se ordenan por rango, con la mayor consecuencia de riesgo primero. Para los riesgos
con consecuencias más graves, se elaboran planes de mitigación y se adoptan estrategias
(transferir, reducir, evitar o contingencia); para los de poca o ninguna trascendencia, no se hace
nada (aceptar).
El proyecto debe ser monitoreado continuamente en busca de síntomas de riesgos previamente
identificados, así como también de nuevos riesgos emergentes (no identificados previamente).
Los riesgos conocidos pueden tardar mucho tiempo antes de que comiencen a producir
problemas. Si un síntoma llega al punto desencadenante, se toma una decisión sobre el curso
de acción, que podría ser instituir un plan preparado u organizar una reunión para elegir una
solución. A veces la respuesta es no hacer nada; sin embargo, nada debe ser una elección
consciente, no un descuido, y se debe realizar un seguimiento posterior para garantizar que fue
la elección correcta.
Todos los riesgos considerados críticos o importantes se rastrean a lo largo del proyecto o las
fases a las que se aplican; para garantizar esto, se asigna a alguien la responsabilidad de
rastrear y monitorear los síntomas de cada riesgo importante.
En conjunto, el registro de riesgos, las estrategias de mitigación, los métodos de seguimiento,
los responsables, los planes de contingencia y las reservas de cronograma y presupuesto
constituyen el plan de gestión de riesgos del proyecto. El plan se actualiza continuamente para
tener en cuenta los cambios en el estado del riesgo (riesgos antiguos evitados, degradados o
mejorados; riesgos existentes reevaluados; nuevos riesgos agregados). Se alerta al director del
proyecto (ya veces a otros directores y al cliente) sobre problemas emergentes; idealmente, la
cultura del proyecto encarna la franqueza y la honestidad, y las personas notifican fácilmente al
gerente del proyecto cada vez que detectan la materialización de un riesgo conocido o el
surgimiento de uno nuevo.
10.6 La gestión de proyectos es gestión de riesgos
La gestión de riesgos complementa y forma parte de otras prácticas de gestión de proyectos,

como los requisitos y la definición del trabajo, la programación, la elaboración de presupuestos,
la gestión de la configuración, el control de cambios y el seguimiento y control del rendimiento.
Con todo esto, los gerentes identifican y evalúan los riesgos para poder reducirlos de manera
proactiva o planificar las consecuencias. Si, por ejemplo, un proyecto debe completarse en 9
meses pero se estima que tardará más de 12, la gerencia puede tomar una multitud de pasos
para aumentar la probabilidad de que termine en 9.
Idealmente, la identificación de riesgos, la evaluación y la planificación de la respuesta se
tratan como un aspecto formal de la planificación del proyecto, y el plan de gestión de riesgos
resultante se integra como parte del plan maestro de ejecución junto con el cronograma, el
presupuesto, el plan de gestión de la calidad, el control de cambios y la gestión de la configuración.
plan, plan de comunicaciones, etc. Durante la ejecución del proyecto, el seguimiento de riesgos
se incorpora como una medida en el proceso de seguimiento y control del proyecto. Idealmente,
muchos miembros del equipo del proyecto y otras partes interesadas participan en la identificación
de riesgos, la planificación de respuestas y el seguimiento de riesgos.
Por supuesto, no todos los proyectos necesitan una gestión integral de riesgos. En proyectos
pequeños, un personal pequeño, bien pagado y motivado generalmente puede superar las
dificultades asociadas con los riesgos y, si no, las consecuencias suelen ser pequeñas de todos modos.
Sin embargo, en proyectos más grandes, donde hay mucho en juego y los riesgos de fracaso, la
gestión de riesgos es especialmente importante. Estos proyectos requieren conciencia y respeto
por todos los riesgos significativos: de seguridad, legales, sociales y políticos, así como técnicos
y financieros.
Principios de gestión de riesgos
Cada proyecto para el cual se conocen o sospechan riesgos no triviales debe tener un plan de
gestión de riesgos. El plan debe especificar, para un proyecto en particular, los procedimientos
para identificar y evaluar los riesgos, la(s) persona(s) involucrada(s) en el proceso de gestión de
riesgos y las responsabilidades específicas, los métodos para evaluar y
priorización de riesgos, pautas para la mitigación de riesgos y planificación de contingencias, y

métodos para rastrear y reportar riesgos y abordar riesgos emergentes e imprevistos. El plan
debe abordar los principios generales para la gestión de riesgos, como los siguientes:
26
• Crear un perfil de riesgo para cada fuente de riesgo; esto incluye la probabilidad de
riesgo, el costo y el impacto en el cronograma, y las contingencias a invocar. El perfil
también debe especificar los primeros síntomas visibles (eventos desencadenantes)
que indicarían cuándo se está materializando el riesgo. En general, las fuentes de alto
riesgo deben tener muchos ojos observando de cerca, y los planes de contingencia
deben actualizarse para reflejar el progreso del proyecto y los riesgos emergentes. La
figura 10.5 ilustra la plantilla para un perfil de riesgo: un resumen de todo lo que se
sabe sobre un riesgo. Este documento se mantendría en una carpeta o biblioteca,
actualizado según sea necesario hasta que se crea que el riesgo ya no existe y se
“cierra”.
• Designar un oficial de riesgos para el proyecto, alguien cuya responsabilidad principal
sea la gestión de riesgos del proyecto. Esta no debe ser la misma persona que el
director del proyecto; no debe ser una persona que pueda hacer nada, sino un abogado
del diablo, identificando y rastreando todas las razones por las que algo podría no
funcionar, incluso cuando todos los demás creen que funcionará. • Incluya en el
presupuesto y programe una reserva de riesgo calculada: una reserva de dinero, tiempo
y otros recursos para hacer frente a los riesgos en caso de que se materialicen. La
reserva se utiliza a discreción del director del proyecto para cubrir riesgos no
especificados por el perfil de cada riesgo. Puede incluir los valores RT o RC (descritos
en el Apéndice del capítulo) u otras cantidades. Por lo general, no está asociado con
un plan de contingencia y su uso puede estar limitado a aplicaciones particulares o
áreas de riesgo. El gerente del proyecto mantiene estrictamente confidenciales las
cantidades exactas que se mantienen en las reservas (de lo contrario, un proyecto
tenderá a consumir cualquier cantidad disponible), aunque otros deben saber que hay
una reserva disponible (de lo contrario, construirán sus propias reservas secretas ).
• Establezca canales de comunicación (quizás anónimos) dentro del equipo del proyecto
para garantizar que cualquier mala noticia llegue rápidamente al gerente del proyecto,
los riesgos se controlen continuamente y el estado del riesgo se evalúe continuamente.
y comunicado.
• Especificar los procedimientos para garantizar una documentación precisa y completa
de las propuestas, los planes detallados del proyecto, las solicitudes de cambio, los
informes de progreso y el informe de resumen posterior a la finalización. En general,
cuanto mejor sea la documentación de proyectos pasados, más información estará
disponible para planificar proyectos futuros similares e identificar posibles riesgos.
Esperar lo inesperado
Habiendo identificado innumerables peligros y consecuencias de riesgo y preparado todo tipo

de controles y salvaguardas, se puede hacer creer a las personas que todo lo que posiblemente
podría salir mal ha sido anticipado y cubierto; por lo tanto, cuando algo todavía sale mal, los
toma completamente desprevenidos. Si bien es cierto que la planificación de riesgos puede
cubrir muchos o la mayoría de los riesgos, nunca podrá cubrirlos todos. Por lo tanto, la
planificación de riesgos debe
Figura 10.5 Documento para el perfil y plan de respuesta de un riesgo identificado.
moderarse con el concepto de “no planificación” o el enfoque de Napoleón, que consiste

en esperar que algo saldrá mal y estar listo para encontrar formas de enfrentarlo a
medida que surja. Esto es tan importante para hacer frente al riesgo como lo es una
planificación exhaustiva y creer que se han cubierto todos los riesgos. 27
Ejemplo 10.6: Gestión de riesgos a medida

que surgen: desarrollo del F117 Stealth Fighter 28
Un ejemplo de cómo gestionar el riesgo en proyectos de I+D es el F117 Stealth

Programa de combate, cuyo objetivo es desarrollar un nuevo y revolucionario avión

"poco observable" (difícil de detectar con radar) capaz de ataques de alta precisión
contra objetivos enemigos. El F117 implicó un alto riesgo porque se tuvieron que
aprender muchas lecciones durante el programa y se tuvieron que superar desafíos importantes.
Pero los administradores del programa esperaban desafíos a lo largo del programa,
desde el diseño y la prueba iniciales hasta la evaluación y la implementación final. Para
gestionar los riesgos, se tomaron numerosas decisiones sobre el terreno entre los
directores de programa de Lockheed (contratista) y la Fuerza Aérea (cliente).
El programa se estableció para el despliegue rápido de recursos para resolver los
problemas a medida que surgieran. Los gerentes del cliente y del contratista trabajaron
en estrecha colaboración para minimizar las demoras burocráticas. Los cronogramas
eran optimistas y se basaban en suposiciones de que todo funcionaría; sin embargo,
todos a lo largo de la cadena de gestión conocían los riesgos y los desafíos a superar,
por lo que los problemas nunca fueron una sorpresa ni amenazaron el apoyo del
programa. Este es un buen ejemplo de administrar el riesgo en lugar de evitar el riesgo.
Advertencias de gestión de riesgos
Por todo lo bueno que puede proporcionar, la gestión de riesgos puede crear riesgos. Casi
todas las filosofías, procedimientos o prescripciones tienen advertencias, y eso también se
aplica a la gestión de riesgos. Los malentendidos o la mala aplicación de los conceptos de
gestión de riesgos pueden obstaculizar un proyecto al hacer creer a las personas que no
tienen nada de qué preocuparse, lo que en realidad puede dejarlos peor preparados para
enfrentar problemas emergentes que no anticiparon.
Habiendo creado un plan de gestión de riesgos, los gerentes pueden animarse a tomar
riesgos que de otro modo no podrían tomar. Gran parte del aporte al análisis de riesgos es
subjetivo; aborda lo que podría suceder, no lo que sucederá. El análisis y la planificación de
datos les da a las personas la sensación de tener poder sobre los eventos, incluso cuando los
eventos son arriesgados. Subestimar la probabilidad de riesgo o el impacto puede hacer que
las consecuencias parezcan insignificantes, lo que lleva a algunas personas a aventurarse en
un territorio peligroso que el sentido común no permitiría. Por ejemplo, la seguridad de los
cinturones de seguridad y las bolsas de aire alienta a algunos conductores a correr riesgos,
como conducir demasiado cerca del próximo automóvil o acelerar con las luces amarillas. El resultado es un
mayor probabilidad de un accidente.

La experiencia repetida y la buena documentación son formas vitales de identificar los
riesgos, pero no pueden garantizar que se identificarán todos los riesgos importantes. Los
resultados iguales y similares que han ocurrido repetidamente en proyectos anteriores
eventualmente agotan la capacidad de las personas para imaginar que suceda algo más.
Como resultado, algunos riesgos se vuelven impensables. Incluso los modelos informáticos
sofisticados son inútiles cuando se trata de lidiar con lo impensable porque no se puede instruir
a una computadora para que analice situaciones que están más allá de la imaginación humana.
La experiencia proporciona sólo una muestra de posibilidades, no toda la población.
Gestionar el riesgo no significa eliminarlo, aunque algunos gestores no lo sepan. El primer
síntoma de “intentar eliminar el riesgo” es la microgestión: controles y requisitos de
documentación excesivos, y exigencias triviales de autorización de todo. Los proyectos
implican inherentemente incertidumbre y riesgo. La microgestión rara vez es apropiada y para
algunos proyectos puede ser desastrosa, particularmente cuando los proyectos involucran lo
nuevo, lo no probado y lo no probado. Cuando la gerencia trata de eliminar el riesgo, sofoca la
innovación y, según Aronstein y Piccirillo, “obliga a una empresa a adoptar un enfoque
tecnológico laborioso y de fuerza bruta, que puede ser mucho más costoso a largo plazo que
un enfoque más aventurero en el que algunos programas fallan. pero otros dan saltos
significativos hacia adelante”. 29 La estrategia adecuada de gestión de riesgos para la mayoría
de los proyectos es intentar acomodar y mitigar el riesgo, no evitarlo o eliminarlo.
10.7 Resumen
La gestión de riesgos del proyecto implica identificar los riesgos, evaluarlos y planificar la adopción de las
respuestas adecuadas. La identificación de los riesgos del proyecto comienza en la fase de concepción del
proyecto. Los riesgos del proyecto provienen de muchas fuentes, como la falta de definición y satisfacción de
las necesidades del cliente o los requisitos del mercado, los problemas técnicos que surgen en el trabajo, el
clima, los problemas laborales y de proveedores, las acciones de los competidores y los cambios impuestos
por terceros. Dichos peligros de riesgo se identifican utilizando una variedad de métodos y se basan en la
experiencia con proyectos anteriores y el escrutinio de proyectos planificados.
De los innumerables riesgos en los proyectos, solo se deben abordar los importantes.
La importancia depende de la probabilidad, el impacto y la consecuencia general del riesgo. La probabilidad
es la probabilidad de que ocurra un riesgo, el impacto es el efecto del riesgo; consecuencia de riesgo es una
combinación de los dos. En general, las medidas de consecuencia del riesgo se utilizan para decidir qué
riesgos deben recibir atención y cuáles pueden ignorarse. Sin embargo, como precaución, todos los riesgos
con impacto severo deben ser considerados cuidadosamente, incluso cuando la probabilidad es muy pequeña.
La planificación de la respuesta al riesgo aborda las formas en que se manejarán los riesgos identificados.
Algunos riesgos pueden transferirse a otras partes o distribuirse entre muchas partes interesadas o
subcontratistas. Algunos se pueden evitar; algunos deben ser eliminados.
Pero a veces, un alto riesgo se asocia con grandes beneficios, y tratar de eliminar el riesgo también puede
reducir la rentabilidad. Por lo tanto, mejor que tratar de eliminar el riesgo es tratar de reducirlo a un nivel
manejable. Para áreas de alto riesgo, se deben desarrollar planes de contingencia alternativos.
Los principios para la gestión de riesgos incluyen la creación de un plan de gestión de riesgos que
especifique los riesgos, sus síntomas y planes de respaldo, un puesto de oficial de riesgos responsable de
identificar y rastrear los riesgos, y una reserva de presupuesto y cronograma. El plan debe especificar las
formas de monitorear los riesgos y los problemas emergentes, y comunicarlos al gerente del proyecto. La
documentación adecuada de proyectos anteriores proporciona lecciones aprendidas y advierte a los gerentes
sobre los riesgos potenciales en los próximos proyectos. Ninguna cantidad de preparación puede anticipar
todos los riesgos; Los gerentes deben esperar lo inesperado y estar preparados para enfrentar los riesgos a
medida que
surgir.
El siguiente Apéndice analiza los métodos analíticos comunes para evaluar las
consecuencias del riesgo y decidir entre respuestas alternativas al riesgo. Se emplean
métodos similares en la selección de proyectos, el tema del Capítulo 18.
Ver Capítulo 18
Apéndice: Métodos de análisis de riesgos
Cuatro métodos comunes para el análisis de riesgos son el valor esperado, los árboles de decisión,
las tablas de pagos y la simulación.
Valor esperado
La selección de la respuesta adecuada al riesgo a veces depende de las consecuencias del riesgo
expresadas en términos del valor esperado de los costos y calendarios.
Un valor esperado es el resultado promedio o promedio de numerosas circunstancias repetidas.
Para la evaluación de riesgos, el valor esperado representa el resultado promedio de un proyecto si
se repitiera muchas veces, teniendo en cuenta la posible ocurrencia del riesgo. Matemáticamente es
el promedio ponderado de todos los posibles resultados, donde los pesos son las probabilidades de
los posibles resultados, es decir
Valor esperado = ÿ[(Resultados) × (Probabilidades)]
La consecuencia del riesgo sobre la duración del proyecto, denominada tiempo de riesgo, RT, es el
valor esperado del tiempo estimado para corregir el riesgo, calculado como
La consecuencia del riesgo sobre el costo del proyecto, denominada costo del riesgo, RC, es el valor
esperado del costo estimado para corregir el riesgo, calculado como
Por ejemplo, suponga que el tiempo estimado de referencia (BTE) para la finalización del proyecto es
de 26 semanas y el costo estimado de referencia (BCE) es de $71 000. Suponga que la probabilidad
de riesgo para el proyecto como un todo es 0,3 y, si el riesgo se materializa, el proyecto se retrasaría
5 semanas y costaría $10 000 más. Como la probabilidad de que el riesgo se materialice es 0,3, la
probabilidad de que no se materialice es 0,7. Si el riesgo no se materializa, no serán necesarias
medidas correctoras y el tiempo y coste de la corrección será nulo. Por eso
TR = (5)(0,3) + (0)(0,7) = 1,5 semanas,
RC = ($10,000)(0.3) + (0)(0.7) = $3,000
Estas cifras, RT y RC, son la reserva del cronograma y la contingencia del proyecto (reserva
presupuestaria), respectivamente, mencionadas en los Capítulos 7 y 8.
Teniendo en cuenta el tiempo de riesgo, el tiempo esperado de finalización del proyecto, ET, es
ET = BTE + RT = 26 + 1,5 = 27,5 semanas.
Contabilizando el costo del riesgo, el costo esperado de finalización del proyecto, EC, es
EC = BCE + RC = 71,000 + 3,000 = $74,000
Cuando no se puede estimar el tiempo y el costo correctivos, entonces ET y EC se

calculan como
Estos ejemplos dan cuenta de los factores de riesgo que afectan al proyecto en su conjunto.
Otra forma de determinar la consecuencia del riesgo es primero desagregar el proyecto
en paquetes de trabajo o fases y luego, para cada una , estimar la probabilidad del
riesgo y el tiempo y costo correctivo. Estas estimaciones individuales luego se agregan
para determinar ET y EC para todo el proyecto. Este enfoque tiende a dar estimaciones
de RT y RC más creíbles que las ecuaciones (10.6) a (10.9) porque los riesgos así
identificados en tareas o fases individuales pueden evaluarse con mayor precisión, y
las acciones correctivas necesarias y el tiempo y los costos asociados para tareas
particulares son más fácil de identificar.
Digamos que un proyecto tiene ocho paquetes de trabajo; la siguiente tabla enumera la
información de costos y EC para cada uno, donde EC se calcula como
EC = BCE + [(costo correctivo) × (probabilidad)]

Como se muestra en la tabla, el EC para el proyecto es de $84,850.

Ahora, para el mismo proyecto de ocho paquetes de trabajo, la siguiente tabla da tiempo
información, donde ET se calcula como
ET = BTE + [(Tiempo de corrección) × (Probabilidad)]
Elemento WBS Costo correctivo BCE Probabilidad CE
j $10,000 $ 2,000 .2 $10,400

METRO
8,000 1,000 .3 8,300
V 16,000 4,000 .1 16,400
Y 10,000 6,000 .2 11,200
L 8,000 2,000 .3 8,600
q 9,000 2,000 .1 9,200

W 5,000 1,000 .3 5,450
X 5,000 1,500 .3 5,750
Total $71,000 $84,850
Elemento PEP BTE Tiempo correctivo ET de probabilidad
j 6 1 .2 6.2
METRO 4 1 .3 4.3
V 6 2 .1 6.2
Y 8 3 .2 8.6
L 2 1 .3 2.3
q 8 1 .1 8.1
W 1 1 .3 1.3
X 1 1 .3 1.3
Suponga que la red del proyecto es como se muestra en la Figura 10.6. No considerar el riesgo
tiempo, la ruta crítica sería J–M–V–Y–W–X, lo que da un proyecto BTE de 26
semanas. Contabilizando las consecuencias del riesgo, la ruta crítica no cambia pero
30
la duración aumenta a 27,9 semanas. Este es el proyecto ET.
Figura 10.6 Red de proyectos, teniendo en cuenta el tiempo de riesgo.
Aunque las actividades en rutas críticas y casi críticas deben monitorearse cuidadosamente,
en general, todas las actividades con consecuencias de alto riesgo (alta probabilidad y/o alto
impacto) también deben monitorearse cuidadosamente, incluso cuando no se encuentran en la
ruta crítica.
Aumentar el cronograma y el presupuesto del proyecto para tener en cuenta el tiempo de
riesgo esperado o el costo del riesgo no es garantía de una protección adecuada contra el riesgo.
El tiempo y el costo de riesgo esperados son equivalentes a los promedios a largo plazo, que
resultan de repetir algo muchas veces; esto es cuestionable en los proyectos, ya que rara vez se
repiten idénticamente las actividades del proyecto.
31
Árboles de decisión
Un árbol de decisión es un diagrama en el que las "ramas" del árbol representan diferentes
resultados aleatorios. Se utiliza para evaluar qué respuesta al riesgo entre las alternativas produce
la mejor consecuencia esperada.
Una aplicación de los árboles de decisión es sopesar el costo del posible fracaso del proyecto
frente al beneficio del éxito del proyecto. Suponga que un proyecto tiene un BCE de $200 000,
una probabilidad de fracaso de 0,25 y, si tiene éxito, generará una ganancia neta de $1 000 000.
El concepto de valor esperado se puede utilizar para calcular el valor promedio del proyecto.
Suponiendo que el proyecto pudiera repetirse muchas veces, entonces perdería $200,000 (BCE)
el 25 por ciento del tiempo y generaría $1,000,000 de ganancias el otro 75 por ciento. Por lo
tanto, el resultado esperado sería
Resultado esperado = (–$200 000)(0,25) + ($1 000 000)(0,75) = $700 000.

Esto sugiere que, aunque existe la posibilidad de obtener $1 000 000 netos, es más razonable utilizar
$700 000 para el BCE. También sugiere que todos los costos del proyecto más las acciones tomadas
para reducir o eliminar el riesgo de falla no deben exceder los $700,000.
Otra aplicación de los árboles de decisión es decidir entre respuestas de riesgo alternativas. Suponga
que un proyecto tiene un BCE de $ 10 millones, una probabilidad de falla de riesgo de 0.6 y un impacto
de riesgo de $ 5 millones. Se están considerando dos estrategias para reducir la probabilidad de riesgo
(pero no el impacto del riesgo):
La estrategia 1 costará $2 millones y reducirá la probabilidad de falla a 0.1.

La estrategia 2 costará $1 millón y reducirá la probabilidad de falla a 0.4.
El árbol de decisiones y los costos esperados del proyecto resultantes se muestran en la figura 10.7.
El análisis sugiere que se debe adoptar la Estrategia 1 porque tiene el costo esperado más bajo.
Otra aplicación del análisis del árbol de decisiones es el método del valor comercial esperado que
se usa en la selección de proyectos, discutido en el Capítulo 18.
Ver Capítulo 18
Tablas de incertidumbre y pagos

Figura 10.7 Árbol de decisión.
Cuando no hay experiencia previa o datos históricos sobre los cuales estimar la probabilidad,
entonces la consecuencia del riesgo de valor esperado no se puede calcular y se deben usar
otros criterios para evaluar los cursos de acción frente al riesgo. Esta situación se denomina
incertidumbre, lo que implica que no se dispone de información sobre lo que podría ocurrir.
Para determinar la mejor estrategia bajo incertidumbre, comience identificando posibles caminos
alternativos que el proyecto podría tomar en respuesta a factores sobre los cuales la gerencia
no tiene control. Estos diferentes caminos se denominan estados de naturaleza. Considere
diferentes estrategias o acciones posibles y luego indique el resultado probable para cada
estado de la naturaleza. Los resultados de diferentes combinaciones de estrategias y estados
de la naturaleza se representan en una tabla de pagos.
Por ejemplo, suponga que el éxito de un proyecto para desarrollar el Producto X depende de
la demanda del mercado, que se sabe que es una función de las características de desempeño
particulares del producto. El esfuerzo de desarrollo se puede dirigir en cualquiera de las tres
direcciones posibles, denominadas estrategias A, B y C, cada una de las cuales proporcionará
al producto características de rendimiento diferentes. Suponga también que una empresa
competidora está desarrollando un producto que tendrá características de desempeño similares
a las de la estrategia A. Cuando finalice el esfuerzo de desarrollo del producto, existirá uno de
los tres estados de la naturaleza futuros: N1: ningún producto de la competencia ingresa al
mercado durante al menos 6 meses; N2: el producto de la competencia ingresa al mercado
dentro de los 6 meses posteriores al Producto X; N3: el producto de la competencia se introduce
antes que el Producto X. Suponga que se calculan las ganancias probables en millones de
dólares para las diferentes combinaciones de estrategias y estados de la naturaleza (que se
muestran en la Tabla 10.7).
La pregunta: ¿Qué estrategia se debe adoptar? La respuesta: ¡Depende! Si los patrocinadores
del proyecto son optimistas, elegirán la estrategia que maximice el beneficio potencial. El pago
potencial máximo en la tabla es de $ 90 millones, lo que sucede para la Estrategia C y el Estado
de la Naturaleza N1. Por lo tanto, los patrocinadores optimistas del proyecto adoptarán la
estrategia C. En general, la elección de la estrategia que tiene el potencial de generar el mayor
beneficio se denomina criterio de decisión maximax .
Ahora bien, si los patrocinadores del proyecto son pesimistas, en cambio estarán interesados
en minimizar sus pérdidas potenciales, en cuyo caso adoptarán la estrategia que brinde el mejor
resultado en las peores condiciones posibles. para los tres
estrategias A, B y C, los peores escenarios de pago son: $20 millones, $50

millones y $40 millones, respectivamente. El mejor (menos malo) de los tres cuesta $50
millones, o Estrategia B. En general, la estrategia que da el mejor resultado de
varios escenarios del peor de los casos se denomina criterio de decisión maximin .
Tabla 10.7 Tabla de pagos
Estados de la Naturaleza
Estrategia N1 N2 N3
A 60 30 ÿ20
B 60 50 60
C 90 70 40
Cuadro 10.8 Cuadro de arrepentimiento
Estados de la Naturaleza
Estrategia N1 N2 N3
A 30 40 80
B 30 20 0
C 0 0 20
Cualquier elección de estrategia que no sea la mejor hará que el tomador de decisiones
experimentar una pérdida de oportunidad o arrepentimiento. Esta forma de pensar sugiere otra
criterio para elegir entre estrategias, el criterio de decisión minimax , que es
la estrategia que minimiza el arrepentimiento de no haber elegido la mejor estrategia.
El arrepentimiento por un estado de naturaleza dado es la diferencia en los resultados entre el
mejor estrategia y cualquier otra estrategia. Esto se ilustra en una tabla de arrepentimiento, que se muestra en
Tabla 10.8. Por ejemplo, dados los pagos de la tabla 10.7, para el estado de naturaleza (N1)
el pago más alto es de $ 90 millones. Si la Estrategia C, la estrategia óptima, hubiera sido
seleccionado, el arrepentimiento habría sido cero, pero si se hubieran seleccionado las estrategias A o B
en cambio, los arrepentimientos habrían sido de $30 millones cada uno (la diferencia entre
sus resultados, $60 millones, y el óptimo, $90 millones). El arrepentimiento asciende
para los estados de la naturaleza, N2 y N3 se determinan de manera similar.
Para entender cómo minimizar el arrepentimiento, primero busque en la tabla de arrepentimiento en el

mayor arrepentimiento para cada estrategia. Los arrepentimientos más grandes son $80 millones, $30
millones y $20 millones para las estrategias A, B y C, respectivamente. Luego, escoja el más pequeño
de estos, $20 millones, que corresponde a la Estrategia C. Por lo tanto, la Estrategia C es la mejor
opción en términos de minimizar el arrepentimiento.
Otro enfoque de selección de estrategias es asumir que cada estado de la naturaleza tiene la misma
probabilidad de ocurrir. Esto se llama el criterio de decisión de pago máximo esperado . Volviendo a la
tabla de pagos, Tabla 10.7, suponga que la probabilidad de cada estado de la naturaleza es de un
tercio, por lo tanto, el pago esperado para la Estrategia A dados los resultados de la tabla de pagos es
1/3(60) + 1/3(30) + 1/3(–20) = 23,33 o $23,33 millones
Los pagos esperados para las estrategias B y C, calculados de manera similar, son $56.66 millones y
$66.66 millones, respectivamente. Por lo tanto, la estrategia C se elegiría por dar el pago máximo
esperado. Observe en los ejemplos anteriores que tres de los cuatro criterios de selección apuntan a
la Estrategia C. Esto en sí mismo podría convencer a los tomadores de decisiones de que la Estrategia
C es la más apropiada.
Simulación
La aplicación de la simulación a la gestión de proyectos, ilustrada en el Capítulo 7, proporciona la

distribución de probabilidad de los resultados, que se puede utilizar para determinar la probabilidad (o
verosimilitud) de un resultado particular, como el costo o el tiempo de finalización. A su vez, esto se
puede utilizar para establecer un presupuesto objetivo apropiado o una fecha de finalización, o para
preparar planes de contingencia. Por ejemplo, aunque la ruta crítica del Capítulo 7, ejemplo 7.2, indicó
que el proyecto se completaría en 147 días, la distribución del tiempo de finalización simulada (Figura
7.14) indicó que sería de 155 días, en promedio. Así, como mínimo, la meta de cumplimiento debería
fijarse en 155 días, aunque la probabilidad de no cumplir esa fecha sería del 50 por ciento. Usando la
distribución de probabilidad simulada, se puede establecer una fecha de finalización objetivo de modo
que la probabilidad de no cumplirla sea más aceptable.
Alternativamente, dada una fecha preespecificada en la que el proyecto debe completarse, la simulación
puede usarse para estimar la probabilidad de falla y, por lo tanto, determinar si se deben preparar
planes de contingencia o cambiar los requisitos del proyecto.
actividades o red.
Ver Capítulo 7
1. ¿Se deben ignorar los riesgos que tienen baja probabilidad? Explique.
2. ¿Cómo afecta la tolerancia al riesgo de una persona si califica un riesgo alto, medio o bajo?
3. ¿Qué se entiende por riesgo de fracaso?

4. ¿Qué factores hacen que un proyecto sea de alto riesgo?
5. Analice la diferencia entre riesgo interno y riesgo externo. Lista
fuentes de riesgo en cada una de estas categorías.

6. Describa cada una de las siguientes fuentes de riesgo técnico: madurez, complejidad,
calidad y concurrencia o dependencia.
7. Describa brevemente las siguientes técnicas de identificación de riesgos: analogía, listas
de verificación, análisis WBS, diagramas de flujo de procesos y lluvia de ideas.
8. Describa un diagrama de causa y efecto. Elija un problema (efecto) de su propia elección
y use un diagrama de causa y efecto para ilustrarlo.
9. Un proyecto consiste en desarrollar un sistema con hardware y software de última
generación, ambos complejos, y donde el rendimiento del sistema depende de otro
sistema externo que se está desarrollando simultáneamente. Con base en la Tabla 10.3,
y suponiendo que todos los factores de riesgo son independientes y tienen la misma
ponderación, ¿cuál es el CLF para el proyecto?
10. ¿Qué es un diagrama de influencia? ¿Cómo se utiliza para identificar y analizar las fuentes
de riesgo y asignar prioridades a esas fuentes?
11. Las tablas 10.3 y 10.4 tienen fines ilustrativos. Discuta la aplicabilidad general de estas
tablas para calificar los riesgos en los proyectos. ¿ Utilizaría estas tablas para evaluar la
probabilidad de riesgo y el impacto en un proyecto de su elección? ¿Por qué o por qué
no?
12. ¿Las ecuaciones (10.1), (10.2) y (10.3) presentan buenas formas de calificar la probabilidad,
el impacto y las consecuencias generales del riesgo? Discuta los pros y los contras de
usar estas ecuaciones.
13. Discuta brevemente cada una de las siguientes formas de manejar el riesgo: transferir el riesgo,
evitar el riesgo, reducir el riesgo, plan de contingencia y aceptar el riesgo.
14. Piense en un proyecto con el que esté familiarizado y los problemas que encontró.
Enumere algunas formas en que los problemas podrían haberse evitado y explique cada una de
ellas.
15. ¿Qué es un margen de diseño? ¿Cómo su aplicación reduce el riesgo?

16. Un requisito de un sistema de generación de energía establece que debe proporcionar una salida
mínima de 500 kwh. El sistema tiene tres subsistemas de generación de energía, X, Y y Z. Las
restricciones en el tamaño físico indican que la capacidad de salida del sistema general se dividirá
entre los tres subsistemas en una proporción aproximada de 5:3:2. Se aplica un margen de diseño
del 3 por ciento al sistema y los subsistemas. Tenga en cuenta que debido a que el requisito de
potencia se establece como salida mínima , la salida objetivo será un 3 por ciento superior al
requisito.
una. ¿Cuál es el resultado del requisito objetivo para el sistema en general? b. ¿Cuáles
son los resultados de requisitos objetivo para cada uno de los subsistemas? (Recuerde, los
márgenes del subsistema se suman al margen del sistema). c. Suponga que, en el
mejor de los casos, el subsistema X se puede diseñar para satisfacer solo el 47 por
ciento del requisito de potencia de salida para el sistema general. Suponiendo que los
subsistemas Y y Z pueden diseñarse para cumplir con sus respectivos objetivos de
diseño, ¿puede cumplirse también el requisito de salida para el sistema general?
17. Enumerar y revisar los principios de la gestión de riesgos.

18. ¿Cómo sirve la planificación de riesgos para aumentar el comportamiento de asunción de riesgos?
19. La gestión de riesgos incluye estar preparado para lo inesperado. Explique.

20. ¿Se puede eliminar el riesgo de los proyectos? ¿Debería la gerencia tratar de
eliminarlo?
21. ¿Cómo y dónde se utilizan las consideraciones de tiempo de riesgo y costo de riesgo en el proyecto?
¿planificación?
22. ¿Dónde se utilizarían los criterios de arrepentimiento maximax, maximin y minimax durante el ciclo
de vida del proyecto para gestionar el riesgo del proyecto?
23. La Figura 10.8 a continuación es la red del Proyecto Hidroeléctrico Largesse:
Figura 10.8 Proyecto Hidroeléctrico Largesse.
La siguiente tabla proporciona las estimaciones de costo y tiempo de referencia (BCE y

BTE), las estimaciones de costo y tiempo para corregir fallas y la probabilidad de falla
para cada paquete de trabajo.
una. Determine el tiempo de riesgo y el costo del riesgo para todos los elementos
de la EDT del proyecto. b. Considere los tiempos de riesgo en las rutas no

críticas. ¿Qué actividades y caminos deben vigilarse cuidadosamente porque
presentan los mayores riesgos?
C. ¿Cuál es el costo esperado (EC) y el tiempo esperado (ET) del proyecto?
24. La ubicación geográfica del Proyecto Largesse Hydro lo amenaza con demoras y costos
asociados con el clima. La probabilidad de mal tiempo es
estimado en 0.30 con un impacto potencial de retraso del trabajo por 10 semanas
y aumentando el costo en $20,000.
una. Ignorando los riesgos de tiempo y costo del problema 23, ¿cuáles son los
tiempo esperado de terminación del proyecto y costo de terminación
teniendo en cuenta el riesgo meteorológico?
b. ¿Cuál es el tiempo esperado estimado de finalización del proyecto y
coste teniendo en cuenta el riesgo meteorológico y los riesgos enumerados en Problema

23?
25. Softside Systems tiene un contrato de precio fijo de $100,000 para la instalación de un
nuevo sistema de aplicación. Se espera que el proyecto tome 5 semanas y cueste
$50,000. La experiencia con proyectos similares sugiere una probabilidad de 0.30 de que
el proyecto encontrará problemas que podrían retrasarlo hasta 3
semanas y aumentar el costo en $30,000. Al aumentar el personal del proyecto 20
por ciento por un costo adicional de $10,000 la probabilidad de problemas
se reduciría a 0.10, y la demora y el costo a 1 semana y $8,000,
respectivamente. Configure un árbol de decisiones para mostrar si Softside debería
aumentar el tamaño del personal del proyecto.
26. Un municipio solicitó a Corecast Contractors que presente una
propuesta de oferta para un contrato de garaje de estacionamiento. En el pasado el costo de
preparar ofertas ha sido alrededor del 2 por ciento del costo del trabajo. Corecast
el gerente de proyecto Bradford Pitts está considerando tres posibles ofertas: costo
más 10 por ciento, costo más 20 por ciento y costo más 30 por ciento. Por supuesto,
aumentar el "más por ciento" aumenta el precio del proyecto y disminuye
la probabilidad de ganar el trabajo. Bradford estima la probabilidad de
ganar el trabajo de la siguiente manera:
Precio de oferta P(ganar) P (perder)

P1 C + 0.1C = 1.1C 0.6 0.4
P2 C + 0.2C = 1.2C 0.4 0.6
P3 C + 0.3C = 1.3C 0.2 0.8
En todos los casos, la ganancia (si se gana la oferta) será el precio de la oferta menos el
costo de preparación de la propuesta, o 0.02C; la pérdida (la oferta no se gana) será la

costo de preparación de la propuesta. Prepare un árbol de decisiones para las tres opciones. Si
Bradford utiliza como criterio el beneficio máximo esperado, que puja
propuesta que elegiría?
27. Iron Butterfly, Inc. presenta propuestas en respuesta a RFP y enfrenta tres
posibles resultados: N1, Iron Butterfly obtiene un contrato completo; N2, obtiene un
contrato parcial (el trabajo se comparte con otros contratistas); N3, no se pone
contrato. La empresa está evaluando actualmente tres RFP, codificados P1, P2,
y P3. Para P3 el cliente pagará una cantidad fija por propuesta
preparación; para P1 y P2, Iron Butterfly debe absorber los costos de preparación de la
propuesta, que se espera que sean altos. Basado en proyecto
ingresos y costos de preparación de propuestas, las ganancias esperadas ($
miles) son como se muestra:
N1 N2 N3
P1 500 200 ÿ300
P2 300 100 ÿ100
P3 100 50 25
¿A qué RFP respondería Iron Butterfly usando la decisión de tres

¿criterios?
28. Frank Wesley, gerente de proyecto del proyecto LOGON, está preocupado
sobre el tiempo de desarrollo del transportador robótico. Aunque el
subcontratista, Creative Robotics, ha prometido un tiempo de entrega de 6
semanas, Frank sabe que el tiempo real de entrega será una función de
el número de otros proyectos en los que Creative Robotics está trabajando. Como
incentivo para acelerar la entrega del transportador, Frank tiene tres
opciones:
S1: No hacer nada.
S2: Promise Creative Robotics un contrato futuro con Iron Butterfly.
S3: Amenaza con no volver a contratar a Creative Robotics.
Él estima que el impacto de estas acciones en el tiempo de entrega sería tan
sigue:
Carga de trabajo de robótica creativa

Pagos: estrategia
Lento Promedio Ocupado
S1 4 6 8
S2 3 4 7
S3 3 6 6
¿Qué estrategia debería adoptar Frank con base en los criterios de incertidumbre? Usar
criterios similares al maximax, maximin, minimax arrepentimiento, y
pago máximo esperado, excepto tenga en cuenta que los criterios deben adaptarse
porque aquí el objetivo es minimizar el pago (tiempo); esto es en contraste
al caso habitual, que es maximizar el pago.
Preguntas sobre el Proyecto de Estudio
1. ¿Cuáles creían los gerentes y las partes interesadas que eran los principales riesgos en el
¿proyecto?
2. A su juicio, ¿fue este un proyecto arriesgado? ¿Por qué o por qué no?
3. ¿Se realizó un análisis de riesgo formal? ¿Cuándo se hizo (en la iniciación,
factibilidad, etc)?
4. ¿Se creó un plan formal de gestión de riesgos? Discute el plan.
5. ¿Había un oficial de riesgos? Discuta sus deberes y su papel en el proyecto.

6. ¿Cómo se identificaron los riesgos?
7. ¿Cómo se manejaron los riesgos (a través de la transferencia, aceptación, evitación,

reducción, etc)?
8. Discutir el uso de planes de contingencia y reservas de presupuesto y cronograma

para cubrir riesgos.
9. ¿Qué riesgos se materializaron durante el proyecto y cómo se manejaron?
32
Caso 10.1 La Ópera de Sydney
La Ópera de Sídney (SOH) es una de las principales atracciones turísticas y punto de referencia para
Sydney y toda Australia. Es un importante centro de artes, aunque debido a su diseño,

no es necesariamente el mejor lugar para escuchar ópera. El SOH es visualmente
espectacular y una estructura magnífica (Figura 10.9), pero fue una pesadilla diseñarlo y
construirlo.
El concepto original del SOH fue un boceto presentado por el arquitecto danés Jorn
Utzon. Los jueces lo seleccionaron de una competencia abierta que terminó con 233
entradas de 11 países. Aunque feliz de ganar, Utzon estaba ligeramente sorprendido. El
concepto que había llamado la atención de los jueces consistía únicamente en bocetos
simples, sin planos ni siquiera dibujos en perspectiva. Utzon enfrentó el desafío de
convertir los bocetos en un diseño a partir del cual se pudiera construir una estructura,
pero no tenía experiencia previa en el diseño y construcción de un edificio tan grande.
Debido a que no había planos, dibujos detallados o estimaciones de los materiales
necesarios, había poco en lo que basar las estimaciones de costos. Nadie sabía cómo
se construiría; algunos expertos cuestionaron que pudiera construirse en absoluto.
Curiosamente, debido a que el diseño era tan único, algunas personas pensaron que
también sería económico construirlo. El costo inicial se estimó en $7 millones, a ser
pagado por el gobierno a través de las ganancias de una serie de loterías estatales.
Los ingenieros que revisaron el concepto notaron que las cubiertas del techo eran
mucho más grandes y anchas que las cubiertas jamás construidas. Además, debido a
que sobresalían tan alto, actuarían como velas en los fuertes vientos que soplaban en el puerto.
¡Por lo tanto, tendrían que diseñarse y construirse cuidadosamente para evitar que el
edificio vuele!
Figura 10.9 Ópera de Sydney.

Fuente: iStock.
A los gerentes del gobierno les preocupaba que las personas que examinaban el
diseño pudieran plantear preguntas sobre posibles problemas y estancar el proyecto.
Por lo tanto, avanzaron rápidamente y dividieron el trabajo en tres contratos principales:
los cimientos y el edificio excepto el techo, el techo y el interior y el equipamiento.
Como habían advertido los expertos, el proyecto SOH se convirtió en una debacle
financiera y de ingeniería, duró 15 años y costó 107 millones de dólares (100 millones
de dólares por encima de la estimación inicial). La retrospectiva es 20/20, pero desde
el principio esto debería haber sido visto como un proyecto arriesgado. No obstante,
los riesgos fueron minimizados o ignorados, y poco se hizo para mitigarlos o controlarlos.
Preguntas
1. Identificar los riesgos obvios.

2. ¿Qué acciones tempranas deberían haberse tomado para reducir los riesgos?
3. Discuta algunos principios de gestión de riesgos que fueron ignorados.
Caso 10.2 Infinity & Beyond, Inc.
Infinity & Beyond, Inc. produce productos de moda de alta tecnología. El departamento de
marketing de la compañía ha identificado un nuevo “concepto” de producto a través de
discusiones con tres grupos de enfoque de clientes. El departamento está entusiasmado con
el nuevo concepto y se lo presenta a la alta dirección, quien lo aprueba para su posterior
estudio. A Lisa Denney, directora sénior de desarrollo de nuevos productos, se le pide que
cree un plan y un desglose de costos para el desarrollo, la fabricación y la distribución del
producto. A pesar del entusiasmo del departamento de marketing, Lisa no está segura del
potencial de mercado del producto y de la capacidad de la empresa para desarrollarlo a un
costo razonable.
En su forma de pensar, el mercado parece estar mal definido, los objetivos del producto no
están claros y el producto y su tecnología de producción son inciertos. Lisa le pide a su
diseñador jefe que cree algunos requisitos del producto y un diseño aproximado que cumpla
con los requisitos, y que proponga cómo podría fabricarse el producto.
Después de algunas semanas, el diseñador informa con los requisitos que parecen
satisfacer el concepto de marketing. Ella le dice a Lisa que debido a la novedad de la
tecnología y la complejidad del diseño del producto, la empresa no tiene la experiencia para
desarrollar o incluso fabricar el producto en
su propio. Lisa revisa varias firmas de diseño/desarrollo y le pide a una, Margo-

Spinner Works Company, MSW, que revise el concepto del producto. MSW le
asegura a Lisa que, aunque la tecnología es nueva para ellos, está dentro de su
capacidad. Lisa informa esto a la alta gerencia, quien le dice que siga adelante con
el proyecto de desarrollo.
Lisa establece un contrato de precio fijo con MSW y les otorga la responsabilidad
principal del esfuerzo de desarrollo. La gerencia de MSW había abogado por un
contrato de costo incrementado, pero cuando Lisa estipuló que el acuerdo tenía
que ser de precio fijo, MSW dijo que estaba de acuerdo, solo con la condición de
que se le diera el control total del trabajo de desarrollo. Lisa se siente incómoda
con la propuesta, pero no conoce ninguna otra empresa de diseño calificada para
hacer el trabajo, por lo que acepta.
Preguntas
1. Discuta las principales fuentes de riesgo en este proyecto.

2. ¿Qué piensas sobre el manejo del proyecto por parte de Lisa hasta ahora?
¿Hubieras hecho algo diferente?
3. Discuta qué hicieron Lisa y otras partes que sirvieron para aumentar o
disminuir los riesgos.
Caso 10.3 El puente Nelson Mandela 33
Newtown, Sudáfrica es un suburbio de Johannesburgo que cuenta con un rico patrimonio

cultural. Como parte de un intento de ayudar a rejuvenecer Newtown, se construyó el
puente Nelson Mandela para conectarlo con importantes carreteras y centros comerciales
en Johannesburgo. El puente, que abarca 42 líneas ferroviarias electrificadas (Figura
10.10) , ha sido aclamado por su funcionalidad y belleza.
La falta de espacio para los pilones de soporte (torres) entre las vías del tren dictó que
el diseño del puente tendría un tramo largo. Esto dio como resultado una estructura con el
tablero del puente soportado por tirantes de pilones de altura desigual. Los pilones del lado
norte tienen 48 metros de altura y los del lado sur 35 metros de altura.
Los pilones son columnas compuestas que consisten en tubos de acero que debían
rellenarse con hormigón después de ser izados a la posición vertical. Se tomó la decisión
de bombear el hormigón en los tubos a través de un puerto en la parte inferior de cada tubo.
Esto tenía que hacerse en una sola operación. Aunque la tecnología para vaciar hormigón
de esta forma no era nueva, las columnas eran las más altas de Sudáfrica y su relleno
establecería un récord mundial de
Bombeo de abajo hacia arriba del hormigón autocurado.

La bomba para el concreto se colocó a nivel del suelo entre las líneas ferroviarias electrificadas,
lo que expuso a los trabajadores a los riesgos de estar cerca de operaciones ferroviarias continuas.
El método de bombeo presentaba el riesgo de que el agregado de piedra y el cemento en la
mezcla de concreto se segregaran en los tubos del pilón antes de que el concreto se solidificara,
lo que comprometería la resistencia del concreto. Otro riesgo era que la bomba fallara y el hormigón
se solidificara en un pilón incompleto, lo que imposibilitaría seguir bombeando hormigón desde el
fondo. Se consideraron dos contingencias: una bomba adicional en espera y completar el proceso
vertiendo concreto desde la parte superior del pilón.
Figura 10.10 Puente Nelson Mandela, Johannesburgo.

Fuente: iStock.
El hormigón tuvo que ser transportado por camiones al sitio, lo que corría el riesgo
interrumpiendo el suministro de concreto debido a la congestión del tráfico en la ciudad.
A pesar de trabajar en un patio ocupado con trenes que van y vienen, no
accidente grave ocurrido en cualquier momento en el proyecto de 420.000 horas de trabajo.

La bomba nunca falló y la construcción terminó a tiempo. Se instalaron los cables
atirantados, con un total de 81.000 metros de longitud, y la plataforma del puente se levantó
de los soportes temporales, mientras que las líneas ferroviarias electrificadas debajo
permanecieron vivas. Una vez finalizado el puente, algunos sintieron que los costos
incurridos para reducir los riesgos habían sido excesivos; otros sostuvieron que los riesgos
eran demasiado altos y que no se había hecho lo suficiente para reducirlos.
Preguntas
1. ¿Cómo habría identificado los riesgos? (Consulte también los métodos en

Capítulo 9.)
Ver Capítulo 9
2. Utilizando la siguiente tabla, analice cómo se abordaron los riesgos o

cómo se podrían haber abordado. Incluya cualquier riesgo adicional que
se le ocurra.
3. Indique si los riesgos enumerados en el cuadro anterior son internos o

externo.
4. Describa cómo determinaría los valores esperados de los riesgos
enumerados en la tabla.
5. Compile una lista completa de la información que necesitaría para realizar una
evaluación del riesgo de falla de una bomba.
6. ¿Qué información cree que habría estado disponible al comienzo del proyecto y de
dónde la obtendría?
7. Dibuje un diagrama CE que muestre diferentes factores que podrían contribuir
a retrasar el proyecto.
8. Describa cómo se reducen los riesgos a lo largo de la vida útil de un proyecto como
como este
9. Con referencia a las preocupaciones expresadas al finalizar la construcción, discuta

la declaración: “Los riesgos siempre se relacionan con el futuro. No existe tal cosa
como un riesgo pasado”.
10. Discuta la diferencia entre buenas decisiones y buena suerte.
11. ¿Cómo podría un gerente protegerse contra el riesgo de tomar una decisión que
luego podría tener implicaciones negativas?
Notas finales
1. Citado en Bernstein P. Against the Gods: The Remarkable Story of Risk. Nueva York: John Wiley & Sons;
1996, pág. 331.
2. Cuando se le pidió una vez que definiera la certeza, John Von Neumann, el principal teórico de los modelos matemáticos de
incertidumbre, respondió con un ejemplo: diseñar una casa para que sea seguro que el piso de la sala nunca
cede, "calcular el peso de un piano de cola con seis hombres acurrucados sobre él para cantar, triplicar el peso
peso”, luego diseñe el piso para sostenerlo. ¡Eso garantizará la certeza! Fuente: Bernstein, Contra el
Dioses, pág. 233.
3. Véase Argus R. y Gunderson N. Planificación, realización y control de proyectos. Upper Saddle River, Nueva Jersey:
Prentice Hall; 1997, págs. 22 y 23.
4. Adaptado de Michaels J. Technical Risk Management. Upper Saddle River, Nueva Jersey: Prentice Hall; 1996, págs.
208–250.
5. Turoff M. y Linstone H. (eds). El Método Delphi: Técnicas y Aplicaciones, 2002,
http://is.njit.edu/pubs/delphibook/
6. El término "posibilidad" a veces se distingue de "probabilidad". Este último se refiere a valores basados en medidas de frecuencia de datos
históricos; el primero a estimaciones subjetivas o sensaciones viscerales. Si dos de los tres intentos anteriores tuvieron éxito la primera vez,
entonces, ceteris paribus, la probabilidad de éxito en el
el siguiente intento es 2/3 o 0,67. Sin embargo, incluso sin datos numéricos, una persona con experiencia puede, después de reflexionar,
llegar a una estimación similar de que "las probabilidades son dos a uno de que tendrá éxito la primera vez".
Aunque una estimación es objetiva y la otra subjetiva, eso no implica que una sea mejor que la otra.
otro. Los datos de frecuencia objetiva no necesariamente darán una estimación confiable porque una multitud de factores pueden influir en
los resultados; una estimación subjetiva, por el contrario, podría ser confiable porque los humanos a menudo pueden hacer un buen trabajo
al asimilar muchos factores.
7. Roetzheim W. Gestión estructurada de proyectos informáticos. Upper Saddle River, Nueva Jersey: Prentice Hall; 1988, págs.
23–26; más ejemplos de factores de riesgo y métodos de cuantificación de probabilidad se dan en Michaels,
Gestión de Riesgos Técnicos.
8. Véase Dingle J. Gestión de proyectos: Orientación para los responsables de la toma de decisiones. Londres: Arnold; 1997.
9. Ver Gilbreath R. Winning at Project Management: What Works, What Fails, and Why. Nueva York: Juan
Wiley e hijos; 1986.
10. Roetzheim, Gestión de proyectos informáticos estructurados, págs. 23–26.
11. Pool R. Más allá de la ingeniería: cómo la sociedad da forma a la tecnología. Nueva York: Oxford University Press; 1997,
págs. 197–202
12. Kotulak R. Diferencias clave observadas en Columbia, desastres del Challenger. Chicago Tribune; 2 de febrero de 2003, Sección
1, pág. 5.
13. Pool, Más allá de la ingeniería, págs. 207–214
14. Michaels, Gestión técnica de riesgos, pág. 40
15. Las estadísticas facilitan la despersonalización de las consecuencias. Por ejemplo, es menos angustiante afirmar que
hay una probabilidad de 0.005 de que alguien muera que decir que 5 personas de 1,000 morirán.
16. Mitroff I. y Linstone H. La mente ilimitada. Nueva York: Oxford; 1993, págs. 111–135.
17. Ibíd.
18. Anbari F. (ed.). Casos de estudio en Gestión de Proyectos: El Proyecto Chunnel. Newton Square, Pensilvania: Proyecto
Instituto de Gestión; 2005.
19. Eisner H. Ingeniería de Sistemas Asistidos por Computadora. Upper Saddle River, Nueva Jersey: Prentice Hall; 1988, pág. 335.
20. Ver Grady J. Análisis de requisitos del sistema. Nueva York: McGraw-Hill; 1993, págs. 106–111.
21. Eisner, Ingeniería de sistemas asistida por computadora, pág. 336.
22. Ibíd.
23. Una placa de pruebas es un conjunto funcional de componentes. Un prototipo es un modelo de trabajo temprano de un
Sistema completo. Ambos se utilizan para demostrar, validar o probar la viabilidad de un concepto de diseño.
Las placas de prueba, los prototipos y el modelado se analizan en los capítulos 2 y 9.
24. Wakabayashi H. y Cowan B. Ampliación del Aeropuerto Internacional de Vancouver. red PM; Septiembre,
1998, págs. 39–44.
25. Whitten N. Cumplir con los requisitos mínimos: cualquier cosa más es demasiado. red PM; septiembre de 1998, pág.
19
26. DeMarco T. La fecha límite. Nueva York: Dorset House; 1997, pág. 83; Yourdan E. Ascenso y resurrección de los
Programador estadounidense. Upper Saddle River, Nueva Jersey: Prentice Hall; 1998, págs. 133–136.
27. Dorner D. La lógica del fracaso. Lectura, MA: Addison-Wesley; 1997, pág. 163.
28. Aronstein D. y Piccirillo A. Have Blue and the F117A: Evolution of the Stealth Fighter. Reston, VA:
Instituto Americano de Aeronáutica y Astronáutica; 1997, págs. 79–80.
29. Ibíd., págs. 186–190.
30. Para conocer otros enfoques del análisis del tiempo de riesgo, véase Michaels, Technical Risk Management.
31. Esta sección y la siguiente abordan el tema más general del análisis de decisiones, un tema amplio que recibe
sólo una cobertura superficial aquí. Un libro clásico sobre el tema es el de Luce RD y Raiffa H. Games and
Decisiones. Nueva York: John Wiley & Sons; 1957.
32. Adaptado de Kharbanda O. y Pinto J. What Made Gertie Gallop: Learning from Project Failures. Nuevo
York: Van Nostrand Reinhold; 1996, págs. 177–191.
33. Fuente: Kromhout F. Director de división, Bridges, BKS (Pty) Ltd, Pretoria.
Capítulo 11
Ejecución de Proyectos, Seguimiento y
Control
Los temas de los seis capítulos anteriores caen en gran medida en el ámbito de la
planificación y se abordan inicialmente en las fases de concepción y definición del ciclo de
vida del proyecto. Al final de la fase de definición, el gerente y el equipo del proyecto habrán
preparado un conjunto completo de requisitos y especificaciones y un plan algo completo
para las etapas más inmediatas del proyecto, así como un esquema para las etapas
restantes, que constituyen la ejecución . fase o parte de “entrega” del ciclo de vida del
proyecto. Lo que sucede en la fase de ejecución, y lo que ven la mayoría de los forasteros
cuando miran un proyecto, es el primer tema de este capítulo.
A pesar de todo el esfuerzo dedicado a la planificación, programación y presupuestación
en la fase de definición, ningún plan es nunca completo o perfecto y, además, las cosas rara
vez salen del todo según lo planeado. El propósito del control del proyecto es mantener el
proyecto en movimiento y en el objetivo, seguir el progreso y superar los obstáculos , que
es el otro tema de este capítulo.
11.1 Fase C: Ejecución
La fase de ejecución generalmente incluye las etapas de diseño detallado, producción/

construcción e implementación (Figura 11.1), aunque, en realidad, las etapas difieren
según el propósito del proyecto. En los proyectos de desarrollo de hardware, las
etapas suelen ser diseño, desarrollo y producción; en los proyectos de construcción
son diseñar y construir; y en consultoría son la investigación de antecedentes, la
compilación de informes y la presentación. Muchas empresas tienen metodologías de
proyectos personalizadas con sus propias fases y etapas únicas del proyecto; estos
se analizan en el Capítulo 17. Todos los proyectos que producen un artículo final físico
(un producto, edificio o sistema) también incluyen una etapa de implementación en la
que el artículo final se entrega al usuario. Este capítulo analiza las etapas de diseño y
producción/construcción; el siguiente capítulo cubre la implementación y el cierre del
proyecto.
Ver Capítulo 17
11.2 Etapa de diseño de detalle
En la etapa de diseño de detalle, las especificaciones del sistema se convierten en planos,

bocetos o dibujos. Los resultados de esta etapa son formas pictóricas (planos, diagramas
de flujo o diagramas esquemáticos) o modelos que muestran los componentes, las
1
dimensiones, las relaciones y la configuración del sistema final.
Figura 11.1 Ciclo de vida de desarrollo de sistemas de fases y etapas. Fases A, B, C = ciclo de vida del proyecto.
Durante la etapa de diseño, el sistema se divide en niveles de subsistemas, componentes

y partes. Se revisan varias posibilidades de diseño para los elementos de cada nivel en
cuanto a la compatibilidad entre sí y los elementos de los niveles superiores, y la capacidad
para cumplir con las especificaciones del sistema y los requisitos de costo, cronograma y
rendimiento. El desglose en niveles y componentes utiliza las herramientas mencionadas
anteriormente (diagrama de bloques, Capítulo 2; estructura de desglose de requisitos,
Capítulo 3; y estructura de desglose de trabajo, Capítulo 5).
Ver Capítulos 2, 3 y 5
El proceso de diseño se compone de dos actividades interrelacionadas. Primero está la

preparación de un diseño funcional que muestre los componentes del sistema y sus relaciones.
El propósito de esta actividad de diseño es determinar los elementos lógicos y funcionales del
sistema y cómo deben interconectarse para lograr los objetivos del sistema. Este es el objetivo
de la ingeniería de sistemas (Capítulo 2) y la definición de sistemas/FEL-3 (Capítulo 4).
El segundo es la preparación de un diseño físico que muestre cómo se verán el sistema real
y sus componentes: sus tamaños, formas y posiciones relativas.
Esta actividad de diseño da como resultado dibujos y modelos de ingeniería, fabricación,
arquitectura y otros tipos que muestran los detalles necesarios para fabricar, ensamblar y
mantener el sistema posteriormente. Esta actividad de diseño a veces revela lugares donde el
diseño funcional no es práctico o factible debido a consideraciones de ensamblaje, mantenimiento
o apariencia, en cuyo caso debe volver a hacerse.
El diseño a menudo sigue un proceso evolutivo de prueba y error, como se ilustra en la

Figura 2.7 en el Capítulo 2 y la Figura 4.7 en el Capítulo 4. Se prepara, modela y prueba un
diseño de prueba contra los requisitos del sistema. Si falla, el diseño se modifica y se vuelve a
probar. Esta iteración de diseño, construcción y prueba ocurre en prácticamente todos los
proyectos para desarrollar nuevos sistemas.
Cuando el sistema de elementos finales es complejo, la iteración ocurre en muchos lugares
para elementos y subsistemas en todo el sistema, y los cambios necesarios en uno tienen un
efecto dominó en los demás. Por ejemplo, es posible que se deba ampliar un subsistema, lo
que roba espacio a otro subsistema que luego debe trasladarse a otro lugar, lo que desplaza a
otro subsistema, y así sucesivamente.
Sin control, el resultado es una serie interminable de iteraciones de rediseño, como se ilustra
en el Ejemplo 11.1.
Ejemplo 11.1: Complejidad de Diseño en el Canal 2
Uno de los requisitos obligatorios para el Túnel del Canal de la Mancha

(Chunnel) era que los trenes que lo atravesaran debían ser resistentes al daño por fuego
durante al menos 30 minutos; esto permitiría que todos los vagones de tren pudieran salir del
túnel con un incendio en el interior. Pero la estructura de un vagón de tren normal se deformaría
por el calor y el tren pronto quedaría inmóvil, por lo que habría que utilizar aleaciones de metal
especiales. Esto haría que los trenes fueran más pesados, 2.400 toneladas en lugar de 1.600
toneladas, y requeriría locomotoras más pesadas que necesitaran seis ejes en lugar de cuatro.
Las locomotoras tendrían que diseñarse especialmente y, dado que necesitaban más potencia,
también tendría que cambiarse el sistema de energía del túnel.
El diseño y la producción/construcción no siempre ocurren como etapas discretas y secuenciales,

sino que se superponen. La construcción de una parte del sistema comienza tan pronto como se
completa una parte del diseño, luego comienza la construcción de otra parte cuando se completa una
parte más del diseño, y así sucesivamente. En otras palabras, el sistema se construye mientras aún
se está diseñando, una práctica conocida como seguimiento rápido o diseño-construcción. La vía
rápida es común en la industria de la construcción: se están cavando los cimientos y levantando
acero, aunque el techo y el interior aún se están diseñando. La práctica acelera el trabajo y puede
ahorrar hasta 1 año en un proyecto de construcción importante, pero puede ser riesgoso. Los
problemas de diseño a menudo surgen solo después de que se han resuelto los detalles, pero para
entonces se habrán fabricado partes del sistema o del edificio y es posible que deban reconstruirse,
lo que aumenta los costos y los cronogramas. El método secuencial o de “seguimiento lento” habitual
toma más tiempo pero permite más tiempo para descubrir y resolver problemas de diseño antes de
que comience la construcción.
3
Diseño de interacción
¿Por qué tantos productos basados en software son difíciles de usar y contienen características
oscuras o irrelevantes que la mayoría de la gente no necesita o no quiere? Algunos ejemplos son los
productos de software, los teléfonos celulares y los sistemas de entretenimiento, todos los cuales
contienen numerosas características y funciones que la mayoría de las personas no necesitan y
nunca aprenden a usar. Sin embargo, en un esfuerzo por "mejorar" continuamente el producto, los
desarrolladores siguen agregando cada vez más funciones, un proceso que conduce a "bloatware". Compara, por
por ejemplo, todas las cosas que presumiblemente podría hacer con el software de procesamiento de
textos y hojas de cálculo con las pocas funciones que realmente usa. Estos productos no solo contienen
demasiadas funciones, sino que mezclan funciones que nunca se usan con otras que se usan con
frecuencia, lo que hace que todo el producto sea más difícil de entender y usar.
A los ojos de los clientes, son demasiado complejos.
Los sistemas complejos siempre han existido, pero en el pasado eran operados por personal
capacitado . Los equipos agrícolas y de construcción, las aeronaves, los trenes y los generadores
eléctricos son complejos, pero los utiliza personal capacitado, no la persona promedio. Los productos
comerciales (cámara, consola de automóvil, teléfono celular, etc.) también son complejos, pero son
utilizados por aficionados, no por operadores calificados.
La complejidad y el bloatware ocurren cuando los objetivos del producto y los requisitos del usuario no
están bien definidos, nadie garantiza que el diseño cumpla con los requisitos del usuario y la interacción
usuario-sistema no es un problema de diseño clave. También ocurren cuando el diseño está controlado
por ingenieros y programadores, personas que son técnicamente astutas pero tienden a ignorar el "diseño
de interacción", aspectos del diseño que abordan cómo funciona el producto y cómo interactúa el usuario.
Cada vez que un programador agrega una función favorita a un producto, o un gerente de marketing
insiste en otra característica del producto, están empaquetando las características que desean, pero
ignoran el impacto en el usuario final promedio.
El director del proyecto y el ingeniero de sistemas deben mantener el control sobre el proceso de
diseño y, en particular, sobre el diseño de interacción. Esto comienza conociendo a los usuarios finales y
sus deseos, aptitudes y niveles de habilidad, incorporándolos a los requisitos del usuario y luego
considerando al usuario final en cada decisión que influirá en la función y operación del producto.
diseño de control
Las revisiones de proyectos, discutidas en los Capítulos 9 y 12, están programadas en hitos clave.
Idealmente, son atendidos y dirigidos por expertos externos objetivos para garantizar que el diseño
funcional satisfaga los requisitos y el diseño final se ajuste a las necesidades personales y al presupuesto
de los usuarios.

A lo largo de la etapa de diseño, pueden ser necesarios cambios a diseños anteriores debido a
nuevas tecnologías, problemas técnicos o nuevos requisitos. Dado que estos inevitablemente requieren
modificaciones en las actividades laborales, la gestión del proyecto es responsable de monitorear los
cambios, determinar sus impactos en los planes, cronogramas y presupuestos, y transmitir los impactos
a las partes interesadas para la aprobación de los cambios. Todo esto se maneja a través de un sistema
de control de cambios, como se describe más adelante.
Los cambios de diseño tienden a aumentar los costos del proyecto, pero como se muestra en la
Figura 11.2, los costos de diseño suelen ser una pequeña fracción de los costos de producción. Las
decisiones de diseño impactan en los costos del ciclo de vida (Figura 8.19), por lo que no deben apresurarse.
En consecuencia, prolongar esta etapa para obtener el diseño correcto la primera vez suele ser mucho
menos costoso que cambiar el diseño o solucionar los problemas relacionados con el diseño más
adelante en el proyecto. Pero no se puede permitir que la etapa de diseño continúe indefinidamente y,
a veces, la gestión del proyecto debe imponer una fecha de congelación después de la cual no se
permiten cambios discrecionales.
La gestión de proyectos también es responsable de garantizar que los esfuerzos de diseño se
documenten adecuadamente. Todos deben conocer las características, la configuración, las fortalezas
y las limitaciones del diseño, y la documentación es el precursor para la producción, operación y
mantenimiento del sistema.
Planificación de producción/construcción y etapas posteriores
En la etapa de diseño, el gerente del proyecto ya está mirando hacia el futuro y planificando la etapa
de producción. Esta planificación aborda todos los aspectos de la producción (herramientas, equipos y
materiales necesarios, procedimientos de ensamblaje, pruebas, embalaje, etc.) e incluye un cronograma
detallado de producción/construcción. Si la documentación de diseño (especificaciones, dibujos, etc.)
no está completamente completa, es posible que el plan de producción deba prepararse en fases.
Es importante tener en cuenta que el plan para la etapa de producción/construcción debe tener en
cuenta todos los sistemas, actividades y recursos necesarios para producir, operar y mantener el
sistema del artículo final; esto incluye “artículos secundarios”, así llamados para distinguirlos del
principal artículo final del contrato del proyecto. Los artículos secundarios no son menos importantes
que el artículo final principal; de hecho, sin ellos sería imposible producir, operar o mantener el artículo
final. Aunque los elementos secundarios suelen ser
desarrollados y producidos por otros, el gerente del proyecto general es responsable

de garantizar que todos hayan sido identificados, que los contratistas los desarrollen
y produzcan, y que estarán listos para su uso cuando se haya completado el elemento
final principal. Los elementos secundarios se analizan en el Capítulo 12.
Figura 11.2 Costos relativos de diseño y producción.

11.3 Etapa de producción/construcción
Diseños detallados en mano, el contratista está listo para la producción/construcción. Para

artículos producidos en masa, esto significa que el sistema está listo para fabricar; para
artículos únicos, significa que el sistema está listo para la fabricación/construcción. Las
principales actividades en esta etapa son la fabricación del sistema, las pruebas y la
planificación para la implementación.
Fabricación del sistema
La fabricación del sistema comienza tan pronto como el trabajo de diseño se ha completado
lo suficiente. Los componentes preparados por los contratistas y sus proveedores se
ensamblan en el artículo final. Como en etapas anteriores, el director del proyecto supervisa
el trabajo, coordina los esfuerzos entre los departamentos/subcontratistas y realiza un
seguimiento del progreso con respecto a los presupuestos y cronogramas. Durante esta
etapa, el director del proyecto y el director de fabricación o construcción comparten la
responsabilidad de las principales tareas de gestión de la liberación de órdenes de trabajo;
monitorear, inspeccionar y documentar el progreso; comparar los resultados planificados con
los reales; y tomando medidas correctivas.
Durante la fabricación del sistema, la calidad del trabajo se evalúa constantemente. Como
ocurre con la mayoría de las tareas en la etapa de producción/construcción, el control de
calidad no es, per se, responsabilidad del director del proyecto; no obstante, debido a que el
gerente del proyecto es responsable de la calidad del sistema final, debe asegurarse de que
otros gerentes en la etapa de producción/construcción hayan implementado un plan de
calidad (discutido en el Capítulo 9) para lograr los objetivos de calidad del proyecto.
Ver Capítulo 9
A lo largo de la etapa de producción/construcción, se pueden realizar numerosas pruebas

en componentes, subsistemas y el artículo final final para garantizar que todo cumpla con los
requisitos. Los aspectos de estas pruebas se discuten en el Capítulo 9.
El director del proyecto supervisa la preparación de los planes y programas de prueba y los incluye
en el plan de producción/construcción, y se asegura de que los recursos necesarios estén disponibles
para realizar las pruebas y que los resultados de las pruebas se documenten y archiven para
referencia posterior.
Planificación para la implementación
Con la planificación del proyecto por etapas, los detalles del plan del proyecto se completan a medida
que la información está disponible; durante cada etapa del proyecto, se prepara el plan detallado
para la siguiente etapa. La planificación de la implementación debe comenzar temprano en el
proyecto, en la fase de definición, sin embargo, no es hasta la etapa de producción/construcción que
la planificación de la implementación puede proceder en detalle.
La implementación es el proceso de entregar el sistema al usuario. Las dos actividades principales
en la implementación son instalar el sistema en el entorno del usuario y capacitar al usuario para
operar el sistema. El gerente del proyecto debe desarrollar el plan por adelantado para que la etapa
de implementación pueda comenzar al finalizar la etapa de producción/construcción o antes. El plan
debe garantizar que los elementos complementarios necesarios estarán disponibles a tiempo para la
capacitación del usuario, la instalación del sistema y la operación. Debe abordar la estrategia para
reemplazar el sistema existente por el nuevo e incluir:
1. El enfoque para la conversión del antiguo sistema al nuevo sistema.

2. Secuencia y programación de las actividades de implementación.
3. Criterios de aceptación del nuevo sistema.
4. El enfoque para eliminar gradualmente el antiguo sistema y reasignar personal.
Se podría haber desarrollado un plan de implementación inicial como parte del plan de ejecución del
proyecto; ahora se prepara un plan más detallado con la participación del cliente para abordar los
puntos anteriores. Mientras se prepara este plan, el contratista acumula materiales para capacitar al
usuario en la operación y mantenimiento del sistema. Para sistemas complejos, estos materiales
incluyen manuales para la operación, reparación, prueba y servicio del sistema; materiales de
formación y simuladores; manuales para la formación de formadores; y dibujos esquemáticos,
herramientas especiales y equipos para servicio y soporte. Estos son algunos de los "elementos
secundarios"
previamente mencionado.
Se debe llegar a un acuerdo con el cliente sobre cómo y cuándo se puede cerrar el proyecto,
es decir, cómo y cuándo el cliente considerará aceptable el sistema y el proyecto completo. Los
malentendidos sobre esto, como "aceptación solo después de la modificación", pueden hacer
que un proyecto se retrase indefinidamente; para evitar esto, los requisitos del usuario definidos
al principio del proyecto deben incluir condiciones o criterios para la aceptación del sistema por
parte del cliente. Esto se discute más en el próximo capítulo.
11.4 Proceso de Seguimiento y Control
El seguimiento y control del proyecto, el proceso de mantener el proyecto en movimiento en la dirección

establecida por el plan de ejecución, ocurre a lo largo del proyecto, desde el inicio hasta el cierre. El
proceso es pertinente a cualquier situación en la que el trabajo deba lograr ciertas metas o ajustarse a
un plan. Dado que la mayor parte del trabajo del proyecto ocurre en la fase de ejecución, es aquí donde
también ocurre la mayor parte del seguimiento y control del proyecto.
En términos simples, el proceso de control del proyecto implica evaluar el progreso en relación con
los objetivos o el desempeño planificados y tomar medidas correctivas. Se puede comparar con un
sistema de aire acondicionado doméstico, que funciona de esta manera:
1. La temperatura ambiente deseada se establece en el termostato.

2. El termostato mide la temperatura ambiente real y determina la variación de temperatura
(temperatura real menos temperatura deseada).
3. Si la variación es positiva, el termostato enciende el acondicionador de aire hasta que la
temperatura real coincide con la temperatura deseada (es decir, la variación se vuelve cero).
Prácticamente todos los procesos de monitoreo y control siguen los mismos pasos de (1) establecer el
estándar de desempeño, (2) comparar el desempeño real con el estándar y (3) tomar medidas
correctivas para eliminar cualquier variación.
En los proyectos, establecer estándares de desempeño ocurre principalmente en la fase de
definición y al principio de la fase de ejecución. Los estándares son los requisitos del usuario, las
especificaciones técnicas, los costos presupuestados, los cronogramas y los requisitos de recursos.
El siguiente paso, comparar el rendimiento real con los estándares, ocurre durante la fase de
ejecución. Los presupuestos, los cronogramas y las especificaciones de desempeño se controlan y
comparan con los gastos reales, los resultados de las pruebas, el trabajo completado y otras medidas
de desempeño.
Por último, se toman medidas correctivas siempre que el desempeño real difiere significativamente
del desempeño planificado: se hace algo para cumplir con los resultados y estándares planificados, o
se revisan los resultados y estándares planificados. En este último caso, el contratista debe trabajar
con el cliente para cambiar los objetivos,
revisar los requisitos y modificar el plan. No debe haber sorpresas, y cualquier revisión debe informarse
a todas las partes interesadas relevantes.
Vale la pena repetir que para mantener el proyecto alineado con los estándares (requisitos,
cronogramas y presupuestos, etc.) ¡primero debe haber un plan! En otras palabras, el precursor del
control del proyecto es la definición del proyecto: sin requisitos claros y completos y un buen plan del
proyecto, no puede haber control del proyecto.
Seguimiento de Proyectos
El monitoreo del proyecto se refiere al seguimiento del proyecto, evaluando qué tan bien lo está
haciendo y pronosticando cómo lo hará en el futuro. El seguimiento del proyecto implica la recopilación
e interpretación de datos y la presentación de información.
Los datos recopilados deben relacionarse con los estándares de desempeño del proyecto, es decir,
con los planes del proyecto, los entregables, los cronogramas, los presupuestos y los requisitos. Las
fuentes de datos típicas incluyen facturas de compra de materiales, tarjetas de tiempo de los
trabajadores, avisos de cambios, resultados de pruebas, órdenes de trabajo y opiniones de expertos.
La cantidad y variedad de datos recopilados deben equilibrarse: demasiados datos serán demasiado
costosos de recopilar y examinar, muy pocos no reflejarán adecuadamente el estado del proyecto y
permitirán que los problemas no se controlen. Los datos deben analizarse y los resultados deben
informarse con la suficiente rapidez y frecuencia para que los gerentes puedan detectar rápidamente
las desviaciones del plan y tomar medidas correctivas.
¿Con qué frecuencia deben recopilarse, evaluarse y notificarse los datos? Una buena regla general
es evaluar el progreso del trabajo cada semana. Para proyectos pequeños, esto garantiza que incluso
los paquetes de trabajo que duran solo unas pocas semanas se verificarán al menos dos veces.
Para paquetes de trabajo que duran varios meses, la evaluación cada 2 o 3 semanas puede ser
adecuada. El objetivo es verificar el trabajo con la frecuencia suficiente para permitir una evaluación
precisa del progreso y detectar problemas temprano, pero no con tanta frecuencia como para que se
vuelva una carga. La frecuencia también depende de las personas que realizan el trabajo (las personas
competentes y motivadas pueden ser menos supervisadas que las personas menos competentes o
menos motivadas) y el nivel del trabajo supervisado (por ejemplo, el nivel del programa puede ser
supervisado con menos frecuencia que el nivel del paquete de trabajo). ).
Seguimiento y Control Interno y Externo
El seguimiento y control de un proyecto se realiza tanto interna como externamente.

El control interno se refiere a los procedimientos del contratista para monitorear el trabajo,
informar el estado y tomar medidas. El control externo se refiere a procedimientos adicionales
impuestos por otros, incluido el cliente. Los contratos militares y gubernamentales, por
ejemplo, imponen un control externo al estipular:
1. Informes frecuentes del contratista sobre cronogramas, costos y

actuación.
2. Inspecciones de trabajo por parte de los administradores de programas gubernamentales.
3. Inspección de los libros y registros del contratista por parte del gobierno
auditores
4. Condiciones estrictas impuestas por el contratista sobre los costos y precios permitidos del proyecto
políticas, etc
El control externo puede ser una fuente de molestia para el contratista, ya que implica que
los gerentes pasen por alto a los gerentes y aumenta los costos burocráticos y administrativos.
No obstante, a veces es necesario proteger los intereses del cliente, especialmente en
proyectos de costo incrementado. Idealmente, el contratista y el cliente pueden trabajar
juntos amigablemente para establecer planes compatibles y métodos de monitoreo del trabajo.
Control de costos tradicional
En situaciones fuera del proyecto, el desempeño del trabajo se mide con un análisis de
variación, que compara la cantidad gastada con la cantidad presupuestada. En situaciones
de proyecto, el análisis simple de variación de costos es inadecuado.
Ejemplo 11.2: Análisis de variación de costos
Considere el siguiente informe de estado semanal para el paquete de trabajo "desarrollo

de software":
Costo presupuestado para el Costo real por período = Variación del período
período = $12,000 $14,000 = $2,000
Presupuesto acumulado a la Costo real acumulado hasta la fecha Varianza

fecha acumulada
= $25,000 = $29,000 = $4,000
El informe indica excesos presupuestarios aparentes tanto para el período como para los costos acumulados,
con un exceso de costos acumulados hasta la fecha de $4,000. Pero debido a que no sabemos cuánto trabajo
se ha completado, es imposible determinar si el proyecto está realmente por encima del presupuesto.
Suponga que los $25,000 fueron la cantidad presupuestada para completar el 50 por ciento del desarrollo
de software. Si el 50 por ciento del trabajo se hubiera completado según lo previsto, entonces el proyecto, de
hecho, estaría por encima del presupuesto y habría que hacer algo para reducir o eliminar el exceso de $4,000.
Ahora supongamos que solo se ha completado el 30 por ciento del trabajo; en ese caso, el proyecto estaría
claramente por encima del presupuesto (y retrasado también), y se podrían esperar más sobrecostos
simplemente para quedar atrapados. Como tercera posibilidad, suponga que el 70 por ciento del trabajo se ha
completado; esto es sustancialmente más trabajo de lo que estaba programado. Debido a eso, es posible que
el proyecto no esté por encima del presupuesto e incluso podría estar por debajo del presupuesto para la
cantidad de trabajo realizado.
El punto del ejemplo es que para poder evaluar el estado del proyecto, la información de costos no es suficiente;
también necesita información sobre el progreso del trabajo : información sobre el porcentaje de trabajo completado,
los hitos logrados, etc., todo ello discutido más adelante.
Sistemas de Contabilidad de Costos para el Control de Proyectos
A principios de la década de 1960, el gobierno de EE. UU. desarrolló un sistema de programación y contabilidad de
costos basado en PERT llamado PERT/ Cost. El sistema pasó a ser obligatorio para todos los contratos militares y
de I+D con el Departamento de Defensa de EE. UU. y la NASA (DOD/NASA). Cualquier contratista que quisiera
trabajar para DOD/NASA tenía que usar el

sistema y producir los informes necesarios. PERT/Cost fue una mejora con respecto a las técnicas
tradicionales de contabilidad de costos y estimuló el desarrollo de otros sistemas aún más sofisticados
para rastrear el trabajo e informar el progreso y los costos. Era el sistema original de contabilidad de
costos de proyectos basado en la red: el sistema PCA mencionado en el Capítulo 8 y los sistemas
modernos de Gestión del valor ganado (EVM) que se analizan más adelante en este capítulo.
Ver Capítulo 8
Hoy en día, la mayoría de los PCAS integran información sobre paquetes de trabajo, presupuestos
y cronogramas en un paquete de control de proyectos unificado. Permiten identificar las causas de
los sobrecostos y los sobrecostos de programación entre numerosos paquetes de trabajo o
presupuestos. Dos características comunes de estos sistemas, que se describirán más adelante, son
el uso de paquetes de trabajo y cuentas de control como el punto básico de recopilación de datos
para el control del proyecto y el uso del valor ganado para medir el desempeño del proyecto.
11.5 Paquetes de trabajo y cuentas de control
Los capítulos anteriores describieron el papel de los paquetes de trabajo y las cuentas de control
en la planificación y presupuestación de proyectos; no por casualidad, también son elementos clave
del control del proyecto. Cada cuenta de control consta de uno o más paquetes de trabajo; cada
paquete de trabajo es como un contrato para un trabajo específico con requisitos, una descripción
del trabajo, un presupuesto, un cronograma, etc. Por lo tanto, cada paquete de trabajo y cuenta de
control es un punto focal para la recopilación de datos, la evaluación del progreso del trabajo, la
evaluación de problemas y la acción correctiva.
Los proyectos grandes pueden estar compuestos por cientos de paquetes de trabajo, lo que
hace que sea potencialmente difícil identificar los que causan sobrecostos o sobrecostos en el
cronograma. Una ventaja de un PCAS es que puede clasificar fácilmente todos los paquetes de
trabajo para localizar las fuentes de los problemas. Aunque el paquete de trabajo individual sigue
siendo el elemento central para el control, un PCAS puede consolidar y reportar información para
cualquier nivel del proyecto, desde el nivel de la cuenta de control individual o del paquete de
trabajo hasta el nivel del proyecto. Debido a que las cuentas de nivel superior en la estructura de
cuentas de control se construyen a través de la WBS y las jerarquías organizacionales, las
variaciones en costos y cronogramas en cualquier nivel de proyecto se pueden rastrear a través de
la estructura para identificar los paquetes de trabajo que causan las variaciones.
autorizacion de trabajo
Parte del proceso de control del proyecto es la autorización del trabajo o el control de inicio y fin:
todo el trabajo del proyecto se inicia solo después de la autorización formal y se detiene solo
después de la revisión y aceptación. Esto se aplica tanto al proyecto en su conjunto como a cada
uno de los paquetes de trabajo. A nivel de proyecto, el director del proyecto está autorizado a
comenzar el proyecto tras la aceptación del plan del proyecto por parte del cliente, el director del
programa y/o la alta dirección. Luego, el gerente del proyecto autoriza a los gerentes de los
subproyectos para que comiencen, quienes autorizan a los gerentes y supervisores de los paquetes
de trabajo en el siguiente nivel inferior, como se muestra en la Figura 11.3. El proceso es una
continuación del proceso de iniciación y autorización descrito en el Capítulo 3
y se muestra en la Figura 3.9.
Ver Capítulo 3
El mismo proceso también se aplica a las fases de autorización de un proyecto: después de

cada fase, el cliente y otras partes interesadas evalúan los resultados de la fase, el plan para la
siguiente fase y los riesgos y, si todos son aceptables, autorizan la siguiente fase. (ver “planificación
de proyectos por etapas” discutida en el Capítulo 4 y “proceso de activación” en el Capítulo 17). A
veces, en proyectos contratados, si los resultados de la fase se juzgan inaceptables, se paga al
contratista el monto adeudado y se rescinde el proyecto.
En proyectos grandes, la autorización se subdivide en las etapas de liberación del contrato,

liberación del proyecto y liberación de la orden de trabajo o solicitud de trabajo. Después de que el
cliente adjudica el contrato, el administrador del contrato prepara un documento de liberación del
contrato que especifica los requisitos contractuales y da el visto bueno al director del proyecto. El
contralor o contador del proyecto luego prepara un documento de liberación del proyecto, que
autoriza la financiación del proyecto.
Las tareas o paquetes de trabajo individuales comienzan solo al recibir una orden de trabajo (u
"orden de ingeniería", "orden de taller" u "orden de prueba", según el tipo de trabajo).
A medida que se acerca la fecha de inicio programada para la tarea, el director del proyecto o la
oficina del proyecto entrega el documento de autorización al contratista o departamento para realizar
el trabajo. Para proyectos simples o actividades simples, la autorización verbal puede ser suficiente.
Recopilación de datos de costos, cronogramas y progreso del trabajo

Figura 11.3 Proceso de autorización de trabajo del proyecto.
Una vez que comienza el trabajo, los datos sobre los costos reales y el progreso del trabajo en el paquete
de trabajo se recopilan periódicamente y se ingresan en el PCAS o PMIS (discutido en los Capítulos 8 y
12). El PCAS genera informes de rendimiento periódicamente o según sea necesario para cada paquete
de trabajo, departamento y todo el proyecto.
Evaluar el impacto del progreso del trabajo en los cronogramas es responsabilidad del gerente funcional
o supervisor del equipo a cargo del paquete de trabajo y la tarea.
Cada semana, el supervisor cuenta las horas de trabajo para cada tarea como se indica en las tarjetas de
tiempo. Ella anota las tareas completadas y las tareas aún "abiertas", y estima el tiempo que aún se
necesita para completar las tareas abiertas; a partir de este último, calcula el "porcentaje completado" o el
porcentaje de progreso de la tarea. El progreso se registra en un diagrama de Gantt que muestra las
tareas completadas y abiertas. La figura 11.4 es un ejemplo que muestra el estado del proyecto LOGON
a partir de la semana 20. El porcentaje completo es
representado resaltando la barra de cada tarea. Resaltar toda la barra indica 100 por ciento
completo; resaltar un cuarto de la barra, por ejemplo, significa un 25 por ciento completo. Los
paquetes de trabajo K, L, M, N, O, P y Q están todos abiertos (en proceso pero aún no completados);
los tres primeros y Q están retrasados; O está por delante.
Figura 11.4 Diagrama de Gantt que muestra el estado del trabajo a la semana 20.
¿Cómo se mide el progreso del trabajo y el porcentaje completado? Los costos y el tiempo
transcurrido son fáciles de medir, pero ninguno dice mucho sobre el progreso real del trabajo, por lo
que los gerentes de proyectos a menudo deben confiar en medidas subjetivas. En una encuesta
5
sobre las formas de medir el desempeño de un proyecto en curso, Thompson identificó lo siguiente.
1. Supervisión. Los gerentes y supervisores evalúan el progreso mediante la observación

directa, haciendo preguntas y revisando los informes escritos y la documentación del
proyecto.
2. Hitos. Estos son puntos finales de tareas fácilmente medibles, o transición

puntos entre tareas; por ejemplo, finalización de dibujos, informes, documentos de diseño o
problemas técnicos específicos de la solución.
3. Pruebas y demostraciones. Descritos anteriormente, estos pueden variar desde pruebas
simples de los componentes del sistema hasta pruebas de aceptación del usuario y del
sistema completo. Son una buena manera de medir objetivamente el progreso técnico en
etapas intermedias del proyecto.
4. Reseñas. Descritas en el Capítulo 12, estas son reuniones con gerentes y personal técnico
para revisar el progreso de un diseño o sistema contra el plan.
Ver Capítulo 12
5. Expertos externos. El director del proyecto u otra parte interesada invita a los expertos a
participar en un panel. El panel evalúa el estado del proyecto observando el trabajo en curso,
hablando con el personal del proyecto y revisando la documentación.
6. Estado de la documentación del diseño. Los gerentes de proyectos experimentados pueden
determinar cuándo un diseño está casi terminado por la "integridad" de documentos como
dibujos, esquemas, diagramas funcionales, manuales y procedimientos de prueba.
7. Recursos utilizados. Una solicitud o un cambio en los recursos puede reflejar un progreso;
por ejemplo, las tareas que están a punto de completarse a menudo requieren instalaciones,
personal y equipos especiales de prueba o implementación.
8. Tareas reveladoras. Tareas como el diseño de conceptos, la definición de requisitos, el
análisis de factibilidad y las pruebas repetidas suelen ocurrir al principio de un proyecto; su
aparición más tarde en el proyecto significa una falta de progreso.
9. Benchmarking o analogía. Ciertas tareas, o el proyecto completo, pueden compararse con
tareas o proyectos similares como una forma cruda de sopesar el progreso relativo.
10. Cambios, errores y reelaboración. Debido a que, por lo general, la cantidad de solicitudes
de cambio (que se analizan más adelante), errores, problemas, etc., debería disminuir a
medida que el proyecto se acerca a su finalización, una cantidad alta sostenida puede indicar
una falta de progreso. Esto se analiza más adelante en "seguimiento de problemas".
Si bien medidas como estas se utilizan para evaluar el trabajo en curso y revelar
problemas emergentes, también se necesitan las medidas de gestión de riesgos discutidas en el

Capítulo 10 para anticipar los problemas.
Ver Capítulo 10
Cada semana, el supervisor del paquete de trabajo contabiliza los gastos actuales. Las horas
de mano de obra reportadas en las tarjetas de tiempo se convierten en costo de mano de obra
directa. Los costos de mano de obra directa, material y nivel de esfuerzo (pruebas, soporte, etc.)
para tareas completadas y abiertas se agregan a los costos de trabajo de períodos anteriores y
la suma se multiplica por la tasa de porcentaje de gastos generales. También se incluyen los
cargos por mora y los costos pendientes (una fuente frecuente de sobrecostos). El supervisor del
paquete de trabajo documenta cualquier cambio estimado en los presupuestos o cronogramas
para el trabajo restante y lo envía al gerente del proyecto para su aprobación. El supervisor envía
un informe al director del proyecto que muestra los costos de todo el trabajo completado en
períodos anteriores más el trabajo realizado en el período actual. Una vez que el director del
proyecto valida esta información, la ingresa en el PCAS, que acumula los costos hasta la fecha
para todos los paquetes de trabajo y prepara un informe resumido. Periódicamente, el gerente
del proyecto revisa estos informes para reevaluar el proyecto y estimar el trabajo que aún se
necesita y el costo para completar el proyecto; como se describe más adelante, estos proporcionan
pronósticos de la fecha de finalización y el costo del proyecto al momento de la finalización.
Cuando se completa una tarea o un paquete de trabajo, su presupuesto se cierra para evitar
cualquier facturación adicional no autorizada.
11.6 Énfasis en el seguimiento y control del proyecto
El seguimiento y control del proyecto aborda cinco áreas: alcance, calidad, cronograma, costo
y adquisiciones.
Control de alcance
Los proyectos tienen una tendencia natural a crecer con el tiempo debido a los cambios y
adiciones al alcance, un fenómeno llamado "desplazamiento del alcance". Los cambios o
adiciones al alcance reflejan cambios en los requisitos y la definición del trabajo, que
generalmente van acompañados de aumentos en el tiempo y el costo. El objetivo del control
del alcance es identificar dónde se están produciendo cambios en los requisitos o el trabajo,
garantizar que los cambios sean necesarios y beneficiosos, restringir o delimitar los cambios
siempre que sea posible y gestionar la implementación de los cambios. El control del alcance
se implementa a través del sistema de control de cambios y la gestión de la configuración, que
se describen más adelante.
Control de calidad
El control de calidad es administrar el trabajo para lograr los requisitos y especificaciones

deseados en el artículo final y tomar medidas preventivas para reducir o eliminar errores y
equivocaciones en el proceso de trabajo. Discutido en el Capítulo 9, el control de calidad del
proyecto comienza con el plan de gestión de calidad que establece las condiciones o
estipulaciones sobre lo que es necesario en cada paquete de trabajo para garantizar resultados
de calidad. También especifica las pruebas, inspecciones y revisiones para evaluar el progreso
hacia el cumplimiento de los requisitos. En los proyectos técnicos, el progreso se realiza
mediante una metodología denominada medición del rendimiento técnico (TPM), que se
analiza más adelante en este capítulo.
Ver Capítulo 9
El director del proyecto puede designar un equipo de mejora de la calidad, un pequeño grupo
responsable de identificar y eliminar las fuentes de problemas de calidad únicos y repetitivos. En un
proyecto pequeño, un equipo multifuncional podría cumplir esta función; en un proyecto grande, es
posible que se necesiten varios equipos especializados para abordar problemas con fases o tecnologías
particulares.
Control de horarios
La intención del control del cronograma es mantener el proyecto dentro del cronograma. Incluso los
proyectos planificados con más cuidado se retrasan por razones que escapan al control de cualquiera,
incluidos, por ejemplo, cambios de alcance necesarios, problemas climáticos y escasez de materiales.
Los excesos en el cronograma también ocurren debido a la multitarea, la procrastinación y las
estimaciones de tiempo incorrectas, como se explica en el Capítulo 7. A continuación se presentan
algunas pautas para reducir la variabilidad del cronograma y los excesos en el cronograma.
Ver Capítulo 7
Buffers de tiempo y gráficos de fiebre
Descrito en el Capítulo 7, un colchón de tiempo es una reserva de cronograma, una cantidad de tiempo
incluida en la duración esperada del proyecto para dar cuenta de la incertidumbre. Para implementar
un búfer de tiempo, la fecha de finalización, calculada mediante duraciones ajustadas, se incrementa
en la cantidad del búfer. Si la fecha de finalización tardía es el 31 de julio y el búfer de tiempo es de 4
semanas, la fecha de finalización objetivo se establece para el 31 de agosto.
Los amortiguadores de tiempo son un aspecto de la gestión de proyectos de cadena crítica (CCPM),
que prescribe ubicar amortiguadores al final de la cadena crítica para el proyecto y al final de todos los
subcaminos que alimentan la cadena crítica. Una vez que un proyecto está en marcha, se realiza un
seguimiento de la cantidad de búfer "consumido". Cada vez que se retrasa una tarea en la cadena
crítica o en una cadena de alimentación, “consume” el búfer de tiempo. Cuanto más se consuma el
búfer, más probable es que se agote el búfer y se sobrepase la fecha de finalización prevista. Por lo
tanto, el proyecto debe administrarse para minimizar el consumo de búfer.
El consumo de reserva se rastrea y controla con un "gráfico de fiebre", un gráfico que muestra
el porcentaje de reserva del proyecto consumido frente al porcentaje de la cadena crítica
completada (Figura 11.5). Al principio, un “proyecto saludable” habrá consumido poco o nada de
su reserva, pero a medida que avanza el proyecto, se puede esperar que el porcentaje de reserva
consumido aumente y que el gráfico en el gráfico aumente en diagonal. El seguimiento del gráfico
le permite al director del proyecto medir de alguna manera si el proyecto se completará antes, a
tiempo o tarde; una fuerte tendencia al alza, por ejemplo, indica que el proyecto está estancado:
se está progresando poco en las tareas críticas de la cadena. Para un proyecto saludable, la
pendiente de la línea es poco profunda y gran parte de la reserva del proyecto permanece sin
consumir al final del proyecto.
Completar un proyecto con búfer restante es equivalente a completar el proyecto antes de la fecha
de finalización prevista. Por lo tanto, para completar el proyecto antes de tiempo, el proyecto debe
administrarse para minimizar el consumo de búfer; cuanto más buffer quede, más adelante estará
el proyecto.
El color amarillo en el gráfico indica la posibilidad de que el proyecto sobrepase su fecha límite;
rojo significa fuerte potencial. El cuadro de fiebre se actualiza semanalmente y se toman medidas
rápidas cada vez que la trama se desvía hacia las zonas amarillas o rojas. Las tareas que
consumen el búfer se identifican para que los gerentes puedan desviar más recursos hacia ellas,
desacoplarlas de la cadena crítica o tomar otras medidas. También se crean gráficos de fiebre
para los amortiguadores de alimentación para monitorear el riesgo de retrasar la cadena crítica.
Figura 11.5 Gráfico de fiebre: Porcentaje de búfer consumido versus porcentaje de cadena crítica completada. El cuadro de fiebre es
dividido en regiones verde, amarilla y roja para indicar el estado del proyecto.
Ejemplo 11.3: Cálculo del gráfico de fiebre
Los puntos en el gráfico de fiebre se calculan de la siguiente manera; cada semana:
1. Estime el porcentaje completado para cada tarea abierta en la cadena crítica (CC). Multiplique
este porcentaje por las semanas estimadas necesarias para cada tarea para completar las
semanas.
2. Sume las semanas completadas para todas las tareas abiertas y cerradas (terminadas) en el
CC; esto da CC semanas completadas. Luego divida esta suma por la longitud estimada de
todo el CC para obtener el porcentaje de CC completado (eje x).
3. Calcular: Semanas transcurridas hasta la fecha – CC semanas completadas = Semanas de

búfer consumidas. Calcular: Semanas de búfer consumido/Duración del búfer del proyecto =
Porcentaje de búfer consumido (eje y)
El procedimiento anterior se puede modificar usando días. Los resultados serían los mismos aunque
más precisos.
Como ejemplo del cálculo, considere el proyecto de la figura 11.6.
Suponga que los puntos de datos en el diagrama de fiebre en la Figura 11.5 se derivaron del estado
del proyecto evaluado cada 4 semanas (el estado debe evaluarse cada semana; aquí se usan 4 semanas
para ahorrar espacio). En función del porcentaje completado de la tarea, el porcentaje de CC completado
y el porcentaje de búfer consumido se calculan como se muestra en la Tabla 11.1.
Según la última línea de la tabla, el proyecto se completa en 33 semanas, que es el

cantidad por la cual el proyecto terminó antes del objetivo (36 ÿ 33 = 3).
Figura 11.6 Cadena crítica = 24 semanas, amortiguador del proyecto = 12 semanas.
Tabla 11.1
El gráfico de fiebre es una forma de administrar los amortiguadores de tiempo; el siguiente ejemplo
muestra otro.
Ejemplo 11.4: Repartiendo las Reservas: El

Proyecto Mars Pathfinder 6
El objetivo del proyecto Pathfinder era aterrizar en Marte un rover autopropulsado de seis
ruedas del tamaño de una patineta que se desplazaría sobre el terreno y enviaría fotografías y
datos científicos (Figura 11.7). La reserva presupuestaria del proyecto fue de $40 millones,
alrededor del 30 por ciento del presupuesto total (un porcentaje alto, pero común en proyectos
tecnológicos riesgosos), y su reserva de programación fue de 20 semanas, alrededor del 13
por ciento de los 37 meses de diseño, construcción y ejecución del proyecto. calendario de
pruebas.
Figura 11.7 El rover Mars Pathfinder.
Una vez que el proyecto estaba en marcha, surgió la pregunta: ¿Cómo se deberían
utilizar las reservas? Usarlos con demasiada libertad y demasiado pronto no dejará nada
para más adelante. Utilizarlos con demasiada tacañería sofocará el progreso, aumentará
el riesgo y dará como resultado reservas sobrantes que podrían haber tenido un buen
uso. La Gerencia adoptó la directriz de delimitar el monto de las reservas programadas
disponibles para uso en cada período del proyecto. Por ejemplo, nada de eso debía
usarse (no se permitía el deslizamiento) para el inicio del montaje y la prueba del sistema.
Si luego surgían problemas, la directriz era comprometer las reservas presupuestarias
necesarias para mantener el proyecto dentro del cronograma. (El tiempo era una cuestión
estratégica: la fecha de lanzamiento tenía que coincidir con el posicionamiento relativo
exacto de la Tierra y Marte).
El proyecto fue un éxito. Pathfinder aterrizó de manera segura y el pequeño rover envió
miles de imágenes. El proyecto estableció un nuevo estándar al
diseñar, construir y aterrizar una nave espacial en Marte en la mitad del tiempo y a una vigésima
parte del costo de las misiones anteriores.
Informar con frecuencia sobre el estado de la actividad
Las tareas o paquetes de trabajo en la ruta crítica o la cadena crítica deben estar listos para comenzar
lo antes posible, pero para que eso suceda, el equipo del proyecto debe conocer el estado de los
predecesores de cada tarea. Especialmente en proyectos sensibles al tiempo como Pathfinder, cada
actividad debe proporcionar a sus actividades sucesoras informes de estado diarios que indiquen los
días restantes esperados para completar y la fecha más temprana en que los sucesores deben
comenzar a trabajar. El mandato es que tan pronto como se completen los predecesores inmediatos
de una actividad crítica, el equipo asignado a la siguiente actividad comenzará a trabajar, incluso si
tiene que dejar de trabajar en otra cosa. En la terminología de CCPM, la cuenta regresiva para
comenzar a trabajar temprano en la cadena crítica se denomina reserva de recursos.
Dar a conocer las consecuencias de los retrasos y los beneficios de la finalización anticipada
Todos (miembros del equipo, subcontratistas y proveedores) deben conocer las consecuencias de
excederse en el cronograma y los beneficios de terminar antes de tiempo. El contrato del proyecto
podría ofrecer pagos de incentivos por finalización anticipada o presupuestar dinero extra para
bonificaciones a los trabajadores y subcontratistas que finalicen antes de tiempo. El siguiente ejemplo
describe otras medidas para mantener los proyectos a tiempo.
Ejemplo 11.5: Cumplimiento de los plazos de

lanzamiento en Microsoft 7
Microsoft cumple con las fechas de lanzamiento del producto mediante la congelación visual,
las fechas de envío objetivo internas y los búferes de tiempo. Un “congelamiento visual” es una
suspensión impuesta en el diseño del producto que afecta aspectos de la apariencia visual del
producto. La fecha de congelación generalmente ocurre alrededor del 40 por ciento del cronograma.
Al llegar a esa fecha, los desarrolladores bloquean el producto y, a partir de entonces, permiten
pocos o ningún cambio en funciones como menús, cuadros de diálogo y ventanas de
documentos. La congelación permite que el grupo de educación del usuario prepare materiales
de capacitación y documentación del sistema (elementos complementarios) junto con la
depuración y prueba final del producto para que los materiales estén listos al momento del
lanzamiento del producto.
Microsoft también establece "fechas objetivo internas" que presionan a los desarrolladores
para que decidan qué características del producto deben incluirse absolutamente y cuáles
pueden prescindirse; de lo contrario, tienden a seguir agregando funciones al producto e
ignorar el cronograma. Esto garantiza que el producto contendrá las funciones mínimas
necesarias y aún así se lanzará a tiempo.
Para dar cuenta de tareas pasadas por alto o mal entendidas, errores difíciles y cambios en
las funciones, Microsoft coloca búferes de tiempo en los cronogramas de los proyectos. Los
amortiguadores, que pueden oscilar entre el 20 y el 50 por ciento del tiempo total del programa,
se utilizan exclusivamente para cubrir incertidumbres y no tareas rutinarias, no claras para mí.
El equipo del proyecto se esfuerza por cumplir con la fecha de envío interna, que es la fecha
de lanzamiento anunciada al público menos el margen de tiempo.
Control de Adquisiciones
El contratista principal es responsable de la calidad, el cronograma y el costo de todos los artículos

adquiridos para el proyecto. A menudo, el gerente del proyecto visitará e inspeccionará las
instalaciones de cada proveedor para asegurarse de que sean capaces de cumplir con los requisitos.
Una vez que el proyecto está en marcha, supervisa el progreso de cada proveedor visitando el sitio
del proveedor y solicitando informes frecuentes de estado y, a veces, de gastos del proveedor. El
director del proyecto hace lo que sea necesario para avisar o ayudar a los proveedores cuando
surgen problemas. Para todos los principales artículos y servicios subcontratados, se deben preparar
planes de contingencia, incluida una posible disposición contractual para transferir el trabajo a otros
proveedores en caso de que los proveedores originales enfrenten problemas graves o irrecuperables.
Estas contingencias se abordan en el plan de adquisiciones y el plan de riesgos del proyecto.
control de costos
El propósito del control de costos es rastrear las variaciones en los gastos con respecto a los
presupuestos, eliminar los gastos no autorizados o inapropiados y minimizar o contener los
cambios de costos. Identifica dónde y por qué se han producido variaciones, y cuándo son
necesarios cambios en las líneas base de costos.
El control de costos ocurre tanto a nivel de paquete de trabajo como a nivel de proyecto,
utilizando la estructura de cuenta de costos y el PCAS descritos en el Capítulo 8. A través del
PCAS, los gastos reales se contabilizan, validan, acumulan y comparan con los costos
presupuestados. Usando los métodos que se describen a continuación, el gerente del proyecto
revisa periódicamente los costos reales y presupuestados, evalúa el trabajo completado y
estima el costo y la fecha de finalización del proyecto.
Ver Capítulo 8
11.7 Análisis de rendimiento y gestión

del valor ganado
El desempeño del proyecto o cualquier parte del mismo se puede evaluar con tres variables: BCWS, ACWP y
BCWP. Estos son acrónimos estándar de la industria, pero para ahorrar tinta usaremos los términos abreviados
PV, AC y EV.
1. PV es el valor planificado (o el costo presupuestado del trabajo programado, BCWS) : la suma del costo
de todo el trabajo y el esfuerzo prorrateado programado para completarse dentro de un período de
tiempo determinado, como se especifica en el presupuesto original.
Por ejemplo, en el Capítulo 8, la Tabla 8.5 y la Figura 8.15 muestran los gastos acumulativos y
semanales del proyecto LOGON. Estas cantidades representan PV. En la semana 20, por ejemplo, el
PV hasta la fecha es de $512 000 y el PV semanal es de $83 000.
Ver Capítulo 8
2. AC es el costo real del trabajo realizado (o ACWP): el costo real
gastos a partir de un período de tiempo determinado.
3. EV es el valor ganado (o costo presupuestado del trabajo realizado, BCWP) : el valor del trabajo realizado
hasta el momento (paquetes de trabajo completados total o parcialmente) de acuerdo con el presupuesto
8
original. De este modo,
• Para una tarea de trabajo completada, EV es lo mismo que el PV para esa tarea. • Para una
tarea de trabajo parcialmente completada, el EV se calcula como el porcentaje completo estimado
de la tarea multiplicado por el presupuesto de la tarea. (Alternativamente, se calcula como el
50 por ciento del presupuesto de la tarea cuando se inicia la tarea, luego el 100 por ciento del
presupuesto de la tarea cuando se completa).
La aplicación de estas variables para rastrear y evaluar el desempeño del proyecto se denomina gestión del valor
ganado o EVM. El siguiente ejemplo ilustra.

Ejemplo 11.6: EV versus PV en la

empresa Parmete
The Parmete Company tiene un contrato de costo fijo de $200,000 para instalar 1,000
parquímetros. El contrato exige retirar los parquímetros viejos de sus soportes y reemplazarlos
por otros nuevos a un costo de $200 por metro.
Parmete estima que se pueden instalar 25 metros cada día. A 25 metros por día y $200
por metro, el proyecto debe terminar en 40 días hábiles con un PV total de $200,000. También
sobre esa base, el valor planificado del trabajo programado (PV) a partir de un día determinado
se puede determinar multiplicando la cantidad de días hábiles completados a partir de ese día
por el costo de instalar 25 medidores ($200 por 25). Por ejemplo, a partir del día 18,
PV = 18 días × (25 metros) × ($200) = $90 000
Es decir, a partir del decimoctavo día de trabajo en el proyecto, el cronograma y el presupuesto

del proyecto especifican que se debería haber realizado un trabajo por un valor de $90,000.
Tenga en cuenta que PV siempre está asociado con una fecha específica en el cronograma
del proyecto.
Por el contrario, el valor ganado (EV) de un día determinado representa el valor del trabajo
realmente realizado en términos de presupuesto. En este proyecto, EV es la cantidad de
medidores realmente instalados hasta la fecha, multiplicada por los $200 presupuestados para
cada medidor. Supongamos, por ejemplo, que al día dieciocho se hubieran instalado 400
metros; de este modo,
EV = (400 metros) × ($200) = $80 000
En otras palabras, al decimoctavo día se ha realizado un trabajo por valor de $80,000. Ahora,
dado que se suponía que se había realizado un trabajo por un valor de $ 90,000 , el proyecto
tiene un retraso de $ 10,000 en el trabajo programado.
Tenga en cuenta que los $ 10,000 no representan un ahorro de costos sino el valor del trabajo
que debería haberse hecho pero no se hizo. Representa 50 parquímetros, o 2 días de trabajo,
lo que significa que al decimoctavo día el proyecto tiene 2 días de atraso. (Los 2 días se
conocen como variación de tiempo o TV). Por lo tanto, EV es una traducción del costo del
proyecto en progreso del trabajo.
A partir del día 18, el proyecto solo ha avanzado 16 días de trabajo.

Esto se representa en el gráfico de PV y EV en la figura 11.8.
Figura 11.8 Gráfico de PV y EV.
Además de las tareas completadas, el EV también debe reflejar las tareas iniciadas pero
solo parcialmente completadas (tareas abiertas). Por ejemplo, suponga que antes de
dejar de fumar al final del decimoctavo día, el instalador del medidor tuvo el tiempo
suficiente para quitar un medidor viejo pero no para instalar uno nuevo: el trabajo en esa tarea fue
50 por ciento completado. Si este fuera el medidor no. 401, entonces EV para el
decimoctavo día sería el costo de los primeros 400 metros más el 50 por ciento del costo
del 401:
VE = $80 000 + (0,50) ($200) = $80 100

Por lo tanto, el EV en el día 18 es de $80 100, lo que representa un poco más de 16 días [$80
100/(25 × $200) = 16,02 días] de trabajo completado.
Las variables PV, AC y EV también se pueden usar para calcular las variaciones que revelan
diferentes aspectos del estado de un proyecto. Por ejemplo, suponga que para el proyecto LOGON
en la semana 20,
VP = $512,000
CA = $ 530,000
VE = $429,000
Usando estas cifras, se pueden determinar tres tipos de varianzas, que se muestran en la Figura
11.9.
1. Variación de horario: SV = EV ÿ PV = ÿ $83,000.

2. Variación de tiempo: TV = SD ÿ BCSP [donde SD es la “fecha de estado” (aquí Semana
20); para BCSP (costo presupuestado, rendimiento programado), consulte la Figura 11.8
en EV para la semana 20, luego vea la semana en la que PV es igual a este EV
(aproximadamente la semana 19)]; por lo tanto, TV = (20 ÿ 19) = 1 semana.
3. Variación de costos: CV = EV ÿ AC = ÿ $101,000.
SV negativo indica que el proyecto está retrasado; SV positivo sugiere que está adelantado. Un SV
para la semana 20 de –$83 000 significa que el proyecto está retrasado. La televisión muestra
aproximadamente cuánto retraso, en este caso alrededor de 1 semana porque se completó un
trabajo (EV) por un valor de $ 429,000, que es aproximadamente el valor del trabajo (PV) que se
suponía que se completaría aproximadamente una semana antes.
CV negativo indica que el proyecto está gastando en exceso para el trabajo completado; CV
positivo indica que está gastando menos. CV de –$101,000 indica que LOGON está gastando de
más.
Análisis de paquetes de trabajo e índices de desempeño
Evaluar el estado del proyecto requiere conocer el desempeño de todos los paquetes de trabajo.
Con información del PCAS, se puede preparar una figura como la Figura 11.9 para
cada paquete de trabajo y cuenta de control.

Vuelva a consultar la Figura 11.4, el estado del proyecto LOGON en la semana 20. Muestra que
las actividades H, I y J se han completado y están cerradas, y las actividades K a Q están "abiertas"
y en curso. Si bien esto brinda una descripción general del paquete de trabajo y el estado del
proyecto, para determinar los orígenes del tamaño de los retrasos o sobrecostos, cada paquete de
trabajo debe evaluarse en detalle; esto se hace calculando dos índices de rendimiento para cada
actividad:
1. Índice de desempeño del cronograma: SPI = EV/

PV 2. Índice de desempeño de costos: CPI = EV/AC
Los valores de SPI y CPI superiores a 1,0 indican que el trabajo está adelantado y por debajo del
presupuesto, respectivamente; valores inferiores a 1,0 indican lo contrario.
La tabla 11.2 muestra información de rendimiento para todas las actividades de LOGON a partir
de la semana 20. Los índices CPI y SPI muestran puntos problemáticos y su magnitud relativa: L,
M y Q son los que más se han quedado atrás
Figura 11.9 Estado del proyecto LOGON a partir de la semana 20.
Tabla 11.2 Informe de rendimiento de LOGON Semana 20 acumulado hasta la fecha

calendario (tienen los SPI más pequeños), y L y M tienen los mayores sobrecostos en
relación con sus tamaños (tienen los CPI más pequeños). El proyecto general está "algo"
retrasado y sobrecosto (SPI = 0,83; CPI = 0,81).
Centrarse solo en el nivel del proyecto o solo en el nivel del paquete de trabajo para
evaluar el estado del proyecto puede ser engañoso, y el gerente del proyecto debe
examinar ambos niveles, de un lado a otro. Si se fija sólo en el nivel del proyecto, el buen
desempeño de algunas actividades puede ocultar el desempeño deficiente de otras. Si se
enfoca solo en paquetes de trabajo individuales, fácilmente puede pasar por alto el efecto
acumulativo de un desempeño levemente bajo en muchas actividades: pequeños
sobrecostos en muchos paquetes de trabajo individuales pueden sumar un gran sobrecosto
para el proyecto. Por ejemplo, SV en la figura 11.9 (-$83 000) sugiere que todo el proyecto
está atrasado (TV = -1 día), sin embargo, el examen de la figura 11.4 revela que solo uno
de los paquetes de trabajo atrasados, la actividad M, está en el punto crítico. (ver Capítulo
6, Figura 6.8). Dado que la actividad M parece tener un retraso de aproximadamente 3
semanas, el proyecto también debe tener un retraso de 3 semanas, no de 1 semana como
lo estima el TV a nivel de proyecto.
Ver Capítulo 6
La importancia de monitorear el desempeño a nivel del paquete de trabajo se ilustra

aún más con un ejemplo del proyecto ROSEBUD. La figura 11.10 es el informe de costos
del paquete de trabajo L para el mes 2. (Los números en las columnas PV son
derivado de la columna Mes 2 en el plan presupuestario en la Figura 8.8, Capítulo 8.)

El período actual y los números acumulativos son los mismos porque el paquete de trabajo L
comienza en el mes 2.
Ver Capítulo 8
Los índices de desempeño para el paquete de trabajo L de ROSEBUD son;
SPI = EV/PV = 0,80

CPI = EV/AC = 0,74
indicando tanto el cronograma como los sobrecostos a partir del Mes 2. Suponga que el gerente del
proyecto investiga los costos del Paquete de trabajo L y descubre lo siguiente:
Figura 11.10 Gráfico de costos del proyecto ROSEBUD al mes 2.
Primero, aunque AC = PV para la mano de obra directa, PV refleja la estimación de que solo se
realizó el 80 por ciento del trabajo programado para el período (EV = PV × SPI = 6050 × 0,80 = 4850).
En segundo lugar, aunque AC = PV para la mano de obra directa, el AC y el PV para los gastos
generales de mano de obra son diferentes debido a un aumento de la tasa del 75 al 90 por ciento durante
Mes 2. Mientras que PV reflejaría la tasa anterior (0,75 × 6050 = 4538), AC reflejaría la nueva
(0,9 × 6050 = 5445). El punto: el hecho de que CA total > PV total en este caso no tiene
relación con el rendimiento real del paquete de trabajo, sino que se debe a un cambio en la
tasa de gastos generales, algo sobre lo que el director del proyecto no tiene control.
Figura 11.11 Gráfico de costos del proyecto ROSEBUD al mes 3.
Ahora mire la Figura 11.11, el informe de costos para el mismo paquete de trabajo pero
para el Mes 3. Los índices de desempeño para las cifras acumulativas son:
SPI = EV/PV = 1,00

CPI = EV/AC = 0,92
Observe primero que la mano de obra directa AC = PV del mes, pero se realizó más trabajo
del planificado para el mes (EV > PV), lo que compensó el déficit de trabajo en el Mes 2 y dio
como resultado que la tarea se completara a tiempo (indicado por SPI = 1,00). El paquete de
trabajo tiene CV negativo, causado por el aumento en la tasa de gastos generales de mano de
obra del 75 al 90 por ciento. ¿El punto? De los numerosos factores que afectan el progreso y
los costos del trabajo del proyecto, algunos están fuera del control del gerente del proyecto.
Determinar las fuentes de las variaciones y los lugares donde el gerente del proyecto puede o
debe actuar requiere un escrutinio de los costos y
rendimiento a nivel de paquete de trabajo. El análisis a nivel de proyecto es simplemente

inadecuado.
Supervisión de índices de rendimiento y variaciones
Con el uso de CPI y SPI a nivel de proyecto, las partes interesadas del proyecto pueden
obtener una estimación rápida del rendimiento del proyecto hasta la fecha. Aunque la
estimación puede ser un tanto inexacta, permite al gerente rastrear tendencias generales
en el desempeño del proyecto. La gráfica de SPI contra CPI en la figura 11.12 es un ejemplo:
LOGON comenzó en las regiones marginales y pobres, se recuperó brevemente y luego se
desplazó de manera inquietante hacia la región pobre y permaneció en ella. El gerente del
proyecto debe hablar con los líderes de equipo y los gerentes funcionales para identificar
las causas detalladas de los problemas.
Rara vez coinciden las medidas de rendimiento real y planificado; como resultado, las
variaciones distintas de cero son más la regla que la excepción. Esto lleva a la pregunta:
¿Qué cantidad de variación es necesaria para exigir la adopción de medidas?
Figura 11.12 Costo/desempeño del cronograma del proyecto LOGON trazado para los meses 1 a 20.
Tabla 11.3 Ejemplo de límites de varianza
Paquete de trabajo A Variaciones mayores a $2,000
Paquete de trabajo B Variaciones mayores a $18,000
Departamento C Variaciones mayores a $6,000
Departamento D Variaciones mayores a $38,000

Proyecto Variaciones mayores a $55,000
La tabla 11.3 muestra los límites de variación "aceptables" para diferentes niveles de proyecto: trabajo
paquete, departamento y proyecto. Sólo cuando una varianza excede un límite son
medidas correctivas consideradas. A veces se permite que los límites varíen. En
proyectos de investigación (Pathfinder, por ejemplo), comienzan algo grandes pero se reducen a
medida que avanza el proyecto. Esto coincide con el riesgo del proyecto, que comienza grande
pero disminuye a medida que avanza el proyecto.
Los límites de variación superior e inferior establecidos en costos y cronogramas ayudan a
identificar lugares donde la calidad del trabajo está en duda. Un proyecto que se ejecuta antes de
lo previsto y por debajo del presupuesto, una situación aparentemente deseable, podría de hecho
estar plagado de recortes y mano de obra de mala calidad. Para el desempeño técnico, se
establecen límites de variación superior e inferior en los requisitos técnicos. Los límites más bajos
son necesarios para asegurar que se cumplan los requisitos; Los límites superiores son necesarios
para evitar un trabajo de desarrollo excesivo o innecesario.
Actualización de estimaciones de tiempo
Después de cada revisión de progreso, podría ser necesario actualizar las fechas de finalización
programadas de las tareas o paquetes de trabajo. En general,
Fecha de finalización prevista para una tarea = Fecha de inicio + Tiempo restante
donde el tiempo restante se determina de dos maneras. La primera es considerarlo en función de

los días trabajados hasta el momento y el progreso actual, es decir:
dónde
La otra forma es simplemente aceptar la opinión de una fuente de confianza ("llevará otros 5 días
para terminar el trabajo"). Esta forma a menudo produce una estimación más precisa que la otra
porque tiene en cuenta cualquier cambio reciente en la tasa de trabajo.
Progreso.
Ejemplo 11.7: Revisión de la fecha de finalización de la tarea
Una tarea comienza el 10 de julio y está planificada para durar 12 días (incluidos los fines de semana).
Después de 5 días hábiles (finales del 14 de julio), el líder estima que la tarea está completa en un 20
por ciento. Si la tasa de progreso sigue siendo la misma, ¿cuál es la fecha prevista de finalización de
la tarea?
Cinco días de trabajo representan un 20 por ciento estimado completo, por lo que el progreso del
trabajo es 20 por ciento/5 = 4 por ciento por día. Así, para completar el 80 por ciento restante debería
tomar 0,80/0,04 = 20 días hábiles. La fecha de finalización revisada es el 15 + 20 de julio = 4 de agosto.
Ahora, supongamos que el líder del equipo cree que la parte restante de la tarea avanzará mucho
más rápido que el 4 por ciento por día y que, como máximo, se requerirán 10 días laborales más. Si la
estimación del líder del equipo se considera creíble, la fecha de finalización revisada sería el 25 de
julio.
Estimación al finalizar
Periódicamente, el gerente del proyecto prepara un pronóstico de finalización , que es una estimación del
tiempo y el costo necesarios para completar el proyecto. Este pronóstico más el estado actual del proyecto
proporcionan un pronóstico de la fecha y el costo del proyecto al finalizar. Las estimaciones del costo restante
para completar el proyecto (el costo de finalización ) y el costo final del proyecto (el costo de finalización ) se
calculan de la siguiente manera:
ETC (costo estimado para completar el proyecto) = (BAC ÿ EV)/CPI
donde BAC es el costo presupuestado al finalizar el proyecto (= PV total al finalizar el objetivo).
EAC (costo estimado al finalizar) = AC + ETC
Los siguientes dos ejemplos ilustran.

Ejemplo 11.8: Pronóstico de ETC y EAC para

el Proyecto ROSEBUD
La figura 11.13 muestra el diagrama de Gantt del proyecto ROSEBUD con el porcentaje
completado y las métricas de EVM para la semana 13. Dada esta información, ¿cuánto costará
completar el proyecto y cuánto costará al finalizar?
El valor de la obra terminada hasta el momento (EV) es de $268.081. El monto total
presupuestado para el proyecto (BAC) es de $344 205, por lo que el valor del trabajo restante es
BAC ÿ EV = $76 124.
El desempeño de costos para el proyecto hasta ahora es:
IPC = EV/AC = 268.081/288.657 = 0,9287
Esto significa que el proyecto está recibiendo menos de 93 centavos de valor por cada dólar
gastado. A esa tasa, el costo estimado para completar es:
ETC = 76,124/0.9287 = $81, 968.
Dado que ya se han gastado $288,657, el proyecto estimó al finalizar

el costo es:
EAC = AC + ETC = 288 657 + 81 968 = $370 625.
Este es un sobrecosto de $370 625 ÿ $344 205 = $26 420, o 7.7 por ciento.
Observe que de acuerdo con EV, el proyecto está levemente adelantado (EV = 268,081) > (PV
= 252,101), aunque lo más probable es que esté atrasado porque la Actividad V está en la ruta
crítica y parece tener aproximadamente 1 semana de atraso según el Gráfico de gantt.
Figura 11.13 Estado del proyecto ROSEBUD en la semana 13.
Ejemplo 11.9: Previsión de ETC y EAC para

el proyecto LOGON
De la discusión anterior en el capítulo, para el proyecto LOGON en la Semana 20,
CPI = 429 000/530 000 = 0,81, por lo

tanto, ETC = (990 000 ÿ 429 000)/0,81 = $692 593, y
EAC = 530 000 + 692 593 = $1 222 593.
A falta de otra información, la fecha de finalización del proyecto revisada se estima

como se muestra en la Figura 11.14 al extender la línea EV, manteniéndola paralela
a la línea PV, hasta que alcance el nivel de BCAC, $990 000. La distancia horizontal
entre la línea PV y la línea EV en BCAC es aproximadamente el horario
exceso de tiempo (variación de tiempo negativa) para el proyecto; en la figura 11.14 , esto es
aproximadamente 3 semanas, por lo que la finalización estimada del proyecto es la semana 50
en lugar de la semana 47.
Esta fecha de finalización revisada aún debe verificarse, ya que un retraso real dependerá
de si las actividades atrasadas se encuentran en la ruta crítica.
De una discusión anterior, sabemos que la Actividad M está en la ruta crítica y tiene 3 semanas
de retraso, por lo que es probable que el proyecto LOGON también tenga 3 semanas de retraso.
Figura 11.14 Gráfico de estado del proyecto LOGON y previsión a partir de la semana 20.
En la figura 11.14 se muestra otra línea, "Forecast AC", que es una extensión de la línea AC
actual hasta el nivel EAC ($1,159,630) y en el
fecha de finalización revisada de la semana 50. Esto proporciona una estimación actual de los
costos "reales" que podrían ser hasta la finalización del proyecto.
Cabe señalar que las estimaciones al finalizar asumen que las condiciones y los recursos no
mejorarán ni empeorarán, lo que el gerente del proyecto LOGON debería cuestionar. Dado el
tamaño del sobrecosto actual ($101 000 a partir de la semana 20) y que el proyecto está a menos
de la mitad, ¿cuál es la probabilidad de terminar todo el trabajo restante por $692 593 sin
sobrecostos adicionales ? (Si parece poco probable, la cifra debe revisarse nuevamente de
acuerdo con las mejores estimaciones). Además, ¿cuál es la probabilidad de que el proyecto
finalice en la estimación revisada de la Semana 50? A partir de la semana 20, el EV es equivalente
al PV de la semana 19, lo que significa que, en términos de costo presupuestado, el trabajo
restante en el proyecto es
47 semanas (fecha prevista) ÿ 19 semanas = 28 semanas.
Sin embargo, dado el SPI actual = 0,84, parece más probable que al proyecto le queden 28/0,84
= 33,3 semanas. El proyecto se encuentra ahora en la semana 20, por lo que la fecha de
finalización revisada es 20 + 33,3 = semana 53,3.
Efecto de la incertidumbre
El EAC se basa en una evaluación de valor único de EV a partir de la SD. Esta evaluación generalmente
se basa en opiniones sobre el porcentaje completo, lo que significa que está sujeta a incertidumbre.
Dado que EV está sujeto a incertidumbre, también lo está EAC. Una forma de explicar esta incertidumbre
es considerar valores optimistas, pesimistas y más probables de EAC, como se ilustra a continuación.
9
Ejemplo 11.10: Incertidumbre en el EAC previsto y

la fecha de finalización
El EV para el proyecto LOGON a partir de la semana 20 es de $429 000. Con el proyecto

presupuestado en $990,000, esto significa que el proyecto está completado en un 43.3 por ciento.
Suponga que un experto mira el proyecto y concluye que está en algún lugar
entre el 35 por ciento y el 48 por ciento completado. Estos representan pesimismo
y escenarios optimistas, respectivamente. Los EV correspondientes son:
Pesimista 0,35 ($990 000) = $346,500
Más probable (dado) 0,48 $429,000
Optimista ($990 000) = $475,200
Dado que AC = $530 000 y PV = $512 000, el rango de posibles CPI, SPI y
Las EAC y las fechas de finalización previstas son:
La figura 11.15 muestra tres puntos que representan los costos previstos (EAC) y
tiempos de finalización y distribuciones de probabilidad para EAC y finalización
tiempo.
Figura 11.15 Costo estimado al finalizar (EAC) y tiempos de finalización.
Estos tiempos de finalización estimados no reflejan qué actividades retrasadas

actualmente, si las hay, se encuentran en la ruta crítica; reflejan solo la velocidad a la
que se realizó el trabajo completado y suponen que esa velocidad es uniforme en todas
partes del proyecto, tanto en las actividades críticas como en las no críticas.
Las estimaciones optimista, más probable y pesimista para el costo y el tiempo de
finalización se pueden pronosticar periódicamente a lo largo del proyecto repitiendo el
procedimiento de pronóstico anterior, digamos, en las semanas 30, 40 y 50. La figura
11.16 muestra gráficos de los tres pronósticos EAC en estos intervalos a partir de la semana 20.
La convergencia de los pronósticos pesimistas y optimistas en la figura sugiere que el
proyecto se dirige hacia un EAC muy probable de $1,150,000.
Figura 11.16 Cadena crítica = 24 semanas, amortiguador del proyecto = 12 semanas.
Deficiencias de EVM
Las métricas de valor ganado pueden ser inexactas y engañosas, por lo que deben tratarse con
precaución. Por ejemplo, puede surgir un CV negativo (sobrecosto) debido a cargos generales que
se originan fuera del proyecto y no tienen relación con el desempeño del proyecto. De manera similar,
el CV positivo (insuficiencia) puede ocurrir simplemente porque las facturas aún no se han pagado.
Siempre que los pagos se realicen en períodos distintos a los de los gastos incurridos o
presupuestados, el CV está sesgado. Esto lleva a algunas empresas a aplicar métodos EV a algunos
factores de costos (p. ej., costos laborales para sus propios empleados) y no a otros (p. ej., artículos
adquiridos que requieren pago por adelantado). Al final, las fuentes de costos siempre deben
examinarse para identificar las razones de las variaciones.
El método EV se basa en estimaciones del porcentaje completado. Es posible realizar estimaciones

precisas del porcentaje completo siempre que el trabajo se pueda medir en unidades uniformes (por
ejemplo, número de ladrillos colocados, millas de asfalto colocado, número de accesorios instalados,
etc.), pero son difíciles o imposibles cuando el resultado del trabajo (por ejemplo, dibujos producidos o líneas de código
escritas) no se puede medir en unidades uniformes (no todos los dibujos o líneas de código requieren la misma cantidad
de tiempo para producir).
EVM y la gestión de proyectos de cadena crítica se pueden usar en combinación, siempre que el propósito de cada
uno esté claramente diferenciado. EVM es un método de informes y seguimiento de costes; no distingue actividades
“críticas” en el cronograma.
CCPM es una herramienta de programación; no aborda los costos. En ocasiones, los dos métodos dan señales
contradictorias sobre el rendimiento del proyecto (SPI o TV en usos de EVM frente a consumo de búfer en CCPM). Una
regla general es usar EVM para el seguimiento y la generación de informes de costos (quizás según lo requiera un
cliente), pero basar las decisiones de asignación de recursos y programación en el consumo de búfer y CCPM.
10
Medición del rendimiento técnico
Además de los costos y los cronogramas, el desempeño depende de qué tan bien el proyecto cumpla con los requisitos
técnicos. La medición del rendimiento técnico (TPM) es un método para realizar un seguimiento del historial de objetivos
o requisitos técnicos a lo largo del tiempo.
El propósito de TPM es proporcionar (1) la mejor estimación del rendimiento técnico actual y el progreso hasta la fecha,
y (2) una estimación del rendimiento técnico al finalizar el proyecto. Ambas estimaciones se basan en los resultados de
modelos, simulaciones, pruebas o demostraciones.

11
Para realizar el TPM, primero es necesario especificar las medidas de rendimiento técnico que son indicadores clave
para el sistema de artículo final. Estas medidas deben estar vinculadas a los requisitos del cliente y representar los
principales impulsores del rendimiento. Un sistema a gran escala puede tener una docena de medidas de alto nivel, en
cuyo caso es necesario definir los parámetros de diseño de los que depende cada medida y establecer los valores
necesarios para estos parámetros. Ejemplos de medidas de desempeño incluyen:
Disponibilidad Capacidad Tamaño/Espacio
Utilidad de copia de seguridad Tiempo de respuesta Fiabilidad
La seguridad Seguridad Potencia/empuje

Velocidad tiempo de configuración Compatibilidad de interfaz

Supervivencia Durabilidad interoperabilidad
mantenibilidad Rango Simplicidad/complejidad
Flexibilidad Diferencia Relación señal-ruido
Tiempo del ciclo Costo Hora de viajar
Eficiencia Utilización Tiempo de inactividad
Tasa de producción Tasa de errores/defectos Peso
Periódicamente durante el proyecto, el rendimiento se calcula o mide y

en comparación con los objetivos. Las medidas iniciales se basan en estimaciones de cálculo,
modelado y simulaciones; medidas posteriores se derivan de la prueba y
resultados de demostración en hardware y software reales. Estimaciones y reales
Las medidas del objetivo técnico se trazan en un gráfico TPM que muestra
progreso hacia el logro del objetivo. Si el rendimiento real de una parte del
sistema excede la meta u objetivo por algún margen, entonces a veces eso
El margen puede compensarse con objetivos para otras partes del sistema donde
falta rendimiento o está en riesgo. Esto se ilustra a continuación.
Ejemplo 11.11: TPM para decisiones de compensación de diseño
Con base en el Ejemplo 10.5 del Capítulo 10, diseñe los pesos objetivo para los componentes
del sistema de navegación de una nave espacial se fijaron en 44 libras para el Subsistema A
y 26.4 libras para el Subsistema B. También se establecieron márgenes de diseño para
los dos subsistemas para cubrir el riesgo de no cumplir con estos objetivos; la
los márgenes representan montos por los cuales los valores objetivo podrían ser excedidos
y aun así lograr los requisitos del sistema.
Ver Capítulo 10
El gráfico TPM en la Figura 11.17 muestra el progreso del diseño (real versus
valores objetivo) para los dos subsistemas; gráficos como este y se utilizan para hacer
decisiones de compensación de diseño. Este gráfico muestra el rendimiento y el diseño actuales
objetivos en tres hitos del proyecto:
1. En el momento de la demostración preliminar del modelo, los pesos reales

medidos para ambos subsistemas eran demasiado altos, aunque el
Subsistema A estaba relativamente mucho más cerca de su objetivo de
diseño que el Subsistema B.
2. En el momento de la revisión precrítica, el subsistema A se había mejorado
y estaba cerca de su peso objetivo; sin embargo, el Subsistema B todavía
estaba lejos de su objetivo. Estaba claro que el subsistema A podría
cumplir su objetivo de 44 libras, pero el subsistema B no podría cumplir su
objetivo de 26,4 libras. Se tomó la decisión de reducir el margen de diseño
no utilizado del subsistema A en 3,6 libras y aumentar el objetivo de diseño
del subsistema B en esa cantidad a 30 libras.
Figura 11.17 Gráficos TPM con fases temporales para los subsistemas A y B.
3. A partir de la revisión crítica del diseño, el subsistema A había cumplido

su objetivo, pero el subsistema B aún estaba rezagado; además, se
anticipó que solo era posible una mejora adicional limitada en B. Se
tomó la decisión de transferir 6 libras más del margen de diseño no
utilizado del Subsistema A al objetivo del Subsistema B, aumentándolo
a 36 libras. La línea punteada para el Subsistema B más allá de la
revisión crítica del diseño es la mejora aún necesaria para lograr el
valor objetivo revisado del Subsistema B.
11.8 Gestión de problemas
Un problema es un problema emergente, una pregunta o un asunto en disputa. Puede provenir de

cualquier parte, pero es algo que hay que resolver. Los problemas que se originan a partir de riesgos
identificados anteriormente se pueden resolver con las respuestas de mitigación o contingencia en el plan
de riesgos. Sin embargo, la mayoría de los problemas no se habrán anticipado y deberán abordarse a
medida que surjan. No se pueden abordar todos los detalles en el plan del proyecto, y no se pueden
anticipar todas las circunstancias. Surgirán problemas de certeza y serán necesarias acciones de
seguimiento.
Los problemas, riesgos y cambios están relacionados: un riesgo materializado (un riesgo que ha
surgido o que seguramente surgirá) o una solicitud de cambio puede dar lugar a un problema; o bien, un
problema puede resultar en una solicitud de cambio o un nuevo riesgo. Cada uno implica un "elemento de
acción", es decir, una respuesta, ya sea una solicitud de cambio, un plan de resolución de problemas o
una estrategia de mitigación de riesgos. Un proyecto encontrará numerosos problemas, y para cada uno
de ellos, el director del proyecto debe evaluar su impacto en el cronograma, el presupuesto, otras tareas,
recursos y la calidad del producto final.
Al igual que los riesgos y los cambios, los problemas deben gestionarse. Cada problema debe
documentarse, priorizarse, rastrearse, resolverse y cerrarse. Similar al control de cambios (que se analiza
a continuación), la gestión de problemas implica los pasos de identificación, documentación, análisis/
evaluación, comunicación, acción, seguimiento y cierre. Estos pasos se pueden describir en relación con
el registro de problemas en la Figura 11.18, que es un registro de todos los problemas encontrados. El
registro se conserva durante todo el proyecto y se actualiza cada vez que surge un nuevo problema o
cambia de estado.
En la Figura 11.18, asociado con cada problema hay una ID (identificador alfanumérico simple),
nombre/ descripción del problema, fecha de emisión y autor. El tipo de problema clasifica el problema
según su función, origen, acción o impacto. Por ejemplo, algunas empresas especifican el tipo de problema
como "técnico", "organizativo", "parte interesada" o "adquisición"; otros usan "Riesgo", "Solicitud de
cambio" o "Emergente (problema)". El impacto, si se conoce, es la consecuencia posible o cierta del
problema si no se resuelve adecuadamente.
Cada problema es evaluado por su importancia para el proyecto y/o el elemento final por el director del
proyecto, el equipo del proyecto u otros. El resultado de la evaluación es un
prioridad asignada (p. ej., 1 a 5); esto puede basarse en la gravedad (1 a 5) del problema y otros problemas
pendientes según lo determine su impacto. El resultado del análisis es una acción recomendada o especificada
para resolver el problema con una fecha de vencimiento y una persona asignada.
El estado de todos los problemas se supervisa con frecuencia. Las reuniones de estado semanales
comienzan con una revisión del registro de problemas y una actualización del estado actual de cada problema;
esto puede indicarse con una sola letra que represente, por ejemplo: No iniciado, Análisis, X: cancelado, acción
en progreso, Completado/resuelto o Escalado. La persona asignada es responsable de informar y acreditar el
estado. La fecha resuelta se registra para las emisiones cerradas. Los problemas obstinados se “escalan”, es
decir, se remiten a una autoridad superior (administración superior, patrocinador o cliente), quienquiera que
tenga la autoridad, los recursos o la capacidad para resolver el problema.
Para proyectos medianos y grandes, la gestión de problemas sigue un proceso más o menos análogo a la
gestión de riesgos (sustituya "asunto" por "riesgo" en la Figura 10.1) y el control de cambios (sustituya
"problema" por "cambio" en la Figura 11.20).
Figura 11.18 Problemas og.
Una forma de medir el progreso del proyecto es monitorear el estado de los problemas. Todos los proyectos
encuentran problemas, pero los "sanos" los resuelven convenientemente; cuando los problemas
permanecen sin resolver, la acumulación de problemas crece y se vuelve cada vez más difícil
de manejar. La figura 11.19 muestra la cantidad de problemas no resueltos (no C o X) en un
momento particular del proyecto y cuánto tiempo han estado en el registro. El declive superficial
en la curva superior representa un proyecto problemático: numerosos problemas no se han
resuelto y la mayoría tiene varias semanas de antigüedad. La curva inferior representa un
proyecto saludable donde los problemas se resuelven con bastante rapidez.
Figura 11.19 Número de problemas no resueltos (pendientes) frente a la antigüedad de los problemas.
11.9 Control de cambios
Ningún proyecto va completamente de acuerdo al plan. Los cambios en el sistema de artículos

finales y el plan del proyecto son inevitables debido a descuidos en la planificación, nuevas
oportunidades o eventos y problemas imprevistos. Dichos cambios requieren modificar el trabajo,
reorganizar o agregar personal y equilibrar tiempo, costo y desempeño. Las modificaciones a las
especificaciones y los sacrificios al desempeño técnico a veces son necesarios para cumplir con las
limitaciones de tiempo y costo.
El impacto de los cambios
En general, cuanto más grande y complejo sea el proyecto, mayor será el número de cambios y más
se desviarán los costos y los cronogramas reales de los objetivos.
Los cambios son una de las causas principales de los sobrecostos y de los plazos, y de las malas
relaciones entre los contratistas y los clientes. Cada cambio tiene un efecto dominó: en respuesta a
un problema emergente, se deben cambiar elementos del producto final y del plan del proyecto, pero
en forma de reacción en cadena, se requieren cambios en otros elementos del producto final y del
proyecto, y estos impactar aún a otros.
En general, cuanto más avanza el proyecto, más perjudicial es el efecto de los cambios. Los
cambios de diseño realizados en un componente durante el ensamblaje y las pruebas del sistema a
menudo conducen a la reelaboración o el rediseño de otros componentes. Los cambios realizados
aún más tarde en la construcción y la instalación causan aún más problemas: el trabajo debe
interrumpirse, derribarse o rehacerse y los materiales deben desecharse. La moral también se ve

afectada: la gente ve su trabajo desmantelado, descartado y rehecho; todos están bajo presión para
que el proyecto vuelva a estar dentro del presupuesto y el cronograma.
Razones para los cambios
12
Un proyecto típico experimenta los siguientes tipos de cambios:
1. Cambios en el alcance y las especificaciones del proyecto. Como regla general, cuanto más
incierto el proyecto, es más probable que el alcance y las especificaciones tengan

que modificarse más adelante en el proyecto.
2. Cambios en el diseño debido a errores, omisiones, incógnitas, ideas tardías o
necesidades revisadas. Los errores u omisiones necesariamente deben corregirse o
acomodarse, pero los clientes a menudo intentan introducir cambios innecesarios que
están más allá del alcance original (pero, esperan, por el precio original).
3. Cambios exigidos por códigos gubernamentales (salud, seguridad, trabajo, medio

ambiente), contratos laborales, proveedores, la comunidad u otros actores del medio
ambiente.
4. Cambios que se cree mejorarán la tasa de rendimiento del proyecto.
5. Cambios percibidos para mejorar los requisitos originales. Muchas personas quieren
mejorar su trabajo; aunque aparentemente deseables, estas mejoras pueden expandir
el proyecto más allá de su alcance y requisitos originales.
Los ejemplos de los cambios anteriores incluyen: (1) Después de que se haya completado el
diseño, aumentar el requisito de carga útil en una sonda espacial para permitir el hardware
adicional necesario; (2) encontrar un cable enterrado durante la excavación, que debe ser
redirigido; (3) interrumpir el trabajo por problemas laborales o violaciones al código municipal;
(4) alterar la capacidad de diseño de una refinería en construcción para aumentar la tasa de
producción de la refinería; (5) agregar más funciones a un diseño de software ya aceptable
(bloatware) para mejorar la comerciabilidad percibida.
Tenga en cuenta que algunos cambios 1, 4 y 5 son discrecionales, es decir, pueden rechazarse,
mientras que 2 y 3 son de facto, es decir, ya "ocurrieron" y deben aceptarse.
Sistema de Control de Cambios y Gestión de la Configuración
Una forma de gestionar los cambios y reducir sus impactos negativos es emplear un sistema
de control de cambios formal. Debido a que hacer cambios es similar a otros aspectos del
trabajo del proyecto, es decir, deben definirse, programarse y presupuestarse, el proceso de
redacción e implementación de cambios es similar al proceso de planificación del proyecto.
El propósito del sistema de control de cambios es revisar el diseño propuesto y los cambios de
trabajo, descartar todos menos los necesarios y asegurarse de que todo el trabajo relacionado
también es revisado, revisado y autorizado. Según Harrison, el sistema debería: 13
1. Identificar continuamente los cambios a medida que ocurren.
2. Revelar el impacto de los cambios en los costos del proyecto, la duración del proyecto y otros
Tareas.
3. Aceptar o rechazar los cambios propuestos en base al análisis de impactos.
4. Comunicar los cambios a todas las partes involucradas.
5. Especificar una política para minimizar conflictos y resolver disputas.
6. Asegúrese de que se implementen los cambios.
7. Informar mensualmente un resumen de todos los cambios a la fecha y su impacto en la
proyecto.
El sistema de control de cambios se establece al principio del proyecto y luego se utiliza para evaluar el impacto
de los cambios propuestos en las estimaciones y planes, y rastrear cualquier variación en el desempeño actual y
las estimaciones originales a cambios específicos aprobados.
Ver Capítulo 9
El sistema de control de cambios se enfoca en el proyecto, pero es parte de un proceso más amplio para
controlar e integrar cambios en el diseño, desarrollo, construcción y operación del sistema de producto final, sus
subsistemas y componentes: el proceso de administración de configuración mencionado en Capítulo 9. Cuando
se aprueba por primera vez un elemento del diseño (p. ej., un criterio de desempeño) o del plan del proyecto (p.
ej., declaración del alcance, cronograma o presupuesto), se lo denomina línea base; cada vez que la línea de
base se modifica posteriormente para reflejar los cambios aprobados, se denomina segunda línea de base, tercera
línea de base, etc.
Para controlar y minimizar los cambios de diseño y trabajo, el sistema de control de cambios
14
incluye los siguientes procedimientos:
• Requerir que los SOW originales, las órdenes de trabajo, los cronogramas y los presupuestos sean
inequívoca y acordada por las personas responsables. • Supervisión
estrecha del trabajo para garantizar que cumpla (no exceda) las especificaciones.
• Examinar cuidadosamente el trabajo en busca de cambios en el alcance, el costo o el cronograma del trabajo
excesos y tomar medidas correctivas rápidas.

• Requerir un proceso formal de solicitud y aprobación de todos los discrecionales
cambios.
• Exigir procedimientos de control similares a todos los contratistas y proveedores para todos
órdenes de compra, solicitudes de prueba, etc.
• Evaluar el impacto de todos los cambios en el producto final y el proyecto y revisar los
diseños y planes para reflejar el impacto. • Congelar el proyecto contra todos los cambios
de diseño no esenciales en una etapa predefinida; esto prohíbe cambios de diseño
adicionales para que pueda comenzar la siguiente etapa (fabricación, construcción o
codificación y prueba). La fecha de congelación se establece al principio del proyecto y
se le recuerda constantemente al personal del proyecto.
El proceso, resumido en la Figura 11.20, garantiza que todos los cambios discrecionales y de facto
en el diseño y las tareas de trabajo se documenten en cuanto a su efecto en el proyecto y el
elemento final, se evalúen formalmente y se acepten o rechacen.
Figura 11.20 Proceso de control de cambios.
Una parte clave del proceso es el documento de solicitud de cambio (Figura 11.21), que
proporciona información y la justificación de un cambio propuesto. Cualquier miembro del
equipo del proyecto u otra parte interesada puede solicitar un cambio enviando una solicitud
de cambio. Todos, independientemente de su función, título o puesto, deben seguir el mismo
procedimiento de solicitud.
Figura 11.21 Ejemplo de documento de solicitud de cambio.
En proyectos grandes, una junta de control de cambios se reúne semanalmente para revisar
las solicitudes de cambio, evaluar sus impactos y decidir qué cambios rechazar y cuáles
aprobar. La junta está compuesta por el gerente de proyecto, los gerentes funcionales, el
administrador de contratos y los representantes de clientes.
Cualquier cambio propuesto o promulgado que afecte el tiempo, el costo o la naturaleza del
trabajo de una sola tarea y tareas relacionadas debe documentarse. Todos los involucrados en
el proyecto tienen el potencial de reconocer u originar cambios, y se debe esperar que todos
los llamen la atención del gerente del proyecto.
11.10 Administración de contratos
La administración del contrato es responsable de asegurar que todos los compromisos del
15
desarrollador/contratista y el cliente como se especifica en el contrato.
La gestión de adquisiciones, discutida en el Capítulo 5, es un aspecto de la administración de
contratos que se ocupa específicamente de la gestión de las relaciones con los proveedores y
subcontratistas que proporcionan bienes, trabajos y servicios contratados.
Ver Capítulo 5
La administración de contratos es un aspecto del control de proyectos que atañe

exclusivamente al trabajo contratado; incluye autorizar el inicio de obras; monitorear el trabajo
con respecto a los presupuestos, cronogramas y desempeño técnico; garantizar la calidad;
controlar los cambios; y enviar y recibir pagos por el trabajo completado.
Bajo la administración del contrato, las solicitudes de cambio para el trabajo contratado se
evalúan según las condiciones establecidas en el contrato del proyecto; en caso de diferencias,
los cambios se implementan solo después de obtener las aprobaciones y modificar el contrato.
La administración de contratos se gestiona utilizando procedimientos similares a los descritos
para la autorización de tareas, seguimiento e informes de rendimiento y control de cambios.
Cuando el cliente requiera procedimientos específicos adicionales para el seguimiento y reporte
del proyecto, estos deberán ser incorporados en el sistema de seguimiento y control del
proyecto del contratista.
La administración de contratos también asegura que los clientes sean facturados por
entregables como se especifica en el contrato, y que se paga a los subcontratistas y

proveedores. Para proyectos simples, la facturación y el seguimiento de pagos se realizan a
través del sistema de cuentas por cobrar del contratista; para proyectos grandes y complejos,
se maneja a través de un sistema de seguimiento de pagos y facturación dedicado.
11.11 Problemas con Proyectos de Monitoreo

y Control
No importa cuán minucioso y concienzudo sea el gerente del proyecto o cuán sofisticado sea el
sistema de control del proyecto, el monitoreo y el control de los proyectos pueden ser
dieciséis
problemático por las siguientes razones:
1. El proceso de seguimiento y control se enfoca en un solo factor, como el costo, e ignora

otros como el cronograma y el desempeño técnico. Esto sucede cuando los procedimientos
de control son emitidos por un área funcional, como contabilidad, y otras áreas no están
involucradas. Forzar el cumplimiento de un factor da como resultado excesos o deslices
en otras áreas; por ejemplo, el énfasis excesivo en los costos puede conducir a retrasos
en el cronograma o mano de obra de mala calidad.
2. Los miembros del equipo del proyecto resienten los intentos de monitorear y controlar su
trabajo (esto sucede especialmente cuando no se involucraron lo suficiente en la
planificación del trabajo) o no cumplen con los procedimientos de control. Los gerentes
alientan esto cuando ignoran a quienes no cumplen con los procedimientos de control.
3. Los miembros del equipo del proyecto no informan los problemas de los que son
conscientes. Puede que no entiendan la situación; si lo hacen, podrían dudar en revelarlo.
La información que reportan puede estar fragmentada y ser difícil de reconstruir.
4. El sistema de control se basa completamente en la autoevaluación del progreso y la calidad

del trabajo, y las personas brindan información sesgada; este es un gran obstáculo para el
control efectivo del proyecto.
5. Los gerentes actúan con indiferencia ante temas controvertidos, creyendo que con el
tiempo los problemas se resuelven solos. Esto lleva a los trabajadores a creer que a la
gerencia no le importa, una actitud que probablemente se contagie a otros a lo largo del
proyecto.
6. Los gerentes que supervisan varios proyectos tergiversan los cargos, de modo que los
excesos en un proyecto se compensan con insuficiencias en otros (o dentro de un proyecto,
los excesos en algunos paquetes de trabajo se compensan con insuficiencias en otros).
otros). La práctica distorsiona los datos históricos que podrían usarse para estimar
los costos de proyectos futuros. Tampoco es ético porque a menudo resulta en un
cobro incorrecto a los clientes.
La gerencia debe ser consciente de estos problemas y trabajar para eliminarlos del proceso
de seguimiento y control. Sobre todo, debe esforzarse por un proceso que sea impersonal,
objetivo y uniformemente aplicado a todos los aspectos del proyecto: personas, partes y
tareas.
11.12 Resumen
La fase de ejecución incluye las etapas de diseño, producción/ construcción e implementación.
Durante la etapa de diseño, el concepto del sistema se subdivide en niveles de subsistemas,
componentes y partes, y para cada uno de estos diseños, se crean esquemas y modelos. El resultado
es un diseño funcional y un diseño físico . En la etapa de producción/construcción, las actividades
principales son la fabricación y las pruebas. Los componentes se ensamblan y el sistema del artículo
final se produce y prueba para garantizar que se cumplan los requisitos para el sistema y sus
componentes.
La gestión de proyectos es responsable de coordinar todas las actividades y controlar cualquier
cambio.
A lo largo de la fase de ejecución, el proceso de control del proyecto guía al proyecto para que
siga avanzando hacia los objetivos de alcance, presupuesto, cronograma y calidad. El punto focal de
control son los paquetes de trabajo individuales y las cuentas de control.
Prácticamente todas las actividades de control (autorización, recopilación de datos, evaluación de
progreso, evaluación de problemas y acción correctiva) ocurren a nivel de paquete de trabajo/cuenta
de control.
El proceso de seguimiento y control comienza con la autorización; una vez autorizado, el trabajo
se realiza un seguimiento continuo con referencia al plan del proyecto para la conformidad con el
alcance, la calidad, los cronogramas y los presupuestos. Las medidas técnicas clave se monitorean
para medir el progreso hacia el cumplimiento de los objetivos técnicos.
El desempeño hasta la fecha se revisa utilizando el concepto de valor ganado, y se revisan las
estimaciones del costo del proyecto y la fecha de finalización.
Cada vez que los costos y los cronogramas se mueven más allá de los límites preestablecidos, o
surgen nuevas oportunidades o problemas intratables, el trabajo debe ser replanificado y
reprogramado. Los cambios son inevitables, pero se hace todo lo posible para minimizar su impacto
en los costos y los excesos de programación. Un sistema formal de control de cambios y gestión de
la configuración garantiza que los cambios se documenten, evalúen, autoricen y comuniquen.
El siguiente capítulo concluye el tema de la ejecución del proyecto y cubre los temas de evaluación,
presentación de informes y comunicación del proyecto. También cubre el resto de la fase de
ejecución: implementación del sistema y cierre del proyecto,
y la última fase del ciclo de desarrollo de sistemas, Operación.

Resumen de variables
PV = costo presupuestado del trabajo programado (BCWS)
AC = costo real del trabajo realizado (ACWP)
EV = valor ganado = costo presupuestado del trabajo realizado (BCWP)
SV = variación de horario = EV ÿ PV
CV = variación de costo = EV ÿ AC
BAC = costo total presupuestado del proyecto

SPI = índice de rendimiento del cronograma = EV/PV
CPI = índice de desempeño de costos = EV/AC
ETC = costo previsto para completar = (BAC–EV)/CPI donde BAC es el costo presupuestado al finalizar
EAC = costo estimado de finalización = AC + ETC

BCSP = costo presupuestado, rendimiento programado = fecha en la que PV es igual a EV en la fecha
de estado
TV = variación de tiempo
1. ¿Cuál es la práctica de “aceleración” o “diseño/construcción”? ¿Cuáles son los

beneficios y peligros potenciales asociados?
2. ¿Qué sucede durante la etapa de diseño? ¿Quien esta implicado? ¿Qué hacen? ¿Cuál es el papel
del director del proyecto? ¿Cómo se monitorean y controlan los cambios de diseño?
3. ¿Cuál es el papel del diseño de interacción en el diseño de productos y

¿desarrollo?
4. ¿Qué incluye el plan de producción/construcción?
5. ¿Qué sucede durante la etapa de producción/construcción? ¿Cómo se planifica el trabajo?
y coordinado? ¿Quién supervisa el trabajo?
6. ¿Cuál es la distinción entre el artículo final del proyecto y los artículos secundarios del proyecto?
¿Qué papel tiene el director del proyecto con respecto a cada uno?
7. ¿Qué es la administración de contratos?
8. ¿Cuáles son las tres fases del proceso de seguimiento y control del proyecto?
9. Explique las diferencias entre los controles internos y externos del proyecto.
10. ¿Cómo se asignan los gastos generales en los paquetes de trabajo?
11. Si se nota una variación en el costo o el cronograma a nivel de proyecto, ¿cómo se
rastreado hasta la fuente de la varianza?
12. Describa el proceso de autorización de trabajo. ¿Qué suele incluir una orden de trabajo?
13. Describa el proceso de recopilación de datos sobre el costo, el cronograma y el trabajo realizado.
14. Discuta diferentes formas de medir el progreso del trabajo en curso.

15. ¿Por qué el control de cambio de alcance es una parte importante del control del proyecto?
¿proceso?
16. Discutir el control de calidad aplicado a los proyectos.
17. ¿Cuáles son las causas principales de los sobrecostos del cronograma del proyecto? Analice al
menos cuatro prácticas que pueden usarse para reducir la variabilidad del cronograma y mantener
los proyectos dentro del cronograma.
18. Consulte el ejemplo 11.3.
una. Suponga que en la semana 28 el equipo descubre un error de procedimiento que invalidó
todo el trabajo realizado hasta el momento en la tarea R. ¿Cuáles son los valores
revisados para el porcentaje de CC completado y el porcentaje de búfer consumido para
la semana 28? ¿En qué parte del gráfico de fiebre se encuentra el proyecto? b. Vuelva a
calcular el porcentaje de CC completado y el porcentaje de búfer consumido a partir de las
siguientes semanas para el porcentaje de tareas completadas en cada una: 16: S, T 100
%; 20: S, T 100 %, Q 10 %; 24: S, T, Q 40%; 28: S, T, Q 100%; 32: S, T, Q, R 50%. A
partir de la semana 32, ¿parece que el proyecto se puede completar para la semana 36?
19. Explique PV, AC y EV, y cómo se usan para determinar las varianzas AV, SV, CV y TV. Explique el
significado de estas variaciones.
20. ¿Qué significa que las cifras del índice de costo o de programación sean menores a 1.00?
21. Explique el TPM, su propósito y cómo se lleva a cabo.
22. ¿Qué es un “asunto”? Explique la "gestión de problemas" y cómo se implementa a través del registro
de problemas.
23. Explique ETC y cómo se relaciona con EAC.
24. Analice las razones por las que el director del proyecto intenta resistirse a los cambios del proyecto.
25. ¿Qué debe hacer un sistema de control de cambios? Describir los procedimientos que minimizan los
cambios innecesarios.
26. ¿Qué aspectos del control de proyectos se incluyen en la administración de contratos?
27. ¿Cuáles son algunas de las dificultades que se encuentran al intentar controlar un
¿proyecto?
28. Utilice las redes de la figura 11.22 para determinar ES, LS, EF y LF para todas las actividades (el
número en el cuadro de actividad es la duración en días). Aplicar el concepto de buffer a la ruta crítica.
Para Red (a) use un búfer de tiempo de 3 semanas para la ruta crítica, un búfer de tiempo de 1
semana para cada ruta que alimenta la ruta crítica. Para la red (b), use un búfer de tiempo de 4
semanas en la ruta crítica, un búfer de 2 semanas para cada ruta que alimenta la ruta crítica.
29. En el proyecto LOGON, suponga que el estado del proyecto a la semana 22 es el siguiente (observe el
uso de los acrónimos más largos; algunos paquetes de software de administración de proyectos usan
estos y no los acrónimos más cortos PV, AC y EV).
BCWS = $ 628,000
ACWP = $640,000
BCWP = $ 590,000
Responde las siguientes preguntas:
una. ¿Cuál es el valor ganado del proyecto a partir de la

semana 22? b. Calcule SV y CV. C. Dibuje un gráfico de estado
similar a la figura 11.14 y trace BCWS, ACWP y BCWP. Mostrar SV y CV.
Determine TV a partir de la gráfica.
d. Calcule SPI y CPI. ¿Ha mejorado o empeorado el rendimiento del

proyecto desde la semana 20?
Figura 11.22 Redes de dos proyectos.
mi. Usando BAC = $990,000, calcule ETC y EAC. ¿Cómo se compara

EAC con la estimación de la Semana 20 de $1,222,593? A partir de su
cuadro de estado, determine la fecha de finalización revisada. ¿Cómo
se compara con la fecha revisada (semana 48 y 49) a partir de la
semana 20? F. ¿Son consistentes los resultados de la Parte (e) con los
resultados de la Parte (d) con respecto a la mejora o deterioro del proyecto?
rendimiento desde la semana 20?
30. El costo presupuestado al 30 de abril para un paquete de trabajo es de $18,000. Suponga

que el 30 de abril el supervisor determina que solo se completó el 80 por ciento del trabajo
programado y el gasto real es de $19,000.
¿Qué es el BCWP? Calcule SV, CV, SPI y CPI para el paquete de trabajo.
31. Utilizando el gráfico de estado de la figura 11.23:
una. Calcule SV, CV y TV, y calcule SPI y CPI para la semana

30. Interpreta los resultados.
b. Calcule ETC y EAC. Calcule la fecha de finalización revisada y dibuje las líneas
para el pronóstico AC y el pronóstico EV.
32. Suponga para los siguientes problemas que el trabajo continúa durante
fines de semana
una. Una tarea está planificada para comenzar el 30 de abril y demora 20 días en
completarse. La fecha real de inicio es el 3 de mayo. Después de 4 días de
trabajo, el supervisor estima que la tarea está completa en un 25 por ciento. Si el
ritmo de trabajo sigue siendo el mismo, ¿cuál es la fecha prevista de finalización?
b. La tarea C tiene dos predecesores inmediatos, las tareas A y B. Está previsto que
la tarea A tarde 5 días en completarse; La tarea B está planificada para tomar 10
días. La hora de inicio temprano para ambas tareas es el 1 de agosto. Las fechas
de inicio reales para las tareas A y B son el 2 y el 1 de agosto, respectivamente.
Al final del 4 de agosto, se evalúa que la Tarea A se completó en un 20 por
ciento y la Tarea B en un 30 por ciento. ¿Cuál es el tiempo esperado de inicio
anticipado para la Tarea C?
33. Consulte el problema 29. Suponga que para la semana 22 los $590 000 indicados son el EV
"más probable". Dado un BAC de $990,000, esto representa el 59.6 por ciento del proyecto
completado. Suponga que un experto evalúa el proyecto LOGON en ese momento y
concluye que LOGON está completado entre el 50 y el 65 por ciento: estos son los escenarios
pesimista y optimista.
Calcule los CPI, SPI, EAC pesimistas, más probables y optimistas correspondientes y
las fechas de finalización previstas para el proyecto.
Figura 11.23 Estado del proyecto a la semana 30.
34. Vuelva a consultar el problema 28 y la figura 11.22.
una. Para la red (a), suponga que después de 7 semanas, las actividades A, B
y E se completaron, D se completó en un 50 por ciento y C se completó en
un 80 por ciento. ¿Cuál es la fecha de finalización anticipada revisada para
el proyecto? b. Para la red (b), suponga que después de 25 semanas, las
actividades A, B, C, F, E, G e I se completaron, y D y H están listas para
comenzar en la semana 26. ¿Cuál es la fecha de finalización anticipada
revisada para ¿el proyecto?
35. Para las siguientes preguntas, consulte la figura 11.24.

A partir de la Semana 5, para el proyecto:
una. ¿Cuál es el valor planificado (PV)?

b. ¿Cuál es el valor ganado del trabajo completado (EV)? C.
¿Cuál es el costo real del proyecto (AC)? d. ¿Cuál es el valor
del trabajo restante? mi. ¿Qué es el IPC?
F. ¿Cuál es el costo estimado para completar el proyecto

(ETC)? gramo. ¿Cuál es el costo previsto al finalizar (EAC)? H.
¿Cuál es la variación estimada del costo al momento de la finalización y el
porcentaje de exceso o defecto?
i. Según EV, ¿el proyecto está adelantado o atrasado? j. De
acuerdo con la ruta crítica (ACFH), ¿el proyecto está adelantado o
retrasado?
Figura 11.24 Estado del proyecto a la semana 5.

1. ¿Qué tipo de controles externos, si los hubiere, impuso el cliente a

¿el proyecto?
2. ¿Qué tipos de controles internos se utilizaron? (Por ejemplo, paquete de trabajo
control, control de cuentas de costos, etc.) Describa.
3. Describa el proceso de control del proyecto:
una. ¿Cómo se autorizó el inicio de las obras? Dar ejemplos de trabajo.

órdenes de autorización.
b. ¿Cómo se recolectaron los datos para monitorear el trabajo? Explicar los métodos
y procedimientos—tiempo, facturas, etc. c.
¿Cómo se contaron y resumieron los datos?
d. ¿Cómo se validaron los datos?
4. ¿El concepto de valor ganado (costo presupuestado del trabajo realizado)

¿usó?
5. ¿Cómo se supervisó el desempeño del proyecto? ¿Qué medidas de rendimiento y varianza

se utilizaron? ¿Se utilizó el concepto de gestión de reservas? Explique.
6. ¿Cómo se identificaron, rastrearon y actuaron los problemas/problemas?

7. ¿Se utilizaron los conceptos de pronóstico ETC y EAC? Si es así, ¿por quién?
¿Con qué frecuencia?
8. ¿Se establecieron límites de variación para el costo y desempeño del proyecto? ¿Que eran?
¿Cómo se aplicaron?
9. Cuando ocurrieron problemas de costo, cronograma o desempeño, ¿qué acción tomó el
gerente del proyecto? Dé ejemplos de problemas y lo que hizo el director del proyecto.
10. ¿Qué cambios en el producto o la meta del proyecto ocurrieron durante el proyecto?
Describa el proceso de control de cambios utilizado. ¿Cómo se revisaron, autorizaron y
comunicaron los cambios al plan o sistema? Mostrar ejemplos de documentos de control de
cambios.
Caso 11.1 Proyecto Cybersonic
Miles Wilder, director de proyecto del proyecto Cybersonic, se considera a sí mismo un

"director de proyecto de director de proyecto". Afirma utilizar los principios de una buena
gestión de proyectos, empezando por tener un plan y usándolo para realizar un
seguimiento cuidadoso del proyecto. Anuncia a los líderes de su equipo que las reuniones
de estado se llevarán a cabo en lunes alternos durante el proyecto esperado de un año.
Los 18 líderes de equipo de proyecto deben asistir y dar resúmenes de las tareas en las
que están trabajando actualmente.
Todos los líderes de equipo se presentan a la primera reunión de estado. Siete están
actualmente gestionando el trabajo para el proyecto y están programados para dar
informes; los otros 11 aún no están trabajando en el proyecto (como se especifica en el
cronograma del proyecto), pero asisten porque Miles quiere que se mantengan
informados sobre el progreso del proyecto. La reunión está programada para 3 horas;
los jefes de equipo deben informar sobre lo que consideren importante. Después de 4
horas de informes de cinco de los líderes, Miles da por finalizada la reunión. Se informan
varios problemas importantes que intenta resolver en la reunión. Se deciden acciones
específicas para resolver algunos de ellos y Miles programa otra reunión para 2 días
después para abordar los otros problemas y escuchar los dos informes restantes.
Algunos de los líderes del equipo están molestos porque tendrán que cambiar sus
horarios para asistir a la reunión.
Miles llega con una hora de retraso a la próxima reunión, que, después de 3 horas,
deja suficiente tiempo para resolver todos los problemas pero no lo suficiente para que
los dos líderes den informes. Miles les pregunta si se enfrentan a problemas o problemas
importantes. Cuando responden “no”, les permite omitir los informes, pero promete
comenzar con ellos en la próxima reunión 2 semanas después. A algunos de los líderes
de equipo se les asignan acciones para abordar los problemas actuales. Algunos de los
asistentes sienten que la reunión fue una pérdida de tiempo.
Antes de la próxima reunión, algunos de los líderes informan a Miles que no pueden
asistir y enviarán representantes. Esta reunión se vuelve incómoda por tres razones. En
primer lugar, se plantean varios problemas nuevos sobre el proyecto y, de nuevo, la
discusión subsiguiente se alarga y no hay tiempo suficiente para
todos para dar un informe de estado; solo seis de los ocho líderes de equipo
programados dan sus informes. En segundo lugar, algunos de los líderes no están de
acuerdo con Miles sobre las acciones asignadas en la reunión anterior. Debido a que
no se tomaron actas en esa reunión, cada líder siguió sus propias notas sobre las
acciones a tomar, algunas de las cuales entran en conflicto con las expectativas de
Miles. En tercer lugar, las personas en la reunión que son "representantes" no están
completamente al tanto de lo que sucedió en las reuniones anteriores, no tienen
suficiente información para dar informes completos o responder preguntas, y dudan
en comprometerse a actuar sin la aprobación de sus líderes de equipo.
Las próximas reuniones siguen el mismo patrón: se pasan del horario; asisten
menos líderes de equipo y más representantes; no se entregan informes de estado
por falta de tiempo; la gente no está de acuerdo sobre los problemas identificados y
las acciones a tomar. El proyecto se atrasa debido a que los problemas no se abordan
adecuadamente o con la suficiente rapidez.
Miles siente que se está desperdiciando demasiado tiempo resolviendo problemas
en las reuniones y que, en cambio, muchos problemas deberían ser resueltos por
completo por los líderes de equipo. Instruye a los líderes para que elaboren soluciones
y cambios por su cuenta y para informar en las reuniones de estado solo los
resultados. Esto reduce la duración de las reuniones pero crea otras complicaciones:
algunos líderes de equipo toman medidas y hacen cambios que ignoran las
dependencias del proyecto y entran en conflicto con las tareas de trabajo de otros
líderes. Todos están trabajando horas extras, pero el proyecto Cybersonic se retrasa aún más.
Preguntas
1. ¿Por qué el enfoque de Miles para rastrear y controlar el proyecto Cybersonic

es ineficaz?
2. Si estuvieras a cargo, ¿qué harías?
Caso 11.2 Mina de oro SA: Valor ganado después de un

cambio de alcance 17
Al equipo de la mina de oro de Sudáfrica (SA) se le encomendó la excavación de un

pozo de ventilación de 2000 metros de profundidad y la excavación de espacio para
una estación en el fondo. El plan era hundir el pozo en 20 meses a un costo de R65,000
(alrededor de US $10,000) por metro de profundidad del pozo. Para la estación en la
parte inferior, se tendrían que excavar 30000 m3 de roca dentro de 3 meses a un costo
de R700 por m3 . El plan asumió un valor ganado uniforme a lo largo del tiempo.
Una vez iniciadas las obras, se modificó el alcance del proyecto para incluir la
excavación de una nueva estación en la mitad del pozo (Figura 11.25) con un volumen
de 2.0000 m3 . Se acordó que elde
trabajo adicional
excavación quetendría que realizarse
la estación al mismo
inferior, pero ritmo
dado que
la remoción de la roca requería levantar solo 1000 metros (en lugar de los 2000 metros
de la estación inferior), el equipo acordó la costo de R500 por m3 para la nueva
estación. Dado que el espacio de trabajo limitado y los recursos disponibles delimitarían
la cantidad de trabajo que se podría realizar simultáneamente, todos coincidieron en
que la nueva estación retrasaría el hundimiento del pozo.
Después de 13 meses, el pozo había alcanzado una profundidad de 1.400 metros bajo
la superficie y se completó la excavación de la estación intermedia. El actual
el costo en ese momento era de R90 millones, más de lo presupuestado para

el período. Esto provocó un problema de flujo de efectivo en esa etapa, y la
gerencia ejecutiva solicitó un informe de valor ganado. No se disponía de
información sobre la cantidad relativa de tiempo dedicado a excavar la nueva
estación y hundir el pozo.
Figura 11.25 Pozo de mina.

Preguntas
1. Calcular el CV, SV, TV, CPI y SPI.

2. Prepare un gráfico para ilustrar el plan inicial del trabajo, incluida la
excavación de la estación en el fondo del pozo, así como el plan
modificado. Indique el valor ganado y el costo real después de 13 meses.
3. Con respecto al problema de flujo de efectivo que se vio agravado por la

alta tasa de gasto, discuta la conveniencia de ejecutar los proyectos más
rápido de lo planeado.
Caso 11.3 Proceso de control de cambios en la

18
empresa Dynacom
En Dynacom Company, cualquier cambio que pueda afectar el alcance del proyecto
está sujeto a un riguroso proceso de revisión y aprobación. Cualquier persona que
solicite un cambio debe documentarlo y presentarlo al líder del equipo. Si el líder
del equipo aprueba la solicitud, la ingresa en el sistema de solicitud de cambio de
la empresa, que el gerente del proyecto verifica todos los días. Luego, el gerente
del proyecto se reúne con el líder del equipo y el solicitante original para discutir el
posible impacto del cambio en el proyecto. Si concluyen que el cambio vale la
pena, el gerente del proyecto programa una reunión con todo el equipo para
analizar la necesidad del cambio, su impacto en el cronograma y el presupuesto, y los riesgos.
A veces, un equipo aprueba los cambios de inmediato, otras veces la revisión
demora unos días o semanas. Si el equipo aprueba el cambio, envía una
recomendación a la junta de gestión de cambios técnicos (TCM) para una
decisión final. El TCM no tiene ninguna asociación con el proyecto y está formado
por altos directivos y otros directores de proyecto. Si el TCM acepta la
recomendación, el gerente del proyecto realiza los cambios necesarios en los
cronogramas de trabajo, presupuestos y otros documentos. Dynacom es una
empresa bastante conservadora y el proceso ha servido bien para ayudarla a
evitar los riesgos asociados con los cambios.
Un inconveniente es que el proceso tarda al menos 3 a 5 semanas para decidir
sobre una solicitud de cambio. Como resultado, los gerentes de proyectos a
veces implementan cambios antes de que sean aprobados. Por ejemplo, Karen,
la gerente de un proyecto con un cronograma muy ajustado y atrasado, necesitaba
hacer cambios en la ruta crítica. Le preocupaba que si esperaba la aprobación
de los cambios, el proyecto se retrasaría demasiado y podría cancelarse. Con la
intención de volver a programar el proyecto y dispuesta a arriesgarse a infringir
las reglas, hizo los cambios de inmediato y asumió que la junta de TCM los
aceptaría, lo cual hizo.
Preguntas
1. ¿Cuál es su opinión sobre el proceso de control de cambios en Dynacom?

¿Cuáles son los beneficios y los inconvenientes?
2. ¿Qué opinas de que Karen pase por alto el proceso para hacer
¿cambios?
Notas finales
1. La salida del diseño normalmente se cataloga en un índice de registro maestro o paquete de datos que enumera todos los dibujos,
especificaciones de materiales, especificaciones de procesos, por ejemplo, para materiales, tratamiento térmico, soldadura, etc. Una guía
para las prácticas de especificación es MIL-STD 490A.
2. Fetherston D. El canal. Nueva York, Nueva York: Times Books; 1997, págs. 198–199.
3. Cooper A. Los reclusos dirigen el asilo: por qué los productos de alta tecnología nos vuelven locos y cómo
Restaurar la Cordura. Indianápolis, IN: Sams; 1999.
4. Los términos "variación" y "desviación" se usan aquí de manera intercambiable, aunque en algunos contratos la variación
se refiere a pequeños cambios en el plan del proyecto por los cuales se espera una compensación o corrección, mientras que la desviación
se refiere a grandes cambios que requieren una respuesta contractual formal.
5. Thompson C. Medidas de desempeño intermedias en proyectos de ingeniería. Actas de Portland
Conferencia internacional sobre gestión de ingeniería y tecnología, Portland, OR, 27 al 31 de julio de
1997, pág. 392.
6. Muirhead B. y Simon W. High Velocity Leadership: The Mars Pathfinder Approach to Better, Faster,
Más económico. Nueva York, NY: Harper-Business; 1999, págs. 40–42.
7. Cusumano M. y Selby R. Secretos de Microsoft. Nueva York, Nueva York: Prensa libre; 1995, págs. 204, 221, 256–257, 417.
8. Los métodos para determinar EV (BCWP) se explican en Pham T. El elusivo costo presupuestado del trabajo realizado para proyectos de
investigación y desarrollo. Project Management Quarterly (marzo de 1985): 76–79;
para EVM, consulte Fleming Q. y Koppleman J. Gestión de proyectos de valor ganado. Upper Darby, Pensilvania: Proyecto
Instituto de Gestión; 1996.
9. Sigurdsen A. Método para verificar el desempeño de costos del proyecto. Revista de gestión de proyectos 25(4); 1994:
26–31.
10. Los problemas de EVM frente a CCPM se analizan en Newbold R., Budd CS y Budd CI Protecting Earned Value
Horarios con Calendario Margen. ProCadena Soluciones, 2010,
http://www.prochain.com/pm/articles/ProtectingEVSchedules.pdf; descargado el 5 de enero de 2016.
11. Para ver ejemplos de modelos analíticos utilizados para TPM, consulte Eisner H. Computer-Aided Systems Engineering.
Upper Saddle River, Nueva Jersey: Prentice Hall; 1988, págs. 297–326.
12. Harrison, F. Gestión avanzada de proyectos. Hants, Inglaterra: Gower; 1981, págs. 242–244.
13. Ibíd., págs. 245 y 246.
14. Ibíd., pág. 244; Archibald, Gestión de programas y proyectos de alta tecnología, págs. 187–190.
15. Hirsch W. The Contracts Management Deskbook. Nueva York, NY: Asociación Estadounidense de Administración;
1986, Capítulo 6.
16. Roman, Ciencia, Tecnología e Innovación, págs. 327–328, 391–395.
17. Fuente: Sr. P. Joubert de Anglo Platinum.
18. Adaptado de Quane J., Kosin M., Heinlen L., Mahoney S. y Quantraro F. Cyberdyne Project Planning
Informe de investigación de gestión, Quinlan School of Business, Loyola University Chicago, mayo de 2007.
Capítulo 12
Evaluación de Proyectos, Comunicación,
Implementación y Cierre
Lo miramos y no lo vemos.
—Lao-Tzu, siglo VI a.C.
El capítulo anterior describió cómo se realiza el seguimiento y la orientación de un proyecto

para cumplir con los cronogramas, los costos y los objetivos de desempeño. A medida que
avanza el proyecto, el gerente del proyecto realiza un seguimiento y evalúa su progreso y
comunica su estado a los trabajadores, la alta dirección y el cliente. La primera parte de este
capítulo analiza los métodos para evaluar y reportar el estado del proyecto y los temas más
amplios de los sistemas de comunicación e información del proyecto. Claramente, la
comunicación del proyecto ocurre a lo largo del proyecto, por lo que estos temas se
superponen con los temas relacionados discutidos anteriormente en el libro.
El final de la fase de ejecución, y del ciclo de vida del proyecto, es la implementación y el
cierre. Tal como se define aquí, la implementación se refiere al punto del proyecto en el que
el artículo final se instala en el entorno del cliente y se entrega al cliente. En algunos
proyectos, la implementación ocurre simultáneamente con la fabricación/construcción del
sistema, en otros es una etapa separada. Un deber del gerente del proyecto es ayudar al
cliente a tomar posesión del artículo final.
Todos los proyectos llegan a su fin, y el gerente del proyecto es responsable del
cierre ordenado del proyecto. IPMA considera que el cierre es una competencia
técnica necesaria; en PRINCE2 es uno de los siete procesos clave de gestión de proyectos.
La segunda parte de este capítulo cubre la implementación y el cierre, así como lo
que sucede en la fase final del ciclo de desarrollo del sistema, Operación.
12.1 Evaluación del Proyecto
El propósito de la evaluación del proyecto es evaluar el desempeño, revelar áreas en las

que el proyecto no está logrando los objetivos y descubrir problemas existentes o potenciales
para que puedan corregirse. Aunque es seguro que se producirán problemas y desviaciones,
no se sabe a priori dónde ni cuándo. La evaluación con el propósito de orientar el proyecto
se denomina evaluación formativa; responde a las preguntas "¿Qué está pasando?" y
“¿Cómo va el proyecto?” La evaluación con el fin de evaluar el proyecto una vez finalizado y
evaluar los resultados finales se denomina evaluación resumida; responde a las preguntas
"¿Qué pasó?" y "¿Cuáles fueron los resultados?" Es el tema central de la etapa “post-
proyecto” y “confirmar beneficios” de la metodología del proyecto PRINCE2.
Evaluación formativa del proyecto
Métodos y Medidas
Se debe utilizar una variedad de métodos, medidas y fuentes para evaluar el progreso y
estos deben especificarse en el plan del proyecto. El uso de una variedad de medidas y
fuentes aumenta la validez de la evaluación, particularmente cuando todas conducen a la
misma conclusión. Las formas principales en que se obtiene y transmite la información del
proyecto son los informes escritos, los informes orales, la observación y las reuniones de revisión.
Los informes escritos son la forma más común y rápida de comunicar información sobre
costos, cronogramas y desempeño del trabajo. Pueden ser muy informativos, a menos que
el escritor decida ocultar u oscurecer la información. Los informes orales proporcionan una
forma rápida de transmitir información, aunque su precisión depende de las habilidades
verbales e interpretativas y de la honestidad del presentador. La precisión de los informes,
tanto orales como escritos, también depende de la cantidad de canales por los que debe
pasar la información para llegar al escritor o presentador; en general, cuantos más canales,
menor es la precisión. Los gerentes de proyecto lo saben, así que además de los informes,
también recopilan información caminando por el proyecto, hablando con la gente,
y haciendo sus propias observaciones de primera mano. 1
Visitas al sitio
La mayoría de los gerentes de proyectos nunca confiarían únicamente en informes de segunda o

tercera mano o fuentes remotas como el correo electrónico para rastrear el progreso del proyecto. Si
no pueden estar siempre en el sitio del proyecto, se aseguran de visitarlo con frecuencia, sin previo
aviso y sin invitación. En el sitio, intentan hablar informalmente con los miembros del equipo durante
el almuerzo o en el descanso. De esta manera, muestran su participación activa en el proyecto,
aprenden lo que está sucediendo y construyen relaciones con el equipo.
En lugar de preguntar sobre el “estado” del proyecto, a veces es mejor preguntar a las personas
cómo les va en la vida, qué les va bien y qué no, y qué recursos o apoyo necesitan. El hecho de que
nadie informe problemas o se queje no significa que todo esté bien. Las señales de que se pueden
estar gestando problemas incluyen que los miembros del equipo guarden silencio o no participen en
las reuniones, eviten las discusiones sobre el proyecto o brinden informes contradictorios sobre el
proyecto. El director del proyecto observa las expresiones faciales y el lenguaje corporal de las
personas. En lugar de tratar de hablar con todos, se concentra en las personas cuyas tareas han sido
tradicionalmente las más problemáticas. Intenta validar los problemas informados obteniendo al
menos dos puntos de vista.
Tecnología
El gerente de un proyecto disperso geográficamente no puede estar en todos los sitios y tiene que
depender de la tecnología: video y audioconferencia, sitios web, correo electrónico y teléfono celular.
Las videoconferencias pueden ser efectivas pero requieren las instalaciones técnicas apropiadas;
Las audioconferencias también pueden ser buenas, pero implican una programación cuidadosa para
no perder el tiempo de las personas. Internet es efectivo para transmitir planes, informes, documentos
y memorandos; sin embargo, es pasivo y no requiere que las personas vean o respondan a los
documentos publicados. La mayoría de los gerentes de proyectos, especialmente en la construcción,
dependen en cierta medida o en gran medida de los teléfonos celulares y las tabletas para la
comunicación en el sitio.
En proyectos internacionales a larga distancia la mejor forma de comunicación es

Conversaciones telefónicas individuales frecuentes , que permiten al director del proyecto escuchar el
tono de voz, sondear detalles y obtener retroalimentación en tiempo real. Pero los administradores del
sitio y los contratistas no siempre son completamente veraces, por lo que el administrador del proyecto
también necesita una fuente confiable en el sitio para observar el trabajo e informar sobre el progreso.
Esto se analiza en el Capítulo 19.
Ver Capítulo 19
Una buena regla general para la comunicación es: cuanto más delicado sea el tema, menor será la
tecnología para comunicarlo. Para temas muy delicados, vale la pena viajar al sitio y reunirse cara a
cara. Para temas relativamente delicados, el teléfono está bien; para problemas no confidenciales, el
correo electrónico está bien. Siempre haga un seguimiento de las discusiones o compromisos
importantes por escrito.
12.2 Gestión de la Comunicación del Proyecto
Plan de comunicación
Para proyectos más grandes, el plan de ejecución debe incluir un plan de comunicación
que aborde las diversas formas de comunicación del proyecto: formal e informal, verbal
y escrita. Incluye un cronograma tentativo para todas las revisiones formales y reuniones
importantes, y describe los formatos de las reuniones, los itinerarios esperados, los
preparativos previos, los límites de tiempo de presentación, la política de asistencia y
quién dirigirá. También especifica importantes puntos de contacto (quién es quién) entre
el cliente, el contratista, los subcontratistas, los partidarios y otros grupos de interés.
La tabla de la Figura 12.1 muestra parte de un plan de comunicación que especifica
las reuniones e informes esperados, y los participantes de cada uno; no se muestra, el
plan también podría incluir la reunión inicial, el acta de constitución del proyecto, las
reuniones de cierre de fase y proyecto, las reuniones de salud y seguridad, etc. La tabla
se complementaría con detalles sobre qué, dónde, cuándo y cómo para cada tipo de
reunión. y reportar
El plan de comunicación debe distribuirse a todos los miembros del equipo del
proyecto y discutirse antes de que comience el proyecto. Para que todos entiendan la
documentación requerida y el contenido y formato de cada uno, el plan debe incluir
ejemplos de documentación buena y mala de proyectos anteriores. Mucho de esto se
puede publicar en línea.
Figura 12.1 Ejemplo de plan de comunicación.
Gestión de documentación
Los proyectos requieren y generan numerosos documentos, cuyo volumen puede llegar a ser
abrumador. Por lo tanto, muchos proyectos necesitan un sistema de gestión de documentación
(DMS) para garantizar que los documentos requeridos se creen, cumplan con los estándares y
estén organizados y almacenados para que las personas autorizadas puedan acceder fácilmente
a ellos. Es posible que se necesite un DMS computarizado para rastrear, almacenar, acceder y
actualizar versiones de documentos digitales.
Reuniones de revisión de estado

Las reuniones de revisión de estado se encuentran entre las formas más importantes de evaluar
y comunicar el progreso del proyecto. La función principal de estas reuniones es identificar las
desviaciones del plan del proyecto y corregirlas rápidamente. Los participantes de la reunión
discuten el progreso del proyecto, el estado de los problemas, los problemas actuales y existentes
y las oportunidades. Pueden ser informales y convocados según sea necesario, o formales y
programados en hitos clave del proyecto. Los proyectos grandes requieren ambos.
Revisiones informales
Las revisiones informales se llevan a cabo con frecuencia y regularidad. También se denominan
“revisiones por pares” porque son atendidas por un grupo de pares. La participación real depende
de la fase del proyecto y de los problemas en cuestión: solo participan los miembros del equipo,
los representantes del cliente, los gerentes funcionales y de proyecto que deben participar. Antes
de las reuniones, se actualizan el estado de los problemas y las fechas y costos estimados de
finalización. Se espera que los asistentes con asignaciones hagan presentaciones.
Un objetivo principal de las revisiones es descubrir problemas y cuestiones y acordar cursos

de acción; en consecuencia, se esperan malas noticias y problemas y se confrontan abiertamente.
El director del proyecto actúa como facilitador y fomenta la honestidad y la franqueza. Se debe
evitar señalar con el dedo, pasar la culpa o disimular el conflicto; tales comportamientos solo
hacen perder tiempo y desalientan la asistencia.
Ver Capítulo 11
Cualquier problema que surja en una revisión se anota en el registro de problemas, descrito
en el Capítulo 11, y una de las primeras tareas del día en cada revisión es evaluar los elementos
del registro y el estado de cada uno. Siempre, el director del proyecto, no un secretario o
funcionario, debe dirigir la revisión, tomar notas y, cuando sea necesario, redactar y distribuir las
notas. Esto refuerza la percepción de que el líder está comprometido, involucrado y a cargo.
Reuniones de pie
La "reunión de pie" diaria es una forma de revisión informal. Destinado principalmente a actualizar el
estado, identificar problemas y acelerar las soluciones, la reunión es breve (15 minutos) y va al grano.
Por lo general, se lleva a cabo al comienzo del día, el equipo ofrece un repaso rápido del progreso de
ayer y los próximos pasos de hoy. La asistencia sorpresa ocasional de una persona destacada (gerente
sénior del contratista o del cliente) añade energía y mantiene a todos alerta. Los problemas que requieren
más de un minuto de reflexión se posponen para una reunión programada.
Revisiones formales
Las revisiones formales se programan en hitos o etapas críticas del proyecto. Dos de estas revisiones
son la revisión preliminar del diseño y la revisión crítica del diseño aplicadas a los proyectos de diseño y
desarrollo descritos en el Capítulo 9. La revisión preliminar del diseño evalúa el ajuste de las
especificaciones del diseño funcional a los requisitos operativos básicos; la revisión crítica del diseño
evalúa los detalles del diseño frente a las especificaciones preliminares del diseño. Las revisiones a
veces sirven como una puerta para continuar con el proyecto, y la decisión de continuar o finalizar el
proyecto depende de los resultados de la revisión.
Ver Capítulo 9
En todo proyecto, independientemente de las obligaciones contractuales, el cliente debe asumir

alguna responsabilidad como guardián del proyecto. La auditoría del proyecto es una revisión formal
especial iniciada por el cliente para evaluar de forma independiente el progreso del proyecto.
Puede llevarse a cabo en cualquier etapa del proyecto o ante cualquier cambio significativo en los costos,
el cronograma o las metas del proyecto. Las auditorías se analizan en el Capítulo 9.
Ver Capítulo 9
Sala de reuniones del proyecto
Las reuniones y conferencias del proyecto a menudo se convocan en un lugar de reunión central.
u oficina de proyectos. La sala de reuniones proporciona espacio físico para preparar, almacenar y mostrar
información del proyecto. Los diagramas de Gantt, las redes y los diagramas de costos que muestran el
rendimiento planificado y real se muestran en las paredes para una fácil referencia. La sala tiene una mesa
de conferencias, sillas, archivadores, computadoras, un proyector y, en ocasiones, equipo de teleconferencia.
Informes y documentos formales
La gerencia de la empresa debe mantenerse informada sobre el estado, el progreso y el desempeño de los
proyectos en curso y futuros. Los problemas que afectan las ganancias, los cronogramas o los presupuestos,
así como las acciones recomendadas, deben informarse con prontitud. Las partes interesadas (el cliente, los
grupos de profesionales, ciudadanos y activistas, las agencias públicas, los accionistas y otras personas que
tengan un interés genuino en el proyecto) también deben mantenerse al día. La comunicación frecuente y
honesta con las partes interesadas genera confianza y evita sorpresas.
Reportes a la Alta Gerencia y al PMO
El director del proyecto y el personal envían informes a la alta dirección y a la oficina de gestión de proyectos
(PMO) utilizando la información generada por el PCAS o el PMIS.
2
Los informes, disponibles en formato escrito y en línea, incluyen:
1. Resumen del estado del proyecto.

2. Elementos de bandera roja donde se han tomado o deberían tomarse acciones correctivas.
3. Logros hasta la fecha, cambios de cronograma y estimaciones de cronograma y costo al momento
de la finalización.
4. Situación actual de costos y desempeño de costos.
5. Plan de mano de obra y limitaciones.
Cuando varios proyectos están en marcha simultáneamente, la PMO compila y proporciona a la gerencia
resúmenes mensuales que muestran su estado relativo. Cada resumen incluye los nombres del cliente y del
director del proyecto; inversión monetaria y laboral; fechas de inicio y finalización programadas; posibles
riesgos, pérdidas y
ganancias; y otra información. Los resúmenes permiten que la gerencia evalúe el desempeño
relativo de los proyectos y su influencia combinada en la empresa, y que la PMO coordine planes,
autorizaciones y asignaciones de recursos entre los proyectos. Cuando los proyectos se
administran como una cartera (Capítulo 18), los resúmenes ayudan a la gerencia a decidir qué
proyectos continuar, aumentar o disminuir los recursos o terminar.
Ver Capítulo 18
Reportes a Gerentes de Proyectos, Programas y Funcionales
En un proyecto grande, los líderes del paquete de trabajo y los administradores de subproyectos
envían informes mensuales al administrador del proyecto sobre el trabajo completado, los costos
actuales y previstos y los cronogramas de finalización actualizados, y el administrador del proyecto
envía informes relacionados al administrador del programa (similar a la Tabla 11.1 ). y Figura
11.14 en el Capítulo 11). Cada mes, el gerente de proyecto también envía informes que muestran
los costos incurridos al gerente o controlador financiero de la empresa, e informes que muestran
las horas de mano de obra y los costos invertidos en paquetes de trabajo a los gerentes
funcionales. Los informes de las Figuras 8.8 a 8.12 del Capítulo 8, modificados para incluir los
gastos reales, son representativos.
Reportes a Clientes/Usuarios
Cada mes, el gerente del proyecto debe enviar al cliente un informe sobre el progreso del trabajo
y los impactos de cualquier cambio en el alcance, el cronograma o el costo del trabajo.
Si bien el director de marketing o de relaciones con el cliente del contratista puede estar
formalmente encargado de comunicar la información relacionada con el contrato al cliente,
depende del gerente del proyecto asegurarse de que el cliente permanezca bien informado, y
debe estar disponible para responder preguntas y solicitudes de proyectos. información. El cliente
nunca debe estar “sorprendido”.
12.3 Sistemas de Información de Gestión de Proyectos
Los métodos formales de planificación y control descritos en este libro no requieren más datos de entrada o
información que la que está o debería estar disponible en cualquier proyecto.
Lo que sí requieren es, en una palabra, un sistema para recopilar, organizar, almacenar, procesar y difundir esa
información: un sistema de información de gestión de proyectos (PMIS).
Software PMIS
Métodos como EVM, control de cambios y gestión de configuración para un proyecto grande requieren procesar e
integrar una gran cantidad de información. Como las computadoras son buenas en esto, el software PMIS se ha
convertido en una herramienta esencial para la planificación y el control de proyectos. De hecho, sin software sería
difícil realizar gran parte del análisis necesario para planificar y controlar grandes proyectos.
Existen numerosos tipos de paquetes de software de proyecto PMIS que varían ampliamente en capacidad,
flexibilidad y precio. Los paquetes de software PMIS más simples están limitados en lo que pueden hacer, pero por
lo general son buenos en lo que sea; una vez que se domina el software simple, es fácil actualizarlo a un software
más sofisticado.
Características de los PMIS
El siguiente es un resumen de los tipos de capacidades analíticas, resultados, funciones y características que
ofrece el software PMIS. Es importante tener en cuenta que entre los muchos paquetes de software disponibles, la
mayoría no tiene todas estas capacidades; algunos realizan sólo las funciones más básicas.
Programación y planificación de redes
Prácticamente todos los paquetes de software de proyectos realizan la programación de proyectos utilizando la red.
basados en algoritmos para calcular los tiempos tempranos y tardíos, los tiempos de holgura y
la ruta crítica o la cadena crítica. Entre las capacidades a buscar están el tipo de procedimiento
(CPM, PERT, PDM, CCPM), el número máximo de actividades permitidas, el formato para
actividades y eventos (algunos usan un esquema WBS) y la calidad y claridad de los resultados
( ej., red, diagrama de Gantt, informes tabulares o varios tipos).
Administracion de recursos
La mayoría de los sistemas de software realizan la carga, nivelación y asignación de recursos,

pero varían en la sofisticación analítica y la calidad de los informes. Las principales
consideraciones son el número máximo de recursos permitidos por actividad o proyecto; el tipo
de técnicas de carga/programación utilizadas (recurso limitado, tiempo limitado o ambos);
programación dividida (detención y reinicio de actividades); uso intercambiable de diferentes
recursos; y tasa de uso de recursos.
presupuesto
Los sistemas de software varían mucho en la forma en que manejan los costos y generan
informes de presupuesto y resumen de costos. En algunos, la información de costos y gastos
no se trata de manera explícita; en otros, la contabilidad de costos es una característica
importante. El software PMIS para proyectos grandes debe tener un módulo de costos y
presupuestos (como el PCAS descrito en el Capítulo 8) que está integrado con módulos para
planificación, programación, adquisición y seguimiento.
Ver Capítulo 8
Gestión de múltiples proyectos y carteras de proyectos
Muchos sistemas de software permiten agrupar datos de diferentes proyectos para el análisis ,
la planificación y el control de varios proyectos. Esta función combina información de varios
proyectos simultáneos para formar una imagen del estado general del
organización. Algunos sistemas de software proporcionan un "panel de control" o una descripción

general de todos los proyectos. Los gerentes pueden distinguir fácilmente qué proyectos están
funcionando bien de aquellos que experimentan problemas o sobrecostos, una capacidad esencial
para la gestión de cartera de proyectos (Capítulo 18). Al "hacer clic" en un proyecto en particular,
pueden hacer zoom para ver información más detallada sobre el proyecto.
Ver Capítulo 18
Control de costos, análisis de rendimiento y control de cambios
Aquí es donde las capacidades del software del proyecto difieren considerablemente. Para realizar
la función de control, un sistema debe poder comparar los costos reales y el trabajo completado
con el desempeño presupuestado y planificado. Entre las características que se deben tener en
cuenta se encuentran la capacidad del software para calcular e informar las variaciones de costos
y cronogramas y las métricas EVM (índices de rendimiento y pronósticos para completar). Los
paquetes de software más sofisticados "resumen" los resultados y permiten la agregación, el
análisis y la generación de informes en todos los niveles de la EDT. También permiten la
modificación y actualización de los planes existentes mediante el ingreso de fechas y costos reales de inicio y finaliz
Además, ayudan a administrar y revelar los impactos de las solicitudes de cambio. El software con
capacidades de simulación integra la red, el presupuesto y la información de recursos y permite que
el administrador del proyecto haga preguntas "qué pasaría si" en varios escenarios.
Interfaz y flexibilidad
Algunos paquetes de software de PMIS son compatibles con las bases de datos existentes para
nómina, compras, inventario, ERP, contabilidad de costos u otros PMIS, y se vinculan con ellas;
algunos se pueden usar con DBMS populares, modelado y sistemas de análisis de riesgos.
Los sistemas varían ampliamente en su flexibilidad. Muchos realizan un conjunto limitado de
funciones; otros permiten al usuario desarrollar nuevas aplicaciones o modificar las existentes,
según las necesidades. Entre las aplicaciones disponibles se encuentran el control de cambios, la
gestión de la configuración, las matrices de responsabilidad, los informes de gastos, los informes de
costes y rendimiento técnico y los resúmenes de rendimiento técnico. Muchos
Los sistemas permiten un fácil acceso a través de un navegador a una variedad de aplicaciones
comerciales y bases de datos que utilizan tecnología de Internet.
3
Gestión de proyectos habilitada para la web
Muchos productos de software de gestión de proyectos aprovechan la tecnología habilitada para la web
que ofrece planes e informes en sitios web interactivos. Esta tecnología es adecuada para situaciones en
las que el equipo del proyecto y las partes interesadas están dispersos geográficamente. Poner la
información en el sitio web de un proyecto u otra red de Internet o intranet ofrece los beneficios de la
información inmediata
disponibilidad, comunicación rápida y fácil entre trabajadores e información actualizada porque se

comunica en tiempo real.
Con el software de gestión de proyectos integrado del navegador web, los miembros del equipo
pueden informar sobre el progreso y recuperar tareas a través de sus propias páginas web individuales.
El gerente puede agregar información recibida de sitios de trabajo dispersos para obtener una visión
general de todo el proyecto.
En la mayoría de los casos, las herramientas necesarias ya están a mano. El software de proyecto
habilitado para la web requiere solo una cosa: acceso a un navegador web. Casi todo el mundo usa
Internet, por lo que los miembros del equipo se adaptan fácilmente a los métodos basados en la web para
enviar y acceder a la información del proyecto. Los costos de gastos generales, actualización y
mantenimiento de la comunicación basada en web son muy bajos.
4
Intranets y Productividad Grupal
Una intranet es una red informática privada que utiliza estándares y protocolos de Internet para permitir
la comunicación entre las personas dentro de una organización. Proporciona acceso a un conjunto común
de información de las computadoras dentro de una organización. Solo los miembros de la organización y
otras partes autorizadas pueden acceder a la intranet, aunque el acceso se puede extender a
organizaciones, socios o clientes externos de confianza a través de una red extendida llamada extranet.
Con una intranet, es fácil para los usuarios acceder al software de productividad grupal y almacenar
informes, perfiles, calendarios y programaciones. También es fácil localizar información en estos
documentos utilizando herramientas especiales para compartir documentos como
como servicios de alojamiento de archivos, grupos de noticias, salas de chat y pizarras electrónicas.
Estas herramientas son especialmente útiles para compartir información pictórica sobre requisitos y
descripciones de diseño de productos.
Una de las formas más comunes en que los gerentes de proyecto usan las intranets es para
recopilar información sobre el tiempo dedicado a los proyectos. La información se conserva en una
base de datos del proyecto y luego se procesa mediante un software de gestión de proyectos para
informar y contabilizar el tiempo invertido y el tiempo que aún se necesita para completar el proyecto.
En el pasado, las videoconferencias o las audioconferencias eran las únicas formas de que los
equipos dispersos geográficamente celebraran reuniones, pero hoy en día se pueden compartir video,
voz y datos a través de la intranet o Internet en ubicaciones de escritorio. La información compartida
puede ser en forma de hoja de cálculo, documento de texto, presentación, gráfico, fotografía, esquema
de ingeniería, archivo de video o transmisión en vivo. Otras formas para que los participantes
compartan colectivamente información del proyecto y agreguen comentarios y vean las contribuciones
de otros son los foros de discusión en línea y las salas de chat.
En Boeing, por ejemplo, todos los diseños, que se almacenan electrónicamente y se mantienen
actualizados para reflejar los cambios más recientes, están disponibles de inmediato para cualquiera
que los necesite. La notificación de cualquier cambio se envía por correo electrónico a todos los que
necesitan saber, según se especifica en una matriz de responsabilidad (personas con responsabilidad
"N"). Siempre que los miembros del equipo tengan acceso a una computadora y un navegador,
pueden participar en las reuniones. Los ingenieros de Kansas que tienen problemas para ensamblar
una maqueta pueden enviar imágenes de video a los diseñadores de Seattle, quienes pueden ver la
maqueta, evaluar el problema y ofrecer sugerencias; en ausencia de esa tecnología, los diseñadores
tendrían que ir a Kansas. La gestión de reuniones y equipos virtuales habilitados por tecnología se
analiza en el Capítulo 16.
Ver Capítulo 16
Algunas palabras sobre el correo electrónico. Cualquier gerente de proyecto experimentado dirá
que es una herramienta de comunicación importante, pero le aconsejará que no reemplaza las
reuniones cara a cara o por teléfono, especialmente cuando se trata de tomar decisiones.
PMIS en el ciclo de vida del proyecto

Como se muestra en la Figura 12.2, un PMIS puede ayudar al director del proyecto en todas
las fases del ciclo de vida del proyecto. El siguiente ejemplo ilustra este uso.
Figura 12.2 Funciones del PMIS en el ciclo de vida del proyecto.
'
Ejemplo 12.1: Sigma PMIS para Proyecto
Associates Planificación y Control
Sigma Associates, la empresa de arquitectura/ingeniería mencionada en el Capítulo 8,

Ejemplo 8.7, utiliza un PMIS para las funciones de control y planificación de proyectos.
El PMIS de Sigma es tan ubicuo en sus operaciones que los empleados lo ven como un
miembro del equipo; lo llaman "Sally".
Ver Capítulo 8
Una vez que se aprueba un proyecto, la función de Sally es comparar rutinariamente el

plan de proyecto de línea de base original o actual con el desempeño real, generar
advertencias sobre discrepancias y pronosticar los resultados de cronograma y costo.
Cada semana, Sally recibe información sobre los costos actuales y acumula
estimaciones del tiempo semanal dedicado a cada actividad de todos los participantes del
proyecto. Los gastos no laborales y los reembolsos de los clientes se ingresan a través
del sistema de contabilidad general de la empresa.
Cada dos semanas, el director del proyecto calcula las horas necesarias para completar
cada actividad, que Sally convierte en un porcentaje completado. El sistema multiplica las
horas de mano de obra presupuestadas por estos porcentajes para determinar las horas
de mano de obra estimadas necesarias para llevar la actividad a su nivel actual de
finalización (una forma de valor ganado). Al comparar esta estimación con los gastos de
mano de obra reales de las tarjetas de tiempo, el director del proyecto puede determinar si
la actividad avanza al ritmo presupuestado. Sally hace comparaciones entre lo real y lo
planificado y reporta discrepancias, que los gerentes usan para detectar problemas. Cada
vez que un director de proyecto no proporciona las horas estimadas quincenales, recibe
un aviso de Sally.
Sally usa las horas anticipadas para completar para preparar estimaciones de las
cargas de mano de obra requeridas para el resto del proyecto. Estas estimaciones se
utilizan para ajustar las cargas de mano de obra restantes y para hacer las revisiones
necesarias a los horarios.
El contralor usa Sally para pronosticar el tiempo y los montos de la facturación del
cliente, y el tiempo de los pagos esperados de acuerdo con el historial de pago de cada
cliente. Con base en el porcentaje de trabajo completado, el sistema calcula una estimación
de los honorarios ganados del cliente y los compara con los gastos reales del proyecto en
un análisis mensual de pérdidas y ganancias. Sally también genera informes mensuales
de ganancias netas resumidas por oficina, departamento y gerente de proyecto. También
combina la utilidad neta de todos los proyectos para dar una idea de la salud financiera de
la empresa.
Sally también verifica la exactitud de las horas cargadas en las tarjetas de tiempo
comparando horas con fechas en el horario, y retiene cualquier tarjeta con discrepancias y envía una nota al
empleado. Cada semana envía un informe resumido de tarjetas rechazadas a la contraloría.
Adaptando el PMIS al Proyecto
La mayoría del software de información de PM no es rival para las capacidades de Sally, pero está bien, ya que tales
capacidades no siempre son necesarias. El propósito de un PMIS, en palabras de Palla, es “llevar la información
correcta a la persona correcta en el momento correcto para que se pueda tomar la decisión correcta para el proyecto”.
5
Cualquier
es el correcto Las empresas suelen utilizar más de un tipo de software de información PMISde
de gestión capaz de hacer
proyectos, poresto
ejemplo, Microsoft Project para proyectos más pequeños y Primavera para proyectos grandes.
Si bien el software de gestión de proyectos es esencial para manejar de manera eficiente los aspectos
computacionales de la gestión de proyectos, su papel debe verse en contexto, ya que los sistemas informáticos tienen
un valor limitado en relación con numerosos aspectos de la gestión de proyectos: identificar y negociar con las partes
interesadas clave, elegir subcontratistas clave, motivar a los equipo, y resolución de conflictos interpersonales, por
nombrar algunos. Sin embargo, muchos gerentes de proyectos novatos asisten a un seminario de software de 1 día y
tienen la impresión de que la gestión de proyectos consiste en poco más que crear diagramas de Gantt en una
computadora (!)
12.4 Comunicación informal

Gran parte de la comunicación en los proyectos ocurre informalmente a través de la vid. Dicha
comunicación no es exhaustiva ni confiable, distorsiona el mensaje y no garantiza que las
personas que necesitan información alguna vez la obtengan. Sin embargo, a pesar de los
inconvenientes, dicha comunicación informal es en gran medida beneficiosa y esencial.
Cumple con las necesidades sociales y laborales y transmite información de manera más
rápida y directa que la mayoría de los sistemas formales. Algunos teóricos postulan que una
amplia red de comunicación informal es esencial para que cualquier organización funcione
bien.
Si bien los gerentes no pueden controlar la comunicación informal, pueden influir en ella.
Una forma es insistir en la informalidad eliminando las barreras de estatus e inspirando
conversaciones informales entre gerentes y trabajadores. Algunas empresas insisten en que
todos, desde el presidente para abajo, usen una etiqueta con su nombre, se llamen por su
nombre de pila y que los gerentes mantengan una política de "puertas abiertas". El diseño
físico de la oficina también es fundamental: la eliminación de paredes y divisiones, la
colocación de sillas y escritorios en "agrupaciones familiares" para equipos y la ubicación
puntual de salones son formas de fomentar la comunicación informal.
La gestión de proyectos intenta hacer lo que a veces hace la organización informal: permitir
que las personas involucradas en un problema o decisión se comuniquen directamente y
tomen decisiones.
12.5 Etapa de implementación
La etapa final del ciclo de vida del proyecto es la implementación, la etapa en la que el sistema
del elemento final u otro entregable se entrega al usuario para su operación.
A veces, la implementación ocurre en un instante; a veces lleva mucho más tiempo. Toma un
reloj. Si el reloj es simple, simplemente conéctelo y configúrelo. Si se trata de un reloj despertador
digital con radio, es posible que primero deba leer las instrucciones. Si se trata de un reloj
nuclear como el que utiliza la Oficina de Normas de EE. UU., es posible que deba asistir a un
programa de capacitación de una semana. Si el reloj debe reemplazar un reloj existente
conectado a un dispositivo temporizador que controla la iluminación y la calefacción en un gran
rascacielos, deberá desarrollar una estrategia para sustituir el reloj a fin de minimizar las
molestias y molestias a las personas en el edificio. Puede haber muchos problemas asociados
con la implementación, comenzando con la capacitación del usuario y las pruebas de aceptación.
Entrenamiento de usuario
El propósito de la capacitación del usuario es informar al usuario sobre cómo operar, mantener
y dar servicio al sistema. En un extremo, la capacitación es un simple folleto de instrucciones;
por el otro, es un programa extenso y continuo con un presupuesto anual considerable. La
capacitación del usuario comienza con la determinación de los requisitos de capacitación: el tipo
y el alcance de la capacitación requerida. Esto dictará el tipo de materiales necesarios (manuales,
videos, simuladores); personal a capacitar (personal existente o recién contratado); técnicas a
utilizar (aula, estudio independiente, dramatizaciones); cronograma de capacitación (todos a la
vez, en fases o en curso); y dotación de personal (contratista, usuario o personal de formación
subcontratado). Los usuarios deben revisar y aprobar todos los procedimientos y documentos
de capacitación antes de que comience la capacitación, y luego proporcionar información para
mejorar la capacitación. A menudo, el usuario se hace cargo de la formación después de que
los formadores del contratista hayan formado a los formadores del usuario.
La formación de los usuarios debe abordar la cuestión de cómo encajará el nuevo sistema
en el entorno del usuario. Debe proporcionar una visión general de los objetivos del sistema,
alcance y operación, y cómo el sistema interactúa con la organización usuaria.

Esto permitirá al usuario comprender el sistema dentro de su entorno e integrarlo con los sistemas
existentes. Los nuevos sistemas crean miedo, estrés y ansiedad; uno de los objetivos del
entrenamiento también debe ser aliviar o eliminar estos.
Pruebas de aceptación del usuario
Entre las pruebas del artículo final realizadas antes o durante la instalación se encuentran las
pruebas de aceptación del usuario. Los resultados de estas pruebas determinan si el sistema puede
adoptarse o instalarse tal como está, si necesita modificaciones o ajustes, o si debe rechazarse.
Las pruebas de aceptación del usuario difieren de las pruebas realizadas por el contratista
durante el diseño y la producción, aunque las pruebas del contratista deben anticipar y ser lo
suficientemente rigurosas para superar los requisitos de prueba del usuario. No obstante, el
contratista debe estar preparado para realizar modificaciones a la espera de los resultados de las
pruebas del usuario.
Idealmente, los usuarios realizan las pruebas de aceptación con una asistencia mínima del
equipo del proyecto. En los casos en que no puedan realizar las pruebas, el equipo del proyecto
debe actuar como usuarios sustitutos y hacer todo lo posible para probar el sistema tal como lo
haría el usuario, lo que significa asumir el papel de alguien sin experiencia técnica relacionada con
el sistema. La falta de participación del usuario en estas pruebas puede conducir a problemas
posteriores; por lo tanto, incluso en el papel de usuario-probador sustituto, el contratista debe insistir
en que el usuario esté presente para presenciar las pruebas.
Instalación y conversión del sistema
La etapa de instalación y conversión del sistema se realiza de acuerdo al plan de implementación.

Durante esta etapa, el equipo se instala, prueba, ajusta y se considera operable para el cumplimiento
de los requisitos.
Prácticamente todos los sistemas nuevos están, en cierto sentido, diseñados para sustituir otros
sistemas existentes, por lo que es de gran importancia la estrategia que se utilizará para reemplazar
el sistema antiguo por el nuevo: el proceso de conversión. Tres estrategias posibles, ilustradas en
la Figura 12.3, son:
• Instalación en paralelo: tanto los sistemas nuevos como los antiguos funcionan en paralelo
hasta que el nuevo sistema esté suficientemente probado.
• Operación piloto: el nuevo sistema se opera en una capacidad limitada hasta que se prueba, y luego
se implementa a medida que se retira el sistema anterior. • Pavo frío (Big Bang): de un solo golpe,
el nuevo sistema se instala y
el antiguo se muda.
Seleccionar una estrategia de conversión no es sencillo; implica consideraciones de costos, riesgos y

logística. Por ejemplo, la primera estrategia parece la más segura: si falla el nuevo sistema, el anterior sigue
ahí. Pero también es el más caro porque se deben operar dos sistemas completos simultáneamente y con
todo el personal necesario.
Con la segunda estrategia, los costos y riesgos son bajos y el personal puede capacitarse por etapas. El
inconveniente es que la operación piloto no es necesariamente representativa de la operación completa del
sistema y, a veces, solo después de que el nuevo sistema se haya incorporado por completo (y el anterior se
haya eliminado) los problemas se harán evidentes. La última estrategia es la más rápida y potencialmente la
menos costosa, pero también es la más riesgosa y plantea problemas sobre cuándo se capacitará al personal
y qué sucederá si falla el nuevo sistema.
Antes de la instalación, el gerente del proyecto actualiza todos los planes y cronogramas, obtiene
aprobaciones para las revisiones y renueva los compromisos de los equipos del contratista y del cliente. La
implementación es una etapa de alto estrés para todos, y el gerente y el equipo del proyecto deben ser
pacientes con los usuarios y sensibles a sus preguntas, inquietudes y temores.
Una vez que se ha instalado el nuevo sistema, el contratista continúa supervisándolo y realizando pruebas
para asegurarse de que se instaló correctamente, funciona como se esperaba e interactúa sin problemas con
otros sistemas en el entorno del usuario.
12.6 Terminación y Cierre del Proyecto

Para cuando se haya entregado e instalado el artículo final, muchos miembros del equipo del
proyecto estarán ansiosos por pasar a algo nuevo. Los gerentes cambian con entusiasmo el
énfasis a los próximos proyectos y, como resultado, pueden prestar poca atención a la
terminación. Sin embargo, como indica el sentido común, terminar un proyecto no es menos
importante que cualquier otra actividad del proyecto. De hecho, el método de finalización puede
determinar en última instancia el éxito o el fracaso del proyecto.
Al cierre, el producto o entregable se entrega al cliente.
A veces, los contratos prevén una primera entrega al finalizar y una segunda entrega después
de un período de responsabilidad por defectos (también conocido como período de retención,
período de garantía o período de mantenimiento). En la primera entrega, el cliente debe
asegurarse de que se identifiquen y notifiquen todos los defectos patentes (defectos que una
persona calificada puede detectar fácilmente). A partir de entonces, el contratista sólo responde
de la subsanación de los vicios ocultos, que son aquellos que no pudieron ser detectados
mediante una inspección razonable en la primera entrega. Si, por ejemplo, no estaba lloviendo
en el momento de la primera entrega, un techo que gotea después cuando llueve se consideraría
un defecto latente. El propósito de la segunda entrega es brindarle al cliente más tiempo para
identificar desviaciones de las especificaciones o mano de obra deficiente.
Después de la segunda entrega, el contratista ya no es responsable de los defectos; cualquier
tarifa de retención retenida por el cliente para garantizar el cumplimiento se paga al contratista.
Figura 12.3 Tres estrategias para la conversión del sistema.
La terminación puede ocurrir en una variedad de formas, siendo la mejor forma planificada
y sistemática. Las peores formas son la cancelación abrupta, el desgaste lento del esfuerzo o
el desvío de recursos por parte de proyectos de mayor prioridad. Un proyecto puede arruinarse
simplemente si se le permite "cojear" hasta que se esfuma. A menos que finalice formalmente ,
un proyecto puede prolongarse indefinidamente, a veces por negligencia o recursos insuficientes,
a veces intencionalmente por falta de trabajo de seguimiento. En este último caso, los
trabajadores permanecen en la nómina del proyecto después de haber completado su trabajo.
A menos que el proyecto finalice oficialmente, las órdenes de trabajo permanecen abiertas y
los cargos por mano de obra continúan acumulándose.
Tipos de terminación
Las semillas del éxito del proyecto se siembran temprano: dado que el éxito del proyecto depende
en gran parte de la aceptación de los resultados del proyecto por parte del cliente, el director del
proyecto debe asegurarse durante la definición del proyecto de que los criterios de aceptación estén
claramente definidos, acordados y documentados, y cualquier cambio hechos después de que sean
aprobados por el contratista y el cliente.
Hay muchas razones por las que los proyectos no llegan a completarse con éxito. Un proyecto
puede abortarse cuando las pérdidas financieras o de otro tipo por la terminación anticipada se
consideran menores que las pérdidas esperadas por completar el proyecto. Podría ser un proyecto
de "elefante blanco" con baja rentabilidad percibida o probabilidad de éxito.
El cliente del artículo final del proyecto podría simplemente cambiar de opinión y ya no desearlo.
Los proyectos también se detienen debido a cambios en las condiciones del mercado o en la
tecnología, desempeño técnico insatisfactorio, mala calidad de los materiales o mano de obra,
incumplimiento del contrato o insatisfacción del cliente con el contratista. Muchas de estas razones
son culpa del contratista y podrían haberse evitado si la gerencia del proyecto hubiera ejercido una
mejor planificación y control, respetado más al cliente o actuado de una manera más ética. Tales
rescisiones dejan sin cumplir los requisitos del usuario y empañan la competencia técnica y la
capacidad de gestión del contratista.
Responsabilidades de terminación y liquidación
Al igual que con todos los demás trabajos del proyecto, el gerente del proyecto es responsable de
planificar, programar, monitorear y controlar las actividades de terminación y cierre.
6
Archibald enumera las siguientes responsabilidades:
A. Planificación, programación y seguimiento de las actividades de cierre:
• Obtener y aprobar los planes de terminación de funcional involucrado

gerentes
• Preparar y coordinar planes y cronogramas de terminación. • Plan
para la transferencia de los miembros del equipo del proyecto y los recursos a otros
proyectos
• Supervisar el cumplimiento de todos los acuerdos contractuales.
• Supervisar la disposición de los materiales sobrantes y el proyecto
equipo.
B. Actividades de cierre final:
• Cerrar todas las órdenes de trabajo y contratos con subcontratistas para
trabajo completo. •
Notificar a todos los departamentos de la finalización del
proyecto. • Cerrar la oficina del proyecto y todas las instalaciones ocupadas por el proyecto
organización. •
Cerrar libros de proyectos.
• Asegurar la entrega de archivos y registros del proyecto al responsable
gerentes
C. Actividades de aceptación, obligación y pago del cliente:
• Garantizar la entrega de artículos finales, artículos complementarios y la aceptación del cliente

de artículos
• Notificar al cliente cuando todas las obligaciones contractuales han sido

cumplido.
• Asegurarse de que se haya completado toda la documentación relacionada con la

aceptación del cliente según lo requerido por el contrato. • Acelerar cualquier
actividad del cliente necesaria para completar el proyecto. • Transmitir pago formal y
cobro de pagos. • Obtener del cliente un reconocimiento formal del cumplimiento de las
obligaciones contractuales que libere al contratista de obligaciones adicionales (excepto
garantías y avales).
La responsabilidad del grupo C, en particular por el pago y las obligaciones contractuales, se comparte
con el administrador del contrato u otros responsables de las negociaciones entre la empresa y el
cliente y los contratos legales. La actividad final, obtener el reconocimiento formal del cliente, puede
implicar reclamos si el cliente no ha proporcionado los datos o el soporte acordados, o si ha solicitado
artículos fuera del contrato.
especificaciones. En estos casos el contratista tiene derecho a una indemnización.

Antes de que el proyecto se considere cerrado, el cliente revisa los resultados o el artículo
final con el contratista para asegurarse de que todo sea satisfactorio. Los elementos que aún
están abiertos y necesitan atención, y con los que el contratista está de acuerdo, se registran
en una lista, a veces llamada "lista de verificación". Luego, el contratista marca los elementos
de la lista a medida que se rectifican.
Ejemplo 12.2: Lista de verificación para el canal 7
Cinco meses antes de la fecha de finalización programada del Chunnel, la lista de

verificación todavía contenía muchos elementos: más de 22,000. Increíblemente, el día
antes de la entrega programada del Chunnel a su propietario/operador, ese número se
había reducido a solo 100. El problema era que el contrato no permitía (cero) artículos en
la lista de verificación; cualquier elemento abierto en el momento de la entrega anularía
el acuerdo y suspendería el pago. Una solución simple sería retrasar la entrega hasta
que se arreglaran los elementos restantes, lo que se estimó en solo una semana. Pero
pocas cosas asociadas con el Chunnel eran simples. Ya se habían enviado las
invitaciones para la ceremonia de entrega y se habían completado los preparativos para
la gran celebración de gala.
Además, un sindicato de unos 200 bancos ubicados en todo el mundo financió el
proyecto, y cualquier retraso propuesto en la entrega requeriría su aprobación.
Lo que siguió fue una serie de negociaciones frenéticas y apresuradas por teléfono y
fax que se prolongaron durante toda la noche. Al amanecer, el sindicato bancario había
accedido a modificar el contrato. La ceremonia de despedida de gala transcurrió según
lo planeado, con fuegos artificiales, champán, un grupo coral y una banda de jazz de
Dixieland. La ceremonia, a la que asistieron ejecutivos corporativos y gerentes de
proyectos de las diez principales empresas contratistas de Chunnel, además de otros
1000 invitados, fue un proyecto menor en sí mismo.
No se puede subestimar la importancia de hacer un buen trabajo en el momento del despido;

tampoco la dificultad. En la prisa por terminar el proyecto y la confusión que lo acompaña, es
fácil pasar por alto, manejar mal o estropear la terminación. los
Las responsabilidades de terminación enumeradas anteriormente deben delegarse sistemáticamente y marcarse
como completadas. La terminación requiere el mismo grado de atención que otras responsabilidades de gestión
de proyectos.
Cerrar el contrato
La entrega, instalación y aceptación por parte del usuario del elemento final principal del contrato (hardware,
software o servicio) no significa necesariamente que el proyecto esté cerrado. La finalización del proyecto puede
retrasarse hasta que se entreguen los artículos auxiliares necesarios ( artículos complementarios) o el pago de
una compensación por incumplimiento de los acuerdos contractuales. Esto se aplica no solo al contrato entre el
cliente y el contratista, sino también a los contratos entre el contratista y los subcontratistas.
Artículos secundarios
La instalación, operación, mantenimiento y monitoreo del artículo final del contrato a menudo depende de la
disponibilidad de numerosos artículos complementarios del contrato, como herramientas especiales, instrumentos,
repuestos, informes, dibujos, cursos de instrucción y manuales de operación y mantenimiento del usuario. Los
subcontratistas generalmente proporcionan los elementos secundarios y pueden variar desde lo simple y
mundano hasta lo complejo e innovador. El primero se ejemplifica en un manual operativo para un servidor de
red, el segundo en un simulador de computadora de alta fidelidad para capacitar a los operadores de una gran
instalación de procesamiento químico. Simple o complejo, la finalización exitosa de los elementos secundarios
es importante para la finalización exitosa del proyecto.
Los artículos secundarios son artículos de contrato entregables y su costo puede contribuir a un porcentaje
significativo del costo total del proyecto. Sin embargo, tal vez porque se consideran elementos "secundarios", a
menudo se subestima el tiempo y el esfuerzo necesarios para desarrollarlos y producirlos. El resultado es un
retraso en la implementación del artículo final y el cierre del proyecto.
Los elementos secundarios deben incluirse en todos los aspectos de la planificación y el control del proyecto.
El director del proyecto debe asegurarse de que se comprenda bien el alcance del trabajo secundario y de que
se asigne personal calificado con tiempo para cumplir con sus tareas.
secundarias ni requisitos.
8 Los elementos
extensiones
secundarios
del proyecto.
son parte
Se les
deldebe
trabajo
darcontratado,
plena consideración
no ideas en la
EDT, el cronograma del proyecto y el presupuesto.
Traspaso y ajustes negociados
En muchos proyectos, el contratista recibe el pago de solo una parte del costo total del
proyecto, digamos del 80 al 90 por ciento, y el resto depende del desempeño del artículo
final, el cumplimiento del contratista con los acuerdos contractuales o la calidad del
9
relación laboral con el contratista.
Estas contingencias de pago final se consideran problemas posteriores a la aceptación
porque ocurren después de que el cliente haya aceptado el artículo final principal. Si el
artículo final entregado es satisfactorio pero no cumple con las especificaciones
contratadas, si se encuentra defectuoso después de un período de prueba debido a
deficiencias en el diseño o la producción, o si se entrega tarde, es posible que el
contratista deba pagar una compensación negociada. al cliente.
La aprobación del contrato también puede depender de qué tan bien funcione el
producto después de la instalación o la entrega, y el contratista podría estar obligado a
brindar soporte al usuario en el sitio, sin cargo adicional, para eliminar cualquier
deficiencia operativa.
A veces, el cliente o el contratista busca negociar aspectos del precio del contrato o la
fecha de finalización una vez finalizado el proyecto. El gobierno de EE. UU. se reserva el
derecho de negociar tarifas generales después de recibir el precio final de los contratos
de costo adicional. Del mismo modo, un contratista a veces busca negociar una fecha de
finalización revisada en el contrato después de que se completa el proyecto, generalmente
porque excedió la fecha programada y quiere salvar su reputación.
Cabe señalar que la discusión anterior se aplica a los contratos entre el contratista y
los subcontratistas, así como al contrato entre el cliente y
el contratista.
12.7 Evaluación resumida del proyecto
Una de las actividades finales del equipo del proyecto después del cierre del proyecto es realizar una
evaluación formal. Esta evaluación resumida final brinda a la dirección del proyecto y de la empresa
la oportunidad de aprender de sus aciertos y errores en el proyecto. Sin una revisión resumida, hay
una tendencia a suprimir mentalmente los problemas encontrados y subestimar el impacto de los
errores o juicios erróneos.
(“Las cosas no estaban realmente tan mal, ¿verdad?”) La evaluación del resumen del proyecto revisa
y evalúa el desempeño del equipo del proyecto y el sistema de elementos finales. Su propósito es
identificar y evaluar lo que se hizo y lo que queda por hacer, no para encontrar fallas o culpar. Dos
formas de evaluación resumida son la revisión del proyecto posterior a la finalización y la revisión del
sistema posterior a la instalación.
Revisión del proyecto posterior a la finalización
La revisión del proyecto posterior a la finalización (perversamente también llamada post mórtem) es
una revisión y evaluación resumida del proyecto realizada por el contratista inmediatamente después
del cierre del proyecto, lo suficientemente temprano para que los miembros del equipo del proyecto
10 Es un
todavía estén presentes, disponibles para participar y recordar lo que sucedió. tarea importante para
la cual se deben incluir fondos y tiempo en el presupuesto y cronograma del proyecto. Las revisiones
posteriores a la finalización son una forma en que las empresas intentan mejorar continuamente los
proyectos futuros a través de las lecciones aprendidas de proyectos anteriores, una oportunidad que
muchas empresas desaprovechan.
La revisión posterior a la finalización del proyecto debe revisar:
1. Objetivos iniciales del proyecto en términos de desempeño técnico, cronograma y costo; y

la solidez de los objetivos dadas las necesidades y el problema que el sistema debería
haber resuelto.
2. Cambios en los objetivos y motivos de los cambios, indicando qué cambios
eran evitables y cuáles no.
3. Las actividades y relaciones del equipo del proyecto a lo largo del ciclo de vida del proyecto,
incluida la eficacia de la gestión del proyecto; relaciones
entre la alta dirección, el equipo del proyecto, la organización funcional y el cliente; y

reacciones y satisfacción de los clientes.
4. La participación y el desempeño de todas las partes interesadas, incluidos los
subcontratistas y proveedores, el cliente y los grupos de apoyo externos.
5. Gastos, fuentes de costos y rentabilidad.
6. Áreas del proyecto donde el desempeño fue particularmente bueno, señalando las razones
del éxito e identificando los procesos que funcionaron bien.
7. Problemas, errores, descuidos y áreas de bajo desempeño, y la
causas
8. Una lista de lecciones aprendidas y recomendaciones para incorporarlas

en proyectos futuros.
La revisión ocurre en una reunión de medio día o de un día completo con representantes de todas
las áreas funcionales que contribuyeron sustancialmente al proyecto. Para fomentar la apertura y
la franqueza, los gerentes de estas áreas no deben estar en la reunión.
Se puede seleccionar un facilitador externo para guiar la revisión y garantizar que sea integral e
imparcial. En la reunión, los participantes notan de forma independiente las cosas que salieron bien
y mal con el proyecto; luego comparten sus notas y crean listas de lecciones aprendidas y
recomendaciones para proyectos futuros. Luego, las listas completas se presentan formalmente a
las partes interesadas, a otros miembros del equipo del proyecto y a los gerentes de proyectos,
funcionales y senior.
La revisión busca determinar lecciones que puedan aplicarse a proyectos futuros, no criticar o
culpabilizar. Sus resultados se documentan en un informe de resumen del proyecto, que se
convierte en el documento autorizado del proyecto. El informe resumido describe el proyecto, su
evolución y el resultado. Describe el plan del proyecto, dónde funcionó y dónde falló. Debido a que
los proyectos afectan a diferentes partes de diferentes maneras, las opiniones del cliente, el equipo
del proyecto y la alta dirección deben enumerarse por separado.
El informe de resumen del proyecto se convierte en la referencia para las preguntas relacionadas
con el proyecto que puedan surgir más adelante. La minuciosidad y la claridad son esenciales ya
que las personas que trabajaron en el proyecto generalmente no estarán disponibles más tarde
para responder preguntas. El informe se conserva en una biblioteca de proyectos, y sus lecciones
aprendidas y recomendaciones se promueven en otros proyectos, a veces por la PMO. Las
revisiones y resúmenes posteriores a la finalización son formas de capturar y volver a aplicar el conocimiento.
a proyectos futuros: herramientas para la gestión del conocimiento del proyecto, discutidas en el Capítulo
17
Ver Capítulo 17
11
Ejemplo 12.3: Autopsias de Microsoft
Los proyectos de desarrollo de productos en Microsoft a menudo concluyen con un informe post
mórtem escrito que se distribuye a los miembros del equipo, los altos ejecutivos y los directores de
desarrollo, codificación y pruebas de productos, y a los niveles más altos de gestión, que para
proyectos importantes incluye al presidente de la empresa. . La preparación de un informe puede
requerir hasta 6 meses y puede variar de menos de 10 páginas a más de 100 páginas. Su propósito
es describir lo que funcionó bien en el proyecto, lo que no funcionó y lo que podría hacerse para
mejorar proyectos futuros. También se incluye información descriptiva, como el tamaño del equipo
del proyecto, la duración del proyecto, aspectos del producto (tamaño en miles de líneas de código
[KLOC], lenguajes y plataforma utilizados), problemas de calidad (número de errores por KLOC,
tipo y gravedad de los errores), programar el rendimiento (fechas reales versus planificadas) y el
proceso de desarrollo (herramientas utilizadas, interdependencias con otros grupos). Los gerentes
funcionales preparan el borrador inicial y luego lo distribuyen por correo electrónico a otros
miembros del equipo para que comenten.
Revisión del sistema posterior a la instalación
La revisión posterior a la finalización del proyecto se centró en el proyecto. Algunos meses después de
su entrega, el elemento final o el sistema también deben evaluarse para evaluar su desempeño en el
entorno del usuario y en condiciones operativas continuas.
Esta revisión del sistema posterior a la instalación se enfoca en el sistema del elemento final y sirve para
una variedad de propósitos, como proporcionar información de operación y mantenimiento para los
diseñadores del sistema y revelar posibles mejoras necesarias para el
usuarios del sistema. Basándose en los requisitos originales del usuario, la revisión del sistema
posterior a la instalación intenta responder a las preguntas: Ahora que el sistema está
completamente operativo, ¿está haciendo lo que estaba destinado a hacer? ¿El usuario obtiene
los beneficios esperados? ¿Qué cambios, si los hay, son necesarios para que el sistema satisfaga
mejor las necesidades de los usuarios?
Es importante que el sistema evaluado no se altere con el entregado.

Frecuentemente el usuario realiza modificaciones y mejoras al sistema después de la instalación;
aunque no tiene nada de malo en sí mismo, el sistema está física o funcionalmente diferente al
que se entregó o instaló, hecho que debe ser considerado al momento de evaluar su desempeño.
Durante el curso de la revisión, el equipo de evaluación podría descubrir elementos del sistema
que necesitan reparación o modificación. Las fallas de diseño, los problemas operativos o las
mejoras necesarias que no se pudieron haber previsto antes a veces se vuelven evidentes solo
después de que el sistema ha estado en funcionamiento de rutina.
Los resultados de la revisión se resumen en un informe que describe el rendimiento del
sistema en comparación con sus objetivos, cualquier problema de mantenimiento y posibles
mejoras sugeridas. La revisión del sistema posterior a la instalación y la revisión del resumen del
proyecto se archivan juntas y se conservan como referencias para la planificación de proyectos
futuros.
12.8 Después del Proyecto—Fase D: Operación
Más allá de la terminación del proyecto, lo que sucede a continuación depende de si el

elemento final o entregable es un sistema físico que se debe operar y mantener (por
ejemplo, un producto, una máquina o un procedimiento operativo) o es un servicio para
el cual no hay nada físico para operar ( ej., un concierto de rock, la reubicación de una
empresa, una fusión empresarial o una auditoría). En el primer caso (es decir, el proyecto
da como resultado un sistema o producto físico), el ciclo de desarrollo de sistemas entra
en la fase D, Operación. El contratista puede permanecer involucrado con el cliente y el
sistema en la fase de Operación de dos maneras: (1) aceptando mantener/reparar el
sistema, o (2) iniciando un nuevo proyecto para mejorar o reemplazar el sistema.
Evaluación y mantenimiento del sistema
El contratista puede realizar la evaluación del sistema ya sea como parte del acuerdo del
contrato original o mediante un acuerdo adicional. La evaluación puede ocurrir como la
última actividad programada del contratista en la forma de una revisión posterior a la
instalación, descrita anteriormente, o como un acuerdo extendido para proporcionar
revisión periódica y/o servicio al sistema de forma continua. El acuerdo puede ser un
acuerdo de garantía mediante el cual el contratista revisa y mantiene el sistema durante
un período de tiempo especificado previamente como parte del contrato original, o puede
ser un acuerdo "extendido" que continúa la participación del contratista durante un
período de tiempo más largo. El contratista puede asignar representantes y técnicos del
sistema al sitio del usuario para realizar el mantenimiento preventivo y las actualizaciones
del sistema de forma programada o según lo solicite el
usuario.
Mejorar o reemplazar el sistema
Cuando el cliente quiere ampliar o sustituir el sistema contratado originalmente, surge un

nuevo proyecto; desde la perspectiva del contratista original, esta es una
Ampliación del proyecto original.

Hay dos tipos de prórrogas: discrecionales y esenciales. Las extensiones discrecionales
son solicitadas por el cliente o propuestas por el contratista con el fin de mejorar la
operación, el desempeño o la conveniencia del elemento final original del proyecto. El
entorno sigue siendo el mismo, pero ahora han aparecido nuevas y mejores formas que
pueden mejorar el sistema. Las de otro tipo, las prórrogas esenciales, son obligatorias; sin
ellos el sistema dejará de funcionar o quedará obsoleto. Un artículo final que ya no es
adecuado debido a cambios en el entorno o deficiencias de diseño debe mejorarse o
reemplazarse.
La decisión de expandir, mejorar o reemplazar un sistema marca el comienzo de un
nuevo ciclo de desarrollo de sistemas, que se inicia con una solicitud del usuario (por
ejemplo, una RFP) o una propuesta del contratista. La extensión en sí se convierte en un
nuevo proyecto. La humanidad se involucra en pocos proyectos sin salida; cada uno
estimula a los demás, y el ciclo de desarrollo de sistemas sigue avanzando, de ahí el término "ciclo".
12.9 Resumen
La evaluación de proyectos se basa en una variedad de fuentes y medidas para recopilar y
comunicar información de evaluación, incluidos informes escritos y orales, observaciones y
reuniones de revisión. Las visitas al sitio y las conversaciones individuales son las mejores
fuentes, al igual que las revisiones informales y las reuniones de revisión formales. Las
revisiones informales se llevan a cabo regularmente y son realizadas por miembros del equipo del proyecto.
Las revisiones formales son revisiones o auditorías especiales realizadas en etapas clave o
hitos del proyecto y realizadas por personas externas con experiencia. Proporcionan
evaluaciones independientes del desempeño general del proyecto, sugerencias o instrucciones
para mejorar el proyecto y, a veces, una decisión sobre si continuar o no con el proyecto. Los
tipos de informes y revisiones, y los detalles sobre contenidos, formatos, cronogramas,
participantes y puntos de contacto se especifican en el plan de comunicación del proyecto.
En muchos proyectos, los paquetes de software PMIS realizan funciones de planificación

y control, como programación, gestión de recursos, elaboración de presupuestos, seguimiento,
control de costos y análisis de rendimiento. Muchos utilizan tecnología basada en la web, que
brinda los beneficios de fácil accesibilidad en sitios remotos, facilidad de uso y confiabilidad y
actualidad de la información.
La implementación, la etapa final del ciclo de vida del proyecto, es cuando el sistema del
elemento final u otro entregable se completa y se entrega al usuario. Entre las tareas
importantes durante la implementación se encuentran la capacitación de los usuarios, las
pruebas de aceptación de los usuarios y la instalación y conversión del sistema. El contratista
capacita al usuario para operar, mantener y reparar el sistema, y desarrolla una estrategia
para instalar el sistema en el entorno del usuario; tres estrategias posibles son paralelo, piloto
y pavo frío. El usuario realiza su propio conjunto de pruebas para determinar si el sistema de
artículo final instalado es aceptable o no.
El proyecto finaliza mediante una serie de procedimientos formales supervisados por el
director del proyecto. Después de la finalización del proyecto, se lleva a cabo una revisión del
proyecto posterior a la finalización (post mórtem) para evaluar la eficacia de la organización
del proyecto. Además, una vez que el sistema de artículo final ha estado en funcionamiento,
se realiza una revisión del sistema posterior a la instalación para evaluar su desempeño y
determinar las posibles necesidades de mantenimiento o mejora. Los resultados documentados se

combinan en un informe resumido para proporcionar un documento de referencia para futuros
equipos de proyecto.
1. Describir la diferencia entre evaluación formativa y evaluación resumida en la gestión de

proyectos.
2. ¿Por qué es mejor confiar en una variedad de fuentes de información para la evaluación
en lugar de solo unas pocas? Dé algunos ejemplos de cómo se utilizan varias fuentes en
la evaluación de proyectos.
3. ¿Cuáles son las ventajas y desventajas de las siguientes fuentes de información: (a)
gráficos y tablas, (b) informes orales y escritos, (c) evaluación de primera mano?
4. ¿Cuál es el propósito de las revisiones internas por pares? ¿Cuándo se celebran? Quién
participa?
5. ¿Qué es una revisión crítica formal? ¿Cuándo se lleva a cabo una revisión formal y qué
se mira? ¿Por qué los extraños lo llevan a cabo? ¿Por qué querría un cliente o un
partidario del proyecto una revisión formal?
6. ¿Qué debe incluirse en los informes de estado para la alta dirección?
7. ¿Qué informes debe recibir el director del proyecto? ¿Cómo funciona el proyecto
gerente utiliza estos informes?
8. ¿Qué informes se envían a los gerentes funcionales?
9. ¿Cuándo y qué tipo de informes se envían al cliente? Por que es
informar a los clientes tan importante?
10. ¿Cuál es el papel del PMIS en la gestión de proyectos?
11. Analice las aplicaciones y los beneficios de la gestión de proyectos basada en la web.
12. Discutir los usos del PMIS a lo largo de las fases de la vida del proyecto
ciclo.
13. ¿Cómo se implementa el sistema? Describir las consideraciones importantes.
para entregar el sistema al usuario.
14. Analice la capacitación de los usuarios y por qué a veces se incluye en la etapa de
implementación.
15. ¿Cómo se prueba y verifica el elemento final del proyecto para su aprobación?
16. Describa las diferentes estrategias para instalar o convertir al
nuevo sistema.
17. ¿Cuáles son los motivos de terminación del proyecto? ¿Cómo se puede evitar la terminación por
razones distintas al logro de los objetivos del proyecto?
18. ¿Qué implica la planificación y programación de la finalización del proyecto?
19. ¿Cuál es el papel del gerente del proyecto y del administrador del contrato para recibir la aceptación del
trabajo por parte del cliente y el pago final?
20. ¿Qué son los elementos secundarios? Dé ejemplos que no se usen en este libro. ¿Cómo pueden
retrasar la finalización del proyecto?
21. ¿Qué tipos de ajustes negociados se realizan después de la aceptación del contrato? ¿Por qué querría
un usuario o contratista especificar los términos de un contrato después de que se complete el
proyecto?
22. ¿Qué es una lista de verificación?
23. ¿Qué son las extensiones de proyectos y cómo se originan? ¿Cómo se gestiona la extensión de un
proyecto?
24. ¿Cuáles son las diferencias entre los dos tipos de revisiones resumidas del proyecto: la revisión del
proyecto posterior a la finalización (o post mórtem) y la revisión del sistema posterior a la instalación?
Describa cada uno.
25. Describa lo que sucede durante la fase de operación. ¿Qué papel juega la organización de desarrollo
de sistemas (contratista) en esta fase?

1. ¿Con qué frecuencia y qué tipo de reuniones de revisión se llevaron a cabo en el proyecto?
¿Por qué se celebraron? ¿Quiénes los atendieron?
2. ¿Cuándo y por qué motivo se realizaron revisiones especiales?
3. ¿Cómo se aseguró el seguimiento de las decisiones tomadas durante las reuniones de revisión?
4. ¿Había una sala de reuniones del proyecto? ¿Con qué frecuencia y de qué manera fue
¿usó?
5. Describa los tipos de informes de proyectos que se envían a la alta dirección y al cliente. ¿Quién
emitió estos informes? ¿Qué tipos de informes se enviaron a los gerentes funcionales y de
proyecto? ¿Quién los emitió?
6. Describa el PMIS utilizado en el proyecto. ¿Era el mismo que se usaba para la contabilidad de
costos (PCAS) y la programación de proyectos? ¿Combinó programación, presupuestación,
autorización y control, o se utilizaron varios sistemas diferentes? Si se utilizaron varios sistemas,
¿cómo se integraron?
7. ¿Cuáles fueron los puntos fuertes y débiles del sistema PMIS? ¿El sistema cumplió
adecuadamente con los requerimientos de información para planificar y controlar el proyecto?
¿Alguna de las deficiencias fue culpa de la computadora PMIS o del sistema de soporte manual
que proporcionó entradas y utilizó las salidas? ¿Se utilizó un sistema basado en la web? ¿Qué
mejoras sugeriría para el sistema?
8. ¿Fomentó el director del proyecto la comunicación abierta e informal? Si es así, ¿de qué manera?
9. ¿Cómo terminó el proyecto? Describa las actividades del gerente del proyecto durante la etapa
final del proyecto y los pasos tomados para cerrarlo.
10. Si el artículo final es un edificio u otro artículo “construido”, ¿cómo se entregó al usuario? Describir
el proceso de prueba, aceptación, capacitación y autorización.
11. ¿Cómo se cerró el contrato? ¿Hubo elementos secundarios o

ajustes negociados al contrato?
12. ¿Surgieron proyectos de seguimiento a partir del proyecto que se está investigando?
13. Describa la revisión del resumen posterior al proyecto (informe preparado al final del
proyecto). ¿Quién lo preparó? ¿A quién fue enviado? ¿Cómo se usó?
¿Donde esta ahora? Muestre un ejemplo (o parte de uno).
14. ¿Hubo una revisión posterior a la instalación del producto o resultado del proyecto?
¿Cuándo? ¿Por quién? ¿Qué encontraron? ¿El cliente solicitó la revisión o fue un
procedimiento estándar?
15. ¿Qué pasó con el equipo del proyecto después de que se completó el proyecto?
16. ¿Se mantuvo el contratista involucrado con el cliente y el artículo final?
a través de un acuerdo extendido?
Caso 12.1 Informe de estado del proyecto LOGON
El proyecto Assum LOGON comenzó según lo programado en mayo de 2020. A fines de

septiembre, después de que el proyecto había estado en marcha durante 20 semanas,
Midwest Parcel Distribution (MPD), el cliente, solicitó a Frank Wesley, el gerente del
proyecto, que preparara un informe de estado resumido por escrito sobre Avance hasta la fecha.
Revise los Apéndices A y B al final del libro para conocer los antecedentes del proyecto;
consulte el Apéndice C para obtener información sobre el presupuesto y las fechas
programadas para los hitos y entregables. Prepara el informe como si fueras Frank.
Tenga en cuenta que el informe es para la alta dirección de MPD y debe abordar los
temas de mayor importancia para ellos: entregables y otros requisitos, cronograma y
presupuesto, como se indica en el Apéndice C. El informe también debe señalar cualquier
problema encontrado hasta la fecha, desafíos anticipados y sugerencias recomendadas
o cambios al plan.
Ver Apéndices A, B y C
Caso 12.2 Edificio Central de Información SLU

La construcción del nuevo edificio de la Central de Información en South Land

University (SLU) se completó a tiempo y dentro del presupuesto. Los administradores
de SLU y los gerentes de Finley Construction Company, el contratista principal del
edificio, están muy satisfechos con los resultados. Además de cumplir con los
objetivos de cronograma y costo, el edificio y su equipo, incluida una variedad de
computadoras y dispositivos técnicos destinados a aumentar el aprendizaje,
parecen haber cumplido con todos los requisitos técnicos. Gran parte de la
tecnología es de vanguardia, y SLU está aplicando parte de ella por primera vez en
un entorno de aprendizaje/enseñanza. Por todas las cuentas, el proyecto es un éxito.
Después de revisar y confirmar que se han cumplido todas las obligaciones de
Finley para el proyecto, Jack Krackower, el gerente del proyecto, se reúne con
Sharon Holden, vicepresidente de finanzas de SLU, y Ramat Ghan, vicepresidente
de instalaciones de SLU, para finalizar los detalles de la terminación del proyecto. y pago
La reunión va bien y termina con la discusión de futuros proyectos en SLU y la
posible participación de Finley. Después de la reunión, Jack regresa a su oficina,
después de lo cual el director de la PMO de Finley le pregunta si planea hacer una
revisión del proyecto posterior a la finalización. “No”, bromeó Jack, “no es necesario.
El proyecto fue un éxito y todo salió tal como estaba previsto”.
Unos meses más tarde, Sharon y Ramat dan una presentación final del proyecto
al presidente de SLU, informando que cumplía con todos los requisitos técnicos y
de construcción, el cronograma y el presupuesto. De hecho, dicen, dado el resultado
positivo del proyecto, parte de la nueva tecnología en el edificio debería instalarse
en otros edificios del campus y contratar a Finley para que lo supervise. “No tan
rápido”, dice el presidente. “Escuché informes de que los estudiantes y profesores
encuentran la nueva tecnología confusa, difícil de usar y tal vez irrelevante. De
hecho, algunas habitaciones del edificio están vacías por falta de uso.
Otras salas están abarrotadas, pero los estudiantes van allí para socializar o
relajarse, no para aprovechar ninguna tecnología de aprendizaje sofisticada. No sé
cuál es el problema, si es con la tecnología o con la forma en que Finley lo manejó”.
Preguntas
1. Comente sobre el descuido de Jack de realizar una revisión del proyecto posterior
a la finalización. ¿Es innecesaria una revisión cuando un proyecto se considera
un éxito?
2. ¿Es realmente un éxito el proyecto? ¿Qué tipo de pasos de seguimiento deberían

haber tomado Finley y SLU después de que se completó el proyecto?
Caso 12.3 Comunicación formal e informal
Mientras sale de la oficina del presidente, Philip niega con la cabeza. Estaba claro que la
presidenta estaba un poco avergonzada de no conocer los detalles del sistema de gestión
de configuración de su empresa; parecía aún más avergonzada de tener que cancelar un
acuerdo que hizo anoche en una cena con su contraparte en HeavyEng. “En cierto modo
le sirve a ella”, murmura.
Desde que Philip fue nombrado gerente de compras en TechnoVehicle, han surgido
varios problemas relacionados con la comunicación, especialmente con el desarrollo de un
vehículo que TechnoVehicle ha estado diseñando y para el cual HeavyEng hizo el prototipo
y se está preparando para producir. El producto es un vehículo de extinción de incendios
de última generación encargado por varios aeropuertos.
Philip ha estado preocupado por las reuniones constantes entre los equipos de ingeniería
de las dos empresas y las numerosas modificaciones de diseño a las que aparentemente
ha dado lugar. Sin embargo, también se da cuenta de la necesidad de tales reuniones para
garantizar una fabricación rentable. Y ahora el presidente lo llamó para decirle que ella le
había dicho al presidente de HeavyEng
que TechnoVehicle en el futuro suministrará a HeavyEng copias

electrónicas de los dibujos en lugar de las copias "en papel" que han
estado suministrando. Tuvo que informarle que las copias "impresas"
de los dibujos, no las electrónicas, están bajo control de configuración
y que lo que ella acordó en la cena simplemente no funcionaría.
Después de una hora de dar vueltas en la oficina, llama al asistente
del presidente para solicitar una reunión; la agenda: comunicación
formal e informal. Luego llama al gerente de ingeniería para concertar
una reunión con los dos sobre el mismo tema.
Preguntas
1. ¿Por qué crees que Felipe está molesto por el acuerdo entre los dos
presidentes?
2. ¿Qué similitud hay entre la comunicación entre los dos presidentes y la
comunicación entre los equipos de ingeniería de las dos empresas?
3. ¿Qué mensaje debe transmitir Felipe durante las dos reuniones que ha
programado?
4. ¿Por qué la idea de Philip de reuniones cara a cara con el presidente y
el gerente de ingeniería es bueno?
5. ¿Cuál es una buena regla general con respecto a la comunicación formal
e informal para cualquier proyecto?
Notas finales
1. Véase Turner J. y Muller R. Comunicación y cooperación en proyectos entre el propietario del proyecto como
principio y el director del proyecto como agente, European Management Journal, 22(3): 2004. 327–336.
2. Archibald R. Gestión de programas y proyectos de alta tecnología. Nueva York: John Wiley & Sons, 1976. pág.
191.
3. Se prepararon partes de esta sección con la ayuda de Elisa Denney.
4. Palla R. Introducción a las herramientas de software de microcomputadoras para la gestión de proyectos, Project Management
Diario. Agosto de 1987: 61–68.
5. Ibíd.
6. Véase Archibald R. Managing High-Technology Programs and Projects, págs. 235–236 y 264–270, para una
lista de control completa de las actividades de liquidación.
7. Fetherston D. Chunnel. Nueva York: Libros de tiempo; 1997, págs. 372–375.
8. Hajek V. Gestión de proyectos de ingeniería, 3.ª ed. Nueva York: McGraw-Hill; 1984, págs. 233–240 describe
monitorear y apoyar elementos secundarios para proyectos de hardware de ingeniería y software de computadora.
9. Ibíd., págs. 241–242.
10. Williams T. Revisiones posteriores al proyecto para obtener lecciones aprendidas efectivas. Newton Square, Pensilvania: Proyecto
Instituto de Gestión, 2007; Whitten N. Gestión de proyectos de desarrollo de software, 2ª ed. Nueva York:
John Wiley & Sons, 1995; págs. 343–357.
11. Cusumano M. y Selby R. Microsoft Secrets. Nueva York: Prensa Libre; 1995, págs. 331–334.
Capítulo 13
Gestión ágil de proyectos y Lean
Algunos métodos de gestión de proyectos que se practican en la construcción, la

infraestructura y el desarrollo de productos a gran escala no son adecuados para
proyectos en los que las soluciones o los requisitos finales son inciertos o están sujetos a cambios.
Tal es el caso de los proyectos de desarrollo de software, y en 2001 un grupo de 17
desarrolladores publicaron el informe The Agile Manifesto en el que propusieron los
principios de una forma de gestión más adecuada para el desarrollo de software, a
saber:
Individuos e interacciones sobre procesos y herramientas

Software funcional sobre documentación completa
Colaboración con el cliente sobre negociación de
contratos Responder al cambio sobre seguir un1plan.
Para cada principio de la lista, la implicación es que las cosas de la izquierda (p. ej.,
individuos e interacciones) deben enfatizarse sobre las cosas de la derecha (procesos
y herramientas).
Constantemente surgen prácticas innovadoras en la gestión de proyectos, y el
Manifiesto avalaba algunas que, hasta entonces, se habían aplicado de forma limitada.
Acompañando al Manifiesto estaba el surgimiento del "desarrollo de software ágil", que
fue el precursor de la gestión ágil de proyectos (APM) y prácticas particulares.
como Scrum, que se describen en este capítulo. APM es una forma de metodología de gestión
de proyectos, que se cubre más ampliamente en el Capítulo 17.
Ver Capítulo 17
Lean, abreviatura de producción ajustada, se refiere al Sistema de producción de Toyota,

el sistema de gestión que ayudó a impulsar a Toyota a la vanguardia de la industria automotriz.
Los creadores de The Agile Manifesto se inspiraron en los principios Lean de Toyota (mejora
continua, eliminación de desperdicios y respeto por las personas 2), por lo que no es una
coincidencia que APM y Lean se superpongan un poco. Pero, como se analiza en este
capítulo, las aplicaciones lean se extienden más allá de los proyectos de software y se han
afianzado en otros lugares, especialmente en los proyectos de desarrollo de3 productos.
13.1 Gestión de Proyectos Tradicional

Todos los proyectos pueden conceptualizarse en términos de las fases del ciclo de vida de
Concepción, Definición y Ejecución, aunque exactamente lo que sucede en cada fase
depende del tipo de proyecto y, en particular, de qué tan claro, completo o bien entendido
sea el problema. /necesidad, objetivos y solución/elemento final del proyecto.
Cuando estos se entienden bien, el proyecto avanza fácilmente a través de las fases: los
objetivos y la solución/elemento final se establecen en Concepción; los requisitos y el plan
del proyecto se redactan en la Definición; y el trabajo hacia las metas/requisitos se lleva a
cabo en Ejecución. Pero en muchos proyectos la solución/elemento final no es seguro, y
tampoco lo son los requisitos. Dichos proyectos no pueden moverse “fácilmente” a través de
las fases, y administrarlos requiere desviarse de los métodos de administración de proyectos
tradicionales como se describe en capítulos anteriores.
Figura 13.1 Metodología TPM: se aplica cuando el problema/los objetivos y la solución/elemento final pueden estar bien definidos.
La metodología tradicional de gestión de proyectos, o TPM, la llamada metodología en

cascada, se aplica a proyectos en los que el problema/objetivo y la solución/elemento final
se entienden bien y se pueden definir al principio del proyecto.
Cada una de las fases de definición y ejecución ocurre solo una vez: los requisitos de la
solución/elemento final y el plan del proyecto se establecen claramente en la definición, y el
trabajo se ejecuta de conformidad con el plan en ejecución (Figura 13.1). Los proyectos
TPM son proyectos impulsados por planes; ejecución significa, simplemente, “ejecutar el plan”.
TPM incremental
Figura 13.2 TPM incremental: se aplica cuando el problema/los objetivos y la solución/elemento final están bien definidos y el
el artículo final debe construirse/lanzarse en incrementos.
Una variante de este enfoque permite implementar (o lanzar) el artículo final en una serie
de incrementos. Con el "TPM incremental", el artículo final se implementa paso a paso,
pieza por pieza, lo que permite que algunos elementos comiencen a usarse antes de que
se complete todo el artículo final (Figura 13.2). Los pisos inferiores de un edificio, por
ejemplo, están terminados y ocupados aunque los pisos superiores aún se están
construyendo. Las decisiones sobre cuándo se construirán e implementarán los incrementos
se basan en las dependencias entre ellos (qué piezas deben preceder a otras). y
consideraciones de mercado o financieras. Además de permitir que el cliente comience a
usar partes del artículo final antes, el TPM incremental brinda oportunidades para
experimentar y aprender sobre el sistema del artículo final e identificar los cambios o
mejoras necesarios. Pero TPM incremental sigue siendo TPM: asume que la solución se
entiende bien y se define claramente al principio del proyecto; la única diferencia es que el
artículo final se demarca en elementos discretos que se implementarán en una serie de
pasos, por ejemplo, con 6 semanas o 6 meses de diferencia.
Uso inapropiado de TPM

Cuando la solución no se puede identificar claramente o es incierta (por ejemplo, desarrollo
de una nueva tecnología o producto revolucionario), entonces los requisitos del artículo final
no se puede definir completamente y el proyecto no se puede planificar completamente. En

cambio, tanto los requisitos como el plan deberán desarrollarse con el tiempo, a medida que
las cosas se entiendan mejor. La consecuencia de esto es que los requisitos y el plan se
expandirán y cambiarán, quizás con frecuencia. El proceso de control de cambios descrito
en el Capítulo 11 no es adecuado para este tipo de cambio continuo y tiende a extender la
duración del proyecto, aumentar los costos y, a menudo, producir resultados mediocres o de
mala calidad.
Ver Capítulo 11
La incapacidad para definir un problema o solución no debe confundirse con ignorancia.

Quizás se sepa poco, pero por lo general se sabe algo , y eso puede ser suficiente para
iniciar un proyecto. A diferencia de TPM, en el que gran parte del plan se completa al
principio del proyecto (o, para proyectos largos, se planifica a un alto nivel y se agregan los
detalles más adelante), una alternativa es reconocer que se sabe relativamente poco y
utilizar el proyecto como vehículo . aprender más. En lugar de implementar una solución
conocida, el enfoque del proyecto es aprender cuál debería ser la solución; en lugar de pasar
por las fases de definición y ejecución una vez, el proyecto las recorre iterativamente en un
estilo de aprendizaje sobre la marcha. En resumen, todos los proyectos comienzan con el
inicio y terminan con el cierre, pero si las fases/etapas intermedias suceden una o varias
veces depende de la certeza de cuál debe ser la solución/elemento final.
13.2 Gestión Ágil de Proyectos, APM
Las metodologías de gestión de proyectos que se adaptan a la incertidumbre de una

manera iterativa y de aprendizaje sobre la marcha se conocen como Gestión ágil de
proyectos, APM. En los proyectos de APM, el cliente/desarrollador no sabe o no tiene
clara la solución deseada y no puede definir los requisitos del artículo final por adelantado.
Por lo tanto, el objetivo principal de la fase de definición en APM es identificar, lo mejor
posible, los deseos y necesidades del cliente y crear un plan de alto nivel para abordar
esas necesidades. Los requisitos y características reales del artículo final se desarrollarán
más adelante en una serie de iteraciones. El plan de alto nivel especifica el número
anticipado, la duración y los objetivos de las iteraciones.
Aprendiendo de iteraciones
Las iteraciones ocurren en la fase de ejecución (Figura 13.3). Cada iteración conduce a
descubrimientos y requisitos mejor definidos; cada uno concluye con un “incremento” de
liberación o artículo final: una solución parcial que aborda las necesidades o el problema
del cliente, pero de manera limitada. La planificación se realiza justo a tiempo: en cada
iteración, el cliente y el equipo evalúan el progreso realizado hasta el momento y planifican
las próximas iteraciones. Por lo tanto, en cada iteración incluye no solo las etapas de
ejecución típicas de diseño, construcción y prueba, sino también aspectos de la etapa de
definición: definición de requisitos y planificación del proyecto. El énfasis en la planificación
y ejecución está en la creatividad y la entrega de una solución de valor. Los presupuestos
y los horarios son de menor o poca importancia.
Para facilitar el aprendizaje y el descubrimiento, las iteraciones tienden a ser cortas,
en algunos casos solo de 2 a 4 semanas cada una, en otros casos de varios meses. Se
evalúa el resultado de cada incremento: ¿Proporciona los beneficios esperados? ¿Es útil
y usable? ¿Qué le falta o qué tiene de malo? Esto permite al desarrollador mejorar las
versiones subsiguientes para que, al finalizar el proyecto, los incrementos acumulativos
habrán satisfecho total o sustancialmente las necesidades del cliente y
quiere.
Figura 13.3 APM: se aplica cuando el problema/los objetivos están bien definidos, pero la solución está mal definida.
Variantes de APM4
APM viene en varias formas y la que se usa depende de lo que se sabe sobre el
artículo final/solución. Por ejemplo, ¿sabemos la gama de diferentes soluciones
posibles disponibles pero no cuál es la mejor para elegir? ¿Conocemos la mejor
solución, pero no los detalles al respecto? ¿O simplemente no conocemos la solución,
ni siquiera el problema?
Tomemos el segundo caso: se conoce la solución pero no los detalles. En ese caso,
la fase de ejecución se repite iterativamente, como se describe, y el propósito de cada
iteración es descubrir e integrar características y funciones recientemente identificadas
en la solución/elemento final. Es posible que el proyecto no tenga una fecha límite y
continúe hasta que el cliente esté satisfecho o se agote el presupuesto. El cliente
participa durante todo el proyecto, evalúa los cambios/adiciones a la solución y
proporciona comentarios al equipo de desarrollo. El modelo en espiral es un ejemplo.
Ejemplo 13.1: El modelo espiral
Con el modelo en espiral, el artículo o producto final se lanza en una serie de

ciclos múltiples, y cada ciclo dura de unos pocos a varios meses. 5 También
llamado “prototipo iterativo”, cada ciclo incluye las etapas habituales de análisis,
diseño, desarrollo, prueba, integración, etc., y da como resultado un prototipo. La inicial
ciclo entrega, con optimismo, un prototipo de producto, que el cliente utiliza y

evalúa. El proceso se repite, y cada ciclo entrega una versión prototipo
mejorada basada en los comentarios de los clientes de versiones anteriores
(Figura 13.4). Después de varios ciclos, ya sea un número predeterminado o
siempre que el cliente esté completamente satisfecho, se lanza la versión
operativa o de "producción" del artículo final.
El modelo en espiral se aplica más comúnmente para mejorar sucesivamente
un prototipo que conduce a un producto final, pero también se puede aplicar
para mejorar sucesivamente un producto final. Un ejemplo es un producto de
software o una porción de software de hardware donde cada pocos meses o
anualmente se lanza una versión actualizada o mejorada del producto. Esta
“espiral hacia afuera” del desarrollo del producto (Figura 13.4) continúa
mientras el producto siga siendo “mejorable” y viable en el mercado.
Figura 13.4 Metodología de desarrollo en espiral.
Hay una gran diferencia entre APM (incluido el modelo en espiral) y

TPM incremental. Con TPM incremental, que se aplica a todo tipo de artículos finales,
incluidos los únicos (estación espacial, portaaviones, rascacielos, autopista), no se
espera que el artículo final "evolucione". Aunque partes o elementos del artículo final
pueden evolucionar, el artículo final general no lo hace; su estructura/composición
fundamental se fija al inicio del proyecto.
Además, la solución/elemento final general y los elementos que se agregarán
gradualmente se conocen y definen en gran medida al principio del proyecto.
Con APM, los detalles de la solución y el sistema del elemento final evolucionan y
se expanden con cada iteración, lo cual es necesario ya que gran parte de la solución
es incierta y el propósito de las iteraciones es descubrir y definir los detalles. Cada
iteración comienza con una comprensión limitada de algún aspecto de la solución y se
basa en el conocimiento de las versiones de iteraciones anteriores. El proceso converge
iterativamente en una solución completa.
Los productos modernos son una combinación de hardware y software. Por lo
general, el hardware debe desarrollarse utilizando el enfoque TPM, aunque el software
podría utilizar de forma más adecuada un enfoque APM. Un desafío en la gestión de
proyectos de desarrollo de hardware y software es coordinar las iteraciones para que
el software necesario esté disponible para integrarse con el hardware que se produce
de forma tradicional en cascada. 6 Por lo general, la duración de cada iteración en
APM corresponde a cuánto se sabe sobre la solución: cuanto menos se sabe, más
corta es la duración. Cuando la solución es bastante conocida, las iteraciones pueden
durar varios meses; esto es común en proyectos de modelos en espiral. Cuando sea
menos conocido, deberán ser más breves; en. En el popular método Scrum de APM,
cada iteración dura solo unas semanas.
13.3 Scrum7
El proceso Scrum se muestra en la Figura 13.5. El enfoque de Scrum (el término Scrum
derivado de una faceta del fútbol de rugby) es crear un producto de software con las
funciones y características "deseadas". Pero inicialmente, las funciones y características
son desconocidas, por lo que el proceso comienza con una lista de necesidades y deseos
del cliente llamada "registro de productos". El backlog, que es creado por el cliente o un
representante llamado "propietario del producto", generalmente consiste en una lista de
historias que describen cómo un usuario podría usar o beneficiarse del producto.
Justo antes de cada iteración, denominada "sprint", el equipo de desarrollo y el
propietario del producto revisan el backlog del producto y seleccionan algunos elementos
en los que enfocar el siguiente sprint; estos elementos constituyen el "retraso del sprint".
El equipo acuerda la funcionalidad que debe crear para abordar esos elementos y que se
ajustará a la fecha límite del sprint o "recuadro de tiempo" de, por lo general, 2 a 4
semanas. Durante el sprint, el equipo se reúne brevemente cada mañana para revisar el
progreso y determinar las tareas del día. Al final del sprint, el equipo lanza un "producto
potencialmente entregable" (PSP); también revisa el desempeño de su trabajo para
aprender lecciones para sprints posteriores.
Figura 13.5 Proceso Scrum.
Fuente: Adaptado de Schwaber K. y Beedle M. Desarrollo de software ágil con Scrum. Sillín superior
River, Nueva Jersey: Prentice Hall; 2002.
Funciones de Scrum 8
En Scrum, las responsabilidades de gestión se comparten entre otros roles: maestro de

scrum (SM), propietario del producto (PO) y equipo del proyecto. No hay un gerente de
proyecto, por lo que un gerente de proyecto "tradicional" en una organización Scrum debe
cambiar roles: si es buena facilitando, podría ser el SM; si tiene conocimientos sobre los
clientes y el negocio, podría ser la OP; si le gusta ser práctica y estar en medio de las
cosas, podría ser un miembro del equipo.
Maestro Scrum
El SM es responsable de facilitar la colaboración del equipo y mantener al equipo enfocado

en el proyecto. El SM trabaja a tiempo completo en el proyecto y se desempeña como
entrenador, asesor, ejecutor de las reglas de Scrum y, en ocasiones, administrador. A
diferencia de un gerente de proyecto, no toma decisiones por el equipo. Puede decirles a
las personas lo que deben hacer y ayudar a capacitarlas o facilitarlas, pero no puede
decirles cómo deben hacerlo. El SM debe estar familiarizado con la organización y saber
cómo obtener los recursos necesarios y eliminar las barreras.
Dueño del producto
El PO es responsable de garantizar que el equipo sepa en qué consiste o podría

evolucionar el producto y quiénes son los clientes y competidores. El PO establece la
"visión" del artículo/producto final (cómo debe funcionar, cuándo debe completarse, cuánto
debe costar) y sigue recordándoselo al equipo actualizando con frecuencia la acumulación
del producto y discutiendo la acumulación con el equipo.
La OP representa al “cliente” y, por lo tanto, debe comprender a fondo a los clientes y
usuarios, el negocio o el mercado. ella debe ser buena en
comunicarse y escuchar a los clientes, usuarios y al equipo. En Scrum, el PO es quien toma las decisiones
con respecto a los asuntos del producto y los problemas relacionados con el producto que enfrenta el
equipo y, por lo tanto, debe tener autoridad para tomar decisiones en la organización.
El SM y el PO no deben ser la misma persona. Debe existir una tensión entre los roles: el PO presiona
por más en el producto, pero el SM retrocede cada vez que siente que el PO está pidiendo demasiado del
equipo.
Grupo de proyecto
El equipo comprende todo lo que requiere el proyecto: analistas, programadores, evaluadores, etc. Los
miembros trabajan principalmente en sus especialidades, pero contribuyen a todas las demás
especialidades. Las asignaciones de trabajo son tentativas porque se espera que los miembros brinden
asistencia donde sea necesario. Si un miembro termina su tarea antes de tiempo, se espera que comience
una nueva o que también ayude a otros, independientemente de su especialidad. Dice Cohen, en Scrum
no hay “mi trabajo” y “tu trabajo”; sólo existe “nuestro trabajo”. 9 A través de la rotación y el intercambio de
roles (lo que ocurre de manera similar en la ingeniería concurrente, discutida en los Capítulos 4 y 14), los
miembros desarrollan una comprensión de cada tarea en el proyecto. Todo el mundo es capaz de
hacer y hace un poco de todo.
Dado que todos participan en todas las tareas, saben lo que se ha hecho y lo que queda por hacer. Esto
reduce la necesidad de documentación formal y "entrega" de trabajo (tiempo de inactividad por esperar a
otros).
Estructura de equipo
Los equipos Scrum son pequeños, típicamente de cinco a diez personas; Amazon los llama equipos de
"dos pizzas", lo que ofrece ventajas: pueden centrarse mejor en los objetivos del proyecto y disfrutan de
una mayor interacción, participación y satisfacción entre los miembros. También tienden a terminar los
proyectos con menos esfuerzo total y en menos tiempo.
Un equipo Scrum es autoorganizado y autogestionado. Decide por sí mismo cómo logrará los
objetivos y dividirá y controlará el trabajo. Sin embargo, aún es necesaria cierta gestión externa
para establecer objetivos y límites a nivel de proyecto y eliminar barreras de alto nivel.
Los sprints son rápidos y enfatizan el aprendizaje rápido, por lo que la comunicación en tiempo
real entre los miembros del equipo es esencial. En consecuencia, los miembros del equipo suelen
trabajar a tiempo completo en un proyecto y en el mismo lugar. Pero Scrum también se ha aplicado
con éxito en proyectos en los que los miembros están distribuidos por todo el mundo y dependen
de Internet y la tecnología para mantenerse en contacto. En proyectos grandes, el trabajo se
10
distribuye entre muchos equipos Scrum de dos pizzas.
Pila de Producto
Scrum sustituye la definición inicial y todo a la vez en un solo punto con una definición paso a paso
repartida en múltiples sprints. Las necesidades y los deseos de los clientes que se enumeran en la
cartera de productos están mínimamente definidos, inicialmente en forma de "historias de usuarios"
o "epopeyas", y se refinan y amplían con el tiempo. Dado que inicialmente se desconocen las
funciones/características deseadas y otros detalles del producto, es más práctico definir el producto
en términos de historias que de requisitos específicos. Cada historia es una declaración simple
desde la perspectiva del usuario sobre el uso potencial, la funcionalidad o la capacidad de un
producto, generalmente escrita en una tarjeta de 3 × 5 o en una nota adhesiva y en el formato
"Como <tipo de usuario>, quiero <algún objetivo". > porque <alguna razón>.” El enfoque de cada
sprint es satisfacer algunas historias de usuarios. Una historia de usuario que tiene múltiples
objetivos y es demasiado grande para ser abordada en un sprint se llama épica. Eventualmente,
las épicas deben dividirse en historias de usuario más simples que puedan manejarse en un sprint.
Las historias y características en una cartera de productos se pueden escribir en diferentes

niveles de detalle. Las historias que son específicas, bien entendidas y que se pueden abordar en
un solo sprint se colocan en la parte superior de la cartera de pedidos. Las historias que son más
amplias y menos comprendidas se ubican más abajo. Las epopeyas empiezan con poco trabajo
atrasado; a medida que avanza el proyecto, se dividen en historias de usuario y se mueven hacia
arriba. El PO mantiene el trabajo pendiente: agregar, eliminar y volver a priorizar elementos.
En Scrum, el énfasis en la definición del sistema cambia de la documentación a la
discusión. Antes de cada sprint, el equipo discute las historias en la cartera de pedidos con el
PO y elige las que entiende mejor y quiere atacar en el próximo sprint; estos forman el sprint
backlog.
Para cada historia seleccionada, el equipo y el PO definen “condiciones de satisfacción”
(COS), que indican lo que el usuario espera y no espera. El COS y las historias de usuario
constituyen la única "documentación de requisitos" para un sprint. Cuando el producto debe
cumplir con las leyes reglamentarias o realizar cálculos complejos, los requisitos se especifican
en términos de ejemplos realistas que ilustran lo que el producto debe ser capaz de hacer.
Sprints
El objetivo de cada sprint es entregar un producto que funcione, generalmente software. Este
producto se denomina "producto mínimo viable" o "producto potencialmente transportable":
PSP. Aunque no es un producto o una solución completos, y no necesariamente sin errores,
el PSP cumple con todos los requisitos establecidos por el PO (p. ej., el COS) y el equipo del
proyecto (p. ej., finalización de todas las etapas de desarrollo) y es un producto de trabajo
independiente. Con cada PSP, el cliente obtiene un producto utilizable y el equipo recibe
comentarios sobre lo que ha hecho hasta ahora con el producto y cuánto le queda por hacer.
Incluso si el proyecto finaliza a mitad de camino, el cliente se beneficia de los PSP entregados
hasta el momento.
Dentro de cada sprint, se realizan todas las etapas para producir un PSP (análisis de
código-prueba-comprobación), sin embargo, se superponen y se realizan en "trozos": un
pequeño análisis, un poco de codificación y un poco de prueba en una función, luego un
pequeño análisis de codificación-prueba en otro, y así sucesivamente. El credo es: “Haz un
poco de todo, todo el tiempo”. En cualquier momento dado, diferentes funciones se encuentran
en diferentes etapas de desarrollo: análisis, codificación, prueba, etc.; por eso, las personas
del equipo deben ser capaces de hacer cualquier cosa cuando sea necesario.
Como se mencionó, la duración del sprint es fija o está limitada en el tiempo, generalmente
de 2 a 4 semanas, según el tiempo que desee el equipo. Timeboxing simplifica la planificación
y la estimación, ya que el equipo aprende cuánto puede hacer en cada sprint (ritmo de trabajo)
y puede monitorear su tasa de producción. Conociendo su ritmo de trabajo, el equipo
selecciona historias de usuario para cada sprint backlog que cree que es capaz de lograr durante el
caja de tiempo. La duración de la caja de tiempo se mantiene constante a lo largo del

proyecto; está estrictamente reforzado y rara vez se permiten horas extras. Un proyecto
típico involucra muchos sprints y los equipos son más efectivos cuando trabajan a un ritmo
de trabajo uniforme y sostenible. Si el equipo no puede terminar todo el trabajo pendiente
del sprint, el PO decide qué elementos descartar y recoger en sprints posteriores.
Una vez que un sprint está en marcha, el PO se hace a un lado pero siempre está
disponible cuando el equipo lo solicita.
Incrementos de sprint frente a versiones de producción
Cada sprint produce un nuevo incremento de artículo final o PSP, pero rara vez los clientes
pueden absorber cambios tan frecuentes en sus entornos operativos o de producción. Lo
más probable es que el cliente pueda implementar una versión revisada de "producción" u
operada por el usuario solo unas pocas veces al año, aunque esa versión incorporará los
descubrimientos y mejoras acumulativos de todos los incrementos de sprint lanzados hasta
ese momento. Mientras tanto, para que el equipo de desarrollo pueda recibir comentarios
prácticos frecuentes, un grupo de enfoque de unas diez personas que representan al cliente
y los usuarios clave revisan y critican los incrementos o PSP publicados para cada sprint.
Esto proporciona al equipo información útil sobre los cambios y mejoras necesarios para
abordar en los próximos sprints. Después de, digamos, seis sprints o seis meses, las
mejoras acumuladas se incorporan a la versión de producción.
Los planes Scrum se desarrollan progresivamente. Se prepara un plan al principio del

proyecto, pero contiene solo los fundamentos de la solución/artículo final y tiene pocos detalles.
Cualquier compromiso especificado permite una amplia libertad para el cambio. El proceso
de planificación es similar al enfoque gradual descrito en el Capítulo 4, con la diferencia de
que el "objetivo" y sus requisitos asociados en proyectos ágiles están algo en movimiento y
el camino para alcanzarlos es menos claro.
Ver Capítulo 4
A medida que el conocimiento del equipo se expande durante el proyecto, también lo hacen
los detalles del plan. Este refinamiento progresivo del plan tiene muchos beneficios: evita
planificar cosas que son desconocidas o inciertas; difiere las decisiones hasta que haya
información adecuada; y permite margen de maniobra para cambiar de dirección. La
planificación, junto con la revisión y el control del trabajo, ocurre en una serie de reuniones
antes, durante y después de cada sprint.
Reunión de planificación de Sprint
Antes de cada sprint, el equipo dedica de 4 a 8 horas a prepararse para los próximos sprints.
Selecciona las historias de usuario de la cartera de productos para la próxima acumulación de
sprint. Para cada elemento del backlog del sprint, el equipo determina las tareas específicas
que se deben realizar y estima el tiempo; esto le permite al equipo saber que el trabajo que ha
elegido es "realizable" dentro del marco de tiempo del sprint y, más tarde, realizar un
seguimiento de su progreso. El equipo también selecciona historias para los siguientes dos
sprints (por ejemplo, al final del sprint 2, planifica el sprint 3 y crea retrasos para los sprints 4 y 5).
Reunión diaria de Sprint (también conocida como Daily Scrum)
El equipo se reúne cada mañana durante el sprint durante 15 minutos para revisar el progreso
y actualizar la pizarra y el gráfico de trabajo (Ejemplos 13.2 y 13.3 a continuación).
Las reuniones son sensatas y se llevan a cabo a la misma hora y en el mismo lugar. Abordan:
¿Qué hiciste ayer? ¿Qué harás hoy? ¿Estás enfrentando algún obstáculo? Los miembros del
equipo discuten lo que deben hacer y el Scrum master aprende qué barreras debe eliminar.
Seguimiento y Control
Scrum utiliza herramientas visuales simples para rastrear y controlar el trabajo. Los siguientes
son dos ejemplos.
Ejemplo 13.2: Pizarra Blanca 11
Cada trabajo se escribe en una nota adhesiva y se coloca en la sección "Por hacer" de
una pizarra blanca; Pendiente es el primero de un proceso hipotético de cuatro pasos
seguido de En proceso (realizado), Verificar (realizado correctamente) y Listo (Figura 13.6).
Cada trabajo es una tarea que se debe realizar en una historia de usuario en la
acumulación de sprint, por ejemplo, análisis, código, prueba, etc. Los diferentes tipos de
tareas se pueden representar con diferentes notas de color. A medida que avanzan los
trabajos, las notas se mueven de una sección de la pizarra a la siguiente. Suponga que
el equipo de desarrollo ha decidido que no pueden haber más de tres trabajos a la vez
en una sección; es decir, cuando una sección tiene tres notas, no se permiten más.
Restringir los trabajos en cada sección como este, llamado Kanban, evita que el equipo
asuma tareas adicionales antes de que haya completado las tareas existentes y mantiene
el trabajo moviéndose a un ritmo uniforme, llamado velocidad o tiempo de ciclo (discutido más adelante).
Simplemente escaneando la pizarra, el equipo puede ver en cualquier momento qué
trabajos están retrasando el progreso y necesitan recursos adicionales.
Figura 13.6 Tablero blanco para seguimiento y control de tareas de trabajo.
Ejemplo 13.3: Burn Down Chart 12
El progreso en cada sprint también se rastrea con un gráfico de quemado, un

gráfico que muestra el esfuerzo de trabajo restante (trabajo atrasado) en el eje
vertical y los días de sprint en el eje horizontal (Figura 13.7). El esfuerzo de trabajo,
la cantidad de "sudor" que el equipo dedica a un sprint, se puede medir de la forma
que prefiera el equipo: puntos de historia, horas o días de esfuerzo, etc. Durante la
reunión de planificación del sprint, el equipo identifica los trabajos o tareas que
realizará, distribuye los trabajos entre el equipo y asigna "puntos de historia" o puntos estimados.
horas o días de esfuerzo a cada uno. Si se utilizan puntos de historia, el equipo asigna
puntos a cada tarea en proporción al esfuerzo estimado necesario para realizarla (cuanto
más esfuerzo se requiere, más puntos se asignan); si son horas de esfuerzo, el equipo
estima la cantidad de horas de trabajo necesarias para completar cada tarea.
El total de horas estimadas de esfuerzo para todas las tareas debe estar dentro del
timebox: las horas disponibles para el sprint. Por ejemplo, un equipo con seis miembros
que trabajan días nominales de 6 horas (= 36 horas de trabajo por día) durante 4
semanas (20 días) tendrá 720 horas de trabajo de esfuerzo disponibles, por lo que el
trabajo requerido para completar las historias de usuario seleccionadas para el La
acumulación de sprint debe ser factible dentro de esa restricción. De hecho, al
seleccionar historias de la cartera de productos, el equipo lleva un registro continuo de
las horas de esfuerzo involucradas, y no selecciona más historias de las que pueden
"encajar" dentro de las horas de trabajo disponibles. Aunque el equipo ciertamente
trabajará al menos 8 horas al día, al usar solo 6 horas al día en la estimación, está
siendo conservador y, de alguna manera, garantiza que podrá completar la acumulación de sprint.
Siguiendo con el mismo ejemplo, al inicio del sprint el equipo tendrá 720 “horas de
esfuerzo restantes”; si fuera a completar cada tarea exactamente en el tiempo estimado,
entonces cada día las horas de esfuerzo restantes en el gráfico de quemado deberían
disminuir en 36 horas (Figura 13.7).
En realidad, por supuesto, las tareas toman más o menos tiempo de lo estimado.
Cada vez que una tarea lleva menos tiempo y finaliza antes, se inicia una nueva tarea.
Al final del día, cada miembro del equipo registra las tareas que completó y proporciona
una estimación de las horas de esfuerzo que aún le quedan para completar cualquier
tarea en la que aún esté trabajando. Por ejemplo, supongamos que el día 7 un miembro
del equipo comienza la Tarea A, que se estimó en 6 horas, y la termina en solo 3 horas.
Inmediatamente después, comienza la Tarea B y trabaja en ella durante el resto del día.
Supongamos que se estimó que la Tarea B tomaría 8 horas, pero al final del día el
miembro del equipo estima que aún quedan 2 horas de trabajo. (Esto se puede hacer
usando el porcentaje completado. Si una tarea de 8 horas se estima en un 75 por ciento
completada, eso equivale a 0,75 × 8 = 6 horas completadas y 2 horas restantes). Así, al
final del Día 7, considerando solo las Tareas A y B, las horas de esfuerzo restantes en
el gráfico se reducirán en 6 horas (tiempo estimado) para la Tarea A y 6 horas (8
estimadas – 2 restantes) para la Tarea B .
Trabajar más rápido de lo esperado aparece en el gráfico de quemado donde sea
la línea trazada es más inclinada que la línea esperada estimada. En la figura

13.8 , esto sucedió los días 2, 8 y 11.
Si las tareas toman más tiempo de lo esperado, las horas de esfuerzo restantes
disminuirán menos rápidamente de lo estimado, y la pendiente de la gráfica en el
gráfico de quemado será menor que (o al revés) la línea estimada. En otras
palabras, al final del día, aunque el equipo haya trabajado más de 36 horas de
trabajo, si no completó las tareas asignadas para el día, las horas de esfuerzo
restantes se reducirán en menos de 36 horas. .
Por ejemplo, supongamos que un día algunos miembros del equipo no completaron
las tareas asignadas y estiman que para hacerlo requerirán 31 horas más.
Por lo tanto, para ese día, las horas de esfuerzo restantes se reducirán solo 5
horas (36 – 31), no 36 horas como se esperaba. Por supuesto, si al final de un día
las horas restantes estimadas para las tareas que deberían haberse realizado ese
día superan las 36 horas, entonces las horas de esfuerzo restantes en el gráfico
aumentarán. En la figura 13.8 esto ocurre en los días 5 y 7.
Figura 13.7 Gráfico de quemado , rendimiento estimado y esperado.

Figura 13.8 Gráfico de quemado , rendimiento real durante 11 días.
Al monitorear el gráfico, el equipo puede identificar fácilmente problemas con el alcance del
sprint (número y tamaño de las tareas) o el ritmo o la calidad del trabajo, o errores en los tiempos
estimados. También puede medir su progreso diario y si podrá completar la acumulación de
sprints dentro del plazo.
El ritmo de trabajo en Scrum se llama "velocidad". La figura 13.8 muestra aproximadamente
405 horas de esfuerzo restantes al final del día 11. Por lo tanto, el equipo completó 720 ÿ 405 =
315 horas de esfuerzo y su velocidad es:
Esfuerzo completado/días transcurridos = 315 horas/11 días = 28,6 horas de trabajo/día
Si el equipo mantiene esta velocidad, terminará el trabajo restante en 405/28,6 = 14,2 días,
lo que significa que habrá tomado 11 + 14,2 = 25,2 o 26 días para realizar todas las tareas
previstas, y excederá el plazo de 20 días por 6 días.
Cuando un sprint o un proyecto completo se atrasa en el cronograma, es decir, el trabajo planificado

no se puede completar dentro del marco de tiempo, entonces se cambia el alcance del proyecto, no la
calidad, los recursos o el cronograma . Si lo hace, permite que el proyecto cumpla con sus objetivos más
metas importantes sin comprometer la calidad, aumentar los costos o extender los
cronogramas. Si el PO hubiera puesto 50 características en la cartera de productos
priorizada y si 40 de ellas se entregaron en los sprints con límite de tiempo, entonces el
PO habrá obtenido un producto totalmente funcional y operativo con las 40 características
de mayor prioridad, todo dentro del tiempo y dinero asignado
Revisión de Sprint/Reunión retrospectiva
Concluir cada sprint es una reunión de dos partes de un día. En la primera mitad de la
reunión, el equipo revisa el trabajo planificado, completado y no completado, y presenta o
demuestra las partes completadas al PO o al cliente. En la segunda mitad reflexiona sobre
lo que salió bien en el sprint, lo que no tan bien y lo que necesita mejorar en el próximo
sprint.
13.4 Controversia APM

Muchos de los métodos y herramientas de TPM se desarrollaron en la década de 1950 para
abordar proyectos de construcción y sistemas a gran escala y desarrollo de productos, los
tipos de proyectos ilustrados en este libro. Sin embargo, aplicados al desarrollo de software,
los mismos métodos y herramientas condujeron a fallas generalizadas. Simplemente, el
desarrollo de software es diferente a la construcción y el desarrollo de hardware, de ahí el
origen del Manifiesto Ágil y APM.
Proyectos Bits versus Atoms
Pero también funciona a la inversa: los enfoques APM desarrollados para proyectos de
desarrollo de software (los llamados "bits") tienen una aplicabilidad limitada en proyectos de
hardware ("átomos"). Parafraseando a Paul Lohnes:
Cuando se trata de 'pedazos', que no tienen fisicalidad (peso, masa, forma, longitud, altura, etc.), los requisitos se
pueden cambiar fácilmente si el cliente está dispuesto a pagar por el retrabajo. Pero cuando se trata de entregables
13
que involucran "átomos", que tienen fisicalidad, es un asunto diferente.
Por ejemplo, una vez que se ha diseñado una aeronave (un producto de hardware) con un
fuselaje de 18 metros de diámetro, un cambio en los requisitos a 17,5 metros requeriría un
rediseño significativo de muchos de los componentes del fuselaje, un rediseño de los sistemas
y componentes relacionados, e implican una pérdida significativa de tiempo y costos. No se
puede diseñar y construir un avión (o un corazón artificial o un puente) a través de sprints
iterativos. Simplemente, APM no funcionará allí. (Tampoco funcionará en proyectos sujetos a
leyes regulatorias que exijan una definición exhaustiva de los requisitos y la documentación
del proyecto; por ejemplo, desarrollo de productos farmacéuticos).
Sin embargo, puede diseñar y construir parte del software de aviónica del avión, lo que
14
a través de plantea un punto importante. Cada vez más, productos una vez
sprints, considerados como hardware, son en realidad productos de hardware-software, y la
parte de software eclipsa o dicta la parte de hardware. Los teléfonos celulares son un ejemplo,
pero también lo son los aviones, algunos de los cuales pueden volar solo en virtud del
software. Por lo tanto, aunque los métodos de APM pueden limitarse a los elementos finales de software,
Dada la iniquidad del software dentro del hardware, la aplicabilidad de APM es amplia y creciente.
15
APM: ¿Una metodología de gestión de proyectos? dieciséis
Algunos han argumentado que APM no es una metodología de gestión de proyectos per se, sino
una metodología de desarrollo de productos destinada principalmente a la creación de software, no
a la gestión de proyectos. Si bien es cierto que APM se originó y se ha aplicado principalmente en
proyectos de desarrollo de software, creemos que las prácticas para el "desarrollo" (de hardware o
software, y de sistemas en general) se entrelazan lo suficiente con la gestión y el liderazgo para
merecer llamarlos métodos de gestión de proyectos, y lo hemos hecho a lo largo de este libro
(véanse los capítulos 2, 3, 4, 11, 14).
Principios de gestión de proyectos
Con la difusión de las "prácticas ágiles", algunos defensores han prescrito que reemplacen las
prácticas que se originan en TPM, sin importar el tipo de proyecto. Pero el Manifiesto Ágil no
pretendía desacreditar el TPM, y un enfoque razonado de la gestión de proyectos dice que no se
debe reemplazar una metodología o un conjunto de prácticas por otro, sino elegir selectivamente
entre ambos según la naturaleza del proyecto, el producto final. , y las partes interesadas.
Ya sea que los entregables sean bits o átomos, los principios y prácticas asociados con la "buena
gestión de proyectos" siguen siendo los mismos: las diferencias radican en cuándo, dónde y cómo
se aplican. Por ejemplo, siempre es importante definir los requisitos: si se puede hacer temprano y
todo a la vez, debe hacerse de esa manera, como en TPM; cuando no puede, entonces tendrá que
hacerse de forma iterativa y evolutiva, como en APM. De cualquier manera, aprender los requisitos
y esforzarse por cumplirlos es una parte importante de la gestión de proyectos.
El control del proyecto siempre es importante también: TPM utiliza diagramas de Gantt, redes,
valor ganado y métodos formales de control de cambios; APM utiliza iteraciones controladas,
enmarcadas en el tiempo y rastreadas con gráficos de quemado. Los métodos en ambos sirven
para mantener los proyectos a tiempo y avanzar hacia las metas del proyecto.
APM se ha llamado gestión de proyectos "liviana" porque enfatiza
comunicación informal y documentación mínima. Pero APM se aplica a proyectos para los que
las soluciones o los elementos finales son vagos o desconocidos, por lo que no hay mucho
que documentar y crear documentación por sí mismo sería una pérdida de tiempo. APM
reemplaza las funciones de almacenamiento e intercambio de información de la documentación
con algo que funciona mejor: la comunicación cara a cara. Las personas en pequeños equipos
ubicados en el mismo lugar que trabajan en tareas pequeñas en periodos cortos de tiempo
saben casi todo sobre el proyecto que se puede saber, y lo comparten verbalmente. No
necesitan documentación. Pero APM no elimina la necesidad de
documentación: el artículo final aún debe estar documentado por las mismas razones que en
TPM: para permitir que los operadores y los futuros desarrolladores comprendan el artículo
final, su funcionamiento, capacidad y limitaciones.
En resumen, las herramientas y los métodos de APM son apropiados y deseables para los
entregables de software, pero lo son menos o simplemente no funcionarán para algunos
entregables físicos. APM tiene un lugar entre las prácticas de gestión de proyectos, pero
muchos proyectos aún requieren un enfoque más formal y estructurado para la definición y
ejecución. Por lo tanto, sería incorrecto intentar reemplazar TPM con APM; más apropiado
sería considerar APM como una adición a la caja de herramientas del gerente de proyecto.
13.5 Producción ajustada y gestión de proyectos

La producción ajustada se refiere al concepto de hacer el trabajo con la menor cantidad de tiempo,
recursos y esfuerzo sin disminuir la calidad o la producción. Lean equivale a "sin desperdicio",
donde el desperdicio es cualquier cosa que aumente el costo pero no el valor de un producto o
resultado final. Toyota, el creador de la producción ajustada, identificó tipos particulares de
desperdicios. Los más relevantes para los ambientes de proyectos son la sobreproducción
(producción más allá de lo requerido), inventario (mantener materiales en exceso o recursos
innecesarios), procesamiento adicional (realizar más trabajo o con mayor calidad que la necesaria),
esperar (retrasar el trabajo), defectos (incorrectos o inadecuados). trabajo) y movimiento (traspasos
o transferencias innecesarias de trabajo). Un desperdicio adicional es el talento humano no
utilizado, es decir, no aprovechar al máximo las ideas, habilidades y capacidades de los
trabajadores. 17 La producción ajustada enfatiza el “flujo del producto”, el concepto de que
cualquier cosa que se mueva a través de un proceso de múltiples etapas debe fluir sin
obstáculos de una etapa a la siguiente.
En la fabricación, el "flujo" es de materiales que se mueven a través del proceso de producción
para ser transformados o ensamblados en un producto. En los proyectos, el flujo es de información
y secuencias de tareas de trabajo para crear elementos finales conceptuales o físicos. A pesar de
tener su origen en la fabricación, muchos conceptos y prácticas de producción ajustada se aplican
a los proyectos; estos incluyen flujo de lotes pequeños, espera mínima, tiempo de ciclo,
estandarización, transferencias mínimas, gestión visual y Kanban.
No es casualidad que estos conceptos se superpongan con las prácticas de APM, por lo que a
veces se hace referencia a APM como "gestión de proyectos ajustada". Sin embargo, los
conceptos y prácticas lean se pueden encontrar en todo tipo de proyectos, no solo en proyectos
orientados a bits (software) sino también en proyectos orientados a átomos (construcción) y
18
orientados a bits y átomos (desarrollo de productos).
Flujo de lotes pequeños19
Mire un gráfico de Gantt o un diagrama de red; lo que ve son etapas del proyecto o actividades
vinculadas en orden de precedencia. Es posible que vea "Requisitos" seguido
por "Código", Código seguido de "Prueba", Prueba seguida de "Integración", y así

sucesivamente. La implicación es que las etapas se realizan en secuencia. Al finalizar una
etapa, los resultados y el trabajo se transfieren a la siguiente.
Figura 13.9 Proceso de cuatro etapas, trabajo transferido mensualmente al finalizar cada etapa.
En la fabricación, el trabajo que pasa de una etapa a otra como este se denomina
"producción por lotes" y la implicación es que el trabajo se mueve a través del proceso en
lotes. Si el tamaño del lote de trabajo es de 40 elementos, se procesan 40 elementos en cada
etapa y nada pasa a la siguiente etapa hasta que se completan los 40. Cuarenta elementos
pasan a la etapa 1, luego 40 van a la etapa 2 y así sucesivamente. En un proyecto el lote
puede constituir 40 requisitos, 40 módulos codificados, 40 pruebas, 40 dibujos, etc.
La Figura 13.9 muestra cómo funciona esto: al completar la etapa de Requisitos, todos los
requisitos se envían a la etapa de Código; al completar la etapa de Código, todos los módulos
codificados se liberan a la etapa de Prueba. La palabra clave es "finalización": todo el trabajo
en una etapa debe completarse antes de que se publiquen los resultados y pueda comenzar
la siguiente etapa. En una empresa de desarrollo de productos, a veces puede ver que esto
sucede como pilas de papel (requisitos, dibujos, trabajo
órdenes y otros documentos) moviéndose de un departamento a otro. La información digital también se

mueve de esta manera, pero es menos obvia ya que se almacena y transfiere sin ser vista.
El ejemplo de la Figura 13.9 requiere 4 semanas en cada etapa y, por lo tanto, una liberación y
transferencia cada 4 semanas. Pero hay una forma alternativa de hacer esto, que es transferir parte del
trabajo en cada etapa cada semana. Por ejemplo, en lugar de esperar hasta que se completen todos los
requisitos, transfiera los requisitos que se completaron cada semana para que pueda comenzar la siguiente
etapa. 20 La Figura 13.10 ilustra esto, mostrando el flujo de trabajo de una etapa a otra semanalmente.
Podría ser
posible transferir el trabajo con más frecuencia, diariamente o incluso elemento por elemento. La
transferencia de elementos individuales (requisitos, módulos codificados, resultados de pruebas, etc.) entre
etapas uno por uno se denomina "flujo de una pieza", lo que significa que todo se mueve a través del
proyecto en lotes tan pequeños como uno.
Reducir el tamaño del lote de esta manera tiene muchos beneficios.
Duración del proyecto
Con lotes más pequeños, las etapas del proyecto se superponen y el proyecto finaliza antes. En la Figura
13.9 , donde los resultados se transfieren entre etapas cada 4 semanas, el proyecto tarda 16 semanas en
completarse. En la Figura 13.10, donde los resultados se transfieren semanalmente, el proyecto dura 7
semanas.
Figura 13.10 Proceso de cuatro etapas, trabajo transferido semanalmente.
Calidad
Supongamos que un error cometido en los requisitos no se detecta hasta la prueba, que
según la figura 13.9 ocurre 4 o más semanas después de que se completa la etapa de
requisitos. Si el error afectó a los requisitos y la codificación subsiguientes, es posible que
haya que rehacer muchos requisitos y mucho código.
Con los lotes más pequeños de la Figura 13.10, el error se detectará en la etapa de
Prueba menos de 2 semanas después de que se originó en Requisitos. En la semana 3,
algunos requisitos y la mitad de la codificación aún deberán realizarse y el error aún no los
habrá influido. Además, en la semana 3, las etapas de requisitos y código todavía están en
curso, y las personas en esas etapas, que han trabajado recientemente en los requisitos y
el código afectados, podrán identificar más fácilmente la fuente.
del error y corregirlo.
Retroalimentación
El beneficio de calidad de los lotes más pequeños se deriva de la retroalimentación acelerada.

En la Figura 13.9 , las etapas de Requisitos y Código no tienen oportunidad de recibir
retroalimentación de las etapas de Prueba e Integración. Se habrán completado los requisitos
y el Código; la única forma de que esas etapas se beneficien de la información obtenida en
etapas posteriores es reiniciarlas. Las personas que trabajaron en esas etapas anteriores
habrán pasado a otras tareas/proyectos y será difícil recuperarlos. Además, las personas se
olvidan y puede resultarles difícil determinar la naturaleza del error y corregirlo (ver eficiencia,
a continuación).
En todos los proyectos, los requisitos idealmente se concretan lo antes posible;
paradójicamente, la mejor manera de hacerlo, especialmente cuando los requisitos son
inciertos, es aprender de la información basada en los descubrimientos realizados más
adelante, en las etapas de Prueba, Integración y Lanzamiento. Los lotes pequeños permiten
esto: si alguien en la etapa de Prueba determina que se debe cambiar un requisito, puede
comunicárselo a las personas que trabajan en Requisitos, que aún está en proceso (Figura
13.11). Si determina que se debe cambiar el código, puede comunicárselo a Code, que también
está en proceso. La retroalimentación frecuente permite revisar las decisiones en función de la
información más reciente. Esto es lo que sucede en APM.
Figura 13.11 Retroalimentación: compartir aprendizaje e información con etapas anteriores.
Eficiencia
Supongamos que la etapa de código creó programas a partir de un lote de 40

requisitos, pero luego descubrió que los 40 requisitos se basaban en una
suposición inicial incorrecta. Esto requerirá que se revisen y corrijan los 40
requisitos, y que el código basado en esos requisitos también se revise y
corrija. Si, en cambio, la etapa del Código hubiera recibido solo los primeros
10 requisitos, identificado la suposición incorrecta e informado a quienes
crearon los requisitos, los siguientes 30 requisitos no incluirían esa suposición
y solo se tendrían que volver a hacer los primeros 10 requisitos y el código asociado. Y reha
tomará relativamente menos tiempo porque todo está todavía fresco en la mente de todos.
En general, cuando las personas reciben comentarios rápidos, pueden arreglar las cosas rápidamente; cuando reciben
comentarios tardíos, pierden el tiempo averiguando qué hicieron mal.
Variabilidad de la carga de trabajo
Los lotes grandes entre etapas imponen una carga de trabajo ascendente y descendente en los recursos del proyecto.
Un ingeniero que puede probar fácilmente dos artículos al día estará sobrecargado con la llegada de 40 artículos. A
medida que se mueven grandes lotes a través de un proyecto, los recursos en cada etapa se estiran. Dice Reinertsen,
es como ver "un elefante moverse a través de
una boa constrictor”, sobrecargando progresivamente las etapas del sistema a lo largo del camino. 21
Los lotes más pequeños provocan una menor variabilidad de la carga de trabajo y dan como resultado una carga de
trabajo más uniforme para los recursos del proyecto.
Urgencia y Motivación
Un programador que debe entregar un código escrito para la prueba mañana está motivado y coloca el código en la
parte superior de su lista de tareas pendientes. No se sentirá tan motivada si el código debe entregarse dentro de 30
días como parte de un lote que incluirá el código de otros programadores.
Costo general
Cuanto mayor sea el lote, más artículos se deben verificar e informar. Si el software se prueba en un lote grande,
puede haber muchos errores para identificar y 22 Si hay 100 errores abiertos y uno más es rectificado, los llamados
ver si el nuevo es único o duplica a alguno de"errores

los otros.
abiertos".
Si solo hay
descubierto,
diez errores
los abiertos,
100 tendrán
cada
que
uno
sernuevo
revisados
deberá
para
compararse con solo otros nueve. Los informes de estado abordarían 10 errores en lugar de 100. Y, dado que 10
errores se resolverán mucho antes que 100, no será necesario informarlos durante tanto tiempo.
Riesgo
Gran parte del riesgo en los proyectos de desarrollo proviene de las amenazas de cambios en las
necesidades y deseos de los clientes, la preferencia por parte de los competidores y la aparición de
nuevas tecnologías. Los lotes más pequeños permiten una retroalimentación más rápida sobre todo
esto y permiten que el proyecto finalice más rápido y, por lo tanto, sea vulnerable a los riesgos por
un tiempo más corto.
Por supuesto, también hay un argumento para lotes más grandes: menor costo de configuración
y transporte/transferencia de lotes. Por lo general, el trabajo en un lote debe estar precedido por la
preparación, y luego el lote debe transferirse; por lo tanto, concomitantemente con lotes de menor
tamaño hay mayores costos de instalación y transferencia. En los proyectos, sin embargo, dichos
costos suelen ser bajos o insignificantes (¿cuál es el costo de transferir lotes de información?), y las
ventajas comparativas de los lotes pequeños ganan.
Tamaño de lote frente a iteración
El tamaño del lote y la iteración son conceptos relacionados. TPM es un lote grande, una sola
iteración: haga cada etapa una vez y complete todo antes de pasar a la siguiente etapa.
APM es un lote pequeño, muchas iteraciones: repetir etapas iterativamente; en cada iteración,
aborde solo una parte de la solución/elemento final y aproveche los comentarios de las iteraciones
anteriores. Scrum es iteraciones dentro de iteraciones: hacer un poco de todo cada día para construir
una pequeña parte del sistema; combine las piezas durante cada sprint para crear un resultado
utilizable e independiente; con el último sprint, combine los resultados para crear un producto
completo.
En general, el tamaño del lote y la frecuencia de iteración deben variar según la incertidumbre:
los proyectos con mayor incertidumbre deben usar lotes de menor tamaño (tareas más cortas),
repetidos con más frecuencia para permitir una retroalimentación y cambios más rápidos. Los
proyectos de APM manejan la incertidumbre de esta manera, pero también lo pueden hacer los
proyectos de TPM: proporcione los requisitos del grupo de diseño tan pronto como se creen; entregar
los dibujos al grupo de modelado tan pronto como se creen; y así. Este principio se aplica siempre
que la consecuencia del riesgo de cometer un error o hacer un retrabajo sea menor que el valor de
hacer el trabajo más rápido y obtener retroalimentación más rápido.
23
Tamaño de cola y espera
Las colas (retrasos de trabajo a la espera de ser realizados) son el proyecto equivalente al inventario.
En general, cuanto más larga sea la cola, mayor será el tiempo de espera (piense en las personas que
esperan en la cola para pasar por un mostrador de caja; cuanto más larga sea la cola, más larga será
la espera).
La longitud de la cola y el tamaño del lote están relacionados: cuanto mayor sea el lote que llega a
una etapa, más larga será la cola. La Figura 13.12, que es similar a la Figura 13.9, muestra el tamaño
de la cola de trabajo en cada punto de transferencia de trabajo. Los triángulos sombreados representan
colas crecientes a medida que se procesan los elementos en cada etapa. El lado derecho de cada
triángulo es la cantidad de trabajo transferido a la siguiente etapa; Piense en ello como un lote de
artículos que tienen que esperar en línea en la siguiente etapa para ser procesados. La figura 13.13
muestra lo que sucede con lotes más pequeños. Los triángulos más pequeños representan colas más
pequeñas y tiempos de espera más cortos.
Figura 13.12 Longitud de cola, trabajo transferido mensualmente.

Figura 13.13 Longitud de la cola, trabajo transferido semanalmente.
En los sistemas de fabricación, las colas son fáciles de ver (son artículos físicos) y cuando se
vuelven demasiado grandes, los gerentes intentan acortarlas. Pero en los proyectos, las colas suelen
ser invisibles: consisten en información almacenada en computadoras; sin darse cuenta de ellos, los
gerentes no se sienten obligados a hacer nada para acortarlos.
Pero las colas largas, incluso las invisibles, tienen los mismos inconvenientes que los lotes grandes
y los mismos beneficios para reducirlos. Dos formas de reducir el tamaño promedio de la cola son
acelerar la etapa (mover elementos a través de ella más rápido) o reducir el tamaño del lote de
elementos que llegan a la etapa. Mientras que el trabajo en una etapa a menudo no puede
simplemente "acelerarse", los tamaños de los lotes que llegan a la etapa a menudo se pueden reducir.
El “proceso de entrada” descrito en los capítulos 4 y 18, mediante el cual el proyecto se detiene
en varias etapas para su revisión y autorización, ilustra el caso de grandes lotes y largas colas de la
figura 13.12. A pesar de sus supuestas ventajas, el proceso de selección detiene el trabajo y la
información en cada etapa y no los libera hasta que se aprueba todo. Si la velocidad de
comercialización es una meta del proyecto, la puerta es
no es la forma de lograrlo.
Cronometraje y estandarización de ciclos
El tiempo de ciclo es el tiempo para completar un trabajo o unidad. En un proyecto, el tiempo de ciclo
puede ser el tiempo para construir un modelo, codificar un módulo, completar una prueba, lanzar un nuevo
producto, etc. La sincronización del ciclo es el concepto de regularidad o ritmo, y significa dedicar
aproximadamente el mismo tiempo para construir cada modelo, realizar cada prueba, lanzar cada producto,
etc. En términos de programación, dice, por ejemplo, “completaremos un módulo todos los días, día tras
día” o “completaremos una prueba importante cada semana, semana tras semana” o “lanzaremos una
nueva versión del producto cada mes, mes tras mes”.
La sincronización del ciclo está relacionada con el concepto de flujo suave, o trabajo que se realiza de
manera uniforme a un ritmo, ritmo o ritmo, sin interrupción. Tal uniformidad reduce la incertidumbre sobre
la variabilidad de la carga de trabajo y permite que los gerentes y trabajadores conozcan y cumplan con
las expectativas; por ejemplo, cada día un programador sabe que se espera que complete un módulo
codificado. El flujo uniforme se logra en parte moviendo el trabajo de una etapa a otra periódicamente y en
lotes pequeños. El trabajo tiene un tamaño lo suficientemente pequeño para que pueda completarse en el
tiempo de ciclo asignado.
En los proyectos APM, el trabajo fluye de esta manera: el concepto de velocidad antes mencionado.
Considere, por ejemplo, un proyecto que implica ciclos diarios de integración de código y prueba. Esto
significa que todos los días los programadores completarán y enviarán el código que está listo para probar,
y todos los días los evaluadores completarán las pruebas y enviarán el código probado que está listo para
integrarse. Si el código no está listo para probar o integrar, no se envía, pero como todos saben lo que se
espera cada día, la mayoría de las veces lo hacen. Todos reciben, producen y entregan entidades
conocidas todos los días.
La sincronización del ciclo cuenta con la ayuda del principio lean de estandarización, que se refiere a
establecer estándares en procesos, tareas, horarios, etc., de modo que todos tiendan a trabajar de la
misma manera, durante la misma cantidad de tiempo y utilicen los mismos pasos. y recursos La
estandarización reduce la incertidumbre y la variabilidad con respecto a qué
debe hacerse y los recursos necesarios para hacerlo. En las organizaciones esbeltas, los estándares
de trabajo los establecen las personas más familiarizadas con el trabajo, los que realmente lo hacen;
esto es parte del principio de autogestión que se describe más adelante.
24
Reuniones y Revisiones
Las aplicaciones y los beneficios de los lotes pequeños y la sincronización del ciclo se aplican
ampliamente; un buen ejemplo son las reuniones y revisiones. En lugar de programar reuniones
largas e infrecuentes, use reuniones estándar, frecuentes y cortas: reuniones diarias. Las reuniones
cortas y frecuentes permiten una retroalimentación más rápida y atacar los problemas de inmediato
y con urgencia. El tiempo total de las reuniones permanece igual, ya que las reuniones cortas
frecuentes no requieren más tiempo que las reuniones largas poco frecuentes.
Los horarios de las reuniones están estandarizados y cronometrados por ciclos, es decir, las
reuniones se convocan a la misma hora y lugar, todos los días o el mismo día de la semana. Esto
reduce el esfuerzo de planificación y coordinación y los retrasos en las decisiones: mientras que una
reunión ad-hoc puede tardar varios días en organizarse y, por lo tanto, retrasar las decisiones varios
días, las reuniones diarias no requieren arreglos y retrasan las decisiones como máximo 1 día.
El mismo concepto de tiempo de ciclo estandarizado se aplica a las revisiones del estado del
proyecto: convocarlas a intervalos regulares, a la misma hora y el mismo día todos los meses,
independientemente del progreso o los problemas del proyecto. Todos conocen las fechas de las
reuniones con anticipación y pueden incluirlas en sus horarios.
Los beneficios de las reuniones cortas, regulares y frecuentes se ven en todas partes.
Reinertsen cuenta la historia de HP donde cada mañana y tarde el carrito de café venía rodando por
25
los departamentos. Dos veces al día, los ingenieros se reunían
alrededor del carro, hablaban informalmente y cruzaban ideas. Después de que se terminó el carrito
de café, los ingenieros tuvieron que ir a la cafetería a tomar café. Todos fueron en diferentes
momentos y la polinización cruzada disminuyó significativamente.
Se aplica una lógica de tiempo de ciclo estandarizado similar a los recursos que admiten varios
proyectos: ponerlos a disposición de cada proyecto a una hora programada todos los días o semanas.
Por ejemplo, el representante de fabricación está disponible para un equipo de proyecto de 9 am a
10 am cada mañana. De esa manera, cualquier persona en el proyecto que necesite trabajar con el
representante tendrá una hora durante la cual el
representante está totalmente disponible. Si surge un tema importante, cualquier persona puede solicitar la
asistencia del representante en otros momentos; de lo contrario, esperan hasta el día siguiente. El tiempo
disponible se puede ajustar para la etapa del proyecto y la demanda del recurso.
Autogestión, transferencias mínimas, gestión visual y

Kanban
La filosofía de producción ajustada reconoce que los problemas y oportunidades en un proceso a menudo son
identificados primero por los trabajadores en el proceso y, dadas las habilidades apropiadas, son las personas
más adecuadas para tomar decisiones y tomar medidas correctivas. Este es el principio lean de la autogestión,
que se refiere a empoderar a los equipos de trabajadores y brindarles la información necesaria para tomar
medidas sin la dirección de supervisores o gerentes.
En un equipo de proyecto autogestionado todos pueden ayudar a los demás, y cada uno puede hacer un
poco de todo, independientemente de su especialidad.
Reinertsen llama a estos "recursos en forma de T", personas profundas en un área pero amplias en
muchos: ¡aprendiz de todos los oficios, maestro de uno!26 Los recursos en forma de T se desarrollan
contratando "recursos en forma de I" (en lo profundo de un área) y asignándoles tareas para expandir su
conjunto de habilidades. En un proyecto, esto comienza dando a los trabajadores asignaciones en etapas
"adyacentes" del proyecto, etapas que normalmente proporcionan insumos o reciben productos del trabajador.
Por ejemplo, los analistas reciben capacitación cruzada para programar y los programadores reciben
capacitación cruzada para realizar análisis y pruebas.
Cuando la cola de programación se vuelve demasiado larga (tal vez como se indica en una pizarra), los
analistas dejan de hacer análisis y comienzan a programar; cuando la cola de prueba se vuelve demasiado
larga, los programadores dejan de codificar y comienzan a probar. Lo mismo vale para todos.
Por lo general, en los proyectos, los miembros del equipo trabajan en diferentes departamentos, edificios o
donde sea que se los necesite. Sin embargo, para un equipo autogestionado, lo mejor es ubicar físicamente a
todos en el mismo lugar; esta es una máxima para los proyectos de APM, pero también se aplica a la ingeniería
concurrente en los proyectos de TPM. La colocación maximiza el intercambio de información, la retroalimentación
y la cooperación. Los miembros del equipo comparten información constantemente, con frecuencia y en lotes
pequeños. Aprenden sobre cada
las familias, los antecedentes y los intereses de los demás, lo que construye la cohesión del equipo.
La ubicación conjunta también elimina una fuente principal de ineficiencia en los proyectos: las transferencias,
que se refieren a la transferencia de tareas o elementos entre etapas del proyecto, trabajadores, departamentos
o contratistas. Las transferencias son un desperdicio: los trabajos están a la espera de ser procesados y la
transferencia de información es inadecuada o incorrecta. La colocación minimiza estos desperdicios porque
todos ya saben todo.

Los equipos autogestionados cuentan con la ayuda de la gestión visual: señales visuales a su alrededor que
brindan información que les permite decidir qué, cuándo y cuánto hacer y cuándo y dónde ocurren los problemas.
En una línea de producción, por ejemplo, cada trabajador observa a otros trabajadores en etapas antes y
después de él. Si ve que esas etapas están siendo subutilizadas o sobrecargadas, acelera o desacelera su
propio trabajo o camina para ayudar a esas etapas.
Un equipo de proyecto autogestionado actúa de manera similar. Realiza un seguimiento y controla el flujo de
trabajo a través de reuniones diarias, gráficos de quemado y pizarras blancas.
Las notas adhesivas en pizarras blancas muestran trabajos o historias de usuarios en cada etapa del proceso:
a medida que los trabajos pasan de una etapa a otra, las notas se mueven de una sección a otra, lo que permite
que todos vean los trabajos en cada etapa del proyecto y qué etapas están sobrecargado o subcargado.
De manera similar, el equipo administra la cantidad de trabajos en las etapas del proyecto y, al usar una
pizarra blanca, puede restringir la cantidad de trabajos (tamaño de la cola) en una etapa y evitar que las etapas
posteriores (posteriores) se sobrecarguen con el trabajo que proviene de las etapas anteriores (anteriores). )
etapas. El concepto de producción ajustada de regular y suavizar el flujo de trabajo restringiendo el volumen de
trabajo en cada etapa se llama Kanban.
Con Kanban, también llamado "producción pull", el trabajo se "jala" a través de un proceso: no se permite que
ninguna etapa transfiera trabajo a la siguiente hasta que recibe una señal de que la siguiente etapa está lista
para recibirlo. Por ejemplo, en la pizarra blanca de la figura 13.6 , cada etapa puede contener un máximo de
tres trabajos. La señal de que una etapa está lista para recibir otro trabajo es simplemente cuando la cantidad
de trabajos (notas adhesivas) en la etapa cae por debajo de tres. El equipo puede usar este método simple y
visual para monitorear el progreso y controlar el trabajo para que los trabajos fluyan a un ritmo uniforme.
13.6 Resumen
La metodología tradicional de gestión de proyectos (TPM) se aplica a proyectos en los que el problema/
objetivo y la solución/elemento final se entienden bien y se pueden definir bien. Las fases/etapas del
proyecto se completan en gran medida en secuencia. En TPM incremental, una variación de TPM, el
artículo final se implementa en etapas o partes, lo que permite que partes del mismo se pongan en uso
antes.
La gestión ágil de proyectos (APM) se aplica a proyectos en los que la solución/elemento final es
algo o en gran medida incierto. Acomoda esta incertidumbre a través de un proceso de aprendizaje
sobre la marcha de pasos iterativos en la fase de ejecución, donde cada iteración conduce a la liberación
de un "incremento" del artículo final y una mejor comprensión del artículo final final.
En la forma de modelo en espiral de APM, el artículo final se libera a través de una serie de ciclos
múltiples, donde cada ciclo consta de las etapas de análisis, diseño, desarrollo, prueba, etc., y da como
resultado un prototipo. Con cada ciclo, el cliente proporciona retroalimentación al desarrollador, quien
crea una versión mejorada del prototipo y, en última instancia, un producto final.
Scrum, otra forma de APM, se aplica comúnmente al desarrollo de software.

El proceso de scrum comienza cuando el propietario del producto enumera las necesidades y los deseos
del cliente/usuario en la cartera de pedidos del producto, y el equipo los aborda a través de una serie de
sprints. Cada sprint se enfoca en un subconjunto de elementos en la cartera de pedidos y da como
resultado el lanzamiento de "algo de valor" para el cliente: un producto potencialmente entregable.
El equipo recibe comentarios sobre el lanzamiento como entrada para los sprints posteriores.
La producción ajustada implica realizar el trabajo con el menor tiempo, recursos y esfuerzo sin
disminuir la calidad del trabajo o la producción. Enfatiza el flujo suave, que cualquier cosa que pase por
un proceso de múltiples etapas debe moverse sin obstáculos. APM a veces se denomina "gestión de
proyectos ajustada", pero las prácticas ajustadas también se aplican a los proyectos de TPM.
Un concepto esbelto es el uso de lotes pequeños. Al disminuir el tamaño del lote, las etapas del
proyecto se pueden superponer: el proyecto finaliza antes, los errores se detectan antes y el equipo
recibe comentarios más rápidos de las etapas posteriores y del cliente. Otro beneficio es que los equipos
de proyecto aprenden y pueden hacer las cosas más rápido,
que reduce el riesgo.

El tamaño del lote y la iteración son conceptos relacionados. APM es un lote pequeño, muchas
iteraciones: las etapas se repiten iterativamente; cada iteración aborda solo una parte de la solución/elemento
final y aprovecha los comentarios de las iteraciones anteriores.
El tamaño del lote y la longitud de la cola también están relacionados. Cuanto más pequeño sea el lote que
llega a una etapa, más corta será la cola de trabajo y el tiempo para mover el trabajo a través de cada etapa.
Otro concepto lean, ciclo de tiempo (CT), significa dedicar el mismo tiempo para hacer cada tipo de tarea;
todos reciben, producen y entregan entidades conocidas todos los días. CT se facilita mediante la
estandarización de los procedimientos de trabajo.
La filosofía Lean reconoce que los problemas y oportunidades en un proceso a menudo son identificados
primero por los trabajadores en el proceso; dadas las habilidades adecuadas, a menudo son los más
adecuados para tomar decisiones y emprender acciones correctivas. Este es el
concepto de autogestión: facultar a los equipos de trabajadores para que decidan y actúen con la ayuda de
la gestión visual; proporcionar a los equipos información visual que les permita decidir qué, cuándo y cuánto
hacer. La pizarra blanca es un ejemplo de una herramienta de gestión visual: permite al equipo monitorear
los trabajos en un proyecto y restringir el volumen de trabajo en las etapas. Esa práctica, llamada Kanban,
suaviza el flujo de trabajo y facilita CT. Para los gerentes de proyecto, tales conceptos sugieren formas de
mejorar la eficiencia y eliminar los desperdicios, formas limitadas solo por la imaginación.
Las secciones anteriores del libro describieron cómo los gerentes de proyecto, las organizaciones y los
equipos planifican, organizan y guían los proyectos de principio a fin, aunque se dijo poco sobre los gerentes
de proyecto, las organizaciones o los equipos mismos. La siguiente sección se enfoca en los gerentes y
equipos; aborda el comportamiento organizacional del proyecto y los temas de estructura organizacional,
liderazgo, trabajo en equipo y conflicto y estrés.
1. ¿Cuál es la principal característica de los proyectos en los que TPM (waterfall

enfoque) se aplica?
2. ¿Cómo se manejan los cambios en los requisitos con TPM?
3. ¿En qué se diferencia el TPM incremental del TPM? que es "incremental "
sobre eso?
4. ¿Para qué tipo de proyectos el TPM es inapropiado o inadecuado?

5. Describa cómo APM puede describirse como un enfoque de "aprender sobre la marcha".
6. ¿Qué sucede durante cada iteración en APM? ¿Cuáles son los resultados esperados de una
iteración? ¿Cuánto duran las iteraciones?
7. Describa el proceso de planificación en APM.
8. ¿En qué se diferencia APM de TPM incremental?
9. Describe cómo funciona el modelo en espiral y los resultados de cada ciclo. En
¿En qué se diferencia el modelo en espiral de Scrum?
10. ¿Puede imaginar proyectos en los que se aplicarían tanto APM como TPM?
Describelos.
11. Defina cada uno de los siguientes: acumulación de productos, historias de usuarios y epopeyas,
acumulación de sprint, sprint, timebox, condiciones de satisfacción, producto potencialmente
entregable.
12. Definir los roles y responsabilidades del Scrum master y del producto.
dueño.
13. Describa las características importantes de un equipo Scrum: roles, estructura, tamaño,
responsabilidades de los miembros del equipo.
14. ¿Cómo se convierten los resultados de los “incrementos de sprint” en versiones de producción
u operativas del producto?
15. ¿Qué sucede durante lo siguiente: reuniones de planificación de sprint, reuniones diarias de
Scrum y reuniones de revisión/retrospectivas?
16. Describa cómo se utiliza una pizarra blanca para realizar un seguimiento de los trabajos/tareas.
17. Describa cómo se usa un gráfico de quemado para seguir el progreso del trabajo.
18. Si un equipo de tres personas debe trabajar 6 horas al día durante un sprint de 15 días, ¿cuál
es el número total de horas de trabajo disponibles en el sprint? ¿Cuál será el
horas de esfuerzo restantes al comienzo del sprint?

19. El día 7, Helena comienza y completa la Tarea A, que se estimó en 4 horas. También inicia la
Tarea B, que se estima que demorará 5 horas, pero al final del día supone que la tarea está
completa en un 60 por ciento. Para el día 7, ¿cuántas horas ha reducido Helena las horas de
esfuerzo restantes?
20. A partir del día 7, al sprint le quedan 59 horas de esfuerzo. El sprint comenzó con 120 horas de
esfuerzo restantes y se programó a 15 días. ¿Cuál es la velocidad? ¿Terminará el proyecto
dentro de la caja de tiempo?
21. Si un sprint se está quedando atrás, ¿por qué no hacer trabajar al equipo horas extras para completarlo?
el retraso?
22. ¿Por qué la aplicación de los métodos APM se limita a ciertos tipos de proyectos?
¿Por qué podría ser difícil aplicar APM a proyectos de construcción, infraestructura a gran
escala y desarrollo de productos de hardware?
23. ¿A qué se refiere “lean” en producción ajustada?
24. ¿A qué se refiere “flujo” en los proyectos? ¿Qué es lo que está fluyendo?
25. ¿Qué son los “lotes” en los proyectos? ¿Qué es el flujo de lote pequeño?
26. Explique cómo los lotes pequeños: reducen la duración del proyecto; mejorar calidad; aumentar
la retroalimentación, la eficiencia y la motivación; y disminuir la variabilidad de la carga de
trabajo, los costos generales y el riesgo.
27. También existen inconvenientes para los lotes pequeños (por lo tanto, beneficios para los lotes grandes).
lotes). ¿Qué son?

28. Describa la conexión entre el tamaño del lote y la iteración en los proyectos.
29. Describa la conexión entre el tamaño del lote, el tamaño de la cola y la espera
tiempo.
30. ¿Dónde están las colas en un proyecto y qué, exactamente, está esperando en el
colas?
31. ¿El proceso de gatillado es de lotes grandes o lotes pequeños?
32. ¿Qué es la sincronización del ciclo? ¿Cómo se aplica a los proyectos y cuáles son los
¿beneficios?
33. ¿Qué significa estandarización en el contexto de un proyecto? Dar algo

ejemplos
34. Describa los equipos autogestionados. ¿Son iguales o diferentes a los equipos de APM?
35. ¿Cómo reducen los equipos autogestionados el problema de los traspasos?

36. ¿Qué es la gestión visual? Dar ejemplos.
37. ¿Qué es Kanban? ¿Cómo se aplica a la gestión de proyectos?
¿Cree o sabe con certeza que se utilizaron prácticas incrementales, iterativas, ágiles o lean en el proyecto? Si es
así, responda las siguientes preguntas.
1. ¿Se realizó el proyecto en iteraciones? Si es así, ¿por qué? ¿Qué aspectos del proyecto (fases o
etapas) se estaban iterando?
2. Si el proyecto se realizó en iteraciones, ¿cuáles fueron los resultados de cada una? ¿Diría usted que
fueron “incrementos”?
3. Si se usó el modelo en espiral, ¿en qué se parece o en qué se diferencia del modelo descrito en el
capítulo? Si se utilizó el enfoque Scrum, ¿en qué se parece o en qué se diferencia? Al responder
esto, refiérase a los términos mencionados en la Pregunta 11 anterior.
4. ¿Había un Scrum Master y un Product Owner? ¿Cuáles eran sus roles?
5. ¿Había un director de proyecto? ¿Cuál fue su papel?
6. Describa el equipo del proyecto, las funciones de los miembros del equipo, las responsabilidades y
cómo funcionaba el equipo.
7. ¿Quiénes eran las otras partes interesadas y cuáles eran sus funciones?
8. ¿Cómo se planeó el proyecto? ¿Cómo fue rastreado y controlado? Fueron

pizarras blancas, tablas de quemado u otros métodos utilizados?
9. ¿Conoce el director del proyecto los “métodos lean”? ¿Los aplica a la gestión de proyectos?
10. ¿Diría que el trabajo en este proyecto se movió en lotes pequeños o grandes? (¿De qué están hechos
los “lotes”?) Si son grandes, explique cómo/dónde se podría haber beneficiado el proyecto con lotes
pequeños.
11. ¿Observó tareas de trabajo esperando o retrasadas que podrían haber

¿Se ha beneficiado de las transferencias de lotes más pequeños?
12. ¿Observó la sincronización del ciclo o la estandarización de tareas en el proyecto?
13. ¿Se aplicaron métodos de gestión visual o el concepto Kanban en la
¿proyecto?
14. ¿Se autogestionó el equipo? En caso afirmativo, analice de qué manera se las arregló
sí mismo.
Caso 13.1 Gran entrada para Accent, Inc.
El objetivo del proyecto Grand Entry era proporcionar un nuevo portal web para los
empleados de Accent, Inc. que reemplazaría el portal existente, que los empleados
consideraban que estaba abarrotado y era difícil de usar. La declaración de la
misión del proyecto era "Crear una experiencia de usuario mejorada mediante el
desarrollo de un sistema simple e intuitivo que permita a los usuarios navegar y
acceder a los contenidos deseados de manera rápida y eficiente". Entre sus
objetivos se encontraban “diseño innovador, interfaces simples e intuitivas, funciones
para alentar a los usuarios a regresar al sitio y el uso de un proceso ágil para desarrollar el sitio”.
El CIO había oído hablar de la metodología ágil y pensó que Grand Entry sería
un buen lugar para probarla. Le asignó el proyecto a Theodora Lamar, una gerente
de proyectos de software con mucha experiencia, aunque ninguna en ágil. La alta
dirección no proporcionó ningún presupuesto, pero le dijo a Theodora que
mantuviera los costos entre “$400 000 y $600 000” (para cubrir los salarios de los
trabajadores asignados al proyecto) y que esperara que se completara en 16 meses.
Debía llevar a cabo el proyecto de "moda ágil", en el que cada sprint debía ofrecer
"funcionalidad adicional" que sería revisada y aprobada por las "partes interesadas".
Theodora leyó algunos artículos sobre Agile y Scrum, se nombró Scrum Master
y seleccionó a dos analistas para el equipo de Grand Entry (GE). Su primera acción
fue formar un grupo de enfoque a través del cual los usuarios del portal pudieran
expresar su descontento con el sistema actual. El equipo eligió para el grupo focal
a dos empleados de Accent, recientemente contratados y aún no asignados a un
trabajo específico. Al ser nuevos en la empresa, tenían experiencia reciente con el
portal y conocían sus limitaciones. Su función era doble: (1) hablar con la mayor
cantidad posible de compañeros de trabajo para conocer los problemas del portal
actual y obtener ideas para mejorar; (2) usar los entregables de cada sprint y hacer
sugerencias. Inicialmente dedicarían todo su tiempo al proyecto; luego dividirían su
tiempo entre el proyecto y otras asignaciones de trabajo.
Theodora y los analistas primero entrevistaron a los dos empleados y luego

tres altos directivos, incluido el CIO. Sus comentarios y sugerencias formaron la base
de la lista original de "requisitos de usuario" para Grand Entry.
Theodora revisó la lista y eligió las que pensó que serían las más realistas para
implementar. Luego seleccionó a tres personas más de diferentes departamentos para
que se unieran al equipo de GE: un arquitecto, un desarrollador y un recurso de soporte.
Ninguno de ellos había trabajado juntos, pero Theodora los conocía a todos y sentía
que técnicamente eran "los mejores". Además del equipo de GE, la otra parte técnica
involucrada en el proyecto fue Metasoft, el desarrollador de la plataforma de navegación
en la que residía el portal. Metasoft manejaría todos los problemas del proyecto
relacionados con el navegador.
El equipo de GE se identificó a sí mismo, al grupo de enfoque, a Metasoft y a los
tres gerentes principales como las "partes interesadas" del proyecto. No incluyó ni se
comunicó con el grupo encargado de mantener y actualizar el portal existente y, como
resultado, no estaba al tanto de los problemas que ese grupo ya había descubierto.
Esto resultó en cierta duplicación de esfuerzos, ya que tanto el equipo de GE como el
grupo de mantenimiento trabajaron en los mismos problemas; el equipo de GE incluso
probó enfoques que el grupo de mantenimiento ya había probado sin éxito. Cuando el
grupo de mantenimiento finalmente se enteró del proyecto, inicialmente se resistieron a
las solicitudes de asistencia del equipo de GE. Solo varias semanas después
comenzaron a cooperar.
Theodora planeó el proyecto en forma de onda continua de 4 meses; es decir,
preparó un plan para abordar los requisitos en un próximo período de 4 meses y tenía
la intención de repetirlo cuatro veces durante el proyecto de 16 meses.
El plan no especificaba el número esperado de sprints ni su duración.
Cada sprint debía durar de 2 a 3 semanas, según la estimación de Theodora de cuánto
tiempo le llevaría completar los requisitos que había seleccionado. Algunos sprints
planeados originalmente para 2 semanas se extendieron a 3 semanas cuando el trabajo
tomó más tiempo de lo previsto.
Durante el proyecto, el navegador se cerró dos veces y el equipo de GE quedó a
merced de Metasoft. Metasoft no había asignado ninguna prioridad especial a Grand
Entry y, en cada caso, tomó varios días solucionar los problemas que detuvieron el
trabajo en el proyecto.
El resultado de cada sprint fue una versión beta que el equipo de GE demostró al
grupo de enfoque. La respuesta del grupo focal típicamente
consistía en mejoras sugeridas más allá de lo que el equipo era capaz de abordar en
los próximos sprints. Esto creó una acumulación de nuevos requisitos y problemas
abiertos, de los cuales Theodora solo pudo seleccionar algunos como puntos focales
del próximo sprint. Dado que tantos problemas previamente identificados no se habían
abordado, el grupo de enfoque siguió reidentificándolos; por lo tanto, en lugar de
identificar problemas nuevos y más apremiantes, el grupo siguió señalando problemas
que el equipo de GE conocía pero que no había tenido tiempo de solucionar.
Unos meses después de iniciado el proyecto, los gerentes senior adicionales
comenzaron a asistir a las demostraciones beta y agregaron sus propias sugerencias
de mejoras. En consecuencia, los problemas que se pretendían resolver o las
funcionalidades que se agregarían en los próximos sprints fueron reemplazados por
nuevos requisitos. La lista de partes interesadas creció a medida que más gerentes
conocían el proyecto y asistían a las demostraciones.
A medida que crecía la lista de requisitos, Theodora impuso más trabajo al equipo,
lo que resultó en horas extra todos los días. Ella había tratado de evitar las horas
extras, pero nunca siendo completamente consciente de las tareas en las que estaba
trabajando su equipo, les pedía que hicieran más. Nunca dijeron que no, y solo después
de varias semanas de que el equipo trabajara horas extras, con una disminución
notable de la moral y un aumento de los errores, se dio cuenta de que estaba pidiendo demasiado.
Theodora no sabía exactamente qué estaban haciendo los miembros del equipo porque
su método de seguimiento era completamente verbal. Ella les había dicho a los
miembros del equipo que serían responsables de informarse mutuamente sobre cuándo
habían completado o se habían estancado en una tarea. Los miembros del equipo
tenían diferentes percepciones sobre el progreso del trabajo, y solo la revisión constante
de Theodora evitó que el trabajo se perdiera.
El proyecto se completó en 16 meses y el rango de dólares estimado. Los requisitos
más significativos identificados por el grupo de enfoque y los gerentes superiores se
incorporaron al portal, pero las opiniones sobre la efectividad de Grand Entry de la
población general de empleados aún están pendientes. El grupo de mantenimiento se
encargará de la operación y la futura actualización y reparación de Grand Entry, lo que,
según el grupo, podría ser difícil ya que el "proceso ágil" del equipo de GE produjo
poca documentación, tan poca que el funcionamiento de partes del sitio es difícil.
comprender, y determinar dónde y cómo hacer las correcciones podría resultar un
desafío. el GE
El equipo, siguiendo el credo del Manifiesto Ágil de "trabajo de valor agregado sobre
documentación", no había hecho prácticamente nada para documentar su trabajo o el
sistema que había creado.
Preguntas
1. Prepare una sección de "lecciones aprendidas" para el informe de cierre del

Proyecto Grand Entry. Considere al menos los siguientes puntos:
una. El cliente y la representación del cliente b.

Definición y priorización de requerimientos c. Tareas
seleccionadas para cada sprint d. Participación de
Metasoft e. Planificación de proyectos y planificación
de sprints de Theodora f. Duración del sprint y tiempo extra
g. Seguimiento y control de proyectos h. Documentación
2. Describa cómo el caso ilustra los beneficios y las desventajas de ágil.

¿Cuáles de los errores cometidos se debieron específicamente al método ágil
y cuáles podrían haberse cometido también con un enfoque más tradicional?
Caso 13.2 Tecnología para rastrear vehículos robados 27
Track & Found, Inc. (TFI), una empresa líder en seguimiento y recuperación de vehículos,
había crecido significativamente en los últimos 10 años debido a la gran demanda de
sus sistemas para fines de seguros. La empresa era consciente de que toda su oferta
de productos dependía de las capacidades de tecnología de la información y la
comunicación, por lo que reestructuró su departamento de TI en una organización
"DevOps" para promover la metodología de desarrollo de software DevOps. los
La reestructuración dividió el departamento de TI en dos equipos, uno para desarrollo (50

empleados) y otro para operaciones (30 empleados). Los programadores e ingenieros más
experimentados y mejor calificados del departamento fueron colocados en el equipo de
desarrollo; sus graduados universitarios menos calificados y recién contratados fueron
puestos en el equipo de operaciones. Debido a que la empresa estaba creciendo tan
rápidamente, los dos equipos tuvieron que ubicarse en edificios diferentes ubicados a una
distancia considerable entre sí.
La gerencia ejecutiva de TFI se acercó a SoftTech Engineers, una empresa de ingeniería
de software de renombre con la que había tenido una relación de larga data, para ayudar
a su propio equipo de desarrollo a desarrollar una nueva aplicación de seguimiento (llamada
"TFIApp") para ser utilizada por equipos de respuesta de vehículos junto con TFI. solución
de seguimiento existente para recuperar vehículos robados de forma más rápida y precisa.
SoftTech se incluyó en el proyecto porque poseía habilidades y conocimientos de desarrollo
que TFI no tenía, además tenía experiencia en gestión de proyectos ágiles que la gerencia
de TFI consideró que podría beneficiar el proyecto. El equipo de desarrollo de TFI no tenía
esa experiencia y esperaba que SoftTech brindara orientación.
En el proyecto TFIApp, SoftTec crearía software para la aplicación de seguimiento

basada en GPS, el equipo de TFI crearía hardware para agregar funcionalidad a la unidad
receptora del vehículo y SoftTec integraría el hardware y el software. SoftTec también
podía desarrollar hardware, pero en interés de la metodología DevOp, la gerencia de TFI
le dio la tarea a su propio equipo de desarrollo para fomentar una estrecha relación de
trabajo con el equipo de operaciones.
SoftTec dividió el trabajo para los componentes de hardware y software del sistema en
una serie de sprints de dos semanas. La finalización de cada sprint sería seguida por una
demostración a la gerencia de TFI. Al dividir el trabajo, el gerente de proyecto de TFIApp,
que trabajaba para SoftTec, se aseguró de que prácticamente todo el trabajo de su propio
equipo pudiera realizarse independientemente del trabajo del equipo de desarrollo (había
aprendido por experiencia previa que no se podía esperar que el departamento de TI de
TFI apegarse a los planes). Los equipos no tendrían que trabajar juntos hasta la integración
al final del proyecto.
El trabajo del equipo de SoftTec avanzó sin problemas y completó los entregables
previstos de cada sprint para el software TFIApp a tiempo, en
presupuesto, y de acuerdo a las especificaciones. Desafortunadamente, sin

embargo, el equipo de desarrollo de TFI completó sus entregas solo para el primer sprint.
A partir de entonces, se retrasó cada vez más porque necesitaba información del
equipo de operaciones, el cual, al no tener suficiente personal, estaba
constantemente en modo de extinción de incendios y no tenía tiempo para reunirse
con el equipo de desarrollo. Como consecuencia de "dividir el trabajo", el equipo de
desarrollo no había recibido capacitación y poca orientación en Agile. Y el hecho
de que el equipo no estaba demostrando los entregables cada dos semanas parece
haber sido pasado por alto por el gerente de proyecto de SoftTec y la gerencia de
TFI. Ninguno de los dos había mostrado mucho interés en el equipo de desarrollo
hasta que SoftTec completó su aplicación de software y se estaba preparando para
la integración con el hardware del equipo de desarrollo. Al escuchar de SoftTec que
el hardware no estaba listo, el ejecutivo de TI de TFI corrió hacia el equipo de
desarrollo y exigió una explicación.
Preguntas
1. ¿Qué es DevOps? Enumere algunas características de la metodología de

desarrollo de software DevOps.
2. ¿Qué podría haber hecho diferente el gerente del proyecto SoftTec para
asegurar un resultado más exitoso para todo el proyecto?
3. ¿Qué partes del proyecto ágil funcionaron bien y qué partes del proyecto no
se adhirieron a la metodología ágil?
4. ¿Qué debería haber hecho de manera diferente la gerencia de TFI? ¿Qué
consejo tiene para que administren mejor sus recursos de TI?
Notas finales
1. Fowler M. y Highsmith J. The Agile Manifesto, agosto de 2001. Ver http://www.pmp-projects.org/Agile

Manifiesto.pdf.
2. Nicholas J. Producción ajustada para la ventaja competitiva. Boca Raton, FL: CRC/Prensa de productividad; 2011.
3. Para conocer los principios básicos, consulte, Dennis P. Lean Production Simplified, 2nd edn. Nueva York: Prensa de productividad;
2007. Para aplicaciones a la gestión de proyectos, véase Blackburn, J. Time-Based Competition. Homewood, Illinois:
Negocio Uno Irwin; 1991; Reinertsen, D. Gestión de la fábrica de diseño, Nueva York: Free Press; 1997;
Leach L. Gestión de proyectos Lean: ocho principios para el éxito. Boise, ID: Proyectos Avanzados; 2005.
4. Para una cobertura completa de APM y sus variantes, consulte Wysocki R. Gestión eficaz de proyectos:
Tradicional, Ágil, Extremo, 6.ª ed. Nueva York: Wiley; 2012. Gran parte de la siguiente discusión está adaptada
de ese libro, particularmente de las págs. 44–47, 380–445.
5. El modelo espiral se introdujo en Boehm B. Un modelo espiral de desarrollo y mejora de software,
ACM SIGSOFT Software Engineering Notes, ACM, 11(4): 14–24, agosto de 1986.
6. El problema de la gestión de la integración de hardware y software y las metodologías simultáneas de cascada y espiral se aborda
en Maier M. y Eberhardt R. The Art of Systems Architecting, 3.ª ed. Boca
Ratón, Florida: CRC Press; 2009, págs. 96–98.
7. Gran parte de esta sección está adaptada de Cohen M. Succeeding with Agile: Software Development Using
Melé. Upper Saddle River, Nueva Jersey: Addison Wesley; 2010.
8. Ibíd., págs. 117–140.
9. Ibíd., pág. 202.
10. Ibíd., págs. 355–388. Para una discusión sobre la escalabilidad ágil, consulte Gower B. y Rally Software. Negocio Ágil: A
Guía del líder para aprovechar la complejidad. Boulder, CO: software de reunión; 2013.
11. Adaptado de Ries E. The Lean Startup. Nueva York: Crown Business; 2011. págs. 138–140.
12. Consulte Schwaber K. y Beedle M. Desarrollo ágil de software con Scrum. Upper Saddle River, Nueva Jersey:
Pearson; 2001.
13. Lohnes P. y Wilson C. ¿Pueden la gestión de proyectos ágil y tradicional ser socios? Integración ágil
métodos con proyecto administración mejor practicas

http://pppm.mclmg.com/docs/AgileVsCBPwhitePaperFinalB.pdf. Consultado el 10 de septiembre de 2014.
14. Consulte Wils A., Van Baelen S., Holvoet T. y De Vlaminck K. Agility in the Avionics Software World. KU
Lovaina distribución, Departamento de computadora Ciencias. Lovaina,
https://distrinet.cs.kuleuven.be/legacy/publications/42148.pdf. Consultado el 17 de septiembre de 2014.
15. Lohnes y Wilson. ¿Pueden la gestión de proyectos ágil y tradicional ser socios? La mayoría de los métodos de APM
se originaron y se utilizan en proyectos de desarrollo de software, pero uno, Adaptive Project Framework,
supuestamente se puede utilizar en todo tipo de proyectos; véase Wysocki. Gestión eficaz de proyectos, págs. 408–437.
16. Ver Weaver P. Agile no es una metodología de gestión de proyectos. Blog publicado el 2 de abril de 2012.
http://network.projectmanagers.net/profiles/blogs/agile-is-not-a-project-management method/Consultado el 10 de
septiembre de 2014.
17. Nicholas, Producción ajustada para la ventaja competitiva.
18. Producción ajustada aplicada a proyectos de construcción; véase Ballard G. El último planificador. California del norte
Conferencia de Primavera del Instituto de Construcción. Monterey, CS: Instituto de Construcción Esbelta. abril de 1994; Koskela
L., Howell G., Ballard G. y Tommelein I. Fundamentos de Lean Construction, en Best R. y de Valence
G. (editores). Diseño y Construcción: Building in Value. Oxford, Reino Unido: Butterworth-Heinemann; 2002.
19. Conceptos de gestión de proyectos Lean en el desarrollo de productos: véase Reinertsen D. Gestión del diseño
Factory, op cit., y The Principles of Product Development Flow: Second Generation Lean Product
Desarrollo. Redondo Beach, CA: Celebras, 2009. Las siguientes secciones se basan en este último, especialmente
Capítulos 5 y 7.
20. Hay dos tipos de lotes: producción y transferencia. La producción es el volumen de trabajo realizado en un
escenario sin interrupción; La transferencia es el volumen de trabajo que se mueve de una etapa a otra. Nuestra discusión de
lotes se centra únicamente en el tamaño del lote de transferencia. Para obtener más información sobre la producción frente a la transferencia por
lotes, consulte Nicholas, Lean Production for Competitive Advantage.
21. Reinertsen, Los principios del flujo de desarrollo de productos, pág. 112.
22. Ibíd., pág. 115.
23. Ibíd., págs. 111–120.
24. Ibíd., págs. 180–185.
25. Ibíd., pág. 185.
26. Ibíd., págs. 155 y 156.
27. Bond-Barnard T., Universidad de Pretoria.

Parte IV
Comportamiento organizacional

Los proyectos son organizaciones de individuos y grupos creados con el propósito de entregar
resultados o elementos finales, y el éxito del proyecto depende en parte de cómo se estructuran
esas organizaciones y qué tan bien trabajan juntas las personas dentro de ellas.
como equipos.
Los tres capítulos de esta sección se centran en cuestiones organizativas y de comportamiento

inherentes a los proyectos. Describen las formas en que se organizan e integran los proyectos, los
estilos de liderazgo de los gerentes de proyectos, las funciones y responsabilidades de los miembros
del equipo del proyecto y las formas en que se administran los equipos para maximizar el trabajo en
equipo y minimizar las consecuencias personales negativas de trabajar en proyectos.
Capítulo 14
Estructura de la organización del proyecto y
Integración
Las organizaciones son sistemas de elementos humanos y físicos creados para lograr objetivos.
Como ocurre con todos los sistemas, se describen en parte por su estructura: la forma de las
relaciones que unen sus elementos. En todas las organizaciones coexisten dos tipos de
estructuras. Uno es la estructura formal, la publicada que describe las relaciones normativas
superior-subordinado, las cadenas de mando y las subdivisiones y agrupaciones de elementos.
La otra es la estructura informal, la inédita que describe relaciones que evolucionan a través de
las interacciones de las personas. Mientras que la organización formal prescribe cómo se
supone que se debe relacionar la gente, la organización informal es cómo se relaciona
realmente. Este capítulo trata principalmente de la estructura organizativa formal de los
proyectos y las organizaciones de proyectos están estructuradas, según los objetivos del
proyecto y los recursos disponibles.
El capítulo también trata sobre la integración del proyecto, que es la forma en que los grupos
funcionales individuales, las subunidades, las fases del proyecto y las tareas de trabajo se
interrelacionan y coordinan para lograr los objetivos del proyecto. La discusión cubre varios
medios de integración de proyectos y el caso especial de integración dentro de proyectos de
desarrollo a gran escala.
Es importante tener en cuenta que, en ocasiones, los proyectos se llevan a cabo sin ninguna
organización formal del proyecto, per se. En otras palabras, un gerente y las personas
tienen la tarea de trabajar en un proyecto, pero no se reconoce explícitamente ningún
grupo u organización del proyecto. La falta de una organización de proyecto identificada
hace que todo sea más difícil de manejar debido a la incertidumbre sobre las relaciones
de reporte y quién, exactamente, está en el proyecto. También digno de mención, y como
se discutirá en el capítulo, es que la mayoría de las organizaciones de proyectos están
“superpuestas” a la estructura organizacional existente; Aunque esto los hace más aptos
para lograr las metas del proyecto, las personas en la organización formal a veces ven la
organización del proyecto como disruptiva para el negocio habitual.
14.1 Estructura organizativa formal

Los conceptos de estructura organizacional se aplican a todo tipo de organizaciones
(compañías, instituciones, agencias) ya sus subunidades (divisiones, departamentos,
proyectos y equipos). La estructura de la organización formal se publica en un gráfico
como el de la NASA en la figura 14.1. Un vistazo rápido revela tanto la jerarquía
organizativa como las agrupaciones para tareas especializadas. El gráfico de la
Figura 14.1 muestra, por ejemplo:
Figura 14.1 Organización y organigrama de la NASA.
1. La gama de actividades en las que participa la organización y las principales

subdivisiones de la organización (exploración, operaciones espaciales,
ciencia, investigación aeronáutica).
2. La jerarquía de gestión y las relaciones de informes (en "Misión", por ejemplo,
los directores de Ames, Goddard y Jet Propulsion Laboratory informan todos
al administrador de ciencias).
3. El tipo de trabajo y responsabilidad de cada subdivisión (p. ej., los proyectos en los
centros de investigación se centran en disciplinas u objetivos específicos, como la
exploración espacial y las operaciones espaciales).
4. Las líneas oficiales de autoridad y comunicación (el administrador es la máxima
autoridad, el subadministrador es el siguiente, y así sucesivamente; la comunicación se
mueve verticalmente a lo largo de las líneas de un recuadro al siguiente).
Hay cosas que el gráfico no muestra, por ejemplo, contactos personales en los que, por
ejemplo, los trabajadores de Jet Propulsion Lab se comunican directamente con los trabajadores
de Dryden por correo electrónico y teléfono, no (como implica el gráfico) a través de los directores
de estos centros. No obstante, el gráfico es útil para dar una visión general de los departamentos
y funciones de la organización y las relaciones formales entre ellos.
14.2 Diseño Organizacional por Diferenciación

e Integración
No existe un tipo "mejor" de estructura organizativa. La estructura más adecuada depende
de los objetivos de la organización, el tipo de trabajo, los recursos disponibles y el entorno.
Las estructuras organizacionales típicamente se desarrollan a través de una combinación de
respuestas planificadas y evolutivas a problemas continuos. Para hacer frente a ciertas
clases de situaciones y problemas, las organizaciones crean subdivisiones y agrupaciones
especializadas, cada una con la experiencia y los recursos necesarios. A medida que crecen
o cambia el entorno, agregan nuevas subdivisiones y agrupaciones para manejar nuevas
situaciones y problemas emergentes. Por ejemplo, cuando una empresa amplía su línea de
productos, puede subdividir su área de fabricación en divisiones orientadas al producto para
abordar mejor los problemas específicos de cada línea. A medida que una empresa expande
su territorio de ventas, puede subdividir geográficamente su fuerza de marketing para
manejar mejor los problemas de origen regional. Esta subdivisión en áreas especializadas
se llama diferenciación.
Por lo general, las subunidades de una organización no actúan como entidades
independientes, sino que interactúan y se apoyan entre sí, al menos en teoría. El grado en
que interactúan y coordinan sus acciones para cumplir con los objetivos de la organización
se denomina integración.
Formas tradicionales de organización
Hay seis formas en que las organizaciones tradicionales se diferencian en subunidades:

funcional, geográfica, producto, cliente, proceso y proyecto. Comenzaremos observando las
primeras cinco formas de diferenciación y luego profundizaremos en la forma del proyecto.
Diferenciación Funcional
La diferenciación funcional se llama así porque divide la organización en subunidades

funcionales como marketing, finanzas, producción, recursos humanos e investigación; la
estructura de Iron Butterfly Co. en la figura 14.2 es un ejemplo. La mayor parte de la
integración entre subunidades se maneja mediante reglas, procedimientos, planes
coordinados y presupuestos. Cuando ocurran discrepancias que no puedan ser manejadas
por estas medidas, los gerentes de las subunidades afectadas deben trabajar en conjunto
para resolverlas.
La diferenciación funcional funciona bien en entornos repetitivos y estables porque hay
pocos cambios y el nivel bastante bajo de integración que ofrecen las reglas, los
procedimientos y la cadena de mando hace el trabajo. La organización funcionalmente
diferenciada tiene una larga historia que se remonta al ejército romano y la Iglesia católica
y sigue siendo hoy en día la forma de organización más predominante.
Diferenciación Geográfica
Figura 14.2 Diferenciación funcional en la estructura organizativa de Iron Butterfly Company.
La mayoría de las organizaciones tienen más de una base para la diferenciación. El

ejército romano también estaba geográficamente diferenciado; es decir, se estructuró
según región o ubicación. Las organizaciones se subdividen según la región (p. ej.,
sucursal del Atlántico, división europea, comando del Lejano Oriente, etc.) para adaptarse
a los requisitos únicos de los clientes, mercados, proveedores, adversarios locales, etc.
Dentro de cada subunidad geográfica, a menudo se conserva la diferenciación funcional.
Las subunidades regionales pueden operar con relativa autonomía y cualquier integración
entre ellos podría lograrse mediante reglas y procedimientos financieros y de presentación de informes
estandarizados.
La diferenciación del producto
Las empresas con una variedad de líneas de productos utilizan la diferenciación basada en productos.
Corporaciones como General Motors, General Foods y General Electric se dividen en subdivisiones
en las que cada una diseña, fabrica y comercializa su propia línea de productos. Dentro de cada
subdivisión hay un desglose funcional, geográfico o de otro tipo. Al igual que con las organizaciones
geográficamente diferenciadas, la integración entre subdivisiones de productos tiende a limitarse a
normas y procedimientos financieros y de información estandarizados.
Diferenciación de clientes
Las organizaciones también pueden diferenciar por tipo de cliente. Por ejemplo, las empresas con
grandes ventas militares y comerciales a menudo establecen una división separada porque los
requisitos federales para propuestas, contratos y especificaciones de productos difieren sustancialmente
de los de los clientes comerciales. El nivel de integración entre las divisiones de los clientes depende
de la interdependencia de las líneas de productos; típicamente, sin embargo, hay poca integración.
Diferenciación de procesos
Las organizaciones también diferencian según el proceso o la secuencia de pasos. Esto se ilustra en
la figura 14.2 para la división de fabricación de Iron Butterfly Co., que incluye departamentos de
ensamblaje, inspección y empaque, tres pasos en el proceso de fabricación. Las subunidades en esta
forma de diferenciación requieren una integración de alto nivel porque están secuencialmente
interrelacionadas y los problemas en una unidad afectan directamente a las demás. Las subunidades
se integran a través de planes y cronogramas coordinados y grupos de trabajo y equipos, que se
analizan más adelante.
Inconvenientes de las formas tradicionales de organización
Por su mismo diseño, las formas tradicionales de organización sólo pueden abordar ciertos tipos de
problemas anticipados y clasificables. A medida que cambia el entorno y surgen nuevos tipos de
problemas, reaccionan diferenciando aún más las subunidades y agregando más reglas,
procedimientos y niveles de gestión; es decir, agregan más burocracia, cuyo precio es menor
flexibilidad y mayor dificultad para integrar las subunidades.
Las formas de organización tradicionales funcionan bajo el supuesto de que todos los problemas
o tareas pueden clasificarse y resolverse claramente dentro de unidades especializadas que pueden
trabajar de forma independiente. El problema es que, cuando surge un problema que no encaja en
ninguna de las subunidades, es posible que no haya lugar para ello. Tales problemas caen por las
grietas.
Una forma de manejar problemas imprevistos e inclasificables es rediseñar la organización cada

vez que surja uno. Sin embargo, el proceso de rediseño de una organización para adaptarse a
problemas únicos es lento y costoso. La alternativa al rediseño es aumentar los problemas en la
cadena de mando e involucrar a los gerentes de las unidades funcionales más adecuadas para
resolverlos. Esto funciona siempre y cuando no se haga con demasiada frecuencia, ya que la
cadena de mando puede verse abrumada rápidamente y la respuesta es agregar más gerentes (es
decir, aumentar aún más el tamaño de la burocracia). En resumen, las formas de organización
tradicionales no son adecuadas para situaciones con cambios frecuentes y alta incertidumbre. No
obstante, la mayoría de los proyectos se llevan a cabo dentro o utilizan recursos proporcionados
por organizaciones con formas tradicionales de estructura.
14.3 Requisitos de las organizaciones del proyecto
Los entornos de proyecto se caracterizan por cambios frecuentes e incertidumbre y, por lo general,
requieren los recursos y el esfuerzo de trabajo coordinado de múltiples subunidades y organizaciones.
Cada proyecto es un nuevo emprendimiento, algo único, dirigido a una nueva meta; por eso, la
incertidumbre y el riesgo son inherentes. Los cambios, errores o retrasos en una subunidad tienen
consecuencias para todas las demás. Por eso, los recursos de las subunidades deben poder trabajar
juntos, deben estar integrados. Las organizaciones de proyectos se crean en torno a proyectos e,
idealmente, su estructura y composición es la que mejor se adapta al proyecto. Y como los proyectos, son
temporales. Cuando finaliza el proyecto, la organización del proyecto se disuelve.
Los proyectos de desarrollo de software, productos farmacéuticos, biomedicina, exploración espacial,

desarrollo de productos e incluso construcción se encuentran de forma rutinaria con cambios inesperados
en los objetivos, las necesidades de los clientes, las demandas ambientales y los recursos; en
consecuencia, sus organizaciones deben ser adaptables a lo inesperado; en una palabra, deben ser
orgánicos, lo que significa tanto altamente diferenciados como altamente integrados para adaptarse a una
variedad de problemas y situaciones. Para lograr esto, todas las organizaciones de proyectos tienen dos
propiedades:
• Subunidades diferenciadas para adaptarse a los requisitos únicos del proyecto y del entorno.
• Subunidades integradas mediante relaciones horizontales.
Estas propiedades se discuten a continuación.

1
14.4 Integración de Subunidades en Proyectos
Las organizaciones tradicionales se caracterizan por su "verticalidad" o dependencia de patrones

de autoridad y comunicación de arriba hacia abajo. Esto los hace lentos e ineficaces para lidiar
con la incertidumbre o situaciones que cambian rápidamente.
En contraste, las organizaciones de proyectos se caracterizan por su horizontalidad o uso de
comunicación directa entre las partes involucradas en un problema.
La horizontalidad significa traspasar las líneas formales de autoridad y trasladar las decisiones al
nivel de las partes afectadas.
Todas las organizaciones tienen elementos de horizontalidad, principalmente en forma de
contactos personales, relaciones informales y amistades. La horizontalidad ayuda a acelerar la
comunicación y resolver problemas entre subunidades. Por ejemplo, cada vez que el departamento
de ensamblaje de la figura 14.2 experimenta una escasez de piezas menores, George, el capataz
de ensamblaje, llama a Helen para que compre un favor de "pedido urgente". La llamada informal
pasa por alto la estructura formal (los respectivos gerentes de George y Helen) y acelera el pedido.
Una desventaja de los procesos informales es que no garantizan que todos los que deberían
estar involucrados lo estén. Por ejemplo, Helen debe cargar todas las compras a una cuenta; si
George no está al tanto del monto en dólares en la cuenta, sus solicitudes informales podrían
agotar la cuenta antes de que se puedan acreditar fondos adicionales, lo que involucra a alguien
en el área de contabilidad que no está al tanto de las solicitudes de George.
Además, si George no le dice a nadie sobre la escasez de piezas, entonces la razón del problema
(hurto, piezas defectuosas o pedido insuficiente) nunca se resolverá. En resumen, los procesos
informales en muchos aspectos son inadecuados.
Las organizaciones de proyectos mejoran los procesos informales al construir la horizontalidad
en la estructura de la organización formal mediante el uso de funciones llamadas integradores.
Los integradores son personas o grupos que facilitan la comunicación entre todas las subunidades
que trabajan en una tarea común. Los integradores eluden las líneas de autoridad tradicionales y
aceleran la comunicación, pero también se aseguran de que todos los afectados por un problema
estén involucrados y tengan la información necesaria.
En los proyectos se utilizan varios tipos de integradores. Se enumeran a continuación en orden

de aumentar la autoridad, la necesidad y el costo; en la lista, los últimos tipos asumen toda la autoridad y
responsabilidad de los primeros: 2
• Funciones de
enlace • Grupos de trabajo y equipos
• Dinamizadores y coordinadores de proyectos •
Gerentes puros de proyectos • Gerentes matriciales
• Contratistas integradores.
14.5 Roles de enlace, grupos de trabajo y equipos
El rol de enlace es una persona o grupo especializado que vincula dos o más departamentos. En
la Figura 14.3 , la línea punteada representa el rol de enlace del “controlador de inventario”. Esta
persona realiza funciones en el departamento de ensamblaje, pero también notifica a las compras
sobre faltantes inminentes y realiza un seguimiento de los pedidos realizados. La función libera
al capataz de montaje de la responsabilidad y, al legitimar el proceso, garantiza que se realicen
los pedidos, se financien y documenten.
Pero el papel de enlace no siempre es efectivo. Aunque el controlador de inventario del

ejemplo agiliza el pedido de piezas, el motivo de la escasez de piezas no se resuelve. Para
desentrañar el problema, podría ser necesario involucrar a personas de otras partes de la
empresa. Aquí es donde entra en juego el siguiente tipo de rol integrador, un grupo de trabajo o
equipo multifuncional .
Un grupo de trabajo es un grupo temporal con representantes de varias subunidades
(multifuncionales) que se reúnen para resolver un problema. Cuando se forma un grupo de este
tipo y comienza a abordar el problema, están, de hecho, realizando un proyecto. Por ejemplo,
cuando ocurre una escasez, el capataz de ensamblaje podría convocar a representantes de las
áreas de inspección, finanzas y compras. El grupo de trabajo se reúne tantas veces como sea
necesario para resolver el problema y luego se disuelve. Los grupos de trabajo más efectivos
tienen diez miembros o menos y un líder de equipo o
coordinador, y son de corta duración. 3

Figura 14.3 Rol de enlace entre los departamentos de Montaje y Compras.
Tanto el líder del equipo como los miembros son seleccionados por (y el líder depende directamente
de) quien haya iniciado o patrocinado el proyecto: un gerente funcional, vicepresidente o director
ejecutivo. Los líderes de equipo son responsables de acelerar y coordinar los esfuerzos del equipo, y
pueden tener autoridad para dirigir tareas y subcontratar trabajos. Sin embargo, por lo general tienen
poca autoridad formal sobre los miembros del equipo que, a menudo, dividen su tiempo entre el
grupo de trabajo y su trabajo “habitual”.
Los grupos de trabajo emprenden una variedad ilimitada de proyectos y asignaciones especiales,
incluidos los siguientes:
• Reorganizaciones de empresas
• Fusiones, adquisiciones o desinversiones •
Estudios especiales, encuestas o evaluaciones •
Auditorías importantes • Esfuerzos de eficiencia,
modernización y reducción de costos • Expansiones geográficas o
de marketing • Reubicaciones de instalaciones o cambios en el
diseño de las instalaciones • Programas de desarrollo de
administración y organización • Instalación de nuevos equipos o
procedimientos.
Idealmente, los miembros del grupo de trabajo tienen información relevante para el proyecto además
de autoridad para hacer compromisos para sus áreas funcionales. Careciendo de información,
el grupo no puede tomar buenas decisiones; al carecer de autoridad, el grupo no podrá

actuar sobre sus decisiones.
Para problemas que son novedosos pero necesitan atención continua , se forman equipos
permanentes . Estos equipos tienen las mismas características que los grupos de trabajo
excepto que se reúnen periódicamente de manera regular, indefinidamente. Por ejemplo, si
Iron Butterfly Company fabrica productos que requieren cambios de diseño a lo largo del
año, entonces los representantes de diseño, fabricación, adquisiciones y otras áreas deben
reunirse cara a cara con regularidad para tomar decisiones con respecto a estos cambios
en respuesta. a los mercados y la competencia cambiantes. Los miembros trabajan en el
equipo a tiempo parcial o completo.
La mayoría de los proyectos involucran varios tipos de equipos; algunos se reúnen
durante una sola fase del ciclo de vida del proyecto, otros para todo el proyecto. Un ejemplo
de esto último es la junta de cambios discutida en el Capítulo 11, un equipo multifuncional
que se reúne periódicamente para discutir y aprobar cambios de diseño.
Ver Capítulo 11
A veces es difícil encontrar personas con el conocimiento, la autoridad y la inclinación

necesarios para servir en fuerzas y equipos de tareas multifuncionales. Las personas
desarrollan actitudes y metas orientadas hacia su especialización, y si bien esto les ayuda
a ser efectivos en su propia área de trabajo, delimita su capacidad para trabajar con
personas de otras áreas. Para los proyectos multifuncionales, los métodos de formación de
equipos descritos en el Capítulo 16 ayudan a romper las barreras y forjar vínculos entre los
miembros del equipo del proyecto.
Ver Capítulo 16
14.6 Impulsores y coordinadores de proyectos
El tipo más simple de organización de proyectos es un solo grupo pequeño de personas,

un grupo de trabajo o un equipo formado a tiempo completo o parcial para realizar una
tarea. Tal grupo puede existir dentro de un área funcional o abarcar múltiples áreas funcionales.
áreas
Proyectos dentro de un área funcional
Tiene sentido que un proyecto que afecta solo a un área funcional se ubique en esa área.
Por ejemplo, un proyecto para encuestar las actitudes de los clientes acerca de un nuevo
producto normalmente se ubicaría por completo dentro del departamento de marketing,
como se indica en la figura 14.4 , porque allí se encuentran todos los recursos y la
experiencia necesarios. El equipo hace todo: prepara el instrumento de la encuesta, obtiene
las listas de correo, distribuye la encuesta y procesa los resultados. Un equipo de proyecto
como este es dirigido por un expedidor de proyecto, alguien4seleccionado
del área donde
por se
el gerente
encuentra
el proyecto. El expedidor coordina las decisiones, crea y supervisa los cronogramas,
mantiene el proyecto en movimiento e informa al gerente. Sin embargo, el facilitador
normalmente no tiene autoridad sobre los miembros del equipo y, por lo tanto, debe confiar
en la persuasión, el conocimiento personal y la información sobre el proyecto para influir
en los miembros del equipo. Una organización grande puede tener más de 100 proyectos
de este tipo en ejecución en sus departamentos funcionales en un momento dado.
Figura 14.4 Gestor de proyectos dentro de una sola área funcional.
Equipos de proyecto multifuncionales
Un ejemplo de un proyecto que podría usar un equipo multifuncional es uno para desarrollar
un sistema de planificación de recursos empresariales (ERP), que es un sistema de toda la
empresa que conecta información sobre pronósticos, entrada de pedidos, compras e
inventario. El equipo, que podría denominarse “Grupo de trabajo de ERP”, incluiría
representantes de todos los departamentos que deben proporcionar entradas al sistema o
utilizar sus salidas, como contabilidad, control de inventario, compras, fabricación, ingeniería
y TI. Los representantes de proveedores y clientes también pueden estar en el equipo. El
equipo es responsable de definir los requisitos del sistema y de supervisar el desarrollo y la
instalación del sistema.
Los equipos multifuncionales son comunes en el desarrollo de productos. Al formar equipos

muy unidos de ingenieros, diseñadores, fabricantes, ensambladores, comercializadores,
proveedores, distribuidores y clientes, las fases del ciclo de desarrollo de sistemas se pueden
realizar simultáneamente en lugar de secuencialmente. Este enfoque, llamado ingeniería
concurrente, elimina las barreras multifuncionales y puede dar como resultado una mayor
calidad y un menor costo. La ingeniería concurrente se analiza en el Capítulo 4 y más
adelante en este capítulo.
Ver Capítulo 4
Figura 14.5 Equipo de proyecto multifuncional.
Los equipos de proyectos multifuncionales por lo general no están asociados con

ningún área funcional en particular (son multifuncionales), y reportan a un gerente de
nivel superior, como se muestra en la Figura 14.5, lo que atribuye una mayor importancia
al proyecto. La persona que gestiona un proyecto de este tipo se designa como
coordinador del proyecto. El coordinador no tiene autoridad de línea sobre los miembros
del equipo, pero sí tiene autoridad para tomar y ejecutar decisiones sobre presupuestos,
cronogramas y desempeño del trabajo del proyecto. La influencia del coordinador se
origina en su reporte a un gerente general de alto nivel y, al igual que el expedidor, su
conocimiento y posición central en el proyecto.
14.7 Organizaciones puras de proyectos
Los proyectos que involucran mucha complejidad, grandes compromisos de recursos y

mucho en juego requieren un proyecto puro o una forma de organización proyectada . Un
proyecto puro es una organización separada, a veces su propia compañía, creada
especialmente para el logro de la meta del proyecto y singularmente dedicada al mismo.
Todo lo que se necesita para lograr las metas del proyecto (todos los recursos humanos y
físicos necesarios) se incorpora a la organización pura del proyecto. A menudo, dentro de
la organización pura del proyecto hay enlaces, grupos de trabajo y equipos.
A la cabeza de la organización de objetos puros está el director de proyectos puro. A
diferencia de un coordinador o expedidor, el gerente de proyecto puro tiene autoridad formal
sobre todas las personas y recursos físicos asignados al proyecto y, por lo tanto, el máximo
control. El director del proyecto puede traer recursos de áreas funcionales internas, así
como contratar a subcontratistas y proveedores externos. El gerente de proyecto puro está
involucrado en el proyecto de principio a fin: durante la preparación de la propuesta, solicita
y concilia los planes de las áreas funcionales y prepara el presupuesto preliminar y las
estimaciones del cronograma; después de la aceptación, contrata personal; durante la
ejecución del proyecto, asigna recursos y aprueba cambios en los requisitos y el plan del
proyecto. Cuando el personal debe ser “prestado” de las áreas funcionales, negocia para
obtenerlos.
Cuando se requieren recursos externos, el director del proyecto encabeza la selección y
las negociaciones con los subcontratistas. Ella supervisa y coordina su trabajo con otras
áreas del proyecto. Los gerentes de proyecto en los ejemplos de Delamir Roofing,
recuperación de desastres y NASA en el Capítulo 1 son gerentes de proyecto puros.
Ver Capítulo 1
Variaciones puras del proyecto
Tres variaciones comunes de la estructura del proyecto puro son el centro del proyecto, el
proyecto parcial y el proyecto independiente.
En el centro de proyectos, la estructura de la organización matriz sigue siendo la misma

excepto por la adición de un "brazo de proyecto" y un director de proyecto separados. Este
formulario se muestra en la figura 14.6 para Iron Butterfly Company, que muestra dos brazos
de proyectos puros, LOGON y SPECTOR. (Por supuesto, a diferencia de las personas, ¡las
organizaciones pueden tener cualquier cantidad de brazos!) Los recursos y el personal se
toman prestados de las áreas funcionales y de personal para trabajar en el centro de proyectos
durante el tiempo que sea necesario. General Motors utilizó un centro de proyectos cuando
eligió a 1200 personas clave de varias divisiones para la tarea de reducir el tamaño de los
vehículos en todas sus líneas automotrices. El centro de proyectos desarrolló sugerencias, las
entregó a las divisiones automotrices para su implementación y luego se disolvió. En otra
corporación, se utilizó un centro de proyectos para supervisar la reubicación de sus oficinas
corporativas. El centro de proyectos trabajó a tiempo completo para abordar los complicados
problemas de la reubicación, mientras que el resto de la organización siguió trabajando como de costumbre.
En un proyecto parcial, las funciones críticas para el proyecto (como la construcción o la
ingeniería) se asignan al director del proyecto, mientras que otras funciones orientadas al
soporte (como las adquisiciones y la contabilidad) permanecen dentro de las áreas funcionales
de la organización matriz. El gerente de un proyecto parcial controla directamente todas las
tareas principales del proyecto, pero recibe asistencia de áreas de la empresa matriz para
tareas de apoyo. En la figura 14.6, por ejemplo, el director del proyecto LOGON podría
controlar completamente el diseño y la fabricación, pero depender de las áreas de finanzas,
recursos humanos y marketing para el soporte funcional.
Figura 14.6 Proyectos puros como “brazos” de la organización funcional.
El proyecto independiente es una organización completa creada especialmente con el

propósito de llevar a cabo el proyecto. Por lo general, se usa para proyectos
gubernamentales, de obras públicas o de desarrollo e instalación a gran escala que
involucran a uno o más contratistas principales, docenas de subcontratistas y numerosas
organizaciones de apoyo, proveedores y consultores. El programa de desarrollo de la
Estación Espacial Internacional, el complejo hidroeléctrico La Grande de Quebec, el Túnel
del Canal, la Presa de las Tres Gargantas de China y el Big Dig de Boston son ejemplos.
Cuando se completan estos proyectos, queda una función para operar el sistema, pero el
resto de la organización se disuelve. Los proyectos independientes se analizan más
adelante en este capítulo en las secciones sobre integración en proyectos a gran escala e
ingeniería concurrente.
Desventajas
La principal desventaja de la organización pura de proyectos es su costo. Debido a que cada proyecto
puro es una organización total o parcialmente independiente, debe contar con personal total o sustancial.
Cada proyecto se convierte en un imperio autónomo y, a menudo, se comparten poco o se utilizan pocos
recursos con otros proyectos.
Las empresas que llevan a cabo múltiples proyectos puros pueden incurrir en una considerable duplicación
de esfuerzos e instalaciones, y altos gastos generales.
Para garantizar que los recursos estarán disponibles cuando se necesiten, las organizaciones de
proyectos puros deben comenzar a adquirirlos antes del proyecto. Uno de los autores se encontraba entre
los numerosos ingenieros contratados en previsión de un gran contrato gubernamental para garantizar que
el proyecto pudiera comenzar tan pronto como se firmara el contrato. Pero el contrato nunca se adjudicó y
todos tuvieron que ser trasladados a otro lugar o despedidos. Solo la pérdida de nómina ascendió a cientos
de meses-hombre.
En la mayoría de las organizaciones, el gerente funcional es la fuerza impulsora que impulsa a los
trabajadores a desarrollar aún más sus competencias técnicas. La mayoría de los gerentes funcionales
alientan a sus trabajadores profesionales a ampliar sus capacidades y lo respaldan con aumentos y
promociones. Pero en una organización pura de proyectos puede que no haya gerentes funcionales y, por
lo tanto, nadie que enfatice el desarrollo de competencias. El tacto habitual del director del proyecto es, al
carecer de la competencia técnica interna adecuada, subcontratar el trabajo. Si bien esto podría satisfacer
las necesidades del proyecto, representa una oportunidad perdida para que la organización desarrolle su
propia experiencia interna. Además, aquellos trabajadores que tienen una competencia considerable a
menudo renuncian después de completar lo que consideran la parte interesante del proyecto porque no
pueden prever lo que harán a continuación en el proyecto, o cuál será el próximo proyecto.
Esto sugiere aún otro costo: la reubicación. Siempre que no hay trabajo de seguimiento, la organización
pura del proyecto enfrenta el problema de qué hacer con su fuerza laboral una vez que finaliza el proyecto.
El personal que ha trabajado en proyectos a largo plazo a menudo se vuelve tan especializado que no
puede ubicarse en proyectos que requieren habilidades más generalizadas o actualizadas.
Las organizaciones puras de proyectos son estrictamente temporales; a medida que el proyecto llega
a su fin, crece la incertidumbre sobre el destino del equipo y decae la moral y el entusiasmo. Un gerente
de proyecto puede estar tan preocupado por generar nuevos contratos o encontrar trabajos para él y su
equipo que se vuelva negligente con
sus responsabilidades de cierre para el proyecto actual.

14.8 Organizaciones Matrices
Aunque la forma de proyecto puro a menudo proporciona la única forma de hacer un proyecto
de una sola vez a gran escala, sus desventajas lo hacen poco práctico para las industrias que
operan continuamente en base a proyectos; tales industrias incluyen la arquitectura y la
construcción, donde cada edificio, puente o carretera es un proyecto; desarrollo de productos,
donde cada concepto de producto, diseño, fabricación y promoción es un proyecto; TI, donde
cada instalación de hardware y software es un proyecto; derecho y contabilidad, donde cada
caso y auditoría es un proyecto; y aeroespacial, donde cada nuevo avión y sistema espacial es
un proyecto. La mayoría de estos proyectos son demasiado grandes, demasiado complejos y
tienen mucho en juego para ser manejados por grupos de trabajo. Además, las empresas de
estas industrias están involucradas en muchos proyectos a la vez (son organizaciones de
proyectos múltiples) y necesitan la capacidad de crear grandes grupos de proyectos rápidamente
sin las desventajas de personal y costos asociadas con las organizaciones de proyectos puros.
Para lograr esta capacidad , evolucionó la forma matricial de organización. Adoptada por
primera vez en la industria aeroespacial por firmas como Boeing y Lockheed-Martin, la matriz,
ilustrada en la figura 14.7, es una estructura de autoridad y relaciones de informes en forma de
cuadrícula creada por la superposición de una organización de proyecto en un 5 Esta
tradicional y funcional. capacidades. superposición da la matriz cuatro organización única
En primer lugar, la parte funcional proporciona el conjunto de conocimientos técnicos y

recursos físicos que necesitan los proyectos. Cada gerente de proyecto crea un equipo de
proyecto negociando con gerentes funcionales para "tomar prestada" la experiencia y los
recursos físicos necesarios para su proyecto. Cada proyecto está compuesto por trabajadores
que están en préstamo para trabajar en el equipo durante el transcurso del proyecto. Este
hecho de compartir la misma fuerza laboral en varios proyectos reduce la duplicación de esfuerzos.
Segundo, mientras que en sus “hogares funcionales” los trabajadores se asocian con
colegas en sus campos de especialización; esto no solo los mantiene actualizados en su
profesión u oficio, sino que los hace más asignables a nuevos proyectos. Cada área funcional
tiene, en un momento dado, muchas personas trabajando en diferentes proyectos, compartiendo
ideas e intercambiando puntos de vista. Esto hace que todos ellos sean más efectivos en
sus respectivos proyectos.

Tercero, cuando se cumplen sus asignaciones o se completa el proyecto, los trabajadores
regresan a sus hogares funcionales para nuevas asignaciones. Esto elimina la ansiedad y reduce
las fluctuaciones en los niveles de fuerza laboral y la moral de los trabajadores.
Finalmente, mientras que los gerentes de las áreas funcionales brindan recursos y soporte
técnico a cada proyecto, una persona, el gerente del proyecto (o gerente matricial) supervisa los
recursos y unifica e integra sus esfuerzos para lograr las metas del proyecto.
Figura 14.7 Forma matricial de organización del proyecto.
Aunque la estructura matricial comparte la virtud con las organizaciones de proyectos puros
de tener recursos dedicados y un gerente de proyecto para dar visibilidad al proyecto, el rango
de autoridad del gerente de proyecto dentro de la matriz puede variar considerablemente. El
Project Management Institute distingue a las organizaciones matriciales como “fuertes”, “débiles”
o “equilibradas”. En una matriz fuerte, los gerentes de proyecto tienen autoridad y control
sustanciales sobre los fondos del proyecto y otros recursos, y dedican la mayor parte o la totalidad
de su tiempo a administrar cada proyecto. en un
matriz débil, los gerentes de proyecto son en realidad coordinadores o expedidores que,
como se explicó antes, no son gerentes de proyecto completos y deben encajar el rol en
otro trabajo, generalmente fuera del proyecto. Coordinan el trabajo del proyecto realizado
por las áreas funcionales contribuyentes, pero tienen poca autoridad, no tienen
responsabilidad presupuestaria y no tienen la capacidad de controlar los recursos por sí
mismos; el trabajo del proyecto dentro de las funciones es supervisado por los gerentes
funcionales. En la matriz equilibrada, los gerentes son gerentes de proyecto de pleno
derecho, pero su nivel de autoridad y control sobre los presupuestos y los recursos es
menor que en una matriz fuerte y se comparte con los gerentes funcionales.
En una organización matricial fuerte, priorizar y equilibrar los recursos compartidos por
los diferentes proyectos es responsabilidad del gerente del proyecto o del director de la
PMO (el “vicepresidente de proyectos” en la Figura 14.8). El administrador de proyectos
atiende los requisitos de los proyectos actuales y futuros, resuelve los conflictos de recursos
entre proyectos y releva a la alta dirección de la responsabilidad de las operaciones del
proyecto. La PMO se analiza más adelante.
Problemas con las organizaciones matriciales
El principal beneficio de la organización matricial, su combinación vertical-horizontal 6 La

es también la fuente principal de sus problemas. estructura,matriz no manera
sino una es solo una estructura,
completamente
diferente de hacer las cosas. La mayoría de las organizaciones están acostumbradas a la
toma de decisiones jerárquica y al flujo de información vertical. Con su énfasis en las
relaciones horizontales, el flujo de información lateral y la toma de decisiones
descentralizada, la matriz es claramente contraria. Superpone un sistema de equipo
horizontal sobre un sistema funcional vertical, y las empresas que adoptan la estructura
deben agregar sistemas de procesamiento de información horizontales a los sistemas de
comando y contabilidad verticales existentes. Se puede hacer, pero tiende a ser algo difícil
y costoso.
Figura 14.8 Ubicación del vicepresidente de proyectos en una organización matricial fuerte.
En términos humanos, el inconveniente de la matriz es que induce al conflicto.

En teoría, la matriz promueve la toma de decisiones coordinada entre las áreas funcionales y
permite que se tomen decisiones de compensación en beneficio de la
proyecto. Sin embargo, asume que existe un equilibrio de poder entre los gerentes funcionales
y de proyecto. A menudo, sin embargo, la autoridad en la matriz no está clara y los gerentes
funcionales y de proyecto compiten para controlarse entre sí. En las organizaciones de
proyectos múltiples, los gerentes funcionales controlan los recursos del proyecto, por lo que
surge un conflicto sobre qué proyecto tiene prioridad y qué gerentes de proyecto obtienen lo mejor.
recursos.
La estructura matricial intenta ser lo mejor de ambos mundos: funcional y proyectada. El
principal problema con la matriz tiene sus raíces en algo que a pocas personas les gusta
admitir: el miedo y el poder: los gerentes funcionales temen que los gerentes de proyecto
(quienes a veces se percibe que tienen el trabajo más interesante y desafiante) puedan tomar
el control de "sus" recursos y reducir su papel a una mera función de “apoyo/personal”. Se
preocupan aún más cuando el Vicepresidente de Proyectos controla la financiación del
proyecto y amenaza con subcontratar el trabajo.
normalmente proporcionada por las áreas funcionales. Los gerentes de proyecto también se frustran
porque, a diferencia de los gerentes funcionales, tienen poco o ningún control sobre los incentivos
de los trabajadores, como promociones, salarios y bonificaciones.
No existen soluciones fáciles para estos problemas, pero para empezar, todos deben comprender
sus roles: el gerente del proyecto debe tener voz sobre lo que se debe hacer, y los gerentes
funcionales deben tener voz sobre cómo se debe hacer (y, para en gran medida, quién dentro de la
función debe hacerlo).
Aquí hay otro problema: cada trabajador de proyecto en la matriz tiene dos jefes, un gerente
funcional y un gerente de matriz de proyecto; esto viola un principio fundamental de la gestión: una
sola cadena de mando. El gerente de proyecto dirige al trabajador en un proyecto, pero el gerente
funcional evalúa el desempeño del trabajador. El resultado inevitable es el conflicto de roles y la
confusión: ¿a quién debe rendirle lealtad el trabajador, al director del proyecto o al director funcional?
Para evitar conflictos y confusiones en la matriz, todos, gerentes y trabajadores, deben tener una
referencia común y la organización debe establecer prioridades claras. Boeing, por ejemplo, que ha
utilizado la matriz con éxito durante años, establece prioridades día a día: las personas operan en
un equipo de proyecto o en un área funcional, y dan prioridad a cualquier área en la que se
conducir a otros dilemas, que se explican a continuación. encuentren.
Ejemplo 14.1 Problema de los dos sombreros
La estructura matricial requiere muchos gerentes, pero en muchas organizaciones los gerentes
son escasos. Una solución es que los gerentes usen dos sombreros: uno como gerente de
proyecto y el otro como gerente funcional. Mientras usa el sombrero funcional, el gerente
asigna recursos a diferentes proyectos; el problema es que, mientras usa el sombrero del
proyecto, es difícil convencer a otros gerentes de proyectos de que no ha obtenido los mejores
recursos para los proyectos que está administrando. Además, para las personas de su
departamento que están trabajando en sus proyectos, el “sombrero del proyecto” es invisible.
Todo lo que ven es ese “sombrero funcional”, siempre conscientes del hecho de que él
controla sus salarios y promociones; como resultado, siempre dan prioridad a sus proyectos
sobre otros en los que están trabajando.
en.
Cualquier intento de adoptar una estructura matricial debe ir acompañado de cambios

tanto de actitud como culturales, que son difíciles de lograr. En muchas empresas, los
conflictos sobre las prioridades y la asignación de recursos son eliminados o reducidos por
la PMO, que establece las prioridades y asigna los recursos. Sin embargo, incluso con una
PMO, la ansiedad y el conflicto siguen siendo enfermedades comunes de la matriz.
estructura.
14.9 Selección de un formulario de organización para proyectos
Los gerentes de proyecto rara vez participan en el diseño de las estructuras organizativas de
los proyectos que lideran, pero pueden ofrecer sugerencias a los gerentes que lo hacen. Es
imposible establecer qué forma de organización es siempre la mejor, pero los criterios generales
ayudan a especificar qué forma es la más apropiada para un proyecto determinado. La figura
14.9 muestra la aplicabilidad aproximada de diferentes formas de organización de proyectos en
función de cuatro criterios:
• Frecuencia de nuevos proyectos (con qué frecuencia o en qué medida la empresa

matriz está involucrada en la actividad relacionada con el proyecto). • Duración de los
proyectos (cuánto tiempo dura un proyecto típico). • Tamaño de los proyectos (nivel de
recursos humanos, de capital u otros en relación con otras actividades de la empresa). •
Complejidad de las relaciones (número de áreas funcionales involucradas en la
proyecto y grado de interdependencia).
Las formas matriciales y de proyectos puros son aplicables a proyectos de mediana y alta
complejidad y de tamaño mediano o grande y en empresas que siempre están realizando
proyectos. Este tipo de proyectos requieren grandes cantidades de recursos e información y
necesitan gerentes de proyecto e integradores con una fuerte autoridad. En particular, la matriz
funciona mejor cuando se realiza una variedad de proyectos diferentes al mismo tiempo y todos
pueden compartir recursos funcionales a tiempo parcial. Por el contrario, cuando hay menos
variedad entre proyectos, cuando los especialistas deben dedicarse a tiempo completo y
cuando se desea una autoridad de proyecto de alto nivel, entonces es mejor la forma de
proyecto puro. Ambas formas son aplicables cuando los proyectos son la “forma de vida” de la
organización.
Figura 14.9 Algunos criterios para seleccionar la forma organizativa apropiada del proyecto.
Para proyectos más pequeños que involucran varias áreas funcionales, los grupos de trabajo y los equipos
multifuncionales son más apropiados. Los grupos de trabajo a tiempo parcial administrados por expedidores
pueden manejar de manera efectiva proyectos de corta duración que involucran una o unas pocas áreas
funcionales. Cuando están involucradas varias áreas, es más adecuado un grupo de trabajo multifuncional
liderado por un coordinador que reporta al gerente general.
Los proyectos de mayor duración, pero de pequeño alcance, se manejan mejor con equipos de proyecto de
tiempo completo con coordinadores. Cuando el tamaño del equipo necesario para realizar la tarea se vuelve
grande y las interrelaciones complejas, entonces se debe establecer una matriz temporal o un proyecto parcial.
Los equipos, grupos de trabajo y centros de proyectos son apropiados cuando la estructura y el flujo de trabajo
existentes de la organización no se pueden interrumpir.
Al seleccionar un formato de proyecto, considere la importancia relativa de los siguientes criterios: el interés
del proyecto, el grado de incertidumbre tecnológica, la criticidad de las metas de tiempo y costo, y la singularidad
8 Para
del proyecto.
Por ejemplo, los grupos de trabajo y los equipos generalmente son apropiados cuando la tarea
del proyecto implica una gran certeza y un riesgo mínimo, y cuando el tiempo y el costo no son
factores importantes. Cuando el riesgo y la incertidumbre son grandes, cuando los objetivos de
tiempo y costo son críticos, o cuando hay mucho en juego, las formas matriciales y de proyectos
puros brindan mejor el alto nivel obligatorio de integración y control. Cuando un proyecto difiere
mucho del negocio normal de la empresa, debe utilizar una forma de proyecto puro parcial o
total.
Todas estas consideraciones se relacionan con el proyecto en sí mismo que, de hecho, a
veces es menos importante que los atributos y las experiencias de la empresa matriz. Por
ejemplo, las formas matriciales y de proyectos puros rara vez se encuentran en organizaciones
pequeñas, que generalmente no tienen suficientes recursos y gerentes para comprometerse.
Las actitudes de la alta dirección sobre el nivel apropiado de responsabilidad y autoridad del
director del proyecto también son importantes. El factor más importante es la experiencia de la
empresa con los proyectos y la percepción de la gerencia sobre qué formas de proyecto
funcionan mejor. Las empresas con poca experiencia en proyectos evitan la matriz porque es
difícil de adoptar. Ante un proyecto complejo, adoptan un enfoque parcial o de centro de proyecto.
La mayoría de las organizaciones están involucradas en una variedad de proyectos y utilizan

una variedad de formas de proyecto diferentes, lo que mejor se adapte a cada proyecto. En una
organización dada, gran parte o la mayor parte del trabajo puede ser realizado por equipos
matriciales, pero algunos proyectos de alta visibilidad se configurarán como proyectos puros.
Mientras tanto, dentro de los departamentos funcionales, se están llevando a cabo innumerables
proyectos pequeños de una sola función, y dispersos en otros lugares, hay grupos de trabajo de
proyectos. Dentro de un proyecto dado, se puede crear una estructura compuesta , es decir,
una estructura que combina características de una forma funcional, matricial y de proyecto puro,
según el alcance y los tipos de trabajo en el proyecto. En Microsoft Corporation, por ejemplo, la
estructura organizativa de los proyectos de desarrollo refleja los productos que producen.
Ejemplo 14.2 Organización de desarrollo de

productos en Microsoft 9
Un proyecto de desarrollo de productos de software en Microsoft puede involucrar de 300

a 400 personas, incluidos especialistas en especificación de productos, desarrollo,
pruebas, educación del usuario y planificación. Los administradores y desarrolladores de

programas dividen el producto en "características", donde cada característica es un
bloque de construcción relativamente independiente que será evidente para los clientes
(por ejemplo, imprimir, agregar una columna de números o interactuar con una marca
particular de hardware). Luego dividen la organización del proyecto en equipos de
desarrollo donde cada uno se concentra en una o algunas de estas características. En
esencia, el proyecto se divide en pequeños proyectos basados en funciones que reflejan
la estructura del producto en general. A través de esta organización basada en funciones,
la funcionalidad del producto se puede aumentar simplemente agregando más equipos
de desarrollo: cuantas más funciones se deseen en el producto, más equipos se
asignarán al proyecto.
Cada equipo consta de tres a ocho desarrolladores, uno de los cuales es el "líder".
El líder reporta al gerente de desarrollo del proyecto, quien tiene una visión amplia del
producto y las interconexiones entre sus características. Una versión reciente de Excel
tenía diez equipos de características: ocho trabajando en el producto básico de Excel,
uno en un producto gráfico y uno en un producto de herramienta de consulta. Junto con
cada equipo de desarrollo de funciones, hay equipos paralelos responsables de las
pruebas de funciones y la educación de los usuarios.
Cada equipo de características tiene una autonomía considerable, aunque debe seguir
reglas para que su trabajo se mantenga coordinado con los otros equipos. Se espera
que cada equipo "construya" y haya verificado una cierta cantidad de código cada día.
Esto obliga a los equipos a sincronizar su trabajo al ritmo del proyecto global.
La filosofía de Microsoft para organizar proyectos es que un producto tiende a reflejar
la organización que lo creó. Una organización grande y lenta creará un producto de
software grande y lento. Un grupo pequeño y ágil en el que todos se lleven bien producirá
piezas de código que funcionen bien en conjunto, razón por la cual Microsoft usa equipos
pequeños y flexibles.
14.10 Oficina de proyectos y PMO
El término oficina de proyectos tiene un doble significado: puede referirse a un grupo de personal
de apoyo que informa al director del proyecto y puede ser un lugar físico donde se reúne el equipo
del proyecto. Nuestra discusión aquí se centrará en el personal de apoyo del proyecto.
El propósito de la oficina de proyectos es coordinar esfuerzos de trabajo y asesorar a las
diferentes áreas funcionales y subcontratistas sobre lo que deben hacer (pero no cómo deben
hacerlo). La oficina es responsable de planificar, dirigir y controlar las actividades del proyecto y
de vincular a los equipos del proyecto, los usuarios y la alta dirección. Cuando los proyectos son
pequeños y los procedimientos están bien establecidos, la oficina puede constar de una sola
persona, el director del proyecto. Cuando la oficina debe coordinar múltiples proyectos, el personal
es mayor y comprende lo que se denomina la oficina de proyectos o, más comúnmente, la oficina
de gestión de proyectos o PMO. La PMO es una oficina de apoyo que desarrolla la política y la
metodología de gestión de proyectos, ofrece capacitación y brinda varios servicios a los gerentes
de proyectos, como se describe en el Capítulo 17.
Ver Capítulo 17
Funciones de la Oficina de Proyectos
Las funciones y la composición de la oficina de proyectos dependen de la autoridad del director del
proyecto y del tamaño, la importancia y el objetivo del proyecto. La oficina de proyectos que se
muestra en la figura 14.10 es para un esfuerzo de desarrollo de ingeniería a gran escala.
Entre las funciones mostradas está la de planificación y control. Durante las fases de concepción y
definición, esta función prepara la EDT, cronogramas y presupuestos. Durante la ejecución,
monitorea el trabajo, pronostica tendencias, actualiza cronogramas y presupuestos, y distribuye
informes a la gerencia funcional, de nivel superior y de clientes.
Ver Apéndice, Capítulo 2

También se muestran funciones de ingeniería de sistemas y gestión de configuración, ambas

encabezadas por el ingeniero de proyecto. La función de ingeniería de sistemas supervisa el análisis de
sistemas, la definición de requisitos y las especificaciones de productos finales (discutidos en el Apéndice
del Capítulo 2) y proporciona insumos para la planificación y el control. La gestión de la configuración
(discutida en los Capítulos 9 y 11) define la configuración inicial del producto y controla los cambios en
los requisitos del producto y del sistema y los planes del proyecto. Como se muestra, la oficina de
proyectos también maneja la contratación y el control financiero.
La integración de las funciones dentro de un proyecto se logra estructurando el proyecto 10 Esto
sucede por oficina

reflejar las áreas funcionales que debe integrar. incluyendo en la oficina un representante de cadapara
área
funcional que trabaja en el proyecto (en la Figura 14.10, compras, contabilidad, etc.). Si bien cada
representante es especialista en una disciplina funcional, mientras que en la oficina de proyectos su papel
principal es integrar esa disciplina con las demás. Como resultado, a través de la coordinación e
integración de los representantes funcionales en la oficina de proyectos, se coordina e integra el trabajo
de las áreas funcionales en el proyecto. Por lo general, los miembros del personal del proyecto están
ubicados en la misma oficina física donde pueden mezclarse y encontrarse cara a cara. En proyectos
más pequeños, el tamaño de la oficina de proyectos puede reducirse permitiendo que algunos o la
mayoría de los representantes funcionales permanezcan en sus áreas funcionales.
Figura 14.10 Oficina de proyectos para un gran proyecto de desarrollo.
Oficina de Proyectos, PMO y Oficina de Programas
Las organizaciones multiproyecto también tienen una oficina de proyectos (que no debe confundirse con
la oficina de proyectos), oficina de programas o PMO. Esto se mostró en la Figura 14.8 como el
"vicepresidente de proyectos". En las organizaciones puras de proyectos, la oficina se ubica en un nivel
entre la alta gerencia y los gerentes de proyecto (en la Figura 14.6, estaría ubicada debajo del gerente
general y en la línea conectada a los proyectos LOGON y SPECTOR). Cuando los proyectos son
pequeños, la oficina de proyectos sustituye a las oficinas de proyectos individuales y se encarga de las
propuestas, la contratación, la programación, el control de costos y la preparación de informes para cada
proyecto. Cuando los proyectos son grandes o se superponen, la oficina de proyectos o PMO se utiliza
además de las oficinas de proyectos y coordina los requisitos combinados de todos los proyectos.
11
Cuando los proyectos forman parte de un programa, se establece una oficina de programas para
garantizar que los proyectos se complementen entre sí y se “suman” a las metas generales del programa. los
La oficina del programa (discutida en el Capítulo 17) maneja las interfaces y la integración
entre proyectos y con recursos externos para cada proyecto, mantiene el entusiasmo y el
apoyo del cliente y mantiene informados a los gerentes de proyectos sobre posibles
problemas. La oficina del programa de la NASA descrita en el Capítulo 1 es un ejemplo.
Cuando los programas son muy grandes, el trabajo de integración de la oficina del programa
se complementa con “contratistas de integración” externos, que se analizan a continuación.
14.11 Integración en Proyectos de Gran Escala
En un proyecto a gran escala (LSP) o megaproyecto, numerosas partes (patrocinadores,

contratistas principales, subcontratistas, consultores y proveedores) contribuyen a un solo esfuerzo.
La Figura 14.11 muestra los principales contribuyentes y relaciones en un LSP.
Las relaciones son complejas y las líneas de autoridad que conectan a las partes a menudo
son débiles, a veces basadas completamente en contratos y órdenes de compra. Si la figura
14.11 parece algo confusa, eso simplemente refleja el hecho de que las relaciones en los LSP
pueden ser confusas. Los ejemplos de LSP incluyen sistemas espaciales (por ejemplo, la
Estación Espacial Internacional), proyectos de construcción (empresa hidroeléctrica La Grande
de Canadá, proyecto de control de inundaciones Delta de Holanda, el Túnel del Canal, la
Presa de las Tres Gargantas de China), reubicaciones de empresas (que involucran al cliente,
empresas de mudanzas, construcción empresas, reclutadores, consultores y proveedores) y
fusiones corporativas (grupos duales de clientes, consultores y abogados).
Nótese en la Figura 14.11 las relaciones directas, tanto horizontales como jerárquicas,
entre los gerentes de los diferentes colaboradores así como entre sus áreas funcionales.
Tales relaciones entre, por ejemplo, grupos de diseño del patrocinador y sus contratistas y
subcontratistas ayudan a acelerar la toma de decisiones y a estrechar la integración. Las
relaciones entre los contribuyentes son facilitadas por los gerentes de proyecto, coordinadores,
expedidores, enlaces y grupos de trabajo.
La mayoría de los LSP se dedican al desarrollo y/o construcción de sistemas complejos. El
esfuerzo total se subdivide entre varios contribuyentes, cada uno de los cuales es responsable
de un subsistema o componente específico que debe integrarse con otros para formar el
sistema general. La figura 14.12, por ejemplo, muestra los principales componentes de la
Estación Espacial Internacional. La figura está simplificada y no muestra los elementos
principales del programa, como los vehículos de lanzamiento para colocar los componentes
en la órbita terrestre, los sistemas de apoyo y las numerosas organizaciones que trabajan para
desarrollar, producir e integrar los componentes (contratistas principales, subcontratistas y
proveedores).
Contratistas de Supervisión e Integración

En obras públicas y proyectos gubernamentales, la integración suele ser responsabilidad de la agencia
patrocinadora. A veces, sin embargo, las tareas de ingeniería y gestión son bastante difíciles o extensas y se
requiere ayuda externa.
Figura 14.11 Relaciones de integración en un proyecto a gran escala.
Entre los primeros LSP en experimentar los problemas de integración inherentes a los grandes
12 Para
Los sistemas fueron proyectos de desarrollo de sistemas de armas durante la Segunda Guerra Mundial.
Por ejemplo, oficinas separadas dentro del Cuerpo Aéreo del Ejército compraron los componentes que componían
un avión bombardero, y estos componentes (fuselaje, motores y componentes electrónicos) luego fueron
suministrados y ensamblados por el fabricante del avión.
A medida que los sistemas se volvieron más complejos, este enfoque dejó de funcionar. A veces, las interfaces
de los componentes eran diferentes, por lo que los tapones y sujetadores no encajaban, o el
los tamaños de los componentes eran diferentes a los planeados y todo el sistema tuvo
que ser rediseñado para acomodarlos. Para superar estas dificultades, los militares
formaron grupos técnicos para coordinar las interfaces de los componentes, pero esto
13
resultó en una burocracia masiva y solo empeoró las cosas, como explica Livingston:
Un contratista quería cambiar el reloj de la cabina de un avión de un mecanismo de un día a uno de ocho días. Escribió
una solicitud y se la entregó al representante militar, quien la remitió al grupo técnico militar. El grupo de tecnología revisó
la solicitud y le pidió al contratista una solicitud más detallada. El contratista revisó la solicitud y la volvió a presentar. El
grupo de tecnología aprobó la solicitud y la envió al comité de cambios. El comité de cambios revisó y aceptó el cambio,
luego envió una autorización por escrito al representante, quien la envió al contratista. En total, esta simple solicitud de
cambio tardó tres meses en aprobarse.
Figura 14.12 Componentes principales del hardware y montaje de la Estación Espacial Internacional.
Fuente: NASA
Hoy en día, el proceso se agiliza al otorgar la responsabilidad de la integración a un solo

organismo de "supervisión", generalmente el líder o contratista principal (el "principal"),
un rol similar al de un consultor de bodas o contratista general, pero a mayor escala. los
El patrocinador del proyecto sigue siendo responsable de contratar a los contratistas

asociados (fabricantes de subsistemas), tomar decisiones importantes y resolver conflictos
entre el principal y los asociados. Los asociados se convierten en subcontratistas (“subs”)
del contratista principal, reciben órdenes del principal y están sujetos a su vigilancia y
aprobación. La figura 14.13 muestra las relaciones entre el patrocinador, el principal y los
14
sustitutos de un gran proyecto de tránsito urbano.
A veces, se le confiere al principal una responsabilidad aún mayor, como ayudar al
patrocinador en la selección de asociados, el precio de los subsistemas y la asignación de
fondos para el proyecto. Esta situación plantea un problema cuando el principal y los subs
son competidores ya que, comprensiblemente, los subs dudan en divulgar conceptos de
diseño innovadores o detalles del subsistema, aunque el principal necesita saber esas
cosas para integrar los subsistemas.
A veces, incluso los contratistas principales más grandes no son lo suficientemente
grandes. En esos momentos, forman equipos ("empresas conjuntas") y presentan
propuestas conjuntas en las que una empresa actúa como líder y asume la responsabilidad
de la ingeniería y gestión de sistemas de las demás. Esto atrae a las pequeñas y medianas
empresas que normalmente no tendrían los recursos para contratar de forma independiente.
Sin embargo, con este enfoque, a menos que la empresa líder sea fuerte, podría haber
serios problemas de interfaz. Pero es probable que ningún equipo tenga todas las mejores
ideas, y el patrocinador puede requerir que la empresa líder abra el desarrollo de
subsistemas a los competidores y, si es necesario, cambie a los miembros del equipo.
Figura 14.13 Relaciones de administración y autoridad en un gran proyecto de construcción.
Cuando el contratista principal carece de la capacidad para realizar todo el trabajo de

integración, se contrata por completo a una empresa consultora independiente oa un
contratista de integración para que brinde asesoramiento sobre integración e ingeniería.
15Estos contratistas, que a veces emplean a miles de trabajadores, pueden reunir
rápidamente todos los recursos necesarios. El problema es que a menudo operan en el
mismo negocio que los contratistas que son responsables de integrar, lo que los coloca
en la incómoda posición de administrar a sus competidores y poder aprender sus secretos.
Ejemplo 14.3 Fusión corporativa: proyecto no

técnico a gran escala dieciséis
La gestión de integración especial es necesaria no solo para proyectos técnicos,

sino también para cualquier proyecto grande y complejo . Cuando una de las
compañías farmacéuticas más grandes de EE. UU. adquirió una de las firmas
farmacéuticas más grandes de Europa por $ 6900 millones, una adquisición que
involucró a 10 000 personas, 18 plantas de fabricación y 30 filiales internacionales,
contrató a una conocida firma consultora mundial para supervisar el esfuerzo de
integración. La firma consultora estableció una oficina de gestión de programas y
un equipo de gestión de integración de adquisiciones global (AIM) con 18 personas
a tiempo completo a nivel de director de la corporación estadounidense. El
propósito del equipo AIM era planificar, administrar y ejecutar la integración en
todas las divisiones y áreas funcionales de la corporación. Este equipo pasó a
crear otros equipos, llegando finalmente a 24 e incluyendo a más de 500 personas
de ambas corporaciones. La consultora compuso los equipos, estructuró el trabajo
de los equipos, participó en sus principales decisiones, vigiló las actividades de la
ruta crítica y consultó con los gerentes y equipos funcionales de la empresa
europea. Al contratar a la consultora como contratista de integración, el proyecto
se benefició de las mejores prácticas y lecciones aprendidas a través de los
muchos años de experiencia en fusiones y adquisiciones del consultor, experiencia
de la que carecían los dos gigantes farmacéuticos. La estructura del proyecto,
que constaba de la empresa consultora, los equipos de AIM y otros equipos, era
una organización puramente de proyecto dedicada por completo a la fusión corporativa.
14.12 Integración en Proyectos de Desarrollo de Sistemas
La integración del proyecto se puede conceptualizar de dos maneras: integración de

las áreas funcionales de la organización del proyecto e integración de las fases del
proyecto. El primero, y el tema del capítulo hasta ahora, se llama integración
horizontal; el último se llama integración vertical (Figura 14.14). Las dos formas están
interrelacionadas porque la integración de las fases del proyecto también suele
requerir la integración de las áreas funcionales que trabajan dentro de las fases.
Los proyectos a gran escala en el desarrollo de productos y software requieren los
esfuerzos integrados de muchas unidades funcionales a lo largo de la concepción,
definición, diseño, prueba, producción e instalación. Lograr la necesaria integración
de alto nivel puede ser difícil y no siempre sucede.
Desarrollo de sistemas no integrados (en serie)
En un proyecto de desarrollo tradicional, un grupo funcional diferente es responsable

de cada etapa del proyecto. Por ejemplo, el grupo de marketing especifica el concepto
inicial y los requisitos del usuario, luego el grupo de diseño define las especificaciones
técnicas y crea el diseño del sistema, luego el grupo de fabricación determina cómo
fabricarán el producto, y así sucesivamente. Incluso cuando un gerente de proyecto
supervisa el proceso, el trabajo en cada etapa permanece centrado en gran medida
en un área funcional e involucra mínimamente a las otras áreas. El proyecto es una
serie de "entregas" en las que un grupo funcional entrega su trabajo al siguiente. En
cada etapa toma el relevo un nuevo grupo funcional, que “hereda” y se ve obligado a
acomodar la producción de las áreas anteriores. Como resultado, el grupo de diseño
debe crear un diseño de producto que se ajuste a los requisitos heredados del
marketing; a su vez, el grupo de fabricación debe desarrollar un proceso de producción
que se ajuste al diseño que heredó del grupo de diseño. Este proceso de desarrollo
en serie, ilustrado en la Figura 14.15, implica poca interacción e intercambio de
conocimientos entre los grupos participantes .
Figura 14.14 Integración horizontal y vertical en proyectos de desarrollo de sistemas.
Figura 14.15 Interacción tradicional entre áreas funcionales durante las fases de desarrollo de un sistema
proyecto.
Fuente: Adaptado de Wheelwright S. y Clark K. Revolutionizing Product Development. Nueva York, NY:
Prensa Libre; 1992, pág. 178.

Dado que los diferentes grupos funcionales trabajan de forma un tanto independiente,
sus decisiones a menudo son incompletas o incorrectas porque no abordan las
necesidades y requisitos de otras áreas funcionales involucradas en el proyecto. Como
resultado, por ejemplo, el grupo de marketing especifica un requisito que no es realmente
necesario, pero el grupo de diseño lo hereda y debe incorporarlo al diseño del producto;
el grupo de fabricación hereda entonces el diseño, que descubre que será difícil o
costoso de producir. Cada grupo funcional que ingresa al proceso debe esforzarse por
acomodar los compromisos hechos por grupos anteriores. Cuando encuentra un
compromiso previo (sobre un requisito, diseño, procedimiento, etc.) que es erróneo o
difícil de implementar, debe solicitar una modificación al compromiso de los otros grupos.
Este intercambio de ida y vuelta entre grupos da como resultado numerosas solicitudes
de cambio, lo que retrasa el progreso y aumenta los costos. El problema es la falta de
integración horizontal y vertical: una falla de los grupos involucrados al principio del
proceso para abordar el ciclo de vida completo del sistema y las necesidades de los
grupos funcionales que luego heredarán y tendrán que vivir con las consecuencias de
sus decisiones.
Un enfoque integrado para el desarrollo de sistemas es la ingeniería concurrente.
14.13 Ingeniería Concurrente

La ingeniería concurrente se implementa con un equipo multifuncional estructurado como un equipo
matricial o una organización de proyectos puros. Cada grupo, departamento o contratista responsable
o influenciado por alguna parte del proyecto tiene la oportunidad de participar temprano en el
proyecto y contribuir a las decisiones clave.
Contribuyen a las decisiones mucho antes de que realmente comiencen a diseñar, producir, probar
u operar el sistema (Figura 14.16). A diferencia del desarrollo de sistemas en serie, las transferencias
no existen porque todas las partes tienen algo que ver con todo.
La integración horizontal y la integración vertical se logran de una sola vez.
En las decisiones de ingeniería concurrentes sobre el diseño, el desarrollo, la producción y la
operación se superponen, lo que reduce en gran medida la duración del proyecto. Por ejemplo, el
proceso de fabricación de troqueles para estampar paneles de carrocería de automóviles, que es
costoso y requiere mucho tiempo, no suele ocurrir hasta que se acerca el lanzamiento del producto.
Sin embargo, con la ingeniería concurrente, los troqueles se diseñan y producen poco después de
que se hayan diseñado los paneles de la carrocería, lo que ocurre meses antes del lanzamiento y
da suficiente tiempo para resolver errores en los troqueles y hacer cambios si es necesario.
El diseño simultáneo de los paneles y las matrices por sí solo puede reducir el tiempo de preparación
de la producción de un automóvil nuevo en más de un año.
La ingeniería simultánea también mejora las compensaciones entre las características del
producto y las capacidades de producción. Trabajando juntos, los diseñadores de productos y
procesos pueden descubrir cambios sutiles en las características de diseño de productos que serían
transparentes para el cliente pero que aprovecharían las capacidades de producción existentes. El
resultado: costos de producción más bajos debido a menos errores de producción y reelaboración,
y menos problemas de uso por parte del cliente y reclamos de garantía.
Figura 14.16 Interacción concurrente entre áreas funcionales en el desarrollo de sistemas.
Fuente: Adaptado de Wheelwright S. y Clark K. Revolutionizing Product Development. Nueva York, NY:
Prensa Libre; 1992, pág. 178.
organización del equipo
Se organiza un equipo de ingeniería concurrente para maximizar la comunicación y el control de los miembros
del equipo sobre las decisiones de diseño. Esto se logra de la siguiente manera: 17
• Autonomía. Los miembros de un equipo de ingeniería concurrente quedan liberados de obligaciones

no relacionadas y se comprometen plenamente con el esfuerzo de desarrollo. • El mejor caso es
tiempo completo, duración completa. Idealmente, los miembros están involucrados en todas las
decisiones a lo largo de todo el proceso de desarrollo de sistemas. Eso es lo que significa
"concurrente".
• Colocado. Los miembros del equipo trabajan muy cerca y comparten una oficina, lo que fomenta
conversaciones informales frecuentes y espontáneas. Las reuniones semanales formales
periódicas se reemplazan en gran medida por reuniones y reuniones informales continuas.
• Tamaño pequeño. El equipo es lo suficientemente pequeño para permitir una comunicación abierta
y alentar el compromiso del equipo, pero lo suficientemente grande para representar a todos los
áreas funcionales afectadas, clientes y proveedores clave. Unos seis miembros del
equipo es lo óptimo, aunque entre 10 y 20 pueden ser efectivos. Si el tamaño supera los
20, se forman subequipos más pequeños y los coordina un grupo directivo entre equipos.
• Equipo de hacedores. Cada miembro es especialista en alguna área (ingeniería de diseño,

fabricación, marketing, compras, etc.), pero se espera que asuma una amplia gama de
responsabilidades y obligaciones. Los miembros son personas que "pueden hacer",
dispuestas a visitar clientes y proveedores, trabajar en el diseño y hacer trabajos de
modelado, ensamblaje y cualquier otra cosa que se necesite hacer.
Estas características reflejan las de los equipos ágiles como se describe en el capítulo anterior.
Pero la ingeniería concurrente es más que simplemente organizar a las personas en un equipo.
Es tomar personas normalmente involucradas en una sola etapa del proceso de desarrollo del
sistema e involucrarlas en las otras etapas. Los diseñadores de productos recorren la fábrica para
ver cómo se fabrican sus diseños y qué características del diseño dificultan o facilitan la producción.
Al mismo tiempo, los ingenieros de producción y los trabajadores de ensamblaje hablan con los
diseñadores para comprender por qué una característica de diseño es importante y debe
conservarse. Algunos fabricantes de automóviles requieren que sus diseñadores pasen un día
completo cada pocos meses ensamblando la parte del automóvil que ayudaron a diseñar.
Hay otras formas en que las organizaciones organizan equipos para lograr verticalidad.
e integración horizontal. El siguiente ejemplo describe dos.
Ejemplo 14.4 Desarrollo de sistemas en

Motorola y Lockheed-Martin 18
El ciclo de desarrollo de sistemas de Motorola incluye las fases de definición de productos,

desarrollo de contratos, desarrollo de productos y finalización del programa. El proceso
enfatiza la integración de funciones para desarrollar productos innovadores y la utilización
efectiva de recursos para el desarrollo rápido de productos.
Los proyectos son conducidos por un equipo multifuncional central responsable de la mayoría
de las decisiones de desarrollo y del trabajo de diseño detallado, así como de especificar
requisitos de recursos y el establecimiento de objetivos de rendimiento. Las unidades

funcionales brindan apoyo al equipo central.
El enfoque de equipo central se usa cuando la velocidad es crítica, como en proyectos
para crear sistemas con arquitecturas completamente nuevas o en mercados que cambian
rápidamente. Para un proyecto de desarrollo de un nuevo sistema de buscapersonas, el
equipo estaba formado por un director de proyecto y ocho miembros de ingeniería industrial,
robótica, ingeniería de procesos, adquisiciones, diseño de productos, fabricación, recursos
humanos y contabilidad/finanzas, además de un miembro de Hewlett Packard , el proveedor
de un componente crucial en el sistema. Para animar a los extraños a "observar" al equipo
y ofrecer sugerencias, trabajaron en una oficina acristalada ubicada en medio de una
planta de fabricación. El equipo creó el plan de trabajo para el proyecto y, después de
obtener la aprobación de la alta gerencia, asumió la responsabilidad de realizar la mayor
parte del proyecto. El proyecto se completó en 18 meses (la mitad del tiempo habitual para
un proyecto de ese tamaño), cumplió con el objetivo de costo (que fue mucho más bajo de
lo normal) y arrojó un producto de alta calidad y confiabilidad.
La división de desarrollo avanzado de Lockheed-Martin, llamada "Skunk Works", tiene

la reputación de desarrollar diseños radicales y aviones y vehículos espaciales
revolucionarios. 19 El término “Skunk Works” es una marca registrada de Lockheed, pero
en el uso común se refiere a un equipo de proyecto autónomo que trabaja en tecnología
avanzada que puede lograr resultados más rápidamente y a un costo menor que los
proyectos de desarrollo tradicionales. Para cada esfuerzo de desarrollo, Skunk Works
selecciona personalmente al gerente del proyecto y al equipo multifuncional.
A diferencia de los equipos principales de Motorola, que dependen de equipos funcionales
para obtener recursos y soporte, cada equipo de Skunk Works es totalmente autónomo y
controla prácticamente todos los recursos que necesita. El equipo es similar a una unidad
comercial separada: trabaja por sí solo y tiene la autoridad para solicitar recursos y
subcontratar trabajo. El énfasis en los equipos de Skunk Works está en la excelencia
técnica y la velocidad. Aunque los proyectos tienden a seguir ampliamente las fases
familiares de concepción, definición, etc., el equipo es libre de crear procedimientos y
estándares que mejor se adapten a los objetivos de un proyecto. Los miembros del equipo
se seleccionan por su alta competencia, amplias habilidades, fuerte compromiso y
capacidad para pensar de inmediato. Están ubicados en el mismo lugar, generalmente en
un sitio aislado para aumentar la motivación y el trabajo en equipo y para mantener el secreto. Aparte
de los presupuestos y los procedimientos generales, el equipo recibe instrucciones

mínimas de la alta dirección. Desde su inicio en la Segunda Guerra Mundial, Skunk Works
se ha convertido en un modelo para crear aviones y vehículos espaciales altamente
innovadores y de vanguardia de forma rápida y económica.
Ver Capítulo 10
Un ejemplo es el caza F117 Stealth mencionado en el Capítulo 10. 20 El Aire

Force quería un avión de producción de costo relativamente bajo que fuera difícil de
detectar en el radar (sigilo). El equipo de Skunk Works creó un diseño radical que utilizó
nuevos materiales pero minimizó los costos mediante el uso de un motor, computadoras,
controles de vuelo y otras partes de aeronaves preexistentes. El proyecto se completó en
un tiempo récord: 31 meses. El costo de la investigación, el desarrollo y la producción de
59 aviones fue de $ 6600 millones, considerado bajo en el momento en que otros
programas de aeronaves superaban en $ 1000 millones el presupuesto. La eficiencia y el
bajo costo se atribuyeron en parte al equipo de desarrollo pequeño (unos pocos cientos
de personas en la fase de diseño), que minimizó la burocracia y maximizó la comunicación
y el control del proyecto.
Equipos de peso pesado
Los equipos de Motorola descritos en el ejemplo 14.4 son lo que Wheelwright y Clark 21
denominan equipos de “peso pesado”; son el desarrollo de sistemas equivalente a las
organizaciones puras de proyecto descritas antes. Los gerentes de proyecto también son pesos
pesados porque están mínimamente al mismo nivel que los gerentes funcionales, lo que les
otorga influencia organizacional para ejercer una fuerte influencia sobre todos los involucrados
en el proyecto de desarrollo. Los equipos de Lockheed-Martin Skunk Works son totalmente
autónomos e incluso "más pesados" en el sentido de que controlan todos los recursos que
necesitan para realizar el trabajo. Al ser autónomo, por supuesto, el equipo solo puede culparse
a sí mismo si el proyecto falla.
Tanto los equipos centrales multifuncionales como los equipos autónomos brindan un fuerte
énfasis en el objetivo del proyecto, disciplina para hacer frente a la complejidad y
consistencia entre los detalles del diseño. Los equipos definen y enfocan los requisitos del cliente, y los
traducen en términos que todos en el equipo puedan entender. Los pasos del proceso de desarrollo y los
detalles del sistema se manejan de manera coherente, minimizando las inconsistencias y los cambios
posteriores.
Una desventaja de los equipos pesados es que los componentes o elementos individuales del sistema
de elementos finales pueden no alcanzar la misma excelencia técnica de alto nivel que tendrían si hubieran
recibido la atención de un área funcional tradicional. Aunque un equipo multidisciplinario podría diseñar un
componente que cumpla con los requisitos y se integre con todo el sistema, el componente podría contener
fallas que solo un equipo funcional de especialistas podría haber evitado. Una forma de evitar ese
problema es involucrar a especialistas en las revisiones de diseño, mencionadas en los Capítulos 9 y 12.

14.14 Resumen
La estructura se refiere a la forma en que las organizaciones intentan alcanzar los objetivos y
responder a los problemas del entorno. Dos características clave de la estructura son la
diferenciación y la integración; la primera es la forma en que las organizaciones se subdividen
en subunidades especializadas; el último es cómo vinculan las subunidades para coordinar sus acciones.
Las organizaciones tradicionalmente diferencian las subunidades a lo largo de líneas funcionales,
geográficas, de clientes y de procesos, e integran las subunidades con reglas, procedimientos,
planes coordinados y cadenas de mando. Estos medios son efectivos cuando el ambiente es
estable y las tareas son seguras, pero menos cuando las metas y tareas involucran cambios
frecuentes, alta complejidad e incertidumbre—el caso de la mayoría de los proyectos.
Cada organización de proyecto está estructurada de manera única para adaptarse a las
metas y el entorno del proyecto. Está formado para incluir todas las funciones necesarias e
integrar esas funciones a través de roles de gestión que enfatizan las relaciones horizontales.
Cuando el objetivo del proyecto involucra solo una especialidad, el equipo del proyecto está
compuesto por personal de un área funcional. Más común es cuando requiere múltiples
funciones y el equipo está compuesto por miembros provenientes de todas las subunidades
funcionales involucradas o impactadas por el proyecto; esta forma de organización, denominada
grupo de trabajo o equipo multifuncional, está dirigida por un facilitador o coordinador del
proyecto. Los expedidores y coordinadores dirigen el trabajo del proyecto, pero carecen de
autoridad para controlar los recursos o influir fuertemente en el comportamiento de los miembros del equipo.
Para proyectos que tienen mucho en juego y requieren un compromiso de recursos
considerable, la forma apropiada de organización es el proyecto puro. Esta forma le da al
objetivo del proyecto la más alta prioridad y al gerente del proyecto una mayor capacidad para
comandar y controlar los recursos que se necesitan, aunque tiende a ser costoso en términos
de inicio y cierre.
El formulario de organización matricial crea equipos de proyecto al compartir miembros y
recursos de todas las subunidades funcionales. Es efectivo para crear un flujo continuo de
equipos de proyecto, sin embargo, puede ser difícil de implementar e induce conflictos
organizacionales.
Muchas empresas utilizan un compuesto de formas: la matriz y el proyecto puro para
grandes proyectos, equipos multifuncionales y grupos de trabajo para los más pequeños. La mayoría
de las organizaciones de proyectos son híbridos y combinan combinaciones de fuerzas de trabajo,
proyectos puros y formas matriciales. 22
El jefe de proyecto de un gran proyecto a menudo cuenta con la asistencia de especialistas y
representantes funcionales en la oficina del proyecto. Esta oficina de proyectos se encarga de la
contratación, la planificación, la programación y el control, pero su función principal es la integración
de las unidades funcionales. En un proyecto a gran escala que involucra a múltiples organizaciones,
el patrocinador del proyecto a veces asume la integración de todos los esfuerzos de las
organizaciones. Para un proyecto grande y técnicamente complejo, la responsabilidad generalmente
la maneja el contratista principal o un contratista de integración especial. En las empresas que deben
coordinar los esfuerzos de múltiples proyectos, la supervisión e integración de los proyectos está a
cargo de la oficina de proyectos, PMO u oficina de programas.
La integración del proyecto implica coordinar tanto los esfuerzos de múltiples unidades (integración
horizontal) como las fases del proyecto (integración vertical). En los proyectos de desarrollo de
sistemas, esta integración se logra mediante la combinación de representantes de todas las partes
afectadas por el sistema del elemento final en un solo equipo durante la duración del proyecto, una
práctica denominada ingeniería concurrente. El equipo se forma al inicio del proyecto y tiene los
recursos y la autoridad para tomar decisiones que afectan el proyecto y el ciclo de vida completo del
producto o sistema final.
1. ¿Qué significan los términos “diferenciación” e “integración”?

2. ¿Cuáles son las formas tradicionales de diferenciación? Enumere algunas empresas que
actualmente usan cada uno.
3. Enumerar las diversas formas de integración. Dé ejemplos de cada uno. cual de
¿Son estas formas de integración “laterales”?
4. ¿Cuáles son las ventajas de las organizaciones funcionales? ¿Cuales son las desventajas?
5. ¿Qué distingue a las formas de proyecto de otras formas de organización?

6. Describa la responsabilidad y autoridad de cada uno de los siguientes:
• Dinamizador de
proyectos • Coordinador de
proyectos • Líder de proyectos en un
proyecto puro • Líder de proyectos en una matriz.
7. Describa las aplicaciones, ventajas y desventajas de cada uno de los

siguiendo:
• Grupo de trabajo del
proyecto • Equipo del
proyecto • Proyecto puro y centro de proyectos

• Matriz.
8. Dé algunos ejemplos de organizaciones donde cada uno de estos proyectos forma

ha sido usado.
9. ¿Qué es la oficina de proyectos? Describa su propósito. ¿Quién está en la oficina de proyectos?

¿Cómo deben seleccionarse los miembros de la oficina del proyecto?
10. ¿Qué se entiende por organización informal? Da algunos ejemplos. ¿Cómo ayuda o dificulta la
organización formal? ¿Cómo pueden ser influenciados por el director del proyecto sus aspectos
beneficiosos?
11. Describa el papel del contratista principal y el contratista de integración en
proyectos a gran escala.

12. Una forma de contratista de integración es el consultor de bodas; otro es el consultor que
organiza las reuniones de la escuela secundaria. Para cada:
• Enumerar los diversos grupos, organizaciones y partidos individuales que

están involucrados y deben ser integrados.
• Describa la relación entre estas partes y cómo el consultor coordina sus esfuerzos,
tanto antes como durante la boda o reunión.
13. ¿Qué partes deberían o podrían incluirse en un equipo de ingeniería concurrente? ¿Cuáles
son las contribuciones de cada uno? ¿Cómo mejora su inclusión en el equipo (a) el proceso
de desarrollo de sistemas y (b) el producto final resultante?
14. ¿Cuáles cree que son algunas de las principales dificultades para cambiar de un enfoque
de desarrollo tradicional no integrado a un enfoque de ingeniería concurrente?
1. En su proyecto, ¿cómo está organizada la organización matriz, por ejemplo, funcional

o geográficamente? Muestre el organigrama, su desglose general y las relaciones.
2. ¿Cómo encaja su proyecto en el organigrama de la matriz?

¿organización?
3. ¿Qué forma de estructura de proyecto se utiliza en su proyecto? Mostrar el
organigrama del proyecto; indicar los roles clave y los vínculos de autoridad y
comunicación entre ellos.
4. ¿Cómo se desarrolló la estructura del proyecto? ¿“Evolucionó” durante el proyecto?
¿Quién diseña o influye en la estructura del proyecto? ¿Qué papel tuvo el director
del proyecto en su diseño? ¿El diseño es similar a los utilizados en otros proyectos
similares en la organización?
5. Critique el diseño del proyecto. ¿Es apropiado para el objetivo del proyecto, el
organización matriz y el medio ambiente?
6. ¿Existe una oficina de proyectos? ¿Hay también una oficina de proyectos o una
oficina de programas? En cada caso: (a) describa la oficina y cómo se utiliza; (b)
describir a los miembros del personal de la oficina del proyecto o programa:
representantes, especialistas, etc. ¿Cuál es el propósito del personal de la oficina
del proyecto? Describir las diversas tareas y funciones a cargo de la oficina de
proyectos. ¿Cuál es la participación de los miembros en la oficina del proyecto
(tiempo completo, según sea necesario, etc.)? ¿Cuál es la relación jerárquica entre
el director del proyecto y los miembros de la oficina del proyecto?
7. ¿Cómo integra el director del proyecto las áreas funcionales?
8. ¿Están involucrados los contratistas principales y asociados? De ser así, cuál es la
función de la empresa que está estudiando (principal, subcontratista o proveedora)
y cómo encaja en la estructura de todas las organizaciones que contribuyen al
proyecto. Si corresponde, discuta la participación de contratistas de integración o
contratistas de líderes de equipo.
9. ¿El proyecto aplicó ingeniería concurrente? Si es así, comenta cómo fue.
aplicado.
Caso 14.1 Organización para el Proyecto LOGON
Iron Butterfly Company es una empresa mediana de ingeniería y fabricación que se

especializa en sistemas de almacenamiento y manejo de materiales. La empresa
compra la mayoría de los subsistemas y componentes de sus productos y los ensambla
para satisfacer los requisitos del cliente. Cada sistema IBC se fabrica según las
especificaciones del cliente y la mayor parte del trabajo de la empresa consiste en el
diseño, montaje, instalación y verificación del sistema. Los 250 empleados de la
empresa se dividen aproximadamente en partes iguales entre cinco divisiones:
ingeniería, diseño, fabricación, servicio al cliente y marketing. Recientemente, la
competencia ha obligado a la empresa a expandirse hacia los sistemas de
almacenamiento computarizados a pesar de su experiencia y conocimientos bastante limitados en ese ca
Midwest Parcel Distribution Company ha adjudicado a IBC un gran contrato para un
sistema robótico para la colocación, el almacenamiento, la recuperación y el
enrutamiento de contenedores de envío para camiones y trenes. Este sistema, llamado
Logistical Online System, LOGON, se desarrollará e instalará en el principal centro de
distribución de Midwest en Chicago. El contrato tiene un precio fijo de $14,5 millones e
incluye diseño, fabricación e instalación en el centro. IBC se adjudicó el contrato porque
fue la oferta más baja y tiene un historial sobresaliente de calidad y servicio al cliente.
Una cláusula en el contrato impone una multa de $1,000 diarios por no cumplir con la
fecha de entrega especificada.
En varios momentos a lo largo del proyecto estimado de 47 semanas, estará
involucrado personal de las divisiones funcionales de diseño, fabricación, adquisición y
servicio al cliente, la mayoría a tiempo completo durante entre 4 y 18 semanas. En el
pasado, la empresa ha establecido equipos de gestión de proyectos ad hoc compuestos
por un coordinador de proyecto y miembros de las áreas funcionales. Estos equipos
son entonces responsables de planificar, programar y presupuestar el trabajo real que
deben realizar los departamentos funcionales. Los miembros del equipo sirven
principalmente como enlaces con las áreas funcionales y trabajan a tiempo parcial en
los equipos.
El contrato LOGON difiere de otros sistemas IBC, tanto en su uso intensivo de
operación computarizada en tiempo real a través de terminales remotas, como en su
Talla. Aunque IBC tiene alguna experiencia previa con sistemas de almacenamiento en
tiempo real, la tecnología involucrada está en constante evolución. IBC contrató
recientemente a personas con los antecedentes necesarios para el proyecto. Además,
ha firmado contratos con CRC y CreativeRobotics para proporcionar hardware
informático y robótico, y asistencia con el diseño, la instalación y la comprobación del
sistema.
El contrato LOGON se encuentra entre los más grandes que IBC ha realizado jamás.
La empresa se encuentra actualmente en medio de otros dos proyectos que absorben
aproximadamente las tres cuartas partes de su capacidad laboral, está finalizando un
tercero que involucra solo la división de servicio al cliente y tiene dos propuestas
sobresalientes para proyectos pequeños bajo revisión.
Discuta cómo organizaría el proyecto LOGON si fuera el presidente de IBC. Analice
las alternativas disponibles para el proyecto LOGON y las ventajas y desventajas
relativas de cada una. ¿Qué suposiciones se deben hacer?
Caso 14.2 Cámara estenopeica y óptica, Inc.: ¿Por

qué necesitamos un director de proyecto?
Beverly es la recién nombrada vicepresidenta de estrategia de Pinhole Camera and

Optics, Inc. (lema: "Ver el mundo a través de un agujero de alfiler"), una empresa de
fabricación privada de tamaño mediano. Hasta hace poco, la empresa de 14 años había
experimentado un rápido crecimiento mediante el desarrollo de nuevos productos y
procesos de fabricación óptica. Beverly cree que la posición de mercado de la empresa
ha disminuido porque Pinhole no ha podido reaccionar con la suficiente rapidez a los
requisitos cambiantes del mercado y al aumento de la competencia. La empresa se
divide en los departamentos funcionales tradicionales de investigación, marketing,
ventas, producción, etc. Los proyectos de desarrollo de nuevos productos se gestionan
traspasando la responsabilidad entre los directores de los departamentos. Beverly cree
que este es el mayor contribuyente a la incapacidad de Pinhole para identificar y
responder al mercado.
oportunidades, y le gustaría crear una nueva posición, gerente de nuevos productos, con
el fin de integrar los departamentos durante los proyectos de desarrollo de productos.
Esta posición sería el gerente de proyecto de desarrollo de nuevos productos.
El dueño de la empresa, Ovidio Pinoli, no está de acuerdo. Sostiene que los gerentes
de los departamentos funcionales, la mayoría de los cuales han estado en la empresa
desde sus inicios, son excelentes gerentes, realmente conocen sus especialidades y, por
lo general, pueden trabajar juntos. Siente que no hay necesidad de crear el puesto,
aunque se pregunta de dónde vendría una persona así. En cambio, el Sr. Pinoli sugiere
que para cada nuevo proyecto se elija a uno de los gerentes de departamento para
coordinar los esfuerzos de todos los departamentos. El gerente sería seleccionado del
departamento que tiene el papel más importante en el proyecto; es decir, según se trate
principalmente de investigación, comercialización o producción.
Beverly está convencida de que la idea del Sr. Pinoli no mejorará la situación.
Decide preparar un informe escrito formal que abordará los pros y los contras de las
sugerencias del Sr. Pinoli y lo persuadirá de que el nuevo puesto de gerente de nuevos
productos debe ser ocupado por alguien que no sea un gerente de departamento
funcional. También quiere describir cómo los nuevos proyectos de desarrollo de Pinhole
podrían estar mejor organizados y dotados de personal.
Si usted fuera Beverly, ¿por qué no estaría de acuerdo con la sugerencia del Sr. Pinoli
de que los gerentes departamentales existentes actúen como gerentes de proyecto?
¿Qué diría en el informe para argumentar a favor del cargo de gerente de nuevos
productos?
Caso 14.3 Implementación de una estructura matricial

en un laboratorio de I+D 23
El laboratorio de I+D de una gran corporación multinacional holandesa cumplía dos

funciones: desarrollo de procesos de productos y departamentos funcionales de apoyo;
dividió estos dos roles aproximadamente 50/50. Los empleados del laboratorio se agruparon en
13 departamentos: siete (con 85 empleados) dedicados principalmente al desarrollo de

productos/procesos, ocho (con 84 empleados) a actividades de apoyo al servicio.
Se tomó la decisión de reestructurar el laboratorio de una forma funcional a una matriz,

y se nombró un comité de políticas para redactar una propuesta para la reestructuración.
Después de un año de discusión, se introdujo una “matriz equilibrada” y se nombraron cinco
directores de proyecto. Los gerentes funcionales expresaron su inquietud por la matriz
equilibrada y sugirieron en cambio una "matriz débil", pero fueron rechazados. Los gerentes
funcionales encargados del desarrollo de productos/procesos se quejaron de la pérdida de
autoridad operativa. Los gerentes responsables de las actividades de soporte tenían una
queja diferente: en el pasado, su trabajo de apoyo a las partes interesadas fuera del
laboratorio de I+D siempre había tenido prioridad sobre las actividades de desarrollo, que
realizaban en el tiempo restante. La matriz ahora cambió eso, dando prioridad a las
actividades de desarrollo con fechas de vencimiento obligatorias.
Los gerentes funcionales, que "no se sintieron llamados a cooperar mucho", se rebelaron
y dejaron de hacer contribuciones constructivas a los proyectos en los que participaban sus
departamentos. Esto obligó a los gerentes de proyecto a intentar administrar los proyectos
sin ayuda de nadie, lo que resultó en sobrecargas de trabajo graves. Tratando de acelerar
el trabajo del proyecto, pasaban sigilosamente por alto a los gerentes funcionales cada vez
que visitaban los departamentos funcionales.
Otro factor que contribuyó a la ruptura fue el hecho de que los gerentes de proyectos
recibieron salarios más altos y mejores autos de la empresa que los gerentes funcionales.
Dos veces los gerentes funcionales solicitaron que algunos proyectos en el portafolio de
proyectos fueran delegados a sus departamentos. La primera vez crearon una lista de 22
proyectos grandes y 26 pequeños (“pequeños” definidos como aquellos que requieren
menos de 1000 horas de trabajo por medio año, muchos de los cuales involucraban solo a
uno o dos departamentos) y propusieron que los pequeños se delegaran a sus departamentos
El comité de política contrarrestó esto cancelando algunos proyectos pequeños e integrando
otros en los grandes proyectos. Seis meses después, los gerentes funcionales notaron que
algunos de los proyectos más grandes involucraban a siete u ocho departamentos y que
era difícil coordinar el trabajo entre ellos. Propusieron que los grandes proyectos se
dividieran en subproyectos con la responsabilidad delegada a los gerentes de subproyectos
dentro de los departamentos funcionales. Este
Los gerentes de proyecto se opusieron a la propuesta y la rechazaron.

Los gerentes de proyecto, frustrados porque el personal a menudo se cambiaba entre
proyectos, propusieron que el personal asignado a proyectos más grandes se transfiriera
temporalmente (en lugar de cambiar) a otros departamentos. También propusieron que
las personas en proyectos más grandes sean asignadas para permanecer allí
“semipermanentemente”, por un período de, digamos, 6 meses, y dentro de ese período
no serían reasignados. Después de un año de deliberación, ambas ideas se implementaron
a pesar de la oposición de los gerentes orientados al soporte porque comprometían su
capacidad para dar prioridad a las solicitudes de servicio. Los responsables de producción
y marketing, que querían una respuesta rápida a sus solicitudes, apoyaron estas
objeciones.
Inicialmente, las tareas de soporte de servicio que requerían más de 300 horas estaban
a cargo de los gerentes de proyecto y las que requerían menos las manejaban los
gerentes funcionales; más tarde, el umbral de 300 horas se redujo a 100 horas.
Todas las solicitudes de servicio se enviaban directamente a los departamentos para su
posterior asignación a gerentes funcionales o de proyecto, pero los gerentes de proyecto
sospechaban que los gerentes funcionales manipulaban la regla al crear proyectos de
servicio que generalmente requerían menos de 100 horas. Por lo tanto, propusieron que
las solicitudes de servicio se les enviaran directamente, pero esto fue rechazado.
Tres años después de iniciar la estructura de la matriz, el comportamiento destructivo
disminuyó lentamente; todavía existían desacuerdos, pero el ambiente mejoró.
Los gerentes de los departamentos orientados al soporte admitieron que la estructura
matricial mejoró el establecimiento de objetivos y el control del proyecto, pero aun así
favorecieron una forma más débil de matriz sobre la matriz equilibrada. Los gerentes de
los departamentos orientados al desarrollo llegaron a aceptar la matriz equilibrada, aunque
el gerente general no quedó satisfecho y sugirió que todos los departamentos deberían
dividir su personal en dos grupos, uno para el desarrollo de procesos y productos y otro
para el trabajo de apoyo.
Preguntas
1. ¿Cuáles habrían sido las funciones y responsabilidades de los gerentes

funcionales antes de la implementación de una estructura matricial? ¿Cómo
contribuyó el cambio de roles al conflicto después de la implementación de la
matriz?
2. Comente la queja de los gerentes funcionales de los departamentos orientados
al soporte acerca de las fechas de vencimiento que se aplican para el trabajo
de desarrollo de productos. ¿Qué posibles soluciones sugieres?
3. Muchos de los proyectos requerían la participación de solo uno o dos
departamentos. Comente cómo se debería haber tenido en cuenta este hecho
en el diseño de la estructura organizativa.
4. ¿Por qué tendría sentido que los proyectos más pequeños fueran manejados
por gerentes funcionales?
5. ¿Por qué tendría sentido la propuesta de gerentes de subproyectos en
departamentos funcionales para los proyectos más grandes?
6. A veces, las propuestas razonables se "politizan". ¿Qué papel crees que juega
la sospecha mutua en esto? ¿Cómo podría haberse evitado esto en este
caso? Comente la idea de que los gerentes de proyecto deben mostrar un
"liderazgo integrador".
7. En este caso tomó un año de discusiones antes de implementar la estructura
matricial y otros 3 años antes de que comenzara a funcionar razonablemente
bien. Comenta el tiempo que crees que debería llevar implementar una
estructura matricial. ¿Qué factores deben ser considerados?
Notas finales
1. La discusión sobre la estructura de la organización y los mecanismos de integración en entornos de alta tecnología está a
cargo de Galbraith J. Environmental and Technology Determinants of Organisation Design. En: Lorsch
JW y Lawrence PR, (eds.). Estudios en Diseño de Organizaciones. Homewood, IL: Irwin-Dorsey; 1970, págs.
113–139.
2. Véase Galbraith J. Diseño de Organizaciones Complejas. Lectura, MA: Addison-Wesley; 1973.
3. Peters T. y Waterman R. En busca de la excelencia. Nueva York: Warner Communications; 1984, págs. 127–
130.
4. Véase Davis K. El papel de la gestión de proyectos en la fabricación científica. Transacciones IEEE de
Gestión de Ingeniería 1962; 9(3): 109–113.
5. La organización matricial, sus aplicaciones e implementación se describen en Davis S. y Lawrence P.
Matriz. Lectura, MA: Addison-Wesley; 1977.
6. McCann J. y Galbraith J. Relaciones interdepartamentales. En: Nystrom P. y Starbuck W. (eds.). Manual
de Diseño Organizacional II, núm. 61, Nueva York: Oxford University Press; 1981.
7. Peters y Waterman, En busca de la excelencia, págs. 307–308.
8. Véase Thomas R., Keating J. y Bluedorn A. Estructuras de autoridad para la gestión de proyectos. Diario de
Ingeniería y Gestión de la Construcción 1983; 109(4): 406–422.
9. Cusumano M. y Selby R. Secretos de Microsoft. Nueva York: Prensa Libre; 1995, págs. 74, 235–236, 248–249.
10. Burns J. Gestión eficaz de programas. En: Lorsch J., Lawrence P. (eds.). Estudios en Organización
Diseño. Homewood, IL: Irwin-Dorsey; 1970, págs. 140–152.
11. Archibald R. Gestión de programas y proyectos de alta tecnología. Nueva York: John Wiley & Sons; 1976,
Capítulo 4.
12. Esta discusión se basa en la contratación del sistema de armas de Livingston J. Revisión de negocios de Harvard. Julio-
agosto de 1959; 83–92.
13. Ibíd., 85.
14. Adaptado de Lammie J. y Shah D. Gestión de la construcción: MARTA en retrospectiva. Diario de
Ingeniería y Gestión de la Construcción 1984; 110(4): 459–475.

15. Discusión completa de los contratistas de integración proporcionada por Sayles L. y Chandler M. Managing Large
Sistemas: Organizaciones para el Futuro. Nueva York: Harper & Row; 1971, págs. 253–271.
16. Arndt D., Clampett L., Fedder W., Foxx K., Lorenz C., Ward N. y Worthington J. Análisis del rol
del equipo AIM en la integración de Knoll Pharmaceuticals en Abbott Laboratories. Loyola
Universidad de Chicago; 13 de julio de 2002.
17. De Nicholas J. Ingeniería concurrente: superación de obstáculos para el trabajo en equipo. Producción e Inventario
Revista de gestión 1994; 35(3): 18–22.
18. Porciones adaptadas de Wheelwright S. y Clark K. Revolutionizing Product Development. Nueva York:
La Prensa Libre; 1992, págs. 159–162, 200–203.
19. Su SR-71, un avión de reconocimiento de alto rendimiento desarrollado en la década de 1960, todavía tiene el
récord de velocidad cinco décadas después. Ver Rich B. y Janos L. Skunk Works. Boston: pequeño, marrón y
Compañía; 1994.
20. Véase Aronstein D. y Piccirillo A. Have Blue and the F-117A: Evolution of the “Stealth Fighter”. Descansa en,
VA: Instituto Americano de Aeronáutica y Astronáutica; 1997; Stroud M. Cómo voló el F-117A
presupuesto, a tiempo. Diario del inversor; 1 de febrero de 1991.
21. Wheelwright y Clark, Revolutionizing Product Development, págs. 194–196, 202–112.
22. Las fortalezas y debilidades de diferentes formas de proyecto se describen en Bannerman P. Risk Implications of
Estructuras de organización de proyectos de software, 20.ª Conferencia australiana de ingeniería de software, IEEE
Computer Society, del 14 al 17 de abril de 2009, Gold Cost, Australia.
23. Adaptado de De Laat, PB. Gestión matricial de proyectos y luchas de poder: Un estudio de caso de una I+D
laboratorio. Revisión de gestión de ingeniería de IEEE, invierno de 1995.

Capítulo 15
Roles del proyecto y partes interesadas
Todo el mundo es un
escenario, y todos los hombres y mujeres meros actores.
—William Shakespeare Como gustéis
Cuando una organización emprende un proyecto, forma un equipo de proyecto puro, un equipo
matriz o un grupo de trabajo, pero a menos que sea un proyecto puro, la mayoría de las
personas del equipo son "prestadas": provienen de departamentos funcionales o contratistas y
trabajan en el proyecto. sólo durante el tiempo que sean necesarios. La gestión de proyectos
“hace que el trabajo se realice a través de personas externas” 1: personas de diversos grupos
funcionales y profesionales repartidos por toda la empresa matriz y subcontratistas externos.
Como describen Sayles y Chandler, la gestión de proyectos
trata lateralmente, pero no en el sentido de grupo informal, organización informal. Requiere una capacidad por parte del
gerente para armar un mecanismo organizacional dentro del cual es probable que se alcancen decisiones oportunas y
relevantes [así como] un esquema conceptual para las interfaces de "funcionamiento"... [Es un] dinámico, interactivo,
2
concepto iterativo e intelectualmente desafiante del rol gerencial.
Parte de ser un gerente de proyecto es la capacidad de influir en las personas sin dar órdenes
o tomar decisiones de la misma manera que otros gerentes. La mayoría de los gerentes de
proyectos tienen una gran responsabilidad pero poca autoridad formal, por lo que necesitan un
conjunto de habilidades y un estilo de liderazgo diferentes a los de los gerentes tradicionales.
Por supuesto, el gerente del proyecto es solo uno de los numerosos individuos y grupos que
están involucrados, influyen o son influenciados por un proyecto, denominados colectivamente
como partes interesadas del proyecto. Este capítulo analiza el rol del director del proyecto, las
partes interesadas del proyecto y el rol del director del proyecto en la gestión de las expectativas
de las partes interesadas.
15.1 El Gerente de Proyecto
Rol del Gerente de Proyecto
El director de proyecto es la pieza central de la gestión de proyectos; ella es el pegamento que

mantiene unido el proyecto y el impulsor y agitador que lo impulsa. Ser gerente de proyecto requiere
usar sombreros diferentes, algunos al mismo tiempo; estos sombreros son los de un integrador,
comunicador, tomador de decisiones, motivador, evangelista y emprendedor.
Como figura central en el proyecto, el papel principal del gerente del proyecto es integrar todo y
a todos para lograr las metas del proyecto. El gerente de proyecto ha sido llamado el “metrónomo”
organizacional, la persona que mantiene los diversos elementos del proyecto respondiendo a un
solo latido central. 3
El gerente del proyecto es el centro de comunicación, el embudo a través del cual fluyen la
mayoría de los informes, solicitudes, memorandos y quejas. Acepta aportes de más fuentes y dirige
la información a más receptores que nadie en el proyecto. Entre fuentes y receptores, refina, resume
y traduce la información para mantener a todas las partes interesadas clave bien informadas sobre
los planes, el progreso y los cambios del proyecto. Muchos dicen que los gerentes de proyecto
pasan el 90 por ciento de su tiempo comunicándose; no todos los gerentes de proyectos estarán de
acuerdo con esa cifra, pero prácticamente todos dirán que pasan la mayor parte de su tiempo
comunicándose.
Al ser el centro de comunicación, el gerente del proyecto también es el tomador de decisiones
central para establecer el alcance y la dirección del proyecto, asignar recursos y equilibrar los
criterios de cronograma, costo y rendimiento. Incluso cuando carece de autoridad para tomar
decisiones de alto nivel, a menudo está bien situada para influir en otros que sí toman las decisiones.
El principal factor de motivación en cualquier grupo diverso es un fuerte compromiso con una
meta central. El gerente de proyecto exitoso puede fomentar el entusiasmo, el espíritu de equipo, la
confianza y hacer avanzar al equipo, incluso cuando el trabajo se vuelve estresante y frustrante.
Se podría decir que el director del proyecto es una especie de evangelista que construye la fe en
el proyecto, su valor y viabilidad. Durante la fase conceptual, ella es a menudo la única persona
que ve el panorama general, y si el proyecto se financia o no, a menudo depende de su capacidad
para obtener el respaldo de las partes interesadas influyentes.
El gerente del proyecto también es como un empresario , impulsado a obtener los fondos, las
instalaciones y las personas necesarias para hacer despegar el proyecto y mantenerlo en marcha.
Debe ganarse a los interesados reacios que cuestionan el apoyo o la asignación de recursos al
proyecto. Una vez que el trabajo está en marcha, debe continuar defendiendo el proyecto y, a
veces, luchar por su existencia. Al final, ya sea que el proyecto tenga éxito o fracase, el director
del proyecto es responsable en última instancia.
Ejemplo 15.1: Gutzon Borglum: Project

Manager y escultor 4
Si está familiarizado con las tallas que se muestran en la Figura 15.1 , entonces conoce la
obra de Gutzon Borglum. Más de dos millones de personas al año visitan el Monumento
Nacional Monte Rushmore. La mayoría de los que escuchan el nombre
Gutzon Borglum piensa que fue él quien esculpió los rostros; él era , por supuesto, el
escultor, aunque no de los rostros reales de la montaña. El contrato para el proyecto
especificaba que el monumento “debería ser tallado… por… y/o bajo la dirección de Gutzon
Borglum” y que Borglum disfrutaría de “plena, final y total libertad de autoridad en la
ejecución del diseño del monumento”. .” Esculpió los rostros, pero en un modelo en miniatura
de 1/12 del tamaño de los que estaban en la montaña para que sirviera como guía para los
trabajadores que hacían la "escultura" real, gran parte de la cual consistía en quitar grandes
cantidades de granito con dinamita. taladros pesados y martillos neumáticos.
Proyectos de tan grandiosa envergadura nunca son obra de una sola persona, aunque en
el caso del Monte Rushmore, si alguien debería recibir crédito, tendría que ser Gutzon
Borglum. Muchos otros contribuyeron al proyecto de manera importante, pero fueron los
esfuerzos incansables de Borglum los que produjeron gran parte de la financiación del
proyecto, y su genio y dedicación lo que hizo que sucediera. Escogió el sitio; escribió cartas
y habló personalmente con empresarios, industriales ricos, senadores, congresistas y
presidentes de los Estados Unidos; él
determinó que los rostros serían los de Washington, Jefferson, Roosevelt y

Lincoln; contrató y dirigió la cuadrilla de trabajo; creó los medios innovadores para
trasladar el diseño del modelo a la montaña; y, además, se ocupó de una miríada
de detalles, desde el diseño de los andamios, las plataformas de trabajo, el
tranvía, los montacargas y los edificios del terreno hasta la orquestación de los
desfiles para la inauguración inicial y las ceremonias de inauguración final. La
gente se preguntaba cuándo descansaba o dormía. Por supuesto, de ninguna
manera era perfecto; no siempre tuvo los problemas del proyecto bajo control y
sus esfuerzos en los primeros años fueron criticados por ser desorganizados.
Cuando comenzó el proyecto en 1927, Borglum no estaba completamente seguro
de cómo sería el monumento. Las personas familiarizadas con Borglum quedaron
impresionadas con su talento artístico, pero quedaron aún más impresionadas
con su "capacidad para el afecto, la ira, la generosidad, la tacañería, la nobleza,
la mezquindad, el encanto y lay pura
humildad, repugnancia".
le faltaba 5 Le
“terquedad faltaba modestia
testaruda”. Pensabayen
grande, soñaba en grande, hablaba en grande y no tenía miedo de emprender
cualquier empresa. Su entusiasmo era contagioso.
Figura 15.1 La obra más famosa de Gutzon Borglum atrae a millones de visitantes al año.
Foto cortesía de John Nicholas.
El equipo de trabajo del proyecto estaba formado por 22 hombres. La mayor parte de la escultura la
hicieron usando taladros de 80 libras y martillos neumáticos mientras colgaban del costado de un acantilado.
Se sentaron en arneses diseñados por Borglum que se bajaron por la ladera de la

montaña con cabrestantes manuales. Imagine sus sentimientos, como los describe
el biógrafo Rex Smith:
Taladras mientras cuelgas del costado de un muro de piedra... Desde donde te sientas puedes mirar
montañas y llanuras que se extienden más allá de lo que alcanza la vista. Rodeado por estos vastos
6
espacios, suspendido contra un acantilado de piedra, te sientes empequeñecido e insignificante… e inquieto”.
Borglum era muy estricto con la seguridad, por lo que, a pesar de los peligros, hubo
pocos accidentes y ninguna muerte durante 14 años de trabajo. Borglum nunca fue
amigo de su tripulación, pero se preocupaba por ellos y los cuidaba y, a cambio,
eran leales a él y entre ellos.
Al ver el monumento hoy, nos damos cuenta de que su construcción debió
plantear grandes desafíos, pero que, obviamente, esos desafíos fueron superados.
Borglum, sin embargo, nunca estuvo seguro de que fueran vencidos. Aunque había
seleccionado la montaña, sabía que existía el riesgo de que pudiera contener
algunos desastrosos defectos ocultos (grietas o roca mala) que no se podrían trabajar.
alrededor. De hecho, además de la financiación, fue la forma de la montaña y sus
profundas fisuras lo que determinó que el número de bustos presidenciales fuera
de cuatro. Una y otra vez surgieron obstáculos, se agotaron los fondos y el proyecto
tuvo que detenerse. Pero Borglum y otros partidarios perseveraron para que el
proyecto volviera a revivir. Al final, la talla fue abandonada y el monumento quedó
incompleto porque la nación estaba a punto de verse envuelta en la Segunda
Guerra Mundial y ya no apoyaría el esfuerzo. Apenas unos meses antes de que se
cancelara el proyecto, Borglum murió. Él había sido la principal fuerza impulsora
del proyecto, y hay que preguntarse, si hubiera vivido, ¿cuánto más del monumento
habría completado? Borglum era escultor, pero cuando se trataba de convertir una
montaña en un monumento, era el máximo responsable del proyecto.
Responsabilidades laborales
La principal responsabilidad del gerente del proyecto es entregar el producto final del proyecto de
acuerdo con los requisitos y los términos del contrato y, cuando se especifique, en cumplimiento de
los objetivos de ganancias. Otras responsabilidades específicas varían según el tamaño y la
naturaleza del proyecto, la etapa del proyecto y las responsabilidades delegadas por la alta dirección,
que van en el extremo inferior desde la influencia bastante limitada de un expedidor del proyecto
hasta la centralizada, casi control autocrático de un gerente de proyecto puro.
Aunque las responsabilidades varían, por lo general incluyen: 7
• Planificación de tareas del proyecto y resultados finales, creación de la EDT, cronograma y

presupuesto, coordinar tareas y asignar recursos.
• Selección y organización del equipo del proyecto. •
Trabajar y negociar con partes interesadas influyentes (clientes, gerentes funcionales,
contratistas, simpatizantes y alta dirección) y gestionar sus expectativas. • Seguimiento del
estado del proyecto y comunicación del estado a las partes interesadas. • Identificación de
problemas técnicos y funcionales. • Resolver problemas directamente o saber dónde encontrar
ayuda. • Abordaje de crisis y resolución de conflictos.
La mayoría de los gerentes de proyectos medianos y grandes reportan en una capacidad de línea a
un ejecutivo de alto nivel. Se espera que supervisen y narren el estado técnico y financiero del
proyecto y que informen errores, problemas o sobrecostos actuales y previstos.
Dominio Competencia y Orientación
Los gerentes de proyecto trabajan en las interfaces entre la alta gerencia, el cliente y los tecnólogos
o contratistas, por lo que deben tener capacidad gerencial, competencia técnica y otras calificaciones
generales. Deben sentirse tan cómodos en la oficina hablando con ejecutivos y clientes sobre
políticas, cronogramas y presupuestos como en la planta, el taller o en el sitio hablando con expertos
en la materia y
supervisores sobre cuestiones técnicas.

Amplios antecedentes también son esenciales. Cuanto más diferenciadas sean las áreas
funcionales, más propensas serán al conflicto. Para integrar de manera efectiva áreas
funcionales múltiples y diversas, el director del proyecto debe comprender cada una de las
áreas (la jerga, las técnicas y los procedimientos utilizados) y sus contribuciones al proyecto.
Conocido como competencia de dominio, el gerente del proyecto debe tener una buena
comprensión de todas las áreas del proyecto. Otra forma de decir esto es que la competencia
técnica y administrativa del director del proyecto debe cubrir todo el alcance del proyecto, es
decir, todas las áreas dentro del enunciado del alcance del proyecto y las tareas en el primer o
segundo nivel de la estructura de desglose del trabajo. Aunque la mayoría de los gerentes de
proyectos no pueden ser expertos en todas las áreas del proyecto, deben estar lo
suficientemente familiarizados con las áreas para ser “creíbles”—para discutir inteligentemente
los problemas, ponderar las ideas ofrecidas por los especialistas y evaluar y tomar decisiones
balanceadas apropiadas. Del mismo modo, para tratar eficazmente con la alta dirección y el
cliente, deben estar familiarizados con el funcionamiento y los negocios de las organizaciones
matriz y del cliente.
Los gerentes de proyecto no pueden saberlo todo. Cuando son responsables de áreas que
desconocen, lo admiten y buscan la opinión y el consejo de personas en las que confían. Como
regla general, un gerente de proyecto nunca trata de fanfarronear, ya que hacerlo corre el
riesgo de perder toda credibilidad con las partes interesadas.
Los estudios indican que los gerentes de proyecto más efectivos adoptan metas, tiempo y
orientaciones interpersonales intermedias a las unidades funcionales que integran. En otras
palabras, adoptan una perspectiva equilibrada. 8 Porun
ejemplo, para integrar
departamento los esfuerzos
de producción y un de
departamento de investigación, el director del proyecto adopta una perspectiva temporal
intermedia entre la perspectiva semanal a corto plazo de la producción y la perspectiva futurista
a largo plazo de la investigación.
En cuanto a la importancia relativa de la capacidad técnica versus la competencia gerencial,
eso depende del proyecto. Los directores de proyecto en la mayoría de los proyectos de
investigación e ingeniería necesitan una mayor competencia técnica porque los problemas y la
orientación del equipo del proyecto son técnicos. En proyectos no técnicos, sin embargo, los
gerentes de proyecto necesitan una mayor capacidad de gestión porque los proyectos
involucran áreas funcionales múltiples y diversas. En general, los gerentes de proyecto deben
ser lo suficientemente técnicos para poder comprender los problemas del proyecto, pero no
tanto como para descuidar su función gerencial. No hay sustituto para una gestión fuerte
competencia en el papel del director del proyecto.

15.2 Autoridad de gestión del proyecto
La autoridad se refiere al poder de un gerente para ordenar a otros que actúen o no actúen.
Existen diferentes tipos de autoridad, la más familiar es la conferida por la organización y escrita
en la descripción del trabajo del gerente, llamada autoridad legal.
Dada la autoridad legal, se considera que las personas en posiciones organizacionales más altas
tienen el “derecho” de controlar las acciones de las personas debajo de ellos. Asociado con la
autoridad legal está el poder de recompensa, el poder de evaluar y recompensar a los subordinados.
Otro tipo de autoridad, la autoridad carismática, surge del poder que uno gana a través de
características personales como el encanto, la personalidad y la apariencia. Las personas tanto
dentro como fuera de la organización formal pueden aumentar su autoridad siendo carismáticas.
Autoridad Tradicional
La teoría de la gestión dice que la autoridad siempre es mayor en los niveles más altos de la
organización y se delega hacia abajo. Se supone que así debe ser porque se supone que los
gerentes en los niveles más altos "saben más" y, por lo tanto, pueden tomar decisiones y "mandar"
a los trabajadores en los niveles más bajos. Este punto ha sido cuestionado sobre la base de que
los gerentes, particularmente en las organizaciones basadas en tecnología, no pueden saber todo
lo necesario para tomar decisiones complejas. A menudo carecen de experiencia técnica y, por lo
tanto, cada vez más, deben confiar en especialistas subordinados para recibir asesoramiento.
Incluso los gerentes técnicamente capacitados no siempre pueden administrar solos; dependen
de los grupos de personal para la asistencia presupuestaria y de personal. Especialmente en los
proyectos, este aspecto de la “gestión participativa” (descrito en el Capítulo 16) es un lugar común.
Ver Capítulo 16
Influencia
Es importante distinguir entre la autoridad legal y la capacidad de influir.

Los gerentes con autoridad legal influyen en los subordinados dando órdenes y controlando
salarios y promociones. Por lo general, sin embargo, los gerentes más efectivos pueden ejercer
influencia sin "dar órdenes" a los demás o hacer un problema de su relación superior-
subordinado. Esto es especialmente cierto cuando los subordinados tienen una buena
educación o mucha experiencia. De hecho, los gerentes que confían únicamente en la
autoridad legal suelen ser relativamente ineficaces. Los gerentes efectivos tienden
9
confiar en cambio en otras dos fuentes de influencia: el conocimiento y la personalidad.
La primera fuente, denominada poder experto, se refiere a un nivel especial de conocimiento o
competencia; los subordinados creen que la persona posee conocimiento e información que
es importante y que ellos mismos no tienen. Simplemente, se considera que el poseedor del
poder experto tiene razón porque sabe más, y los demás se someten fácilmente a sus
solicitudes.
El otro, llamado poder referente, deriva de la compenetración, la atracción personal, la
amistad, las alianzas y los favores recíprocos. El subordinado de alguna manera se identifica
con el detentador del poder y se remite a sus solicitudes.
Dado el poder experto y el poder de referencia, una persona puede influir en los demás
independientemente de la jerarquía formal. Estas formas de poder pueden incluso invertir
sutilmente la relación de autoridad. Un subordinado puede ejercer una influencia considerable
sobre su superior si el superior llega a confiar en el subordinado para obtener información o
consejo, o si se desarrolla un vínculo de confianza, respeto o afecto entre ellos. Todo el mundo
ha visto esto, y la historia está repleta de ejemplos de personas de estatura social u organizativa
“más baja” que controlan a personas de mayor estatura: Alejandría fue emperatriz de Rusia;
Rasputín era un sacerdote humilde.
Autoridad en Proyectos
Los gerentes funcionales tienden a depender de diferentes formas de influencia: conocimiento,

experiencia, persuasión y relaciones personales; sin embargo, cuando estos fallan, pueden
recurrir a su autoridad legal. Pero los gerentes de proyecto no pueden hacer esto. Excepto en
el caso del gerente de proyecto puro, el gerente de proyecto típico carece de cualquier forma
de autoridad legal.
En las organizaciones tradicionales, la influencia y la autoridad fluyen verticalmente, pero en
proyectos fluyen horizontal y diagonalmente. El director del proyecto existe fuera de la jerarquía
tradicional. Su papel es temporal, se superpone a la estructura existente y no se le otorga la influencia
inherente a una posición jerárquica. Los gerentes de proyecto trabajan a través de líneas funcionales y
organizacionales y, a excepción de los miembros de la oficina del proyecto, no tienen subordinados que
les reporten en una capacidad de línea directa. El problema se complica aún más en las organizaciones
matriciales en las que los gerentes de proyecto deben compartir la autoridad con los gerentes
funcionales.
Por lo tanto, a pesar de la gran responsabilidad que tienen, la mayoría de los gerentes de proyecto
carecen de un nivel comparable de autoridad formal. En cambio, tienen autoridad sobre el proyecto, lo
que significa que pueden tomar decisiones sobre los objetivos, políticas, cronogramas y presupuestos
del proyecto, pero carecen de autoridad para dar órdenes que respalden esas decisiones.
La disparidad entre alta responsabilidad formal y baja autoridad formal tiene 10 La brecha implica
brecha de autoridad. debe esforzarse por desarrollar
queotras
los gerentes
formas de
deinfluencia
proyecto se
en conocen
ausenciacomo
de la
autoridad legal.
“Cómo hacer amigos e influir en las personas” no es un tema académico para el proyecto
gerentes
Figura 15.2 Fuentes de influencia de los directores de proyecto.
Autoridad del director del proyecto

La mayoría de los gerentes de proyecto manejan la brecha de autoridad de manera

similar: al no tener autoridad legal, su recurso es confiar en la influencia derivada del
poder experto y el poder de referencia. Tienen que hacer esto también porque no
importa el proyecto, dependen de otros para hacer el trabajo. Se deben tomar
numerosas decisiones, muchas de las cuales no tienen ni el tiempo ni la experiencia.
Incluso en el raro caso de que un gerente de proyecto tenga autoridad legal, rara vez
la usa porque las decisiones y órdenes unilaterales son inconsistentes con la necesidad
de reciprocidad y compensaciones en los proyectos. Los gerentes de proyecto saben
que no toda la información debe canalizarse a través de ellos y fomentan el contacto
informal directo entre las personas involucradas.
Los gerentes de proyecto también ganan influencia a través de redes de alianzas y
conexiones informales que construyen con gerentes y otras partes interesadas. La
fuerza y la amplitud de estas redes aumentan con la competencia percibida del director
del proyecto, la reputación de los logros del proyecto anterior y el carisma. La
característica final, el carisma, se refiere al atractivo personal del director del proyecto,
algo sobre el comportamiento, el comportamiento o la personalidad del director del
proyecto que gusta a la gente. ¿Por qué debería importar esto? Bueno, es más
probable que las partes interesadas del proyecto se asocien, ayuden o hagan lo que
solicita un gerente de proyecto si les gusta que si no; Es tan simple como eso. Si el
proyecto se mete en problemas, un director de proyecto que le guste a la gente tendrá
alianzas y amigos a los que pedir ayuda.
En resumen, los gerentes de proyecto tienden a confiar en el conocimiento, la experiencia,
las relaciones personales y la personalidad para influir en los demás (Figura 15.2). Para
construir poder basado en expertos, deben ser percibidos como técnica y administrativamente
competentes. Para construir poder basado en referentes, deben desarrollar habilidades
efectivas interpersonales, de persuasión y negociación. Las formas en que los diferentes
gerentes de proyecto emplean estas fuentes de influencia se ilustran en el ejemplo 15.2.
Ejemplo 15.2: Gerentes de proyecto efectivos,

contraste de estilos 11
Kelly Johnson y Ben Rich, ambos exgerentes jefes de la

división de proyectos avanzados de Lockheed-Martin Company, "Skunk Works".
Kelly Johnson era una leyenda viva, no solo en la empresa sino también en toda
la industria aeroespacial. Con la ayuda de un equipo altamente cohesionado de
ingenieros y trabajadores de taller, creó más de 40 aviones, incluidos los más rápidos
y que vuelan más alto del mundo. Sin embargo, era estrictamente comercial, sin
humor, de mal genio y con la reputación de "comer ingenieros jóvenes como bocadillos
entre comidas". Hizo sudar a las personas con las que tenía tratos (burócratas e
ingenieros), en particular a los que inventaban excusas y a los que buscaban fallas,
por lo que tenía tantos detractores como amigos. No obstante, cuando la gerencia
necesitaba a alguien que encabezara los proyectos más difíciles y desafiantes,
seleccionaban repetidamente a Kelly. ¿Por qué? Debajo del mal genio y la apariencia
algo descuidada había un genio infalible. Lo sabía todo, al parecer, y su habilidad
para hacer deducciones precisas en el acto asombró a todos.
Para una nueva entrada de motor, Kelly simplemente echó un vistazo al diseño inicial
y lo pronunció mal, aproximadamente "un 20 por ciento demasiado grande". Sus
ingenieros trabajaron un día completo para volver a calcular el diseño solo para
descubrir que, efectivamente, la entrada del motor era un 18 por ciento demasiado
grande. En otra ocasión miró un diseño y dijo “la carga aquí es de 6,3 psi”. Después
de una hora de cálculos complicados, su gente lo midió en 6,2 psi. Cuando se jubiló,
Kelly Johnson fue reconocido como el destacado aerodinámico de su época.
Kelly eligió como sucesor a Ben Rich. Ben fue el primero en reconocer que no
poseía el genio de Kelly y, por lo tanto, confiaría en sus equipos para la mayoría de
las decisiones. Su primer movimiento fue aflojar las riendas y permitir que los equipos
hicieran la mayoría de las decisiones por su cuenta. Ben fue decisivo al decirle a un
equipo lo que quería, pero luego dejó que ellos decidieran qué métodos aplicar.
Se limitó a charlar y animar a través de un suministro interminable de frases
ingeniosas. Como dijo un empleado: “Mientras que Kelly gobernó por su mal genio,
Ben gobernó por sus chistes malos”. Ben utilizó un enfoque no amenazante. Si bien
no rehuía regañar a las personas que lo merecían, prefería felicitar a las personas y
levantarles la moral. Dijo un colega que era el gerente perfecto: estaba allí para tomar
las decisiones difíciles, defender y proteger a sus equipos de proyectos, obtener más
dinero y nuevos proyectos, y convencer al gobierno ya la alta gerencia del valor del
trabajo de sus equipos.
Johnson y Rich lideraron usando diferentes estilos, pero ambos han sido reconocidos por la
industria como gerentes de proyectos ejemplares. Kelly Johnson logró grandes cosas, a pesar
de su temperamento, y la mayoría de los ingenieros consideraron un honor haber trabajado con
él. La competencia y la reputación eran sus puntos fuertes; la gente toleraba su personalidad.
Ben Rich, sin pereza técnica, reconoció que tenía algunas personas más inteligentes trabajando
para él. Sin embargo, a diferencia de Kelly, tenía carisma y muchos amigos personales, y con
eso también pudo lograr grandes cosas en Skunk Works.
El equilibrio de poder
Por lo general, los gerentes de proyecto y los gerentes funcionales comparten la autoridad, pero en
los proyectos de alto desempeño esa autoridad está claramente diferenciada.12 Los gerentes de
proyecto tienen poder para decidir qué se debe hacer, procurar recursos, coordinar esfuerzos de
trabajo y mediar en conflictos; por el contrario, los gerentes funcionales tienen poder para decidir
cómo se deben hacer las cosas, la tecnología que se utilizará, y para resolver problemas técnicos.
Aunque un gerente de proyecto rara vez tiene algún tipo de poder de recompensa, los trabajadores
tienden a escuchar más si perciben que el gerente de proyecto tiene alguna influencia sobre sus
salarios y promociones.
15.3 Calificaciones del Gerente de Proyecto
Las calificaciones de los gerentes de proyectos exitosos se dividen en cuatro categorías: características
personales, habilidades interpersonales, habilidades comerciales generales y habilidades técnicas.
Características personales
Archibald enumera las siguientes como características personales esenciales: 13
• Flexible y adaptable •
Preferencia por la iniciativa y el liderazgo •
Confianza, persuasión, fluidez verbal • Comunicador e
integrador eficaz • Capaz de equilibrar soluciones
técnicas con tiempo, costo y factores humanos • Bien organizado y disciplinado •
Generalista en lugar de especialista.
Estas características tienen sentido dado el entorno del proyecto y las responsabilidades y restricciones
impuestas al rol del director del proyecto. Obviamente, los gerentes de proyecto también deben ser
capaces de manejar la presión de los plazos constantes, la gran incertidumbre, los inicios y cierres y los
cambios constantes en las metas, tareas, personas y relaciones.
Al gerente de proyecto típico le gusta estar fuera de casa, mezclándose con el equipo del proyecto
en el sitio y en otros lugares con las partes interesadas. De esta manera, se conecta con la gente, se
mantiene informado y levanta la moral.
Habilidades interpersonales
Un gerente de proyecto necesita fuertes habilidades interpersonales y de comportamiento y la capacidad

14
de "escuchar activamente" y "leer a las personas". para aclarar yactiva
La escucha parafrasear
significapara asegurarse
hacer preguntasde que
entiende lo que las personas son
dicho; significa:
• Hacer preguntas capciosas. •

Permanecer callado y permitir que la otra persona tenga suficiente tiempo para hablar. •
Reflexionar sobre la respuesta de la persona y verificar que sea correcta. • Reflexionar
sobre las emociones de la persona.
El acrónimo de escucha activa es LEAR: Escuchar, Explorar, Reconocer, Responder.
El director del proyecto debe ser sensible a las actitudes de los interesados en el proyecto.
Los especialistas en el equipo del proyecto a menudo desdeñan todo lo que no sea técnico y se
resienten de las restricciones presupuestarias y de cronograma. El gerente del proyecto debe poder
convencerlos de por qué estos son importantes.
El director del proyecto también debe saber cómo generar confianza, promover el espíritu de
equipo y recompensar la cooperación; a menudo lo hace a través de las únicas formas de recompensa
que puede dar: elogios y crédito. Un buen gerente de proyecto comprende las personalidades,
actitudes y fortalezas de los miembros de su equipo y sabe cómo utilizar sus talentos, incluso cuando
no están a la altura de sus estándares. Es sensible a las debilidades, las necesidades y la codicia
humanas, y es capaz de resolver conflictos, manejar el estrés y entrenar y aconsejar a los miembros
del equipo. Parece una tarea difícil, pero un buen gerente de proyecto puede hacer todo eso.
Habilidades Comerciales Generales
Después de todo, el gerente de proyecto es un gerente y, por lo tanto, también debe tener
conocimientos generales de negocios y habilidades que incluyen:
• Entender la organización y el negocio. • Conocimiento de

gestión: marketing, contabilidad, contratación, compras, administración de recursos humanos y
conceptos comerciales. • Capacidad para traducir los requisitos comerciales en proyectos y
sistemas
requisitos
• Interés fuerte, activo y continuo en la enseñanza, la capacitación y el desarrollo
subordinados
La mayoría de los gerentes de proyectos tienen responsabilidad de costos, por lo que deben
comprender los conceptos de estimación de costos, elaboración de presupuestos, flujo de efectivo,
gastos generales, incentivos y costos compartidos. Están involucrados en acuerdos contractuales,
por lo que deben conocer los términos y las implicaciones del contrato. Son responsables de las
fases y la programación del trabajo para cumplir con las fechas de entrega, por lo que deben estar
familiarizados con las tareas de trabajo, los procesos y los recursos para ejecutar el proyecto. Y son
responsables de hacer cumplir los cronogramas, por lo tanto, deben conocer las herramientas y
técnicas para la planificación, el seguimiento y el control.
Habilidades técnicas
Para poder tomar decisiones informadas, los gerentes de proyecto deben tener una sólida
comprensión de los aspectos técnicos del proyecto. Como se mencionó, su "competencia de
dominio" debe abarcar todo el alcance del proyecto. En proyectos sin tecnología o de baja tecnología,
la comprensión se puede desarrollar a través de la experiencia y la capacitación informal. En
proyectos de alta tecnología, las calificaciones técnicas son más rigurosas y generalmente requieren
una carrera moldeada en el entorno tecnológico y un título en ciencias o ingeniería.
15
Aunque los gerentes de proyecto rara vez hacen análisis técnico, deben estar calificados para
integrar conceptos de diferentes disciplinas y hacer juicios técnicos. A menudo, las personas
técnicamente calificadas no son buenas para integrar conceptos de diferentes especialidades porque
la formación de pregrado en ingeniería 16 La tecnología suele enfatizar el análisis e ignorar la
integración. el director del proyecto debe ser capaz de entender y hablar el idioma de todos los
especialistas del equipo, independientemente de su especialidad; esto es mínimamente necesario
para comunicarse e integrar el trabajo de los especialistas.
Selección y Reclutamiento
El gerente para encabezar un proyecto determinado se selecciona entre las filas de gerentes
funcionales y de productos, especialistas en la materia y gerentes de proyectos experimentados. La
última fuente es la mejor, aunque no siempre factible. Puede ser difícil encontrar un gerente de
proyecto experimentado que tenga la combinación adecuada de
Calificaciones y está disponible para el nuevo proyecto. Como resultado, cuando se necesita
un gerente de proyecto con experiencia, a menudo se lo contrata desde el exterior; esto es
fácilmente observable en las listas de trabajos en línea y en los principales periódicos (la
Figura 15.3 muestra una muestra). La desventaja de contratar a un extraño es que le llevará
tiempo hacer amigos, crear alianzas y aprender las políticas de la organización. En el lado
positivo, es probable que esté mejor preparado para asumir la tarea de manera objetiva (sin
influencia política) y no tendrá enemigos, al menos inicialmente.
El director del proyecto también se puede seleccionar entre los directores funcionales,
aunque los directores funcionales a veces tienen dificultades para cambiar a una perspectiva
de proyecto, lo que requiere pasar de administrar solo un área a supervisar e integrar el
trabajo de muchas áreas. A menos que tenga abundante experiencia completa, es probable
que todos lo perciban como un gerente funcional más.
Los gerentes de proyecto también se pueden “crear” mediante la promoción de especialistas
en la materia (ingenieros, científicos, analistas de sistemas, diseñadores de productos, etc.),
aunque esto tiene el mismo inconveniente que colocar a cualquier persona que no sea gerente
en un rol gerencial: tiene que primero aprender a administrar. Ser un buen ingeniero o auditor
no garantiza que la persona sea un buen gerente de proyecto. Además, el especialista debe
aprender a desvincularse de su área de especialidad y convertirse en generalista. Idealmente,
la asignación de la gestión del proyecto no entrará en conflicto con las líneas de autoridad
existentes. Es una mala idea, por ejemplo, promover a un especialista al cargo de gerente de
proyecto y darle autoridad sobre su antiguo jefe.
Capacitación
Las habilidades de gestión de proyectos no se pueden aprender rápidamente, por lo que las
organizaciones dedican una cantidad considerable de tiempo y dinero a preparar a las
personas para el puesto. Algunos patrocinan programas de capacitación internos que se
enfocan en los requisitos especiales de sus organizaciones; otros utilizan seminarios externos
y programas universitarios. En los últimos años ha habido una proliferación de ambos tipos de
programas, acompañada de un aumento de la formación orientada a las certificaciones
profesionales como el PMP, APMP e ICB-IPMA. A menudo, una oficina de soporte de
proyectos o PMO ayuda con esta capacitación y desarrollo profesional.
Figura 15.3 Anuncios de puestos de gestión de proyectos.
Pero no hay sustituto para la experiencia. Muchas organizaciones permiten a las personas
prometedoras que aspiran a convertirse en gerentes de proyectos el beneficio de estar en el trabajo.
17
Como parte de sus trayectorias profesionales, rotan las asignaciones a lo largo de todo el proceso.
capacitación. áreas de la organización para desarrollar suficiente competencia de dominio que les
permita gestionar proyectos que involucran esas áreas. Los especialistas técnicos trabajan a tiempo
completo o parcial como asistentes de gerentes de proyectos experimentados y, si bien esto los
expone a la administración, también pone a prueba su aptitud y talento para ser gerentes.
A los valiosos especialistas técnicos con poca aptitud o capacidad gerencial se les brindan otras
oportunidades profesionales no gerenciales acordes con sus habilidades y
intereses.
Ejemplo 15.3: Capacitación en el trabajo de

gerentes de18 proyecto
El enfoque de Microsoft Corporation para preparar gerentes de proyecto (a los que

denominan "gerentes de programa") es típico. No existe un programa oficial de
capacitación para administradores de programas ni directrices que detallen los requisitos
del puesto. La gente aprende el trabajo “haciéndolo”. Microsoft selecciona y asesora
cuidadosamente a las personas adecuadas y luego espera que aprendan en el trabajo.
Para alrededor del 90 por ciento de los gerentes de programa, la capacitación se lleva a
cabo emparejando a un nuevo gerente de programa con un gerente de programa
experimentado y exitoso; el otro 10 por ciento recibe capacitación formal que incluye una
sesión de capacitación de 3 semanas. Microsoft ocasionalmente realiza almuerzos
grabados en video donde los gerentes presentan sus experiencias y luego hace circular las cintas de video.
Pasando al rol
Las responsabilidades de la gestión de proyectos van desde pocas y mundanas en proyectos
simples hasta extensas y desafiantes en proyectos complejos. Independientemente de las
calificaciones del gerente del proyecto, la carga del rol se alivia cuando el proyecto
19
gerente:
• Entiende lo que tiene que hacer. •

Comprende su autoridad y sus límites. •
Comprende su relación con los demás en el proyecto. • Conoce
los resultados concretos que constituyen un trabajo bien hecho. •
Sabe lo que es capaz de hacer bien y dónde se queda corto. • Es
consciente de lo que se puede y se debe hacer para corregir una mala situación.
• Cree que sus superiores tienen interés y creen en él, y están
deseoso de que triunfe.
En casos ideales, la alta dirección proporciona todo esto al director del proyecto; a veces, sin
embargo, depende del gerente del proyecto buscar, solicitar o exigir
15.4 Cumplimiento del rol de gestión de proyectos
Las organizaciones usan varios títulos para el rol de gerente de proyecto, incluidos "director de proyecto",
"líder de proyecto" y "presidente del grupo de trabajo". También se utilizan los títulos de "coordinador del
grupo de trabajo", "supervisor de proyectos" e "ingeniero de proyectos", aunque generalmente implican
roles más enfocados con menos responsabilidad que otras formas.
El rol de gestión de proyectos más efectivo ocurre cuando una persona se involucra durante la preparación
de la propuesta y permanece hasta la finalización del proyecto.
Cuando no hay nadie disponible o lo suficientemente competente para gestionar el proyecto, el papel se
cumple de otras maneras. Por ejemplo, puede ser ocupado por el gerente general o el gerente de planta,
aunque estos gerentes generalmente no tienen el tiempo necesario para dedicarse al proyecto ni la
flexibilidad para cambiar roles. Alternativamente, el rol puede asignarse temporalmente a un gerente
funcional. Aquí, el gerente debe dividir su tiempo entre el proyecto y su departamento, y ambos pueden
sufrir. Además, esta combinación funcional-director de proyecto puede tener problemas para obtener la
cooperación de otros directores funcionales cuando lo ven como un competidor por los recursos.
Este rol de “dos sombreros” tiene otros problemas, como se menciona en el Capítulo 14.
Ver Capítulo 14
En los proyectos a largo plazo, la responsabilidad puede pasar de un gerente funcional al siguiente a
medida que el proyecto avanza por las etapas. En esa situación, sin embargo, no hay nadie que dé
continuidad gerencial o técnica de una etapa a la siguiente (para integrar las etapas). Los gerentes de
etapas posteriores se ven obligados a heredar problemas creados por gerentes de etapas anteriores.
A veces, las responsabilidades de gestión de proyectos se dividen entre dos o más personas. Esto
sucede en los proyectos de construcción en los que el arquitecto es responsable de los asuntos técnicos,
mientras que el llamado director del proyecto se encarga del "papeleo" administrativo. Dos gerentes tienden
a complicar los problemas de coordinación, comunicación y autoridad porque ambos comparten la
responsabilidad.
Además, cuando el gerente del proyecto se vuelve subordinado, por ejemplo, al arquitecto, su capacidad
para administrar el proyecto se ve comprometida. Una división similar es común en el
industria cinematográfica. El productor de cine maneja los recursos, cronogramas y

presupuestos (en esencia, el gerente del proyecto), mientras que el director supervisa los
asuntos técnico-artísticos; sólo ocasionalmente son la misma persona. Debido a que la
filmación de una película es una actividad artística, los directores necesitan flexibilidad en
los presupuestos y los cronogramas de filmación, pero los costos también importan, y el
productor se enfrenta a la pregunta "¿a qué precio la creatividad?" No sorprende que los
20
No feliz.
dos no siempre tengan una relación obstante, la industria del cine tiene en alta estima el
papel de director de proyecto. Cuando se otorga un Premio de la Academia a la "Mejor
película", se otorga al productor de la película, la persona que administra los recursos, los
presupuestos y los cronogramas.
Algunos proyectos, especialmente los grandes en el sector público, requieren habilidades
excepcionales de presentación, negociación y política para tratar con amplios grupos de
interés y poderosos grupos de interés público y privado. En tales proyectos, también es
común ver a dos personas al frente de un proyecto: una para tratar los asuntos técnicos y
la otra con las partes interesadas.
Idealmente, solo hay un gerente de proyecto, y cualquier otro que también se desempeñe
en una capacidad gerencial o administrativa (ingenieros, arquitectos, directores, etc.) le
reporta.
Aunque idealmente la persona que desempeña el rol de gestión de proyectos dedica
tiempo completo a la gestión del proyecto, es común que los gerentes supervisen múltiples
proyectos. Esto es aceptable siempre que el gerente pueda cumplir adecuadamente sus
responsabilidades con todos ellos. De hecho, la gestión de múltiples proyectos puede ser
ventajosa porque pone al director del proyecto en posición de resolver conflictos de
recursos y prioridades y de negociar recursos entre todos los proyectos que supervisa.
15.5 Roles en el Equipo del Proyecto
Al principio de un proyecto, el director del proyecto y los directores funcionales dividen el proyecto
general en paquetes de trabajo. Esta división determina los requisitos de habilidades y sirve como
base para la selección y subcontratación de personal. Aquellos en áreas de soporte funcional,
contratistas y la oficina del proyecto que contribuirán al proyecto se convierten en parte del equipo
del proyecto. Esta sección describe los roles en el equipo.
Miembros en la Oficina de Proyectos
El Capítulo 14 describió el propósito de la oficina de proyectos. En la figura 15.4 se muestra un

ejemplo de oficina de proyectos (que no debe confundirse con una oficina de gestión de proyectos
o PMO) para un gran proyecto de desarrollo de ingeniería . En esta sección se describen los
miembros de la oficina de proyectos.
Ver Capítulo 14
El ingeniero de proyecto (también conocido como ingeniero de sistemas o diseñador de sistemas)

asume la responsabilidad de coordinar las áreas tecnológicas y asegura el diseño integrado del
artículo final. Cuando intervienen varias áreas funcionales o subcontratistas,
el ingeniero del proyecto:21
1. Supervisa el diseño y desarrollo de productos o sistemas.

2. Traduce los requisitos de rendimiento en requisitos de diseño.
3. Coordina y dirige el trabajo de las áreas funcionales y
subcontratistas
4. Planifica, monitorea, evalúa y documenta el progreso en el diseño y

Pruebas de subsistemas y del sistema en general.
5. Supervisa la gestión de la configuración y el sistema de control de cambios.
Figura 15.4 Miembros de la oficina de proyectos en un gran proyecto de desarrollo de ingeniería.
A veces, el título "ingeniero de proyectos" denota una persona que tiene responsabilidades
completas de gerente de proyectos, aunque más comúnmente se refiere al rol más limitado
que se describe aquí.
El administrador del contrato 22
es responsable de los aspectos legales del proyecto,
como la autorización para comenzar a trabajar y la subcontratación con empresas externas.
El administrador ayuda a preparar propuestas, definir y negociar contratos, integrar los
requisitos del contrato en los planes del proyecto, garantizar el cumplimiento de las
obligaciones contractuales y monitorear y comunicar al cliente los cambios en el alcance del
proyecto. Durante el cierre, notifica al cliente sobre las obligaciones cumplidas, documenta la
aceptación del artículo final por parte del cliente e inicia solicitudes formales de pago. También
es responsable de recopilar y almacenar RFP, correspondencia, documentos legales, cambios
de contrato, facturas, comprobantes de pago y documentos relacionados.
El controlador de proyectos 23 trabaja con gerentes funcionales para definir tareas en la

WBS y para identificar a las personas responsables de controlar las tareas. Mantiene archivos
de paquetes de trabajo y resúmenes de costos, publica documentos de autorización de
trabajo aprobados, supervisa el progreso del trabajo, evalúa el progreso del cronograma y el
costo, y revisa las estimaciones de tiempo y costo para completar el proyecto. También
prepara revisiones de presupuestos, cronogramas y autorizaciones de trabajo, redacta
informes de progreso para los usuarios y la gerencia, y cierra las cuentas de costos al finalizar.
El contable del proyecto proporciona apoyo contable al proyecto. Él
establece procedimientos para usar el PMIS, ayuda a identificar las tareas a controlar, establece
cuentas de control, prepara estimaciones de costos, valida los costos informados e investiga
problemas financieros.
El enlace con el cliente mantiene relaciones amistosas entre el contratista y el cliente. Ella
participa en discusiones técnicas y revisiones en curso (dentro de los límites del contrato) y ayuda
a acelerar los cambios de contrato.
El coordinador de producción planifica y coordina los aspectos de producción del proyecto. Las
responsabilidades incluyen revisar los documentos de ingeniería enviados a producción; desarrollo
de requisitos para equipos y piezas; supervisar los procesos de adquisición y montaje de piezas
para el artículo final; monitorear los costos de producción; programar todas las actividades
relacionadas con la producción; y sirviendo como enlace del gerente de proyecto con el
departamento de producción.
El gerente de campo o sitio supervisa la construcción, la instalación, las pruebas y la entrega
del artículo final del proyecto al cliente. Las responsabilidades incluyen la programación de
operaciones de campo, el seguimiento de los costos de las operaciones de campo y la supervisión
del personal de campo.
El supervisor de garantía de calidad establece y administra los procedimientos de garantía de
calidad. Sus responsabilidades abarcan aumentar la conciencia de calidad e instituir medios para
mejorar los métodos de trabajo y producir cero defectos.
La oficina de proyectos también cuenta con representantes de los departamentos funcionales
y subcontratistas participantes. Estas personas trabajan con el director del proyecto y entre sí para
coordinar las actividades de sus áreas funcionales con el
proyecto general. Trabajan y cargan su tiempo a la oficina de proyectos cada vez que deben
reunirse con el jefe de proyecto y los representantes de las otras áreas, y regresan a sus
departamentos funcionales tan pronto como finaliza su trabajo.
La cantidad de personal en la oficina del proyecto debe ser tan pequeña como sea práctico.
Esto mantiene la oficina flexible, minimiza los costos de personal y los problemas de asignación,
y es más fácil de administrar para el gerente del proyecto. Los miembros del personal de la oficina
contribuyen a tiempo completo o parcial según sea necesario y pueden estar ubicados físicamente
en diferentes lugares.
Gerentes Funcionales
A menudo, el glamour del trabajo se encuentra en el lado del proyecto, y los gerentes
funcionales pueden percibir sus funciones como disminuidas. Pero si las discusiones
anteriores lo han llevado a creer que los gerentes funcionales están de alguna manera
subordinados al gerente de proyecto, tenga en cuenta que ese rara vez es el caso. Los
gerentes funcionales y de proyecto dependen unos de otros para lograr los objetivos del
proyecto. Los gerentes funcionales son responsables de mantener la competencia técnica y
dotar de personal y ejecutar las tareas del proyecto dentro de sus disciplinas y áreas
funcionales. Trabajan con el director del proyecto para definir las tareas y planificarlas, programarlas y pres
El personal de las organizaciones matriciales cambia de un proyecto a otro, y su único
"hogar" permanente es su departamento funcional. El gerente funcional es responsable no
solo de la contratación, evaluación del desempeño y compensación de las personas de su
área, sino también de su desarrollo profesional. A diferencia de los gerentes de proyectos
que tienden a solicitar "recursos humanos" únicamente en términos de lo que es mejor para
sus proyectos, es más probable que un gerente funcional busque los intereses de las
personas a las que solicita.
En la mayoría de las organizaciones de proyectos, los gerentes funcionales retienen la
misma autoridad y responsabilidad que en los entornos que no son de proyectos. Sin
embargo, algunos gerentes funcionales creen que el rol de gerente de proyecto socava su
autoridad y que podrían manejar mejor el proyecto si estuviera exclusivamente dentro de su
dominio. Los gerentes de proyecto que intentan socavar la autoridad de los gerentes
funcionales tendrán dificultades para obtener apoyo cuando lo necesiten (ver, por ejemplo,
el Caso 14.3 en el Capítulo 14).
Antes de que comience un proyecto, se deben delinear claramente las responsabilidades
y
contribuciones al contenido técnico de cada gerente funcional . garantizar una base técnica
sólida y continua para todos los proyectos y aliviar la animosidad potencial entre los gerentes
funcionales y de proyecto.
Ver Capítulo 14
Líderes Funcionales de Proyecto y Supervisores de Paquetes de Trabajo
En algunos proyectos, cada gerente funcional selecciona un líder funcional del proyecto
para que sirva de enlace entre él y el gerente del proyecto. Esta persona prepara
parte del plan del proyecto correspondiente a su departamento y supervisa el trabajo del
proyecto realizado por el departamento.
Cuando se asigna una gran cantidad de trabajo a un departamento determinado, ese
trabajo se divide en varios paquetes de trabajo y la responsabilidad de cada uno se delega a
un supervisor del paquete de trabajo. El supervisor prepara el plan para el paquete de trabajo
y supervisa el trabajo.
15.6 Funciones fuera del equipo del proyecto
Esta sección analiza algunos de los roles de los individuos y grupos fuera del equipo del proyecto
que influyen o controlan la gestión, los recursos y los resultados de un proyecto (Figura 15.5).
Gerente de Proyectos o Director PMO
El gerente de proyectos (también llamado director de PMO, vicepresidente de proyectos o

director de proyectos) se encuentra en el mismo nivel jerárquico que los gerentes funcionales
(consulte la Figura 14.8 en el Capítulo 14). Este gerente supervisa múltiples proyectos y: 25
Ver Capítulo 14
• Dirige y evalúa a todos los jefes de proyecto. • Asegura

que los proyectos sean consistentes con las limitaciones de recursos y los objetivos
estratégicos de la organización. • Trabaja con jefes funcionales para asignar recursos
y resolver prioridades
Conflictos entre proyectos.
• Asiste en el desarrollo de políticas y técnicas de gestión de proyectos y
sistemas de planificación y control de proyectos.
• Asegura la consistencia entre los proyectos y que los cambios en el costo, el cronograma
o los objetivos de desempeño de un proyecto se integren con los de otros proyectos.
El Capítulo 17 describe el papel de la PMO con más detalle.
Ver Capítulo 17
Alta dirección
La alta dirección toma todas las decisiones importantes sobre la selección y priorización de
proyectos. Aprueba el estudio de viabilidad del proyecto, selecciona el director del proyecto y
autoriza la puesta en marcha del proyecto. En las organizaciones que practican la gestión de
carteras de proyectos en las que los proyectos se gestionan en grupos para una mejor alineación
con las estrategias organizativas y la asignación de recursos, esta responsabilidad la encabeza el
gestor de carteras de proyectos, que se analiza en el Capítulo 18.
Ver Capítulo 18
Figura 15.5 Roles fuera del equipo del proyecto.
La alta dirección establece las reglas y políticas que rigen la

26
gestión de proyectos de la organización. Directamente o a través de la PMO, ésta:
• Define la responsabilidad y autoridad del director del proyecto en relación con otros
gerentes
• Define el alcance y las limitaciones de las responsabilidades del director del proyecto.
• Establece políticas para resolver conflictos de proyectos y establecer prioridades.

• Especifica criterios para evaluar el desempeño del gerente del proyecto. • Soporta
la metodología de gestión de proyectos.
La autoridad de un director de proyecto solo es otorgada por el director de proyectos y

establecida en los estatutos de la organización, o según lo acordado en el contrato con el
cliente. En situaciones que involucran negociaciones críticas o conflictos irresolubles, la alta
dirección puede adelantarse a la autoridad del director del proyecto.
Director del programa
Cuando el proyecto es parte de un esfuerzo más grande llamado programa, el director del
proyecto trabaja con un director del programa que es responsable de coordinar el proyecto
con otros proyectos y esfuerzos de trabajo para alcanzar las metas del programa. El papel del
administrador del programa se cubre en el Capítulo 17.
Ver Capítulo 17
Partidarios del proyecto: campeón y patrocinador
Cada proyecto necesita el apoyo de dos personas externas clave, el campeón del proyecto y
el patrocinador del proyecto. El campeón es alguien que cree firmemente en el proyecto y
argumenta a su favor, tanto en su inicio como posteriormente. El campeón debe tener
“influencia” y ser el tipo de persona capaz de convencer a las partes interesadas del valor o
los beneficios del proyecto. El campeón suele ser el portavoz más visible del proyecto. Cuando
el proyecto no tiene un campeón, es posible que el director del proyecto tenga que ponerse
su sombrero de “evangelista” e ir a buscar uno.
El patrocinador del proyecto es alguien que trabaja para garantizar que el proyecto obtenga
la prioridad, la financiación y los recursos necesarios. Al igual que el campeón, esta persona
es influyente, aunque más en términos de autoridad formal para despejar obstáculos e influir
en las decisiones de la alta dirección; como consecuencia, para proyectos no realizados para
clientes externos, a menudo ocupa un puesto en la alta dirección.
Normalmente, el patrocinador no dedica mucho tiempo al proyecto, pero está
no obstante, es accesible para el gerente del proyecto y está disponible para ayudar cuando
el proyecto se topa con un obstáculo y necesita asistencia de alto nivel. Cuando el proyecto
es parte de un programa, a veces el director del programa actúa como patrocinador del proyecto.
Ocasionalmente, el campeón y el patrocinador son la misma persona.
27
15.7 Participación de las partes interesadas del proyecto
El término “partes interesadas” aparece con frecuencia a lo largo de este capítulo y en todo el
libro. Esto se debe a que las partes interesadas son actores clave en los proyectos y
desempeñan un papel fundamental en la gestión de proyectos. Por definición, una parte
interesada del proyecto es cualquier grupo o individuo afectado, interesado o que tenga una
influencia potencial en el proyecto. Entre las partes interesadas más importantes se encuentran
los clientes y usuarios, como se analiza en otras partes del libro, y los roles relacionados con
el proyecto que se analizan en las secciones anteriores 15.5 y 15.6. Otras partes interesadas
incluyen posibles clientes/usuarios, socios, prestamistas, gobiernos, prensa y grupos
comerciales. Con el creciente reconocimiento de que los proyectos tienen impactos ambientales
generalizados, incluso globales, las partes interesadas del proyecto también incluyen
potencialmente a todas las personas preocupadas o afectadas por los impactos ambientales
del proyecto, incluidos todos en la comunidad en general, la sociedad en su conjunto y, para
el caso, todos los habitantes de la Tierra. organismos vivos.
Algunas partes interesadas apoyan el proyecto y quieren que tenga éxito; otros lo resisten
y quieren que lo maten. Estos últimos incluyen administradores de áreas que compiten con el
proyecto por los recursos, grupos de interés ambiental o político o lobbies, y cualquier persona
que perciba el proyecto como perjudicial para sus propios intereses o los de la sociedad. La
mayoría de las partes interesadas no conocen y no se preocupan por otros
partes interesadas. Antes de que comience un proyecto, el gerente del proyecto debe saber
quiénes son las partes interesadas. En esencia, debe preparar una lista de todos los individuos,
organizaciones y grupos influenciados o capaces de influir en el proyecto, y tratar de
determinar posibles relaciones o líneas de influencia entre ellos. Esto es parte del compromiso
de las partes interesadas, que comienza con el conocimiento de quiénes son las partes
interesadas clave, la comprensión de sus intereses, necesidades y actitudes con respecto al
proyecto, y la preparación de estrategias para acomodarlos. Hacer eso generalmente requiere
hablar directamente con las partes interesadas para conocer sus puntos de vista y opiniones,
lo que esperan del proyecto (y del gerente del proyecto), lo que necesitan (requisitos explícitos)
y esperan (requisitos no declarados o indefinidos), y cómo podrían ser. influenciado. Dados
los recursos limitados, la capacidad técnica o las demandas de otras partes interesadas, no
se pueden satisfacer todas las necesidades y expectativas, en cuyo caso el proyecto
gerente hace lo mejor que puede. A veces hace lo que hace simplemente porque es lo “correcto”
o lo ético.
Ejemplo 15.4: Partes interesadas descontentas
Chris es el gerente de proyecto de una torre de oficinas de 54 pisos que se eleva junto al
río Chicago. La torre eclipsa un edificio tipo loft de 12 pisos al lado; a medida que se
eleva, bloquea las impresionantes vistas que los residentes de los lofts alguna vez
tuvieron del río y el horizonte, un problema común en las ciudades donde un edificio se
levanta junto a otro. Para reconocer su molestia, Chris dispuso que cada mañana se
sirviera café, roles y donas de una cafetería popular en el vestíbulo del edificio tipo loft.
Cuando algunos residentes se quejaron de que no les gustaba el café, se cambió de
tienda. Un fin de semana después de que se construyeron los pisos inferiores del nuevo
edificio y se limpió el sitio, organizó un picnic de un día con actividades para los residentes
y las familias del loft. Una residente, Hilda, se quejó de que su pequeña unidad estaría a
la vista de todos en el nuevo edificio. Chris se ofreció a comprarle persianas y cortinas,
pero ella se negó.
Todas las mañanas, la construcción del nuevo edificio se reanuda a las 5 am y, con
ella, las luces brillantes y la cacofonía. Para recordarle su irritación, todas las mañanas
Hilda deja un mensaje en el celular de Chris, algo así como: "Aquí son las 5 a.m. y estoy
completamente despierto por todo el alboroto que estás causando".
Varias veces a la semana, Chris le devuelve la llamada. Siempre cortés, se disculpa
porque no hay más que pueda hacer para mejorar las cosas para ella.
La lista de interesados puede ser larga, y la cantidad de comunicación, información

proporcionada e interacción con cada uno debe depender de sus intereses en el proyecto y el
poder o la capacidad de influir en los resultados del proyecto.
La siguiente tabla muestra las estrategias apropiadas para tratar con las partes interesadas
según su nivel de interés y su nivel potencial de influencia. Por ejemplo, las partes interesadas
con gran influencia pero poco interés deben “mantenerse satisfechas”, para que no se opongan
al proyecto si quedan insatisfechas. La estrategia elegida debe abordar si el "interés" de la parte
interesada es de apoyo, oposición o neutral, cómo el gerente del proyecto involucrará a la parte
interesada
a lo largo del proyecto, así como las preferencias de comunicación de los interesados (presencial, teléfono,
correo electrónico, etc.). Para las partes interesadas que se oponen al proyecto, la estrategia debe especificar
cómo obtener su apoyo o, en su defecto, cómo mitigar o acomodar su oposición. (Como muestra el Ejemplo
15.4 , la estrategia podría ser tratar de satisfacer a todos los interesados con alto interés, incluso aquellos con
poca influencia) . influencia y estrategias para comunicarse con ellos, involucrarlos o tratar con ellos. El plan
debe reflejarse en el plan de comunicación del proyecto y el plan de ejecución del proyecto.
Actores con poca influencia en el proyecto Actores con alta influencia en
el proyecto
Partes interesadas con

Concéntrese en estos:
alto interés en el Mantenerse informado
manténgase informado y satisfecho
proyecto
Partes interesadas con bajo Posiblemente ignorar; monitorear los

Mantener satisfecho
interés en el proyecto cambios en el interés/influencia
28
Ejemplo 15.5: La gran excavación
El Proyecto de Túnel/Arteria Central (CAT) de Boston, conocido localmente como Big Dig, es un ejemplo
de un proyecto complejo que debe adaptarse a los intereses de muchas partes interesadas, incluidos los
gobiernos federal, estatal y local,

29
contratistas y numerosos grupos de interés (Figura 15.6).
La parte de la arteria central del proyecto reemplazó la autopista interestatal elevada que atravesaba
el centro de Boston con un túnel. La autopista elevada (llamada burlonamente la "serpiente verde") era
una monstruosidad que separaba el North End y el paseo marítimo de Boston del resto del centro.
Además de reemplazar la arteria central, el proyecto CAT incluyó un túnel debajo del puerto de Boston
hasta el aeropuerto Logan y nuevos puentes a través del río Charles hasta Cambridge: un total de 160
millas de carriles en 3.7 millas de túneles, 2.3 millas de puentes y 1.5 millas de superficie. calles Celebrado
como "el más grande, el más

complejo proyecto de carretera jamás emprendido en los EE. UU.” Su precio original era
de $ 5 mil millones; el proyecto finalmente costó más de cuatro veces esa cantidad.
Figura 15.6 Partes interesadas clave en el proyecto Big Dig antes de 1992.
Los partidarios del proyecto se enfrentaron a problemas abrumadores. La delegación

del Congreso de Massachusetts tuvo que impulsar proyectos de ley a través del Congreso
de los EE. UU. que proporcionarían la mayor parte de los fondos; esto requería tener en
cuenta los intereses de una gran cantidad de aliados ad hoc en el Congreso y hacerles
promesas. Con la autorización de financiación de la Administración Federal de Carreteras
(FHWA), los partidarios abordaron la cuestión de quién debería supervisar el proyecto, la
Autoridad de Transporte del Área de la Bahía de Massachusetts (MBTA) o el Departamento
de Obras Públicas de Massachusetts (DPW).
Aunque MBTA tenía una mejor reputación en la gestión de la construcción, se le asignó el
trabajo a DPW con el argumento de que MBTA es un transporte público, no una carretera.
agencia. Para gestionar el proyecto, DPW contrató al experimentado equipo de contratistas de

Bechtel/Parson Brink-erhoff, una empresa conjunta formada por dos de las firmas de consultoría
e ingeniería de gestión más grandes del mundo: Bechtel Corporation y Parsons Brinkerhoff
Quade & Douglas. Los dos (llamados Joint Venture) se habían asociado antes como contratistas
para el Sistema BART de San Francisco, y Bechtel había trabajado en el Túnel del Canal de la
Mancha y el parque temático MGM de Disney en Florida.
El proyecto CAT se dividió en las fases de diseño conceptual, diseño preliminar, diseño final
y construcción. Joint Venture creó el diseño preliminar pero contrató a contratistas para el diseño
final y la construcción.
Inicialmente, el proyecto constaba de 56 paquetes de trabajo de diseño y 132 de construcción,
cada uno con un contratista principal. La gestión de los contratistas responsables de los paquetes
de diseño de arterias y túneles requería una coordinación especialmente estrecha, ya que estos
paquetes producían secciones contiguas de carreteras y túneles que tenían que encajar.
De acuerdo con la ley, Joint Venture colocó un borrador del proyecto en bibliotecas públicas
y proporcionó audiencias públicas. Esto dio como resultado que los ingenieros de DPW y Joint
Venture tuvieran que negociar con cientos de vecindarios, iglesias, empresas y grupos
ambientales, desarrolladores e individuos para mitigar innumerables problemas relacionados con
los impactos ambientales y comunitarios.
Estos finalmente contribuyeron a grandes aumentos en el alcance, los costos y los cronogramas
del proyecto.
Poner en marcha un proyecto implica negociar aros y obstáculos planteados por las partes interesadas.
El gerente del proyecto siempre tiene en cuenta a las partes interesadas y trabaja para obtener y
retener su apoyo en formas grandes y pequeñas.
30
Ejemplo 15.6: McCormick Place West
McCormick Place West es parte de un importante proyecto de varias etapas y varios años para
expandir el complejo de convenciones McCormick Place de Chicago. El grupo de empresas que
se asoció para diseñar y construir la estructura (otra “empresa conjunta”) trabajó para establecer
relaciones con los residentes y negocios cercanos.
Los gerentes y el personal del proyecto visitaron las escuelas secundarias locales para
educar a los estudiantes sobre prácticas y carreras en construcción, ingeniería y arquitectura.
Ofrecieron un programa para contratar trabajadores locales, enseñarles habilidades
comerciales a través de la experiencia práctica y la oportunidad de obtener la certificación
sindical; unas 20 personas al año se certificaron de esta manera. El contratista donó
computadoras viejas a las escuelas locales y automóviles para sus clases de taller.
Copiando una popular serie de telerrealidad, la empresa remodeló la casa de una familia
local necesitada. Estos y otros programas caritativos beneficiaron a la comunidad local y
ayudaron al contratista a obtener el apoyo de la comunidad.
15.8 Resumen
Los gerentes de proyecto trabajan en la interfaz proyecto-funcional-cliente, integrando
elementos del proyecto para lograr objetivos de tiempo, costo y rendimiento. Tienen la
responsabilidad final por el éxito de los proyectos, pero a menudo trabajan fuera de la
jerarquía tradicional y tienen poca autoridad formal. Para influir en las decisiones y el
comportamiento suelen recurrir a la negociación, las alianzas, los favores y los acuerdos
recíprocos. Su mayor fuente de influencia es el respeto que ganan a través de una
administración hábil y competente, competencia técnica y carisma.
Los gerentes de proyecto exitosos son percibidos como técnica y administrativamente
competentes. Tienen competencia comercial y de dominio: un amplio conocimiento que
abarca todo el alcance del proyecto. También tienen fuertes habilidades de comportamiento
y comunicación y pueden funcionar de manera efectiva en condiciones inciertas y
cambiantes.
El papel de gerente de proyecto lo desempeña mejor una persona que esté involucrada
en el proyecto de principio a fin. Compartir o rotar el rol entre varias personas suele ser
menos efectivo, aunque a veces es necesario nombrar diferentes gerentes de proyecto
para diferentes fases del proyecto para cumplir con consideraciones técnicas,
administrativas o políticas.
Los gerentes de proyecto realizan el trabajo a través de un equipo compuesto por
personas de varios grupos funcionales y de apoyo repartidos por toda la empresa matriz y
de subcontratistas externos. La oficina de proyectos brinda asistencia administrativa. Los
gerentes funcionales contribuyen al contenido técnico del proyecto y comparten la
responsabilidad de desarrollar planes, cronogramas y presupuestos para las tareas
realizadas por sus áreas. Mantienen la base técnica de la que se nutren los proyectos.
La alta dirección, el director de proyectos o director de la PMO, el director del programa

y el campeón del proyecto y los patrocinadores del proyecto desempeñan papeles clave
en el proyecto. La alta dirección establece las políticas, responsabilidades y relaciones de
autoridad a través de las cuales se lleva a cabo la gestión del proyecto. El gerente de
proyectos o director de la PMO se asegura de que los proyectos sean consistentes con los
objetivos de la organización y reciban los recursos necesarios. El campeón reúne apoyo para el
proyecto y convence a otros de sus beneficios y valor. El patrocinador apoya el proyecto

y, a través de la influencia organizacional, le da al proyecto la prioridad necesaria y
recursos.
Numerosos otros interesados apoyan o se resisten al proyecto y pueden tener un
gran impacto en su éxito o fracaso. El gerente del proyecto necesita saber quiénes son,
sus intereses e influencia en el proyecto, y desarrollar estrategias para que las partes
interesadas más importantes obtengan su apoyo al proyecto o mitiguen o acomoden su
oposición.
Las personas encuentran el trabajo en proyectos desafiante, gratificante y estimulante,
pero sin duda también lo encuentran agotador y estresante. Maximizar las posibilidades
de éxito del proyecto y minimizar las bajas humanas en el camino requiere habilidades
especiales para tratar con grupos e individuos. Estos se tratan en el próximo capítulo.
1. ¿Cuál es la función principal del director del proyecto?

2. ¿Qué significa “el gerente de proyecto es un evangelista y emprendedor”?
3. Describa las responsabilidades de un gerente de proyecto. ¿De qué manera la

presupuestación, la programación y el control se consideran responsabilidades de
integración y coordinación?
4. Discutir la necesidad relativa de competencia tanto técnica como gerencial
en gestión de proyectos.
5. ¿Por qué es esencial una amplia experiencia para el gerente de proyecto? que es un
antecedentes amplios?
6. ¿Qué es la autoridad legal? ¿En qué se diferencia de la autoridad carismática?
7. Describir cómo y de qué manera las personas en las organizaciones, independientemente de
posición jerárquica, influir en los demás.
8. ¿En qué se diferencia la autoridad del gerente de proyecto típico de la autoridad de otros
gerentes?
9. ¿Qué se entiende por “brecha de autoridad”?
10. ¿Cuál es la fuente de influencia más común utilizada por los gerentes de proyecto? ¿Cómo
utiliza el director del proyecto esta influencia para inducir a los directores funcionales a
asignar personal al proyecto?
11. Enumere las calificaciones ideales (personales, conductuales, técnicas) para los gerentes de
proyecto. ¿En qué se diferencian de las calificaciones de los gerentes funcionales? ¿Cómo
varían estos dependiendo del proyecto?
12. Discuta las consideraciones al seleccionar un gerente de proyecto de entre cada uno de los
siguientes grupos: gerentes de proyecto experimentados, gerentes funcionales, especialistas
funcionales.
13. Analice los pros y los contras de las distintas formas de cumplir el rol de director de proyecto
(por ejemplo, a tiempo parcial, varios directores de proyecto para un proyecto, un director
para varios proyectos, etc.).
14. ¿Cómo se capacitan los gerentes de proyectos en el trabajo? ¿Cuáles son las ventajas y
desventajas de depender de la capacitación en el trabajo como fuente de
gerentes de proyecto?
15. Describa las responsabilidades de los miembros clave de la oficina de proyectos para un
proyecto a gran escala.
16. Describa las responsabilidades del gerente de proyectos o director de la PMO.
17. Describa las responsabilidades relacionadas con el proyecto de la alta dirección.
18. Describa las responsabilidades del gerente funcional, el líder del proyecto y el supervisor
del paquete de trabajo en la gestión del proyecto y sus interfaces entre sí.
19. ¿Quién es el campeón del proyecto y quién es el patrocinador del proyecto?

20. ¿Quiénes son las partes interesadas? ¿Qué influencia tienen en un proyecto y por qué es
importante tenerlos en cuenta? ¿Qué debe hacer el director del proyecto para “gestionar”
a las partes interesadas y sus expectativas?
1. En su proyecto, ¿cuál es el título formal que se le da al rol de proyecto?

¿gerente?
2. ¿En qué parte de la estructura de la organización se encuentra el director del proyecto? mostrar esto
en un organigrama.
3. Describa en una oración el rol general del gerente de proyecto de su
proyecto. Ahora, enumere sus responsabilidades específicas .
4. En su opinión, ¿el llamado gerente de proyecto es el verdadero gerente de proyecto o
alguien más controla el proyecto? Si es lo último, ¿qué efecto tiene esto en la capacidad
del director del proyecto para influir en el proyecto?
5. ¿Describiría la orientación del director del proyecto como más

¿Técnico o más gerencial? Explique.
6. Describa los antecedentes profesionales del director del proyecto. ¿Ha ayudado u
obstaculizado su capacidad para ser gerente de proyectos? (Puede plantear esta
pregunta al director del proyecto).
7. Describa la autoridad del director del proyecto. ¿Cuánta autoridad legal tiene el director
del proyecto? ¿Se especifica la autoridad del director del proyecto en el estatuto de la
organización?
8. ¿Qué tan grande diría que es la brecha de autoridad del gerente del proyecto? Explique.
¿El director del proyecto tiene alguna queja al respecto?
9. ¿De dónde obtiene esta organización sus gerentes de proyecto? ¿Cuenta con un
procedimiento o seminarios para la formación y selección de gestores de proyectos?
¿De dónde vino el gerente de su proyecto?
10. ¿Cómo cumple este rol este gerente de proyecto: a tiempo parcial o completo, compartido
o rotado con otros gerentes, gerente de varios proyectos a la vez?
Explique. ¿El gerente del proyecto tiene suficiente tiempo para hacer un trabajo efectivo?
¿Sería más eficaz otra forma de ocupar el puesto?
11. ¿Existe una oficina de proyectos? De no ser así, ¿cómo se manejan las responsabilidades (por
ejemplo, para la administración de contratos)? Si es así, ¿quién está en la oficina del proyecto
(un ingeniero de proyectos, administrador de contratos, representante de campo, etc.)? Son
¿Están prestados, a tiempo completo oa tiempo parcial? Describa sus responsabilidades.

12. ¿Qué gerentes funcionales están involucrados en este proyecto? Describa sus
responsabilidades en el proyecto y las decisiones que toman unilateralmente o
comparten con el director del proyecto.
13. ¿Existe un gerente de proyectos o director de la PMO? ¿Proyecto campeon?
¿Patrocinador? Describa sus responsabilidades e influencia en el proyecto.
14. ¿Cuál ha sido el papel de la alta dirección en su proyecto? ¿Cuál es, en general,
la participación de la alta dirección en los proyectos de esta organización?
15. ¿Quiénes son los otros interesados clave? ¿Cómo se comunicó o trabajó con
ellos, los involucró o los acomodó de otro modo en la planificación y ejecución
del proyecto?
Caso 15.1 El Proyecto LOGON
La alta dirección de Iron Butterfly Company (IBC) ha decidido adoptar una forma de
organización de gestión de proyectos para el proyecto LOGON. Como consultor de
la alta dirección, se le han encomendado dos tareas para ayudar a implementar esto.
Primero, debe desarrollar una declaración de política de gestión de proyectos y una
descripción del puesto de director de proyecto. La declaración de política debe definir
el rol del gerente de proyecto con respecto a los gerentes funcionales y aclarar el rol
de los gerentes funcionales en el proyecto. La descripción del trabajo debe definir las
responsabilidades específicas y la autoridad legal del director del proyecto. Debe
considerar las reacciones de los gerentes funcionales a la declaración de política y la
descripción del trabajo y la mejor manera de obtener su "aceptación". ¿Cómo puede
el director del proyecto tener autoridad suficiente para gestionar el proyecto LOGON
sin usurpar la autoridad de los otros directores cuyo apoyo es necesario? También
debe sugerir a la alta gerencia qué formas de incentivos se pueden usar para lograr
que los miembros del equipo trabajen juntos hacia las metas del proyecto. Recuerde,
los departamentos funcionales también están actualmente involucrados en su propio
trabajo y trabajan en otras actividades del proyecto.
Su segunda tarea es especificar y documentar las calificaciones para el
cargo de gerente de proyecto LOGON. Después de considerar la naturaleza del

proyecto (alcance técnico, riesgos, complejidad, etc.) como se describe en el Caso
13.1, prepare una lista de calificaciones (antecedentes generales y experiencia,
características de personalidad, habilidades administrativas, técnicas e
interpersonales) para seleccionar candidatos y haciendo la selección final. IBC
tiene algunos empleados que han trabajado como coordinadores de proyectos y
expedidores, pero ninguno tiene experiencia como gerente de proyectos puro o
matriz. Considere las suposiciones y los pros y los contras de seleccionar un
gerente funcional o un especialista técnico dentro de IBC o un gerente de proyecto
experimentado fuera de la empresa. Se ha firmado un contrato y LOGON comenzará
en 4 meses.
Ver Capítulo 13
Caso 15.2 Selección de un Gerente de Proyecto en

Nuwave Products Company
Nuwave Products Company, un fabricante mediano de motores pequeños y piezas

de motores, contrató recientemente a una empresa consultora de software, Noware,
Inc., para diseñar software para un nuevo sistema de fabricación integrado que se
instalará en un futuro próximo. El diseño del software es parte de un proyecto
mucho más grande que también implica la adquisición e instalación de nuevos
equipos de fabricación, un nuevo proceso de producción y la capacitación de los
trabajadores. El nuevo proceso de producción involucrará conceptos de “producción
ajustada” que son muy diferentes del proceso actual de Nuwave; involucrará a los
trabajadores en los esfuerzos de mejora y probablemente requerirá nada menos
que un cambio de cultura entre los gerentes, supervisores y trabajadores de línea de Nuwave.
Normalmente, el departamento de fabricación asigna un director de proyecto a
los proyectos que implican nuevos procesos. Sin embargo, nadie en el departamento
tiene experiencia con un proyecto de este alcance, el nuevo software y
equipos, o con conceptos de producción esbelta y cambio cultural. Algunos gerentes

de Nuwave creen que, además de diseñar el software, Noware debería supervisar
todo el proyecto: la instalación del equipo, la “transición eficiente” y la capacitación
de los trabajadores. Por el contrario, el director del departamento de fabricación cree
que una de sus ingenieras superiores, Roberta Withers, debería encargarse del proyecto.
Tiene un profundo conocimiento del proceso de fabricación actual y es la experta del
departamento en sistemas mecánicos. Es ingeniera mecánica y ha estado en el
departamento de fabricación de Nuwave durante 6 años.
Ella no sabe nada sobre producción ajustada o sistemas de fabricación integrados,
pero su jefe cree que el proyecto sería una buena oportunidad para que ella aprenda.
Suponga que debe actuar sobre la información disponible en el caso: si fuera su

elección, ¿a quién seleccionaría para administrar el proyecto: Noware, Roberta u otra
persona? Explique.
Caso 15.3 Partes interesadas en Boston 31

'
s gran excavación
(Consulte el Ejemplo 15.5) Antes de que la delegación del Congreso de Massachusetts

pudiera buscar financiamiento federal para el proyecto Big Dig, primero tuvo que
encuestar a los electores sobre temas delicados de transporte. El entonces presidente
de la Cámara, Philip “Tip” O'Neal, quería saber cuál era la posición de sus partidarios,
los votantes de East Boston. Cuando se le habló por primera vez del proyecto, dijo:
“No estamos construyendo ningún túnel”. Cambió de opinión cuando sus partidarios
predijeron que “los sindicatos van a marchar sobre ti (si vetas el túnel)” y le aseguraron
que “no se perderían hogares” en East Boston. los
La delegación luego enfrentó la oposición de la administración Reagan y la FHWA,
quienes inicialmente argumentaron que el proyecto no era elegible para financiamiento
federal.
Una de las primeras responsabilidades de Joint Venture/DPW fue preparar una
declaración de impacto ambiental, cuyo borrador constaba de varios volúmenes
gruesos. La Parte I describió los impactos en 17 categorías, incluyendo
“transporte”, “calidad del aire”, “ruido y vibraciones”, “aspectos económicos”, “características

visuales”, “recursos históricos”, “calidad del agua”, “humedales y cursos de agua” y
“vegetación y vida silvestre”. Bajo “aspectos económicos” describió la actividad comercial
e industrial, el turismo y los patrones de empleo en las áreas afectadas. El informe afirmó
que el proyecto no desplazaría ninguna residencia, sino que reubicaría 134 empresas con
4100 empleados.
En la primera audiencia pública hablaron 175 personas, incluidas algunas de la EPA y

el Sierra Club, y 99 proporcionaron comentarios por escrito. La magnitud y complejidad
del proyecto se refleja en una muestra de los grupos de interés público representados:
The 1000 Friends of Massachusetts, American Automobile Association, Archdiocese of
Boston/Can-Do Alliance, Beacon Hill Civic Association, Bikes Not Bombs, Boston Building
Trades Association, Boston Society of Architects, Charles River Watershed Association,
Conservation Law Foundation of New England y Haymarket Pushcart Association.
El secretario de medio ambiente de Massachusetts emitió un certificado de aprobación,

permitiendo que la construcción continuara solo después de que se implementaron ciertas
medidas para mitigar los impactos ambientales. El certificado recomendaba la planificación
para la utilización de 27 acres del centro de Boston que se crearían recientemente
mediante la eliminación de la Arteria Central elevada, e instaba a formular "estrategias
creativas" para integrar el nuevo sistema de carreteras con el transporte público, limitar el
estacionamiento en el centro y reservar la carretera. carriles para vehículos de alta
ocupación.
Más allá de los asuntos ambientales, el proyecto tuvo que responder a los problemas
planteados por cientos de grupos, empresas y agencias; Los funcionarios establecieron la
cantidad de compromisos de mitigación temprana en 1100 para un costo adicional del
proyecto de $2800 millones, incluidos $450 millones para carriles, bordillos y aceras
temporales que permitirían que las empresas continúen durante la construcción, y $230
millones para que la ciudad de Cambridge construya un parque a lo largo del río Charles.
Preguntas
1. A partir de la información provista aquí y en el Ejemplo 15.4, cree una lista

de las partes interesadas del proyecto. Revise la Figura 15.6 para incluirlos
y mostrar posibles vínculos (relaciones o influencias) entre ellos. Para cada
parte interesada, indique sus posibles intereses en el proyecto y las formas
en que podría influir en la realización del proyecto y sus resultados.
2. Teniendo en cuenta los aspectos técnicos del proyecto (construcción de
túneles, carreteras y puentes; demolición de la estructura elevada y
reemplazo con parques) y sus impactos políticos, económicos, ambientales
y sociales (y las partes interesadas para cada uno), ¿qué características
(habilidades, antecedentes) , competencias) ¿necesitaría el gerente “ideal”
supervisar un proyecto de tal alcance y magnitud?
Notas finales
1. Sayles L. y Chandler M. Gestión de grandes sistemas: organizaciones para el futuro. Nueva York: Harper &
Fila; 1971, pág. 204.
2. Ibíd., pág. 212.
3. Ibíd., pág. 204.
4. Porciones adaptadas de Smith R. The Carving of Mount Rushmore. Nueva York: Abbeville Press; 1985.
5. Ibíd., págs. 17 y 18.
6. Ibíd., págs. 164.
7. Archibald R. Gestión de programas y proyectos de alta tecnología. Nueva York: Wiley-Interscience; 1976, pág.
35; Atkins W. Selección de un director de proyecto. Journal of Systems Management, octubre de 1980, p. 34; y
Roman D. Gestión de proyectos: un enfoque de sistemas. Nueva York: Elsevier; 1986, pág. 419.
8. Lawrence P. y Lorsch J. Organización y entorno: gestión de la diferenciación y la integración.
Boston: Escuela de Graduados en Negocios, Universidad de Harvard; 1967, Capítulo 3.
9. Estas bases del poder interpersonal fueron descritas por primera vez por French J. y Raven B. Las bases del poder social. Reimpreso en
Cartwright D. y Zander A. (eds.). Dinámica de grupo, 3ª ed. Nueva York: Harper &
Fila; 1968, págs. 259–269.
10. Hodgetts R. Técnicas de liderazgo en la organización de proyectos. Revista de la Academia de Gestión 1968;
11: 211–219.
11. Rich B. y Janos L. Skunk Works. Boston: Little, Brown & Co; 1994.
12. Katz R. y Allen T. Rendimiento del proyecto y locus de influencia en la matriz de I+D. Academia de
Revista de gestión 1985; 28(1): 67–87.
13. Archibaldo. Gestión de programas de alta tecnología, pág. 55.
14. Adams J., Barndt S. y Martin M. Gestión por gestión de proyectos. Dayton: Tecnología Universal;
1979. pág. 137.
15. Gaddis P. El director del proyecto. Revista de Negocios de Harvard; Mayo–junio de 1959, 89–97.
16. Ibíd., 95.

17. Roman, Gestión de proyectos, págs. 439–440.
18. Cusumano M. y Selby R. Secretos de Microsoft. Nueva York: Prensa Libre; 1995, págs. 105 y 106.
19. Kerzner H. Gestión de proyectos: un enfoque de sistemas para la planificación, programación y control. Nuevo
York: Van Nostrand Reinhold; 1979, pág. 99
20. Un ejemplo es la película Heaven's Gate, donde al director se le permitió dominar virtualmente el
productores de películas. Programada para completarse en 6 meses a un costo de $7.5 millones, la producción fue
lanzado un año tarde y $ 28 millones por encima del presupuesto. La película fue un fracaso de taquilla y ayudó a hacerse con el
fallecimiento del guionista de la película, United Artists. De Bach S. Final Cut. Nueva York: William Morrow;
1985.
21. Las responsabilidades de los ingenieros de proyectos se describen en Chase W. Management of Systems Engineering.
Nueva York: Wiley-Interscience; 1974, págs. 25–29.
22. Según Archibald, Management High-Technology Programs, págs. 124–128, 199.
23. Ibíd., págs. 128–131.
24. Katz y Allen, Project performance and the locus of influence, pp. 83–84.
25. Cleland D. y King W. Análisis de sistemas y gestión de proyectos, 3.ª ed. Nueva York: McGraw-Hill;
1983, pág. 358.
26. Ibíd., págs. 362 y 363.
27. Véase Schibi O. Gestión de las expectativas de las partes interesadas para el éxito del proyecto. Plantación, Florida: J Ross Publishing;
2013; Roeder T. Gestión de las partes interesadas del proyecto. Nueva York: Wiley; 2013.
28. Hughes T. Rescatando a Prometeo. Nueva York: Libros antiguos; 1998, Capítulo 5; Luberoff D., Altshuler A. y
Megaproyecto de Baxter C .: una historia política del proyecto de túnel/ arteria multimillonario de Boston.
Cambridge, MA: Centro Taubman, Escuela John F. Kennedy, Universidad de Harvard; 1993;
http://www.bigdig.com/:http://lfmsdm.mit.edu/news_articles/sdm_business_trip_fall03/sdm_business_trip_fall03.html
29. La figura 15.6 muestra a las partes interesadas antes de 1992. Después de eso, la responsabilidad de la empresa conjunta pasó del DPW
de Massachusetts al Departamento de Carreteras de Massachusetts; después de 1997 se traslada al
Autoridad de la autopista de peaje de Massachusetts (MTA). En 1998, Joint Venture y MTA formaron un “proyecto integrado
office” para combinar la experiencia de consultoría de gestión de Joint Venture con la dedicación a largo plazo y la experiencia especializada
de MTA .
Proyecto de Túnel/ Arteria Central. prensa de las academias nacionales, 2003; Capítulo 5;
http://books.nap.edu/openbook.php?record_id=10629&page=31; consultado el 8 de mayo de 2007.

30. Klinger A., Belmonte D., Chou E., Phares C., Volman N. y Pina R. The McCormick Place West
Proyecto de Expansión, Informe de Chicago de la Universidad Loyola, febrero de 2005.
31. Fuente: Hughes T. Rescuing Prometheus.

capitulo 16
Gestión de la participación, el trabajo en equipo y
Conflicto
¡Eh! je suis leur chef, il fallait bien les suivre.

¡Ah bueno! ¡Soy su líder, realmente debería seguirlos!
—Alexandre Auguste Ledru-Rollin
Trabajo en equipo. ¡No necesitamos eso!

Me saltaré este capítulo.
—Gerente de proyecto anónimo
Durante los alunizajes tripulados en la luna, el investigador Richard Chapman 1 Esto

un estudio sobre la gestión de proyectos de la NASA. apogeo:
fue durante
un período
la NASA
marcado
realizó
por
logros extraordinarios y una época en la que la NASA se mantuvo como ejemplo de una
gran agencia que realmente funcionó. Es instructivo comenzar este capítulo con algunas
de las observaciones de Chapman sobre los gerentes de proyecto de esa época;
parafraseando sus comentarios:
Además de la competencia técnica y la capacidad de gestión, todos están de acuerdo en que el director del proyecto debe tener la
capacidad de construir un equipo de proyecto cohesivo.
(pág. 93)
Aquellos gerentes de proyecto que desarrollaron los equipos de proyecto más unidos pusieron énfasis en
toma de decisiones descentralizada y resolución de problemas técnicos en el nivel donde residen tanto el problema como la mayor parte de la experiencia.
Alentaron a los miembros del proyecto a tener un sentido de responsabilidad para la resolución de problemas en sus respectivos niveles, dentro de las
pautas asignadas.
(pág. 83)
La mayoría del personal del proyecto creía que recibió un generoso apoyo y atención del gerente del proyecto, y la mayoría reconoce que el gerente del
proyecto es enérgico y justo al otorgar reconocimiento a los miembros del equipo y al recompensarlos por lo mejor de su capacidad.
(pág. 82)
En otro estudio de la NASA, EH Kloman comparó el desempeño de dos grandes proyectos,

Lunar Orbiter y Surveyor. Lunar Orbiter fue un éxito y cumplió los objetivos dentro de los límites
de tiempo y recursos; Surveyor tuvo menos éxito y experimentó sobrecostos y sobrecostos en
el cronograma. El estudio caracterizó a las organizaciones de clientes/contratistas de Lunar
Orbiter como unidades cohesivas muy unidas, con buen trabajo en equipo y respeto mutuo y
confianza entre las contrapartes del proyecto. Por el contrario, el trabajo en equipo en Surveyor
se caracterizó como "lento e irregular" para crecer y "estimulado por una sensación de ansiedad
y preocupación". 2 Kloman concluyó:
Lo que emerge quizás con más fuerza de una visión retrospectiva amplia es la importancia de los aspectos humanos de la organización y la gestión. Ambos
proyectos demostraron la naturaleza crítica de las habilidades humanas, las relaciones interpersonales, la compatibilidad entre gerentes individuales y el
trabajo en equipo.
(pág. 359)
Estos comentarios son el quid de este capítulo: los problemas de comportamiento, como la
toma de decisiones descentralizada, las habilidades interpersonales y el trabajo en equipo,
son importantes en la gestión de proyectos. Desafortunadamente, a menudo se pasan por alto
en la práctica y la educación de la gestión de proyectos, posiblemente porque los gerentes sin
experiencia y los especialistas en las disciplinas "duras" (técnicos, ingenieros y gente de
negocios) los ven como "blandos" y relativamente intrascendentes. Pero en realidad estos no
son blandos; son duros como clavos y pueden tener un impacto profundo en el desempeño del proyecto.
En este capítulo se analizan los temas abordados por los dos estudios citados: toma de
decisiones participativa, trabajo en equipo, resolución de conflictos y el tema relacionado del
estrés emocional en el trabajo.
16.1 Liderazgo en Gestión de Proyectos
Estilo de liderazgo
El Capítulo 14 describió formas organizacionales adecuadas para diferentes propósitos y tipos de

proyectos. Asimismo, existe una variedad de estilos de liderazgo adecuados, dependiendo de la
situación. El liderazgo es la capacidad de influir en el comportamiento de los demás para lograr
algo deseado; El estilo de liderazgo es la forma en que un líder logra esa influencia.
El estilo de liderazgo se puede clasificar entre los dos extremos de orientado a la tarea y
orientado a las relaciones. Los gerentes orientados a tareas muestran una mayor preocupación
por la meta y el trabajo y tienden a comportarse de manera más autocrática. Los gerentes
orientados a las relaciones muestran una mayor preocupación por las personas y tienden a
comportarse de manera más democrática.
Numerosos estudios han intentado discernir el estilo de liderazgo más efectivo. La mayoría
concluye que ningún estilo de liderazgo es mejor para todas las situaciones.
La eficacia del estilo depende de las características del líder, los seguidores, la relación
interpersonal del líder con los seguidores y la naturaleza y el entorno de la tarea. Esta perspectiva,
denominada enfoque de contingencia o situacional del liderazgo, sugiere que el líder debe aplicar
el estilo que mejor se adapte a la situación y utilizar el mismo estilo para todos los empleados y
situaciones. La siguiente sección describe brevemente dos de estos enfoques tal como los
concibieron los investigadores Fred Fiedler y Hersey and Blanchard.
Ver Capítulo 14
Enfoques de contingencia y situacionales
Según Fiedler, si (1) el 3 las tres variables que más afectan la influencia de un líder son
grupo de trabajo acepta o rechaza al líder, (2) la tarea es rutinaria o

complejo, y (3) el líder tiene una autoridad formal alta o baja. Un gerente de proyecto puede
encontrarse con cualquiera de estas situaciones, aunque comúnmente:
• El director del proyecto se lleva bien con los miembros del equipo y es respetado por su
capacidad y experiencia. • La tarea es relativamente compleja y requiere mucho juicio o
creatividad.
• El director del proyecto tiene una autoridad formal relativamente baja.
La investigación de Fiedler indica que bajo estas condiciones un estilo orientado a las relaciones es
el más efectivo. El comportamiento más destacado en este estilo son los lazos emocionales
positivos del líder y la preocupación por sus subordinados. desarrolló un modelo llamado liderazgo
4
Hersey y Blanchard situacional que sopesa la interacción de tres variables: (a) la
cantidad de dirección y orientación que brinda un líder (comportamiento de tarea), (b) la cantidad de
apoyo socioemocional que brinda (comportamiento de relaciones) y ( c) la disposición de los
seguidores para realizar la tarea (madurez). La última variable, “madurez”, tiene dos aspectos: la
habilidad o capacidad de los seguidores para hacer algo, y su motivación o disposición para hacerlo.
Según el modelo, el comportamiento del líder más efectivo depende del nivel de madurez de los
seguidores. Los gerentes de proyecto rara vez manejan trabajadores no calificados; más a menudo
tratan con especialistas técnicos, gerentes, profesionales, comerciantes y otras personas altamente
capacitadas. Por lo tanto, por lo general trabajan con personas que (1) son capaces pero quizás no
están dispuestas a hacer lo que el gerente quiere, o (2) pueden y están dispuestas a hacer lo que él
quiere. Para el Grupo (1) el modelo recomienda un estilo participativo , es decir, el líder facilitando,
apoyando y comunicándose con los seguidores; el líder comparte la toma de decisiones con los
seguidores. Para el Grupo (2), el modelo recomienda un estilo de delegación ; es decir, el líder
identifica el problema o la meta, luego delega en los seguidores la responsabilidad de resolver el
problema y determinar cómo y dónde implementarlo.
Ocasionalmente, los gerentes de proyectos se encuentran con un Grupo (3): personas dispuestas
a trabajar pero relativamente incapaces o no calificadas (por ejemplo, recién graduados
universitarios). Para este grupo, el modelo recomienda que el líder proporcione instrucción y
supervisión cercana. Sin embargo, esta situación es un caso especial, ya que incluso cuando el
gerente del proyecto da instrucciones, alienta a los seguidores a desarrollar las capacidades
necesarias para ingresar a las filas del Grupo (2).
Al investigar la gestión del personal científico y técnico, Hersey y Blanchard encontraron

que las personas con educación y experiencia de alto nivel responden bien al liderazgo
participativo y delegado, y no responden bien a las instrucciones detalladas y la supervisión
cercana. Por supuesto, esto no quiere decir que los gerentes de proyecto nunca se
enfrenten a trabajadores que no estén dispuestos a seguir instrucciones o que no tomen
la iniciativa. En los casos en que falla la participación o la delegación, es posible que un
gerente de proyecto con autoridad legal deba engatusar, dar órdenes e incluso despedir
a los trabajadores.
Circunstancias del Proyecto
El estilo de liderazgo eficaz también depende de las circunstancias del proyecto. Por
ejemplo, un estilo más directivo puede ser apropiado cuando hay presión para completar
el trabajo rápidamente; es decir, a veces el ritmo de trabajo exige un estilo de liderazgo
más directivo; es decir, la intensidad del trabajo sirve como motivador. Además, en un
proyecto de alto ritmo puede haber poco tiempo para generar la confianza necesaria para
un estilo más participativo; este es a veces el caso cuando el equipo del proyecto involucra
a subcontratistas o una fuerza laboral con la que el gerente del proyecto no está
familiarizado o no está acostumbrado a trabajar. En tales situaciones, el director del
proyecto puede necesitar ser más directivo y asertivo. Como en otros aspectos, el gerente
de proyecto debe ser adaptable, capaz de usar diferentes sombreros de estilo de liderazgo
y cambiarlos rápidamente.
16.2 Gestión participativa

Los modelos de Fiedler, Hersey y Blanchard ofrecen conclusiones similares sobre el liderazgo
de proyectos: el estilo más efectivo para los gerentes de proyectos es un estilo orientado a las
relaciones: apoyo, facilitación y aliento. A veces, los gerentes de proyecto deben dar órdenes o
decirle a la gente qué hacer, pero en la mayoría de las situaciones de proyectos, la delegación
funciona mejor, incluso cuando se combina con un comportamiento orientado a la tarea.
Esta conclusión está respaldada por investigaciones en grandes proyectos aeroespaciales

que muestran que el estilo de liderazgo más eficaz es la gestión participativa.
Los gerentes en esos proyectos rara vez dan órdenes a aquellos en quienes deben influir, en
parte porque la mayoría de estos individuos no están subordinados al gerente del proyecto, en
parte porque dar órdenes induce una reacción negativa de "no lo haré" y en parte porque los
"subordinados son, después de todo, los expertos. Los gerentes de proyecto usan la gestión
participativa porque, hasta cierto punto, deben hacerlo. Aunque tienen una buena visión del
sistema total, por lo general están más alejados de los problemas técnicos y menos calificados
para resolverlos que las personas a su cargo.
5 equipos
Motivación
El trabajo por proyectos puede ser estimulante, satisfactorio y proporcionar una gran sensación
de logro; combinados con la presión constante para cumplir con los objetivos del proyecto, estos
son motivadores naturales. Los elementos inherentes a la gestión de proyectos (contratos, WBS,
diagramas de Gantt, matrices de responsabilidad, etc.) también son motivadores. Proporcionan
metas claras que, combinadas con recompensas financieras y profesionales, motivan a las
personas de la misma manera que el enfoque de gestión por objetivos.
Pero el trabajo por proyectos también incluye desmotivadores. Demasiada presión conduce
al estrés, la tensión y el conflicto. En trabajos grandes, las personas pueden perder de vista el
producto final, alienarse y sentirse amenazados. Una ventaja de la gestión participativa es que
ayuda a obtener el compromiso de los trabajadores con las decisiones del proyecto y
disminuir los desmotivadores potenciales.

Los gerentes de proyectos participativos no renuncian a la responsabilidad; lo delegan.
Incluso cuando tienen autoridad legal, involucran a otros informándoles de los problemas, consultándoles
sus opiniones y brindándoles retroalimentación frecuente.
Se permite que los trabajadores informados ayuden a preparar los planes y presupuestos del proyecto.
A través de esa participación obtienen una apreciación de cómo encaja su trabajo.
Se sienten más asociados con el proyecto y dedicados a su éxito.
Pero, como se indicó anteriormente, las personas y las situaciones varían, y el director del proyecto
debe determinar para cada trabajador cuánta responsabilidad puede manejar y cuánta necesita ser
supervisada y dirigida. Por lo general, los gerentes de proyecto brindan apoyo, involucran a otros en la
toma de decisiones y evitan el comportamiento dogmático o impaciente. Especialmente en proyectos
con alto potencial de conflicto, invierten una energía emocional considerable en el desarrollo de la
confianza y las relaciones interpersonales.
Pero simplemente decirles a los gerentes de proyectos que necesitan desarrollar un estilo
participativo, orientado a las relaciones y las tareas no es suficiente. A menos que un gerente de
proyecto reciba apoyo para ajustar los estilos, es posible que no pueda hacerlo; los viejos patrones de
comportamiento permanecen; los nuevos son difíciles de desarrollar. A menudo, las empresas brindan
capacitación en habilidades interpersonales y creación de equipos para ayudar a los gerentes a hacer
la transición. Sin embargo, incluso con capacitación, no todos pueden cambiar el estilo de liderazgo.
La esperanza en el entrenamiento es que cada líder, si está tan motivado, al menos sabrá en qué
dirección dirigir su comportamiento.
En palabras de Bennis y Nanus, los líderes más efectivos son capaces de “alinear” las energías de
las personas y grupos detrás de la meta. Lideran “tirando en lugar de empujando; inspirando más que
ordenando”; y creando expectativas desafiantes y alcanzables y gratificando el progreso en lugar de 6
La amplia evidencia, anecdótica y empírica, es esa manipulación efectiva. los gerentes de proyecto
son líderes fuertes que utilizan la gestión participativa.
16.3 Equipos en Gestión de Proyectos
Las organizaciones de proyectos están compuestas por grupos. Como ilustra la figura 16.1 ,
en un proyecto grande, algunos de estos grupos están compuestos por personas de una
organización (en la figura, la oficina del proyecto, el equipo de gestión de nivel medio y los
equipos de paquetes de trabajo funcionales y multifuncionales), mientras que otros vienen
de múltiples organizaciones (el equipo de gestión de proyectos (PM) y el equipo funcional
entre organizaciones). La membresía en muchos de estos grupos se superpone y las
personas desempeñan múltiples roles que vinculan a los grupos.
Figura 16.1 Grupos que componen el equipo del proyecto.
El término equipo de proyecto como se usa aquí se refiere a cualquier grupo que trabaja
en el proyecto oa todos los grupos en combinación. La diferencia entre un grupo y un equipo
es que el primero es simplemente una colección de personas, mientras que el segundo es un
colección trabajando hacia un objetivo común. Prácticamente todo el trabajo realizado en un

proyecto, mental y físico, es producto de los equipos. Para tener éxito, un proyecto necesita
trabajo en equipo.
El problema con los equipos
Las fallas en los proyectos a menudo se pueden atribuir a la incapacidad de un equipo para
tomar las decisiones correctas, realizar las tareas correctas o realizar las tareas correctamente.
Estos fracasos a menudo se derivan de las enfermedades de los equipos: conflicto interno;
tiempo perdido en asuntos irrelevantes; y decisiones tomadas al azar. Los equipos a menudo
están más preocupados por hacer la tarea que por hacerla bien. Muchos equipos nunca saben
cuál es su propósito , por lo que nunca saben cuándo o si lo han logrado.
En proyectos con múltiples equipos, cada uno puede estar orientado a diferentes objetivos.
Pueden estar en oficinas separadas y físicamente aislados, lo que crea y refuerza los límites
percibidos y una actitud entre los equipos de "nosotros contra ellos". Estos crean un entorno de
proyecto portentoso que es un mal augurio para el éxito del proyecto.
Equipos de alto rendimiento
Por el contrario, los proyectos exitosos son el resultado de los esfuerzos de equipos efectivos ,
equipos que tienen éxito en lograr cualquier cosa que se propongan. ¿Qué hace que un equipo
sea efectivo? Peter Vaill estudió una gran cantidad de equipos altamente efectivos, equipos que
7
“se desempeñan a niveles de excelencia muy superiores a los de sistemas comparables”.
La característica destacada que encontró entre todos los equipos efectivos es que conocen y
están comprometidos con las metas del equipo. Los miembros nunca se confunden acerca de
por qué existe el equipo o cuáles son sus roles individuales. Los líderes inculcan la creencia en el
propósito del equipo, eliminar dudas y encarnar un espíritu de equipo. También encontró:
• Alta motivación y compromiso con el propósito del equipo. •

Trabajo en equipo centrado en la tarea. Distinciones entre funciones se disuelven
y los miembros trabajan juntos para hacer lo que deben. • El

liderazgo es fuerte, claro y nunca ambivalente. Los líderes son confiables y predecibles,
independientemente del estilo.
• El equipo se ve a sí mismo como distinto de los demás; los miembros sienten que “somos
diferente."
Vaill encontró tres características siempre presentes en los equipos de alto rendimiento, a las
que llama tiempo, sentimiento y enfoque. En primer lugar, los líderes y los miembros están
totalmente comprometidos con el proyecto y le dedican cantidades extraordinarias de tiempo.
Trabajan en casa, en la oficina, en taxis, en cualquier lugar. En segundo lugar, se sienten muy
convencidos de alcanzar la meta. Se preocupan profundamente por el propósito, la historia, el
futuro y los miembros del equipo. Y tercero, se enfocan en temas clave; tienen una lista clara de
prioridades en mente. El tiempo, el sentimiento y el enfoque siempre se encuentran juntos. Vaill
alienta a los posibles líderes a “buscar constantemente hacer lo correcto y lo que se necesita en
el sistema (enfoque). Hágalo en términos de su energía (tiempo). Pon toda tu psique en ello
8
(sentimiento)”.
Para los gerentes de proyectos, los hallazgos de Vaill subrayan la importancia de una definición
clara y un fuerte compromiso para lograr los objetivos del proyecto, la clarificación de los roles y
tareas de los miembros del equipo y un "espíritu de proyecto" que une a todos.
Ejemplo 16.1 Tiempo, Sentimiento y Enfoque en la

Gestión de Proyectos: Renovación de la Estatua de la Libertad
La renovación de la Estatua de la Libertad es un buen ejemplo del tipo de compromiso y

esfuerzo que se requiere para gestionar con éxito un proyecto a gran escala.
proyecto.9 Más de 25 firmas presentaron propuestas para la tarea de liderar el equipo
de 500 ingenieros, arquitectos, artesanos y artesanos que harían la renovación. Se
seleccionó para el trabajo la pequeña empresa de gestión de la construcción de Lehrer/
McGovern, Inc.
Hofer describe a los socios de la firma: Lehrer es de voz suave y generalmente de
apariencia conservadora; McGovern se afeita la cabeza, tiene un bigote de manubrio y usa
botas de vaquero. A pesar de las diferencias en apariencia, los dos comparten objetivos
similares y una amplia experiencia como ingenieros civiles y gerentes de construcción.
¿Le dedicaron mucho tiempo al proyecto? Para coordinar los más de

50 negocios haciendo el trabajo, Lehrer y McGovern a menudo trabajaban 16 horas al día.

Manejaron todo, desde ayudar a los arquitectos y artesanos a implementar los planes, hasta
hacer arreglos con los subcontratistas y asegurarse de que los materiales se ordenaran y
entregaran a tiempo.
¿Le inculcaron sentimiento por el proyecto? Dijo Lehrer, “este proyecto es un trabajo de
amor. El espíritu y el orgullo de cientos de hombres y mujeres involucrados sacan lo mejor de
nosotros como estadounidenses”. 10 Ellos también
esos deesperaban e inspiraban
todos los demás. sentimientosa como
Solo contrataron
personas que tuvieran “el mismo compromiso y dedicación que nosotros, que sean agresivas
y ambiciosas y entiendan que prácticamente nada es imposible”. trabajo, le dieron una lección
no se permitiría que nada dañara la “joya de la corona de los Estados
a cada
Unidos”.
subcontratista de que
¿Mantuvieron el enfoque? Su mayor énfasis estaba en el trabajo de alta calidad.

Los dos socios creían que la participación personal y cercana de la gerencia era crucial para
la calidad, por lo que realizaron visitas frecuentes al sitio y supervisaron o manejaron
personalmente miles de detalles.
Este fue un proyecto excepcional, muy publicitado y enfrentado a una presión política
considerable; pero muchos proyectos fracasan, a pesar de la alta presión y la publicidad. En
este caso, el tiempo, el sentimiento y el enfoque de la gerencia ayudaron a que el proyecto
tuviera éxito.
Equipos de proyecto efectivos
El trabajo del proyecto requiere una estrecha colaboración. Las personas en los equipos de proyecto
deben confiar y aceptar los juicios de los demás y apoyarse mutuamente. Los gerentes deben
compartir información y consultarse entre sí para tomar decisiones. Cada persona y grupo debe estar
comprometido con los objetivos del proyecto, no solo con los suyos propios.
Una forma de aumentar la colaboración y el compromiso es ubicar a todos los miembros del
equipo del proyecto en las mismas oficinas. El contacto diario frecuente hace que sea más probable
que las personas se identifiquen con el equipo y los objetivos del proyecto.
Pero incluso si fuera posible la ubicación conjunta de los miembros del equipo, la proximidad por
sí sola no garantizará un equipo eficaz. Los hallazgos de Vaill muestran que los equipos efectivos son
claro sobre su propósito, comprometido con él, conoce sus roles individuales y entiende
cómo trabajar juntos como un equipo. Sin embargo, en muchos proyectos, especialmente
cuando las personas no han trabajado juntas anteriormente, los miembros del equipo no
conocen los objetivos del equipo ni sus propias responsabilidades, y nunca aprenden a
trabajar juntos. Un propósito de la formación de equipos es asegurarse de que eso no suceda.
16.4 El enfoque de formación de equipos
En un estudio de dos centros de investigación de la NASA, se pidió a 36 gerentes de proyecto que

clasificaran las funciones más importantes de su trabajo. Clasificadas como primera o segunda por
todos los gerentes estaban las funciones de organizar, dirigir y motivar al equipo del proyecto y los
12
grupos de apoyo. En otro estudio que involucró 32 proyectos de investigación
y desarrollo de productos, se identificó la cohesión del grupo como el factor individual más importante
13
para lograr las metas del proyecto.
La cohesión y la eficacia del grupo no surgen por casualidad. Como cualquier otro sistema útil, se
debe desarrollar un equipo u organización. Este es el propósito del team building, un procedimiento
mediante el cual un equipo aborda formalmente cómo debería o ha estado trabajando, con el objetivo
de mejorar su eficacia. La creación de equipos considera los problemas del proceso grupal, que son
los procesos o métodos mediante los cuales se hacen las cosas. Los problemas se relacionan con la
toma de decisiones, la resolución de problemas, los objetivos del equipo, los conflictos internos y la
comunicación. Los grupos efectivos reconocen y monitorean estos problemas. Durante la formación
de equipos, un grupo explora tales problemas y luego planifica cómo abordará los problemas y realizará
su trabajo.
cuando se necesita
La necesidad de formación de equipos depende del equipo y la naturaleza de la tarea.

En general, cuanto más variados sean los antecedentes y las responsabilidades de los miembros del
equipo, mayor será la necesidad. Por ejemplo, los miembros de equipos multidisciplinarios tienen
diferentes antecedentes laborales y puntos de vista sobre la planificación y realización del trabajo;
algunos toman una perspectiva más amplia, otros están orientados a los detalles. La formación de
equipos puede ayudar a ambos tipos a aceptar sus diferencias y trabajar hacia objetivos comunes.
Los proyectos que involucran innovación, nuevas tecnologías, altos riesgos y cronogramas
ajustados someten a los equipos a un gran estrés. Un poco de estrés motivará a un equipo, pero
demasiado es perjudicial. La creación de equipos puede ayudar al equipo a lidiar con el estrés y a
revelar y resolver los problemas a medida que ocurren, antes de que se intensifiquen e interfieran con
el desempeño del equipo.
Aspectos de los esfuerzos de formación de equipos
El propósito de la formación de equipos es mejorar la capacidad de un grupo para trabajar juntos. Con
este fin, el enfoque se esfuerza por construir normas tales como:
1. Comunicación efectiva entre los miembros.

2. Resolución efectiva de problemas de procesos grupales.
3. Resolución constructiva de conflictos.
4. Colaboración de alto nivel entre los miembros del equipo.

5. Un ambiente de confianza y apoyo dentro del grupo.
6. Aclaración del propósito del equipo y el papel de cada miembro.
Tres características comunes a cualquier esfuerzo de formación de equipos son:
• Está cuidadosamente planificado y facilitado, a menudo por una parte externa: un consultor o
miembro del personal de relaciones humanas o de la PMO.
• La parte externa recopila datos sobre el funcionamiento del proceso del equipo por adelantado y
luego ayuda al equipo a “trabajar” con los datos durante un taller de diagnóstico/resolución de
problemas. • El equipo planifica la autoevaluación y el seguimiento posteriores.
Los siguientes son ejemplos de creación de equipos aplicados a tres situaciones: un equipo de trabajo
experimentado, un equipo nuevo y varios equipos que deben trabajar juntos.
16.5 Mejora de los equipos de trabajo en curso
Considere cómo se aplica la creación de equipos a un equipo existente, como un equipo de

gestión multifuncional, un equipo de diseño y construcción, un equipo Scrum o un equipo de
clientes, contratistas y subcontratistas. Los problemas típicos de tales equipos incluyen la
incapacidad para llegar a un acuerdo, la falta de ideas innovadoras, demasiado conflicto o
complacencia de los miembros del equipo.
Inicialmente, el gerente del proyecto o el director de la PMO llama a un consultor de relaciones

humanas u otra persona con habilidades de facilitación para facilitar el esfuerzo. Su función es
ayudar al grupo a resolver sus propios problemas llamando la atención sobre la forma en que el
comportamiento del grupo está afectando sus decisiones y desempeño.
El consultor recopila datos de los miembros mediante entrevistas personales o cuestionarios.
Luego resume los datos, manteniendo anónimas las fuentes de los comentarios individuales.
Este resumen se presentará más tarde a todo el equipo en un próximo taller.
El consultor primero comparte los resultados con el líder del equipo (jefe de proyecto o
departamento, supervisor del paquete de trabajo, etc.) y lo asesora sobre cómo prepararse para
el taller. La consultora se mantiene imparcial: todo el equipo es su cliente.
En el taller, los miembros revisan el resumen y analizan los problemas del grupo. Este taller
se diferencia de las reuniones ordinarias del personal en muchos aspectos. Se reúne en una
ubicación fuera del sitio lejos de las interrupciones, puede durar varios días e incluye a todos los
miembros del equipo. El ambiente es abierto y sincero, sin las restricciones habituales de superior
a subordinado. El consultor facilita el taller.
Los detalles del taller varían. Un formato común es este: 14
1. El taller comienza con una discusión de la agenda. Miembros del equipo

describir lo que les gustaría y lo que no quieren que suceda.
2. El consultor publica un resumen de la información recopilada en la pared para una fácil
referencia. La discusión puede ser necesaria para asegurarse de que todos entiendan
los problemas. El consultor también puede publicar citas anónimas
de las entrevistas, por ejemplo:
“Nuestras reuniones siempre están dominadas por las mismas dos o tres personas”.
“Nuestra forma de hacer las cosas es lenta y desorganizada”.
“No tengo voz en las decisiones que afectan a mi grupo funcional”.
“Aunque la líder del equipo pide nuestras opiniones, sé que las ignora”.
“Nuestro equipo no tiene un esquema sobre cómo encajar nuevas tareas en la carga de trabajo existente”.
“No hay nada que distinga los roles de ingenieros e investigadores en este proyecto”.
3. El equipo prioriza los problemas que quiere resolver en el tiempo

restricción del taller.
4. El equipo trabaja para resolver los temas prioritarios. Mientras tanto:
una. El consultor monitorea la sesión y señala los comportamientos disfuncionales

del grupo, alienta a los miembros a expresar sus sentimientos, confronta los
comportamientos que conducen a la defensiva o la desconfianza y refuerza el
comportamiento efectivo. b. El grupo se critica periódicamente a sí mismo.
Después de resolver un problema, hace una pausa para evaluar qué ayudó o
dificultó el
proceso.
C. El grupo prepara un plan de acción formal con soluciones, fechas límite y
personas responsables. El plan puede incluir “directrices operativas” que
especifiquen cómo funcionará el grupo. (Las pautas típicas se describen en la
siguiente sección).
Uno de los autores ha trabajado con equipos de proyecto en talleres para resolver de manera
efectiva problemas que van desde problemas técnicos hasta conflictos interpersonales.
Figura 16.2 El proceso de creación de equipos.
Para garantizar que se implementen los pasos de acción, el trabajo de seguimiento se programa
formalmente en sesiones de 2 a 3 meses después o menos formalmente durante las reuniones regulares.
El equipo hace un balance de su funcionamiento, las mejoras que ha realizado y lo que aún se necesita.
El propio grupo asume el papel de consultor; si surgen nuevos problemas, repite el proceso, como se
resume en la Figura 16.2.
Dos condiciones son necesarias para el éxito de la formación de equipos. Primero, el líder del
equipo y los gerentes superiores deben aceptar los problemas descubiertos y ayudar (o proporcionar
recursos) para trabajar en la búsqueda de soluciones. Segundo, los miembros del equipo deben querer
resolver los problemas del grupo. Deben ser abiertos y honestos al proporcionar información, dispuestos
a compartir la responsabilidad de haber causado los problemas y dispuestos a trabajar para encontrar
soluciones.
16.6 Creación de nuevos equipos
Por lo general, las personas de los nuevos equipos desarrollan rápidamente vínculos interpersonales
basados en atributos como la edad, el género o la nacionalidad similares. Desafortunadamente, tales
lazos pueden ser superficiales y perjudiciales para la unidad y el desempeño del equipo; lo que es
mejor en términos de cohesión y desempeño del equipo es que desarrollan vínculos en torno a
habilidades, competencias y tareas compartidas. Por lo tanto, los primeros esfuerzos de creación de
equipos deberían proporcionar a los miembros del equipo la oportunidad de trabajar juntos en tareas
15
relacionadas con los objetivos del proyecto y desarrollar relaciones orientadas a la competencia o la tarea.
El propósito de la formación de equipos para un equipo recién formado es que el equipo llegue a
un acuerdo sobre su propósito, cómo logrará su propósito y las funciones de sus miembros. El equipo
también se ocupa de cómo sus miembros trabajarán juntos de manera tal de lograr su propósito de
manera efectiva y hacer que todos se sientan bien con él y con los demás.
Un taller de trabajo en equipo es convocado por un facilitador. Durante el taller, los miembros se
familiarizarán, llegarán a un acuerdo sobre los objetivos y decidirán cómo funcionarán como equipo.
En Team Building: Issues and Alternatives, William Dyer describe la agenda de dicho taller de la
siguiente manera: 16
Paso 1: desarrollar un nivel de prioridad
Los miembros de un equipo a veces difieren en la prioridad que le dan a la meta del proyecto oa las
tareas de trabajo. Especialmente en equipos ad hoc o grupos de trabajo con miembros a tiempo
parcial, algunos miembros le dan alta prioridad al proyecto, otros baja. Una forma de reconocer estas
diferencias es que cada miembro indique en una escala de 0 a 10 la prioridad del proyecto en
comparación con su otro trabajo. Otra forma es pedirle a cada uno que indique la cantidad de tiempo
que puede dedicar al proyecto cada día o semana. La información se cuenta y se publica en un gráfico
similar a la figura 16.3. Los miembros del equipo discuten las diferencias en sus compromisos con el
proyecto y se invita a los individuos a explicar sus posiciones en el gráfico. La discusión ayuda a
reducir el resentimiento potencial de algunos miembros que se comprometen a más
trabajo o menos trabajo que otros.
Paso 2: Comparte las expectativas
Se le pide a cada persona que piense en lo siguiente: (1) ¿Cómo sería este equipo si todo
funcionara idealmente? (2) ¿Cómo sería si todo saliera mal? (3) En general, ¿qué tipo de
problemas ocurren en los grupos de trabajo? y (4)
¿Qué acciones se deben tomar para hacer de este un equipo efectivo? Las respuestas se
comparten verbalmente y luego se publican. Se discuten las preocupaciones. Estos se
trabajarán más adelante en el Paso 4.
Paso 3: Aclarar el Propósito y los Objetivos
El equipo discute y registra su propósito y objetivos. A veces esto es sencillo, como cuando ya
se han establecido los objetivos; otras veces el grupo tendrá que definir sus objetivos desde
cero. De cualquier manera, el propósito y los objetivos deben estar claramente definidos y
aceptados por todos. Luego, el grupo desarrolla subobjetivos para que los miembros puedan
recibir tareas específicas.
Los objetivos deben complementar cualquier objetivo y requisito del usuario y del sistema tal
como se define en el SOW o la Carta (descritos en los Capítulos 3 a 5). De hecho, una sesión
como esta se puede utilizar para crear el SOW o la carta.
ver capítulos 3–5
Figura 16.3 Clasificación de prioridad del proyecto para diez miembros del equipo.
Paso 4: Formular pautas operativas
La disfunción del grupo a menudo surge de expectativas mixtas sobre los roles de trabajo, las
asignaciones de trabajo y cómo debería funcionar el grupo. Esto puede evitarse si el equipo
establece pautas operativas que aborden, por ejemplo:
1. ¿Cómo tomará decisiones el equipo: por dictado del líder, por voto, por consenso o por
otros medios? ¿Quién debe participar en la toma de decisiones? Por ejemplo, en
algunos casos tal vez solo dos o tres miembros deberían estar involucrados; en otros,
sólo las personas mejor informadas; en otros, todo el equipo.
2. ¿Cómo resolverá el equipo las diferencias entre los miembros y subgrupos?

Los desacuerdos hacen perder mucho tiempo, por lo que las pautas deben abordar los
tipos de conflictos que probablemente surjan y las opciones para resolverlos: consenso,
votación o llamar a un mediador.
3. ¿Cómo se asignará el trabajo? ¿Qué tareas deben ser manejadas por todo el grupo,
cuáles por subgrupos o individuos? ¿Deben asignarse las tareas de acuerdo con la
experiencia, la posición de autoridad o la preferencia personal? Si varias personas
quieren hacer una tarea, ¿cómo deben elegirse: por habilidad, experiencia o
voluntariado?
4. ¿Cómo se asegurará el equipo de que se complete el trabajo? Una persona que se
atrasa puede retrasar el trabajo de los demás. ¿Cómo garantizará el equipo que las
asignaciones y las fechas de finalización estén claras y que se tomen medidas
correctivas cuando los esfuerzos se retrasen o estén fuera de control? ¿Quién ayudará
si alguien se atrasa? ¿Cómo manejará el equipo a los holgazanes?
5. ¿Cómo asegurará el equipo una discusión abierta? El equipo debe asegurarse de que
los miembros puedan discutir abiertamente los problemas para que las ideas no sean
ignoradas o suprimidas, y todos sean escuchados. ¿Cómo se mantendrá comprometida
a la gente menos inclinada a hablar debido a su personalidad, idioma o cultura? ¿Cómo
se aquietará a la gente locuaz?
6. ¿Con qué frecuencia y dónde se reunirá el equipo? ¿Quién se espera que asista?
¿Cómo se informará a las personas ausentes sobre lo sucedido en las reuniones?
7. ¿Cómo evaluará el equipo su proceso y los cambios necesarios? El equipo

especifica un procedimiento para revisar periódicamente si las pautas anteriores están

funcionando o deben cambiarse. Algunos equipos nombran a un miembro para cada
reunión con el rol de asegurarse de que el equipo cumpla con esta guía.
Los equipos también pueden discutir las funciones y responsabilidades actuales de sus miembros e
identificar cualquier ambigüedad, superposición o conflicto.
Un nuevo equipo no tiene que esperar a que surjan problemas antes de actuar.
A través de la creación de equipos, puede desarrollar expectativas y pautas para prevenir problemas
grupales comunes.
Equipos de disolución
Lo opuesto a la creación de equipos es la disolución del equipo. Los equipos exitosos generan lazos
estrechos y relaciones sólidas; cuando finaliza el proyecto, las personas suelen ser reacias a
abandonar las relaciones y, de hecho, pueden sufrir sentimientos de pérdida. Estos sentimientos
deben ser reconocidos y compartidos. El cierre del proyecto puede ir seguido de una ceremonia (un
banquete, una fiesta o una reunión informal) para reconocer al equipo por sus logros y despedirse.
16.7 Resolución de problemas intergrupales
Cuando varios equipos deben trabajar juntos, surgen problemas entre ellos, como comunicar
u ocultar información, competencia entre ellos o coordinar sus esfuerzos. La resolución de
problemas intergrupales (IGPS) es una técnica para mejorar las relaciones de trabajo entre
varios equipos; siguiente es un ejemplo.
17
Los dos grupos se reúnen por un día. En ese tiempo:
1. Cada grupo compila cuatro listas: (1) lo que creen que el otro grupo es responsable;
(2) lo que sienten que son las fortalezas y debilidades del otro grupo; (3) lo que el
grupo piensa que son sus propias responsabilidades; y (4) lo que el grupo anticipa
que el otro grupo piensa sobre ellos (fortalezas, debilidades, responsabilidades).
2. Los grupos se reúnen para compartir sus listas. La única discusión permitida es para
aclarar puntos de desacuerdo.
3. Los grupos se separan, esta vez para discutir lo que aprendieron de las listas de los
demás y para enumerar y priorizar los problemas que deben resolverse.
4. Finalmente, los grupos se reúnen nuevamente para discutir las diferencias y desarrollar
un plan mutuo para resolverlas.
Los grupos se reúnen nuevamente unas semanas más tarde en una sesión de seguimiento
para evaluar qué tan bien está funcionando su plan. El resultado suele ser una comprensión
mucho mejor de las expectativas de cada grupo sobre el otro y una mejor relación de trabajo.
IGPS se aplica cada vez que los grupos interactúan o deben trabajar juntos. Algunos
ejemplos son los equipos de proyecto compuestos por grupos de diferentes contratistas. Sin
IGPS, cada grupo a menudo trata de optimizar sus propias metas y las metas generales del
proyecto o programa se ven afectadas. IGPS es útil siempre que existan interdependencias,
plazos o situaciones que provoquen conflicto y estrés entre grupos.
Es probable que los participantes en una sesión intergrupal tengan una experiencia "genial".
Cada grupo puede descubrir que sus expectativas difieren significativamente (y entran en
conflicto con) las de otros grupos. Esta realización es un primer y necesario paso para alinear
las expectativas y la planificación para resolver las diferencias.
Una advertencia es que los grupos no deben participar en IGPS hasta que primero
resuelvan cualquier problema interno serio . En otras palabras, un grupo primero debe
tener su propia casa en orden (construirse en equipo) antes de intentar resolver sus
problemas con otros grupos.
16.8 Equipos virtuales
A veces, todos los miembros del equipo del proyecto (el gerente y todos sus miembros) se
encuentran en un lugar diferente. Dichos equipos, llamados equipos virtuales o distribuidos , son
comunes en proyectos de diseño y desarrollo donde los especialistas se encuentran en todo el
mundo. En ocasiones, el director del proyecto o los miembros del equipo pueden reunirse cara a
cara con otros miembros, pero a menudo eso nunca sucede y su interacción es únicamente a través
de la tecnología de la comunicación.
Aunque se aplican muchos de los principios de liderazgo y formación de equipos descritos
anteriormente, la gestión de equipos virtuales requiere una consideración especial. La gente no
puede cruzar el pasillo para hacer preguntas o convocar una reunión por capricho; deben confiar en
la tecnología para comunicarse. Esto dificulta la toma de decisiones, el seguimiento de los
compromisos, el seguimiento de los resultados y la construcción de relaciones y la cohesión del
equipo. Y todo empeora cuando el equipo se distribuye en diferentes zonas horarias, idiomas y
culturas.
18
Tecnología de la comunicación
Los equipos virtuales existen en virtud de la tecnología. Cuando los presupuestos de viaje son
escasos, la mayor parte de la comunicación se realiza electrónicamente. Hay muchas opciones
tecnológicas disponibles, y un proyecto generalmente empleará varias. Todos caen bajo el título de
"groupware", que es un software para facilitar que las personas trabajen juntas en una tarea común.
Groupware que emula reuniones cara a cara y permite que las personas hablen
continua y simultáneamente se llama síncrono; incluye:
• Conferencias de datos en tiempo real y de

escritorio • Sistemas de reuniones electrónicas
• Videoconferencias • Audioconferencias •
Mensajería instantánea (IM).
El software colaborativo que solo permite la comunicación intermitente de ida y vuelta se denomina asíncrono;
esto incluye:
• Correo electrónico
• Dispositivos informáticos personales •

Calendarios y horarios de grupo • Tableros
de anuncios
• Sitios web del equipo.
La tecnología adecuada depende en gran medida de la tarea. Las tareas y decisiones ambiguas o desafiantes
requieren tecnologías que son "ricas en medios" e imitan una conversación normal, es decir, tecnologías
sincrónicas. Las tecnologías asincrónicas como el correo electrónico no son ricas en medios; su uso debería
limitarse a compartir información y documentación. Los equipos virtuales, sin embargo, comparten mucha
documentación porque, en general, en ausencia de reuniones presenciales, la escritura reemplaza la
conversación; simplemente, los equipos virtuales necesitan escribir más. Incluso las conferencias de audio y las
llamadas telefónicas a la antigua deben ser seguidas por escrito para garantizar la claridad.
La tecnología que se utilizará debe ser compatible con el hardware/software en los sitios de los diferentes
miembros del equipo. Además, los miembros deben sentirse cómodos con el uso de la tecnología y tener
acceso a la capacitación.
Equipo Cohesión 19
En general, en un equipo cohesionado los miembros comparten una visión y confían unos en otros.
Entre las formas en que el gerente de proyecto construye una visión compartida están:
• Explicar al equipo la importancia del proyecto y la contribución de cada miembro. En un equipo

internacional, el director del proyecto podría tener que viajar a todos los sitios para hacer esto.
• Negociar y aclarar los roles, responsabilidades y responsabilidades de todos.
• Identificar medidas de desempeño orientadas a resultados para cada miembro; las medidas deben ser
lo suficientemente específicas para que el director del proyecto pueda medir
el desempeño de cada miembro.
• Relacionado con el punto anterior, desarrollar métodos para revisar el progreso. Esto podría requerir
revisiones semanales de audioconferencias.
• Establecer protocolos de comunicación en cuanto a:
• modos de comunicación preferidos: correo electrónico, voz, mensajería instantánea,
mensajes de texto, etc. • tiempo transcurrido aceptable para responder mensajes • mejor
hora del día para llamar o programar reuniones • horas en que las personas están en la
oficina • horas fuera de la oficina aceptables para llamar o reunir.
• Cree pautas operativas del equipo para la toma de decisiones, resolución de conflictos, etc., e inclúyalas en
el estatuto del equipo. Si el equipo puede reunirse cara a cara al menos una vez, esto se puede hacer
utilizando el procedimiento de la Sección 16.6.
El líder debe esperar y reforzar el cumplimiento de las directrices.
Confianza20
La cohesión del equipo también depende del nivel de confianza entre el director del proyecto y los miembros del
equipo. La mejor forma integral de generar confianza es a través del contacto cara a cara. Un equipo virtual no puede
hacer eso regularmente, aunque ocasionalmente puede permitir/animar a los miembros a visitar los sitios de los
demás. Una alternativa es que los representantes de los subequipos en diferentes sitios "floten" entre los otros sitios
del proyecto. Otra es que todo el equipo se reúna para una reunión de lanzamiento del proyecto. Independientemente
de la alternativa, las visitas/reuniones deben ser lo suficientemente largas (varios días o semanas) para que las
personas se “conozcan” y desarrollen vínculos personales; este es más el propósito de las visitas que hacer un
trabajo. Idealmente, las visitas/reuniones cara a cara ocurren al comienzo del proyecto; si eso no es factible, deberían
ocurrir siempre que lo sea. Como mínimo, el gerente del proyecto debe tratar de reunirse con todos al menos una vez
en persona, aunque lo ideal es que sea más frecuente, si es posible. Cohen llama a esto “administración al volar”, el
equivalente en equipo virtual de la administración al caminar. ¡Él dice que debe esperar que el presupuesto de viaje
aumente con los equipos virtuales, no disminuya!
21
En general, la confianza se desarrolla cuando las personas ven que otros se desempeñan de manera competente,
actuar con integridad y mostrar preocupación por el bienestar de los demás; se erosiona cuando dudan
unos de otros o del líder. Es importante que todos reciban información crítica al mismo tiempo, de lo
contrario, los individuos podrían percibir que el líder u otros los están excluyendo u olvidando.
Faltan pistas definitivas sobre el desempeño en equipos virtuales, por lo que incluso una pequeña
información negativa puede destruir la reputación de un individuo o equipo. El director del proyecto y los
miembros del equipo deben apoyar al equipo y al proyecto en las buenas y en las malas; esto es cierto
para los equipos presenciales, pero más aún para los equipos virtuales. La información que indique un
rendimiento deficiente nunca debe aceptarse sin investigarla primero.
22
Reuniones Virtuales
La gestión de reuniones de un equipo virtual plantea problemas especiales. Duarte y Snyder recomiendan
lo siguiente.
• Participación. No todos necesitan o tienen tiempo para asistir a todas las reuniones. El director
del proyecto debe decidir para cada reunión cuál de los miembros del equipo es obligatoria y
cuál es opcional. Explique a las personas no invitadas el motivo y cuándo o si obtendrán los
resultados de la reunión. Almacene documentos importantes en una carpeta web para que las
personas que no estén en las reuniones puedan mantenerse al día.
• Preparación. Distribuya la agenda de la reunión de antemano para que la gente pueda prepararse.
Explique qué personas se espera que contribuyan, cuánto (un poco o mucho) y de qué manera.
Trate de obtener las reacciones de las personas sobre los problemas y las respuestas a las
preguntas antes de la reunión.
• Durante la reunión. Permita tiempo al comienzo para una pequeña charla y charla.
En las conferencias de voz, siempre comience la conversación anunciando quién está hablando.
Cohen sugiere que en las audioconferencias se designe a una persona en cada lugar con buen
oído para las voces para mostrar una imagen de quien esté hablando del otro lado. ¡La gente se
acostumbra a esto y realmente mira la foto como si fuera la foto la que habla!
23
• Sea inclusivo. Salude a cada miembro o pídale que se presente. Hacer

asegúrese de que todos sean escuchados; pide a todos que participen y llama a la gente
que no han hablado. Sea culturalmente sensible para no poner a nadie en un aprieto.
Busque un punto de vista diverso, como pedirle a un miembro que haga de abogado del
diablo. Practique comunicarse de maneras que conduzcan a la confianza: muestre respeto,
use nombres que las personas prefieren que las llamen, cree un diálogo, no un monólogo,
y escuche con atención. Sea indulgente cuando alguien comete un error.
• Marcar el ritmo de la reunión. Guiar la discusión hacia una resolución o postergación;

recordar a la gente el tiempo restante. Establecer la asignación de tiempo para cada
elemento; pregunte si el equipo quiere extender la reunión.
• Hacer cumplir la participación. Verifique con frecuencia que todos estén cumpliendo con
la agenda. Observe si los miembros no han hablado y solicite su opinión. En las reuniones
que no se llevan a cabo en el idioma nativo del equipo, los miembros pueden tener
problemas para mantenerse al día con la discusión. Proporcione descansos para que
organicen y recopilen sus pensamientos. • Resumir. Al final, resuma la discusión y
asegúrese de que se registren las decisiones o acciones. Obtenga compromisos sobre quién
hará qué. Intente que las actas de la reunión estén disponibles para todos unos días
después de la reunión. Tenga cuidado de asegurarse de que las actas (y las interpretaciones
de lo que se dijo) sean correctas.
16.9 Conflicto
En todas las organizaciones, las diferencias en objetivos, expectativas y valores conducen al

conflicto. Los proyectos no son una excepción y, en todo caso, están predispuestos al conflicto.
Los conflictos surgen entre clientes y contratistas, proyectos y grupos funcionales, y
subcontratistas y departamentos. Ocurre entre personas en el mismo equipo, diferentes
equipos en la misma organización y equipos en diferentes organizaciones.
Y es común en los equipos virtuales donde los medios de comunicación electrónicos pueden
amplificar los malentendidos y dificultar la generación de confianza. Algunos conflictos son
naturales y beneficiosos; demasiado es destructivo.
Entre Usuario y Contratista
Las semillas del conflicto cliente-contratista se siembran temprano durante las negociaciones
del contrato. Las personas que representan a las dos partes por lo general están menos
preocupadas por generar confianza que por impulsar un trato duro para sus propios intereses.
El cliente quiere minimizar los costos, el contratista maximizar las ganancias. La ganancia de
uno es la pérdida del otro. En el extremo, cada parte se esfuerza por llegar a un acuerdo que
proporcione una "salida" en caso de que no pueda cumplir con su parte del trato; cada uno
trata de responsabilizar al otro en caso de fracaso. Dice un gerente,
Se empieza con la ciencia y la ingeniería, pero el proyecto, una vez decidido, hay que costearlo. Tienes que seleccionar
contratistas y obtener la aprobación de los presupuestos. Luego recurre a los contratistas que trabajan con usted y escribe
contratos que dicen que no confía en ellos. Lo que comienza como un hermoso sueño científico termina siendo una masa
24
de anguilas resbaladizas.
El contrato mismo se convierte en una fuente de conflicto. Un acuerdo de costo incrementado

puede brindar pocos incentivos para que el contratista controle los gastos, y el cliente debe
supervisar todo de cerca. Tal escrutinio es un irritante constante para el contratista. En un
contrato de precio fijo, el contratista puede solicitar revisiones al alza periódicas, también una
fuente de conflicto. Es probable que cualquier contrato con términos mal especificados de
costo, cronograma o desempeño tenga múltiples interpretaciones y genere desacuerdos.
Dentro de la Organización del Proyecto
La interdependencia de alto nivel en los proyectos entre áreas funcionales aumenta la cantidad de
contacto entre ellas y, al mismo tiempo, las posibilidades de conflicto.
Las diferentes áreas tienen diferentes ideas, objetivos y soluciones para problemas similares,
diferencias que a veces deben resolverse sin el beneficio de un común
superior.
Además, las necesidades de las áreas funcionales a menudo son incompatibles con las necesidades
del proyecto, y las áreas funcionales a menudo solicitan cambios en el plan del proyecto que el director
del proyecto debe rechazar. El gerente del proyecto podría tener que comprometer los altos estándares
técnicos de los departamentos funcionales con consideraciones de tiempo y costo del proyecto.
Incluso cuando los directores de proyectos están de acuerdo con el juicio técnico de los especialistas,
a veces no están de acuerdo sobre los medios de implementación.
En las organizaciones matriciales, los gerentes funcionales a veces ven a los gerentes de proyectos
como si invadieran su territorio y les molesta tener que compartir la planificación y el control con ellos.
Pueden negarse a liberar a cierto personal para proyectos o tratar de retener la autoridad sobre el
personal que liberan. Los trabajadores con relaciones de doble reporte a menudo se sienten en
conflicto sobre prioridades y lealtades.
Además, la gente suele ser reacia a aceptar el cambio, pero en los proyectos el cambio es la
norma. Los procedimientos administrativos, las interfaces de grupo, el alcance del proyecto y las
asignaciones de recursos están en constante cambio. Los cambios en la fuerza laboral dificultan el
establecimiento de relaciones de subordinación duraderas.
Finalmente, los proyectos heredan disputas que no tienen nada que ver con ellos. Independientemente
del entorno, los enfrentamientos surgen de las diferencias de actitudes, objetivos personales y rasgos
individuales, y de las personas que intentan avanzar en sus carreras. Estos crean una historia de
antagonismos que preparan el escenario para el conflicto mucho antes de que comience un proyecto.
El ciclo de vida del proyecto
Thamhain y Wilemon 25 investigó las fuentes de conflicto en un estudio que involucró a

100 gerentes de proyecto. Determinaron que las tres mayores fuentes de conflicto son los cronogramas,
las prioridades de los proyectos y la fuerza laboral, todas las áreas sobre las cuales
los gerentes de proyecto generalmente tienen un control limitado. Otras fuentes de conflicto
identificadas son las opiniones técnicas y las compensaciones de desempeño, los problemas
administrativos y organizacionales, las diferencias interpersonales y los costos. Los costos son una
causa de conflicto relativamente menor, suponen los autores, no porque los costos no sean
importantes, sino porque son difíciles de controlar y, por lo general, se tratan de manera incremental
a lo largo de la vida de un proyecto.
También encontraron que las fuentes de conflicto cambian de una fase a la siguiente, como se
resume en la Figura 16.4.
Durante la concepción del proyecto, las fuentes de conflicto más significativas son las prioridades,
los procedimientos administrativos, los cronogramas y la mano de obra. Las disputas entre el
proyecto y las áreas funcionales surgen sobre la importancia relativa del proyecto en comparación
con otras actividades, la cantidad de control que debe tener el gerente del proyecto, el personal
que se asignará y la programación del proyecto en las cargas de trabajo existentes.
Durante la definición del proyecto, la principal fuente de conflicto siguen siendo las prioridades,
seguidas de los cronogramas, procedimientos y cuestiones técnicas. Los conflictos de prioridad se
mantienen desde la fase anterior, pero surgen nuevas disputas sobre el cumplimiento de los
horarios y los esfuerzos de los departamentos funcionales para cumplir con los requisitos técnicos.
Figura 16.4 Principales fuentes de conflicto durante el ciclo de vida del proyecto.
Fuente: Adaptado de H. Thamhain y D. Wilemon, “Gestión de conflictos en los ciclos de vida del proyecto”, Sloan
Management Review, primavera de 1975: 31–50.
Durante la ejecución surgen fricciones por desfases en el cronograma, problemas técnicos y

cuestiones laborales. Los plazos pueden volverse difíciles de cumplir debido a
acumulando desfases de horario. Los esfuerzos destinados a la integración del sistema, el rendimiento
técnico de los subsistemas, el control de calidad y la confiabilidad también encuentran problemas.
Los requisitos de mano de obra crecen al máximo y ejercen presión sobre el grupo disponible de
trabajadores.
Durante el cierre, los cronogramas siguen siendo la principal fuente de conflicto, ya que los
desfases acumulados dificultan el cumplimiento de la fecha de finalización prevista. Las presiones
por cumplir los objetivos y la ansiedad por los proyectos futuros aumentan las tensiones y los conflictos
de personalidad. La incorporación paulatina de nuevos proyectos y la absorción de personal
nuevamente en áreas funcionales crean más conflictos.
Consecuencias del conflicto
El conflicto es inevitable en los esfuerzos humanos y no siempre es perjudicial.

26
Manejado adecuadamente, una cierta cantidad de conflicto es bueno porque:
1. Obliga a las personas a buscar nuevos enfoques.

2. Hace que los problemas persistentes afloren y sean tratados.
3. Obliga a las personas a aclarar sus puntos de vista.
4. Estimula el interés y la creatividad.

5. Brinda a las personas la oportunidad de probar sus capacidades.
De hecho, la ausencia total de conflicto no es saludable. Llamado pensamiento de grupo, es un signo

de exceso de conformidad. Provoca monotonía e monotonía y da como resultado un juicio pobre o
mediocre. Por el contrario, una cierta cantidad de conflicto por las diferencias de opinión estimula la
discusión y puede mejorar la resolución de problemas. En los grupos de proyectos encargados de
explorar nuevas ideas o resolver problemas complejos, es esencial que haya algún conflicto.
El conflicto entre grupos que compiten es beneficioso porque aumenta la cohesión del grupo, el
espíritu, la lealtad y la intensidad de la competencia.
Sin embargo, el conflicto entre equipos que deberían cooperar puede ser devastador.
Cada grupo desarrolla una actitud de “nosotros contra ellos” y se esfuerza egoístamente por lograr
sus propios objetivos. Si no se controla ni se resuelve, el conflicto aumenta en espiral y genera
hostilidad. Dentro de un proyecto, el conflicto fomenta la falta de respeto y confianza, y destruye la
comunicación entre grupos e individuos. Ideas, opiniones o
las sugerencias de otros son rechazadas o desacreditadas. El espíritu de proyecto se derrumba y la

organización del proyecto se fragmenta.
Ejemplo 16.2 Conflicto en los equipos de desarrollo de

productos 27
Microsoft forma pequeños equipos en torno a los productos y luego les permite organizarse y
trabajar como deseen. Contrata a personas brillantes y agresivas recién egresadas de la
escuela, y luego las presiona para que obtengan lo mejor de ellas.
Como describe el autor Fred Moody, cada equipo de producto consta de diseñadores cuya
tarea es tratar de agregar características al producto; desarrolladores cuyo papel parcial es
resistir las funciones por cumplir con los plazos; y un administrador de programas cuya función
es mediar y dictar veredictos. Además de tener diferentes tareas y objetivos, existe un gran
abismo entre desarrolladores y diseñadores en términos de temperamento, intereses y estilos.
Los desarrolladores a menudo sienten que es imposible hacer que los diseñadores entiendan
incluso los elementos más simples de un problema de programación. Los diseñadores pueden
pasar semanas en algún aspecto de un producto, solo para que un desarrollador les diga
groseramente que será imposible implementarlo. Los diseñadores son de las artes;
desarrolladores de matemáticas y ciencias. Los diseñadores tienden a ser mujeres,
vegetarianos, habladores y viven en lofts; los desarrolladores tienden a ser hombres, comen
comida rápida y hablan poco, excepto para decir "No es cierto". La forma en que lidian con el conflicto también di
Los desarrolladores son dados a ráfagas de juegos traviesos y salpicarán la puerta de un
diseñador con disparos de una pistola Nerf-ball. Los diseñadores simplemente se quejan con
su supervisor.
Esta relación de confrontación afecta al equipo, el producto, los clientes y la empresa.
Moody cita al desarrollador principal de un proyecto, quien dijo: “Nunca había pasado por algo
así. Cometimos los mismos errores antes, y ahora los estamos cometiendo nuevamente.
Todo proyecto es así. Seguimos diciendo que aprendemos de nuestros errores, pero seguimos
pasando por el mismo [improperio] una y otra vez”.
16.10 Gestión de conflictos de grupo
¿Cómo afrontan las personas los conflictos? En general hay cinco formas:
1. Retirarse o retirarse del desacuerdo.

2. Suavizar o restar importancia a la importancia del desacuerdo
(hacer de cuenta que no existe).
3. Forzar el asunto ejerciendo poder.
4. Comprometerse o negociar para traer al menos algún grado de satisfacción a
todas las fiestas.
5. Enfrentar el conflicto directamente; trabajar a través del desacuerdo con la resolución de

problemas.
Todos estos son a veces apropiados. En una discusión acalorada, puede ser mejor retirarse hasta
que las emociones se hayan calmado, o quitarle énfasis al desacuerdo antes de que se distorsione
fuera de proporción. Pero ninguno de estos resuelve el problema, que probablemente volverá a
surgir. Un gerente podría forzar el problema usando la autoridad; esto hace que la acción se lleve a
cabo, pero corre el riesgo de crear hostilidad. Como se discutió anteriormente, si se debe usar la
autoridad, es mejor que se base en el conocimiento o la experiencia. Para negociar o llegar a un
compromiso, ambas partes deben estar dispuestas a renunciar a algo para obtener algo y, en última
instancia, pueden sentir que perdieron más de lo que ganaron. De los cinco enfoques, el único que
funciona para resolver los problemas subyacentes es la confrontación.
Confrontación
La confrontación implica identificar problemas potenciales o existentes y luego enfrentarlos. A nivel

de organización, esto sucede cuando todas las áreas involucradas en el proyecto acuerdan los
objetivos, planes, requisitos de mano de obra y prioridades del proyecto. Requiere un seguimiento
cuidadoso de los cronogramas, un estrecho contacto entre los grupos de proyectos y una pronta
28
resolución de los problemas técnicos.
A nivel individual, un gerente de proyecto confronta los conflictos planteando
29
preguntas y desafíos como:
¿Cómo sabes que este rediseño resolverá el problema? Pruébamelo.

¿Qué ha hecho para corregir las fallas que aparecieron en la prueba que acordamos?
¿Cómo espera recuperar el tiempo perdido si no ha programado horas extras?
Preguntas como estas demuestran que el gerente del proyecto está vitalmente interesado y alerta, y
que todo está sujeto a cuestionamiento. Es una parte crucial de la gestión eficaz de proyectos.
Sin embargo, hay una trampa: el mismo proceso de confrontación es en sí mismo una fuente de
conflicto, pero a nivel interpersonal . Con frecuencia, lo que comienza como un conflicto de horarios,
prioridades o cuestiones técnicas degenera en un conflicto de “personalidades”.
La confrontación exitosa supone mucho sobre los individuos y grupos involucrados. Asume que
están dispuestos a revelar por qué favorecen un determinado curso de acción, y que están abiertos y
no son hostiles a las opiniones diferentes. Asume que todos están trabajando hacia un objetivo común
y están dispuestos a abandonar una posición a favor de otra.
El simple hecho es que muchos grupos y gerentes son muy críticos con las opiniones de los demás.
Frente a las diferencias, tienden a operar emocionalmente, no analíticamente. Para que las personas
utilicen la confrontación como una forma de resolver conflictos, primero deben ser capaces de manejar
sus emociones.
30
Técnica de aclaración de roles
El conflicto en los proyectos a menudo surge porque las personas tienen expectativas mixtas sobre los
planes de trabajo, los roles y las responsabilidades. En particular, los desacuerdos surgen porque:
• El proyecto es nuevo y la gente no tiene claro lo que se supone

hacer y lo que otros esperan de ellos.
• Los cambios en los proyectos y las reasignaciones de trabajo han dejado poco claro cómo
los miembros del equipo deben interactuar.
• Las personas reciben solicitudes que no entienden o escuchan cosas en el
rumores que creen que ya deberían saber.
• Todos piensan que alguien más está manejando una situación que, en realidad, nadie lo hace.
• Las personas no entienden lo que está haciendo su grupo u otros grupos.
La técnica de aclaración de roles (RCT) es un procedimiento sistemático para ayudar a

resolver estas fuentes de conflicto. Como sugiere el título “aclaración de roles”, el objetivo es
que todos entiendan sus propias responsabilidades y deberes principales y los de los demás,
y que todos sepan lo que los demás esperan de ellos.
RCT es similar a la formación de equipos. Incluye la recopilación de datos, una reunión de
un día y un consultor que actúa como facilitador. Cuando se incorpora como parte de la
creación de equipos para un nuevo equipo, permite que el gerente del proyecto y el equipo
negocien los roles de los miembros del equipo. Es especialmente útil en casos donde las
responsabilidades son algo ambiguas.
La técnica aplicada a un equipo existente comienza cuando cada persona responde un
31
cuestionario antes de una reunión:
1. ¿Qué espera la organización de usted en su trabajo?

2. ¿Qué haces realmente en tu trabajo?
3. ¿Qué deberían saber los demás acerca de su trabajo que les ayudaría?
4. ¿Qué necesita saber acerca de los trabajos de los demás que le ayudaría?
5. ¿Qué dificultades experimenta con los demás?
6. ¿Qué cambios en la organización o actividades mejorarían el desempeño del grupo?
¿trabajar?
Al comienzo de la reunión del grupo, se anuncian las reglas básicas: las personas deben ser
sinceras, dar respuestas honestas y expresar sus preocupaciones, y todos deben estar de
acuerdo con las decisiones. La reunión comienza con cada persona leyendo las respuestas a
las tres primeras preguntas. A medida que cada persona lee, los demás tienen la oportunidad
de responder. Es importante que cada persona escuche cómo ven los demás su trabajo y qué
esperan de ellos.
Luego, cada persona lee la respuesta a la Pregunta 4 y escucha las respuestas de las
personas que identificó. Los problemas de la Pregunta 5 que aún no se han resuelto se
abordan a continuación. A lo largo del proceso, el énfasis está en resolver problemas, no en
culpar. Luego, el grupo discute la Pregunta 6 y trata de llegar a un consenso sobre los cambios
necesarios.
16.11 Manejo del estrés emocional 32
Trabajar en proyectos puede ser estresante. Las largas horas, los horarios apretados, los altos
riesgos y las grandes apuestas afectan las relaciones sociales y la salud mental y física individual.
Los proyectos logran grandes cosas, pero también provocan úlceras, divorcios, crisis nerviosas y
ataques al corazón. El estrés emocional afecta el desempeño y la salud física de los trabajadores
del proyecto y es un problema que en un momento u otro enfrentan la mayoría de los gerentes
de proyecto.
Factores que influyen en el estrés
La cantidad de estrés emocional que experimenta una persona y qué tan bien lo maneja depende
del ajuste entre dos factores: las demandas del entorno y las capacidades de adaptación del
individuo. En otras palabras, el estrés relacionado con el trabajo depende de la percepción de
una persona de las demandas u oportunidades del trabajo y de sus habilidades, confianza y
motivación para desempeñarse. Un gerente que enfrenta el incumplimiento inminente de una
fecha límite puede sentirse estresado si cree que la fecha límite debe cumplirse a toda costa,
pero no se siente estresado si simplemente acepta que cumplir la fecha límite es imposible. El
estrés es una reacción a condiciones internas y ambientales prolongadas que sobrecargan las
capacidades de adaptación de una persona. Para sentirse angustiado (estrés negativo), las
capacidades de un individuo deben estar sobrecargadas. Incluso cuando una persona es capaz
de manejar una situación, todavía se sentirá angustiada si le falta confianza en sí misma o no
puede tomar una decisión.
Estrés en Proyectos
Entre las numerosas causas de estrés en los proyectos se encuentran el ritmo acelerado, la
fuerza de trabajo transitoria, la ansiedad por las discrepancias entre el desempeño y los objetivos,
y el incumplimiento inminente de los requisitos de costos, cronogramas o contratos. En
construcción, por ejemplo, dicen Bryman et al.:
[El director del proyecto] está en primera línea controlando la mano de obra; es responsable ante el
En…un
cliente, ante su organización a un alto nivel; es responsable de millones de libras [o $] en trabajo.
entorno muy frágil, está a merced del clima, las entregas de material, los problemas laborales y los
33
problemas para obtener información.
Restringiremos la discusión a tres causas principales de estrés en los proyectos: sobrecarga de trabajo,
conflicto de roles y relaciones interpersonales.
La sobrecarga de trabajo se experimenta de dos maneras. Uno es tener demasiado trabajo o hacer
demasiadas cosas a la vez, con presiones de tiempo, muchas horas y sin interrupciones. El otro es asumir
un trabajo que excede la capacidad y el conocimiento de uno. La sobrecarga puede ser autoinducida por
la necesidad de logro de un individuo, o puede ser impuesta por las responsabilidades del trabajo.
Prevalece durante los esfuerzos de choque para recuperar el terreno perdido y acelerar los proyectos
hacia su finalización. Cuando la sobrecarga se equilibra con las habilidades, puede ser positiva y
motivadora; cuando excede las habilidades, es angustiante. Un problema relacionado, la carga insuficiente
de trabajo, ocurre con una carga de trabajo demasiado pequeña o con un trabajo por debajo de la
capacidad de una persona. La carga insuficiente puede ocurrir durante una pausa prolongada entre
proyectos.
El conflicto de roles ocurre, por ejemplo, cuando una persona informa a un gerente funcional y a un
gerente de proyecto, y los dos gerentes imponen demandas contradictorias o incompatibles. También
sucede cuando una persona asume múltiples roles incompatibles. Por ejemplo, un director de proyecto
puede descubrir que para ser un buen administrador se requieren cosas que entren en conflicto con sus
valores como ingeniera profesional.
La ambigüedad de roles es el resultado de información inadecuada o confusa sobre lo que una persona
debe hacer para cumplir con su trabajo, o las consecuencias de no cumplir con los requisitos del trabajo.
La persona no sabe dónde está ni qué hacer. El conflicto de roles y la ambigüedad de roles son comunes
en proyectos donde los trabajadores intentan satisfacer las expectativas de muchas personas. Los
gerentes de proyecto en particular pueden sentirse frustrados porque tienen autoridad limitada para
satisfacer los requisitos de numerosas partes interesadas.
El estrés también se desarrolla a partir de las demandas y presiones de las relaciones sociales.
Los gerentes que son egocéntricos y dictatoriales crean estrés para sus trabajadores.
Las personalidades irritables, abrasivas o condescendientes hacen que los demás se sientan poco
importantes y provocan ansiedad.
En resumen, el proyecto típico es un refugio de factores estresantes ambientales: el estrés es
inevitable.
Manejo del estrés
La mayoría de las personas acepta el estrés como el precio del éxito; sin embargo, aunque el
estrés es inevitable, la angustia (estrés negativo) no lo es. Los gerentes de proyecto deben
poder anticipar qué demandas laborales son más estresantes y tratar de mejorar los efectos
negativos.
En general, las formas de reducir el estrés negativo en el trabajo tienen como objetivo
cambiar las condiciones organizacionales que causan estrés o ayudar a las personas a
sobrellevar mejor el estrés. Dado que el estrés resulta de la interacción de las personas con su
entorno, ambos son necesarios. Los medios organizacionales están dirigidos a factores
estresantes de tareas, roles, físicos e interpersonales; los medios individuales están dirigidos a
la capacidad de las personas para manejar y responder a demandas estresantes. Nos
centraremos en los medios organizacionales: métodos aplicados por los gerentes para reducir
34
el estrés en los proyectos.
Establezca planes y horarios razonables
Una forma de reducir el estrés es planificar y programar proyectos para permitir horas de
trabajo y tiempo libre razonables. Los planes bien concebidos y los cronogramas preparados
con anticipación ayudan a equilibrar la carga de trabajo; los trabajadores saben qué se espera
y cuándo, lo que ayuda a evitar la ambigüedad, la sobrecarga de trabajo y el "crujido" que
precede a los hitos y al cierre del proyecto.
Modificar las demandas de trabajo a través de la participación
Los líderes dictatoriales y egocéntricos (el jefe demasiado mandón) causan estrés; lo mismo
ocurre con lo contrario, el no hacer nada, la falta de exigencia. Por el contrario, hay
investigaciones que respaldan que el estilo de liderazgo menos estresante es el participativo.
Permitir a los trabajadores una libertad de decisión y una autonomía acordes con su capacidad
puede ayudar a reducir el estrés en los proyectos. Los líderes participativos establecen metas y definen tareas
límites, pero permita a los trabajadores flexibilidad en cuanto a cómo lograr esos objetivos y límites.
Apoyo social
Una forma de reducir el estrés que surge de los roles y las relaciones laborales es aumentar el apoyo
social dentro de los equipos de proyecto. El apoyo social es la ayuda que se obtiene a través de las
relaciones interpersonales. En general, las personas son más capaces de sobrellevar la situación
cuando sienten que los demás se preocupan por ellos y están dispuestos a ayudarlos.
Las fuentes vitales de apoyo social son la familia, los amigos cercanos y un jefe solidario,
compañeros de trabajo y subordinados. El apoyo social de los jefes y compañeros de trabajo no altera
necesariamente el factor estresante, pero ayuda a las personas a sobrellevarlo mejor. Un gerente de
proyecto solidario ayuda a amortiguar el estrés destructivo; sus subordinados tienen menos
probabilidades de sufrir consecuencias dañinas que aquellos con gerentes que no los apoyan. El
apoyo social de los compañeros de trabajo es igualmente importante; atrapado entre las expectativas
conflictivas de un gerente funcional y un gerente de proyecto, una persona con compañeros de trabajo
que lo apoyen estará mejor capacitada para lidiar con el conflicto.
¿Cómo se vuelven solidarias las personas? Simplemente decirle a alguien que sea de apoyo no
funciona. Incluso cuando los gerentes tratan de brindar apoyo dando consejos, a menudo dejan a la
persona angustiada en una situación peor. Brindar asistencia física es fácil, pero brindar verdadero
apoyo emocional es difícil y más sutil. La escucha empática, la comprensión y la preocupación real
son partes esenciales del apoyo que a menudo faltan en los esfuerzos ingenuos por ayudar. Por lo
tanto, por lo general, es necesario proporcionar algún tipo de formación en habilidades de apoyo social
y reforzar y recompensar el uso de estas habilidades.
Desafortunadamente, al igual que con muchos otros aspectos conductuales de la gestión, la formación
en empatía y sensibilidad se consideran cuestiones "suaves" y se devalúan como "no productivas".
16.12 Resumen
Las teorías de contingencia del liderazgo sugieren que el estilo de liderazgo más efectivo en la mayoría de
las situaciones de proyectos es el orientado a las relaciones y participativo; esto se debe a que los gerentes
de proyecto deben confiar en las opiniones de los miembros del equipo del proyecto y otros expertos.
Un factor significativo que afecta el desempeño del proyecto es la cohesión y el trabajo en equipo. El
trabajo en equipo debe desarrollarse y fomentarse. Pero los grupos necesitan ayuda para desarrollar un
trabajo en equipo efectivo, especialmente cuando el equipo está compuesto por miembros de diferentes
orígenes o los expone a un alto nivel de estrés. Los métodos para la formación de equipos se aplican a una
variedad de situaciones, como la resolución de problemas en un equipo experimentado, la creación de
trabajo en equipo en un grupo nuevo o la resolución de problemas entre dos o más grupos. Con una ligera
variación, estos métodos se pueden adaptar para reunir a clientes, subcontratistas y proveedores al
comienzo de un proyecto.
Muchos equipos de proyecto rara vez o nunca se encuentran cara a cara. Los equipos virtuales, una
característica del panorama de proyectos moderno, dependen de la tecnología para comunicarse y requieren
habilidades especiales para administrar y liderar.
El conflicto es inevitable en los proyectos y, bien gestionado, beneficioso. Las principales fuentes de
conflicto en los proyectos incluyen cronogramas, costos, prioridades, niveles de mano de obra, opiniones
técnicas, cuestiones administrativas y conflictos interpersonales; estos varían en importancia relativa
dependiendo de las etapas del ciclo de vida del proyecto. Generalmente, el conflicto se trata mejor a través
de la confrontación, es decir, examinando los problemas e intentando resolver el conflicto en su origen.
El estrés en los proyectos también es inevitable. El estrés induce energía y aumenta la vitalidad, pero en
exceso puede ser debilitante. Las principales fuentes de estrés en los proyectos son metas y cronogramas
exigentes, tareas de trabajo, roles y relaciones sociales. La planificación anticipada de las cargas de trabajo
y los plazos puede reducir muchas de las fuentes técnicas de estrés. La gestión participativa y el apoyo
social ayudan a los trabajadores a sobrellevar el estrés; el primero da a los trabajadores libertad para cumplir
con los requisitos, el segundo les muestra a los trabajadores que los demás se preocupan por ellos y están
dispuestos a ayudarlos o brindarles apoyo.
1. Explique la diferencia entre los estilos de liderazgo orientados a las tareas y orientados a las
relaciones.
2. Describa el enfoque de contingencia para el liderazgo. De acuerdo a esto
enfoque, ¿cuál es la mejor manera de liderar?
3. Discuta las diferencias entre los modelos de liderazgo de Fiedler y Hersey-Blanchard. ¿Qué dicen
estos modelos sobre el liderazgo en las situaciones que enfrentan los gerentes de proyecto?
4. ¿Cómo es útil la gestión participativa para motivar y ganar

¿compromiso?
5. ¿Por qué es importante el trabajo en equipo en los proyectos? ¿No es suficiente que el individuo
¿Los trabajadores están altamente calificados y motivados?
6. ¿Qué características son comunes a los sistemas de alto rendimiento de Vaill?

7. ¿Qué se entiende por problemas de procesos grupales? ¿Qué tipo de problemas tienen
¿incluir?
8. ¿Cuál es el propósito de la formación de equipos? ¿Dónde se necesita la formación de equipos?

9. Resuma los pasos de una sesión de trabajo en equipo para un grupo que ha estado trabajando en
conjunto. Resuma los pasos para construir un nuevo equipo de proyecto.
10. Resuma los pasos del proceso del IGPS.
11. Qué condiciones de gestión y de los miembros del equipo son necesarias
para que las intervenciones de formación de equipos tengan éxito?
12. Describa algunas situaciones que conozca en las que podría ser útil la formación de equipos.
usó.
13. ¿Cuáles cree que son las razones por las que la formación de equipos no se utiliza con más
frecuencia? ¿Qué barreras existen para aplicar el team building?
14. Enumere las tecnologías disponibles para equipos virtuales. ¿A qué tareas/decisiones se aplica
cada una?
15. ¿Cómo se desarrolla la confianza y la cohesión en los equipos virtuales?
16. Enumere algunas consideraciones especiales en la gestión de reuniones virtuales.
17. ¿Cuáles son las fuentes de conflicto entre el usuario y el contratista?
¿Cómo los contratos conducen al conflicto?
18. ¿Cuáles son las fuentes de conflicto entre las partes del proyecto?
¿organización?
19. Describa cómo varían las fuentes de conflicto con las fases del proyecto
ciclo vital.
20. ¿Por qué algunos conflictos son naturales y beneficiosos?
21. Describa cuatro formas de lidiar con el conflicto.
22. Explique cómo el director del proyecto utiliza la confrontación para resolver conflictos.
23. ¿Qué condiciones deben existir para que la confrontación tenga éxito?
24. Describa la técnica de clarificación de roles. ¿Qué fuentes de conflicto tiene

¿resolver?
25. Describa estas fuentes de estrés en los proyectos: metas y cronogramas del proyecto,
sobrecarga de trabajo, conflicto y ambigüedad de roles y relaciones sociales/interpersonales.
Describa sus experiencias laborales con estas fuentes de estrés.
26. Describa los medios por los cuales la gestión participativa ayuda a reducir
estrés laboral.
27. ¿Qué es el “apoyo social”? ¿Cuáles son las fuentes de apoyo social? Cómo
¿El apoyo social reduce el estrés laboral?
Preguntas sobre el Proyecto de Estudio
1. ¿Cómo caracterizaría el estilo de liderazgo del gerente de proyecto en su proyecto? ¿Es

autoritario, laissez faire (no hacer nada) o participativo? ¿El director del proyecto está
orientado a las tareas, a las relaciones o ambos?
2. ¿Sobre qué tipo de personas debe influir el director del proyecto? Dadas las teorías de
este capítulo, ¿es apropiado el estilo de liderazgo del director del proyecto? A pesar de
las teorías, ¿parece efectivo el estilo utilizado por el director del proyecto?
3. ¿Cuáles cree que son los principales motivadores de trabajo para las personas en este
proyecto? Analice la importancia relativa del salario, el potencial profesional, los
incentivos y la participación en la toma de decisiones.
4. Describa los diferentes grupos (equipos de gestión, oficina de proyectos, grupos
funcionales) que componen el equipo de proyecto en este proyecto.
5. ¿Qué mecanismos se utilizan para vincular estos equipos, por ejemplo, coordinadores,
reuniones frecuentes o proximidad de los trabajadores?
6. ¿Qué tipos de actividades formales e informales se utilizan para aumentar la cohesión del
equipo del proyecto? ¿Alguno de estos se puede denominar como la formación de

equipos?
7. ¿El equipo del proyecto es un equipo virtual? En caso afirmativo, ¿qué disposiciones especiales establece el
toma el gerente para dirigir y administrar el equipo?

8. ¿Se toman medidas para resolver problemas que involucran a varios grupos?
9. ¿Cómo caracterizaría el nivel de trabajo en equipo en este proyecto?
10. Pregunte si el director del proyecto conoce procedimientos formales de formación de
equipos y resolución de problemas intergrupales como los que se describen en este libro.
11. Al final de este (u otros proyectos), ¿cómo disuelve la organización un equipo? ¿Existen
procedimientos para reconocer a los miembros o lidiar con sus sentimientos acerca de
la disolución?
12. ¿Qué tan frecuente es el conflicto y qué efecto tiene en el desempeño individual y del
proyecto?
13. ¿Cómo resuelve el conflicto el director del proyecto? ¿Se utiliza la confrontación?
14. ¿Se utilizan procedimientos formales, como RCT o IGPS, para resolver conflictos?
15. El estrés emocional es un problema personal y la mayoría de las personas dudan en hablar de
él a un nivel que no sea general. Aún así, puede preguntarle al director del proyecto oa otros
miembros del equipo sobre las tensiones que sienten o perciben personalmente en el proyecto.
16. ¿Es este un proyecto de alto o bajo estrés? Explique. Si hay mucho estrés, ¿se da por sentado
o las personas toman medidas para reducir el estrés?
17. ¿El gerente del proyecto trata de ayudar a los miembros del equipo a lidiar con el estrés laboral?
Explique.
Caso 16.1 Wilma Keith
Wilma Keith había trabajado durante más de 20 años como directora de proyectos de éxito.
Pero incluso con esos antecedentes, encontró el Proyecto Wiseteam frustrante y abrumador. Poco
después de ser asignada al proyecto, se reunió con Cappun Queeg, vicepresidente de
comunicaciones. “Wilma”, dijo, “en pocas palabras, el Proyecto Wiseteam debe completarse y estar
operativo dentro de seis meses”. Ella ya había estimado que el proyecto tomaría alrededor de un
año y protestó. Queeg se molestó y dijo: "¡Hazlo!". Wilma buscó en la empresa a las mejores
personas que pudo encontrar y se decidió por cuatro jóvenes analistas técnicos de diferentes
departamentos. Ninguno de ellos estaba orientado a las personas o era muy bueno para
comunicarse; técnicamente, sin embargo, eran los mejores. Al revisar los requisitos del proyecto,
todos estuvieron de acuerdo: tomaría un año, al menos. Cuando Wilma le informó a Queeg, él dijo
simplemente: “Si no terminas en seis meses, estás despedido. ¡Es una promesa!"
Así que Wilma puso a trabajar al equipo. Todos conocían la fecha límite de Queeg. En un
momento se pasó para decir que si no tenían éxito, todos serían despedidos. Esto puso nerviosos
a los analistas, pero Wilma prometió que si alguien iba a ser despedido, sería ella, no ellos. También
prometió que se encargaría de todos los tratos con Queeg, protegerlos de su abuso y asumir la
responsabilidad por cualquier retraso o problema. El equipo se entusiasmó con Wilma y se puso a
trabajar, en promedio 6 días a la semana, 15 a 20 horas al día. wilma nunca
dejalos; si ellos estaban trabajando, ella también. Empezó a traer brownies, muchos
brownies, actuando como una "madre del den" y tratando al equipo como si fueran una
familia. De hecho, dadas las largas horas de trabajo, el equipo rara vez veía a sus familias
reales y el cuidado maternal de Wilma parecía llenar un vacío.
Varios meses después de iniciado el proyecto, Queeg irrumpió y le preguntó a Wilma

por qué había solicitado la ayuda de dos consultores externos. Ella dijo que a pesar de las
largas horas de trabajo, el equipo todavía estaba atrasado y necesitaba recursos adicionales
para cumplir con la fecha límite. Queeg se enfureció porque no estaba dispuesto a contratar
a ningún consultor. Wilma lo miró directamente a los ojos. "¡Tú no lo haces, y yo renuncio!"
Queeg sabía que hablaba en serio. "Está bien", dijo, "pero eso es todo lo que obtendrás".
El equipo estaba asombrado: Wilma se había enfrentado al vicepresidente. Esto los unió
aún más y los unió contra el “enemigo” común.
La intensa presión, las largas horas, la fuerte competencia del equipo y el apoyo de
Wilma funcionaron: el equipo terminó el proyecto dos semanas antes y por debajo del
presupuesto, incluso con los gastos de los dos consultores. Pero finalmente el proyecto
fracasó porque el sistema Wiseteam que había demandado Queeg no aportó nada nuevo
a sus usuarios. Queeg nunca había hablado con los usuarios; Wiseteam fue su propio
proyecto "mascota". Un año después se fue de la empresa.
Preguntas
1. ¿Qué opinas sobre el estilo de liderazgo de Wilma? ¿Qué aspectos de su estilo

motivaron al equipo? ¿Diría que el estilo de Wilma está más orientado a las
tareas oa las relaciones?
2. ¿Qué aspectos del estilo de Wilma cree que son típicos de los buenos gerentes
de proyectos?
3. Este fue un proyecto estresante. ¿Qué hizo Wilma que ayudó al equipo a manejar
el estrés?
4. ¿Es este caso realista? ¿Se imponen demandas poco realistas como esta a los
gerentes de proyectos?
Caso 16.2 Nave espacial Mars Climate Orbiter 35
La NASA diseñó la nave espacial Mars Climate Orbiter para recopilar datos sobre las
condiciones atmosféricas de Marte y servir como estación de transmisión de datos. Los
instrumentos a bordo del Orbiter proporcionarían información detallada sobre la
temperatura, el polvo, el vapor de agua y el dióxido de carbono en la atmósfera de Marte
durante aproximadamente 2 años terrestres. El Orbiter también proporcionaría un punto
de retransmisión para transmisiones de datos hacia y desde naves espaciales en la
superficie de Marte por hasta 5 años.
Nueve meses después del lanzamiento, el Orbiter llegó a las proximidades de Marte y
encendió su motor principal para ponerse en órbita alrededor del planeta. Todo parecía
normal cuando pasó detrás de Marte visto desde la Tierra. Después de eso, nunca más
se supo del Orbiter; presumiblemente se había estrellado contra el planeta. Parafraseando
al gerente de proyecto Richard Cook, “Habíamos planeado
acercarse al planeta a una altitud de unos 150 kilómetros, pero al revisar los datos
previos a la llegada, vimos indicaciones de que la altitud de aproximación era
mucho menor, unos 60 kilómetros. Creemos que la altitud mínima de supervivencia
de la nave espacial habría sido de 85 kilómetros”.
Posteriormente, una revisión interna por pares atribuyó la pérdida de la misión
de 280 millones de dólares a un error en la información transmitida entre los dos
equipos responsables de las operaciones del Orbiter, el equipo de la nave espacial
en Colorado y el equipo de navegación de la misión en California. Al comunicarse
de un lado a otro, un equipo usó unidades imperiales (pies, libras), el otro usó
unidades métricas (metros, gramos). Sin saberlo, los dos equipos estaban usando
diferentes sistemas de medición para obtener información crítica para maniobrar la
nave espacial en la órbita de Marte adecuada.
Preguntas
1. ¿Cómo pudo ocurrir tal error entre los dos equipos?
2. ¿Qué sugiere el error sobre el grado de interacción y coordinación entre los

equipos?
3. ¿Cómo podría haberse evitado este problema?

Notas finales
1. Chapman R. Gestión de proyectos en la NASA: el sistema y los hombres. Washington, DC: NASA SP-324,
N.º NTIS N75-15692; 1973. El equipo del proyecto al que se hace referencia es el personal de la oficina del proyecto, que constaba de una
pocos miembros en pequeños proyectos de matriz a 70 en grandes proyectos puros.
2. Kloman E. Gestión de proyectos espaciales no tripulados. Washington, DC: NASA SP-4102; 1972, pág. 23
3. Fiedler F. Una teoría de la eficacia del liderazgo. Nueva York: McGraw-Hill; 1967.
4. Hersey P. y Blanchard K. Gestión del comportamiento organizacional: utilización de los recursos humanos, 4.ª ed.
Upper Saddle River, Nueva Jersey: Prentice Hall; 1982, págs. 150–173.
5. Sayles L. y Chandler M. Gestión de grandes sistemas: organizaciones para el futuro. Nueva York: Harper &
Fila; 1971, pág. 219.
6. Bennis W. y Nanus B. Liderazgo: estrategias para hacerse cargo. Nueva York: Harper & Row; 1985, págs.
224–225.
7. Vaill P. El propósito de los sistemas de alto rendimiento. Dinámica organizacional, otoño de 1982: 23–39.
8. Ibíd., 38.
9. Esta discusión se basa en gran medida en el ejército empresarial de Hofer W. Lady Liberty, Nation's Business, julio de 1983:
18–28; ver también Hall A. Liberty levanta su lámpara una vez más. National Geographic, julio de 1986: 2–19.
10. Ibíd., 28.
11. Ibíd., 21.
12. Véase Chapman, Project Management in NASA, págs. 59–62. Las otras funciones de la gestión de proyectos.
se definieron como planificación de proyectos, información y control, y consulta.
13. Keller R. Predictores del desempeño de grupos de proyectos en organizaciones de I+D. Academia de
Management Journal 29 (4) diciembre de 1986: 715–726.
14. Ver, por ejemplo, Dyer W. Team Building: Current Issues and New Alternatives, 3ra ed. Lectura MA:
Addison-Wesley; 1995; Reilly A. y Jones J. Team building, en Pfeiffer J. y Jones J. (eds.). Anual
Manual de Facilitadores de Grupo. LaJolla, CA: Asociados Universitarios; 1974.
15. Basado en la investigación de Gratton L., Voight A. y Erickson, T. Bridging faultiness in diversity teams. MIT
Revisión de la gestión de Sloan 48(4); 2007: 3
16. Esta discusión se basa en gran medida en Dyer, Team Building.
17. Blake R., Shepard H. y Mouton J. Gestión de conflictos intergrupales en la industria. Houston: Golfo
Publicación; 1965.
18. Esta sección se basa en gran medida en Duarte D. y Snyder N. Mastering Virtual Teams. San Francisco, CA:
Jossey-Bass; 2006, págs. 31 a 80.
19. Partes de esta sección son de Duarte y Snyder, Mastering Virtual Teams, p. 77.
20. Basado en Duarte y Snyder, Mastering Virtual Teams, págs. 145–147; y Cohen M. Sucediendo con
Ágil. Upper Saddle River, Nueva Jersey: Addison-Wesley; 2010, págs. 367–370.
21. Cohen, Succeeding with Agile, pág. 370.
22. Gran parte de esta sección fue adaptada de Duarte y Snyder, Mastering Virtual Teams, pp. 170–183.
23. Cohen M. Succeeding with Agile, págs. 376–377
24. Sayles y Chandler, Ibíd., pág. 278.
25. Thamhain H. y Wilemon D. Gestión de conflictos en los ciclos de vida de los proyectos. revisión de gestión de sloan,
primavera de 1975; 31–50; y Thamhain H. y Wilemon D. Diagnóstico de determinantes de conflicto en proyectos
administración. IEEE Transactions of Engineering Management 22, febrero de 1975.
26. Schmidt W. Conflict: Un proceso poderoso para el cambio (bueno o malo). Revisión de la gestión 63, diciembre
1974: 5.
27. Moody F. Canto el Cuerpo Electrónico. Nueva York: vikingo; 1995, págs. 110–115.
28. Ibíd., págs. 46 y 47.
29. Sayles y Chandler, Gestión de grandes sistemas, pág. 216.
30. Método basado en Dyer, Team Building, pp. 109–116.
31. Ibíd., pág. 112.
32. Partes de esta sección adaptadas de Huse E. y Cummings T. Organization Development and Change,
3ra ed. San Pablo: Oeste; 1985, Capítulo 12; Quick J. y Quick J. Estrés Organizacional y Preventivo
Administración. Nueva York: McGraw-Hill; 1984; y Williams J. Comportamiento humano en las organizaciones, 2do .
ed. Cincinnati: suroeste; 1982, Capítulo 9.
33. Bryman A. et al., El concepto del sistema temporal: El caso del proyecto de construcción. Investigación en
Sociología y Psicología de las Organizaciones 5, 1987: 253–283.
34. Partes de esta sección adaptadas de Huse y Cummings, Organization Development and Change;
Rápido y Rápido, Estrés Organizacional y Gestión Preventiva; Williams, Comportamiento humano en
Organizaciones; Casa J. Estrés Laboral y Apoyo Social. Lectura, MA: Addison-Wesley; 1981; y
Warshaw L. Manejo del estrés. Lectura, MA: Addison-Wesley; mil novecientos ochenta y dos.
35. Sitio web de la NASA, diciembre de 1999.

Parte V
Gestión de Proyectos en el Corporativo
Contexto

Más allá de las habilidades de liderazgo y las herramientas y métodos de gestión de

proyectos, ¿qué más se necesita para mejorar el éxito del proyecto? Una parte de la
respuesta es que la organización debe apoyar a sus gerentes y alentarlos y permitirles
aplicar las mejores prácticas de gestión de proyectos; otra es que emprenda proyectos que
sean viables y beneficiosos para la organización; es decir, debe seleccionar proyectos que
cumplan con criterios sólidos basados en los objetivos de la organización y los recursos
disponibles. Estos son los temas del Capítulo 17 y Capítulo 18, respectivamente.
En la creciente globalización empresarial y tecnológica actual, un tema de creciente
importancia es la gestión de proyectos internacionales; este es el tema del Capítulo 19.
El tema abarca casi todo lo demás cubierto en este libro (aunque desde una perspectiva
internacional), por lo que sirve como un resumen y una revisión adecuados.
capitulo 17
Meta-Gestión de Proyectos y
Gestión de programas
La metagestión de proyectos se refiere a aspectos importantes de la gestión de

proyectos sobre los que los directores de proyectos suelen tener poca o ninguna
influencia. Por ejemplo, el enfoque general a adoptar y la preparación de una
organización para realizar proyectos pueden depender de otros: altos directivos y
directores. En otras palabras, los gerentes de proyecto están limitados en lo que
pueden lograr, y la probabilidad de éxito del proyecto depende en parte de las medidas
que tome la organización. Dichas medidas, el primer tema del capítulo, incluyen la
madurez de la gestión de proyectos, la metodología de gestión de proyectos, la gestión
del conocimiento y la oficina de gestión de proyectos (PMO). Con frecuencia, los
proyectos se emprenden como parte de una agenda más amplia: programas, y estos
requieren su propio tipo de gestión, la gestión de programas, que es el segundo tema del capítulo.
17.1 Madurez de la gestión de proyectos y modelos

de madurez
¿Qué tan buenos somos realmente? ¿Qué tan bien estamos a la altura de nuestros competidores?
¿En qué áreas debemos mejorar? Estas son preguntas que las empresas se hacen continuamente
sobre sus capacidades y competencias. La capacidad o competencia de una organización con
respecto a la gestión de proyectos se conoce como su "madurez".
Continuidad de madurez
Así como las personas maduran física y mentalmente, las organizaciones maduran en la gestión
de proyectos. Los niveles típicos de madurez se muestran en la Figura 17.1.
El proceso de madurez creciente en la gestión de proyectos comienza cuando algunas
personas comienzan a comprender los principios de una buena gestión de proyectos y los
practican por su cuenta. Por supuesto, para que la organización desarrolle aún más su capacidad,
muchas personas deben practicar los principios, y para que eso suceda se requiere una conciencia
a nivel ejecutivo sobre la importancia de la gestión de proyectos y la voluntad de apoyar la difusión
de esos principios en toda la empresa. Estos pasos incluyen la documentación de las lecciones
aprendidas de cada proyecto para el beneficio de otros proyectos y el desarrollo de un lenguaje
común de términos de gestión de proyectos para ser utilizado en toda la empresa. Una empresa
con proyectos en todo el mundo podría crear un glosario de términos en varios idiomas.
Naturalmente, pasar a un nivel superior de madurez también requiere que la organización

desarrolle una metodología de gestión de proyectos. En última instancia, la organización está en
posición de comparar sus capacidades de gestión de proyectos con organizaciones que son
líderes en la industria. 1
Figura 17.1 Niveles de madurez/competencia en gestión de proyectos.
Modelos de madurez
La madurez de la gestión de proyectos de una organización se mide de acuerdo con los llamados "modelos
de madurez"; existen muchos modelos reconocidos aunque ninguno ha logrado aceptación a nivel mundial.
2
Los modelos de madurez se dividen en tres categorías:3
• Modelos de procesos de entrega técnica •

Modelos de procesos de gestión de proyectos •
Modelos de organización total.
Los modelos de procesos de entrega técnica se originaron en el movimiento de gestión de calidad total de
la década de 1980, cuando las empresas comenzaron a medir sus capacidades de gestión de calidad. Un
ejemplo es el Modelo de Madurez de la Capacidad (CMM) desarrollado por el Instituto de Ingeniería de
Software de la Universidad Carnegie-Mellon durante las décadas de 1980 y 1990 para ayudar a identificar
contratistas de software competentes. El modelo, que enfatiza la documentación del proceso, similar a la
calidad ISO
estándares, tiene cinco niveles de madurez.
Los Modelos de Procesos de Gestión de Proyectos se centran en áreas de conocimiento.4 Muchos de estos
modelos se basan en las diez áreas de conocimiento de Project Management 5 , donde el Project Management
Bodyseofdetermina
Knowledge (PMBOK) del Instituto (PMI), el nivel de madurez alcanzado en cada área de conocimiento
en comparación con los criterios estandarizados durante una auditoría. La Figura 17.2 muestra los resultados de
la auditoría para los niveles de madurez evaluados para las áreas de "Iniciación" (según el PBMOK).
Los modelos de procesos comúnmente especifican cinco niveles de madurez, comparables a los
6
niveles en la figura 17.1:
• Ad Hoc: sin procedimientos ni planes formales •
Planificación de proyectos individuales • Planificación y
control sistemáticos de proyectos • Planificación y control
integrado multiproyecto y formal • Mejora continua del PM.
Tras el desarrollo de CMM, el PMI patrocinó una investigación en la Universidad de California Berkeley y la
Universidad George Washington que 7 Esto produjo el Modelo de Madurez de Gestión de Proyectos
Organizacionales (OPM3). es un ejemplo de un modelo organizacional total , llamado así porque da cuenta de toda
la organización y cómo administra proyectos, programas (discutidos más adelante en este capítulo) y carteras de
proyectos (discutidos en el Capítulo 18).

Figura 17.2 Resultados de una evaluación de madurez con respecto a los aspectos de gestión de proyectos.
Ver Capítulo 18
¿Qué tan buenos debemos ser?
Sería incorrecto suponer que una organización debe esforzarse por lograr la madurez del más
alto nivel en todos los aspectos, tal como lo prescriben estos modelos. Diferentes empresas
tienen diferentes necesidades que requieren diferentes niveles de madurez. Por ejemplo,
mientras que una empresa que realiza investigaciones con fondos internos limitados necesita
una gran capacidad en la selección de proyectos, un contratista de construcción con capacidad
para aceptar cualquier trabajo que se presente no la necesita. Del mismo modo, una empresa
que desarrolla reactores nucleares necesita una gran madurez en prácticas ambientales y de
seguridad, pero una empresa que desarrolla juegos de computadora probablemente no. Un
estudio sobre la madurez de la gestión de proyectos en el desarrollo de productos encontró que
las herramientas y los procesos de gestión de proyectos estandarizados aumentan el éxito del
proyecto hasta cierto punto, más allá del cual reducen el éxito; es decir, la conformidad con los
estándares demadurez
la industria solo puede
permite el éxitollevarlo hasta cierto
del proyecto punto.
en todas las 8 Ningún modelo
industrias único
y tipos de de
proyectos.
Cada organización debe identificar qué áreas de
competencia son importantes y evitan desperdiciar recursos para lograr una alta madurez en áreas
que no son importantes o irrelevantes.
Beneficios y deficiencias de los modelos de madurez 9
Haber alcanzado una calificación alta de acuerdo con un modelo de madurez estándar le da a la
empresa el derecho a presumir.
En una propuesta, una empresa puede señalar que ha alcanzado un alto nivel de madurez para
un modelo reconocido.
Sin embargo, por su propia naturaleza, los modelos de madurez enfatizan los procesos y
procedimientos formales y se enfocan solo en el conocimiento explícito, que es el conocimiento
que se puede documentar. Una debilidad de los modelos es que ignoran el conocimiento tácito,
que es conocimiento que no se puede escribir o describir fácilmente. El liderazgo, la comunicación,
el trabajo en equipo y el conocimiento y las habilidades que poseen los gerentes de proyecto y los
miembros del equipo juegan un papel importante en el éxito del proyecto; sin embargo, al ser
tácitos, representan conocimiento no explicado por los modelos de madurez. 10
Madurez del proyecto y éxito del proyecto
Los estudios indican que aproximadamente dos tercios de las organizaciones califican en los
niveles 1 o 2 en la escala de madurez de cinco niveles. Las empresas de las industrias petroquímica
y de defensa son relativamente más maduras; los de seguros, servicios financieros y de salud,
11
investigación y desarrollo farmacéutico y telecomunicaciones son menos maduros.
¿Lograr una mayor madurez según los modelos se correlaciona con un mayor éxito del
proyecto? La evidencia empírica es insignificante, pero la respuesta es "no necesariamente". El
éxito del proyecto depende de muchas cosas, incluido el entorno del proyecto, el equipo y el
director del proyecto, ninguno de los cuales abordan los modelos de madurez. La mayoría de los
gerentes senior ven poca asociación entre el nivel de madurez y el desempeño del proyecto.
12
Algunos estudios afirmaron una correlación positiva entre la madurez
y el éxito del proyecto, pero carecen de una base teórica y, como era de esperar, fueron realizados
por consultores, no por investigadores. 13 Y no es obvio que la madurez por sí sola ofrezca una
ventaja competitiva. Los modelos miden
sólo el conocimiento explícito, el que puede ser estandarizado y documentado y, por lo

tanto, copiado o adoptado por cada empresa. Por lo tanto, una organización que imita las
prácticas estándar e ignora el desarrollo de sus propias fortalezas únicas nunca podrá ser
14
mejor que sus competidores.
Para alcanzar los Niveles de Madurez 3 y superiores en la Figura 17.1, procesos y
estándares para la gestión de proyectos, se debe crear y utilizar una metodología de
gestión de proyectos . También se necesita documentar y utilizar las Lecciones aprendidas,
que se relacionan con la gestión del conocimiento, y crear una PMO (Oficina de Gestión
de Proyectos). Estos temas se describen a continuación.
17.2 Metodología de gestión de proyectos 15
Una metodología de gestión de proyectos es un marco o procedimiento que especifica

quién debe hacer qué en cada etapa del ciclo de vida del proyecto. Estándares como la
Guía del PMBOK brindan procesos y herramientas que, muchas veces, se incorporan a la
metodología. La metodología utilizada por una organización generalmente aborda muchos
de los temas de este libro, aunque está organizada de la manera que mejor se adapte a la
organización. Proporciona una estructura para que todos los proyectos se gestionen y
realicen de manera estandarizada, disciplinada y sistemática, utilizando prácticas comunes
para aumentar la probabilidad de que los proyectos tengan éxito. Una organización crea o
adopta la metodología para que se ajuste de manera única a sus requisitos, procedimientos
y cultura comerciales, y al tamaño, alcance y tecnología de sus proyectos. Algunas
metodologías prescriben las tareas técnicas de un proyecto; nuestro enfoque está en
aquellos que enfatizan las tareas de gestión de proyectos.
¿Por qué Metodología?
Al fomentar la conformidad con una metodología de gestión de proyectos prescrita, una

organización ayuda a garantizar que todos los proyectos se realicen y gestionen de manera
similar. Al carecer de una metodología, los gerentes de proyectos individuales utilizarán
sus propias prácticas y herramientas de gestión, algunas buenas, otras no tan buenas.
El objetivo de la metodología es garantizar que se apliquen las “buenas” y “mejores”
prácticas reconocidas en todos los proyectos, y elevar las prácticas de todos los gerentes
de proyecto a las de sus mejores gerentes. La metodología proporciona una forma común
de hacer las cosas y una terminología común. Todos haciendo las cosas de manera similar
mejoran la comunicación y el aprendizaje sobre esas formas. Por supuesto, todo gerente
debe practicarlo. Los gerentes acostumbrados a un enfoque estructurado y documentado
para la gestión de proyectos adoptarán más fácilmente la metodología; aquellos que no
están acostumbrados pueden no hacerlo.
¿Qué exige la metodología?

La metodología especifica las etapas del ciclo de vida de los proyectos en una organización
y las funciones y tareas de gestión de los directores de proyectos y las partes interesadas en
cada etapa. Por ejemplo, especifica quién es responsable de iniciar, proponer, revisar y
seleccionar proyectos, y las funciones y responsabilidades dentro de la junta de revisión de
proyectos (discutido en el próximo capítulo) y la PMO (discutido más adelante en este
capítulo). También especifica las personas que deben revisar el proyecto en las puertas y
aprobar los presupuestos y cronogramas.
Fases y puertas
La mayoría de los proyectos se llevan a cabo de manera escalonada. La metodología de

gestión de proyectos define los pasos —fases o etapas— en que se dividen los proyectos —
por ejemplo, inicio, factibilidad, definición, desarrollo y lanzamiento— y qué debe suceder en
cada uno. Al comienzo de cada etapa puede haber una "puerta", llamada así porque en ese
punto se evalúan el estado actual del proyecto y los planes para el resto del proyecto, y se
toma la decisión de continuar, suspender o cancelar el proyecto. proyecto. El número de
etapas y puertas depende de la metodología, con un mínimo generalmente de cuatro o cinco;
Motorola en el Caso 17.2 tenía 16 subfases (etapas) dentro de cinco fases para sus proyectos
de Sistemas Celulares. Las puertas también pueden representar la aprobación de, por
ejemplo, el inicio del proyecto, los requisitos del sistema, la validación del sistema y el
lanzamiento del sistema. Las decisiones en cada puerta se basan en
criterios.
El proceso de selección es común en organizaciones que llevan a cabo proyectos internos
simultáneos en desarrollo de productos, TI, infraestructura, desarrollo de productos o mejora
de procesos, y dondequiera que los proyectos "compitan" por objetivos y recursos de
productos o mercados. Es una forma de seleccionar proyectos más débiles y menos
prometedores para que los escasos recursos se dediquen a proyectos más fuertes y
prometedores; también reduce el riesgo en grandes proyectos independientes.
Relación con el ciclo de vida del proyecto
La figura 17.3 ilustra una metodología de gestión de proyectos para un ciclo de vida del
proyecto de siete etapas (desde la iniciación hasta el mantenimiento). En general, la metodologa
debe ajustarse a las prácticas técnicas y comerciales de la organización; por ejemplo,

las etapas 4 y 5 de la metodología de la Figura 17.3 deben ser compatibles con
cualquier metodología de desarrollo que emplee la organización: cascada, espiral,
iterativa o Scrum.
Elementos de la Metodología
El contenido de una metodología de gestión de proyectos ha sido el tema de la mayor

parte de este libro. De hecho, una forma de crear una metodología es mirar los temas
y métodos en los libros de gestión de proyectos, determinar cuáles son aplicables a los
proyectos de la organización y luego organizarlos en un marco de acuerdo con el ciclo
de vida del proyecto.
El contenido real y los detalles de la metodología, sus tareas y requisitos, dependen
del alcance y la escala de los proyectos de la organización. Para proyectos grandes,
complejos y riesgosos, la metodología especificaría tareas y métodos detallados para
el análisis, definición, planificación, seguimiento, control y cierre. Para proyectos
pequeños y de bajo riesgo, una metodología algo simplista es adecuada. Las opciones
sobre qué aspectos de la metodología se deben seguir y cuáles se pueden omitir en un
proyecto determinado deben establecerse en la metodología y no dejarse a discreción
del director del proyecto.
figura 17.3 Fases del ciclo de vida del proyecto versus metodología de gestión de proyectos.
Una metodología típica define las fases o etapas del ciclo de vida del proyecto y para
cada fase las tareas y entregables, y las partes interesadas y sus responsabilidades.
Ciclo de vida del proyecto
Este libro ha utilizado las fases de Concepción, Definición y Ejecución, cada una con una
serie de etapas; en general, sin embargo, un proyecto en particular puede definirse en
términos de cualquier número de fases o etapas. La metodología define las fases o
etapas nominales en términos de lo que mejor represente la progresión “natural” de los
proyectos de la organización, desde el inicio hasta la ejecución y el cierre.
Las fases del proyecto pueden basarse en estándares. Por ejemplo, las organizaciones
involucradas en grandes proyectos de ingeniería/construcción comúnmente emplean un
ciclo de vida con fases definidas por el Instituto de Industrias de la Construcción (CII), a
saber, Viabilidad, Concepto, Alcance detallado y Diseño y Construcción, Arranque y
Puesta en marcha, y Operaciones. Las empresas que construyen instalaciones para las
industrias química, mineral y de petróleo y gas suelen utilizar las fases recomendadas por IPA
(Análisis de proyecto independiente), que son Generar/ Dar forma a la idea, Definir la oportunidad (FEL-1), Desarrollar
el alcance (FEL-2), Definir el proyecto (FEL-3), Ejecutar y Producir. Las primeras fases de esta metodología se
discutieron como "carga frontal" en el Capítulo 4.
La metodología también puede incluir etapas anteriores y posteriores al proyecto real (por ejemplo, la metodología
de la Figura 17.3 incluye la etapa de mantenimiento posterior al proyecto).
Ver Capítulo 4
Tareas requeridas y entregables
Para cada fase o etapa, la metodología especifica las tareas y entregables de la gestión del proyecto; por ejemplo, la
Fase 1: Inicio/ Factibilidad en la metodología de la Figura 17.3 podría especificar:
• Reúna al equipo e identifique a las partes interesadas. •
Preparar el acta de constitución del proyecto. • Preparar una
lista preliminar de tareas. • Realizar análisis de riesgos y
preparar una lista de riesgos clave. • Desarrollar una lista de requisitos.
• Preparar solicitud de financiación. • Preparar plan de recursos,
cronograma, plan de gastos. • Preparar propuesta de proyecto.
La metodología incluirá tareas y entregables que cubren prácticamente todos los temas tratados en este libro, como los
de la Tabla 17.1.
Tabla 17.1 Tareas y entregables de la gestión de proyectos
Inicio/propuesta de proyecto Adquisiciones/Gestión de contratos

Identificación de partes interesadas Reclutamiento, formación, despidos
Selección de proyectos Seguimiento/revisión de proyectos
Desarrollo de propuestas Entrada de datos

Planificación de proyectos Reportando a la gerencia
Especificación de requisitos Auditoría de proyectos

Definición de trabajo Control/garantía de calidad
Necesidades de recursos Control de procesos
Estimación de tiempos y costos Cambio de control
Planificación cierre del proyecto
Presupuesto/contabilidad Revisión posterior al proyecto
Análisis de riesgo Revisión posterior a la implementación
Conocimiento administrativo
Quién es responsable: firmas y aprobaciones
Como se mencionó, la metodología podría incluir puertas en las que el proyecto debe ser
aprobado. La metodología especificaría las personas que tienen autoridad para aprobar
y los roles de las partes interesadas particulares, como el cliente, patrocinador, campeón y
gerente de proyecto.
La metodología para una gran corporación se muestra en la Figura 17.4. Interesado en
sus detalles, ejemplifica el alcance de las tareas, entregables y responsabilidades
cubierto en una metodología integral de gestión de proyectos.
La Metodología PRINCE2
Un ejemplo de una metodología estándar es PRINCE2, que el Gobierno del Reino Unido
desarrollado como una guía para que las organizaciones desarrollen sus propios
metodologías. Define los roles de los gerentes de alto nivel (corporativo o
programa), la Junta de Proyecto, el director del proyecto y los directores de equipo. Eso
prescribe las etapas del proyecto como Anteproyecto, Iniciación, Entrega posterior
etapa(s) y Entrega final. La etapa de Anteproyecto se inicia por mandato
documento, la etapa de Iniciación por un escrito, y las etapas de Entrega Posterior por un
PID (Documentos de Inicio del Proyecto); puede haber solo una entrega posterior
escenario para pequeños proyectos pero varios para grandes proyectos. PRINCE2 también prescribe un
proceso de gestión de los límites de la etapa que se seguirá al completar la etapa de inicio
y las etapas de entrega subsiguientes. El proceso define las actividades del gerente del
proyecto para permitir que la Junta de Proyecto evalúe cada etapa y apruebe el plan para
la siguiente etapa y el plan general actualizado del proyecto, y los procedimientos para
controlar las etapas y administrar la entrega del producto en la etapa de entrega final.
figura 17.4 Metodología integral de gestión de proyectos en seis etapas.
¿Talla única?
La mayoría de las metodologías son algo flexibles. Especifican los requisitos de gestión de
proyectos para un tipo genérico de proyecto, pero permiten la inclusión de otros
requisitos, dependiendo de las características únicas de cada proyecto. Cuando todos los
proyectos en una organización son similares en términos de alcance, tamaño y tecnología,
entonces una metodología podría ser adecuada para todos ellos.
Para acomodar proyectos de diferente tamaño y complejidad, la metodología puede ser
“escalable” o venir en, digamos, tres o cuatro versiones, la particular que se aplicará dependiendo
de los recursos de capital, la duración, la cantidad de paquetes de trabajo y contratistas, y el
riesgo. del proyecto. Sin embargo, un problema con múltiples metodologías es decidir cuál es
apropiado para un proyecto determinado. La decisión generalmente se basa en factores del
proyecto, como se analiza en la sección I.3 de
dieciséis
la Introducción: novedad, complejidad, tecnología y ritmo.

La mayoría de las organizaciones tienen una metodología básica, quizás escalable, porque
todos sus proyectos tienden a ser similares. Pero organizaciones como las empresas de petróleo
y gas, que emprenden proyectos en diferentes categorías (desarrollo de productos, exploración,
construcción, investigación aplicada, marketing) tienen múltiples metodologías diferentes. Una
metodología se aplicaría a, digamos, proyectos en busca de nuevas fuentes de petróleo, otra a
proyectos para construir nuevas refinerías o plataformas de perforación oceánica. Las etapas
técnicas, las tareas y los ciclos de vida de estos proyectos varían y, por lo tanto, requieren
diferentes metodologías de gestión de proyectos.
Creando la Metodología
Dos formas en que una organización desarrolla una metodología son crearla desde cero o
adoptarla de otro lugar. En la primera forma, un pequeño grupo de los mejores gerentes de
proyectos de la organización se reúnen para crear una metodología que incorpore métodos que
ellos usan o reconocen como buenos y creen que deben adoptarse para su uso en cada
proyecto. En la segunda forma, los gerentes observan las metodologías utilizadas por otras
organizaciones y que representan los estándares de la industria, y adoptan partes de las que
encuentran más adecuadas. Muchas empresas han desarrollado sus propias metodologías
únicas, algunas de las cuales se pueden encontrar en línea. Muchas de estas metodologías son
similares en términos de alcance y detalles, y son una buena fuente de ideas.
Cuando una organización mira un estándar de la industria o el de otra organización

metodología, las utiliza como línea de base a partir de la cual crear su propia metodología y
adaptarla con precisión a sus proyectos y prácticas comerciales. Idealmente, la adaptación
la realiza un grupo de los mejores gerentes de proyectos de la organización (no gerentes
senior ni consultores pagados); esto ayuda a garantizar que la metodología sea apropiada
para los proyectos de la organización y será aceptada por su proyecto
gerentes
Metodología en evolución y mejora continua
Una metodología de gestión de proyectos no es algo estático; está sujeta a cambios y

mejoras basadas en la experiencia y en un entorno cambiante. Una metodología debe
revisarse periódicamente para incorporar cambios en proyectos, tecnología y prácticas
comerciales. A medida que se agregan nuevos pasos y requisitos, se eliminan otros para
evitar que la metodología se vuelva difícil de manejar. Por supuesto, la capacidad de mejorar
la metodología depende de cuánto pueda aprender la organización de sus proyectos
anteriores: su gestión del conocimiento; cubierto a continuación.
Quizás el desiderátum de cualquier metodología es que la recompensa por usarla debe

exceder el esfuerzo de crearla y mantenerla. La metodología no debe volverse aún más
burocrática, obligando a los gerentes a atender más a las reglas que a la gestión de
proyectos. No debe convertirse en "Vamos a completar estos formularios y 'marcar las
casillas' para que podamos continuar con el trabajo".
17.3 Gestión del conocimiento del proyecto
Una trampa potencial en la gestión de proyectos es tratar cada proyecto como si fuera
completamente único e ignorar las lecciones de otros proyectos. Las soluciones a los
problemas se inventan… y se reinventan. Los errores se repiten… y se vuelven a repetir.
¿Por qué sucede eso? Como dice el dicho: “Si me engañas una vez, te avergüenzo.
¡Si me engañas dos veces, la culpa es mía!"
Como ejemplo, considere un proyecto que se piensa que es verdaderamente único. El

director del proyecto debe reflexionar sobre qué esperar y cómo proceder. Comienza con
una pizarra limpia y supone que no hay nadie en la organización que lo ayude porque,
después de todo, el proyecto es único. Pero rara vez se puede decir que no hay nadie en
la organización que pueda ayudar. Por lo general, hay alguien, en algún lugar, con
experiencia y conocimientos que son relevantes para el proyecto. ¡Si tan solo el director
del proyecto supiera quién es ese alguien!
Los autores O'Dell y Grayson describen el problema del conocimiento desperdiciado
Know. No sé que existe o cómo acceder a ella. A menudo,
en su libro
el desperdicio
If Only We Know
ocurrewhat
porque
We
la organización no tiene un proceso formal para capturar y difundir el conocimiento; es
decir, no tiene gestión del conocimiento. En una organización de proyectos, la gestión del
conocimiento ayudaría a garantizar que las personas en cada proyecto aprendan algo y
que todo lo que aprendan esté disponible para otros que puedan usarlo. La gestión del
conocimiento puede proporcionar a los directores de proyectos el conocimiento que
necesitan, ¡incluso en los casos en que ellos mismos no saben que lo necesitan!
Olvido organizacional
De acuerdo con la curva de aprendizaje clásica, el conocimiento se acumula con la

experiencia: cuanto más haces algo, más aprendes y mejor te vuelves, al menos hasta
cierto punto. Lo mismo ocurre con el aprendizaje organizacional, pero a veces con un
giro: inicialmente, la organización adquiere conocimiento a través de la experiencia
(aprende más a medida que hace más), pero luego llega a una meseta o comienza a retroceder, sabien
menos incluso cuando hace más. Este “olvido organizacional” ocurre cuando los trabajadores,
especialmente aquellos con conocimiento tácito (que se analiza más adelante), dejan la
organización, los nuevos procesos y tecnologías vuelven obsoletos a los antiguos, los
procedimientos no están documentados o los registros se descartan o se pierden. 18 Cuando
los equipos se disuelven después de cada proyecto, es fácil que ellos (y la organización) olviden
lo que aprendieron o pierdan oportunidades de aprender de su experiencia y aplicarla a proyectos futuros.
Capturando conocimiento
El conocimiento es información puesta en uso. Todo lo vivido en los proyectos es fuente de

información, pero para aprender de esa experiencia los directivos y equipos deben reflexionar
sobre cada experiencia y sacar conclusiones; deben pensar en lo que sucedió, lo que hicieron
y los resultados; de lo contrario, no aprenderán o lo olvidarán.
Una oportunidad de aprender de un proyecto es llevar a cabo una revisión del proyecto
posterior a la finalización o una autopsia discutida en mejora continua en el Capítulo 9.
Durante la revisión, el equipo examina detenidamente lo que hizo y lo que aprendió de ello.
Reflexiona sobre eventos significativos, éxitos y fracasos, y las acciones que los condujeron.
Esto se analiza en el cierre del proyecto en el Capítulo 12.
A veces, una revisión posterior a la finalización no es suficiente; sucede al final del proyecto,
y en ese momento los recuerdos de los eventos se han desvanecido, los recuerdos de los
detalles se han atenuado y la información se ha perdido. Por lo tanto, especialmente en
proyectos largos, se deben realizar revisiones intermedias adicionales en hitos clave y después
de eventos notables. A diferencia de las revisiones de estado que miden el progreso e identifican
problemas, el propósito de estas revisiones es reflexionar sobre las acciones realizadas y
aprender de la experiencia.
Conocimiento común y transferencia de conocimientos 19
Nancy Dixon define el conocimiento común organizacional como el conocimiento disponible

y de fácil acceso para todos en la organización. Es el conocimiento de "cómo" obtenido a través de

las experiencias de la empresa, en gran medida exclusivo de la empresa y, por lo general, no
disponible para el público. Debido a que se obtiene de las experiencias dentro de la empresa y no es
conocido por personas ajenas, potencialmente distingue a la organización. No se puede medir por
modelos de madurez, sin embargo, es quizás el tipo de conocimiento más importante para ayudar a
una organización a superar a la competencia.
Pero para que el conocimiento organizacional se vuelva “común”, debe ser capturado, retenido y
compartido a través de un mecanismo llamado transferencia de conocimiento. La transferencia de
conocimiento puede ocurrir ampliamente en toda la organización o directamente entre individuos.
Documentación y Bases de Datos
Una forma de transferir el conocimiento relacionado con el proyecto es documentar los aprendizajes
de las revisiones posteriores a la finalización y de la mitad del proceso, e incorporarlos en la
metodología de gestión del proyecto y las listas de verificación de "lecciones aprendidas", "riesgos y
dificultades" y "mejores prácticas". ” El conocimiento documentado también se puede transferir a
través de bibliotecas de informes de proyectos, seminarios de capacitación y bases de datos de
conocimiento en línea. Estas fuentes proporcionan información para, entre otras cosas, la estimación
de "analogía" en las propuestas de proyectos.
Ejemplo 17.1 Preparación de una propuesta utilizando bases de

datos y asesoramiento de pares
Jacque ha recibido una solicitud de propuesta de un cliente para proporcionar asesoramiento

de ingeniería para un nuevo proceso. El cliente quiere una respuesta pronto. Jacque accede a
la base de datos de conocimiento de la empresa para ver lo que ha hecho y está haciendo su
empresa en relación con el proceso. También revisa los resúmenes y artículos en línea para
conocer las prácticas líderes de la industria para el proceso y luego verifica el sistema de
seguimiento de competencias de la empresa en busca de nombres de personas dentro de la
empresa que conozcan el proceso. El nombre
Aparece Leslee, alguien a quien conoció anteriormente en una reunión de networking de toda
la empresa, que la firma de Jacque organiza con frecuencia con el propósito expreso de
permitir que las personas se conozcan y compartan experiencias de proyectos. Jacque
organiza una conferencia telefónica con Leslee, pero antes Leslee consulta la base de datos
de la empresa en busca de antecedentes sobre el cliente de Jacque. Durante la conferencia
telefónica, Leslee y Jacque resuelven los detalles de la propuesta, que Jacque completa y
envía al cliente, apenas una semana después de haber recibido la RFP.
Las bases de datos juegan un papel útil en la gestión del conocimiento, pero su creación y
mantenimiento es un tema propio y está más allá del alcance de este libro. Baste decir que una base
de datos de conocimientos requiere un esfuerzo considerable y que idealmente la administra un
equipo de expertos en conocimientos que saben cómo hacer que sea útil y fácil de usar.
Ernst & Young, por ejemplo, conserva una base de datos de las propuestas, presentaciones y planes
mejor escritos y más informativos organizados en áreas temáticas llamadas 20 , cada una
formulario estandarizado
administrada
y a grupos
por unde
equipo
usuarios
de expertos,
específicos.
documentada en un "Powerpacks",
Un problema con el conocimiento retenido en una base de datos es que está latente: existe pero
es útil solo cuando se accede a la base de datos. Una persona que necesita información tiene que
iniciar el proceso de transferencia y saber dónde buscar en la base de datos y qué preguntas hacer.
De hecho, algunas empresas imponen conocimientos potencialmente útiles a las personas que
los necesitan o podrían utilizarlos. Un grupo de apoyo al proyecto (PSG) o PMO rastrea la
información que podría ser útil para las personas y la reenvía. Si, por ejemplo, un proyecto ha hecho
un trabajo sobresaliente en la reducción de costos de materiales, el PSG escribirá un breve informe
sobre el proyecto y lo enviará a los gerentes de otros proyectos que puedan estar interesados. Esta
documentación y distribución de informes sobre “mejores prácticas” ayuda a la organización a
ampliar su conocimiento común.
Conocimiento tácito e interacción personal
Pero algunos tipos de conocimiento no se pueden resumir en informes escritos y, por lo tanto, no se
pueden transferir a través de un documento o una base de datos. En el Ejemplo 17.1, Jacque confió
no solo en las bases de datos sino también en Leslee para obtener asesoramiento. El asesoramiento
entre pares es la forma de transferencia de conocimientos uno a uno que la firma de Jacque fomenta
a través de reuniones de redes donde las personas se conocen en las que algún día podrían confiar.
al.
Tal interacción personal es necesaria para transferir conocimiento tácito, es decir,
conocimiento que es difícil de poner en palabras escritas o incluso en imágenes, y que
existe solo en la cabeza de las personas y, a veces, es difícil de articular. (Por ejemplo,
aunque puede reconocer fácilmente el rostro de una persona, es posible que no pueda
describir los rasgos faciales de la persona que le permitan hacerlo). Gran parte del
conocimiento requerido para administrar y llevar a cabo un proyecto es tácito, lo que
significa que no puede conservarse o transferirse a través de bases de datos, documentos, informes o lista
Revisiones posteriores a la acción
Los equipos que permanecen intactos de un proyecto a otro pueden aprender y desarrollar un
almacén de conocimientos en crecimiento a través de revisiones posteriores a la acción (AAR). El
concepto se deriva de los equipos de tropas del Ejército de los EE. UU., que usan AAR para
21
informar y aprender de las consecuencias de sus acciones inmediatamente después de un evento.
Una AAR es una reunión rápida inmediatamente después de un evento en la que un
equipo analiza lo que hizo, lo que sucedió, lo que se suponía que debía suceder y qué
representó la diferencia. No es realmente una "reunión", sino más bien una parte de la
forma en que el equipo realiza su trabajo, una AAR es rápida, precisa y toma tan solo 20
minutos. Todos los involucrados en la acción participan y un miembro facilita. El imperativo
es que todos sean sinceros y digan la verdad sin temor a la recriminación. Los AAR son
más efectivos para proyectos que tienen objetivos claros y específicos, y donde el equipo
ha establecido medidas claras para evaluar el impacto de sus acciones para alcanzar los
22
objetivos.
La información de un AAR generalmente se mantiene confidencial, lo que fomenta la
franqueza y reduce los temores de que el equipo o las personas obtengan una mala reputación.
Los equipos que deseen aprender deben sentirse libres de probar diferentes acciones, algunas
que podrían no funcionar, y admitir abiertamente los errores. Todo lo que el equipo aprende en un
AAR permanece con el equipo, a menos que decida compartirlo con personas externas.
Consulta entre pares y grupos de recursos de proyectos
Las AAR se aplican a equipos intactos que realizan proyectos repetitivos. ¿Qué pasa con los
equipos recién formados que acaban de empezar y donde gran parte del proyecto es nuevo
para ellos: su tecnología, ubicación geográfica, cultura, etc.? Es probable que el conocimiento
que necesitan resida en algún lugar de la organización; el truco es conectar a las personas
que tienen el conocimiento (proveedores) con aquellos que lo necesitan (receptores) para que
las dos partes puedan interactuar personalmente uno a uno.
¿Por qué interactuar personalmente? Porque cuando los proveedores y los receptores de
conocimiento lo hacen, suceden cosas asombrosas, como preguntas y soluciones que surgen
entre ellos y que ni el proveedor ni el receptor habrían pensado de antemano. Tal vez hayas
experimentado esto: pides el consejo de alguien, lo que los lleva a hacerte una pregunta, lo
que te lleva a responder una pregunta, y así sucesivamente. A menudo, este cuestionamiento
de ida y vuelta da como resultado seguir caminos que ninguno de ustedes anticipó. El
proveedor de conocimiento ve la situación de una manera nueva, establece paralelismos y
presenta percepciones e ideas nuevas. La pregunta es: ¿qué puede hacer una organización
para reunir a los proveedores y receptores de conocimiento para que esto suceda?
Ejemplo 17.2 Consulta entre pares
Un equipo de ingenieros de naves espaciales está preparando una propuesta para

licitar un satélite para una corporación de telecomunicaciones. El equipo revisó los
requisitos del cliente y preparó un diseño preliminar, pero no puede decidir sobre las
características de la configuración del satélite debido al gran riesgo y la inversión del
proyecto. Para obtener asesoramiento, el líder del equipo se pone en contacto con 11
personas en diferentes divisiones de la empresa a quienes conoce personalmente o por
rumores. Seis responden que están dispuestos a ayudar: cuatro de las divisiones de la
empresa en California y Texas, y dos que trabajan en la NASA, y el líder hace arreglos
para que ellos ("asesores de pares") se reúnan en persona con su equipo durante un día
en California. . En la reunión, el equipo del satélite presenta los datos que ha recopilado
y pega diagramas y gráficos en las paredes. Los consultores pares preguntan al equipo
sobre las implicaciones de los datos y luego
todos trabajan juntos para desarrollar criterios para decidir la configuración final. Luego, el
equipo satélite abandona la sala brevemente mientras los consultores pares revisan todo y
preparan recomendaciones. Cuando el equipo del satélite regresa, los consultores resumen
sus conclusiones. No se toma ninguna decisión sobre la configuración final en la reunión,
sin embargo, el equipo del satélite ha aprendido mucho sobre los problemas que aún debe
resolver.
Para la empresa de este ejemplo, cualquier director de proyecto que necesite una consulta
entre pares puede solicitarla y la empresa cubrirá los gastos de viaje y tiempo libre de los
consultores. El proceso de consulta enfatiza el cuestionamiento, el análisis y la retroalimentación;
los consultores pares ofrecen orientación, pero el equipo del proyecto toma sus propias
decisiones. 23
Algunas empresas utilizan un "sistema de localización", que proporciona nombres, direcciones,

números de teléfono y otra información pertinente de personas en todo el mundo que trabajan en
áreas de conocimiento específicas; algunas empresas complementan eso con sus propios
consultores internos a tiempo completo.
24
Ejemplo 17.3 Grupo de apoyo al proyecto
El grupo de soporte de proyectos (PSG) de una gran corporación farmacéutica incluye diez
consultores disponibles a pedido para brindar apoyo experto a cualquier gerente de
proyecto que lo solicite. También están disponibles los servicios de medio tiempo de más
de 50 gerentes en toda la corporación con experiencia en planificación y ejecución de
proyectos. Como centro de beneficio, el PSG cobra honorarios a las unidades empresariales
de los gestores de proyectos a los que asiste. El PSG también patrocina foros semestrales
donde los gerentes de proyecto se reúnen para compartir experiencias.
Los beneficios del PSG se ilustran en la historia de Trevor, un gerente de proyecto típico.
Cuando su proyecto estaba a punto de completarse, Trevor asistió a un foro. Confiado en
que su proyecto había sido un gran éxito, se sorprendió al enterarse de otros dos proyectos
similares recientemente completados. Uno había desarrollado un proceso que, de haberlo
sabido, podría haberle ahorrado 3 meses a su proyecto; el otro había cometido errores
similares a los cometidos en el proyecto de Trevor y, de haberlo sabido, podría haberse
ahorrado $50,000. En otras palabras, el
¡El costo de que Trevor no supiera lo que otros en su compañía ya sabían fue de 3 meses
y $50,000!
Para su próximo proyecto, Trevor se puso en contacto con el PSG, que asignó a Jiang
para trabajar con él. Aunque el departamento de Trevor tuvo que pagar por los servicios
de Jiang, Trevor sintió que el consejo que recibiría podría beneficiar sustancialmente su
proyecto de $250 millones. El PSG también proporcionó una base de datos de proyectos
actuales con prácticas de vanguardia, que Jiang y Trevor usaron para desarrollar el plan
del proyecto. A lo largo del proyecto de 2 años, Jiang contribuyó con ideas, herramientas
de gestión, objetivos de evaluación comparativa, revisión por pares y disponibilidad de
guardia para tutoría y entrenamiento.
Aunque muchos gerentes de proyecto en la empresa usan bases de datos de
conocimiento, la forma más importante de obtener conocimiento específico del proyecto
es a través de consultores que dedican el tiempo para comprender un proyecto lo
suficientemente bien como para aprovechar su conocimiento tácito para obtener
información y sugerencias. Son “bases de datos vivas” que viajan de proyecto en
proyecto, adaptando su conocimiento a las necesidades de cada uno.
La transferencia de conocimientos a partir de la interacción personal funciona mejor cuando

la organización apoya y facilita el proceso. Las solicitudes de asistencia se consideran un
proceso comercial legítimo, no una solicitud de favores; la gente pide ayuda libremente sin
sentirse intrusiva. Se alienta o se requiere que todos aprovechen el proceso. El conocimiento
es poder, y esa es otra razón para formalizar el proceso: en algunas organizaciones, las
personas informadas pero hambrientas de poder se resisten a las solicitudes de asistencia y
evitan compartir lo que saben.
Discusión
Las empresas con las mejores prácticas de gestión del conocimiento utilizan una variedad de
métodos que dan cuenta tanto del conocimiento tácito como del conocimiento explícito. Por
ejemplo, los diseñadores de naves espaciales de Hughes Space & Communication Company
pueden reducir los costos de desarrollo al "reutilizar" los diseños siempre que sea posible. Para
no “reinventar” nada, se apoyan en la “Autopista del Conocimiento”, un proceso que incluye una
intranet, una base de datos de lecciones aprendidas y mejores prácticas
25
compilado por un equipo editorial y consejos para expertos. En Microsoft,
se fomenta el intercambio de información a través de almuerzos informales mensuales
entre grupos. Los gerentes de Word, Excel y MS Project se reúnen durante dos horas
para hablar sobre su trabajo, problemas y pensamientos; también se les anima a
reunirse de manera informal o dar presentaciones a otros gerentes de toda la empresa
y en todo el mundo. 26
¿Quién es el responsable de gestionar el conocimiento del proyecto? El gerente de
proyecto es responsable de capturar el conocimiento en cada proyecto y compartirlo con
sus pares, pero la responsabilidad del “conocimiento común” organizacional debe recaer
en los gerentes o unidades organizacionales que supervisan los proyectos. En muchos
casos esa responsabilidad reside en un PSG o equipo de gestión del conocimiento. A
menudo, el equipo es parte de la PMO.
17.4 Oficina de Gestión de Proyectos 27
Piense por un momento en todo lo que hace el gerente de proyectos como se describe
en este libro y pronto se dará cuenta de que ser un gerente de proyectos es mucho trabajo.
Gran parte de ese trabajo implica recopilar y procesar datos y preparar documentos,
informes, planes, presupuestos y presentaciones. La carga de trabajo puede ser
abrumadora y, a veces, no hay suficiente tiempo en un día para hacerlo todo.
Ejemplo 17.4 Centro Médico del Área de la Bahía
Gaurav y otros directores de proyectos del Centro Médico del Área de la Bahía
asistieron a una serie de seminarios sobre gestión de proyectos. Al final de la serie
todos coincidieron en el valor de las herramientas aprendidas y volvieron al trabajo
con toda la intención de ponerlas en práctica. Meses después, la realidad fue que
Gaurav y sus colegas habían usado poco de lo que habían aprendido y casi nada
había cambiado en la forma en que administraban los proyectos. Gaurav había
comenzado a crear un gráfico WBS y Gantt para sus proyectos más grandes, pero
se dio por vencido; ya trabajaba muchas horas, le quedaba poco tiempo para
dedicarse a ellas. Además, BAMC no ofreció apoyo ni reconocimiento para usar
estas u otras herramientas comunes de gestión de proyectos.
BAMC no es diferente de muchas organizaciones: envían gerentes de proyecto a

seminarios para aprender formas nuevas y mejores, pero luego no hacen nada para
alentar o apoyar el uso de esas formas. Las herramientas quedan en el camino y nada cambia.
Contrarrestando esto en otras organizaciones está la oficina de gestión de proyectos
(PMO, también llamada oficina de soporte de proyectos o PSO), un departamento o
unidad cuyo propósito es ayudar y apoyar a los directores de proyectos, asignar recursos
de proyectos y, en general, facilitar una buena gestión de proyectos. práctica. La PMO
establece y mantiene la metodología de gestión de proyectos, impulsa iniciativas que
aumentarán la madurez de gestión de proyectos de la organización y supervisa la gestión
del conocimiento. Una PMO formaliza la práctica de la gestión de proyectos,
pero asiste a los gerentes de proyecto para que no se sientan abrumados y puedan adaptarse a
la formalización.
Liderazgo de la Oficina de Gestión de Proyectos
Los altos directivos a menudo no entienden la gestión de proyectos; lo ven como un rol o trabajo,
no como una profesión. Para ellos, los proyectos son sucesos discretos que tienen poco en
común. Permiten que los gerentes de proyecto trabajen de manera independiente pero les
otorgan poca autoridad formal. Uno de los primeros desafíos de la PMO es recalcar en los
gerentes senior la importancia del rol de gerente de proyecto y de que todos se adhieran a una
metodología de gestión de proyectos prescrita. Para llamar la atención de los gerentes senior,
la PMO debe contar con algunos de los gerentes de proyectos más experimentados y respetados
de la organización.
figura 17.5 Principales funciones y responsabilidades de la PMO.
La PMO puede tomar muchas formas. Típicamente es un personal permanente que ayuda a
guiar proyectos en todos o ciertos departamentos de la organización; a veces lo es
creado para servir a un solo gran proyecto o programa y se disuelve al cierre del proyecto.
Algunas PMO están centradas en el cliente o en el departamento, por ejemplo, sirviendo a los
gerentes en proyectos para un determinado cliente, o para departamentos como TI, investigación
o desarrollo de productos, unidades donde el trabajo se basa principalmente en proyectos.
¿Qué hace exactamente una PMO? Los focos y las actividades de una PMO, que se
muestran en la Figura 17.5, se describen en las siguientes secciones, comenzando en cada
caso con las actividades básicas de la mayoría de las PMO y terminando con las de
organizaciones de proyectos maduras.
1. Estándares de Gestión de Proyectos
Metodología de Gestión de Proyectos
La metodología es la forma prescrita por la organización para gestionar un proyecto; si es la

“ley”, entonces la PMO es el “legislador”, el “promotor de la ley” y el “ejecutor de la ley”. A
menudo, la PMO origina la metodología, la mantiene y es responsable de su implementación y
mejora.
Políticas, procedimientos, estándares y métricas de gestión de proyectos
La aplicación de la metodología requiere políticas, procedimientos, estándares y métricas. Un

ejemplo es una política que requiere que los gerentes de todos los proyectos de cierto tamaño
se ajusten a la metodología. Si la metodología incluye "Crear el plan del proyecto", también
especificará detalles sobre lo que constituye el "plan" y los procedimientos para crearlo (por
ejemplo, definir el alcance, crear la EDT, estimar recursos, tiempo y costo, etc.). La PMO
establece las políticas y define los procedimientos.
Idealmente, la PMO también brinda a los gerentes de proyecto apoyo y asistencia con
respecto a las políticas, los procedimientos o los requisitos que sugiere o exige. Para que las
políticas y los procedimientos sean fácilmente realizables y no demasiado onerosos, la PMO
ofrece varias formas de asistencia, como proporcionar apoyo administrativo, de recopilación de
datos y de ingreso de datos, y formularios, plantillas y listas de verificación estándar fáciles de
usar.
2. Recursos del proyecto y apoyo a la gestión del proyecto
Administracion de recursos
Un problema común en las organizaciones basadas en proyectos es que los proyectos

simplemente no cuentan con los recursos adecuados. Esto sucede cuando los proyectos
se inician y aprueban sin considerar los recursos necesarios frente a los recursos
disponibles. Como resultado, los recursos se transfieren de un proyecto a otro y algunos
proyectos se retrasan o posponen para que otros puedan iniciarse o finalizarse.
En esta capacidad, la PMO mantiene un registro de los recursos del proyecto, como el
número de empleados de tiempo completo en cada cargo o categoría de habilidad. El
registro incluye para cada recurso el número asignado a proyectos actuales versus el
número disponible para nuevas asignaciones de proyectos. Esto permite a la organización
determinar para un nuevo proyecto si hay suficientes recursos disponibles, si se deben
adquirir recursos adicionales o si el proyecto se debe posponer o cancelar.
En muchas organizaciones, la selección y la prioridad relativa de los proyectos las
establece una Junta de Revisión de Proyectos (PRB). La PMO proporciona la información
sobre los recursos para que la PRB pueda determinar la factibilidad de emprender cada
nuevo proyecto y asignar los recursos a los proyectos de mayor prioridad. El capítulo 18
cubre esto.
Ver Capítulo 18
Software de Gestión de Proyectos y Tecnología de la Comunicación
En la mayoría de las empresas basadas en proyectos, todos los directores de proyectos

utilizan el mismo software de gestión de proyectos. A menudo, este software está integrado
con otro software para adquisiciones, recursos humanos y finanzas, y tiene aplicaciones de
telecomunicaciones e Internet/intranet. El software comprende un “sistema de gestión de
proyectos empresariales” que forma parte del sistema ERP de la empresa. A menudo, la
PMO es responsable de la adquisición, instalación y actualización del software, así como
de brindar capacitación en su uso y aplicaciones. Para software que requiere tiempo-
Al consumir la entrada de datos para la programación, el presupuesto, la planificación y el seguimiento, la

PMO a menudo proporciona apoyo administrativo y de entrada de datos.
Instalaciones del proyecto
Los proyectos ubicados en sitios independientes (proyectos de construcción) o fuera de la organización de

origen (incluidos proyectos en el extranjero) o involucran múltiples funciones u organizaciones necesitan una
oficina física, un lugar central para que el personal del proyecto se reúna y trabaje. La PMO organiza la
oficina del proyecto y las instalaciones relacionadas, como salas de reuniones para conferencias y foros.
Para proyectos en el extranjero, también podría organizar viajes, alojamiento y otras necesidades del personal
del proyecto.
Mentoría, Consultoría y Gestión del Conocimiento
Como se discutió, el personal de la PMO puede incluir expertos técnicos y gerentes de proyectos
experimentados disponibles para recibir asesoramiento y consultas. Además, la PMO programa y facilita
sesiones de creación de equipos, reuniones de estado y revisiones posteriores a la finalización, y proporciona
facilitadores para guiar las sesiones.
La PMO es el centro de gestión del conocimiento del proyecto, no solo en virtud de sus servicios de
consultoría y tutoría, sino también por promover el conocimiento común organizacional mediante la
organización de foros, encuentros profesionales y grupos de discusión donde los gerentes de proyectos se
reúnen y comparten experiencias y lecciones aprendidas.
3. Competencia del Gerente de Proyecto
La PMO supervisa la mayoría de los asuntos relacionados con las habilidades y destrezas de los gerentes de
proyecto de la organización; específicamente:
• Determina los requisitos de habilidades y competencias para los gerentes de proyectos, •

Ayuda a contratar nuevos gerentes de proyectos, • Organiza que los gerentes de proyectos
asistan a cursos y seminarios de capacitación, • Prepara trayectorias profesionales para los
gerentes de proyectos y ofrece trayectorias profesionales
entrenamiento,
• Ayuda a los gerentes a prepararse para la certificación (PMP, CPM, APM, CAPM,
RegPM),
• Asiste en la evaluación y promoción de gerentes de proyecto, • Ofrece
capacitación en metodología, herramientas y liderazgo de gestión de proyectos
y habilidades de comunicación.
4. Enlace con la Junta de Revisión de Proyectos
Por ahora, basta con decir que el PRB está a cargo de la supervisión de todos los proyectos
importantes, incluida la decisión de cuáles financiar, cuáles diferir y cuáles eliminar (discutido
en el Capítulo 18). La PMO actúa como asesora de la PRB y proporciona a la PRB la
información necesaria para tomar estas decisiones. A medida que cada proyecto pasa por el
proceso de selección, el PRB evalúa su desempeño, en parte basándose en la información
de los "paneles de control" del proyecto publicados en el sitio web que comparan el desempeño
de cada proyecto con el de otros proyectos en términos de algunas métricas clave. La PMO
se asegura de que los proyectos que llegan a una puerta hayan cumplido con la documentación
y otros requisitos de entrada, y publica información sobre los proyectos para que la PRB los
revise. Podría decirse que la capacidad de la PRB para tomar decisiones efectivas se basa
en gran medida en la capacidad de la PMO para proporcionarle información precisa y oportuna
sobre el proyecto. El director de la PMO se sienta en el PRB y ayuda con la selección de
proyectos y las decisiones de prioridad.
Ver Capítulo 18
Evolución de la PMO
La creación de una PMO es un proyecto en sí mismo. A veces, las PMO se establecen todas
a la vez y con la ayuda de consultores externos; a menudo se crean más lentamente e
internamente. Comienzan con un personal pequeño y un propósito limitado, instigados por
uno o unos pocos gerentes de proyectos veteranos que reconocen la necesidad de un
enfoque estandarizado para la gestión de proyectos. La mayoría de las veces esto sucede en la TI
o departamentos de desarrollo de productos (PD) donde el trabajo se basa en proyectos.

Los gerentes que impulsaron la PMO, con el apoyo de un gerente de nivel superior como
campeón, crean una metodología de gestión de proyectos. También crean los procedimientos,
estándares, formularios y plantillas necesarios para que la metodología funcione y comienzan a
ofrecer capacitación a los gerentes de proyecto. Inicialmente, la PMO puede consistir en una
persona: el "director" de la PMO, quien (no por casualidad) suele ser la misma persona que
concibió la PMO y ayudó a crear la metodología.
Con el tiempo, el puesto de director y el personal de la PMO se amplían a medida que

aumentan sus responsabilidades para incluir asesoramiento, consultoría, perfeccionamiento de
la metodología y prestación de apoyo administrativo y técnico. Al principio, la PMO supervisa
proyectos solo en el área de la organización en la que surgió, como PD o TI. Si todo va bien, los
proyectos en esa área mejorarán y, al darse cuenta de esto, la alta dirección indicará a otros
departamentos que utilicen la metodología en sus proyectos. En este punto, el rol de la PMO se
amplía para ayudar a los gerentes de proyectos de toda la empresa a aplicar la metodología,
desarrollar metodologías alternativas para dar mejor cuenta de la diversidad de proyectos en
toda la empresa y organizar foros y seminarios, acumular lecciones aprendidas y crear bases de
datos de conocimiento. y listas de competencias (gestión del conocimiento). También se le
puede solicitar a la PMO que establezca un proceso de selección y ayude a la PRB en la
selección y priorización de proyectos. Eventualmente, la PMO podría convertirse en un
departamento completo en el que todos los gerentes de proyecto estén "basados" y desde el
cual se les asignan proyectos en toda la empresa.
En respuesta a esta sección, algunos lectores podrían reaccionar: "¡Eso no es como la PMO
en mi organización!" El hecho es que, a veces, los gerentes de proyectos ven a la PMO como
poco más que la "policía de proyectos" de la alta gerencia, cuyo objetivo principal es vigilar los
proyectos, publicar boletos rojos, amarillos o verdes en el tablero del proyecto y hacer cumplir
las órdenes de la alta gerencia. prácticas y requisitos. Dichas PMO son PMO solo de nombre y
son contrarias al espíritu previsto de la PMO, que es facilitar una mejor gestión de proyectos y
permitir que los gerentes de proyecto hagan mejor su trabajo.
17.5 Gestión del programa

Un programa (o programa) es un conjunto de proyectos y otras actividades organizadas y
coordinadas para lograr un propósito u objetivo general. Los proyectos están interrelacionados
(interdependientes o vinculados en las relaciones predecesor-sucesor), a menudo comparten
clientes, tecnología o recursos comunes y proporcionan una capacidad colectiva. Un ejemplo
es el programa de un fabricante de automóviles para desarrollar “vehículos ecológicos”. El
programa consta de múltiples proyectos, algunos dedicados al desarrollo de motores eléctricos,
motores híbridos y motores de combustible alternativo, otros al desarrollo de tecnología de
baterías y materiales livianos para componentes de carrocería. Al igual que los elementos de
un sistema, cada uno cumple una función necesaria para el éxito del programa.
La gestión del programa prioriza y coordina el conjunto de proyectos y otras actividades

para cumplir con los objetivos del programa y obtener beneficios que no se pueden lograr con
un solo proyecto. A veces, la gestión de programas se considera una extensión de la gestión
estratégica, ya que implementa iniciativas estratégicas y gestiona el cambio en la organización
o comunidad. El programa de vehículos ecológicos, por ejemplo, podría verse como la forma
en que el fabricante implementa una iniciativa estratégica para mover su tecnología y
producción hacia automóviles sin combustible de carbono.
La gestión de proyectos y la gestión de programas comparten características comunes,
pero la gestión de programas es una disciplina en sí misma, lo cual es necesario porque,
simplemente, los programas son diferentes a los proyectos.
Programas versus Proyectos
28
Las principales diferencias entre un proyecto y un programa son:
• Un proyecto proporciona entregables específicos (productos, servicios u otros

resultados) por un costo específico en una fecha específica. Un programa brinda
beneficios : mayores ingresos, ganancias, satisfacción del cliente o conocimiento;
mejor servicio comunitario; disminución de costos o daño ambiental; mejores procesos
de negocio y resultados. Los beneficios se derivan de la
entregables de los proyectos u otras actividades y, por lo general, se alinean con las
estrategias comerciales. • La duración de un programa puede ser indefinida sin fecha de
finalización establecida. • Un proyecto proporciona resultados a clientes y clientes particulares.
Un programa brinda beneficios a múltiples partes interesadas con diferentes necesidades en
toda la organización, comunidad o sociedad.
• Un programa puede evolucionar con el tiempo en respuesta a la competencia, tecnología,

o cambios políticos.
• Múltiples proyectos, actividades y recursos permiten que el programa logre
beneficios que superan los que se pueden lograr con cualquier proyecto.
El último punto dice que los beneficios de un programa van más allá de los de los proyectos que lo
componen. Tomemos, por ejemplo, una empresa constructora que forma programas basados en los
tipos de proyectos que realiza. Al agrupar proyectos en programas para, por ejemplo, construcción
de caminos, repavimentación de caminos y sistemas de retención, cada programa brinda beneficios,
por ejemplo, consolidación de aprobaciones de trabajo y simplificación de procesos, que no se
pueden lograr con los proyectos individuales.
29
Tipos de programas
Entre los tipos comunes de programas se encuentran los orientados a objetivos, de mejora y de
cartera.
Un programa orientado a objetivos es un grupo de proyectos y otras actividades que, combinados,
implementan una estrategia o cambio organizacional, o desarrollan e implementan una nueva
aplicación o tecnología. El programa coordina los proyectos y otras actividades para lograr beneficios
generales vinculados a las estrategias comerciales y objetivos organizacionales amplios. El programa
de vehículos ecológicos es un ejemplo; el programa Cosmic Mercury Exploration del Caso 17.4 es
otro.
Un programa de mejora proporciona mejoras periódicas a los sistemas, procesos o infraestructura
existentes a través de avances proporcionados por proyectos individuales.
El programa sirve como marco para tratar con las solicitudes de toda la organización para mayor
funcionalidad, capacidad o rendimiento, incluso mantenimiento, y lo hace durante la vida útil del
sistema o proceso que pretende mejorar.
Un ejemplo es un hospital que adopta métodos de "producción ajustada", que implica
numerosos proyectos y actividades (eventos de mejora, sesiones de capacitación, cambios en los

procesos y procedimientos) que deben coordinarse y alinearse con las metas del hospital y las
operaciones en curso. Otro ejemplo es un programa de capacitación laboral patrocinado por el
gobierno que sirve como centro de intercambio de información para instituciones que ofrecen
capacitación/educación para la equivalencia de la escuela secundaria, educación básica para
adultos, capacitación en habilidades profesionales, títulos universitarios, certificaciones, aprendizajes y pasantías.
Un programa de cartera es un grupo de proyectos que, por lo demás, son independientes pero
comparten algo, como recursos o tecnología. El propósito del programa es coordinar los proyectos
entre sí, asignar recursos compartidos o consolidar procedimientos para mejorar el desempeño del
conjunto general de proyectos. La empresa constructora mencionada anteriormente que forma
programas en torno a los mismos tipos de proyectos es un ejemplo.
Los programas también se pueden clasificar según la forma en que se inician. 30 Algunos se
derivan de una estrategia clara: la organización del programa se crea en torno a una visión y
propósito estratégicos, luego se crean proyectos y otras iniciativas para lograr el propósito; Los
programas orientados a objetivos se forman de esta manera. Alternativamente, un programa “surge”
cuando alguien reconoce que los proyectos preexistentes podrían administrarse mejor si estuvieran
organizados y coordinados. Si los proyectos son en gran medida independientes, podrían agruparse
en una cartera; si están relacionados y contribuyen a un propósito mayor, podrían agruparse en un
programa relacionado con la mejora.
17.6 Fases del programa 31
Los programas no tienen entregas específicas ni fechas de finalización, por lo que no siguen el mismo
ciclo de vida que los proyectos. No obstante, los programas orientados a objetivos y algunos programas
de mejora tienen ciclos de vida con fases como el inicio del programa, la definición, la ejecución del
proyecto, la renovación y el cierre. Mientras que los ciclos de vida de los proyectos normalmente
terminan con la entrega del artículo final, los ciclos de vida del programa pueden extenderse para incluir
la transición de la organización y la operación inicial del artículo final. Las fases del programa pueden
repetirse: los proyectos se ejecutan, los elementos finales se entregan y luego el programa se renueva
(repite) o se cierra.
Fase de inicio (o formulación) del programa
Un programa se inicia en respuesta a alguna presión o necesidad de la organización, por ejemplo:

clientes, objetivos, desafíos o estrategias nuevos o cambiantes; competencia; o una revisión de los
programas y proyectos actuales y propuestos. Un ejecutivo crea un caso de negocios de alto nivel que
define los objetivos del programa y la alineación con las estrategias organizacionales, y justifica su
factibilidad. Una revisión de puerta después de esta fase por parte de la junta de gobierno del programa
aprueba o cancela el programa.
Si se aprueba, se selecciona un administrador del programa y el equipo del programa.
Fase de Definición
Esta fase sigue a la iniciación del programa oa una decisión de "renovación", que se describe a
continuación. Después de la iniciación, esta fase incluye establecer un caso de negocios más detallado
y los objetivos del programa, un plan del programa, los requisitos de recursos y el presupuesto, y definir
y secuenciar los proyectos iniciales conocidos y otros trabajos para comprender el programa. También
requiere la creación de una estructura organizativa para el gobierno y la gestión del programa, la
asignación de responsabilidades del programa y el establecimiento de procedimientos y sistemas
operativos.
Si la fase sigue a una decisión de renovación, la definición consiste en actualizar
estrategias y objetivos, estableciendo proyectos nuevos o revisados y otras iniciativas, y

actualizando el plan y las responsabilidades del programa. La puerta después de esta
fase determina si el programa y sus proyectos componentes están listos para la fase de
Ejecución del Proyecto.
Fase de Ejecución del Proyecto
Se ejecutan los proyectos y demás actividades de trabajo que constituyen el programa.

El equipo del programa monitorea el desempeño colectivo y las interdependencias de los
proyectos; La alta gerencia evalúa los beneficios del programa y determina si los cambios
son necesarios para mantener los proyectos o el programa alineados con los objetivos
del programa. La fase incluye dirigir la entrega de los elementos finales del proyecto,
preparar a la organización para el cambio y garantizar el apoyo para la adopción y
operación de los elementos finales. La puerta después de esta fase evalúa los beneficios
acumulados hasta el momento, los riesgos del programa y la alineación de los proyectos
con las metas de la organización, y determina si el programa se mantendrá ("renovará")
o se cerrará. Con la renovación, el programa continúa tal cual o con cambios en su
dirección o composición, e inicia un nuevo ciclo de Definición y Ejecución del Proyecto.
Fase de cierre
El programa finaliza porque se lograron los objetivos, el programa ya no es justificable o

hay mayores beneficios disponibles en otros lugares. Los proyectos inconclusos y otros
trabajos se cancelan o asignan a otros programas. Se realiza una revisión posterior al
programa para las lecciones aprendidas, y el equipo del programa se disuelve y se
reasigna.
17.7 Temas de gestión de programas 32
Cuatro temas impregnan la gestión de programas: gestión de decisiones, gestión de beneficios,

gobernanza de programas y gestión de las expectativas de las partes interesadas.
33
Gestión de decisiones
La gestión de decisiones se refiere a la forma en que se toman e implementan las decisiones.

En los programas, debe tener en cuenta la complejidad de las decisiones resultantes de
múltiples partes interesadas, la incertidumbre sobre el futuro, la ambigüedad sobre las
alternativas y los vínculos entre los resultados y los objetivos estratégicos.
La gestión de decisiones en los programas ocurre iterativamente a lo largo de todas las
fases del programa. Las partes interesadas discuten asuntos, acuerdan una visión compartida
y toman una serie de pequeñas decisiones alineadas con la visión. Evalúan los beneficios de
los entregables del proyecto y otras actividades para tomar decisiones y tomar medidas con
respecto a los proyectos, programas o estrategias. Las organizaciones sin gestión de programas
tienden a no evaluar los beneficios empresariales de los proyectos.
Gestión de Beneficios
34
Los beneficios son mejoras comerciales tangibles que respaldan los objetivos estratégicos.
Pueden medirse solo después de que los elementos finales o las capacidades de los proyectos
u otras actividades se hayan implementado y estén operativos.
La gestión de beneficios se refiere a la evaluación del impacto organizacional del programa
y la gestión de los beneficios interdependientes entregados por los proyectos. Los beneficios
esperados se definen primero durante el inicio del programa en el caso de negocios. En
Definición, se desarrolla un plan de beneficios , que especifica cómo los beneficios se alinean
con las estrategias organizacionales y se derivarán de los resultados del programa. El plan
también estipula un cronograma para la realización de los beneficios, métricas para medirlos,
roles y responsabilidades para gestionarlos y medios para transferir los beneficios del programa
a la organización. En ejecución de proyecto
los beneficios son monitoreados, y en Renovación y Cierre, la responsabilidad de mantener

los beneficios se transfiere a los clientes y otras partes.
Gobernanza del programa
La gobernanza del programa se refiere a la forma en que se organizan y coordinan los

elementos del programa para cumplir con los objetivos del programa. La gobernanza
comienza con el desarrollo de una visión y los objetivos del programa basados en las
estrategias comerciales y las necesidades de las partes interesadas, y luego crea y usa los
mecanismos necesarios para monitorear el programa y mantenerlo alineado con los objetivos
y las estrategias. Como se mencionó, incluye revisiones de puerta de fase para decidir si el
programa debe continuar o cerrarse.
La responsabilidad de la gobernanza se comparte entre la junta de gobernanza del
programa (o comité directivo), el director del programa, el gerente del programa y el equipo
del programa. La junta, un comité de gerentes senior, cumple muchas funciones: iniciar el
programa, alinearlo con las estrategias de la organización, aprobar planes y solicitudes de
cambio de alto nivel, revisar el progreso y los beneficios, ayudar al gerente del programa en
temas difíciles, asegurar la disponibilidad de recursos, y mantener el programa en conformidad
con las políticas y procedimientos de la organización. La junta se reúne solo periódicamente
y, por lo tanto, depende del equipo del programa para la supervisión y orientación del
programa. En organizaciones con muchos programas, la responsabilidad de la gobernanza
se comparte con una oficina de gestión de programas; este y otros roles de gobierno del
programa se analizan más adelante.
Gestión de las expectativas de las partes interesadas
La gestión de las expectativas de las partes interesadas, discutida en el Capítulo 15, incluye
los pasos para identificar a las partes interesadas, sus intereses y expectativas, y su
influencia; comunicarse con ellos; y trabajando para aumentar su aceptación o apoyo al
programa y disminuir cualquier resistencia. A veces se denomina “participación de las partes
interesadas” porque las partes interesadas deben participar en la definición y ejecución del
programa; además, en general, no les gusta que los “manejen”. A menudo, las partes
interesadas tienen una autoridad y un poder formales considerables, lo que requiere un mecanismo de facili
estilo de liderazgo participativo por parte del director del programa. Las partes interesadas con
frecuencia tienen expectativas diferentes o contradictorias, por lo que llegar a un acuerdo implica
mucha negociación.
Las partes interesadas clave se consideran "socios" del programa y su compromiso es una calle de
doble sentido: el programa tiene como objetivo cumplir con las expectativas de las partes interesadas,
pero al mismo tiempo las partes interesadas deben cumplir con las expectativas del programa, por
ejemplo, cooperar en la definición de los requisitos del programa y los beneficios esperados y, más
tarde , suministrar información y dar aprobaciones previa solicitud. La gestión de las partes interesadas
debe tener en cuenta el hecho de que, en los programas, tanto las partes interesadas como sus
expectativas pueden cambiar.
Ver Capítulo 15
35
17.8 Organización del Programa
Los roles y relaciones en la organización de un programa se ilustran en la Figura 17.6.
A la cabeza de la organización se encuentran el patrocinador del programa, la junta

directiva, el director, el administrador de cambios comerciales y las partes interesadas clave.
La junta directiva, como se mencionó, es responsable de definir la relación del programa con
la estrategia y las metas de la organización, supervisar y guiar el programa y crear un entorno
de apoyo para el programa. La junta generalmente está dirigida por un director de programa,
un ejecutivo que es "dueño" del programa y tiene la responsabilidad general de cumplir con
los objetivos y brindar beneficios. A menudo, sin embargo, quien toma las decisiones clave en
la junta es el patrocinador del programa; ella defiende el programa y le otorga la ratificación de
la alta gerencia. Ella es responsable de la "transición" fluida de los elementos finales y los
resultados del proyecto a las operaciones comerciales en curso, y de informar a la junta sobre
los beneficios resultantes. (A veces, la responsabilidad de la transición la maneja alguien con
un rol especial, el administrador de cambios comerciales).
La figura 17.6 también muestra una oficina de gestión de programas y una oficina de
programas. Los dos términos a veces se usan indistintamente, pero tal como se definen aquí,
son diferentes. La oficina del programa es el equipo que asiste al gerente del programa en la
administración de proyectos u otras iniciativas dentro del programa. Para los proyectos dentro
del programa, la oficina maneja innumerables funciones: contratación, elaboración de
presupuestos, capacitación, gestión de riesgos; eliminando tareas redundantes; resultados de
seguimiento; estado de los informes; y monitorear y evaluar los beneficios a nivel de programa
de los resultados del proyecto. En programas grandes asigna recursos y coordina esfuerzos
entre proyectos constituyentes. Al cierre del programa, la oficina del programa se disuelve.
En contraste, la oficina de gestión de programas (PmMO) es una oficina permanente que
brinda apoyo administrativo a todos los programas. Cumple una función similar a la PMO,
discutida anteriormente, excepto que está dirigida a programas, no a proyectos.
figura 17.6 Organización del programa, roles y relaciones.
En el centro de la organización de un programa se encuentra el gerente del programa, cuya

responsabilidad general es lograr los resultados del programa tal como se definen en el plan de beneficios.
Los deberes específicos incluyen: 36
• Desarrollar planes y cronogramas a nivel de programa.

• Revisar y aprobar los planes del proyecto para que se ajusten a las estrategias, los planes y
los cronogramas del programa. • Ser responsable ante la junta de gobierno por el
cronograma, el presupuesto y la calidad de todas las actividades del programa; proporcionar a
la junta actualizaciones sobre el progreso del programa.
El administrador del programa trabaja con el "equipo del programa", que en la Figura 17.6
incluye la Oficina del Programa, los gerentes de los proyectos constituyentes y otras iniciativas del
programa, y cualquier otra persona involucrada en la administración del programa.
17.9 Consideraciones especiales
La mayoría de los directores de programas han sido directores de proyectos y están

familiarizados con las herramientas y los métodos de gestión de proyectos. Sin embargo, al
convertirse en gerente de programas, descubren que la gestión de programas difiere de la
gestión de proyectos en varios aspectos, como los siguientes.
Gestión de transición
La transición es un tema central en la gestión de programas; esta es la transferencia de los

resultados del proyecto (productos, capacidades, conocimientos) a las partes interesadas del
programa (usuarios, operadores, clientes). Se refiere a todo lo relacionado con la entrega de los
resultados del proyecto al cliente o usuario, como la toma de posesión física, las pruebas
operativas y la capacitación, y el seguimiento y soporte. En términos del ciclo de desarrollo del
sistema, incluye la Fase D, o al menos lo suficiente para determinar si se han obtenido los
beneficios esperados. Mientras que en un proyecto, la entrega de artículos finales generalmente
ocurre solo una vez; en un programa sucede repetidamente, generalmente al final de cada uno
de una sucesión de proyectos u otras actividades. En consecuencia, el éxito del programa
depende de implementaciones exitosas repetidas y exige una planificación y supervisión
continuas de la transición según lo dispuesto por la administración del programa.
Gestión de riesgos e interfaces
La gestión de riesgos del programa implica identificar, evaluar y gestionar los riesgos a nivel de
programa . Un gran riesgo a nivel de programa es el “riesgo de interfaz”, es decir, el riesgo
causado por las interdependencias entre los proyectos componentes. Cada proyecto puede ser
el sucesor o predecesor de al menos otro proyecto y, por lo tanto, puede retrasarse o ser
retrasado por otros proyectos por falta de productos, información, servicios o recursos.
Abordar tales riesgos se denomina “gestión de interfaces”, lo que implica identificar interfaces
(entradas/salidas) entre proyectos y garantizar que los
los insumos necesarios para cada proyecto serán producidos (como productos) por al menos otro
proyecto, actividad o fuente externa. También implica la coordinación de los cronogramas de los
proyectos para que los productos de un proyecto estén disponibles según los necesiten otros
proyectos. Los administradores de programas tienden a no entrometerse en las actividades de proyectos individuales.
Ven los proyectos como cajas negras con entradas y salidas, y programan proyectos para dar cuenta
de sus interdependencias, cuándo se necesitan entregas o para dar tiempo a la organización a
absorber los cambios. La sincronización adecuada de los entregables a menudo se logra tratando
cada interfaz como un contrato: un acuerdo formal entre proyectos de interfaz sobre lo que cada uno
puede esperar de los demás. 37
Definición de trabajo
¿Cómo se define el trabajo en un programa? En un proyecto, a menudo el trabajo se define con una
EDT. ¿Se puede utilizar un enfoque similar para definir el trabajo del programa? La respuesta depende
del tipo de programa. En un programa de cartera, el trabajo del programa está en gran medida
"predefinido": es simplemente el trabajo definido para los proyectos individuales que componen el
programa. Los proyectos son en gran medida independientes, por lo que el trabajo del programa es
simplemente la suma del trabajo de los proyectos y otras actividades en la cartera.
Para un programa de mejora típico, el punto de partida es un plan a largo plazo (más de 5 años)
que especifica las metas, la dirección y las prioridades del programa. Periódicamente se agregan
proyectos al programa en función de su capacidad para adaptarse al plan y las necesidades
emergentes de la organización. Por lo tanto, el trabajo del programa se basa en cualquier proyecto
que se considere necesario para avanzar en las metas del programa; en muchos casos, como con un
programa de cartera, este es simplemente el trabajo definido de los proyectos seleccionados para el
programa.
Para un programa orientado a objetivos, la definición del trabajo es más desafiante ya que los
requisitos del objetivo del programa deben definirse y luego asignarse entre un conjunto de proyectos
por determinar. A menudo, el objetivo implica innovación o nueva tecnología y requisitos inciertos, por
lo que la planificación del programa se realiza de forma “incremental”; el conocimiento obtenido de
proyectos anteriores determina los próximos pasos
38
y futuros proyectos.
Esto es similar al proceso de planificación por etapas descrito en el Capítulo 4. Los principales
elementos de trabajo en un programa orientado a objetivos se pueden mostrar en un programa .
estructura de descomposición (PBS) que descompone el programa en "paquetes de programas".

Estos paquetes, los elementos de trabajo del programa, se convierten en la base para crear los
proyectos que constituirán el programa; a menudo, los paquetes definen uno o dos niveles
superiores de WBS para los proyectos.
Ver Capítulo 4
La planificación de programas orientados a objetivos y de mejora incluye la identificación de los

proyectos constituyentes del programa. Los gerentes de estos proyectos desarrollan un plan que
muestra las estimaciones de tiempo y recursos de cada proyecto y las interfaces con otros
proyectos; a partir de estos, el administrador del programa crea un resumen que resume el
trabajo, los cronogramas, las necesidades de recursos y las interfaces de todos los proyectos.
Esto le permite crear un cronograma a nivel de programa con fechas de hitos para los resultados
del programa y secuenciar proyectos para tener en cuenta las interdependencias de los proyectos y los recursos
restricciones
Una vez que el programa está en marcha, el administrador del programa realiza un seguimiento
del consumo de reserva, los gastos y otras medidas de desempeño para cada proyecto, busca
problemas potenciales y evalúa el impacto de cada proyecto sobre los demás y el programa en
general. Los métodos para hacer esto están cubiertos por las fuentes al final .
notas
adaptarse a los cambios en los hitos y los recursos a nivel del programa.
Cambio de control
Los cambios dentro de un proyecto que no afectan a otros proyectos o al programa son
manejados por gerentes de proyectos individuales; aquellos que afecten a otros proyectos o al
programa deben ser manejados por el administrador del programa. Al igual que el control de
cambios del proyecto, el control de cambios del programa es un proceso para evaluar las
solicitudes de cambio, aprobarlas o denegarlas y comunicar las acciones de seguimiento. Los
cambios requeridos o solicitados que emanan del exterior también deben ser evaluados por su
impactos en proyectos existentes y futuros, y los gerentes de los proyectos afectados notificados para
tomar las medidas apropiadas.
Dirección de Procuración
La mayoría de los programas son algo a largo plazo y, en consecuencia, también lo son las relaciones
con los contratistas y proveedores. Los contratistas a menudo participan en múltiples proyectos dentro
de un programa, en cuyo caso el énfasis de contratación cambia de cumplir con los requisitos
inmediatos a desarrollar relaciones y asociaciones a largo plazo basadas en las necesidades mutuas
del programa y los contratistas.
Conceptos erróneos de gestión de programas
La gestión de programas no debe confundirse con la gestión de proyectos múltiples, la gestión de

"megaproyectos" o la gestión de varios proyectos como si cada uno fuera un paquete de trabajo.
La gestión de múltiples proyectos se refiere a la gestión de un conjunto de proyectos que se basan

en fondos comunes de recursos. Los proyectos pueden no tener nada en común, sin embargo, deben
coordinarse y programarse para cumplir con sus objetivos individuales pero sin exceder las limitaciones
de recursos. Un propósito principal de la gestión de proyectos múltiples es permitir que los proyectos
individuales cumplan con sus propios plazos y objetivos, a diferencia de la gestión de programas,
donde el énfasis primordial está en cumplir los objetivos del programa.
A veces, un proyecto grande, un "mega" o "súper" proyecto, se gestiona más fácilmente si se divide
en varios subproyectos. Pero a menos que la gestión de los subproyectos de esta manera proporcione
beneficios (aparte de la facilidad de gestión) superiores a la suma de los beneficios de todos los
subproyectos, gestionar tal cosa sigue siendo gestión de proyectos, no gestión de programas.
Finalmente, los administradores de programas no pueden administrar los proyectos en un programa

de la misma manera que un administrador de proyectos administra los paquetes de trabajo en un
proyecto. Hay muchas razones por las cuales; Aquí hay dos: 1) Los gerentes de programa generalmente
no tienen autoridad para "controlar" los presupuestos y cronogramas del proyecto de la misma manera.
los gerentes controlan los paquetes de trabajo; y 2) no pueden usar una técnica como el valor
ganado para evaluar el progreso del programa, ya que dicho progreso se deriva de las
interdependencias del proyecto y es más que la suma de los proyectos componentes.
Progreso.
17.10 Resumen
Los primeros temas de este capítulo (madurez, metodología de gestión de proyectos, gestión
del conocimiento y la PMO) se encuentran en gran parte o totalmente más allá de la
responsabilidad y capacidad del director del proyecto, pero son críticos o al menos relevantes
para el éxito del proyecto.
La metodología de gestión de proyectos proporciona un marco y un conjunto de tareas
estructuradas, herramientas y técnicas para concebir, definir, planificar, programar, presupuestar,
seguir, controlar y cerrar proyectos. La metodología define las fases o etapas del proyecto y lo
que debe suceder durante cada una, incluidas las funciones y tareas del director del proyecto y
de otras partes interesadas del proyecto. Es el medio por el cual todos los proyectos de una
organización se gestionan y ejecutan de manera estandarizada, disciplinada y sistemática,
utilizando las mejores prácticas reconocidas.
La madurez de la gestión de proyectos se refiere a la capacidad o competencia de una
organización para gestionar proyectos, incluida la medida en que emplea una metodología y
métodos formalizados para la planificación y el control, la integración de múltiples proyectos y
la mejora continua. Una calificación alta en un modelo de madurez indica que una organización
ha logrado un alto nivel de estandarización en sus prácticas y procesos de gestión de proyectos.
Los proyectos son únicos y temporales, por lo que es fácil que las personas y las
organizaciones pierdan oportunidades de aprender de la experiencia del proyecto, olviden lo
que aprendieron o no apliquen lo aprendido a nuevos proyectos. Es necesario un proceso
formal de gestión del conocimiento para aprender de la experiencia del proyecto y retener y
compartir ese aprendizaje con otros. Las formas de aprender de los proyectos incluyen
revisiones: a mitad de camino, después de la finalización y después de la acción. Las formas
de retener y compartir el conocimiento de los proyectos incluyen listas de verificación, bases de
datos y otras formas de documentación (para el conocimiento explícito) y consultas entre pares,
grupos de apoyo de recursos del proyecto o consultores expertos en conocimiento (para el conocimiento tácito
La PMO es una unidad o departamento dedicado a mejorar la práctica de la gestión de
proyectos y apoyar a los directores de proyectos. La PMO establece y mantiene la metodología,
impulsa iniciativas para aumentar la madurez de gestión de proyectos de la organización y
gestiona el conocimiento del proyecto. se desarrolla
normas y procedimientos, y gestiona los recursos para los proyectos. La PMO brinda
capacitación, consultoría y tutoría, y ayuda en la planificación y el control integrados de
múltiples proyectos y la gestión de carteras.
La gestión de programas tiene como objetivo gestionar programas, que son una
colección de proyectos y otras actividades agrupadas para cumplir objetivos y proporcionar
una capacidad colectiva o beneficios más allá de los proyectos individuales. La gestión de
programas y la gestión de proyectos difieren en muchos aspectos, entre ellos: fases y
etapas del ciclo de vida, funciones y estructura de la organización, temas de énfasis y
métodos de iniciación, planificación, definición y control. En consecuencia, la gestión de
programas requiere herramientas y prácticas especialmente adecuadas para ese propósito.
1. ¿Cuáles son los beneficios de la metodología de gestión de proyectos? ¿Cuáles son las desventajas
de una organización que no tiene uno?
2. ¿Qué especifica la metodología de gestión de proyectos? ¿Qué aspectos de la gestión de proyectos
aborda la metodología? Discuta los tipos de tareas y entregables cubiertos en la metodología.
3. ¿Dónde se origina la metodología? ¿Quién lo crea y lo promueve?

4. ¿Cuál es el propósito de las puertas del proyecto? Describa dónde encaja el proceso de activación
en la metodología de gestión de proyectos.
5. ¿Por qué una organización podría tener más de una metodología? Qué son
los problemas de tener más de uno?
6. Analice el significado del término “madurez de la gestión de proyectos”.
7. ¿Qué miden o qué miden los modelos de proceso de madurez de gestión de proyectos?
¿evaluar?
8. Enumere cinco niveles de madurez de gestión de proyectos.

9. Mencione los beneficios de que una organización obtenga una calificación alta en un modelo de
madurez de gestión de proyectos.
10. ¿Qué aspectos críticos para la gestión eficaz de proyectos ignora el modelo de madurez?
11. En una oración, ¿cuál es el propósito de la gestión del conocimiento en la gestión de proyectos?
12. Describa algunas formas de capturar el conocimiento del proyecto.

13. ¿Cuál es la diferencia entre conocimiento tácito y conocimiento explícito?
14. Mencione algunas dificultades asociadas con retener y compartir (transferir) el conocimiento tácito.
15. ¿Qué tipo de conocimiento no se puede retener en una base de datos? Donde es eso
conocimiento que se encuentra?
16. ¿Qué es una revisión posterior a la acción? ¿En qué se diferencia de una revisión posterior a la
finalización?
17. ¿Cómo se utiliza la consulta entre pares en el intercambio de conocimientos?
18. ¿Qué responsabilidad tiene el director del proyecto para el proyecto?

¿conocimiento administrativo?
19. ¿Cuál es el propósito general de la oficina de gestión de proyectos (PMO)?
20. ¿Cuál es el papel de la PMO con respecto a cada uno de los siguientes:
una. metodología de gestión de proyectos

b. política, procedimientos y estándares de gestión de proyectos c.
gestión de recursos del proyecto d. proyecto de software y tecnología
de comunicaciones e. mentoría, consultoría y gestión del
conocimiento f. competencia del director de proyecto g. junta de
revisión de proyectos (o junta de gobierno o dirección de proyectos)
comité).
21. ¿Cómo se inicia y crece una PMO típica? Describa el papel de los gerentes de proyecto
en el inicio y la gestión de la PMO.
22. ¿En qué se diferencian los programas y los proyectos?
23. Explique los cuatro temas de la gestión de programas.

24. Explicar las fases del programa de inicio, definición, ejecución del proyecto, renovación
y cierre del programa.
25. Explique los siguientes roles dentro de la estructura del programa: patrocinador, junta
de gobierno, director, gerente de cambios comerciales, oficina de gestión del programa,
gerente del programa y oficina del programa.
1. ¿El proyecto siguió una metodología formal establecida? Si es así, descríbalo.

¿Cuál es la opinión del director del proyecto y del personal del proyecto en
cuanto a la eficacia de la metodología? ¿Dónde se originó la metodología?
2. Si no existía una metodología formal, ¿el director del proyecto usó su propia
metodología informal? Si es así, ¿cuál fue? ¿Fue efectivo?
3. ¿Cuál es su opinión sobre la madurez de la gestión de proyectos de esta
organización? ¿Es la organización madura o algo inmadura?
4. ¿Se hizo algo para capturar el conocimiento en este proyecto? ¿Se tomaron
medidas para retener este conocimiento para su aplicación y transferencia a
otros proyectos?
5. Entre los métodos de gestión del conocimiento descritos en este capítulo,
¿cuáles se practicaron en este proyecto? ¿Cómo se comparte el conocimiento
en la organización?
6. ¿La organización tiene una PMO? Si es así, ¿cuáles son sus funciones? ¿Cómo
fue visible el papel de la PMO en este proyecto? En su opinión, ¿la PMO ayudó
o entorpeció al gerente del proyecto? Explique.
7. ¿Fue el proyecto parte de un programa más grande? Si es así, trate de responder a las preguntas.
24 y 25 anteriores sobre el programa.
Caso 17.1 Maxim Corporation América (MCA)
Maxim Corporation es un proveedor líder de servicios de gestión de riesgos,

corretaje de seguros y suscripción de seguros especializados. Con una base de
empleados de más de 50 000 personas en 600 oficinas en más de 100 países, la
corporación tiene una visión amplia de la industria de seguros y aprovecha su
experiencia en cientos de disciplinas en todo el mundo.
Operaciones de TI y PMO
El departamento de operaciones de TI de la división de EE. UU. se encuentra en la

sede corporativa de Maxim Corporation America. Anteriormente, el departamento
tenía más de 1200 empleados y era responsable del 80 por ciento de todos los
proyectos de TI de MCA (el otro 20 por ciento iba a consultores); manejó tres tipos
de proyectos: estratégicos, de infraestructura y de aplicaciones de clientes.
En 2009, el departamento de ITO estableció una PMO para supervisar proyectos
de infraestructura. La oficina constaba de un director, personal de apoyo y diez
gerentes de proyecto. El director reportaba al Director de Tecnología (CTO), quien
reportaba al Director de Información Global (CIO). La función principal de la PMO era
asignar gerentes a proyectos de infraestructura y realizar un seguimiento de los
proyectos. En un momento dado, se estaban realizando alrededor de 30 proyectos
de infraestructura y muchos más en consideración.
Metodología de PM
Una de las primeras iniciativas del director de la PMO fue desarrollar una
metodología de gestión de proyectos con la ayuda de sus directores de proyectos
más experimentados. La metodología o marco de gestión de proyectos (PMF)
especifica las fases prescritas del proyecto, la documentación y las puertas que
cubren todos los aspectos del ciclo de vida del proyecto, desde el inicio del
proyecto hasta la aprobación de la finalización y la revisión post mortem. Se cree
que es bastante bueno: riguroso pero no burocráticamente engorroso.
Servicios de la Oficina de Gestión de Proyectos
La PMO hizo cumplir la metodología y ayudó a los gerentes de proyecto en su uso

a través de capacitación y entrenamiento. Además de esto, realizó cursos sobre
temas como comunicación de proyectos y habilidades de liderazgo, convocó
reuniones para que los gerentes de proyectos discutieran sus proyectos y patrocinó
seminarios. Creó plantillas y formularios para reflejar las lecciones aprendidas de
los proyectos completados, y dispuso que los gerentes de proyectos fueran
asesorados y asesorados por gerentes de proyectos experimentados.
Gestión de la cartera
Además, la PMO ayudó a la Junta de Revisión de Proyectos en la selección de
proyectos propuestos y la evaluación de proyectos en curso. El PRB es un comité de
10 a 12 gerentes que incluye el CIO global, el CTO, el director de la PMO, el
vicepresidente de finanzas y los gerentes sénior con responsabilidad presupuestaria
para los proyectos actuales y propuestos. La PMO se aseguró de que se completara
la documentación especificada en el PMF para cada proyecto y se obtuvieran las
firmas antes de cada entrada. También evaluó el desempeño relativo de los proyectos
para permitir que el PRB decida cuál aprobar, retener o matar en las puertas.
Reevaluación de las operaciones de TI
A fines de 2010, los consultores recomendaron que si MCA externalizaba todas las
operaciones de infraestructura de TI, ahorraría entre 30 y 50 millones de dólares al
año. MCA respondió rápidamente y en junio de 2011 había subcontratado todas sus
operaciones de infraestructura de TI a CorCom, un gran contratista de TI. CorCom
tenía una reputación de disciplina operativa, gestión sólida de proyectos y buenos
informes. Tenía una PMO interna para supervisar los proyectos, incluidos los que
había adquirido de MCA. De las 600 personas en operaciones de TI en MCA que
originalmente trabajaban en proyectos de infraestructura, CorCom contrató a 480.
PMO de TI hoy
Se retuvo al director de la PMO de MCA, pero su unidad se redujo a cuatro gerentes de
proyecto y un especialista en soporte, principalmente para supervisar tareas asociadas con

la subcontratación de proyectos de TI y el inicio y factibilidad de proyectos de TI. El papel
educativo de la PMO se ha visto disminuido y su oferta de cursos se ha reducido
considerablemente. La PMO realiza cursos para familiarizar al personal de CorCom con el
PMF de MCA, pero ha dejado de brindar servicios de tutoría y entrenamiento.
Un problema observado desde la subcontratación de la infraestructura de TI es que

CorCom no se involucra en un proyecto hasta después de haberlo definido.
Mientras que en el pasado los gerentes de proyecto de MCA estaban involucrados durante
la concepción del proyecto y la definición de requisitos, los gerentes de proyecto de CorCom
no están involucrados hasta después de la aprobación y definición del proyecto. La postura
de los gerentes de CorCom es: "Díganos exactamente lo que quiere y se lo entregaremos".
Esto contrasta con la vieja forma de “Permítanos ayudarlo a definir sus necesidades y
requisitos, y sugerirle las mejores alternativas”. Los gerentes de proyecto de CorCom no
tienen voz en la definición de los requisitos que deben cumplir. La preocupación de algunas
unidades de MCA es que esta falta de interacción temprana entre el usuario y el desarrollador
impide una identificación completa de las necesidades del cliente. Pero es demasiado pronto
para saber si esta preocupación es algo más que una percepción.
El director está convencido de la importancia continua de la PMO de TI.
Ha programado una reunión con el CIO global para analizar el futuro de la PMO.
Preguntas
1. ¿Tiene futuro la PMO de TI de MCA? ¿Qué papel, si es que tiene alguno, puede
¿retener? ¿Puede ayudar en la interacción usuario-desarrollador?
2. ¿Cómo se compara el papel del director de la PMO con el del vicepresidente de proyectos?
ilustrado en la Figura 14.8 y el director de la PMO discutido en el Capítulo 15?
'
Caso 17.2 Motorola s Metodología M-Gate y
el proyecto razr40
Motorola emplea la siguiente metodología de proyecto de 16 etapas llamada M

Puerta:
Concepto de idea M15 Libro de contratos M7
MM Concepto Aceptar Preparación de diseño M6

Selección de solución M13 Preparación para la prueba del sistema M5
Cartera M12 Aceptar M4 listo para prueba de campo

Bloqueo de solución M11 M3 listo para introducción controlada
Inicio del proyecto M10 Implementación de volumen M2
Línea base de requisitos del sistema M9 Plan de Retiro M1 Aprobado
Requisitos del sistema M8 asignados M0 Fin de vida
La metodología corresponde aproximadamente a un ciclo de vida del producto de cinco fases:
M15 M14 M10 M9 M8 M7

M12 M11 M5 M4 M3 M2 M1 M0
M13 M6
Negocio portafolio Proyecto Lanzamiento de la implementación y

Caso Planificación Definición Cerrar
Cada etapa especifica los criterios de entrada y salida, los requisitos de gestión y tareas, y
los participantes y partes interesadas clave. El proceso completo incluye cinco puertas de
"pasar/no pasar" en las que se debe probar la viabilidad de un producto para que el proyecto
sobreviva.
La metodología M-Gate enfatiza la calidad del producto y las necesidades del cliente, pero
fue creada antes de la era de los teléfonos celulares omnipresentes. Produjo algunos éxitos
bien conocidos, pero al ritmo de un caracol cada 3 o 4 años. Los escenarios y las puertas
reducen el riesgo y aumentan la calidad, pero también desalientan las nuevas ideas y retrasan
el lanzamiento del producto, grandes inconvenientes en el ferozmente competitivo mercado de
teléfonos portátiles.
De hecho, el largo proceso inicialmente eliminó el concepto RAZR que se convertiría en el
teléfono más popular de Motorola en una década. Impuso iteraciones engorrosas de
investigación de mercado y requisitos obligatorios que entraban en conflicto con los objetivos
de diseño de RAZR. La investigación de marketing de Motorola mostró que los tamaños de los
teléfonos estaban aumentando, pero RAZR apuntaba a lo contrario: ser lo más delgado posible
(como una navaja). Como regla general, los diseñadores de productos debían incorporar
cualquier característica que desearan los clientes de su compañía inalámbrica, aunque para
RAZR pensaron que era mejor excluir a los clientes en aras del secreto. Solo gracias a la
persistencia de un cuadro dedicado de ingenieros se aprobó el proyecto. Gracias a los
partidarios de alto nivel, la gerencia le permitió a RAZR la libertad de operar como un zorrillo:
un pequeño equipo muy unido, que trabaja en el más alto secreto y en gran medida según sus
propias reglas.
Para el proyecto RAZR, las etapas M15 y M14 se reemplazaron con un proceso más
adecuado para productos innovadores. En términos del método de selección de embudo
descrito en el Capítulo 18 (Figura 18.3b), el proceso comienza con conceptos de productos
seleccionados y priorizados que fluyen desde el extremo estrecho del embudo. Los conceptos
pasan entonces por cinco etapas:
Ver Capítulo 18
• Etapa 1: Elaborar una breve propuesta técnica para cada concepto de producto.
• Etapa 2: Categorizar las propuestas. •

Etapa 3: Desarrollar un plan de recursos para convertir cada concepto en un
prototipo.
• Etapa 4: construir un prototipo para demostrar el concepto a los gerentes
y grupos de productos; matar los conceptos mal recibidos.
• Etapa 5: Transfiera los conceptos sobrevivientes al equipo de planificación de cartera
para ingresar a una cartera de productos de varios años (ingrese al proceso M-Gate
en la etapa M12).
Tan pronto como se lanzó el teléfono RAZR, se convirtió en un éxito inmediato, vendiendo más
de 110 millones de unidades en 4 años e impulsando a Motorola al segundo lugar en el mercado
de teléfonos celulares después de Nokia. En 2008 , PC World clasificó al RAZR en el puesto
número 12 en Los 50 mejores dispositivos de los últimos 50 años.
Preguntas
1. ¿Por qué fue necesario que el equipo RAZR trabajara fuera de la metodología M
Gate? ¿En qué situaciones podría ser necesario trabajar o modificar una
metodología existente?
2. ¿Cuáles son los posibles inconvenientes de permitir que los proyectos se desvíen?
de la metodología?
Caso 17.3 Compañía Tecknokrat
La empresa de consultoría de software Tecknokrat Company tiene 18 gerentes de proyecto,

muchos de los cuales comenzaron como analistas y desarrolladores de sistemas cuando se
fundó la empresa en 1977.
Tecknokrat tiene una buena reputación en términos de productos y servicios de calidad,

pero recientemente ha visto caer su negocio y sus ganancias porque muchos de sus proyectos
se completan tarde y por encima del presupuesto. Para revertir la tendencia, la firma contrató
a Drago Kovacic, un gerente de proyecto que había sido director de TI de la PMO en un
banco. El mandato de Drago es ayudar a los gerentes de proyectos a mejorar el cronograma
del proyecto y el desempeño del presupuesto.
En sus primeras dos semanas en Tecknokrat, Drago entrevistó al proyecto
gerentes y los observaron en la práctica. Señaló lo siguiente:
• Todos tienen su propia forma de hacer las cosas. No hay prescripciones sobre cómo
gestionar proyectos. • Todos trabajan en la misma oficina pero rara vez interactúan.
Nadie sabe
mucho sobre lo que los demás están haciendo.
• Algunos de los gerentes parecen antagónicos entre sí. • Algunos parecen

estar compitiendo entre sí. • No hay tutoría. Los veteranos sienten: todo lo
que sé lo tuve que aprender a través de la experiencia; los nuevos tienen que hacer
eso también.
Indagando más, descubrió algunas políticas curiosas de la empresa:
• Al final del año, los "mejores" gerentes de proyecto en términos de cumplimiento de

cronogramas y presupuestos reciben premios: el mejor recibe $20 000, el segundo
mejor $10 000, el tercero $5 000. Todos los años, desde que cualquiera puede
recordar, las mismas cuatro o cinco personas han ganado los premios; todos ellos
llevan más de 20 años en la empresa.
• La empresa utiliza la educación como incentivo. Por cada proyecto que supere las
metas o reciba elogios del cliente, el gerente puede asistir a un seminario empresarial
local de su elección. El incentivo tiende a ir a un pequeño grupo de gerentes que, no
por casualidad, incluye al mismo grupo que recibe los premios en dólares de fin de
año.
El propósito aparente de los premios e incentivos es estimular a los gerentes a hacer un mejor
trabajo en términos de cumplir con las metas del proyecto.
Preguntas
1. Según las observaciones de Drago, ¿cuáles cree que son los principales
problemas en la gestión de proyectos de Tecknokrat?
2. ¿Qué opinas de los premios e incentivos? ¿Por qué no han tenido el efecto
deseado?
3. ¿Qué debe hacer Drago? ¿Qué dificultades es probable que encuentre?
Caso 17.4 Programa de Exploración de Mercurio41
Un ejemplo de gestión de programas y proyectos en la NASA es el Programa de

Exploración de Mercurio (MEP) hipotético para enviar una serie de tres sondas
espaciales de sobrevuelo al planeta Mercurio. Todos los grandes programas espaciales
de la NASA se dividen en dos fases, Formulación e Implementación,
42
aunque los detalles de las fases varían según el tipo de programa.
Los proyectos también se dividen en fases, que también difieren según el tipo de
proyecto. El MEP constaba de varios proyectos, incluido uno para cada una de las tres
sondas espaciales "Cosmic". Estos proyectos se dividieron en cuatro fases: A,
conceptualización; B, diseño preliminar; C, diseño final y fabricación; y D, lanzamiento
y operación (Figura 17.7).
figura 17.7 Programa de Exploración de Mercurio y proyectos Cósmicos; no se muestran varios otros soportes
proyectos y actividades del programa. El plazo del programa es de 10 a 15 años.
Uno de los objetivos a largo plazo de la NASA es recopilar y analizar datos sobre los
planetas del sistema solar. El MEP se inició cuando los científicos de la NASA instaron al
director del Centro de Vuelo Espacial Goddard y al director de Programas Planetarios en
la sede de la NASA a aprobar un estudio de viabilidad para enviar sondas a Mercurio
para realizar mediciones geofísicas. El estudio, que inició la fase de Formulación del
MEP, estaría dirigido a determinar si el programa debe emprenderse y, de ser así,
determinar el curso técnico de acción y preparar un plan de programa. El director de
Goddard nombró un equipo de estudio de científicos e ingenieros de la NASA.
Además de investigar enfoques técnicos potenciales para la misión y seleccionar uno, el

equipo identificó desarrollos tecnológicos y actividades de apoyo necesarias para que el
programa tenga éxito, creó una estructura de gestión del programa, desarrolló requisitos
de programa de alto nivel y preparó estimaciones preliminares de costos y cronograma.
La gerencia de la NASA había seleccionado un líder de equipo para supervisar el

estudio de factibilidad y un oficial de enlace para coordinar el estudio con la sede de la NASA.
Entre los requisitos para el oficial de enlace estaban la formación técnica adecuada y una
personalidad que asegurara una relación de trabajo fluida con el director de Goddard y el
líder del equipo de estudio. Si se aprueba el programa, esta persona se convertiría en el
gerente del programa y el líder del equipo de estudio se convertiría en el gerente del
proyecto.
Con base en el estudio de factibilidad, el líder del equipo de estudio y el enlace
El oficial redactó una propuesta de proyecto y un documento de aprobación (PAD) para

la Fase A, conceptualización, de la sonda espacial, llamada "Cósmica". El documento
describía los recursos y limitaciones del proyecto, estimaba la cantidad de sondas
espaciales y el tipo de vehículo de lanzamiento necesarios, y asignaba fondos y mano de obra.
El oficial de enlace coordinó la obtención de todas las aprobaciones necesarias de
varias divisiones y oficinas centrales de la NASA.43
Tras la aprobación del PAD, se autorizó al MEP a pasar a la fase de Implementación
y Cosmic I, la primera sonda espacial, a la Fase A. El oficial de enlace fue nombrado
formalmente director del programa y el líder del equipo de estudio fue nombrado director
del proyecto de Cosmic I. La principal responsabilidad del administrador del programa
sería facilitar todas las revisiones y decisiones de MEP y Cosmic en la sede de la NASA,
coordinar el trabajo con otras agencias gubernamentales y promover los intereses del
programa dentro y fuera de la NASA. El puesto de director de programa liberó al director
de proyecto de la mayor parte del trabajo de enlace con la sede y otras agencias y
proporcionó un "amigo" en la sede para eliminar obstáculos y proporcionar los recursos
necesarios y la ventaja al tratar con otras unidades de la NASA.
El director del proyecto reunió a un equipo para desarrollar especificaciones para los
contratistas. (En la NASA, la mayoría del "trabajo" real del proyecto, por ejemplo, diseño,
construcción y lanzamiento de naves espaciales, lo realizan contratistas. Por ejemplo,
en su apogeo, el programa lunar Apolo requirió el apoyo de unos 20,000 contratistas).
El equipo preparó cronogramas y los requisitos de recursos estimados y las relaciones
establecidas con la NASA y sus equipos de contratistas responsables de las principales
áreas del proyecto, como el vehículo de lanzamiento, la confiabilidad, la adquisición de
datos y las operaciones de lanzamiento. Eligió los experimentos que se realizarían en
las misiones y determinó que se requerirían tres misiones de naves espaciales; además
de Cosmic (ahora llamado Cosmic I) estarían Cosmic II y Cosmic III; cada uno constituiría
un proyecto. La Fase A concluyó con un plan de proyecto preliminar que especificaba
los requisitos técnicos del proyecto, los requisitos de lanzamiento y seguimiento, la
mano de obra y los fondos necesarios, y los cronogramas e hitos para cumplir con los
objetivos del proyecto.
El plan fue aprobado por la gerencia en Goddard y la sede de la NASA; en efecto, se
convirtió en el contrato entre la oficina del programa y Goddard. A partir de entonces, el
director del proyecto Cosmic I envió informes semanales
al gerente del programa, y el gerente del programa trabajó rápidamente para resolver
cualquier inconveniente que requiriera la sede u otras unidades de la NASA. Por
ejemplo, cada vez que surgía un problema que requería investigación, el director del
programa iniciaba la obtención de los fondos para apoyar la investigación.
El documento PAD para la Fase A se actualizó continuamente y se convirtió en los
documentos PAD para las Fases B, C y D. Al pasar a la Fase B, el proyecto Cosmic I
apareció en el sistema de información de la NASA para informar y controlar el progreso
técnico, financiero y de programación. .
En la Fase B, diseño preliminar, el equipo del proyecto completó el desarrollo de
tecnología y la creación de prototipos de ingeniería, y finalizó el diseño preliminar de
la sonda espacial Cosmic I y los sistemas de apoyo. Seleccionó el vehículo de
lanzamiento para las tres misiones, el cohete Atlas IX y una plataforma común para
las tres sondas. Cada sonda sería única, pero todas estarían construidas sobre esta
plataforma y utilizarían equipos comunes de navegación, comunicación y control; esto
ayudaría a ahorrar costos del programa.
El equipo también revisó el plan de referencia del proyecto y validó que todos los
presupuestos y cronogramas del proyecto estuvieran completos y fueran adecuados
para el riesgo anticipado, que el diseño preliminar cumpliera con los requisitos y que
el proyecto estuviera lo suficientemente maduro para pasar a la Fase C. Una vez que
la sede central aprobó el plan el proyecto entró en la Fase C.
Durante la Fase C, el diseño final y la fabricación, los contratistas crearon diseños
de ingeniería detallados, maquetas y especificaciones para todos los subsistemas
principales de la sonda Cosmic I. El equipo del proyecto seleccionó contratistas (a
través de un proceso de propuesta RFP similar al descrito en el Ejemplo 3.8, Propuesta
para la nave espacial Apolo) para diseñar, fabricar y probar la sonda espacial, el
cohete Atlas y los sistemas operativos. El equipo trabajó con científicos cuyos
experimentos se realizarían en las sondas, ingenieros que preparaban cohetes para
las tres misiones, ingenieros en el Cabo Kennedy donde se realizarían los lanzamientos
y científicos en el Laboratorio de Propulsión a Chorro donde se adquirirían los datos
de las sondas espaciales después del lanzamiento.
A lo largo de la Fase C, los directores de proyectos y programas participaron en
numerosas revisiones formales de proyectos. Visitaron las plantas de los contratistas
y participaron en reuniones para revisiones de diseño y pruebas, control de calidad e
integración de sistemas. El gerente del programa supervisó el progreso del proyecto,
escribió informes que respaldaban el presupuesto anual del programa y mantuvo el

programa "vendido" en la sede de la NASA ya los comités del Congreso.
La fase D, lanzamiento y operación, comenzó nominalmente cuando se lanzó la
nave espacial Cosmic I. El gerente del proyecto supervisó a todos los que trabajaron
en esta fase, incluido el equipo de lanzamiento, los gerentes de los proyectos y
programas asociados de la NASA, los científicos cuyos instrumentos estaban en la
sonda espacial, los contratistas que construyeron la sonda y el cohete Atlas, y el
equipo de la Fuerza Aérea que controla el misil. rango. Durante la cuenta regresiva
antes del lanzamiento, solo el gerente del proyecto tenía la autoridad para tomar la
decisión final e irrevocable de "ir".
Los datos se registraron entre el despegue del cohete y la colocación exitosa de la
sonda espacial en una trayectoria hacia Mercurio, y se analizaron los problemas para
evitar repeticiones en la siguiente sonda, Cosmic II. Una vez que la comunicación y la
instrumentación en Cosmic I estaban funcionando de manera verificable y devolviendo
datos utilizables, el gerente del programa centró su atención en Cosmic II, ahora en la
etapa de Fase C. Continuó monitoreando la operación de Cosmic I para que las
lecciones aprendidas se aplicaran para mejorar el diseño de Cosmic III, que para
entonces estaba en la Fase B.
Preguntas
1. ¿Por qué el MEP fue un “programa” y no un “proyecto”?

2. ¿Cuáles son los proyectos diferenciables con el MEP? Algunos se nombran en este
caso, pero ¿qué otros podrían haber?
3. ¿Quiénes son las partes/partes interesadas en el “equipo del proyecto/programa”?
4. ¿Qué se debe “coordinar” entre los proyectos y las partes interesadas?
5. El programa incluye tres misiones a Mercurio. ¿Qué era común a todos ellos? ¿Qué
era único para cada uno? ¿De qué manera los proyectos fueron interdependientes?
6. Describa el rol del director del proyecto. Describa el rol del administrador del programa.
¿Por qué una persona no podría desempeñar ambos roles en este programa?
7. El caso ilustra el proceso de puerta de fase. ¿Cuáles son las fases y las puertas? ¿Por
qué cree que el programa se gestiona de esta manera?
Notas finales
1. Lenguaje común, procesos, metodología, benchmarking y mejora continua son los cinco
niveles de madurez definidos por Kerzner H. en Planificación Estratégica para la Gestión de Proyectos usando un Proyecto
Modelo de Madurez Gerencial. Nueva York, Nueva York: Wiley; 2001.
2. Jugdev K. y Thomas J. Modelos de madurez de gestión de proyectos: las balas de plata de la competencia
¿ventaja? Revista de gestión de proyectos, 33(4); 2002: 4–14.
3. Cooke-Davies T., Schlichter J. y Bredillet C. Más allá de la Guía del PMBOK. Actas del 32
Instituto Anual de Gestión de Proyectos, 2001 Seminarios y Simposio. Newton Square, Pensilvania: Proyecto
Instituto de Gerencia.
4. Jugdev K. y Thomas J. Modelos de madurez de gestión de proyectos.
5. Una guía para el conocimiento de la dirección de proyectos (Guías del PMBOK), 5.ª ed. Newton Square, Pensilvania:
Instituto de manejo proyectos; 2013.
6. Kwak Y. e Ibbs C. Modelo de madurez del proceso de gestión de proyectos (PM)2 (Modelo de PM de Berkeley),
www.ce.berkeley.edu/~ibbs/yhkwak/pmmatrutiy.htmel; véase también Crawford J. Gestión de proyectos
Modelo de madurez: proporciona un camino comprobado hacia la excelencia en la gestión de proyectos. Nueva York, Nueva York: Marcel
Dekker; 2002.
7. Ibbs C. y Kwak Y. Evaluación de la madurez de la gestión de proyectos. Revista de gestión de proyectos 31(1); 2000:
32–43; PMI. Modelo Organizacional de Gestión de Proyectos. Newton Square, Pensilvania: Gestión de proyectos
Instituto; 2003.
8. Milosevic D. y Patanakul P. La gestión de proyectos estandarizada puede aumentar el proyecto de desarrollo
éxito. Revista Internacional de Gestión de Proyectos 23; 2005: 181-192.
9. Pennypacker J. y Grant K. Madurez de la gestión de proyectos: un punto de referencia de la industria. Gestión de proyectos
Revista 34(1); 2003: 4–11.
10. Skulmoski G. Madurez del proyecto e interfaz de costos. Ingeniería de Costos 43(6); 2001: 11–18.
11. Cooke-Davies T. y Arzymanow A. La madurez de la gestión de proyectos en diferentes industrias: una
investigación de las variaciones entre los modelos de gestión de proyectos. Revista Internacional de Proyectos
Gestión 21; 2003: 471–478; Pennypacker y Grant, Madurez de la gestión de proyectos: una industria
punto de referencia; Crawford L. Percepciones de la alta dirección sobre la competencia en gestión de proyectos.
Revista Internacional de Gestión de Proyectos 23; 2005: 7-16.
12. Crawford L. Percepciones de la alta dirección sobre la competencia en gestión de proyectos.
13. Jugdev y Thomas, Modelos de madurez de gestión de proyectos. Un ejemplo de un estudio de la industria está en Nieto
Rodriguez A. y Evrard D. Una primera encuesta global sobre el estado actual de madurez de la gestión de proyectos
en organizaciones de todo el mundo. Precio Waterhouse Cooper; 2004.
14. Jugdev y Thomas, Modelos de madurez de gestión de proyectos.
15. Esta sección se basa en información de entrevistas con gerentes de proyecto y directores de PMO en 11
organizaciones: Doug Brandt (Abbott Laboratories); Jacki Koehler (ABN-Amro); Ruta Kulbis (Accenture);
Pozos de acebo (Aon); Carson Neally, Jim Yeck, Robert Wunderlick y Jeff Roberts (Argonne National
Laboratorio); Douglas Gilman, Joe Wolke y Eileen Will (Junta de Comercio de Chicago); Martín testamentos
(Recursos de información, Inc.); Cynthia Reyes (Nicor); Thomas Foley (Sears Corzo); Gurran Gopal (Tellabs); y Carol Bobbe
(TransUnion).
16. Shenhar A. y Dvir D. Reinventar la gestión de proyectos: el enfoque de diamante para un crecimiento exitoso
e Innovación. Boston, MA: Prensa de la Escuela de Negocios de Harvard; 2007.
17. O'Dell C. y Jackson Grayson C. Si tan solo supiéramos lo que sabemos. Nueva York, Nueva York: Prensa libre; 1998.
18. Argote L. Aprendizaje organizacional: creación, retención y transferencia de conocimiento. Boston, Massachusetts:
Editores académicos de Kluwer; 1999.
19. Dixon N. Conocimiento común: cómo prosperan las empresas compartiendo lo que saben. Boston, Massachusetts:
Prensa de la Escuela de Negocios de Harvard; 2000.
20 Ernst & Joven. Conocimiento Administración.
http://www.ey.com/global/content.nsf/Middle_East/Knowledge_Management_-_Tools, descargado en abril
13, 2007.
21. Guía del líder para la revisión posterior a la acción (TC 25-20), Departamento del Ejército de EE. UU.; 1993.
22. Dixon, Common Knowledge, págs. 77–79, 81–82.
23. Ernst & Young. Conocimiento administrativo; Biblioteca Nacional de Salud, Gestión del Conocimiento
Biblioteca de Especialistas, Peer Assist; http:/www.library.nhs.uk/knowledgemanagement/ViewResource.aspx?
resID=125167, descargado el 14 de abril de 2007,
24. Otros ejemplos proporcionados por ibid, pp. 103–104, y Welch N. Peer Assist Overview,
http://003cce4.netsolhost.com/PeerAssit.htm, consultado el 12 de abril de 2007.
25. O'Dell y Grayson, Si tan solo supiéramos lo que sabemos, págs. 51–52.
26. Cumsumano M. y Selby R. Microsoft Secrets. Nueva York, Nueva York: Prensa libre; 1995, pág. 243.
27. Fuentes: ver nota 15.
28. Pellegrinelli S. Gestión de programas: Organización del cambio basado en proyectos. Revista Internacional de
Gestión de proyectos 15(2), 1997, 141–149; PMI. El Estándar para la Gestión de Programas, 3.ª ed.,
Newton Square, Pensilvania: Instituto de Gestión de Proyectos, 2013.
29. Ibíd., Pellegrinelli.
30. Thiry M. Gestión de programas. Dorchester, Reino Unido: Gower; 2010, pág. 39.
31. Pellegrinelli, Gestión de programas.
32. El Estándar para la Gestión de Programas.
33. Thiry, Gestión de programas, págs. 59–63.
34. Ibíd., 77
35. La Norma para la Gestión de Programas; Thiry, págs. 83–88.
36. Hanford M. Gestión de programas: diferente de la gestión de proyectos. desarrollador,
http://www.ibm.com/developerworks/rational/library/4751.html Descargado el 22 de diciembre de 2014.
37. Kendrick T. Identificación y gestión del riesgo del proyecto. Nueva York: Amacom; 2003, págs. 99 y 100.
38. Op cit., Pellegrinelli.
39. Milosevic D. y Martinelli R. Gestión de programas para mejorar los resultados empresariales. Nueva York: Wiley;
2007; Thiry, Gestión de programas.
40. Caso derivado de: McQuellon R., Pini L., Benedicata M., Mjavanadze D., Madura S., Grzybowski M. y
Proyecto Velasco M. Razr. Escuela de Graduados en Negocios, Universidad Loyola de Chicago; febrero de 2007;
La ventaja de Lashinsky A. RAZR: cómo un equipo de ingenieros y diseñadores desafió las propias reglas de Motorola para crear
un celular que revivió la empresa. Fortuna, 1 de junio de 2006; Sitio web de Gizmodo , Motorola Insider Blame
Juego: Los ingenieros empujaron a los diseñadores a un lado, B. Koerner, http://gizmodo.com/5038839/motorola-insider
culpa-juego-ingenieros-empujados-diseñadores-aparte, consultado el 24 de agosto de 2010.
41. Caso basado en Chapman R. Project Management in NASA: The System and the Men. NASA, SP–324
Washington DC; 1973, págs. 13–19.
42. Manual de gestión de proyectos y programas de vuelos espaciales de la NASA. NASA/SP-2014-3705. Washington,
CORRIENTE CONTINUA: NASA Sede, Septiembre 2014.
http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20150000400.pdf. Descargado el 20 de julio de 2015.

43. Las aprobaciones de programas y proyectos ocurren a lo largo y al final de las fases de la NASA e involucran un
complicado proceso de revisión; el “PAD” descrito aquí es una versión mucho más simplificada del proceso.
capitulo 18
Selección y Portafolio de Proyectos
administración
Los lirios que se pudren huelen mucho peor que las malas hierbas.
—Shakespeare, Sonetos
Los errores, como pajas, fluyen sobre la

superficie; El que quiera buscar perlas debe sumergirse debajo.
—John Dryden
Este capítulo está dirigido a cualquiera que se pregunte cómo las empresas eligen proyectos.
En muchas empresas; los gerentes de proyecto no participan en la selección o aprobación
de proyectos; simplemente, se asignan a proyectos ya elegidos por otra persona. Sin
embargo, en ocasiones, especialmente en las empresas más pequeñas, los directores de
proyectos ayudan en la selección de proyectos; ayudan a elegir los proyectos que ellos u
otros administrarán.
Los proyectos son los medios por los cuales las organizaciones persiguen sus objetivos
estratégicos, por lo tanto, hacer los proyectos correctos es fundamental para el éxito de su
negocio. Si los objetivos de una organización son “ser el líder en costes bajos”, “ampliar la
cuota de mercado en Europa” o “preservar el medio ambiente natural”, esperaría que la
mayoría de sus proyectos estuvieran dirigidos a esos objetivos.
Pero a menudo ese no es el caso. En muchas empresas, los proyectos tienen poco que ver con los
objetivos estratégicos y, en cambio, representan intereses a corto plazo, oportunidades fáciles de
aprovechar o las agendas de unas pocas personas. Los proyectos de "caballo de batalla" de los altos
ejecutivos obtienen el estatus de vaca sagrada a pesar de los beneficios cuestionables y acaparan
recursos de proyectos de evidente mayor valor comercial.
Un estudio de 35 empresas predominantemente norteamericanas reveló un gasto relativamente
bajo en proyectos que contribuyen a los objetivos de la empresa. 1 En general, los recursos
de los proyectos estaban muy dispersos porque las empresas tenían demasiados proyectos y no
tenían una forma sistemática de priorizarlos. La mayoría de los proyectos eran “frutos al alcance de la
mano”, relativamente fáciles de hacer pero que ofrecían pocos beneficios comerciales; dichos proyectos
desperdician recursos y privan a una empresa de oportunidades comerciales.
18.1 Gestión de la cartera de proyectos
Una cartera de proyectos es un grupo de proyectos y programas dirigidos a objetivos

estratégicos que comparten recursos y compiten por la financiación. Cada cartera respalda
un tema, por ejemplo, un objetivo estratégico, una línea de productos, una unidad de
negocios, un mercado o un área geográfica de operación. Cualquier programa o proyecto
que contribuya o se incluya en un tema en particular se agrega al portafolio; por lo tanto, la
mayoría de las organizaciones tendrían varias carteras.
figura 18.1 Carteras, programas y proyectos.
Como se muestra en la Figura 18.1, un portafolio puede constar de programas, proyectos

y otras actividades laborales, incluso otros portafolios. Sin embargo, a diferencia de los
proyectos de un programa, los proyectos y otros elementos de una cartera no son
necesariamente interdependientes. Se agrupan en la cartera con el fin de administrarlos
mejor en su conjunto y priorizar y asignar recursos entre ellos para lograr mejor los objetivos
de la organización.
Casi por definición, cualquier organización que administra y asigna recursos a más de un
proyecto tiene una cartera de proyectos, ya sea que los gerentes reconozcan o no
2
eso. Las organizaciones familiarizadas con el concepto de cartera de proyectos
comúnmente se ajustan a un proceso llamado gestión de cartera de proyectos;
Brevemente, esto involucra dos pasos: (1) crear portafolios—definir “temas” alrededor
de los cuales formar portafolios y criterios para incluir proyectos y programas en cada
portafolio; categorizar los proyectos y programas actuales y propuestos en carteras
particulares; y (2) administrar carteras: evaluar los proyectos y programas propuestos
para decidir si cada uno debe aprobarse, suspenderse o rechazarse; priorizar los
proyectos aprobados y asignar recursos para que los proyectos prioritarios obtengan
la financiación adecuada; y el seguimiento y la gestión de proyectos y programas de
forma colectiva por el bien de la cartera y el negocio en general.
La forma más rudimentaria de gestión de cartera es simplemente realizar un
seguimiento de los proyectos en curso y bajo consideración. La organización tiene dos
listas: una para proyectos “activos”, otra para proyectos “potenciales” o en espera. Por
simple que parezca, la creación y el mantenimiento de dichas listas en ausencia de un
proceso de gestión de cartera no es trivial, ya que los gerentes habitualmente inician
proyectos sin registrarlos y no mantienen listas de proyectos actuales y propuestos.
Académicos, consultores y empresas de software han propuesto muchos enfoques
para la gestión de carteras de proyectos. La amplitud del tema llena libros; por lo tanto,
el tratamiento aquí se limita a una revisión de los enfoques más comunes.
3
Proceso para Proyectos Exitosos
Los proyectos y programas exitosos dependen de dos cosas: hacer los proyectos
correctos y hacerlos de la manera correcta. Los dos suceden en un proceso que
involucra a gerentes sénior, gerentes de unidades de negocios y gerentes de proyectos:
• Dirección estratégica: enfocar la organización. Los altos directivos articulan

la visión y la misión de la organización, definen estrategias, establecen
presupuestos y asignan recursos a las unidades de negocio. Algunos ejemplos
de estrategias contrastantes son ser el líder tecnológico o de bajo costo, ser
innovador o imitativo, o buscar mercados masivos o de nicho.
• Gestión de carteras: elija los proyectos adecuados. Los gerentes de
unidades de negocios desarrollan estrategias, metas e iniciativas consistentes
con la misión y las estrategias corporativas. Cada objetivo o iniciativa se convierte en el
tema para la creación de una cartera y la fijación de criterios específicos, que se convierten
en la base para la selección de proyectos a partir de propuestas generadas internamente o por
clientes.
• Metodología de gating: nutrir o deshacerse de proyectos. Los gerentes de las unidades de

negocios evalúan cada proyecto a medida que pasa por las puertas comparando su
desempeño con el desempeño y los criterios de entrada de otros proyectos. A los proyectos
importantes pero con dificultades se les asignan más recursos; los proyectos de bajo
rendimiento o mediocres se suspenden o cancelan. • Gestión de proyectos: hacer bien los
proyectos. Los gerentes de proyecto guían los proyectos usando principios y prácticas de
gestión de proyectos como se describe a lo largo de este libro.
Gerente de Portafolio de Proyectos
El gerente de la cartera de proyectos es la persona encargada de supervisar la cartera de proyectos.

Su objetivo es alcanzar los objetivos organizacionales a través de la inversión de la cartera en
programas y proyectos; por lo tanto, tiene un papel importante en la orientación de la organización en
la dirección correcta y, en consecuencia, tiene una perspectiva comercial mucho más amplia y de más
largo plazo que los gerentes de proyectos y programas.
Trabajando con la Junta de Revisión de Proyectos (descrito a continuación), la cartera
El papel del gerente es:
• Asegurar que los proyectos y programas se alineen con los objetivos estratégicos y
iniciativas.
• Evaluar los proyectos y programas propuestos en términos de beneficios potenciales,

los recursos necesarios y el riesgo.
• Aprobar proyectos que puedan lograr objetivos estratégicos dentro de límites aceptables de
riesgo y recursos. Esto sucede en una fase temprana del proyecto, como FEL-1.
• Agrupar proyectos y programas relacionados o interdependientes en carteras. • Priorizar

programas y proyectos basados en la contribución a la estrategia
objetivos, requerimientos de recursos y riesgos.
• Desarrollar un plan de recursos y asignar recursos a programas y proyectos. • Buscar una
inversión óptima mediante el diseño de una combinación de programas y proyectos
para explotar las sinergias entre ellos y proporcionar equilibrio en términos de riesgo,
tamaño, duración, etc. • Supervisar, revisar y evaluar los proyectos en las puertas de fase
para el impacto comercial y la justificación comercial. • Informar los resultados de la
evaluación y las recomendaciones a los altos ejecutivos.
Los aspectos del rol del administrador de cartera pueden parecer similares a los de un administrador
de proyecto o programa, pero el administrador de cartera tiene la autoridad final. Cada gerente de
proyecto defiende y puede luchar por la existencia de su proyecto, pero el gerente de cartera
analiza los beneficios del proyecto para la organización y puede recomendar reducir o terminar el
proyecto.
Idealmente, el gerente de cartera tiene experiencia en gestión de proyectos y gestión de
programas; sin embargo, lo más importante es que comprenda el entorno comercial de la
organización (p. ej., mercados y competidores), capacidades, ventajas competitivas y estrategias,
e interactúe bien con los ejecutivos y las partes interesadas sénior.
Junta de revisión de proyectos
El administrador de la cartera comparte la responsabilidad de la selección de proyectos y la gestión

de la cartera con la Junta de Revisión de Proyectos o PRB (también conocido como Equipo de
Gestión de la Cartera, Junta de Gobernanza del Proyecto, Comité Directivo, Consejo del Proyecto).
La membresía de PRB generalmente incluye al administrador de cartera, director financiero (CFO),
director de riesgo (CRO), director de recursos humanos (CHRO), director de la oficina de gestión
de proyectos (PMO) y director técnico (CTO), siendo el último alguien de TI, ingeniería o desarrollo
de productos. Para cada propuesta de proyecto, el CFO sopesa los costos y los beneficios
financieros, el CRO evalúa los riesgos, el CHRO evalúa los requisitos de recursos humanos, el
CTO evalúa los beneficios técnicos y las dificultades, y el director de la PMO compila la
documentación . decisiones de selección y entrada. preside el PRB y tiene la última palabra sobre
en la cartera. las adiciones o eliminaciones de proyectos
Para los proyectos de investigación e ingeniería, el PRB incluirá un grupo de "revisores pares"
técnicos que evaluarán y calificarán las propuestas de manera independiente de acuerdo con
mérito científico o técnico, probabilidad de éxito y competencia o capacidad de los autores de la

propuesta. Si todos asignan puntajes bajos a una propuesta, el proyecto es rechazado. Si todos
asignan puntajes altos, el proyecto se aprueba, siempre que otros en el PRB también lo aprueben
y haya fondos disponibles. Cuando la financiación es escasa, se aprueban pocos proyectos,
independientemente de las puntuaciones altas. Cuando es abundante, incluso se pueden aprobar
5
proyectos calificados como mediocres.
18.2 Marco para la Selección de Proyectos y

Gestión de Cartera
En organizaciones donde los proyectos se generan internamente, el proceso de gestión de cartera
se utiliza para evaluar propuestas y aprobar proyectos; en aquellos donde los proyectos se
generan externamente, se utiliza para determinar a qué RFP debe responder la empresa.
Los proyectos difieren con respecto a los requisitos de recursos, el riesgo, el costo y el valor
estratégico, por lo que elegir los proyectos correctos no es fácil. Dado que la mayoría de los
proyectos representan inversiones, muchos de los métodos utilizados en la gestión de la cartera
de proyectos se derivan de los métodos de gestión de inversiones. Así como una cartera de
inversiones puede reducir el riesgo monetario, por ejemplo, invirtiendo en múltiples monedas
(libra, euro, yen o dólar), una cartera de proyectos puede reducir el riesgo al incorporar proyectos
de múltiples sectores comerciales.
Proceso de selección
Una organización que habitualmente enfrenta decisiones de selección de proyectos debe seguir
un proceso prescrito para evaluar y comparar propuestas de proyectos. El proceso debe utilizar
un conjunto de criterios medibles que reflejen las iniciativas y los objetivos estratégicos de la
organización.
El proceso de evaluación y selección de proyectos y su relación con otros aspectos de la
gestión de cartera se muestran en la Figura 18.2. En la Fase I, cada proyecto se evalúa y examina
de forma independiente; en la Fase II, se comparan todos los proyectos y se aprueba un
los componen. subconjunto. selección de programas, así como a los proyectos que
Fase I
La Fase I comienza con una etapa de preselección para eliminar proyectos claramente deficientes
propuestas; esto corresponde a la etapa de “anteproyecto” o FEL-1 discutida en el Capítulo

4. Para pasar este paso, un proyecto debe estar justificado en términos de organización 7 Los
supervivencia continuaproyectos de supervivencia
o el crecimiento. viabilidad son necesarios
de la paraLos
organización. la salud y la de
proyectos
crecimiento, aunque no son esenciales para la supervivencia, amplían o aprovechan
oportunidades para la organización. La justificación se documenta en un caso de negocios
preliminar que confirma que el proyecto es compatible con las estrategias organizacionales,
vale la pena y es viable (los beneficios esperados exceden los costos esperados). Un proyecto
también necesita un campeón y un patrocinador que lo apoyen. Se rechazan los proyectos
que carecen de justificación, respaldo o información suficiente para tomar una decisión. A
veces, se emplea una lista de verificación simple con una pequeña cantidad de criterios y
cada propuesta se califica como excelente, buena, deficiente, etc. Las propuestas que caen
por debajo de una calificación compuesta de "umbral" se rechazan automáticamente.
Ver Capítulo 4
figura 18.2 Metodología de análisis, selección y gestión de cartera de proyectos.
Fuente: Adaptado de Archer N. y Ghasemzadeh F. Un marco integrado para la cartera de proyectos
selección. Revista Internacional de Gestión de Proyectos 17(4); 1999: 207–216.
Ver Capítulo 4
Las propuestas que pasan la preselección se someten a análisis utilizando modelos

cuantitativos y cualitativos y métodos de puntuación. El análisis podría calificar o valorar la
propuesta en términos de diversos criterios, como "vínculo con los objetivos estratégicos", "valor
financiero" o "cumplimiento de las restricciones", que conducen a un caso comercial más
detallado y verificado (por ejemplo, como en FEL- 2, discutido en el Capítulo 4).
Para ser considerada para la Fase II y posible financiamiento, una propuesta debe exceder un
valor mínimo de corte o puntuación; tal es el propósito de la selección: determinar qué proyectos
cumplen con los requisitos mínimos de beneficios, riesgos u otros criterios específicos, y aprobarlos.
8
La Fase I restringe el grupo de proyectos que ingresan a la Fase II a solo los proyectos "correctos"
y genera información para las decisiones de selección de cartera en la Fase II. Para desalentar las
propuestas de proyectos que son frívolas o claramente deficientes, las RFP y los procedimientos de
inicio de proyectos deben especificar claramente los requisitos mínimos para la aprobación del
proyecto.
Fase II
El primer paso de la Fase II es la selección de cartera en la que los proyectos aprobados en la Fase
I se revisan junto con los proyectos existentes para determinar qué combinación de ellos constituiría
la "mejor" cartera. Los proyectos se comparan en términos de puntajes del análisis de la propuesta
o, para proyectos existentes, medidas de su estado actual y desempeño. Todos los proyectos,
propuestos y existentes, se comparan entre sí utilizando los mismos criterios.
La Fase II no es un evento único sino un proceso continuo. Los proyectos existentes se evalúan
en función de los beneficios, el rendimiento y los costos esperados mediante el proceso de selección.
Aquellos en problemas y que no cumplan con los requisitos mínimos son despedidos por completo.
Los restantes se agrupan con nuevos proyectos y todos están ordenados por rango para su
reconsideración sobre la continuación, la reducción o el aumento del apoyo o la cancelación.
La ordenación por rango ayuda a garantizar que los proyectos de alta prioridad reciban recursos y
financiación. Debido a que los objetivos, las oportunidades (nuevas estrategias, RFP y propuestas),
las amenazas, los recursos y el entorno externo cambian periódicamente, también lo hará la cartera:
se agregan nuevos proyectos mientras que algunos proyectos actuales se aceleran, retrasan o
cancelan.
Embudo y filtro
El propósito del proceso de análisis y selección no es desalentar los proyectos, sino asegurarse de
que solo se busquen los proyectos "correctos". Si una empresa trabaja externamente bajo contrato
o internamente para desarrollar nuevos productos o
procesos, se apoya en proyectos de supervivencia y crecimiento; idealmente, tiene la opción de elegir

proyectos entre muchas propuestas, RFP y solicitudes de inicio.
Por lo tanto, el proceso de selección de la empresa se puede comparar con un embudo en el que fluyen
muchas propuestas y un filtro a través del cual solo emergen las mejores, como se ilustra en la Figura
18.3. El truco consiste en diseñar el proceso con una boca de embudo lo suficientemente ancha como
para admitir muchas propuestas, pero un filtro lo suficientemente fino como para descartar las malas
9
propuestas y, al mismo tiempo, proporcionar un flujo constante de proyectos de alta calidad.
18.3 Métodos para evaluar proyectos individuales
La selección de proyectos se basa en el análisis de proyectos individuales. Cada análisis

incorpora supuestos, algunos de los cuales podrían resultar erróneos más adelante; por esta
razón, el análisis siempre debe estar completamente documentado e incluir los supuestos
establecidos. Entre los métodos de análisis más comunes se encuentran los modelos
financieros y los modelos de puntuación.
figura 18.3 Proceso de selección de proyectos como embudo y filtro.
Fuente: Adaptado de S. Wheelwright y K. Clark, Revolutionizing Product Development. Nueva York: Gratis
Prensa; 1992.
Modelos Financieros
Los modelos financieros miden las propuestas de proyectos en términos de criterios

económicos o financieros, como el valor presente neto (VAN), la tasa interna de retorno (IRR),
el retorno de la inversión original (ROI), el período de recuperación y el costo del ciclo de vida
(discutido en el Capítulo 9 ). ). Un modelo común de este tipo es el valor comercial esperado
(ECV), una aplicación del análisis de árbol de decisión (ver el Apéndice del Capítulo 10). Este
modelo, ilustrado en la Figura 18.4, considera los costos, las ganancias y la probabilidad de éxito de
10
el desarrollo y lanzamiento de un nuevo producto. Suponga que el costo de
desarrollo del producto es de $10 millones, el costo de lanzamiento es de $1,5 millones, el NPV para el
flujo futuro de ganancias es de $50 millones y las probabilidades de éxito son del 80 por ciento en
desarrollo y del 60 por ciento en el mercado. Después,
VCE = [($50)0,6 ÿ $1,5 millones] 0,80 ÿ $10 millones = $12,8 millones
En general, cuanto mayor sea el ECV, más preferido será el proyecto.
Otro modelo financiero es la relación beneficio/costo (B/C), que pondera los beneficios
de un proyecto contra sus costos. Un ejemplo sencillo es:
Los valores en el numerador y el denominador se expresan de la misma forma, ya sea como montos
anualizados o de valor presente. Por ejemplo, si el ingreso anual estimado del proyecto es de $100 000,
el costo anual estimado es de $25 000 y la probabilidad de éxito es del 50 %, la relación resultante es
2,0. Por lo tanto, por cada dólar gastado en el proyecto, se esperaría a cambio dos dólares en beneficio.
B/C también se puede calcular para otras formas de beneficios.
11
Por ejemplo, en la proporción
el "valor" puede ser el ahorro de costes. Suponga, por ejemplo, que la renovación de una fábrica y la
instalación de nuevos equipos generarán un ahorro de valor presente esperado de $6 millones por un
costo de valor presente (renovación de instalaciones, instalación de equipos y gastos anuales de
operación y mantenimiento) de $3 millones. La relación B/C para el proyecto es 2.0.
figura 18.4 Modelo para calcular el valor comercial esperado, ECV.
Fuente: Adaptado de Cooper R., Edgett S. y Kleinschmidt E. Gestión de cartera en nuevos productos
desarrollo: Lecciones de los líderes, fase I. En Dye L. y Pennypacker J. (ed.), Project Portfolio
Administración. West Chester, PA: Centro de Prácticas Comerciales; 1999, págs. 97–116.
Por supuesto, la precisión de la relación depende de la precisión de los valores de todos

los costos y beneficios relevantes, incluidos los "ocultos" o externos, como los impactos
en la sociedad, la economía y el medio ambiente.12 Los costos y beneficios ocultos
pueden ser difíciles de identificar y medir y, a menudo, superan con creces los costos y
beneficios más obvios. En el ejemplo de renovación, suponga que después de que
comienza el proyecto se descubre que el sistema eléctrico de la fábrica está fuera de
código y necesita reemplazo, y se determina que el piso no es sólido y necesita refuerzo;
o, suponga que las regulaciones ambientales cambian, requiriendo nuevos equipos para
limpiar el humo y los líquidos descargados de la fábrica. No anticipar estos costos daría
como resultado una relación B/C inexacta y engañosa.
Las principales debilidades de los modelos financieros son el exceso de confianza en
las estimaciones de costos, ahorros, flujos futuros de ganancias, probabilidades, etc.; falta
de datos para estimar estos valores durante la concepción del proyecto; y la tendencia de
los partidarios del proyecto a subestimar los costos y exagerar los beneficios. Otra
debilidad es la confianza exclusiva en un criterio (financiero) y el descuido de otros criterios
de igual o mayor importancia; El NPV, por ejemplo, no mide el valor estratégico de un
proyecto o la medida en que, digamos, un proyecto contribuiría al objetivo de "expandir el
mercado en Europa".
Modelos de puntuación
Los modelos de puntuación califican los proyectos en términos de múltiples criterios que, además de las
medidas cuantificables, incluyen otros no cuantificables como el riesgo de mercado, el entusiasmo del
cliente o la adecuación a los objetivos de la empresa, cualquier criterio que se considere importante y
discrimine entre proyectos.
En los modelos de calificación más simples, se califica un proyecto en cada criterio de acuerdo con una
escala (por ejemplo, 5 = excelente, 4 = bueno, 3 = adecuado, 2 = deficiente, 1 = malo) y las calificaciones
de todos los criterios se suman para obtener producir una puntuación general del proyecto. Las
calificaciones ponderadas se utilizan cuando algunos criterios se consideran más importantes que otros.
La tabla 18.1 ilustra un método de puntuación que incluye probabilidades y pesos.
La primera columna son los criterios de puntuación, y las siguientes cinco columnas ("Muy bueno" a "Muy
malo") son la probabilidad esperada de que el proyecto cumpla con los criterios. Por ejemplo, la probabilidad
de que la perspectiva a largo plazo para el proyecto sea "Muy buena" es del 80 por ciento y que sea
"Buena" es del 20 por ciento. La forma en que se obtienen estas probabilidades depende de la información
disponible y puede variar desde una intuición hasta un análisis cuantitativo sofisticado; por ejemplo, el
puntaje en la tabla para "Aceptabilidad del nivel de riesgo" puede basarse en una opinión o derivarse del
análisis de los impactos y probabilidades del riesgo, explicado en el Capítulo 10. Al igual que con todos los
análisis, cuantos más datos estén disponibles y más experimentado el equipo de puntaje , más precisas
serán las estimaciones.
Los números en la columna Calificación esperada en la Tabla 18.1 se calculan como la suma de las
probabilidades por el puntaje. La calificación esperada para la perspectiva a largo plazo del producto, por
ejemplo, es 0,8(4) + 0,2(3) = 3,8.
La siguiente columna, Peso, refleja la importancia relativa de los criterios (un criterio con una
ponderación de 10 se considera el doble de importante que uno con una ponderación de 5); a veces, los
pesos se establecen en un total de 100, como se muestra. La siguiente columna, Puntuación esperada
ponderada, es el Peso multiplicado por la Calificación esperada. Para la perspectiva a largo plazo del
producto, el puntaje esperado ponderado es 3.8 × 10 =
38.
La parte inferior de la Tabla 18.1 muestra el puntaje esperado ponderado total (suma de todos los
criterios), 336,8 de un máximo posible de 400. Este puntaje se usa para evaluar la propuesta en la Fase I
o clasificarla con otros proyectos en la Fase II.
Una limitación de los métodos de calificación es que ignoran los recursos necesarios para
implementar proyectos. Los proyectos grandes tienden a recibir más atención y obtienen una
puntuación más alta que los proyectos pequeños, pero consumen más recursos y excluyen otros
proyectos, incluso los importantes. Esta limitación se puede compensar considerando
simultáneamente los fondos o recursos necesarios de un proyecto y su puntuación o calificación,
como en el método de rentabilidad, que se describe más adelante.
Ver Capítulo 10
Tabla 18.1 Modelo de puntuación ponderada del proyecto

18.4 Métodos de Comparación y Selección de Proyectos
Los proyectos propuestos que han sobrevivido a la Fase I se comparan con los proyectos actuales en la
Fase II para determinar qué combinación de proyectos constituye la mejor cartera. El resultado será agregar
algunos proyectos nuevos a la cartera y eliminar algunos proyectos actuales.
En su revisión de carteras de proyectos en el desarrollo de productos, Cooper et al.

13
encontró que los enfoques de selección de proyectos tienden a apuntar a los siguientes objetivos:
• Maximizar el valor o utilidad de la cartera. • Lograr el

equilibrio en la cartera. • Adecuar el portafolio a los objetivos
e iniciativas estratégicas de la organización.
valor o utilidad
Los métodos de valor o utilidad seleccionan proyectos con el mayor “valor” o utilidad según lo determinado
a partir de modelos financieros o métodos de puntuación.
Métodos de criterio único
Estos métodos clasifican los proyectos según un solo valor o medida de utilidad (p. ej., ECV del modelo en
la Figura 18.4 o puntaje en la Tabla 18.1), y los que tienen la clasificación más alta se seleccionan según la
disponibilidad de recursos. Se puede aplicar un umbral de valor mínimo para las propuestas de selección,
como rechazar aquellas con una relación B/C inferior a 1,5, una puntuación máxima inferior al 50 % (200/400
en la Tabla 18.1) o una TIR inferior al 8 %. (llamada tasa crítica).
Otros métodos de valoración, más allá de nuestro alcance, incluyen técnicas de programación matemática
para seleccionar la combinación de proyectos que maximiza el valor de la cartera sujeto a dependencias de
proyectos, recursos limitados y otros
restricciones
Por supuesto, las estimaciones calculadas del valor financiero se basan en supuestos
sobre los valores de las variables de entrada, cuya validez siempre está abierta a cuestionamiento. En
un análisis de sensibilidad, los valores de las variables de entrada (independientes) se modifican para
determinar el efecto sobre el valor financiero estimado del proyecto (variable dependiente); en otras
palabras, el análisis prueba qué tan sensible es el valor financiero estimado a los cambios en las variables
de entrada (qué sucede con el ECV si, por ejemplo, los costos aumentan un 30 por ciento y el tipo de
cambio aumenta un 10 por ciento). Al medir el efecto de los cambios en cada una de las variables de
entrada o en una combinación de ellas sobre el valor financiero calculado, se determina el rango de
valores para las variables de entrada que producen un valor financiero del proyecto "aceptable". Un
proyecto cuyo valor financiero es sensible incluso a pequeños cambios en los valores de entrada se
14
considera riesgoso.
El inconveniente obvio de los métodos de un solo criterio es la dependencia de un solo valor para
clasificar los proyectos, lo que puede ser riesgoso porque las estimaciones subyacentes de costos,
beneficios, probabilidades, etc. a menudo están plagadas de imprecisiones. Además, los métodos tienden
a estar cargados de suposiciones que, si son incorrectas o se pasan por alto, pueden conducir a
conclusiones erróneas. La clasificación de los proyectos según B/C, por ejemplo, supone que todos los
proyectos son comparables, aunque a menudo no lo son.
El proyecto A con un B/C de 3,0 estaría clasificado por delante del proyecto B con un B/C de 2,0 incluso
si el proyecto B tuviera un beneficio de $2 millones y el proyecto A tuviera un beneficio de solo $200 000.
Métodos de múltiples criterios
Un proyecto se puede valorar de muchas maneras, aunque puede ser valorado alto en un criterio pero
valorado bajo en otro. Para superar el enigma de que
15
criterio a utilizar son métodos que emplean múltiples criterios. 18.2 califica Por ejemplo, Tabla
cada proyecto según tres criterios: Ajuste con la estrategia corporativa (calificación subjetiva de 0 a 4; 0
es un ajuste deficiente, 4 es un ajuste perfecto); Recompensa (ECV, calculada a partir del modelo
financiero); y Riesgo (calificación subjetiva de 0 a 4; 0 es sin riesgo, 4 es de alto riesgo). Se comparan las
puntuaciones de los proyectos para cada criterio y se clasifican los proyectos. Por ejemplo, en la Tabla
18.2 , el Proyecto Adrastea ocupa el puesto 5 en Ajuste Estratégico porque obtuvo la puntuación más
baja, 0 (nota, algunos proyectos tienen la misma clasificación porque sus puntajes están empatados);
ocupa el puesto 4 en ECV porque obtuvo el cuarto lugar en valor de ECV; y ocupa el puesto 4 en Riesgo
porque obtuvo una puntuación alta en riesgo (empatado con los Proyectos Thebe y Europa). La puntuación de clasificació
columna se calcula como el promedio de las tres clasificaciones; para el Proyecto Adrastea it
es (5 + 4 + 4) /3 = 4,33; esto coloca al proyecto en séptimo y último lugar.
Tabla 18.2 Lista ordenada por rango de criterios múltiples
Proyecto Puntuación de clasificación de riesgo de recompensa de ajuste estratégico (ECV)
Proyecto Métis 4 (1) 2,3 (7) 3 (3) 3.67 (5)
Proyecto Adrastea 0(5) 3,5 (4) 4 (4) 4.33 (7)
Proyecto Tebe 2 (3) 3,1 (5) 4 (4) 4.0 (6)
Proyecto 10 3 (2) 2,6 (6) 2 (2) 3.33 (4)
Proyecto Europa 1 (4) 6,4 (1) 4 (4) 3.0 (3)
Proyecto Ganímedes 3 (2) 4,6 (3) 3 (3) 2.67 (2)
Proyecto Calisto 4 (1) 5,3 (2) 2 (2) 1.67(1)
Al tener en cuenta múltiples criterios y permitir que se agreguen criterios adicionales

como se desee, este método asegura de alguna manera que los "buenos" proyectos (en términos de
criterios financieros o de puntuación utilizados) se conservan como candidatos para la selección. A
La limitación de este y todos los métodos de valor es que por sí solos no garantizan que
los proyectos que constituyen la cartera serán “equilibrados” o alineados con
objetivos y estrategias organizacionales.
Saldo de cartera 16
Los inversores inteligentes evitan asumir demasiados riesgos. En lugar de poner todos sus huevos en
una canasta, se diversifican y tratan de equilibrar las inversiones que son de alta ganancia,
alto riesgo con los que son de baja ganancia pero de bajo riesgo. A pesar de las tentadoras oportunidades
por grandes ganancias u otras recompensas, pocos promotores inmobiliarios, empresas farmacéuticas
empresas, desarrolladores de software u otros ponen todos sus recursos en proyectos,
mercados o productos cuyos resultados son muy inciertos. buscan el equilibrio
proyectos que son apuestas con proyectos que son apuestas seguras.
Una forma de mostrar este saldo es con un "gráfico de burbujas". En la Figura 18.5 cada
“burbuja” representa un proyecto; el eje x representa la recompensa del proyecto o esperada
beneficios; el eje y, la probabilidad de éxito del proyecto. El eje de la recompensa puede ser un
escala de intervalo (p. ej., valores para ECV, NPV, etc.) o escala ordinal (p. ej., alto, bajo);
De manera similar, el eje de probabilidad puede ser de intervalo (probabilidad de 0 a 100) u ordinal
(baja, alta). Los tamaños de las burbujas representan los tamaños relativos de los proyectos según,
por ejemplo, la financiación o los recursos.
Las organizaciones de desarrollo de productos etiquetan los cuatro cuadrantes del gráfico de
acuerdo con los tipos de proyectos que uno encuentra: perlas, ostras, pan con mantequilla y elefantes
blancos.
Las perlas son los proyectos que toda empresa desea: alta probabilidad de éxito y alta recompensa;
pero en realidad todas las empresas también tienen proyectos en los otros cuadrantes. Las ostras
tienen una menor probabilidad de éxito debido a los riesgos técnicos o de otro tipo, pero vale la pena
buscarlas debido a la gran recompensa potencial. El objetivo es encontrar perlas en las ostras; la
mayoría de las ostras no contienen perlas, pero eso no se sabe de antemano.
Los proyectos de pan y mantequilla son los más comunes: las recompensas son de bajas a
moderadas, pero la probabilidad de éxito es alta. Sin embargo, demasiados proyectos de pan y
mantequilla restan recursos a las perlas y las ostras y reducen las oportunidades comerciales futuras.
figura 18.5 Gráfico de burbujas para la probabilidad de éxito y recompensa del proyecto, y el tamaño del proyecto.
Fuente: Adaptado de Cooper R., Edgett S. y Kleinschmidt E. (1999).

figura 18.6 Gráfico de burbujas para probabilidad de éxito y recompensa, y rango de incertidumbre.
Fuente: Adaptado de Cooper R., Edgett S. y Kleinschmidt E. (1999).
Los elefantes blancos son proyectos con baja probabilidad de éxito y baja rentabilidad.
Debe preguntarse por qué una empresa retendría proyectos en esta categoría.
El hecho es que, habiendo gastado dinero y esfuerzo en un proyecto, las empresas sienten que
17
deben continuar; se mantienen comprometidos con los proyectos debido a los fondos ya gastados.
Un enfoque más prudente es considerar los fondos gastados como “costos irrecuperables” e
irrelevantes para decidir el futuro de cada proyecto. A veces se necesita coraje para seleccionar un
proyecto de elefante blanco de la cartera, especialmente cuando fue idea de un gerente influyente.
La figura 18.6 muestra otro tipo de gráfico de burbujas en el que el tamaño y la forma de cada
burbuja reflejan la incertidumbre sobre la probabilidad de éxito del proyecto y la recompensa; cuanto
18
mayor o más larga sea la burbuja, mayor será la incertidumbre.
Al igual que otros métodos de evaluación, el inconveniente de los gráficos de burbujas es grande.
confianza en estimaciones o conjeturas de probabilidades, recompensas, costos, etc. Además, no

muestran el orden de clasificación o la prioridad de los proyectos utilizando criterios distintos a la
recompensa y la probabilidad de éxito (por ejemplo, cuál es mejor, "High-flyer", "Xyclon" o ¿“Minería
de Marte”?) o cómo los proyectos deben distribuirse en los cuadrantes.
No obstante, suponiendo que el equipo de selección de proyectos conozca el equilibrio que está
buscando, estos gráficos pueden ser útiles para decidir qué proyectos analizar con más cuidado y
cuáles ignorar. Conceptualmente, al menos, cada organización tiene una línea de "umbral" (Figura
18.6) por encima de la cual se aceptan proyectos, por debajo de la cual se rechazan.
Ajuste estrategico
Otra forma de seleccionar proyectos es de acuerdo con qué tan bien se ajustan a las metas y
estrategias organizacionales. Comenzando con la misión, las iniciativas estratégicas y los objetivos
de la organización, la alta dirección decide las categorías (temas) de proyectos que mejor se alinean
con ellos.
Los proyectos generalmente se clasifican de acuerdo con:19
• Objetivo estratégico (p. ej., defender la base de productos, hacer crecer la base,
diversificación de productos,
etc.) • Línea de productos (producto A, B, C,
etc.) • Tipo de proyecto (I+D, mejora de capital, mejora de procesos, etc.) • Geografía
(Toronto, California, Panamá, América Central, etc.) • Unidad de negocio (marketing,
fabricación, desarrollo de productos, etc.).
Otros ejemplos son los cinco encabezados de la Tabla 18.3. Asociado con cada categoría hay un
monto de financiamiento asignado ($12,5 millones, $8,5 millones, $10 millones, etc.), que es el
presupuesto total disponible para todos los proyectos en una categoría.
En una empresa pequeña, las categorías pueden consolidarse en una cartera y administrarse
como un solo grupo de cartera, o en un programa y ser supervisado por un administrador de
programas. En una empresa grande, cada categoría sería una cartera de proyectos separada
supervisada por su propio administrador de cartera y PRB.
Las empresas habitualmente emprenden más proyectos de los que pueden manejar. Por ejemplo,
en la tabla 18.3 los totales al final de las columnas indican que
todos los proyectos, excepto la segunda categoría, requieren una financiación superior a la
financiación asignada. Para decidir qué proyectos incluir en la cartera, el PRB ordena la lista
de proyectos (usando los métodos descritos anteriormente) y, comenzando desde arriba,
selecciona proyectos hasta que se agotan los fondos. Suponiendo que los proyectos en la
Tabla 18.3 están ordenados por rango, los proyectos subrayados representan el corte. En la
última categoría, por ejemplo, el Proyecto S es el corte; y los Proyectos A1 y E1 no serán financiados.
Un proyecto aprobado se admite en la cartera, pero su ejecución final depende de la
disponibilidad de recursos clave limitados. Alguien, en algún lugar (quizás la PMO) realiza un
seguimiento de la asignación de recursos clave limitados, y solo cuando los recursos están
disponibles se puede programar el inicio de un proyecto.
Cuadro 18.3 Clasificación de proyectos ordenados por categoría
Decidir sobre las categorías y la financiación de cada una es responsabilidad de la alta

dirección. Presumiblemente, tales decisiones se basan en la consideración de la misión, las
estrategias y los objetivos de la organización, aunque a veces la asignación es discutible. La
misión de la NASA, por ejemplo, es apoyar la investigación y el desarrollo en aeronáutica,
vuelos espaciales tripulados y exploración espacial no tripulada, aunque a veces la mayor parte
de los fondos de la NASA se destinan a programas de vuelos espaciales tripulados, lo que deja
poco para la exploración espacial no tripulada e incluso menos para la investigación aeronáutica.
Esto ha llevado a los críticos a afirmar que la asignación de fondos sesgada de la NASA no
respalda la gama completa de la agencia.
de supuestos objetivos.
Cuadrícula de costo-beneficio
Un método muy adecuado para priorizar y seleccionar proyectos de acuerdo con varios criterios
20
es la tabla de costo-beneficio de Buss. Suponga que dos criterios importantes son los
beneficios financieros y el costo del proyecto. El PRB revisa la propuesta de cada proyecto y la
califica (alta, media o baja) de acuerdo con los beneficios financieros y el costo. El resultado se
muestra en una cuadrícula de tres por tres. Cuando se califican varios proyectos de esta manera,
el resultado se parece a la Cuadrícula A de la Figura 18.7, que muestra las calificaciones de 12 proyectos.
Después de revisar la cuadrícula y llegar a un acuerdo sobre el posicionamiento relativo de los
proyectos mostrados, el equipo repite el procedimiento para criterios adicionales como beneficios
técnicos, beneficios intangibles, ajuste con la estrategia comercial de la empresa, etc., y traza los
resultados en otras cuadrículas ( Figura 18.7).
figura 18.7 Cuadrículas de costo-beneficio de Buss, calificaciones para 12 proyectos.
¿Cómo se evalúan los beneficios intangibles? Primero, el equipo acuerda los beneficios intangibles que
desea considerar, como la imagen de la empresa, la satisfacción del cliente o el ajuste estratégico. Los
equipos que tienen miembros con diferentes perspectivas, es decir, algunos que ven los proyectos en
términos de rentabilidad financiera, otros que los ven en términos de capacidades técnicas o beneficios
estratégicos, suelen identificar mejor los intangibles que los equipos en los que todos piensan igual. Dada la
lista de intangibles, el equipo elige un método de puntuación. Si, por ejemplo, hay seis beneficios intangibles
y cada uno tiene una puntuación de 1 a 5, entonces la puntuación máxima posible de un proyecto para
intangibles será 30. Para ubicar un proyecto en la cuadrícula, las puntuaciones se convierten en categorías
simples, por ejemplo, ÿ 20 es Alto, ÿ 10 es Bajo, en el medio es Medio.
21
Se crea una lista ordenada por rango a partir de las cuadrículas completas. Proyectos en la parte inferior
las celdas de la derecha se colocarían en la parte superior de la lista; los de arriba a la izquierda,
abajo. Pero además de la ubicación en las cuadrículas, el orden de clasificación también depende
de las prioridades de la organización. En la Figura 18.7 , los proyectos 1, 3, 8 y 11 aparecen en la
parte inferior derecha de tres de las cuadrículas, pero si la principal prioridad de la organización es
el beneficio financiero, entonces el proyecto 8 se clasificaría más bajo e incluso podría rechazarse.
La selección final también dependerá del tamaño de cada proyecto y de los fondos y recursos
disponibles, como se describió anteriormente.
La principal ventaja del método de cuadrícula es la exposición clara de los beneficios
comparativos de los proyectos determinados por el juicio colectivo del equipo. Para este y todos los
métodos de selección y evaluación del equipo, idealmente los miembros del equipo representan
una amplia gama de perspectivas (técnica, producto/mercado, financiera, ambiental, etc.).
22
Aunque parezca que el método de cuadrícula se basa demasiado en el juicio subjetivo y muy
poco en el análisis formal, el equipo podría, de hecho, usar métodos de análisis formales y modelos
cuantitativos para llegar a sus calificaciones. (Sin embargo, como se mencionó, los métodos
cuantitativos a menudo se basan en estimaciones que son poco más que conjeturas, lo que los
hace no más precisos que los métodos subjetivos, a pesar de crear falsas percepciones de lo
contrario).
23
Análisis de rentabilidad
El análisis de costo-efectividad es similar al método de cuadrícula de costo-beneficio, pero utiliza
valores numéricos para costos y beneficios. El término “efectividad” se refiere a la
grado en que se espera que un proyecto cumpla con los requisitos del proyecto; es intercambiable
con términos como beneficio, valor, utilidad y rendimiento. Al igual que con esos términos, la
evaluación de la eficacia implica la consideración de múltiples factores. Al evaluar proyectos de
aeronaves comerciales, por ejemplo, la efectividad tendría en cuenta alguna combinación de
capacidad de pasajeros, peso, alcance, velocidad, eficiencia de combustible y mantenibilidad de la
aeronave, que están interrelacionados de manera compleja. Un método para derivar una sola
medida que incorpore múltiples factores es calificar los factores subjetivamente (pero utilizando los
resultados del análisis cuantitativo y el asesoramiento de expertos técnicos), sopesar las
calificaciones y sumarlas, de manera similar al modelo de calificación ponderada ilustrado en la
Tabla 18.1. Los factores elegidos
para el análisis representan formas significativas de distinguir entre proyectos, y se supone que
los proyectos son idénticos en todos los demás aspectos importantes.
El ejemplo de la Tabla 18.4 muestra tres proyectos propuestos y siete factores. 24 Cada
proyecto se califica para cada factor de 0 a 100 para la eficacia (E) y para la eficacia ponderada
(WE = peso × E). Total WE, la suma de la eficacia ponderada en los siete factores, es la eficacia
del proyecto.
El método no clasifica los proyectos, pero sugiere cuáles deben descartarse y permite el
análisis de compensación de los proyectos restantes. Por ejemplo, la Figura 18.8 muestra los
tres proyectos de la Tabla 18.4 y otros cinco proyectos. Los proyectos j, h y m (en el área
sombreada) se encuentran por debajo del umbral mínimo de efectividad de 75 y se descartarían.
La línea que conecta los puntos superiores (j, A, n, C)—llamada “frontera eficiente”—representa
la máxima efectividad alcanzable para un costo dado (o costo mínimo para un nivel de
efectividad dado). Los proyectos B y k están por debajo de esta línea, lo que significa que son
inferiores a por lo menos otro proyecto en términos de costo y eficacia y también deben
descartarse. Solo los proyectos A, n y C son dignos de mayor consideración.
Una línea de máxima eficacia con una pendiente positiva indica que el aumento del costo
del proyecto se justifica por el aumento de la eficacia. Pero el grado de pendiente también es
importante: el Proyecto C es solo marginalmente más efectivo que el Proyecto n , pero cuesta
mucho más, lo que sugiere que probablemente no valga la pena continuar.
Cuadro 18.4 Análisis de datos de rentabilidad

figura 18.8 Efectividad versus costo de desarrollo para ocho proyectos.
Como se mencionó, la selección de proyectos se basa en información imperfecta sobre

costos y beneficios. Si bien los modelos de este capítulo brindan formas “objetivas” de clasificar
el laberinto de hechos, cifras y problemas asociados con la selección de proyectos, rara vez las
decisiones finales se basan únicamente en ellos; El hecho es que los instintos humanos, las
emociones y los motivos ocultos también juegan un papel en la selección de proyectos.
18.5 Integración del proceso de selección y

25
gestión de cartera
La gestión de cartera incluye la selección de nuevos proyectos y la revisión periódica de los
proyectos actuales. El administrador de cartera y PRB deben decidir cuándo iniciar cada
proyecto recién aprobado, inmediatamente o más tarde, y si cada proyecto actual debe
mantenerse, cambiarse o terminarse. Se reconsideran los proyectos que exceden los plazos
o los costos esperados, que no cumplen con los requisitos o que ya no son adecuados para
cambiar los objetivos de la empresa o el entorno. Los proyectos de bajo rendimiento o que
ya no son necesarios se cancelan para dar paso a proyectos esenciales o más prometedores.
Una señal de un proceso de gestión de cartera eficaz es que periódicamente se cancelan
algunos proyectos.
En muchas empresas, la revisión periódica del proyecto se realiza a través de un
proceso de puerta de entrada o etapa. La gestión de la puerta y la cartera se complementan
entre sí, pero los dos procesos son muy diferentes. En gating, cada proyecto se revisa en
ciertos hitos o etapas, y el destino del proyecto se basa en una evaluación de su progreso;
la evaluación no considera el impacto del proyecto en los recursos u objetivos
organizacionales, u otros proyectos.
Por el contrario, la gestión de cartera analiza todos los proyectos de la cartera y los
compara en términos de beneficios, costos y recursos. Esto implica un esfuerzo considerable
y, en consecuencia, puede ocurrir solo tres o cuatro veces al año, tal vez menos. Dado que
las empresas suelen participar en muchos proyectos y propuestas en un momento dado,
cada uno de los cuales llega a una puerta de decisión en un momento diferente, no es
factible comparar todos los proyectos de una cartera cada vez que uno de ellos llega a una
puerta.
Además, los dos procesos tienden a utilizar diferentes criterios de decisión: mientras que
la activación normalmente permite que un proyecto continúe siempre y cuando se ajuste a
los planes, las expectativas y el entorno empresarial, la gestión de cartera permite que
continúe solo si se compara favorablemente con otros proyectos. Además, los dos procesos
suelen involucrar a diferentes equipos: las decisiones en el proceso de entrada las toman
los gerentes de nivel medio y los clientes; en la gestión de carteras las realiza el gestor de
carteras y el PRB.
No obstante, lo ideal es que los dos procesos y equipos se ayuden entre sí: eliminando
proyectos marginales para que la cartera no tenga ningún rendimiento inferior, y la gestión de
cartera elimina proyectos que no contribuyen a los objetivos de la empresa. Además, el PRB
ayuda a los gerentes en el proceso de selección al compartir sus listados ordenados por rango y
al anotar cualquier cambio en la estrategia y los objetivos de la empresa.
Los gerentes de puertas consideran esta información y, a veces, cancelan proyectos que, en
última instancia, habrían sido cancelados por el PRB de todos modos.
18.6 Resumen y discusión

La gestión de cartera es el proceso de elegir y gestionar aquellos proyectos que mejor logran los
objetivos de la organización sujetos a limitaciones de recursos.
La gestión de cartera en combinación con la gestión estratégica, el proceso de selección y la
gestión de proyectos ayudan a garantizar que la organización realice los proyectos correctos y que
los realice correctamente.
La selección de proyectos y la gestión de la cartera pasan por un proceso de múltiples etapas
de preselección, análisis y selección de propuestas de nuevos proyectos, y luego clasificación,
selección y revisión continua de proyectos nuevos y existentes aprobados. La alta dirección
establece los criterios de alto nivel para las decisiones de selección de proyectos, pero la selección
real de proyectos y la gestión de la cartera recae en el gestor de la cartera y la PRB.
Este capítulo revisó una variedad de métodos para calificar, evaluar y comparar proyectos en
términos de beneficios, costos, riesgos, requisitos de recursos y objetivos estratégicos. Sin
embargo, los métodos cubiertos no dan cuenta de todo.
La dependencia del proyecto es un ejemplo: cuando el Proyecto B depende del Proyecto A,
entonces la aprobación del Proyecto A podría depender de la importancia del Proyecto B y, por supuesto,
26
La aprobación del Proyecto B dependerá de si el Proyecto A ha sido aprobado.
Un asunto separado pero relacionado es la selección de proyectos paralelos, como en el
desarrollo de nuevas tecnologías, para aumentar la probabilidad de que al menos uno logre un
gran avance.
Dada la variedad de métodos para analizar, calificar y seleccionar proyectos, la pregunta es:
¿cuál es el mejor? En la práctica, ningún método sobresale por encima de los demás, pero no es
necesario elegir solo un método. De hecho, los métodos descritos deben usarse en combinación.
Por ejemplo, los proyectos primero divididos según categorías estratégicas pueden luego ser
juzgados por el método de cuadrícula de costo-beneficio; los mejores de estos pueden clasificarse
y seleccionarse de acuerdo con los recursos disponibles. O bien, los proyectos priorizados
utilizando enfoques financieros, de puntuación o de rentabilidad se pueden verificar para determinar
el saldo de la cartera en gráficos de burbujas y luego juzgarse con el método de cuadrícula. El uso
de múltiples métodos de selección ayuda a asegurar que los proyectos seleccionados sean los
"correctos".
1. ¿Cuáles son las tres o cuatro características principales de la cartera de proyectos?

¿administración?
2. ¿Qué es una cartera de proyectos? ¿En qué se diferencian las carteras de proyectos de
programas?
3. ¿Es una mala práctica hacer primero los proyectos más fáciles ("elegir
Fruta")?
4. Compare lo siguiente; para cada estado el enfoque y cómo se relaciona con
proyectos:
• Gestión estratégica • Gestión

de carteras • Metodología de
gating.
5. ¿Cuáles son las responsabilidades del administrador de la cartera de proyectos?

6. ¿Cuáles son las responsabilidades de la junta de revisión de proyectos? ¿Quiénes son los
miembros del PRB?
7. “Algunos proyectos simplemente tienes que hacerlos. No tienes elección." Dé ejemplos de

proyectos en los que no tenga otra opción.
8. ¿Cuál es el propósito de la preselección en el proceso de selección de proyectos?
¿En qué se diferencia de la selección de proyectos?
9. Explique la selección de cartera. ¿Qué tipo de proyectos considera—
actual, propuesta o ambas?
10. ¿Cómo influiría la capacidad sobrante en las decisiones de selección de proyectos? ¿Qué
debe hacer con la capacidad sobrante?
11. Cada uno de los proyectos W, X, Y y Z se está evaluando de acuerdo con cuatro criterios:
rendimiento potencial de la inversión, falta de riesgo tecnológico, "amigable" con el medio
ambiente y servicio a la comunidad:
• Proyecto W: Retorno, alto; Riesgo, medio; Medio ambiente, medio;

Servicio, bajo.
• Proyecto X: Retorno, medio; Riesgo, alto; Medio ambiente, medio;

Servicio, bajo.
• Proyecto Y: Retorno, medio; Riesgo, medio; Ambiente, alto; Servicio, alto. • Proyecto
Z: Retorno, medio; Riesgo, medio; Ambiente, alto;
Servicio, bajo.
Cree un esquema para seleccionar los proyectos, asumiendo el mismo peso para todos los
criterios. Qué proyecto sale mejor; cual peor?
12. Para los cuatro proyectos anteriores, asigne puntajes de alto = 3, medio = 2 y bajo = 1.
Suponga que los criterios están ponderados: Retorno potencial de la inversión = 0.3, Falta
de riesgo tecnológico = 0.3, “Amigabilidad” ambiental = 0.3 , y Servicio a la Comunidad = 0.1.
Ahora, ¿qué proyectos salen mejor y peor?
13. Comparar los métodos ECV y B/C para la evaluación de proyectos.

14. ¿Cuál es el valor comercial esperado (ECV) de un proyecto que implica el lanzamiento de un
nuevo producto con un costo de desarrollo estimado de $15 millones, un costo de lanzamiento
de $0,8 millones y un VPN para el flujo futuro de ganancias de $45 millones si las
probabilidades de éxito son 70 por ciento en desarrollo y 50 por ciento en el mercado?
15. Un proyecto tiene tres fases: concepto, desarrollo y lanzamiento, que se espera que cuesten
$5 millones, $15 millones y $4 millones, respectivamente. Las probabilidades de éxito de las
tres fases son 0,5, 8 y 0,7, respectivamente. Si el VPN estimado de las ganancias futuras es
de $90 millones, ¿cuál es el ECV para el proyecto? (Respuesta: $ 11,1 millones.)
16. En el ejemplo anterior, ¿qué más se debe considerar si la corriente de

ganancias eran en euros en lugar de dólares?
17. En el problema 15, suponga que la probabilidad de éxito del proyecto es 0,5 × 0,8 × 0,7
= 0,28.
• ¿Cuál es la relación B/C para el proyecto? •

¿Qué medida hace que el proyecto se vea más atractivo, ECV o B/C? En su opinión,
¿merece aprobación el proyecto?
18. El proyecto A y el proyecto B tienen el mismo costo total de $4 millones. La probabilidad de

éxito del Proyecto A es del 95 por ciento, las posibilidades del Proyecto B son del 50 por ciento.
Se espera que el Proyecto A genere ingresos de $11 millones, pero incurrirá en costos de
mantenimiento de $5 millones. Se espera que el Proyecto B genere ingresos y eficiencias de $8
millones que ahorrarían $5 millones en gastos. Aplicando la relación B/C, ¿qué proyecto recomendaría?
19. ¿Qué ventaja tienen los modelos de puntuación sobre los modelos financieros en términos
de evaluar el valor o la utilidad de los proyectos?
20. ¿Cuáles son los inconvenientes de los modelos financieros? ¿De modelos de puntuación?
21. ¿Cuáles son los tres enfoques principales para comparar y seleccionar
proyectos?
22. ¿Cuál es el inconveniente de clasificar los proyectos utilizando un solo criterio?

¿métodos?
23. Repita el ejemplo de la Tabla 18.2, pero además de Ajuste, Recompensa y Riesgo, incluya un cuarto
criterio: Imagen pública del proyecto (4 = alta, 0 = ninguna).
Suponga que los proyectos están calificados de la siguiente manera en Imagen pública (los números
entre paréntesis están clasificados en la lista):
Proyecto: Imagen Pública 0
Proyecto Métis (5) 1 (4) 4
Proyecto Adrastea (1) 3 (2) 4
Proyecto Tebe (1) 2 (3) 3
Proyecto 10 (2)
Proyecto Europa
Proyecto Ganímedes
Proyecto Calisto
Incluya esta clasificación con las clasificaciones de Ajuste estratégico, Recompensa y
Riesgo; volver a calcular los puntajes de clasificación para los proyectos en función de los cuatro
criterios.
24. Dibuje un gráfico de burbujas para Riesgo versus Recompensa similar a la Figura 18.5 para los proyectos
en la Tabla 2. Suponga que ECV < 3 es "Bajo" y ECV > 6 es "Alto".
Para el riesgo, 1 es "Bajo" y 4 es "Alto". Use las clasificaciones de imagen pública (no clasificaciones)
del problema 23 para "dimensionar" los proyectos en el cuadro: es decir, 4 es el proyecto más grande,
3 es el más pequeño, etc., ¡y 0 es un punto! Según el gráfico de burbujas, ¿qué proyectos son perlas?
¿Cuáles son los elefantes blancos? cuales son

¿pan y mantequilla?
25. La alta dirección ha decidido reasignar fondos entre los cinco
categorías de proyectos listados en la Tabla 18.3 como sigue: $13M, $8M, $7.5M,
10 millones de dólares y 7,8 millones de dólares, respectivamente. ¿Cuáles son los proyectos de corte en cada uno de
las cinco categorías?
26. Explique cómo se pueden usar las cuadrículas de costo-beneficio para clasificar los proyectos.
27. Analice las similitudes y diferencias entre los gráficos de burbujas y el costo.
rejillas de beneficios.
28. Suponga que el Proyecto D se agrega a los proyectos en la Tabla 18.4 y ha sido
clasificada para la eficacia como se muestra en la Tabla 18.5.
Calcule la eficacia ponderada total utilizando los pesos de la tabla 18.4. ¿Cómo funciona Project
D comparar con los otros en la figura 18.8?
29. Una vez que un proyecto ha sido aprobado y admitido a la cartera de proyectos,
¿Cómo se monitorea a partir de entonces? ¿Bajo qué circunstancias podría ser

¿cancelado?
30. Describa las diferencias entre el proceso de gating y la cartera.
administración. ¿Cuáles son las dificultades para integrar los dos procesos?
¿Cómo podrían superarse las dificultades para que los proyectos de la cartera puedan
también ser proyectos cerrados?
Tabla 18.5
Proyecto D
factores mi
Velocidad 80
Rango 90
Eficiencia 95
Comodidad 85
Capacidad 95
masa cargada 90
mantenibilidad 80
Costo $ 2.5 mil millones

1. ¿Cuenta la organización con un proceso de gestión de cartera? Si es así,

describa los pasos clave del proceso y los gerentes y otras personas que
participan en el proceso. En su opinión, ¿es efectivo el proceso? ¿Cuáles son
sus fortalezas y debilidades?
2. ¿La organización tiene gerentes de cartera o PRB (juntas de gobierno, comités
directivos de proyectos, etc.)? Describa sus roles y modus operandi.
3. Describa el proceso de análisis y selección de proyectos de la organización.

¿Qué tipo de modelos y métodos de análisis y selección se utilizan?
4. ¿Cómo se comparan y clasifican los proyectos? ¿Quién hace la aprobación y
decisiones de financiación?
5. ¿La organización tiene un proceso de selección? Describa las puertas, los

criterios de evaluación y enumere quién participa en cada puerta. En su
opinión, ¿es efectivo el proceso?
6. Si la organización tiene tanto gestión de cartera como procesos de selección,
discuta la relación entre los dos y la forma en que están integrados.
7. Si la organización tiene una PMO, analice el papel de la PMO en la gestión de

la cartera y el proceso de selección.
Nota: El Caso 3.3 y el Caso 16.2 están relacionados con los temas de este capítulo.
Caso 18.1 Empresa de Energía Consolidada
Energía Consolidada (CE) es un servicio público que genera y distribuye

electricidad en todo EE. La empresa participa en muchos tipos de proyectos, incluida la

construcción de equipos e instalaciones de generación y transmisión eléctrica, actualización
y reparación de equipos e instalaciones, tecnología de la información para el servicio al
cliente e investigación energética. Gran parte del trabajo de este proyecto se subcontrata,
aunque CE mismo realiza aproximadamente la mitad. La empresa cuenta con unidades de
construcción y especialistas en equipos en cinco regiones, especialistas en tecnología de la
información en tres regiones y unidades de investigación en dos. Las unidades de
investigación trabajan en proyectos iniciados por la oficina corporativa, pero las unidades de
construcción, actualización y mantenimiento de equipos y TI trabajan en proyectos iniciados
por las cinco oficinas regionales. Cada una de las unidades está asignada a una o dos
regiones; cualquier proyecto identificado por una oficina regional se entrega automáticamente
a la unidad de construcción, TI o equipo asignada a la región.
Las decisiones sobre los proyectos se toman a nivel regional y corporativo: los proyectos
que cuestan más de $20 millones se manejan a nivel corporativo; de lo contrario, se
manejan regionalmente. Cada vez que una oficina regional financia un proyecto, primero
decide si la unidad de TI, equipo o construcción de su región puede manejar el trabajo; si
es así, les asigna el trabajo, de lo contrario, contrata el trabajo utilizando el proceso de RFP/
propuesta. Una PRB corporativa toma decisiones para proyectos que superan los 20
millones de dólares. Cuando la PRB aprueba un proyecto, adjudica el trabajo a la unidad
interna asignada a la región que solicitó el proyecto oa un contratista a través del proceso
de RFP/propuesta.
Recientemente, un miembro del PRB tuvo una idea inteligente: ¿por qué no utilizar el
proceso de RFP/propuestas para todos los proyectos, incluidos los que podrían realizarse
internamente? Cuando una oficina regional identifica un proyecto potencial, en lugar de
entregar el proyecto automáticamente a la unidad interna preasignada, envía una RFP a
todas las unidades de TI, construcción o equipos de la empresa.
La unidad con la mejor propuesta obtendría el trabajo, independientemente de su ubicación.
Algunos miembros de la junta se opusieron a la sugerencia, diciendo que pondría unidades
con la misma experiencia en competencia entre sí. Otros argumentaron que no tenía sentido
que, por ejemplo, una unidad de construcción asumiera un proyecto fuera de su región
porque el transporte de equipos y el traslado de equipos de trabajo a sitios de proyectos
distantes aumentarían los costos del proyecto. Otros respondieron que tales argumentos no
tenían sentido porque la competencia entre las unidades
fomentar un trabajo de mayor calidad y reducir los costos corporativos generales.

Pregunta
¿Qué piensas de esta idea? ¿Cuáles son los pros y los contras?
Caso 18.2 Fábrica de cemento propuesta para la

empresa PCS
(Tenga en cuenta que, para este caso, es posible que desee revisar el proceso de carga
frontal (FEL) en el Capítulo 4).
La primera oración en el resumen ejecutivo del borrador del caso de negocios dice: “La
fábrica de cemento propuesta sería la respuesta perfecta al objetivo de la alta gerencia de
hacer crecer la base de productos de PCS sin dejar de ser un productor de materiales de
construcción de bajo costo”. El trabajo geológico realizado como parte del estudio de
factibilidad había apuntado a un sitio que contenía piedra caliza de alta calidad, un recurso
clave en la producción de cemento, que podría explotarse de manera muy económica. El
sitio, que ya era propiedad de PCS, estaba subutilizado y podría albergar adecuadamente
una nueva planta ubicada justo al lado del pozo de piedra caliza propuesto.
Permitió un acceso amplio y rentable a toda la logística y los recursos esenciales, incluidos
otros materiales necesarios para la fabricación de cemento de alta calidad.
El caso de negocios y el estudio de factibilidad también indicaron un alto retorno de la

inversión para el proyecto, muy por encima de la tasa límite establecida por la compañía para
que un nuevo proyecto sea considerado para su inclusión en su cartera de proyectos.
Dada la competencia de la empresa en la producción de cemento, los riesgos técnicos y de
producción se evaluaron como bajos.
Todo parecía estar en orden, y el equipo que proponía el proyecto era optimista en cuanto
a la aprobación de la siguiente fase del proyecto propuesto (FEL-2)
sería una mera formalidad. Presentaron el proyecto de caso comercial a la PMO para su
finalización y a la alta dirección para la autorización de FEL-2. Para su sorpresa, el director de
la PMO insistió en que el equipo debía hacer explícitos todos los supuestos y hacer un análisis
de sensibilidad antes de siquiera considerar leer detenidamente el caso de negocios. Señaló
que el alto precio actual del cemento, como se supuso en el estudio de factibilidad, era el
resultado de una industria de la construcción china en auge que podría disminuir
significativamente en el futuro previsible. Otro miembro de la PMO agregó: “¿Y si
los costos asumidos aumentan y no podemos apegarnos al presupuesto propuesto, como fue
el caso con varios de nuestros proyectos recientes?”
Ver Capítulo 4
Preguntas
1. Explique por qué un caso de negocios debe tener en cuenta alternativas

escenarios para las variables importantes.
2. Enumere los temas o problemas que no se mencionan en el caso pero que deben
considerarse antes de que el proyecto obtenga el visto bueno.
Notas finales
1. Cooper R., Edgett S. y Kleinschmidt E. Gestión de cartera en el desarrollo de nuevos productos: Lecciones de los líderes, fase II.
Research Technology Management, noviembre–diciembre de 1997: 43–52, reimpreso en Dye L. y
Pennypacker J. (eds). Gestión del portafolio de proyectos. West Chester, PA: Centro de Prácticas Comerciales;
1999, págs. 27–33.
2. Sommer R. Gestión de cartera de proyectos: Un nuevo paradigma. 1998. Actas del Proyecto Anual
Seminarios y simposios del Management Institute . Newtown Square, PA: Instituto de Gestión de Proyectos;
reimpreso en Dye y Pennypacker, Project Portfolio Management, págs. 55–59.
3. Esta sección fue adoptada de Cooper et al., Portfolio management in new product development, pp. 34–35;
y Bridges D. Gestión de cartera de proyectos: Ideas y prácticas. En Dye y Pennypacker, Proyecto
Gestión de cartera, págs. 97–116.
4. Levine H. Gestión de cartera de proyectos: ¿una canción sin palabras? Red PM. julio de 1999.
5. Davidson Frame J. La nueva gestión de proyectos. San Francisco, CA: Jossey-Bass Publishers; 1994, pág. 190.
6. Archer N. y Ghasemzadeh F. Un marco integrado para la selección de cartera de proyectos. Internacional
Revista de Gestión de Proyectos 17(4); 1999: 207–216.
7. Sommer, Gestión de carteras de proyectos: Un nuevo paradigma; y Bridges D. Cartera de proyectos
gestión: Ideas y prácticas.
8. Puentes D. Gestión de cartera de proyectos: Ideas y prácticas.
9. La selección de proyectos como embudo se describe en Wheelwright S. y Clark K. Revolutionizing Product
Desarrollo. Nueva York, Nueva York: Prensa libre; 1992.
10. Método descrito en Cooper et al. Gestión de cartera en el desarrollo de nuevos productos: Lecciones de
líderes, fase I. Research Technology Management, septiembre–octubre de 1997, 16–19, reimpreso en Dye y
Pennypacker, Project Portfolio Management, págs. 97—116.
11. Shtub A., Bard JF y Globerson, S. Gestión de proyectos: procesos, metodologías y economía, 2 .
ed. Acantilados de Englewood, Nueva Jersey: Prentice Hall; 2005, págs. 182 y 183.
12. Ibíd., 186–187.
13. Cooper et al., Gestión de cartera en el desarrollo de nuevos productos: Lecciones de los líderes, fase I.
14. Los enfoques de optimización de programación matemática para la selección de proyectos se describen en la literatura .
en la investigación de operaciones. Para ver un ejemplo, consulte Dickinson M., Thornton A. y Graves S. Technology portfolio
management: Optimización de proyectos interdependientes durante múltiples períodos de tiempo. IEEE
Transacciones de Gestión de Ingeniería 48(4); 2001, 5l8–527.
15. Método descrito en Cooper et al., Portfolio management in new product development: Lessons from
líderes, fase I.
16. Ibíd. Los gráficos de burbujas se crean fácilmente con software comercial (busque en Google el término "gráfico de burbujas" para
ejemplos de métodos y productos).
17. Meyer, WG El efecto del sesgo de optimismo en la decisión de terminar proyectos fallidos. Proyecto
Management Journal 45(4), agosto/septiembre; 2014, 7–20.
18. Cooper et al., Gestión de cartera en el desarrollo de nuevos productos: Lecciones de los líderes, fase I.
19. Método descrito en Cooper et, Portfolio management in new product development: Lessons from
líderes, fase II.
20. Frame, The New Project Management, págs. 181–185; Buss M. Cómo clasificar los proyectos informáticos. harvard
Revision del negocio. enero-febrero; 1983.
21. Buss, ibíd.
22. Frame, La nueva gestión de proyectos, p. 185.
23. Resumen del método presentado en Shtub et al., Project Management: Engineering, Technology, and
Implementación, págs. 127–130.
24. Este ejemplo, como otros en este capítulo, es una ilustración muy simplificada. Evaluación de opciones para
el desarrollo de sistemas a gran escala, como aviones, implica estudios de ingeniería para evaluar configuraciones alternativas y
detalles de diseño, además de análisis económicos de desarrollo, adquisición y costos operativos, y proyecciones de ventas
unitarias. Ver, Jenkinson L., Simpkin P. y Rhodes D. Civil Aircraft Design.
Londres: Arnold; 1999.
25. Esta sección fue adoptada de Cooper et al., Portfolio management in new product development: Lessons
de líderes, fase II; y Nelson et al., Building on the stage/gate: Una arquitectura empresarial para el desarrollo de nuevos productos.
26. Sobre la selección de proyectos dependientes, véase Dickinson et al., Technology portfolio management: Optimizing
proyectos interdependientes en múltiples períodos de tiempo.

capitulo 19
Gestión de proyectos internacionales
Considere tres proyectos recientes:
1. General Electric dividió el proyecto de desarrollo de un nuevo dispositivo de

monitorización cardíaca entre dos equipos, uno en Milwaukee y otro en Bangalore. El
trabajo de desarrollo de hardware fue realizado por el equipo estadounidense, el
trabajo de software por el equipo indio. El gerente que los coordinaba tenía su sede
en Milwaukee, pero viajaba con frecuencia a Bangalore. El proyecto requería un
intercambio continuo de personas, equipos, software e información.
2. Bechtel, una corporación estadounidense con divisiones en todo el mundo, supervisó

la construcción de una ciudad industrial completa en Arabia Saudita. Como contratista
principal, gestionó y coordinó el trabajo, los materiales y los principales sistemas in
situ proporcionados por subcontratistas de Europa, EE. UU. y Arabia Saudí. El gerente
de proyecto de Bechtel permaneció en el sitio durante la mayor parte del proyecto,
pero viajó por todo el mundo para reunirse con los gerentes senior de Bechtel y
1 socios contratistas.
3. La División de Aviones Comerciales de Boeing es el principal diseñador, integrador de
sistemas y ensamblador final del avión comercial 787, pero prácticamente todo el
diseño y la fabricación de los principales aviones
Los componentes y subsistemas (alas, secciones del fuselaje, motores e

instrumentación) son realizados por proveedores contratados en Japón, Canadá,
España, Italia y EE. UU. La oficina de gestión de programas de Boeing en el estado
de Washington dirige la supervisión y la integración de los proveedores y otras
divisiones de Boeing que contribuyen al programa.
La similitud obvia entre estos proyectos es que tienen un alcance "internacional" o "global".
A diferencia de los proyectos nacionales de un solo país, en los que la mayoría o todas las
partes interesadas y el trabajo del proyecto se limitan a un país, las partes interesadas en
estos proyectos son transnacionales e interculturales, y el trabajo del proyecto se lleva a
cabo en diferentes países.
19.1 Proyectos Internacionales
Los proyectos internacionales se han vuelto omnipresentes a medida que más empresas
establecen divisiones, buscan clientes y subcontratan el trabajo a proveedores y
contratistas en diferentes países. Gracias en gran parte a los costos más bajos y la
mayor capacidad del transporte aéreo y marítimo global, las tecnologías de comunicación
mejoradas impulsadas por Internet y las capacidades tecnológicas y comerciales
emergentes en países como China, Brasil e India, las empresas buscan y ejecutan
proyectos en todas partes.
Si bien tales proyectos son atractivos debido a los beneficios y oportunidades que
conlleva operar a escala internacional, al mismo tiempo son vulnerables a un riesgo
considerable. Independientemente del alcance o el elemento final, un proyecto que es
"global", "internacional" o "en el extranjero" hereda automáticamente más problemas y
un mayor riesgo que uno que no lo es. E independientemente de las cuestiones y los
problemas que enfrenta el gerente de un proyecto nacional de un país, el gerente de un
proyecto internacional enfrenta automáticamente una "capa adicional" de problemas.
Esa capa adicional toca casi todo lo relacionado con la gestión: liderazgo, relaciones
interpersonales, partes interesadas, comunicación, definición del trabajo, estimación,
gestión de riesgos y seguimiento y control del trabajo. El idioma, la comunicación, las
costumbres locales, el transporte y la infraestructura (todas de poca o ninguna
importancia en un proyecto del país de origen) se convierten en factores importantes en un proyecto in
2
19.2 Problemas en la gestión de proyectos internacionales
Cada nuevo proyecto internacional plantea una nueva serie de incógnitas. Para ilustrar, piense
en un proyecto internacional como algo análogo a una obra de teatro con actores, guiones,
decorados y accesorios. Los actores son las partes interesadas del proyecto y las redes sociales,
los guiones son las instituciones sociales que guían y restringen el comportamiento de las
personas, el escenario es el lugar de trabajo del proyecto y los accesorios son las tecnologías del
proyecto. Así como los actores, los guiones, los escenarios y la utilería difieren en cada obra,
también difieren las partes interesadas, las instituciones, la ubicación del sitio y las tecnologías
en cada proyecto internacional. Tales diferencias exponen el proyecto a posibles errores y
descuidos en la organización, planificación y ejecución.
La tabla 19.1 enumera los aspectos de un proyecto internacional que tienden a dificultar su
planificación y ejecución; algunos son “explícitos”—algo fáciles de identificar y contabilizar en los
planes y estimaciones del proyecto, otros son “tácitos”—más difíciles de aislar y abordar. En
general, cuanto más “desconocidos” sean el país anfitrión y su gente para el director del proyecto
y los miembros del equipo, más difícil será para ellos planificar y ejecutar el proyecto. En adelante,
“anfitrión” se refiere al lugar donde se ejecuta el proyecto; “domicilio” al país de origen del
contratista, desarrollador o director del proyecto. La ignorancia sobre las incógnitas hace que sea
difícil anticipar problemas, establecer prioridades y actuar adecuadamente. Es por eso que los
proyectos internacionales a menudo tienen problemas para cumplir con los compromisos de
cronograma, presupuesto o requisitos.
Tabla 19.1 Incógnitas en un Proyecto Internacional
1. Instituciones y cultura locales
a) Lenguaje (explícito) b)
Normas, costumbres sociales, actitudes tradiciones (tácito)
c) Leyes, reglas, derechos, sanciones (explícito)
2. Partes interesadas locales: trabajadores, gerentes, consultores, proveedores
(tácito) a) Habilidad, experiencia, motivación b) Reputación, honestidad,
integridad c) Quién sabe quién; que tiene conocimientos, recursos y conexiones
3. Entorno natural local (explícito) a)

Entorno del sitio: suelo, pendiente del terreno,
vegetación b) Entorno regional: clima, tiempo, geografía, actividad sísmica
4. Tecnología local (explícito)
a) Infraestructura: caminos, edificios, comunicación b)
Herramientas y sistemas disponibles: GPS, equipos, hardware, software,
materiales.
Nota: “Local” se refiere a personas y factores situados en el lugar o región del proyecto, o que se vuelven
activadas en el contexto local, incluidas las ONG, asociaciones y otras organizaciones internacionales que
desempeñan un papel en la “promulgación de normas y reglamentos ambientales, tecnológicos, ocupacionales y legales” para el
nivel local. 3
19.3 Instituciones locales y cultura
Las partes interesadas en proyectos internacionales abarcan diferentes idiomas y culturas que
influyen en la comunicación, las actitudes, el comportamiento, las prácticas laborales, los patrones
de decisión y, en última instancia, el desempeño del proyecto. Además, están guiados o restringidos
por leyes, reglamentos y normas regionales o nacionales.
Cultura
La cultura se refiere al conjunto de valores, creencias, comportamientos y actitudes que tienden a

compartir los miembros de un grupo, organización, país o región. Entre las muchas formas de medir
la cultura se encuentra un estudio frecuentemente citado de Hofstede sobre los empleados de IBM
en más de 50 países. El estudio identificó cinco dimensiones de la cultura. 3
• Distribución de energía (PD). La medida en que los miembros menos poderosos de una
cultura aceptan o esperan que el poder se distribuya de manera desigual, frente a sentir
que el poder debería distribuirse por igual. Las personas de países con alta DP tienden a
tener en alta estima a sus superiores o líderes y no cuestionan sus directivas o acciones. •
Individualismo (IND). La medida en que los miembros de una cultura creen que se espera
que se cuiden a sí mismos en lugar de ser parte y atendido por un grupo al que son leales. •
Orientación al logro (ACH). La medida en que los roles se distribuyen a lo largo de las líneas
de género: "masculino", que implica una orientación asertiva, dura o de logro, frente a
"femenino", que implica una orientación más relacional, de ayuda o de calidad de vida. Las
personas de países con ACH alto se preocupan más por las ganancias y las señales de
éxito; los de países de ACH más bajos se preocupan más por compartir, cooperar y cuidar
a los demás.
• Evitación de la incertidumbre (UNA). La medida en que los miembros se sienten incómodos

con situaciones inciertas o ambiguas y necesitan tomar medidas para imponer orden y
estructura, en lugar de aceptar la incertidumbre o
ambigüedad. Las personas de países con una ANU baja se sienten más cómodas con
la ambigüedad y se sienten menos incómodas en ausencia de planes detallados y
funciones y responsabilidades de equipo formalizadas.
• Orientación a largo plazo (LTO). La medida en que los miembros buscan beneficios a
largo plazo y resultados o gratificaciones diferidos, en lugar de buscar resultados y
gratificaciones inmediatos o a corto plazo.
La investigación de Hofstede mostró diferencias considerables en estas dimensiones por país: la

Tabla 19.2 brinda algunos resultados. Los valores más grandes implican la tendencia a aceptar
la distribución desigual del poder, ser individualista, buscar el logro y ser masculino, más cómodo
con la incertidumbre y orientado a largo plazo; los valores más pequeños implican lo contrario.
Para un proyecto con miembros del equipo en diferentes países, las diferencias en estas
dimensiones pueden merecer atención. Por ejemplo, un equipo de proyecto con miembros
ubicados en el Reino Unido, EE. UU. y China podría esperar diferencias en términos de PD, IND,
UNA y LTO. Según la tabla, es más probable que los miembros del equipo en China acepten las
diferencias de autoridad que los de EE. UU. y el Reino Unido; también es probable que estén
más dispuestos a "mezclarse" en el equipo y no quieren ser señalados como individuos que
como miembros en los EE. UU. o el Reino Unido. Los miembros del equipo estadounidense
posiblemente se sientan un poco más cómodos con la incertidumbre o la ambigüedad que sus
colegas del Reino Unido o China; y los miembros en China probablemente estarán menos
influenciados por las ganancias e incentivos a corto plazo que los del Reino Unido o los EE. UU.
Cualquiera de estos podría dar lugar a diferentes respuestas a las expectativas de gestión por
parte de los miembros de diferentes países.
Un peligro con hallazgos como este es la tentación de generalizar aunque, por supuesto, las
personas son únicas y no necesariamente se ajustan al promedio. Algunos han criticado los
hallazgos por una serie de razones, incluida la metodología y la base. Sin embargo, el hecho es
4
suposiciones que las personas en diferentes regiones y
los países difieren, lo que puede ser un desafío cuando tienen que trabajar juntos.
Si bien los desafíos pueden ser significativos incluso entre los trabajadores de diferentes países
desarrollados, se exacerban cuando la fuerza laboral combina miembros de países desarrollados
y países en desarrollo (también conocidos como economías emergentes).
Cuadro 19.2 Dimensiones culturales de Hofstede: resultados representativos

Como cualquier desafío, la solución comienza con ventilar las diferencias, y eso puede
suceder como parte de una sesión de trabajo en equipo. Como se describe en el Capítulo 16,
uno de los propósitos de la creación de equipos es que los miembros reconozcan sus
diferencias (en este caso, sus valores, sistemas de creencias y expectativas) y desarrollen
pautas de comportamiento que superen esas diferencias. Además de la formación de equipos,
la gestión de proyectos debe buscar fortalecer las relaciones interpersonales, la confianza y el
respeto mutuo, todo lo cual tiende a reducir los estereotipos y generar cohesión en los
proyectos de equipo.
Cabe destacar que la cultura nacional a veces importa menos a las personas que la cultura
de su profesión o sus intereses personales. Esto dice, por ejemplo, que un ingeniero de
software indio podría sentirse más en común con un ingeniero estadounidense que con su
compañero indio promedio. 5 Un gerente
desarrollar
de proyecto
“comunidades
podría aprovechar
de práctica”
tal afinidad
para superar
al las
diferencias culturales y construir la unidad del equipo.
Ver Capítulo 16
Idioma
Cuando las partes interesadas del proyecto hablan diferentes idiomas, las conversaciones y
los documentos compartidos del proyecto, como el alcance, los requisitos, los presupuestos y
los contratos, deben traducirse. El desafío es asegurarse de que cada traducción refleje fielmente
el contenido y la intención del mensaje original.

Incluso los proyectos en los que aparentemente todos usan el mismo idioma enfrentan
dificultades. Por ejemplo, las mismas palabras en inglés cuando se usan en Estados Unidos,
el Reino Unido, Sudáfrica, Australia e India pueden tener significados diferentes; agregue a
esa jerga, vernáculo, términos idiomáticos y mala dicción, y el resultado es que el mensaje
se “pierde en la traducción”. Por ejemplo, “dile a los ingleses que caminen sobre la acera y
caminarán sobre lo que los estadounidenses llaman la acera; dígales a los estadounidenses
que caminen sobre la acera, caminarán por el medio de lo que los ingleses llaman asfalto”.
6 Los gerentes estadounidenses
británicos quesuelen decir
con los que es más difícil comunicarse con los
franceses.
La mejor práctica en la comunicación internacional es utilizar siempre las palabras y

frases más sencillas y concisas. Antes de enviar mensajes y documentos importantes, pida
a varias personas que los interpreten. Napoleón hizo algo como esto: antes de emitir órdenes
militares, siempre hacía que un cabo las leyera, razonando que si alguien de bajo rango
podía entenderlas, ciertamente también lo harían sus oficiales. 7 A menudo, los lugareños
afirman que entienden inglés cuando, de hecho, su comprensión del mismo es pobre en el
mejor de los casos. Cuando salpican sus respuestas con “sí, sí, sí”, es seguro que no
entienden lo que se dice. Al dar directivas verbales, siempre sígalas por escrito.
El gerente de un proyecto en el extranjero debe aprender al menos lo suficiente del idioma

local para realizar transacciones diarias simples. Hacerlo también muestra respeto por las
personas del país anfitrión, que aprecian los intentos de los visitantes (quizás torpes) de
comunicarse en el idioma local.
Los gerentes a veces crean un glosario de términos del proyecto que puede ser extenso
e incluso puede incluir imágenes. Para el proyecto de la década de 1960 para desarrollar el
avión supersónico Concorde anglo-francés, se creó un diccionario de proyecto especial
francés-inglés.
Formalidad
Mientras que los socios comerciales en América del Norte tienden a dirigirse entre sí:
subordinados, superiores inmediatos e incluso altos directivos, por nombre,

la mayoría de las demás partes del mundo usan alguna variante de señor, señor o señora. Tal
formalidad se extiende a la forma en que las personas se presentan, comunican ideas, se
comprometen y dan y reciben tarjetas de presentación. El código de conducta del lugar de trabajo
puede desalentar las bromas y otras formas de informalidad. La formalidad también se aplica a
los documentos: mientras que las propuestas y los contratos nacionales suelen enviarse por fax,
correo electrónico o comunicarse verbalmente, tales prácticas en proyectos internacionales
plantean interrogantes sobre el país donde se realizan los acuerdos o se concluyen los contratos
y, por lo tanto, la ley de contratos y el tribunal de quién. de ley se aplica.
En algunas áreas del mundo, las prácticas de poca importancia en otros lugares se elevan a
un gran arte. En Japón, por ejemplo, el intercambio de tarjetas de visita es una parte esencial de
la etiqueta empresarial y comprende, lo que equivale a, una "ceremonia" de tarjetas de visita.
Actitudes sobre la edad
Muchas culturas asocian la sabiduría con la edad. Las personas mayores obtienen
automáticamente mayor respeto, reverencia y credibilidad que los gerentes más jóvenes,
independientemente de su experiencia. Los gerentes en posiciones senior siempre son mayores
(y generalmente hombres) y tienden a ignorar o evitar a cualquier persona mucho más joven que
ellos. En las reuniones, los gerentes mayores son los que más hablan y los gerentes más jóvenes
evitan contradecirlos, incluso cuando no están de acuerdo.
Comportamiento social
En los países del Medio y Lejano Oriente, la mayor parte de la construcción de relaciones e
incluso negocios formales se lleva a cabo fuera del horario laboral en reuniones sociales. Lo que
se considera una conducta adecuada está dictado por las normas locales aunque, en general, se
considera inapropiado cualquier signo de embriaguez, confraternización, vestimenta descuidada
o demasiado informal, o compartir detalles personales sobre familiares o amigos. El
comportamiento que se consideraría adecuado o incluso esperado en otros lugares, como llevar
a un cónyuge a una reunión o hablar con el cónyuge de otra persona, podría ser vergonzoso y
potencialmente arruinar una relación comercial.
Por supuesto, siempre se debe evitar el comportamiento y la vestimenta ofensivos, aunque
lo que se considera ofensivo varía según el país. En el Medio Oriente, la cabeza de una mujer
debe cubrirse en público, y se supone que los hombres y las mujeres no deben saludarse
dándose la mano. La gente en Roma tiende a vestirse más elegantemente que, digamos, en
las ciudades de los EE. UU., y un turista de los EE. UU. que no llamaría la atención en casa
podría parecer un poco desaliñado en Roma. Cuando se trabaja en Roma (o Beijing o Mumbai),
una buena regla general es adoptar algunas de las costumbres locales de vestimenta y
comportamiento (suponiendo que no violen un código de ética personal o universal).
Esto se aplica a todo tipo de comportamiento, incluida la entrega de obsequios, que en

muchos países se considera una forma adecuada de mostrar gratitud, pero en otros países
está prohibido. Ciertos obsequios se consideran aceptables, otros no, y la discreción es
necesaria para evitar violar las costumbres locales de etiqueta o las leyes.
Comida y bebida
Los expatriados recién llegados a menudo escanean los menús locales en busca de elementos
familiares, sin saber que los alimentos enumerados no serán los mismos que en casa. Las
franquicias de restaurantes en el hogar o conocidas son más confiables y, a veces, brindan
una familiaridad bienvenida. Las porciones de carne en Europa y Asia tienden a ser pequeñas,
minúsculas para los estándares estadounidenses. La carne y los martinis pueden no estar en
el menú, o en cualquier menú en cualquier parte del país, e incluso preguntar por ellos es
completamente inapropiado. La regla general con respecto a la comida y la bebida, pero
aplicable a todo lo relacionado con las costumbres locales, es ser respetuoso, educado y
tolerante, incluso cuando las costumbres no se adapten a su gusto o predisposición.
Actitudes sobre el tiempo
En algunos países occidentales la puntualidad lo es todo. El tiempo es visto como un recurso

limitado, y ser puntual asegura que nunca se desperdicie. ¡Las personas que vacilan o llegan
tarde se consideran groseras y desconsideradas con el tiempo de los demás! Pero en el Medio
y Lejano Oriente y la mayor parte de África, el concepto de tiempo se ve de manera diferente:
más importante que hacer las cosas puntualmente es asegurarse de que se hagan bien. Si se
necesita tiempo para preparar un plan y luego revisarlo y revisarlo de nuevo, que así sea, incluso si
el horario se desliza. Un gerente occidental acostumbrado a llenar cada minuto con trabajo se
molestará por las muchas reuniones de "pérdida de tiempo" organizadas por sus socios comerciales
asiáticos o del Medio Oriente; ellos, a su vez, se sentirán insultados por su angustia por continuar
con los negocios y cuestionarán sus motivos y su lealtad hacia ellos.
Días festivos, fines de semana, vacaciones
Cada país tiene sus propias vacaciones no laborales. Estados Unidos tiene siete días festivos
nacionales; la mayoría de los países europeos tienen, pero Alemania tiene 16. Un proyecto que
involucre a participantes de, digamos, cuatro países, cada uno con cinco días festivos nacionales,
posiblemente podría enfrentar 20 días de inactividad por vacaciones. Las festividades del Ramadán
y el Año Nuevo chino afectan los cronogramas de muchos proyectos. Incluso cuando diferentes
condados comparten los mismos días festivos, las fechas exactas pueden diferir. El feriado de
Navidad se extiende en los EE. UU. del 23 de diciembre al 2 de enero, pero en Rusia y algunos
países de Europa del Este es del 31 de diciembre al 8 de enero, a veces más tarde. En el hemisferio
sur, las vacaciones de verano caen en diciembre y, a veces, detienen el trabajo del proyecto durante
la mayor parte del mes. El “fin de semana” en muchas partes del mundo es el sábado y el domingo,
pero en el Medio Oriente es el viernes y el sábado. Si bien estas diferencias crean problemas para
algunos proyectos, ofrecen oportunidades para otros al permitir que el trabajo continúe en diferentes
lugares del mundo los siete días de la semana.
El tiempo libre de vacaciones también varía según el país y la región. Mientras que en los EE. UU.
las vacaciones de dos o tres semanas son estándar, la ley australiana prescribe cuatro semanas, al
igual que la Unión Europea, generalmente todo el mes de agosto. Algunos países exigen por ley seis
semanas de vacaciones más otras seis por enfermedad.
Tiempo de trabajo
Lo que constituye un día de trabajo y una semana de trabajo "habituales" también varía. La ley
francesa ordena y hace cumplir una semana laboral de no más de 35 horas, y la ley china especifica
una semana laboral de cinco días de 8 horas. Las leyes laborales no siempre se cumplen, pero
ningún director de proyecto de ningún país debería apostar a violarlas.
Las normas sociales también importan. Si la cultura local dicta que la “jornada de trabajo” es entre
6 am y 2 pm, el gerente de un proyecto de 9 a 5 probablemente verá que su fuerza laboral local

se queda dormida alrededor de las 3 pm.
Despidos
Aunque comúnmente en los EE. UU. los empleados son despedidos cuando finaliza un proyecto
y no hay trabajo de seguimiento, en algunos países dicha terminación no es automática,
especialmente para los trabajadores que sirvieron 12 meses continuos en el proyecto. ¿Qué
debe hacer un gerente con estos empleados? En muchos países europeos, las leyes laborales
dictan a quién puede despedir un empleador y cómo debe hacerlo. Según David Pringle, del
Career Journal Europe, las decisiones de despido de los empleadores alemanes deben ajustarse
a criterios sociales que a veces los obligan a “retener personal de mayor edad, con familias
numerosas y que pueden encontrarlo muy 8 Los empleadores franceses a menudo deben “dar
progreso de los programas deinformes
reducción
detallados
de personal
en difícil
a las conseguir
autoridades
nuevos
estatales”.
trabajos.” el
Leyes, Contratos, Derechos
La ley vigente para un proyecto es la ley del país anfitrión, no la del país de origen del
desarrollador o contratista, aunque los contratistas de EE. UU. que trabajan en el extranjero
también deben cumplir con la ley de EE. UU. y el truco es no violar las leyes de ninguno de los
dos países. . La Ley de Prácticas Corruptas en el Extranjero, por ejemplo, prohíbe que los
contratistas estadounidenses participen en sobornos, aunque la práctica es bastante común en
muchas partes del mundo.
En países como China, las reglas no siempre se hacen cumplir y los contratistas y clientes
locales pueden decirle simplemente que las ignore (por supuesto, arriesgando la posibilidad de
que en cualquier momento se hagan cumplir las reglas ) . Una práctica segura es verificar lo que
dicen los lugareños sobre la ley y nunca hacer nada ilegal.
Debido a las diferencias en el idioma, las formalidades, la terminología, los reglamentos y las
leyes, los contratos internacionales tardan más en finalizar que los contratos nacionales.
Tener la redacción y la terminología correctas en los contratos es extremadamente importante,
e incluso los detalles más pequeños (como los cambios de iniciales y las páginas) son
importantes. El director del proyecto debe participar en las negociaciones del contrato desde el principio y:
esto es esencial: tener acceso en el país de acogida a su propio asesor legal oa un buen
asesoramiento legal.
Para minimizar la confusión sobre la terminología de los contratos, la Cámara de Comercio
Internacional ha creado una lista de Términos Comerciales Internacionales, o "Incoterms",
descritos en su sitio web como "definiciones comerciales estándar que se usan más
comúnmente en los contratos de ventas internacionales... (y) en el corazón de comercio
mundial." El uso de Incoterms en los contratos ayuda a aclarar las expectativas y “contribuye
en gran medida a proporcionar la seguridad jurídica en la que se debe basar la confianza
mutua entre los socios comerciales”. 9
El contratista debe asegurarse de incluir estipulaciones y acciones en el contrato para
proteger sus derechos intelectuales y estar preparado para tomar medidas si descubre que
sus ideas, productos o tecnología están siendo pirateados.
Litigio, Pago, Cumplir Términos de Contrato
La contratación en proyectos internacionales es un tema completo en sí mismo y más allá del

alcance de este libro. Mientras que algunos proyectos emplean contratos de formato estándar
(por ejemplo, FIDIC o NEC; consulte la nota 10, Capítulo 5), muchas empresas grandes
preparan sus propios contratos. En general, los contratos deben diseñarse para evitar
disputas legales, que en el ámbito internacional pueden ser una pesadilla: desordenadas,
lentas, costosas y, a veces, corruptas. Deben especificar que cualquier disputa legal se
litigará en un país neutral, es decir, ni el anfitrión ni el país de origen del contratista. Los
contratistas estadounidenses a menudo especifican Inglaterra.
Ver Capítulo 5
Cada contrato debe proporcionar estipulaciones para asegurar que el cliente recibirá sus
entregables y el contratista su pago. Esto parecería habitual incluso en proyectos nacionales
de un solo país, pero debido a las extremas dificultades de los litigios en proyectos
internacionales, las estipulaciones deben ser tales que eliminen incluso la más mínima
posibilidad de problemas. El contrato podría imponer multas severas por no cumplir con los
cronogramas o requisitos, y ofrecer fuertes incentivos para excederlos (dichos incentivos
asumen que el contratista está en el
posición para realizar el trabajo para cumplir con los requisitos, lo que no siempre es el caso en
los países en desarrollo).
Para proteger al contratista, el contrato puede especificar un primer pago grande seguido de
pagos al cumplir objetivos frecuentes con fases de tiempo. Los pagos a menudo se retrasan,
no por el cliente, sino porque la transferencia internacional de fondos generalmente requiere la
aprobación de una agencia del país anfitrión, lo que puede demorar 60 días. En ocasiones, los
pagos a extranjeros deben realizarse a través de agentes fiscales, lo que complica aún más el
proceso de pago.
Por lo general, los contratistas nunca deben realizar trabajos por un pago no garantizado
después de la finalización del proyecto. En muchos países, incluida China, el sistema para
administrar el crédito y las cuentas por cobrar no es muy bueno y es difícil determinar la
solvencia del cliente.
Política
La estabilidad política nacional y local y la posición del gobierno con respecto al proyecto son
factores de riesgo potenciales. Las huelgas laborales radicales, la reforma política, el
derrocamiento del gobierno, la intervención militar local y el terrorismo son claramente
situaciones que amenazan un proyecto. Si bien fenómenos como las huelgas laborales son
raros en países como los EE. UU., son comunes en otros lugares. Pero tales eventos rara vez
se materializan con poca antelación y sin señales de advertencia. Un contratista en un proyecto
internacional debe tener personas confiables en la región anfitriona para monitorear estos
signos y mantener informada a la gerencia del proyecto.
Debería ser obvio a partir de esta discusión que los proyectos internacionales están plagados
de problemas ausentes en los proyectos de una sola nación. El siguiente ejemplo ilustra
problemas adicionales, además de lo que sucede cuando los equipos transculturales ignoran
la integración.
Ejemplo 19.1 El Proyecto Canal10

La fase inicial de construcción del Túnel del Canal de la Mancha de 51 km (32 millas)
entre Gran Bretaña y Francia se manejó casi como dos proyectos separados: uno
partiendo de Gran Bretaña y el otro de Francia, ambos compitiendo para ver cuál
llegaría primero a la mitad del camino. Se pensaba que la competencia aceleraría

las cosas. Pero los equipos representaban dos culturas diferentes y la competencia
solo agravó las diferencias y exacerbó los problemas.
Para empezar, lo ideal es que los contratos se escriban en un idioma y se rijan
por un sistema legal, pero el proyecto Chunnel tenía dos contratos, uno en inglés
y otro en francés, y ninguno tenía precedencia sobre el otro. Aunque los contratos
supuestamente se basaban en principios comunes a los dos sistemas legales, los
enfoques legales sobre salud, seguridad, sindicatos e impuestos diferían
significativamente, y un panel designado para resolver disputas a menudo se
enfrentaba a la situación de tener que tomar decisiones difíciles.
Los dos países también difieren en cuanto a las normas relativas, por ejemplo,
a las locomotoras y los vagones, el ancho de vía, los voltajes y los sistemas de
señalización, aunque, claramente, en todos los casos tendría que haber uno solo.
Se decidió que donde existiera una diferencia entre los estándares de los dos
países, debería prevalecer el más alto, aunque no siempre era obvio qué estándar
era el más alto (por ejemplo, la forma de verter el concreto).
Las decisiones de un gobierno democrático pueden requerir una deliberación
sustancial, pero las decisiones de dos gobiernos democráticos requieren aún más
deliberación. Decidir simplemente si aumentar el ancho de la puerta de 600 mm a
700 mm tomó 9 meses.
19.4 Partes interesadas locales
Contratistas11
Los equipos de proyectos que operan en países extranjeros a menudo deben contratar
contratistas locales. Aunque la subcontratación de contratistas locales puede reducir los costos
de mano de obra y reubicación, puede aumentar los costos de capacitación y supervisión. A
veces, un costo laboral más bajo equivale a una productividad más baja, lo que se traduce en
la necesidad de más trabajadores, borrando así cualquier ahorro potencial (muchos países
como India, sin embargo, tienen costos laborales bajos pero una productividad tan alta como
en las naciones occidentales). Un contratista local que esté familiarizado con las costumbres y
la burocracia locales a veces puede eliminar los trámites burocráticos y evitar molestias que
obstaculizarían a un contratista externo.
La selección de un contratista local va más allá de los criterios habituales de habilidad,
experiencia, recursos y estabilidad financiera. Una consideración es la calidad probable de las
comunicaciones del contratista según lo determinado por el idioma y la cultura. Otro es la
familiaridad del contratista con las prácticas comerciales comunes. Las prácticas que se dan
por sentadas en la mayoría de los países (p. ej., RFP, propuestas, SOW, controles de cambios
e informes de estado) pueden ser desconocidas para un contratista local y un reto para su
adopción. También es importante la reputación ética del contratista ("ética" según se define
según los estándares occidentales, no los estándares locales). Aunque tal vez sea difícil de
realizar, una revisión de diligencia debida del historial comercial del contratista, su reputación
de honestidad y sus conexiones políticas es, no obstante, una necesidad.
Clientes y simpatizantes
Las buenas relaciones con clientes y simpatizantes siempre son importantes, pero más aún en
proyectos internacionales. En general, mientras que los occidentales tienden primero a
establecer acuerdos contractuales y luego construyen relaciones, los orientales primero
construyen relaciones y luego llegan a acuerdos. Independientemente de la trayectoria
profesional del director del proyecto y su empresa, empresas locales, subcontratistas,
los proveedores y los clientes potenciales tienden a negarse a aceptar, colaborar o brindar apoyo
hasta que sientan que conocen personalmente al gerente del proyecto. Construir relaciones
personales y confianza con colegas y asociados comerciales es fundamental para el proceso
comercial.
Ejemplo 19.2 Cómo arruinar una

relación comercial 12
Las negociaciones entre una empresa estadounidense y una empresa de la India para
finalizar el contrato de un proyecto prometedor comenzaron con una serie de reuniones informales.
Poco después de llegar a la India, el gerente de proyecto estadounidense sintió que sus
clientes se estaban demorando innecesariamente, por lo que trató de animarlos. Pero cuanto
más lo intentaba, más dudaban los indios de sus motivos y menos confiaban en él. Como es
su costumbre, habían planeado retrasar las conversaciones serias hasta después de
familiarizarse con el estadounidense, un proceso de construcción de confianza destinado a
ocurrir durante unos días de cenas y reuniones sociales. El gerente del proyecto, sin embargo,
esperaba que las conversaciones serias comenzaran poco después de su llegada y
concluyeran después de no más de unos pocos días. Debido a que las negociaciones se
realizaron en inglés y la mayor parte del trabajo del proyecto debía ser realizado en los EE.
UU. por un equipo de los EE. costumbres; en otras palabras, lo arruinó.
Las negociaciones fracasaron y el técnico voló a casa sin contrato.

19.5 Cuestiones geonacionales
Muchos problemas relacionados con los proyectos internacionales surgen del simple hecho de
que las partes interesadas están dispersas en diferentes naciones o regiones geográficas.
Riesgo cambiario y moneda
Las oscilaciones económicas que alteran los tipos de cambio y los valores relativos de las
monedas ponen en riesgo los costos, los ingresos y las ganancias del proyecto. Por ejemplo, el 6
de diciembre de 2015, el rand sudafricano se negoció a R14,35/$US; el 12 de diciembre cayó a
R15.89; y el 12 de enero de 2016 cotizaba a R16.16. Para cualquier proyecto sudafricano que
dependiera de artículos importados, este cambio en el tipo de cambio podría haber planteado serias
consecuencias.
Para proteger el valor de su trabajo contratado, un contratista debe exigir el pago en términos
de su moneda local (por ejemplo, dólares estadounidenses para un contratista estadounidense),
aunque debe decirse que la mayoría de los contratos internacionales se celebran en dólares
estadounidenses. Es probable que los clientes acepten esto para proyectos de corta duración,
aunque no necesariamente para proyectos más largos debido al mayor riesgo de un cambio
significativo en los tipos de cambio. Por supuesto, el asunto es discutible a menos que el gobierno
anfitrión otorgue al cliente el derecho legal de pagar el proyecto en moneda extranjera.
Ejemplo 19.3 Impacto del cambio en el tipo de cambio de

moneda
Un contratista francés acepta hacer un proyecto en Francia para un cliente estadounidense.

El contratista estima que el proyecto costará 900.000 € y, para obtener una buena ganancia,
fija el precio del proyecto en 1.000.000 €. Para acomodar al cliente, el precio del contrato
se establece en dólares. En el momento de la firma del contrato el tipo de cambio es de 1,3
$ por euro, de ahí el precio especificado en el contrato
es de 1.300.000 dólares estadounidenses.
Muchos meses después el proyecto está terminado y la obra acaba costando 900.000€
como estaba previsto. El cliente paga el precio acordado de $1.300.000, pero el tipo de
cambio ha cambiado y ahora es de $1,4 por euro. Siendo así, el pago equivale a 1.300.000
$/1,40 = 928.571 €. En lugar de unos limpios 100 000 €, el contratista gana solo € (900 0000
ÿ 928 571) = 28 571 €. Una forma alternativa de ver esto es decir que el aumento de la tasa
$/€ llevó a un aumento en el gasto en dólares del proyecto (de 900 000 € (1,3) = 1 170 000
$ a 900 000 € (1,4) = 1 260 000 $). Se mire como se mire, el contratista obtuvo menos
ganancias.
Una forma de reducir el riesgo cambiario es fijar en el contrato el precio de hoy por un pago que
no ocurrirá hasta más tarde. Llamada cobertura de transacciones esperadas en moneda extranjera,
esto protege el flujo de efectivo futuro contra fluctuaciones negativas de la moneda. El precio fijo a
plazo refleja la diferencia en las tasas de interés entre los países del cliente y del contratista .
que ambas partes acuerden y especifiquen el tipo de cambio en el contrato. El monto
reducir
delel pago
riesgoestá
es
determinado por la tarifa establecida en el contrato, no la tarifa en el momento del pago. Una
tercera forma, y la más común, de reducir el riesgo cambiario es "cobertura a plazo", o transferir el
riesgo de un cambio desfavorable en el valor de la moneda a una compañía de seguros.
Compensaciones 14
Los contratistas extranjeros en grandes proyectos financiados por el gobierno a menudo están
sujetos a requisitos relacionados con el gasto en el país anfitrión llamados "compensaciones" o
comercio de compensación. Por ejemplo, se le puede solicitar al contratista que gaste un porcentaje
del costo del proyecto en mano de obra local, materiales o productos suministrados localmente,
líneas aéreas locales y servicios de transporte, y subcontratistas locales. Las compensaciones
como estas que están vinculadas directamente a las actividades del proyecto se denominan
"compensaciones directas". Otra forma, denominada “compensación indirecta”, requiere que el
contratista contribuya a actividades ajenas al proyecto, como empresas comerciales o mejoras a
carreteras, comunicaciones u otra infraestructura, con el propósito de reducir el monto neto de los pagos que salen
el país. El valor de la compensación puede variar desde un pequeño porcentaje hasta más del costo
total del proyecto. A veces, el truco es que el contratista cumpla con el requisito de compensación y aún
así obtenga una ganancia.
Los requisitos de compensación se especifican en la RFP y, a veces, un contratista gana el trabajo
basándose principalmente en el plan de compensación descrito en la propuesta. En esencia, la
compensación es el factor decisivo, superando en importancia el trabajo principal del proyecto.
Restricciones de exportación/importación
La exportación/importación de cierta tecnología, software y hardware de EE. UU. está regulada por
agencias gubernamentales como los Departamentos de Comercio, Estado y Agricultura de EE. UU. Al
principio del proyecto, los diseñadores de sistemas y los planificadores del proyecto deben identificar los
elementos que son esenciales para el proyecto pero cuya importación/exportación está restringida o
prohibida; estos elementos deberán ser sustituidos por alternativas no restringidas.
Zonas horarias
Es posible que las partes interesadas del proyecto ubicadas en diferentes zonas horarias no tengan
horarios comerciales normales superpuestos, y los mensajes entre ellos pueden tardar días en leerse o
responderse. Evitar demoras en la comunicación es en gran medida una cuestión de planificación, como
programar las horas de trabajo en las zonas para permitir la superposición de 2 a 3 horas y garantizar el
fácil acceso del gerente del proyecto y otros participantes clave a través de mensajes de teléfono celular
y correo electrónico durante las etapas críticas de el proyecto.
En proyectos que requieren viajes frecuentes a través de múltiples zonas horarias, jet lag
los gerentes y los miembros del equipo necesitan más tiempo para ponerse al día.
19.6 Gerente de Proyecto
15
Problemas típicos en un proyecto internacional:
• Los miembros del equipo necesitan visas
de viaje. • Alguien en el equipo del proyecto no tiene un pasaporte válido. •

Alguien del equipo necesita pruebas de salud e inoculaciones antes de dirigirse a
el sitio del proyecto.
• Alguien se enferma o lesiona en el sitio del proyecto. •
Alguien es arrestado por una infracción de tránsito local.
En momentos como estos, el primer lugar al que acude la gente es al director del proyecto, esperando
que sea capaz de manejar la situación personalmente o sepa dónde obtener ayuda.
Mientras se ocupa de estos problemas, el director del proyecto debe seguir ocupándose de los
problemas relacionados con el proyecto, tanto en el sitio como en casa.
El director del proyecto debe ser en gran medida autosuficiente. Enfrentado a desafíos únicos y,
a menudo, sin el apoyo de asociados y familiares cercanos, el gerente de proyecto debe adaptarse
al entorno local y ser capaz de resolver situaciones problemáticas que dejarían perpleja o inmovilizaría
a una persona menor. El sentido del humor ayuda, al igual que la experiencia laboral previa en
proyectos internacionales.
Sensibilidad y Aceptación
El director del proyecto debe comprender las normas y costumbres locales y ser capaz de desarrollar
relaciones de confianza con socios comerciales y clientes en el país anfitrión. Es posible que el
personal local, los contratistas y los trabajadores no sepan qué esperar de los gerentes extranjeros
o cómo tratar con ellos. Para ganarse su confianza, el director del proyecto debe ser capaz de
mostrar respeto y aceptación de su cultura.
A veces lo hace de manera sutil, como emular aspectos de sus costumbres sociales, comer comidas
populares locales o usar formas de vestimenta local.
Cada cultura una nueva experiencia
Cada proyecto en un nuevo país o región requiere nuevo aprendizaje y familiarización, y las
experiencias de una cultura o país no se pueden generalizar a otros. Por ejemplo, aunque los
trabajadores locales puedan parecer desmotivados o carentes de creatividad, la realidad podría ser
que simplemente no saben lo que se supone que deben hacer y requieren una instrucción y una
explicación cuidadosas. El director del proyecto debe emplear cualquier fuente de motivación que
funcione mejor. ¡A veces es una simple cuestión de ajustar las horas de la jornada laboral para que
se ajusten a los relojes biológicos locales!
Tampoco debe suponerse que, porque un proceso o método tuvo éxito en un país, lo hará en
otro, o que los trabajadores y proveedores locales aceptarán automáticamente el proceso o método.
Hacer suposiciones sin considerar los sentimientos y actitudes locales puede crear resentimiento y
resistencia entre el personal local.
Es posible que el director del proyecto deba ajustar su estilo de liderazgo de acuerdo con la
cultura. Por ejemplo, las personas en las culturas de distribución de alto poder de Hofstede pueden
necesitar o esperar más entrenamiento que aquellas de culturas de distribución de bajo poder.
Entre los desafíos de administrar un equipo intercultural se encuentran ser conscientes y lidiar
con los sesgos al evaluar a los miembros del equipo. En general, la tendencia es valorar más a las
personas de la propia cultura que a las de otras culturas.
El gerente del proyecto debe preguntarse: si esta persona fuera de mi propia cultura, ¿la evaluaría
de la misma manera?
Idealmente, todos en el proyecto, pero especialmente el gerente del proyecto, poseen habilidades
para salvar las diferencias culturales. Tales habilidades incluyen: 16
• Comprender cómo las perspectivas culturales influyen en el trabajo y

colaboración.
• Comprender cómo la cultura nacional, funcional y organizacional afecta

estilo de trabajo, interacciones de equipo y expectativas de las personas.
• Sensibilidad a las prácticas comerciales de diferentes países y regiones.
Disponible, totalmente comprometido, totalmente a cargo

Idealmente, el gerente del proyecto está en el medio de todo, administrando el proyecto no

desde una oficina remota sino en el sitio del proyecto. Siempre o con frecuencia está disponible
para ver lo que sucede y discutir los problemas con los gerentes, el personal y los trabajadores
locales. Ella está totalmente comprometida con el proyecto y permanece en el sitio hasta que se
completa el proyecto y el cliente ha firmado.
Los miembros del equipo son testigos de cómo el director del proyecto toma decisiones que
afectan al proyecto y a ellos personalmente. El gerente del proyecto debe estar en contacto
constante con su equipo y disponible para ayudarlos cuando lo necesiten, no solo con las
decisiones del proyecto, sino también con los documentos, la moneda, la vivienda o la asistencia
médica; de esta manera se gana su gratitud, respeto y compromiso. Cuando el gerente del
proyecto no puede estar en el sitio o trabaja con un equipo virtual, debe permanecer
comprometido a través de correos electrónicos frecuentes y mensajería instantánea, para que
los miembros del proyecto no perciban que está fuera de contacto.
Gerente de Proyectos Locales
En situaciones en las que el gerente del proyecto no pueda estar en el sitio, la responsabilidad
diaria del proyecto debe delegarse en alguien que los trabajadores vean como visiblemente
comprometido y totalmente a cargo, un gerente de proyecto local. Por lo tanto, cada subproyecto
en un proyecto global tendrá dos gerentes de proyecto, el gerente de proyecto global que
planifica y coordina desde la oficina central y viaja entre los sitios, y el gerente de proyecto local
que es responsable de la planificación detallada en el sitio y la gestión diaria. . El gerente local
reporta al gerente global; las responsabilidades y la autoridad de los dos están claramente
delineadas y entendidas por el equipo del proyecto.
Al momento de la contratación, se debe informar al gerente local del proyecto sobre las
expectativas, responsabilidades y objetivos de desempeño, y luego recordárselo periódicamente.
Contratar y capacitar a un buen gerente de proyecto local no es fácil, por lo que cuando surge
un problema, se le debe dar todas las oportunidades para resolverlo. Si el problema es grave y
se cree que está empeorando, el gerente de proyecto global debe "llevar en paracaídas" a una
persona de confianza para evaluar la situación y ofrecer asistencia.
Solo cuando la situación se considere desesperada, se debe reemplazar al gerente del proyecto
local. Pero eso puede causar un retraso de 6 meses a medida que el nuevo gerente se instala y
se ocupa de la familia y otros asuntos (de supervivencia).

17
19.7 Representante local
Cada proyecto internacional necesita a alguien en el país anfitrión para mediar con los trabajadores locales,
los sindicatos y los funcionarios gubernamentales, mantener informado al director del proyecto sobre los
asuntos locales y ayudar a resolver los problemas culturales y normativos.
Esta persona, el representante local, es responsable de:
• Representar al director del proyecto y la empresa ante el cliente, y vice

viceversa
• Mantener el proyecto vendido a clientes y simpatizantes. • Organización

de servicios en el país (reservas de hoteles y automóviles,
comunicaciones, intérpretes, personal de oficina y espacio). •
Organizar reuniones con funcionarios gubernamentales, agregados y consulados. • Educar al
cliente sobre los requisitos del gobierno del país de origen; por ejemplo, la transferencia de tecnología
y conocimientos técnicos.
• Ayudar a organizar viviendas locales para el personal del proyecto.
• Ayudar a localizar subcontratistas locales. • Informar al director del
proyecto sobre la política y la economía del país.
Las calificaciones del representante local incluyen un conocimiento profundo del proyecto: su misión,
alcance, tecnología, administración y equipo, y la empresa contratista: sus funcionarios, productos y
servicios. Si el contratista está realizando varios proyectos en el país anfitrión, el representante local debe
estar familiarizado con todos ellos.
El representante local debe conocer a fondo la cultura y las costumbres sociales del país anfitrión e,
idealmente, dominar el idioma local. No es necesario que sea nativo del país anfitrión, pero sí que sea
sensible y se sienta cómodo con las costumbres y la cultura locales. Además, el representante local debe
estar comprometido con el proyecto y no estar ansioso por salir corriendo a medida que se acerca su
finalización.
Cuando el proyecto tiene un gerente de proyecto local, idealmente esa persona también actúa como
representante local a menos que, sin embargo, no esté familiarizada con la cultura, las costumbres y las
partes interesadas locales, en cuyo caso debería tener un representante local.
Una forma de encontrar un representante local es asociarse con una empresa local para una parte del
trabajo del proyecto. En efecto, el socio se convierte en el representante local. Calificaciones de
el socio combine las descritas en el apartado 19.4 con capacidad para realizar el
trabajo contratado, capacidad de comunicación y reputación ética.
19.8 Alta Dirección, Comité Directivo y PMO

Prácticamente todo en un proyecto internacional es más difícil y lleva más tiempo. El
respaldo sostenido y el apoyo de la alta dirección son cruciales, pero cuando un
proyecto está lejos, experimenta problemas y tarda demasiado, es fácil que los
gerentes en casa pierdan interés. Para evitar eso, la alta dirección debe crear un
comité para guiar el proyecto y asignar a la PMO un rol para ayudar a administrarlo.
18
Comité Directivo
El comité directivo (o junta de revisión) de un proyecto internacional incluye gerentes

sénior y patrocinadores tanto de la sede de la empresa como del país/región
anfitriona del proyecto. Para un proyecto global compuesto por múltiples sitios de
proyecto, el gerente a cargo del proyecto general (es decir, el gerente de proyecto
global) también está en el comité. El propósito de este comité directivo “ejecutivo” o
“global” es establecer un marco de gobernanza para coordinar y financiar el proyecto.
Si el proyecto comprende subproyectos en varios sitios, el comité también establece
metas globales y coordina el trabajo y los recursos entre los subproyectos.
Cada subproyecto también debe tener un comité directivo “local”. Este comité está
compuesto por patrocinadores y gerentes locales y, para un proyecto global
compuesto por varios sitios del proyecto, el gerente del proyecto local. Este comité
planifica y ejecuta los detalles del proyecto y maneja los problemas que se originan
en el sitio del proyecto o en el país anfitrión. Las cuestiones graves que no puede
resolver se remiten al comité ejecutivo.
Rol de la PMO19
Además de las funciones descritas en el Capítulo 17, la PMO para proyectos

internacionales hace lo siguiente:
• Asiste a la alta dirección en la evaluación y selección de

proyectos
• Recopila lecciones aprendidas de proyectos internacionales y las incorpora en plantillas,
listas de verificación y sesiones de capacitación. • Da seguimiento a temas y problemas
identificados por la gerencia que requieren
coordinación entre múltiples proyectos internacionales. •
Gestiona archivos y documentación para proyectos internacionales. •
Identifica jefes de proyecto para proyectos internacionales. • Brinda
apoyo y tutoría para gerentes de proyectos en el extranjero. • Programa
foros para que los gerentes de proyectos internacionales compartan
experiencias.
• Brinda capacitación y educación sobre idioma, cultura, protocolo, leyes,
etc., pertenecientes a cada proyecto internacional.
En general, el personal del proyecto que vaya al extranjero debe estar bien informado sobre el
proyecto y saber qué esperar. Después de su llegada, no deberían tener que preocuparse por
qué hacer, dónde ir o quedarse, oa quién ver; dichas preocupaciones restan valor a su
capacidad para trabajar en el proyecto. La PMO y el comité directivo ejecutivo comparten la
responsabilidad de estos asuntos, organizando la capacitación y el entrenamiento, los arreglos
de viaje y estadía, el representante local del proyecto y muchos otros asuntos, grandes y
pequeños.
Ver Capítulo 17
19.9 Formación de equipos y relaciones
El director del proyecto inicia el proyecto internacional con una sesión de trabajo en equipo
para los miembros clave del equipo del proyecto, incluidos los directores y el personal
local. El propósito de la sesión es desarrollar un propósito común y expectativas
compartidas, identificar problemas probables o posibles y desarrollar pautas de proyecto
para evitar problemas. Las pautas abordan asuntos familiares como la colaboración, la
gestión de conflictos y la asignación de roles, pero también problemas exclusivos de los
proyectos internacionales, como la coordinación entre países y zonas horarias, y factores
interculturales, lingüísticos y sociales que podrían dificultar la comunicación y la toma de
20
decisiones. . cuánto suponeUn ejercicio
que útil es que
las personas cadaculturas
de otras participante exprese
están cómoa
dispuestas
adaptarse a su cultura, y cuánto está dispuesto a adaptarse a la de ellos.
El contratista también debe realizar una sesión con cada subcontratista local para
discutir los problemas que puedan surgir y preparar un plan para prevenirlos o mitigarlos.
En la sesión determinan qué tareas realizarán individualmente y cuáles en conjunto.
Idealmente, una gran parte de los paquetes de trabajo (20-30 por ciento) serán realizados
conjuntamente por equipos tanto del país anfitrión como del país de origen. Esto alentará
a los trabajadores locales a hacerse cargo del proyecto y, al mismo tiempo, permitirá que
el contratista mantenga el control sobre el trabajo.
Más allá de construir relaciones con los miembros del equipo del proyecto local, el
director del proyecto debe desarrollar relaciones con las partes interesadas en el país
anfitrión. Si el proyecto se ve envuelto en problemas serios, será útil tener vínculos
personales con el gobierno local y nacional, los funcionarios comerciales y laborales y los proveedores.
Con este fin, el director del proyecto debe hacer tiempo para asistir a eventos sociales con
funcionarios locales y celebrar fiestas locales y eventos culturales.
Un proyecto internacional no puede abordarse de la misma manera que un proyecto nacional.

Primero se deben identificar los problemas potenciales en el proyecto asociados con la
cultura, el país, las leyes, la gente y la política.
Donde empezar
¿Cómo aprenden los gerentes de proyecto lo que necesitan saber en cada proyecto
21
internacional? Aquí hay formas comunes:
1. Mire ejemplos de proyectos similares realizados en el país por su empresa u otras y

trate de aprender lo que hicieron. Busque gerentes de proyecto con experiencia en
el país o región anfitriona y pídales consejo.
2. Contratar a un consultor creíble o expatriado independiente para brindar orientación

y servir como intermediario cultural con las partes interesadas locales. Busque a
quienes tengan experiencia en proyectos y hayan desarrollado una red social y
conexiones locales en la región anfitriona.
3. Solicite asesoramiento a guías, profesionales o grupos asesores internacionales de
confianza sobre la política, las normas, las costumbres, las prácticas comerciales y
el entorno económico locales. Aunque es posible que no estén familiarizados con
el negocio o la tecnología de un proyecto en particular, conocerán la mano de obra,
los recursos y las leyes locales.
4. Asistir a programas formales de capacitación dedicados a hacer frente a extranjeros
partes interesadas, instituciones y entornos.
5. Comience con un pequeño proyecto piloto en el país para tener tiempo de
familiarizarse con la cultura y las leyes antes de comprometerse con proyectos más
grandes y riesgosos.
6. Crear un equipo de gestión de riesgos culturales para identificar posibles problemas
transculturales y transnacionales y los pasos para reducirlos o evitarlos. La
composición de este equipo debe reflejar los grupos nacionales y étnicos
de los interesados del proyecto.
Requerimientos del cliente
La mayoría de los proyectos comienzan con una lista de necesidades y deseos del cliente, que
luego el contratista amplía y convierte en una lista de requisitos técnicos. En un proyecto en
varios idiomas, el proceso se complica porque la lista del cliente debe traducirse al idioma del
contratista, luego la lista del contratista debe volver a traducirse al idioma del cliente para su
aprobación. El proceso puede ser largo, aunque, por lo general, los gerentes occidentales están
ansiosos por hacerlo lo más rápido posible. Pero los gerentes no occidentales, que adoptan una
postura diferente, pueden preferir posponer la definición de los detalles y primero construir
relaciones y establecer áreas de acuerdo. La actitud es, no se preocupe, los desacuerdos sobre
los detalles son inevitables pero se resolverán. Generar confianza y establecer áreas de acuerdo
son responsabilidades clave para el director del proyecto; no deben delegarse en alguien de
desarrollo de negocio, ventas o marketing, como ocurre en los proyectos domésticos.
22
Alcance y SOW en Proyectos Globales
Para un proyecto global que consta de subproyectos en múltiples ubicaciones internacionales,

un comité directivo global prepara la declaración del alcance, el SOW y un plan preliminar que
especifica los países o regiones de los subproyectos. El plan identifica metas, estrategias, metas,
costos, etc., para cada país y subproyecto, aunque sólo en forma de estimaciones, propuestas o
sugerencias.
El gerente del proyecto local, el patrocinador local y el comité directivo local para cada
subproyecto luego revisan el plan preliminar y lo amplían con mayor detalle para dar cuenta de
su conocimiento de la región y el sitio. También hacen sugerencias al comité global sobre el
propósito, las metas, los beneficios y los costos del subproyecto.
El proceso se repite para cada subproyecto, lo que da como resultado la información ilustrada
en la Tabla 19.3.
Debido a las diferencias en la cultura, las normas y los idiomas, los subproyectos que
comienzan con un propósito, alcance y SOW casi idénticos a menudo terminan variando.
sustancialmente. Para adaptarse a las diferencias en propósitos, metas, etc. (Tabla 19.3, filas 1 a 8),
el comité directivo global ajusta el alcance y el SOW (filas 9 y 10) para cada subproyecto. En el curso
de iteraciones de ida y vuelta entre los comités directivos global y local, los alcances y SOW de los
subproyectos y el proyecto global (fila 11) se ajustan mutuamente y se hacen compatibles.
Cuadro 19.3 Impactos de las diferencias entre países en el alcance global y local y el SOW
Subproyecto en Subproyecto en Subproyecto en

País A País B País C
1. Propósitos
2. Metas
3. Estrategias
4. Costo
5. Horario
6. Beneficios
7. Problemas
8. Riesgos
9. Alcance
10. SOW
11. Objetivos, alcance y SOW

del proyecto global
Los resultados esperados del proceso son que:
1. Los gerentes y equipos de proyectos locales se involucran y se comprometen

a sus subproyectos.
2. Cada patrocinador local acepta los objetivos y el alcance del subproyecto y promete apoyo.
3. El alcance, las metas y el SOW de los subproyectos se ajustan a las costumbres, regulaciones
y leyes locales.
4. Las partes interesadas a nivel global y local están de acuerdo.
5. Los objetivos, el alcance y el SOW de los subproyectos se alinean con los del global
proyecto.
23
Definición de Trabajo y EDT
La definición del trabajo debe tener en cuenta los muchos factores adicionales que distinguen un proyecto
internacional de un proyecto nacional. Un enfoque es comenzar con una plantilla WBS genérica para la
parte técnica del proyecto y luego expandirla para incluir factores internacionales. La plantilla inicial
establece el desglose de primer nivel de las actividades o los elementos finales, las áreas generales de
trabajo y los recursos necesarios, y puede parecer similar a un proyecto nacional de un solo país. Luego,
cada actividad de primer nivel se asigna a un miembro del equipo que será responsable de administrarla
(presumiblemente la persona que más sabe sobre ella). Esta persona, que podría ser el gerente del
proyecto local, subdivide la actividad en definiciones detalladas de tareas con estimaciones de recursos,
tiempo y costo.
Hasta ahora, el proceso de definición del trabajo no es muy diferente al de un proyecto doméstico. Sin
embargo, en un proyecto internacional, a medida que las actividades se desglosan en mayor detalle,
comienzan a surgir asuntos relevantes para el lugar. Es en los niveles inferiores de la EDT donde un
proyecto internacional se vuelve realmente único. Aunque un tipo genérico de proyecto repetido en cada
uno de varios países puede parecer el mismo en términos de actividades técnicas de alto nivel, los
subproyectos en diferentes países se ven bastante diferentes en niveles de trabajo más bajos debido a las
diferencias en cultura, instituciones, geografía, etc. en. Los problemas locales o internacionales identificados
en cada paquete de trabajo (por ejemplo, la Tabla 19.4) deben abordarse con tareas detalladas dentro de
los paquetes de trabajo o mediante paquetes de trabajo adicionales.
Tabla 19.4 Temas en Proyectos Internacionales
• Los miembros del equipo hablan diferentes idiomas. •
Los miembros del equipo expatriados necesitan vacunas, pasaportes, visas, etc. • Los
miembros del equipo expatriados necesitan alojamiento, comida y transporte locales. •
Los miembros del equipo local carecen de conocimientos y habilidades sobre el trabajo
del proyecto. • La infraestructura de comunicación local es deficiente. • El
líder del proyecto carece de experiencia internacional previa. • Los miembros
del equipo expatriados carecen de conocimientos sobre la cultura local y el país anfitrión.
• Los miembros del equipo local no están familiarizados con las prácticas comerciales del contratista.
• El estado del trabajo puede ser difícil de determinar. • En
ocasiones, el proyecto requerirá personas de la oficina central con habilidades críticas. • La
infraestructura de transporte local es deficiente. • Las necesidades comerciales

de la oficina local difieren de las de la oficina central.
• Proyecto dependerá de proveedores que no tienen fuerte presencia en el país. • Los procesos
comerciales en el país anfitrión difieren de los del país
de origen. • La tecnología o el material requieren licencias de exportación y aprobaciones de importación.
• El inicio de un proyecto o tarea depende del éxito de otro proyecto o tarea. • Los miembros del
equipo pueden ser retirados del proyecto debido a otras necesidades de mayor prioridad.
Además de descubrir problemas a través del proceso WBS descrito anteriormente, se puede crear una
WBS transcultural/internacional dedicada completamente a problemas internacionales (Figura 19.1) . Esto lo
hace un “equipo de riesgo cultural” especial cuyo único propósito es identificar y tratar problemas culturales/
internacionales. El desglose de primer nivel de esta EDT podría consistir en los siguientes paquetes de trabajo:
24
1. Identificar temas y factores internacionales y locales importantes en el proyecto.

2. Evaluar los riesgos asociados con estos problemas y preparar planes para abordar
a ellos.
3. Brindar apoyo al personal extranjero en el proyecto.

4. Proporcionar apoyo para la formación de equipos y la creación de relaciones.
5. Gestionar el conocimiento obtenido para este y otros proyectos internacionales.
Como ilustra la Figura 19.1 , las dos WBS brindan un enfoque doble para ayudar a garantizar que no se pase
por alto ningún problema internacional importante; cualquier redundancia que aparezca en ambas EDT
simplemente se consolida.
Figura 19.1 EDT para un proyecto internacional.
Una forma de realizar un seguimiento de las tareas detalladas y los paquetes de trabajo
en un proyecto global es con una matriz de resumen, que se muestra en la Tabla 19.5. La
matriz revela qué tareas son exclusivas de ciertos subproyectos y países y cuáles son
comunes entre muchos o todos. También sugiere lugares donde el conocimiento obtenido
de un subproyecto podría usarse en otro y ayuda a garantizar que no se pasen por alto
tareas o problemas importantes.
Paquetes de trabajo y responsabilidades
Dado que, en general, los paquetes de trabajo más pequeños son más fáciles de rastrear
y controlar que los más grandes, la EDT técnica debe subdividirse en última instancia en
paquetes pequeños de corta duración y resultados medibles. Sin embargo, al principio del
proceso de definición, un desglose tan detallado no será posible ni, debido a las muchas
incógnitas, deseable. No obstante, una vez que el proyecto está en marcha y se aclara el
panorama de las actividades pendientes y se desvanecen las incógnitas, se puede definir
con mayor detalle el trabajo. Al igual que con la planificación de proyectos por etapas, la WBS y
El plan se revisa continuamente, y los próximos paquetes de trabajo inmediatos se

subdividido en tareas detalladas y de corta duración, idealmente de no más de 2 semanas
cada.
Mientras se crea la EDT, también se crea la matriz de responsabilidad para mostrar la
responsabilidades de todas las partes que trabajan en el proyecto o lo apoyan: cliente,
subcontratistas y otras partes interesadas, tanto en casa como en el sitio del proyecto/anfitrión
país.
Tabla 19.5 Matriz resumen de tareas versus subproyectos
Tareas Subproyecto en Subproyecto en Subproyecto en

País A País B País C
Tareas Técnicas
Encuesta X X
Desarrollo del sitio X X

Sitio de construcción X X
Sistema X X X
implementación
Prueba del sistema X X X
Capacitación X X
Direccionamiento de tareas
Asuntos locales
Mano de obra X X
Subcontratistas X X
Permisos X X
Costumbres X X
Zona horaria X X
Idioma X X
Enfoque adaptado de Seward J. Managing a global project, pp.3–4, ETP The Structure Program &
Proyecto administración Compañía. descargado Septiembre 9, 2005 de
http://www.etpint.com/globalproject.htm.
25
Recursos, cronograma y presupuesto
Cualquier estimación de recursos, tiempo y costo basada en la experiencia nacional debe revisarse
cuando se aplica a proyectos en el extranjero. Los recursos planificados deben ajustarse a las diferencias
en los niveles de productividad del equipo y la mano de obra, y los cronogramas y presupuestos deben
ajustarse al tiempo y los costos de comunicación (fax, teléfono, mensajería, traductores), viajes (tarifas
aéreas, alquiler de automóviles, tarifas de taxis y limusinas) y arreglos para conferencias y servicios
locales. El presupuesto debe incluir tarifas y costos de seguros, licencias, revisiones gubernamentales,
vivienda local, incentivos salariales para trabajar en el extranjero, automóviles, guarderías, educación,
seguridad y atención médica. También se deben contabilizar los gastos y plazos para la obtención de
pasaportes y visas, y el transporte de gerentes, trabajadores y reemplazos de acuerdo con el cronograma
del proyecto.
Además de los factores ya mencionados, la preparación del envío, el transporte entre países, la
inspección y el despacho de aduanas y el transporte en el país anfitrión aumentan el tiempo y el costo de
los proyectos internacionales.
El tiempo de transporte en el país anfitrión depende de la calidad de las carreteras y de los aeropuertos,
puertos, camiones y otros servicios locales disponibles. Si el único transporte disponible hacia o desde el
sitio del proyecto sale solo una vez por semana, perderlo por un minuto podría resultar en un retraso de
una semana. Cualquier material o equipo que se traiga de los EE. UU., pero que se considere como
"transferencia de tecnología", primero debe ser aprobado por el Departamento de Estado, lo que puede
demorar meses. También se debe anticipar la fluctuación de los tipos de cambio, por ejemplo pronosticando
el impacto de, digamos, un cambio de + 10 por ciento en el euro sobre el costo estimado del proyecto al
finalizar.
Todas estas actividades adicionales hacen que los proyectos internacionales, ceteris paribus, sean más
costosos, prolongados y riesgosos que los proyectos nacionales.
Ejemplo 19.4 Tiempo y costo adicionales

de un proyecto internacional
Un contratista que trabajaba en un proyecto en el extranjero se encontró con mal tiempo que
ensució el equipo y detuvo el proyecto. De vuelta a casa, el contratista simplemente habría traído
otro equipo más apropiado para el clima, pero en el país anfitrión ese equipo no estaba disponible
y tuvo que ser importado.
Los problemas asociados con el transporte internacional del equipo (licencias de

exportación, cronogramas de envío), el transporte local (carreteras locales y servicios de
transporte) y la burocracia local (inspección aduanera y regulaciones de importación de
equipos) aumentaron sustancialmente el tiempo, el costo y el riesgo del proyecto. . Una
solución que habría sido relativamente sencilla en un proyecto nacional se convirtió en
una propuesta larga, costosa y arriesgada en el proyecto en el extranjero.
Las habilidades y la ética de trabajo de los profesionales y trabajadores locales también

deben tenerse en cuenta en las estimaciones de tiempo y los horarios. Debido a las diferencias
de idioma, la productividad de un ingeniero local podría considerarse equivalente a sólo la mitad
de la de, digamos, un ingeniero estadounidense y se compensaría extendiendo el cronograma
de trabajo de ingeniería del proyecto. Por otro lado, si los costos laborales más bajos de los
ingenieros locales permitieran contratar a varios de ellos para reemplazar a un estadounidense,
entonces podría no ser necesario extender el cronograma del proyecto. Pero rara vez tales
compensaciones son fáciles de determinar de antemano.
Ejemplo 19.5 Productividad en Proyectos Internacionales
Uno de los autores ha trabajado con ingenieros estadounidenses, canadienses y alemanes

en proyectos en Sudáfrica. A pesar de su competencia profesional, en todos los casos
estos ingenieros necesitaron mucho tiempo antes de volverse tan productivos como los
ingenieros locales debido a factores como el tiempo para “adaptarse”, la falta de redes
personales, la falta de conocimiento sobre las empresas y los procesos locales, la falta
de comprensión del entorno cultural, y problemas de comunicación; estos pusieron a los
ingenieros expatriados en desventaja y redujeron su productividad, al menos inicialmente,
y les impidieron trabajar a su máximo potencial. Como consecuencia, a los ingenieros
expatriados solo se les asignaron asignaciones técnicas, mientras que a los ingenieros
sudafricanos con calificaciones y experiencia similares se les asignaron asignaciones que
incluían responsabilidad de gestión.
Capacitación
A menudo, mucha preparación se dedica a capacitar y entrenar a los gerentes y al

personal expatriados en la cultura, las tradiciones y las regulaciones del país anfitrión. Por
lo general, se pasa por alto, pero a veces es igual de importante, la capacitación de los
gerentes y el personal local en la cultura, las prácticas comerciales comunes y los
procedimientos técnicos del contratista y del país de origen. El ajuste cultural es una calle
de doble sentido. Para la capacitación de locales, la estrategia y el entorno deben
diseñarse cuidadosamente, ya que el modo occidental de lectura-discusión en el aula no
es muy efectivo en algunas culturas.
26
19.11 Seguimiento del Proyecto
El gerente del proyecto debe asegurarse de que cada subcontratista local comprenda sus
expectativas de comunicación e informes de progreso. Debe exigir que el gerente de proyecto
local y los líderes de equipo presenten actualizaciones de tareas semanales; en un proyecto
internacional esto se simplifica publicando los planes del proyecto y las actualizaciones en
Internet. Suponiendo que los paquetes de trabajo técnico se han definido para que tengan una
duración relativamente corta (no más de 2 o 3 semanas), el director del proyecto podrá
discernir fácilmente si el trabajo se completó, está dentro del cronograma o está atrasado.
Cuando un subcontratista local comienza a atrasarse o no cumple con los requisitos, el

gerente del proyecto debe intervenir y asumir un papel más directo en la gestión del trabajo
del subcontratista; si eso no es posible, debe asignar a una persona local para ayudar al
subcontratista. Los litigios internacionales pueden ser una gran molestia, por lo que es mejor
intentar primero asesorar a un subcontratista para que vuelva a encarrilarse que recurrir a
acciones legales.
El gerente del proyecto que no puede estar en el sitio dependerá en gran medida del
teléfono y las teleconferencias para comunicarse con los locales. Una buena práctica es
preceder toda comunicación verbal con una comunicación escrita para que los trabajadores
locales sepan qué esperar y estén preparados, y luego hacer un seguimiento con cualquier
directiva o plan de acción por escrito. Esto ayudará a reducir los malentendidos entre las
partes, comunes en los proyectos internacionales.
La directora de proyecto de un proyecto internacional debe hacer notar su presencia; si no
puede estar siempre en el lugar, debe hacer visitas frecuentes, sin previo aviso. En ninguna
parte es más importante el valor de las visitas al sitio y la visibilidad que en los proyectos
internacionales.
19.12 Comunicación
Plan de Comunicación 27
Como otros proyectos, un proyecto internacional debe tener un plan de comunicación.

Además de los contenidos descritos en el Capítulo 12, este plan debe abordar las dificultades
derivadas de las diferencias de idiomas y zonas horarias. Además, debe especificar las personas
de contacto importantes (Quién es quién) en el país anfitrión, el país de origen y en otros lugares.
Todos, personal del proyecto nacional y extranjero y subcontratistas, deben comprender los
informes requeridos y la comunicación escrita, y el contenido y formato de cada uno. Los
contratistas extranjeros y el personal local del proyecto pueden no estar familiarizados con los
documentos de proyecto "comunes" y se les debe enseñar por qué son importantes y cómo se
utilizarán.
Se debe adoptar un “lenguaje de trabajo” común para todo el proyecto o para partes específicas
del mismo. Aquellos que no estén familiarizados con el idioma de trabajo deben recibir lecciones
de idioma aceleradas; Se debe recordar a todos los que usan el lenguaje común que hablen
despacio y usen términos simples y sin jerga. El boletín del proyecto debe publicarse en múltiples
versiones para los diferentes idiomas de las partes interesadas clave del proyecto.
Ver Capítulo 12
Reuniones
El plan de comunicación debe incluir un cronograma tentativo para todas las revisiones formales
y reuniones importantes, y describir el formato de las reuniones, el contenido esperado, los
preparativos previos, los límites de tiempo, la política de asistencia y quién liderará.
Dado que las reuniones formales en proyectos internacionales pueden ser difíciles de programar,
requieren mucha preparación y exponen a las personas a meteduras de pata o embrollos
culturales, es mejor tener la menor cantidad posible de ellos. Además, el director del proyecto debe cumplir
con clientes o funcionarios locales antes de las reuniones formales para informar cualquier problema
importante; nadie debe sorprenderse por lo que escucha en una reunión.
El método principal para el seguimiento del estado y la identificación de problemas debe ser la
comunicación uno a uno y reuniones informales frecuentes , convocadas según sea necesario, la
hora y el lugar determinados por la urgencia y el propósito, por ejemplo, semanas alternas si todo
está bien, más a menudo si no, y en el lugar que experimenta los problemas o problemas. La
asistencia debe estar restringida a los contribuyentes a la reunión oa las personas que se
beneficiarían de estar allí. Al igual que con los proyectos domésticos, el director del proyecto debe
ser la persona que toma notas, las redacta y las distribuye.
Ver Capítulo 16
El equipo en un proyecto internacional puede estar disperso en múltiples ubicaciones alrededor

del mundo, ya sea un equipo distribuido o virtual, y la mayoría de las reuniones se realizan a través
de tecnología de reuniones electrónicas o conferencias de audio o web.
Las recomendaciones para “reuniones virtuales” en la Sección 16.8 en el Capítulo 16 se aplican
también a proyectos internacionales, con la adición de algunos más. En aras de construir relaciones
personales y confianza en el equipo, cada reunión debe comenzar con una conversación informal.
Dedique unos minutos para que los miembros hablen sobre sus
familias, pasatiempos, intereses, etc., y dé tiempo antes de un día festivo para que el equipo local
explique las costumbres del día festivo. No es tan importante que los miembros sepan mucho unos
de otros, sino que demuestren que se preocupan lo suficiente como para querer escuchar sobre sus
vidas personales y sus vacaciones.
Establecer el tiempo para las reuniones virtuales puede ser problemático. Cohen dice: "No es la
distancia, es la diferencia horaria". 28 Ciudad dellaCabo y San
misma Francisco
distancia están aproximadamente
de Londres (9700 km frente a a
8600 km), pero la primera está 2 horas por delante de Londres, mientras que la segunda está 8
horas por detrás. La programación de llamadas y reuniones entre Londres y Ciudad del Cabo
planteará pocos problemas; programar reuniones Londres-San Francisco, ¡eso es otra cosa! Deben
evitarse las reuniones celebradas durante la hora de la comida, aunque lo que se entiende por "hora
de la comida" varía en todo el mundo. En América del Norte la cena es alrededor de las 6 de la
tarde; en Europa, India y otros lugares, las 8 o las 9 de la noche es
más común.
29
Cuando las diferencias horarias son grandes, comparta el dolor de programar reuniones.
Chicago y Mumbai tienen una diferencia de 10,5 horas y no permiten un tiempo de reunión
conveniente para los equipos en ambos lugares. La solución es rotar los horarios de las reuniones:
a veces a las 8 a. m., hora de Chicago (6:30 p. m. en Mumbai), a veces a las 8 a. m., hora de
Mumbai (9:30 p. m. en Chicago). La regla debería mantenerse incluso si Chicago es la oficina
central del proyecto con 30 personas y Mumbai es un satélite con solo seis personas. La rotación
reduce las diferencias de “poder” percibidas entre los miembros y ayuda a generar confianza y
respeto. Si el proyecto tiene personas dispersas por todo el mundo, el número de afectados se
puede minimizar requiriendo que solo unos pocos miembros o un representante de cada lugar
participen en las reuniones (nuevamente, tiempos rotativos). Esta alternativa nunca es tan buena
como que todos participen (al igual que las reuniones virtuales nunca son tan buenas como las
presenciales), pero a veces es necesario hacer concesiones.
Para generar conciencia, el gerente del proyecto debe distribuir una guía a todos los miembros
del equipo que muestre el país de cada miembro y la diferencia horaria entre las zonas horarias.
También debe enumerar las horas, los días, las comidas y los días festivos en los que los
30
miembros del equipo han dicho que no pueden o prefieren no reunirse.
19.13 Riesgos y Contingencias

Los proyectos internacionales están llenos de riesgos, aunque a menudo los riesgos son sutiles
o están ocultos y solo se pueden exponer al ver el proyecto desde las perspectivas de las
diferentes culturas y países de las partes interesadas del proyecto. Cualquier política de riesgo
permanente del contratista o cliente (descrita en el Capítulo 10) debe aplicarse de manera
uniforme en todos los proyectos en todos los países. En otras palabras, la tolerancia al riesgo de
una empresa expresada en la política de riesgos debe permanecer constante, sin importar el
proyecto o el país.
Como se discutió en el Capítulo 10, el análisis de riesgos comienza en la concepción y
definición del proyecto al imaginar diferentes escenarios sobre lo que podría salir mal. El riesgo
del proyecto está asociado con el nivel de incertidumbre: cuanto menos seguro esté de algo,
mayor será el riesgo. En un proyecto internacional, gran parte de la incertidumbre se relaciona
con la ignorancia sobre la cultura local, las costumbres, el idioma, las instituciones, la
infraestructura y las partes interesadas. Por lo tanto, el aprendizaje es una estrategia importante
para reducir los riesgos en proyectos internacionales: cuanto más sepa sobre estos temas, mejor
podrá identificar y mitigar los riesgos.
Ver Capítulo 10
Otra estrategia, sin embargo, es disminuir la cantidad de aprendizaje necesario para lidiar con
las regulaciones, leyes y recursos locales. Esto se hace en el siguiente
31
maneras:
• Subcontratar actividades que están fuertemente restringidas por las regulaciones locales.
La compra de terrenos, la obtención de permisos, la contratación de locales y el traslado
de materiales a través de la aduana son riesgosos porque requieren conocimientos
sobre las leyes y costumbres locales. Al externalizar estas actividades a subcontratistas
expertos, la carga de la responsabilidad (y gran parte del riesgo) se traslada a los
subcontratistas.
• Realizar trabajos intensivos en tecnología en el hogar. En lugar de lidiar con las

incertidumbres de la mano de obra, los materiales y la infraestructura locales, haga la
mayor parte del trabajo en los principales entregables de hardware y software en casa y luego
transportarlos al exterior hasta el lugar de montaje e instalación. • Suscribir

contratos de derecho internacional o de terceros países. En lugar de aprender las
complejidades de las leyes locales y depender de los abogados locales, finalice todos
los acuerdos contractuales de acuerdo con la ley internacional o en un país neutral
donde las leyes sean más familiares. Esta práctica es obligatoria en países donde las
leyes locales no son claras o la aplicación es impredecible.
La mayoría de las empresas emplean una combinación de lo anterior: aprenden y tratan algunos
aspectos del país anfitrión y la cultura por sí mismos, pero evitan tener que aprender y tratar con
otros. La mezcla depende del tipo de proyecto. En general, cuanto más requiere un proyecto que
el contratista esté “integrado” en un país extranjero, más debe aprender el contratista sobre el
país, sus leyes y cultura.
Los contratistas como Fluor y Bechtel que realizan grandes proyectos de construcción están muy
arraigados en el entorno local porque los proyectos llevan años, tienen un gran alcance y
dependen en cierta medida de los recursos locales. Por lo tanto, las empresas deben aprender
sobre el país o la región del proyecto, lo que hacen mediante la contratación de contratistas
locales, trabajadores locales y expatriados que conocen a fondo el país.
También gestionan metódicamente todo el conocimiento adquirido sobre el país de acogida. Al
mismo tiempo, reducen su necesidad de aprender sobre todo mediante la prefabricación de
entregables en el hogar siempre que sea posible, la subcontratación a proveedores y contratistas
locales y la contratación de representantes locales para tratar con las partes interesadas locales
y expatriados independientes para administrar la tecnología y los contratos.
Por supuesto, el gerente de proyecto en el sitio de un proyecto internacional siempre está
“incrustado” en el país anfitrión, incluso cuando el contratista (su empleador) no lo está.
Aunque conocer las formas y los protocolos locales puede no importarle a su empresa, sí le
importa al gerente que tiene que vivir y trabajar en el país anfitrión durante el tiempo que dure el
proyecto. De todas las formas de reducir los riesgos en un proyecto internacional, quizás la mejor
en general sea aprender y adaptarse a las costumbres, leyes, infraestructura y normas sociales
locales, y construir relaciones de confianza con líderes, subcontratistas, trabajadores y
funcionarios en el país anfitrión.
19.14 Resumen
Un proyecto de alcance internacional automáticamente hereda más problemas y mayor
riesgo que uno que no lo es. Estos temas tocan casi todo lo relacionado con la gestión de
proyectos: liderazgo, relaciones interpersonales, participación de las partes interesadas,
comunicación, planificación, gestión de riesgos y seguimiento y control.
El director del proyecto debe poder trabajar con subcontratistas, proveedores, clientes,
socios comerciales y funcionarios locales. A menudo, estas partes interesadas retienen el
esfuerzo, la colaboración o el apoyo hasta que sienten que conocen personalmente al
gerente del proyecto. Por lo tanto, ganar familiaridad personal y construir relaciones es un
aspecto fundamental en la gestión de proyectos internacionales. Además de la "competencia
de dominio" sobre los aspectos técnicos del proyecto, el director del proyecto debe ser
autosuficiente, adaptable en entornos desconocidos y capaz de comprender y respetar la
cultura y las costumbres locales.
Cuando el director del proyecto no siempre puede estar en el sitio, se debe designar un
director de proyecto local para manejar la planificación detallada y la gestión diaria.
Además, se debe designar un “representante local” permanente para actualizar al gerente
del proyecto sobre asuntos locales, mediar con las partes interesadas locales y ayudar a
resolver problemas locales.
Cada proyecto global debe tener un comité directivo ejecutivo para supervisar la
gobernanza y la financiación, y establecer objetivos y coordinar el trabajo entre los
subproyectos en diferentes sitios. Cada subproyecto debe tener un comité directivo local
para planificar y ejecutar los detalles y manejar los problemas locales.
La definición y planificación de un proyecto internacional requiere identificar los muchos
problemas e incógnitas asociados con la cultura, el país, las leyes, las personas, etc., y
tenerlos en cuenta en los planes, cronogramas y presupuestos del proyecto. Los gerentes
y otras personas familiarizadas con el entorno local deben ser consultados e involucrados en
elaboración de planos detallados. El proyecto puede tener dos EDT, uno para aspectos
técnicos del proyecto, otro para aspectos culturales o internacionales. El hecho de que casi
todo requiere más esfuerzo, tiempo y costo debe tenerse en cuenta en las tareas, los
cronogramas y los presupuestos.
El gerente del proyecto debe proporcionar metas y direcciones firmes a los gerentes y
subcontratistas locales. Idealmente ella está en el sitio; si no, hace visitas frecuentes, sin previo
aviso.
Muchos riesgos en los proyectos internacionales surgen del desconocimiento de las costumbres
y condiciones locales e internacionales; por lo tanto, una de las mejores maneras de reducir el
riesgo es aprender sobre las costumbres, leyes, infraestructura y normas sociales locales, y construir
relaciones de confianza con las partes interesadas locales.
1. Considere la analogía de un proyecto internacional con una obra de teatro. En proyectos internacionales,
¿quiénes son los actores, cuáles son los guiones, cuáles son los escenarios y cuáles son los accesorios?
2. ¿Cuáles son las cuatro categorías principales de “incógnitas” en un contexto internacional?
¿proyecto?
3. En la lista anterior, ¿qué incógnitas están implícitas y cuáles son explícitas?
¿Por qué las incógnitas implícitas son potencialmente más problemáticas para el director del proyecto?
4. Describa cada una de las cinco dimensiones culturales de Hofstede. como es la conciencia
de estas dimensiones relevantes para la gestión de proyectos?
5. Considere dos países con los que esté familiarizado. Compárelos y contrástelos en términos de lo
siguiente: las cinco dimensiones culturales de Hofstede, el idioma, la formalidad, la entrega de
obsequios, las actitudes sobre la edad y el tiempo, la comida y la bebida, las vacaciones y el tiempo
libre, y el tiempo de trabajo habitual.
6. ¿Por qué los despidos de trabajadores después del proyecto podrían causar problemas legales para
el contratista o empleador?
7. Para un proyecto en el extranjero, ¿cuáles leyes prevalecen, el país anfitrión o el país de origen?
8. ¿Qué son los “Incoterms”?
9. ¿Qué problemas legales están asociados con los contratos en proyectos internacionales? ¿Qué medidas
se deben tomar para evitarlos, o para tratarlos en caso de que surjan?
10. ¿Cómo puede el director del proyecto saber por adelantado de inminentes cambios políticos o
problemas laborales/sindicales en el país anfitrión?
11. ¿Cuáles son algunos de los beneficios de contratar contratistas locales en una empresa internacional?
¿proyecto? ¿Cuáles son los inconvenientes y las dificultades?
12. Describa el papel de las reuniones informales y eventos sociales en la construcción

confianza.
13. Describa las formas en que un contratista puede protegerse contra el aumento de los costos o la caída
de los precios como resultado de la fluctuación de los tipos de cambio.

14. ¿Qué es una “compensación”? Compara compensaciones indirectas y directas.
15. Mencione algunas formas de restricciones de exportación/importación. ¿De qué manera

pueden impactar un proyecto internacional?
16. Un proyecto involucra a miembros del equipo en Nueva York y Roma. Discuta cómo acomodaría
la diferencia horaria de 6 horas para maximizar la comunicación y la coordinación entre ellos.
17. En proyectos globales que incluyen subproyectos en múltiples sitios, ¿quién es responsable
de la supervisión diaria de cada subproyecto en cada sitio?
18. ¿Se puede suponer que una tecnología o proceso que resultó exitoso en un proyecto en un
país automáticamente lo será en un proyecto idéntico en otro país? Explique.
19. ¿Quiénes deben estar capacitados en las culturas, tradiciones y reglamentos del país de
origen o anfitrión, los gerentes y el personal que viajarán al país anfitrión para trabajar en el
proyecto, o los gerentes y subcontratistas locales que trabajarán en el proyecto? el proyecto
para un contratista que tiene su sede en el extranjero?
20. ¿Cuáles son las responsabilidades y calificaciones del representante local?
21. ¿Cuál es el papel del comité directivo del proyecto (o comité de gobierno o junta de revisión)?
¿Cuál es la diferencia entre los comités directivos globales y locales?
22. ¿Cuál es el papel de la PMO en un proyecto internacional?

23. ¿Cuáles son las formas de construir el trabajo en equipo y fomentar la cooperación entre los
miembros del equipo del proyecto de los países de origen y anfitriones?
24. ¿Cuáles son las formas de construir relaciones con proveedores y funcionarios locales? ¿Por
qué son tan importantes estas relaciones?
25. ¿Cómo puede el director del proyecto aprender sobre el país anfitrión y sobre los riesgos
potenciales relacionados con la cultura y el medio ambiente en el proyecto?
26. Discutir el proceso de desarrollo del alcance y SOW para los subproyectos en
un proyecto global multinacional de sitios múltiples.
27. Describa la WBS para identificar los problemas únicos de un proyecto internacional. ¿En qué
se parece o se diferencia la EDT técnica de una EDT técnica para un proyecto nacional de
un solo país?
28. Mencione algunos de los problemas que podría tener la EDT en un proyecto internacional.
dirigirse.
29. Describa el propósito y el contenido de la matriz de resumen de la tabla 19.5.
30. Comente el tamaño de los paquetes de trabajo en un proyecto internacional. Cómo
¿Se rastrean y controlan los paquetes de trabajo?
31. Enumere algunos factores que deben tenerse en cuenta al estimar los recursos, el tiempo
y el costo, y al establecer presupuestos y cronogramas para un proyecto internacional.
32. ¿Qué temas especiales debe abordar el plan de comunicación de un proyecto internacional?
33. ¿Cuáles son algunas estrategias para manejar riesgos en proyectos internacionales?
Si su proyecto de investigación fue un proyecto global o internacional, o involucró a clientes y/o

contratistas en el extranjero, considere las siguientes preguntas.
1. ¿Qué hizo el contratista y/o el director del proyecto en este proyecto que
difiere de un proyecto doméstico típico?
2. Discuta los aspectos del país, la cultura, el idioma y el comportamiento social del país
anfitrión que desafiaron al gerente del proyecto.
3. ¿Cómo aprendieron el director del proyecto y el personal sobre la cultura y las
tradiciones del país anfitrión? En su opinión, ¿estaban bien informados y preparados
para trabajar en el país anfitrión?
4. ¿Qué dificultades se encontraron que se derivan de la internacional
naturaleza del proyecto? ¿Podrían haberse evitado mediante una mejor planificación?
5. Discutir los siguientes roles, según corresponda: del gerente local del proyecto;
del comité de dirección, de la PMO.
6. ¿Cómo identificó el director del proyecto los problemas especiales relacionados con la
naturaleza internacional del proyecto y cómo los tuvo en cuenta al planificar el proyecto?
7. ¿Qué ajustes hizo el director del proyecto a las estimaciones de recursos, tiempo y
costos para tener en cuenta las diferencias en los países que suministran mano de
obra y materiales al proyecto?
8. ¿Qué estrategias se emplearon para identificar y reducir los riesgos del proyecto?
Caso 19.1 Proyecto Mozal: inversión internacional en

32
un país subdesarrollado
Mozal es un proyecto de $1.4 mil millones lanzado en 1998 para construir una fundición de
aluminio de 250.000 toneladas por año (tpa) en Mozambique (Figura 19.2). La idea de
tal proyecto al principio parecía absurdo. Construir una planta de producción tan
grande, moderna y con tecnología de punta requeriría financiamiento internacional y
suministros estables de materias primas y mano de obra, pero Mozambique era una
de las naciones más pobres del mundo con una infraestructura en ruinas después de
dos décadas de guerra civil. . Sin embargo, el proyecto fue un éxito, se completó
meses antes de lo previsto y muy por debajo del presupuesto. Vale la pena ver cómo sucedió eso.
figura 19.2 Fundición de aluminio Mozal.
El principal accionista promotor y controlador de Mozal era Gencor, una gran

empresa minera sudafricana (más tarde parte de BHP Billiton) que recientemente
había completado la fundición Hillside más grande del mundo (500 000 tpa) en
Richards Bay, República de Sudáfrica (RSA). En 1995, Gencor envió un equipo
multinacional de especialistas sudafricanos, canadienses y franceses del proyecto
Hillside a buscar el sitio para otra fundición.
Mozambique
El equipo eligió a Mozambique por varias razones (Figura 19.3). Su capital, Maputo,
ofrecía un puerto adecuado (aunque deteriorado) para importar alúmina y exportar
aluminio, además de abundante mano de obra barata (aunque en gran parte no
calificada). Además, la empresa eléctrica sudafricana Eskom vio la oportunidad de
extender su red eléctrica a Mozambique. La red proporcionaría energía confiable a
Swazilandia y, más tarde, sería el conducto para suministrar energía hidroeléctrica
desde el río Zambesi en Mozambique a la RSA.
El gobierno de Mozambique fue receptivo a Mozal ya que el proyecto impulsaría
su política de industrialización. Mozal se convertiría en la primera empresa en
calificar como empresa en la Zona Franca Industrial, otorgando a sus partidarios
exenciones de impuestos y aranceles. Además, dado que Mozambique es un país
de Asia, el Pacífico y el Caribe en virtud del Acuerdo de Lomé, el aluminio producido
allí entraría libre de impuestos en la Unión Europea. Después de una visita a la
fundición de Hillside, el Primer Ministro de Mozambique defendió el proyecto y facilitó
los cambios regulatorios y burocráticos necesarios para que continuara.
El sitio elegido para la fundición se encontraba en un área sin desarrollar a 17 km

del puerto. Para cerrar el proyecto, Gencor acordó financiar todo el trabajo de
infraestructura relacionado, incluido el desarrollo de las instalaciones portuarias,
contra el reembolso a través del tiempo a través de impuestos y compensaciones de
ingresos portuarios. Los miembros clave del equipo de Mozal se trasladaron a
Mozambique; esto les permitió entablar relaciones con las partes interesadas en
todo el gobierno y la comunidad.
figura 19.3 Fundición Mozal y alrededores.

Financiación
Otro accionista patrocinador del proyecto fue Industrial Development Corporation (IDC), un
banco de desarrollo del gobierno de RSA creado para buscar oportunidades de inversión que
promuevan la estabilidad económica. IDC acordó proporcionar financiación a bajo costo,
crédito a la exportación y garantías a los fabricantes y contratistas sudafricanos. La Corporación
Financiera Internacional (CFI), miembro del Grupo del Banco Mundial que promueve la
inversión sostenible en los países en desarrollo, también accedió a financiar el proyecto luego
de estar convencida de que era comercialmente viable, ambientalmente racional y ofrecía
importantes beneficios para la región.
Todas las principales entradas y salidas de efectivo se establecieron en dólares estadounidenses para minimizar
exposición a divisas.
Mitigación de riesgos y visto bueno
Se anticipó que los costos de producción del proyecto estarían en el 5 por ciento
inferior de la capacidad de la industria, y su caso comercial superó los criterios de
inversión de Gencor. El único riesgo importante del proyecto era Mozambique. En
mayo de 1997, los gobiernos de Mozambique y la RSA firmaron un acuerdo
comprometiéndose a honrar y proteger las inversiones transfronterizas. Luego de
discusiones privadas con grupos de interés influyentes en Mozambique, IDC e IFC
decidieron buscar un accionista internacional influyente para compartir el riesgo. En 1997
Mitsubishi Corporation, el conglomerado japonés, se sumó y en mayo de 1998 se
dio luz verde al proyecto.
Construcción
La construcción en el sitio de Mozambique planteó grandes desafíos. Los lugareños hablan

portugués, pero los gerentes, supervisores y el software de computadora expatriados usan inglés.
Se realizaron algunos trabajos de ingeniería básica en Canadá y Francia; algunos equipos
especializados fueron diseñados y fabricados en Japón y Francia. La mayor parte de la planificación,
coordinación, diseño detallado y preparación del material tuvo lugar en la RSA.
Los enlaces por carretera y ferrocarril conectaban Mozal con Richards Bay, RSA, donde llegaban
materiales y equipos del extranjero para su transporte al sitio del proyecto. En una etapa del
proyecto quedó claro que los agentes de Mozambique tenían problemas para procesar los 60 a 80
camiones de equipos y materiales que cruzan la frontera diariamente. Pero el director del proyecto
había establecido buenas relaciones con las partes interesadas clave, incluido el presidente de
Mozambique, y los convenció de permitir que el equipo de Mozal ayudara a administrar el puesto
fronterizo.
El proyecto empleó a muchos trabajadores experimentados del proyecto Hillside, aunque hubo
que contratar a miles de trabajadores no calificados más. Se establecieron escuelas para
capacitarlos en la construcción y aumentar la conciencia sobre la seguridad y los riesgos de la
infección por el VIH. Para combatir la malaria, el área que rodea el sitio se roció continuamente y
se establecieron clínicas de tiempo completo en el lugar que eventualmente manejarían más de
6,000 casos. Para los residentes desplazados por el proyecto, se asignaron y cultivaron nuevas
tierras de cultivo, y se estableció un fideicomiso de desarrollo para atender la educación local y
otras necesidades de la comunidad.
Antes de que los contratistas pudieran acceder a partes del sitio y los corredores de servicio, las
minas terrestres colocadas durante la guerra civil tuvieron que ser limpiadas. La construcción de
líneas de suministro de energía a campo traviesa y, en consecuencia, la puesta en marcha de la
fundición se vieron amenazadas por grandes inundaciones ciclónicas. Se necesitaban helicópteros
de carga pesada para volar en grandes pilones prefabricados fuera del sitio y para tender cables eléctricos.
Uno de los objetivos del proyecto era maximizar el contenido local. Un estimado
Se gastaron $75 millones en la economía local. En el pico de la construcción, el 70 por ciento

de las 9.000 personas empleadas en el sitio eran mozambiqueños.
Preguntas
1. Resuma los problemas y factores que plantearon riesgos para el proyecto

Mozal. ¿Cuál de ellos surgió del carácter internacional del proyecto?
2. ¿Qué acciones llevaron a la finalización exitosa del proyecto a pesar de la

riesgos?
3. El equipo comenzó a buscar un sitio adecuado en 1995, pero el proyecto no

se lanzó hasta 1998. Discuta el tipo de trabajo requerido durante la fase
previa al proyecto de un proyecto internacional de alto riesgo como Mozal
y la importancia de ese trabajo.
4. Discutir las responsabilidades sociales relacionadas con proyectos en países
en desarrollo como Mozambique.
Tareas de estudio
1. Usted es el nuevo director designado para el proyecto Mozal propuesto. El
estudio de factibilidad está completo y debe convencer a los patrocinadores y
prestamistas internacionales para que se comprometan con el proyecto.
Desarrollar una presentación para una junta especial de partes interesadas
solicitando el visto bueno para comprometer $ 1.4 mil millones para el proyecto;
aborde sus expectativas y cómo manejará los riesgos percibidos.
2. El proyecto ha recibido el visto bueno y ahora te enfrentas a la realidad de
movilizar a tu equipo y comenzar a trabajar en un país extranjero.
¿Qué desafíos especiales del proyecto puede esperar y cómo va a sentar las
bases para el éxito?
3. ¿Cuáles cree que son los criterios para evaluar el éxito de este proyecto
internacional?
' Puerto Rico Oficina 33

Caso 19.2 Espíritu Electrónica
Spirit Electronics Company, una firma estadounidense, está construyendo una sucursal de
oficinas en Puerto Rico. Susan Marcie de la firma de administración de la construcción
Weller & Waxhall está administrando el proyecto; este es su primer proyecto fuera de los
Estados Unidos. Visitó el sitio del proyecto y se reunió con la persona que sería el
representante local del proyecto. Al preparar el presupuesto buscó ofertas de proveedores
en los Estados Unidos y Puerto Rico.
Las ofertas recibidas de firmas estadounidenses parecían extremadamente altas; esto más el hecho
de que las leyes laborales en Puerto Rico exigen que algunos trabajos sean realizados por proveedores
locales llevó a Susan a seleccionar principalmente proveedores puertorriqueños.
Spirit quería que el proyecto se completara en 30 semanas. Dado que las ofertas de costos de los
proveedores tardaron en llegar, Susan preparó un presupuesto utilizando la hoja de cálculo de estimación
de costos de su empresa y los costos estandarizados. El proceso de revisión del presupuesto de Spirit lleva
cuatro semanas y, pensó, cuanto antes se apruebe el presupuesto, antes podrá comenzar el proyecto. Se
aprobó el presupuesto del proyecto por $690.457.
A medida que avanzaba la planificación del proyecto, surgieron problemas ya que el proyecto estaba en
Puerto Rico:
• Se requieren permisos tanto de la ciudad como del estado (los EE. UU. requieren solo
permisos de la ciudad).
• Se requiere seguro laboral al 5 por ciento del costo de construcción (no se requiere en los EE.
UU.). • Impuestos municipales inusualmente altos para trabajos de construcción. • Alto costo de
muebles (mucho más alto que en EE.UU.). • Alto coste de seguridad por riesgo de robo (más alto
que en EE.UU.). • Cierre de trabajo por feriado estatal (22 de diciembre a enero
15).
Estos, además de otros problemas menores, elevaron el costo estimado a $1,250,998. Spirit amenazó con
cancelar, pero Susan pudo negociar con los proveedores y reducir el costo a $987,655, a lo que Spirit
accedió.
Susan sabía que en los proyectos en el extranjero se debe incluir tiempo adicional en el cronograma
para dar cuenta de las incógnitas. Ella propuso retrasar la finalización del objetivo 8 semanas, pero Spirit
se opuso. Pudo crear un cronograma para cumplir con el objetivo original pagando al gobierno $20,000
para acelerar los permisos.
A medida que avanzaba el proyecto, Susan tuvo que responder a varios otros problemas:
• Largos plazos de entrega para accesorios hechos a la medida (6 a 8 semanas). Susan pidió a los
contratistas que ordenaran los accesorios necesarios lo antes posible. • Carpintería para
gabinetes y estanterías, que por lo general debe hacerse en el sitio después de que las paredes
estén terminadas y se conozcan las dimensiones exactas de la habitación. Para evitar esto, se
cambió el diseño del edificio para que la carpintería se pudiera prefabricar.

• Largos plazos de entrega de los permisos (3 a 16 semanas). Presentó dibujos y

solicitudes de permisos con mucha anticipación, mostrando las fechas en que se
necesitarían los permisos.
• Vendedores de instalación de muebles desorganizados. Susan hizo que los proveedores

crearan un plan (a partir del cual estimó un tiempo de finalización de 8 semanas) y
luego los obligó a cumplirlo.
• Dicotomía de la mano de obra local: costo extremadamente alto (cinco veces más caro
que en EE. UU. pero capaz de cumplir con las expectativas de manera confiable) o
costo extremadamente bajo (capacidad incierta para hacer un trabajo de calidad ya tiempo).
Por lo general, Susan contrató al
primero. • Costo y tiempo adicional para materiales importados debido a impuestos de
importación y costos de envío, y 6 semanas para inspecciones gubernamentales. Para
evitar demoras, Susan dispuso el espacio de almacenamiento local y el envío de
materiales mucho antes de la necesidad.
• Diferencias de idioma entre los miembros del equipo local y de EE. UU. (superintendente
del sitio, personal de TI, carpinteros y trabajadores). Para tareas que requerían
coordinación entre estos miembros, Susan amplió los tiempos de duración.
Preguntas
1. Al administrar el proyecto, ¿cómo abordó Susan explícitamente el hecho de

que era un proyecto “en el extranjero”?
2. ¿Cómo podría tener problemas preidentificados que finalmente requirieron
que rehaciera el presupuesto? ¿Cómo podría haber anticipado otros
problemas que surgieron más tarde?
Notas finales
1. - 2: Centro industrial de 200.000 millones de SR en

Jubail Ciudad la Creación, Zawya.
http://www.zawya.com/story.cfm/sidZAWYA20050321123628. Descargado el 12 de junio de 2006.
2. Adoptado de Orr R. Estrategias para tener éxito en entornos extranjeros. Colaboratorio para la Investigación sobre
Proyectos Globales, Universidad de Stanford. CIB W92 Simposio Internacional Adquisiciones de Construcción—La
Impact of Cultural Differences and Systems on Construction Performance, (Las Vegas, 8 al 10 de febrero de 2005, 3).
http://crgp.stanford.edu/publications/conference_papers/RyanVegas.pdf. Descargado el 10 de abril de 2007.
3. Estas descripciones están simplificadas y cada dimensión tiene ramificaciones mucho más amplias que las implícitas aquí.
Véase Hofstede G., Hofstede GJ y Minkov M. Cultures and Organisations: Software of the Mind, 3 .
ed. Nueva York, NY: McGraw-Hill Education; 2010.
4. El modelo de McSweeney B. Hofstede de las diferencias culturales nacionales y sus consecuencias: un triunfo de
fe: un fracaso del análisis. Relaciones Humanas (55) 2002; 89.
5. Carmel E. Equipos de software global: colaboración a través de fronteras y zonas horarias. Río Saddle Superior,
Nueva Jersey: Prentice Hall; 1998.
6. Turner J. Manual de gestión basada en proyectos. Nueva York, NY: McGraw-Hill; 1998, pág. 483.
7. Murphy O. Gestión de Proyectos Internacionales. Mason, OH: Thompson; 2005, pág. 23
8. Pringle D. Encontrar maneras de evitar las leyes laborales rígidas. Revista de Carrera Europa.
http://www.expatica.com/actual/article.asp?subchannel_id=157&story_id=10562. Consultado el 8 de mayo de 2006.
9. Cámara de Comercio Internacional, Políticas y Prácticas Comerciales, Incoterms 2000.
http://www.iccwbo.org/policy/law/id315/index.html. Consultado el 11 de abril de 2007.
10. Lemley J. Gestión del túnel del Canal: lecciones aprendidas, Túneles y tecnología espacial subterránea,
10(2), (1995): 9–11. http://www.ita-aites.org/applications/30th/PDF/TUST_95_v10_n1_5-29.pdf.
Descargado el 2 de diciembre de 2007; Anbari F. (ed.) Estudios de casos en gestión de proyectos: The Chunnel
Proyecto. Newton Square, PA: Instituto de Gestión de Proyectos; 2005.
11. Murphy, Gestión de proyectos internacionales, pág. 63.
12. Adaptado de Mathew M. Doing Business in India: A Cultural Perspective.
www.stylusinc.com/business/india/cultural_tips.htm. Descargado el 25 de septiembre de 2006.

13 Extranjero Intercambio. DT Comercial Bancario.
www.tdcommercialbanking.com/foreignx/products/forward.jsp. Consultado el 10 de marzo de 2006.
14. Murphy, Gestión de proyectos internacionales, pág. 63.
15. Lientz B. y Rea K. Gestión de proyectos internacionales. Ámsterdam: Prensa Académica; 2003, pág. 49.
16. Duarte D. y Snyder N. Dominando equipos virtuales. San Francisco, CA: Jossey-Bass; 2006, pág. 134
17. Murphy, Gestión de proyectos internacionales, págs. 65–66.
18. Lientz y Rea, International Project Management, págs. 44–45.
19. Ibíd., pág. 56
20. Ibíd., págs. 71 y 72.
21. Orr, Estrategias para tener éxito en entornos extranjeros, pág. 5.
22. Enfoques similares discutidos Lientz y Rea, International Project Management, Capítulo 2.
23. Lientz y Rea, Gestión de Proyectos Internacionales, Capítulo 2.
24. Grove C., Hallawell W. y Smith C. Una EDT paralela para proyectos internacionales. Conocimientos profesionales
Centro, Grovewell LLC, 1999. www.grovewell.com/pub-project-wbs.html. Descargado el 25 de enero de 2006.
25. Estas y otras consideraciones discutidas en Murphy, International Project Management, pp. 72–73, 88,
91–94, 178.
26. Lientz y Rea, Gestión de Proyectos Internacionales, págs. 124–128
27. Ibíd., págs. 155–170
28. Cohen M. Tener éxito con Agile. Upper Saddle River, Nueva Jersey: Addison-Wesley, 2010, pág. 375.
29. Ibíd., pág. 377.
30. Duarte y Snyder, Mastering Virtual Teams, p. 68.
31. Orr, Estrategias para tener éxito en entornos extranjeros, págs. 6–7.
32. Comunicación personal, Rob A. Barbour, ex presidente, Mozal.
33. Caso adaptado de Carta K., Cisek A., Cho L., Farr B., Hobbs M. y Kim C. Sprint Powered Workplace.
Graduate School of Business, Loyola University Chicago, febrero de 2007.

Apéndice A
RFP para distribución de paquetes en el medio oeste
Compañía
A continuación se encuentra la RFP para el sistema LOGON propuesto enviado por

Midwest Parcel Distribution Company (MPD) a los contratistas que se consideran más
capaces de cumplir con los requisitos. Solo se muestran entradas parciales para
minimizar la longitud del ejemplo. La referencia al “Apéndice” es para un apéndice
hipotético adjunto a la RFP, no a ningún apéndice de este libro.
Introducción
Usted ha sido seleccionado por Midwest Parcel Distribution Company como potencialmente
capaz de cumplir con nuestros requisitos para un nuevo sistema. Se le invita a enviar una
propuesta para suministrar el hardware, el software y los servicios de soporte para el
sistema descrito en esta solicitud de propuesta.
Sección 1 Antecedentes
MPD busca adjudicar un contrato para el diseño, fabricación, instalación, prueba y verificación
de un sistema de transporte, almacenamiento y base de datos para la colocación,
almacenamiento y recuperación automática (PSR) de contenedores de envío estandarizados.
El sistema, denominado sistema logístico en línea (LOGON), se instalará en las instalaciones
de distribución de MPD en Chicago... (Análisis adicional de las instalaciones de distribución
de Chicago, las necesidades futuras proyectadas y el propósito y los objetivos del sistema LOGON).
Sección 2 Declaración de trabajo
El contratista será responsable de proporcionar experiencia, mano de obra, material, herramientas,

supervisión y servicios para el diseño completo, desarrollo, instalación, verificación y servicios
relacionados para la plena capacidad operativa del sistema LOGON. El contratista realizará todas
las pruebas necesarias de los sistemas y subsistemas diseñados e instalados por el contratista, así
como de las instalaciones actuales para garantizar la compatibilidad con el nuevo sistema y con los
requisitos locales, estatales y federales.
El sistema LOGON debe cumplir con los requisitos de rendimiento, ser compatible con las
limitaciones estructurales y de servicios públicos existentes de la instalación, y cumplir con los
estándares y códigos logísticos y de empaquetado, como se especifica en la Sección 6: Información
técnica... (Análisis adicional de los servicios, equipos y materiales a ser proporcionado por el
contratista, y una lista de elementos finales específicos.)
Exclusiones
La remoción del equipo PSR existente se realizará bajo un contrato separado y es responsabilidad
de MPD. La remoción se completará a tiempo para que se instale el nuevo sistema... (Análisis de
los servicios, equipos y materiales provistos por MPD u otros contratistas y por los cuales el
contratista NO es responsable).
Fecha programada de entrega
El sistema LOGON estará en pleno funcionamiento el 30 de abril de 2021 o antes. Todo el hardware,
el software y los servicios de soporte necesarios para el funcionamiento completo del sistema se
proporcionarán o completarán antes del 30 de abril de 2021. La instalación del sitio comenzará a
más tardar el 30 de noviembre. , 2020.
Subcontratistas
Con la propuesta, el contratista deberá presentar una lista de subcontratistas y el trabajo

que se le asignará a cada uno. Los subcontratistas estarán sujetos a la aprobación de MPD
antes de la colocación de un contrato.
Costo y Contrato
El precio del contrato no excederá los $15 millones. El contrato tendrá un precio fijo con un
cargo de multa de $ 10,000 por día por no cumplir con la fecha de finalización operativa del
30 de abril de 2021.
Sección 3 Contenido y formato de la propuesta
La propuesta incluirá las siguientes secciones y se ajustará a las instrucciones específicas de la siguiente manera.
Índice de la propuesta
1. Portada (utilice el Formulario I proporcionado en el Apéndice)
2. Resumen ejecutivo 3.
(a) Antecedentes de la declaración de
necesidad (b) Enfoque técnico y características distintivas (c) Plan y
cronograma del proyecto (utilice los formularios II a V provistos en
Apéndice)
4. Presupuesto y precio (utilice el Formulario VI proporcionado en el Apéndice)
5. Organización del proyecto y plan de gestión 6. Experiencia
previa y personal clave 7. Anexos
(a) Declaración de confidencialidad firmada (utilice el Formulario VII en el Apéndice) (b) MPD
suministró información confidencial (c) Cartas de compromiso para trabajos contratados a
terceros.
Instrucciones específicas
(Detalles sobre el propósito, el contenido específico, el formato específico y la extensión aproximada de cada una
de las secciones enumeradas anteriormente).

Sección 4 Presentación de propuestas
Presentación
El contratista presentará dos (2) copias de la propuesta completa junto con todos
Información confidencial de MPD a:
lynn joffrey
Ayudante Administrativo
Distribución de paquetes del medio oeste
Empresa 13257 N.
Wavelength Avenue Chicago,
IL 60699, EE. UU. (773)
773-7733
Plazo
MPD debe recibir la propuesta antes de las 5 p. m. del 15 de agosto de 2019.

Fecha y criterios de selección
Selección y fecha de adjudicación
5 de septiembre de 2019.
Sección 5 Criterios de selección
Las propuestas completas recibidas antes de la fecha límite serán evaluadas según los siguientes criterios:
1. Capacidad técnica:
(a) Capacidad del sistema para cumplir con los requisitos de rendimiento dentro de las
limitaciones de las instalaciones, normas y códigos existentes. (15%) (b) Facilidad de
uso del sistema con respecto a la operación, confiabilidad,
y mantenimiento. (5%)
(c) Uso de tecnología de punta para asegurar que el sistema permanezca
actual en la próxima década. (15%)
(d) Servicios de soporte del sistema durante el período del contrato y disponibles después.
(5%)
2. Precio de oferta del contratista. (25%)

3. Experiencia y calificaciones del contratista. (25%)
4. Plan de organización y gestión del proyecto. (10%)
Sección 6 Información técnica
Confidencialidad
Los datos técnicos adjuntos y los planos, especificaciones, requisitos y anexos adicionales
solicitados se tratarán de forma confidencial y serán propiedad de MPD. La información
proporcionada en esta RFP o solicitada a MPD no se duplicará más allá de lo necesario para
preparar la propuesta. El original y todos los duplicados se devolverán con la propuesta. (Ver
Formulario VII, Apéndice.)
(Adjuntos a la RFP hay Apéndices que contienen formularios, acuerdos y datos técnicos de
respaldo, estándares y requisitos de desempeño necesarios para preparar y presentar una
propuesta).
Datos técnicos de apoyo
1. Datos técnicos adjuntos en el Apéndice C de esta RFP:
(a) Requisitos y estándares de rendimiento técnico para LOGON

sistema
(b) Especificaciones estructurales y de servicios públicos de la instalación
(c) Plano de planta de la instalación
2. Para aclaraciones e información adicional, comuníquese con:
Sr. Ed Demerest
Director de proyectos,
Instalaciones Midwest Parcel Distribution
Company N. Wavelength Avenue Chicago,
IL 60699, EE. UU.
773-7733
Apéndice B
Propuesta de Sistema Logístico en Línea
Proyecto (LOGON): Enviado a
Compañía de distribución de paquetes del
medio oeste de Iron Butterfly Company
1 hoja de portada
Formulario I: Portada
1. Nombre del proyecto: Proyecto de sistema logístico en línea (LOGON) para Midwest Parcel
Distribution Company, centro de distribución de Chicago
2. Ref. Trabajo No. 904-01
3. Contratista: Iron Butterfly Corporation, Goose Rocks, Maine 4. Nombre y
dirección del contacto: Frank Wesley, Gerente de Proyecto, Iron Butterfly Corporation, División
de Aplicaciones Robóticas, 150 Seaview Lane, Goose Rocks, Maine 715- 332-9132,
fwesley@ibuttc.com 5. Marcar el contenido de la propuesta
1. Portada
2. Resumen ejecutivo X 3.
A. Declaración de Antecedentes de la Necesidad

X B. Enfoque Técnico y Características Distintivas X C. Plan y
Cronograma del Proyecto (Formularios de RFP: II. Paquetes de Trabajo; III.
Entregables; IV. Cronograma de Trabajo; V.
Subcontratistas) X
4. Presupuesto y Precio (Precio del Proyecto: $14,413,905)
A. Presupuesto y Precio (Formulario VI de RFP) X B.

Variaciones, Cambios, Contingencias X C. Facturación
y Pagos X
5. Plan de Organización y Gestión del Proyecto X 6.

Calificaciones y Personal Clave
A. Empresa y Proyectos Anteriores X

B. Hojas de vida del Gerente de Proyecto y del Ingeniero de Proyecto X
7. Anexos (proporcionar como se especifica en la RFP o según sea necesario para

corroborar las afirmaciones en la propuesta) X
2 Resumen ejecutivo
Iron Butterfly Corporation de Goose Rocks, MN, presenta esta propuesta para el diseño
e instalación del sistema LOGON en el centro de distribución de Chicago de Midwest
Parcel Distribution Company. Nuestro sistema propuesto integra tecnología robótica y de
redes neuronales para agilizar el transporte y el almacenamiento de paquetes, y
complementará el sistema de procesamiento de información de distribución existente de MPD.
El sistema propuesto utiliza transportadores de drones robóticos para colocar y
recuperar paquetes almacenados. El sistema utilizará tecnología de red neuronal y, por
lo tanto, realmente aprenderá dónde colocar y recuperar paquetes y ganará en eficiencia
con el tiempo.
Los beneficios significativos del sistema propuesto son:
• Puede acomodar fácilmente el aumento esperado del 20% en el volumen

anticipado por MPD. • Se puede operar por aproximadamente un 10% menos
que el costo operativo anual de la
sistema actual.
• Puede implementarse fácilmente en la instalación existente sin cambios
estructurales en el edificio y solo cambios menores en los servicios eléctricos. •
Es fácilmente ampliable en caso de que la instalación actual se amplíe al
lote baldío contiguo.
• Puede diseñarse, instalarse y ponerse en pleno funcionamiento dentro de 1 año
de contrato. La conversión se puede realizar en tres fases de 2 meses, cada una
en solo un tercio de la instalación. Por lo tanto, durante la conversión de 6 meses,
la instalación actual podrá operar a más del 60% de su capacidad. • El hardware
y el software del sistema son duraderos y fáciles de mantener , como lo demuestran
miles de horas de uso operativo de los sistemas actuales por parte de los clientes
de Iron Butterfly Company (IBC).
IBC tiene 40 años de experiencia en la gestión de proyectos de diseño e implementación

de grandes sistemas de almacenamiento y transporte de depósitos. Hemos elegido
profesionales altamente experimentados como gerente de proyecto e ingeniero de
proyecto para supervisar la administración y tecnología del proyecto LOGON. Lo harán
trabajar en estrecha colaboración con MPD para garantizar que el sistema instalado satisfaga las
necesidades de MPD identificadas en la RFP y el estudio de factibilidad y que surjan durante el
proyecto.
Creative Robotics Company de Newton, MA, es socio de IBC en este proyecto.
Modificarán los drones transportadores robóticos para este proyecto. CRC es el líder de la
industria en tecnología de drones robóticos y ha desarrollado robots para la NASA, así como
transportadores de drones robóticos para todos los sistemas de transporte de drones robóticos
instalados por IBC.
Nuestro precio por el sistema es $14,413,905; Mantendremos este precio fijo durante los
próximos 120 días. Iron Butterfly y Creative Robotics están totalmente comprometidos con este
proyecto y garantizan sus beneficios. Lo invitamos a contactarnos para mayor información y una
presentación formal a su conveniencia.
3 Declaración de trabajo
A. Antecedentes Declaración de Necesidad
Reconocemos que MPD Company busca un sistema de seguimiento, transporte y

almacenamiento de paquetes para reemplazar el sistema actual en su principal sistema de
instalaciones de distribución en Chicago. El sistema existente está operando a su máxima
capacidad; el nuevo sistema debe poder acomodar un aumento esperado del 20 por ciento en
los envíos de paquetes durante los próximos siete años. Además, reconocemos que el sistema
existente utiliza un proceso que se ha vuelto anticuado. Los objetivos de MPD para el nuevo
sistema son acomodar el crecimiento esperado, mejorar sustancialmente la velocidad del
manejo de paquetes, aumentar la utilización del espacio de las instalaciones de almacenamiento
existentes, mejorar el mantenimiento de registros y reducir los costos de mano de obra, seguros
y mermas. El nuevo sistema, que se llamará LOGON, automatizará por completo el proceso de
colocación, almacenamiento y recuperación (PSR) de contenedores de envío estandarizados.
MPD busca un contratista para diseñar, fabricar e instalar el sistema, que incluirá todo el
hardware y software para el transporte y almacenamiento de paquetes, y el procesamiento y
almacenamiento de información asociados para el seguimiento y control de inventario y
paquetes. Esto se logrará con los entregables enumerados en el Formulario III y descritos en la Sección B.
También reconocemos que la eliminación del equipo PSR existente se realizará en virtud de
un contrato por separado, y que durante la instalación del sistema, MPD organizará el
almacenamiento alternativo en otros sitios.
B. Enfoque técnico y características distintivas
Con base en el análisis de la información que nos proporcionó el Sr. Ed Demerest sobre la
instalación de Tulsa de MPD, que se considera una instalación modelo, y los datos incluidos en
el paquete RFP, concluimos que el mejor enfoque para satisfacer las necesidades y objetivos
de MPD es un sistema que utiliza transportadores de drones robóticos, bastidores con
contenedores de envío de tamaño estándar y cubos de almacenamiento, y una base de datos
informática para la colocación y recuperación automática de paquetes y el mantenimiento de registros. El nuev
El sistema se derivará de una combinación de avances en tecnología robótica y de drones, inteligencia

artificial, así como la aplicación de tecnología existente.
Nuestra empresa tiene 40 años de experiencia en diseño e instalación de manejo de paquetes y sistemas
de información asociados, incluidos ocho sistemas de drones robóticos instalados para empresas en
América del Norte y Europa. (La experiencia se explica en la Sección 6, Calificaciones y personal clave).
Mientras se usa tecnología avanzada, el sistema propuesto incorporará características de los sistemas
existentes de MPD para evitar la duplicación de esfuerzos y brindar un sistema completamente operativo
en menos de 12 meses desde el inicio.
Los sistemas propuestos funcionan así: al

llegar un paquete al muelle de recepción del centro de distribución, se coloca en uno de los tres
"cubos" de paquetes de tamaño estándar. Los cubos están codificados electrónicamente según el artículo
y el destino del envío. Este código se transmite a una base de datos maestra desde cualquiera de las
cuatro terminales de trabajo ubicadas en el muelle. Las estaciones de trabajo están conectadas a través
de una red DEM-LAN a un CRC Modelo 4000
servidor. El Modelo 4000 tiene 4 terabytes de almacenamiento más respaldo para retener información
sobre la descripción, el estado, la ubicación y el destino del paquete. El sistema realiza un seguimiento
del espacio de almacenamiento restante disponible y, si es necesario, reasigna los cubos para una
utilización óptima del espacio. La asignación para la utilización del espacio se basa en la tecnología de
redes neuronales, que permite que el sistema "aprenda" y mejore sus reasignaciones con el tiempo. El
CRC 4000 también proporcionará informes sobre el estado y el rendimiento del sistema según lo solicite
la gerencia.
Los cubos de paquetes están conectados a un robot transportador de drones que lleva el cubo a una
ranura de almacenamiento vacante "adecuada" dentro de un contenedor de envío ubicado en un estante.
La computadora determina qué contenedor tiene una ranura vacante de tamaño suficiente y que contiene
paquetes destinados al mismo destino oa un destino cercano como paquetes en el cubo del transportador.
El transportador de drones robóticos luego transporta el cubo al contenedor de envío apropiado y lo
descarga en la ranura vacante. Los contenedores de envío se apilan en tres alturas en siete filas de
estantes (Artículos 2 y 3). La capacidad de almacenamiento de las instalaciones es de 400 contenedores
marítimos, cada uno con una capacidad de almacenamiento de 150 pies cúbicos.
Cuando se va a cargar un camión que se dirige a un destino específico, el destino se ingresa en la

estación de trabajo de la terminal del muelle y el sistema de base de datos identifica todos los
contenedores con baldes con paquetes que se dirigen al mismo destino oa destinos cercanos.
El sistema dirige los transportadores de drones robóticos a los contenedores apropiados para la recuperación de los cubos.
El sistema utiliza seis transportadores de drones robotizados que operan de forma independiente y simultánea. Los
transportadores de drones recuperan los cubos y los transportan al muelle de carga para colocar los paquetes en el camión
de salida. El tiempo de recuperación especificado más largo es de 6 minutos. Se incluirá un séptimo transportador de
drones como respaldo.
(La discusión continúa sobre las características del sistema robótico y la red neuronal
software, incluidos los beneficios y ventajas sobre diseños alternativos).
C. Plan y cronograma del proyecto (Formularios II a V de la RFP)
Formulario II: Paquetes de trabajo
1. Realizar el diseño funcional del sistema general.
2. Preparar especificaciones de diseño detalladas para subcontratistas de transportadores robóticos, sistemas de
estantes de almacenamiento y contenedores de envío y paquetería.
3. Preparar las especificaciones del software para la interfaz del sistema DEM-LAN y CRC 4000.
4. Preparar dibujos de modificación detallados para las unidades transportadoras de drones robóticos y el sistema
de estanterías de almacenamiento.
5. Preparar un plan para la instalación y prueba del sistema en el sitio.
6. Fabricar unidades transportadoras de drones robóticos y subensamblajes de soporte de rack
en las instalaciones de IBC.
7. Realizar pruebas preliminares de funcionalidad en siete transportadores de drones robóticos

unidades.
8. Realizar pruebas estructurales y funcionales de los sistemas de estanterías de almacenamiento.
9. Realizar la instalación de todos los subsistemas en el sitio de las instalaciones de MPD Chicago.
10. Realice la verificación de los subsistemas y la verificación final del sistema general en el sitio de las instalaciones
de MPD.
11. Códigos y Normas. (Lista de requisitos y normas para locales, estatales,
y agencias federales, y medidas para el cumplimiento)

Formulario III: Entregables
Grupo de hardware A 7
racks de almacenamiento, 109 3 159 3 69, instalados en el sitio

Verificación estructural y funcional final de los estantes 400
contenedores de envío instalados en el sitio 1,000 cubos para
paquetes de tamaño D43A 600 cubos para paquetes de
tamaño D25B 600 cubos para paquetes de tamaño D12C
Comprobación estructural y funcional final
Grupo de hardware B 7
unidades transportadoras robóticas, cada una con una capacidad de carga máxima de 20 libras compatible
con baldes para paquetes de tres tamaños, recuperación en 6 minutos en el punto más lejano,
instaladas en el sitio
Caja funcional de cuatro unidades
Comprobación de integración, Grupos A y B
Grupo de software
Red DEM-LAN, cuatro terminales de estación de trabajo CRC 2950 y CRC 4000
servidor, software del sistema operativo (CRC)

Software Vista-Robotic (Robótica Creativa)
Sistema de almacenamiento de tríada; Procesamiento de transacciones Mobius (CRC)
Apoyo
Dos copias, manuales de operación/mantenimiento del sistema
Transportador robótico de drones/integración CRC 4000 Capacitación de usuarios para
competencia
Pago final del sistema, usuario
Formulario IV: Horario de Trabajo
1. Comenzar el diseño básico mayo 2020

2. Revisión de diseño básico julio 2020
3. Aprobación del diseño del proceso/vía septiembre 2020

4. Revisión de especificaciones del sistema informático octubre 2020
5. Grupos de hardware A y B recibidos diciembre 2020
6. Comenzar la instalación en el sitio enero 2021

7. Terminar la instalación del sistema completo1/2 marzo 2021
8. Aprobación del usuario final mayo 2021
Formulario V: Subcontratistas
1. Creative Robotics, Inc., Newton, MA, suministrará los siete drones robóticos
transportadores y el software necesario.
2. Steel Enterprises, Inc., West Arroyo, OH, suministrará e instalará las piezas
para los estantes de almacenamiento.
3. United Plastics Co., Provo, UT, suministrará los contenedores de envío y

cubos de paquetes.
4. CompuResearch Corp., Toronto, Ontario, suministrará estaciones de trabajo terminales,
Red DEM-LAN y software de red neuronal de computadora CRC 4000,
e instalación de software y hardware relacionado.
4 Presupuesto y Precio (Precio del Proyecto: $14,413,905)
A. Presupuesto y Precio (formulario VI de RFP)
B. Variaciones, Cambios, Contingencias
(Enumere las condiciones bajo las cuales cambiarán los costos: cambio en el alcance del trabajo, costo
de los materiales fabricados con acero, paros laborales por disputas laborales, etc.)
C. Facturación y Pagos
(Propone la forma de facturación y pago.)

5. Plan de Organización y Gestión del Proyecto
Nuestra empresa conoce la gestión de proyectos y tiene la experiencia, las habilidades, los
procedimientos y el software para realizar con éxito este proyecto. El gerente del proyecto, el
Sr. Wesley, será responsable de administrar el trabajo del proyecto, incluido todo el trabajo de
contacto con el cliente, la presentación de informes de progreso, el cumplimiento de los
compromisos contractuales con respecto al cronograma y el desempeño técnico, y el seguimiento
de los gastos presupuestarios (consulte la Sección 6, Calificaciones y personal clave). ). La
ingeniera del proyecto, Julia Melissa, será responsable de definir las especificaciones y
garantizar que el sistema cumpla con los requisitos técnicos. Supervisará la preparación de los
requisitos de diseño y los dibujos, y garantizará el cumplimiento de los requisitos técnicos del
sistema en el sitio. La Sra. Melissa ha trabajado en IBC durante 7 años y en los tres proyectos
robóticos más recientes de IBC. El gerente de fabricación, Ira Block, será responsable de
administrar la adquisición y el ensamblaje de materiales y el trabajo relacionado en la planta de
IBC, coordinar las operaciones de ensamblaje y aprobar los ensamblajes antes del envío al sitio
de MPD. El Sr. Block ha trabajado con IBC durante 9 años.
Dentro de 1 mes de la firma del contrato, el gerente del proyecto preparará un plan de
ejecución del proyecto para que MPD lo revise. A partir de entonces, presentará informes de
progreso en reuniones mensuales con el personal de MPD. La documentación escrita se
proporcionará por adelantado a MPD. Las reuniones revisarán los gastos hasta la fecha, el
progreso del trabajo y los hitos y entregables alcanzados, todos rastreados por el sistema de
control, seguimiento y planificación de gestión de proyectos IRIS de IBC. Otras reuniones
formales incluyen una reunión de revisión a mitad del proyecto y una reunión de resumen del
proyecto; además de otros solicitados por MPD o IBC.
(Las secciones adicionales abordan la estructura de informes y comunicaciones y la mitigación
de riesgos).
6. Cualificaciones y personal clave
A. Empresa y Proyectos Anteriores
Iron Butterfly Corporation ha estado en el negocio del diseño e instalación de sistemas de

almacenamiento personalizados durante 35 años. Entre nuestros clientes se encuentran Nalco,
Firebrand, Kraft, Abbott Laboratories, Cardinal Health, Swiss Guard y Boeing.
Nuestra empresa cuenta con la certificación ISO 9000 desde 1996; también hemos sido
certificados como proveedor de Categoría A para Grego Systems y proveedor de Clase IIA para
la División de Aviones Comerciales de Boeing. (Nota del autor: este es un ejemplo hipotético).
En 2005 recibimos el premio Genie Design Award de IAWA. En 1998 nos asociamos con Creative
Robotics Company para diseñar el primer sistema de almacenamiento robótico completamente
automatizado y en 2011 instalamos el primer sistema operativo de transporte de drones en el
centro de distribución AIKEN de 300ÿ000 pies cuadrados en Hamilton, Ontario. En 2014
instalamos un sistema similar para Genteco Distributors en su centro de empaque de 400,000
pies cuadrados en Everett, WA. Los transportadores de drones robóticos se basan en el modelo
industrial estándar EZ, producido por Fancy Free Aerospace, Inc. El modelo EZ tiene más de
tres años y 350 000 horas de servicio industrial sin mayores incidentes. El diseño del Model EZ
fue modificado para aplicaciones de almacenamiento por el presidente de CRC y profesor del
MIT, el Dr. Sanjeev Rayu.
(Incluya algunas oraciones sobre la experiencia, los proyectos y los logros de Creative Robotics).
Hasta ahora hemos instalado un total de ocho de estos sistemas para clientes satisfechos.
(Los párrafos adicionales brindan detalles de estos sistemas: tamaño y aplicaciones, costo de
los proyectos, nombres de los clientes e información para contactar a estos clientes).
B. Hojas de vida del Gerente de Proyectos y del Ingeniero de Proyectos
(Adjunte un currículum de una página para cada gerente de proyecto e ingeniero de proyecto
que muestre experiencia en proyectos relacionados y antecedentes relevantes: títulos, membresías,
y certificaciones. También incluya currículos de media página para una o dos personas clave
en el proyecto).
7 archivos adjuntos
(Esta sección proporciona adjuntos como se especifica en la RFP o según sea necesario para corroborar
las afirmaciones en la propuesta); p.ej:
A. Declaración de confidencialidad firmada (utilice el Formulario VII en la RFP)

B. MPD suministró información confidencial C. Datos
técnicos y análisis para sustentar el sistema propuesto D. Cartas de compromiso
para trabajos contratados a terceros.
Apéndice C
Plan de Ejecución del Proyecto Logístico
Sistema en línea
Contenido
Carta de presentación
I. Resumen de Gestión II.
Descripción del Proyecto III.
Sección de Organización
III.1 Administración del proyecto
III.2 Organización y responsabilidad del proyecto
III.3 Administración de subcontratistas
III.4 Interfaz de cliente
III.5 Mano de obra y formación
III.6 Formación de usuarios
IV. Sección Técnica
IV.1 Declaración de trabajo y alcance
IV.2 Cronograma y calendario
IV.3 Presupuesto y costo
IV.4 Requisitos de información
IV.5 Documentación y mantenimiento
IV.6 Revisión del trabajo
IV.7 Códigos y normas aplicables
IV.8 Variaciones, cambios, contingencias
IV.9 Entregables del contrato

Para: VER DISTRIBUCIÓN Árbitro. Número de trabajo:
De: Frank Wesley, Gerente de Proyecto 904-01 Fecha: 3 de enero de 2020
Asunto: Proyecto de Sistema Logístico en Línea
Plan de Ejecución del Proyecto
El Plan de Ejecución del Proyecto del Sistema Logístico en Línea para el centro de distribución de
Chicago de Midwest Parcel Distribution Company ha sido modificado para incluir sus sugerencias y
aprobado por todos en la distribución.
Se envían copias de este documento para su uso en el cumplimiento de los requisitos del contrato.
Caja FW:es
Distribución:
Julia Melissa, Ingeniera de Proyectos

Sam Block, gerente de fabricación
Noah Errs, supervisor de control de calidad
Larry Fine, gerente de software
Sharry Hyman, directora de diseño
Brian Jennings, supervisor de montaje
Frank Nichol, Gerente de operaciones del sitio
Emily Nichol, supervisora de montaje
Robert Powers, supervisor de dibujo
Burton Vance, Gerente de Compras
Plan de Ejecución del Proyecto del Sistema Logístico en Línea
I Resumen de gestión
El 5 de septiembre de 2019, Midwest Parcel Distribution (MPD) Company otorgó a Iron Butterfly
Company (IBC) el contrato para instalar el sistema Logistical Online (LOGON) en las instalaciones
de distribución de MPD en Chicago.
El proyecto consiste en diseñar, fabricar e instalar un sistema de transporte, almacenamiento y
base de datos de paquetes, para la colocación, almacenamiento y recuperación automática de
contenedores de envío estandarizados. El sistema utiliza unidades transportadoras de drones
robóticos y una base de datos computarizada para la colocación y recuperación automática de
paquetes y el mantenimiento de registros.
Iron Butterfly es el contratista principal y es responsable del diseño del hardware y el software, la
fabricación de los componentes, la instalación del sistema y el pago. Los principales subcontratistas
son Creative Robotics, Inc. (CRI), Steel Enterprises, Inc. (SEI), United Plastics Co. (UPC) y
CompuResearch Corp.
(CRC). Iron Butterfly se encargará de la gestión general de proyectos entre CRI, SEI y UPC Corp. y
la administración de contratos relacionados. El director del proyecto es el Sr.
Frank Wesley, y la ingeniera del proyecto es la Sra. Julia Melissa.
El proyecto comenzará con el diseño básico el 17 de mayo de 2020 o antes y la aprobación final
del sistema por parte de MPD Co. tendrá lugar el 2 de mayo de 2021 o antes. Las subtareas
principales se muestran en el punto 7.
El precio del contrato es de $14 520 000, tarifa fija con aumento limitado, con base en una fecha
de aprobación final objetivo del 2 de mayo de 2021. Los gastos totales, tabulados en el punto 8, por
mano de obra, gastos generales, materiales, subcontratación y gastos generales/administrativos
son de $13 140 270 . El acuerdo prevé una cláusula de escalamiento ligada a índices de inflación
para gastos de materiales para el sistema de soporte de estanterías de acero. Se impondrá una
sanción de $10,000 por día a IBC por excederse en el cumplimiento de objetivos.
Los arreglos de contingencia en el acuerdo permiten la reconsideración de la sanción en caso de
interrupción del trabajo por disputa laboral con la gerencia.
II Descripción del Proyecto
El 5 de septiembre de 2019, IBC se adjudicó el contrato para el Proyecto del Sistema LOGON. La
adjudicación siguió a una revisión de licitación competitiva de 1 mes por parte de MPD Company de
Nueva York. El sistema se instalará en las principales instalaciones de distribución de MPD Co. en
Chicago.
El proyecto consiste en el diseño, fabricación e instalación de un sistema de transporte,
almacenamiento y base de datos de paquetería (LOGON) para la colocación, almacenamiento y
recuperación de contenedores marítimos estandarizados. El sistema mejorará sustancialmente la
velocidad del manejo de paquetes, aumentará la utilización del espacio de las instalaciones de
almacenamiento, mejorará el mantenimiento de registros y reducirá los costos de mano de obra en las
instalaciones. Los beneficios complementarios anticipados incluyen una prima de seguro reducida y costos de contracción
El sistema utiliza unidades transportadoras de drones robóticos, bastidores con contenedores de
envío y cubos de almacenamiento de tamaño estándar, y una base de datos computarizada para la
colocación y recuperación automática de paquetes y el mantenimiento de registros. El sistema funciona
de la siguiente manera:
Una vez que un paquete llega al muelle de recepción del centro de distribución, se coloca en uno de
los tres "cubos" de paquetes de tamaño estándar que están codificados electrónicamente según el
artículo del paquete y el destino del envío. Este código se transmite a una base de datos maestra desde
cualquiera de las cuatro estaciones de trabajo terminales. Las estaciones de trabajo están conectadas a
través de una red DEM-LAN a un servidor CRC Modelo 4000 con almacenamiento de 4 terabytes con
respaldo para retener información sobre la descripción del paquete, el estado, la ubicación de
almacenamiento y el destino. El sistema realiza un seguimiento del espacio de almacenamiento
disponible y reasigna los cubos para una utilización óptima del espacio; previa solicitud, proporciona
informes sobre el estado y el rendimiento del sistema.
Los cubos de paquetes están conectados a un transportador de drones robóticos (elemento 1). Los
drones son modelos industriales EZ, producidos por Fancy Free Aerospace, Inc. y modificados por CRI
para esta aplicación. El modelo EZ ha estado en uso durante más de tres años y 350 000 horas de
servicio industrial sin accidentes.
El transportador lleva la cubeta a una ranura de almacenamiento vacante "adecuada" dentro de un
contenedor de envío ubicado en un estante en la instalación. La computadora determina qué contenedor
de envío tiene una ranura vacante de tamaño suficiente y que contiene paquetes que van al mismo
destino o a un destino cercano como paquetes en el cubo de paquetes del transportador de drones. El
transportador luego transporta el balde al
contenedor de envío apropiado y lo descarga en la ranura vacante. Los contenedores de envío se

apilan en tres alturas en siete filas de estantes (Artículos 2 y 3). La instalación tiene capacidad para
400 contenedores, cada uno con 150 pies cúbicos. pies de capacidad de almacenamiento.
Artículo 1 Transportador de drones robóticos.

Tema 2 Disposición del sitio MPD.

artículo 3 Ensamblaje del bastidor de almacenamiento.
Cuando se va a cargar un camión que va a un destino específico, el destino se ingresa en la estación

de trabajo de la terminal del muelle para que el sistema de base de datos pueda identificar todos los
contenedores de envío con paquetes que van al mismo destino oa destinos cercanos. Luego, el sistema
enruta los transportadores robóticos a los contenedores de envío apropiados para la recuperación de
los cubos de paquetes. El sistema cuenta con seis transportadores de drones robóticos que operan de
forma independiente y simultánea. Los transportadores recuperan los baldes y los transportan de
regreso al muelle de carga para colocar los paquetes en los camiones que parten. El tiempo de
recuperación más largo en el sistema es de 6 minutos. El sistema empleará tecnología de red neuronal
que le permitirá mejorar su capacidad para colocar y recuperar contenedores. Se proporciona un
séptimo transportador de drones como respaldo.
IBC es el contratista principal y es responsable del diseño de hardware y software, fabricación de

componentes, instalación del sistema y verificación. Los principales subcontratistas son CRI, que
suministrará los componentes principales para los transportadores de drones robóticos; SEI, que
suministrará el sistema de estanterías de almacenamiento; UPC, que suministrará los contenedores
marítimos y baldes de paquetería; y CRC, que suministrará las estaciones de trabajo terminales, la red
DEM-LAN, el software de redes neuronales, la computadora CRC 4000, así como el soporte para el
desarrollo de software y la instalación del hardware de la computadora.
Durante la instalación del sistema, MPD ha dispuesto un almacenamiento alternativo y temporal

en otra instalación y el desvío de la mayor parte del tráfico de paquetes a sus otros sitios.
La información de diseño sobre las instalaciones de MPD en Tulsa se utilizará para tratar de mover
inicialmente el proyecto a una etapa avanzada. El trabajo de diseño restante utilizará la mayor cantidad
posible de trabajo que ya se ha realizado, sin comprometer la confidencialidad de los clientes, en
proyectos anteriores similares.
III Sección de Organización
III.1 Administración del Proyecto
La correspondencia sobre asuntos del proyecto será entre el gerente del proyecto para IBC
y el director de proyecto de MPD. El personal del proyecto puede comunicarse directamente con el
cliente o los subcontratistas para obtener información, proporcionando al gerente del proyecto y al
director del proyecto copias de los memorandos y conversaciones.
El número de cuenta asignado al proyecto LOGON es 901-0000. A los paquetes de trabajo y las
tareas se les asignarán números de subcuenta en el momento en que se autoricen las instrucciones y
los cronogramas del paquete de trabajo. Una sola factura para las cuentas del proyecto en su conjunto
es aceptable para la facturación a intervalos mensuales.
III.2 Organización y responsabilidad del proyecto
La organización de IBC para la realización del proyecto LOGON se muestra en el Punto 4. Las
responsabilidades administrativas y de gestión se resumen en el Punto 5.
El director del proyecto, el Sr. Wesley, es responsable de todos los contactos con los clientes, los
informes de progreso, el cumplimiento de los compromisos contractuales con respecto al cronograma y
el desempeño técnico, y el seguimiento de los gastos presupuestarios. Él y su personal reportarán
directamente al Sr. Ed Demerest, vicepresidente y director de proyectos de MPD Co.
La ingeniera del proyecto, Sra. Melissa, es responsable de establecer las especificaciones y la

entrega del sistema para cumplir con los requisitos técnicos. Supervisará la preparación de los requisitos
de diseño y los dibujos, calculará las cantidades, comprobará los dibujos y los cálculos, y se asegurará
de que se cumplan los requisitos técnicos del sistema en el sitio.
El gerente de fabricación, el Sr. Block, es responsable de administrar las adquisiciones, el ensamblaje

y el trabajo relacionado en la planta de IBC. Se asegurará de que las piezas entregadas por los
subcontratistas cumplan con los requisitos, coordinará el ensamblaje de los transportadores de drones
robóticos y los subsistemas de estanterías de almacenamiento, y firmará la aprobación final para los
ensamblajes antes del envío al sitio.
III.3 Administración de Subcontratistas
El personal clave de los cuatro subcontratistas principales CRI, SEI, UPC y CRC es:
Bill Planté Coordinador de proyectos, CRI

terry hemmart Gerente, manufactura, SEI

delbert dillert Representación de clientes, UPC
lynn duthbart Representante de ingeniería de sistemas, CRC
Elmer Hyman Representante del cliente, CRC
Cambios a los respectivos acuerdos solicitados por un subcontratista o por IBC

será actuado por el gerente de proyecto de IBC, el Sr. Wesley, al recibir una
propuesta escrita del subcontratista.
La correspondencia con los subcontratistas sobre asuntos técnicos será
dirigida a las cuatro primeras personas anteriormente nombradas oa sus suplentes. Software
el trabajo relacionado con las especificaciones con CRC será coordinado por el cliente de CRC
representante. Conversaciones telefónicas del proyecto entre IBC y subcontratistas
se anotará en notas manuscritas y copias enviadas al ingeniero de proyecto de IBC.
Punto 4 Organigrama LOGON.

Tema 5 Responsabilidades del proyecto.
Los informes formales de progreso serán preparados por el coordinador del proyecto CRI, el
El gerente de fabricación de SEI, el representante del cliente de UPC y el CRC
representante de ingeniería de sistemas para su presentación en reuniones semanales
celebrada en la oficina de Chicago de IBC durante la duración de la participación programada. Informal
las reuniones se programarán según sea necesario y pueden requerir la asistencia de otros
según lo solicitado por los subcontratistas o el director del proyecto. los
siguiente número mínimo de reuniones formales se incluyen en los respectivos
acuerdos de subcontratación.
IRC S reuniones
SEI 3 reuniones
UPC 2 reuniones
CDN 5 reuniones (desarrollo de software)
CDN 8 reuniones (integración del sistema del sitio)
Los subcontratistas proporcionarán información y prestarán servicios de la siguiente manera:

1. CRI realizará todo el trabajo asociado con la adquisición, fabricación y pruebas

funcionales de componentes de piezas y subensamblajes de acuerdo con las
especificaciones, planos y dibujos proporcionados por IBC. Las partes y componentes
para siete transportadores de drones robóticos se entregarán a IBC según los criterios
y fechas especificados en el acuerdo.
2. SEI realizará todo el trabajo asociado con la adquisición, fabricación y pruebas
funcionales de piezas y subensamblajes según las especificaciones, planos y dibujos
proporcionados por IBC. Las piezas y los componentes de los siete estantes de
almacenamiento se entregarán a IBC según los criterios y fechas especificados en el
acuerdo.
3. UPC realizará todo el trabajo asociado con la adquisición, fabricación y pruebas
funcionales de componentes de piezas y subensamblajes según las especificaciones
proporcionadas por IBC. Los contenedores de plástico y los baldes para paquetes se
entregarán a las instalaciones de distribución de MPD Chicago en las cantidades y
según las fechas especificadas en el acuerdo. Se entregará un contenedor de plástico
y uno de cada uno de los cubos de paquetes de tres tamaños a las instalaciones de
IBC para las pruebas según el acuerdo.
4. CRC realizará todo el trabajo asociado con el desarrollo, la programación y las
pruebas del software de control del transportador robótico y de redes neuronales del
sistema LOGON y la base de datos del sistema según las especificaciones
proporcionadas por IBC. El software se entregará a las instalaciones de IBC según el acuerdo.
5. CRC transportará, instalará y realizará pruebas de componentes e integración para la
verificación de cinco estaciones de trabajo terminales, red DEM-LAN, servidor CRC
4000, software NN, sistema de respaldo y hardware periférico según los criterios y
fechas especificados en el acuerdo.
IBC proporcionará la gestión general de proyectos de CRI, SEI y UPC y la administración de

contratos relacionados, y servicios legales, contables, de seguros, de auditoría y de
asesoramiento, según sea necesario.
III.4 Interfaz del cliente
El personal clave asociado con el proyecto para MPD Company es:

Ed Demerest Director de proyecto, Chicago

lynn joffrey Asistente administrativo, Chicago
Fiesta Cecil Gerente financiero, Chicago
María Marquart Gerente de operaciones, Nueva York
Los cambios o modificaciones al acuerdo solicitados por MPD o por IBC serán resueltos por el
gerente de operaciones al recibir una propuesta por escrito de
CIB.
La correspondencia con MPD será dirigida al director del proyecto. Las conversaciones
telefónicas del proyecto entre IBC y las partes externas se anotarán en memorandos escritos a
mano y se enviarán copias a la Sra. Joffrey.
Los informes de progreso serán preparados por el Sr. Wesley, gerente de proyectos de IBC,
para su presentación en las reuniones mensuales que se realizarán en la oficina de MPD Co. en
Chicago. Otras reuniones pueden requerir la asistencia de otras personas según lo requiera MPD
o lo solicite el Sr. Wesley. El Sr. Wesley también convocará una revisión de la mitad del proyecto
y un resumen del proyecto en la oficina de MPD en Nueva York. Quince reuniones están incluidas
en el acuerdo. MPD proporcionará información y prestará servicios en el proyecto de la siguiente
manera:
1. Realizar todos los elementos del trabajo asociados con la desocupación del sitio antes de
la fecha del acuerdo para el comienzo de la instalación del sistema.
2. Proporcionar levantamientos, criterios de diseño, planos y anteproyectos elaborados bajo
convenios previos o recibidos a través de solicitudes de propuestas para el sistema
LOGON.
3. Proporcionar criterios de diseño, dibujos y planos preparados para el sistema automatizado de
almacenamiento y recuperación de paquetes en las instalaciones de MPD Co. en Tulsa.
4. Obtener todas las aprobaciones internas, municipales, estatales y federales que sean
necesarias para completar el proyecto.
5. Proporcionar la gestión general del proyecto entre MPD, IBC y CRC Corp., y los servicios
legales, contables, de seguros, de auditoría y de consultoría que requiera el proyecto.
El administrador del contrato es el gerente de operaciones. Los cambios o modificaciones al

acuerdo con MPD, solicitados por MPD o IBC, estarán sujetos a una propuesta por escrito de IBC
al administrador del contrato de MPD a través del proyecto de IBC.
gerente.
El gerente financiero es responsable de las aprobaciones de los resúmenes de gastos
mensuales proporcionados por INC y el pago mensual a IBC. MPD es responsable de asegurar
el apoyo necesario de las empresas de servicios públicos eléctricos y telefónicos para la
conexión del sistema y de poner a disposición de IBC todos los criterios, planos y estudios
preparados para las instalaciones del sitio de Chicago y el sistema automatizado de las
instalaciones de Tulsa.
III.5 Mano de obra y capacitación
No se prevén requisitos de mano de obra adicionales más allá de los niveles actuales de
personal para realizar los servicios de este proyecto. Cinco personas del grupo de diseño de
IBC se han inscrito y habrán completado un seminario de robótica antes de que comience el
proyecto.
III.6 Formación de usuarios
Se proporcionarán dos manuales de operación de sistemas y 16 horas de asistencia técnica.

Posteriormente, la capacitación continua de los operadores será responsabilidad de MPD.
IV Sección Técnica
IV.1 Declaración de Trabajo y Alcance
Las principales tareas a realizar son el diseño, fabricación, instalación y verificación del sistema
LOGON para el centro de distribución de Chicago de MPD Co.
La obra se ejecutará de acuerdo con las condiciones establecidas en el
especificaciones en la propuesta de IBC y confirmadas en el acuerdo.

Las subtareas requeridas para realizar las tareas principales se muestran en el Punto 6 (las letras se refieren
a las designaciones de tareas en el Punto 6):

1. Realizar el diseño básico del sistema general (H).
2. Preparar especificaciones de diseño detalladas para transportadores de drones robóticos, sistemas de
estantes de almacenamiento y contenedores de envío y paquetería que se enviarán a CRC, SEI y UPC
(J, I, M, N).
3. Prepare las especificaciones para el software y la interfaz del sistema DEM-LAN y CRC 4000 (L).
Tema 6 Principales subtareas.
4. Preparar planos de ensamblaje detallados para las unidades transportadoras de drones robóticos y el
sistema de estantes de almacenamiento (O, K).
5. Preparar dibujos y un plan maestro para la instalación y prueba del sistema (P).
6. Fabricar siete unidades transportadoras de drones robóticos y subensamblajes de soporte de estantes en
las instalaciones de IBC (U, V).
7. Realice pruebas de funcionalidad en todas las unidades de transporte en la instalación IBC (X).
8. Realizar pruebas estructurales y funcionales en los sistemas de estanterías en las instalaciones de IBC
(W).
9. Realizar la instalación de todos los subsistemas en el sitio de las instalaciones de MPD Chicago (Y).
10. Realice la verificación de los subsistemas y la verificación final del sistema general en MPD
sitio (Z).
IV.2 Cronograma y Calendario
El proyecto comenzará con el diseño básico el 11 de mayo de 2020 o antes;
la instalación en el sitio comenzará el 10 de enero de 2021 o antes; y sistema final
la aprobación por parte de MPD Co. será el 2 de mayo de 2021 o antes. El cronograma para
aspectos significativos del proyecto se encuentra en el Punto 7. Los hitos señalados son:
1. Comenzar el diseño básico 2. 11 de mayo de 2020
Revisión del diseño básico 3. 26 de julio de 2020
Revisión del diseño del transportador y del transportador 4. 6 de septiembre de 2020
Revisión de las especificaciones del sistema 20 de septiembre de 2020
informático S. Revisión de los grupos de hardware A y 29 de noviembre de 2020
B 6. Comenzar la instalación en el sitio 7. 10 de enero de 2021
Aprobación final del usuario 2 de mayo de 2021
Las fechas de inicio de las actividades que dependen de los resultados de las revisiones formales serán
ajustado para permitir cambios significativos en la duración de las actividades anteriores,
aunque no se prevén ajustes.
Se han incluido instrucciones del paquete de trabajo y un programa detallado para el diseño básico.
repartido. La información subsiguiente del programa y del paquete de trabajo se
distribuidos y discutidos en las reuniones de revisión.
El cronograma de los entregables del contrato se proporciona en la Sección IV.9.

Tema 7 Cronograma del proyecto.
IV.3 Presupuesto y Costo
El precio del contrato es de $14 520 000, tarifa fija con escalamiento limitado, con base en una
fecha de aprobación final objetivo del 2 de mayo de 2021. Los gastos y tarifas se facturarán y se
pagarán mensualmente a medida que se incurran. El acuerdo prevé una cláusula de escalamiento
ligada a índices de inflación para gastos de materiales para el sistema de soporte de estanterías de
acero. Se impondrá una sanción de $10,000 por día a IBC por excederse en el cumplimiento de objetivos.
Las disposiciones de contingencia en el acuerdo permiten la reconsideración de la sanción en caso
de interrupción del trabajo por conflictos laborales.
Se han estimado las principales tareas, subtareas, horas-hombre y dólares para realizarlas. Los
gastos totales, tabulados en el punto 8, por mano de obra, gastos generales, materiales,
subcontratación y generales/administrativos son de $13,140,270.
Los gastos de mano de obra directa están bajo el control inmediato de los jefes de departamento
en los departamentos de diseño, fabricación, adquisición y servicio al cliente porque asignan
personal al proyecto.
El gerente del proyecto es responsable de la hora-hombre y los gastos directos, y recibirá
informes quincenales de los gastos de tiempo y dinero.
IV.4 Requisitos de información
La mayor parte de la información requerida por IBC para cumplir con los términos del acuerdo ha
sido suministrada por MPD Co. Se obtendrá una cantidad limitada de información del sitio a partir
de encuestas adicionales realizadas por IBC. MPD ayudará en el trabajo de inspección para
acelerar el proyecto.
IV.5 Documentación y Mantenimiento
Los gerentes funcionales enviarán informes de progreso y gastos quincenales al gerente del
proyecto. El gerente del proyecto enviará informes mensuales de resumen del proyecto a los
gerentes funcionales y a otros gerentes y supervisores enumerados en
distribución.
La documentación de costos, rendimiento y progreso se mantendrá e informará a través del sistema

de contabilidad de costos del proyecto de la empresa.
El gerente del proyecto preparará un informe resumido final para IBC y MPD
archivos de la empresa.
El director del proyecto es responsable del mantenimiento de todos los archivos del proyecto. Todas
las copias de los documentos del proyecto enviadas fuera de IBC saldrán únicamente bajo su dirección.
IV.6 Revisión del Trabajo
La revisión interna del trabajo producido en cada una de las divisiones de diseño, fabricación, adquisición
y servicio al cliente es responsabilidad del jefe de división de cada una de las disciplinas funcionales.
IV.7 Códigos y normas aplicables
Los bastidores de almacenamiento y las estructuras de soporte, los arneses eléctricos y los transmisores
de radio deben diseñarse de acuerdo con los estándares aplicables de AATOP, ASMER, OSHA, la Junta
de requisitos de construcción de Illinois y la ciudad de Chicago.
IV.8 Variaciones, Cambios, Contingencias
El acuerdo con MPD define las condiciones para considerar un cambio en la compensación o sanciones
debido a un cambio en el alcance del trabajo o el costo de los materiales fabricados en acero, o una
interrupción imprevista del trabajo por disputa laboral. Describe el procedimiento mediante el cual se
puede obtener la autorización de MPD para tal cambio.
Punto 8 Estimación de costos del proyecto LOGON.

El acuerdo, Párrafo 9.2, bajo compensación principal, establece:
Siempre que haya un cambio importante en el alcance, el carácter o la complejidad del trabajo, o si se requiere
trabajo adicional, o si hay un aumento en el gasto para el CONTRATISTA por los materiales fabricados en acero
según lo negociado en el contrato con el responsable SUBCONTRATISTAS, o si se produce una paralización de
los trabajos producto de un conflicto laboral con la gerencia, el CONTRATISTA deberá, a solicitud del CLIENTE,
presentar una estimación de costos de los servicios de la CONSULTORÍA y gastos por el cambio, ya sea que
implique un aumento o una disminución en la Suma Global. El CLIENTE deberá solicitar dicho presupuesto a través
del formulario que se facilita en el presente (Anexo F). Los cambios por razones de disputa laboral con la gerencia
serán revisados y determinados de acuerdo con las condiciones especificadas (Anexo G).
Durante la instalación y las pruebas del sistema, MPD ha hecho arreglos para desviar el 70
por ciento de su negocio de paquetería de Chicago a otros centros. El resto se almacenará en
una instalación alternativa cerca de Chicago. En caso de que se sobrepase el cronograma, el
plan de desvío de ruta seguirá vigente. MPD requiere un aviso de 30 días sobre el exceso de
tiempo previsto para extender el acuerdo con la instalación de almacenamiento alternativa de
Chicago.
IV.9 Entregables del Contrato
Todos los elementos deben ensamblarse, instalarse y operarse en el sitio de acuerdo con las especificaciones técnicas
del acuerdo.
Los subcontratistas transportarán componentes y piezas a la planta de IBC según este cronograma:
Artículo Fecha
1 de noviembre de
Piezas y componentes para transportadores robotizados de CRI
2020
4 de noviembre,
Piezas y componentes para sistemas de estanterías de almacenamiento de SEI
2020
Un contenedor de envío y uno de cada uno de los cubos de paquetes de tres 10 de noviembre de
tamaños de UPC 2020
25 de octubre
Software de control del sistema de transporte de drones robóticos de CRC
de 2020
Los siguientes son los artículos identificados en el acuerdo como entregables a MPD:
Artículo Fecha
Hardware (Grupo A)
Siete estantes de almacenamiento, 7' × 15' × 85' (D × H × L)

15 de noviembre
Instalado en el sitio
de 2020
29 de noviembre
de 2020
6 de diciembre
Se entregaron 400 contenedores de envío instalados en el sitio.
de 2020
13 de diciembre
Se entregaron 1000 baldes para paquetes de tamaño D43A
de 2020
13 de diciembre
Se entregaron 600 cubos para paquetes de tamaño D25B
de 2020
13 de diciembre
Se entregaron 600 cubos para paquetes de tamaño D12C
de 2020
Noviembre
8, 2020
Hardware (Grupo B)
Siete unidades transportadoras de robots (cada una con una capacidad de carga máxima
de 80 libras compatible con cubos de paquetes de tres tamaños)
8 de noviembre
Instalado en el sitio
de 2020
10 de
Caja funcional de siete unidades
noviembre de 2020
3 de enero,
Comprobación de integración, grupos A y B
2021
Grupo de software
19 de
Envío de especificaciones de software a CRC
septiembre de 2020
(Instalación de red DEM-LAN, cuatro terminales de estación de trabajo CRC 2950 y servidor 7 de febrero,
CRC 4000, realizada por CRC) 2021
7 de marzo
Comprobación de integración de software, realizada por CRC
de 2021
pago final
7 de marzo
Dos copias, manuales de operación/mantenimiento del sistema
de 2021
4 de abril,
Transportador robótico de drones/integración CRC 4000
2021
Abril 8,
Prueba de sistemas de referencia, con paquetes
2021
11 y 12 de
Entrenamiento de usuario
abril de 2021
Más reciente,
Pago final del sistema, usuario 2 de mayo

de 2021
Índice
AAR ver revisiones posteriores a la acción
AAS ver Sistemas avanzados de automatización
AC ver coste real del trabajo realizado
Accent, Inc., caso 477-8
pruebas de aceptación 335, 440–1
contabilidad 168–70, 292–5, 309, 392–5, 528, véase también presupuestos; costos
adquisición 69–70, 179–80 gestión
de integración de adquisiciones (AIM) 503–4
actividad: contingencia 286–7; ciclos de vida 67–8; diagramas de red 192, 193, 194; anejos 172, 235, 236, 248, 399;
incertidumbre 240–72, véase también esfuerzo
diagramas de actividad en flecha (AOA) 218-20
diagramas de actividad en el nodo (AON) 191–3, 220 costo
real del trabajo realizado (AC/ACWP) 400, 402
ACWP ver el costo real del trabajo realizado
administración 90, 290–2, 419–20, 527, 528, 535, 674, 675–7
Sistemas de automatización avanzada (AAS) 52–3
análisis avanzado de redes de proyectos 232–74
revisiones posteriores a la acción (AAR)
580 gestión ágil de proyectos (APM) 10, 14–5, 72, 115, 126, 453–80
AIM ver gestión de integración de adquisición
sistemas de control de tráfico aéreo 52–3
caso de adversidad de bolsas de aire 344
proyectos de aviones 58–9, 126–7, 369, 465, 628
proyecto de ampliación del aeropuerto 365
proyecto de fundición de aluminio 652–5
enfoques de analogía 283–4, 312–3, 349–50

AOA ver diagramas de actividad en flecha
AON ver diagramas de actividad en nodo
APM ver gestión ágil de proyectos
Programa de la nave espacial Apolo 7, 95–6, 97, 106–7, 325
tasaciones 49
Archibald, R. 9, 443, 522-3
Arquidiócesis de Boston caso 33–4
Diagramación de flechas 218-20
garantía, calidad 320, 322–3, 324, 338 átomos
proyectos 465, véase también desarrollo de hardware
audioconferencia 431
auditorías 33, 329, 343, 434
autoridad 363, 491, 494, 495, 502, 515, 519–22, 630, véase también influencia; energía
procesos de autorización 94, 393
B/C ver relaciones costo/beneficio
atrasos 470–2 caso
del sistema de manejo de equipaje 16–8
Proyecto de enlace marítimo de Bandra-Worli 279–80
Barrage Construction Company caso 184–5
cambios de referencia 417–8
estimaciones de referencia 371, 373
tamaño de lote 466–70, 474
Bechtel 628
cambio de comportamiento 259–60
conductismo 10
relaciones beneficio/costo (B/C) 610–1
gestión de beneficios 589
Desastre de la planta química de Bhopal 359
Big Dig Project ver Proyecto de Túnel/Arteria Central
bits proyectos 465, véase también desarrollo de software
Blanchard, K. 543
hinchado 387
Boca Business System caso 187–8

cuerpos de conocimiento (BOK) 10, 12–3
Boeing 331–3, 437, 628
Los libros de texto ven cuerpos de conocimiento
Borglum, Gutzon 516–8
proyectos de Boston 33–4, 339–41, 533–4 enfoques
ascendentes 53, 54, 284–6, 287–8, 313–4
lluvia de ideas 328, 337, 351–2
Branson, sir Ricardo 31, 129, 141, 312
proyectos de pan y mantequilla 614, 615
protoboards 365
construcción de puentes 268–70, 381–2
Proyectos aeroespaciales británicos 58–9
gráficos de burbujas 614, 615, 616
presupuestos: márgenes de diseño 364; estimación 275-315; proyectos internacionales 646–7, 655–6; software PMIS 436;
propuestas y planes 667–8, 681; reservas 277, 398–9; riesgo 364, 372; análisis de varianza 391–2; trabajo realizado 400–2, véase también contabilidad;
costos; valor agregado; valor planificado
amortiguadores: proyecto 254–9, 262; riesgo 367; tiempo 396–8, 399
gráficos de quemado 462–4
construcción de puentes atirantados 268–70
CAD/CAM ver diseño asistido por computadora/tecnología asistida por computadora
horarios de calendario 202–3, consulte también diagramas de Gantt
proyectos de campaña 33–4
Caso de la mina de oro canadiense 150–1
capacidad ver madurez
Modelos de madurez de capacidad (CMM) 570, 571
Estadio de Ciudad del Cabo 341
proyectos de inversión de capital 32
estudios de casos: adversidad de bolsas de aire 344; Evaluación de la propuesta de la nave espacial Apolo 106–7; empresa constructora de presas: Sean's
WBS 184–5; contratistas de Bridgecon 268–70; colapso del techo en el Proyecto Big Dig
339–41; proceso de control de cambios en Dynacom Company 428; Compañía de energía consolidada 624–5;
Proyecto Cibersónico 426; Aeropuerto de Denver 16–8; Recuperación de desastres en Marshall Field's 38–9; costos estimados para el Proyecto
Chunnel 312–3; Copa Mundial de la FIFA Sudáfrica 341–4; Estimación de Fiona para el Gorgy
Proyecto 313–4; implementación del sistema de beneficios flexibles en Shah Alam Medical Center 40; formales y
comunicación informal 451; Distrito Sanitario 57 del Condado de Glades; Gran Entrada para Accent, Inc. 477–8;
implementar una estructura matricial en un laboratorio de I+D 512–3; Lavasoft.com: interpretación de los requisitos del cliente 149–50;
costes del ciclo de vida de la flota de naves espaciales turísticas 312; proyecto LOGON 270–1, 511, 537;
Nave espacial del orbitador climático de Marte 565; Maxim Corporación América 595–6; construcción de melbourne
empresas 228–30, 314; Programa de exploración de mercurio 599–600; La metodología M-Gate de Motorola y la
Proyecto RAZR 597–8; Proyecto Mozal: inversión internacional en un país subdesarrollado 652–5; los
Puente Nelson Mandela 381–2; diagrama de red para un gran proyecto de construcción 226–7; Papúa Petera
proyecto de aldea 271–2; Cámara estenopeica y óptica, Inc.: ¿por qué necesitamos un director de proyecto? 511–2;
planificación de la implementación de Boca en Kulczydski Products 187–8; Desarrolladores Polanski 107; fábrica de cemento propuesta
para la empresa PCS 625–6; mina de oro propuesta en Canadá: planificación del proyecto por etapas 150–1;
Revcon Products y Welbar Inc.: comunicación cliente-contratista 148–9; Tráfico del condado de Santa Clara
sistema de operaciones y proyecto de coordinación de señales 61–2, 151; seleccionando un gerente de proyecto en Nuwave
Compañía de productos 537–8; Edificio central de información SLU 450–1; mina de oro sudafricana: valor ganado después de un
cambio de alcance 427; Oficina de Spirit Electronics en Puerto Rico 655–6; partes interesadas en Boston's Big
Excavar 538–9; Star–Board Construction y Santero Associates: Requisitos SNAFU 147–8; Star Trek
Enterprises, Inc.: plan de proyecto de Deva 185–6; informe de estado del Proyecto LOGON 450; La Ópera de Sydney 379–80;
tecnología para rastrear vehículos robados 479; Compañía Tecknokrat 598; plan de proyecto de Walter 186; Centro Médico de la
Universidad de la Costa Oeste 105; Wilma Keith 564; Gestión de datos X-philes (XDM)
Corporación 106
CAT ver Proyecto de Túnel/Arteria Central, Boston
causa y efecto (CE) 48, 337, 351–2
CC ver enfoques de cadena crítica (CC)
CCPM ver gestión de proyectos de cadena crítica
CE ver diagramas de causa y efecto
Proyecto de Túnel/Arteria Central (CAT) (Proyecto Big Dig) 339–41, 533–4
certeza 304, 346, 497
Transbordador espacial Challenger 316,
356 campeones 531
cambio: tableros 489; cláusulas 277; conflicto 556; control 124, 388, 416–9, 428, 436; aplicación de 37; problemas
gestión 415; gestión de programas 592; pide 326
Chapman, Ricardo 541
Desastre de Chernóbil 331, 359–60
Caso de inundación de Chicago 38–9
Chrysler 145–6
Proyecto Chunnel ver Proyecto Túnel del Canal de la Mancha
CI ver elementos de configuración
Criterios de Cleland y King 24–5, 47
CLF ver factores de probabilidad compuestos
interfaces de cliente 677–8
comunicación cliente-contratista 148–9
sistemas cerrados 46–7
liquidación 140, 390, 430, 441–5, 557, 588
CMM ver Modelos de Madurez de Capacidad
gestión de proyectos comerciales/con fines de lucro 29
comunicación: APM 464; costos y presupuesto 278; compromiso 532; evaluación 431, 432–41, 448, 451;
integración 516; proyectos internacionales 648–9; riesgo 367; equipo 565
tecnología de la comunicación 431, 552–3, 584
competencia 10, 13–4, 585, véase también madurez
competición 8, 30–1, 77, 93, 275–6, 316, 348, 374 finalización
249, 258, 279–80, 375, 407–12, 441–5, 448, 467
complejidad 4–8, 16–8, 349, 363, 387, 496–7, 500
factores de probabilidad compuestos (CLF) 353–4
metodología integral de gestión de proyectos de seis etapas 576 diseño asistido
por computadora/tecnología asistida por computadora (CAD/CAM) 331–3
computadoras/computación 24, 203, 247–9, 354, 357, 397, véase también Tecnología de la información; software
fase de concepción 68–9, 73–104, 280–1, 288, 308, 348, 370, 556
fase conceptual 50, 128–32, 327, 599–600
ingeniería concurrente 51, 126, 308, 505–8
elementos de configuración (CI) 134, 135, 136, 137–8, 325
gestión de configuración 124, 324–6, 417–9, 499
conflicto 46, 495, 496, 555–9, 562
Consolidated Energy case 624–5
restricciones: costos y presupuesto 302; ciclos de vida 81; necesidades de gestión 7–8; recursos 209–16; alcance
definición 159; enfoques de sistemas 46, 49; teoría de 252–60, 260–2, 263
construcción: contratación 91; retrasos 16–8; fase de ejecución 385; proyectos internacionales 628, 652–5; estándares de productividad
laboral 314; proyectos a gran escala 502; redes 226–7, 228–30, 268–70; planificación 177–8; riesgo
379–82; partes interesadas 532; estructura 32–3; sostenibilidad 83–4; ingeniería de sistemas 140; EDT 184–5
contingencia: estimación 286–7; fondos 277, 280–1; proyectos internacionales 649–50; liderazgo 542–3, 562;
planificación 365, 681; reservas 309; tiempo 254–6
mejora continua 322–3, 338 contratistas:
conferencias 180; costos y presupuestación 275–6, 278, 280–1; integración 500–4; proyectos internacionales
636; ciclos de vida y concepción 70–1, 72, 75–6, 76–7, 79–80; vigilancia y control 391; duración del proyecto
268–70; calidad 323–4, 334; conflicto de usuario 555
conferencia de contratistas 180
contratos: administración 90, 419–20, 528; cambiar las cláusulas 277; cierre 443, 444, 445; costos y presupuesto 107,
116, 279, 288; incentivos 238; proyectos internacionales 634–5, 636, 649–50; tipos de 97-104; ciclos de vida y
concepción 90-107; planificación 161, 162, 684–5; riesgo 362, véase también adquisiciones, subcontratación
testigo: APM 461–4; gestión de búfer 259; cambio 124, 388, 416–9, 428, 436; cuesta 391–2, 400–2; costos y
presupuestación 278; diseño 388; ejecución 390–2, 395–400, 420, 426; funciones de dirección 21, 22; PMIS 438–9; gestión de
programas 592; calidad 320, 323, 324, 325–6, 335–7, 338; papeles 528; programación 396–400,
400–2
cuentas de control 168–70, 293–5, 309, 392–5
contexto corporativo 33, 503–4, 567–685
índice de rendimiento de costos (IPC) 402–5, 408, 409
costo más tarifa fija (CPFF) 99–100, 362
contrato de costo más incentivo (CPIF) 101–2 análisis
de costo-beneficio 321, 618–9, 622 cuadrícula de costo-
beneficio 618–9
análisis de rentabilidad 619–20
contratos de costo incrementado 93, 98, 99–100, 279, 288, 362,
555 costos: contratos 99–104, 107, 116, 279, 288; control 391–2, 400–2; método de la ruta crítica 232–8; definición 111;
diseño 364, 388; estimación 116, 275–315; fase de ejecución 393–5, 402–5, 408, 409, 420; internacional
proyectos 646–7, 656; producción ajustada 470; ciclos de vida 74; seguimiento 406; planificación 681, 682-3; PMIS
software 436; objetivos del proyecto 8–9; organizaciones puras de proyectos 492, 493; calidad 321; riesgo 358, 365, 371, 379–80;
selección 610–1; compensaciones de tiempo 232–8; incertidumbre 4, 410–2; WBS 167, 294–5; paquetes de trabajo 167, 285, 286,
309, véase también contabilidad, presupuestos; presupuestos
CPA un caso 33
CPFF ver costo más tarifa fija
CPI ver índice de rendimiento de costos
CPIF ver contrato de costo más incentivo
CPM ver método de ruta crítica
bloquear el proyecto 236–8

enfoques de cadena crítica (CC) 216, 252–60, 263, 397 gestión de
proyectos de cadena crítica (CCPM) 263, 396, 412 ruta crítica 195–202,
217
método de la ruta crítica (CPM) 232–8, 263
críticas críticas 327, 328, 433
factores transculturales 639, 644–5
equipos multifuncionales 308, 396, 497, 505, 507–8, 509
Software de bola de cristal 249
CSOW ver declaración de trabajo del contrato
CT ver tiempo de ciclo
cultura 10, 630–6, 639, 644–5, 651
clientes: APM 459; especificaciones de referencia 124; cierre 443; proyectos internacionales 636, 642–3; enlace 528;
diferenciación organizacional 486; calidad 334; reportando 435; requisitos 149–50; desarrollo de sistemas
ciclos 72, véase también partes interesadas; usuarios
Proyecto cibersónico caso 426
tiempo de ciclo (CT) 472–3, 475
Caso de la empresa de Dalian 8, 31–2
tableros 436, 585, 586
bases de datos 579, 581
suposiciones del día 1 220–1
defectos 318, 330, 344, 441–5
fase de definición: finalización de 385; conflicto 556; costos y presupuestación 288; proyectos internacionales 642–7, 650;
planificación 161–8; programas 588; proyecto y sistema 109–52; calidad 319; alcance 159–60; ciclos de desarrollo de sistemas 69
Delamir Roofing Company caso 32–3
Técnica Delphi 352 Deming,
W. Edward 319
Aeropuerto de Denver 16–8
diseño: cambios a 416, 418; ingeniería concurrente 506, 507, 508; costos y presupuestación 277, 306, 307, 308;
etapa de detalle 139–40, 385–8; ciclos de desarrollo 70; fase de ejecución 420; márgenes 363–4, 413–4; organizacional 484–6; gestión de
programas 599–601; calidad 321, 324–6, 334; reseñas 326–9; sistemas
ingeniería 133–40
equipos de diseño y construcción 126–7

enfoque de diseño-construcción-prueba 386, 387
enfoques deterministas 232–40, 243 ciclos de
desarrollo 67, 68–74, 280–1, 386
proyectos de desarrollo: costos y presupuestación 282, 306, 307, 308; fase de ejecución 385; internacional 628; nuevo
productos 30-2; riesgo 346, 347; sistemas 139–40, véase también desarrollo de productos
diferenciación 484–6, 508
directores 590
recuperación ante desastres 34–5, 38–
9 reglas de despacho 251–2
equipos distribuidos 552–3
estrategias de no hacer nada 366
documentación: APM 464; comunicación 433, 434–5; diseño 388; inspección 334–5; conocimiento 579, 593;
planificación 681; riesgo 367, 369, 370; equipos virtuales 553
competencia de dominio 518–9, 524, 525, 535, 650
Duarte, D. 554-5
fechas de vencimiento 202, 252–4, 255, 259–60
duración: simulación por computadora 247–9; método de la ruta crítica 232–8; producción ajustada 467; estructura de organización
497; planificación 195, 196, 197–200; división de actividades 213; sprints 460, ver también tiempo
Compañía Dynacom caso 428
primeros tiempos de finalización 197-8;
256–7 tiempos de inicio temprano 197–8,
300–4 valor ganado (EV) 23, 400–14, 427
factores económicos 277–8
esfuerzo, ver actividad
EIA ver declaraciones de impacto ambiental
nodos finales 192–3
artículos finales 110, 159, 385, 453, 454, 455, ver también inclusiones
compromiso 531–4, 535, 538–9, 589
ingeniería: costo 275, 284–6; sistemas 51–4, 527–8
Ingeniería, Procura y Construcción (EPC) 91
Proyecto del Túnel del Canal de la Mancha (Chunnel) 312–3, 362, 387, 444, 635
emprendedores 516
declaraciones de impacto ambiental (DIA) 83, 538

entornos 29–30, 44–5, 47, 48
EPC ver Ingeniería, Adquisiciones y Construcción
epopeyas 459-60
costos crecientes 99, 276–80, 308
EV ver valor ganado
evaluación: ofertas 180; comunicación 431, 432–41, 448, 451; modularización 53–4; proyecto 30, 430–1, 607–9;
propuestas 106–7; despliegue de la función de calidad 141–6; reseñas 448; resumen 445–7; Ingeniería de Sistemas
136–8, 139
EVM ver gestión del valor ganado
procesos en evolución 10, 112, 216–7, 325–6, 386, 457, 577, 585–6
tipos de cambio 278, 637
fase de ejecución: control de cambios 416–9; carta de contraste 117; conflicto 557; costos y presupuestación 292;
seguimiento y control 385–429; planificación 75, 113–4, 156–8, 670–85; programas 588; gestión de la calidad
321, 322; riesgo 366; horarios 172; ciclos de desarrollo de sistemas 69–70
tiempos esperados 242, 243, 244, 371
valor esperado 358, 359, 360, 370–2, 373, 610
expeditors 489–91, 509
gastos 288–92, 303, 304, 357
experiencia 278, 282–3, 520, 521–2
extensiones 447–8
extranets 437
F117 Caza furtivo 369, 508
FAA ver Administración Federal de Aviación
fabricación 140, 286, 389, 600
Análisis modal de fallas y efectos (FMEA) 330–1, 332, 351, 358 vía rápida
72, 246, 387 fase de factibilidad 74–84, 85, 130, 306, 574–5, 599, 625
Administración Federal de Aviación (FAA) 52–3
amortiguadores de alimentación 254–6, 257, 258
FEL ver carga frontal
cuadros de fiebre 396–8
FFBD ver diagrama de bloques de flujo funcional
Fiedler, F. 542-3
gerentes de campo 528
Copa Mundial de la FIFA, Sudáfrica 341–4 factores
financieros 33, 74–5, 78, 610–1, 618–9, 654, véase también presupuestos; costos
tiempos de finalización 205, 206, 208, 228, 229
diagramas de espina de pescado ver diagramas de causa y efecto
contratos de precio fijo (FP) 93, 98–9, 102, 279, 288, 362, 555
sistema de beneficios flexibles 40
recuperación de inundaciones 38–9
FMEA ver Modo de Falla y Análisis de Efectos
pronósticos 298, 305, 408–10
enfoques formales 327, 328, 433–5, 451, 483–515, 632, 648
evaluación formativa 430, 431
fase de formulación 587, 599 modelo
de cuatro fases del ciclo de desarrollo del sistema 68–70, 110
FP ver contratos a precio fijo
FPIF ver contrato tarifa incentivo precio fijo
Chasis, J Davidson 78–9
marcos, enfoques de sistemas 48–51 carga frontal
(FEL) 69, 118, 625–6
vehículos de bajo consumo 306
estructuras de desglose del trabajo orientadas a funciones 163, 165
áreas funcionales: líneas base 132; conflicto 555–6; diseño 386, 420; diferenciación 485, 486; expedidores 490;
integración 507–8; gestión 492–3; estructuras matriciales 493, 495–6, 512–3; organización 499, 504–5,
508–9, 511–2; revisiones de preparación 327; informes 434–5; requisitos 121–2, 130–1; roles 515, 524, 529–30;
paquetes de trabajo 295
diagrama de bloques de flujo funcional (FFBD) 121, 130–1, 133, 136 proyectos
de campañas de recaudación de fondos 33–4
embudo y filtro 609
G&A ver gastos generales y administrativos
Diagramas de Gantt 23, 172–7, 186, 190, 200–1, 202–3, 394, 408
procesos de entrada 72, 472, 573, 606, 609 gastos
generales y administrativos (G&A) 290–2
general eléctrica 628

Motores generales 491
modelos de sectores de población generalizados 50
cuestiones geonacionales 636–8
diferenciación geográfica 485–6
Gilbreath, Roberto 55
Distrito Sanitario del Condado de Glades 57
proyectos globales 58, 643–4, ver también proyectos internacionales
GMP ver precio máximo garantizado
metas: costos y presupuestación 281–2; funciones de dirección 21; programas 587, 595; caracteristicas del proyecto 3,
8–9; procesos de selección 616–8; enfoques de sistemas 43, 49; equipo 545, 546, 552
proyectos de minas de oro 150–1, 427
Goldratt, E. 216, 257
Goman Publishing Company 26–7 bienes,
trabajos o servicios (GWS) 179–82
Proyecto Gorgy caso 313–4
gobernanza 589, 590
proyectos y programas gubernamentales 29–30, 34–6
Caso del proyecto Grand Entry 477–8
Gran Pirámide de Keops 1, 2
manejo de conflictos grupales 558–9
problemas de proceso de grupo 547
software de productividad grupal 437
pensamiento grupal 557
trabajo en grupo 552–3
precio máximo garantizado (GMP) 100, 101, 102
garantías 362–3
GWS ver bienes, trabajos o servicios
Hábitat para la Humanidad 232–3
proyectos de hardware 465, 479, 628
Harrison, F. 417
Estudio de riesgos y operabilidad (HAZOP) 351
peligros 113, 348–9, 355
HAZOP ver Estudio de riesgos y operabilidad

política/plan de salud, seguridad y medio ambiente (HSE) 113
Hersey, pág. 543
métodos heurísticos 251–2
estructuras jerárquicas 45, 46, 174–7
requisitos del sistema de alto nivel 120–1
Hofstede, G. 630, 657
estructuras horizontales 23, 487, 495, 504, 505, 508–9
sistemas hospitalarios 81–2, 105, 587
ejemplos de construcción de casas 116, 162, 163, 232–3
Matriz de la Casa de la Calidad 141–4
HSE ver política/plan de salud, seguridad y medio ambiente
sistemas creados por humanos 42, 43, 47–8
Recursos en forma de I 473
IBC ver Compañía Mariposa de Hierro
IGPS ver resolución de problemas intergrupales
fase de implementación 389–90, 430, 440–1, 448, 512–3, 599, 600
incentivos 93, 101–4, 238, 239
incremental TPM 454–5, 457
indicadores 413–4
índices 402–5, 405–6
individualismo 630
influencia 354–5, 520, 521, 535, véase también autoridad; energía
enfoques informales 328, 433, 439–40, 451, 483, 487, 648
información 277, 279, 292, 293, 437, 450–1, 681, véase también conocimiento
tecnología de la información 89, 187–8, 595, 596, ver también computadoras/computación; software
fase de iniciación 73–4, 89–90, 94, 287–8, 574–5, 587
relación entrada-proceso-salida 45–6
inspecciones 316, 323, 334–5, 343
instalación 441, 446–7
seguro 360–2
integración 46, 145, 168–70, 483–514, 516, 519, 534, 620–1
interdependencia 48, 354–5
interfaces: cliente 677–8; eventos 172; ciclos de vida 81; gerente 518–9; planificación y control 9; software PMIS 436;
gestión de programas 591; enfoques de sistemas 48, 49, 136
resolución de problemas intergrupales (IGPS) 551–2
Asociación Internacional de Gestión de Proyectos (IPMA) 10, 13–4
proyectos internacionales 278, 628–58
Estación Espacial Internacional 2, 3, 502
Internet 431
intranets 437
inversión 652–5
IPMA ver Asociación Internacional de Gestión de Proyectos
Iron Butterfly Company (IBC): solicitudes de cambio 419; diferenciación funcional 485, 486; redes 270–1;
estructura organizativa 491, 492, 494, 511; planificación 158, 159–60, 168, 171; propuestas 663–9, véase también
Proyecto LOGON; Compañía de paquetería del medio oeste
diagramas de Ishikawa ver diagramas de causa y efecto
Ishikawa, Kaoru 335
gestión de problemas 414–6, 433
enfoques iterativos 53–4, 124–5, 455–8, 470, 474
Industrias Jamal caso 70–1
JLEP ver Proyecto de extensión de la línea Jubilee
Johnson, Kelly 521–2
empresas conjuntas 359, 502
Proyecto de extensión de la línea Jubilee (JLEP) 59–61
Kanban 473–4
Wilma Keith caso 564
reuniones iniciales 111–2, 554
conocimiento: cuerpos de 10, 12–3; gestión 350, 577–82, 584, 593; modelos de madurez 571–2, véase también
información
Caso de productos Kulczydski 187–8
mano de obra: costo y presupuestación 285, 286, 289–90, 293, 395; proyectos internacionales 633–4, 636, 647; planificación y
redes 210, 211, 212, 230; estándares de productividad 314
gastos generales del proyecto intensivos en mano de obra 291 retrasos
204, 229 lenguaje 631–2, 647, 656

LaPage Power Company caso 107 proyectos
a gran escala (LSP): antiguo 1–2; integración 500–4; diagramas de red 226–7; estructura de organización
509; plantas de procesamiento 331, 333; oficina de proyectos 499; subcontratación 92
horas de inicio tardío 300–5
lavasoft.es caso 149-50
derecho internacional 634, 649–50
LCC ver costo del ciclo de vida
liderazgo 21, 22, 529–30, 542–3, 562, 583, 638–40 producción
ajustada (LP) 319, 453, 464–74, 474, 587
enfoques de aprendizaje 4, 158, 455–6, 468–9, 593
aspectos legales 519, 520, 634, 649–50
cartas de interés 69
nivelación, recurso 210–2, 215–6
enlace 488–9, 528, 585, 599
costos del ciclo de vida (LCC) 74, 306–8, 312
ciclos de vida: conflicto 556–7; costos y presupuestación 280–1, 292; interfaces 81; metodologías 573, 574; etapas
453–5; PMIS 437–8; enfoques de sistemas 50–1, 52, 67–108, 386
método de línea de equilibrio (LOB) 177–9
métodos de programación lineal 177–9 litigio 634–
cargando, recurso 210
LOB ver método de línea de saldo
nivel local 630–6, 639–40, 641, 650
Lockheed-Martin 507–8, 521-22
Proyecto de sistema logístico en línea (LOGON): finalización 409–12; costo y presupuestación 300, 301–2, 303, 304; carga de equipos 214; diagramas
de Gantt 173; redes 194, 270–1, 300; organización 491, 492, 511;
desempeño 402–4, 506; planificación 158, 159–60, 165, 167, 168, 171, 681, 684–5; propuestas 663–9; recurso
restricciones 211, 212; solicitud de propuesta 659–62;
Proyecto de sistema logístico en línea (LOGON) (cont.) roles 537; programación 201, 203, 215; informes de estado 450; trabajar
progreso 394, véase también Iron Butterfly Company; Compañía de distribución de paquetes del medio oeste
planificación logística 181–2
INICIO DE SESIÓN ver Proyecto de sistema logístico en línea
Lohnes, Pablo 465
Proyecto del sistema subterráneo de Londres 59–61

LP ver producción ajustada
LSP ve proyectos a gran escala
Proyecto del Orbitador Lunar 541–2
Proyecto Mars Climate Orbiter 565
Proyecto Mars Pathfinder 328, 398–9
Marshall Field's, caso de recuperación ante desastres 38–9
estructuras matriciales: gestión 27; organizaciones 251, 493–6, 497, 498, 509, 556; investigación y desarrollo
512–3; responsabilidad 170; riesgo 350
madurez 349, 543, 569–72, 593
Maxim Corporation América (MCA) caso 595-6
MCA ver Maxim Corporation América
Proyecto McCormick Place Oeste, Chicago 534
reuniones 432, 433–4, 461, 464, 472–3, 554–5, 559, 648–9
gestión de megaproyectos 593
Melbourne Construction Company casos 228–30, 314
Programa de Exploración de Mercurio caso 599–600
sesgo de fusión 240, 246, 351
metagestión 569–603
Metodología M-Gate 597–8
microgestión 369–70
Microsoft 71, 73, 399, 446, 498, 526, 557–8
Midwest Parcel Distribution (MPD) Company 87–8, 158, 159–60, 270–1, 450, 659–62, véase también Iron Butterfly
Compañía; Proyecto INICIO DE SESIÓN
gestión de proyectos militares 30
enfoques de modelado 50, 139, 331–3, 570–1
modularización 51, 52, 53–4
seguimiento: cierre 443; cuentas de control 294–5; fase de ejecución 385–429, 390–2, 395–400, 420; internacional
proyectos 647–8; gestión de problemas 415; desempeño 405–6; progreso 196; riesgo 366, véase también seguimiento
Métodos de simulación Monte-Carlo 247–9, 359
Moreland Systems caso 107
escenarios más probables 238, 240, 242, 410–2
Proyecto Motorola RAZR 507–8, 597–8
Monumento Nacional del Monte Rushmore 516–8

industria del cine 527
Proyecto Mozal 652–5
MPD ver Compañía de distribución de paquetes del medio oeste
enfoques de planificación de varias fases 144–5
enfoques de proyectos múltiples: comunicación 434, 436; metagestión 593; organización 493, 500, 530;
recursos 260–2, 263; programación 251–2
multitarea 212–3, 258–9
enfoques multidisciplinarios 51, 52
equipos multifuncionales 488–9, 490–1
horarios multinivel 174–7, 176
métodos de diagramación de precedencia múltiple 206–9 proyectos
de equipos múltiples 545 métodos de criterios múltiples 613–4
NA ver División Espacial de la Aviación de América del Norte
El enfoque de Napoleón 369
NASA: metagestión 599–600; estructura organizativa 484; gestión de proyectos y programas 35–6, 599-
601; propuestas 95–6, 97, 106–7; trabajo en equipo 541–2, 565; complejidad técnica 7
desastres naturales 4
sistemas naturales 47–8
necesidades 7–8, 73, 78–81, 82, 128–32, 664–5, véanse también los requisitos
El puente Nelson Mandela 381–2
métodos basados en red 23, 190–231, 232–74, 351, 372, 435, 521
gastos generales del proyecto que no requieren mucha
mano de obra 291 enfoques no planificados 369
proyectos de campañas de recaudación de fondos sin fines de lucro 33–4
no gestión de proyectos 21–41
actividades no críticas 196, 199, 200
desarrollo de sistemas no integrados 504–5
Invasión de Normandía 3–4
North American Aviation's Space Division (NA) 95–6 novedad,
tecnología, complejidad, ritmo (NTCP) modelo 4–7, 16–8
NTCP ver novedad, tecnología, complejidad, modelo de ritmo
industria de la energía nuclear 283–4, 356, 359–60

Nuwave Products Company caso 537-8
objetivos 43, 49, 80, 550, 604
diseños listos para usar (OTS) 132, 282
compensaciones 637–8
foros de discusión en línea 437
entrenamiento en el trabajo 526
sistemas abiertos 46–7
fase de operación: costos 306, 307; directrices 551; instalación y conversión 441, 447–8; ciclos de vida 70, 80–1,
140; seguimiento y control 390
escenarios optimistas 238, 240, 242, 410–2
informes orales 431
organizaciones orgánicas 487
organización: complejidad 7; planes de ejecución 157; integración 483–514; Proyecto LOGON 511, 668, 674–8; NASA
35–6; planificación 168–70; programas 590–1; formulario de proyecto puro 24; reputación de 25; enfoques de sistemas 47
OTS ve diseños listos para usar
subcontratación 148, 179–80, 649, véase también adquisiciones, contratos
gastos generales 290–2
supervisión 500–4
proyectos de ostras 614, 615
ritmo 6
estimaciones de tiempo rellenadas 252–4, 255, 258–9
Papua Petroleum Company caso 271-2
Principio de Pareto 214, 329–30, 336–7
participación 35–6, 541–66, 543, 561, 562
pago 443, 634–5, 637
tablas de pagos 373–5
PBS ver estructura de desglose del programa
PCAS ver sistemas de contabilidad de costos de proyectos
PC 625–6
PDM ver método de diagramación de precedencia
Proyectos Pearl 614, 615
enfoques de pares 328, 433, 579, 580–1, 607

cargos de penalización 238
rendimiento: APM 462–4; corporativo 598; evaluación 430; fase de ejecución 394–5, 420; metas 8–9; garantía 305; incentivos 102–3; madurez 572;
requisitos 121, 316; reseñas 446–7; normas 390, 391; sistemas
ingeniería 131–2; TPM 337, 396, 413–4, 465, 474, ver también progreso
análisis de rendimiento 400–14, 436, véase también valor ganado
personal 529, 668–9
PERT ver Técnica de Evaluación y Revisión de Programas
estimaciones pesimistas 242, 247, 410–2
aproximaciones por fases 68–74, 114–6, 150–1, 217, 389, 573, 587–8 operación
piloto 441 Pinhole Camera and Optics, Inc. caso 511–2
valor planificado (VP) 400–2
planificación: APM 461–4; técnicas básicas 155–89; gestión de beneficios 589; cierre 443, 444; comunicación 432–3, 648; fase de definición 112–6;
diseño 388; FEL 118; funciones de dirección 21, 22; implementación 389–90; proyectos internacionales 629, 648, 650, 656; trabajo 210, 211, 212,
230; ciclo de vida 110; Proyecto INICIO DE SESIÓN
666–7, 668, 670–85; PMIS 435, 438–9; propuestas 87; calidad 320, 321–2, 323, 338; riesgo 360–6, 367, 368, 370; programación 170–9, 190–231,
680; ciclos de desarrollo de software 71; participación de las partes interesadas 532–3; estrés
gestión 561; requisitos del usuario 119
PMI ver Instituto de Gestión de Proyectos
PMIS ver sistemas de información de gestión de proyectos
PMO ver oficina de gestión de proyectos
Polanski Developers caso 107
Programa del sistema de misiles Polaris, US Navy 241
política 635
gestión de carteras 29, 32, 74, 434, 436, 530, 587, 596, 604–27 revisiones posteriores
a la finalización 322–3, 445–7, 578
recuperación posdesastre 34–5
autopsias 158, 578, ver también revisiones posteriores a la finalización
productos potencialmente transportables (PSP) 458, 460
poder 495, 522, 630, véase también autoridad; influencia
método de diagramación de precedencia (PDM) 204–9, 217, consulte también actividad en el nodo
relaciones de precedencia 173, 190, 208, 226, 252, 256–7 diseño preliminar
133–8, 327
preselección 74, 87, 607–8

Metodología PRINCE2 10, 15–6, 117, 575
reglas de prioridad 251–2, 253, 260
resolución de problemas 551–2
proceso 12–3, 45–6, 234, 319, 351, 486, ver también funciones
adquisiciones 68, 73–104, 179–82, 400, 419, 592, véase también subcontratación, contratos
desarrollo de productos: APM 453–80; ciclos 30–2, 70–1; iniciación 89; estructura organizativa 498, 511–2; calidad
331, 332, 333, 335; reseñas 327; riesgo 374; conflicto de equipo 557–8; requisitos del usuario 119, véase también desarrollo
proyectos
diferenciación del producto 486
ciclos de vida del producto 50
gestión del producto 28–9
estructuras de desglose del trabajo orientadas al producto 162
producción 70, 140, 388–90, 464–74, 528 estimadores
de costos profesionales 278
estructura de descomposición del programa (PBS) 595
Técnica de Evaluación y Revisión de Programas (PERT) 241–50, 244, 263, 359, 392
gestión de programas 28, 434–5, 484, 500, 531, 586–93, 599–601, 605
progreso 196, 343, 393–5, véase también rendimiento
amortiguadores de proyectos 254–6, 257, 258,
262 sistemas de contabilidad de costos de proyectos (PCAS) 292–3, 392, 393–
4 sistemas de información de gestión de proyectos (PMIS) 292, 293, 435–9, 448
Instituto de Gestión de Proyectos (PMI) 10, 12–3
filosofía de gestión de proyectos 10–1 oficina de
gestión de proyectos (PMO) 494, 498–500, 527–9, 582–6, 593, 625, 640–1, véase también apoyo
modelos de procesos de gestión de proyectos 570–1
propuestas: evaluación 106–7; planes de ejecución 156–7; conocimiento 579; ciclos de vida 69, 75, 76–7, 84–6, 94; NASA 95–6, 97, 106–7;
planificación de proyectos por etapas 150–1; solicitudes de 76–7, 660–2, 663–9; declaración de trabajo 84,
106, 659–60, 664
prototipos 124–5, 139, 149, 331–3, 365
PSP ve productos potencialmente entregables
proyectos y programas del sector público 34–6
Puerto Rico caso 655-6
listas de golpes 443, 444
pura gestión de proyectos 27, 515

organizaciones puras de proyectos 24, 491–3, 497, 509
PV ver valor planificado
QFD ver despliegue de la función de calidad
calificaciones 76, 89, 522–6, 668–9
calidad 316–45, 349, 396, 389, 468, 529 despliegue
de funciones de calidad (QFD) 127, 141–6, 337
cuantificativismo 10
colas 470–2
enfoques de clasificación 613–4, 617, 619
prototipos rápidos (RP) 124–5
sistemas de clasificación 87–8, 353, 355–6, 357–8, 571, 593, 611–2
Proyecto RAZR, Motorola 597–8
RCR ver calificación de consecuencia de riesgo
ECA ver técnicas de aclaración de roles
proyectos inmobiliarios 85
estimaciones de tiempo realistas 254
proyectos de reconstrucción 34–5
contratación 524
gerentes orientados a las relaciones 542, 543, 562
relaciones: proyectos de desarrollo de aeronaves 58–9; proyectos internacionales 641–2; proyectos a gran escala 500;
programas 590; enfoques de sistemas 42–3, 45–6, 48; tiempo-costo 233–4
informes 399, 431, 432, 434–5, 445–6, 448
solicitud de propuesta (RFP) 68–9, 76–7, 85, 86, 95–6, 106, 625, 659–62
requisitos: APM 464, 477; cambios a 416; contratos 97–8; costos y presupuestación 277; cliente 149–50;
definiendo 79–81, 82, 118–23, 126, 129, 144; diseño 387; márgenes de diseño y riesgo 364; metas 8–9; proyectos internacionales 642–3;
producción ajustada 467, 468, 469; organizaciones 487; rendimiento 316; planificación 681; proyecto
y contraste de definición del sistema 110–1; calidad 144, 317; especificaciones 123, 124; ingeniería de sistemas 130–1,
135–6; usuarios 78–81, 82, 118–20, 123, 124, 387; estructuras de desglose de trabajo 162, véase también necesidades
investigación y desarrollo 277, 512–3
reservas 203–4, 277, 367, 371, 396, 397, 398–9
amortiguadores de recursos 256–7, 258, 262, 399
gestión de recursos 436

recursos: asignación 251–2, 260–2; cadenas críticas 256; proyectos internacionales 646–7; consulta entre pares 580–1;
PMO 584; selección de proyectos 616; organizaciones puras de proyectos 492; programación 209–16, 227, 233, 234, 246,
251–2; enfoques de sistemas 49
responsabilidades: APM 458; contratistas de integración 502; proyectos internacionales 638–40, 645; gerente 526–7, 534,
544; matrices 170, 171, 182; metodologías 573, 575; participativo 35-6; planificación 168–70, 675, 676; PMO 585–6; gestión de carteras 606–7;
problemas con 59, 60; gestión de programas 28, 589; gestión de calidad 321, 322; riesgo 362–3; roles 515, 518, 520; rescisión y liquidación 443–
4; desglose del trabajo
estructuras 162
Caso de productos Revcon 148–9
reseñas: APM 464; tableros 585, 625; cierre 443; comunicación 433–4; evaluación 448; producción Lean
472–3; LOGON Proyecto plan 681; desempeño 413–4; planificación 115; PMO 585; gestión de la cartera
606–7; posterior a la finalización 322–3, 445–6, 446–7, 578, 580; gestión de programas 600–1; progreso 395; calidad
gestión 326–9, véase también procesos de activación
RFP ver solicitud de propuesta
Rico, Ben 521–2
riesgo: contratos 99, 100; proyectos internacionales 629, 637, 649–50, 651, 656; gestión de problemas 414, 415; inclinarse
producción 470; gestión 346–84, 595–6; gestión de programas 591
calificación de consecuencia de riesgo (RCR) 357–
8 número de prioridad de riesgo (RPN) 331
Proyecto de autopresupuesto de robótica (ROSEBUD) 195, 196, 207–8, 294–8, 299, 354, 357, 404–5, 408
técnicas de aclaración de roles (RCT) 559
roles 515–40, 560, 583–5, 590, 641
planificación de olas rodantes 195
Romano, Daniel 29
ROSEBUD ver Proyecto de autopresupuestación de robótica
RP ver prototipos rápidos
RPN ver número de prioridad de riesgo
Rutan, Burt 30–1, 129, 141, 312
Proyecto del Sistema de Operaciones de Tráfico y Coordinación de Señales del Condado de Santa Clara 61–2
Santero Asociados caso 147-8
Arabia Saudita proyecto 628
metodologías escalables 283, 576, 577 índice de
rendimiento del cronograma (SPI) 402–5

programación: análisis avanzado 232–74; cierre 443; control 396–400, 400–2; costos y presupuesto 275, 298,
300; retrasos a 279–80; márgenes de diseño 364; fase de ejecución 393–5, 420; incentivos 102–3; proyectos internacionales 646–7;
metagestión 598; seguimiento 396–400, 406; planificación 170–9, 190–231, 680; PMIS
software 435; adquisiciones 180–1, 182; propuestas 666–7; riesgos 348, 364, 365, 371, 372; manejo del estrés
561; presupuestos por etapas 309
alcance: cambio 416, 427; controlar 395; proyectos internacionales 643–4; planificación 157, 159–61, 182, 678–80;
verificación 323
modelos de puntuación 611–2
cribado 608
melé 457–64, 470, 474, 477
COSUDE ver ciclos de desarrollo de sistemas
procesos de selección 86–9, 494–8, 524, 537–8, 604–27, 661
autogestión 473–4
alta dirección 434, 518, 530–1, 535, 583, 640–1
sensibilidad 613, 625, 638–9
desarrollo de sistemas en serie 504–5
proyectos del sector servicios 33–4
sistemas de alcantarillado 57
Hospital Shah Alam caso 8, 40
NTCP Diamante 7 de Shenhar y Dvir
regla de tiempo de tarea más corto 252, 253
Sigma Associates caso 293, 438–9
proyectos de coordinación de señales 61–2, 151
Simón, Herbert 53
simulación 247–9, 375
métodos de criterio único 613
gestión del sitio 431, 528
enfoques situacionales 542–3
Seis Sigma 319, 338
Mofeta trabaja 507–8, 521–2
holgura 200–2, 254, 259
deslizamiento 91, 103, 202, 280, 399, 479, 511, 557
SLU ver Universidad de South Land
pequeños lotes 466–70, 474

pequeños proyectos 32–3, 254, 255, 284–6
Nieve, CP 10
proyectos de estadios de fútbol 341–4
factores sociales 27–8, 277–8, 561–2, 632
software: APM 453–80; cuesta 391–2; cadenas críticas 260; internacional 628; redes y programación 263; estructura organizativa 498; PMIS 435–7, 438–
9, 448; PMO 584; ciclos de desarrollo del sistema 71, véase también
ordenadores
Proyectos de Sudáfrica 341–4, 381-2, 427
Caso 450–1 de la Universidad de South Land (SLU)
SOW ver declaración de trabajo
Transbordador espacial programa 7, 356
SpaceShipOne (SS1) 30–1, 80–1, 129, 133, 139, 140–1, 306–7
naves espaciales: transbordador Challenger 316, 356; márgenes de diseño 364, 413–4; requisitos del sistema de alto nivel 120–1;
costos del ciclo de vida 306–7, 312; especificaciones 122, 123–4, 132; ingeniería de sistemas 131, 132, 134, 135, 136; compensaciones 137–8;
estructuras de descomposición del trabajo 164; Proyecto Premio X 82
especificaciones: construido 325; cambios a 416; calidad 317, 320, 323, 334, 338; sistema 122, 123–4; sistemas 132
SPI ver índice de rendimiento del cronograma
modelos en espiral 456–7, 474
Spirit Electronics Company caso 655-6
división de actividades 212–3
patrocinadores 531, 590
sprints 126, 457–8, 460–4, 474, 478, 479
SS1 ver SpaceShipOne
partes interesadas: ciclos de desarrollo 58, 72–3; compromiso 531–4, 535, 538–9, 589; iniciación 89–90; internacional
proyectos 636, 650; gestión de programas 589; calidad 342, 343; riesgo 349; roles 515–40; Ingeniería de Sistemas
51, 52, 128–9, véase también clientes; usuarios
estandarización 26, 166, 472, 572–3, 593
normas: seguimiento y control 390, 391; planificación 681; PMO 583–4; profesional 10, 12–6; proyecto
metodologías de gestión 574; calidad 321, 323; sostenibilidad 84
manuales de normas 286
reuniones de pie 433
Caso de construcción de tablero de estribor 147–8
hora de inicio 192–3, 197–200, 204–5, 228, 229
control de arranque y parada 393

Startrek Enterprises, Inc. caso 185–6 declaración
de trabajo (SOW): contratos 94; proyectos internacionales 643–4; planificación 157, 159–61, 182, 678–80;
propuestas 84, 106, 659–60, 664
Proyecto de renovación de la Estatua de la Libertad 25, 546
informes de estado 450
reuniones de revisión de estado 433–4
comités directivos 640–1, 650
enfoques estocásticos 240–72
Tormentas, Harrison 95–6
enfoques estratégicos 604, 606, 616–8
estrés 559–62
síndrome de los estudiantes
259 subcontratación 91–2, 362, 650, 675–7, 684–5, véase también contratación
especialistas en la materia 524
subsistemas 43, 44, 51, 54, 646, véase también estructura de descomposición del trabajo
subunidades 487–96, 508–9
sucesores 199–200, 201–2, 256–7
resumen, costo 295–9
evaluación resumida 445–7
matrices resumen 645, 646
planes resumidos 156
informes resumidos 434
evaluación sumativa 430
proyecto de avión comercial supersónico 306
soporte 140, 498–500, 513, 531, 561–2, 581, 584, 636, véase también oficina de gestión de proyectos
sostenibilidad 83–4
La Ópera de Sydney 379–80
Synder, N. 554–5
enfoques de sistemas: definición 109–52; inspección y prueba 334–5; planes de proyectos integrados 168; visión general
22, 37, 42–63; contraste del proyecto 110–1; requisitos 120–1, 123, 124
ciclos de desarrollo de sistemas (SDC) 67, 68–74, 280–1, 386 proyectos de
desarrollo de sistemas 30–2, 254, 255, 324–35, 504–5 , 507–8
ingeniería de sistemas 51, 52, 128–41, 499; V-modelo 53–4

Recursos en forma de T 473
objetivos 199, 202, 203–4, 246, 281–2, 399, 413–4
grupos de trabajo 488–9
tareas 163, 170, 172, 542, 574–5, consulte también paquetes de trabajo
enfoques de formación de equipos 112, 547–8, 562, 641–2
equipos: APM 459; características 9; comunicación 565; transcultural 639; multifuncional 308, 396, 497, 505,
507–8, 509; procesos de inspección 334–5; integración 488–9; proyectos internacionales 641–2; administración
544–55; organización 506–8; roles 527–9; definición del sistema 126–7; trabajando en 541–66, 562
aspectos técnicos: auditorías 329; complejidad 7; requisitos funcionales 121; gerentes 519, 524, 525–6, 527, 535;
planificación 157, 678–85; propuestas 661–2, 665; riesgo 348–9, 363; programar la nivelación 215–6
modelos de procesos de entrega técnica 570 medición
del desempeño técnico (TPM) 337, 396, 413–4, 465, 474 tecnología 4–7, 16–8, 241, 356, 431,
479, 646, 649
Caso de la empresa Tecknokrat 598
caso de satélite de telecomunicaciones 580–1
terminación 441–5, 448
prueba 30, 50, 124–5, 139, 334–5, 440–1, 467, 468–70
teoría de las restricciones (TOC) 252–62, 263
pensamiento, sistemas 42–3 Thompson, C. 394–5
tiempo: proyectos limitados 209–10; contingencias 254–6; estimaciones 242–6, 271, 407; acabado 205, 206, 208, 228,
229; metas 8–9; proyectos internacionales 633, 638, 646–7; producción ajustada 472; costos del ciclo de vida 306; redes 300–4; relleno 252–4, 255,
258–9; gestión de programas 28; riesgo 358, 371–2; programación 197–200; trabajar
paquetes 167, ver también duración
tiempo, sentimiento y enfoque 546
tiempo y material (TM) 100
amortiguadores de tiempo 396–8, 399;
compensaciones de costo-tiempo 232–8, 239
incertidumbre de costo- tiempo 280–1
presupuestos de fase de tiempo 293, 309
redes de escala temporal 207, 208
caja de tiempo 458, 460, 464
TM ver tiempo y material
TOC ver teoría de restricciones

alta dirección 434, 518, 530–1, 535, 583, 621, 640–1
análisis de arriba hacia abajo 53,
54 enfoques de arriba hacia abajo 287–8
Modelos de organización total 571
gestión de calidad total (TQM) 319, 338
holgura total 200–1, 202, 221
Puente de la torre, Londres 316–7
Toyota 453, 466
TPM véase Medición del rendimiento técnico
TQM ver gestión de calidad total
trazabilidad 124, 131, 134, 135, 164, 325
Track & Found, Inc. caso 479
seguimiento: APM 461–4; gestión de configuración 325; método de valor ganado 23; ejecución 366, 426; Gantt
gráficos 174; proyectos internacionales 645; riesgo 366; control de horarios 396–8; ver también monitoreo
compensaciones 93, 137–8, 413–4, 506, 619
gestión de proyectos tradicional (TPM) 453–5 sistema de
operaciones de tráfico y proyecto de coordinación de señales 61–2, 151
entrenamiento 440, 524–6, 640, 647, 678
gestión de transición 591
procesos de prueba y error 386
confianza 554, 636
desastre del tsunami 34, 35
construcción de túneles 312–3, 339–41, 362, 387, 444, 533–4, 635
roles de dos sombreros 496, 526
incertidumbre: duración de la actividad 240–72; costos y presupuestación 4, 277, 280–1, 286–7, 410–2; producto final 453, 454,
455; proyectos internacionales 630; producción ajustada 470; organización 486, 487, 497; saldo de cartera 615; necesidades de gestión de proyectos
7–8; riesgo 347, 363, 373–5, véase también gestión ágil de proyectos
proyectos de sistemas subterráneos 59–61
usuarios: APM 459, 477; conflicto de contratistas 555; capacitación en implementación 440; necesidades y requisitos 78–81, 82,
118–20, 123, 124, 387; planificación 678; informes 435, véase también clientes; partes interesadas
historias de usuarios 459–60, 461
utilidad 613–4
Vaill, Pedro 545–6, 547
valor 317, 613–4
Aeropuerto de Vancouver 365
efectos de variabilidad 240–72
tiempos de actividad variable 232–74, 238–41
varianza 391–2, 405–6
requisitos de verificación 131–2
estructuras verticales 487, 504, 505, 509
estructuras verticales-horizontales 494–5
videoconferencia 431
construcción de aldea 271–2
Virgin Galactic 31
reuniones virtuales 554–5, 648–9
equipos virtuales 552–3, 562
declaraciones de visión 73
congelación visual 399
gestión visual 473–4
V-modelo 53–4
garantías 362–3
Warren Warehousing Company caso 284
válvulas de nivel de agua 148–9
metodología cascada 125, 126
WBS ver estructuras de desglose de trabajo
WCMC ver Centro Médico de la Universidad de la Costa Oeste
proyectos de desarrollo de sistemas de armas 501
sitios web 8, 149–50, 436–7, 477–8
Caso Welbar Inc. 148–9
West Coast University Medical Center caso 105 tablero blanco
enfoques 461–2, 474
elefante blanco proyectos 615, 616
White Knight 30, 31, 133 trabajo:
APM 471, 474; cambios 418; definición 161–8, 591–2; esfuerzo 462–4; flujos 472; idiomas 648; inclinarse
producción 469; cargando 212, 214, 215; patrones 633–4; estrés 560–2
estructuras de desglose del trabajo (WBS): costos y presupuestación 167, 294–5; creación de redes 193; internacional
proyectos 644–5; planificación 161–70, 173, 182; propuestas 85; riesgo 351; relleno de tiempo 258
paquetes de trabajo: cuentas de control 294–7, 392–5; costos y presupuestación 167, 285, 286, 309; proyectos internacionales
645; desempeño 402–5; planificación 161, 165–6, 167, 168, 173; supervisores 529–30
talleres 548–9, 550
Copa del Mundo, Sudáfrica 341–4
Wutzrite Company caso 85
Caso de X-philes Data Management (XDM) Corporation 106
Proyecto X-Prize 30–1, 82, 129
XDM ver Corporación de gestión de datos X-philes


Español Proyect Management For Engineering, Bussiness and Technology 5th Edition

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Español Proyect Management For Engineering, Bussiness and Technology 5th Edition

Cargado por

Copyright:

Formatos disponibles

Machine Translated by Google

Machine Translated by Google

Gestión de Proyectos para Ingeniería,

• Actualizaciones para cubrir los últimos desarrollos en el proyecto

• Referencia cruzada a las metodologías IPMA, APM y PRINCE2 •

John Nicholas, PhD, es profesor de Gestión de Operaciones en la Universidad de Loyola,

Herman Steyn, PhD, es profesor en la Graduate School of Technology Management de la

Mark Calabrese, Universidad de Florida Central, EE. UU.

Barrie Todhunter, Universidad del Sur de Queensland, Australia

Martijn Leijten, Universidad Tecnológica de Delft, Países Bajos

Benita Zulch, Universidad del Estado Libre, Sudáfrica

Richard Kamm, Universidad de Bath, Reino Unido

Gestión de Proyectos para Ingeniería,

Quinta edición publicada en 2017

2 Park Square, Milton Park, Abingdon, Oxón OX14 4RN

711 Tercera Avenida, Nueva York, NY 10017

© 2017 John Nicholas y Herman Steyn

con las secciones 77 y 78 de la Ley de derechos de autor, diseños y patentes de 1988.

sistema de almacenamiento o recuperación de información, sin permiso por escrito. desde el

solo para identificación y explicación sin intención de infringir.

Cuarta edición publicada por Routledge 2012 Tercera

edición publicada por Elsevier Inc. 2008

Catalogación de la Biblioteca Británica en datos de publicación

Un registro de catálogo para este libro está disponible en la Biblioteca Británica.

Catalogación de la Biblioteca del Congreso en datos de publicación

Se ha solicitado un registro de catálogo para este libro.

ISBN: 978-1-138-93735-2 (hbk)

ISBN: 978-1-138-93734-5 (pbk)

ISBN: 978-1-315-67631-9 (ebk)

Compuesto en Joanna por Servis Filmsetting Ltd, Stockport, Cheshire

Visite el sitio web complementario: www.routledge.com/cw/nicholas

A Sharry, Julia, Joshua y Abigail

PARTE I: FILOSOFÍA Y CONCEPTOS

1 ¿Qué es la gestión de proyectos?

PARTE II: CICLO DE VIDA DEL PROYECTO

3 Ciclo de vida del proyecto y concepción del proyecto

PARTE III: SISTEMAS Y PROCEDIMIENTOS DE PLANIFICACIÓN Y CONTROL

5 técnicas básicas de planificación de proyectos

9 Gestión de la calidad del proyecto

PARTE IV: COMPORTAMIENTO DE LA ORGANIZACIÓN

14 Estructura e integración de la organización del proyecto

PARTE V: GESTIÓN DE PROYECTOS EN EL CONTEXTO CORPORATIVO

17 Meta-Gestión de Proyectos y Gestión de Programas

18 Selección de Proyectos y Gestión de Cartera

Apéndice A: RFP para Midwest Parcel Distribution Company

PARTE I: FILOSOFÍA Y CONCEPTOS

1 ¿Qué es la gestión de proyectos?

1.1 Funciones de la Gerencia 1.2

2.1 Sistemas y pensamiento sistémico

PARTE II: CICLO DE VIDA DEL PROYECTO

3 Ciclo de vida del proyecto y concepción del proyecto

3.1 Ciclo de vida del

4 Definición del Proyecto y Definición del Sistema

4.1 Fase B: Definición

4.2 Definición del Proyecto

4.3 Planificación del proyecto por fases (onda rodante)

Associates: Requisitos Snafu Caso 4.2

Caso 4.4 Mina de oro propuesta en Canadá: Planificación de proyecto

PARTE III: SISTEMAS Y PROCEDIMIENTOS PARA LA PLANIFICACIÓN Y

5 técnicas básicas de planificación de proyectos

5.5 Organización y responsabilidades del proyecto 5.6

Caso 5.2 Startrek Enterprises, Inc.: Plan de proyecto de Deva

6 Planificación del cronograma del proyecto y redes