Pmbook Adm Proy.

pmbok-spain_cover-r1
12/17/02
2:31 PM
Page 1
PMBOK Guide
Edicin 2000
Una Gua a los
Fundamentos
de la Direccin
de Proyectos
PROJECT MANAGEMENT INSTITUTE

Gua Oficial a los Fundamentos de la Direccin de Proyectos
Una Gua a los
Fundamentos
de la Direccin de
Proyectos
(PMBOK Guide)
un Estndar Nacional Americano

ANSI/PMI 99-001 2000
Una Gua a los
Fundamentos
de la Direccin de
Proyectos
(PMBOK Guide)
EDICIN 2000
Project Management Institute

Newtown Square, Pennsylvania, EUA
ISBN: 1-930699-63-8
ISBN: 1-930699-18-2 (Espaol oficial, tapa blanda)
ISBN: 1-880410-23-0 (Ingls, tapa blanda)
ISBN: 1-880410-22-2 (Ingls, tapa dura)
ISBN: 1-880410-25-7 (Ingls, CD-ROM)
Publicado por: Project Management Institute, Inc.

Four Campus Boulevard
Newtown Square, Pennsylvania 19073-3299, EUA
Telfono: 610-356-4600 o visite nuestro sitio Web : www.pmi.org
Correo Electrnico: pmihq@pmi.org
2002 Project Management Institute, Inc. Todos los derechos reservados.
El departamento de publicaciones de PMI acepta con beneplcito correcciones y comentarios a este docmento.
Adems de comentarios acerca del contenido de Una Gua a los Fundamentos de la Direccin de Proyectos
(PMBOK Guide), apreciaremos nos enve informacin sobre errores tipogrficos, de formato u otros. Simplemente fotocopie la pgina correspondiente de la Gua PMBOK, marque el error y envelo a: PMI Publications,
Four Campus Boulevard, Newtown Square, PA 19073-3299 EUA, telfono: 610-356-4600, fax: 610-356-4647,
correo electrnico: booked@pmi.org.
PMI y el logotipo de PMI son servicios y marcas registradas en los Estados Unidos de Norteamrica y en otras
naciones; PMP y el logotipo de PMP son marcas registradas de certificacin en los Estados Unidos de
Norteamrica y en otras naciones; PMBOK, PM Network y PMI Today son marcas registradas en los
Estados Unidos de Norteamrica y en otras naciones; Project Management Journal y Building professionalism
in project management son marcas registradas del Project Management Institute, Inc.
Los libros editados por PMI tienen descuentos especiales por cantidad para ser usados como premios y promociones de ventas, o en programas corporativos de entrenamiento o en otros programas de capacitacin. Para
mayor informacin escriba por favor a PMI Publications, Four Campus Boulevard, Newtown Square, PA 190733299 USA. o contacte a su librera habitual.
Impreso en los Estados Unidos de Norteamrica. Ninguna parte de este trabajo puede ser reproducido o transmitido en forma alguna o por algn medio, ya sea electrnico, manual, fotocopiado, grabado o por algn sistema
de almacenamiento y recuperacin de informacin sin permiso previo del editor.
El papel usado en este libro cumple con el Estndar de Papel Permanente emitido por la National Information
Standards Organization (Z39.481984). Impreso y encuadernado por Automated Graphic Systems, White
Plains, Maryland, USA.
Traduccin realizada por el Captulo del PMI de Buenos Aires, Argentina
Equipo de Traduccin:
Claudio Arfeli, MetaControl S.A.
Jorge Barbeito, PMP, Consultor
Adrin Ferrero, PMP, Consultor
Jorge Gadze, PMP, IEEC
Hctor Garca, Consultor
Orlando Marone, PMP, NCR
Laura Pedretti, Avaya
Diana Russo, PMP, Consultor
Claudio Schicht, PMP, Consultor
Osvaldo Ucha, MetaControl S.A.
Ricardo Wehbe, PMP, UADE Proyectos
Director del Proyecto de Traduccin:
Alberto Lpez, PMP, IDP Proyectos
Los servicios de edicin y diseo fueron realizados por Lexicomm International Ltd., Jenkintown, Pennsylvania,
EUA.
El diseo de la tapa fue realizado por Melinda Possinger.
Impreso y encuadernado por Automated Graphic Systems, White Plains, Maryland, EUA.
10 9 8 7 6 5 4 3 2 1
Contenido
ndice de Figuras ---------------------------------------------------------------Prlogo de la Edicin 2000 ---------------------------------------------------
vii
ix
SECCIN IMARCO CONCEPTUAL DE LA

DIRECCIN DE PROYECTOS ----------------------------------------------Captulo 1Introduccin ------------------------------------------------------
1
3
1.1
1.2
1.3
1.4
1.5
Propsito de esta Gua -----------------------------------------------------Qu es un Proyecto? -----------------------------------------------------Qu es la Direccin de Proyectos? -------------------------------------Relacin con otras Disciplinas de Direccin -----------------------------Emprendimientos Relacionados -------------------------------------------
3
4
6
9
10
Captulo 2El Contexto de la Direccin de Proyectos -------------2.1 Fases del Proyecto y Ciclo de Vida del Proyecto -----------------------2.2 Interesados en el Proyecto-------------------------------------------------2.3 Influencias de la Organizacin --------------------------------------------2.4 Habilidades Clave de Direccin en General -----------------------------2.5 Influencias Sociales, Econmicas y Ambientales -----------------------Captulo 3Procesos de la Direccin de Proyectos ----------------3.1 Procesos del Proyecto -----------------------------------------------------3.2 Grupos de Procesos -------------------------------------------------------3.3 Interacciones entre Procesos ---------------------------------------------3.4 Adaptacin de las Interacciones entre Procesos -----------------------3.5 Organizacin de los Procesos de Direccin del Proyecto --------------
11
11
16
18
21
26
29
29
30
32
37
38
SECCIN IIREAS DE CONOCIMIENTO DE LA

DIRECCIN DE PROYECTOS ----------------------------------------------Captulo 4Gestin de la Integracin del Proyecto -----------------
39
41
4.1 Desarrollo del Plan del Proyecto ------------------------------------------4.2 Ejecucin del Plan del Proyecto ------------------------------------------4.3 Control Integrado de Cambios ---------------------------------------------
42
46
47
Captulo 5Gestin del Alcance del Proyecto ------------------------5.1 Iniciacin --------------------------------------------------------------------5.2 Planificacin del Alcance --------------------------------------------------5.3 Definicin del Alcance -----------------------------------------------------5.4 Verificacin del Alcance ----------------------------------------------------5.5 Control de Cambios del Alcance -----------------------------------------Captulo 6Gestin de Tiempos del Proyecto ------------------------6.1 Definicin de Actividades --------------------------------------------------6.2 Secuenciamiento de Actividades -----------------------------------------6.3 Estimacin de la Duracin de las Actividades ---------------------------6.4 Desarrollo del Cronograma ------------------------------------------------6.5 Control del Cronograma ---------------------------------------------------Captulo 7Gestin de Costos del Proyecto --------------------------7.1 Planificacin de Recursos -------------------------------------------------7.2 Estimacin de Costos -----------------------------------------------------7.3 Asignacin del Presupuesto de Costos ----------------------------------7.4 Control de Costos -----------------------------------------------------------
51
53
55
57
61
62
65
65
68
71
73
79
83
85
86
89
90
Una Gua a los Fundamentos de la Direccin de Proyectos (PMBOK Guide) Edicin 2000
2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 EUA
Captulo 8Gestin de la Calidad del Proyecto ----------------------8.1 Planificacin de la Calidad -------------------------------------------------8.2 Aseguramiento de la Calidad ---------------------------------------------8.3 Control de Calidad ---------------------------------------------------------Captulo 9Gestin de los Recursos Humanos del Proyecto ----9.1 Planificacin de la Organizacin ------------------------------------------9.2 Adquisicin de Personal ---------------------------------------------------9.3 Desarrollo del Equipo ------------------------------------------------------Captulo 10Gestin de las Comunicaciones del Proyecto ------10.1 Planificacin de las Comunicaciones -------------------------------------10.2 Distribucin de la Informacin ---------------------------------------------10.3 Informes de Rendimiento --------------------------------------------------10.4 Cierre Administrativo -------------------------------------------------------Captulo 11Gestin de Riesgos del Proyecto -----------------------11.1 Planificacin de la Gestin de Riesgos -----------------------------------11.2 Identificacin de Riesgos --------------------------------------------------11.3 Anlisis Cualitativo de Riesgos --------------------------------------------11.4 Anlisis Cuantitativo de Riesgos ------------------------------------------11.5 Planificacin de la Respuesta a Riesgos ---------------------------------11.6 Supervisin y Control de Riesgos ----------------------------------------Captulo12Gestin de las Adquisiciones del Proyecto ----------12.1 Planificacin de Adquisiciones --------------------------------------------12.2 Planificacin de la Bsqueda de Proveedores --------------------------12.3 Bsqueda de Proveedores ------------------------------------------------12.4 Seleccin de Proveedores -------------------------------------------------12.5 Administracin del Contrato -----------------------------------------------12.6 Cierre del Contrato ----------------------------------------------------------
95
97
101
102
107
108
112
114
117
119
121
122
125
127
129
131
133
137
140
144
147
149
152
153
155
156
158
SECCIN IIIAPNDICES -------------------------------------------------------Apndice AProceso de Establecimiento de Estndares del

Project Management Institute ---------------------------Apndice BEvolucin de la Gua a los Fundamentos de la
Direccin de Proyectos ------------------------------------Apndice CColaboradores y Revisores de la
Edicin 2000 de la Gua PMBOK ----------------------Apndice DNotas -------------------------------------------------------------Apndice EExtensiones al rea de Aplicacin ---------------------Apndice FFuentes Adicionales de Informacin
sobre la Direccin de Proyectos ------------------------Apndice GResumen de las reas de Conocimiento de la
Direccin de Proyectos -------------------------------------
161
163
167
175
179
181
185
189
SECCIN IVGLOSARIO E NDICE ------------------------------------------- 193

Glosario ----------------------------------------------------------------------------- 195
ndice -------------------------------------------------------------------------------- 215
vi
ndice de Figuras
Figura 1-1.
Figura 1-2.
Figura 2-1.
Figura 2-2.
Figura 2-3.
Figura 2-4.
Figura 2-5.
Figura 2-6.
Figura 2-7.
Figura 2-8.
Figura 2-9.
Figura 2-10.
Figura 2-11.
Figura 2-12.
Figura 3-1.
Figura 3-2.
Figura 3-3.
Figura 3-4.
Figura 3-5.
Figura 3-6.
Figura 3-7.
Figura 3-8.
Figura 3-9.
Figura 4-1.
Figura 4-2.
Figura 5-1.
Figura 5-2.
Figura 5-3.
Figura 5-4.
Figura 6-1.
Figura 6-2.
Figura 6-3.
Figura 6-4.
Figura 6-5.
Figura 6-6.
Figura 6-7.
Figura 7-1.
Figura 7-2.
Figura 8-1.
Figura 8-2.
Visin General de las reas de Conocimiento y de

los Procesos de la Direccin de Proyectos----------------------------------------------------------Relacin de la Direccin de Proyectos con otras Disciplinas de Direccin-----------------------Ejemplo de un Ciclo de Vida Genrico ---------------------------------------------------------------Ciclo de Vida Representativo de Adquisiciones de Defensa,
segn US DODI 5000.2 (Borrador de Coordinacin Final, Abril 2000)----------------------------Ciclo de Vida Representativo de un Proyecto de Construccin, segn Morris ------------------Ciclo de Vida Representativo de un Proyecto Farmacutico, segn Murphy -------------------Ciclo de Vida Representativo del Desarrollo de Software, segn Muench -----------------------Influencia de la Estructura de la Organizacin en los Proyectos ----------------------------------Organizacin Funcional --------------------------------------------------------------------------------Organizacin Proyectizada ---------------------------------------------------------------------------Organizacin Matricial Dbil --------------------------------------------------------------------------Organizacin Matricial Balanceada -------------------------------------------------------------------Organizacin Matricial Fuerte -------------------------------------------------------------------------Organizacin Combinada -----------------------------------------------------------------------------Vnculos entre los Grupos de Procesos en una Fase-----------------------------------------------Superposicin de los Grupos de Procesos en una Fase-------------------------------------------Interaccin entre Fases --------------------------------------------------------------------------------Relaciones entre los Procesos de Iniciacin---------------------------------------------------------Relaciones entre los Procesos de Planificacin -----------------------------------------------------Relaciones entre los Procesos de Ejecucin --------------------------------------------------------Relaciones entre los Procesos de Control -----------------------------------------------------------Relaciones entre los Procesos de Cierre ------------------------------------------------------------Clasificacin de los Procesos de la Direccin de Proyectos segn los Grupos de
Procesos y las reas de Conocimiento -------------------------------------------------------------Visin General de la Gestin de la Integracin del Proyecto --------------------------------------Coordinacin de Cambios a Travs de Todo el Proyecto -----------------------------------------Visin General de la Gestin del Alcance del Proyecto---------------------------------------------Ejemplo de Estructura Detallada de Trabajo para Artculos de Materiales de Defensa ---------Ejemplo de Estructura Detallada de Trabajo (WBS) Organizada por Fases ----------------------Ejemplo de Estructura Detallada de Trabajo (WBS) para una
Planta de Tratamiento de Aguas Residuales -------------------------------------------------------Visin General de la Gestin de Tiempos del Proyecto --------------------------------------------Diagrama de Red Lgica Dibujado Usando el Mtodo de
Diagramacin por Precedencia ----------------------------------------------------------------------Diagrama de Red Lgica Dibujado Usando el Mtodo de
Diagramacin con Flechas ----------------------------------------------------------------------------Clculo de Duracin PERT para una Sola Actividad------------------------------------------------Diagrama de Red del Proyecto con Fechas ---------------------------------------------------------Grfico de Barras (Gantt) ------------------------------------------------------------------------------Grfico de Hitos ----------------------------------------------------------------------------------------Visin General de la Gestin de Costos del Proyecto ----------------------------------------------Grfico Ilustrativo de un Plan de Referencia de Costos --------------------------------------------Visin General de la Gestin de la Calidad del Proyecto -------------------------------------------Diagrama de Causa-Efecto ----------------------------------------------------------------------------
8
9
13
14
15
16
17
19
20
21
22
22
23
23
31
31
31
32
33
35
36
37
38
42
48
52
58
59
60
66
69
70
76
77
78
79
84
90
96
99
vii
Figura 8-3.
Figura 8-4.
Figura 8-5.
Figura 9-1.
Figura 9-2.
Figura 9-3.
Figura 10-1.
Figura 10-2.
Figura 10-3.
Figura 11-1.
Figura 11-2.
Figura 11-3.
Figura 11-4.
Figura 11-5.
Figura 11-6.
Figura 11-7.
Figura 12-1.
viii
Ejemplo de Diagrama de Flujo de un Proceso ------------------------------------------------------Grfico de Control del Rendimiento del Cronograma del Proyecto -----------------------------Diagrama de Pareto -----------------------------------------------------------------------------------Visin General de la Gestin de los Recursos Humanos del Proyecto --------------------------Matriz de Asignacin de Responsabilidades --------------------------------------------------------Histograma Ilustrativo de Recursos ------------------------------------------------------------------Visin General de la Gestin de las Comunicaciones del Proyecto -------------------------------Informe Grfico Ilustrativo de Rendimiento ----------------------------------------------------------Informe Tabular Ilustrativo de Rendimiento ---------------------------------------------------------Visin General de la Gestin de Riesgos del Proyecto ---------------------------------------------Clasificacin de Impactos de un Riesgo -------------------------------------------------------------Matriz de ProbabilidadImpacto ----------------------------------------------------------------------Estimacin de Costos y Rangos de la Entrevista del Riesgo -------------------------------------Ejemplos de Distribuciones de Probabilidad Comnmente Usadas -----------------------------Anlisis del rbol de Decisiones ---------------------------------------------------------------------Simulacin del Riesgo de Costo ---------------------------------------------------------------------Visin General de la Gestin de las Adquisiciones del Proyecto -----------------------------------
100
104
105
108
111
112
118
124
124
128
136
137
139
140
141
142
148
Prlogo de la Edicin 2000

Este documento reemplaza a Una gua a los Fundamentos de la Direccin de
Proyectos del Project Management Institute (PMI) (PMBOK Guide), publicada en
1996.
El alcance del proyecto de actualizar la publicacin del 1996 fue:
Agregar nuevo material reflejando el crecimiento de los conocimientos y prcticas
en el campo de la Direccin de Proyectos, capturando esas habilidades, herramientas, tcnicas y otros importantes elementos que hayan sido ampliamente aceptados. (Conceptos generalmente aceptados o sea son aplicados en gran cantidad de
proyectos gran parte del tiempo y hay consenso respecto de su valor y utilidad)
Hacer ms claros ciertos textos e ilustraciones para que este documento sea ms
beneficioso para los lectores.
Corregir errores existentes en el documento anterior.
Para colaborar con los lectores de este documento quines estn familiarizados con
el documento anterior, nosotros hemos sumariado las principales diferencias:
1. A travs del documento, nosotros clarificamos que los proyectos estn regidos por
los requerimientos, los cuales resultan de las necesidades, deseos y expectativas.
2. Estrechamos la relacin con la estrategia de la organizacin a lo largo del documento.
3. Proporcionamos ms nfasis en la elaboracin de la Seccin 1.2.3.
4. Registramos el rol de la Oficina de Proyectos en la Seccin 2.3.4.
5. Agregamos referencias a la Direccin de Proyectos participando en el desarrollo
de las economas como as tambin los impactos sociales, econmicos y ambientales en
Seccin 2.5.4.
6. Agregamos un tratamiento ms extendido de la Gestin del Valor del Trabajo
Realizado en el Captulo 4 (Gestin de la Integracin del Proyecto), Captulo 7 (Gestin
de Costos del Proyecto), y Captulo 10 (Gestin de las Comunicaciones del Proyecto).
7. Rescribimos el Captulo 11 (Gestin de Riesgos del Proyecto). El captulo ahora
contiene seis procesos en vez de los cuatro procesos que tena la versin anterior. Los seis
procesos son Planificacin de la Gestin de Riesgos, Identificacin de Riesgos, Anlisis
Cualitativo de Riesgos, Anlisis Cuantitativo de Riesgos Plan de Respuesta al Riesgo y
Supervisin y Control de Riesgos.
8. Movimos la Verificacin del Alcance de los procesos de ejecucin a los procesos de
control.
9. Cambiamos el nombre del Proceso 4.3 de Control de Cambios Global por Control
de Cambios Integrado para poner nfasis en la importancia del Control de Cambio a
travs de todo el proyecto.
10. Agregamos un grfico que relaciona los treinta y nueve procesos de la Direccin
de Proyectos y los cinco Grupos de Procesos con las nueve reas de Conocimiento en la
Figura 3-9.
11. Estandarizamos la terminologa a travs del documento de proveedor a
vendedor.
12. Agregamos varias Tcnicas y Herramientas:
ix
Captulo 4 (Gestin de la Integracin del Proyecto)

Gestin del Valor del Trabajo Realizado (EVM)
Accin Preventiva
Captulo 5 (Gestin del Alcance del Proyecto)
Actualizaciones de la Descripcin del Alcance
Plan del Proyecto
Plan de Referencia Ajustado
Captulo 6 (Gestin de Tiempos del Proyecto)
Tres Medidas Posibles de la Duracin
Reserva de Contingencia
Estructura Codificada
Anlisis de la Variacin
Hitos
Atributos de las Actividades
Herramientas de Computacin
Captulo 7 (Gestin de Costos del Proyecto)
Informacin Detallada sobre las Estimaciones
Mtricas del Valor del Trabajo Realizado
Captulo 8 (Gestin de la Calidad del Proyecto)
Costo de la Calidad
Captulo 10 (Gestin de las Comunicaciones del Proyecto)
Informes del Proyecto
Presentaciones del Proyecto
Cierre Administrativo del Proyecto
Captulo 11 (Gestin de Riesgos del Proyecto este captulo fue reescrito)
Los Fundamentos de la Profesin de Direccin de Proyectos contina creciendo y el PMI
intenta actualizar la PMBOK Guide peridicamente. Por lo tanto, si usted tiene cualquier
comentario acerca de este documento o sugerencias acerca de cmo este documento puede
ser mejorado, por favor envelos a:
PMI Project Management Standards Program
Newtown Square, PA 19073-3299 EUA
Telfono: +610-356-4600
Fax: +610-356-4647
Correo electrnico: pmihq@pmi.org
Internet: http://www.pmi.org
SECCIN I
MARCO CONCEPTUAL DE LA DIRECCIN DE PROYECTOS
1. Introduccin
2. El Contexto de la Direccin de Proyectos
3. Procesos de la Direccin de Proyectos
Captulo 1
Introduccin
Fundamentos de Direccin de Proyectos (PMBOK) (Project Management Body of Knowledge,
PMBOK) es un trmino genrico que describe la totalidad de los conocimientos de la profesin de direccin de proyectos. Al igual que en otras profesiones, como abogaca, medicina
o ciencias econmicas, los conocimientos residen en los practicantes y acadmicos que lo
aplican y lo desarrollan. El conjunto completo de conocimientos de direccin de proyectos
incluye conocimientos de prcticas tradicionales ampliamente aplicadas, as como conocimientos de prcticas innovadoras y avanzadas de uso ms limitado e incluye tanto material
publicado como no publicado.
Este captulo define y explica muchos trminos clave y provee una visin del resto de este
documento. Incluye las siguientes secciones principales:
1.1 Propsito de esta Gua
1.2 Qu es un Proyecto?
1.3 Qu es la Direccin de Proyectos?
1.4 Relacin con otras Disciplinas de Direccin
1.5 Emprendimientos Relacionados
1.1 PROPSITO DE ESTA GUA

La direccin de proyectos es una profesin emergente. El propsito principal de este documento es identificar y describir el subconjunto del PMBOK que es generalmente aceptado.
Generalmente aceptado significa que los conocimientos y las prcticas descritas son aplicables
a la mayora de los proyectos y que existe un amplio consenso sobre su valor y utilidad.
Generalmente aceptado no significa que los conocimientos y las prcticas descritas sean o
deberan ser aplicadas uniformemente en todos los proyectos. El equipo de direccin del
proyecto es siempre responsable de determinar qu resulta apropiado para cada proyecto.
Este documento tambin intenta proporcionar una terminologa comn dentro de la profesin y la prctica para hablar y escribir sobre direccin de proyectos. La direccin de
proyectos es una profesin relativamente joven, y an cuando existe un entendimiento comn
respecto de lo que se hace, hay una relativa discrepancia en la terminologa utilizada.
Este documento proporciona una referencia bsica para cualquiera que se interese en la
profesin de la direccin de proyectos. Esto incluye, pero no se limita a:
1.2 | 1.2.3
Captulo 1 Introduccin
Altos ejecutivos
Gerentes de directores de proyecto
Directores de proyecto y otros miembros del equipo de proyecto
Clientes de proyectos y otros interesados en los proyectos (stakeholders)
Gerentes funcionales con empleados asignados a equipos de proyecto
Educadores de direccin de proyectos y materias relacionadas
Consultores y otros especialistas en direccin de proyectos y reas afines
Capacitadores que desarrollan programas de educacin de direccin de proyectos
Como referencia bsica, este documento no es un compendio total de todo los conocimientos. El apndice E explica la necesidad de contar con extensiones por rea de aplicacin,
mientras que el apndice F lista fuentes de mayor informacin sobre direccin de proyectos.
Este documento es tambin utilizado por el Project Management Institute como una
referencia bsica sobre los conocimientos y las prcticas de direccin de proyectos para sus
programas de desarrollo profesional, incluyendo:
Certificacin como Profesional de Direccin de Proyectos (Project Management Professional, PMP).
Acreditacin de programas educativos en direccin de proyectos.
1.2 QU ES UN PROYECTO?
Las organizaciones ejecutan trabajos. El trabajo generalmente involucra tanto operaciones como
proyectos, an cuando ambos pueden superponerse. Las operaciones y los proyectos comparten muchas caractersticas; por ejemplo, son:
Realizados por personas.
Restringidos por recursos limitados.
Planificados, ejecutados y controlados.
Los proyectos son frecuentemente implementados como un medio para ejecutar un plan
estratgico. Operaciones y proyectos difieren primordialmente en que las operaciones son continuas y repetitivas, mientras que los proyectos son temporarios y nicos. Un proyecto puede
entonces ser definido de acuerdo con sus caractersticas distintivas un proyecto es un
emprendimiento temporario realizado para crear un producto o servicio nico. Temporario significa que cada proyecto tiene un comienzo definido y un final definido. nico significa que
el producto o servicio es diferente de alguna manera que lo distingue de otros productos o servicios. Para muchas organizaciones, los proyectos son instrumentos para responder a requerimientos que no pueden ser atendidos dentro de los lmites operacionales normales de la
organizacin.
Los proyectos son emprendidos en todos los niveles de las organizaciones. Ellos pueden
involucrar a una sola persona o a muchos miles. Su duracin vara desde unas pocas semanas
hasta ms de cinco aos. Los proyectos pueden involucrar una sola unidad de la organizacin
o pueden cruzar sus fronteras, como en las asociaciones y convenios para un proyecto determinado. Los proyectos son crticos para la ejecucin de las estrategias de negocio de las organizaciones ejecutantes, porque los proyectos son instrumentos por medio de los cuales se
implementan las estrategias. Ejemplo de proyectos incluyen:
Desarrollar un nuevo producto o servicio.
Efectuar un cambio en la estructura, en la dotacin del personal o en estilo de una organizacin.
Disear un nuevo vehculo de transporte.
Desarrollar o adquirir un sistema de informacin nuevo o modificado.
Construir un edificio o una planta.
Construir un sistema de suministro de agua para una comunidad en un pas en desarrollo.
Ejecutar una campaa para un partido poltico.
Implementar un nuevo procedimiento o proceso de negocio.
1.2.1
Temporario
Temporario significa que cada proyecto tiene un comienzo definido y un final definido. El final
se alcanza cuando se han logrado los objetivos del proyecto o cuando queda claro que los
objetivos del proyecto no sern o no podrn ser alcanzados, o cuando la necesidad del
proyecto ya no existe y el proyecto es cancelado. Temporario no necesariamente significa de
corta duracin; muchos proyectos duran varios aos. En cada caso, sin embargo, la duracin
del proyecto es finita; los proyectos no son esfuerzos continuos. Adicionalmente, temporario
no se aplica generalmente a los productos o servicios creados por el proyecto. Los proyectos
pueden tener frecuentemente impactos sociales, econmicos y ambientales, intencionales o no,
que perduran mucho ms que los propios proyectos. La mayora de los proyectos son emprendidos para crear un resultado duradero. Por ejemplo, un proyecto para levantar un monumento
nacional crear un resultado que se espera perdure por siglos. Una serie de proyectos y/o
proyectos complementarios en paralelo pueden ser requeridos para alcanzar un objetivo
estratgico.
Los objetivos de proyectos y operaciones son fundamentalmente diferentes. El objetivo de
un proyecto es obtener su resultado y cerrar el proyecto. El objetivo de una operacin continua, no-proyectizada, es normalmente dar respaldo al negocio. Los proyectos son fundamentalmente diferentes, porque ellos cesan cuando su objetivo declarado ha sido alcanzado,
mientras que los emprendimientos que no son proyectos adoptan un nuevo grupo de objetivos
y continan trabajando.
La naturaleza temporaria de los proyectos puede aplicarse a otros aspectos de los
emprendimientos:
La oportunidad o ventana de negocio es usualmente temporaria la mayora de los
proyectos tiene un perodo limitado para producir sus productos o servicios.
El equipo del proyecto, como equipo, rara vez subsiste despus del proyecto la mayora
de los proyectos son ejecutados por un equipo creado con el nico propsito de ejecutar
el proyecto, que es disuelto cuando se completa el proyecto.
1.2.2
Producto, Servicio o Resultado nico

Los proyectos involucran hacer algo que no ha sido hecho antes y que es, entonces, nico. Un
producto o servicio puede ser nico an cuando la categora a la que pertenece sea amplia.
Por ejemplo, muchos miles de edificios de oficinas han sido construidos, pero cada edificio
individual es nicodifiere en propietario, diseo, ubicacin, contratista, etc. La presencia de
elementos repetitivos tampoco cambia la condicin fundamental de nico que tiene el trabajo
del proyecto. Por ejemplo:
Un proyecto para desarrollar un nuevo avin comercial de lnea puede requerir mltiples
prototipos.
Un proyecto para poner una nueva droga en el mercado puede requerir miles de dosis de
la droga para permitir ensayos clnicos.
Un proyecto de desarrollo inmobiliario puede incluir cientos de unidades individuales.
Un proyecto de desarrollo (por ejemplo, de agua potable y alcantarillado) puede ser implementado en cinco reas geogrficas.
1.2.3
Elaboracin Progresiva
La elaboracin progresiva es una caracterstica de los proyectos que integra los conceptos de
temporario y nico. Debido a que el resultado de cada proyecto es nico, las caractersticas
que distinguen al producto o servicio deben ser elaboradas progresivamente. Progresivamente
significa procediendo paso a paso, progresando continuamente a travs de incrementos
1.3 | 1.3.2
mientras que elaborado significa llevado a cabo cuidadosa y detalladamente, desarrollado por
completo (1). Estas caractersticas distintivas van a ser definidas genricamente al comienzo
del proyecto, y se volvern ms explcitas y detalladas a medida que el equipo del proyecto
desarrolle un mejor y ms completo entendimiento del producto.
La elaboracin progresiva de las caractersticas del producto debe ser cuidadosamente coordinada con la apropiada definicin del alcance del proyecto, particularmente si el proyecto
es ejecutado bajo contrato. Cuando es apropiadamente definido, el alcance del proyecto
el trabajo por ser realizado debera permanecer constante an cuando las caractersticas del
producto sean elaboradas progresivamente. La relacin entre el alcance del producto y el
alcance del proyecto se trata ms adelante, en la introduccin al captulo 5.
Los siguientes ejemplos ilustran la elaboracin progresiva en dos diferentes reas de aplicacin.
Ejemplo 1. El desarrollo de una planta de procesamiento qumico comienza con la ingeniera de proceso que define las caractersticas del proceso. Esas caractersticas son utilizadas
para disear las principales unidades de procesamiento. Esa informacin se convierte en la
base para el diseo de ingeniera, que define tanto el plano detallado de la planta como las
caractersticas mecnicas de las unidades de proceso y las instalaciones auxiliares. Todo esto
tiene como resultado diseos que son elaborados para producir planos de fabricacin
(isomtricos de construccin). Durante la construccin, se interpreta y adapta tanto como se
necesite y se somete a la aprobacin respectiva. Esta subsecuente elaboracin de las caractersticas es capturada por planos de acuerdo a lo realizado. Durante las pruebas y la puesta
en marcha, la elaboracin adicional de caractersticas, se realiza frecuentemente en la forma de
ajustes operativos finales.
Ejemplo 2. El resultado de un proyecto de desarrollo econmico puede ser definido inicialmente como: Mejorar la calidad de vida de los residentes de menores ingresos de la comunidad X. A medida que el proyecto progresa, los resultados podran ser descritos ms
especficamente como, por ejemplo: Proporcionar acceso a alimentacin y agua a 500 residentes de bajos ingresos en la comunidad X. La prxima etapa de elaboracin progresiva
podra enfocarse exclusivamente en mejorar la produccin y mercadeo agrcola, considerando
la provisin de agua como segunda prioridad, que ser iniciada una vez que los temas vinculados a la agricultura hayan sido resueltos.
1.3 QU ES LA DIRECCIN DE PROYECTOS?

La direccin de proyectos es la aplicacin de conocimientos, habilidades, herramientas y tcnicas a las actividades del proyecto para satisfacer los requerimientos del proyecto. La direccin de proyectos se realiza a travs del uso de procesos como: inicio, planificacin, ejecucin,
control y cierre. El equipo del proyecto maneja el trabajo del proyecto y ese trabajo tpicamente involucra:
Demandas contrapuestas sobre: alcance, tiempo, costo, riesgos y calidad.
Interesados con diferentes necesidades y expectativas.
Requerimientos identificados.
Es importante notar que muchos de los procesos de la direccin de proyectos son iterativos
por naturaleza. Esto es debido, en parte, a la existencia y necesidad de elaboracin progresiva
dentro del proyecto, a travs del ciclo de vida del mismo. Es decir, cuanto ms se sabe de un
proyecto, mejor preparado se est para manejarlo.
El trmino direccin de proyectos es a veces utilizado para describir un enfoque organizativo para el manejo de las operaciones continuas. Ese enfoque, ms propiamente identificado como direccin por proyectos, trata como proyectos a muchos de los aspectos de las
operaciones continuas para aplicar en ellos las tcnicas de la direccin de proyectos. An
cuando el entendimiento de la direccin de proyectos es crtico para una organizacin que utiliza la direccin por proyectos, el tratamiento detallado de este enfoque est fuera del alcance
de este documento.
Los conocimientos sobre direccin de proyectos pueden ser utilizados de muchas maneras.
Este documento contiene dos secciones principales y doce captulos, como se describe a continuacin.
1.3.1
Marco Conceptual de la Direccin de Proyectos

La seccin I, Marco Conceptual de la Direccin de Proyectos, proporciona una estructura
bsica para entender la direccin de proyectos.
El captulo 1, Introduccin, define la terminologa clave y proporciona un resumen del
resto del documento.
El captulo 2, El Contexto de la Direccin de Proyectos, describe el entorno dentro del
cual operan los proyectos. El equipo de direccin del proyecto debe entender este contexto
amplioel manejo de las actividades del da a da del proyecto es necesario para el xito, pero
no suficiente.
El captulo 3, Procesos de la Direccin de Proyectos, describe una visin general
respecto de la forma en que diversos procesos de la direccin de proyectos normalmente
interactan entre s. Es esencial entender estas interacciones para poder entender el material
que se presenta en los captulos 4 a 12.
1.3.2
reas de Conocimiento de la Direccin de Proyectos

La seccin II, reas de Conocimiento de la Direccin de Proyectos, describe los
conocimientos y las prcticas de la direccin de proyectos en trminos de los procesos que
la componen. Estos procesos han sido organizados dentro de nueve reas de conocimiento,
como se describe seguidamente y se ilustra en la figura 1-1.
El captulo 4, Gestin de la Integracin del Proyecto, describe los procesos requeridos
para asegurar que los diversos elementos del proyecto sean coordinados apropiadamente. Consiste en el desarrollo del plan del proyecto, la ejecucin del plan del proyecto y el control de
cambios integrado.
El captulo 5, Gestin del Alcance del Proyecto, describe los procesos requeridos para
asegurar que el proyecto incluya todo el trabajo requerido, y slo el trabajo requerido, para
completar el proyecto exitosamente. Consiste en iniciacin, planificacin del alcance, definicin del alcance, verificacin del alcance y control de cambios de alcance.
El captulo 6, Gestin de Tiempos del Proyecto, describe los procesos requeridos para
asegurar que el proyecto se complete a tiempo. Consiste en definicin de las actividades,
secuenciamiento de las actividades, clculo de la duracin de las actividades, desarrollo del
cronograma y control del cronograma.
El captulo 7, Gestin de Costos del Proyecto, describe los procesos requeridos para asegurar que el proyecto se complete dentro del presupuesto aprobado. Consiste en la planificacin de los recursos, estimacin de costos, asignacin del presupuesto de costos y control
de los costos.
El captulo 8, Gestin de la Calidad del Proyecto, describe los procesos requeridos para
asegurar que el proyecto va a satisfacer las necesidades por las cuales ha sido emprendido.
Consiste en planificacin de la calidad, aseguramiento de la calidad y control de la calidad.
El captulo 9, Gestin de los Recursos Humanos del Proyecto, describe los procesos
requeridos para hacer el uso ms efectivo de las personas involucradas en el proyecto. Consiste en planificacin de la organizacin, adquisicin de personal y desarrollo del equipo.
El captulo 10, Gestin de las Comunicaciones del Proyecto, describe los procesos
requeridos para asegurar que la generacin, recoleccin, distribucin, almacenamiento y
Figura 11 | 1.4
Figura 11. Visin General de las reas de Conocimiento y de los Procesos de la Direccin de Proyectos
destino final de la informacin del proyecto se realice en tiempo y forma. Consiste en planificacin de las comunicaciones, distribucin de la informacin, informes de rendimiento y
cierre administrativo.
El captulo 11, Gestin de Riesgos del Proyecto, describe los procesos relativos a la identificacin, anlisis y respuesta a los riesgos del proyecto. Consiste en planificacin de la gestin
de riesgos, identificacin de riesgos, anlisis cualitativo de los riesgos, anlisis cuantitativo de
los riesgos, plan de respuesta a los riesgos y supervisin y control de riesgos.
El captulo 12, Gestin de las Adquisiciones del Proyecto, describe los procesos
requeridos para adquirir bienes y servicios desde fuera de la organizacin ejecutante. Consiste
en planificacin de adquisiciones, planificacin de la bsqueda de proveedores, bsqueda de
proveedores, seleccin de proveedores, administracin del contrato y cierre del contrato.
Figura 12. Relacin de la Direccin de Proyectos con Otras Disciplinas de Direccin
1.4 RELACIN CON OTRAS DISCIPLINAS DE DIRECCIN

Gran parte de los conocimientos necesarios para manejar proyectos es propio de la direccin
de proyectos (por ejemplo, el anlisis del camino crtico y la estructura detallada del trabajo
Work Breakdown Structure, WBS). Sin embargo, el PMBOK abarca otras disciplinas de gestin,
como se ilustra en la figura 1-2.
La gestin general comprende la planificacin, organizacin, seleccin de personal, ejecucin y control de operaciones de una empresa. La gestin general tambin incluye disciplinas
de respaldo vinculadas a asuntos legales, planificacin estratgica, logstica y gestin de
recursos humanos. El PMBOK cubre o modifica muchas reas de la gestin general conducta de la organizacin, pronstico financiero y tcnicas de planificacin, para nombrar
algunas. La seccin 2.4 proporciona una descripcin ms detallada sobre la gestin general.
Las reas de aplicacin son categoras de proyectos que tienen elementos significativos
comunes que no estn presentes ni son necesarios en todos los proyectos. Las reas de aplicacin son definidas usualmente en trminos de:
Departamentos funcionales y disciplinas de respaldo, como las legales, de produccin, de
manejo de inventario, de mercadeo, de logstica y de personal.
Elementos tcnicos, como desarrollo de software, productos farmacuticos, ingeniera de
abastecimiento de agua o alcantarillado o ingeniera de construccin.
Especializacin de gestin, como contratacin para el gobierno, desarrollo de comunidades
o desarrollo de nuevos productos.
Grupos de industria, como el automotor, qumico, agrcola o de servicios financieros.
El apndice E incluye una descripcin ms detallada sobre las reas de aplicacin de la
direccin de proyectos.
1.5 | 2.1.1
10
1.5 EMPRENDIMIENTOS RELACIONADOS

Ciertos tipos de emprendimientos estn ntimamente relacionados con los proyectos. Frecuentemente hay una jerarqua de plan estratgico, programa, proyecto y subproyecto, dentro
de la cual un programa que consiste en varios proyectos asociados contribuye a conseguir un
plan estratgico. Estos emprendimientos relacionados se describen a continuacin.
Programas. Un programa es un grupo de proyectos gestionados en forma coordinada para
obtener beneficios no disponibles en caso de gestionarlos individualmente (2). Muchos programas tambin incluyen elementos de operaciones continuas. Por ejemplo:
El programa del avin XYZ incluye tanto el proyecto o los proyectos de diseo y desarrollo del avin como el proceso continuo de fabricacin y mantenimiento de esos aviones.
Muchas empresas de electrnica tienen directores de programas que son responsables tanto
del lanzamiento de productos individuales (proyectos) como de la coordinacin de mltiples versiones a travs del tiempo (una operacin continua).
Los programas pueden tambin involucrar una serie de emprendimientos repetitivos o
cclicos, por ejemplo:
Las empresas de servicios pblicos frecuentemente hablan de programas anuales de
construccin, una operacin regular y continua que involucra muchos proyectos.
Muchas empresas sin fines de lucro tienen un programa de financiamiento, un esfuerzo
continuo para obtener respaldo financiero que frecuentemente involucra una serie de
proyectos separados, tales como promover un aumento en la masa de miembros o una
subasta.
Publicar un peridico o una revista tambin es un programa el peridico en s mismo
es un esfuerzo continuo, pero cada nmero en particular es un proyecto.
En algunas reas de aplicacin, la direccin de programas y la direccin de proyectos son
tratados como sinnimos, mientras que en otras la direccin de proyectos es un componente
de la direccin de programas. Esta diversidad de significados vuelve imperativo que cualquier
debate sobre direccin de programas en contraposicin a direccin de proyectos est precedido por un acuerdo sobre una clara y consistente definicin de cada trmino.
Subproyectos. Los proyectos son frecuentemente divididos en componentes ms manejables
o subproyectos. Los subproyectos son frecuentemente contratados a una empresa externa o a
otra unidad funcional de la organizacin ejecutante. Algunos ejemplos son:
Subproyectos basados en el proceso del proyecto, tales como una fase nica.
Subproyectos relativos al requerimiento de habilidades de los recursos humanos, como la
instalacin de plomera o electricidad en un proyecto de construccin.
Subproyectos que involucran tecnologa, como la comprobacin automtica de programas
de computacin en un proyecto de desarrollo de software.
Los subproyectos son tpicamente tratados y gestionados como proyectos.
Gestin del Portafolio de Proyectos. La gestin del portafolio de proyectos se refiere a la
seleccin y respaldo de proyectos o programas de inversin. Estas inversiones en proyectos
y programas son guiadas por el plan estratgico y los recursos disponibles de la organizacin.
Captulo 2
El Contexto de la Direccin
de Proyectos
Los proyectos y la direccin de proyectos operan en un entorno ms amplio que el atribuible
al propio proyecto. El equipo de direccin de proyectos debe entender esta amplitud de contexto gestionar las actividades del da a da del proyecto es necesario para alcanzar el xito,
pero no suficiente. Este captulo describe aspectos clave del contexto de la direccin de
proyectos que no se cubren en ninguna otra parte de este documento. Los temas aqu tratados
incluyen:
2.1 Fases del Proyecto y Ciclo de Vida del Proyecto
2.2 Interesados en el Proyecto
2.3 Influencias de la Organizacin
2.4 Habilidades Clave de Direccin en General
2.5 Influencia Sociales, Econmicas y Ambientales
2.1 FASES DEL PROYECTO Y CICLO DE VIDA DEL PROYECTO

Debido a que los proyectos son un emprendimiento nico, implican un cierto grado de incertidumbre. Las organizaciones ejecutantes usualmente dividen cada proyecto en varias fases del
proyecto para mejorar su control y proporcionar vnculos con las operaciones continuas de la
organizacin ejecutante. El conjunto de las fases del proyecto se conoce como el ciclo de vida
del proyecto.
2.1.1
Caractersticas de las Fases del Proyecto

Cada fase del proyecto se completa con la obtencin de uno o ms entregables. Un entregable,
en trminos de direccin de proyectos, es el producto de un trabajo, tal como un estudio de
factibilidad, un diseo detallado o un prototipo. Los entregables, y por lo tanto las fases, son
parte de una secuencia lgica diseada para asegurar la definicin apropiada del producto del
proyecto.
El fin de una fase del proyecto generalmente est marcado por una revisin de los entregables clave y del rendimiento del proyecto hasta esa fecha, para a) determinar si el proyecto
debe comenzar su prxima fase y b) detectar y corregir errores en una forma efectiva en trminos de costo. Estas revisiones al fin de cada fase son tambin conocidas por: salidas de fase
(phase exits), salidas de escena (stage gates) o puntos de cancelacin (kill points).
11
Captulo 2 El Contexto de la Direccin de Proyectos
2.1.2 | 2.1.3
Cada fase del proyecto normalmente incluye un grupo de entregables especficos, diseados para establecer el nivel deseado de control de gestin. La mayora de estos elementos
estn relacionados con un entregable principal de la fase. Las fases toman tpicamente sus
nombres en relacin con estos elementos: requerimientos, diseo, construccin, pruebas,
puesta en marcha, produccin y otros, de acuerdo con lo que corresponda. Varios ciclos de
vida representativos de proyectos se describen en la seccin 2.1.3.
2.1.2
Caractersticas del Ciclo de Vida del Proyecto

El ciclo de vida del proyecto definir tambin el comienzo y el final de un proyecto. Por
ejemplo, cuando una organizacin identifica una oportunidad a la cual le interesara responder,
frecuentemente autoriza una evaluacin de las necesidades y/o un estudio de factibilidad para
decidir si se emprender un proyecto. La definicin del ciclo de vida del proyecto determinar
si el estudio de factibilidad debe tratarse como la primera fase del proyecto o como un
proyecto separado.
La definicin del ciclo de vida del proyecto tambin determina qu acciones de transicin
se incluyen al principio y al final del proyecto y cules no se incluyen. De esta forma, la definicin del ciclo de vida del proyecto puede utilizarse para vincular al proyecto con las operaciones continuas de la organizacin ejecutante.
La secuencia de fases definida en la mayora de los ciclos de vida de proyectos generalmente involucra cierta forma de transferencia de tecnologa (handoff), como sucede al pasar
de requerimientos a diseo, de construccin a operaciones o de diseo a producir. Los entregables de la fase precedente son usualmente aprobados antes de comenzar el trabajo de la
prxima fase. Sin embargo, en algunos casos se comienza la fase subsiguiente antes de aprobar
el entregable de la fase anterior. Esto se hace cuando el riesgo involucrado es razonablemente
aceptable. Esta prctica de superponer fases es frecuentemente llamada camino acelerado (fast
tracking).
Los ciclos de vida de proyectos generalmente definen:
El trabajo tcnico que debera realizarse en cada fase (por ejemplo, el trabajo del arquitecto
es parte de la fase de definicin o de la fase de ejecucin?).
Las personas que deben involucrarse en cada fase (por ejemplo, operarios que deben
involucrarse en la obtencin de requerimientos y en el diseo).
Las descripciones del ciclo de vida del proyecto pueden ser muy generales o muy detalladas. Descripciones altamente detalladas pueden contener gran cantidad de formularios, grficos y listas de verificacin para proporcionar estructura y consistencia. Estos enfoques
detallados son comnmente denominados metodologas de direccin de proyectos.
La mayora de las descripciones del ciclo de vida del proyecto comparten un nmero de
caractersticas comunes:
El nivel de costo y de personal es bajo al comienzo, crece al avanzar en el proyecto y cae
rpidamente cuando el proyecto se aproxima a su conclusin. Este esquema se ilustra en
la figura 2-1.
Al comenzar el proyecto, la probabilidad en completarlo con xito es baja y por lo tanto el
riesgo y la incertidumbre son altos. La probabilidad de terminar con xito se torna progresivamente mayor a medida que el proyecto avanza.
El poder que tienen los interesados en el proyecto para influir en las caractersticas finales
del producto del proyecto y en el costo final del proyecto es alto al comienzo y decrece
progresivamente a medida que el proyecto avanza. La causa mayor de este fenmeno es
que el costo de los cambios y de la correccin de errores generalmente crece a medida que
el proyecto avanza.
Debe tenerse cuidado en distinguir entre el ciclo de vida del proyecto y el ciclo de vida del
producto. Por ejemplo, un proyecto emprendido para poner en el mercado una nueva computadora de escritorio es slo una fase del ciclo de vida del producto.
12
Figura 21. Ejemplo de un Ciclo de Vida Genrico
Aun cuando muchos ciclos de vida de proyectos tienen nombres de fases similares y
requieren entregables similares, muy pocos son idnticos. La mayora tiene cuatro o cinco
fases, pero algunos tienen nueve o ms. Incluso dentro de una misma rea de aplicacin
puede haber variaciones significativas un ciclo de vida para el desarrollo de software de una
organizacin puede tener una nica fase de diseo, mientras que otro tiene fases separadas
para el diseo funcional y el diseo detallado.
Los subproyectos dentro de los proyectos pueden tener tambin ciclos de vida diferentes.
Por ejemplo, una empresa de arquitectura contratada para disear un nuevo edificio de oficinas se involucra primero en la fase de definicin, a fin de obtener el diseo, y luego en la fase
de ejecucin, a fin de brindar soporte al esfuerzo de construccin. El proyecto de diseo de
arquitectura, sin embargo, tiene su propia serie de fases, desde el desarrollo conceptual,
pasando por la definicin e implementacin, hasta llegar a la conclusin. El arquitecto puede,
inclusive, tratar el diseo de los edificios y el soporte a la construccin como proyectos separados, con sus propias fases.
2.1.3
Ciclos de Vida Representativos de Proyectos

Los siguientes ciclos de vida de proyectos han sido seleccionados para ilustrar la diversidad de
enfoques en uso. Los ejemplos que se muestran son tpicos; esto no significa que sean
recomendados ni preferidos. En cada caso, los nombres de las fases y los entregables principales son los declarados por el autor de cada una de las figuras.
Adquisiciones de Defensa. La Instruccin 5000.2 del Departamento de Defensa de los
Estados Unidos de Norteamrica, en su borrador de coordinacin final de abril de 2000, define
una serie de hitos y fases de la adquisicin que se muestran en la figura 2-2.
Conceptualizacin y desarrollo de la tecnologa documentos de estudio de conceptos
alternativos para satisfacer las necesidades de una misin; desarrollo de subsistemas/componentes y demostracin del concepto/tecnologa de nuevos conceptos de sistema. Termina con la seleccin de una arquitectura de sistema y una tecnologa madura por ser
utilizada.
Desarrollo y demostracin de sistema integracin del sistema; reduccin del riesgo;
demostracin de modelos de desarrollo de ingeniera; desarrollo, prueba y evaluacin
operativa temprana. Termina con la demostracin del sistema en un entorno operativo.
Produccin y entrega produccin inicial de baja cantidad (Low Rate Initial Production
LRIP); desarrollo completo de la capacidad de fabricacin; esta fase se superpone a la
operacin continua y el soporte.
13
Figura 22 | Figura 23
Figura 22.
Ciclo de Vida Representativo de Adquisiciones de Defensa, segn US DODI 5000.2

(Borrador de Coordinacin Final, Abril 2000)
Soporteesta fase es parte del ciclo de vida del producto, pero es en realidad una gestin
de operacin continua. Varios proyectos pueden ser conducidos durante esta fase para
mejorar la capacidad, corregir defectos, etc.
Construccin. Adaptado de Morris (1), describe el ciclo de vida de un proyecto de construccin, tal como se ilustra en la figura 2-3.
Factibilidad formulacin del proyecto, estudio de factibilidad, diseo estratgico y
aprobacin. Una decisin de continuar/no continuar se toma al final de esta fase.
Planificacin y diseo diseo bsico, costo y cronograma, trminos y condiciones contractuales, y planificacin detallada. Los contratos principales se firman al final de esta fase.
Construccin fabricacin, entrega, obra civil, instalacin y prueba. El edificio queda sustancialmente terminado al final de esta fase.
Habilitacin y puesta en marcha prueba final y mantenimiento. El edificio queda completamente operativo al final de esta fase.
Industria farmacutica. Murphy (2) describe el ciclo de vida de un proyecto en Estados
Unidos de Norteamrica para el desarrollo de un nuevo producto farmacutico, como se ilustra
en la figura 2-4.
Descubrimiento y evaluacin preliminar incluye investigacin bsica y aplicada para
identificar candidatos para las pruebas preclnicas.
Desarrollo preclnico incluye pruebas de laboratorio y en animales, para determinar la
seguridad y eficacia, as como la preparacin y presentacin de la solicitud de nueva droga
en investigacin (IND).
Registro(s) incluye las pruebas de la fase clnica I, II y III, as como la preparacin y presentacin de la solicitud de nueva droga (NDA).
Actividad posterior a la solicitud incluye trabajo adicional requerido para dar soporte a
la revisin de la NDA por parte de la Administracin de Alimentacin y Drogas.
14
Figura 23. Ciclo de Vida Representativo de un Proyecto de Construccin, segn Morris
Desarrollo de Software. Hay una gran cantidad de modelos de ciclos de vida en uso para
el software, tal como el modelo de cascada. Muench y otros (3) describen un modelo en
espiral para el desarrollo de software con cuatro ciclos y cuatro cuadrantes, tal como se ilustra
en la figura 2-5.
Ciclo de prueba concepto captura los requerimientos de negocio, define los objetivos
para la prueba de concepto, produce el diseo conceptual del sistema y el diseo de la
lgica y construye la prueba de concepto, produce los planes de prueba de aceptacin,
conduce el anlisis de riesgos y genera recomendaciones.
Ciclo de construccin inicial deduce los requerimientos de sistema, define los objetivos
para la construccin inicial, produce el diseo lgico del sistema, disea e implementa la
primera construccin, produce los planes de prueba del sistema, evala la primera construccin, y genera recomendaciones.
Ciclo de segunda construccin deduce los requerimientos del subsistema, define los
objetivos para la segunda construccin, produce el diseo fsico, implementa la segunda
construccin, produce el plan de prueba del subsistema, evala la segunda construccin
y genera recomendaciones.
Ciclo final completa los requerimientos unitarios y el diseo final, implementa la construccin final y ejecuta las pruebas unitarias, de subsistema, de sistema y de aceptacin.
15
Figura 2-4 | Figura 25
Figura 24. Ciclo de Vida Representativo de un Proyecto Farmacutico, segn Murphy
2.2
INTERESADOS EN EL PROYECTO
Los interesados en el proyecto (stakeholders) son individuos y organizaciones que estn activamente involucrados en el proyecto o cuyos intereses pueden ser afectados positiva o negativamente como resultado de la ejecucin o conclusin del proyecto. Ellos pueden tambin
ejercer influencia sobre el proyecto y sus resultados. El equipo de direccin de proyectos debe
identificar a los interesados, determinar sus requerimientos y entonces gestionar e influir sobre
esos requerimientos para asegurar el xito del proyecto. La identificacin de los interesados es
con frecuencia especialmente difcil. Por ejemplo, un operario de una lnea de produccin
cuyo empleo depende del resultado de un proyecto de diseo de un nuevo producto, es un
interesado?
Dentro de los interesados clave de los proyectos se encuentran:
Director del proyecto la persona responsable de la direccin del proyecto.
Cliente la persona u organizacin que utilizar el resultado del proyecto. Puede haber
mltiples niveles de clientes. Por ejemplo, dentro de los clientes para un nuevo producto
farmacutico pueden encontrarse los doctores que lo recetan, los pacientes que los toman
y las entidades que pagan por l. En algunas reas de aplicacin, cliente y usuario son
sinnimos mientras que en otras cliente se refiere a la entidad que compra el resultado del
proyecto y usuarios son aquellos que usan directamente el resultado del proyecto.
Organizacin ejecutante la empresa cuyos empleados estn ms directamente involucrados en realizar el trabajo del proyecto.
Miembros del equipo de direccin del proyecto el grupo que ejecuta el trabajo del
proyecto.
Patrocinador el individuo o grupo interno o externo a la organizacin ejecutante que
proporciona los recursos financieros, en efectivo o de otra manera, para el proyecto.
Adicionalmente, hay muchos nombres diferentes y categoras de interesados en los
proyectos internos y externos, dueos y proveedores de fondos, proveedores y contratistas,
miembros del equipo y sus familias, agencias del gobierno y medios de comunicacin, ciudadanos particulares, organizaciones de influencia temporales o permanentes y la sociedad en
general. La nomenclatura y el agrupamiento de interesados es principalmente una ayuda para
identificar qu individuos y organizaciones se ven a s mismos como interesados. Los roles y
las responsabilidades de los interesados pueden superponerse, como cuando una empresa de
ingeniera proporciona financiamiento para una planta que ella misma est diseando.
16
Figura 25. Ciclo de Vida Representativo del Desarrollo de Software, segn Muench
La gestin de las expectativas de los interesados puede ser difcil porque los interesados con frecuencia tienen objetivos diferentes que pueden entrar en conflicto. Por
ejemplo:
El gerente de un departamento que ha solicitado un nuevo sistema de procesamiento de informacin puede desear un bajo costo, el arquitecto del sistema
puede enfatizar la excelencia tcnica y el contratista de programacin puede estar
ms interesado en maximizar su ganancia.
17
2.3 | 2.3.3
El vicepresidente de investigacin de una empresa de electrnica puede definir el xito de

un producto nuevo como una tecnologa de avanzada, el vicepresidente de produccin
puede definirlo como prcticas de nivel mundial y el vicepresidente de mercadeo puede
estar principalmente preocupado con la cantidad de nuevas caractersticas.
El propietario en un proyecto de desarrollo inmobiliario puede estar concentrado en la ejecucin en plazo, el cuerpo de gobierno local puede desear maximizar el ingreso impositivo, un grupo ecologista pueden desear minimizar el impacto ambiental adverso y los
vecinos pueden desear que el proyecto se realice en otro sitio.
En general, la diferencia entre los interesados debera resolverse en favor del cliente. Esto
no significa, sin embargo, que las necesidades y expectativas de otros interesados puedan o
deban ser descartadas. Encontrar una resolucin apropiada a esas diferencias puede ser una
de los mayores desafos de la direccin de proyectos.
2.3 INFLUENCIAS DE LA ORGANIZACIN

Los proyectos son tpicamente parte de una organizacin mayor que la del proyecto corporaciones, agencias de gobierno, instituciones de salud, entidades internacionales, asociaciones profesionales, y otras. Incluso cuando el proyecto es la organizacin (convenios,
asociaciones), estar igualmente influido por la organizacin u organizaciones que le dieron
lugar. La madurez de la organizacin con respecto a sus sistemas de direccin de proyectos, el
estilo, la cultura, la estructura de la organizacin y la oficina de direccin de proyectos pueden
tambin influir en el proyecto. Las secciones siguientes describen aspectos clave de las
mayores estructuras de las organizaciones que probablemente influyan en el proyecto.
2.3.1
Sistemas de Organizacin
Las organizaciones basadas en proyectos son aqullas cuyas operaciones consisten principalmente en proyectos. Estas organizaciones pertenecen a dos categoras:
Organizaciones que obtienen sus ingresos principalmente de la ejecucin de proyectos para
otros empresas de arquitectura, firmas de ingenieros, consultores, contratistas de
construccin, contratistas del gobierno, organizaciones no gubernamentales, etc.
Organizaciones que han adoptado la direccin por proyectos (management by projects)
(vase la seccin 1.3).
Estas organizaciones tienden a tener sistemas de gestin para facilitar la direccin de
proyectos. Por ejemplo, sus sistemas financieros son con frecuencia especialmente diseados
para contabilizar, hacer seguimiento e informar sobre mltiples proyectos simultneos.
Las organizaciones no basadas en proyectos frecuentemente carecen de sistemas de gestin
diseados para apoyar las necesidades de los proyectos en forma eficiente y efectiva. La
ausencia de sistemas orientados a proyectos usualmente dificulta la direccin de proyectos. En
algunos casos, las organizaciones no basadas en proyectos tienen departamentos u otras
unidades que operan como organizaciones basadas en proyectos con sistemas afines a
proyectos.
El equipo de direccin de proyectos debera tener un conocimiento profundo sobre la
forma en que los sistemas de la organizacin afectan al proyecto. Por ejemplo, si la organizacin premia a sus gerentes funcionales por cargar el tiempo de su personal a los proyectos,
entonces el equipo de direccin de proyectos podra tener que implementar controles para
asegurar que ese personal sea utilizado en forma efectiva dentro del proyecto.
18
Figura 26. Influencia de la Estructura de la Organizacin en los Proyectos
2.3.2
Culturas y Estilos Organizacionales

La mayora de las organizaciones han desarrollado culturas nicas y descriptibles. Estas culturas
se reflejan en sus valores compartidos, normas, creencias y expectativas; en sus polticas y procedimientos; en su visin de las relaciones de autoridad y en muchos otros factores. La cultura
de las organizaciones frecuentemente tiene una influencia directa sobre el proyecto. Por
ejemplo:
Es ms probable que un equipo que propone un enfoque inusual o de alto riesgo obtenga
la aprobacin dentro de una organizacin agresiva o emprendedora.
Un director de proyecto (PM) con un estilo altamente participativo tiende a encontrar problemas dentro de una organizacin jerrquica rgida, mientras que un director de proyecto
con un estilo autoritario se vera igualmente confrontado en una organizacin participativa.
2.3.3
Estructura de la Organizacin
La estructura de la organizacin ejecutante frecuentemente restringe o pauta los trminos en
que sus recursos estn disponibles para el proyecto. Las estructuras de la organizacin pueden
ser caracterizadas dentro de un espectro que va desde funcional a proyectizada, pasando por
una variedad de estructuras matriciales. La figura 2-6 muestra las caractersticas clave que, en
relacin con los proyectos, tienen los principales tipos de estructura de la organizacin. La
organizacin del proyecto se trata en la seccin 9.1, Planificacin de la organizacin.
La organizacin funcional clsica, tal como se muestra en la figura 2-7, es una jerarqua
donde cada empleado tiene un superior claramente establecido. Los empleados estn agrupados en el nivel superior por su especialidad, como produccin, mercadeo, ingeniera y contabilidad, con una subdivisin adicional de ingeniera en organizaciones funcionales que dan
soporte al negocio de la organizacin mayor (por ejemplo, mecnica y elctrica). Las organizaciones funcionales igualmente tienen proyectos, pero el alcance percibido para esos
proyectos est restringido a los lmites de la funcin: el departamento de ingeniera dentro de
una organizacin funcional har su trabajo con independencia de los departamentos de
19
Figura 27 | 2.4
Figura 27. Organizacin Funcional
produccin o mercadeo. Por ejemplo, cuando se emprende el desarrollo de un nuevo producto dentro de una organizacin puramente funcional, la fase de diseo es frecuentemente
denominada proyecto de diseo e incluye slo personal del departamento de ingeniera. Si
aparecen preguntas relacionadas con fabricacin, son pasadas a travs de la jerarqua hasta
el jefe del departamento, quien consulta con el jefe del departamento de produccin. El jefe
del departamento de ingeniera devuelve entonces la respuesta a travs de la jerarqua hasta el
director del proyecto de ingeniera.
En el extremo opuesto del espectro est la organizacin proyectizada, tal como se muestra
en la figura 2-8. En una organizacin proyectizada, los miembros del equipo estn frecuentemente ubicados en un mismo lugar. La mayora de los recursos de la organizacin estn involucrados en el trabajo del proyecto y los directores de proyectos cuentan con una gran
independencia y autoridad. Las organizaciones proyectizadas suelen tener unidades denominadas departamentos, pero esos grupos reportan directamente al director de proyecto o
proveen servicios de soporte a diversos proyectos.
Las organizaciones matriciales, como se muestra en las figura 2-9 a figura 2-11, son una
mezcla de caractersticas funcionales y proyectizadas. Las matriciales dbiles mantienen muchas
de las caractersticas de las organizaciones funcionales y el director de proyecto es ms un
coordinador que un director. En forma similar, las matriciales fuertes tienen muchas de las
caractersticas de las organizaciones proyectizadas directores de proyecto de tiempo completo con considerable autoridad y personal administrativo asignado de tiempo completo.
La mayora de las organizaciones modernas incluyen todas estas estructuras en varios
niveles, como se muestra en la figura 2-12. Por ejemplo, hasta una organizacin fundamentalmente funcional puede crear un equipo de proyecto especial para manejar un proyecto
crtico. Ese equipo puede tener muchas de las caractersticas de un proyecto dentro de una
organizacin proyectizada. El equipo puede incluir personal de diferentes departamentos funcionales asignado en tiempo completo, puede desarrollar su propio esquema de procedimientos operativos y puede operar fuera de la estructura estndar y formalizada de informes.
20
Figura 28. Organizacin Proyectizada
2.3.4
Oficina de Proyecto
Hay una gama de interpretaciones respecto de lo que constituye una oficina de proyecto. Una
oficina de proyecto puede operar de diversas formas, desde brindar funciones de soporte a
directores de proyecto en la forma de capacitacin, software, plantillas, etc., hasta ser realmente responsable por los resultados del proyecto.
2.4 HABILIDADES CLAVE DE DIRECCIN EN GENERAL

Direccin en general es un concepto amplio que se refiere a cada aspecto de la gestin continua de una empresa. Entre otros temas, incluye:
Finanzas y contabilidad, ventas y mercadeo, investigacin y desarrollo, fabricacin y distribucin.
Planificacin estratgica, planificacin tctica y planificacin operativa.
Estructuras de la organizacin, comportamiento organizacional, administracin de personal,
compensaciones, beneficios y planes de carrera.
Gestin de las relaciones laborales a travs de la motivacin, delegacin, supervisin,
desarrollo de equipos, manejo de conflictos y otras tcnicas.
Gestin personal a travs de manejo del tiempo propio, manejo de las tensiones y otras tcnicas.
Las habilidades de gestin en general proporcionan la mayor parte de los cimientos para
la construccin de habilidades de direccin de proyectos. Son frecuentemente esenciales para
el director de proyecto. En cualquier proyecto, las habilidades relativas a una gran cantidad de
temas generales de gestin sern requeridas. Esta seccin describe las habilidades clave de
gestin en general que tienen alta probabilidad de afectar a la mayora de los proyectos y que
no se cubren en ninguna otra parte de este documento.
21
Figura 29. Organizacin Matricial Dbil
Figura 210. Organizacin Matricial Balanceada
22
Figura 211. Organizacin Matricial Fuerte
Figura 212. Organizacin Combinada
23
2.4.1 | 2.4.5
Estas habilidades estn bien documentadas en la literatura sobre gestin en general y ellas se
aplican fundamentalmente de la misma forma en un proyecto.
Existen incluso muchas habilidades de gestin en general que son slo relevantes en ciertos
proyectos o en ciertas reas de aplicacin. Por ejemplo, la seguridad de los miembros del
equipo es crtica en virtualmente todos los proyectos de construccin, pero es de poca importancia en la mayora de los proyectos de desarrollo de software.
2.4.1
Liderazgo
Kotter (4) distingue entre liderar y gestionar, enfatizando a la vez la necesidad de ambos: uno
sin el otro tiende a producir pobres resultados. l dice que gestionar es primordialmente ocuparse de producir consistentemente los resultados clave esperados por los interesados, mientras que liderar involucra:
Establecer la direccin desarrollar tanto una visin del futuro como la estrategia para
producir los cambios necesarios a fin de alcanzar esa visin.
Alinear a la gente comunicar esa visin con palabras y hechos a todos aquellos cuya
cooperacin se requiere para alcanzar la visin.
Motivar e inspirar ayudar a que la gente se auto-potencie para vencer las barreras que
se oponen a los cambios, tanto las de recursos como las polticas o burocrticas.
En un proyecto, particularmente en un gran proyecto, generalmente se espera que el
director de proyecto sea tambin su lder. Sin embargo, el liderazgo no se limita al director
de proyecto: tambin puede ser demostrado por muchos individuos diferentes, en muchos
momentos del proyecto. El liderazgo debe ser demostrado en todos los niveles del proyecto
(liderazgo de proyecto, liderazgo tcnicos y liderazgo de equipo).
2.4.2
Comunicacin
La comunicacin implica el intercambio de informacin. El emisor es responsable de la claridad de la informacin, por evitar la ambigedad y asegurar que est completa, de forma que
quien la recibe lo haga en forma correcta. El receptor es responsable de asegurar que la informacin se recibe en forma completa y se entiende correctamente. La comunicacin tiene
muchas dimensiones:
Escrita y oral, escuchar y hablar.
Interna (dentro del proyecto) y externa (hacia el cliente, los medios de informacin, el
pblico, etc.).
Formal (informes, presentaciones, etc.) e informal (memos, conversaciones ad hoc, etc.).
Vertical (hacia arriba y hacia abajo en la organizacin) y horizontal (con compaeros y
socios).
Las habilidades de gestin en general referidas a la comunicacin estn relacionadas con
la gestin de las comunicaciones (descrita en el Captulo 10), pero no son lo mismo que lo que
all se presenta. La comunicacin es el concepto amplio, e involucra un cuerpo de conocimiento substancial que no es privativo del contexto del proyecto, por ejemplo:
Modelos emisor-receptor ciclos de realimentacin, barreras a la comunicacin, etc.
Eleccin del medio cundo comunicar por escrito, cundo hacerlo oralmente, cundo
escribir un memo informal, cundo emitir un informe formal, etc.
24
Estilo de escritura voz activa y voz pasiva, estructura de las oraciones, eleccin
de las palabras, etc.
Tcnicas de presentacin lenguaje corporal, diseo de ayudas visuales, etc.
Tcnicas de manejo de reuniones preparacin de la agenda, manejo de conflictos, etc.
La gestin de las comunicaciones del proyecto es la aplicacin de estos conceptos
amplios a las necesidades especficas de un proyecto por ejemplo, decidir cmo,
cundo, en qu forma y a quin reportar sobre el rendimiento del proyecto.
2.4.3
Negociacin
Negociar implica debatir con otros para entenderse con ellos o alcanzar un acuerdo. El
acuerdo puede ser negociado directamente o con asistencia; la mediacin o el arbitraje
dos tipos de negociacin asistida.
Las negociaciones ocurren acerca de muchos temas, en muchos momentos y en
diversos niveles del proyecto. Durante el transcurso de un proyecto tpico, el personal
del proyecto suele negociar por alguno o todos los siguientes aspectos:
Objetivos de alcance, costo y cronograma.
Cambios al alcance, costo y cronograma.
Trminos y condiciones contractuales.
Asignaciones.
Recursos.
2.4.4
Resolucin de Problemas
La resolucin de problemas implica una combinacin de definicin del problema y toma
de decisiones.
La definicin del problema requiere distinguir entre causas y sntomas. Los problemas pueden ser internos (un empleado clave es transferido a otro proyecto) o
externos (un permiso requerido para empezar el trabajo se ve demorado). Los problemas pueden ser tcnicos (diferentes opiniones sobre la mejor forma de disear un
producto), de gestin (un grupo funcional no se desempea de acuerdo con el plan) o
interpersonales (choques de personalidad o estilo).
La toma de decisiones implica analizar el problema para identificar soluciones
viables y entonces tomar una decisin eligiendo entre ellas. Las decisiones pueden
tomarse u obtenerse (del cliente, del equipo del proyecto o de un gerente funcional).
Una vez tomadas, las decisiones deben ser implementadas. Las decisiones tienen tambin asociados elementos de tiempo la decisin correcta puede no ser la mejor
decisin si se toma demasiado pronto o demasiado tarde.
2.4.5
Influencia en la Organizacin
Influir en la organizacin implica la habilidad de hacer que las cosas se hagan. Esto
requiere entender las estructuras formales e informales de todas las organizaciones
involucradas la organizacin ejecutante, el cliente, los socios, los contratistas y
muchos otros. Influir en la organizacin tambin requiere conocer los mecanismos de
poder y polticos.
25
2.5 | 2.5.4
Ambos, poder y poltica, son usados aqu en su sentido positivo. Pfeffer (5) define el poder
como la habilidad potencial para influir en el comportamiento, para cambiar el curso de los
eventos, para vencer la resistencia y para lograr que la gente haga cosas que de otra forma no
hara. De forma similar, Eccles y otros (6) dicen que la poltica se refiere a conseguir acciones
colectivas de un grupo de personas que pueden tener intereses significativamente diferentes.
Se refiere a utilizar el conflicto y el desorden en forma creativa. El sentido negativo, por
supuesto, deriva de que al intentar reconciliar estos intereses se desatan luchas de poder y
juegos de organizacin que pueden a veces adquirir una vida propia totalmente improductiva.
2.5 INFLUENCIAS SOCIALES, ECONMICAS Y AMBIENTALES

Como el caso de las habilidades de gestin en general, la influencia socioeconmica incluye
una amplia gama de conceptos y de temas. El equipo de direccin de proyectos debe entender
que las condiciones y tendencias reinantes en esta rea pueden tener grandes efectos en su
proyecto: un pequeo cambio aqu puede traducirse, usualmente luego de un tiempo, en una
convulsin catastrfica dentro del propio proyecto. De las muchas influencias socioeconmicas
potenciales, las principales categoras que frecuentemente afectan a los proyectos se describen
brevemente a continuacin.
2.5.1
Estndares y Regulaciones
La Organizacin Internacional de Estandarizacin (International Organization for Standardization, ISO) establece la siguiente diferencia entre estndares y regulaciones (7):
Un estndar es un documento aprobado por un cuerpo reconocido que proporciona, para
uso comn y repetido, reglas, guas o caractersticas para productos, procesos o servicios
cuyo cumplimiento no es obligatorio. Hay muchos estndares en uso que cubren desde
estabilidad trmica de fluidos hidrulicos hasta el tamao de los disquetes de computadora.
Una regulacin es un documento que describe las caractersticas de productos, procesos
o servicios, incluyendo las estipulaciones administrativas aplicables, cuyo cumplimiento es
obligatorio. El reglamento de edificacin es un ejemplo de regulacin.
Debe distinguirse cuidadosamente entre estndares y regulaciones, debido a que existe un
rea gris entre las dos. Por ejemplo:
Los estndares suelen comenzar como guas que describen un enfoque preferido, y luego,
con su adopcin generalizada, se convierten en regulaciones de facto (por ejemplo, el uso
del mtodo de camino crtico para trazar el cronograma de proyectos de construccin).
El cumplimiento puede ser obligatorio en diferentes niveles (por ejemplo, por una agencia
de gobierno, por la direccin de una organizacin ejecutante o por el equipo de direccin
de proyectos)
Para muchos proyectos, los estndares y regulaciones (cualquiera sea la definicin) son
muy bien conocidos y los planes de proyecto reflejan sus efectos. En otros casos, la influencia
es desconocida o incierta y debe ser considerada dentro de la gestin de riesgos del proyecto
(descrita en el captulo 11).
26
2.5.2
Internacionalizacin
A medida que crece la cantidad de organizaciones que se involucran en trabajos que trascienden las fronteras de sus pases, hay ms proyectos que se expanden fuera de las fronteras
nacionales. Adems de a la tradicional preocupacin por alcance, costo, tiempo y calidad, el
equipo de direccin de proyectos debe tambin considerar el efecto de la diferencia en usos
de horarios, feriados nacionales y regionales, requerimientos de viajes para reuniones personales, la logstica para teleconferencias y las frecuentemente voltiles diferencias polticas.
2.5.3
Influencias Culturales
Cultura es la totalidad de los patrones de comportamiento transmitidos socialmente, el arte,
las creencias, las instituciones y todo otro resultado del trabajo y el pensamiento humano (8).
Cada proyecto debe operar dentro de un contexto de una o varias normas culturales. Esta rea
de influencia incluye aspectos polticos, econmicos, demogrficos, educativos, ticos, tnicos,
religiosos y otros relativos a prcticas, creencias y actitudes que afectan la forma en que
interactan las personas y las organizaciones.
2.5.4
Sustentabilidad Social, Econmica y Ambiental

Virtualmente todos los proyectos se planifican e implementan en un contexto social,
econmico y ambiental y tienen impactos positivos y negativos deseados y no deseados. Las
organizaciones son cada vez ms responsables por el impacto del resultado de sus proyectos
(por ejemplo, la destruccin accidental de un yacimiento arqueolgico durante un proyecto de
construccin de una carretera), as como por el efecto de sus proyectos sobre la gente, la
economa y el medio ambiente hasta bastante tiempo despus de haber completado un
proyecto (por ejemplo, una carretera puede facilitar el acceso, pero tambin acelerar la destruccin, de un entorno que alguna vez fue prstino).
27
Captulo 3
Procesos de la
Direccin de Proyectos
La direccin de proyectos es un esfuerzo integrador una accin o la falta de accin en una
de las reas afectar, por lo general, otras reas. Las interacciones pueden ser directas y bien
entendidas o pueden ser sutiles e inciertas. Por ejemplo, un cambio de alcance casi siempre
afectar el costo del proyecto, pero puede o no afectar la motivacin del equipo o la calidad
del producto.
Estas interacciones a menudo requieren intercambios entre los objetivos del proyecto el
desempeo de una de las reas slo puede incrementarse sacrificando el desempeo en otra
de ellas. Los intercambios especficos de desempeo pueden variar de proyecto a proyecto y
de organizacin a organizacin. La gestin exitosa del proyecto requiere resolver estas interacciones en forma activa. Muchos profesionales de direccin del proyecto se refieren a la triple
restriccin del proyecto como un marco de referencia para evaluar demandas en competencia.
La triple restriccin del proyecto se representa grficamente como un tringulo en el cual cada
uno de los lados, o de los vrtices, representa uno de los parmetros que maneja el equipo de
proyecto.
Para comprender mejor la naturaleza integradora de la direccin del proyecto y para enfatizar la importancia de la integracin, este documento describe la direccin del proyecto en
funcin de sus procesos componentes y sus interacciones. Este captulo brinda una introduccin al concepto de direccin del proyecto como una cantidad de procesos interconectados y,
de este modo, establece los fundamentos esenciales para comprender las descripciones de los
procesos que se hallan en los captulos 4 a 12. Por lo tanto incluye las siguientes secciones
principales:
3.1 Procesos del Proyecto
3.2 Grupos de Procesos
3.3 Interacciones entre Procesos
3.4 Adaptacin de las Interacciones entre Procesos
3.5 Organizacin de los Procesos de Direccin del Proyecto
3.1 PROCESOS DEL PROYECTO

Los proyectos se componen de procesos. Un proceso es una serie de acciones que producen
un resultado (1). Los procesos de proyecto son ejecutados por personas y, por lo general,
pertenecen a una de las dos siguientes categoras principales:
29
3.2 | Figura 33
Captulo 3 Procesos de la Direccin de Proyectos
Procesos de la direccin del proyecto describen, organizan y ejecutan el trabajo del

proyecto. Los procesos de la direccin que se aplican la mayora de las veces a la mayora
de los proyectos, son descritos brevemente en este captulo y en detalle, en los captulos 4
a 12.
Procesos orientados al producto especifican y crean el producto del proyecto. Los procesos
orientados al producto comnmente se definen de acuerdo con el ciclo de vida del
proyecto (analizado en la seccin 2.1) y varan segn el rea de aplicacin (analizada en el
Apndice E).
Los procesos de direccin del proyecto y los procesos orientados al producto se superponen e interactan durante el proyecto. Por ejemplo, el alcance del proyecto no se puede
establecer si no se cuenta con una elemental comprensin de cmo crear el producto.
3.2 GRUPOS DE PROCESOS

Los procesos de direccin del proyecto pueden ser organizados en cinco grupos, de uno o ms
procesos cada uno:
Procesos de iniciacin autorizacin del proyecto o de una fase del mismo.
Procesos de planificacin definicin y refinamiento de objetivos, seleccin de la mejor
alternativa entre posibles cursos de accin para lograr los objetivos a alcanzar por el
proyecto.
Procesos de ejecucin coordinacin de las personas y de otros recursos necesarios para
llevar a cabo el plan.
Procesos de control aseguramiento de que se cumplan los objetivos del proyecto
mediante la supervisin y la medicin regular del avance para identificar las variaciones
con respecto al plan y poder tomar las acciones correctivas cuando sea necesario.
Procesos de cierre formalizacin de la aceptacin del proyecto o de una fase y organizacin de un final ordenado.
Los grupos de procesos estn vinculados por los resultados que producen el resultado
o la salida de uno de ellos, a menudo constituye la entrada en otro proceso. Los vnculos de
los grupos de procesos centrales son iterados planificacin provee a ejecucin, al comienzo
del proyecto, un plan de proyecto documentado y luego, a medida que el proyecto progresa,
entrega actualizaciones documentadas de dicho plan. Estas conexiones estn ilustradas en la
figura 3-1. Adems, los grupos de procesos de direccin del proyecto no son eventos discretos, puntuales; ellos son actividades que se superponen y que se ejecutan con variada intensidad a travs de cada fase del proyecto. En la figura 3-2 se ilustra cmo los grupos de
procesos se superponen y cmo varan a travs de la fase.
Finalmente, las interacciones entre los grupos de procesos atraviesan las fases de modo tal
que el cierre de una fase brinda los elementos necesarios para el inicio de la fase siguiente. Por
ejemplo, el cierre de una fase de diseo requiere la aceptacin por parte del cliente del documento resultante. Simultneamente, este documento de diseo define la descripcin del producto, necesaria para la fase de implementacin que sigue. Esta interaccin se ilustra en la
figura 3-3.
La repeticin de los procesos de iniciacin al comienzo de cada fase permite mantener el
proyecto enfocado en los objetivos del negocio, dado que son stos la causa de su implementacin. Asimismo, debera ayudar a decidir la cancelacin del proyecto si ya no existen las
necesidades del negocio o si el proyecto ya no tiene probabilidades adecuadas de satisfacer
tales necesidades. Las necesidades del negocio se analizan con mayor profundidad en la introduccin a la seccin 5.1, Iniciacin.
Es importante destacar que las entradas y salidas reales de los procesos dependen de la fase
en la que stos se llevan a cabo. Si bien la figura 3-3 se ha dibujado con fases discretas y
procesos discretos, en un proyecto real se producir un gran nmero de superposiciones. El
proceso de planificacin, por ejemplo, debe proveer no slo detalles del trabajo a ser ejecutado en la fase en que se encuentra el proyecto, para completarla exitosamente, sino que
30
Figura 31. Vinculos entre los Grupos de Procesos en una Fase
Figura 32. Superposicin de los Grupos de Procesos en una Fase
Figura 33. Interaccin entre Fases
31
Figura 34. Relaciones entre los Procesos de Iniciacin
tambin debe brindar alguna descripcin preliminar del trabajo a ser realizado en fases posteriores. Esta progresiva elaboracin del plan del proyecto se conoce a menudo como planificacin dinmica (rolling wave planning), lo cual significa que la planificacin es un proceso
iterativo y continuo.
Involucrar en las fases del proyecto a los interesados por lo general mejora las probabilidades de satisfacer los requerimientos del cliente y facilita la aceptacin o el compromiso con
el proyecto por parte de los interesados, lo cual a menudo es crtico para el xito.
3.3 INTERACCIONES ENTRE PROCESOS

Dentro de cada grupo de procesos, los procesos individuales estn conectados por sus
entradas y salidas. Tomando en cuenta dichas conexiones, podemos describir cada proceso en
funcin de sus:
Entradas documentos o productos documentados sobre los cuales se efectuarn
acciones.
Tcnicas y herramientas mecanismos aplicados a las entradas para transformarlas en
salidas.
Salidas documentos o productos documentados que resultan del proceso.
Los procesos de direccin del proyecto comunes a la mayora de los casos, para la mayora
de las reas de aplicacin, se listan aqu y se describen en detalle en los captulos 4 a 12. Los
nmeros entre parntesis, que se indican a continuacin del nombre de cada proceso identifican el captulo y la seccin en la que ste es descrito. Las interacciones entre procesos,
ilustradas en las figuras de este captulo, son tambin tpicas de la mayora de los procesos, en
la mayora de las reas de aplicacin. En la seccin 3.4 se analiza la adaptacin de las descripciones de los procesos y sus interacciones.
3.3.1
Procesos de Iniciacin
La figura 3-4 ilustra el nico proceso integrante de este grupo de procesos.
Iniciacin (5.1) autorizar el proyecto o la fase es parte de la gestin del alcance del
proyecto.
3.3.2
Procesos de Planificacin
La planificacin es crucial en el proyecto, porque ste implica hacer algo que no se ha
hecho antes. Es por ello que esta seccin tiene ms procesos que otras. A pesar de esto, el
nmero de procesos no significa que la direccin del proyecto sea primordialmente planificacin la magnitud de la planificacin realizada debe estar en concordancia con el alcance
del proyecto y la utilidad de la informacin desarrollada. La planificacin es un esfuerzo continuo que se realiza a lo largo de la vida del proyecto.
32
Figura 35. Relaciones entre los Procesos de Planificacin
En la figura 3-5 se muestran las relaciones existentes entre los procesos del grupo planificacin del proyecto (este cuadro es una apertura detallada de la elipse denominada Procesos
de Planificacin de la figura 3-1). Estos procesos estn sujetos a frecuentes iteraciones antes
de completarse el plan del proyecto. Por ejemplo, si la fecha inicial de finalizacin del proyecto
es inaceptable, podra ser necesario redefinir los recursos del proyecto, los costos o aun el
alcance del mismo. Adems, la planificacin no es una ciencia exacta dos equipos distintos
pueden generar planes muy diversos para un mismo proyecto.
Procesos centrales. Algunos procesos de planificacin tienen dependencias definidas, las
que requieren que sean ejecutados esencialmente en el mismo orden en la mayora de los
proyectos. Por ejemplo, se deben determinar las actividades antes de que puedan ser programadas o costeadas. Estos procesos centrales de planificacin pueden ser iterados varias veces
durante cada una de las fases del proyecto. Ellos incluyen:
33
3.3.2 | 3.3.3
34
Planificacin del Alcance (5.2) desarrollo de una descripcin escrita del alcance del
proyecto como base de futuras decisiones a ser tomadas en el mismo.
Definicin del Alcance (5.3) subdivisin de los entregables mayores del proyecto en
componentes menores y ms simples para gestionar.
Definicin de Actividades (6.1) identificacin de las actividades especficas que deben
ejecutarse para producir los diversos entregables del proyecto.
Secuenciamiento de Actividades (6.2) identificacin y documentacin de las dependencias entre las actividades.
Estimacin de la Duracin de las Actividades (6.3) estimacin del nmero de perodos
de trabajo que ser necesario para completar cada una de las actividades.
Desarrollo del Cronograma (6.4) anlisis de la secuencia de actividades, de la duracin
de las actividades y de las necesidades de recursos para crear el cronograma del proyecto.
Planificacin de la Gestin de Riesgos (11.1) decisin acerca de cmo encarar y planificar la gestin de riesgos en el proyecto.
Planificacin de Recursos (7.1) determinacin de qu recursos (personas, equipos, materiales, etc.) y qu cantidades de cada uno debern ser usados para ejecutar las actividades
del proyecto.
Estimacin de Costos (7.2) desarrollo de una aproximacin (estimacin) de los costos
de los recursos requeridos para completar las actividades del proyecto.
Asignacin del Presupuesto de Costos (7.3) asignacin de los costos estimados a cada
uno de los paquetes de trabajo.
Desarrollo del Plan del Proyecto (4.1) reunin de los resultados de otros procesos de
planificacin y sntesis en un documento consistente y coherente.
Procesos facilitadores. Las interacciones entre los otros procesos de planificacin son ms
dependientes de la naturaleza del proyecto. Por ejemplo, en algunos proyectos, pocos o
ningn riesgo se pueden identificar hasta que no se haya completado la mayor parte de la
planificacin y, recin en esa instancia, el equipo de proyecto toma conciencia de que los objetivos de costo y cronograma son extremadamente comprometidos y por lo tanto implican un
riesgo considerable. Si bien estos procesos facilitadores son realizados en forma intermitente y
segn sea necesario durante el proyecto, no son opcionales. Ellos incluyen:
Planificacin de la Calidad (8.1) identificacin de qu estndares de calidad son relevantes para el proyecto y determinacin de cmo satisfacerlos.
Planificacin de la Organizacin (9.1) identificacin, documentacin y asignacin de
roles, responsabilidades y relaciones de reporte en el proyecto.
Adquisicin de Personal (9.2) obtencin de los recursos humanos necesarios asignados
y trabajando en el proyecto.
Planificacin de las Comunicaciones (10.1) determinacin de las necesidades de informacin y comunicacin de los interesados: quin necesita qu informacin, cundo la
necesita y cmo se le har llegar.
Identificacin de Riesgos (11.2) determinacin de qu riesgos pueden afectar el proyecto
y documentacin de las caractersticas de cada uno.
Anlisis Cualitativo de Riesgos (11.3) anlisis cualitativo de los riesgos y condiciones de
riesgo para dar prioridades a sus efectos sobre los objetivos del proyecto.
Anlisis Cuantitativo de Riesgos (11.4) medicin de la probabilidad y el impacto de los
riesgos y evaluacin de cmo afectan los objetivos del proyecto.
Plan de Respuesta a Riesgos (11.5) desarrollo de procedimientos y tcnicas para ampliar
las oportunidades y reducir las amenazas que los riesgos pueden provocar a los objetivos
del proyecto.
Figura 36. Relaciones entre los Procesos de Ejecucin
Planificacin de Adquisiciones (12.1) determinacin de qu comprar, cunto y cundo.

Planificacin de la Bsqueda de Proveedores (12.2) documentacin de los requerimientos del producto e identificacin de las potenciales fuentes.
3.3.3
Procesos de Ejecucin
Los procesos de ejecucin incluyen procesos centrales y procesos facilitadores. La figura 3-6
ilustra cmo interactan los siguientes procesos centrales y facilitadores:
Ejecucin del Plan de Proyecto (4.2) realizacin del plan de proyecto ejecutando las
actividades incluidas en el mismo.
Aseguramiento de la Calidad (8.2) evaluacin del desempeo completo del proyecto, de
manera regular para brindar confianza de que el proyecto va a satisfacer los estndares de
calidad relevantes.
Desarrollo del Equipo (9.3) desarrollo de habilidades y competencias, individuales y grupales, para mejorar el desempeo del equipo.
Distribucin de la Informacin (10.2) aseguramiento de que la informacin necesaria a
cada uno de los interesados en el proyecto est disponible en tiempo y forma.
Bsqueda de Proveedores (12.3) obtencin de cotizaciones, ofertas o propuestas segn
sea apropiado.
Seleccin de Proveedores (12.4) eleccin entre los potenciales vendedores.
Administracin del Contrato (12.5) gestin de la relacin con el vendedor.
35
Figura 37 | 3.4
Figura 37. Relaciones entre los Procesos de Control
3.3.4
Procesos de Control
El desempeo del proyecto debe ser supervisado y medido regularmente para identificar variaciones respecto al plan. Estas variaciones alimentan los procesos de control de las diversas
reas de conocimiento. En el caso de observarse variaciones significativas (por ejemplo,
aqullas que ponen en peligro los objetivos del proyecto) se ajusta el plan repitiendo los procesos de planificacin adecuados para este fin. Por ejemplo, no haber cumplido con la fecha
de finalizacin de una actividad puede requerir ajustes al plan de desarrollo del equipo del
proyecto, implementar horas extras o realizar ajustes entre los objetivos de presupuesto y
cronograma del proyecto. Controlar incluye tambin tomar acciones preventivas para anticiparse a posibles problemas.
El grupo de procesos de control est compuesto por procesos centrales y facilitadores.
La figura 3-7 ilustra cmo interactan los siguientes procesos centrales y facilitadores:
Control Integrado de Cambios (4.3) coordinacin de los cambios a lo largo de todo el
proyecto.
Verificacin del Alcance (5.4) formalizacin de la aceptacin del alcance del proyecto.
Control de Cambios del Alcance (5.5) control de los cambios al alcance del proyecto.
Control del Cronograma (6.5) control de los cambios al cronograma del proyecto.
Control de Costos (7.4) control de los cambios al presupuesto del proyecto.
Control de Calidad (8.3) supervisin de los resultados especficos del proyecto para
determinar si cumplen con los estndares relevantes e identificacin de modos de eliminar
las causas del desempeo insatisfactorio.
Informes de Rendimiento (10.3) recoleccin y distribucin de la informacin del
rendimiento. Esto incluye el informe del estado, la medicin del avance y el pronstico al
finalizar el proyecto.
Supervisin y Control de Riesgos (11.6) realizacin del seguimiento de los riesgos identificados, supervisin de los riesgos residuales e identificacin de nuevos riesgos, aseguramiento de la ejecucin de los planes de respuesta a los riesgos y evaluacin de su eficacia
en la reduccin de los riesgos.
36
Figura 38. Relaciones entre los Procesos de Cierre
3.3.5
Procesos de Cierre
La figura 3-8 ilustra cmo interactan los siguientes procesos centrales:
Cierre del Contrato (12.6) finalizacin y cierre del contrato, incluyendo la resolucin de
todos los puntos abiertos.
Cierre Administrativo (10.4) generacin, recoleccin y distribucin de la informacin
para formalizar la conclusin de la fase o del proyecto, incluyendo la evaluacin del
proyecto y la recopilacin de las lecciones aprendidas para su uso en la planificacin de
futuros proyectos o fases.
3.4 ADAPTACIN DE LAS INTERACCIONES ENTRE PROCESOS

Los procesos y las interacciones de la Seccin 3.3 verifican la prueba de aceptacin general
ellos se aplican a la mayora de los proyectos la mayor parte de las veces. Sin embargo, no
todos los procesos son necesarios en todos los proyectos y no todas las interacciones se
aplican a todos los proyectos. Por ejemplo:
Una organizacin que usa contratistas en forma intensiva puede describir en el plan del
proyecto y en forma explcita dnde se produce cada proceso de adquisicin.
La ausencia de un proceso no implica que el mismo no debera ser ejecutado. El equipo de
direccin del proyecto debera identificar y dirigir todos los procesos que son necesarios
para asegurar un proyecto exitoso.
En los proyectos que dependen de recursos nicos (desarrollo de software profesional, productos biofarmacuticos, etc.), pueden establecerse roles y responsabilidades antes de la
definicin del alcance, puesto que aquello que es factible hacer puede ser funcin de quin
est disponible para hacerlo.
Algunas salidas de procesos pueden definirse anticipadamente como restricciones. Por
ejemplo, la gerencia puede establecer como meta una determinada fecha de finalizacin
y no adoptar la que surja del proceso de planificacin. Una fecha de finalizacin impuesta
puede incrementar el riesgo del proyecto, agregar costos y comprometer la calidad.
Los proyectos ms grandes pueden requerir relativamente mayor detalle. Por ejemplo, la
identificacin del riesgo puede subdividirse adicionalmente para focalizar separadamente
la identificacin de riesgos en costos, riesgos en cronograma, riesgos tcnicos y los riesgos
de calidad.
En subproyectos y proyectos ms pequeos se dedicar relativamente poco esfuerzo a
aquellos procesos cuyas salidas han sido definidas a nivel del proyecto (por ejemplo, un
subcontratista puede ignorar explcitamente los riesgos, pues stos son asumidos por el
contratista principal) o a aquellos procesos que slo proporcionan beneficios marginales
(por ejemplo, podra no haber un plan de comunicaciones formal en un proyecto integrado
por slo cuatro personas).
37
Figura 39 | Seccin II
Figura 39.
Clasificacin de los Procesos de Direccin de Proyectos segn los Grupos de Procesos y las
reas de Conocimiento
3.5 ORGANIZACIN DE LOS PROCESOS DE DIRECCIN DEL

PROYECTO
La figura 3-9 muestra la organizacin de los treinta y nueve procesos de gestin del proyecto,
dentro de los cinco grupos de procesos de direccin del proyecto: iniciacin, planificacin, ejecucin, control y cierre y a las nueve reas de conocimiento en los captulos 4 a 12.
Este diagrama no pretende ser exclusivo pero s indicar, de modo general, dnde se ubican
los procesos de direccin del proyecto, tanto en los grupos de procesos de gestin del
proyecto como en las reas de conocimiento de la direccin del proyecto.
38
SECCIN II
reas de Conocimiento de la Direccin de Proyectos
4. Gestin de la Integracin del Proyecto

5. Gestin del Alcance del Proyecto
6. Gestin de Tiempos del Proyecto
7. Gestin de Costos del Proyecto
8. Gestin de la Calidad del Proyecto
9. Gestin de los Recursos Humanos del Proyecto
10. Gestin de las Comunicaciones del Proyecto
11. Gestin de Riesgos del Proyecto
12. Gestin de las Adquisiciones del Proyecto
Captulo 4
Gestin de la Integracin del

Proyecto
La gestin de la integracin del proyecto incluye los procesos requeridos para asegurar que los
diferentes elementos del proyecto sean adecuadamente coordinados. Implica compensar entre
los objetivos y las alternativas que compiten entre s con el fin de alcanzar o exceder las necesidades y expectativas de los interesados en el proyecto. Mientras todos los procesos de la direccin de proyectos son de alguna manera integradores, los procesos descritos en este captulo
son primariamente integradores. La figura 4-1 proporciona una visin general de los
siguientes procesos principales:
4.1 Desarrollo del Plan del Proyecto integracin y coordinacin de todos los planes del
proyecto para crear un documento consistente y coherente.
4.2 Ejecucin del Plan del Proyecto realizacin del plan del proyecto llevando a cabo las
actividades.
4.3 Control Integrado de Cambios coordinacin de los cambios a lo largo de todo el
proyecto.
Estos procesos interactan recprocamente y con los procesos en las otras reas de
conocimiento. Cada proceso puede implicar el esfuerzo de uno o ms individuos o grupos
de individuos, segn las necesidades del proyecto. Cada proceso ocurre generalmente por lo
menos una vez en cada fase del proyecto.
Aunque los procesos se presentan aqu como elementos discretos con interfaces bien
definidas, en la prctica pueden solaparse y actuar entre s de maneras no detalladas aqu. Las
interacciones entre procesos son tratadas en detalle en el captulo 3.
Los procesos, herramientas y tcnicas usadas para integrar los procesos de la direccin de
proyectos constituyen el foco de este captulo. Por ejemplo, la gestin de la integracin del
proyecto entra en escena cuando se necesita una estimacin de costos para un plan de contingencia o cuando deben identificarse los riesgos asociados con varias alternativas para
proveer personal. Sin embargo, para que un proyecto sea completado exitosamente, la integracin debe ocurrir tambin en varias otras reas. Por ejemplo:
El trabajo del proyecto debe integrarse con las operaciones diarias de la organizacin ejecutante.
Deben integrarse el alcance del producto y el alcance del proyecto (la diferencia entre el
alcance del producto y el alcance del proyecto se trata en la introduccin al captulo 5).
Una de las tcnicas usadas, tanto para integrar los diferentes procesos como para medir el
rendimiento del proyecto a medida que se avanza desde el inicio a la finalizacin, es la Gestin
del Valor del Trabajo Realizado (EVM). La EVM ser tratada en este captulo como una
Una Gua a los Fundamentos de la Direccin de Proyectos (PMBOK Guide) 2000 ed.
41
Figura 41 | 4.1.1.5
Captulo 4 Gestin de la Integracin del Proyecto
Figura 41. Visin General de la Gestin de la Integracin del Proyecto
metodologa de integracin del proyecto, mientras que la tcnica del valor del trabajo realizado
(EV) ser tratada en otros captulos como una herramienta para evaluar el rendimiento contra
el plan del proyecto.
El software de gestin de proyectos es una herramienta que ayuda a la integracin dentro
de un proyecto. Y se puede extender a todos los procesos de la direccin de proyectos.
4.1 DESARROLLO DEL PLAN DEL PROYECTO

El desarrollo del plan del proyecto usa las salidas de los otros procesos de planificacin,
incluyendo la planificacin estratgica, para crear un documento consistente y coherente que
puede usarse para guiar tanto la ejecucin como el control del proyecto. Este proceso casi
siempre se itera varias veces. Por ejemplo, el borrador inicial puede incluir requerimientos de
recursos genricos y una sucesin de actividades sin fecha, mientras las versiones subsiguientes
del plan incluirn recursos especficos y fechas explcitas. El alcance del trabajo del proyecto
es un proceso iterativo generalmente hecho por el equipo del proyecto utilizando una Estructura Detallada del Trabajo (WBS), que permite al equipo capturar y luego descomponer todo
el trabajo del proyecto. Todo el trabajo definido debe ser planeado, estimado, programado y
autorizado con el uso de planes detallados de control de la gestin integrada, a veces llamados
Planes de Cuentas de Control en el proceso EVM. La suma de todos los planes de control de
la gestin integrada constituir el alcance total del proyecto.
42
El plan del proyecto es usado para:

Guiar la ejecucin del proyecto.
Documentar las hiptesis de la planificacin del proyecto.
Documentar las decisiones de la planificacin del proyecto con respecto a las alternativas
escogidas.
Facilitar la comunicacin entre los interesados.
Definir las revisiones clave de la gestin en cuanto al contenido, magnitud y oportunidad.
Proporcionar un plan de referencia para la medicin del progreso y el control del proyecto.
4.1.1
.1
.2
.3
.4
.5
Entradas al Desarrollo del Plan del Proyecto

Otras salidas de la planificacin. Todas las salidas de los procesos de planificacin en las otras
reas de conocimiento (la Seccin 3.3 proporciona un resumen de estos procesos de planificacin del proyecto) son entradas para desarrollar el plan del proyecto. Otras salidas de la
planificacin incluyen documentos de base, tales como la WBS, y los detalles de respaldo.
Muchos proyectos tambin requerirn entradas especficas del rea de aplicacin (por ejemplo,
la mayora de los proyectos ms importantes requerirn una previsin de flujo de fondos).
Informacin histrica. La informacin histrica disponible (por ejemplo, bases de datos de estimaciones, registros de rendimiento de proyectos anteriores) debera haber sido consultada
durante los otros procesos de planificacin del proyecto. Esta informacin tambin debe estar
disponible durante el desarrollo del plan del proyecto para ayudar a verificar hiptesis y a
evaluar alternativas que son identificadas como parte de este proceso.
Polticas de la organizacin. Alguna o todas las organizaciones involucradas en el proyecto
pueden tener polticas formales e informales cuyos efectos deben ser considerados. Las
polticas de la organizacin que tpicamente deben ser consideradas incluyen, pero no se limitan a:
La gestin de calidadauditora de procesos, objetivos de mejora continua.
Gestin del personalguas para la incorporacin y desafectacin del personal, revisiones
del rendimiento de los empleados.
Control financieroinformes de tiempo, revisiones de los requerimientos y reintegros de
gastos, cdigos contables, contratos estndar de aprovisionamiento.
Restricciones. Una restriccin es una limitacin aplicable que afectar el rendimiento del
proyecto. Por ejemplo, un presupuesto predefinido es una restriccin que muy probablemente
limitar las opciones del equipo con respecto al alcance, cantidad de personal y cronograma.
Cuando un proyecto es realizado bajo un contrato, las clusulas contractuales generalmente
sern una restriccin.
Hiptesis. Las hiptesis son factores que, para los propsitos de la planificacin, se consideran
como verdaderos, reales o ciertos. Las hiptesis afectan todos los aspectos de la planificacin
del proyecto y son parte de la elaboracin progresiva del proyecto. Los equipos del proyecto
frecuentemente identifican, documentan y validan las hiptesis como parte de su proceso de
43
4.1.2 | 4.1.3.2
planificacin. Por ejemplo, si la fecha en que una persona clave estar disponible es incierta,
el equipo puede asumir una fecha especfica de inicio. Las hiptesis generalmente involucran
un grado de riesgo.
4.1.2
.1
.2
.3
.4
4.1.3
.1
44
Tcnicas y Herramientas para el Desarrollo del Plan del Proyecto

Metodologa de planificacin del proyecto. Una metodologa de planificacin del proyecto es
cualquier enfoque estructurado usado para guiar al equipo del proyecto durante el desarrollo
del plan del proyecto. Puede ser tan simple como formularios y plantillas estndar (en papel
o electrnicas, formales o informales) o tan complejo como una serie de simulaciones
requeridas (por ejemplo, anlisis Monte Carlo del riesgo del cronograma). La mayora de las
metodologas de planificacin de proyectos hace uso de una combinacin de herramientas
duras, como software de direccin de proyectos, y herramientas blandas, como reuniones
de inicio.
Conocimiento y habilidades de los interesados. Cada interesado tiene habilidades y
conocimientos que pueden ser tiles en el desarrollo del plan del proyecto. El equipo de direccin del proyecto debe crear un ambiente en el que los interesados puedan contribuir apropiadamente (vase tambin la seccin 9.3, Desarrollo del equipo). Variarn quines contribuyan,
con qu contribuyen y cundo contribuyen. Por ejemplo:
En un proyecto de construccin que se est haciendo bajo un contrato de precio fijo, el
ingeniero profesional de costos har una importante contribucin al objetivo de rentabilidad durante la preparacin de la propuesta cuando se est determinando el monto del contrato.
En un proyecto donde el personal se est definiendo de antemano, los contribuyentes individuales pueden ayudar significativamente a lograr los objetivos de costo y cronograma
revisando la racionalidad de la duracin y el esfuerzo estimados.
Sistema de informacin de direccin de proyectos (PMIS). Un PMIS consta de las Tcnicas y
Herramientas usadas para recoger, integrar y distribuir las salidas de los procesos de gestin
del proyecto. Se usa para apoyar todos los aspectos del proyecto desde el comienzo hasta el
cierre y puede incluir tanto sistemas manuales como automatizados.
Gestin del valor del trabajo realizado (EVM). Una tcnica usada para integrar el alcance, el
cronograma y los recursos del proyecto y para medir e informar del rendimiento del proyecto
desde el comienzo al cierre. Ms comentarios sobre EVM pueden encontrarse en la seccin
7.4.2.3.
Salidas del Desarrollo del Plan del Proyecto

Plan del proyecto. El plan del proyecto es un documento formal y aprobado que se utiliza para
administrar la ejecucin del proyecto. El cronograma del proyecto lista las fechas planeadas
para realizar las actividades y alcanzar los hitos identificados en el plan del proyecto (vase
la seccin 6.4.3.1). El plan y el cronograma del proyecto deberan distribuirse como se defini
en el plan de gestin de las comunicaciones (por ejemplo, la direccin de la organizacin ejecutante puede requerir una amplia cobertura con poco detalle, mientras que un contratista
puede requerir detalles completos en un solo asunto). En algunas reas de aplicacin, el trmino plan integrado de proyecto se usa para referirse a este documento.
Debe hacerse una clara distincin entre el plan del proyecto y los planes de referencia de
medicin del rendimiento. El plan del proyecto es un documento o coleccin de documentos
que debera esperarse que cambie con el tiempo a medida que se disponga de ms informacin sobre el proyecto. Los planes de referencia de medicin del rendimiento normalmente
cambiarn slo intermitentemente, y generalmente slo en respuesta a un cambio aprobado
del alcance del trabajo o de un entregable.
.2
Hay muchas maneras de organizar y presentar el plan del proyecto, pero normalmente
incluye por lo menos los siguientes puntos (que se describen con ms detalle en otras partes
de este documento):
Acta del proyecto.
Una descripcin del enfoque o estrategia de direccin del proyecto (un resumen de los
planes de gestin individuales de las otras reas de conocimiento).
Descripcin del alcance, que incluye los objetivos del proyecto y los entregables del
proyecto.
WBS al nivel al que ser ejercido el control, como un documento del alcance de los planes
de referencia.
Estimaciones de costos, fechas de inicio y finalizacin del cronograma y asignaciones de
responsabilidad para cada entregable dentro de la WBS al nivel al que se ejercer el control.
Planes de referencia de medicin del rendimiento para el alcance tcnico, el cronograma y
el costo por ejemplo, el plan de referencia del cronograma (cronograma del proyecto)
y el plan de referencia del costo (presupuesto del proyecto por fase).
Hitos ms importantes y las fechas objetivo para cada uno.
Personal clave o requerido y su costo y/o esfuerzo esperado.
Plan de gestin del riesgo, incluyendo: los riesgos clave, con sus restricciones e hiptesis,
y respuestas y contingencias planeadas (donde sea apropiado) para cada uno.
Planes de gestin complementarios, a saber:
Plan de gestin del alcance (seccin 5.2.3.3).
Plan de gestin del cronograma (seccin 6.4.3.3).
Plan de gestin de costos (seccin 7.2.3.3).
Plan de gestin de la calidad (seccin 8.1.3.1).
Plan de gestin del personal (seccin 9.1.3.2).
Plan de gestin de las comunicaciones (seccin 10.1.3.1).
Plan de respuesta a riesgos (seccin 11.5.3.1).
Plan de la gestin de las adquisiciones (seccin 12.1.3.1).
Cada uno de estos planes podra ser incluido, si fuera necesario, con el detalle
requerido por cada proyecto especfico.
Temas en tratamiento y decisiones pendientes.
De acuerdo con las necesidades particulares de cada proyecto deben incluirse, en el plan
formal, otras salidas de la planificacin del mismo. Por ejemplo, el plan para un proyecto
grande generalmente incluir un organigrama de ste.
Detalle de respaldo. El detalle de respaldo para el plan del proyecto incluye:
Salidas de otros procesos de planificacin que no estn incluidos en el plan del proyecto.
Informacin adicional o documentacin generada durante el desarrollo del plan del
proyecto (por ejemplo, restricciones e hiptesis que no fueron conocidas previamente).
Documentos tcnicos, tales como un historial de todos los requerimientos, especificaciones,
y diseos conceptuales.
Documentacin de estndares relevantes.
Especificaciones de la planificacin temprana del desarrollo del proyecto.
Este material debera organizarse como fuere necesario para facilitar su uso durante la ejecucin del plan del proyecto.
45
4.2 | 4.3
4.2 EJECUCIN DEL PLAN DEL PROYECTO

La ejecucin de plan de proyecto es el proceso primario para llevar a cabo el plan del proyecto
la mayor parte del presupuesto del proyecto se gastar realizando este proceso. En este proceso, el director del proyecto y el equipo de direccin del proyecto deben coordinar y dirigir
las distintas interfaces tcnicas y organizativas que existen en el proyecto. Es el proceso del
proyecto que est ms directamente afectado por el rea de aplicacin en la cual realmente se
crea el producto del proyecto. Debe supervisarse continuamente el rendimiento contra los
planes de referencia del proyecto para que puedan tomarse acciones correctivas basadas en el
rendimiento real contra el plan del proyecto. Para apoyar el anlisis, se harn previsiones peridicas de los resultados finales del costo y del cronograma.
4.2.1
.1
.2
.3
.4
.5
4.2.2
.1
.2
46
Entradas a la Ejecucin del Plan del Proyecto

Plan del proyecto. El plan del proyecto se describe en la seccin 4.1.3.1. Los planes complementarios de gestin (plan de gestin del alcance, plan de gestin del riesgo, plan de gestin
de las adquisiciones, plan de gestin de la configuracin, etc.) y los planes de referencia de
medicin del rendimiento son entradas importantes para la ejecucin del plan del proyecto.
Detalle de respaldo. Los detalles de respaldo se describen en la seccin 4.1.3.2.
Polticas de la organizacin. Las polticas de la organizacin se describen en la seccin 4.1.1.3.
Alguna o todas las organizaciones involucradas en el proyecto pueden tener polticas formales
e informales que pueden afectar la ejecucin del plan del proyecto.
Accin preventiva. Una accin preventiva es algo que reduce la probabilidad de consecuencias potenciales de eventos de riesgo del proyecto.
Accin correctiva. Una accin correctiva es algo que se hace para llevar el rendimiento futuro
esperado en armona con el plan del proyecto. La accin correctiva es una salida de diferentes
procesos de control como entrada aqu, completa el ciclo de realimentacin necesario para
asegurar una administracin eficaz del proyecto.
Tcnicas y Herramientas para la Ejecucin del Plan del Proyecto

Habilidades de gestin en general. Las habilidades de gestin en general, como liderazgo,
comunicacin y negociacin, son esenciales para la ejecucin eficaz del plan del proyecto. Las
habilidades de gestin en general se describen en la seccin 2.4.
Conocimiento y habilidades sobre el producto. El equipo del proyecto debe tener acceso a un
conjunto apropiado de habilidades y conocimiento sobre el producto del proyecto. Las habilidades necesarias se definen como parte de la planificacin (especialmente en la planificacin
de recursos, seccin 7.1) y son suministradas a travs del proceso de contratacin del personal
(descrito en la seccin 9.2).
.3
.4
.5
.6
4.2.3
.1
.2
Sistema de autorizacin del trabajo. Un sistema de autorizacin del trabajo es un procedimiento formal para aprobar el trabajo del proyecto, para asegurar que el trabajo se haga en
el momento correcto y en la secuencia adecuada. El mecanismo primario es tpicamente una
autorizacin escrita para empezar el trabajo en una actividad especfica o paquete de trabajo.
El diseo de un sistema de autorizacin del trabajo debe equilibrar el valor del control con
el costo de ese control. Por ejemplo, en muchos proyectos menores las autorizaciones verbales
resultan adecuadas.
Reuniones de revisin de estado. Las reuniones de revisin de estado son reuniones establecidas regularmente para intercambiar informacin sobre el proyecto. En la mayora de los
proyectos, las reuniones de revisin de estado se celebrarn con diversa frecuencia y en
niveles diferentes (por ejemplo, el equipo de direccin del proyecto puede encontrarse semanalmente por s mismo y mensualmente con el cliente).
Sistema de informacin de direccin del proyecto. El PMIS se describe en la seccin 4.1.2.3.
Procedimientos de la organizacin. Alguna o todas las organizaciones involucradas en el
proyecto pueden tener procedimientos formales e informales que son tiles durante la ejecucin del proyecto.
Salidas de la Ejecucin del Plan del Proyecto

Resultados del trabajo. Los resultados del trabajo son los productos de las actividades realizadas para llevar a cabo el proyecto. La informacin sobre los resultados del trabajo cules
entregables se han completado y cules no, hasta qu punto se estn cumpliendo las normas
de calidad, en qu costos se ha incurrido o qu costos se han comprometido, etc. se
recopila como parte de la ejecucin del plan del proyecto y alimenta los procesos de informes
de rendimiento (vase la seccin 10.3 para un tratamiento ms detallado de informes de
rendimiento). Debe notarse que, aunque los resultados son entregables frecuentemente tangibles como edificios, caminos, etc., tambin son a menudo intangibles tales como personas
capacitadas que pueden efectivamente aplicar esa capacitacin.
Requerimientos de cambio. Los requerimientos de cambio (por ejemplo, para extender o
acortar el alcance del proyecto, para modificar el costo [presupuestos] o las estimaciones del
cronograma [fechas, etc.]) son identificados a menudo mientras el trabajo del proyecto est
siendo realizado.
4.3 CONTROL INTEGRADO DE CAMBIOS

El control integrado de cambios est relacionado con a) influenciar en los factores que crean
cambios para asegurar que los cambios estn acordados, b) determinar que un cambio ha
ocurrido, y c) gestionar los cambios reales cuando y a medida que ocurren. El alcance del
proyecto definido originalmente y los planes de referencia integrados del rendimiento deben
ser mantenidos por medio de una gestin continua de cambios de los planes de referencia, ya
sea rechazando nuevos cambios o bien aprobando cambios e incorporndolos a un plan de
referencia revisado del proyecto. El control de cambios integrado requiere:
Mantener la integridad de los planes de referencia de medicin del rendimiento.
Asegurar que los cambios al alcance del producto se reflejan en la definicin del alcance
del proyecto. La diferencia entre alcance del producto y alcance del proyecto se trata en la
introduccin al captulo 5.
Coordinar los cambios a travs de las reas de conocimiento, como se ilustra en la figura
4-2. Por ejemplo, un cambio propuesto al cronograma afectar a menudo costos, riesgos,
calidad y cantidad de personal.
47
4.3.1 | 4.3.3.3
Figura 42. Coordinacin de Cambios a Travs de Todo el Proyecto
4.3.1
.1
.2
.3
4.3.2
.1
48
Entradas al Control Integrado de Cambios

Plan del proyecto. El plan del proyecto proporciona el plan de referencia contra el cual se
controlarn los cambios (vase la seccin 4.1.3.1).
Informes de rendimiento. Los informes de rendimiento (descritos en la seccin 10.3) proporcionan informacin sobre el rendimiento del proyecto. Los informes de rendimiento tambin
pueden alertar al equipo del proyecto sobre temas que pueden causar problemas en el futuro.
Requerimientos de cambio. Los requerimientos de cambio pueden ocurrir en muchas formas
orales o escritos, directos o indirectos, iniciados externamente o internamente y de
obligacin legal u optativos.
Tcnicas y Herramientas para el Control Integrado de Cambios

Sistema de control de cambios. Un sistema de control de cambios es una coleccin de procedimientos formales documentados que define cmo ser supervisado y evaluado el
rendimiento del proyecto e incluye los pasos mediante los cuales pueden cambiarse documentos oficiales del proyecto. Incluye los documentos, los sistemas de seguimiento, los procesos y los niveles de aprobacin necesarios para autorizar los cambios.
.2
.3
.4
.5
4.3.3
.1
.2
.3
En muchos casos, la organizacin ejecutante tendr un sistema de control de cambios que

puede ser adoptado como est para su uso en el proyecto. Sin embargo, si no hay disponible
un sistema apropiado, el equipo de direccin del proyecto necesitar desarrollar uno como
parte del proyecto.
Muchos sistemas de control de cambios incluyen un grupo responsable de aprobar o rechazar los cambios propuestos. Los roles y responsabilidades de estos grupos estn claramente
definidos dentro del sistema de control de cambios y son acordados por todas los principales
interesados en el proyecto. Las organizaciones se diferencian por la denominacin del comit;
sin embargo, algunas denominaciones comunes son Comit de Control de la Configuracin
(CCB), Comit de Revisin de Ingeniera (ERB), Comit de Revisin Tcnica (TRB), Comit de
Evaluacin Tcnica (TAB) y otras. El sistema de control de cambios tambin debe incluir procedimientos para manejar cambios que pueden aprobarse sin una revisin previa, por ejemplo,
como resultado de emergencias. Tpicamente, un sistema de control de cambios permitir la
aprobacin automtica de categoras definidas de cambios. Estos cambios deben tambin
documentarse y deben registrarse para que se pueda documentar la evolucin del plan de referencia.
Gestin de la configuracin. La gestin de la configuracin es cualquier procedimiento documentado que se utiliza para emplear direccin tcnica y administrativa y vigilancia, a fin de:
Identificar y documentar las caractersticas funcionales y fsicas de un elemento o sistema.
Controlar cualquier cambio a dichas caractersticas.
Registrar e informar el cambio y su estado de implantacin.
Auditar los elementos y sistemas para verificar conformidad con los requisitos.
En muchas reas de aplicacin, la gestin de la configuracin es un subconjunto del sistema de control de cambios y se usa para asegurar que la descripcin del producto del
proyecto sea correcta y completa. En otras reas de aplicacin, el control de cambios se refiere
a cualquier esfuerzo sistemtico para gestionar cambios del proyecto.
Medicin del rendimiento. Las tcnicas de medicin del rendimiento tales como EV (descrito
en la seccin 10.3.2.4) ayudan a evaluar si las variaciones del plan requieren acciones correctivas.
Planificacin adicional. Los proyectos raramente avanzan exactamente segn el plan. Los
potenciales cambios pueden requerir nuevas estimaciones de costos o revisiones de las existentes, modificaciones de la secuencia de actividades, de los cronogramas, de los requerimientos
de recursos, de los anlisis de alternativas de respuesta al riesgo u otros ajustes al plan del
proyecto.
Sistema integrado de direccin del proyecto. El PMIS se describe en la Seccin 4.1.2.3.
Salidas del Control Integrado de Cambios

Actualizaciones al plan del proyecto. Una actualizacin al plan del proyecto es cualquier modificacin a los contenidos del plan del proyecto o al detalle de respaldo (descritos en las secciones 4.1.3.1 y 4.1.3.2 respectivamente). Se debe notificar al interesado apropiado cuando sea
necesario.
Accin correctiva. La accin correctiva se describe en la seccin 4.2.1.5.
Lecciones aprendidas. Las causas de variaciones, el razonamiento detrs de la accin correctiva escogida y otros tipos de lecciones aprendidas deben documentarse para que se vuelvan
parte de la base de datos histrica para este proyecto y otros proyectos de la organizacin ejecutante. Esta base de datos es tambin la base para una administracin del conocimiento.
49
Captulo 5
Gestin del Alcance del

Proyecto
La gestin del alcance del proyecto comprende los procesos requeridos para asegurar que el
proyecto incluya todo el trabajo necesario, y solamente el trabajo necesario, para completar el
proyecto con xito (1). Est relacionada principalmente con la definicin y control de lo que
est o no est incluido en el proyecto. La figura 5-1 proporciona una visin general de los
siguientes procesos principales de la gestin del alcance del proyecto:
5.1 Iniciacin autorizacin del proyecto o fase.
5.2 Planificacin del Alcance desarrollo de un enunciado escrito del alcance como la
base para futuras decisiones del proyecto.
5.3 Definicin del Alcance subdivisin de los principales entregables del proyecto en
componentes ms pequeos y manejables.
5.4 Verificacin del Alcance formalizacin de la aceptacin del alcance del proyecto.
5.5 Control de Cambios del Alcance control de los cambios al alcance del proyecto.
En el contexto del proyecto, la palabra alcance puede referirse a lo siguiente:
Alcance del producto las caractersticas y funciones que caracterizan un producto o servicio.
Alcance del proyecto el trabajo que debe realizarse para entregar un producto con las
caractersticas y funciones especificadas.
Los procesos, herramientas y tcnicas empleados para gestionar el alcance del proyecto son
el foco de este captulo. Los procesos, herramientas y tcnicas empleados para dirigir el alcance
del producto varan de acuerdo con el rea de aplicacin y son usualmente definidos como
parte del ciclo de vida del proyecto (el ciclo de vida del proyecto se trata en la seccin 2.1).
Generalmente, un proyecto entrega como resultado un nico producto, pero ese producto
puede tener componentes secundarios, cada uno de ellos con su propio alcance de producto,
separado pero interdependiente. Por ejemplo, un nuevo sistema telefnico generalmente
incluir cuatro componentes secundarios: hardware, software, capacitacin e implementacin.
El cumplimiento del alcance del proyecto se verifica comparndolo con el plan del
proyecto, mientras que el del alcance del producto se verifica comparndolo con los requerimientos del mismo. Ambos tipos de gestin de alcance deben estar perfectamente integrados
para asegurar que el trabajo del proyecto dar como resultado la entrega del producto especificado.
2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
EUA
51
Figura 51 | 5.1.1.1|
Captulo 5 Gestin del Alcance del Proyecto
Figura 51. Visin General de la Gestin del Alcance del Proyecto
52
5.1 INICIACIN
Iniciacin es el proceso de autorizar formalmente un nuevo proyecto o la continuacin de un
proyecto existente a su siguiente fase (vase seccin 2.1 para una descripcin ms detallada
de las fases del proyecto). Este comienzo formal conecta el proyecto con los trabajos en curso
de la organizacin ejecutora. En algunas organizaciones, un proyecto no se inicia formalmente
hasta no haber completado una evaluacin de necesidades, una estimacin de factibilidad, un
plan preliminar o alguna otra forma equivalente de anlisis que, como tal, ha sido comenzada
separadamente. Algunos tipos de proyectos, especialmente los de servicio interno y los de
desarrollo de nuevos productos, se inician informalmente y de manera acotada y se realiza
cierta cantidad limitada de trabajo para garantizar las aprobaciones necesarias para el inicio
formal del proyecto. Generalmente, los proyectos son autorizados como resultado de una o
ms de las siguientes causas:
Una demanda del mercado (por ejemplo, una compaa automotriz autoriza un proyecto
para construir automviles ms eficientes en respuesta a la escasez de gasolina).
Una necesidad de negocio (por ejemplo, una compaa de educacin autoriza un proyecto
para crear un nuevo curso para aumentar sus ingresos).
Requerimiento del cliente (por ejemplo, una planta elctrica autoriza un proyecto para
construir una nueva subestacin para abastecer un nuevo parque industrial).
Un avance tecnolgico (por ejemplo, una empresa electrnica, despus de haberse registrado avances en memorias de computadora, autoriza un nuevo proyecto para desarrollar
una consola de vdeo-juego).
Una necesidad legal (por ejemplo, un fabricante de pinturas autoriza un proyecto para
establecer los procedimientos del manejo de materiales txicos).
Una necesidad social (por ejemplo, una organizacin no gubernamental en un pas en
desarrollo autoriza un proyecto para proveer sistemas de agua potable, letrinas y educacin
sanitaria para comunidades de bajos ingresos que sufren de altos ndices de clera).
Esos estmulos pueden tambin llamarse problemas, oportunidades o requerimientos de
negocio. Lo fundamental de todos estos trminos es que la direccin empresaria suele tener
que tomar una decisin sobre cmo responder.
5.1.1
.1
Entradas para la Iniciacin

Descripcin del producto. La descripcin del producto documenta las caractersticas del producto o servicio que el proyecto debe crear. Generalmente, la descripcin del producto se
realizar con menor detalle en las fases iniciales y con ms detalle en las siguientes, segn se
van elaborando progresivamente las caractersticas del mismo.
La descripcin del producto tambin debera documentar la relacin entre el producto o
servicio que se est creando y las necesidades del negocio u otros incentivos que dieron relevancia al proyecto (vase la lista en la seccin 5.1). Aunque la forma y el contenido de la
descripcin del producto pueden variar, deberan ser siempre lo suficientemente detallados
para respaldar la posterior planificacin del proyecto.
53
5.1.1.2 | 5.2.1.4
.2
.3
.4
5.1.2
.1
.2
5.1.3
.1
54
Muchos proyectos incluyen una organizacin (la vendedora) que realiza un trabajo bajo
contrato para otra (la compradora). En tales circunstancias, la descripcin inicial del producto
la provee normalmente el comprador.
Plan estratgico. Todos los proyectos deberan sustentar los objetivos estratgicos de la organizacin ejecutora el plan estratgico de la organizacin ejecutora debera considerarse
como un factor a tener en cuenta en las decisiones de seleccin del proyecto.
Criterios de seleccin de proyectos. Los criterios de seleccin de proyectos se definen
habitualmente en trminos de los mritos del producto del proyecto y pueden abarcar todo el
rango de preocupaciones posibles de la direccin (retorno financiero, participacin en el mercado, percepciones pblicas, etc.).
Informacin histrica. Si se dispone de informacin histrica acerca de los resultados de las
decisiones tomadas en anteriores selecciones de proyectos y del rendimiento de esos
proyectos, sta debe analizarse hasta donde sea posible. Cuando la iniciacin implica la
aprobacin para llevar a cabo la siguiente fase de un proyecto, la informacin sobre los resultados de las fases previas suele ser crtica.
Tcnicas y Herramientas para la Iniciacin

Mtodos de seleccin de proyectos. Los mtodos de seleccin de proyectos comprenden la
medicin del valor o de lo atractivo para el dueo del proyecto. Los mtodos de seleccin de
proyectos incluyen la evaluacin de los criterios de decisin (si se utilizan criterios mltiples,
deberan combinarse en una funcin de valor nico) y los medios de clculo del valor en
incertidumbre. stos se conocen como modelo de decisin y mtodo de clculo. La seleccin
de proyectos tambin se ocupa de la eleccin de modos alternativos de realizar el proyecto.
Pueden utilizarse herramientas de optimizacin para buscar la combinacin ptima de las
variables de decisin. Generalmente, los mtodos de seleccin de proyectos pertenecen a una
de estas dos grandes categoras (2):
Mtodos de medicin del beneficio procedimientos comparativos, modelos de calificacin, contribucin al beneficio del negocio o modelos econmicos.
Mtodos de optimizacin condicionada modelos matemticos que utilizan algoritmos de
programacin lineal, no lineal, dinmica, integral y de mltiples objetivos.
Estos mtodos se suelen denominar modelos de decisin. Los modelos de decisin
incluyen tcnicas generalizadas (rboles de decisin, elecciones forzadas y otras) as como
otras ms especializadas (procesos de anlisis jerrquico AHP , anlisis de la estructura lgica y otros). La aplicacin de criterios complejos de seleccin de proyectos
mediante modelos sofisticados se trata frecuentemente como una fase separada del
proyecto.
Juicio de expertos. El juicio de expertos se requerir frecuentemente para evaluar el ingreso
de datos a este proceso. Este conocimiento especializado puede proporcionarlo cualquier persona o grupo de personas con experiencia o entrenamiento especfico en la materia y se puede
obtener de varias fuentes, incluyendo:
Otras unidades pertenecientes a la organizacin ejecutante.
Consultores.
Interesados en el proyecto, incluyendo clientes.
Asociaciones profesionales y tcnicas.
Grupos industriales.
Salidas de la Iniciacin
Acta del proyecto. El acta del proyecto es un documento que autoriza formalmente un
proyecto. sta debera incluir, en forma directa o bien por referencia a otros documentos:
La necesidad de negocio que debe ser satisfecha por el proyecto.
La descripcin del producto (descrita en la seccin 5.1.1.1).
El acta del proyecto debera ser emitida por un director no directamente involucrado en
el proyecto y a un nivel adecuado a las necesidades del proyecto. sta otorga al director del
.2
.3
.4
proyecto la autoridad para asignar los recursos de la organizacin a las actividades del proyecto.
Cuando un proyecto se realiza bajo contrato, el contrato firmado servir generalmente al
proveedor como acta del proyecto.
Director del proyecto identificado/asignado. En general, el director del proyecto debe ser identificado y asignado al proyecto tan pronto como sea posible. El director del proyecto debe ser
asignado siempre antes del comienzo de la ejecucin del plan del proyecto (descrito en la seccin 4.2) y preferentemente antes de que se haya avanzado mucho en la planificacin del
proyecto (los procesos de planificacin del proyecto se describen en la seccin 3.3.2).
Restricciones. Las restricciones son factores que limitarn las opciones del equipo de direccin
del proyecto. Por ejemplo, un presupuesto predefinido es una restriccin que muy probablemente limite las opciones del equipo del proyecto en cuanto a su alcance, asignacin de personal y cronograma.
Cuando un proyecto se realiza bajo contrato, generalmente las disposiciones contractuales
actuarn como restricciones. Otro ejemplo es un requerimiento de que el producto del
proyecto sea social, econmica y ambientalmente sustentable, lo cual tendr tambin efecto
sobre el alcance, la asignacin del personal y el cronograma del proyecto.
Hiptesis. Vase la seccin 4.1.1.5.
5.2 PLANIFICACIN DEL ALCANCE

La planificacin del alcance es el proceso progresivo de elaborar y documentar el trabajo del
proyecto (alcance del proyecto), que crea el producto del proyecto. La planificacin del
alcance del proyecto comienza con las entradas iniciales de la descripcin del producto, el acta
del proyecto y la definicin inicial de restricciones e hiptesis. Ntese que la descripcin del
producto incorpora requerimientos del producto que reflejan necesidades acordadas con el
cliente y el diseo del producto que cumple con sus requerimientos. Las salidas de la planificacin del alcance son la descripcin del alcance y el plan de gestin del alcance, con el
detalle de respaldo. La enunciacin del alcance constituye la base para un acuerdo entre el
proyecto y el cliente del proyecto para identificar tanto los objetivos como los entregables del
proyecto. Los equipos del proyecto desarrollan mltiples enunciados del alcance apropiados
para el nivel de estructura detallada del trabajo del proyecto.
5.2.1
.1
.2
.3
.4
Entradas a la Planificacin del Alcance

Descripcin del producto. La descripcin del producto es tratada en la seccin 5.1.1.1.
Acta del proyecto. El acta del proyecto es tratada en la seccin 5.1.3.1.
Restricciones. Las restricciones son tratadas en la seccin 5.1.3.3.
Hiptesis. Las hiptesis son tratadas en la seccin 4.1.1.5.
55
5.2.2 | 5.3.2.1
5.2.2
.1
.2
.3
.4
5.2.3
.1
.2
.3
56
Tcnicas y Herramientas para la Planificacin del Alcance

Anlisis del producto. El anlisis del producto supone desarrollar una mejor comprensin del
producto del proyecto. Incluye tcnicas tales como ingeniera de sistemas de anlisis de la
estructura detallada del producto, ingeniera del valor, anlisis del valor, anlisis funcional y la
utilizacin de la funcin de calidad.
Anlisis costo/beneficio. El anlisis costo/beneficio comprende la estimacin de los costos tangibles e intangibles (gastos) y de los beneficios (ingresos) de diferentes proyectos y productos
alternativos, para luego, utilizando mediciones financieras tales como tasa interna de retorno
o perodo de repago, para evaluar la conveniencia relativa de las alternativas identificadas.
Identificacin de alternativas. ste es un trmino general para cualquier tcnica utilizada para
generar diferentes alternativas de solucin para el proyecto. Hay una gran variedad de tcnicas
de gestin general que se usan frecuentemente; entre las ms comunes estn la tormenta de
ideas y el pensamiento lateral.
Juicio de expertos. El juicio de expertos se describe en la seccin 5.1.2.2.
Salidas de la Planificacin del Alcance

Enunciacin del alcance. La enunciacin del alcance provee una base documentada para la
toma de decisiones futuras en el proyecto y para confirmar o desarrollar entre las personas
interesadas en el proyecto un entendimiento comn del alcance del mismo. A medida que progresa el proyecto, puede ser necesario revisar o refinar el enunciado del alcance para reflejar
los cambios aprobados en el alcance del proyecto. La enunciacin del alcance debe incluir,
directamente o por referencia a otros documentos:
Justificacin del proyecto la necesidad de negocio que debe ser resuelta por el proyecto.
La justificacin del proyecto provee la base para la evaluacin de futuras negociaciones.
Producto del proyecto un breve resumen de la descripcin del producto (la descripcin
del producto se describe en la seccin 5.1.1.1).
Entregables del proyecto una lista a modo de resumen de los subproductos cuya completa y satisfactoria entrega marca la finalizacin del proyecto. Por ejemplo los principales
entregables de un proyecto de desarrollo de software pueden incluir el cdigo ejecutable
de computadora, un manual de usuario y un tutorial interactivo. Cuando sean conocidas,
las exclusiones deben ser identificadas, pero cualquier cosa no incluida explcitamente est
implcitamente excluida.
Objetivos del proyecto los criterios cuantificables que deben alcanzarse para que el
proyecto se considere un xito. Los objetivos del proyecto deberan incluir, al menos,
medidas de costos, cronograma y calidad. Los objetivos del proyecto deben tener un
atributo (por ejemplo, costo), una unidad de medida (por ejemplo, dlares USA) y un valor
absoluto o relativo (por ejemplo, menos de 1,5 millones). Los objetivos no cuantificables
(por ejemplo, satisfaccin del cliente) conllevan un elevado riesgo para su efectivo
cumplimiento.
Detalles de respaldo. Los detalles de respaldo de la descripcin del alcance deben organizarse
y documentarse segn se necesiten para facilitar su uso en otros procesos de la gestin de
proyectos. Los detalles de respaldo siempre deberan incluir la documentacin de todas las
restricciones e hiptesis identificadas. La cantidad de detalle adicional puede variar segn el
rea de aplicacin.
Plan de gestin del alcance. Este documento describe cmo ser gestionado el alcance del
proyecto y cmo los cambios del alcance se integrarn en el propio proyecto. Tambin,
debera incluir una evaluacin de la estabilidad esperada del alcance del proyecto (por
ejemplo, su tendencia al cambio, con qu frecuencia y en qu cantidad). El plan de gestin del
alcance debera incluir tambin una clara descripcin de cmo se identificarn y clasificarn
los cambios del alcance (esto es especialmente difcil y, por consiguiente, absolutamente esencial cuando las caractersticas del producto an estn siendo elaboradas).
Segn las necesidades del proyecto, un plan de gestin del alcance puede ser formal o
informal, altamente detallado o en lneas generales. Es un componente secundario del plan del
proyecto (descrito en la seccin 4.1.3.1).
5.3 DEFINICIN DEL ALCANCE

La definicin del alcance abarca la subdivisin de los principales entregables del proyecto
(identificados en la descripcin del alcance, en la Seccin 5.2.3.1) en componentes ms
pequeos y manejables con el fin de:
Mejorar la precisin de las estimaciones de costos, duracin y recursos.
Definir el plan de referencia para la medicin del rendimiento y control del proyecto.
Facilitar una clara asignacin de responsabilidades.
La adecuada definicin del alcance es crtica para el xito del proyecto. Cuando hay una
pobre definicin del alcance, se puede esperar que se eleven los costos finales del proyecto
debido a los inevitables cambios que interrumpen el ritmo del proyecto, causan reprocesos,
aumentan los plazos del proyecto y disminuyen la productividad y la moral de la fuerza laboral (3).
5.3.1
.1
.2
.3
.4
.5
5.3.2
.1
Entradas a la Definicin del Alcance

La enunciacin del alcance. El enunciado del alcance se describe en la seccin 5.2.3.1.
Restricciones. Las restricciones se describen en la seccin 5.1.3.3. Cuando se realiza un
proyecto bajo contrato, las restricciones definidas por las provisiones contractuales son frecuentemente consideraciones importantes que deben ser revisadas durante la definicin del
alcance.
Hiptesis. Las hiptesis se describen en la seccin 4.1.1.5.
Otras salidas de los procesos de planificacin. Se deberan revisar las salidas procedentes de
procesos de otras reas de conocimiento para ver su posible impacto en la definicin del
alcance del proyecto.
Informacin histrica. Durante la definicin del alcance debera considerarse la informacin
histrica sobre proyectos previos. La informacin sobre errores y omisiones en proyectos previos debera resultar especialmente til.
Tcnicas y Herramientas para la Definicin del Alcance

Plantillas de Estructura Detallada del Trabajo (WBS). Una estructura detallada del trabajo (WBS,
descrita en la seccin 5.3.3.1) de un proyecto previo puede utilizarse a menudo como modelo
para un nuevo proyecto. Aunque cada proyecto es nico, las WBS pueden a menudo ser reutilizadas, ya que la mayora de los proyectos se parecen a otros, al menos en parte. Por
ejemplo, la mayora de los proyectos dentro de una organizacin determinada tendrn el
mismo o similar ciclo de vida y tendrn, adems, los mismos o similares entregables requeridos
en cada fase.
57
Figura 52 | 5.3.3.1
Figura 52. Ejemplo de Estructura Detallada de Trabajo (WBS) para Artculos de Materiales de Defensa
.2
58
Muchas reas de aplicacin u organizaciones ejecutoras tienen WBS normalizadas o seminormalizadas que pueden usarse como plantillas. Por ejemplo, el Departamento de Defensa
de EE.UU. ha definido una WBS normalizada para los Materiales de Defensa (MIL-HDBK-881).
En la figura 5-2, se muestra una parte de estas plantillas.
Descomposicin. La descomposicin comprende la subdivisin de los principales entregables
del proyecto en otros componentes ms pequeos y manejables, de forma tal que los entregables sean definidos con suficiente detalle para responder a las futuras actividades del
proyecto (planificacin, ejecucin, control y cierre). La descomposicin comprende los
siguientes pasos principales:
(1) Identificar los principales entregables del proyecto, incluyendo la gestin del proyecto.
Los principales entregables siempre se deben definir en trminos de cmo el proyecto ser
realmente organizado. Por ejemplo:
Las fases del ciclo de vida del proyecto pueden utilizarse como el primer nivel de descomposicin, repitiendo los entregables del proyecto en el segundo nivel, como se ilustra en la
figura 5-3.
El principio organizativo dentro de cada rama de una WBS puede variar, como se ilustra en
la figura 5-4.
(2) Decidir si se pueden realizar estimaciones adecuadas de duracin y costos a este nivel
de detalle para cada entregable. El significado de adecuadas puede variar a lo largo del
proyecto (puede no ser posible la descomposicin de un resultado que se producir muy lejos
en el tiempo). Para cada entregable, hay que pasar al paso 4 si se ha logrado el detalle adecuado y al paso 3 si no es as (esto quiere decir que los diferentes entregables pueden tener
diferentes niveles de descomposicin).
Figura 53. Ejemplo de Estructura Detallada de Trabajo (WBS) Organizada por Fases
(3) Identificar los elementos constituyentes de un entregable. Los elementos constituyentes

se deberan describir en trminos de entregables que sean verificables y tangibles para facilitar
la medicin del rendimiento. Tal como se hace con los elementos principales, los elementos
constituyentes del proyecto deben definirse en trminos de cmo se realizar realmente el trabajo del proyecto. Tanto servicios como productos pueden significar entregables tangibles y
verificables (por ejemplo, el informe de estado se puede describir como informe de estado
semanal para un elemento manufacturado, y los elementos constituyentes podran incluir
varios componentes individuales ms el montaje final). Repetir el paso 2 para cada elemento
constituyente.
(4) Verificar la exactitud de la descomposicin:
Son necesarios y suficientes los elementos en el nivel inferior para completar el elemento
descompuesto? Si no es as, se deben modificar los elementos constituyentes (aadir, eliminar o redefinir).
Est cada elemento clara y completamente definido? Si no es as, se deben revisar o
ampliar las descripciones.
Se puede planificar apropiadamente cada elemento? Presupuestar? Asignar a una unidad
especfica de la organizacin (por ejemplo, un departamento, equipo o individuo) que
aceptar la responsabilidad de concluir satisfactoriamente el elemento? Si no fuera as, se
requieren revisiones que permitan un adecuado control de gestin.
5.3.3
.1
Salidas de la Definicin del Alcance

Estructura Detallada de Trabajo (WBS). Una estructura detallada de trabajo es una agrupacin
de elementos del proyecto orientada a los entregables del mismo, que organiza y define el
59
Figura 54 | 5.4
Figura 54.
Ejemplo de Estructura Detallada de Trabajo (WBS) para una Planta de Tratamiento de Aguas
Residuales
alcance completo del proyecto: trabajos que no estn en la WBS quedan fuera del alcance del
proyecto. Como con la descripcin del alcance, la WBS se utiliza a menudo para desarrollar
o confirmar un entendimiento comn del alcance del proyecto. Cada nivel decendente representa una descripcin cada vez ms detallada de los entregables del proyecto. La seccin
5.3.2.2 describe el enfoque ms usual para desarrollar una WBS. Una WBS se representa normalmente en forma de diagrama como se muestra en las figuras 5-2, 5-3 y 5-4; sin embargo,
la WBS no se debera confundir con el mtodo de representacin dibujar una lista no estructurada de actividades en forma de diagrama no la convierte en una WBS.
A cada elemento en la WBS se le asigna generalmente un identificador nico; estos identificadores pueden proveer una estructura para un resumen jerrquico de costos y recursos. Los
elementos de los niveles ms bajos de la WBS pueden denominarse paquetes de trabajo, especialmente en organizaciones que utilizan prcticas de gestin del valor del trabajo realizado.
Estos paquetes de trabajo pueden ser descompuestos an ms en una estructura detallada de
trabajo de subproyecto. Generalmente este tipo de enfoque es utilizado cuando el director del
proyecto asigna un alcance de trabajo a otra organizacin y sta debe planificar y gestionar
el alcance del trabajo a un nivel ms detallado que el director de proyecto en el proyecto principal. Esos paquetes de trabajo pueden ser descompuestos an ms en el plan de proyecto y
en el cronograma, como se describe en las secciones 5.3.2.2. y 6.1.2.1.
60
.2
Las descripciones de los elementos de trabajo se recopilan frecuentemente en un diccionario de la WBS. Un diccionario de la WBS incluye generalmente tanto la descripcin de
los paquetes de trabajo como cualquier otra informacin de planificacin tales como fechas del
cronograma, presupuestos de costos y asignaciones de personal.
No debera confundirse la WBS con otros tipos de estructuras de desglose utilizadas para
presentar informacin del proyecto. Otras estructuras comnmente utilizadas en algunas reas
de aplicacin pueden ser:
WBS contractual (CWBS), que se utiliza para definir el nivel de informacin que el
vendedor suministrar al comprador. La WBS contractual tiene normalmente menos detalle
que la WBS utilizada por el vendedor para dirigir su propio trabajo.
Estructura detallada organizacional (Organization Breakdown Structure-OBS), que se usa
para mostrar qu elementos de trabajo han sido asignados a qu unidades de la organizacin.
Estructura detallada de los recursos (Resource Breakdown Structure-RBS), que es una
variacin de la estructura detallada organizativa y se utiliza normalmente cuando se asignan
elementos de trabajo a individuos.
Lista de materiales (Bill of materials-BOM), que representa una relacin jerrquica de los
montajes fsicos, submontajes y componentes necesarios para fabricar un producto manufacturado.
Estructura detallada de proyecto (Product Breakdown Structure-PBS), que es fundamentalmente lo mismo que una WBS correctamente realizada. El trmino estructura detallada de
proyecto se utiliza ampliamente en reas de aplicacin en las que el trmino WBS se utiliza incorrectamente para referirse a una lista de materiales (BOM).
Actualizaciones de la enunciacin del alcance. Incluye cualquier modificacin de los contenidos del enunciado del alcance (descrita en la seccin 5.2.3.1). Segn sea necesario, deber
notificarse a los interesados que corresponda.
5.4 VERIFICACIN DEL ALCANCE

La verificacin del alcance del proyecto es el proceso para obtener la aceptacin formal del
alcance del proyecto por parte de los interesados en el proyecto (patrocinador, cliente,
usuarios, etc.). Requiere la revisin de los entregables y de los resultados del trabajo del
proyecto para asegurarse que todo se ha completado correcta y satisfactoriamente. Si el
proyecto se termina antes de lo previsto, el proceso de verificacin del alcance debera
establecer y documentar el nivel y extensin de lo completado. La verificacin del alcance del
proyecto se diferencia del control de la calidad (descrito en la seccin 8.3) en que est ante
todo interesado en la aceptacin de los entregables del trabajo, mientras que el control de la
calidad est ante todo interesado en que los entregables del trabajo sean correctos. Estos procesos son generalmente realizados en paralelo para asegurar tanto la calidad como la
aceptacin.
61
5.4.1 | 5.5.3.1
5.4.1
.1
.2
.3
.4
.5
5.4.2
.1
5.4.3
.1
Entradas a la Verificacin del Alcance

Resultados del trabajo: Los resultados del trabajo qu entregables han sido total o parcialmente cumplidos son una salida de la ejecucin del plan del proyecto (descrito en la seccin 4.2).
Documentacin del producto: Los documentos producidos para describir los productos del
proyecto deben estar disponibles para su revisin. Los trminos utilizados para describir esta
documentacin (planos, especificaciones, documentacin tcnica, dibujos, etc.) varan segn
el rea de aplicacin.
Estructura detallada del trabajo. La WBS ayuda en la definicin del alcance y debera ser utilizada para verificar el trabajo del proyecto (vase la seccin 5.3.3.1).
Enunciacin del alcance. La enunciacin del alcance define el alcance con cierto detalle y
debera ser verificado (vase la seccin 5.2.3.1).
Plan del proyecto. El plan del proyecto se describe en la seccin 4.1.3.1.
Tcnicas y Herramientas para la Verificacin del Alcance

Inspeccin: La inspeccin incluye actividades tales como medicin, examen y pruebas que se
lleven a cabo para determinar si los entregables se ajustan a los requerimientos. Las inspecciones pueden denominarse revisiones, revisiones de producto, auditoras y pruebas de funcionamiento; en algunas reas de aplicacin, estos trminos tienen significados especficos y
concretos.
Salidas de la Verificacin del Alcance

Aceptacin formal: Debe elaborarse y distribuirse la documentacin que acredite que el cliente
o patrocinador ha aceptado el producto de la fase del proyecto o sus principales entregables.
Tal aceptacin puede ser condicional, especialmente al final de una fase.
5.5 CONTROL DE CAMBIOS DEL ALCANCE

El control de cambios del alcance est relacionado con a) influir en los factores que crean cambios en el alcance para asegurar que los cambios sean acordados; b) determinar cundo se ha
producido un cambio del alcance; y c) administrar los cambios reales cuando cundo ocurren,
si es que ocurren. El control de cambios del alcance debe estar ntimamente integrado con los
otros procesos de control (control de tiempos, control de costos, control de calidad y otros que
se describieron en la seccin 4.3).
62
5.5.1
.1
.2
.3
.4
5.5.2
.1
.2
.3
5.5.3
.1
Entradas al Control de Cambios del Alcance

Estructura detallada del trabajo. La WBS se describe en la seccin 5.3.3.1. Ella define el plan
de referencia para el alcance del proyecto.
Informes de rendimiento. Los informes de rendimiento del proyecto, descritos en la seccin
10.3.3.1, dan informacin sobre el desarrollo del alcance, como cules entregables intermedios
se han completado y cules no. Los informes de rendimiento tambin pueden alertar al equipo
del proyecto sobre qu aspectos pueden causar problemas en el futuro.
Requerimientos de cambio. Los requerimientos de cambio pueden suceder de muchas maneras: verbalmente o por escrito, directa o indirectamente, originadas interna o externamente, por
imperativo legal u opcionalmente. Los cambios pueden requerir extender el alcance o pueden
permitir reducirlo. La mayora de los requerimientos para realizar cambios son el resultado de:
Un evento externo (por ejemplo, el cambio de una regulacin gubernamental)
Un error u omisin al definir el alcance del producto (por ejemplo, la no inclusin de una
caracterstica requerida en el diseo de un sistema de telecomunicaciones).
Un error u omisin al definir el alcance del proyecto (por ejemplo, utilizar una lista de
materiales en lugar de una estructura detallada del proyecto).
Un cambio en el valor agregado (por ejemplo, un proyecto de mejora ambiental es capaz
de reducir los costos utilizando una tecnologa que no estaba disponible cuando se defini
originalmente el alcance del proyecto).
La implementacin de un plan de contingencia o una solucin alternativa en respuesta a
un riesgo, como se describe en la seccin 11.6.3.3.
Plan de gestin del alcance: El plan de gestin del alcance es descrito en la seccin 5.2.3.3.
Tcnicas y Herramientas para el Control de Cambios del Alcance

Control de cambios del alcance: El control de cambios del alcance define los procedimientos
mediante los cuales se puede cambiar el alcance del proyecto. Incluye formularios, sistemas
de seguimiento y niveles de aprobacin necesarios para autorizar los cambios. El control de
cambios del alcance debe estar integrado en el control global de cambios descrito en la seccin 4.3 y, en particular, en cualquier sistema o sistemas implementados para controlar el
alcance del producto. Cuando el proyecto se realiza bajo contrato, el control de cambios del
alcance del proyecto tambin debe estar de acuerdo con todas las disposiciones contractuales
relevantes.
Medicin del rendimiento. Las tcnicas para medir el rendimiento, descritas en la seccin
10.3.2, ayudan a evaluar la magnitud de cualquier variacin que se produzca. Una parte importante del control de cambios del alcance del proyecto es determinar qu origina la variacin
relativa al plan de referencia y decidir si esta variacin requiere alguna accin correctiva.
Planificacin adicional. Pocos proyectos se desarrollan exactamente segn el plan inicial. Los
futuros cambios del alcance del proyecto pueden requerir modificaciones de la WBS o el
anlisis de enfoques alternativos (vanse las secciones 5.3.3.1 y 5.2.2.3 respectivamente).
Salidas del Control de Cambios del Alcance

Cambios del alcance. Un cambio del alcance es una modificacin en el alcance del proyecto
acordado al definir la WBS aprobada. Los cambios del alcance a menudo necesitan ajustes de
costos, plazos, calidad u otros objetivos del proyecto.
Los cambios del alcance se realimentan durante el proceso de planificacin. Los documentos tcnicos y de planificacin son actualizados segn sea necesario y los interesados en
el proyecto deben ser informados apropiadamente.
63
5.5.3.2 | 6.1
.2
.3
.4
64
Accin correctiva. Es cualquier tipo de accin realizada para alinear el rendimiento futuro
esperado del proyecto con el plan del mismo.
Lecciones aprendidas. Las causas de las variaciones, los razonamientos que sustentan las
acciones correctivas adoptadas y otros tipos de lecciones aprendidas sobre el control de cambios del alcance del proyecto deberan ser documentadas para posibilitar que esta informacin
se convierta en parte de una base de datos histrica para ste y otros proyectos de la organizacin ejecutora.
Plan de referencia ajustado. Dependiendo de la naturaleza de los cambios, el correspondiente
documento del plan de referencia puede ser revisado y reemitido para reflejar el cambio
aprobado y ser as el nuevo plan de referencia para futuros cambios.
Captulo 6
Gestin de Tiempos del

Proyecto
La gestin de tiempos del proyecto incluye los procesos requeridos para asegurar la ejecucin
del proyecto en el tiempo fijado. La figura 6-1 proporciona una visin general de los
siguientes procesos principales en el desarrollo del cronograma de tiempos del proyecto:
6.1 Definicin de Actividades identificacin de las actividades especficas que deben ejecutarse para producir los diversos entregables del proyecto.
6.2 Secuenciamiento de Actividades identificacin y documentacin de las relaciones
de dependencia.
6.3 Estimacin de la Duracin de las Actividades estimacin del nmero de perodos
laborales que se requerirn para completar las actividades individuales.
6.4 Desarrollo del Cronograma anlisis de la secuencia de las actividades, duracin de
las actividades y requerimientos de recursos para crear el cronograma del proyecto.
6.5 Control del Cronograma control de los cambios al cronograma del proyecto.
En algunos proyectos, especialmente los pequeos, el secuenciamiento de actividades, la
estimacin de la duracin de las actividades y el desarrollo del cronograma estn tan
estrechamente vinculados que son vistos como un nico proceso (por ejemplo, pueden ser ejecutados por un nico individuo durante un perodo relativamente corto). Se los presenta aqu
como procesos distintos porque las herramientas y tcnicas para cada uno son diferentes.
6.1 DEFINICIN DE ACTIVIDADES

La definicin de actividades involucra la identificacin y documentacin de las actividades
especficas que deben ser ejecutadas para generar los entregables y sub-entregables identificados en la estructura detallada del trabajo (WBS). Est implcita en este proceso la necesidad
de definir las actividades de modo que los objetivos del proyecto se cumplan.
65
Captulo 6 Gestin de Tiempos del Proyecto
Figure 61 | 6.1.3.1
Captulo 6 Gerenciamento de Tempo do Projeto
Figura 61. Visin General de la Gestin de Tiempos del Proyecto
66
6.1.1
.1
.2
.3
.4
.5
.6
6.1.2
.1
.2
6.1.3
.1
Entradas a la Definicin de Actividades

Estructura detallada del trabajo (WBS). La estructura detallada del trabajo (WBS) es la fuente
primaria de informacin para la definicin de actividades (vase la seccin 5.3.3.1 para un
tratamiento ms detallado de la WBS).
Enunciacin del alcance. La justificacin y los objetivos del proyecto contenidos en la enunciacin del alcance deben ser considerados explcitamente durante la definicin de actividades
(vase la seccin 5.2.3.1 para un tratamiento ms detallado sobre la enunciacin del alcance).
Informacin histrica. La informacin histrica (qu actividades fueron realmente requeridas
en proyectos anteriores similares) debera ser considerada en la definicin de las actividades
del proyecto.
Restricciones. Las restricciones son factores que pueden limitar las opciones del equipo de
direccin del proyecto; un ejemplo podra ser el uso de una duracin mxima deseada para
las actividades.
Hiptesis. Vase la seccin 4.1.1.5
Juicio de expertos. El juicio de los expertos se trata en las secciones 5.1.2.2. y 6.3.2.1.
Tcnicas y Herramientas para la Definicin de Actividades

Descomposicin. Dentro del contexto del proceso de la Definicin de Actividades, la descomposicin comprende la subdivisin de los paquetes de trabajo del proyecto en componentes
ms pequeos y manejables para proporcionar mejor control de gestin. La tcnica de la
descomposicin se describe con ms detalle en la seccin 5.3.2.2. La mayor diferencia entre la
descomposicin aqu y en la Definicin del Alcance es que los resultados finales aqu estn
descritos como actividades ms que como entregables. La WBS y la lista de actividades generalmente se desarrollan en forma secuencial, siendo la WBS la base para el desarrollo de la lista
final de actividades. En algunas reas de aplicacin, la WBS y la lista de actividades se desarrollan en forma concurrente.
Plantillas. Una lista de actividades (descrita en la seccin 6.1.3.1) o una parte de una lista de
actividades de un proyecto anterior se utilizan frecuentemente como una plantilla para un
nuevo proyecto. Las actividades en las plantillas tambin pueden contener una lista de las aptitudes de los recursos y la cantidad de horas de esfuerzo requeridas, la identificacin de riesgos,
los entregables esperados y cualquier otra informacin descriptiva.
Salidas de la Definicin de Actividades

Lista de actividades. La lista de actividades debe incluir todas las actividades que van a ser ejecutadas en el proyecto. Debera estar organizada como una extensin de la WBS para garantizar que est completa y que no incluya actividades no requeridas como parte del alcance del
67
6.1.3.2 | 6.2.2.1
.2
.3
proyecto. Como en el caso de la WBS, la lista de actividades debera incluir la descripcin de

cada actividad para asegurar que los miembros del equipo de trabajo entiendan cmo se debe
hacer el trabajo.
Detalle de Respaldo. El detalle de respaldo de la lista de actividades debera estar documentado y organizado de manera tal de facilitar su uso en otros procesos de la direccin de
proyectos. El detalle de respaldo siempre debera incluir documentacin sobre todas las
hiptesis y restricciones identificadas. La cantidad de detalles adicionales vara por rea de aplicacin.
Actualizacin de la estructura detallada de trabajo. Al usar la WBS para identificar qu actividades van a ser necesarias, el equipo del proyecto puede identificar entregables faltantes o
puede determinar que la descripcin de entregables requiere ser clarificada o corregida.
Cualquiera de esas actualizaciones, debe quedar reflejada en la WBS y en la documentacin
relacionada, como por ejemplo en las estimaciones de costos. Estas actualizaciones son llamadas a menudo refinamientos y son ms probables cuando el proyecto involucra nuevas tecnologas o tecnologas no probadas.
6.2 SECUENCIAMIENTO DE ACTIVIDADES

El secuenciamiento de actividades implica la identificacin y documentacin de relaciones lgicas entre actividades. Las actividades deben secuenciarse en forma precisa para sustentar el
posterior desarrollo de un cronograma realista y factible. El secuenciamiento puede ejecutarse
con la ayuda de una computadora (por ejemplo, usando software de gestin de proyectos) o
mediante tcnicas manuales. Las tcnicas manuales a menudo son ms efectivas para proyectos
pequeos y en las primeras fases de proyectos grandes, cuando slo se dispone de pequeos
detalles. Las tcnicas manuales y automticas tambin pueden usarse en forma combinada.
6.2.1
.1
.2
.3
68
Entradas al Secuenciamiento de Actividades

Lista de actividades. La lista de actividades se describe en la seccin 6.1.3.1.
Enunciado del producto. La descripcin del producto se trata en la seccin 5.1.1.1. Las caractersticas de los productos a menudo afectan el secuenciamiento de actividades (por ejemplo,
el diseo fsico de una planta a ser construida, las interfaces de un subsistema de un proyecto
de software). Mientras que estos efectos a menudo estn visibles en la lista de actividades, la
descripcin del producto debera ser revisada para asegurar su exactitud.
Dependencias obligatorias. Las dependencias obligatorias son aquellas inherentes a la naturaleza del trabajo a ser desarrollado. Ellas comprenden a menudo limitaciones fsicas. (En un
proyecto de construccin, es imposible edificar la superestructura hasta que se hayan construido las bases; en un proyecto de electrnica, se debe hacer el prototipo antes de poder probarlo.) Las dependencias obligatorias son llamadas tambin de lgica rgida.
Figura 62. Diagrama de Red Lgica Dibujado Usando el Mtodo de Diagramacin por Precedencia
.4
.5
.6
6.2.2
.1
Dependencias Discrecionales. Las dependencias discrecionales son aqullas definidas por el

equipo de direccin del proyecto. Deberan usarse con cuidado (y totalmente documentadas),
dado que pueden limitar opciones posteriores del cronograma. Las dependencias discrecionales son generalmente definidas basndose en el conocimiento de:
Las mejores prcticas dentro de un rea de aplicacin en particular.
Algunos aspectos inusuales del proyecto en los que se desea una secuencia especfica, aun
cuando haya otras secuencias aceptables.
Las dependencias discrecionales pueden ser llamadas tambin de lgica preferida, lgica preferencial o lgica flexible.
Dependencias externas. Las dependencias externas son aqullas que implican una relacin
entre las actividades del proyecto y las actividades que no son del proyecto. Por ejemplo, la
actividad de prueba en un proyecto de software puede ser dependiente de la entrega del hardware proveniente de una fuente externa o, en un proyecto de construccin, puede ser necesario mantener audiencias ambientales antes de comenzar con la preparacin del lugar.
Hitos. Los hitos necesitan ser parte del secuenciamiento de actividades para asegurar que se
cumplan los requerimientos necesarios para alcanzarlos.
Tcnicas y Herramientas para el Secuenciamiento de Actividades

Mtodo de diagramacin por precedencia (PDM). ste es un mtodo para construir diagramas
de red que usa cajas o rectngulos (nodos) para representar las actividades y conecta las
mismas con flechas que muestran las dependencias (vase tambin la seccin 6.2.3.1). La
figura 6-2 muestra un diagrama de lgica de red simple que usa PDM. Esta tcnica tambin se
conoce como actividad en el nodo (AON) y es el mtodo ms usado en los paquetes de software de gestin de proyectos. El PDM puede hacerse manualmente o en una computadora.
Incluye cuatro tipos de dependencias o relaciones de precedencia:
Fin a inicio el inicio del trabajo de la sucesora depende de la finalizacin del trabajo
de la predecesora.
Fin a fin la finalizacin del trabajo de la sucesora depende de la finalizacin del trabajo
de la predecesora.
Inicio a inicio el inicio del trabajo de la sucesora depende del inicio del trabajo de la
predecesora.
Inicio a fin la finalizacin de la sucesora depende del inicio de la predecesora.
En PDM, fin a inicio es el tipo de relacin lgica ms usado. Las relaciones inicio a fin son
de uso poco frecuente y tpicamente usadas slo por profesionales. El uso de las relaciones
inicio-inicio, fin a fin o inicio a fin en software de gestin de proyectos puede producir resultados inesperados, dado que estos tipos de relaciones no han sido consistentemente implementados.
69
Figura 63 | 6.3.1.4
Figura 63. Diagrama de Red Lgica Dibujado Usando el Mtodo de Diagramacin con Flechas
.2
.3
.4
6.2.3
.1
70
Mtodo de diagramacin con flechas (ADM). Este mtodo para construir un diagrama de red
del proyecto usa flechas para representar las actividades y las conecta a nodos para mostrar
sus dependencias (vase tambin la seccin 6.2.3.1) La figura 6-3 imuestra un diagrama de
lgica de red simple que usa ADM. Esta tcnica es tambin llamada actividad en la flecha
(AOA) y, aunque menos predominante que el PDM, es elegida en algunas reas de aplicacin.
El ADM usa solamente la dependencia fin-inicio y puede requerir el uso de actividades ficticias para definir correctamente todas las relaciones lgicas. El ADM puede hacerse manualmente o en una computadora.
Mtodo condicionales de diagramacin. Las tcnicas de diagramacin como la Tcnica de
Evalua-cin y Revisin Grfica (GERT) y los modelos Dinmicos de Sistemas permiten considerar actividades no secuenciales tales como lazos (por ejemplo, una prueba que debe ser
repetida ms de una vez) o ramificaciones condicionales (por ejemplo, una actualizacin de
diseo que solamente se necesita si la inspeccin detecta errores). Ni el PDM ni el ADM permiten ciclos o ramificaciones condicionales.
Plantillas de red. Las redes estandarizadas pueden ser usadas para acelerar la preparacin de
diagramas de redes. Ellas pueden incluir un proyecto completo o solamente una parte del
mismo. Las partes de una red a menudo son referidas como subredes o redes fraccionadas
(fragnets). Las subredes son especialmente tiles cuando un proyecto incluye muchas caractersticas idnticas o casi idnticas, como los pisos en un edificio de oficinas, los ensayos
clnicos en un proyecto de investigacin farmacutica, los mdulos de programas en un
proyecto de software o la fase de lanzamiento de un proyecto de desarrollo.
Salidas del Secuenciamiento de Actividades

Diagramas de red del proyecto. Los diagramas de red del proyecto son grficos esquemticos
de las actividades del proyecto y las relaciones lgicas (dependencias) entre ellas. Las figuras
6-2 y 6-3 ilustran dos metodologas diferentes para dibujar un diagrama de red del proyecto.
Un diagrama de red del proyecto puede construirse manualmente o por medio de una computadora. Puede incluir detalles completos de las actividades del proyecto, o tener una o ms
actividades resumidas (actividad sumaria). El diagrama debera acompaarse de un resumen
narrativo que describiera el criterio de secuenciamiento bsico. Cualquier secuencia inusual
debera ser completamente detallada.
Un diagrama de red del proyecto a menudo se lo refiere como un diagrama PERT. Histricamente el PERT (Tcnica de Evaluacin y Revisin de Programas) es un tipo especfico de
diagrama de red (vase tambin la seccin 6.4.2.1).
.2
Actualizaciones de la lista de actividades. De la misma forma que el proceso de definicin de

actividades puede generar actualizaciones en la WBS, la preparacin de los diagramas de red
del proyecto puede poner de manifiesto instancias donde una actividad debe ser dividida o
redefinida para diagramar las interrelaciones lgicas correctas.
6.3 ESTIMACIN DE LA DURACIN DE LAS ACTIVIDADES

La estimacin de la duracin de las actividades es el proceso de tomar informacin del alcance
y de los recursos del proyecto y luego desarrollar las duraciones para usarlas como entradas al
cronograma. Los datos para la estimacin de la duracin son generalmente dados por la persona o grupo del equipo del proyecto que est ms familiarizado con la naturaleza de cada
actividad. La estimacin, a menudo, es desarrollada en forma progresiva y el proceso considera
la calidad y disponibilidad de los datos de entrada. De esta manera, puede suponerse que las
estimaciones sern cada vez ms exactas y de calidad reconocida. El integrante o grupo del
equipo del proyecto que est ms familiarizado con la naturaleza de una actividad especfica
debe hacer, o al menos aprobar, la estimacin.
Estimar el nmero de perodos laborales necesarios para completar una actividad a veces
requiere tener en cuenta tambin el tiempo transcurrido. Por ejemplo, si el curado del
hormign va a requerir cuatro das, ello va a demandar un perodo de dos a cuatro jornadas
laborales, basndose en a) en qu da de la semana comience y b) si el fin de semana se considera como perodo laborable o no. La mayora de los programas de computadora de construccin de cronogramas manejan este problema mediante el uso de calendarios laborales
alternativos.
La duracin total del proyecto tambin puede estimarse usando las herramientas y tcnicas
presentadas aqu, pero se calcula ms adecuadamente como resultado del desarrollo del cronograma (descrito en la seccin 6.4). El equipo del proyecto puede considerar la duracin del
proyecto como una distribucin de probabilidad (usando tcnicas probabilsticas) o como una
estimacin puntual (usando tcnicas determinsticas).
6.3.1
.1
.2
.3
.4
Entradas a la Estimacin de la Duracin de Actividades

Lista de actividades. La lista de actividades se describe en la seccin 6.1.3.1.
Restricciones. Las restricciones se describen en la seccin 6.1.1.4.
Hiptesis. Las hiptesis se describen en la seccin 4.1.1.5. Un ejemplo podra ser la cantidad
de perodos de reporte para toda la duracin del proyecto, que podra determinar duraciones
mximaspor ejemplo, dos perodos de reporte.
Requerimientos de los recursos. Los requerimientos de los recursos se describen en la seccin
7.1.3.1. La duracin de la mayora de las actividades estar significativamente influenciada por
los recursos asignados a las mismas. Por ejemplo, dos personas que trabajen juntas pueden ser
capaces de completar una actividad de diseo en la mitad del tiempo que cualquiera de ellas
71
6.3.1.5 | 6.4
.5
.6
.7
6.3.2
.1
.2
72
necesitara individualmente, mientras que una persona que trabaje medio tiempo en una
actividad generalmente va a insumir por lo menos el doble de tiempo que la misma persona
trabajando en tiempo completo. De todos modos, los proyectos pueden experimentar una
sobrecarga de comunicacin cuando se agregan recursos adicionales, lo cual reduce la productividad y causa una mejora en la produccin proporcionalmente menor al incremento de
recursos.
Capacidades de los recursos. La duracin de la mayora de las actividades se ver significativamente influenciada por las capacidades de los recursos humanos y materiales asignados a
ellas. Por ejemplo, se espera que un miembro experimentado del personal complete una
actividad en menos tiempo que uno sin experiencia, en el caso que ambos sean asignados a
tiempo completo.
Informacin histrica. A menudo hay informacin histrica disponible sobre las duraciones
probables de muchas categoras de actividades proveniente de una o ms de las siguientes
fuentes:
Archivos de proyectos una o ms de las organizaciones involucradas en el proyecto
puede disponer de registros de los resultados de proyectos anteriores que estn lo suficientemente detallados como para ayudar al desarrollo de la estimacin de las duraciones.
En algunas reas de aplicacin, los miembros individuales del equipo de trabajo pueden
mantener dichas registros.
Bases de datos comerciales de duraciones estimadas la informacin histrica a menudo
est disponible comercialmente. Estas bases de datos tienden a ser especialmente tiles
cuando la duracin de las actividades no est determinada por el contenido del trabajo
actual (por ejemplo, cunto tiempo demanda el secado del cemento armado, cunto
tiempo demanda a una oficina gubernamental responder un cierto tipo de requerimiento).
Conocimiento del equipo de trabajo los miembros individuales del equipo de trabajo
pueden recordar las duraciones previas reales o estimadas. Aunque tales recuerdos pueden
ser tiles, son generalmente menos confiables que los resultados documentados.
Riesgos identificados. El equipo de proyecto debe considerar la informacin sobre riesgos
identificados (vase la seccin 11.2) en el momento de generar las estimaciones de la duracin
de las actividades, dado que los riesgos (tanto amenazas como oportunidades) pueden tener
una gran influencia sobre las duraciones. El equipo de proyecto debe considerar hasta dnde
est incluido el efecto de los riesgos en la estimacin de la duracin planificada para cada
actividad, incluyendo los riesgos con alto impacto o probabilidad.
Tcnicas y Herramientas para la Estimacin de la Duracin de Actividades

Juicio de expertos. El juicio de los expertos se describe en la seccin 5.1.2.2. Las duraciones
a veces son difciles de estimar por la cantidad de factores que pueden influenciarlas (por
ejemplo, el nivel de los recursos, la productividad de los recursos). El juicio de expertos guiado
por la informacin histrica debera ser usado siempre que sea posible. Si tal experiencia no
est disponible, las estimaciones son intrnsecamente inciertas y riesgosas (vase el captulo 11,
gestin de riesgos del proyecto).
Estimacin anloga. Por estimaciones anlogas, tambin llamadas estimaciones de arriba hacia
abajo, se entiende el uso de duraciones reales de actividades previas similares, como base para
la estimacin de la duracin de una actividad futura. Frecuentemente se usa para estimar la
duracin del proyecto cuando hay una cantidad limitada de informacin de detalle del
proyecto (por ejemplo, en las fases iniciales). Las estimaciones anlogas son una forma de
juicio de expertos.(descrito en la seccin 6.3.2.1)
Las estimaciones anlogas son ms confiables cuando a) las actividades previas son similares de hecho y no slo en apariencia y b) los individuos que preparan las estimaciones tienen
la experiencia necesaria.
.3
.4
6.3.3
.1
.2
.3
Duraciones calculadas cuantitativamente. Las cantidades a ser realizadas para cada categora
de trabajo especfica (por ejemplo, nmero de dibujos, metros de cable, toneladas de acero,
etc.) definidas por las reas de ingeniera/diseo multiplicadas por un ndice de productividad
(por ejemplo, horas por dibujo, metros de cable por hora, etc.) pueden usarse para estimar
la duracin de las actividades.
Tiempo de reserva (contingencia). El equipo de proyecto puede optar por agregar tiempo adicional, llamado tambin reserva, contingencia o mitigacin, que puede ser adicionado a la
duracin de una actividad o en algn lugar del cronograma como reconocimiento del riesgo
del cronograma. Este tiempo de reserva puede ser un porcentaje de la duracin estimada o un
nmero fijo de perodos laborables. Ms adelante, el tiempo de reserva puede ser disminuirse
o eliminarse, en la medida de que se disponga de informacin ms precisa sobre el proyecto.
Tal tiempo de reserva debera documentarse, as como otros datos e hiptesis.
Salidas de la Estimacin de la Duracin de las Actividades

Estimacin de la duracin de las actividades. La estimacin de la duracin de las actividades es
una evaluacin cuantitativa del nmero probable de perodos laborables necesarios para completar una actividad.
La estimacin de la duracin de las actividades siempre debera incluir alguna indicacin
del rango de resultados posible. Por ejemplo:
2 semanas 2 das para indicar que la actividad va a llevar por lo menos ocho das y no
ms de doce (asumiendo cinco das laborables por semana).
15 por ciento de probabilidad de exceder tres semanas para indicar una alta probabilidad
(85 por ciento) de que la actividad tomar tres semanas o menos.
El Captulo 11 sobre Gestin de Riesgos de Proyectos incluye un tratamiento ms detallado
sobre la incertidumbre de las estimaciones.
Base de las estimaciones. Las hiptesis hechas para desarrollar las estimaciones deben ser documentadas.
Actualizaciones de la lista de actividades. La actualizacin de la lista de actividades se describe
en la seccin 6.2.3.2.
6.4 DESARROLLO DEL CRONOGRAMA

Desarrollar el cronograma significa determinar la fecha de inicio y finalizacin de las actividades del proyecto. Si las fechas de inicio y finalizacin no son realistas, entonces es improbable que el proyecto finalice como estaba planeado. El proceso del desarrollo del cronograma
debe ser a menudo iterado (junto con los procesos que proveen las entradas, especialmente
las estimaciones de duracin y costos) antes de determinar el cronograma final del proyecto.
73
6.4.1 | 6.4.2.3
6.4.1
.1
.2
.3
.4
.5
.6
.7
.8
.9
.10
74
Entradas al Desarrollo del Cronograma

Diagramas de red del proyecto. Los diagramas de red de proyectos se describen en la seccin
6.2.3.1.
Estimaciones de la duracin de las actividades. Las estimaciones de duracin de las actividades
se describen en la seccin 6.3.3.1.
Requerimiento de los recursos. Los requerimientos de recursos se describen en la seccin
6.3.1.4.
Enunciado de los recursos disponibles. El conocimiento de qu recursos van a estar
disponibles, en qu momento y con qu pautas, es necesario para el desarrollo del cronograma. Por ejemplo, los recursos crticos o compartidos pueden ser especialmente dificultosos
de planificar dado que su disponibilidad puede ser altamente variable. El nivel de detalle y
especificidad en la descripcin del equipo de recursos puede ser variable. Por ejemplo, es
necesario saber slo que dos consultores van a estar disponibles en un marco de tiempo para
el desarrollo preliminar del cronograma de un proyecto de consultora. El cronograma final
para el mismo proyecto, sin embargo, identifica qu consultor especfico va a estar disponible.
Calendarios. El calendario del proyecto y de los recursos identifica perodos donde el trabajo
est permitido. Los calendarios del proyecto afectan a todos los recursos (por ejemplo, algunos
proyectos se van a ejecutar solamente durante horas normales de das laborables, mientras que
otros van a ejecutarse a tres turnos completos). Una semana de cinco das laborables es un
ejemplo de uso del calendario. Los calendarios de recursos afectan un recurso especfico o una
categora de recursos (por ejemplo, un miembro del equipo de proyecto puede estar de vacaciones o en un programa de entrenamiento, un contrato de trabajo puede limitar a ciertos trabajadores a ciertos das de la semana).
Restricciones. Las restricciones son factores que limitarn las opciones del equipo de gestin
del proyecto. Hay dos categoras principales de restricciones de tiempo consideradas durante
el desarrollo del cronograma:
Fechas impuestas las fechas impuestas para el inicio o finalizacin de las actividades
pueden ser usadas para restringir el inicio o finalizacin antes de una fecha especificada
o despus de esa fecha. Mientras que las cuatro restricciones de fechas estn tpicamente
disponibles en los programas de gestin de proyectos, las restricciones inicio no antes de
y finalizacin no despus de son las ms comnmente usadas. El uso tpico de las restricciones de fechas incluye situaciones como la ventana de oportunidad en un proyecto tecnolgico, las restricciones climticas en actividades al aire libre, el acatamiento de
disposiciones gubernamentales respecto del cuidado del medio ambiente, la entrega de
materiales provenientes de partes no representadas en el cronograma del proyecto, etc.
Eventos claves o hitos principales la terminacin de ciertos entregables para una fecha
especfica puede ser requerida por el patrocinador del proyecto, el cliente del proyecto u
otros interesados. Una vez concertadas, esas fechas pasan a ser las esperadas y a menudo
pueden ser modificadas solamente con grandes dificultades. Los hitos pueden tambin ser
usados para indicar interfaces con trabajos fuera del proyecto. Tales tareas no estn tpicamente incluidas en la base de datos del proyecto y los hitos con restricciones de fecha
pueden proveer la interfaz de cronogramas apropiada.
Hiptesis. Vase la seccin 4.1.1.5
Adelantos y retrasos. Cualquiera de las dependencias puede requerir especificaciones de adelantos o desfases para definir con precisin la relacin. Un ejemplo de retraso: puede desearse
planificar dos semanas de demora (retraso) entre encargar una pieza de un equipo e instalarla
o usarla. Un ejemplo de adelanto en una dependencia fin-inicio con un adelanto de diez das:
la actividad sucesora comienza diez das antes de que la predecesora se haya completado.
Plan de gestin de riesgos. El plan de gestin del riesgo se trata en la seccin 11.1.3.
Atributos de las actividades. Los atributos de las actividades incluidas las responsabilidades
(por ejemplo, quin va a ejecutar la tarea), el rea geogrfica o edificio (dnde va a desarro-
llarse el trabajo) y el tipo de actividad (por ejemplo, resumen o detalle) son muy
importantes para ulteriores selecciones y clasificaciones de las actividades planeadas de manera
conveniente para los usuarios. La clasificacin de la estructura detallada de trabajo (WBS) es
tambin un importante atributo que permite un til ordenamiento y clasificacin de las actividades.
6.4.2
.1
.2
.3
Tcnicas y Herramientas para el Desarrollo del Cronograma

Anlisis Matemtico. El anlisis matemtico comprende el clculo terico de las fechas de
inicio y finalizacin tempranas y tardas para todas las actividades del proyecto, sin considerar
ninguna limitacin de recursos. Las fechas resultantes no son el cronograma, aunque s indican
los perodos en los cuales las actividades pueden ser programadas, dadas las limitaciones de
recursos y otras restricciones conocidas. Las tcnicas de anlisis matemtico ms ampliamente
conocidas son:
Mtodo del Camino Crtico (CPM) calcula en forma simple y determinista la fecha de
inicio y finalizacin temprana y tarda para cada actividad, basndose en una lgica de red
secuencial y una estimacin simple de la duracin. El enfoque del CPM es calcular la
flotacin para determinar qu actividades tienen la mnima flexibilidad de cronograma. Los
algoritmos fundamentales del CPM son a menudo usados en otros tipos de anlisis
matemticos.
Tcnica de Evaluacin y Revisin Grfica (GERT) admite un tratamiento probabilstico,
tanto para la lgica de red como para la estimacin de la duracin de las actividades (por
ejemplo, algunas actividades pueden no ser ejecutadas, algunas pueden ser ejecutadas slo
en parte y otras pueden ser ejecutas ms de una vez).
Tcnica de Evaluacin y Revisin de Programas (PERT) usa una estimacin promedio
para calcular la duracin de las actividades. A pesar de que hay diferencias superficiales,
PERT se diferencia primordialmente del CPM en que aqul usa la distribucin media (valor
esperado) en lugar de la estimacin ms probable originalmente usada en CPM (vase la
figura 6-4). PERT en s mismo es raramente usado hoy en da.
Compresin de la duracin. La compresin de la duracin es un caso especial del anlisis
matemtico que busca caminos para acortar el cronograma del proyecto sin cambiar su alcance
(por ejemplo, cumplir fechas impuestas u otros objetivos del cronograma). La compresin de
la duracin incluye tcnicas tales como:
Compresin en la cual la negociacin entre costo y cronograma es analizada para determinar cmo obtener, si es posible, el mayor acortamiento con el mnimo incremento de
costo. La compresin no siempre produce alternativas viables y generalmente ocasiona
incremento de costos.
Camino acelerado hacer actividades en paralelo que normalmente seran ejecutadas en
secuencia (por ejemplo, comenzar a escribir el cdigo de un proyecto de software antes de
que el diseo est completo o comenzar a construir los cimientos de una planta de procesamiento de petrleo antes de completar el 25 por ciento del diseo). El camino acelerado
a menudo resulta en re-proceso y generalmente incrementa el riesgo.
Simulacin. La simulacin implica el clculo de mltiples duraciones del proyecto con diferentes conjuntos de hiptesis sobre las actividades. La tcnica ms comn es la del Anlisis Monte
Carlo, en el cual una distribucin de resultados probables se define para cada actividad y es
usada para calcular una distribucin de resultados probables para todo el proyecto (vase tambin la seccin 11.4.2.4). Adicionalmente, se pueden realizar anlisis qu pasa si usando la
lgica de redes para simular diferentes escenarios, tales como la demora en la entrega de uno
de los principales componentes, la extensin de la duracin de un diseo especfico o la aparicin de factores externos (como una huelga o un cambio en los procesos permitidos). Los
resultados de la simulacin qu pasa si pueden usarse para evaluar la factibilidad del cronograma bajo condiciones adversas, y preparar los planes de contingencia/respuesta para superar
o mitigar el impacto de situaciones inesperadas.
75
Figura 64 | 6.4.3.1
Figura 64. Clculo de Duracin PERT para una Sola Actividad
.4
.5
76
Mtodo heurstico de nivelacin de recursos. El anlisis matemtico a menudo produce un

cronograma preliminar de fecha temprana que requiere ms recursos durante ciertos perodos
de tiempo que los que estn disponibles o requiere cambios en los niveles de los recursos que
no son controlables. Enunciados heursticos tales como, asignar recursos escasos primero a
las actividades del camino crtico pueden aplicarse para desarrollar un cronograma que refleje
tales restricciones. La nivelacin de recursos a menudo redunda en un proyecto ms largo que
el cronograma preliminar. Esta tcnica a veces es llamada mtodo basado en recursos, especialmente cuando es implementada con optimizaciones computarizadas. La reasignacin de
recursos de actividades no crticas a crticas es una manera comn de retrotraer un cronograma,
tanto como sea posible, a la duracin total pretendida originalmente. La utilizacin de horas
extras, fines de semana o turnos mltiples tambin debe ser considerada para reducir la
duracin de actividades crticas. El incremento de la productividad basado en el uso de diferentes tecnologas y/o maquinarias (por ejemplo, soldaduras automticas, cortadoras elctricas de
tubos, etc.) es otra forma de acortar las duraciones que alargaron el cronograma preliminar. El
camino acelerado, si es posible (como se describe en la seccin 6.4.2.2), es otra forma de
reducir la duracin total del proyecto. Algunos proyectos pueden tener recursos finitos y
crticos, requiriendo que estos recursos sean programados en forma inversa a partir de la fecha
de finalizacin del proyecto; esto es conocido como asignacin inversa de recursos. El encadenamiento crtico es una tcnica que modifica el cronograma del proyecto para tener en
cuenta los recursos limitados.
Software de direccin de proyectos. El software de direccin de proyectos es ampliamente
usado para asistir en el desarrollo del cronograma. Otro software puede ser capaz de interactuar directa o indirectamente con aqul, o con otro software, para satisfacer los requerimientos
de otras reas de conocimiento. Estos productos automatizan el clculo del anlisis matemtico
Figura 65. Diagrama de Red del Proyecto con Fechas
.6
6.4.3
.1
y la nivelacin de recursos, permitiendo as una rpida consideracin de muchas alternativas

de cronogramas. Ellos son ampliamente usados para imprimir o exhibir los resultados del
desarrollo del cronograma.
Estructura de la codificacin. Las actividades deberan tener una estructura de codificacin que
permita clasificaciones y/o extracciones basadas en diferentes atributos asignados a las actividades, tales como responsabilidad, rea geogrfica o edificio, fase del proyecto, nivel del
cronograma, tipo de actividad y clasificacin de la WBS.
Salidas del Desarrollo del Cronograma

Cronograma del proyecto. El cronograma del proyecto incluye al menos las fechas de inicio
planificadas y de finalizacin esperadas para cada actividad. (Nota: el cronograma del proyecto
permanece en forma preliminar hasta la confirmacin de la asignacin de recursos. Esto generalmente sucede al completar el desarrollo del plan del proyecto, seccin 4.1).
El cronograma del proyecto puede ser presentado en forma de resumen (el cronograma
maestro) o en detalle. A pesar de que puede ser presentado en forma de tabla, se presenta ms
a menudo en forma grfica, usando uno o ms de los siguientes formatos:
Diagramas de red del proyecto con informacin agregada de fechas (vase la figura 6-5).
Estos grficos generalmente muestran tanto las actividades lgicas como el camino crtico
del proyecto (vase la seccin 6.2.3.1 para ms informacin sobre los diagramas de red de
proyecto).
77
Figura 66 | 6.5.1.1
Figura 66. Grfico de Barras (Gantt)
.2
.3
.4
78
Grfico de barras, tambin llamado grfico de Gantt (vase la figura 6-6), muestra las
fechas de inicio y finalizacin de las actividades, as como las duraciones esperadas y, a
veces, las dependencias. Ellos son relativamente fciles de leer y se usan frecuentemente
en las presentaciones gerenciales.
Los grficos de hitos (vase al figura 6-7) son similares a los grficos de barras, pero slo
identifican las fechas de inicio o finalizacin de los principales entregables y las interfaces
externas claves.
Detalle de respaldo. El detalle de respaldo para el cronograma del proyecto incluye al menos
la documentacin de todos las hiptesis y restricciones identificadas. La cantidad de detalle adicional vara por rea de aplicacin. Por ejemplo:
En un proyecto de construccin es muy comn incluir elementos tales como histogramas
de recursos, proyecciones de flujo de caja y cronogramas de pedidos y entregas.
En un proyecto de electrnica es muy comn incluir solamente histogramas de recursos.
La informacin frecuentemente provista como detalles de respaldo incluye, pero no est
limitada a:
Los requerimientos de recursos por perodos de tiempo, a menudo en el formato de histograma de recursos.
Cronogramas alternativos (por ejemplo, el mejor caso o el peor caso, recursos nivelados
o no, con o sin fechas impuestas).
Reservas de contingencia del cronograma (vase la seccin 11.4).
Plan de gestin de tiempos. Un plan de gestin del cronograma define cmo se van a administrar los cambios del cronograma. Puede ser formal o informal, sumamente detallado o ampliamente bosquejado, basado en la necesidad del proyecto. Es un elemento subsidiario del
plan general del proyecto (vase la seccin 4.1).
Actualizacin de los requerimientos de los recursos. La actualizacin de la nivelacin de
recursos puede tener un efecto significativo sobre las estimaciones preliminares de requerimientos de recursos.
Figura 67. Grfico de Hitos
6.5 CONTROL DEL CRONOGRAMA

El control del cronograma se ocupa de a) influenciar los factores que crean cambios en el
cronograma para asegurar que los cambios sean acordados, b) determinar que el cronograma
ha cambiado y c) administrar los cambios concretos cuando suceden. El control del cronograma debe estar totalmente integrado con los otros procesos de control, tal como se describe
en la seccin 4.3 Control Integrado de Cambios.
6.5.1
.1
Entradas al Control del Cronograma

Cronograma del proyecto. El cronograma del proyecto se describe en la seccin 6.4.3.1. El
cronograma aprobado del proyecto, llamado plan de referencia del cronograma (que debe ser
factible tcnicamente y en trminos de recursos), es un componente del plan del proyecto
descrito en la seccin 4.1.3.1. ste provee las bases para medir y reportar el rendimiento del
cronograma.
79
6.5.5.2 | 6.5.3.3
.2
.3
.4
6.5.2
.1
.2
.3
.4
.5
6.5.3
.1
80
Informes del rendimiento. Los informes de rendimiento, tratados en la seccin 10.3.3.1, proveen
informacin sobre el rendimiento del cronograma, tal como qu fechas planeadas se han
logrado y cules no. Los informes de rendimiento pueden tambin alertar al equipo de
proyecto con respecto a algunos temas que pueden causar problemas en el futuro.
Pedidos de cambios. Los requerimientos de cambio pueden ocurrir en distintas formas oral
o escrita, directa o indirecta, iniciados externa o internamente y legalmente obligatorios u
opcionales. Los cambios pueden requerir una extensin del cronograma o pueden permitir
acelerarlo (vase la seccin 4.3.1.3).
Plan de gestin de tiempos. El plan de gestin del cronograma se describe en la seccin
6.4.3.3.
Tcnicas y Herramientas para el Control del Cronograma

Sistema de control de cambios del cronograma. Un sistema de control de cambios del cronograma define los procedimientos por los cuales el cronograma del proyecto puede ser cambiado. Incluye los formularios, sistemas de rastreo y niveles de aprobacin necesarios para
autorizar los cambios. El control de cambios del cronograma debera integrarse al sistema de
control integrado de cambios descrito en la seccin 4.3.
Medicin del rendimiento. Las tcnicas de medicin del rendimiento, como las descritas en la
seccin 10.3.2, ayudan a evaluar la magnitud de cualquier variacin que ocurra. Una parte
importante del control del cronograma es decidir si la variacin del cronograma requiere
acciones correctivas. Por ejemplo, una demora mayor en una actividad no crtica puede tener
un pequeo efecto sobre la totalidad del proyecto, mientras que una demora ms pequea
sobre una actividad crtica o casi crtica puede requerir acciones inmediatas.
Planificacin adicional. Pocos proyectos se ejecutan exactamente de acuerdo con lo planificado.
Los cambios prospectivos pueden requerir estimaciones nuevas o revisadas de las duraciones
de las actividades, la modificacin de la secuencia de las actividades o el anlisis de cronogramas alternativos.
Software de direccin del proyecto. El software para la gestin de proyectos se describe en la
seccin 6.4.2.5. La capacidad del software para la gestin de proyectos de rastrear las fechas
planeadas versus las fechas reales y para pronosticar el efecto de los cambios de cronograma,
real o potencial, lo hacen una herramienta til para control del cronograma.
Anlisis de variacin. El rendimiento del anlisis de variacin durante el proceso de supervisin
del cronograma es un elemento clave para el control de tiempos. La comparacin de las fechas
planificadas con las fechas de inicio y finalizacin reales/pronosticadas provee informacin til
para la deteccin de desvos y para la implementacin de soluciones correctivas en caso de
demoras. La variacin de la flotacin es tambin un componente esencial de la planificacin
para evaluar el rendimiento del proyecto en el tiempo. Debe prestarse una particular atencin
a las actividades crticas y sub-crticas (por ejemplo, anlisis de los diez caminos subcrticos en
el orden de la flotacin ascendente).
Salidas del Control del Cronograma

Actualizaciones del cronograma. Una actualizacin del cronograma es cualquier modificacin
a la informacin del cronograma usado para administrar el proyecto, debiendo notificarse,
segn sea necesario, a los interesados apropiados. Las actualizaciones del cronograma pueden
o no requerir ajustes a otros aspectos del plan del proyecto.
Las revisiones con una categora especial de actualizaciones del cronograma. Las revisiones
son cambios a las fechas de inicio y finalizacin del cronograma en el cronograma aprobado
del proyecto. Estos cambios son generalmente incorporados en respuesta a cambios de alcance
o cambios de las estimaciones. En algunos casos, las demoras en el cronograma pueden ser
tan severas que se requiere una re-planificacin que provea de datos realistas para medir el
.2
.3
rendimiento. Sin embargo, debe tenerse mucho cuidado antes de realzar una re-planificacin,
porque los datos histricos del cronograma del proyecto pueden perderse. La re-planificacin
slo debera usarse como ltimo recurso para controlar el cronograma. La planificacin de
nuevas fechas debera ser el modo normal de las revisiones del cronograma.
Acciones correctivas. Una accin correctiva es cualquier tipo de accin realizada para alinear
el rendimiento futuro del proyecto con el plan del proyecto. Las acciones correctivas en el rea
de gestin de tiempos a menudo implican aceleraciones: acciones especiales tomadas para asegurar la finalizacin de una actividad en tiempo o con la menor demora posible. Las acciones
correctivas frecuentemente requieren un anlisis de causas-raz para identificar la causa de la
variacin y la recuperacin del cronograma pueda planificarse y ejecutarse para actividades
posteriores en el tiempo y no solamente tener en cuenta la actividad que causa el desvo.
Lecciones aprendidas. Las causas de las variaciones, los fundamentos detrs de las acciones
correctivas elegidas y otros tipos de lecciones aprendidas del control del cronograma deberan
ser documentados, de modo que pasen a ser parte de la base de datos histrica para ste u
otros proyectos de la organizacin ejecutante.
81
Captulo 7
Gestin de Costos del

Proyecto
La Gestin de Costos del Proyecto incluye los procesos requeridos para asegurar que el
proyecto se complete sin exceder el presupuesto aprobado. La figura 7-1 proporciona una
visin general de los siguientes procesos mayores:
7.1 Planificacin de Recursos determinacin de qu recursos (personal, equipamiento,
materiales) y qu cantidades de cada uno sern necesarios para realizar las actividades del
proyecto.
7.2 Estimacin de Costos desarrollo de una aproximacin (estimacin) de los costos de
los recursos necesarios para completar las actividades del proyecto.
7.3 Asignacin del Presupuesto de Costos asignacin de los costos globales estimados
a las actividades individuales.
7.4 Control de Costos control de cambios en el presupuesto del proyecto.
La gestin de costos del proyecto se ocupa principalmente del costo de los recursos necesarios para completar las actividades del proyecto. Sin embargo, la gestin de costos del
proyecto tambin debera considerar el efecto de las decisiones de proyecto sobre los costos
de uso del producto del proyecto. Por ejemplo, una limitacin del nmero de revisiones de
diseo puede reducir el costo del proyecto a expensas de un incremento en los costos operativos del cliente. Esta visin amplia de la gestin de costos en proyectos se denomina frecuentemente clculo de costos del ciclo de vida. El clculo de costos del ciclo de vida
juntamente con tcnicas de ingeniera del valor se utiliza para reducir costos y tiempos, mejorar
la calidad y el rendimiento y optimizar la toma de decisiones.
En muchas reas de aplicacin, el pronstico y anlisis de los resultados financieros
prospectivos del proyecto se efectan fuera del mismo. En otras, la gestin de costos de
proyecto tambin incluye este trabajo. Cuando estos pronsticos y anlisis estn incluidos, la
gestin de costos de proyectos incluir procesos adicionales y numerosas tcnicas generales
de direccin tales como retorno de inversin, valor actual neto, anlisis de retorno y otros.
La gestin de costos del proyecto debera considerar tambin las necesidades de informacin de los interesados diferentes interesados pueden medir los costos del proyecto de
diferentes maneras y en diferentes momentos. Por ejemplo, los costos de una adquisicin
pueden computarse en el momento en que se decide la compra, cuando se encarga el producto, cuando el producto es entregado, cuando el pago es efectuado o cuando el pago se
registra contablemente.
83
Figura 71 | 7.1.1.2
Captulo 7 Gestin de Costos del Proyecto
Figura 71. Visin General de la Gestin de Costos del Proyecto
84
Cuando los costos del proyecto se utilizan como parte de un sistema de recompensas y
reconocimientos, (tratado en la seccin 9.3.2.3), los costos controlables y los no controlables
deberan ser estimados y presupuestados separadamente para asegurar que las recompensas
reflejen el rendimiento real.
En algunos proyectos, especialmente en los de poca magnitud, la planificacin de recursos,
estimacin de costos y asignacin del presupuesto de costos estn tan estrechamente vinculadas que se las ve como un nico proceso (por ejemplo, puede ser realizado por un solo individuo en un lapso relativamente breve). Estos procesos se presentan aqu separadamente
porque las herramientas y tcnicas para cada uno de ellos son diferentes. La capacidad de
influenciar sobre los costos es mayor en las primeras etapas del proyecto y por ello es crtico
una temprana definicin del alcance, as como una exhaustiva identificacin de requerimientos
y la ejecucin de un plan seguro.
7.1 PLANIFICACIN DE RECURSOS

La planificacin de recursos implica la determinacin de qu recursos fsicos (personal,
equipamiento, materiales), qu cantidades de cada uno de ellos y en qu momento sern necesarios para realizar las actividades del proyecto. Debe estar estrechamente coordinada con la
estimacin de costos (descrita en la seccin 7.2). Por ejemplo:
El equipo de un proyecto de construccin necesitar conocer los cdigos de construccin
locales. Este conocimiento est frecuentemente disponible a travs de los proveedores
locales. Sin embargo, si el equipo local de trabajo carece de la experiencia necesaria para
el uso de tcnicas de construccin inusuales o especializadas, el costo adicional de un consultor puede ser la manera ms efectiva de asegurar familiaridad con los cdigos de
construccin locales.
Un equipo de diseo de un automvil debe conocer las tcnicas de ensamblaje automatizado ms recientes. Este conocimiento puede obtenerse contratando un consultor,
enviando un diseador a un seminario de robtica o incluyendo a alguna persona del
departamento de produccin como miembro del equipo.
7.1.1
.1
.2
Entradas a la Planificacin de Recursos

Estructura detallada del trabajo. La estructura detallada del trabajo (WBS, descrita en la seccin
5.3.3.1) identifica los entregables del proyecto y los procesos que necesitarn recursos, y, por
lo tanto, es la entrada primaria para la planificacin de recursos. Cualesquiera salidas relevantes
de otros procesos de planificacin deben ser provistos a travs de la WBS para asegurar un
control adecuado.
Informacin histrica. Si estuviere disponible, debe utilizarse la informacin histrica referente
a qu tipos de recursos fueron necesarios para trabajos similares en proyectos previos.
85
7.1.1.3 | 7.2.1.8
.3
.4
.5
.6
7.1.2
.1
.2
.3
7.1.3
.1
Enunciacin del alcance. La enunciacin del alcance (descrita en la seccin 5.2.3.1) contiene
la justificacin y los objetivos del proyecto. Ambos deben ser considerados explcitamente
durante la planificacin de recursos.
Descripcin del conjunto de recursos. El conocimiento de qu recursos (personal,
equipamientos, materiales) estarn disponibles es necesario para la planificacin de recursos.
El nivel de detalle y la especificidad de la descripcin del conjunto de recursos es variable. Por
ejemplo, durante las fases tempranas de un proyecto de diseo de ingeniera, el conjunto de
recursos puede incluir ingenieros jvenes e ingenieros experimentados en gran nmero.
Durante fases posteriores del mismo proyecto, sin embargo, el conjunto puede estar limitado
a aquellos individuos con mayores conocimientos sobre el proyecto como resultado de haber
trabajado en el mismo desde las fases tempranas.
Polticas organizacionales. Durante la planificacin de recursos, deben considerarse las polticas
de la organizacin ejecutante sobre incorporacin de personal y alquiler o adquisicin de
equipamientos.
Estimaciones de duracin de actividades. Tiempo de duracin de actividades (descritos en la
seccin 6.3.3.1).
Tcnicas y Herramientas para la Planificacin de Recursos

Juicio de expertos. El juicio de expertos se utiliza frecuentemente para evaluar las entradas a
este proceso. Este conocimiento puede ser provisto por cualquier individuo o grupo con
conocimiento especializado o capacitacin y est disponible de diversas fuentes, incluyendo:
Otras unidades dentro de la organizacin ejecutante.
Consultores.
Asociaciones tcnicas y profesionales.
Grupos de la industria.
Identificacin de alternativas. La identificacin de alternativas se trata en la seccin 5.2.2.3.
Software de gestin de proyectos. El software de gestin de proyectos tiene la capacidad de
ayudar a organizar grupos de recursos. Dependiendo de la complejidad del software, es
posible definir disponibilidad y porcentajes, as como calendarios de recursos.
Salidas de la Planificacin de Recursos

Requerimientos de recursos. La salida del proceso de planificacin de recursos es una descripcin de qu tipos de recursos son requeridos y en qu cantidades para cada elemento en el
nivel ms bajo de la WBS. Los requerimientos de recursos para niveles superiores dentro de la
WBS pueden calcularse basndose en los valores de los niveles inferiores. Estos recursos se
obtienen o bien a travs de la adquisicin de personal (descrita en la seccin 9.2) o a travs
de adquisiciones (descritas en el captulo 12).
7.2 ESTIMACIN DE COSTOS

La estimacin de costos implica el desarrollo de una aproximacin (estimacin) de los costos
de los recursos necesarios para completar las actividades del proyecto. Al estimar costos, el
estimador debe considerar las causas de las variaciones de la estimacin final para poder
realizar mejor la gestin del proyecto.
Cuando un proyecto se realiza bajo contrato, debe tenerse cuidado en distinguir entre estimacin de costo y fijacin del precio. La estimacin de costos implica evaluacin del resultado
cuantitativo cunto le costar a la organizacin ejecutante proveer el producto o servicio
comprometido? La fijacin del precio es una decisin de negocios cunto cobrar la organizacin ejecutante por el producto o servicio que utiliza la estimacin de costos como una
consideracin entre muchas otras.
86
La estimacin de costos incluye la identificacin y consideracin de varias alternativas de

costos. Por ejemplo, en la mayora de las reas de aplicacin, se considera que el trabajo adicional durante la fase de diseo puede potencialmente reducir el costo de la fase de produccin. El proceso de estimacin de costos debe considerar si el costo del trabajo adicional de
diseo ser compensado por las reducciones de costos esperadas.
7.2.1
.1
.2
.3
.4
.5
.6
.7
.8
Entradas para la Estimacin de Costos

Estructura detallada del trabajo. La WBS est descrita en la seccin 5.3.3.1. Se utiliza para organizar las estimaciones de costos y para asegurar que todo el trabajo identificado ha sido estimado.
Requerimientos de recursos. Los requerimientos de recursos se describen en la seccin 7.1.3.1.
Costo de los recursos. El individuo o grupo que prepara las estimaciones debe conocer los
costos unitarios (por ejemplo, costo del personal por hora, costo del material por volumen) de
cada recurso para poder calcular los costos del proyecto. Si los costos reales no se conocieran,
los costos unitarios mismos podran tener que ser estimados.
Estimaciones de duracin de actividades. Las estimaciones de duracin de actividades
(descritas en la seccin 6.3.3.1) afectarn las estimaciones de costos de cualquier proyecto en
el que se incluya una reserva para el costo de financiacin (o sea, los cargos por intereses).
Publicaciones de estimaciones. Datos comercialmente disponibles sobre estimacin de costos.
Informacin histrica. Existe frecuentemente informacin sobre los costos de muchas categoras de recursos disponible en una o ms de las siguientes fuentes:
puede mantener registros de resultados de proyectos previos suficientemente detallados
como para servir de ayuda en el desarrollo de estimaciones de costos. En algunas reas de
aplicacin, son miembros individuales del equipo quienes mantienen tales registros.
Bases de datos comerciales de estimaciones de costos frecuentemente hay informacin
comercialmente disponible.
Experiencia del equipo del proyecto los miembros individuales del equipo del proyecto
pueden recordar costos reales o estimaciones anteriores. Si bien tales experiencias pueden
ser tiles, generalmente son menos confiables que los resultados documentados.
Plan de cuentas. Un plan de cuentas describe la estructura de codificacin utilizada por la
organizacin ejecutante para reportar informacin financiera en los libros contables. Las estimaciones de costos del proyecto deben ser asignadas a la categora contable apropiada.
Riesgos. El equipo del proyecto debe considerar la informacin sobre riesgos (vase seccin
11.2.3.1) cuando est produciendo estimaciones de costos, puesto que los riesgos (sean stos
amenazas u oportunidades) pueden tener un impacto significativo sobre los costos. El equipo
del proyecto debe considerar en qu medida el efecto del riesgo debe incluirse en las estimaciones de costos para cada actividad.
87
7.2.2 | 7.3.1.2
7.2.2
.1
.2
.3
.4
.5
7.2.3
.1
88
Tcnicas y Herramientas de la Estimacin de Costos

Estimacin por analoga. Una estimacin por analoga, tambin llamada una estimacin de
arriba hacia abajo, significa utilizar los costos de un proyecto previo similar como base para
estimar los costos del presente proyecto. Se utiliza frecuentemente para estimar costos totales
de proyecto cuando la cantidad de informacin detallada sobre el proyecto es limitada (por
ejemplo, en fases tempranas). La estimacin por analoga es una forma de juicio de expertos
(descrito en la seccin 7.1.2.1).
Una estimacin por analoga es en general menos costosa que otras tcnicas, pero tambin
es generalmente menos precisa. Es ms confiable cuando a) los proyectos previos son similares en los hechos y no slo en apariencia y b) las personas o grupos que preparan la estimacin tienen los conocimientos y experiencia adecuados.
Modelos paramtricos. Los modelos paramtricos implican el uso de determinadas caractersticas (parmetros) del proyecto dentro de un modelo matemtico para predecir los costos
del proyecto. Los modelos pueden ser simples (la construccin de viviendas residenciales
costar una cierta cantidad por metro cuadrado edificado) o complejos (un modelo de costos
de desarrollo de software utiliza trece factores de ajuste separados, cada uno de los cuales tiene
entre cinco y siete puntos).
Tanto el costo como la precisin de los modelos paramtricos varan ampliamente. Es ms
probable que los resultados sean confiables cuando a) la informacin histrica utilizada para
desarrollar el modelo era precisa, b) los parmetros utilizados en el modelo son cuantificables
y c) el modelo es escalable (es decir, funciona bien tanto para un proyecto muy grande como
para uno muy pequeo).
Estimacin de abajo hacia arriba. Esta tcnica implica la estimacin del costo de las actividades
individuales o paquetes de trabajo y luego la integracin de las estimaciones individuales para
obtener el costo total.
El costo y la precisin de la estimacin de abajo hacia arriba estn determinados por el
tamao y la complejidad de las actividades individuales o paquetes de trabajo: actividades ms
pequeas incrementarn tanto la precisin como el costo del proceso de estimacin. El equipo
de direccin del proyecto debe sopesar el beneficio de la precisin adicional contra el costo
adicional.
Herramientas de computacin. Las herramientas de computacin, tales como el software de
gestin de proyectos, las hojas de clculo y las herramientas de simulacin y estadsticas, son
ampliamente utilizadas para asistir en el proceso de estimacin de costos. Tales productos
pueden simplificar el uso de las otras herramientas descritas ms arriba y por lo tanto facilitar
una rpida consideracin de muchas alternativas de costos.
Otros mtodos de estimacin de costos. Por ejemplo, anlisis de propuestas para licitaciones.
Salidas de la Estimacin de Costos

Estimaciones de costos. Las estimaciones de costos son evaluaciones cuantitativas de los
costos probables de los recursos necesarios para completar las actividades del proyecto. stos
pueden estar presentados sumaria o detalladamente.
Deben estimarse los costos para todos los recursos que sern imputados al proyecto. Esto
incluye, entre otros, los costos laborales, de materiales, de suministros y categoras especiales
tales como reservas por inflacin y reservas de costos.
Las estimaciones de costos generalmente estn expresadas en unidades monetarias
(dlares, euros, yen, etc.) para facilitar las comparaciones tanto dentro del proyecto como entre
diversos proyectos. En algunos casos, el estimador puede utilizar unidades de medida para
estimar costos, tales como horas de trabajo o das de trabajo, juntamente con sus estimaciones
de costos para facilitar el control por parte de la direccin. La estimacin de costos incluye
generalmente la consideracin de planes apropiados de respuesta a los riesgos, por ejemplo,
planes de contingencia.
.2
.3
Las estimaciones de costos pueden mejorarse a travs de refinamientos a medida que el

proyecto progresa para reflejar los detalles adicionales disponibles. En algunas reas de aplicacin existen guas sobre cundo tales refinamientos deben efectuarse y qu grado de precisin se espera. Por ejemplo, la Asociacin Internacional para el Avance de la Ingeniera de
Costos (AACE) ha identificado una progresin de cinco tipos de estimaciones en costos de
construccin durante la etapa de ingeniera: orden de magnitud, conceptual, preliminar, definitivo y control.
Informaciones adicionales. Las informaciones adicionales para las estimaciones de costos
deberan incluir:
Una enunciacin del alcance del trabajo estimado. Esto se provee frecuentemente con una
referencia a la WBS.
Documentacin de los fundamentos de la estimacin; es decir, cmo fue desarrollada.
Documentacin sobre cualesquiera hiptesis hechas.
Una indicacin sobre el rango de los posibles resultados; por ejemplo, $10,000 $1,000
para indicar que se espera que el costo de la actividad est entre $9,000 y $11,000.
La cantidad y el tipo de informacin adicional varan dependiendo del rea de aplicacin.
Incluso la conservacin de notas manuscritas puede resultar valiosa para una mejor comprensin de cmo se desarroll la estimacin.
Plan de gestin de costos. El plan de gestin de costos describe cmo las variaciones de
costos sern manejadas (por ejemplo, diferentes respuestas a problemas mayores que a problemas menores). Dependiendo de las necesidades de los interesados, un plan de gestin de
costos puede ser formal o informal, muy detallado o ampliamente esbozado. El plan de gestin
de costos es un elemento subsidiario del plan del proyecto (tratado en la seccin 4.1.3.1).
7.3 ASIGNACIN DEL PRESUPUESTO DE COSTOS

La asignacin del presupuesto de costos implica la asignacin de las estimaciones de costos
generales a actividades o paquetes de trabajo individuales a fin de establecer un plan de referencia de costos para medir el rendimiento del proyecto. Si bien las condiciones de la realidad
pueden determinar que las estimaciones se hagan despus de que el presupuesto ha sido
aprobado, las estimaciones deberan hacerse en lo posible antes del requerimiento del presupuesto.
7.3.1
.1
.2
Entradas a la Asignacin del Presupuesto de Costos

Estimaciones de costos. Las estimaciones de costos estn descritas en la seccin 7.2.3.1.
Estructura detallada del trabajo. La WBS (descrita en la seccin 5.3.3.1) identifica los elementos
del proyecto a los cuales se les asignarn costos.
89
Figura 72 | 7.4.2.2
Figura 72. Grfico Ilustrativo de un Plan de Referencia de Costos
.3
.4
7.3.2
.1
7.3.3
.1
Cronograma del proyecto. El cronograma del proyecto (descrito en la seccin 6.4.3.1) incluye
las fechas esperadas de inicio y fin para los componentes del proyecto a los cuales se asignarn
costos. Esta informacin es necesaria para imputar los costos al perodo en el cual se efectuarn los mismos.
Plan de gestin de riesgos. El plan de gestin de riesgos se trata en la seccin 11.1.3. Adems,
el plan de gestin de riesgos incluye a menudo una contingencia de costos, que puede ser
determinada sobre la base de la precisin esperada de la estimacin.
Tcnicas y Herramientas para la Asignacin del Presupuesto de Costos

Tcnicas y herramientas para la asignacin del presupuesto de costos. Las herramientas y tcnicas descritas en la seccin 7.2.2 para desarrollar estimaciones de costos se utilizan tambin
para el desarrollo de presupuestos de actividades o paquetes de trabajo.
Salidas de la Asignacin del Presupuesto de Costos

Plan de referencia de costos. El plan de referencia de costos es un grfico en el tiempo del
presupuesto que se utilizar para medir y supervisar la evolucin de los costos del proyecto.
Se desarrolla sumando los costos estimados por perodo y usualmente se lo representa por una
curva S, como se ilustra en la figura 7-2.
Muchos proyectos, especialmente grandes proyectos, pueden tener mltiples planes de
referencia para medir diferentes aspectos de la evolucin de los costos. Por ejemplo, un plan
de gastos o una previsin de desembolsos es un plan de referencia de costos para medir erogaciones.
7.4 CONTROL DE COSTOS

El control de costos tiene por objetivos a) influenciar los factores que crean cambios en el plan
de referencia de costos para asegurar que los cambios estn acordados, b) determinar que el
plan de referencia de costos ha cambiado y c) administrar los cambios cuando y segn
ocurran. El control de costos incluye:
90
Supervisar la evolucin de costos para detectar cualquier variacin con respecto al plan.
Asegurar que todos los cambios apropiados sean registrados exactamente en el plan de
referencia de costos.
Prevenir que cambios incorrectos, inapropiados o no autorizados sean incluidos en el plan
de referencia de costos.
Informar a los interesados sobre los cambios autorizados.
Efectuar acciones para mantener los costos esperados dentro de lmites aceptables.
El control de costos incluye la bsqueda de los porqu de las variaciones, tanto positivas
como negativas. Debe estar completamente integrado con los otros procesos de control (control de cambios de alcance, control del cronograma, control de calidad y otros, segn se trata
en la seccin 4.3). Por ejemplo, una respuesta inapropiada a variaciones de costos puede ocasionar problemas de calidad o de cronograma, o producir un nivel de riesgo inaceptable en
una etapa ulterior del proyecto.
7.4.1
.1
.2
.3
.4
7.4.2
.1
.2
Entradas al Control de Costos

Plan de referencia de costos. El plan de referencia de costos est descrito en la seccin 7.3.3.1.
Informes de rendimiento. Los informes de rendimiento (tratados en la seccin 10.3.3.1)
proveen informacin sobre el alcance del proyecto y eficiencia de los costos, por ejemplo qu
presupuestos se han cumplido y cules no. Los informes de rendimiento pueden alertar al
equipo del proyecto sobre puntos que pueden causar problemas en el futuro.
Requerimientos de cambio. Los requerimientos de cambio pueden ocurrir de diversas formas
oral o escrita, directa o indirecta, externa o internamente iniciada e impuesta legalmente u
opcional. Los cambios pueden requerir incrementos del presupuesto o pueden permitir
reducirlo.
Plan de gestin de costos. El plan de gestin de costos est descrito en la seccin 7.2.3.3.
Tcnicas y Herramientas para la Gestin de Costos

Sistema de control de cambios de costos. Un sistema de control de cambios de costos define
los procedimientos a travs de los cuales el plan de referencia de costos puede ser modificado.
Incluye la documentacin, los sistemas de seguimiento y los niveles de aprobacin necesarios
para la autorizacin de cambios. El sistema de control de cambios de costos debera estar integrado en el sistema de control global de cambios tratado en la seccin 4.3.
Medicin del rendimiento. Las tcnicas de medicin del rendimiento, descritas en la seccin
10.3.2, ayudan a evaluar la magnitud de cualesquiera variaciones que ocurran. La Gestin del
Valor del Trabajo Realizado (EVM), descrita en las secciones 7.4.2.3 y 10.3.2.4, es particularmente til para el control de costos. Una importante parte del control de costos es determinar
qu est causando una variacin y decidir si la variacin requiere una accin correctiva.
91
7.4.2.3 | 7.4.3.6
.3
.4
.5
7.4.3
.1
.2
.3
.4
92
Gestin del Valor del Trabajo Realizado (EVM). Todos los Planes de Cuentas de Control (CAPs)
de EVM deben evaluar continuamente el rendimiento del proyecto a travs de las relaciones
entre tres variables independientes: 1) El Valor Planeado, el trabajo fsico previsto, incluyendo
el valor estimado de este trabajo (anteriormente llamado Costo Presupuestado del Trabajo Programado [BCWS]) comparado con 2) el Valor del Trabajo Realizado, el trabajo fsico realizado
incluyendo el valor estimado de este trabajo (anteriormente llamado Costo Presupuestado del
Trabajo Realizado [BCWP]) y con 3) el Costo Real (antes denominado Costo Real del Trabajo
Realizado [ACWP]), el costo en que se incurri para obtener el Valor del Trabajo Realizado.
La relacin de 2) el Valor del Trabajo Realizado menos 1) el Valor Planeado constituye la
Variacin del Cronograma (SV). La relacin de 2) el Valor del Trabajo Realizado menos 3) el
Costo Real constituye la Variacin del Costo (CV) del proyecto. Vase tambin la seccin
10.3.2.4.
Planificacin adicional. Pocos proyectos se desenvuelven exactamente como se los haba planificado. Los cambios prospectivos pueden requerir revisiones de las estimaciones de costos,
nuevas estimaciones de costos o enfoques alternativos.
Herramientas de computacin. Las herramientas de computacin, como el software de gestin
de proyectos y las hojas de clculo, se utilizan a menudo para efectuar el seguimiento de los
costos planificados comparados con los costos reales y para efectuar previsiones sobre el
efecto de los cambios de costos.
Salidas del Control de Costos

Estimaciones de costos revisadas. Las estimaciones de costos revisadas son cambios a la informacin de costos utilizada para la gestin del proyecto. Los interesados deben ser notificados
segn sea necesario. Las estimaciones revisadas de costos pueden o no requerir ajustes de
otros aspectos del plan del proyecto.
Actualizaciones del presupuesto. Las actualizaciones del presupuesto son una categora especial de estimaciones de costos revisadas. Las actualizaciones de presupuesto son cambios a un
plan de referencia de costos aprobado. Estos nmeros son generalmente revisados slo como
respuesta a cambios en el alcance. En algunos casos, las variaciones de costos pueden ser tan
severas que un nuevo plan de referencia se hace necesario para dar una medida realista del
rendimiento.
Accin correctiva. Una accin correctiva es cualquier medida tomada para que el rendimiento
esperado futuro est de acuerdo con el plan del proyecto.
Estimacin al trmino. La estimacin al trmino (EAC) es una previsin de los costos totales
ms probables del proyecto basada en el rendimiento y en la cuantificacin de riesgos descritas
en la seccin 11.4.3. Las tcnicas de previsin ms comunes son una variante de:
EAC = Costo real actual ms una nueva estimacin para todo el resto del trabajo. Este
enfoque se utiliza ms frecuentemente cuando el rendimiento pasado muestra que las
hiptesis originales de estimacin eran fundamentalmente errneas, o cuando estas
hiptesis no son ya relevantes debido a una modificacin en las condiciones. Frmula:
EAC = AC + ETC.
EAC = Costo real actual ms el presupuesto restante (BAC EV). Este enfoque se utiliza
ms frecuentemente cuando las variaciones actuales se consideran atpicas y las expectativas del equipo de gestin del proyecto son similares variaciones que no ocurrirn en el
futuro. Frmula: EAC = AC + BAC EV.
EAC = Costo real actual ms el presupuesto restante (BAC EV) modificado por un factor
de eficiencia, frecuentemente el ndice acumulativo de rendimiento de los costos (CPI). Este
enfoque se utiliza ms frecuentemente cuando las variaciones actuales son vistas como
tpicas de futuras variaciones. Frmula: EAC = (AC + (BAC EV)/CPI)este CPI es el CPI
acumulativo.
.5
.6
Cada uno de estos enfoques puede ser el correcto para un proyecto dado y pueden dar
al equipo de direccin del proyecto una seal si las proyecciones de EAC exceden los lmites
de tolerancia aceptables.
Cierre del proyecto. Es necesario desarrollar procesos y procedimientos para el cierre o cancelacin de proyectos. Por ejemplo, el documento SOP 98-1 emitido por el Instituto Americano
de Contadores Pblicos Certificados (AICPA) requiere que todos los costos de un proyecto de
tecnologa fallado sean cargados en el trimestre en el cual se cancel el proyecto.
Lecciones aprendidas. Las causas de variaciones, los razonamientos subyacentes a las
acciones correctivas tomadas y otros tipos de lecciones aprendidas en el proceso de control de
costos deben ser documentados a fin de que pasen a formar parte de la base de datos histrica
para el presente proyecto y para otros proyectos de la organizacin (vase seccin 4.3.3.3).
93
Captulo 8
Gestin de la Calidad del

Proyecto
La gestin de la calidad del proyecto incluye los procesos requeridos para asegurar que el
proyecto satisfar las necesidades por las cuales fue iniciado. Incluye todas las actividades
derivadas de la funcin gerencial con las que se establece la poltica de calidad, los objetivos
y las responsabilidades, as como su implementacin a travs de la planificacin de la calidad,
el aseguramiento de la calidad, el control de calidad y la mejora de calidad, todo en el marco
del sistema de calidad (1). La figura 8-1 proporciona una visin general de los siguientes procesos principales de la gestin de la calidad del proyecto:
8.1 Planificacin de la Calidad identificacin de los estndares de calidad relevantes
para el proyecto y determinacin de cmo satisfacerlos.
8.2 Aseguramiento de la Calidad evaluacin del desempeo completo del proyecto de
manera regular, de modo de brindar confianza en que el proyecto satisfar los estndares
de calidad relevantes.
8.3 Control de Calidad verificacin de los resultados especficos del proyecto para determinar si cumplen con los estndares de calidad relevantes e identificacin de modos de
eliminar las causas del desempeo insatisfactorio.
interacciones entre procesos son discutidas en detalle en el captulo 3.
El enfoque bsico de la gestin de la calidad, descrito en esta seccin, tiene por finalidad
ser compatible con el establecido por la International Organization for Standardization (ISO)
y detallado en las series ISO 9000 y 10000 de dichos estndares y guas de aplicacin. Este
enfoque generalizado pretende ser compatible tambin con a) enfoques personales de la
gestin de calidad, como los recomendados por Deming, Juran, Crosby y otros, y b) enfoques
no personales, pero conceptuales tales como gerencia de calidad total (TQM), mejora continua
y otros.
La gestin de la calidad del proyecto debe apuntar tanto a la gestin del proyecto, como al
producto entregado por el proyecto. El trmino genrico producto a veces se usa en la literatura relacionada con calidad para referirse tanto a bienes como a servicios. El no-cumplimiento
de los requisitos de calidad, en cualquiera de las dos dimensiones, puede tener serias consecuencias negativas para algunos, o para todos los interesados en el proyecto. Por ejemplo:
95
Figura 81 | 8.1
Captulo 8 Gestin de la Calidad del Proyecto
Figura 81. Visin General de la Gestin de la Calidad del Proyecto
Cumplir los requisitos del cliente sobrecargando de trabajo al equipo del proyecto puede
producir consecuencias negativas, tales como un creciente agotamiento del personal.
Cumplir los objetivos de plazos del proyecto ejecutando apresuradamente las inspecciones
planificadas de calidad puede producir consecuencias negativas cuando no se detectan los
errores.
Calidad es la totalidad de las caractersticas de una entidad que le confieren la aptitud para
satisfacer las necesidades establecidas o implcitas (2). Las necesidades establecidas o implcitas son las entradas para establecer los requisitos del proyecto. Un aspecto crtico de la gestin
de la calidad en el contexto del proyecto es la necesidad de transformar las necesidades
implcitas en requerimientos a travs de la gestin del alcance del proyecto, descrita en el
captulo 5.
El equipo de direccin del proyecto debe cuidar de no confundir calidad con grado. El
grado es una categora o rango asignado a entidades que tienen el mismo uso funcional, pero
diferentes caractersticas tcnicas (3). Baja calidad es siempre un problema; bajo grado puede
no serlo. Por ejemplo, un producto de software puede ser de alta calidad (sin defectos obvios,
manual legible) y bajo grado (un nmero limitado de funciones), o bien de baja calidad (con
muchos defectos, documentacin del usuario deficientemente organizada) y alto grado
(numerosas funciones). La determinacin y entrega de los niveles requeridos, tanto de calidad
como de grado, es responsabilidad del director de proyecto y del equipo de direccin del
proyecto.
El equipo de direccin del proyecto debe tener en cuenta que la gestin moderna de calidad se complementa con la direccin del proyecto. Por ejemplo, ambas disciplinas reconocen
la importancia de:
96
Satisfaccin del cliente entender, manejar e influenciar las necesidades de modo de

cumplir las expectativas del cliente. Esto requiere una combinacin de la conformidad con
los requerimientos (el proyecto debe producir lo que se comprometi a producir) con la
adecuacin al uso (el producto o servicio debe satisfacer las necesidades reales).
Priorizar la prevencin sobre la inspeccin el costo de prevenir errores es siempre
mucho menor que el costo de corregirlos cuando son detectados por la inspeccin.
Responsabilidad de la gerencia el xito requiere la participacin de todos los miembros
del equipo, pero es responsabilidad de la gerencia proveer los recursos necesarios para
lograr dicho xito.
Fases conformadas por procesos el ciclo continuo planificarejecutarcontrolar actuar,
descrito por Deming y otros, es muy similar a la combinacin de fases y procesos analizados en el captulo 3, Procesos de Direccin de Proyectos.
Adicionalmente, las iniciativas de mejora de calidad llevadas a cabo por la organizacin ejecutante del proyecto (por ejemplo TQM, Mejora continua y otras) pueden mejorar la calidad
de la direccin del proyecto, as como la calidad del producto del proyecto.
Sin embargo, existe una diferencia importante que el equipo de direccin del proyecto
debe tener en cuenta especialmente la naturaleza temporaria del proyecto, lo cual implica
que las inversiones en mejoras de la calidad del producto, especialmente en lo que se refiere
a prevencin y evaluacin de defectos, a menudo deben ser absorbidas por la organizacin
ejecutante del proyecto, puesto que el proyecto puede no durar lo suficiente como para
recoger los beneficios.
8.1 PLANIFICACIN DE LA CALIDAD

La planificacin de la calidad implica identificar qu estndares de calidad son relevantes para
el proyecto y luego determinar cmo satisfacerlos. Es uno de los procesos facilitadores clave
durante la planificacin del proyecto (vase la seccin 3.3.2, Procesos de planificacin) y
debera ser realizado regularmente y en paralelo con los dems procesos de planificacin del
proyecto. Por ejemplo, los cambios en el producto del proyecto, requeridos para cumplir los
estndares de calidad, pueden requerir ajustes en el costo o en el cronograma o la calidad
deseada del producto puede requerir el anlisis detallado del riesgo de un problema identificado. Antes del desarrollo de las series de las normas ISO 9000, las actividades descritas en esta
seccin como planificacin de la calidad eran generalmente analizadas como parte del aseguramiento de calidad.
Las tcnicas de planificacin de la calidad analizadas en esta seccin son las ms frecuentemente usadas en proyectos. Existen muchas otras que pueden ser tiles en ciertos
proyectos o en algunas reas de aplicacin.
El equipo del proyecto debe tambin tener en cuenta uno de los principios fundamentales
de la gestin de la calidad moderna la calidad se planifica, no se inspecciona.
97
8.1.1 | 8.1.3.1
8.1.1
.1
.2
.3
.4
.5
8.1.2
.1
.2
.3
98
Entradas a la Planificacin de la Calidad

Poltica de calidad. La poltica de calidad es la totalidad de los propsitos y principios de una
organizacin relacionados con la calidad y expresados formalmente por la alta direccin (4).
La poltica de calidad de la organizacin ejecutante puede a menudo ser adoptada como est
para su aplicacin en el proyecto. Sin embargo, si la organizacin carece de una poltica formal
de calidad, o si el proyecto es realizado por varias organizaciones conjuntamente (como en
una asociacin transitoria), entonces el equipo de direccin del proyecto deber desarrollar
una poltica de calidad para el proyecto.
Independientemente del origen de la poltica de calidad, el equipo de direccin del
proyecto es responsable de asegurar que los interesados en el proyecto tengan pleno
conocimiento de la misma (por ejemplo, a travs de la distribucin apropiada de la informacin, como se describe en la Seccin 10.2).
Enunciacin del alcance. La enunciacin del alcance del proyecto (descrita en la seccin
5.2.3.1) es una entrada clave a la planificacin de la calidad, dado que brinda informacin
documentada sobre los principales resultados del proyecto, as como sobre sus objetivos que
sirven para definir requerimientos importantes de los interesados en el proyecto.
Descripcin del producto. Si bien los elementos de la descripcin del producto (detallados en
la seccin 5.1.1.1) pueden estar contenidos en la enunciacin del alcance, a menudo la descripcin del producto contiene detalles de aspectos tcnicos y otras cuestiones que pueden afectar
la planificacin de la calidad.
Estndares y regulaciones. El equipo de direccin del proyecto debe tener en cuenta los
estndares y regulaciones de cada rea de aplicacin especfica que puedan afectar al proyecto.
En la seccin 2.5.1. se hace un anlisis sobre estndares y regulaciones.
Otras salidas de procesos. Adicionalmente a la enunciacin del alcance y a la descripcin del
producto, los procesos de otras reas de conocimiento pueden producir resultados que
deberan ser consideradas como parte de la planificacin de la calidad. Por ejemplo, la planificacin de adquisiciones (descrita en la seccin 12.1) podra identificar los requerimientos de
calidad del contratista, los que deberan reflejarse en el plan total de gestin de la calidad.
Tcnicas y Herramientas para la Planificacin de la Calidad

Anlisis costo/beneficio. El proceso de planificacin de la calidad debe considerar las relaciones costo/beneficio, segn se describen en la seccin 5.2.2.2. El beneficio primordial de
cumplir con los requisitos de calidad es un menor reproceso, lo cual significa mayor productividad, menores costos y mayor satisfaccin de los interesados. El costo primario de cumplir
los requisitos de calidad son los gastos asociados con las actividades de gestin de la calidad
en el proyecto. Un axioma de la disciplina de la gestin de la calidad, es que los beneficios
superan a los costos.
Estudios comparativos (Benchmarking). Un estudio comparativo implica cotejar prcticas de
proyecto, reales o planificadas, con aqullas de otros proyectos para generar ideas de mejora
y proveer un estndar con el cual medir el desempeo. Estos otros proyectos pueden ser de
la organizacin ejecutora del proyecto o externos a ella, y pueden ser dentro de la misma rea
de aplicacin o de otra distinta.
Diagramas de flujo. Un diagrama de flujo es un diagrama que muestra cmo se relacionan
varios elementos de un sistema. Las tcnicas de diagrama de flujo comnmente usadas en la
gestin de calidad incluyen:
Diagrama causa-efecto, tambin llamado diagrama Ishikawa o diagrama de espina de
pescado, que ilustra cmo varios factores pueden vincularse a potenciales problemas o
efectos. La figura 8-2 es un ejemplo de un diagrama genrico de causa-efecto.
Diagramas de flujo del sistema o proceso, que muestra cmo se relacionan varios elementos
de un sistema. La figura 8-3 es un ejemplo de un diagrama de flujo del proceso de revisin
de diseo.
Figura 82. Diagrama de Causa-Efecto
.4
.5
8.1.3
.1
El diagrama de flujo puede servir al equipo del proyecto para anticipar cules pueden ser
y dnde pueden ocurrir problemas de calidad y, de este modo, desarrollar soluciones para su
tratamiento.
Diseo de experimentos. El diseo de experimentos es un mtodo estadstico que permite
identificar qu factores pueden influenciar sobre determinadas variables. Esta tcnica se aplica
ms frecuentemente al producto del proyecto (por ejemplo, los diseadores de automviles
pueden querer determinar qu combinacin de suspensin y neumticos producir las mejores
caractersticas de rodaje a un costo razonable).
Sin embargo, tambin puede aplicarse a aspectos de la direccin de proyectos, tales como
los intercambios de costo y tiempo. Por ejemplo, los ingenieros experimentados tendrn un
costo mayor que los que tienen poca experiencia, pero tambin podrn completar la tarea asignada en un tiempo menor. Un diseo de experimento apropiado (en este caso, calcular los
costos del proyecto y las duraciones para varias combinaciones de ingenieros experimentados
y sin mayor experiencia) permitir a menudo establecer una solucin ptima a partir de un
nmero relativamente limitado de casos.
Costo de la calidad. El costo de calidad se refiere al costo total de todos los esfuerzos para
lograr la calidad del producto/servicio e incluye todos los trabajos para asegurar la conformidad con los requerimientos, as como todo trabajo resultante por las no-conformidades
con los requeri-mientos. Existen tres tipos de costos en que se incurre: costos de prevencin,
costos de evalua-cin y costos por fallas, este ltimo subdividido en costos internos y externos.
Salidas de la Planificacin de la Calidad

Plan de gestin de la calidad. El plan de gestin de la calidad debe describir cmo el equipo
de direccin del proyecto implementar su poltica de calidad. Segn la terminologa ISO 9000,
debera describir el sistema de calidad del proyecto: la estructura organizativa, responsabilidades, procedimientos, procesos y recursos necesarios para implementar la gestin de la calidad (5).
El plan de gestin de la calidad provee una entrada al plan general del proyecto (analizado
en la seccin 4.1, Desarrollo del plan del proyecto) y debe enfocar el control de calidad, el aseguramiento de calidad y la mejora de calidad para el proyecto.
El plan de gestin de la calidad puede ser formal o informal, altamente detallado o ampliamente bosquejado, segn los requisitos del proyecto.
99
Figura 8-3 | 8.2.2.2
Figura 83. Ejemplo de Diagrama de Flujo de un Proceso
.2
100
Definiciones operativas. Una definicin operativa define, en trminos muy especficos, en qu

consiste un tem determinado y cmo es medido por el proceso de control de calidad. Por
ejemplo, no es suficiente decir que cumplir la fechas planificadas es un indicador de gestin
de la calidad; el equipo de direccin del proyecto debe tambin indicar si cada actividad debe
comenzar a tiempo o slo finalizar a tiempo; si sern medidas las actividades individuales, o
slo ciertos entregables y, si es as, cules. Las definiciones operativas son tambin designadas
como mtricas en algunas reas de aplicacin.
.3
.4
Listas de verificacin. Una lista de verificacin es una herramienta estructurada, generalmente

especfica del artculo, utilizada para comprobar que un grupo de pasos requeridos ha sido llevado a cabo. Las listas de verificacin pueden ser simples o complejas. Se expresan con frases
imperativas (Haga esto!) o interrogativas (Ha hecho usted esto?). Muchas organizaciones
han estandarizado las listas de verificacin disponibles, de modo de asegurar consistencia en
tareas llevadas a cabo frecuentemente. En algunas reas de aplicacin hay listas de verificacin
disponibles de asociaciones profesionales o provenientes de proveedores comerciales.
Entradas a otros procesos. El proceso de planificacin de la calidad puede identificar un
requerimiento de alguna actividad adicional en otra rea.
8.2 ASEGURAMIENTO DE LA CALIDAD

El aseguramiento de la calidad consiste de todas las actividades, planificadas y sistemticas,
implementadas en el marco del sistema de calidad, requeridas para brindar confianza en que
el proyecto va a satisfacer los estndares de calidad relevantes (6). Esto debera ser realizado
durante todo el proyecto. Antes del desarrollo las series ISO 9000, las actividades descritas
como planificacin de la calidad eran ampliamente incluidas como parte del aseguramiento de
la calidad.
El aseguramiento de la calidad es generalmente provisto por un Departamento de Aseguramiento de la Calidad o algn sector de la organizacin denominado en forma similar, aunque
no necesariamente debe ser as.
Este aseguramiento debe ser brindado al equipo de direccin del proyecto y al nivel gerencial de la organizacin ejecutante del proyecto (aseguramiento de la calidad interno), o bien
debe ser brindado al cliente y a otros que no estn activamente involucrados en el trabajo del
proyecto (aseguramiento de la calidad externo).
8.2.1
.1
.2
.3
8.2.2
.1
.2
Entradas al Aseguramiento de la Calidad

Plan de gestin de la calidad. El plan de gestin de la calidad es analizado en la seccin
8.1.3.1.
Resultados de las mediciones de control de calidad. Las mediciones de control de calidad son
registros de ensayos y mediciones de control de calidad en un formato til para comparaciones
y anlisis.
Definiciones operativas. Las definiciones operativas son analizadas en la seccin 8.1.3.2
Tcnicas y Herramientas para el Aseguramiento de la Calidad

Tcnicas y herramientas de la planificacin de la calidad. Las tcnicas y herramientas, analizadas en la seccin 8.1.2, pueden ser usadas tambin para el aseguramiento de la calidad.
Auditoras de calidad. Una auditora de calidad es una revisin estructurada de otras actividades de gestin de la calidad. El objetivo de una auditora de calidad es identificar las
101
8.2.3 | 8.3.2.4
lecciones aprendidas que puedan mejorar el desempeo del proyecto actual o de otros
proyectos de la organizacin ejecutante. Las auditoras de calidad pueden ser planificadas o
aleatorias y pueden ser realizadas por auditores internos adecuadamente entrenados o por terceras partes, tales como los organismos de certificacin de sistemas de calidad.
8.2.3
.1
Salidas del Aseguramiento de la Calidad

Mejora de calidad. La mejora de calidad implica tomar acciones para incrementar la efectividad
y eficiencia del proyecto para brindar beneficios adicionales a los interesados en el proyecto.
En muchos casos, implementar la mejora de calidad requerir preparar requerimientos de
cambio o la realizacin de acciones correctivas y ser manejada de acuerdo con los procedimientos de control de cambios integrado, segn ha sido descrito en la seccin 4.3.
8.3 CONTROL DE CALIDAD

El control de calidad implica verificar los resultados especficos del proyecto para determinar
si stos cumplen con los estndares de calidad relevantes e identificar maneras de eliminar las
causas de los resultados insatisfactorios. Esto debe ser realizado durante todo el proyecto. Los
resultados del proyecto incluyen tanto los referidos al producto del proyecto tales como los
entregables, y a los referidos a la direccin del proyecto, tales como los desempeos de costo
y cronograma. El control de calidad es, a menudo, llevado a cabo por un departamento de
control de calidad o por un sector de la organizacin con una denominacin similar, aunque
no necesariamente debe ser as.
El equipo de direccin del proyecto debe tener un conocimiento prctico de control
estadstico de calidad, especialmente muestreo y probabilidad, para ayudar a evaluar los resultados del control de calidad. Entre otros aspectos, al equipo puede resultarle til conocer las
diferencias entre:
Prevencin (mantener los errores fuera del proceso) e inspeccin (evitar que los errores
lleguen a manos del cliente).
Muestreo por atributos (los resultados conforman o no) y muestreo por variables (los resultados son clasificados segn una escala continua que mide el grado de conformidad).
Causas especiales (sucesos inesperados) y causas aleatorias (variacin normal del proceso).
Tolerancias (el resultado es aceptable si cae dentro del rango especificado por la tolerancia)
y lmites de control (el proceso est bajo control si los resultados caen dentro de los lmites
de control).
102
8.3.1
.1
.2
.3
.4
8.3.2
.1
.2
.3
.4
Entradas al Control de Calidad

Resultados de los trabajos. Los resultados de los trabajos (descritos en la seccin 4.2.3.1)
incluyen tanto los resultados del proceso como los resultados del producto. La informacin
acerca de los resultados planificados o esperados (por el plan del proyecto) debe estar
disponible junto con la informacin de los resultados reales.
Plan de gestin de la calidad. El plan de gestin de la calidad es descrito en la seccin 8.1.3.1.
Definiciones operativas. Las definiciones operativas son descritas en la seccin 8.1.3.2.
Listas de verificacin. Las listas de verificacin son descritas en la seccin 8.1.3.3.
Tcnicas y Herramientas para el Control de Calidad

Inspeccin. La inspeccin incluye actividades tales como medir, examinar y ensayar, que se
llevan a cabo para determinar si los resultados son conforme a los requerimientos. Las inspecciones pueden llevarse a cabo en cualquier nivel (por ejemplo, pueden inspeccionarse los
resultados de una simple actividad o bien el producto final del proyecto). Las inspecciones son
denominadas de varias maneras, como revisiones, revisiones de producto, auditoras y revisiones generales; en algunas reas de aplicacin, estos trminos adquieren significados concretos y especficos.
Grficos de control. Los grficos de control son representaciones grficas de los resultados de
un proceso a lo largo del tiempo. Se utilizan para establecer si un proceso se encuentra bajo
control (por ejemplo, son las diferencias en los resultados producidas por variaciones aleatorias o se estn produciendo sucesos inusuales cuyas causas deben ser detectadas y eliminadas?). Cuando un proceso est bajo control, ste no debera ser ajustado. Un proceso debe
ser cambiado para proveer mejoras, pero no debera ser ajustado si est bajo control.
Los grficos de control pueden ser usados para controlar cualquier tipo de variable de
salida. Si bien su mayor aplicacin es para actividades repetitivas, tales como lotes de produccin, los grficos de control pueden usarse tambin para supervisar las variaciones de costo
y cronograma, los volmenes y frecuencia de las modificaciones del alcance, los errores en los
documentos del proyecto u otros resultados de gestin que permitan establecer si el proceso
de direccin del proyecto est bajo control. La figura 8-4 es un grfico de control del desempeo del cronograma del proyecto.
Diagramas de Pareto. Un diagrama de Pareto es un histograma, ordenado por la frecuencia
de ocurrencia, que muestra cuntos resultados fueron generados por cada tipo o categora de
una causa identificada (vase la figura 8-5). El ordenamiento por categora es usado como
gua para la accin correctivael equipo del proyecto debe tomar acciones para corregir
primero los problemas que estn provocando el mayor nmero de defectos. Los diagramas de
Pareto estn conceptualmente relacionados con la ley de Pareto, que sostiene que un nmero
relativamente menor de causas provocar generalmente el mayor nmero de los problemas
o defectos. Esto se conoce comnmente como el principio 80/20, donde el 80 por ciento de
los problemas se debe al 20 por ciento de las causas.
Muestreo estadstico. El muestreo estadstico implica elegir parte de una poblacin que se
desea inspeccionar (por ejemplo, elegir al azar diez planos de ingeniera de una lista de setenta
y cinco). Un muestreo apropiado, a menudo, puede reducir el costo de control de calidad. Hay
un cuerpo de conocimiento sustancial sobre muestreo estadstico; en algunas reas de aplicacin, es necesario que el equipo de direccin del proyecto est familiarizado con una variedad de tcnicas de muestreo.
103
Figura 84. Grfico de Control del Rendimiento del Cronograma del Proyecto
.5
.6
8.3.3
.1
.2
.3
.4
.5
104
Diagramas de flujo. Los diagramas de flujo se describen en la seccin 8.1.2.3. Los diagramas
de flujo son usados en control de calidad para ayudar a analizar cmo ocurren los problemas.
Anlisis de tendencias. El anlisis de tendencias implica el uso de tcnicas matemticas para
predecir resultados futuros sobre la base de resultados histricos. El anlisis de tendencias es
usado a menudo para verificar:
Desempeo tcnico cuntos errores o defectos han sido identificados, cuntos permanecen an sin correccin.
Desempeo de costo y cronograma cuntas actividades, en cada perodo, han sido completadas con variaciones significativas.
Salidas de Control de Calidad

Mejora de la calidad. La mejora de calidad se describe en la seccin 8.2.3.1.
Decisiones de aceptacin. Los artculos inspeccionados sern aceptados o bien rechazados.
Los artculos rechazados pueden requerir reproceso (descrito en la seccin 8.3.3.3).
Reproceso. El reproceso es la accin llevada cabo para lograr que un artculo defectuoso o
no conforme, cumpla los requerimientos o especificaciones. El reproceso, especialmente el
reproceso imprevisto, es una de las causas frecuentes de sobrecostos en el proyecto, en la
mayora de las reas de aplicacin. El equipo de proyecto debe hacer todo esfuerzo razonable
para minimizar el reproceso.
Listas de verificacin completadas. Vase la seccin 8.1.3.3. Cuando se usan listas de verificacin, las listas de verificacin completadas deberan constituirse en parte de los registros del
proyecto.
Ajustes del proceso. Los ajustes de proceso implican acciones correctivas o preventivas
inmediatas, como resultado de las mediciones de control de calidad. En algunos casos, los
ajustes de proceso pueden requerir ser manejados de acuerdo con el control de cambios integrado, que se describe en la seccin 4.3.
Figura 85. Diagrama de Pareto
105
Captulo 9
Gestin de los Recursos

Humanos del Proyecto
La gestin de los recursos humanos del proyecto incluye los procesos necesarios para realizar
el uso ms efectivo de las personas involucradas en el mismo. Incluye a todos los interesados
en el proyecto (patrocinadores, clientes, usuarios, contribuyentes individuales y otros) descritos
en la seccin 2.2. La figura 9-1 proporciona una visin general de los siguientes procesos principales:
9.1 Planificacin de la Organizacin identificacin, documentacin y asignacin de
roles, responsabilidades y lneas de reporte.
9.2 Adquisicin de Personal lograr que los recursos humanos necesarios sean asignados y trabajen en el proyecto.
9.3 Desarrollo del Equipo desarrollo de las aptitudes individuales y de grupo para mejorar
el rendimiento del proyecto.
Hay gran cantidad de literatura sobre la conduccin de personas en un contexto operativo
funcional. Algunos de las muchos temas pueden ser:
Liderazgo, comunicacin, negociacin y otros descritos en la seccin 2.4, Habilidades clave
de gestin en general.
Delegacin, motivacin, capacitacin, tutelaje y otros temas relacionados con la conduccin de individuos.
Desarrollo de equipos, resolucin de conflictos y otros temas relacionados con la conduccin de grupos.
Evaluacin del desempeo, reclutamiento, retencin, relaciones laborales, regulaciones
sobre seguridad y salud ocupacional y otros temas relacionados con la funcin de administracin de recursos humanos.
La mayor parte de este material es directamente aplicable al liderazgo y a la conduccin de
personas en proyectos y el director del proyecto y el equipo de direccin del proyecto deben
estar familiarizados con estos conceptos. Sin embargo, deben tambin ser sensibles a la forma
en que estos conocimientos son aplicados al proyecto. Por ejemplo:
107
Figura 91 | 9.1.1.2
Captulo 9 Gestin de los Recursos Humanos del Proyecto
Figura 91. Visin General de la Gestin de los Recursos Humanos del Proyecto
La naturaleza temporaria de los proyectos implica que las relaciones personales y organizacionales sern generalmente temporales y nuevas. El equipo de direccin del proyecto
debe ser cuidadoso en seleccionar tcnicas que sean apropiadas para estas relaciones transitorias.
La naturaleza y el nmero de interesados en el proyecto usualmente cambiarn segn el
proyecto vaya atravesando las distintas fases de su ciclo de vida. Como consecuencia, tcnicas que son efectivas en una fase determinada, pueden no serlo en otra. El equipo de
direccin del proyecto debe seleccionar cuidadosamente las tcnicas apropiadas para las
necesidades presentes del mismo.
Las actividades administrativas de recursos humanos rara vez son responsabilidad directa
del equipo de direccin del proyecto. Sin embargo, el equipo debe conocer los requerimientos administrativos lo suficientemente como para asegurar su cumplimiento.
Nota: Los directores de proyecto pueden adems tener responsabilidades respecto de la
liberacin y reubicacin de los recursos humanos, dependiendo de la industria u organizacin
a la que pertenezcan.
9.1 PLANIFICACIN DE LA ORGANIZACIN

La planificacin de la organizacin comprende la identificacin, documentacin y asignacin
de roles, responsabilidades y lneas de reporte del proyecto. Los roles, las responsabilidades y
108
las lneas de reporte pueden ser asignados a personas o a grupos. Las personas y grupos
pueden formar parte de la organizacin ejecutora del proyecto o pueden ser externos a ella.
Los grupos internos estn frecuentemente asociados a un departamento funcional especfico
como ingeniera, marketing o contabilidad.
En la mayora de los proyectos, la mayor parte de la planificacin de la organizacin se
realiza como parte de las fases iniciales del proyecto. Sin embargo, los resultados de este proceso deben ser revisados regularmente a lo largo del proyecto para asegurar su vigencia. Si
la organizacin inicial deja de ser efectiva, debera ser revisada inmediatamente.
La planificacin de la organizacin est con frecuencia ntimamente relacionada con la
planificacin de las comunicaciones (descrita en la seccin 10.1), ya que la estructura de la
organizacin del proyecto tendr un impacto importante sobre los requerimientos de comunicaciones del proyecto.
9.1.1
.1
.2
Entradas a la Planificacin de la Organizacin

Interfaces del proyecto: Las interfaces del proyecto generalmente se encuadran en una de las
siguientes tres categoras:
Interfaces organizativas: son relaciones de reporte, formales e informales, entre diferentes
unidades de la organizacin. Las interfaces organizativas pueden ser altamente complejas
o muy simples. Por ejemplo, desarrollar un sistema complejo de telecomunicaciones puede
necesitar la coordinacin de numerosos subcontratistas durante varios aos, mientras que
corregir un error de programacin en un sistema instalado en un nico punto puede
requerir poco ms que la notificacin al usuario y al personal de operaciones al completarse.
Interfaces tcnicas: son relaciones de reporte, formales e informales, entre diferentes disciplinas tcnicas. Las interfaces tcnicas ocurren tanto dentro de las fases del proyecto (por
ejemplo, el diseo desarrollado por los ingenieros civiles debe ser compatible con la superestructura desarrollada por los ingenieros estructurales), como entre fases del proyecto (por
ejemplo, cuando un equipo de diseo automotriz pasa los resultados de su trabajo al
equipo de desarrollo que debe crear las lneas de fabricacin y montaje del vehculo).
Interfaces interpersonales: son relaciones de reporte, formales e informales, entre las
diferentes personas que trabajan en el proyecto.
Estas interfaces frecuentemente ocurren simultneamente, como cuando un arquitecto
empleado en un estudio de arquitectura explica las consideraciones clave del diseo al equipo
de direccin del proyecto de un contratista de construccin no relacionado con el estudio.
Requerimientos del personal: Los requerimientos del personal definen qu tipo de competencias se requieren de qu tipo de trabajadores o grupos de trabajadores y en qu periodos
de tiempo. Los requisitos del personal son un subconjunto de las requisitos generales de todos
los recursos, identificados durante la planificacin de los recursos (descrita en la seccin 7.1).
109
9.1.1.3 | 9.1.3.4
.3
9.1.2
.1
.2
.3
.4
9.1.3
.1
110
Restricciones: Las restricciones son factores que limitan las opciones del equipo del proyecto.
Las opciones organizacionales de un proyecto pueden estar condicionadas de muchas maneras. Factores habituales que pueden restringir la forma en que est organizado el equipo
pueden ser, aunque no se limitan a, los siguientes:
La estructura de la organizacin ejecutora: una organizacin cuya estructura bsica es una
matriz fuerte implica una funcin de director del proyecto mucho ms fuerte que una cuya
estructura bsica es una matriz dbil (vase la seccin 2.3.3 para una descripcin ms
detallada de las estructuras organizacionales).
Convenios colectivos: los acuerdos contractuales con sindicatos u otros grupos de
empleados pueden requerir ciertos roles o relaciones de reporte (en esencia, el grupo de
empleados es un interesado ms en el proyecto).
Preferencias del equipo de direccin de proyecto: si los miembros del equipo de direccin
de proyecto han obtenido xitos con ciertas estructuras en el pasado, probablemente abogarn por estructuras similares en el futuro.
Asignaciones de personal esperadas: la forma en que se organiza un proyecto est frecuentemente influenciada por las competencias de personas especficas.
Tcnicas y Herramientas para la Planificacin de la Organizacin

Plantillas. Aunque cada proyecto es nico, la mayora de los proyectos se asemejan a otros
proyectos en alguna medida. Utilizar las asignaciones de funciones y responsabilidades, as
como las relaciones de reporte de proyectos similares, puede ayudar a acelerar el proceso de
planificacin de la organizacin.
Prcticas de recursos humanos. Muchas organizaciones tienen una variedad de polticas, guas
y procedimientos que pueden ayudar al equipo de direccin de proyecto en varios aspectos
de la planificacin de la organizacin. Por ejemplo, una organizacin que ve a sus directivos
como formadores, probablemente tendr documentacin sobre cmo se debe realizar la funcin del "formador".
Teora de la organizacin. Hay gran cantidad de literatura que describe cmo se pueden y
deben estructurar las organizaciones. Aunque solamente una pequea parte de toda esta literatura est dirigida a la organizacin de proyectos, el equipo de direccin del proyecto debe
estar familia-rizado en forma general con la teora organizacional, de modo de estar mejor
preparado para responder a los requerimientos del proyecto.
Anlisis de los interesados en el proyecto. La identificacin de los interesados en el proyecto,
as como sus necesidades, deben ser analizadas para asegurar que estas necesidades se satisfagan. La seccin 10.1.2.1 describe con ms detalle el anlisis de los interesados en el proyecto.
Salidas de la Planificacin de la Organizacin

Asignacin de roles y responsabilidades. Los roles (quin hace qu) y responsabilidades
(quin decide qu) del proyecto deben asignarse a los interesados que corresponda. Los roles
y responsabilidades pueden variar a lo largo del tiempo. La mayora de los roles y responsabilidades sern asignados a los interesados que estn activamente comprometidos en el trabajo
del proyecto, tales como el director del proyecto, otros miembros del equipo de direccin de
proyecto y los contribuyentes individuales al proyecto.
Los roles y responsabilidades del director del proyecto son generalmente crticos en la
mayora de los proyectos, pero varan significativamente segn las reas de aplicacin.
Los roles y responsabilidades del proyecto deberan estar directamente ligados a la definicin del alcance del proyecto. Se utiliza normalmente para este fin la llamada Matriz de Asignacin de Responsabilidades (o RAM, vase la figura 9-2). En proyectos mayores, las matrices
Figura 92. Matriz de Asignacin de Responsabilidades
.2
.3
.4
RAM se pueden desarrollar a distintos niveles. Por ejemplo, una RAM de alto nivel puede
definir qu grupo o unidad es responsable de cada elemento de la estructura detallada del trabajo (WBS), mientras que las de niveles ms bajos se utilizan dentro del grupo para asignar
roles y responsabilidades para actividades especficas a personas determinadas.
Plan de gestin del personal. El plan de gestin del personal describe cundo y cmo los
recursos humanos se incorporarn y se desvincularn del equipo del proyecto. El plan de
gestin del personal puede ser formal o informal, muy detallado o slo bosquejado, segn las
necesidades del proyecto. Es un elemento subsidiario del plan general del proyecto (vase la
seccin 4.1, Desarrollo del plan de proyecto).
El plan de gestin del personal incluye a menudo histogramas de recursos, como se
muestra en la figura 9-3.
Se debe prestar especial atencin a la forma en que los miembros del equipo de proyecto
(personas o grupos) sern relevados de sus funciones cuando ya no sean necesarios en el
proyecto. Procedimientos de reasignacin adecuados pueden:
Reducir costos, reduciendo o eliminando la tendencia a inventar trabajo para llenar el
tiempo entre una asignacin y la siguiente.
Mejorar la moral, reduciendo o eliminando la incertidumbre sobre las futuras oportunidades
de empleo.
Organigrama. Es una representacin grfica de las relaciones de reporte en el proyecto. Puede
ser formal o informal, muy detallado o simplemente bosquejado, de acuerdo con las necesidades del proyecto. Por ejemplo, el organigrama para un proyecto de servicio interno compuesto por tres o cuatro personas, probablemente no tendr el mismo rigor y detalle que el de
un equipo de respuesta a desastres de 3.000 personas.
Una Estructura Detallada de la Organizacin (OBS) es un tipo especfico de organigrama
que muestra qu unidades de la organizacin son responsables de qu conjunto de actividades.
Detalles de respaldo. El detalle de respaldo para la planificacin de la organizacin vara segn
el rea de aplicacin y el tamao del proyecto. La informacin frecuentemente suministrada
como detalle de respaldo incluye, pero no se limita a:
111
Figura 93 | 9.2.2.1
Figura 93. Histograma Ilustrativo de Recursos
Impacto organizativo: qu alternativas se excluyen al organizar de esta forma.

Descripciones de trabajo: esbozos escritos por cargo, de las aptitudes, responsabilidades,
autoridad, medio ambiente fsico y otras caractersticas relacionadas con la realizacin de
un determinado trabajo. Tambin llamadas descripciones de puestos de trabajo.
Necesidades de formacin: si se prev que el personal por ser asignado no tenga las aptitudes necesarias para el proyecto, dichas aptitudes debern ser desarrolladas como parte
del proyecto.
9.2 ADQUISICIN DE PERSONAL

La contratacin de personal comprende la obtencin de los recursos humanos necesarios (individuos o grupos) asignados y trabajando en el proyecto. En la mayora de los entornos puede
suceder que los mejores recursos no estn disponibles. El equipo de direccin del proyecto
debe prestar especial atencin en asegurar que los recursos disponibles lograrn alcanzar los
requerimientos del proyecto.
112
9.2.1
.1
.2
.3
9.2.2
.1
Entradas a la Adquisicin de Personal

Plan de gestin del personal. El plan de gestin de personal se describe en la seccin 9.1.3.2.
Este plan incluye los requerimientos de personal del proyecto, tal como se describe en la seccin 9.1.1.2.
Descripcin del personal disponible. Cuando el equipo de direccin del proyecto puede influir
o dirigir la asignacin de personal, debe considerar las caractersticas del personal potencialmente disponible. Las consideraciones incluyen, pero no se limitan a:
Experiencia previa los individuos o grupos han realizado anteriormente trabajos similares o relacionados? Los han realizado bien?
Intereses personales los individuos o grupos estn interesados en trabajar en este
proyecto?
Caractersticas personales es probable que los individuos o grupos trabajen bien juntos,
como equipo?
Disponibilidad: estarn los individuos o grupos deseados disponibles en el perodo de
tiempo necesario?
Aptitudes y habilidades qu aptitudes y en qu nivel son requeridas?
Prcticas de reclutamiento. Una o ms de las organizaciones involucradas en el proyecto
puede tener polticas, guas o procedimientos que rigen la asignacin de personal. Cuando los
mismos existen, tales prcticas actan como una restriccin sobre el proceso de adquisicin de
personal.
Tcnicas y Herramientas para la Adquisicin de Personal

Negociaciones. La asignacin de personal debe ser negociada en la mayora de los proyectos.
Por ejemplo, el equipo de direccin del proyecto puede necesitar negociar con:
Directores funcionales responsables para asegurar que el proyecto recibe el personal
apropiadamente competente durante el perodo necesario.
Otros equipos de direccin de proyecto dentro de la organizacin ejecutora, para asignar
adecuadamente los recursos escasos o especializados.
La capacidad de influencia del equipo (vase la seccin 2.4.5, Influencia en la organizacin)
juega un papel importante en la negociacin por la asignacin de personal, de la misma
manera que las polticas de las organizaciones participantes. Por ejemplo, un gerente funcional
puede ser recompensado sobre la base de la utilizacin de personal. Esto crea un incentivo en
el gerente para asignar personal disponible que quizs no cubra todos los requerimientos del
proyecto.
113
9.2.2.2 | 9.3.2.4
.2
.3
9.2.3
.1
.2
Pre-asignacin. En algunos casos, el personal puede ser pre-asignado al proyecto. Esto ocurre
frecuentemente cuando a) el proyecto es el resultado de un concurso y se comprometi personal especfico como parte de la propuesta, o b) el proyecto es un proyecto de servicios
interno y la asignacin de personal se defini en el acta del proyecto.
Adquisiciones. La gestin de adquisiciones del proyecto (descrita en el captulo 12) puede
usarse para obtener los servicios de individuos o grupos de individuos especficos para desarrollar actividades del proyecto. Se recurre a contrataciones temporarias cuando la organizacin
ejecutora carece del personal propio necesario para completar el proyecto (por ejemplo,
debido a una decisin consciente de no contratar esos individuos como empleados de dedicacin completa, por tener todo el personal con la calificacin adecuada previamente asignado
a otros proyectos o como resultado de otras circunstancias).
Salidas de la Adquisicin de Personal

Personal asignado al proyecto. El proyecto est dotado de personal cuando las personas adecuadas han sido realmente asignadas para trabajar en el mismo. El personal puede ser asignado con dedicacin completa o con dedicacin parcial o variable, de acuerdo con las
necesidades del proyecto.
Directorio del equipo del proyecto. Un directorio del equipo del proyecto es un listado que
incluye a todos los miembros del equipo del proyecto y a otros interesados en el proyecto.
El directorio puede ser formal o informal, muy detallado o simplemente bosquejado, de
acuerdo con las necesidades del proyecto.
9.3 DESARROLLO DEL EQUIPO

El desarrollo del equipo comprende tanto la mejora de las habilidades de los interesados en el
proyecto para contribuir individualmente, como la mejora de las habilidades del equipo para
funcionar como tal. El desarrollo individual (tcnico y de gestin) es la base necesaria para
desarrollar el equipo. El desarrollo como equipo es crtico para que el proyecto pueda alcanzar
sus objetivos.
El desarrollo del equipo en un proyecto se complica con frecuencia cuando los miembros
individuales del equipo estn subordinados tanto a un director funcional como al director del
proyecto (vase la seccin 2.3.3 para una descripcin de las estructuras matriciales de organizacin). La gestin eficiente de esta doble relacin de dependencia es frecuentemente un factor crtico de xito del proyecto y es generalmente responsabilidad del director del proyecto.
Aunque el desarrollo del equipo figura en el captulo 3 como uno de los procesos de ejecucin del proyecto, dicho desarrollo ocurre a lo largo de todo el proyecto.
114
9.3.1
.1
.2
.3
.4
.5
9.3.2
.1
.2
.3
.4
Entradas al Desarrollo del Equipo

Personal del proyecto. La asignacin del personal del proyecto se describe en la seccin
9.2.3.1. La asignacin de personal define implcitamente las competencias, individuales y de
equipo, disponibles para el desarrollo del equipo.
Plan del proyecto. El plan del proyecto se describe en la seccin 4.1.3.1. El plan del proyecto
describe el contexto tcnico dentro del cual opera el equipo.
Plan de gestin del personal. El plan de gestin del personal se describe en la seccin 9.1.3.2.
Informes de rendimiento. Los informes de rendimiento (descritos en la seccin 10.3.3.1) proporcionan informacin al equipo del proyecto sobre el rendimiento comparado con el plan del
proyecto.
Comentarios externos. El equipo del proyecto debe medirse y compararse peridicamente con
las expectativas de aquellos que estn fuera del proyecto.
Tcnicas y Herramientas para el Desarrollo del Equipo

Actividades para la formacin del equipo. Abarcan las acciones individuales y de gestin
tomadas, especfica y primariamente, para mejorar el funcionamiento del equipo. Muchas
acciones (tales como incluir a miembros no directivos del equipo en el proceso de planificacin o el establecimiento de reglas bsicas para explicitar y resolver los conflictos) pueden,
como efecto secundario, mejorar el funcionamiento del equipo. Las actividades para el desarrollo del equipo pueden variar desde una agenda peridica de encuentros breves para la revisin
del estado del proyecto, hasta una experiencia ms extensa, externa y profesionalmente organizada, diseada para mejorar las relaciones interpersonales entre los interesados clave.
Hay un cuerpo de literatura sustancial sobre la formacin de equipos de trabajo. El equipo
de direccin del proyecto debera estar familiarizado con una gran variedad de actividades de
formacin de equipo.
Habilidades de gestin en general. Las habilidades de gestin en general (descritas en la seccin 2.4) son de particular importancia para el desarrollo del equipo.
Sistemas de recompensa y reconocimiento. Las recompensas y los sistemas de reconocimiento son acciones formales de gestin que promueven o refuerzan el comportamiento
deseado. Para que sean efectivos, tales sistemas deben establecer el vnculo entre el
rendimiento del proyecto y la recompensa de forma clara, explcita y alcanzable. Por ejemplo,
un director de proyecto que va a ser recompensado por alcanzar los objetivos de costo del
proyecto, debera tener un nivel de control apropiado sobre las decisiones de personal y de
adquisiciones.
Los proyectos deben tener sus propios sistemas de recompensa y reconocimiento, ya que
los sistemas de la organizacin ejecutora pueden no ser apropiados. Por ejemplo, la disposicin de trabajar horas extras para cumplir con un cronograma agresivo debera ser recompensada o reconocida; la necesidad de trabajar horas extra a causa de una mala planificacin,
no debera recompensarse.
Los sistemas de recompensa y reconocimiento deben considerar tambin las diferencias
culturales. Por ejemplo, es muy difcil desarrollar un mecanismo apropiado para recompensar
un equipo en una cultura que estimula el individualismo.
Ubicacin conjunta. Consiste en ubicar a todos, o casi todos, los miembros ms activos del
equipo del proyecto en el mismo lugar fsico, para potenciar su capacidad de trabajar como
equipo. La situacin es muy utilizada en los proyectos grandes y puede ser tambin muy efectiva en proyectos ms pequeos (por ejemplo, con una sala de situacin donde el equipo se
rene y/o presenta cronogramas, actualizaciones, etc.). En algunos proyectos, la ubicacin conjunta puede no ser aplicable; donde esta prctica no es viable, una alternativa puede ser programar frecuentes reuniones cara a cara para fomentar la interaccin entre los miembros.
115
9.3.2.5 | Captulo 10
.5
9.3.3
.1
.2
116
Entrenamiento. Comprende todas las actividades diseadas para aumentar las capacidades del
equipo del proyecto. Algunos autores distinguen entre capacitacin, educacin y desarrollo,
pero estas distinciones no son consistentes ni estn generalmente aceptadas. La capacitacin
puede ser formal (por ejemplo, formacin en aulas, basada en computadoras, etc.) o informal
(por ejemplo, los comentarios provenientes de la experiencia de otros miembros del equipo).
Existe gran cantidad de literatura sobre cmo proveer capacitacin a personas adultas.
Si los miembros del equipo del proyecto carecen de las aptitudes tcnicas o de gestin
necesarias, tales aptitudes deben ser desarrolladas como parte del proyecto, o bien se deben
dar los pasos necesarios para dotar al proyecto apropiadamente. Los costos de capacitacin,
directos o indirectos, son generalmente pagados por la organizacin ejecutante.
Salidas de Desarrollo del Equipo

Mejoras en el rendimiento. Las mejoras del rendimiento del equipo pueden provenir de
diversas fuentes y pueden afectar a muchas reas del rendimiento del proyecto; por ejemplo:
Mejoras en las aptitudes individuales pueden permitir que una persona determinada desarrolle ms efectivamente las actividades asignadas.
Mejoras en el comportamiento del equipo (por ejemplo, explicitar y resolver conflictos),
pueden permitir que los miembros del equipo del proyecto dediquen un mayor porcentaje
de su esfuerzo a actividades tcnicas.
Mejoras, tanto en la aptitud individual como en la capacidad del equipo, pueden facilitar la
identificacin y el desarrollo de mejores mtodos para realizar el trabajo del proyecto.
Entradas para evaluaciones del desempeo. Generalmente el personal de proyecto debera
proporcionar datos para la evaluacin de cualquier miembro del proyecto con el que ellos
interactan de forma significativa.
Captulo 10
Gestin de las
Comunicaciones del
Proyecto
La gestin de las comunicaciones del proyecto incluye los procesos requeridos para asegurar
la generacin oportuna y apropiada, la recoleccin, la distribucin, el almacenamiento y la disposicin final de la informacin del proyecto. Proporciona las relaciones fundamentales entre
las personas, las ideas y la informacin necesarias para el xito. Todos los interesados deben
estar preparados para enviar y recibir comunicaciones y deben entender cmo las comunicaciones en las que estn involucrados como individuos afectan el proyecto en su conjunto. La
figura 10-1 proporciona una visin general de los siguientes procesos principales:
10.1 Planificacin de las Comunicaciones determinacin de las necesidades de informacin y comunicacin de los interesados en el proyecto: qu informacin necesita cada
uno, cundo la necesitar y cmo le ser entregada.
10.2 Distribucin de la Informacin aseguramiento de que la informacin necesaria est
disponible para los interesados en el proyecto de manera oportuna.
10.3 Informes de Rendimiento recoleccin y distribucin de informacin del rendimiento.
Esto incluye informes de situacin, medicin del progreso y pronostico de terminacin.
10.4 Cierre Administrativo generacin, recoleccin y distribucin de informacin para formalizar la conclusin de una fase o del proyecto.
Las habilidades de gestin en general para manejar las comunicaciones (tratadas en la seccin 2.4.2) se relacionan con la gestin de las comunicaciones del proyecto, pero no es lo
mismo. Comunicar es un tema ms amplio e involucra un cuerpo de conocimiento sustancial
que no es exclusivo del contexto del proyecto. Por ejemplo:
Modelos emisor-receptor ciclos de realimentacin, barreras a las comunicaciones, etc.
Eleccin del medio cundo comunicar por escrito versus cundo comunicar oralmente,
cundo escribir un memorando informal versus cundo escribir un informe formal, etc.
117
Figura 101 | 10.1.1.1
Captulo 10 Gestin de las Comunicaciones del Proyecto
Figura 101. Visin General de la Gestin de las Comunicaciones del Proyecto
118
Estilo de escritura voz activa versus voz pasiva, estructura de la oracin, seleccin de
palabras, etc.
Tcnicas de presentacin lenguaje corporal, diseo de medios visuales, etc.
Tcnicas de manejo de reuniones preparacin de una agenda, manejo de conflictos, etc.
10.1 PLANIFICACIN DE LAS COMUNICACIONES

La planificacin de las comunicaciones involucra la determinacin de las necesidades de informacin y de comunicaciones de los interesados en el proyecto: qu informacin necesitar
cada uno, cundo la necesitar, cmo le ser entregada y por quin. Mientras todos los
proyectos comparten la necesidad de comunicar informacin, las necesidades de informacin
y los mtodos de distribucin varan ampliamente. La identificacin de las necesidades de
informacin de los interesados en el proyecto y la determinacin de un medio conveniente
para alcanzar esas necesidades son factores importantes para el xito del proyecto.
En la mayora de los proyectos, lo ms importante de la planificacin de las comunicaciones se hace como parte de las fases iniciales del proyecto. Sin embargo, los resultados de
este proceso deben revisarse regularmente a lo largo del proyecto y deben revisarse cuanto sea
necesario para asegurarse de que continan siendo aplicables.
La planificacin de las comunicaciones est a menudo fuertemente relacionada con la
planificacin de la organizacin (descrita en la seccin 9.1), dado que la estructura de la organizacin del proyecto tendr un efecto importante en los requerimientos de comunicaciones
del proyecto.
10.1.1
.1
Entradas a la Planificacin de las Comunicaciones

Requerimientos de comunicaciones. Los requerimientos de comunicaciones son la suma de
los requerimientos de informacin de los interesados en el proyecto. Los requerimientos se
definen combinando el tipo y formato de la informacin requerida con un anlisis del valor de
esa informacin. Los recursos del proyecto deben ser utilizados slo para comunicar informacin que contribuya al xito o donde una falta de comunicacin pueda llevar al fracaso. La
informacin tpicamente exigida para determinar los requerimientos de comunicaciones del
proyecto incluye:
Las relaciones entre las responsabilidades de la organizacin del proyecto y los interesados
en el mismo.
Las disciplinas, secciones y especialidades involucradas en el proyecto.
La logstica de cuntos individuos estarn involucrados en el proyecto y en qu ubicaciones.
Necesidades de informacin externa (por ejemplo, comunicaciones con los medios).
119
10.1.1.2 | 10.2.2.2
.2
.3
.4
10.1.2
.1
10.1.3
.1
120
Tecnologa de comunicaciones. Las tecnologas o mtodos utilizados para transferir la informacin de un lado a otro entre los interesados en el proyecto puede variar significativamente:
desde breves conversaciones a extensas reuniones, desde simples documentos escritos a
cronogramas y bases de datos accesibles inmediatamente en lnea.
Entre los factores de tecnologa de comunicaciones que pueden afectar al proyecto se
incluyen:
La urgencia de la necesidad de informacin el xito del proyecto depende de tener
informacin frecuentemente actualizada disponible al momento, o alcanzara con emitir
regularmente informes escritos?
La disponibilidad de la tecnologa son apropiados los sistemas que ya estn instalados,
o las necesidades del proyecto justifican un cambio?
El personal previsto para el proyecto son los sistemas de comunicaciones propuestos
compatibles con la experiencia y especializacin de los participantes del proyecto, o se
requerir un extenso entrenamiento y aprendizaje?
La duracin del proyecto es probable que la tecnologa disponible cambie antes de que
el proyecto haya terminado?
Restricciones. Las restricciones son factores que limitarn las opciones del equipo de gestin
del proyecto. Por ejemplo, si se va a contratar una importante cantidad de recursos del
proyecto, se necesitar dar ms importancia al manejo de informacin de los contratos.
Cuando un proyecto es realizado bajo contrato, hay a menudo disposiciones contractuales
especficas que afectan la planificacin de las comunicaciones.
Hiptesis. Vase la seccin 4.1.1.5.
Tcnicas y Herramientas para la Planificacin de las Comunicaciones

Anlisis de los interesados en el proyecto. Se deben analizar las necesidades de informacin
de los diferentes interesados en el proyecto para desarrollar una visin metdica y lgica de
dichas necesidades y de las fuentes de informacin para satisfacer las mismas (el tema de los
interesados en el proyecto es tratado con ms detalle en la seccin 2.2). El anlisis debe considerar mtodos y tecnologas apropiados para el proyecto que proporcionar la informacin
necesaria. Debe tenerse cuidado de evitar gastar recursos en informacin innecesaria o en tecnologa inapropiada.
Salidas de la Planificacin de las Comunicaciones

Plan de gestin de las comunicaciones. Un plan de gestin de las comunicaciones es un documento que proporciona:
Una estructura de recoleccin y archivo que detalla qu mtodos se usarn para obtener
y almacenar los distintos tipos de informacin. Los procedimientos deben cubrir tambin
la recoleccin y distribucin de actualizaciones y correcciones del material distribuido anteriormente.
Una estructura de distribucin que detalle a quin se entregar la informacin (informes de
situacin, datos, cronogramas, documentacin tcnica, etc.) y qu mtodos (informes
escritos, reuniones, etc.) se usarn para distribuir distintos tipos de informacin. Esta estructura debe ser compatible con las responsabilidades y relaciones de reporte descritas por el
organigrama del proyecto.
Una descripcin de la informacin a ser distribuida, incluyendo el formato, el volumen,
nivel de detalle, y convenciones/definiciones a ser usadas.
El cronograma de produccin, mostrando cundo ser llevado a cabo cada tipo de comunicacin.
Mtodos para acceder a la informacin entre comunicaciones ya prefijadas.
Un mtodo para actualizar y refinar el plan de gestin de las comunicaciones a medida que
el proyecto progresa y se desarrolla.
El plan de gestin de las comunicaciones puede ser formal o informal, altamente detallado
o simplemente bosquejado, segn las necesidades del proyecto. Es un componente subsidiario
del plan general del proyecto (descrito en la Seccin 4.1).
10.2
DISTRIBUCIN DE LA INFORMACIN
La distribucin de informacin implica poner a disposicin de los interesados en el proyecto
la informacin necesaria de manera oportuna. Incluye implementar el plan de gestin de las
comunicaciones, como as tambin responder a requerimientos inesperados de informacin.
10.2.1
.1
.2
.3
10.2.2
.1
.2
Entradas a la Distribucin de Informacin

Resultados del trabajo. Los resultados del trabajo son descritos en la seccin 4.2.3.1.
Plan de gestin de las comunicaciones. El plan de gestin de las comunicaciones se describe
Plan del proyecto. El plan del proyecto se describe en la seccin 4.1.3.1.
Tcnicas y Herramientas para la Distribucin de Informacin

Habilidades de comunicacin. Las habilidades de comunicaciones se usan para intercambiar
informacin. El emisor es responsable de que la informacin sea clara, inequvoca y completa
para que el receptor pueda recibirla correctamente y por confirmar que es apropiadamente
entendida. El receptor es responsable de comprobar que la informacin sea recibida en forma
completa y entendida correctamente. La comunicacin tiene varias dimensiones:
Escrita y oral, escuchar y hablar.
Interna (dentro del proyecto) y externa (al cliente, los medios de comunicacin, el pblico,
etc.).
Formal (informes, resmenes, etc.) e informal (memorandos, conversaciones ad-hoc, etc.).
Vertical (hacia arriba y abajo en la organizacin) y horizontal (con los compaeros).
Sistemas de gestin de la informacin. La informacin puede ser compartida por miembros
del equipo e interesados en el proyecto a travs de una variedad de mtodos que incluyen los
sistemas manuales de archivo, bases de datos electrnicas, software de gestin del proyecto
y sistemas que permiten el acceso a documentacin tcnica como dibujos de ingeniera,
especificaciones de diseo, planes de prueba, etc.
121
10.2.2.3 | 10.3.2.5
.3
10.2.3
.1
.2
.3
Mtodos de distribucin de la informacin. La informacin del proyecto puede distribuirse

usando una variedad de mtodos que incluyen reuniones del proyecto, documentos impresos,
acceso compartido a bases de datos electrnicas conectadas a una red de computadoras, envo
de facsmil, correo electrnico, correo de voz, videoconferencias y una intranet del proyecto.
Salidas de la Distribucin de Informacin

Registros del proyecto. Los registros del proyecto pueden incluir la correspondencia, memorandos y documentos que describen el proyecto. Esta informacin debera, dentro de lo
posible y conveniente, mantenerse de manera organizada. Los miembros del equipo de
proyecto pueden a menudo mantener archivos personales en un diario del proyecto.
Informes del proyecto. Informes formales del proyecto sobre el estado del mismo y/o aspectos
importantes.
Presentaciones del proyecto. El equipo del proyecto proporciona informacin, formal o informalmente, a algunos o a todos los interesados en el proyecto. La informacin es relevante a
las necesidades de la audiencia y el mtodo de presentacin es apropiado.
10.3 INFORMES DE RENDIMIENTO

Los informes de rendimiento incluyen la recoleccin y distribucin de informacin del
rendimiento para proporcionar a los interesados en el proyecto informacin sobre cmo estn
usndose los recursos a fin de lograr los objetivos del proyecto. Este proceso incluye:
Informes de situacin que describen dnde est el proyecto ahora por ejemplo, el
estado de las mtricas del cronograma y del presupuesto.
Informes de rendimiento que describen lo que el equipo del proyecto ha logrado por
ejemplo, porcentaje del cronograma que se ha completado o lo que est completo comparado con lo que est en proceso.
Pronsticos predicciones sobre el estado y el avance futuros del proyecto.
Los informes de rendimiento generalmente deben proporcionar informacin sobre el
alcance, el cronograma, los costos y la calidad. Muchos proyectos tambin requieren informacin sobre el riesgo y las adquisiciones. Los informes pueden prepararse sobre todo el
proyecto o bien sobre aspectos especficos del mismo.
10.3.1
.1
122
Entradas a los Informes de Rendimiento

Plan del proyecto. El plan del proyecto se analiza en la seccin 4.1.3.1. El plan del proyecto
contiene los planes de referencia que se usarn para evaluar el rendimiento del proyecto.
.2
.3
10.3.2
.1
.2
.3
.4
.5
Resultados del trabajo. Los resultados del trabajo qu entregables han sido total o parcialmente completados, qu costos (y/o recursos) se han tenido o se han comprometido, etc.
son una salida de la ejecucin del plan del proyecto (tratado en la seccin 4.2.3.1). Los
resultados del trabajo se deben informar dentro del esquema proporcionado por el plan de
gestin de las comunicaciones. Es esencial contar con informacin exacta y uniforme sobre los
resultados del trabajo para que los informes de rendimiento sean tiles.
Otros registros del proyecto. En la seccin 10.2.3.1 se tratan los registros del proyecto. Adicionalmente al plan del proyecto y los resultados del trabajo del proyecto, otros documentos
del proyecto contienen a menudo informacin que pertenece al contexto del proyecto y que
debe ser considerada al evaluar el rendimiento del mismo.
Tcnicas y Herramientas para los Informes de Rendimiento

Revisiones de rendimiento. Las revisiones del rendimiento son reuniones llevadas a cabo para
evaluar el estado y/o progreso del proyecto. Las revisiones del rendimiento se usan tpicamente
junto con una o ms de las tcnicas de informe de rendimiento que se describen ms abajo.
Anlisis de variacin. El anlisis de variacin implica comparar los resultados reales del
proyecto con los resultados planificados o esperados. Las variaciones de costo y cronograma
son las ms frecuentemente analizadas, pero a menudo las variaciones respecto al plan en las
reas de alcance, recursos, calidad y riesgo son de igual o mayor importancia.
Anlisis de tendencias. El anlisis de tendencias implica examinar los resultados del proyecto
a travs del tiempo para determinar si su rendimiento est mejorando o se est deteriorando.
Anlisis del valor del trabajo realizado. El anlisis del valor del trabajo realizado, en sus varias
formas, es el mtodo ms comnmente usado para medir el rendimiento. Integra el alcance, el
costo (o el recurso) y las mediciones del cronograma para ayudar al equipo de gestin del
proyecto a evaluar el rendimiento del proyecto. El valor del trabajo realizado (EV) implica calcular tres valores clave por cada actividad:
El valor planeado (PV), anteriormente llamado costo presupuestado del trabajo programado
(BCWS), es aquella porcin de la estimacin del costo aprobado que se planea ser gastada en la actividad durante un perodo dado.
El costo real (AC), anteriormente llamado costo real del trabajo realizado (ACWP), es el
total de los costos incurridos para ejecutar el trabajo en la actividad durante un periodo
dado. Este costo real debe corresponderse con lo que fue presupuestado para el PV y el
EV (ejemplo: slo horas directas, slo costos directos o todos los costos incluidos los costos
indirectos).
El EV, anteriormente llamado costo presupuestado del trabajo realizado (BCWP), es el valor
del trabajo realmente completado.
Estos tres valores se usan combinados para proporcionar medidas de si el trabajo est
siendo o no cumplido como se planific. Las medidas que ms usualmente se usan son la
variacin del costo (CV) (CV = EV AC) y la variacin del cronograma (SV) (SV = EV PV).
Estos dos valores, el CV y el SV, pueden convertirse en indicadores de eficiencia para reflejar
el rendimiento del costo y del cronograma de cualquier proyecto. El ndice de rendimiento de
costos (CPI = EV/AC) es el indicador de eficiencia del costo ms comnmente usado. El CPI
acumulado (la suma de todos los presupuestos individuales de EV dividido por la suma de
todos los AC individuales) es ampliamente usado para pronosticar los costos del proyecto en
su conclusin. Tambin el ndice de rendimiento del cronograma (SPI = EV/PV) es usado a
veces junto con el CPI para pronosticar las estimaciones de conclusin del proyecto.
Herramientas y tcnicas de distribucin de informacin. Los informes de rendimiento son distribuidos usando las herramientas y tcnicas descritas en la seccin 10.2.2.
123
Figura 102 | 10.4.3.1
Figura 102. Informe Grfico Ilustrativo del Rendimiento
Figura 103. Informe Tabular Ilustrativo del Rendimiento
10.3.3
.1
.2
124
Salidas de Informes de Rendimiento

Informes de rendimiento. Los informes de rendimiento organizan y resumen la informacin
recogida y presentan los resultados de cualquier anlisis. Los informes deben proporcionar el
tipo de informacin y el nivel de detalle requeridos por los diversos interesados en el proyecto,
como se document en el plan de gestin de las comunicaciones.
Los formatos comunes para los informes de rendimiento incluyen diagramas de barras
(tambin llamados diagramas Gantt), curvas S, histogramas y tablas. La figura 10-2 usa una
curva S para mostrar los datos acumulados de un anlisis del valor del trabajo realizado (EV),
mientras que la figura 10-3 muestra un conjunto diferente de datos de EV en forma tabular.
Pedidos de cambio. El anlisis de rendimiento del proyecto genera a menudo un requerimiento para el cambio de algn aspecto del mismo. Estos requerimientos de cambio son manejados como se describi en los diferentes procesos de control de cambios (por ejemplo, gestin
de cambios de alcance, control de cronograma, etc.).
10.4 CIERRE ADMINISTRATIVO

El proyecto o la fase, despus de lograr sus objetivos o concluir por otras razones, requiere un
cierre. El cierre administrativo consiste en documentar los resultados del proyecto para formalizar la aceptacin del producto del proyecto por parte del patrocinador o del cliente.
Incluye la recoleccin de los registros del proyecto; asegurar que ellos reflejan las especificaciones finales; analizar el xito del proyecto, la efectividad y las lecciones aprendidas; y
archivar tal informacin para un uso futuro.
Las actividades del cierre administrativo no deben demorarse hasta la finalizacin del
proyecto. Cada fase del proyecto debe ser apropiadamente cerrada para asegurar que no se
pierda informacin importante y til. Adems, deben actualizarse las habilidades adquiridas
por los empleados en la base de datos del personal, para reflejar las nuevas habilidades y
mayores capacidades.
10.4.1
.1
.2
.3
10.4.2
.1
.2
.3
10.4.3
.1
Entradas al Cierre Administrativo

Documentacin de medicin del rendimiento. Toda la documentacin producida para registrar
y analizar el rendimiento del proyecto, incluyendo los documentos de la planificacin que
establecieron el esquema para la medicin del rendimiento, debe estar disponible para su
revisin durante el cierre administrativo.
Documentacin del producto. Los documentos producidos para describir el producto del
proyecto (planes, especificaciones, documentacin tcnica, dibujos, archivos electrnicos, etc.
la terminologa vara por rea de aplicacin) tambin deben estar disponibles para la
revisin durante el cierre administrativo.
Otros registros del proyecto. Los registros del proyecto son tratados en la seccin 10.2.3.1.
Tcnicas y Herramientas para el Cierre Administrativo

Herramientas y tcnicas para el informe del rendimiento. Las herramientas y tcnicas para el
informe de rendimiento son tratadas en la seccin 10.3.2.
Informes del proyecto. Vase la seccin 10.2.3.2.
Presentaciones del proyecto. Vase la seccin 10.2.3.3.
Salidas del Cierre Administrativo

Archivos del proyecto. Debe prepararse un juego completo de registros indexados del
proyecto para que sea archivado por las personas apropiadas. Debe actualizarse cualquier otra
base de datos histrica especfica del proyecto o general del programa. Cuando se hacen
proyectos bajo contrato, o cuando involucran una cantidad importante de adquisiciones, debe
prestarse particular atencin en archivar los registros financieros.
125
10.4.3.2 | Captulo 11
126
.2
.3
Cierre del proyecto. Es la confirmacin de que el proyecto ha alcanzado todos los requerimientos del cliente para el producto del proyecto (el cliente ha aceptado formalmente los productos y los entregables del proyecto) y los requerimientos de la organizacin ejecutora por
ejemplo, las evaluaciones del personal, informes de presupuesto, lecciones aprendidas, etc.
Lecciones aprendidas. Las lecciones aprendidas son tratadas en la seccin 4.3.3.3.
Captulo 11
Gestin de Riesgos del

Proyecto
La Gestin de Riesgos es el proceso sistemtico de identificacin, anlisis y respuesta a los
riesgos del proyecto. Ello incluye maximizar las probabilidades y consecuencias de sucesos
positivos y minimizar las probabilidades y consecuencias de sucesos adversos a los objetivos
del proyecto. La figura 11-1 provee un panorama general de los siguientes procesos principales:
11.1 Planificacin de la Gestin de Riesgos decisin acerca de cmo enfocar y planificar las actividades de gestin de riesgos para un proyecto.
11.2 Identificacin de Riesgos determinacin de qu riesgos pueden afectar al proyecto
y documentacin de sus caractersticas.
11.3 Anlisis Cualitativo de Riesgos realizacin de un anlisis cualitativo de los riesgos
y las condiciones para establecer una prioridad segn sus efectos sobre los objetivos del
proyecto.
11.4 Anlisis Cuantitativo de Riesgos medicin de la probabilidad y las consecuencias
de los riesgos y estimacin de sus implicancias en los objetivos del proyecto.
11.5 Planificacin de la Respuesta a Riesgos desarrollo de procedimientos y tcnicas
para aumentar las oportunidades y reducir las amenazas a los objetivos del proyecto.
11.6 Supervisin y Control de Riesgos supervisin de riesgos residuales, identificacin
de nuevos riesgos, ejecucin de planes de reduccin de riesgos y evaluacin de su efectividad durante todo el ciclo de vida del proyecto.
conocimiento. Cada proceso ocurre generalmente por lo menos una vez en cada fase del
proyecto. Aunque los procesos se presentan aqu como elementos discretos con interfaces bien
El riesgo en un proyecto es un evento o una condicin que, si ocurre, tiene un efecto positivo o negativo sobre los objetivos del mismo. Un riesgo tiene una causa y, si ocurre, una consecuencia. Por ejemplo, una causa puede ser una solicitud de permiso o tener un nmero
limitado de personal asignado al proyecto. El suceso de riesgo es que esto puede requerir ms
tiempo que lo planificado o que el personal puede no ser el adecuado para realizar las tareas.
Si cualquiera de estos eventos ocurre, habr una consecuencia en el costo, tiempo o calidad
del proyecto. Las condiciones de riesgo pueden incluir aspectos del entorno del proyecto que
pueden contribuir a los riesgos del mismo, tales como pobres prcticas de direccin del
proyecto o la dependencia de participantes externos que no pueden ser controlados.
Los riesgos del proyecto incluyen tanto las amenazas a sus objetivos como las oportunidades de mejora a dichos objetivos. Esto tiene su origen en la incertidumbre que est
127
Figura 111 | 11.1.1.6
Captulo 11 Gestin de Riesgos del Proyecto
Figura 111. Visin General de la Gestin de Riesgos del Proyecto
128
presente en todos los proyectos. Riesgos conocidos son aquellos que han sido identificados
y analizados y que sobre los que no es posible planificar.
Los riesgos desconocidos no pueden ser manejados, aunque los directores de proyecto
pueden tenerlos en cuenta mediante la constitucin de una contingencia general basada en
experiencias pasadas con proyectos similares. Las organizaciones perciben los riesgos por su
relacin con las amenazas al xito del proyecto. Los riesgos que son amenazas para el proyecto
pueden ser aceptados si estn equilibrados con el beneficio que puede ser obtenido al
tomarlos. Por ejemplo, la adopcin de un esquema de camino acelerado para lograr una terminacin adelantada es un riesgo que se toma, que puede ocasionar un mayor costo que el
previsto. Los riesgos que son oportunidades pueden ser activamente seguidos para beneficiar
los objetivos del proyecto.
Para lograr el xito, la organizacin debe estar comprometida a aplicar la gestin de riesgos
en todo el proyecto. Una medida del compromiso de la organizacin est dada por su dedicacin y constancia en la recoleccin de datos de alta calidad, tanto de los riesgos como de
sus caractersticas.
11.1 PLANIFICACIN DE LA GESTIN DE RIESGOS

La planificacin de la gestin de riesgos es el proceso de decidir cmo enfrentar y planificar
las actividades de gestin de riesgos para un proyecto. Es importante planificar los procesos
de gestin del riesgo que siguen, para asegurar que el nivel, el tipo y la visibilidad de la gestin
de riesgos estn en proporcin tanto con los riesgos como con la importancia del proyecto
para la organizacin.
11.1.1
.1
.2
.3
.4
.5
.6
Entradas a la Planificacin de la Gestin de Riesgos

Acta del proyecto. El acta del proyecto es tratada en la seccin 5.1.3.1.
Polticas de gestin de riesgos de la organizacin. Algunas organizaciones pueden tener enfoques pre-definidos de cmo encarar el anlisis y la respuesta a los riesgos, los cuales deben
ser adaptados a un proyecto en particular.
Roles y responsabilidades definidos. Los roles, responsabilidades y niveles de autoridad predefinidos para la toma de decisiones influenciarn la planificacin.
Tolerancia al riesgo de los interesados en el proyecto. Diferentes organizaciones e individuos
tienen dismiles tolerancias al riesgo. Esto puede ser expresado a travs de la enunciacin de
polticas o manifestado en acciones concretas.
Formularios para el plan de gestin del riesgo de la organizacin. Algunas organizaciones han
desarrollado plantillas (o formularios estndares) para ser usados por el equipo del proyecto.
La organizacin, basndose en su aplicabilidad y utilidad en el proyecto, mejorar continuamente dichos formularios.
Estructura detallada del trabajo (WBS). La WBS es tratada en la seccin 5.3.3.1.
129
11.1.2 | 11.2.1.3
11.1.2
.1
11.1.3
.1
130
Tcnicas y Herramientas para la Planificacin de la Gestin de Riesgos

Reuniones de planificacin. Los equipos de proyectos realizan reuniones para elaborar el plan
de gestin del riesgo. Los asistentes incluyen al director del proyecto, a los lderes del equipo
del proyecto y a cualquiera en la organizacin con responsabilidad de gestionar las actividades
de planificacin y ejecucin de riesgos, a los interesados clave en el proyecto y a otros de
acuerdo a la necesidad. Segn sea apropiado, usan formularios de gestin del riesgo y otras
entradas.
Salidas de la Planificacin de la Gestin de Riesgos

Plan de gestin del riesgo. El plan de gestin del riesgo describe cmo se estructura y lleva
a cabo la identificacin, el anlisis cualitativo y cuantitativo, la planificacin de la respuesta, la
supervisin y control de los riesgos durante el ciclo de vida del proyecto. El plan de gestin
del riesgo no trata respuestas a riesgos individuales esto es realizado en el plan de respuesta
al riesgo, descrito en la seccin 11.5.3.1. El plan de gestin del riesgo puede incluir lo
siguiente:
Metodologa. Define los mtodos, herramientas y fuentes de informacin que pueden ser
usados para realizar la gestin del riesgo en el proyecto. Dependiendo de la etapa del
proyecto, de la cantidad de informacin disponible y de la flexibilidad remanente en la
gestin del riesgo, diferentes tipos de evaluaciones pueden ser adecuados.
Roles y responsabilidades. Define el lder, el apoyo y los miembros del equipo de gestin
del riesgo, para cada tipo de accin del plan de gestin del riesgo. Los equipos de gestin
del riesgo, organizados en forma externa a la oficina de proyecto, pueden ser capaces de
lograr un anlisis ms independiente e imparcial del proyecto que el del equipo patrocinante del proyecto.
Asignacin de presupuesto. Establece un presupuesto para la gestin del riesgo del
proyecto.
Periodicidad. Define con qu frecuencia el proceso de gestin del riesgo ser realizado
a travs de todo el ciclo de vida del proyecto. Los resultados deberan ser elaborados en
forma suficientemente temprana como para poder ser tomados en cuenta en las decisiones.
stas deberan ser revisadas peridicamente durante la ejecucin del proyecto.
Puntaje e interpretacin. Los mtodos de puntuacin e interpretacin apropiados para el
tipo y frecuencia del anlisis cualitativo y cuantitativo de riesgos que se est realizando. Los
mtodos y el puntaje deben ser determinados con anticipacin para asegurar consistencia.
Umbrales. El criterio de umbrales para el tratamiento de los riesgos, incluyendo quin y de
que forma los tratar. El dueo del proyecto, el cliente o el patrocinante pueden tener
diferentes umbrales de riesgo. El umbral aceptado constituye el objetivo contra el cual el
equipo del proyecto mide la eficacia de la ejecucin del plan de respuesta al riesgo.
Formatos de reporte. Describen el contenido y formato del plan de respuesta al riesgo
reseado en la seccin 11.5.3.1. Definen cmo los resultados de los procesos de gestin de
riesgos sern documentados, analizados y comunicados al equipo del proyecto, a los interesados, internos y externos a la organizacin, a los patrocinantes y a otros.
Seguimiento. Documenta cmo todas las facetas de las actividades de riesgo sern registradas para beneficio del proyecto en curso, para futuras necesidades y para las lecciones
aprendidas. Documenta si sern auditados los procesos de riesgo y cmo.
11.2 IDENTIFICACIN DE RIESGOS

La identificacin de riesgos implica determinar qu riesgos podran afectar el proyecto y documentar sus caractersticas.
Quienes generalmente participan en la identificacin de riesgos son: el equipo de proyecto,
el equipo de gestin de riesgos, expertos en la materia provenientes de otras reas de la compaa, clientes, usuarios finales, otros directores de proyectos, interesados en el proyecto y
expertos externos.
La identificacin de riesgos es un proceso iterativo. La primera iteracin puede ser realizada
por una parte del equipo del proyecto o por el equipo de gestin de riesgos. El equipo del
proyecto en su totalidad y los principales interesados en el proyecto pueden realizar una
segunda iteracin. Para lograr un anlisis imparcial, la iteracin final podra ser realizada por
personas que no estn involucradas en el proyecto.
A menudo, tan pronto como el riesgo es identificado, pueden ser desarrolladas e inclusive
implementadas respuestas simples y efectivas.
11.2.1
.1
.2
.3
Entradas a Identificacin de Riesgos

Plan de gestin del riesgo. Este plan se describe en la seccin 11.1.3.
Salidas de planificacin del proyecto. La identificacin de riesgos requiere el entendimiento de
la misin, del alcance y de los objetivos del dueo, del patrocinante y de interesados en el
proyecto. Las salidas de otros procesos deberan ser revisadas para identificar posibles riesgos
a travs de todo el proyecto. stos pueden incluir, pero no estn limitados a:
Acta del proyecto.
WBS.
Descripcin del producto.
Estimaciones de tiempos y costos.
Plan de recursos.
Plan de adquisiciones.
Listas de hiptesis y restricciones.
Categoras de riesgo. Los riesgos que pueden afectar al proyecto, de manera favorable o
adversa, pueden ser identificados y organizados en categoras. Las categoras de riesgo
deberan estar bien definidas y deberan reflejar fuentes comunes de riesgo para el rea o
industria de aplicacin. Las categoras incluyen lo siguiente:
Riesgos tcnicos, de calidad o ejecucin tales como confiabilidad de una tecnologa
compleja o an no probada, objetivos de ejecucin no realistas, cambios a la tecnologa
usada o a los estndares de la industria durante el proyecto.
131
11.2.1.4 | 11.3
.4
11.2.2
.1
.2
132
Riesgos de gestin del proyecto tales como deficiente asignacin de tiempos y recursos,
calidad inadecuada del plan del proyecto y pobre uso de las disciplinas de gestin del
proyecto.
Riesgos de la organizacin tales como objetivos de costo, tiempo y alcance que son
internamente inconsistentes, falta de priorizacin de proyectos, financiacin inadecuada
o interrumpida y conflictos de recursos con otros proyectos de la organizacin.
Riesgos externos tales como entorno legal o regulatorio cambiante, cuestiones laborales,
prioridades cambiantes del dueo, riesgo del pas y clima meteorolgico. Riesgos de fuerza
mayor (force majeure), tales como terremotos, inundaciones e intranquilidad social
requieren generalmente, ms que gestin del riesgo, acciones de recuperacin ante desastres.
Informacin histrica. Las siguientes fuentes pueden proveer informacin de proyectos anteriores:
pueden mantener registros de los resultados de otros proyectos, los que pueden ser usados
para identificar riesgos. stos pueden ser reportes finales de proyecto o planes de
respuestas al riesgo. Pueden incluir lecciones aprendidas organizadas, que describen los
problemas y sus soluciones o estar disponibles a travs de la experiencia de los interesados
en el proyecto, u otros de la organizacin.
Informacin publicada la informacin para muchas reas de aplicacin puede encontrarse en bases de datos comerciales, estudios acadmicos, evaluaciones comparativas y
otros estudios publicados.
Tcnicas y Herramientas para la Identificacin de Riesgos

Revisin de documentos. En general, lo que inicialmente hacen los equipos de proyecto es
una revisin estructurada de los planes de proyecto e hiptesis, tanto a nivel total del proyecto
como de detalle a travs de los niveles del alcance, de los archivos de proyectos anteriores y
de otras informaciones.
Tcnicas de recopilacin de informacin. La tormenta de ideas, la tcnica Delphi, las entrevistas y los anlisis de fortalezas, debilidades, oportunidades y amenazas (SWOT) pueden ser
ejemplos de tcnicas de recopilacin de informacin usadas en la identificacin de riesgos.
Tormenta de ideas. La tormenta de ideas es probablemente la tcnica ms frecuentemente
usada en identificacin de riesgos. El objetivo es obtener una lista exhaustiva de riesgos,
que pueda ser examinada ms tarde en los procesos de anlisis cualitativo y cuantitativo.
El equipo del proyecto emplea usualmente esta tcnica, aunque tambin puede ser
usada por un conjunto multidisciplinario de expertos. Bajo el liderazgo de un facilitador, se
generan ideas acerca de los riesgos del proyecto. Durante la reunin se identifica una
amplia gama de fuentes de riesgo, las que luego quedan disponibles para ser analizadas.
Los riesgos son luego categorizados por tipo de riesgo y sus definiciones son ajustadas.
La tcnica Delphi. La tcnica Delphi es una forma de alcanzar consenso entre un grupo de
expertos acerca de un tema tal como los riesgos de un proyecto. Los expertos son identificados, pero su participacin es annima.
Un facilitador emplea un cuestionario para solicitar ideas acerca de los riesgos importantes del proyecto. Las respuestas recibidas son luego enviadas a los expertos para comentarios adicionales. El consenso acerca de los riesgos principales del proyecto puede ser
obtenido luego de algunas vueltas de este proceso. La tcnica Delphi ayuda a reducir
ciertos prejuicios relacionados con los datos y evita que algunas personas ejerzan influencias impropias en el resultado.
Entrevistas. Los riesgos pueden ser identificados entrevistando a directores de proyectos
experimentados o a expertos en el tema. La persona responsable para la identificacin de
riesgos individualiza a las personas correspondientes, les da un breve informe del proyecto
.3
.4
.5
11.2.3
.1
.2
.3
y les suministra informacin tal como la estructura detallada del trabajo y la lista de
hiptesis. Los entrevistados identifican riesgos en el proyecto basndose en su experiencia,
en la informacin del proyecto y en otras fuentes que ellos consideren tiles.
Anlisis de fortalezas, debilidades, oportunidades y amenazas (SWOT). Asegura un examen
del proyecto desde cada una de las perspectivas del SWOT para incrementar el espectro de
los riesgos considerados.
Listas de verificacin. Listas de verificacin para identificacin de riesgos pueden ser desarrolladas basndose en informacin histrica y en el conocimiento que ha sido acumulado de
proyectos previos similares y de otras fuentes de informacin. Una ventaja del uso de una lista
de verificacin es que la identificacin de riesgos es rpida y simple. Una desventaja es la
imposibilidad de construir una lista de verificacin exhaustiva de riesgos y que el usuario se
limite exclusivamente a las categoras del listado. Debe tenerse especial cuidado en explorar
temas que no aparecen en la lista de verificacin estndar si se considera que ellos son relevantes al proyecto especfico. La lista de verificacin debera pormenorizar todos los tipos de
riesgos posibles al proyecto. Es importante revisar la lista como un paso formal de cada procedimiento de cierre de proyecto, para mejorar la lista de los riesgos potenciales y la descripcin de los riesgos.
Anlisis de hiptesis. Cada proyecto es concebido y desarrollado sobre la base de un conjunto
de hiptesis, escenarios o supuestos. El anlisis de hiptesis es una tcnica que explora la
validez de las mismas. Identifica riesgos al proyecto originados en la inexactitud, la inconsistencia o la imperfeccin de las hiptesis.
Tcnicas de diagramacin. Ellas pueden incluir:
Diagramas de causa y efecto (tambin conocidos como de Ishikawa o de espina de
pescado) tiles para identificar causas de riesgos (descritos en seccin 8.1.2.3).
Diagramas de flujo de sistemas o procesos muestra cmo se relacionan diferentes elementos de un sistema y el mecanismo de causalidad (descritos en seccin 8.1.2.3).
Diagramas de Influencia una representacin grafica de un problema mostrando las
influencias causales, el orden en el tiempo de los sucesos y otras relaciones entre las variables y los resultados.
Salidas de la Identificacin de Riesgos

Riesgos. Un riesgo es un suceso o condicin incierta que, si ocurre, tiene un efecto positivo
o negativo en los objetivos del proyecto.
Disparadores. Tambin llamados sntomas o seales de advertencia de riesgos, son indicios
que un riesgo ha ocurrido o est por ocurrir. Por ejemplo, el fracaso en cumplir hitos intermedios puede ser una seal de advertencia anticipada de un inminente atraso de tiempo.
Entradas de otros procesos. La identificacin de riesgos puede mostrar una necesidad de
acciones adicionales en otra rea. Por ejemplo, la WBS puede no tener suficiente detalle para
permitir una identificacin adecuada de riesgos o la programacin de tiempos puede ser
incompleta o no enteramente lgica.
11.3 ANLISIS CUALITATIVO DE RIESGOS

El anlisis cualitativo de riesgos es el proceso de evaluar el impacto y la probabilidad de los
riesgos identificados. Este proceso otorga prioridades a los riesgos de acuerdo con su efecto
potencial en los objetivos del proyecto. El anlisis cualitativo de riesgos es una forma de determinar la importancia de tratar riesgos especficos y guiar las respuestas a los mismos. La criticidad de los tiempos de acciones relacionadas con riesgos puede aumentar la importancia de
un riesgo. Una evaluacin de la calidad de la informacin disponible tambin ayuda a modificar la evaluacin del riesgo. El anlisis cualitativo de riesgos requiere que la probabilidad y
consecuencias de los riesgos sean evaluados usando mtodos y herramientas establecidos de
anlisis cualitativo.
133
11.3.1 | 11.3.2.4
Cuando el anlisis cualitativo es repetido, las tendencias en los resultados pueden indicar la
necesidad de ms o menos acciones de gestin de riesgos. El uso de estas herramientas ayuda
a corregir subjetividades que estn siempre presentes en un plan de proyecto. El anlisis cualitativo de riesgos debera ser continuamente revisado durante el ciclo de vida del proyecto para
estar actualizado con los cambios en los riesgos del mismo. Este proceso puede conducir a un
anlisis adicional en el anlisis cuantitativo de riesgos (11.4) o directamente a la planificacin
de respuesta a al riesgo (11.5).
11.3.1
.1
.2
.3
.4
.5
.6
.7
11.3.2
.1
134
Entradas al Anlisis Cualitativo de Riesgos

Plan de gestin del riesgo. Este plan es descrito en la seccin 11.1.3.
Riesgos identificados. Los riesgos descubiertos durante el proceso de identificacin de riesgos
son evaluados junto con su potencial impacto en el proyecto.
Estado del proyecto. La incertidumbre de un riesgo depende a menudo del progreso del
proyecto a travs de su ciclo de vida. Al inicio del proyecto, muchos riesgos an no se han
manifestado; el diseo del proyecto es inmaduro y pueden ocurrir cambios, haciendo todo esto
posible que luego puedan descubrirse ms riesgos.
Tipo de proyecto. En los proyectos de tipo comn o recurrente puede comprenderse mejor la
probabilidad de ocurrencia de sucesos de riesgo y sus consecuencias. Los proyectos que usan
tecnologa de punta o primera en su clase o proyectos altamente complejos tienden a
tener mayor incertidumbre.
Precisin de los datos. La precisin describe la medida en que se conoce y entiende un riesgo.
Ella mide la magnitud de informacin disponible y la confiabilidad de la misma. La fuente de
informacin que fue usada para identificar el riesgo debe ser evaluada.
Escalas de probabilidad e impacto. Estas escalas, tal como son descritas en la seccin 11.3.2.2,
sern usadas en la evaluacin de dos dimensiones claves del riesgo, tratadas en la seccin
11.3.2.1.
Hiptesis. Las hiptesis identificadas durante el proceso de identificacin de riesgos son
evaluadas como potenciales riesgos (vanse las secciones 4.1.1.5 y 11.2.2.4).
Tcnicas y Herramientas para el Anlisis Cualitativo de Riesgos

Probabilidad e impacto del riesgo. La probabilidad y las consecuencias de los riesgos pueden
ser descritas en trminos cualitativos tales como muy alto, alto, moderado, bajo y muy bajo.
Probabilidad del riesgo es la posibilidad de que un riesgo pueda ocurrir.
Consecuencia del riesgo es el efecto en los objetivos del proyecto si el suceso de riesgo
ocurre.
Estas dos dimensiones del riesgo son aplicadas a sucesos especficos de riesgo, no al
proyecto en su conjunto. El anlisis de riesgos usando la probabilidad y las consecuencias
ayuda a identificar aquellos riesgos que deben ser tratados agresivamente.
.2
.3
.4
Matriz de evaluacin de probabilidad e impacto del riesgo. Se puede construir una matriz para
asignar calificaciones de riesgo (muy bajo, bajo, moderado, alto y muy alto) a riesgos o condiciones basndose en la combinacin de escalas de probabilidad e impacto. Riesgos con alta
probabilidad y alto impacto probablemente requieran un anlisis adicional, incluyendo la cuantificacin y una gestin de riesgos agresiva.
Una escala de probabilidad de riesgos naturalmente cae entre 0.0 (no existe probabilidad)
y 1.0 (certeza). Evaluar la probabilidad de un riesgo puede ser dificultoso ya que normalmente
se usa un juicio basado en la experiencia, el cual a menudo no tiene el beneficio de la informacin histrica. Se puede usar una escala ordinal, que representa valores relativos de probabilidad desde muy improbable hasta casi seguro. Alternativamente, probabilidades especficas
pueden ser asignadas usando una escala general (por ejemplo: .1 / .3 / .5 / .7 / .9).
La escala de impacto de riesgos refleja la severidad de sus efectos en los objetivos del
proyecto. El impacto puede ser ordinal o cardinal, dependiendo de los hbitos de la organizacin que realiza el anlisis. Las escalas ordinales son simplemente valores ordenados por
rango, tales como muy bajo, bajo, moderado, alto y muy alto. Las escalas cardinales asignan
valores a estas repercusiones. Estos valores son usualmente lineales (por ejemplo, .1 / .3 / .5 /
.7 / .9), pero tambin muchas veces son no lineales (por ejemplo, .05 / .1 / .2 / .4 / .8), reflejando el deseo de la organizacin de evitar riesgos de alto impacto. El propsito de ambos
enfoques, si el riesgo en cuestin ocurre, es asignar valores relativos al impacto en los objetivos del proyecto. Escalas claramente definidas, ya sean ordinales o cardinales, pueden ser
desarrolladas usando definiciones acordadas por la organizacin. Estas definiciones mejoran la
calidad de la informacin y hacen que el proceso sea ms repetible.
La figura 11-2 es un ejemplo de evaluacin de los impactos de riesgo por objetivos del
proyecto. Ella ilustra su uso tanto para un enfoque ordinal como cardinal. Estas descripciones
en escalas de impactos relativos deberan ser preparadas por la organizacin antes de que el
proyecto comience.
La figura 11-3 es una matriz de probabilidad-impacto (P-I). Ella ilustra la simple multiplicacin de los valores de la escala asignados a estimaciones de probabilidad e impacto, siendo
sta una forma comn de combinar las dos dimensiones para determinar si un riesgo es considerado bajo, moderado o alto. Esta figura presenta una escala no lineal como un ejemplo de
aversin a riesgos de alto impacto, aunque tambin a menudo se usan escalas lineales. Alternativamente, la matriz P-I puede ser desarrollada usando escalas ordinales. La organizacin
debe determinar qu combinacin de probabilidad e impacto hace que un riesgo sea clasificado como alto (estado rojo), moderado (estado amarillo) o bajo (estado verde) en cada caso.
La calificacin del riesgo ayuda a poner al mismo en una categora que servir de gua para las
acciones de respuesta al riesgo.
Comprobacin de las hiptesis del proyecto. Las hiptesis identificadas deben ser comprobadas sobre la base de dos criterios: estabilidad de la hiptesis y consecuencias para el
proyecto si la suposicin resultara falsa. Durante el proceso de anlisis cualitativo de riesgos
deberan identificarse las hiptesis alternativas que pueden ser ciertas y comprobarse sus consecuencias en los objetivos del proyecto.
Clasificacin de la precisin de los datos. El anlisis cualitativo de riesgos requiere informacin precisa y no tendenciosa para que sea til a la gestin del proyecto. La clasificacin de la
precisin de la informacin es una tcnica para evaluar el grado con el cual la informacin
acerca de los riesgos es til para la gestin de los mismos. Ello implica examinar:
El grado de conocimiento del riesgo.
La informacin disponible acerca del riesgo.
La calidad de la informacin.
Confiabilidad e integridad de la informacin.
135
Figura 112 | 11.4
Figura 112. Clasificacin de Impactos de un Riesgo
El uso de informacin de baja precisin por ejemplo, si un riesgo no es bien entendido

puede llevar a un anlisis cualitativo de poco valor para el director del proyecto. Si la clasificacin de la precisin de la informacin es inaceptable, se hace necesario recolectar mejor
informacin.
11.3.3
.1
.2
.3
136
Salidas al Anlisis Cualitativo de Riesgos

Clasificacin general del riesgo del proyecto. La clasificacin del riesgo puede indicar la posicin general de riesgo en un proyecto en relacin a otros proyectos por medio de la comparacin de sus calificaciones de riesgo. Esto puede ser usado para asignar personal u otros
recursos a proyectos con diferentes calificaciones de riesgo, para tomar una decisin acerca del
proyecto basada en un anlisis de costo-beneficio o para respaldar una recomendacin de iniciacin, continuacin o cancelacin del proyecto.
Lista de riesgos ordenados por prioridad. Los riesgos y las condiciones pueden ser ordenados
por prioridad segn diferentes criterios. Esto incluye calificacin o nivel (alto, moderado y
bajo) de la WBS. Los riesgos pueden ser agrupados en riesgos que requieren respuesta
inmediata y riesgos que pueden ser tratados ms adelante. Los riesgos que afectan costo,
tiempo, funcionalidad y calidad deber ser evaluados separadamente con diferentes calificaciones. Los riesgos crticos deben tener una descripcin de los fundamentos con los que se
evaluaron la probabilidad y el impacto.
Lista de riesgos para anlisis y gestin adicional. Los riesgos clasificados como altos o moderados son los primeros candidatos para un mayor anlisis, incluyendo un anlisis cuantitativo,
y acciones de gestin de riesgos.
Figura 113. Matriz de Probabilidad-Impacto
.4
Tendencias en los resultados del anlisis cualitativo de riesgos. A medida que se repite el
anlisis, se puede apreciar una tendencia en los resultados y se puede tornar ms o menos
urgente e importante encontrar respuestas a los riesgos o efectuar un anlisis adicional de los
mismos.
11.4 ANLISIS CUANTITATIVO DE RIESGOS

El proceso de anlisis cuantitativo de riesgos tiene por finalidad analizar numricamente la
probabilidad de cada riesgo y sus consecuencias en los objetivos del proyecto, como as tambin la magnitud del riesgo total del proyecto. Este proceso usa tcnicas tales como la simulacin Monte Carlo y el anlisis de decisiones para:
Determinar la probabilidad de lograr un objetivo especfico del proyecto.
Cuantificar la exposicin al riesgo del proyecto y determinar el tamao de las reservas de
contingencia de costo y tiempo necesarias.
Identificar los riesgos que requieren una mayor atencin mediante la cuantificacin de su
contribucin relativa al riesgo del proyecto.
Identificar objetivos de costo, tiempo y alcance realistas y alcanzables.
El anlisis cuantitativo generalmente sigue al anlisis cualitativo de riesgos. Aqul requiere
la identificacin del riesgo. Los procesos de anlisis cualitativo y cuantitativo de riesgos pueden
ser realizados juntos o separados. Consideraciones de disponibilidad de tiempo y presupuesto
y la necesidad de enunciados cualitativos y cuantitativos acerca de los riesgos y sus impactos
determinarn los mtodos a ser usados. Cuando el anlisis cuantitativo es repetido, las tendencias en los resultados pueden indicar la necesidad de ms o menos acciones de gestin de
riesgos.
137
11.4.1 | 11.4.3.4
11.4.1
.1
.2
.3
.4
.5
.6
.7
11.4.2
.1
138
Entradas al Anlisis Cuantitativo de Riesgos

Plan de gestin de riesgos. Este plan es descrito en la seccin 11.1.3.
Riesgos identificados. stos son descritos en la seccin 11.2.3.1.
Lista de riesgos ordenados por prioridad. Descrita en la seccin 11.3.3.2.
Lista de riesgos para anlisis y gestin adicional. Descrita en la seccin 11.3.3.3.
Informacin histrica. Informacin de proyectos anteriores similares ya completados, estudios
de proyectos similares por especialistas de riesgo y bases de datos de riesgos que pueden estar
disponibles, originadas en fuentes de la industria o del propietario (vase la seccin 11.2.1.4).
Juicio de expertos. La informacin puede provenir del equipo del proyecto o de otros
expertos en la materia que estn dentro o fuera de la organizacin. Otras fuentes de informacin incluyen expertos en ingeniera o en estadsticas (vase la seccin 5.1.2.2).
Otras salidas de planificacin. Las salidas ms tiles de planificacin son la lgica del proyecto
y las estimaciones de duracin usadas en determinar los cronogramas, el listado de la estructura detallada del trabajo (WBS) con el detalle de todos los elementos de costo con las estimaciones de costos y modelos de los objetivos tcnicos del proyecto.
Tcnicas y Herramientas para el Anlisis Cuantitativo de Riesgos

Entrevistas. Las tcnicas de entrevista son usadas para cuantificar la probabilidad y las consecuencias del riesgo en los objetivos del proyecto. Una entrevista de riesgos con los interesados en el proyecto y con expertos especialistas en la materia puede ser el primer paso en
la cuantificacin de riesgos. La informacin necesaria depende del tipo de distribucin de
probabilidad que ser usada. Por ejemplo, si se usan distribuciones triangulares, la informacin
se podra recolectar agrupndola en escenarios optimistas (bajo), pesimistas (alto) y ms probables o en media y desviacin estndar para distribuciones normal y logartmica normal.
Ejemplos de estimaciones de tres valores para una evaluacin de costos son mostrados en la
figura 11-4.
Las distribuciones continuas de probabilidad se usan usualmente en el anlisis cuantitativo
de riesgos. Las distribuciones representan la probabilidad y las consecuencias del componente
del proyecto. Los tipos de distribucin comn incluyen la uniforme, normal, triangular, beta
y logartmica normal. Dos ejemplos de estas distribuciones son mostrados en la figura 11-5
(donde el eje vertical representa la probabilidad y el horizontal el impacto).
La documentacin que fundamenta los rangos de riesgo es un componente importante de
las entrevistas de riesgos, ya que puede conducir a implementar estrategias efectivas para la
respuesta al riesgo en el proceso de planificacin de respuestas al mismo, descrito en la seccin 11.5.
Figura 114. Estimacin de Costos y Rangos de la Entrevista del Riesgo
.2
.3
.4
11.4.3
.1
.2
.3
.4
Anlisis de sensibilidad. El anlisis de sensibilidad ayuda a determinar qu riesgos tienen el

mayor potencial de impacto en el proyecto. Este mtodo evala el grado en que la incertidumbre de cada elemento del proyecto afecta al objetivo que est siendo examinado cuando
todos los dems elementos inciertos son mantenidos en sus valores bsicos.
Anlisis del rbol de decisiones. Un anlisis de decisiones es usualmente estructurado como
un rbol de decisiones. ste es un diagrama que describe una decisin bajo consideracin y
las implicancias de elegir una u otra de las alternativas disponibles. Incorpora probabilidades
de riesgos y los costos o beneficios de cada camino lgico de sucesos y decisiones futuras.
La resolucin del rbol de decisin permite ver cul decisin produce el mayor valor esperado
al tomador de decisin, cuando todas las implicancias inciertas, costos, beneficios y decisiones
inciertas subsecuentes son cuantificadas. Un rbol de decisiones es mostrado en la figura
11-6.
Simulacin. Una simulacin de proyecto usa un modelo que traduce las incertidumbres especificadas a un nivel detallado en su impacto potencial en los objetivos, que estn expresados
al nivel de todo el proyecto. Las simulaciones de proyecto son generalmente realizadas usando
la tcnica Monte Carlo.
Para un anlisis de riesgos de costos, la simulacin puede usar la tradicional WBS del
proyecto como su modelo. Para un anlisis de riesgos de tiempo, se usa el mtodo del diagrama de precedencia (MDP) (vase la seccin 6.2.2.1).
Un resultado de una simulacin de riesgos de costos se muestra en la figura 11-7.
Salidas del Anlisis Cuantitativo de Riesgos

Lista priorizada de riesgos cuantificados. Esta lista de riesgos incluye aquellos que conllevan
la mayor amenaza o presentan la mayor oportunidad al proyecto conjuntamente con la medida
de su impacto.
Anlisis probabilstico del proyecto. Pronsticos de resultados potenciales de tiempos y costos
del proyecto, listando las fechas posibles de terminacin o la duracin y el costo del proyecto
con sus niveles asociados de confianza.
Probabilidad de lograr los objetivos de costo y tiempo. La probabilidad de lograr los objetivos
del proyecto en el plan en curso y con el conocimiento actual de los riesgos que enfrenta el
proyecto puede ser estimada usando anlisis de riesgo cuantitativo.
Tendencias en los resultados del anlisis cuantitativo de riesgos. A medida que el anlisis es
repetido, se puede manifestar una tendencia en los resultados.
139
Figura 115 | 11.5.2
Figura 115. Ejemplos de Distribuciones de Probabilidad Comnmente Usadas
11.5 PLANIFICACIN DE LA RESPUESTA A RIESGOS

La planificacin de la respuesta a los riesgos es el proceso de desarrollar opciones y determinar
acciones para incrementar las oportunidades y reducir las amenazas a los objetivos del
proyecto. Ello incluye la identificacin y asignacin de individuos o sectores para tomar la
responsabilidad de cada una de las respuestas al riesgo acordadas. Este proceso asegura que
los riesgos identificados son tratados apropiadamente. La eficacia de la planificacin de las
respuestas determinar directamente si el riesgo del proyecto aumenta o disminuye.
La planificacin de la respuesta al riesgo debe ser congruente con la severidad del riesgo,
con un costo efectivo en relacin al desafo, aplicada a tiempo para ser exitosa, realista dentro
del contexto del proyecto, acordada por todas las partes involucradas y debe estar a cargo de
una persona responsable. A menudo se requiere seleccionar, entre varias opciones, la mejor
respuesta al riesgo.
11.5.1
.1
.2
.3
140
Entradas a la Planificacin de la Respuesta a Riesgos

Plan de gestin del riesgo. Este plan es descrito en la seccin 11.1.3.
Lista de riesgos priorizados. Esta lista, proveniente del anlisis cualitativo de riesgos, es descrita
Clasificacin general del riesgo del proyecto. Esto es descrito en la seccin 11.3.3.1.
Figura 116. Anlisis del rbol de Decisiones
.4
.5
.6
.7
.8
.9
.10
.11
11.5.2
Lista priorizada de riesgos cuantificados. Esta lista proveniente del anlisis cuantitativo de
riesgos es descrita en la seccin 11.4.3.1.
Anlisis probabilstico del proyecto. Esto es descrito en la seccin 11.4.3.2.
Probabilidad de lograr los objetivos de costo y tiempo. Esto es descrito en la seccin 11.4.3.3.
Lista de respuestas potenciales. En el proceso de identificacin pueden haberse identificado
acciones que respondan a riesgos individuales o a categoras de riesgos.
Lmites de riesgo. El umbral de riesgo que es aceptable a la organizacin influenciar la planificacin de la respuesta al riesgo (vase la seccin 11.1.3).
Responsables del riesgo. Una lista de los interesados en el proyecto capaces de actuar como
responsables de las respuestas al riesgo. Estos deberan estar involucrados en el desa-rrollo de
dichas respuestas.
Causas comunes de riesgos. Diferentes riesgos pueden ser generados por una causa comn.
Esta situacin puede poner al descubierto oportunidades para mitigar dos o ms riesgos del
proyecto con una nica respuesta genrica.
Tendencias en los resultados del anlisis cualitativo y cuantitativo y de riesgos. Esto es descrito
en las secciones 11.3.3.4 y 11.4.3.4. Las tendencias en los resultados pueden hacer ms o
menos urgente e importante una respuesta o un anlisis adicional del riesgo.
Tcnicas y Herramientas para la Planificacin de la Respuesta a Riesgos

Diferentes estrategias de respuesta a los riesgos estn disponibles. Para cada riesgo debera ser
seleccionada aquella estrategia con mayor probabilidad de xito. Luego se deberan desarrollar
acciones especficas para implementar dicha estrategia. Pueden ser seleccionadas estrategias
primarias y de respaldo.
141
Figura 117 | 11.5.3.3
Figura 117. Simulacin del Riesgo de Costo
.1
.2
.3
142
Evitacin. Evitar riesgos es cambiar el plan del proyecto para eliminar el riesgo o sus condiciones o para proteger los objetivos del proyecto de su impacto. Aunque el equipo del
proyecto no puede eliminar todos los sucesos de riesgo, algunos sucesos especficos pueden
ser evitados.
Algunos sucesos de riesgo que surgen temprano en el proyecto pueden ser gestionados por
medio de la clarificacin de los requerimientos, obteniendo informacin, mejorando la comunicacin o adquiriendo experiencia. La reduccin del alcance para evitar actividades de alto
riesgo, la adicin de recursos o tiempo, la adopcin de un enfoque conocido en vez de uno
innovador o abstenerse de recurrir a un contratista desconocido son algunos ejemplos de
evitacin.
Transferencia. La transferencia del riesgo busca trasladar las consecuencias de un riesgo a una
tercera parte conjuntamente con la responsabilidad por la respuesta. Transferir el riesgo simplemente le otorga a la otra parte la responsabilidad de su gestin; no lo elimina.
Transferir obligaciones por riesgos es ms efectivo cuando se trata de riesgos de exposicin
financiera. La transferencia del riesgo casi siempre involucra el pago de una prima a la parte
que toma el riesgo. Esto incluye el uso de seguros, garantas de cumplimiento, cauciones y
certificados de garanta. Pueden usarse contratos para transferir a un tercero obligaciones por
riesgos especificados. Si el diseo del proyecto es estable, el uso de contratos de precio fijo
puede transferir los riesgos al vendedor.
Mitigacin. La mitigacin busca reducir la probabilidad y/o consecuencias de sucesos adversos
de riesgo a un lmite aceptable. Tomar acciones tempranas para reducir la probabilidad de la
ocurrencia de un riesgo o su impacto en el proyecto es ms efectivo que tratar de reparar las
consecuencias despus de que ha ocurrido. Los costos de mitigacin deberan ser adecuados
a la presunta probabilidad del riesgo y sus consecuencias.
.4
11.5.3
.1
.2
.3
La mitigacin del riesgo puede tomar la forma de la implementacin de un nuevo curso de

accin que reducir el problema por ejemplo, adoptar procesos menos complejos, realizar
ms pruebas ssmicas o de ingeniera o elegir un proveedor ms estable. Puede involucrar el
cambio de condiciones de manera que la probabilidad de la ocurrencia del riesgo se reduzca
por ejemplo, aadir recursos o tiempo al programa de trabajo. Puede requerir el desarrollo
de un prototipo para reducir el riesgo de pasar de un modelo en escala a uno de tamao real.
Donde no es posible reducir la probabilidad, una respuesta de mitigacin puede tratar el
impacto del riesgo, tratando especficamente los elementos que determinan su severidad. Por
ejemplo, diseando redundancia en un subsistema se puede reducir el impacto que resulta de
la falla del componente original.
Aceptacin. Esta tcnica indica que el equipo del proyecto ha decidido no cambiar el plan del
proyecto para tratar el riesgo o es incapaz de identificar cualquier otra estrategia de respuesta
adecuada. La aceptacin activa puede incluir el desarrollo de un plan de contingencia, para ser
ejecutado si el riesgo ocurre. La aceptacin pasiva no requiere accin alguna, dejando en
manos del equipo del proyecto la gestin del riesgo si ste ocurre.
Un plan de contingencia se aplica a riesgos identificados que surgen durante el proyecto.
El desarrollo por adelantado de un plan de contingencia puede reducir en gran medida el
costo de una accin a tomar si ocurre el riesgo. Los disparadores de riesgo, tales como no
cumplir con hitos intermedios, deben ser definidos y controlados. Un plan de reserva debe ser
desarrollado si el riesgo tiene un alto impacto o si la estrategia seleccionada puede no ser completamente eficaz. Esto podra incluir la asignacin de una cantidad de reserva de contingencia,
el desarrollo de opciones alternativas o un cambio en el alcance del proyecto.
La respuesta de aceptacin a riesgos ms usual es la de establecer una asignacin de contingencia o reserva, incluyendo cantidades de tiempo, dinero o recursos para responder a
riesgos conocidos. La asignacin debera ser determinada por las repercusiones, computadas
a un nivel aceptable de exposicin, para los riesgos que han sido aceptados.
Salidas de la Planificacin de la Respuesta a Riesgos

Plan de respuesta al riesgo. El plan de respuestas al riesgo (algunas veces llamado registro de
riesgos) debe ser escrito al nivel de detalle al cual las acciones sern tomadas. Debe incluir
alguno de o todos los siguientes puntos:
Riesgos identificados, sus descripciones, las reas del proyecto afectadas (por ejemplo: un
elemento de la WBS), sus causas y cmo ellas pueden afectar los objetivos del proyecto.
Los responsables del riesgo y sus obligaciones asignadas.
Resultados de los procesos de anlisis cualitativo y cuantitativo de los riesgos.
Respuestas acordadas incluyendo evitacin, transferencia, mitigacin o aceptacin de cada
riesgo en el plan de respuesta al riesgo.
El nivel de riesgo residual restante esperado despus de que la estrategia es implementada.
Acciones especficas para implementar la estrategia de respuesta elegida.
Presupuesto y tiempos de respuesta.
Planes de contingencia y alternativos.
Riesgos residuales. Riesgos residuales son aquellos que an quedan despus de haber implementado respuestas de evitacin, transferencia o mitigacin. Tambin incluyen riesgos menores
que han sido aceptados y tratados, por ejemplo adicionando montos de contingencia al costo
o tiempo permitidos.
Riesgos secundarios. Los riesgos que surgen como un resultado directo de implementar una
respuesta a los riesgos son denominados riesgos secundarios. Los mismos deben ser identificados y sus respuestas planificadas.
143
11.5.3.4 | 11.6.2.5
.4
.5
.6
.7
11.6
Acuerdos contractuales. stos pueden ser convenidos para especificar la responsabilidad de

las partes ante la ocurrencia de riesgos especficos y por seguros, servicios y otros medios
apropiados para evitar o mitigar amenazas.
Montos necesarios de reservas de contingencia. El anlisis probabilstico del proyecto
(11.4.3.2) y los umbrales de riesgo (11.1.3.1) ayudan al director del proyecto a determinar el
monto de reserva o contingencia necesario para reducir a un nivel aceptable para la organizacin el riesgo de sobrepasar los objetivos del proyecto.
Entradas a otros procesos. La mayora de las respuestas al riesgo involucran erogaciones adicionales de tiempo, costo o recursos y requieren cambios al plan del proyecto. Las organizaciones quieren tener la seguridad de que la erogacin est justificada por el nivel de reduccin
de riesgos. Estrategias alternativas deben realimentar a los procesos apropiados de otras reas
de conocimiento.
Entradas a un plan revisado del proyecto. Los resultados del proceso de planificacin de
respuesta deben ser incorporados al plan del proyecto para garantizar que las acciones acordadas sean implementadas y supervisadas como parte de la ejecucin del proyecto.
SUPERVISIN Y CONTROL DE RIESGOS

La supervisin y el control de los riesgos es el proceso que se ocupa del seguimiento de los
riesgos identificados, de la supervisin de los riesgos residuales y de la identificacin de
nuevos riesgos, asegurando la ejecucin de los planes de riesgo y evaluando su eficacia en la
reduccin de los mismos. La supervisin y control de los riesgos registra las mtricas que estn
asociadas con la implementacin de los planes de contingencia. ste es un proceso que se
realiza continuamente durante todo el ciclo de vida del proyecto. Los riesgos cambian a
medida que el proyecto madura; nuevos riesgos aparecen o riesgos previstos desaparecen.
Buenos procesos de supervisin y control de los riesgos proveen informacin que ayuda a
tomar decisiones eficaces en forma anticipada a la ocurrencia del riesgo. La comunicacin a
todos los interesados en el proyecto es necesaria para evaluar peridicamente la aceptacin
del nivel de riesgo en el proyecto.
El propsito de supervisar los riesgos es determinar si:
Las respuestas a los riesgos han sido implementadas como fueron planeadas.
Las acciones de respuestas a los riesgos son tan efectivas como se esperaba o si se debe
desarrollar nuevas respuestas.
Las hiptesis del proyecto son an vlidas.
La exposicin a los riesgos ha cambiado desde su anterior estado, a travs del anlisis de
tendencias.
Un disparador de riesgo ha ocurrido.
Se han seguido polticas y procedimientos apropiados.
Han aparecido u ocurrido riesgos que no haban sido previamente identificados.
El control de riesgos puede involucrar la eleccin de estrategias alternativas, la implementacin de un plan de contingencia, la toma de acciones correctivas o la re-planificacin del
proyecto. El responsable de la respuesta al riesgo debera reportar peridicamente al director
del proyecto y al lder de riesgo del equipo la eficacia del plan, cualquier efecto no anticipado
y cualquier correccin sobre la marcha necesaria para mitigar el riesgo.
144
11.6.1
.1
.2
.3
.4
.5
11.6.2
.1
.2
.3
.4
.5
Entradas a la Supervisin y Control del Riesgo

Plan de gestin del riesgo. ste es descrito en la seccin 11.1.3.
Plan de la respuesta a riesgos. ste es descrito en la seccin 11.5.3.1.
Comunicaciones del proyecto. Los resultados del trabajo y otros registros del proyecto,
descritos en la seccin 10.3.1, proveen informacin acerca del rendimiento y los riesgos del
proyecto. Los reportes comnmente usados para supervisar y controlar los riesgos incluyen
registros de temas pendientes, listas de acciones, disparadores de riesgo o avisos de
escalamiento.
Identificacin y anlisis adicional de riesgos. A medida que el rendimiento del proyecto es
medido y reportado pueden aparecer riesgos potenciales previamente no identificados. Para
estos casos se debera implementar el ciclo de los seis procesos de gestin del riesgo.
Cambios al alcance. stos requieren a menudo nuevos anlisis de riesgos y planes de
respuesta. Los cambios al alcance son descritos en la seccin 5.5.3.1.
Tcnicas y Herramientas para la Supervisin y Control del Riesgo

Auditoras a las respuestas al riesgo del proyecto. Los auditores de riesgo examinan y documentan la eficacia de las respuestas de evitacin, transferencia y mitigacin de los riesgos como
as tambin la eficacia del responsable del riesgo correspondiente. Las auditoras de riesgo se
realizan para controlar el riesgo durante el ciclo de vida del proyecto.
Revisiones peridicas de los riesgos del proyecto. Estas revisiones deberan ser regularmente
programadas. Los riesgos del proyecto deberan estar en la agenda de todas las reuniones del
equipo. La calificacin y el establecimiento de prioridades pueden cambiar durante la vida del
proyecto. Cualquier cambio puede requerir un anlisis cualitativo y/o cuantitativo adicional.
Anlisis del valor del trabajo realizado. El valor del trabajo realizado es usado para supervisar
el rendimiento general del proyecto, comparndolo con el plan de referencia inicial. Los resultados del anlisis del valor del trabajo realizado pueden indicar desvos potenciales de los objetivos de costo y tiempo del proyecto a su terminacin. Cuando un proyecto se desva
significativamente de su plan de referencia inicial, debera realizarse una actualizacin de identificacin y anlisis de riesgos. El anlisis del valor del trabajo realizado es descrito en la seccin 10.3.2.4.
Medicin del rendimiento tcnico. La medicin del rendimiento tcnico compara los logros tcnicos durante la ejecucin del proyecto con lo programado en el plan de resultados tcnicos
a obtener en funcin del tiempo. Un desvo, tal como la no-demostracin de funcionalidad en
un hito planeado, puede implicar un riesgo en el cumplimiento del alcance del proyecto.
Planificacin adicional de respuesta al riesgo. Si emerge un riesgo que no fue anticipado en el
plan de respuesta o su impacto en los objetivos es mayor que lo esperado, la respuesta planificada podra no ser adecuada. En estos casos ser necesario realizar una planificacin de
respuesta adicional para controlar el riesgo.
145
11.6.3 | Captulo 12
11.6.3
.1
.2
.3
.4
.5
.6
146
Salidas de la Supervisin y Control del Riesgo

Planes de soluciones alternativas. stas son respuestas no planificadas a la ocurrencia de
riesgos que fueron previamente aceptados o no identificados. Estas soluciones alternativas
deben estar adecuadamente documentadas e incorporadas al plan del proyecto y al plan de
respuesta al riesgo.
Acciones correctivas. Las medidas correctivas consisten en llevar a cabo las acciones del plan
de contingencia o de las soluciones alternativas.
Solicitudes de pedido de cambio. La implementacin de planes de contingencia o soluciones
alternativas derivan frecuentemente en un requerimiento de cambio al plan del proyecto para
dar as respuesta al riesgo. El resultado es la emisin de un requerimiento de cambio que es
gestionado por el control de cambios integrado, tal como se describe en la seccin 4.3.
Actualizaciones al plan de respuesta al riesgo. Los riesgos pueden ocurrir o no. Aquellos que
ocurren deberan ser documentados y evaluados. La implementacin de controles de riesgos
puede reducir el impacto o la probabilidad de los riesgos identificados. La clasificacin de los
riesgos debe ser reevaluada de forma tal que los riesgos nuevos e importantes sean adecuadamente controlados. Los riesgos que no han ocurrido deberan ser documentados y
cerrados en el plan de respuesta al riesgo.
Base de datos de riesgos. Un lugar de almacenamiento que facilita la recoleccin, mantenimiento y anlisis de la informacin reunida y usada en los procesos de gestin del riesgo. El
uso de esta base de datos ayudar a la gestin de riesgos a travs de toda la organizacin y a
travs del tiempo servir como base del programa de lecciones aprendidas.
Actualizaciones a los listados de verificacin de riesgos. Estas actualizaciones, fundadas en la
experiencia, ayudarn a la gestin de riesgos de futuros proyectos.
Captulo 12
Gestin de las
Adquisiciones del Proyecto
La Gestin de las Adquisiciones del Proyecto incluye los procesos necesarios para adquirir
bienes y servicios a organizaciones externas, con el fin de alcanzar los objetivos del proyecto.
Para simplificar, bienes y servicios, sean uno o muchos, sern referidos generalmente como un
producto. La figura 12-1 proporciona una visin general de los siguientes procesos principales:
12.1 Planificacin de Adquisiciones determinacin de qu adquirir y cundo.
12.2 Planificacin de la Bsqueda de Proveedores documentacin de las especificaciones del producto e identificacin de los potenciales proveedores.
12.3 Bsqueda de Proveedores obtencin de cotizaciones, licitaciones, ofertas o
propuestas, segn corresponda.
12.4 Seleccin de Proveedores seleccin entre potenciales vendedores.
12.5 Administracin del Contrato gestin de la relacin con el proveedor.
12.6 Cierre del Contrato conclusin y liquidacin del contrato, incluyendo la resolucin
de todos los asuntos pendientes.
de individuos, segn las necesidades del proyecto. Aunque los procesos se presentan aqu
como elementos discretos con interfaces bien definidas, en la prctica pueden solaparse y
actuar entre s de maneras no detalladas aqu. Las interacciones entre procesos son tratadas en
detalle en el captulo 3.
La Gestin de las Adquisiciones del Proyecto es analizada desde la perspectiva del comprador considerando la relacin comprador-vendedor. La relacin comprador-vendedor puede
existir a varios niveles en un proyecto. Dependiendo del rea de aplicacin, el vendedor puede
ser llamado subcontratista, proveedor o vendedor.
El vendedor tpicamente organiza sus actividades como un proyecto. En dichos casos:
El comprador es su cliente y el principal interesado en el proyecto.
El equipo de gestin del proyecto del proveedor debe ocuparse de todos los procesos de
la gestin del proyecto, no solamente de los de esta rea de conocimiento.
Los trminos y condiciones del contrato se convierten en entradas clave de varios procesos
del vendedor. En la realidad, el contrato puede contener la entrada (por ejemplo, principales entregables, hitos clave, objetivos de costo) o puede establecer lmites para las
opciones del equipo del proyecto (por ejemplo, a menudo, en etapas de diseo de los
proyectos se requiere que el comprador apruebe las decisiones tomadas por el equipo).
147
Figura 121 | 12.1.1.2
Captulo 12 Gestin de las Adquisiciones del Proyecto
Figura 121. Visin General de la Gestin de las Adquisiciones del Proyecto
148
Este captulo supone que el vendedor es externo a la organizacin ejecutante. Gran parte
de los procesos, sin embargo, son perfectamente aplicables a acuerdos formales realizados
entre diferentes unidades de negocios de la organizacin ejecutante del proyecto. Cuando los
acuerdos son informales, es ms adecuado aplicar los procesos descritos en Gestin de los
Recursos Humanos del Proyecto, Captulo 9, y Gestin de las Comunicaciones del Proyecto,
Captulo 10.
12.1 PLANIFICACIN DE ADQUISICIONES

La Planificacin de Adquisiciones es el proceso de identificacin de aquellas necesidades del
proyecto que sern alcanzadas mejor con la adquisicin de productos y/o servicios fuera de la
organizacin y debera ser realizada durante la definicin del alcance. Este proceso considera
a quin, cmo, qu, cunto y cundo contratar.
Cuando el proyecto obtiene productos y servicios (alcance del proyecto) de una entidad
externa, los procesos, desde la Planificacin de la Bsqueda de Proveedores (seccin 12.2)
hasta el Cierre del Contrato (seccin 12.6), deberan ser ejecutados para cada producto o servicio.
El equipo de gestin del proyecto puede buscar recomendaciones de especialistas en
adquisiciones y contrataciones, cuando lo necesite, y puede involucrarlos tempranamente en
el proceso como miembros del equipo. Cuando el proyecto no adquiere productos o servicios
de organizaciones externas, los procesos desde la Planificacin de la Bsqueda de Proveedores
(seccin 12.2) hasta el Cierre del Contrato (seccin 12.6) no deberan ser ejecutados.
La Planificacin de Adquisiciones tambin debera incluir el anlisis de potenciales vendedores, especialmente si el comprador desea ejercer alguna influencia o control sobre las decisiones del contrato.
12.1.1
.1
.2
Entradas a la Planificacin de Adquisiciones

Enunciado del alcance. El enunciado del alcance (vase la seccin 5.2.3.1) describe los lmites
actuales del proyecto; proporciona informacin importante sobre las necesidades del proyecto
y estrategias que deben ser consideradas durante la planificacin de las adquisiciones.
Descripcin del producto. La descripcin del producto del proyecto (vase la seccin 5.1.1.1)
proporciona informacin importante sobre cualquier tema o aspecto tcnico que debera ser
considerada durante la planificacin de las adquisiciones.
149
12.1.1.3 | 12.1.3.2
.3
.4
.5
.6
.7
12.1.2
.1
.2
.3
150
La descripcin del producto es generalmente ms amplia que un enunciado del trabajo.

Una descripcin del producto describe el producto final del proyecto; un enunciado del trabajo (tratado en la seccin 12.1.3.2) describe la parte del producto que el vendedor debe
proveer al proyecto. Sin embargo si la organizacin ejecutante del proyecto decide adquirir
todo el producto, la diferencia entre los dos conceptos desaparece.
Recursos para la adquisicin. Si la organizacin ejecutante no tiene un grupo formal de contrataciones, entonces el equipo de proyecto deber contar con los recursos y el conocimiento
necesario para realizar las actividades de adquisicin.
Condiciones del mercado. El proceso de planificacin de adquisiciones debe considerar qu
productos y servicios estn disponibles en el mercado, quin los provee y bajo qu trminos
y condiciones.
Salidas de otros procesos de planificacin. En la medida en que otras salidas de planificacin
estn disponibles, deben ser consideradas durante la planificacin de las adquisiciones. Las
salidas de otros procesos de planificacin, que deben a menudo ser consideradas, incluyen
estimaciones preliminares de tiempo y costo, planes de gestin de la calidad, proyecciones del
flujo de ingresos y egresos, la estructura detallada del trabajo (WBS), riesgos identificados y
recursos humanos planificados.
Restricciones. Las restricciones son factores que limitan las opciones del comprador. Una de
las restricciones ms comunes en muchos proyectos es la disponibilidad de fondos.
Hiptesis. Las hiptesis son factores que, a los fines de la planificacin, sern considerados
verdaderos, reales o ciertos.
Tcnicas y Herramientas para la Planificacin de las Adquisiciones

Anlisis de hacer-o-comprar. sta es una tcnica de administracin general y una parte del
proceso inicial de definicin del alcance que puede ser usada para determinar si la organizacin ejecutante puede producir ms eficientemente un producto. El anlisis debera incluir
tanto costos directos como indirectos. Por ejemplo, el anlisis de la alternativa de comprar
debera incluir tanto el costo real de compra como todos aquellos costos indirectos de la
gestin del proceso de compra.
El anlisis de hacer-o-comprar debe considerar tanto las necesidades de largo plazo de la
organizacin ejecutante como las necesidades inmediatas del proyecto. Por ejemplo, comprar
un bien de capital (cualquier bien, desde una gra hasta una computadora personal) en vez
de alquilarlo o arrendarlo puede ser o no conveniente. Sin embargo, si la organizacin ejecutante requiere dicho bien para sus operaciones, la porcin del costo de compra asignada al
proyecto puede ser menor que el costo del alquiler.
Juicio de expertos. El juicio de expertos tcnicos es a menudo requerido para determinar las
entradas a estos procesos. Estos servicios pueden ser provistos por algn individuo o grupo
con conocimiento o entrenamiento especializado y estn disponibles de varias fuentes:
Otras reas de la organizacin ejecutora.
Consultores.
Asociaciones de profesionales y tcnicos.
Cmaras industriales.
Seleccin del tipo de contrato. De acuerdo con el tipo de compra, hay tipos de contratos ms
convenientes que otros. Los contratos pueden dividirse en tres grandes categoras:
Contratos a precio fijo o suma total esta categora de contrato determina un precio fijo
total para un producto claramente definido. En la medida en que el producto no est
definido en forma precisa, tanto el comprador como el vendedor estn tomando riesgos
importantes el comprador puede no recibir el producto que necesita o el vendedor
puede incurrir en gastos adicionales para entregar el producto. Los contratos a precio fijo
pueden incluir incentivos para alcanzar o exceder determinados objetivos del proyecto,
como fechas de entrega especialmente solicitadas.
Contratos con reembolso del costo esta categora de contratos implica el pago (reembolso) al vendedor de sus costos reales, ms honorarios que representan la ganancia del
vendedor. Los costos son generalmente clasificados en directos e indirectos. Los costos
directos son aquellos que estn exclusivamente vinculados al proyecto (por ejemplo,
salarios de los miembros del equipo con dedicacin completa). Los costos indirectos, tambin llamados costos generales, son costos asignados por el contratista a su proyecto, como
costos del negocio (por ejemplo, salarios de los ejecutivos de la organizacin). Los costos
indirectos son normalmente calculados como un porcentaje de los costos directos. Los contratos de reembolso del costo a menudo incluyen incentivos para alcanzar o exceder determinados objetivos del proyecto como fechas de entrega especialmente solicitadas o un
costo total.
Contratos de Tiempo y Material (T&M) Los contratos T&M son un tipo hbrido de
acuerdo contractual que contiene aspectos de las dos categoras descritas previamente. Los
contratos T&M se parecen a los de reembolso del costo en que son abiertos, porque el
precio total del acuerdo no est definido en el momento de la adjudicacin. Por lo tanto,
el valor de los contratos T&M puede crecer como si fuera un acuerdo de reembolso del
costo. Pero por otro lado, los contratos T&M pueden tambin parecerse a los de precio fijo
cuando el comprador y el vendedor establecen valores unitarios; por ejemplo, cuando
ambas partes acuerdan previamente un valor hora para la categora de ingenieros senior.
12.1.3
.1
.2
Salidas de la Planificacin de Adquisiciones

Plan de la gestin de las adquisiciones. El plan de la gestin de las adquisiciones debera
describir el resto de los procesos de la gestin de las adquisiciones (desde la planificacin de
la bsqueda de proveedores hasta el cierre del contrato). Por ejemplo:
Qu tipos de contrato debern ser usados?
Si se utilizarn estimaciones independientes como criterios de evaluacin, quin las reunir
y cundo?
Si la organizacin ejecutora tiene un departamento de compras, qu decisiones puede
tomar el equipo del proyecto por s mismo?
Si se requieren modelos de documentos para los procesos de adquisiciones, dnde
pueden ser encontrados?
Cmo se gestionarn proveedores mltiples?
Cmo se coordinarn las adquisiciones con otros aspectos del proyecto, tales como cronogramas e informes del rendimiento?
Un plan de la gestin de las adquisiciones puede ser formal o informal, altamente detallado
o simplemente bosquejado, segn las necesidades del proyecto. Es un componente del plan
del proyecto descrito en la seccin 4.1, Desarrollo del Plan del Proyecto.
Enunciado(s) del trabajo. El enunciado del trabajo (SOW) describe el artculo a adquirir con
suficiente detalle para permitir a los potenciales vendedores determinar si pueden proveerlo.
El alcance del trmino suficiente detalle puede variar, dependiendo del tipo de producto, de
las necesidades del comprador o de la forma de contratacin esperada.
151
12.2 | 12.3
Algunas reas de aplicacin reconocen diferentes tipos de descripcin del trabajo. Por
ejemplo en algunas jurisdicciones gubernamentales, el concepto SOW est reservado para un
artculo a adquirir que es un producto o servicio especfico y el concepto Enunciado de Objetivos (SOO) es usado cuando el artculo a adquirir se presenta como un problema que debe
ser resuelto.
El enunciado del trabajo puede ser revisado y optimizado a medida que se avanza en el
proceso de adquisicin. Por ejemplo, un potencial vendedor puede sugerir un enfoque ms
eficiente o ms econmico que el originalmente solicitado. Cada artculo a adquirir requiere
una descripcin separada del trabajo. Sin embargo varios productos o servicios podran agruparse en un nico artculo a adquirir con una sola descripcin del trabajo.
El enunciado del trabajo debe ser tan claro, completo y conciso como sea posible. Debe
incluir la descripcin de cualquier servicio complementario requerido, como informes del
rendimiento o el soporte operativo para el artculo adquirido despus de finalizado el proyecto.
En algunas reas de aplicacin, existen requerimientos especficos acerca del contenido y formato para un SOW.
12.2 PLANIFICACIN DE LA BSQUEDA DE PROVEEDORES

La planificacin de la bsqueda de proveedores comprende la preparacin de los documentos
necesarios para realizar la bsqueda de proveedores (el proceso de bsqueda de proveedores
est descrito en la seccin 12.3).
12.2.1
.1
.2
.3
12.2.2
.1
.2
152
Entradas a la Planificacin de la Bsqueda de Proveedores

Plan de la gestin de las adquisiciones. El plan de la gestin de las adquisiciones est descrito
Enunciado(s) del trabajo. El enunciado del trabajo est descrito en la seccin 12.1.3.2.
Otras salidas de los procesos de planificacin. Otras salidas de los procesos de planificacin
(vase la seccin 12.1.1.5), que podran haber sido modificadas desde que fueron consideradas
para planificar las adquisiciones, deberan ser revisadas nuevamente como parte de este proceso. En particular, la planificacin de la bsqueda de proveedores debera estar totalmente
alineada con el cronograma del proyecto.
Tcnicas y Herramientas para la Planificacin de la Bsqueda de Proveedores

Formularios estndar. Los formularios estndar pueden incluir contratos estndar, descripciones estndar de productos a adquirir o versiones estndar de todo o parte de los documentos necesarios para solicitar ofertas (vase la seccin 12.2.3.1). Las organizaciones que
realizan muchas adquisiciones deberan tener varios de estos documentos estandarizados.
Juicio de expertos. El juicio de expertos est descrito en la seccin 12.1.2.2.
12.2.3
.1
.2
.3
Salidas de la Planificacin de la Bsqueda de Proveedores

Documentos de la adquisicin. Los documentos de adquisicin se usan para solicitar propuestas a los potenciales vendedores. Los trminos oferta y cotizacin generalmente se usan
cuando la eleccin estar basada en el precio (adquisicin de productos estndar o comerciales), mientras el trmino propuesta se usa generalmente cuando otras consideraciones son
las importantes, tales como habilidades o enfoques tcnicos. Sin embargo, los trminos a
menudo son usados en forma intercambiable, y se debera tener cuidado en no hacer suposiciones injustificadas sobre la base del trmino utilizado. Los nombres ms frecuentes de los
diferentes tipos de documentos para la adquisicin son: Invitacin a Licitar (Invitation for Bid,
IFB), Solicitud de Propuestas (Request for Proposal, RFP), Solicitud de Cotizacin (Request for
Quotation, RFQ), Invitacin a Negociar y Respuesta Inicial al Contratista.
Los documentos de adquisiciones deben estar estructurados para facilitar respuestas precisas y completas de los potenciales vendedores. Estos documentos deberan contener siempre
la descripcin del producto ms importante (SOW), una descripcin del formato de respuesta
deseado, y cualquier especificacin contractual requerida (por ejemplo, una copia del modelo
de contrato, requerimientos no declarados). Cuando el contratista es el gobierno, parte o todo
el contenido y la estructura de los documentos puede estar definida por regulaciones.
Los documentos de adquisiciones deberan ser suficientemente rigurosos para asegurar
respuestas consistentes y comparables, pero con suficiente flexibilidad para permitir a los
vendedores sugerir mejores alternativas para satisfacer los requerimientos.
Criterios de evaluacin. Los criterios de evaluacin son usados para calificar o ponderar las
propuestas. stos pueden ser objetivos (por ejemplo, El gerente de proyecto propuesto debe
ser un Project Management Professional, PMP) o subjetivos (por ejemplo, El gerente de
proyecto propuesto debe poseer experiencia previa documentada en proyectos similares). Los
criterios de evaluacin a menudo son parte de los documentos de adquisicin.
Los criterios de evaluacin pueden limitarse a un precio de compra si el artculo a adquirir
es fcilmente obtenible de varios proveedores (precio de compra en este contexto incluye el
costo del artculo y los gastos asociados, como el flete). Cuando no es as, deben identificarse
y documentarse otros criterios de seleccin para sustentar la determinacin. Por ejemplo:
Entendimiento de la necesidad como ha sido demostrado en la propuesta del vendedor.
Costo total o del ciclo de vida generar el proveedor seleccionado el menor costo total
(precio de compra ms costo de operacin)?
Capacidad tcnica tiene el vendedor las habilidades y conocimientos necesarios, o
puede esperarse razonablemente que las adquiera?
Enfoque de administracin tiene el vendedor los procesos y procedimientos para asegurar el xito del proyecto, o puede esperarse razonablemente que los desarrolle y administre?
Capacidad financiera tiene el vendedor los recursos financieros necesarios, o puede
esperarse razonablemente que los obtenga?
Actualizaciones del enunciado del trabajo. El enunciado del trabajo es descrito en la seccin
12.1.3.2. Cambios en una o varias descripciones del trabajo pueden ser identificados durante
la planificacin de la bsqueda de proveedores.
12.3 BSQUEDA DE PROVEEDORES

La Bsqueda de Proveedores comprende obtener respuestas de los potenciales proveedores
(ofertas y propuestas) sobre cmo pueden satisfacer las necesidades del proyecto. Gran parte
del trabajo de este proceso es realizado por los potenciales vendedores, normalmente sin costo
para el proyecto.
153
12.3.1 | 12.4.2.1
12.3.1
.1
.2
12.3.2
.1
.2
12.3.3
.1
154
Entradas a la Bsqueda de Proveedores

Documentos de adquisicin. Los documentos de adquisicin estn descritos en la seccin
12.2.3.1.
Listas de vendedores calificados. Algunas organizaciones mantienen listas o archivos con
informacin sobre potenciales vendedores. Estas listas generalmente tienen informacin sobre
experiencia relevante pasada y otras caractersticas de los potenciales vendedores.
Si dichas listas no estn disponibles, el equipo del proyecto deber obtener por s mismo
la informacin. Existe informacin ampliamente disponible en Internet, guas de bibliotecas,
asociaciones locales importantes, catlogos comerciales y otras fuentes similares. Una informacin ms detallada en aspectos muy especficos puede requerir esfuerzos adicionales, tales
como visitar o contactar a clientes de los potenciales proveedores.
Los documentos de adquisicin pueden ser enviados a algunos o a todos los potenciales
vendedores.
Tcnicas y Herramientas para la Bsqueda de Proveedores

Conferencias de oferentes. Las conferencias de oferentes (tambin llamadas conferencias de
contratistas, conferencias de proveedores y conferencias pre-propuesta) son reuniones con los
potenciales vendedores previas a la preparacin de la propuesta. Estas reuniones son utilizadas
para asegurar que todos los oferentes tienen un entendimiento claro y comn de la adquisicin (requerimientos tcnicos, requerimientos contractuales, etc.). Las respuestas a las inquietudes planteadas pueden ser incorporadas a los documentos de adquisicin como
modificaciones. Durante este proceso, todos los potenciales vendedores deben permanecer en
un plano de igualdad.
Publicidad. Las listas existentes de potenciales vendedores pueden a menudo ampliarse colocando anuncios en publicaciones de circulacin general, tales como peridicos o en publicaciones especializadas, tales como revistas de profesionales. Algunos sectores del gobierno
requieren realizar un llamado pblico de cierto tipo de artculos a adquirir; la mayora de los
sectores gubernamentales requieren el anuncio pblico de los subcontratos de un contrato
gubernamental.
Salidas de la Bsqueda de Proveedores

Propuestas. Las propuestas (vanse tambin los comentarios sobre ofertas, cotizaciones y
propuestas en la seccin 12.2.3.1) son documentos preparados por los vendedores que
describen la habilidad del vendedor y su voluntad de proveer el producto requerido. stas son
preparadas de acuerdo con los requerimientos de los principales documentos de adquisicin.
Las propuestas pueden ser complementadas con una presentacin oral.
12.4 SELECCIN DE PROVEEDORES

La seleccin de proveedores implica la recepcin de las ofertas o propuestas y la aplicacin de los criterios de evaluacin para elegir un proveedor. Muchos factores, adems
del costo o precio, pueden requerir evaluacin en el proceso de decisin de la seleccin de proveedores.
El precio puede ser el determinante primario para un producto "disponible", pero
el menor precio propuesto puede no ser el menor costo si el vendedor no tiene
capacidad para entregarlo a tiempo.
Las propuestas a menudo son divididas en secciones tcnicas (enfoque) y comerciales (precios) y evaluadas separadamente.
Pueden requerirse mltiples proveedores para productos crticos.
Las herramientas y tcnicas descritas aqu pueden ser usadas separadamente o en
conjunto. Por ejemplo, un sistema de ponderacin puede ser utilizado para:
Seleccionar un proveedor nico, al que le ser solicitada la firma de un contrato
estndar.
Ordenar jerrquicamente todas las propuestas para establecer un orden para las
negociaciones.
En grandes adquisiciones, este proceso puede repetirse. Basndose en propuestas
preliminares, podra seleccionarse una lista corta de vendedores calificados y luego
realizar una evaluacin ms profunda sobre la base de una propuesta ms detallada y
completa.
12.4.1
.1
.2
.3
12.4.2
.1
Entradas a la Seleccin de Proveedores

Propuestas. Las propuestas son descritas en la seccin 12.3.3.1.
Criterios de evaluacin. Los criterios de evaluacin pueden incluir muestras de los productos/servicios previamente producidos por los proveedores con el propsito de
brindar una forma de evaluar sus capacidades y la calidad de los productos. Tambin
pueden incluir una revisin de los antecedentes del proveedor con la organizacin contratante. Los criterios de evaluacin estn descritos en la seccin 12.2.3.2.
Polticas de la organizacin. Las organizaciones involucradas en adquisiciones para
proyectos tienen tpicamente polticas formales que afectan la evaluacin de las propuestas.
Tcnicas y Herramientas para la Seleccin de Proveedores

Negociacin del contrato. La negociacin del contrato incluye una aclaracin y un
acuerdo mutuo de la estructura y requerimientos del contrato previamente a su firma.
La redaccin del contrato final debera reflejar, en la medida de posible, los acuerdos
logrados. Los aspectos incluidos generalmente, aunque puede haber ms, son responsabilidades y autoridades, leyes y trminos aplicables, enfoques de administracin tcnicos y de negocio, financiacin del contrato y precio.
155
12.4.2.2 | 12.5.1.4
.2
.3
.4
12.4.3
.1
Para adquisiciones complejas, la negociacin del contrato puede ser un proceso independiente con entradas (por ejemplo, una lista abierta de artculos o temas) y salidas (por ejemplo,
un memorando de entendimiento) propias.
Sistema de ponderacin. Un sistema de ponderacin es un mtodo para cuantificar datos
cualitativos con el objeto de minimizar la subjetividad en la seleccin del proveedor. Muchos
de estos sistemas comprenden 1) asignarle un valor numrico a cada criterio de evaluacin, 2)
calificar a los potenciales vendedores en cada criterio, 3) multiplicar el valor numrico de cada
criterio por la calificacin y 4) obtener la calificacin final como el total de todos los productos.
Sistema de seleccin. Un sistema de filtrado establece requerimientos mnimos de cumplimiento de uno o ms de los criterios de evaluacin. Por ejemplo, a los potenciales vendedores
se les podra requerir que propongan un gerente de proyecto con calificaciones especficas
por ejemplo, PMP antes de que sea considerada el resto de la propuesta.
Estimaciones independientes. Para varias adquisiciones, la organizacin compradora puede
preparar sus propias estimaciones independientes como una validacin de los precios propuestos. Diferencias significativas con estas estimaciones podran indicar que la SOW no fue
adecuada, que el potencial vendedor no ha comprendido la solicitud o que fall en responder
a la SOW en su totalidad. Las estimaciones independientes son a menudo denominadas estimaciones de lo que debera costar.
Salidas de la Seleccin de Proveedores

Contrato. Un contrato es un acuerdo mutuo que obliga al vendedor a proveer un producto
especfico y obliga al comprador a pagar por l. Un contrato es un vnculo legal sujeto a resolucin en las cortes. El acuerdo puede ser simple o complejo, generalmente (pero no siempre)
reflejando la simplicidad o complejidad del producto. Los contratos pueden ser llamados, entre
otros nombres, un contrato, un acuerdo, un subcontrato, una orden de compra o un memorando de entendimiento. La mayora de las organizaciones tienen polticas y procedimientos
documentados que definen especficamente quin firmar dichos acuerdos en nombre de la
organizacin, tpicamente llamados delegacin de autoridad para contratar.
A pesar de que todos los documentos del proyecto estn sujetos a algn tipo de revisin y
aprobacin, la naturaleza de las obligaciones legales de un contrato generalmente significa que
estar sujeto a un proceso de aprobacin ms amplio. En todos los casos, un objetivo principal
del proceso de revisin y aprobacin debe ser asegurar que la redaccin del contrato describa
el producto o servicio que satisfar la necesidad identificada. En el caso de grandes proyectos
emprendidos por agencias pblicas, el proceso de revisin puede hasta incluir una revisin
pblica del acuerdo.
12.5 ADMINISTRACIN DEL CONTRATO

La administracin del contrato es el proceso de asegurar que el vendedor cumple con los
requerimientos del contrato. En grandes proyectos con varios proveedores de productos y servicios, un aspecto clave de la administracin del contrato es manejar las interrelaciones entre
todos los proveedores. La naturaleza legal de la relacin contractual hace imperativo que el
equipo del proyecto entienda la importancia de las implicancias legales de las decisiones
tomadas al administrar un contrato.
156
La administracin de un contrato incluye la aplicacin de procesos apropiados de direccin

de proyectos a la(s) relacin(es) contractual(es) y a la integracin de las salidas de estos procesos con la direccin total del proyecto. Esta integracin y coordinacin ocurrir a menudo a
mltiples niveles cuando hay mltiples proveedores y productos involucrados. Los procesos
de la direccin del proyecto que deben ser aplicados son:
Ejecucin del plan del proyecto, descrito en la seccin 4.2, para autorizar el trabajo del contratista en el momento adecuado.
Informe del rendimiento, descrito en la seccin 10.3, para controlar los costos, el cronograma y el rendimiento tcnico del contratista.
Control de calidad, descrito en la seccin 8.3, para inspeccionar y verificar la conformidad
del producto del contratista.
Control de cambios, descrito en la seccin 4.3, para asegurar que los cambios son apropiadamente aprobados y que todas las personas que necesitan conocerlos estn enterados de
esos cambios.
La administracin de un contrato tiene tambin un componente de gestin financiera. Las
condiciones de pago deben estar definidas en el contrato y debe existir una vinculacin especfica entre el avance realizado por el vendedor y los pagos como compensacin al mismo.
12.5.1
.1
.2
.3
.4
Entradas a la Administracin del Contrato

Contrato. Los contratos estn descritos en la seccin 12.4.3.1.
Resultados del trabajo. Los resultados del trabajo del vendedor qu entregables han sido
completados y cules no, en qu medida han sido cumplidos los estndares de calidad, qu
gastos se han realizado o comprometido, etc. son recopilados como parte de la ejecucin
del plan del proyecto (la seccin 4.2 brinda ms detalles sobre la ejecucin del plan del
proyecto).
Pedidos de cambio. Los pedidos de cambio pueden incluir modificaciones a los trminos del
contrato o a la descripcin del producto o servicio que debe ser provisto. Si el trabajo del
vendedor no es satisfactorio, la decisin de finalizar el contrato podra ser tambin administrada como un pedido de cambio. Los cambios rechazados, aquellos donde el vendedor y el
equipo del proyecto no llegaron a un acuerdo por la compensacin correspondiente, reciben
variados nombres como reclamos, controversias o apelaciones.
Facturas del vendedor. El vendedor debe presentar facturas con cierta periodicidad para solicitar el pago del trabajo realizado. Los requerimientos de facturacin, incluyendo la necesaria
documentacin de respaldo, estn definidos en el contrato.
157
12.5.2 | 12.6.3.2
12.5.2
.1
.2
.3
12.5.3
.1
.2
.3
Tcnicas y Herramientas para la Administracin del Contrato

Sistema de control de cambios del contrato. Un sistema de control de cambios del contrato
define el procedimiento mediante el cual el contrato puede ser modificado. ste incluye trabajo administrativo, sistemas de seguimiento, procedimientos de resolucin de diferencias y
niveles de aprobacin necesarios para autorizar los cambios. El sistema de control de cambios
del contrato debe formar parte del sistema de control de cambios integrado (la seccin 4.3
describe el sistema de control de cambios integrado).
Informes del rendimiento. Los informes del rendimiento proveen a la gerencia informacin
sobre cun efectivamente el vendedor est logrando los objetivos del contrato. Los informes
del rendimiento del contrato deben formar parte del informe del rendimiento integrado del
proyecto, descrito en la seccin 10.3.
Sistema de pago. Los pagos al vendedor son normalmente manejados por un sistema de
cuentas a pagar de la organizacin ejecutante. En grandes proyectos con muchos o complejos
requerimientos de adquisicin, el proyecto puede desarrollar su propio sistema. En cualquier
caso, el sistema de pago debe incluir revisiones y aprobaciones apropiadas por parte del
equipo de gestin del proyecto.
Salidas de la Administracin del Contrato

Correspondencia. Los trminos y condiciones del contrato a menudo requieren documentacin escrita de ciertos aspectos de las comunicaciones entre comprador y vendedor, tales
como avisos de rendimiento no satisfactorio, cambios al contrato o aclaraciones.
Cambios del contrato. Los cambios (aprobados y no aprobados) son realimentados a los procesos apropiados de planificacin y de adquisicin del proyecto, para actualizar adecuadamente el plan del proyecto u otra documentacin importante.
Solicitudes de pago. Esto supone que el proyecto est usando un sistema de pagos externo.
Si el proyecto tiene su propio sistema de pagos interno, la salida aqu sera simplemente
"pagos".
12.6 CIERRE DEL CONTRATO

El cierre del contrato es similar al cierre administrativo (descrito en la seccin 10.4), el cual
implica la verificacin del producto (todo el trabajo fue completado correcta y satisfactoriamente?) y el cierre administrativo (actualizacin de registros para mostrar los resultados finales
y archivo de esta informacin para usos futuros). Los trminos y condiciones del contrato
pueden establecer procedimientos especficos para el cierre del contrato. Una finalizacin
anticipada puede ser un caso especial de cierre del contrato.
158
12.6.1
.1
12.6.2
.1
12.6.3
.1
.2
Entradas al Cierre del Contrato

Documentacin del contrato. La documentacin del contrato incluye, entre otros documentos, el contrato propiamente dicho junto con los cronogramas de respaldo, cambios
al contrato solicitados y aprobados, toda documentacin tcnica generada por el
proveedor, informes del rendimiento del vendedor, documentos financieros tales como
facturas y registros de los pagos y los resultados de cualquier inspeccin relacionada
con el contrato.
Tcnicas y Herramientas para el Cierre del Contrato

Auditoras de las adquisiciones. Una auditora de adquisiciones es una revisin estructurada del proceso de adquisicin desde la planificacin de la adquisicin hasta la
administracin del contrato. El objetivo de una auditora de adquisiciones es identificar
xitos y fracasos, que sean tiles para la adquisicin de otros artculos en el mismo o
en otros proyectos dentro la organizacin ejecutante.
Salidas del Cierre del Contrato

Archivo del contrato. Debe prepararse un conjunto completo de registros indexados
para su inclusin final en los registros del proyecto (vase la seccin 10.4 para una
exposicin ms detallada del cierre administrativo y los archivos del proyecto).
Aceptacin formal y cierre. La persona o la organizacin responsable de la administracin del contrato debe entregarle al vendedor un documento formal escrito indicando que el contrato ha sido completado. Los requerimientos para la aceptacin
formal y el cierre generalmente estn definidos en el contrato.
159
SECCIN III
APNDICES
A. Proceso de Establecimiento de Estndares del Project

Management Institute
B. Evolucin de la Gua a los Fundamentos de la Direccin de
Proyectos
C. Colaboradores y Revisores de la Edicin 2000 de la Gua
PMBOK
D. Notas
E. Extensiones al rea de Aplicacin
F.
Fuentes Adicionales de Informacin sobre la Direccin de

Proyectos
G. Resumen de las reas de Conocimiento de la Direccin de

Proyectos
Apndice A
Proceso de Establecimiento
de Estndares del
El proceso de fijacin de estndares del Project Management Institute (PMI) ha sido establecido inicialmente, como poltica del Instituto a travs del voto del Consejo Directivo del PMI,
en su reunin de Octubre de 1993. En Marzo de 1998, el Consejo Directivo del PMI aprob
modificaciones al proceso. Luego, en Marzo de 1999, fue modificado nuevamente, para que
sea consistente con los cambios que paralelamente se producan en los procedimientos
administrativos en el gobierno del PMI.
A.1 DOCUMENTOS DE ESTNDARES DEL PMI

Los Documentos de Estndares del PMI son aquellos desarrollados o publicados por el PMI,
que describen prcticas de direccin de proyecto generalmente aceptadas, especficamente:
Una Gua a los Fundamentos de la Direccin de Proyecto (Gua de PMBOK)
Manuales del Cuerpo de Conocimiento de la Direccin de Proyecto.
El Gerente de Estndares del PMI puede agregar documentos adicionales a esta lista, pero
sujeto al consejo y aprobacin del Grupo de Miembros Asesores al Programa de Estndares de
Direccin de Proyectos del PMI y del Director Ejecutivo del PMI. Los Documentos de Estndares pueden ser trabajos originales publicados por el PMI, o bien pueden ser publicaciones
de otras organizaciones o individuos.
Los Documentos de Estndares sern desarrollados de acuerdo con el Cdigo de Buenas
Prcticas de Normalizacin desarrollado por la Organizacin Internacional de Normas (ISO)
y las Guas de Desarrollo de Normas establecidas por el Instituto Nacional Americano de
Normas (ANSI).
A.2 DESARROLLO DE TRABAJOS ORIGINALES

Los Documentos de Estndares que son trabajos originales desarrollados por el PMI, o que son
revisiones de tales documentos, sern tratados como sigue:
El(los) Potencial(es) Desarrollador(es) de un trabajo someter(n) su propuesta al Gerente
de Estndares del PMI. El Gerente tambin puede solicitar tales propuestas. El Gerente elevar todas las propuestas recibidas al Grupo de Miembros Asesores al Programa de Estndares del PMI, que en conjunto con el Gerente, decidirn sobre la aceptacin o rechazo de
cada propuesta.
163
Apndice A
Apndice A Proceso de Establecimiento de Estndares del Project Management Institute
164
El Gerente informar al(a los) Potencial(es) Desarrollador(es) la decisin adoptada y los

fundamentos de la misma. Si una propuesta aprobada requiere mayores fondos que los que
han sido presupuestados para el desarrollo de estndares, el Gerente someter la propuesta
al Director Ejecutivo del PMI para su aprobacin de los fondos de la misma.
En todas aquellas propuestas que han sido aprobadas y cuentan con los fondos necesarios,
el Gerente apoyar los esfuerzos del desarrollador de modo que maximice las probabilidades de que el producto final sea aceptado. Al(a los) Desarrollador(es) le ser requerido
firmar la Asignacin Voluntaria de Derechos de Autor del PMI.
Cuando el material propuesto ha sido completado a satisfaccin del(de los) desarrollador(es), ste(stos) someter(n) el material al Gerente de Estndares del PMI. El Grupo
de Miembros Asesores al Programa de Estndares del PMI, junto con el Gerente, revisarn
el trabajo y decidirn si pedirn revisiones adicionales por expertos en el tema o bien le
solicitarn un trabajo adicional al(a los) desarrollador(es).
El Gerente designar, sujeto a revisin y aprobacin del Grupo de Miembros Asesores al
Programa de Estndares del PMI, al menos tres personas expertas en el tema, para revisar
y comentar el material. En base a los comentarios recibidos, el Grupo de Miembros
Asesores decidir si acepta el material como Borrador Primario.
El Gerente de Estndares del PMI desarrollar un plan para obtener adecuadas revisiones
pblicas de cada Borrador Primario. Este plan incluir: a) un perodo de revisin de no
menos de un mes y de no ms de seis meses, b) el anuncio de la disponibilidad para
revisin del Borrador Primario en la publicacin PM Network (y/o en otros medios de
publicacin similares adecuados) y c) el costo de las copias de revisin. El Grupo de Miembros Asesores al Programa de Estndares del PMI debe aprobar este plan del Gerente para
las revisiones pblicas. Cada Borrador Primario incluir una nota solicitando que los
comentarios sean enviados al Gerente de Estndares del PMI, en la Casa Matriz del PMI y
haciendo notar el lapso de tiempo previsto y la fecha de cierre del perodo de revisin.
Los Borradores Primarios sern publicados bajo la gida de la Divisin Publicaciones del
PMI y deben cumplir con las directrices de ese grupo en relacin con la tipografa y el
estilo.
Durante el perodo de revisin, el Gerente solicitar la opinin formal de los Gerentes de
otros Programas del PMI (cmo por ejemplo, Certificacin, Educacin, Componentes y
Publicidad) que pueden ser afectados por la futura publicacin del material como un
Estndar del PMI.
Al concluir el perodo de revisin, el Gerente de Estndares del PMI revisar los comentarios recibidos en conjunto con el Grupo de Miembros Asesores al programa de Estndares
del PMI y trabajar conjuntamente con el(los) desarrollador(es) y otras personas, segn sea
necesario, para incorporar los comentarios apropiados. Si los comentarios son importantes,
el Grupo de Miembros Asesores al Programa de Estndares del PMI puede optar por repetir
el proceso de revisin del Borrador Primario.
Cuando el Gerente de Estndares del PMI y el Grupo de Miembros Asesores al Programa
de Estndares del PMI hayan aprobado un Documento Estndar propuesto, el Gerente
someter inmediatamente dicho documento al Director Ejecutivo del PMI para su revisin
final y aprobacin. El Director Ejecutivo del PMI verificar el cumplimiento de los procedimientos y asegurar que la opinin de los miembros ha sido suficientemente tenida en
cuenta. El Director Ejecutivo del PMI a) aprobar el documento como fue presentado, b)
rechazar el documento o c) pedir una revisin adicional, brindando todas las explicaciones necesarias para fundamentar su decisin.
Apndice A Proceso de Establecimiento de Estndares del Project Management Institute
A.3 ADOPCIN DE TRABAJOS NO ORIGINALES COMO ESTNDARES

Los Documentos de Estndares que son trabajos de otras organizaciones o individuos sern
tratados como sigue:
Cualquier persona u organizacin puede presentar al Gerente de Estndares del PMI una
solicitud para que considere como Estndar del PMI una publicacin que no es del PMI. El
Gerente elevar todas las propuestas recibidas al Grupo de Miembros Asesores al Programa
de Estndares del PMI, el cual junto con el Gerente, decidir si se acepta o rechaza cada
propuesta. Si se acepta, el Gerente designar, sujeto a revisin y aprobacin del Grupo de
Miembros Asesores al Programa de Estndares del PMI, al menos tres personas expertas en
el tema, para revisar y comentar sobre el material.
Durante el perodo de revisin, el Gerente solicitar la opinin formal de los Gerentes de
otros Programas del PMI (cmo por ejemplo Certificacin, Educacin, Componentes y
Publicidad) que pueden ser afectados por la futura publicacin del material como un
Estndar del PMI.
En base a los comentarios recibidos, el Grupo de Miembros Asesores en conjunto con el
Gerente, decidirn si a) aceptar la propuesta, segn fue escrita, como un Estndar del PMI,
b) aceptar la propuesta con modificaciones y/o con agregados como un Estndar del PMI,
c) pedir revisin y comentarios adicionales a la propuesta (esto es, revisores adicionales
y/o su emisin como un Borrador Primario), o d) rechazar la propuesta. El Gerente informar al solicitante sobre la decisin y sobre los fundamentos de la misma.
Cuando el Gerente de Estndares del PMI y el Grupo de Miembros Asesores al programa
de Estndares del PMI hayan aprobado un Documento de Estndares del PMI propuesto,
el Gerente someter inmediatamente dicho documento al Director Ejecutivo del PMI para
su revisin final y aprobacin. El Gerente preparar una propuesta, que someter a consideracin del Director Ejecutivo del PMI, en la que se analizar una eventual relacin con
el(los) propietario(s) del material.
El Director Ejecutivo del PMI verificar el cumplimiento de los procedimientos y asegurar
que la opinin de los miembros ha sido suficientemente tenida en cuenta. El Director
Ejecutivo del PMI a) aprobar el documento como fue presentado, b) rechazar el documento, o c) pedir una revisin adicional, brindando todas las explicaciones necesarias
para fundamentar la decisin de la opcin elegida.
165
Apndice B
Evolucin de la Gua a los

Fundamentos de la Direccin
de Proyectos
B.1 DESARROLLO INICIAL

El Instituto de Direccin de Proyectos (PMI) se fund en 1969 bajo la premisa que haba
muchas prcticas de gestin que eran comunes a proyectos en reas de aplicacin tan diversas
como la construccin o la farmacutica. Para la poca de los Simposios/Seminarios del PMI en
Montreal, en 1976, se comenz a discutir ampliamente la idea de que tales prcticas comunes
podan documentarse como estndares. Esto llev, a su vez, a considerar a la direccin de
proyectos como una profesin diferente.
Sin embargo, no fue sino hasta 1981, que el Comit de Directores del PMI aprob un
proyecto para desarrollar los procedimientos y conceptos necesarios para respaldar la profesin de la direccin de proyectos. La propuesta del proyecto sugera tres reas de enfoque:
Las caractersticas distintivas de la prctica profesional (tica)
El contenido y estructura de los fundamentos de la profesin (estndares)
Reconocimiento de logros profesionales (acreditacin)
El equipo de proyecto lleg as a ser conocido como el Grupo de Gestin de la tica,
Estndares y Acreditacin (ESA). El Grupo de Gestin ESA constaba de los siguientes miembros:
Matthew H. Parry, Director
David C. Aird
Frederick R. Fisher
David Haeney
Harvey Kolodney
Charles E. Oliver
William H. Robinson
Douglas J. Ronson
Paul Sims
Eric W. Smythe
Este grupo estuvo asistido por ms de veinticinco voluntarios en varios captulos locales.
La propuesta de tica fue desarrollada y sometida a consideracin por un comit en Washington, D.C., presidido por Lew Ireland. La propuesta sobre Gestin de Tiempos de los Proyectos
se desarroll despus de extensas reuniones de un grupo en Ontario Sur, que incluyeron a
Dave MacDonald, Dave Norman, Bob Spence, Bob Hall, y Matt Parry. La propuesta de Gestin
de Costos se desarroll despus de extensas reuniones dentro del departamento de costos de
Stelco, bajo la direccin de Dave Haeney y Larry Harrison. Otras propuestas fueron desarrolladas por el Grupo de Gestin ESA. La acreditacin fue llevada a cabo por John Adams y su
grupo de Western Carolina University, y llev al desarrollo de las lneas directivas y el
167
Apndice B
Apndice B Evolucin de la Gua a los Fundamentos de la Direccin de Proyectos
programa para la certificacin de Profesionales en Direccin de Proyectos (PMPs) bajo la gua

de Dean Martin.
Los resultados del Proyecto ESA se publicaron en un Informe Especial en el Project
Management Journal de Agosto de 1983. El informe inclua:
Un Cdigo de tica, adems de un procedimiento para el cumplimiento de ese cdigo.
Estndares de referencia para las seis reas principales de conocimiento: Gestin del
Alcance del Proyecto, Gestin de Costos, Gestin de Tiempos, Gestin de la Calidad,
Gestin de los Recursos Humanos, y Gestin de las Comunicaciones.
Directivas para la acreditacin (reconocimiento de la calidad de los programas proporcionados por las entidades educativas) y certificacin (reconocimiento de las calificaciones
profesionales de los individuos).
Este informe se utiliz, posteriormente, como base para los programas iniciales de Acreditacin y Certificacin del PMI. El grado de Maestra en Direccin de Proyectos de Western
Carolina University se acredit en 1983, y los primeros PMPs se certificaron en 1984.
B.2 ACTUALIZACIN 1986-87

La publicacin del Informe del Plan de Referencia del ESA dio origen a muchos debates dentro
del PMI respecto a la adecuacin de los estndares. En 1984, el Comit de Directores del PMI
aprob un segundo proyecto relacionado con los estndares para introducir el conocimiento
utilizado en la direccin de proyectos dentro del encuadre existente del ESA. Entonces se
crearon seis comits para hacerse cargo de cada una de las seis reas de conocimiento identificadas. Adicionalmente, se program un taller como parte de los Seminarios/Simposios
anuales del PMI en 1985.
Como resultado de estos esfuerzos, el Comit de Directores del PMI aprob en principio
un documento revisado, que se public en el Project Management Journal en Agosto de 1986.
Los colaboradores principales para esta versin del documento fueron:
R. Max Wideman, Director
John R. Adams, Director
(durante el desarrollo)
(cuando se public)
Joseph R. Beck
Peter Bibbes
Jim Blethen
Richard Cockfield
Peggy Day
William Dixon
Peter C. Georgas
Shirl Holingsworth
William Kane
Colin Morris
Joe Muhlberger
Philip Nunn
Pat Patrick
David Pym
Linn C. Stuckenbruck
George Vallance
Larry C. Woolslager
Shakir Zuberi
Adems de ampliar y reestructurar el material original, el documento revisado inclua tres
nuevas secciones:
Estructura de Direccin de Proyectos; que se aadi para cubrir las relaciones entre el
proyecto y el entorno externo y entre la direccin de proyectos y la gestin en general.
La Gestin de Riesgos se aadi como un rea de conocimiento separada, a fin de proporcionar una mejor cobertura del tema.
Se aadi la Gestin de Contratos/Adquisiciones como un rea de conocimiento separada,
a fin de proporcionar mejor cobertura del tema.
Posteriormente se agregaron al material diversos cambios editoriales y correcciones y el
Comit de Directores del PMI lo aprob en Marzo de 1987. La versin final se public en
Agosto de 1987 como un nico documento titulado Fundamentos de la Direccin de Proyectos.
168
B.3 ACTUALIZACIN 1996

Tras la publicacin de la versin 1987, continuaron las discusiones sobre el formato apropiado,
contenido y estructura del documento clave de estndares del PMI. En Agosto de 1991, el
Director de Estndares del PMI, Alan Stretton, comenz con un proyecto para actualizar el
documento, basado en comentarios recibidos de los miembros. Distribuyendo extensamente
los borradores de trabajo y a travs de talleres en Seminarios/Simposios del PMI en Dallas,
Pittsburgh y San Diego, despus de varios aos se desarroll un documento revisado.
En Agosto de 1994, el Comit de Estndares del PMI public un Borrador Primario del
documento que se distribuy para que todos los 10.000 miembros del PMI y ms de veinte asociaciones profesionales y tcnicas hicieran sus comentarios.
La publicacin de la Gua de Fundamentos de la Direccin de Proyectos (PMBOK Guide)
en 1996 represent la finalizacin del proyecto iniciado en 1991. Ms adelante en esta seccin
se enumeran los colaboradores y revisores. Tambin se enumera ms adelante en esta seccin
un resumen de las diferencias entre el documento de 1987 y el de 1996, que se incluyeron en
el Prefacio de la edicin de 1996.
El documento reemplaza a los Fundamentos de la Direccin de Proyectos del PMI
(PMBOK), que se public en 1987. Con el fin de ayudar a los usuarios del documento de
1996, que puedan estar familiarizados con su predecesor, a continuacin resumimos las mayores diferencias.
1. Cambiamos el ttulo para enfatizar que este documento no contiene todos los fundamentos de la direccin de proyectos. El documento de 1987 defini a los fundamentos de direccin de proyectos como todos aquellos temas, materias y procesos intelectuales que tengan
que ver con la aplicacin de acertados principios de gestin para proyectos. Claramente,
nunca un documento contendr los fundamentos completos de la direccin de proyectos.
2. Rescribimos completamente la seccin Estructura. La nueva seccin consta de tres captulos:
Introduccin, que establece el propsito del documento y define ampliamente los trminos
proyecto y direccin de proyectos.
El Contexto de la Direccin de Proyectos, que cubre el contexto en que operan los
proyectosel ciclo de vida del proyecto, las perspectivas de las personas interesadas en el
proyecto, influencias externas y habilidades clave de gestin en general.
Procesos de la Direccin de Proyectos, que describe como se interrelacionan los varios elementos de la gestin de proyectos.
3. Desarrollamos una versin revisada de la definicin de proyecto. Queramos tener una
definicin que fuera a la vez abarcadora (no debera ser posible identificar cualquier cometido
que generalmente se pensara como un proyecto y que no se ajustara a la definicin) y
excluyente (no debera ser posible identificar cualquier cometido que satisfaga la definicin
y no se considera generalmente como un proyecto). Revisamos muchas definiciones de
proyecto en la literatura existente y encontramos que todas ellas eran de algn modo insatisfactorias. La nueva definicin est guiada por la caracterstica nica de un proyecto: un
proyecto es un esfuerzo temporario, llevado a cabo para crear un producto o servicio nico.
4. Desarrollamos una visin revisada del ciclo de vida del proyecto. El documento de 1987
defina las fases del proyecto como subdivisiones del ciclo de vida del proyecto. Esta relacin
se ha reordenado y se defini al ciclo de vida del proyecto como una coleccin de fases cuyo
nombre y nmero estn determinados por las necesidades de control de la organizacin que
lleva a cabo el proyecto.
5. Cambiamos el nombre de las principales secciones de funcin a rea del conocimiento.
El trmino funcin se malentenda frecuentemente como un elemento de una organizacin
funcional. El cambio de nombre deber eliminar este malentendido.
6. Reconocimos formalmente la existencia de una novena rea de conocimiento. Ha habido
amplio consenso por algn tiempo que la gestin de proyectos es un proceso integrador. El
Captulo 4, Gestin de la Integracin del Proyecto, reconoce la importancia de esta materia.
169
Apndice B
7. Agregamos la palabra proyecto al ttulo de cada rea de conocimiento. Aunque esto

pudiera parecer redundante, ayuda a clarificar el alcance del documento. Por ejemplo, Gestin
de los Recursos Humanos del Proyecto cubre slo aquellos aspectos de la gestin de recursos
humanos que son nicos o casi nicos en el contexto del proyecto.
8. Elegimos describir las reas de conocimiento en trminos de los procesos que las componen. La bsqueda de un mtodo consistente de presentacin nos llev a reestructurar completamente el documento de 1987 en treinta y siete procesos de la direccin de proyectos. Cada
proceso se describe en trminos de sus entradas, salidas y sus herramientas y tcnicas. Las
entradas y salidas son documentos (p.e., la descripcin del alcance) o artculos documentables
(p.e., dependencias de actividad). Las herramientas y tcnicas son los mecanismos aplicados a
las entradas para crear las salidas. Adems de su simplicidad fundamental, este enfoque ofrece
varios otros beneficios:
Enfatiza las interacciones entre las reas de conocimiento. Las salidas de un proceso se convierten en entradas para otro.
La estructura es flexible y robusta. Los cambios en el conocimiento y la prctica se pueden
acomodar agregando un proceso nuevo, reordenando la secuencia de los procesos, subdividiendo los procesos, o agregando material descriptivo dentro de un proceso.
Los procesos pertenecen al ncleo de otros estndares. Por ejemplo, las normas de calidad
de la Organizacin Internacional para la Normalizacin (las series ISO 9000) se basan en la
identificacin de los procesos de negocios.
9. Aadimos algunas ilustraciones. En lo que hace a las estructuras detalladas del trabajo,
los diagramas de red y las curvas-S, una imagen vale ms que mil palabras.
10. Reorganizamos significativamente el documento. La tabla siguiente proporciona una
comparacin entre los principales encabezados del documento de 1987 y el de 1996:
1987 Nmero y Nombre
0. Estndares de PMBOK
1996 Nmero y Nombre
B. Evolucin de la Gua a los Fundamentos

de la Direccin de Proyectos del PMI
1. Estructura: Fundamentos
1. Introduccin (definiciones bsicas)
2. El Contexto de la Direccin de Proyectos
(los ciclos de vida)
2. Estructura: Visin General
1. Partes varias
2. Partes varias
3. Partes varias
3. Estructura: Modelo Integrador
3. Procesos de la Direccin de Proyectos
4. Gestin de la Integracin del Proyecto
4. Glosario de Trminos Generales
IV. Glosario
A. Gestin del Alcance
5. Gestin del Alcance del Proyecto
B. Gestin de la Calidad
8. Gestin de la Calidad del Proyecto
C. Gestin de Tiempos
6. Gestin de Tiempos del Proyecto
D. Gestin de Costos
7. Gestin de Costos del Proyecto
E. Gestin de Riesgos
11. Gestin de Riesgos del Proyecto
F. Gestin de los Recursos Humanos
9. Gestin de los Recursos Humanos del
Proyecto
G. Gestin de Contratos / Adquisiciones
12. Gestin de las Adquisiciones del Proyecto
H. Gestin de Comunicaciones
10. Gestin de las Comunicaciones del
Proyecto
11. Quitamos clasificar de la lista de propsitos. Tanto el documento de 1996 como la versin de 1987 proporcionaron una estructura para organizar el conocimiento de la gestin de
proyectos, pero ninguna es particularmente efectiva como herramienta de clasificacin. En
primer lugar, los tpicos incluidos no son globales no incluyen prcticas innovadoras o
inusuales. En segundo lugar, muchos elementos tienen relevancia en ms de un rea de
conocimiento o proceso, de tal modo que las categoras no son nicas.
170
Las siguientes personas, tal como se enumeraron en el Apndice C del documento de 1996,
contribuyeron de muchas maneras diferentes en los borradores del documento de 1996. El PMI
les agradece por su esfuerzo.
Comit de Estndares
Las siguientes personas participaron como miembros del Comit de Estndares del PMI durante
el desarrollo de la actualizacin al documento PMBOK de 1996:
William R. Duncan, DuncanNevison, Director de Estndares del PMI
Frederick Ayer, Defense Systems Management College
Cynthia Berg, Medtronic Micro-Rel
Mark Burgess, KnowledgeWorks
Helen Cooke, Cooke & Cooke
Judy Doll, Searle
Drew Fetters, PECO Energy Company
Brian Fletcher, ABRINN Project Management Services
Earl Glenwright, A.S.S.I.S.T.
Eric Jenett, Consultor
Deborah OBray, Manitoba Telephone System
Diane Quinn, Eastman Kodak Co.
Anthony Rizzotto, Miles Diagnostics
Alan Stretton, University of Technology, Sydney
Douglas E. Tryloff, TASC
Colaboradores
Adems de los miembros del Comit de Estndares, las siguientes personas proporcionaron
textos originales o conceptos clave para una o ms secciones en los captulos indicados:
John Adams, Western Carolina University (Captulo 3, Procesos de la Direccin de
Proyectos)
Keely Brunner, Ball Aerospace (Captulo 7, Gestin de Costos del Proyecto)
Louis J. Cabano, Pathfinder, Inc. (Captulo 5, Gestin del Alcance del Proyecto)
Captulo de PMI de Houston
Captulo de PMI de Manitoba
Captulo de PMI de Nueva Zelanda
David Curling, Loday Systems (Captulo 12, Gestin de las Adquisiciones del Proyecto)
Douglas Gordon, Coordinacin de Proyectos Especiales (Captulo 7, Gestin de Costos del
Proyecto)
David T. Hulett, D.T. Hulett & Associates (Captulo 11, Gestin de Riesgos del Proyecto)
Edward Ionata, Bechtel/Parsons Brinckerhoff (Captulo 10, Gestin de las Comunicaciones
del Proyecto)
John M. Nevison, DuncanNevison (Captulo 9, Gestin de los Recursos Humanos del
Proyecto)
Hadley Reynolds, Reynolds Associates (Captulo 2, El Contexto de la Direccin de
Proyectos)
Agnes Salvo, CUNA Mutual Insurance (Captulo 11, Gestin de Riesgos del Proyecto)
W. Stephen Sawle, Consultants to Management, Inc. (Captulo 5, Gestin del Alcance del
Proyecto)
Leonard Stolba, Parsons, Brinckerhoff, Douglas & Quade (Captulo 8, Gestin de la Calidad
del Proyecto)
Ahmet Taspinar, MBP Network (Captulo 6, Gestin de Tiempos del Proyecto)
171
Apndice B
Francis M. Webster Jr. (Captulo 1, Introduccin)
Revisores
Adems del Comit de Estndares y los colaboradores, las siguientes personas proporcionaron
comentarios sobre varios borradores del documento de 1996:
Edward L. Averill, Edward Averill & Associates, Inc.
A. C. Fred Baker, Baker, Barnes Associates, Inc.
F. J. Bud Baker, Wright State University
Tom Belanger, The Sterling Planning Group
John A. Bing, Coastline Community College
Brian Bock, Ziff Desktop Information
Paul Bosakowski, Fluor Daniel
Dorothy J. Burton, Management Systems Associates, Ltd.
Cohort 93, University of Technology, Sydney
Cohort 94, University of Technology, Sydney
Kim Colenso, Applied Business Technologies
Samuel K. Collier, Mead Corporation
Karen Condos-Alfonsi, PMI Executive Office
E. J. Coyle, VDO Yazaki
Darlene Crane, Crane Consulting
Russ Darnall, Fluor Daniel
Maureen Dougherty, GPS Technologies
John J. Downing, Digital Equipment Corporation
Daniel D. Dudek, Optimum Technologies, Inc.
Lawrence East, Westinghouse
Quentin W. Fleming, Primavera Systems, Inc.
Rick Fletcher, Acres
Greg Githens, Maxicomm Project Services, Inc.
Leo Giulianeti, Keane Inc.
Martha D. Hammonds, AMEX TSG Systems
Abdulrazak Hajibrahim, Bombardier
G. Alan Hellawell, Eastman Kodak
Paul Hinkley, Meta Consultants
Wayne L. Hinthorn, PMI Orange Co.
Mark E. Hodson, Eli Lilly & Company
Lew Ireland, L. R. Ireland Associates
Elvin Isgrig, North Dakota State University
Murray Janzen, Procter & Gamble
Frank Jenes
Walter Karpowski, Management Assoc.
William F. Kerrigan, Bechtel International, Inc.
Harold Kerzner, Baldwin-Wallace College
Robert L. Kimmons, Kimmons-Asaro Group Ltd., Inc.
Richard King, AT&T
J. D. Kaay Koch, Koch Associates
Lauri Koskela, VTT Building Technology
Richard E. Little, Project Performance Management
Lyle W. Lockwood, Universal Technology Inc.
Lawrence Mack, PMI Pittsburgh
172
Christopher Madigan, Sandia National Laboratories

Michael L. McCauley, Integrated Project Systems
Hugh McLaughlin, Broadstar Inc.
Frank McNeely, National Contract Management Association
Pierre Menard, Universidad de Quebec en Montreal
Rick Michaels
Raymond Miller, AT&T
Alan Minson, A&R Minson
Colin Morris, Delcan Hatch
R. Bruce Morris
David J. Mueller, Westinghouse
Gary Nelson, Athena Consulting Inc.
John P. Nolan, AACE International
Louise C. Novakowski, Cominco Engineering Services, Ltd.
James OBrien, OBrien-Kreitzberg
JoAnn C. Osmer, Arbella Mutual Insurance Co.
Jon V. Palmquist, Allstate Insurance
Matthew Parry, Target Consultants
John G. Phippen, JGP Quality Services
Hans E. Picard, P&A Consultants Corporation
Serge Y. Piotte, Cartier Group
Charles J. Pospisil, Procon, Inc.
Janice Y. Preston, Pacifica Companies
Mark T. Price, GE Nuclear Energy
Christopher Quaife, Symmetric Resources
Peter E. Quinn, Canadian Air Force
Steven F. Ritter, Mead Corporation
William S. Ruggles, Ruggles & Associates
Ralph B. Sackman, Levi Strauss & Co.
Alice Sapienza, Simmons College
Darryl M. Selleck
Melvin Silverman, Atrium Associates, Inc.
Roy Smith, Decision Planning Corp.
Craig T. Stone, Management Counseling Corp.
Hiroshi Tanaka, JGC Corporation
Robert Templeton, MW Kellogg
Dick Thiel, King County (WA) DPW
Saul Thomashow, Andersen Consulting
J. Tidhar, Oranatech Management Systems, Ltd.
Vijay K. Verma, TRIUMF
Janet Toepfer, Business Office Systems
Alex Walton, Harris Corporation
Jack Way, Simetra, Inc.
R. Max Wideman, AEW Services
Rebecca Winston, EG&G Idaho Inc.
Hugh M. Woodward, Proctor & Gamble
Robert Youker, Management Planning & Control Systems
Shakir H. Zuberi, ICF Kaiser Engineers Hanford
Dirk Zwart, Computer Sciences Corp.
173
Apndice B | Apndice C
174
Equipo de Produccin
Una mencin especial le corresponde a los siguientes empleados de Comunicaciones del PMI:
Jeannette M. Cabanis, Editora, Divisin de Libros
Misty N. Dillard, Asistente Administrativa
Linda V. Gillman, Administradora
Bobby R. Hensley, Coordinador de Publicaciones
Jonathan Hicks, Administrador de Sistemas
Sandy Jenkins, Editora Asociada
Mark S. Parker, Coordinador de Produccin
Dewey L. Messer, Editor Gerente
Danell Moses, Coordinador de Promocin de Marketing
Shirley B. Parker, Gerente Comercial / Marketing
Melissa Pendergast, Coordinadora de Servicios de Informacin
James S. Pennypacker, Editor en Jefe
Michelle Triggs, Diseadora Grfica
Lisa Woodring, Asistente Administrativa
Apndice C
Colaboradores y
Revisores de
la Edicin 2000 de la Gua
PMBOK
Las siguientes personas contribuyeron de diferentes modos en los varios borradores de este
documento. El Project Management Institute (PMI) les est agradecido por su apoyo y les
reconoce su contribucin.
C.1 GRUPO DE MIEMBROS ASESORES DEL PROGRAMA DE

ESTNDARES DE LA DIRECCIN DE PROYECTOS DEL PMI
Las siguientes personas sirvieron como miembros del Grupo de Miembros Asesores del Programa de Estndares de la Direccin de Proyectos del PMI durante el desarrollo de esta edicin del documento Gua a los Fundamentos de la Direccin de Proyectos (Gua PMBOK)
George Belev, KAPL, Inc. Una Compaa Lockheed Martin
Cynthia A. Berg, PMP, Medtronic Microelectronics Center
Sergio Coronado Arrechedera, MicroStrategy
Judith A. Doll, PMP, Monsanto
J. Brian Hobbs, PMP, Universidad de Quebec en Montreal
David Hotchkiss, PMP, Nexgenix
C.2 EQUIPO DEL PROYECTO DE ACTUALIZACIN DE LA GUA

PMBOK
Las siguientes personas sirvieron como miembros del equipo del proyecto para esta Edicin
2000 de la Gua PMBOK, bajo el liderazgo de Cynthia A. Berg, PMP, como Directora del
Proyecto:
Cynthia A. Berg, PMP, Medtronic Microelectronics Center
Judith A. Doll, PMP, Monsanto
Daniel Dudek, PMP, PlanView, Inc.
Quentin Fleming, Primavera Systems, Inc.
175
Apndice C
Apndice C Colaboradores y Revisores de la Edicin 2000 de la Gua PMBOK
Earl Glenwright, ASSIST

David T. Hulett, Ph.D., International Institute for Learning Inc.
Gregory J. Skulmoski, University of Calgary
Greg Githens, PMP, Catalyst Management Consulting
C.3 CONTRIBUYENTES
Adems de los miembros del Grupo de Miembros Asesores al Programa de Estndares del PMI
y del Equipo del Proyecto de la Gua PMBOK, las siguientes personas proporcionaron textos
originales y conceptos clave para una o ms secciones en los captulos indicados. Por otra
parte, el Grupo de Inters Especfico de Gestin de Riesgos del Proyecto del PMI tambin proporcion liderazgo para la reescritura del Captulo 11, Gestin de Riesgos del Proyecto.
Quentin Fleming (Captulo 4, Gestin de la Integracin del Proyecto y Captulo 12, Gestin
de las Adquisiciones del Proyecto)
David Shuster (Captulo 8, Gestin de la Calidad del Proyecto)
David Hulett (Captulo 11, Gestin de Riesgos del Proyecto)
Sam Lane (Captulo 11, Gestin de Riesgos del Proyecto)
Ed Smith (Captulo 11, Gestin de Riesgos del Proyecto)
Alfredo del Cao (Captulo 11, Gestin de Riesgos del Proyecto)
Roger Graves (Captulo 11, Gestin de Riesgos del Proyecto)
David Hillson (Captulo 11, Gestin de Riesgos del Proyecto)
Stephen Reed (Captulo 11, Gestin de Riesgos del Proyecto)
Janice Preston (Captulo 11, Gestin de Riesgos del Proyecto editor)
Mike Wakshull (Captulo 11, Gestin de Riesgos del Proyecto editor)
Robert Youker (varias secciones a lo largo del documento)
C.4
REVISORES
Adems de los miembros del Grupo de Miembros Asesores al Programa de Estndares, del
Equipo del Proyecto de la Gua PMBOK y los Colaboradores, las siguientes personas proporcionaron comentarios al Borrador para Revisin de este documento:
Muhamed Abdomerovic, PMP, D. Eng.
Yassir Afaneh
Fabrizio Agnesi, PMP
Jon D. Allen, PMP
MaryGrace Allenchey, PMP
Robert A. Andrejko, PMP
Ichizo Aoki
Paul C. Aspinwall
Ronald Auffrdou, PMP
Edward Averill, PMP
Frederick L. Ayer, PMP
William W. Bahnmaier, PMP
A. C. Fred Baker, PMP
Carole J. Bass, PMP
Berndt Bellman
Sally Bernstein, PMP
Nigel Blampied, PE, PMP
John Blatta
Patrick Brown, PMP
Chris Cartwright, PMP
Bruce C. Chadbourne, PMP
Raymond C. Clark, PE
Michael T. Clark, PMP
Elizabeth Clarke
David Coates, PMP
Kim Colenso, PMP
Edmund H. Conrow, PMP
Kenneth G. Cooper
John Cornman, PMP
Richard F. Cowan, PMP
Kevin Daly, PMP
Mario Damiani, PMP
Thomas Diethelm, PMP
David M. Drevinsky, PMP
Frank D. Einhorn, PMP
Edward Fern, PMP
Christian Frankenberg, PMP
Scott D. Freauf, PMP
Jean-Luc Frere, PMP
Ichiro Fujita, PMP
Chikako Futamura, PMP
Serge Garon, PEng, PMP
176
Apndice C Colaboradores y Revisores de la Edicin 2000 de la gua PMBOK
Brian L. Garrison, PMP

Peter Bryan Goldsbury
Jean Gouix, PMP
Franz X. Hake
Chris Herbert, PMP
J. Brian Hobbs, PMP
Robin Hornby
Charles L. Hunt
George Jackelen
Elden F. Jones II, PMP, CMII
Lewis Kana, PMP
Ronald L. Kempf, PMP
Kurt V. Kloecker
Blase Kwok, PMP
Philip A. Lindeman
Lyle W. Lockwood, PMP
Arif Mahmood, PMP
Stephen S. Mattingly
Peter McCarthy
Krik D. McManus
Mary F. Miekoski, PMP
Gordon R. Miller, PMP
Jim Morris, PMP
William A. Moylan, PMP
Wolfgang Obermeier
Masato Ohori, PMP
Edward Oliver
Fernando Romero Peailillo
James M. Phillips, PMP
George Pitagorsky, PMP
Bradford S. Price, PMP
Naga Rajan
Bill Righter, PMP
Bernice L. Rocque, PMP
Jon Rude
Fabian Sagristani, PMP
Seymour Samuels
H. Peter Schiller
Maria Scott, PMP
Kazuo Shimizu, PMP
(en nombre del Captulo del PMI de
Tokio, Japan)
Melvin Silverman, Ph.D., P.E.
Keith Skilling, P.E., PMP
Kenneth F. Smith, PMP
Paul J. Solomon
Christopher Wessley Sours, PMP
Joyce Statz, PMP
Thangavel Subbu
Ahmet N. Taspinar, PMP
Eric Glover
Michael Goodman, PMP
Alexander Grassi Sr., PMP
Peter Heffron
Dr. David Hillson, PMP, FAPM
Marion Diane Holbrook
Bill Hubbard
Thomas P. Hurley, PMP
Angyan P. Jagathnarayanan
Sada Joshi, PMP
Subramaniam Kandaswamy, Ph.D., PMP
Robert Dohn Kissinger, Ph.D, PMP
Jan Kristrom
Lawrence P. Leach
Gbor Lipi
J. W. Lowthian, PMP
James Martin (en nombre de INCOSE)
Glen Maxfield
Rob McCormack, PMP
David Michaud
Oscar A. Mignone
Roy E. Morgan, PMP
Bert Mosterd, PMP
John D. Nelson, PMP
Cathy Oest, PMP
Kazuhiko Okubo, PE, PMP
Jerry Partridge, PMP
Francisco Prez-Polo, PMP
Crispin (Kik) Piney, PMP
David L. Prater, PMP
Samuel L. Raisch, PMP
G. Ramachandran, PMP
William Simon Vaughan Robinson
Wolfgang Theodore Roesch
Linda Rust, PMP
James N. Salapatas, PMP
Bradford N. Scales
John R. Schuyler, PMP
Shoukat Sheikh, MBA, PMP
Larry Sieck
Loren J. Simer Jr.

Greg Skulmoski
Barry Smythe, PMP
Joe Soto Sr., PMP
Charlene Spoede, PMP
Emmett Stine, PMP
Jim Szpakowski
John A. Thoren Jr., PMP
177
Apndice C | Apndice D
Apndice C Colaboradores y Revisores de la Edicin 2000 de la Gua PMBOK
Alan D. Uren, PMP

S. Rao Vallabhaneni
Ana Isabel Vzquez Urbina
William W. Wassel, PMP
Rebecca A. Winston
Juan Luis Valero, PMP

Ricardo Viana Vargas, PMP
Stephen E. Wall, PMP
Tammo T. Wilkens, PE, PMP
Jean A. Yager
C.5 COLABORACIONES A LOS DOCUMENTOS PREDECESORES

Se incluyen en esta edicin porciones de la edicin de 1996 y de otros documentos predecesores. El PMI desea reconocer como sustanciales colaboradores en este documento a los
siguientes voluntarios:
John R. Adams
William R. Duncan
Matthew H. Parry
Alan Stretton
R. Max Wideman
El PMI tambin desea reconoce las colaboraciones de los otros voluntarios enumerados en
el Apndice B.
C.6 EQUIPO DE PRODUCCIN

Corresponde una mencin especial a los siguientes empleados del PMI:
Linda Cherry, Editor
Steven L. Fahrenkrog, Gerente de Estndares
Lisa Fisher, Editora Asistente
Lewis M. Gedansky, Gerente de Investigacin
Linda V. Gillman, Coordinadora de Publicidad / Coordinadora de Permisos de Derechos de
Autor de la Gua PMBOK
Eva T. Goldman, Asociada para Investigacin Tcnica y Estndares
Paul Grace, Gerente de Certificacin
Sandy Jenkins, Editor Gerente
Toni D. Knott, Editor del Libro
Dewey L. Messer, Gerente de Diseo y Produccin
Mark S. Parker, Coordinador de Produccin
Shirley B. Parker, Gerente de Publicaciones del Libro / Comercial
Michelle Triggs Owen, Diseadora Grfica
Iesha D. Turner-Brown, Administradora de Estndares
178
Apndice D
Notas
CAPTULO1. INTRODUCCIN
1. The American Heritage Dictionary of the English Language, 3 ed. 1992.
Boston, Mass.: Houghton Mifflin Company.
2. Turner, J. Rodney. 1992. The Handbook of Project-Based Management. New
York: McGraw-Hill.
CAPTULO 2. EL CONTEXTO DE LA DIRECCIN DE PROYECTOS

1. Morris, Peter W. G. 1988. Managing Project Interfaces: Key Points for Project Success. In Cleland and King, Project Management Handbook, 2 ed. Englewood Cliffs, N.J.: Prentice-Hall.
2. Murphy, Patrice L. 1989. Pharmaceutical Project Management: Is It Different?
Project Management Journal (September).
3. Muench, Dean, et al. 1994. The Sybase Development Framework. Oakland,
Calif.: Sybase Inc.
4. Kotter, John P. 1990. A Force for Change: How Leadership Differs from Management. New York: The Free Press.
5. Pfeffer, Jeffrey. 1992. Managing with Power: Politics and Influence in Organizations. HBS Press. Quoted in Eccles et al., Beyond the Hype.
6. Eccles, Robert, et al. 1992. Beyond the Hype. Cambridge, Mass.: Harvard
University Press.
7. International Organization for Standardization. 1994. Code of Good Practice
for Standardization (Draft International Standard). Geneva, Switzerland: ISO
Press.
8. The American Heritage Dictionary of the English Language, 3 ed.
CAPTULO 3. PROCESOS DE LA DIRECCIN DE PROYECTOS

1. The American Heritage Dictionary of the English Language, 3 ed.
CAPTULO 4. GESTIN DE LA INTEGRACIN DEL PROYECTO

No hay notas para este captulo.
179
Apndice D | Apndice E
Apndice D Notas
CAPTULO 5. GESTIN DEL ALCANCE DEL PROYECTO

1. Turner, J. Rodney. 1992. The Handbook of Project-Based Management.
2. yign, M. Gven. 1993. A Decision Support System for R&D Project Selection and Resource Allocation Under Uncertainty. Project Management Journal 3
(Deciembre).
3. Scope Definition and Control, Publication 6-2. 1986 (July). Austin, Tex.:
Construction Industry Institute, p. 45.
CAPTULO 6. GESTIN DE TIEMPOS DEL PROYECTO

CAPTULO 7. GESTIN DE COSTOS DEL PROYECTO

CAPTULO 8. GESTIN DE LA CALIDAD DEL PROYECTO

1. International Organization for Standardization. ISO 8402. 1994. Quality
Management and Quality Assurance. Geneva, Switzerland: ISO Press.
2. Ibid.
3. Ibid.
4. Ibid.
5. Ibid.
6. Ibid.
CAPTULO 9. GESTIN DE LOS RECURSOS HUMANOS DEL

PROYECTO
CAPTULO 10. GESTIN DE LAS COMUNICACIONES DEL PROYECTO

CAPTULO 11. GESTIN DE RIESGOS DEL PROYECTO

CAPTULO 12. GESTIN DE LAS ADQUISICIONES DEL PROYECTO

180
Apndice E
Extensiones al rea de
Aplicacin
E.1 NECESIDAD DE EXTENSIONES AL REA DE APLICACIN

Estas extensiones son necesarias cuando existen prcticas y conocimientos en un rea de aplicacin generalmente aceptados para una categora de proyectos pero que no son generalmente
aceptados en todos los tipos de proyectos de la mayora de las reas de aplicacin. Estas extensiones reflejan:
Aspectos nicos o inusuales del entorno del proyecto que el equipo de direccin del
mismo debe tener en cuenta para administrarlo eficientemente y eficazmente.
Conocimientos comunes y prcticas que, en caso de ser seguidos, mejorarn la eficiencia
y efectividad del proyecto (p.e.: estructuras estndar detalladas del trabajo).
Los conocimientos especficos y prcticas para un rea de aplicacin puede aparecer como
resultado de muchos factores, incluyendo, pero no limitados a, diferencias en normas culturales, terminologa tcnica, impacto social, o ciclos de vida del proyecto. Por ejemplo:
En la construccin, donde virtualmente todos los trabajos son efectuados bajo contrato, hay
conocimientos comunes y prcticas relacionadas con las adquisiciones que no se aplican a
todas las categoras de proyectos.
En biociencia, hay conocimientos comunes y prcticas guiadas por el entorno regulatorio
que no se aplican a todas la categoras de proyectos.
En la contratacin con el gobierno, hay conocimientos comunes y prcticas guiadas por las
regulaciones de las adquisiciones del gobierno que no se aplican a todas las categoras de
proyectos.
En consultora, hay conocimientos comunes y prcticas creadas por las responsabilidades
de Marketing o ventas del director del proyecto que no se aplican a todas las categoras de
proyectos.
Las extensiones al rea de aplicacin son:
Agregados al material principal de los Captulos 1 al 12, no sustitutos a l.
181
Apndice E
Apndice E Extensiones al rea de Aplicacin
Organizadas de una manera similar a este documentoesto es, identificando y describiendo los procesos de la administracin del proyecto nicos para aquella rea de aplicacin.
Agregados nicos al material principal:
Identificando procesos nuevos o modificados
Subdividiendo procesos existentes
Describiendo secuencias diferentes o interacciones de procesos
Incrementando elementos o modificando las definiciones de procesos comunes
Definiendo entradas, herramientas y tcnicas, y/o salidas especiales para los procesos
existentes
Las extensiones al rea de aplicacin no son:
Documentos sobre cmo hacer o directrices prcticas tales documentos podran ser
publicados como estndares del PMI, pero no es lo que se intenta presentar como extensiones.
Un menor nivel de detalle que el que se proporciona en este documento tales detalles
podran proporcionarse en manuales o guas que podran ser publicados como estndares
del PMI, pero no es lo que se intenta presentar como extensiones.
E.2 CRITERIOS PARA EL DESARROLLO DE EXTENSIONES AL REA DE

APLICACIN
Las extensiones se desarrollarn bajo los siguientes criterios:
Existe un cuerpo sustancial de conocimientos que est orientado a los proyectos y que es
nico o casi nico para aquella rea de aplicacin.
Hay un componente reconocible del PMI (p.e.: un Grupo de Inters Especfico, Universidad, o Captulo) o una organizacin externa reconocible deseosa y capaz de comprometer los recursos necesarios para suscribir y soportar el Programa de Estndares del PMI
con el desarrollo y mantenimiento de un Estndar del PMI especfico. Las extensiones
pueden ser desarrolladas por el mismo PMI.
La extensin propuesta es capaz de pasar el mismo nivel de exigencias del riguroso Proceso de Establecimiento de Estndares para la Direccin del Proyecto del PMI como
cualquier otro Estndar del PMI.
E.3 PUBLICACIN Y FORMATO DE LAS EXTENSIONES AL REA DE

APLICACIN
Las extensiones al rea de aplicacin se desarrollan y/o publican por el PMI, o son desarrolladas y/o publicadas por un componente del PMI o una organizacin externa bajo un acuerdo
formal con el PMI.
Las extensiones son comparables con este documento en estilo y contenido. Usan los
nmeros de prrafo y de sub-prrafo de este documento para el material que se haya
extendido.
Las secciones y prrafos de este documento que no se extienden no se repiten en las extensiones.
Las extensiones contienen un fundamento/justificacin sobre la necesidad de la extensin
y su material.
Las extensiones estn delimitadas en trminos de lo que ellas no intentan hacer.
182
E.4 PROCESO PARA EL DESARROLLO Y MANTENIMIENTO DE LAS

EXTENSIONES A LAS REAS DE APLICACIN
Una vez aprobados siguiendo el Proceso de Establecimiento de Estndares del PMI, las extensiones a las reas de aplicacin se transforman en Estndares del PMI. Sern desarrolladas y
mantenidas de acuerdo al proceso que se describe a continuacin.
Una extensin debe ser patrocinada por el PMI, por un componente formalmente aceptado
por el PMI (por ejemplo, un Grupo Especfico de Inters, un Colegio, un Captulo,) o
cualquier otra organizacin externa al PMI, aprobada por el Grupo de Miembros Asesores
al Programa de Estndares del PMI. La forma preferible de convenio es el co-patrocinio con
el PMI. Todas las aprobaciones sern a travs de un acuerdo formal escrito entre el PMI y
la entidad patrocinante, en el que el mismo incluir, entre otras cosas, el acuerdo entre
partes y los derechos de posesin de la propiedad intelectual y de publicacin de la extensin.
Cualquier proyecto para desarrollar, publicar y/o mantener una extensin debe ser
aprobado por el Programa de Estndares del PMI. Debe recibirse del PMI el permiso de
inicio, desarrollo y mantenimiento de la extensin, y ser tema de un acuerdo entre las
organizaciones. Si no hay ninguna otra empresa patrocinadora, el PMI puede elegir seguir
adelante solo.
El grupo de patrocinio notificar y solicitar consejo y apoyo del Grupo de Miembros
Asesores al Programa de Estndares del PMI durante todo el proceso de desa-rrollo y mantenimiento. Colaborarn con la idoneidad de la organizacin patrocinante de la extensin
propuesta y revisarn la extensin durante su desarrollo para identificar cualquier conflicto
o solapamiento con otros proyectos similares en camino.
El grupo de patrocinio preparar una propuesta para desarrollar la extensin. La propuesta
incluir una justificacin del proyecto con una matriz de los procesos especficos de aplicacin y las secciones afectadas de este documento. Tambin contendr el compromiso de
un nmero suficiente de redactores y revisores calificados; la identificacin de las necesidades de financiacin, incluyendo reproduccin, costos de envo postal, costos de telfono,
costos de la publicacin, etc.; el compromiso con los procedimientos del PMI para el desarrollo y mantenimiento de la extensin a los Estndares del PMI; y un plan y cronograma
del desarrollo y mantenimiento de la extensin.
Prosiguiendo con la aceptacin de la propuesta, el equipo del proyecto preparar un acta
del proyecto para ser aprobada por el grupo de patrocinio y el Equipo del Programa de
Estndares del PMI. El acta incluir las fuentes de recursos de financiamiento y cualquier
financiamiento propuesto para que sea provisto por el PMI. Incluir la necesidad de una
revisin peridica de la extensin a travs de informes al Equipo de Programa de Estndares del PMI y una Clusula de Cierre que especifique cundo, y bajo qu condiciones,
la extensin ser quitada del estado activo como estndar del PMI.
La propuesta ser emitida al Director de Estndares del PMI siguiendo el Proceso de
Establecimiento de Estndares del PMI. El Director de Estndares del PMI determinar si la
propuesta puede concluir en un documento que satisfaga los requerimientos de un
Estndar del PMI y si estn identificados los recursos y las fuentes de patrocinio adecuadas.
Para ayudar en esta determinacin, el Director de Estndares del PMI pedir revisin y
comentarios a los Miembros del Grupo Asesor del Programa de Estndares del PMI y, si
fuera necesario, a un panel de expertos, ajenos a la extensin.
El Director de Estndares del PMI, con el apoyo de los Miembros del Grupo Asesor del Programa de Estndares del PMI, supervisarn y colaborarn en el desarrollo del proyecto
aprobado.
La organizacin patrocinadora desarrollar la extensin de acuerdo al acta aprobada del
proyecto, incluyendo la coordinacin con el Equipo de Programa de Estndares del PMI
para soporte, revisin y comentarios.
Cuando se haya completado la extensin a satisfaccin de la organizacin patrocinadora,
se emitir al Director de Estndares del PMI, quien gestionar la aprobacin final y el proceso de publicacin, de acuerdo con el Proceso de Establecimiento de Estndares del PMI.
183
Apndice E | Apndice F
184
Esta presentacin final incluir la inclusin y el compromiso de la organizacin

patrocinadora con los procesos y esfuerzos de mantenimiento de la extensin del
PMI.
Una vez aprobada la extensin como Estndar del PMI, la organizacin patrocinadora implementar el proceso de mantenimiento de la extensin, de acuerdo con
el plan aprobado.
Apndice F
Fuentes Adicionales de
Informacin sobre la
Direccin de Proyectos
La Direccin de Proyectos es una disciplina creciente y dinmica y se publican regularmente
libros y artculos sobre el tema. Las instituciones listadas debajo proporcionan una variedad de
productos y servicios que pueden ser tiles a todos aquellos interesados en la Direccin de
Proyectos.
F.1 ORGANIZACIONES PROFESIONALES Y TCNICAS

Este documento fue desarrollado y publicado por el Project Management Institute (PMI). Se
puede poner en contacto con el PMI en:
Newtown Square, PA 19073-3299 EUA
Telfono: +610/356-4600
Fax: +610/356-4647
Email: pmihq@pmi.org
Internet: http://www.pmi.org
El PMI tiene actualmente acuerdos de cooperacin con las siguientes organizaciones:
Association for the Advancement of Cost Engineering (AACE International)
Telfono: +304/296-8444
Fax: +304/291-5728
Asociacin Espaola de Ingeniera de Proyectos (AEIPRO)
Telfono: +3476-976-761-910
Fax: +349-1447-3187
Australian Institute of Project Management (AIPM)
Telfono: +61-2-9960-0058
Fax: +61-2-9960-0052
Construction & Economy Research Institute of Korea (CERIK)
Telfono: +822-3441-0801
Fax: +822-544-6234
Defense Systems Management College Alumni Association (DSMCAA)
Telfono: +703/960-6802
Fax: +703/960-6807
Engineering Advancement Association of Japan (ENAA)
Telfono: +81-3-3502-4441
Fax: +81-3-3502-5500
185
Apndice F
Apndice F Fuentes Adicionales de Informacin sobre la Direccin de Proyectos
Institute of Project Management (IPM-Ireland)

Telfono: +353-1-661-4677
Fax: +353-1-661-3588
International Project Management Association (IPMA)
Telfono: +44-1594-531-007
Fax: +44-1594-531-008
Korean Institute of Project Management & Technology (PROMAT)
Telfono: +822-522-0360
Fax: +822-523-1680
National Contract Management Association (NCMA)
Telfono: 703/448-9231
Fax: +703/448-0939
The NORDNET National Associations
(Dinamarca, Finlandia, Islandia, Noruega, y Suecia)
Fax: +468-719-9316
Project Management Associates (PMA-India)
Telfono: +91-11-852-6673
Fax: +91-11-646-4481
Project Management Institute South Africa
Telfono: +2711-706-6813
Projekt Management Austria
Telfono: +43-1-1313-52-215
Fax: +43-1-319-78-55
Russian Project Management Association (SOVNET)
Telfono: +7-095-133-26-11
Fax: +7-095-133-24-41
Ukrainian Project Management Association
Telfono: +38-044-272-9400 o +38-044-245-4857
Project Management Association of Slovakia (SPPR)
Telfono: +421-805-599-1806
Fax: +421-805-599-1-818
Slovenian Project Management Association (ZPM)
Telfono: +386-6117-667-134
Fax: +386-61217-431
Adicionalmente, hay numerosas organizaciones en campos relacionados que pueden proporcionar ms informacin sobre la Direccin de Proyectos. Por ejemplo:
Academy of Management
American Management Association International
American Society for Quality Control
Construction Industry Institute
Construction Management Association of America (CMAA)
Institute of Electrical and Electronics Engineers (IEEE)
Institute of Industrial Engineers (IIE)
International Council on Systems Engineering (INCOSE)
National Association for Purchasing Management
National Contract Management Association
Society for Human Resource Management
American Society of Civil Engineers
La informacin vigente para contactar stas y otras organizaciones profesionales y tcnicas
se puede encontrar generalmente en Internet.
F.2 EDITORIALES COMERCIALES

El PMI es el mayor editor de libros de Direccin de Proyectos. Muchas editoriales comerciales
producen libros sobre Direccin de Proyectos y temas relacionados. Las editoriales comerciales
que editan regularmente tales materiales son:
Addison-Wesley
AMACOM
186
Apndice F Fuentes Adicionales de Informacin sobre la Direccin de Proyectos
Gower Press
John Wiley & Sons
Marcel Dekker
McGraw-Hill
Prentice-Hall
Probus
Van Nostrand Reinhold
La mayora de los libros sobre la Direccin de Proyectos de estas editoriales se pueden conseguir a travs del PMI. Muchos de los libros disponibles incluyen extensa bibliografa o listas
de lecturas seleccionadas.
F.3 PROVEEDORES DE PRODUCTOS Y SERVICIOS

Las compaas que suministran software, entrenamiento, consultora, y otros productos y servicios para la profesin de la direccin de proyectos frecuentemente proporcionan monografas
o reimpresiones.
El Programa de Proveedor Registrado de Educacin (R.E.P.) del PMI facilita el desarrollo
profesional continuo de los Miembros del PMI, Profesionales de la Direccin de Proyectos
(PMPs), y otros interesados en la direccin de proyectos vinculando a stos y a los coordinadores de capacitacin con calificados proveedores de educacin y productos. Se puede
encontrar un listado del R.E.P. y sus ofertas educativas asociadas en http://www.pmi.org/education/rep.
F.4 INSTITUCIONES EDUCATIVAS

Muchas universidades y facultades ofrecen programas de educacin continua en la Direccin
de Proyectos y disciplinas relacionadas. Muchas de estas instituciones tambin ofrecen programas para alumnos y graduados.
187
APNDICE G
RESUMEN DE LAS REAS

DE CONOCIMIENTO DE LA
DIRECCIN DE PROYECTOS
GESTIN DE LA INTEGRACIN DEL PROYECTO

Una parte de la Direccin de Proyectos que incluye los procesos requeridos para asegurar que
los diferentes elementos del proyecto son apropiadamente coordinados. Consiste de:
Desarrollo del plan del proyecto integrar y coordinar todos los planes del proyecto para
crear un documento consistente y coherente.
Ejecucin del plan del proyecto llevar a cabo el plan del proyecto realizando las actividades incluidas en l.
Control de cambios integrado coordinar los cambios a lo largo de todo el proyecto.
GESTIN DEL ALCANCE DEL PROYECTO

el proyecto incluye todo el trabajo necesario y solamente el trabajo necesario, para completar
el proyecto con xito. Consiste de:
Iniciacin: autorizacin del proyecto o fase.
Planificacin del alcance desarrollo de un informe escrito del alcance como la base para
futuras decisiones del proyecto.
Definicin del alcance subdividir los principales entregables del proyecto en componentes ms pequeos y manejables.
Verificacin del alcance formalizar la aceptacin del alcance del proyecto.
Control de cambios del alcance controlar los cambios en el alcance del proyecto.
GESTIN DE TIEMPOS DEL PROYECTO

Una parte de la Direccin de Proyectos que incluye los procesos requeridos para asegurar una
terminacin del proyecto en el tiempo previsto. Consiste de:
Definicin de actividades identificacin de las actividades especficas que deben ejecutarse para producir los diversos entregables del proyecto.
189
Apndice G
Apndice G Resumen de las reas de Conocimiento de las Direccin de Proyectos
Secuenciamiento de actividades identificacin y documentacin de las relaciones de

dependencia.
Estimacin de la duracin de las actividades estimacin del nmero de perodos laborales que se requerirn para completar las actividades individuales.
Desarrollo del cronograma anlisis de la secuencia de las actividades, duracin de las
actividades y requerimientos de recursos para crear el cronograma del proyecto.
Control del cronograma control de los cambios al cronograma del proyecto.
GESTIN DE COSTOS DEL PROYECTO

Una parte de la Direccin de Proyectos que incluye los procesos requeridos para asegurar una
terminacin del proyecto dentro del presupuesto aprobado. Consiste de:
Planificacin de recursos determinacin de qu recursos (personal, equipamiento, materiales) y qu cantidades de cada uno sern necesarios para realizar las actividades del
proyecto.
Estimacin de costos desarrollo de una aproximacin (estimacin) de los costos de los
recursos necesarios para completar las actividades del proyecto.
Asignacin del presupuesto de costos asignacin de los costos globales estimados a las
actividades individuales.
Control de costos control de cambios al presupuesto del proyecto.
GESTIN DE LA CALIDAD DEL PROYECTO

el proyecto va a satisfacer las necesidades para las cuales fue implementado. Consiste de:
Planificacin de la calidad identificar qu estndares de calidad son relevantes para el
proyecto y determinar cmo satisfacerlos.
Aseguramiento de la calidad evaluar el desempeo completo del proyecto, de manera
regular, de modo que brinde confianza de que el proyecto va a satisfacer los estndares de
calidad relevantes.
Control de calidad verificar los resultados especficos del proyecto para determinar si
cumplen con los estndares relevantes e identificar modos de eliminar las causas del
desempeo insatisfactorio.
GESTIN DE LOS RECURSOS HUMANOS DEL PROYECTO

Una parte de la Direccin de Proyectos que incluye los procesos necesarios para realizar el uso
ms efectivo de la gente involucrada en el proyecto. Consiste de:
Planificacin de la organizacin identificar, documentar y asignar roles, responsabilidades y lneas de reporte.
Contratacin de personal lograr que los recursos humanos necesarios sean asignados
y trabajen en el proyecto.
Desarrollo del equipo desarrollar las aptitudes individuales y de grupo para mejorar el
desempeo del proyecto.
GESTIN DE LAS COMUNICACIONES DEL PROYECTO

Una parte de la direccin del proyecto que incluye los procesos requeridos para asegurar la
generacin oportuna y apropiada, la recoleccin, la diseminacin, el almacenamiento, y la disposicin final de la informacin del proyecto. Consiste de:
190
Apndice G Resumen de las reas de Conocimiento de la Direccin de Proyectos
Planificacin de las comunicaciones determinar las necesidades de informacin y comunicacin de las personas interesadas en el proyecto: quin necesita qu informacin,
cundo la necesitarn, y cmo les ser entregada.
Distribucin de la informacin hacer que la informacin necesaria est disponible para
las personas interesadas en el proyecto de manera oportuna.
Informes de rendimiento recolectar y distribuir informacin de rendimiento. Esto incluye
informes de situacin, medicin del progreso y pronstico de terminacin.
Cierre administrativo generar, recoger y distribuir informacin para formalizar la conclusin de una fase o del proyecto.
GESTIN DE RIESGOS DEL PROYECTO

La gestin de riesgos es el proceso sistemtico de identificacin, anlisis y respuesta a riesgos
del proyecto. Ello incluye maximizar las probabilidades y consecuencias de sucesos positivos
y minimizar las probabilidades y consecuencias de sucesos adversos a los objetivos del
proyecto. Incluye:
Planificacin de la gestin de riesgos decidiendo como enfocar y planear las actividades
de gestin de riesgos para un proyecto.
Identificacin de riesgos determinando qu riesgos pueden afectar al proyecto y documentando sus caractersticas.
Anlisis cualitativo de riesgos realizando un anlisis cualitativo de riesgos y condiciones
para priorizar sus efectos en los objetivos del proyecto.
Anlisis cuantitativo de riesgos midiendo la probabilidad y consecuencias de riesgos y
estimando sus implicancias en los objetivos del proyecto.
Planificacin de respuesta a los riesgos desarrollando procedimientos y tcnicas para
aumentar las oportunidades y reducir las amenazas a los objetivos del proyecto.
Supervisin y control de riesgos supervisando riesgos residuales, identificando nuevos
riesgos, ejecutando planes de reduccin de riesgos y evaluando su eficacia durante todo el
ciclo de vida del proyecto.
GESTIN DE LAS ADQUISICIONES DEL PROYECTO

Una parte de la Direccin de Proyectos que incluye los procesos necesarios para adquirir
bienes y servicios, de otras organizaciones, con el fin de alcanzar los objetivos del proyecto.
Consiste de:
Planificacin de las adquisiciones determinar qu adquirir y cundo.
Planificacin de la bsqueda de proveedores documentar las especificaciones del producto e identificar los potenciales proveedores.
Bsqueda de proveedores obtener cotizaciones, ofertas o propuestas, segn corresponda.
Seleccin de proveedores seleccionar entre potenciales proveedores.
Administracin del contrato gestionar la relacin con el proveedor.
Cierre del contrato conclusin y liquidacin del contrato, incluyendo la resolucin de
todos los asuntos pendientes.
191
SECCIN IV
GLOSARIO E NDICE
Glosario
ndice
GLOSARIO
1. INCLUSIONES Y EXCLUSIONES
Este glosario incluye trminos que:
son propios, o prcticamente nicos, de la esfera de direccin de proyectos (por ejemplo,
enunciacin del alcance, paquete de trabajo, estructura detallada del trabajo, mtodo del
camino crtico).
no son propios de la esfera de direccin de proyectos, pero se usan de una forma diferente
o con una acepcin ms concreta en este mbito que en el uso diario y general (por
ejemplo, fecha de inicio temprana, actividad, tarea).
En general, este glosario no incluye:
trminos especficos de un rea de aplicacin (por ejemplo, prospecto del proyecto como
documento legal, propio de la urbanizacin de terrenos).
trminos cuyo uso en la esfera de la direccin de proyectos no difiere en forma sustancial
del uso diario (por ejemplo, calendario).
trminos compuestos cuyo significado se deduce claramente de la combinacin de sus
componentes.
variantes, cuando el significado de la variante se deduce claramente del trmino bsico (por
ejemplo, se incluye informe por excepcin, pero no presentacin de informes por excepcin).
Como consecuencia de las inclusiones y exclusiones anteriores, este glosario incluye:
una preponderancia de trminos relativos a la gestin del alcance del proyecto, la gestin
de tiempos del proyecto y la gestin de riesgos del proyecto, dado que muchos de los
vocablos usados en estas reas son propios, o prcticamente nicos, de esta esfera de la
direccin de proyectos.
muchos trminos de gestin de la calidad del proyecto, dado que se usan de una manera
ms concreta que en la vida diaria.
relativamente pocos trminos relacionados con la gestin de los recursos humanos del
proyecto y la gestin de las comunicaciones del proyecto, dado que la mayora de los trminos usados en estas reas no difieren mucho del uso diario.
relativamente pocos trminos relacionados con la gestin de costos del proyecto y la
gestin de adquisiciones del proyecto, dado que la mayora de los trminos usados en estas
reas tienen significados especiales que son muy propios de un rea de aplicacin en particular.
195
Siglas Comunes | Acta
Glosario
2. SIGLAS COMUNES
AC
ACWP
ACWS
AD
ADM
AF
AOA
AON
AS
BAC
BCWP
Actual Cost
Actual Cost of Work Performed
Actual Cost of Work Scheduled
Activity Description
Arrow Diagramming Method
Actual Finish Date
Activity-On-Arrow
Activity-On-Node
Actual Start Date
Budget At Completion
Budgeted Cost of Work Performed
BCWS Budgeted Cots of Work Scheduled

CAP
CCB
CPFF
CPIF
Control Account Plan

Change Control Board
Cost Plus Fixed Fee
Cost Plus Incentive Fee
CPI
CPM
CV
DD
DU
EAC
EF
ES
ETC
Cost Performance Index

Critical Path Method
Cost Variance
Data Date
Duration
Estimate At Completion
Early Finish Date
Early Start Date
Estimate (or Estimated) to
Complete (or Completion)
Earned Value
Earned Value Management
Free Float or Finish-to-Finish
Firm Fixed Price
Fixed Price Incentive Fee
EV
EVM
FF
FFP
FPIF
FS Finish-To-Start
GERT Graphical Evaluation and Review
Technique
IFB Invitation For Bid
LF Late Finish Date
LOE Level Of Effort
LS Late Start Date
MPM Modern Project Management
OBS Organization(al) Breakdown
Structure
PC Percent Complete
PDM Precedence Diagramming
Method
PERT Program Evaluation and Review
Technique
196
Costo Real
Costo Real del Trabajo Realizado
Costo Real del Trabajo Programado
Descripcin de la Actividad
Mtodo de Diagramacin con Flechas
Fecha de Finalizacin Real
Actividad en la Flecha
Actividad en el Nodo
Fecha de Inicio Real
Presupuesto al Trmino
Costo Presupuestado del Trabajo
Realizado
Costo Presupuestado del Trabajo
Programado
Plan de Cuentas de Control
Comit de Control de Cambios
Contrato de Costo Ms Honorarios Fijos
Contrato de Costo Ms Honorarios con
Incentivos
ndice de Rendimiento de Costos
Mtodo del Camino Crtico
Variacin del Costo
Fecha de los Datos
Duracin
Estimacin al Trmino
Fecha de Finalizacin Temprana
Fecha de Inicio Temprana
Estimacin para Terminar
Valor del Trabajo Realizado
Gestin del Valor del Trabajo Realizado
Flotacin Libre o Final a Final
Precio Fijo Absoluto
Precio Fijo Ms Honorarios con Incentivos
Final a Inicio
Tcnica de Evaluacin y Revisin Grfica
Llamada a Licitacin
Fecha de Finalizacin Tarda
Nivel de Esfuerzo
Fecha de Inicio Tarda
Direccin Moderna de Proyectos
Estructura Detallada de la Organizacin
Porcentaje Terminado
Mtodo de Diagramacin por Precedencia
Tcnica de Evaluacin y Revisin del
Programa
Glosario
PF Planned Finish Date

PM (1) Project Management
(2) Project Manager
PMBOK Project Management Body of
Knowledge
PMP Project Management Professional

PS Planned Start Date
PV Planned Value
QA Quality Assurance
QC Quality Control
RAM Responsibility Assignment Matrix
RDU
RFP
RFQ
SF
SOW
SPI
SS
SV
TC
TF
TS
TQM
VE
WBS
Remaining Duration
Request For Proposal
Request For Quotation
(1) Scheduled Finish Date
(2) Start-To-Finish
Statement Of Work
Schedule Performance Index
(1) Scheduled Start Date
(2) Start-To-Start
Schedule Variance
Target Completion Date
(1)Total Float
(2) Target Finish Date
Target Start Date
Total Quality Management
Value Engineering
Work Breakdown Structure
Fecha de Finalizacin Planificada

(1) Direccin de Proyectos
(2) Director del Proyecto
Fundamentos de la Direccin de
Proyectos
Profesional en la Direccin de Proyectos
Fecha de Inicio Planificada
Valor Planificado
Aseguramiento de la Calidad
Control de Calidad
Matriz de Asignacin de
Responsabilidades
Duracin Restante
Solicitud de Propuesta
Solicitud de Cotizacin
(1) Fecha de Finalizacin Programada
(2) Inicio a Fin
Enunciacin del Trabajo
ndice de Rendimiento de Tiempos
(1) Fecha de Inicio Programada
(2) Inicio a Inicio
Variacin de Tiempos
Fecha de Conclusin Objetivo
(1) Flotacin Total
(2) Fecha de Finalizacin Objetivo
Fecha de Inicio Objetivo
Gestin por Calidad Total
Ingeniera del Valor
Estructura Detallada del Trabajo
3. DEFINICIONES
Muchas de las palabras definidas aqu tienen definiciones ms amplias, y en algunos casos distintas, en el diccionario.
Las definiciones utilizan las convenciones siguientes:
Los trminos que se utilizan como parte de las definiciones, y que se definen en el glosario,
aparecen en cursiva.
Cuando se incluyan sinnimos, no se dar definicin alguna y se dirigir al lector al trmino preferido (es decir, vase trmino preferido).
Los trminos relacionados que no sean sinnimos se citan con referencias cruzadas al final
de la definicin (es decir, vase tambin trmino relacionado).
A la Fecha de / As-of Date. Vase fecha de los datos.
Accin Correctiva / Corrective Action. Cambios que se hacen para que el futuro
rendimiento esperado del proyecto se ajuste al plan.
Aceptacin del Riesgo / Risk Acceptance. Tcnica del proceso de planificacin de la
respuesta a riesgos que indica que el equipo del proyecto ha decidido no cambiar el plan
del proyecto para hacer frente a un riesgo, o bien que no puede identificar alguna otra
estrategia de respuesta adecuada.
Acta / Charter. Vase acta del proyecto.
197
Acta del Proyecto | Categora de Riesgo
Glosario
Acta del Proyecto / Project Charter. Documento emitido por la direccin superior que define
formalmente la existencia de un proyecto y confiere autorizacin al director del proyecto para
aplicar los recursos de la organizacin para las actividades del proyecto.
Actividad / Activity. Trabajo realizado durante el transcurso de un proyecto. La actividad tiene
normalmente duracin, costo y recursos requeridos ya previstos. Las actividades se pueden
subdividir en tareas.
Actividad Casi Crtica / Near-Critical Activity. Actividad que tiene una reducida flotacin
total.
Actividad Crtica / Critical Activity. Cualquier actividad de un camino crtico. Se determina
ms comnmente con el mtodo del camino crtico. Aunque algunas actividades son
"crticas" en su sentido literal, sin estar en el camino crtico, este significado se utiliza raramente en el contexto del proyecto.
Actividad en el Nodo (AON) / Activity-On-Node (AON). Vase mtodo de diagramacin
por precedencia.
Actividad en la Flecha (AOA) / Activity-On-Arrow (AOA). Vase mtodo de diagramacin
con flechas.
Actividad Ficticia / Dummy Activity. Actividad de duracin nula que se utiliza para mostrar
una relacin lgica en el mtodo de diagramacin con flechas. Las actividades ficticias se
utilizan cuando las relaciones lgicas no pueden describirse completa o correctamente con
flechas de actividades normales. Las actividades ficticias se representan grficamente como
una lnea de rayas con punta de flecha.
Actividad Predecesora / Predecessor Activity. (1) En el mtodo de diagramacin con flechas, la actividad que entra en un nodo. (2) En el mtodo de diagramacin por precedencia,
la actividad "de procedencia".
Actividad Sucesora / Successor Activity. (1) En el mtodo de diagramacin con flechas,
la actividad que parte de un nodo. (2) En el mtodo de diagramacin por precedencia la
actividad "de destino".
Adelanto / Lead. Modificacin de la relacin lgica que posibilita la aceleracin de una tarea
posterior. Por ejemplo, en una dependencia de final a inicio con un adelanto de 10 das, la
actividad posterior puede empezar 10 das antes de que haya terminado la actividad anterior. Vase tambin desfase.
Administracin del Contrato / Contract Administration. Gestin de la relacin con el
vendedor.
Agrupamiento de Actividades / Hammock. Actividad que resume a varias (un grupo de
actividades afines aparece en conjunto y se informa en forma resumida). El agrupamiento
de actividades puede tener una secuencia interna, o no. Vase tambin subproyecto y
subred.
Alcance / Scope. La suma de los productos y servicios que se proporcionarn como
proyecto. Vase alcance del proyecto y alcance del producto.
Alcance del Producto / Product Scope. Caractersticas y funciones que caracterizan a un
producto o servicio.
Alcance del Proyecto / Project Scope. Labor que debe realizarse para entregar un producto
con las caractersticas y funciones especificadas.
Anlisis Cualitativo de Riesgos / Qualitative Risk Analysis. Realizacin de un anlisis no
numrico de riesgos y condiciones para asignar prioridades al efecto que tendrn sobre los
objetivos del proyecto. Conlleva la evaluacin de las probabilidades y el impacto del riesgo
o de los riesgos del proyecto y el empleo de mtodos, la matriz de probabilidades e impacto
por ejemplo, para clasificar los riesgos como altos, moderados y bajos con objeto de realizar
una planificacin de la respuesta a riesgos con prioridades.
Anlisis Cuantitativo de Riesgos / Quantitative Risk Analysis. Medicin de las probabilidades y consecuencias de los riesgos y el clculo de sus implicaciones para los objetivos
del proyecto. Los riesgos se caracterizan por las distribuciones de probabilidades de los
resultados posibles. Este proceso utiliza tcnicas cuantitativas como la simulacin y el
anlisis del rbol de decisiones.
198
Glosario
Anlisis de Hiptesis / Assumptions Analysis. Tcnica que analiza la exactitud de las

hiptesis e identifica los riesgos del proyecto causados por el carcter impreciso, incoherente o incompleto de las mismas.
Anlisis de la Red / Network Analysis. El proceso de identificar las fechas tempranas y
tardas de inicio y de finalizacin para las partes incompletas de las actividades del proyecto.
Vase tambin mtodo del camino crtico, tcnica de evaluacin y revisin del programa y
tcnica de evaluacin y revisin grfica.
Anlisis del rbol de Decisiones / Decision-Tree Analysis. El rbol de decisiones es un
diagrama que describe una decisin que se est considerando y las consecuencias de
seleccionar una u otra de las alternativas disponibles. Incorpora las probabilidades o riesgos
y los costos o las recompensas de cada camino lgico de hechos y decisiones futuras.
Anlisis del Cronograma / Schedule Analysis. Vase anlisis de redes.
Anlisis del Valor del Trabajo Realizado / Earned Value Analysis. Vase la definicin (1)
que aparece en valor del trabajo realizado.
Anlisis Matemtico / Mathematical Analysis. Vase anlisis de redes.
Anlisis Monte Carlo / Monte Carlo Analysis. Tcnica que realiza una simulacin del
proyecto en forma reiterada con el objeto de calcular una distribucin de los resultados
probables. Vase simulacin.
rea de Aplicacin / Application Area. Categora de proyectos con elementos comunes que
no se encuentran en todos los proyectos. Las reas de aplicacin se definen generalmente
basndose en el producto del proyecto (es decir, por tecnologas o sectores de industrias
similares) o en el tipo de cliente (por ej., interno o externo, gubernamental o comercial). A
menudo se superponen las reas de aplicacin.
Aseguramiento de la Calidad (QA) / Quality Assurance (QA). (1) El proceso de evaluar
peridicamente el rendimiento de todo el proyecto para asegurar que el proyecto cumplir
con las normas de calidad pertinentes. (2) La unidad de la organizacin a la que se asigna
la responsabilidad de asegurar la calidad.
Asignacin del Presupuesto de Costos / Cost Budgeting. Distribucin de los costos estimados a las distintas actividades del proyecto.
Asignacin para Contingencias / Contingency Allowance. Vase reserva.
Base de Datos de Riesgos / Risk Database. Banco de informacin que permite la recopilacin, el mantenimiento y anlisis de los datos recopilados y utilizados en el proceso de
gestin del riesgo. Un programa de lecciones aprendidas utiliza la base de datos de riesgos.
Se trata de un resultado del proceso de supervisin y control de riesgos.
Bsqueda de Proveedores / Solicitation. Obtencin de cotizaciones, licitaciones, ofertas o
propuestas, segn corresponda.
Clculo de Costos del Ciclo de Vida / Life-cycle Costing. El concepto de incluir los costos
de adquisicin, operacin y eliminacin al evaluar diversas alternativas.
Cambio del Alcance / Change in Scope. Vase modificacin del alcance.
Camino / Path. Conjunto de actividades relacionadas secuencialmente en un diagrama de
redes del proyecto.
Camino Acelerado / Fast Tracking. Compresin del cronograma del proyecto mediante la
superposicin de las actividades que normalmente se haran en secuencia, por ejemplo, el
diseo y la construccin. A veces se confunde con ingeniera concurrente.
Camino Crtico / Critical Path. Serie de actividades que determina la duracin del proyecto.
En un modelo determinista, el camino crtico se define generalmente como las actividades
con una flotacin menor o igual a un valor especificado, a menudo cero. Es el camino ms
largo del proyecto. Vase mtodo del camino crtico.
Camino de Red / Network Path. Toda serie continua de actividades conectadas en un diagrama de redes del proyecto.
Categora de Riesgo / Risk Category. Fuente de riesgo potencial que refleja los aspectos
tcnicos, de direccin del proyecto, organizacionales o de fuentes externas.
199
Ciclo de Vida del Proyecto | Cronograma de Hitos
Glosario
200
Ciclo de Vida del Proyecto / Project Life Cycle. Conjunto de fases del proyecto, que por lo
general siguen un orden secuencial, cuyo nombre y cantidad estn determinados por las
necesidades de control de la organizacin u organizaciones involucradas en el proyecto.
Cierre Administrativo / Administrative Closure. Generacin, recopilacin y diseminacin de
informacin para formalizar la finalizacin de un proyecto o fase.
Cierre del Contrato / Contract Close-out. Conclusin y liquidacin del contrato, incluyendo
la resolucin de todos los asuntos pendientes.
Cdigo de Cuentas / Code of Accounts. Todo sistema de numeracin que se utilice para
identificar de forma nica cada uno de los elementos de la estructura detallada del trabajo.
Vase tambin plan de cuentas.
Comit de Control de Cambios (CCB) / Change Control Board (CCB). Grupo de personas
interesadas en el proyecto, constituido formalmente y responsable de aprobar o rechazar
los cambios a los planes del proyecto.
Componente / Component. Parte constituyente, elemento.
Compresin / Crashing. Adopcin de medidas para reducir la duracin total del proyecto
despus de analizar varias alternativas para determinar cmo obtener una compresin
mxima de la duracin por el mnimo costo.
Compresin de la Duracin / Duration Compression. Reduccin del cronograma del
proyecto sin disminuir el alcance del proyecto. Esta compresin de la duracin no siempre
es posible y frecuentemente requiere un aumento del costo del proyecto.
Compresin del Cronograma / Schedule Compression. Vase compresin de la duracin.
Contingencias / Contingencies. Vase reserva y planificacin de contingencias.
Contratacin de Personal / Staff Acquisition. Obtencin de los recursos humanos necesarios asignados al proyecto y que trabajen en l.
Contrato / Contract. Un contrato es un acuerdo mutuo y vinculante que obliga al vendedor
a entregar el producto especificado y al comprador a pagar por l. Generalmente, los contratos corresponden a una de las siguientes categoras generales:
Contratos por precio fijo o de suma global: esta categora de contrato implica un precio total
fijo por un producto bien definido. Los contratos de precio fijo tambin pueden incluir incentivos por cumplir o superar determinados objetivos del proyecto, por ejemplo, los objetivos
de planificacin.
Contratos de costos reembolsables: esta categora de contrato implica el pago (reembolso)
al contratista por sus costos reales. Generalmente, los costos se clasifican en: directos
(costos incurridos directamente por el proyecto, por ejemplo, salarios de los miembros del
equipo del proyecto) e indirectos (costos asignados al proyecto por la organizacin ejecutora como costos de las operaciones, como por ejemplo los salarios de los ejecutivos de
la empresa). Generalmente, los costos indirectos se calculan como un porcentaje de los
costos directos. Los contratos de costos reembolsables frecuentemente incluyen incentivos
por cumplir o superar determinados objetivos del proyecto, por ejemplo, los objetivos de
planificacin o el costo total.
Contratos por tiempo y materiales: estos contratos constituyen un tipo hbrido de acuerdo
contractual que contienen aspectos de los acuerdos de costos reembolsables as como de
los de tipo de precio fijo. Los contratos por tiempo y materiales se asemejan a los acuerdos
de tipo de costos en que son modificables, porque el valor total del acuerdo no se define en
el momento de la firma del contrato. Por tanto, los contratos por tiempo y materiales pueden
crecer en valor contractual como si fueran acuerdos del tipo de costos reembolsables. Por
otra parte, los acuerdos por tiempo y materiales se parecen tambin a los acuerdos de
unidades fijas cuando, por ejemplo, las tarifas por unidad son preestablecidas por el comprador y el vendedor, como en el caso de que ambas partes convengan la remuneracin por
la categora de los "ingenieros principales".
Contrato de Costo ms Honorarios con Incentivos (CPIF) / Cost-Plus-Incentive-Fee
(CPIF) Contract. Un tipo de contrato en el que el comprador reembolsa al vendedor los
costos permitidos (segn la correspondiente definicin del contrato) y el vendedor obtiene
sus ganancias si cumple los criterios de rendimiento definidos.
Glosario
Contrato de Costo ms Honorarios Fijos (CPFF) / Cost-Plus-Fixed-Fee (CPFF) Contract. Un tipo de contrato en el que el comprador reembolsa al vendedor los costos permitidos (segn la correspondiente definicin del contrato) ms una cantidad fija de ganancias
(pago fijo).
Contrato por Precio Fijo / Fixed-Price Contract. Vase contrato por precio fijo absoluto.
Contrato por Precio Fijo Absoluto (FFP) / Firm Fixed-Price (FFP) Contract. Tipo de contrato en que el comprador paga al vendedor una cantidad establecida (segn se define en
el contrato) independientemente de los costos del vendedor.
Contrato por Precio Fijo ms Honorarios con Incentivos (FPIF) / Fixed-Price-IncentiveFee (FPIF) Contract. Tipo de contrato en que el comprador paga al vendedor una cantidad
establecida (segn se define en el contrato) y el vendedor puede ganar una cantidad adicional si cumple los criterios de rendimiento definidos.
Control / Control. Proceso de comparar el rendimiento efectivo con el rendimiento planificado,
analizar las variaciones, evaluar las alternativas posibles y tomar las acciones correctivas que
correspondan y segn sea necesario.
Control de Calidad (QC) / Quality Control (QC). (1) El proceso de supervisar los resultados
especficos del proyecto para determinar si cumplen las normas de calidad pertinentes e
identificar formas de eliminar las causas del rendimiento insatisfactorio. (2) La unidad de la
organizacin a la que se asigne la responsabilidad del control de calidad.
Control de Cambios del Alcance / Scope Change Control. Control de las modificaciones
del alcance del proyecto.
Control de Cambios Integrado / Integrated Change Control. Coordinacin de los cambios
en todo el proyecto.
Control de Costos / Cost Control. Control de los cambios en el presupuesto del proyecto.
Control de Respuestas a los Riesgos / Risk Response Control. Respuesta a los cambios
en materia de riesgos durante el transcurso del proyecto.
Control del Cronograma / Schedule Control. Control de los cambios del cronograma del
proyecto.
Control Global de los Cambios / Overall Change Control. Coordinacin de las modificaciones en todo el proyecto.
Convergencia de Caminos / Path Convergence. El nodo del plan donde confluyen o se
unen los caminos paralelos. En ese nodo, las demoras o el alargamiento de cualquier
camino convergente pueden retrasar el proyecto. En el anlisis cuantitativo de riesgos de un
plan, puede producirse un riesgo importante en este punto.
Costo de la Calidad / Cost of Quality. Los costos en los que se incurre para garantizar la calidad. El costo de la calidad incluye la planificacin de la calidad, el control de calidad y el aseguramiento de la calidad, as como la readaptacin.
Costo Final Proyectado / Forecast Final Cost. Vase estimacin al trmino.
Costo Presupuestado del Trabajo Programado (BCWS) / Budgeted Cost of Work
Scheduled (BCWS). Este trmino ha sido sustituido por el trmino valor planificado.
Costo Presupuestado del Trabajo Realizado (BCWP) / Budgeted Cost of Work Performed (BCWP). Este trmino ha sido sustituido por el trmino valor del trabajo realizado.
Costo Real (AC) / Actual Cost (AC). Los costos totales incurridos que deben estar relacionados con los que se hayan presupuestado dentro del valor planificado y del valor del trabajo realizado (que a veces pueden ser slo las horas de mano de obra directa, slo los
costos directos o todos los costos incluyendo los indirectos) en la realizacin del trabajo
durante un perodo dado. Vase tambin valor del trabajo realizado.
Costo Real del Trabajo Realizado (ACWP) / Actual Cost of Work Performed (ACWP).
Trmino que ha sido sustituido por el trmino costo real.
Cronograma / Schedule. Vase cronograma del proyecto.
Cronograma de Eventos Principales / Key Event Schedule. Vase cronograma maestro.
Cronograma de Hitos / Milestone Schedule. Cronograma resumido que identifica los hitos
principales. Vase tambin cronograma maestro.
201
Cronograma del Proyecto | Equipo de Direccin del Proyecto
Glosario
202
Cronograma del Proyecto / Project Schedule. Las fechas planificadas para realizar las
actividades y cumplir los hitos.
Cronograma Maestro / Master Schedule. Cronograma resumido que identifica las actividades principales y los hitos clave del proyecto. Vase tambin cronograma de hitos.
Cronograma Planificado / Target Schedule. Vase plan de referencia.
Cuantificacin de Riesgos / Risk Quantification. Evaluacin de la probabilidad de ocurrencia y efecto de un evento de riesgo.
Curva S / S-Curve. Representacin grfica de costos acumulativos, horas de mano de obra,
porcentaje de trabajo u otras cantidades, trazadas en funcin del tiempo. El nombre
proviene de la forma de S que tiene la curva (ms plana al principio y al final, y con una pendiente ms pronunciada en el centro) producida en un proyecto que empieza lentamente,
acelera y luego desacelera. Tambin es una expresin para la distribucin de probabilidad
acumulativa que se deriva de la simulacin, una herramienta del anlisis cuantitativo de
riesgos.
Definicin de Actividades / Activity Definition. Identificacin de las actividades especficas
que deben realizarse con objeto de producir los diferentes entregables del proyecto.
Definicin del Alcance / Scope Definition. Subdivisin de los principales entregables en
componentes ms pequeos y manejables para ejercer un mayor control.
Dependencia / Dependency. Vase relacin lgica.
Desarrollo de Respuestas a los Riesgos / Risk Response Development. Definicin de las
medidas tendientes a acrecentar las oportunidades y a reducir las amenazas.
Desarrollo del Cronograma / Schedule Development. Anlisis del orden lgico de las
actividades, de su duracin y de las necesidades de recursos para elaborar el cronograma
del proyecto.
Desarrollo del Equipo / Team Development. Desarrollo de competencias individuales y grupales para mejorar el rendimiento o la ejecucin del proyecto.
Desarrollo del Plan del Proyecto / Project Plan Development. Integracin y coordinacin
de todos los planes del proyecto para crear un documento uniforme y coherente.
Descripcin de la Actividad (AD) / Activity Description (AD). Frase o denominacin breve
que se utiliza en un diagrama de redes del proyecto. Normalmente, la descripcin de
actividad explica el alcance del trabajo de la actividad.
Desfase / Lag. Modificacin de la relacin lgica que dirige un retraso en la tarea posterior. Por
ejemplo, en una dependencia de final a inicio con un desfase de 10 das, la actividad posterior no puede empezar hasta 10 das despus de que haya terminado la actividad anterior. Vase tambin adelanto.
Diagrama de Barras / Bar Chart. Representacin grfica de la informacin relacionada con
la planificacin. En un diagrama de barras tpico, las actividades y otros elementos del
proyecto se enumeran de forma descendente en el lado izquierdo del diagrama, las fechas
aparecen a lo largo de la parte superior y la duracin de las actividades se muestran como
barras horizontales colocadas por fecha. Tambin se conoce como diagrama de Gantt.
Diagrama de Gantt / Gantt Chart. Vase diagrama de barras.
Diagrama de Lgica / Logic Diagram. Vase diagrama de redes del proyecto.
Diagrama de Pareto / Pareto Diagram. Un histograma, ordenado por frecuencia de ocurrencia, que muestra cuntos resultados se han generado por cada causa identificada.
Diagrama de PERT / PERT Chart. Trmino que se utiliza comnmente para referirse a un diagrama de redes del proyecto. Vase tcnica de evaluacin y revisin del programa para
obtener la definicin tradicional de PERT.
Diagrama de Redes con Escala de Tiempo / Time-Scaled Network Diagram. Todo diagrama de redes del proyecto trazado de tal manera que el posicionamiento y la longitud de
la actividad representen su duracin. Esencialmente, es un diagrama de barras que incluye
lgica de redes.
Glosario
Diagrama de Redes del Proyecto / Project Network Diagram. Toda representacin

esquemtica de las relaciones lgicas de las actividades del proyecto. Siempre se traza de
izquierda a derecha para reflejar la cronologa del proyecto. A menudo se lo llama incorrectamente "diagrama de PERT".
Diagrama de Responsabilidades / Responsibility Chart. Vase matriz de asignacin de
responsabilidades.
Diagramas de Control / Control Charts. Los diagramas de control son una representacin
grfica de los resultados de un proceso con el transcurso del tiempo comparados con los
lmites de control establecidos. Se utilizan para determinar si el proceso est "bajo control"
o si necesita algn ajuste.
Direccin de Proyectos (PM) / Project Management (PM). Aplicacin de conocimientos
tericos y prcticos, herramientas y tcnicas a las actividades del proyecto con objeto de
cumplir sus requisitos.
Direccin Moderna de Proyectos (MPM) / Modern Project Management (MPM). Expresin que se utiliza para distinguir el amplio alcance actual de la gestin de proyectos
(alcance, costo, tiempo, calidad, riesgo, etc.) respecto al uso tradicional y ms limitado que
se concentraba en el costo y el tiempo.
Director del Proyecto (PM) / Project Manager (PM). Persona responsable de la direccin
del proyecto.
Disparadores / Triggers. A veces se denominan sntomas o seales de advertencia del riesgo
y son indicaciones de que se ha producido un riesgo, o que est a punto de producirse. Las
alertas o disparadores pueden descubrirse en el proceso de identificacin de riesgos y ser
verificados en el proceso de supervisin y control de riesgos.
Distribucin de la Informacin / Information Distribution. Poner la informacin necesaria
a disposicin de las personas interesadas en el proyecto de forma oportuna.
Duracin (DU) / Duration (DU). Cantidad de perodos de trabajo (sin incluir los das festivos u
otros perodos de inactividad) necesarios para concluir una actividad u otro elemento del
proyecto. Generalmente, se expresa como jornadas o semanas laborales. A veces se
equipara incorrectamente a tiempo transcurrido. Vase tambin esfuerzo.
Duracin Restante (RDU) / Remaining Duration (RDU). El tiempo necesario para finalizar
una actividad.
Ejecucin del Plan del Proyecto / Project Plan Execution. Ejecucin del plan del proyecto
mediante la realizacin de las actividades incluidas en dicho plan.
Elemento / Element. Una de las partes, sustancias o principios que integran un conjunto complejo o compuesto.
Elemento del Trabajo / Work item. Este trmino ya no se utiliza. Es sinnimo de actividad.
Vase actividad.
Enlace / Link. Vase relacin lgica.
Entregable / Deliverable. Todo producto, resultado o elemento mensurable, tangible y verificable que deba entregarse para finalizar un proyecto, o parte de un proyecto. A menudo
se utiliza ms especficamente en referencia a un producto entregable externo, es decir algo
que est sujeto a la aprobacin del patrocinador o del cliente del proyecto.
Enunciacin del Alcance / Scope Statement. La enunciacin del alcance proporciona una
base documentada para tomar decisiones futuras sobre el proyecto y para que las personas
interesadas confirmen o tengan conocimiento general de su alcance. A medida que avance
el proyecto, es probable que sea necesario refinar o cambiar la enunciacin del alcance con
el fin de reflejar las modificaciones aprobadas que se realicen en el alcance del mismo.
Enunciacin del Trabajo (SOW) / Statement of Work (SOW). Descripcin narrativa de los
productos o servicios que han de suministrarse bajo el contrato.
Equipo de Direccin del Proyecto / Project Management Team. Miembros del equipo del
proyecto que participan directamente en las actividades de direccin del mismo. En los
proyectos ms pequeos, el equipo de direccin del proyecto puede incluir prcticamente
a todos los miembros del equipo del proyecto.
203
Esfuerzo | Final a Final
Glosario
204
Esfuerzo / Effort. Cantidad de unidades laborales necesarias para completar una actividad u
otro elemento del proyecto. Generalmente, se expresa como horas, das o semanas de trabajo del personal. No debe confundirse con duracin.
Estimacin al Trmino (EAC) / Estimate At Completion (EAC). Costo total previsto de una
actividad, de un grupo de actividades o del proyecto cuando se ha concluido todo el
alcance del trabajo definido. La mayora de las tcnicas para predecir la EAC incluyen algn
ajuste de la estimacin del costo original, basndose en el rendimiento del proyecto a la
fecha. Tambin se indica como estimado al trmino. A menudo se indica como
EAC = costos reales a la fecha + ETC. Vase tambin valor del trabajo realizado y estimacin
para terminar.
Estimacin de Costos / Cost Estimating. Clculo de una cantidad aproximada (estimada)
del costo de los recursos necesarios para finalizar las actividades del proyecto.
Estimacin de la Duracin de las Actividades / Activity Duration Estimating. Estimacin
del nmero de perodos de trabajo necesarios para finalizar las actividades individuales.
Estimacin de lo que Debera Costar / Should-Cost Estimates. Estimado del costo de un
producto o servicio que se utiliza para proporcionar una evaluacin del carcter razonable
del costo propuesto por un posible contratista.
Estimacin Definitiva / Definitive Estimate. Vase Estimado.
Estimacin del Orden de Magnitud / Order-of-Magnitude Estimate. Vase estimado.
Estimacin para Terminar (ETC) / Estimate To Complete (ETC). Costo restante previsto y
necesario para concluir una actividad, un grupo de actividades o el proyecto. La mayora de
las tcnicas para predecir el ETC incluyen algn ajuste del estimado original, basndose en
el rendimiento del proyecto a la fecha. Tambin denominado estimado para completar.
Vase tambin valor del trabajo realizado y estimacin al trmino.
Estimacin Paramtrica / Parametric Estimating. Tcnica de estimacin que utiliza una
relacin estadstica entre los datos histricos y otras variables (por ej., metros cuadrados en
construccin, lneas de cdigo en el desarrollo de software) para calcular un valor estimado.
Estimado / Estimate. Evaluacin del resultado cuantitativo probable. Normalmente, se aplica
a los costos y la duracin del proyecto y debe incluir siempre alguna indicacin de precisin
(por ej., x por ciento). Generalmente, se utiliza con un modificador (por ej., preliminar, conceptual, de viabilidad). Algunas reas de aplicacin tienen modificadores especficos que
implican intervalos concretos de precisin (por ej., estimacin del orden de magnitud, estimacin del presupuesto y estimacin definitiva en proyectos de ingeniera y construccin).
Estructura Detallada de la Organizacin (OBS) / Organizational Breakdown Structure
(OBS). Una representacin de la organizacin del proyecto, dispuesta de forma que relacione los paquetes de trabajo con las unidades de la organizacin.
Estructura Detallada del Trabajo (WBS) / Work Breakdown Structure (WBS). Agrupamiento de los elementos del proyecto orientado hacia los entregables, que organiza y
define el alcance total del trabajo del proyecto. Cada nivel descendente representa una
definicin cada vez ms detallada del trabajo del mismo.
Evento de Riesgo / Risk Event. Hecho aislado que puede afectar al proyecto de forma positiva o negativa.
Evento en el Nodo / Event-on-Node. Tcnica de diagramas de redes utilizada para representar los hechos mediante recuadros (o nodos) conectados por flechas para indicar el
orden lgico en que se producirn los mismos. Se utiliza en la tcnica de evaluacin y
revisin del programa original.
Evitacin del Riesgo / Risk Avoidance. Modificacin del plan del proyecto para eliminar el
riesgo o proteger los objetivos contra su impacto. Es una herramienta del proceso de planificacin de la respuesta a riesgos.
Fase / Phase. Vase fase del proyecto.
Fase del Proyecto / Project Phase. Coleccin de actividades del proyecto relacionadas lgicamente, que generalmente culminan con la finalizacin del un entregable principal.
Fecha de Conclusin Objetivo (TC) / Target Completion Date (TC). Una fecha impuesta
que restringe o modifica de alguna otra forma el anlisis de redes.
Glosario
Fecha de Finalizacin / Finish Date. Momento relacionado con la finalizacin de una

actividad. Generalmente, se califica con uno de los trminos siguientes: real, planificada,
estimada, programada, temprana, tarda, de referencia, objetivo, o actual.
Fecha de Finalizacin Actual / Current Finish Date. Estimado actual del momento en que
se finalizar una actividad.
Fecha de Finalizacin de Referencia / Baseline Finish Date. Vase fecha de finalizacin
programada.
Fecha de Finalizacin Planificada (PF) / Planned Finish Date (PF). Vase fecha de finalizacin programada.
Fecha de Finalizacin Programada (SF) / Scheduled Finish Date (SF). El momento en que
estaba planificado finalizar el trabajo de una actividad. La fecha de finalizacin programada
se encuentra normalmente dentro del periodo delimitado por la fecha de finalizacin temprana y la fecha de finalizacin tarda. Puede reflejar la nivelacin o escasez de recursos.
Fecha de Finalizacin Objetivo (TF) / Target Finish Date (TF). La fecha en la que est previsto (se pretende) concluir el trabajo de una actividad.
Fecha de Finalizacin Real (AF) / Actual Finish Date (AF). Momento en que se finaliz el
trabajo de una actividad. (Nota: en algunas reas de aplicacin, la actividad se considera
"finalizada" cuando el trabajo se ha "concluido sustancialmente").
Fecha de Finalizacin Tarda (LF) / Late Finish Date (LF). En el mtodo del camino crtico,
lo ms tarde posible que una actividad puede finalizarse sin retrasar un determinado hito del
proyecto (por lo general, la fecha de finalizacin del proyecto).
Fecha de Finalizacin Temprana (EF) / Early Finish Date (EF). En el mtodo del camino
crtico, lo antes posible que las partes incompletas de una actividad (o del proyecto) pueden
finalizar, basndose en la lgica de la red y en todas las restricciones de la planificacin. Las
fechas de finalizacin tempranas pueden cambiar a medida que avanza el proyecto y que
se hacen cambios en el plan del proyecto.
Fecha de Inicio / Start Date. Momento relacionado con el inicio de una actividad, calificado
generalmente por una de las palabras siguientes: real, planificada, estimada, programada,
temprana, tarda, objetivo, de referencia o actual.
Fecha de Inicio Actual / Current Start Date. Estimado actual del momento en que empezar
una actividad.
Fecha de Inicio Objetivo (TS) / Target Start Date (TS). La fecha en la que est planificado
(objetivo) comenzar el trabajo en una actividad.
Fecha de Inicio Planificada (PS) / Planned Start Date (PS). Vase fecha de inicio programada.
Fecha de Inicio Programada (SS) / Scheduled Start Date (SS). El momento en que estaba
previsto comenzar el trabajo de una actividad. La fecha de inicio programada concertada se
encuentra normalmente dentro del periodo delimitado por la fecha de inicio temprana y la
fecha de inicio tarda. Puede reflejar la nivelacin o escasez de recursos.
Fecha de Inicio de Referencia / Baseline Start Date. Vase fecha de inicio programada.
Fecha de Inicio Real (AS) / Actual Start Date (AS). Momento en que comenz el trabajo de
una actividad.
Fecha de Inicio Tarda (LS) / Late Start Date (LS). En el mtodo del camino crtico, lo ms
tarde posible en que una actividad puede comenzar sin retrasar un determinado hito (por lo
general, la fecha de finalizacin del proyecto).
Fecha de Inicio Temprana (ES) / Early Start Date (ES). En el mtodo del camino crtico, lo
antes posible que las partes incompletas de una actividad (o del proyecto) pueden empezar,
basndose en la lgica de la red y en todas las restricciones de la planificacin. Las fechas
de inicio tempranas pueden cambiar a medida que avanza el proyecto y que se efectan
cambios al plan del mismo.
Fecha de los Datos (DD) / Data Date (DD). Fecha en la que, o hasta la que el sistema de
informes del proyecto ha proporcionado el estado actual y los logros. Tambin se conoce
como a la fecha de.
Final a Final (FF) / Finish-to-Finish (FF). Vase relacin lgica.
205
Final a Inicio (FS) | Ingeniera Concurrente
Glosario
206
Final a Inicio (FS) / Finish-to-Start (FS). Vase relacin lgica.

Flecha / Arrow. Representacin grfica de una actividad. Vase tambin mtodo de diagramacin con flechas.
Flotacin / Float. Tiempo que una actividad puede atrasarse respecto a su fecha de inicio
temprana sin retrasar la fecha de finalizacin del proyecto. La flotacin es un clculo
matemtico y puede cambiar a medida que avance el proyecto y se produzcan cambios en
el plan del proyecto. Tambin se llama "holgura", flotacin total y flotacin del camino. Vase
tambin flotacin libre.
Flotacin del Camino / Path Float. Vase flotacin.
Flotacin Libre (FF) / Free Float (FF). Tiempo que una actividad puede atrasarse sin retrasar
la fecha de inicio temprana de cualquiera de las actividades sucesoras. Vase tambin
flotacin.
Flotacin Total (TF) / Total Float (TF). Vase flotacin.
Fondo para Contingencias / Buffer. Vase reserva.
Fragmento de Red / Fragnet. Vase subred.
Fundamentos de la Direccin de Proyectos (PMBOK) / Project Management Body of
Knowledge (PMBOK). Expresin inclusiva que describe la suma de conocimientos de la
profesin de direccin de proyectos. Al igual que con otras profesiones, como derecho,
medicina y contabilidad, los conocimientos residen en los profesionales y acadmicos que
lo aplican y contribuyen a su progreso. El PMBOK abarca prcticas tradicionales comprobadas que se aplican ampliamente, as como prcticas innovadoras y avanzadas que han
tenido un uso ms limitado.
Gerente de Lnea / Line Manager. (1) Gerente de cualquier grupo que fabrique un producto
o preste un servicio. (2) Un gerente funcional.
Gerente Funcional / Functional Manager. Director responsable de las actividades de un
departamento especializado o funcin especializada (por ej., ingeniera, fabricacin o mercadeo).
Gestin de Costos del Proyecto / Project Cost Management. Subconjunto de la direccin
de proyectos que incluye los procesos necesarios para garantizar que el proyecto finalice
dentro del presupuesto aprobado. Consiste en la planificacin de recursos, estimacin de
costos, asignacin del presupuesto de costos y el control de costos.
Gestin de Tiempos del Proyecto / Project Time Management. Subconjunto de la direccin de proyectos que incluye los procesos necesarios para garantizar su finalizacin en trmino. Consiste en la definicin de las actividades, secuenciamiento de las actividades,
estimacin de la duracin de las actividades, desarrollo del cronograma y control del cronograma.
Gestin de la Calidad del Proyecto / Project Quality Management. Subconjunto de la
direccin de proyectos que incluye los procesos necesarios para garantizar que el proyecto
satisfaga las necesidades para las cuales se emprendi. Consiste en la planificacin de la
calidad, el aseguramiento de la calidad y el control de calidad.
Gestin de la Integracin del Proyecto / Project Integration Management. Subconjunto
de la direccin de proyectos que incluye los procesos necesarios para garantizar que los
distintos elementos del proyecto se coordinen debidamente. Consiste en desarrollo del plan
del proyecto, ejecucin del plan del proyecto y control de cambios integrado.
Gestin de las Adquisiciones del Proyecto / Project Procurement Management. Subconjunto de la direccin de proyectos que incluye los procesos necesarios para adquirir
bienes y servicios externos a la organizacin ejecutora con el fin de lograr el alcance del
proyecto. Consiste en la planificacin de las adquisiciones, la planificacin de la bsqueda
de proveedores , la bsqueda de proveedores, la seleccin de proveedores, la administracin del contrato y el cierre del contrato.
Gestin de las Comunicaciones del Proyecto / Project Communications Management.
Subconjunto de la direccin de proyectos que incluye los procesos necesarios para garantizar la generacin, recopilacin, distribucin, almacenamiento y entrega final y apropiada de
la informacin del proyecto. Consiste en la planificacin de las comunicaciones, distribucin
de la informacin, informes de rendimiento y cierre administrativo.
Glosario
Gestin de los Recursos Humanos del Proyecto / Project Human Resource Management. Subconjunto de la direccin de proyectos que incluye los procesos necesarios para
emplear a las personas que participan en el proyecto de la forma ms eficaz posible. Consiste en la planificacin de la organizacin, contratacin de personal y desarrollo del equipo.
Gestin de Riesgos del Proyecto / Project Risk Management. Subconjunto de la direccin de proyectos que incluye los procesos sistemticos de identificacin, anlisis y
respuesta a los riesgos del proyecto. Incluye maximizar las probabilidades y consecuencias
de los eventos positivos y minimizar las probabilidades y consecuencias de los eventos
adversos para los objetivos del proyecto. Consiste en la planificacin de la gestin de
riesgos, la identificacin de riesgos, el anlisis cualitativo de riesgos, el anlisis cuantitativo
de riesgos, el plan de respuesta a riesgos y la supervisin y control de riesgos.
Gestin del Alcance del Proyecto / Project Scope Management. Subconjunto de la direccin de proyectos que incluye los procesos necesarios para garantizar que el proyecto
incluya todas las actividades necesarias, y solamente ellas, para finalizar el proyecto con
xito. Consiste en la iniciacin, la planificacin del alcance, la definicin del alcance, la verificacin del alcance y el control de cambios del alcance.
Gestin del Valor del Trabajo Realizado (EVM) / Earned Value Management (EVM).
Mtodo para integrar el alcance, la planificacin y los recursos, as como para medir el grado
de rendimiento del proyecto. Compara la cantidad de trabajo programada con la realizada
y el dinero presupuestado con el que se gast realmente para determinar si lo realizado se
ajusta a lo planificado.
Gestin por Calidad Total (TQM) / Total Quality Management (TQM). Mtodo comn que
se emplea para implementar un programa de mejoramiento de la calidad en una organizacin.
Grado / Grade. Categora o rango que se utiliza para distinguir elementos que tengan el mismo
uso funcional (por ej., "martillo") pero que no compartan los mismos requisitos de calidad
(por ej., distintos martillos pueden tener que resistir distintos grados de fuerza).
Hiptesis / Assumptions. Factores que se consideran verdaderos, reales o ciertos a efectos
de la planificacin. Las hiptesis afectan a todos los aspectos de la planificacin del
proyecto y son parte de la elaboracin gradual del proyecto. Frecuentemente, los equipos
del proyecto identifican, documentan y convalidan las hiptesis como parte de su proceso
de planificacin. Generalmente, las hiptesis conllevan un grado de riesgo.
Hito / Milestone. Hecho o evento importante del proyecto, normalmente la finalizacin de
algn producto entregable principal.
Holgura / Slack. Trmino utilizado en el mtodo de diagramacin con flechas para significar
flotacin.
Identificacin de Riesgos / Risk Identification. Determinacin de los riesgos que podran
afectar al proyecto y documentacin de sus caractersticas. Las herramientas utilizadas
incluyen la tormenta de ideas y las listas de verificacin.
ndice de Rendimiento de Costos (CPI) / Cost Performance Index (CPI). Relacin de eficiencia entre el valor del trabajo realizado y los costos reales. El CPI se utiliza frecuentemente
para predecir la magnitud de un posible sobrecosto usando la frmula siguiente: BAC/CPI
= proyeccin del costo final. CPI = EV/ AC.
ndice de Rendimiento de Tiempos (SPI) / Schedule Performance Index (SPI). Relacin
de eficiencia entre el valor del trabajo realizado y el valor planificado. EL SPI describe qu
parte del cronograma planificado se realiz realmente. SPI = EV / PV.
Informes de Rendimiento / Performance Reporting. Recopilacin y distribucin de la informacin sobre el grado de rendimiento del proyecto, que incluye informes de situacin,
medicin de los avances y pronsticos o proyecciones.
Informe por Excepcin / Exception Report. Documento que incluye solamente las variaciones importantes respecto al plan (en lugar de todas las variaciones).
Ingeniera Concurrente / Concurrent Engineering. Mtodo para dotar de personal a un
proyecto que, en su forma ms general, requiere la participacin de los encargados de la
implementacin en la fase de diseo. A veces se confunde con camino acelerado.
207
Ingeniera del Valor | Plan de Cuentas de Control (CAP)
Glosario
208
Ingeniera del Valor / Value Engineering. Se trata de un mtodo creativo que se utiliza para
optimizar los costos del ciclo de vida, ahorrar tiempo, aumentar las ganancias, mejorar la
calidad, ampliar la participacin en el mercado, resolver problemas y/o utilizar los recursos
de forma ms eficaz.
Iniciacin / Initiation. Autorizacin del proyecto o de la fase.
Inicio a Fin / Start-to-Finish. Vase relacin lgica.
Inicio a Inicio / Start-to-Start. Vase relacin lgica.
Interesados(as) / Stakeholder. Personas y organizaciones que estn involucradas activamente en el proyecto o cuyos intereses puedan resultar afectados positiva o negativamente
como resultado de la ejecucin o la finalizacin del mismo. Tambin pueden ejercer influencia en el proyecto y sus resultados.
Interrupcin Lgica / Hanger. Interrupcin involuntaria de un camino de redes. Por lo general, son causados por actividades o relaciones lgicas que faltan.
Lazo / Loop. Camino de redes que pasa dos veces por el mismo nodo. Los lazos o bucles no
pueden analizarse con las tcnicas tradicionales de anlisis de redes, como el mtodo del
camino crtico y las tcnicas de evaluacin y revisin del programa. Los bucles estn permitidos en la tcnica de evaluacin y revisin grfica.
Lecciones Aprendidas / Lessons Learned. Lo que se aprende del proceso de ejecucin del
proyecto. Las lecciones aprendidas pueden identificarse en cualquier momento. Tambin se
consideran un registro del proyecto.
Listas de Verificacin / Checklist. Listas de los riesgos posibles que pueden producirse en
un proyecto. Se utilizan como herramientas en el proceso de identificacin de riesgos. Las
listas de verificacin son amplias e incluyen los distintos tipos de riesgos que se han encontrado en proyectos anteriores.
Llamada a Licitacin (IFB) / Invitation for Bid (IFB). Normalmente, esta expresin es
equivalente a solicitud de propuesta. Sin embargo, en algunas reas de aplicacin, puede
tener un significado ms concreto o especfico.
Lgica / Logic. Vase lgica de redes.
Lgica de Redes / Network Logic. Coleccin de dependencias de las actividades que compone un diagrama de redes del proyecto.
Matriz de Asignacin de Responsabilidades (RAM) / Responsibility Assignment Matrix
(RAM). Estructura que relaciona la estructura de organizacin del proyecto con la estructura detallada del trabajo para ayudar a garantizar que cada elemento del alcance del
proyecto se asigne a una persona responsable.
Matriz de Probabilidades e Impacto / Probability and Impact Matrix. Forma comn de
determinar si un riesgo se considera bajo, moderado o alto, mediante la combinacin de los
dos aspectos de un riesgo, su probabilidad de ocurrencia y su impacto en los objetivos en
caso de que se produzca.
Matriz de Obligaciones / Accountability Matrix. Vase matriz de asignacin de responsabilidades.
Matriz de Responsabilidades / Responsibility Matrix. Vase matriz de asignacin de
responsabilidades.
Medicin del Rendimiento Tcnico / Technical Performance Measurement. Esta
medicin compara los logros tcnicos durante la ejecucin del proyecto con los logros tcnicos del cronograma del proyecto.
Mtodo de Diagramacin con Flechas (ADM) / Arrow Diagramming Method (ADM).
Tcnica de diagramacin de redes en la que se representan las actividades con flechas. La
cola de la flecha es el inicio y la punta es el final de la actividad (la longitud de la flecha no
representa la duracin esperada de la actividad). Las actividades se conectan en puntos llamados nodos (que generalmente se dibujan en forma de pequeos crculos) para ilustrar
el orden lgico previsto para realizarlas. Vase tambin mtodo de diagramacin por precedencia.
Glosario
Mtodo de Diagramacin por Precedencia (PDM) / Precedence Diagramming Method

(PDM). Tcnica de diagramas de redes en que las actividades se representan mediante
cuadros (o nodos). Las actividades se enlazan mediante relaciones de precedencia para
indicar la secuencia en que se realizarn.
Mtodo del Camino Crtico (CPM) / Critical Path Method (CPM). Una tcnica de anlisis
de redes que se utiliza para predecir la duracin del proyecto mediante el anlisis del orden
lgico de las actividades (el camino) que tenga el menor grado de flexibilidad de planificacin
(la menor flotacin). Las fechas tempranas se calculan por medio de un recorrido hacia adelante y se utiliza una fecha de inicio especfica. Las fechas tardas se calculan por medio de
un recorrido hacia atrs a partir de la fecha de conclusin especificada (generalmente, la
fecha de finalizacin temprana del proyecto calculada con el recorrido hacia adelante).
Miembros del Equipo / Team Members. Vase miembros del equipo del proyecto.
Miembros del Equipo del Proyecto / Project Team Members. Las personas que informan
directa o indirectamente al director del proyecto.
Mitigacin / Mitigation. Vase mitigacin de riesgos.
Mitigacin de Riesgos / Risk Mitigation. La mitigacin del riesgo procura reducir tanto las
probabilidades como el impacto de un riesgo a un grado aceptable.
Modificacin del Alcance / Scope Change. Todo cambio en el alcance del proyecto. Este
tipo de cambio casi siempre exige un ajuste en los costos o el cronograma del proyecto.
Nivel de Esfuerzo (LOE) / Level of Effort (LOE). Actividad de tipo auxiliar (por ej., contactos
con el proveedor o cliente) que no se presta fcilmente a una medicin de logro discreto.
Por lo general, se caracteriza por tener un ritmo uniforme de actividad a lo largo de un determinado perodo de tiempo.
Nivelacin / Leveling. Vase nivelacin de recursos.
Nivelacin de Recursos / Resource Leveling. Toda forma de anlisis de redes en que las
decisiones de planificacin (fechas de inicio y de finalizacin) se basan en aspectos relativos
a la gestin de los recursos (por ej., disponibilidad de recursos limitados o cambios de difcil
gestin en los niveles de recursos).
Nodo / Node. Uno de los puntos que definen una red; punto de confluencia unido a algunas
de las dems lneas de dependencia o a todas. Vase tambin mtodo de diagramacin
con flechas y mtodo de diagramacin por precedencia.
Organizacin Ejecutante / Performing Organization. Empresa cuyos empleados tienen
una participacin ms directa en la ejecucin de las actividades del proyecto.
Organizacin Funcional / Functional Organization. Estructura de la organizacin en que el
personal est agrupado jerrquicamente por especialidad (por ej., produccin, mercadotecna, ingeniera y contabilidad en el nivel superior; subdividindose ingeniera en
mecnica, elctrica y otras).
Organizacin Matricial / Matrix Organization. Toda estructura de la organizacin en que el
director del proyecto comparta responsabilidades con los gerentes funcionales para asignar
prioridades y dirigir el trabajo de las personas asignadas al proyecto.
Organizacin Proyectizada / Projectized Organization. Toda estructura organizativa en
la que el director del proyecto tenga autoridad plena para asignar prioridades y dirigir el trabajo de las personas asignadas al proyecto.
Paquete de Trabajo / Work Package. Entregable en el nivel ms bajo de la estructura detallada del trabajo. Puede obtenerse mediante el uso de un subproyecto en donde el paquete
de trabajo puede subdividirse en actividades.
Plan de Cuentas / Chart of Accounts. Todo sistema de numeracin que se utilice para
supervisar los costos del proyecto por categora (por ej., mano de obra, suministros y materiales). El plan de cuentas del proyecto se basa generalmente en el plan empresarial de
cuentas de la organizacin ejecutante principal. Vase tambin cdigo de cuentas.
Plan de Cuentas de Control (CAP) / Control Act Plan (CAP). Antes se llamaba Plan de
Cuentas de Costos. El CAP es un punto de control de gestin donde se produce la integracin del alcance, el presupuesto y el cronograma del proyecto, y donde se lleva a cabo
la medida del grado de rendimiento del mismo. Los CAP se colocan en determinados
puntos de gestin de la estructura detallada del trabajo.
209
Plan de Gestin de Riesgos | Retencin
Glosario
210
Plan de Gestin de Riesgos / Risk Management Plan. Documenta cmo se llevarn a

cabo los procesos relacionados con el riesgo durante el proyecto. Es el resultado de la planificacin de la gestin de riesgos.
Plan de Referencia / Baseline. El plan original (de un proyecto, un paquete de trabajo o una
actividad) con los cambios aprobados o sin ellos. Generalmente, se utiliza con un modificador (por ej., costos del plan de referencia, planificacin bsica, plan de referencia para la
medicin del rendimiento, etc.).
Plan de Referencia del Alcance / Scope Baseline. Vase plan de referencia.
Plan de Referencia para la Medicin del Rendimiento / Performance Measurement
Baseline. Plan aprobado con el que se comparan las desviaciones para controlar la gestin.
Plan de Respuesta a Riesgos / Risk Response Plan. Documento en que se detallan todos
los riesgos identificados, incluso la descripcin, causa, probabilidad de ocurrencia, impacto
o impactos en los objetivos, respuestas propuestas, responsables y condicin actual. Se
conoce tambin como registro de riesgos.
Plan del Proyecto / Project Plan. Documento formal aprobado que se utiliza para guiar tanto
la ejecucin como el control del proyecto. Los usos principales del plan del proyecto son
documentar las hiptesis y decisiones de planificacin, facilitar la comunicacin entre las
personas implicadas e interesadas en el proyecto y documentar los planes de referencia
aprobados en materia de alcance, costos y planificacin. El plan del proyecto puede ser
resumido o detallado.
Planificacin de Contingencias / Contingency Planning. El desarrollo de un plan de
gestin que identifique las estrategias alternativas que deben utilizarse para garantizar el
xito del proyecto si se producen determinadas situaciones de riesgo.
Planificacin de la Bsqueda de Proveedores / Solicitation Planning. Documentacin de
los requisitos de los productos e identificacin de las posibles fuentes de adquisicin.
Planificacin de la Calidad / Quality Planning. Identificacin de las normas de calidad que
correspondan al proyecto y la decisin de cmo cumplirlas.
Planificacin de la Gestin de Riesgos / Risk Management Planning. Decisin de cmo
enfocar y planificar las actividades de gestin de riesgos de un proyecto.
Planificacin de la Organizacin / Organizational Planning. Identificacin, documentacin
y asignacin de funciones, responsabilidades y relaciones de reporte.
Planificacin de la Respuesta a Riesgos / Risk Response Planning. Desarrollo de procedimientos y tcnicas para aumentar las oportunidades y reducir las amenazas para los
objetivos del proyecto. Las herramientas incluyen prevencin, mitigacin, transferencia y
aceptacin.
Planificacin de las Adquisiciones / Procurement Planning. Determinacin de qu adquirir
y cundo hacerlo.
Planificacin de las Comunicaciones / Communications Planning. Determinacin de las
necesidades de informacin y comunicacin de las personas interesadas en el proyecto:
quines necesitan informacin, cundo la necesitarn y cmo la obtendrn.
Planificacin de Recursos / Resource Planning. Determinacin de los recursos (personas,
equipos y materiales) que se necesitan, y en qu cantidades, para realizar las actividades
del proyecto.
Planificacin del Alcance / Scope Planning. Proceso de elaboracin gradual del trabajo del
proyecto, que incluye el desarrollo de una enunciacin del alcance por escrito que contiene
justificacin, entregables principales y objetivos del proyecto.
Planificacin del Proyecto / Project Planning. El desarrollo y mantenimiento del plan del
proyecto.
Planificacin Limitada por los Recursos / Resource-Limited Schedule. Una planificacin
del proyecto cuyas fechas de inicio y finalizacin reflejan la disponibilidad esperada de los
recursos. La planificacin final del proyecto siempre debe estar limitada por los recursos.
Porcentaje Terminado (PC) / Percent Complete (PC). Estimado porcentual de la cantidad
de trabajo concluido en una actividad o grupo de actividades.
Glosario
Presupuesto al Trmino (BAC) / Budget At Completion (BAC). Suma de los presupuestos

totales de un proyecto.
Presupuesto Estimado / Budget Estimate. Vase estimado.
Profesional en la Direccin de Proyectos (PMP) / Project Management Professional
(PMP). Persona certificada como tal por el Project Management Institute (PMI, Instituto de
Direccin de Proyectos).
Programa / Program. Grupo de proyectos relacionados y gestionados de forma coordinada.
Por lo general, los programas incluyen un elemento de actividad continuada.
Proyecto / Project. Emprendimiento temporal destinado a crear un producto, servicio o resultado nico.
Recorrido Hacia Adelante / Forward Pass. Clculo de las fechas tempranas de inicio y de
finalizacin para las partes incompletas de todas las actividades de redes. Vase tambin
anlisis de redes y recorrido hacia atrs.
Recorrido Hacia Atrs / Backward Pass. Clculo de fechas de finalizacin e inicio tardas
para las partes incompletas de todas las actividades de las redes. Se determina yendo hacia
atrs en la lgica de las redes a partir de la fecha de conclusin del proyecto, la que puede
calcularse en un recorrido hacia adelante o ser establecida por el cliente o patrocinador.
Vase tambin anlisis de redes.
Red / Network. Vase diagrama de redes del proyecto.
Registro de Riesgos / Risk Register. Vase plan de respuesta a riesgos.
Relacin de Precedencia / Precedence Relationship. Expresin que se utiliza en el mtodo
de diagramacin por precedencia para una relacin lgica. Sin embargo, en el uso actual,
la relacin de precedencia, la relacin lgica y cualquier dependencia se utilizan mucho de
forma intercambiable, independientemente del mtodo de diagramacin que se emplee.
Relacin Lgica / Logical Relationship. Dependencia entre dos actividades del proyecto o
entre una actividad y un hito del proyecto. Vase tambin relacin de precedencia. Los
cuatro tipos posibles de relaciones lgicas son:
Final a inicio: la iniciacin del trabajo posterior depende de la finalizacin del trabajo anterior.
Final a final: la finalizacin del trabajo posterior no puede producirse hasta la finalizacin del
trabajo anterior.
Inicio a inicio: la iniciacin del trabajo posterior depende de la iniciacin del trabajo anterior.
Inicio a final: la finalizacin del trabajo posterior depende de la iniciacin del trabajo anterior.
Reportes Integrados de Costos y Tiempos / Integrated Cost/Schedule Reporting.
Vase valor del trabajo realizado.
Reproceso / Rework. Medida tomada para que un producto defectuoso o que no responda
a los requisitos o especificaciones los cumpla.
Reserva / Reserve. Provisin de fondos en el plan del proyecto para mitigar el riesgo de
costos o planificacin, o de ambos. Se utiliza a menudo con un modificador (por ej., reserva
de gestin, reserva para contingencias) con objeto de proporcionar ms detalles sobre qu
tipos de riesgos se pretende mitigar. El significado especfico del trmino modificado vara
por rea de aplicacin.
Reserva de Gestin / Management Reserve. Cantidad planificada por separado que se utiliza para cubrir situaciones futuras que sean imposibles de predecir (a veces se le llama
"incgnitas desconocidas"). Las reservas de gestin pueden involucrar costo o tiempo. Las
reservas de gestin tienen como finalidad reducir el riesgo de incumplimiento de los objetivos de costos o de tiempos. El uso de la reserva de gestin requiere un cambio del plan
de referencia de los costos del proyecto.
Reserva para Contingencias / Contingency Reserve. Fondos o tiempo necesarios,
adems del estimado, para reducir el riesgo de sobrecostos del proyecto a un nivel aceptable para la organizacin.
Restriccin / Constraint. Restriccin aplicable que afectar el rendimiento del proyecto.
Cualquier factor que afecte el momento de planificacin de una actividad.
Retencin / Retainage. Parte del pago de un contrato que se retiene hasta su conclusin con
objeto de garantizar el pleno rendimiento de los trminos del contrato.
211
Riesgo | verificacin del Alcance
Glosario
212
Riesgo / Risk. Hecho o evento incierto o una condicin que, si se produce, tiene un efecto
positivo o negativo en los objetivos del proyecto.
Riesgo Residual / Residual Risk. Riesgo que permanece despus de haber implementado
las respuestas al riesgo.
Riesgo Secundario / Secondary Risk. Riesgo que se deriva directamente de la implementacin de una respuesta al riesgo.
Secuenciamiento de Actividades / Activity Sequencing. Identificacin y documentacin
de las relaciones lgicas de interaccin.
Seleccin de Proveedores / Source Selection. Seleccin entre los posibles contratistas.
Simulacin / Simulation. La simulacin utiliza un modelo de proyecto que convierte las incertidumbres especficas con un nivel detallado en el posible impacto que tendrn sobre los
objetivos expresados al nivel del proyecto en su totalidad. Las simulaciones del proyecto utilizan modelos informticos y clculos del riesgo a nivel detallado y, por lo general, se realizan utilizando la tcnica de Monte Carlo.
Software para la Direccin de Proyectos / Project Management Software. Tipo de aplicaciones informticas diseadas especficamente a ayudar con la planificacin y el control
de los costos y los planes del proyecto.
Solicitud de Cotizacin (RFQ) / Request for Quotation (RFQ). Expresin que por lo general es equivalente a solicitud de propuesta. Sin embargo, en algunas reas de aplicacin
puede tener un significado ms concreto o ms especfico.
Solicitud de Propuesta (RFP) / Request for Proposal (RFP). Tipo de documento de licitacin que se utiliza para solicitar propuestas de probables vendedores de productos o servicios. En algunas reas de aplicacin puede tener un significado ms concreto o ms
especfico.
Solucin Alternativa / Workaround. Respuesta a un evento de riesgo negativo. A diferencia
de la planificacin de contingencias, la solucin alternativa no se planifica con antelacin a
que se produzca el evento de riesgo.
Subproyecto / Subproject. Porcin ms pequea del proyecto total.
Subred / Subnet. Subdivisin de un diagrama de redes del proyecto que generalmente representa alguna forma de subproyecto.
Subsistema de red / Subnetwork. Vase subred.
Superposicin / Overlap. Vase adelanto.
Supervisin / Monitoring. Captacin, anlisis y elaboracin de informes del rendimiento del
proyecto, normalmente en comparacin con el plan.
Supervisin y Control de Riesgos / Risk Monitoring and Control. Supervisin de los
riesgos residuales, identificacin de nuevos riesgos mediante los planes de reduccin de
riesgos y evaluacin de su eficacia durante todo el ciclo de vida del proyecto.
Tarea / Task. Trmino genrico para aquel trabajo que no est incluido en la estructura detallada del trabajo, pero que potencialmente podra ser un trabajo adicional que detallaran las
personas responsables de esa labor. Tambin, el nivel de esfuerzo ms bajo de un proyecto.
Tcnica de Evaluacin y Revisin del Programa (PERT) / Program Evaluation and
Review Technique (PERT). Una tcnica de anlisis de redes orientada hacia los hechos o
eventos que se utiliza para estimar la duracin del programa cuando haya incertidumbre en
las estimaciones de la duracin de las actividades individuales. La tcnica PERT aplica el
mtodo del camino crtico que utiliza duraciones que se computan con una media ponderada de estimaciones de duracin optimistas, pesimistas y ms probables. La tcnica
PERT calcula la desviacin estndar de la fecha de conclusin a partir de aquellas duraciones de las actividades del camino. Se conoce tambin como Mtodo del anlisis de
momentos.
Tcnica de Evaluacin y Revisin Grfica (GERT) / Graphical Evaluation and Review
Technique (GERT). Tcnica de anlisis de redes que permite el tratamiento condicional y
probabilstico de las relaciones lgicas (es decir, es probable que algunas actividades no
se realicen).
Glosario
Tormenta de Ideas / Brainstorming. Tcnica de creatividad general que puede usarse

para identificar riesgos que usa a un grupo formado por los miembros del equipo o
especialistas en la materia. Generalmente, una sesin de tormenta de ideas consiste
en registrar las opiniones de cada participante para su posterior anlisis. Es una
herramienta del proceso de identificacin de riesgos.
Transferencia / Transference. Vase transferencia de riesgos.
Transferencia de Riesgos / Risk Transference. La transferencia de riesgos consiste
en pasar a terceros el impacto de un riesgo junto con la responsabilidad de la
respuesta.
Unidad de Calendario / Calendar Unit. La unidad de tiempo ms pequea utilizada
en la planificacin del proyecto. Generalmente, las unidades de calendario son horas,
das o semanas, pero tambin pueden ser turnos o minutos. Se utiliza principalmente
en relacin con el software para la direccin de proyectos.
Valor del Trabajo Realizado (EV) / Earned Value (EV). El presupuesto autorizado del
trabajo fsico realizado. La suma de los estimados de costos aprobados (puede
incluir la asignacin de gastos generales) para actividades (o partes de actividades)
finalizadas durante un perodo dado (generalmente de proyecto a la fecha). Antes se
denominaba costo presupuestado del trabajo realizado (BCWP) para una actividad
o grupo de actividades.
Valor Monetario Esperado / Expected Monetary Value. Producto de la probabilidad
de que ocurra un hecho y la ganancia o prdida que producir. Por ejemplo, si hay
un 50 por ciento de probabilidad de que llueva y la lluvia causar una prdida de 100
dlares, el valor monetario esperado del hecho de que llueva es de 50 dlares
(0,5 x $100).
Valor Planificado (PV) / Planned Value (PV). El presupuesto autorizado para realizar
el trabajo fsico planificado. Anteriormente, se denominaba costo presupuestado del
trabajo programado (BCWS en ingls).
Variacin del Costo (CV) / Cost Variance (CV). (1) Cualquier diferencia entre el costo
presupuestado de una actividad y su costo real. (2) En valor del trabajo realizado,
(CV = EV - AC).
Variacin de Tiempos (SV) / Schedule Variance (SV). (1) Toda diferencia entre la
finalizacin planificada de una actividad y la finalizacin real de esa actividad. (2) En
valor del trabajo realizado, (SV = EV - PV).
Vendedor / Seller. Proveedor de bienes o servicios a una organizacin.
Verificacin del Alcance / Scope Verification. Formalizacin de la aceptacin del
alcance del proyecto.
213
NDICE
del valor del trabajo realizado 123, 145, 199
matemtico 75-77, 199
Monte Carlo 44, 75, 199
rea de aplicacin 4, 13, 30, 43, 46, 51, 56,
62, 68-69, 78, 89, 98, 110-11, 125, 131, 147,
161, 181-82, 195, 199
Aseguramiento de la calidad (QA) 7, 35,
95, 97, 99, 101-02, 190, 196, 199
Asignacin del presupuesto de costos 7,
34, 83, 85, 89-90, 190, 199
Asignacin para contingencias 143, 199
A
AC Ver Costo Real
AD Ver Descripcin de la Actividad
ACWP Ver Costo Real del Trabajo Realizado
ADM Ver Mtodo de Diagramacin con Flechas
AF Ver Fecha de Finalizacin Real
AOA Ver Actividad en la Flecha
AON Ver Actividad en el Nodo
AS Ver Fecha de Inicio Real
A la fecha de 197
Accin correctiva 30, 46, 49, 63-64, 80-81,
91-93, 102-03, 144, 146, 197
Aceptacin del riesgo 143, 197
Acta Ver Acta del proyecto
Acta del proyecto 45, 54-55, 114, 129, 131,
183, 198
Actividad 14, 36, 47, 68-69, 71-75, 77-78, 8081, 87-88, 100-01, 103, 123, 170, 198
casi crtica 80, 198
crtica 76, 80, 198
en el nodo (AON) 69, 198
en la flecha (AOA) 70, 198
ficticia 198
predecesora 198
sucesora 74, 198
Adelanto 74, 119, 130, 134, 136, 138, 198
Administracin del contrato 8, 35, 147,
156-59, 191, 198
Agrupamiento de actividades 70,198
Alcance 19, 25, 27, 30, 32-33, 43-45, 59-63,
68, 89, 123, 131-32, 137, 142, 170-71, 197,
198
Alcance del producto 6, 41, 47, 51, 63, 198
Alcance del proyecto 6, 32, 36, 41-42, 47,
51, 55-56, 60-61, 63, 71, 75, 91, 96, 143, 147,
149, 189, 191, 198
Anlisis
cualitativo de riesgos 8, 34, 127, 133-37, 140,
191, 198
cuantitativo de riesgos 8, 34, 127, 130, 132,
134, 136-39, 141, 143, 191, 198
de la red 199
del rbol de decisiones 139, 199
del cronograma Ver Anlisis de Redes.
B
BAC Ver Presupuesto al Trmino
BCWP Ver Costo Presupuestado del Trabajo
Realizado
BCWS Ver Costo Presupuestado del Trabajo
Programado
Bsqueda de proveedores 8, 35, 147, 149,
151-54, 191, 199
C
CAP Ver Plan de Cuentas de Control
CCB Ver Comit de Control de Cambios
CPFF Ver Contrato de Costo ms Honorarios
Fijos
CPI Ver ndice de Rendimiento de Costos
CPIF Ver Contrato de Costo ms Honorarios con
Incentivos
CPM Ver Mtodo del Camino Crtico
CV Ver Variacin del Costo
Clculo de costos del ciclo de vida 83,
199
Cambio del alcance 29, 56. 62-63, 80, 92,
103, 124, 145, 199
Camino 139, 199
acelerado 12, 75, 199
crtico 9, 76-77, 80, 199
de red 199
Ciclo de vida del proyecto 6, 11-14, 30, 51,
57-58, 127, 130, 145, 169-70, 181, 191, 200
Cierre administrativo 8, 37, 117, 125, 15859, 191, 200
215
Cierre administrativo | Holgura
Index
Cierre del contrato 8, 37, 147, 149, 151, 15859, 191, 200
Cdigo de cuentas 200
Comit de control de cambios (CCB) 4849, 80, 91, 158, 200
Compresin 75, 200
Conclusin del contrato 8, 37, 147, 149,
151, 158-59, 191
Contingencias 45, 200
Contratacin de personal 7, 34, 46, 86,
107, 112-14, 190, 200
Contrato 6, 14, 25, 43-44, 47, 54-55, 57, 63,
74, 86, 120, 125, 150-51, 153-59, 169, 171,
173, 181, 200-01
de costo ms honorarios con incentivos (CPIF)
196, 201
de costo ms honorarios fijos (CPFF) 196, 201
por precio fijo 142, 152, 199, 201
por precio fijo absoluto (FFP) 196, 201
por precio fijo ms honorarios con incentivos
(FPIF) 196, 201
Control 11-12, 36, 42-43, 45-47, 49, 57, 59, 6263, 67, 79-80, 85, 88-89, 91, 102-03, 115, 124,
130, 144-45, 149, 157, 170, 201
de calidad (QC) 7, 36, 61-62, 91, 95, 99-104,
157, 190, 196, 201
de cambios integrado 7, 36, 41, 47-49, 63, 7980, 91, 102, 104, 146, 158, 189, 201
de costos 7, 36, 62, 83, 90-93, 190, 201
del cronograma 7, 36, 62, 65, 79-81, 91,
124, 190, 201
Convergencia de caminos 201
Costo
de la calidad 99, 201
presupuestado del trabajo programado (BCWS)
92, 123, 196, 201
presupuestado del Trabajo Realizado (BCWP)
92, 123, 196, 201
Real (AC) 88, 92, 123, 196, 201
Real del Trabajo Realizado (ACWP) 123, 196,
201
Cronograma 14, 25, 36-37, 43-47, 55-56, 61,
68, 73-81, 91, 97, 99-100, 115, 120, 122-23,
127, 129, 131, 133, 136-37, 142, 145, 150-51,
157, 183, 201-02
del proyecto 34, 36, 44-45, 65, 73-75, 77-81,
90, 96, 103, 139, 152, 190, 202
maestro 77, 202
planificado 81, 202
Cuantificacin de riesgos 92, 202
Curva S 90, 124, 170, 202
D
DD
DU
216
Ver Fecha de los Datos

Ver Duracin
Definicin de las actividades 7, 34, 65, 67,

71, 190, 202
Definicin del alcance 6-7, 34, 37, 51, 57,
59, 67, 85, 110, 149-50, 189, 202
Dependencia 74, 127, 202
Desarrollo
del cronograma 7, 34, 65, 71, 73-77, 190, 202
del equipo 7, 35, 44, 107, 114-16, 190, 202
del plan del proyecto 7, 34, 41-44, 77, 99, 111,
151, 189, 202
Descripcin de la actividad (AD) 196, 202
Desfase 26, 74, 202
Diagrama
de barras 78, 124, 198, 202
de Gantt 78, 124, 198, 202
de lgica 202
de Pareto 103, 202
de PERT 70, 202
de redes con escala de tiempo 202
de redes del proyecto 69-71, 74, 77, 197, 203
Diagramas de control 103, 203
Direccin de proyectos (PM) 3-4, 6-7, 9-12,
18, 21, 29, 32, 45-46, 55, 58, 96, 99, 102, 127,
132, 135, 147, 163, 167-71, 189-91, 197, 203
Director del proyecto (PM) 4, 16, 19-21, 24,
46, 54-55, 60-61, 96, 107, 110, 114-15, 130,
136, 144, 153, 156, 181, 197, 203
Distribucin de la informacin 8, 35, 98,
117, 121-23, 191, 203
Duracin (DU) 4-5, 44, 57-58, 71-73, 75-76,
78, 81, 86, 99, 138-39, 196, 203
Duracin restante (RDU) 197, 203
E
EAC Ver Estimacin al Trmino
EF Ver Fecha de Finalizacin Temprana
ES Ver Fecha de Inicio Temprana
ETC Ver Estimacin para Terminar
EV Ver Valor del Trabajo Realizado
EVM Ver Gestin del Valor del Trabajo Realizado
Ejecucin del plan del proyecto 7, 35, 41,
45-47, 55, 62, 123, 157, 189, 203
Enlace 12, 115, 203
Entregable 11-13, 34, 44-45, 47, 51, 55-58, 63,
65, 67-68, 74, 78, 85, 98, 100, 102, 123, 126,
147, 157, 189-90, 197, 200, 203
Enunciacin del alcance 34, 45, 51, 55-57,
60-62, 67, 86, 98, 149, 170, 189, 195, 203
Enunciacin del trabajo (SOW) 150-53,
156, 197, 203
Equipo de direccin del proyecto 3, 7, 11,
16, 18, 26-27, 37, 44, 46-47, 49, 67, 69, 74,
88, 92-93, 96-103, 107-10, 112-13, 115, 120,
123, 147, 149, 151, 157-58, 181, 203
Index
Esfuerzo 10, 13, 32, 37, 41, 44-45, 49, 51, 65,
67, 73, 83, 95, 104, 107, 117, 147, 149, 15354, 204
Estimacin
al trmino (EAC) 92-93, 196, 204
de costos 7, 34, 73, 83, 85-88, 190, 199, 204
definitiva 204
del orden de magnitud 201, 204
para terminar (ETC) 92, 196, 204
paramtrica 204
Estimado 34, 71-73, 75, 83, 86, 88-90, 92, 123,
138, 190, 204
Estructura detallada de la organizacin
(OBS) 61, 111, 196, 203
Estructura detallada del trabajo (WBS) 9,
42-43, 45, 57-63, 65, 67-68, 71, 75, 85-87, 89,
111, 129, 131, 133, 136, 138-39, 143, 150,
170, 181, 195, 197, 204
Evento de riesgo 46, 127, 134, 142, 204
Evento en el nodo 204
Evitacin del riesgo 142, 204
del camino 206

libre (FF) 196, 206
total (TF) 197, 206
Fragmento de red 70, 206
Fundamentos de la Direccin de
Proyectos (PMBOK) 3, 13, 19, 163, 169,
179, 181, 197, 206
G
GERT Ver Tcnica de Evaluacin y Revisin
Grfica
Gerente de lnea 206
Gerente funcional 4, 18, 25, 113-14, 206
Gestin
de costos del proyecto 7, 83, 171-72, 190, 195,
206
del proyecto (PM) 3-4, 6-7, 9-12, 18, 21, 29,
32, 45-46, 55, 58, 96, 99, 102, 127, 132,
135, 147, 163, 167-71, 189-91, 197, 206
de la calidad del proyecto 7, 95-96, 98, 171-72,
190, 195, 206
de la integracin del proyecto 7, 41, 170-71,
189, 206
de las adquisiciones del proyecto 8, 114, 147,
171-72, 191, 195, 206
de las comunicaciones del proyecto 7, 24-25,
117, 149, 171-72, 191, 195, 206
de los recursos humanos del proyecto 7, 107,
149, 170-72, 190, 195, 207
de riesgos del proyecto 8, 26, 72-73, 171-72,
191, 195, 207
de tiempos del proyecto 7, 65, 171-72, 190,
195, 206
del alcance del proyecto 7, 32, 51, 171-72, 189,
195, 207
del valor del trabajo realizado (EVM) 41-42, 44,
60, 91-92, 196, 207
por calidad total (TQM) 95, 97, 197, 207
Grado 96, 207
F
FF Ver Flotacin Libre o Final a Final
FFP Ver Precio Fijo Absoluto
FPIF Ver Precio Fijo ms Honorarios con Incentivos
FS Ver Final a Inicio
Fase 10-14, 20, 30, 32-33, 37, 51, 53-54, 57, 62,
70, 87, 108, 117, 125, 189, 191, 197, 204
Fase del proyecto 11-12, 32, 41, 51, 53-54,
62, 65, 77, 83, 95, 109, 117, 119, 170, 204
Fecha
de conclusin objetivo (TC) 37, 197, 204
de finalizacin 36, 45, 73, 75, 77, 80, 90, 205
de finalizacin actual 205
de finalizacin planificada (PF) 197, 205
de finalizacin programada (SF) 197, 205
de finalizacin objetivo (TF) 197, 205
de finalizacin real (AF) 196, 205
de finalizacin tarda (LF) 196, 198, 202, 205
de finalizacin temprana (EF) 196, 200-02, 205
de inicio 44, 200, 205
de inicio actual 205
de inicio objetivo (TS) 197, 205
de inicio planificada (PS) 197, 205
de inicio programada (SS) 197, 205
de inicio real (AS) 196, 205
de inicio tarda (LS) 196, 205
de inicio temprana (ES) 196, 205
de los datos (DD) 196, 205
Final a final (FF) 69, 196, 205
Final a inicio (FS) 69-70, 74, 196, 206
Flecha 206
Flotacin 75, 80, 206
H
Hito 13, 69, 78, 145, 207
Holgura 202, 207
I
IFB Ver Llamada a Licitacin
Identificacin de riesgos 8, 34, 37, 127,
130, 131, 132, 133, 137, 145, 146, 191, 207
ndice de rendimiento de costos (CPI)
92, 123, 196, 207
ndice de rendimiento de tiempos (SPI)
123, 197, 207
Informes del rendimiento 8, 36, 47, 117,
122-25, 151-52, 157-58, 191, 207
Informe por excepcin 195, 207
217
IFB | WBS
Index
Ingeniera del valor 56, 83, 197, 208

Iniciacin 7, 30, 32, 41, 44, 51, 53-54, 69, 136,
189, 208
Inicio a fin (SF) 69, 197, 208
Inicio a inicio (SS) 69, 197, 208
Interesados(as) 6, 11-12, 16-18, 24, 32, 3435, 41, 43-44, 49, 54, 56, 61, 63, 74, 80, 9192, 107-08, 114-15, 119-22, 124, 129-32, 147,
169, 208
Interrupcin lgica 208
L
LF Ver Fecha de Finalizacin Tarda
LOE Ver Nivel de Esfuerzo
LS Ver Fecha de Inicio Tarda
Lazo 46, 208
Llamada a licitacin (IFB) 153, 196, 208
Lgica 11, 15, 68-69, 75, 77, 138, 208
Lgica de redes 69-70, 75, 198, 201, 203,
208
M
MPM Ver Direccin Moderna de Proyectos
Matriz
de asignacin de responsabilidades (RAM) 110,
197, 208
de probabilidades e impacto 208
Medicin del rendimiento tcnico 145,
208
Mtodo
de diagramacin con flechas (ADM) 70, 196,
208
de diagramacin por precedencia (PDM) 69-70,
139, 196, 209
del camino crtico (CPM) 26, 75, 196, 209
Miembros del equipo 4, 16, 20, 24, 68, 72,
74, 87, 111, 114-16, 121-22, 130, 209
Miembros del equipo del proyecto 4, 16,
68, 111, 114-16, 122, 209
Mitigacin 142-43, 209
Mitigacin de riesgos 143, 203, 209
Modificacin del alcance 29, 56, 62-63, 80,
92, 103, 124, 145, 209
N
Nivel de esfuerzo (LOE) 196, 202, 209
Nivelacin 209
Nivelacin de recursos 76, 77, 78, 202, 209
Nodo 69-70, 209
O
OBS Ver Estructura Detallada de la Organizacin
Organizacin
218
ejecutante 4, 8, 10-12, 16, 19, 25-26, 41, 44,

49, 53-54, 64, 81, 86-87, 93, 97-98, 101,
110, 113-16, 147, 149-51, 158-59, 170,
191, 209
funcional 19-20, 170, 209
proyectizada 20-21, 209
P
PC Ver Porcentaje Terminado
PDM Ver Mtodo de Diagramacin por
Precedencia
PERT Ver Tcnica de Evaluacin y Revisin del
Programa
PF Ver Fecha de Finalizacin Planificada
PM Ver Direccin de Proyectos y Director del
Proyecto
PMBOK Ver Fundamentos de la Direccin de
Proyectos (PMBOK )
PMP Ver Profesional en la Direccin de
Proyectos
PS Ver Fecha de Inicio Planificada
PV Ver Valor Planificado
Paquete de trabajo 34, 47, 60-61, 67, 88-90,
111, 195, 198, 203, 209
Plan
de cuentas 87, 209
de cuentas de control (CAP) 42, 92, 196, 209
de gestin de riesgos 8, 34, 45-46, 74, 90,
127, 129-31, 134, 138, 140, 145, 191, 210
de referencia 43, 45-49, 57, 63-64, 72, 122,
139, 145, 168, 210
de referencia del alcance 63, 210
de referencia para la medicin del rendimiento
44-47, 210
de respuesta a riesgos 8, 34, 45, 88, 127, 130,
134, 140-41, 143, 145-46, 191, 210
del proyecto 26, 30, 32-33, 35, 41-46, 48-49,
51, 57, 61-62, 64, 78-81 89, 92, 99, 103,
111, 115, 121-23, 132, 134, 142-46, 151,
158, 189, 210
Planificacin
de contingencias 210
de la bsqueda de proveedores 8, 35, 147,
149, 151-54, 191, 205, 210
de la calidad 7, 34, 95, 97-99, 101, 190, 210
de la gestin de riesgos 8, 34, 45, 46, 74, 90,
127, 129-31, 134, 138, 140, 145, 191, 210
de la organizacin 7, 19, 34, 107-11, 119, 190,
210
de la respuesta a riesgos 8, 34, 45, 88, 127,
130, 134, 140-41, 143, 145-46, 191, 210
de las adquisiciones 8, 35, 98, 147, 149-52,
159, 191, 210
de las comunicaciones 8, 34, 109, 117, 119,
120, 191, 210
de recursos 7, 34, 46, 83, 85, 86, 109, 190, 210
del alcance 7, 34, 51, 55-56, 189, 206, 210
Index
del proyecto 33, 34, 36, 43-45, 53, 55, 97, 131,
158, 210
Porcentaje terminado (PC) 122, 196, 210
Presupuesto al trmino (BAC) 92, 196, 211
Presupuesto estimado 211
Profesional en la Direccin de Proyectos
(PMP) 4, 153, 156, 168, 175, 197, 211
Programa 10, 70, 74, 146, 168, 204, 207, 211
T
TC Ver Fecha de Conclusin Objetivo
TF Ver Flotacin Total y Fecha de Finalizacin
Objetivo
TS Ver Fecha de Inicio Objetivo
TQM Ver Gestin por Calidad Total
Tarea 101, 127, 195, 212
Tcnica de Evaluacin y Revisin del
Programa (PERT) 70, 75, 196, 212
Tcnica de Evaluacin y Revisin Grfica
(GERT) 70, 75, 196, 212
Transferencia de riesgos 213
Q
QA
QC
Ver Aseguramiento de la Calidad

Ver Control de Calidad
U
RAM Ver Matriz de Asignacin de
Responsabilidades
RDU Ver Duracin Restante
RFP Ver Solicitud de Propuesta
RFQ Ver Solicitud de Cotizacin
Recorrido hacia adelante 211
Recorrido hacia atrs 211
Red 70, 75, 170, 211
Relacin de precedencia 69, 211
Relacin lgica 69, 200-04, 211
Reserva 73, 78, 88, 137, 143-44, 198-99, 211
Reserva para contingencias 78, 137, 144,
211
S
SF Ver Fecha de Finalizacin Planificada e Inicio a
Fin
SOW Ver Enunciacin del Trabajo
SPI Ver ndice de Rendimiento de Tiempos (SPI)
SS Ver Fecha de Inicio Programada e Inicio a Inicio
SV Ver Variacin de Tiempos
Secuenciamiento de las actividades 7,
34, 49, 65, 68-70, 190, 212
Seleccin de proveedores 8, 35, 147, 153,
155-56, 191, 212
Software para la direccin de proyectos
42, 44, 68-69, 74, 76, 80, 86, 88, 92, 121, 212
Solicitud de cotizacin (RFQ) 153, 197, 212
Solicitud de propuesta (RFP) 153, 197, 212
Solucin alternativa 63, 146, 212
Subred 70, 212
Subsistema de red 70, 212
Superposicin 4, 9, 16, 30, 41, 51, 65, 83, 95,
107, 117, 127, 147, 212
Supervisin 30, 36, 80, 91, 95, 102, 127, 130,
144-45, 190-91, 212
Supervisin y control de riesgos 8, 36,
127, 144, 145, 146, 191, 206, 207, 212
Unidad de calendario 213
V
VE Ver Ingeniera del Valor
Valor
del trabajo realizado (EV) 41, 49, 92, 123-24,
145, 196, 213
monetario esperado 75, 213
planificado (PV) 92, 123, 197, 213
Variacin del costo (CV) 89, 91-92, 123,
196, 213
Variacin de tiempos (SV) 92, 103, 123,
197, 213
Verificacin del alcance 7, 36, 51, 61-62,
189, 213
W
WBS Ver Estructura Detallada del Trabajo (WBS)
9, 42-43, 45, 57-63, 65, 67-68, 71, 75, 85-87,
89, 111, 129, 131, 133, 136, 138-39, 143, 150,
170, 181, 195, 197, 204
219
12/17/02
2:31 PM
Page 2
Acerca del Project Management Institute

Desde su fundacin en 1969, el Project Management Institute (PMI) se ha convertido en la organizacin preferida por
todas aquellas personas quienes, alrededor del mundo, trabajan o estn interesadas en Direccin de Proyectos. De
hecho, el PMI es el lder mundial en asociaciones profesionales sin fines de lucro en el rea de Direccin de Proyectos.
A continuacin se indican algunos programas, productos y servicios ofrecidos por el PMI:
Estndares
El PMI desarrolla estndares para la profesin de Direccin de Proyectos, que son valorados por los miembros del
mismo, por el mercado y por otros interesados en proyectos. El documento estndar ms relevante del PMI, Una Gua
a los Fundamentos de la Direccin de Proyectos (PMBOK Guide) es de hecho, en el actual mercado globalizado, el
estndar internacional que brinda los conocimientos y las prcticas necesarios para la Direccin de Proyectos. El PMI
est comprometido con la mejora continua y la expansin del PMBOK Guide, as como con el desarrollo de estndares adicionales.
Certificacin
Desde 1984, el PMI se ha dedicado al desarrollo y mantenimiento de un programa de certificacin profesional, basado
en un riguroso examen, con el objeto de promover la profesin de Direccin de Proyectos y de reconocer los logros
individuales de los profesionales. La certificacin del PMI como Profesional de Direccin de Proyectos (PMP) es la
credencial profesional de mayor reconocimiento mundial para quienes trabajan en Direccin de Proyectos y otros
involucrados en la materia. El PMI ofrece tambin la certificacin de Asociado Certificado en Direccin de Proyectos
(CAPMTM) y las certificaciones de Calificacin Certificada Adicional (CAQTM) en Desarrollo de Productos de la Industria Automotriz, en Proyectos de Bienes de Capital, en Proyectos de Tecnologa de Redes de Informacin, en Proyectos
de Sistemas de Tecnologa de la Informacin (STI) y en Oficina de Direccin de Proyectos (ODP). En 1999, el Departamento de Programas de Certificacin del PMI se constituy en el primer departamento en el mundo, en su tipo, en
obtener la certificacin ISO 9001.
Investigacin
El PMI est abocado a la expansin de los Fundamentos de la Profesin de Direccin de Proyectos. Con este
propsito, se analizan las necesidades profesionales a travs de evaluaciones peridicas y de otros mtodos afines. La
investigacin en Direccin de Proyectos se fomenta a travs de: un foro de investigacin que se realiza cada dos aos,
subvenciones externas para la investigacin, una base de datos de las investigaciones llevadas a cabo y la identificacin de tpicos a investigar. La informacin, la experiencia y los conocimientos actuales de la profesin son
recogidos y diseminados. Asimismo se evala el futuro de la profesin.
Publicaciones
Las ediciones mensuales de la revista profesional del PMI, PM Network, as como del boletn informativo, PMI Today,
mantienen a los miembros del PMI informados sobre las novedades de la institucin, as como tambin sobre lo nuevo
en software, sobre las nuevas tcnicas de Direccin de Proyectos, los prximos eventos, las mejores prcticas y las
lecciones aprendidas de proyectos actuales. El PMI tambin publica trimestralmente el Project Management Journal,
publicacin acadmica lder en tcnicas, investigaciones, teoras y aplicaciones de vanguardia, de la Direccin de
Proyectos. Adicionalmente, el PMI es lder, a nivel mundial, en la publicacin de libros profesionales de Direccin de
Proyectos, medios de capacitacin y herramientas de entrenamiento. Existen cientos de ttulos disponibles en la librera virtual del PMI, en www.pmibookstore.org
Educacin
El PMI brinda su apoyo a una amplia variedad de actividades educativas. El Programa Mundial de Seminarios del PMI
es una muestra de excelencia tanto en contenidos como en instruccin de Direccin de Proyectos. Estos seminarios
se ofrecen durante todo el ao en diversas ciudades del mundo. El PMI tambin reconoce la importancia de la acreditacin acadmica para el progreso de la profesin de Direccin de Proyectos. Por lo tanto, el PMI pone a disposicin
de escuelas calificadas y dems organizaciones la acreditacin para ttulos terciarios y la aprobacin de programas de
postgrados en la disciplina de Direccin de Proyectos. El programa del PMI como Proveedor de Servicios de Educacin Registrado (R.E.P.) brinda acceso a aproximadamente 800 proveedores calificados de actividades de desarrollo
profesional y de productos de aprendizaje en Direccin de Proyectos. Todos estos R.E.P. adhieren a criterios
preestablecidos por el PMI, para el desarrollo apropiado de sus actividades de capacitacin y desarrollo.
Membresa
El PMI es una organizacin de miembros individuales. Los miembros del PMI disponen de una amplia gama de beneficios entre los que se incluyen publicaciones peridicas de alta calidad y descuentos en seminarios educativos y en
libros. Para hallar ms informacin acerca de la membresa en el PMI o bien sobre todos los programas, productos
y servicios ofrecidos por el PMI, visite la pgina Web del PMI en www.pmi.org o contacte al Servicio al Cliente del
PMI para obtener un paquete de informacin al +610-356-4600 o en pmihq@pmi.org.
12/17/02
2:31 PM
Page 1
PMBOK Guide, Edicin 2000

ISBN: 1-930699-18-2

Newtown Square, PA 19073-3299 USA
www.pmi.org
US $35.95

Pmbook Adm Proy.

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Pmbook Adm Proy.

Enviado por

Direitos autorais:

Formatos disponíveis

pmbok-spain_cover-r1

Una Gua a los

PROJECT MANAGEMENT INSTITUTE

Una Gua a los

un Estndar Nacional Americano

Una Gua a los

Project Management Institute

Publicado por: Project Management Institute, Inc.

SECCIN IMARCO CONCEPTUAL DE LA

SECCIN IIREAS DE CONOCIMIENTO DE LA

SECCIN IIIAPNDICES -------------------------------------------------------Apndice AProceso de Establecimiento de Estndares del

SECCIN IVGLOSARIO E NDICE ------------------------------------------- 193

Visin General de las reas de Conocimiento y de

Prlogo de la Edicin 2000

Captulo 4 (Gestin de la Integracin del Proyecto)

1.1 PROPSITO DE ESTA GUA

Producto, Servicio o Resultado nico

1.3 QU ES LA DIRECCIN DE PROYECTOS?

Marco Conceptual de la Direccin de Proyectos

reas de Conocimiento de la Direccin de Proyectos

Figura 12. Relacin de la Direccin de Proyectos con Otras Disciplinas de Direccin

1.4 RELACIN CON OTRAS DISCIPLINAS DE DIRECCIN

1.5 EMPRENDIMIENTOS RELACIONADOS

2.1 FASES DEL PROYECTO Y CICLO DE VIDA DEL PROYECTO

Caractersticas de las Fases del Proyecto

Captulo 2 El Contexto de la Direccin de Proyectos

Caractersticas del Ciclo de Vida del Proyecto

Captulo 2 El Contexto de la Direccin de Proyectos

Figura 21. Ejemplo de un Ciclo de Vida Genrico

Ciclos de Vida Representativos de Proyectos

Captulo 2 El Contexto de la Direccin de Proyectos

Ciclo de Vida Representativo de Adquisiciones de Defensa, segn US DODI 5000.2

Captulo 2 El Contexto de la Direccin de Proyectos

Figura 23. Ciclo de Vida Representativo de un Proyecto de Construccin, segn Morris

Figura 2-4 | Figura 25

Captulo 2 El Contexto de la Direccin de Proyectos

Figura 24. Ciclo de Vida Representativo de un Proyecto Farmacutico, segn Murphy

Captulo 2 El Contexto de la Direccin de Proyectos

Captulo 2 El Contexto de la Direccin de Proyectos

El vicepresidente de investigacin de una empresa de electrnica puede definir el xito de

2.3 INFLUENCIAS DE LA ORGANIZACIN

Captulo 2 El Contexto de la Direccin de Proyectos

Figura 26. Influencia de la Estructura de la Organizacin en los Proyectos

Culturas y Estilos Organizacionales

Captulo 2 El Contexto de la Direccin de Proyectos

Figura 27. Organizacin Funcional

Captulo 2 El Contexto de la Direccin de Proyectos

Figura 28. Organizacin Proyectizada

2.4 HABILIDADES CLAVE DE DIRECCIN EN GENERAL

Figura 29 | Figura 212

Captulo 2 El Contexto de la Direccin de Proyectos

Figura 29. Organizacin Matricial Dbil

Figura 210. Organizacin Matricial Balanceada

Captulo 2 El Contexto de la Direccin de Proyectos

Figura 211. Organizacin Matricial Fuerte

Figura 212. Organizacin Combinada

Captulo 2 El Contexto de la Direccin de Proyectos

Captulo 2 El Contexto de la Direccin de Proyectos

Captulo 2 El Contexto de la Direccin de Proyectos

2.5 INFLUENCIAS SOCIALES, ECONMICAS Y AMBIENTALES

Captulo 2 El Contexto de la Direccin de Proyectos

Sustentabilidad Social, Econmica y Ambiental

3.1 PROCESOS DEL PROYECTO

Captulo 3 Procesos de la Direccin de Proyectos