Guía Fundamental

Traducido al Español por Aserpro LTDA.

a20017153@pucp.edu.pe http://blog.pucp.edu.pe/gestionpucp
SUBGERENCIA DE PROYECTOS -DEPTO. NORMAS, PROCEDIMIENTOS & CALIDAD
1. 1. Introducción
2. 2. El Contexto de la Gestión de Proyectos
3. 3. Los Procesos de la Gestión de Proyectos

Project Management Body of Knowledge (PMBOK®) es un término integral que

describe la suma de conocimiento dentro de la profesión de gestión de proyectos.
Al igual de lo que sucede con otras profesiones como leyes, medicina y
contabilidad, lo medular del conocimiento está en quienes lo practican y en los
académicos que lo aplican y los hacen progresar. La estructura de conocimiento
completa de la gestión de proyectos incluye el estudio de probadas prácticas
tradicionales que se aplican bastamente, como así mismo el conocimiento de
innovadoras y avanzadas prácticas que han sido objeto de un uso más limitado, e
incluye tanto material publicado como inédito.

Este capítulo define y explica varios términos claves y da una reseña del resto del
documento. Este capítulo incluye las siguientes secciones principales:

1. 1.1 Propósito de Esta Guía

2. 1.2 ¿Qué es un Proyecto?
3. 1.3 ¿En Qué Consiste la Gestión de Proyectos?
4. 1.4 Relación con Otras Disciplinas de la Gestión
5. 1.5 Temas Relacionados

1.1 PROPÓSITO DE ESTA GUÍA

La gestión de proyectos es una profesión emergente. El principal propósito de este

documento es el de identificar y describir aquel subconjunto del PMBOK® que
está generalmente aceptado. Generalmente aceptado quiere decir que el
conocimiento y las prácticas descritas son aplicables a la mayoría de los proyectos
la mayor de las veces, y que existe un amplio consenso acerca de su valor y
utilidad. Generalmente aceptado no significa que el conocimiento y las prácticas
descritas son o deben ser aplicadas en forma uniforme a todos los proyectos; el
equipo de gestión de proyectos es siempre el responsable de determinar lo que es
adecuado para un determinado proyecto.

Este documento tiene como finalidad, además, la de proveer un léxico común

dentro de la profesión y de la práctica para conversar y escribir acerca de la
gestión de proyectos. La gestión de proyectos es una profesión relativamente
joven y, aunque existe mucho de común en lo que se hace, hay muy poca similitud
en los términos empleados.
Este documento establece una referencia básica para todo aquel interesado en la
profesión de gestión de proyectos. Esto incluye, pero sin limitarse a:

. Ejecutivos sénior
. Gerentes de gerentes de proyectos
. Gerentes de proyectos y otros miembros del equipo de proyectos
. Clientes de proyectos y otros usuarios de proyectos
. Gerentes funcionales con empleados asignados a equipos de
proyectos
. Educadores dedicados a la docencia en gestión de proyectos y
temas relacionados
. Consultores y otros especialistas en gestión de proyectos y áreas
relacionadas
. Instructores que desarrollan programas educacionales en gestión de
proyectos.

A modo de referencia básica, este documento no es ni extensivo ni del todo

intensivo. El Apéndice E contiene detalles de las extensiones de las áreas de
aplicación, mientras que el Apéndice F lista las fuentes de donde es posible
obtener más información sobre la gestión de proyectos.

Este documento es utilizado, además, por el Instituto de Gestión de Proyectos,

PMI, como referencia fundamental acerca del conocimiento y de las prácticas de la
gestión de proyectos para sus programas de desarrollo profesional que incluyen:

. Certificación de Profesionales en Gestión de Proyectos (PMP®.

. Acreditación de programas educacionales en gestión de proyectos.
1.2 ¿QUÉ ES UN PROYECTO?

Las organizaciones ejecutan el trabajo. El trabajo implica generalmente ya sea

operaciones o proyectos, aunque los dos pueden traslaparse. Las operaciones y
los proyectos tienen muchas características en común; por ejemplo, son:

. Ejecutados por personas.

. Restringidos por recursos limitados.
. Planificados, ejecutados y controlados.

A menudo, se implementan proyectos como una forma de lograr el plan

estratégico de una organización. Las operaciones y los proyectos se diferencian,
principalmente, en el hecho de que las operaciones son continuas y repetitivas,
mientras que los proyectos son temporales y únicos. Así, es posible definir un
proyecto en términos de sus características distintivas – un proyecto es una
empresa temporal que se asume con el fin de crear un producto o servicio único.
Temporal quiere decir que cada proyecto tiene un comienzo y un término
definitivos. Único quiere decir que el producto o servicio es distintivamente
diferente de todos los demás productos o servicios. Para muchas organizaciones,
los proyectos son una forma de responder a aquellas solicitudes que no se pueden
abordar dentro de los límites operacionales normales de la organización.

Los proyectos se llevan a cabo a todo nivel de la organización. Estos pueden

involucrar a una sola persona o bien a varios miles de individuos. Su duración va
de unas cuantas semanas a más de cinco años. Los proyectos pueden involucrar
a una sola unidad de una organización o bien pueden traspasar las fronteras
organizacionales, en la forma de sociedades contractuales (joint ventures) y
sociedades. Los proyectos son críticos para el cumplimiento de la estrategia de
negocios de la organización que los ejecuta, debido a que los proyectos son una
forma de implementar la estrategia. Entre los ejemplos de proyectos se cuentan:

. Desarrollo de un nuevo producto o servicio

. Realización de un cambio en la estructura, dotación o estilo de una
organización
. Diseño de un nuevo vehículo de transporte
. Desarrollo o adquisición de un sistema de información nuevo o
modificado
. Construcción de un edificio o de una planta
. Construcción de un sistema de agua potable para una comunidad de
un país en vías de desarrollo
. Realización de una campaña para un fin político
. Implementación de un nuevo procedimiento o proceso.

1.2.1 Temporal
Temporal quiere decir que todo proyecto tiene un comienzo y un término
definitivos. Llega a término cuando se han logrado los objetivos del proyecto, o
cuando se hace evidente que no será posible cumplir o no se pueden cumplir los
objetivos del proyecto, o cuando ya no existe la necesidad del proyecto y se
termina el proyecto. Temporal no necesariamente significa de corta duración; son
muchos los proyectos que duran por varios años. Sin embargo, cualquiera sea el
caso, la duración de un proyecto es finita; los proyectos no son esfuerzos
continuos.

Además, el concepto de temporalidad no se aplica generalmente al producto o

servicio creado por el proyecto. Los proyectos pueden tener, a menudo, impactos
sociales, económicos y ambientales intencionales o no intencionales cuya
proyección puede ir más allá que los mismos proyectos. La mayor parte de los
proyectos se llevan a cabo con el objeto de crear un resultado de larga duración.
Por ejemplo, un proyecto para erigir un monumento nacional creará un resultado
que se espera dure por siglos. Para lograr un objetivo estratégico, podría ser
necesario que hubiera en paralelo una serie de proyectos y / o proyectos
complementarios.

Los objetivos de los proyectos y de las operaciones son fundamentalmente

diferentes. El objetivo de un proyecto es el de lograr el objetivo y cerrar el
proyecto. El objetivo de una operación continua no-proyectada es, normalmente,
la de sostener el negocio. Los proyectos son fundamentalmente diferentes debido
a que el proyecto se da por terminado una vez que han logrado sus objetivos
declarados; mientras que un quehacer que no se ha proyectado adopta un nuevo
conjunto de objetivos y continúa trabajando.

La naturaleza temporal de los proyectos es aplicable a otros aspectos del

quehacer también:

La oportunidad o ventana de mercado es generalmente temporal -la

mayoría de los proyectos tienen un marco de tiempo limitado en el que
deben producir su producto o servicio.
El equipo de proyectos, como equipo, rara vez tiene mayor prolongación –
la mayoría de los proyectos son ejecutados por un equipo creado para el
solo propósito de llevara cabo el proyecto, desmembrándose el equipo
cuando se de por terminado el proyecto.

1.2.2 Producto, Servicio o Resultados Únicos

Los proyectos involucran realizar algo que no ha sido hecho antes y que, por lo
tanto, es único. Un producto o servicio pueden ser únicos incluso si fuera grande
la categoría a la cual pertenece. Por ejemplo, se han desarrollado varios miles de
edificios de oficina, pero cada instalación individual es única – diferente dueño,
diferente diseño, diferente ubicación, etc. La presencia de elementos repetitivos
no cambia en absoluto el carácter único fundamental del trabajo del proyecto. Por
ejemplo:

. Un proyecto para desarrollar un nuevo avión comercial puede

requerir de múltiples prototipos.
. El proyecto para poner en el mercado una nueva droga puede
requerir miles de dosis de la droga para que sirvan de apoyo en las pruebas
clínicas.
. Un proyecto de desarrollo de bienes raíces puede incluir cientos de
unidades individuales.
. Se puede implementar un proyecto de desarrollo (por ejemplo, agua
y sanidad) en cinco áreas geográficas

1.2.3 Elaboración Progresiva

La elaboración progresiva es una característica de los proyectos, e integra los

conceptos de temporal y único. Dado que el producto de cada proyecto es único,
las características que distinguen el producto o servicio deben ir elaborándose
lentamente. Progresivamente significa “proceder en pasos; continuando
uniformente en incrementos”, mientras que elaborado significa “trabajado con
cuidado y detalle; desarrollado meticulosamente” (1). Estas características
distintivas serán definidas ampliamente al comienzo del proyecto, y se harán más
explícitas y detalladas a medida que el equipo del proyecto desarrolle una
comprensión mejor y más clara del producto.

La elaboración progresiva de las características del producto debe coordinarse

cuidadosamente con la definición adecuada del alcance del proyecto,
especialmente si el proyecto se ejecuta por medio de un contrato. Una vez
definido adecuadamente, el alcance del proyecto – el trabajo a realizar – debe
permanecer constante incluso a medida que se vayan elaborando
progresivamente las características del producto. La relación entre alcance del
producto y alcance del proyecto se analizan con mayor profundidad en la
introducción al Capítulo 5.

Los siguientes dos ejemplos ilustran la elaboración progresiva en dos áreas de

aplicaciones diferentes.

Ejemplo 1. El desarrollo de una planta de procesamiento químico comienza con la

ingeniería de procesos a fin de definir las características del proceso. Estas
características se utilizan para diseñar las principales unidades de procesamiento.
Esta información pasa a ser la base para el diseño de ingeniería, que define tanto
el despliegue detallado de la planta como las características mecánicas de las
unidades de proceso y de las instalaciones auxiliares. Todo esto tiene como
resultado los planos de diseño que se elaborar con el objeto de producir los planos
de fabricación (isométrica de la construcción). Durante la construcción, se realizan
las interpretaciones y adaptaciones que sean necesarias y se someten a la
aprobación correspondiente. Esta mayor elaboración de las características es
capturada por los planos as-built. Durante la etapa de prueba y de marcha blanca,
a menudo se realiza una mayor elaboración de las características en forma de
ajustes finales a la operación.

Ejemplo 2. El producto de un proyecto de desarrollo económico puede definirse

inicialmente como: “Mejorar la calidad de vida de los residentes de menores
ingresos de la comunidad X”. A medida que el proyecto avanza, se pueden ir
describiendo los productos de manera más específica, como por ejemplo: “Brindar
acceso a alimentación y agua a 500 residentes de bajos ingresos de la comunidad
X”. La siguiente etapa de elaboración progresiva podría enfocarse exclusivamente
a aumentar la producción agrícola y el mercadeo, considerándose la provisión de
agua como de segunda prioridad, la cual se iniciaría una vez que el componente
agricultura este bien avanzado.

1.3 ¿EN QUÉ CONSISTE LA GESTIÓN DE PROYECTOS?

La gestión de proyectos es la aplicación del conocimiento, habilidades,

herramientas y técnicas a las actividades del proyecto de forma tal de cumplir con
los requerimientos del proyecto. La gestión de proyectos se lleva a cabo mediante
el uso de procesos tales como: iniciación, planificación, ejecución, control y
término. El equipo del proyecto gestiona el trabajo de los proyectos, trabajo que
comúnmente implica:

Distintas demandas de: alcance, tiempo, costo, riesgo y

calidad. Clientes con diferentes necesidades y expectativas.
Requerimientos identificados.

Es importante hacer notar que muchos de los procesos contenidos dentro de la

gestión de proyectos son iterativos por naturaleza. Esto se debe, en parte, a la
existencia de y a la necesidad de una elaboración progresiva de un proyecto
durante toda su ciclo de vida; es decir, mientras más sabe usted acerca de su
proyecto, mejor será su capacidad para manejarlo.

El término gestión de proyectos se utiliza a veces para describir un enfoque

organizacional para el manejo o administración de operaciones continuas. Este
enfoque, más correctamente llamado gestión por proyectos, trata los diversos
aspectos de las operaciones continuas como proyectos de forma tal de aplicar a
estos las técnicas de gestión de proyectos. Aunque contar con una comprensión
de la gestión de proyectos es un aspecto crítico para aquella organización que
realiza la gestión por proyectos, no está dentro del alcance de este documento
referirse detalladamente al enfoque en sí.

El conocimiento respecto de la gestión de proyectos se puede organizar de

distintas maneras. Este documento cuenta con dos secciones importantes y doce
capítulos, como se describen a continuación.

1.3.1 La Estructura de la Gestión de Proyectos

La Sección 1, Estructura de la Gestión de Proyectos, establece una estructura

básica para la comprensión de la gestión de proyectos.

El Capítulo 1, Introducción, define los términos claves y entrega una reseña del
resto del documento.

El Capítulo 2, El Contexto de la Gestión de Proyectos, describe el ambiente en

que operan los proyectos. El equipo de gestión de proyectos debe entender este
contexto más amplio –la gestión de las actividades diarias del proyecto es algo
necesario para el éxito, pero no suficiente.

El Capítulo 3, Los Procesos de la Gestión de Proyectos, describe una visión

generalizada de cómo interactúan comúnmente los distintos procesos de la
gestión de proyectos. El entendimiento de estas interacciones es esencial para
comprender el material que se presenta en el resto de los Capítulo, del 4 al 12.
1.3.2 Las Áreas de Conocimiento de la Gestión de Proyectos

La Sección II, las Áreas de Conocimiento de la Gestión de Proyectos, describe el

conocimiento y la práctica de la gestión de proyectos en términos de sus procesos
integrados. Estos procesos se han organizado en nueve áreas de conocimiento,
como se describe más abajo y se ilustran en la Figura 1-1.

El Capítulo 4, Gestión de Integración de Proyectos, describe los procesos

requeridos para asegurar que se coordinen adecuadamente los distintos
elementos del proyecto. Esta consiste en el desarrollo de un plan de proyecto, la
ejecución del plan de proyecto y en el control integrado de cambios.

El Capítulo 5, Gestión del Alcance del Proyecto, describe los procesos

requeridos para asegurar que el proyecto incluya todo el trabajo requerido, y sólo
el trabajo requerido, a fin de completar el proyecto exitosamente. Esta consiste en
la iniciación, planificación del alcance, definición del alcance, verificación del
alcance y control de cambios en el alcance.

El Capítulo 6, Gestión de Duración (Tiempo) del Proyecto, describe los

procesos requeridos para asegurar el término a tiempo del proyecto. Esta consiste
en la definición de las actividades, la secuencia de las actividades, estimación de
la duración de las actividades, desarrollo del programa y control del programa.

El Capítulo 7, Gestión de Costos del Proyecto, describe los procesos requeridos

para asegurar la ejecución total del proyecto dentro del presupuesto aprobado.
Esta consiste en la planificación de los recursos, estimación de los costos,
preparación de presupuestos de costos y control de costos.

El Capítulo 8, Gestión de Calidad del Proyecto, describe los procesos

requeridos para asegurarse de que el proyecto satisfará las necesidades para las
cuales fue ejecutado. Esta consiste en la planificación de la calidad,
aseguramiento de la calidad y control de calidad.

El Capítulo 9, Gestión de Recursos Humanos del Proyecto, describe los

procesos requeridos para realizar un uso más eficiente y eficaz de las personas
involucradas con el proyecto. Esta consiste en la planificación organizacional, la
adquisición de personal, y en el desarrollo del equipo.

El Capítulo 10, Gestión de Comunicaciones del Proyecto, describe los procesos

requeridos para asegurar la generación, recopilación, diseminación,
almacenamiento y disposición final de la información del proyecto en forma
adecuada y a tiempo. Esta consiste en la planificación de las comunicaciones,
distribución de la información, reporte del rendimiento / desempeño y cierre
administrativo.

El Capítulo 11, Gestión de Riesgos del Proyecto, describe los procesos que
tienen que ver con la identificación, análisis y respuesta al riesgo del proyecto.
Esta consiste en la planificación de la gestión de riesgos, identificación de los
riesgos, análisis cualitativo de los riesgos, análisis cuantitativo de los riesgos,
planificación de las respuestas a los riesgos, y monitoreo y control de los riesgos.

El Capítulo 12, Gestión de Abastecimiento de Proyectos, describe los procesos

requeridos para adquirir bienes y servicios desde fuera de la organización
ejecutante. Esta consiste en la planificación de la adquisición, planificación del
requerimiento, requisición, selección de la fuente, administración del contrato y
término del contrato.
1.4 RELACIÓN CON OTRAS DISCIPLINAS DE GESTIÓN

Gran parte del conocimiento necesario para gestionar los proyectos es único a la
gestión de proyectos (por ejemplo, el análisis de trayectorias críticas y las
estructuras de división del trabajo). Sin embargo, la PMBOK® se traslapa con
otras disciplinas de gestión, tal como se ilustra en la Figura 1-2.

La gestión general conlleva la planificación, organización, dotación, ejecución y el

control de las operaciones de una empresa continua. La gestión general también
incluye a las disciplinas de apoyo como son la gestión legal, la planificación
estratégica, la logística y la gestión de recursos humanos. La PMBOK® se
traslapa con o modifica la gestión general en muchas áreas – técnicas de
comportamiento organizacional, de predicción financiera y planificación, por
nombrar algunas. La Sección 2.4 analiza en forma más detallada la gestión
general.

Las áreas de aplicación son las categorías de los proyectos que tienen elementos
comunes que son significativos en dichos proyectos, pero que no son necesario o
no están presentes en todos los proyectos. Las áreas de aplicación se definen,
generalmente, en términos de:

. Departamentos funcionales y disciplinas de apoyo, como son los

aspectos legales, la gestión de producción y de inventarios, el marketing, la
logística y el personal.
. Elementos técnicos, tales como el desarrollo de software, la química
y farmacia, la ingeniería ambiental o la ingeniería en construcción.
. Las especializaciones en gestión, como por ejemplo la contratación
estatal, el desarrollo de comunidades o el desarrollo de nuevos productos.

Los grupos de industrias como son la automotriz, la química, la agricultura o

los servicios financieros.

El apéndice E incluye un análisis más detallado de las áreas de aplicación de la

gestión de proyectos.

1.5 TEMAS RELACIONADOS

Ciertos tipos de empresas están estrechamente relacionados con los proyectos. A

menudo, existe una jerarquía de plan estratégico, programa, proyecto y sub-
proyecto, en el cual un programa compuesto por varios proyectos asociados
contribuirá al logro de un plan estratégico. A continuación, se describen estas
tareas relacionadas.

Programas. Un programa es un grupo de proyectos gestionados de una manera

coordinada para obtener aquellos beneficios que no sería posible lograr si se les
gestionara en forma individual (2). Muchos programas incluyen además elementos
de operaciones continuas. Por ejemplo:

. El “programa del avión XYZ” incluye tanto el proyecto como los

proyectos tendientes a diseñar y desarrollar el avión, al igual que la fabricación
continua y el soporte de la nave en tierra.
. Muchas empresas electrónicas cuentas con gerentes de programa
que son los responsables tanto por las versiones de productos individuales
(proyectos) como de la coordinación de las múltiples versiones con el transcurrir
del tiempo (una operación continua).
. Las plantas se refieren a menudo de un “programa de construcción”
anual, una operación regular y continua que involucra varios proyectos.
. Muchas organizaciones sin fines de lucro cuentan con un “programa
benéfico”, un esfuerzo continuo para obtener el apoyo financiero que, por lo
general, involucra una serie de proyectos discretos como son las membresías o
las subastas públicas.
. La publicación de un periódico o de una revista también constituye
un programa -el periódico es en sí un esfuerzo continuo, pero cada tema o tópico
es individualmente un proyecto.

Los programas pueden involucrar también una serie de tareas repetitivas o

cíclicas; por ejemplo:
En algunas áreas de aplicación, la gestión de programas o la gestión de proyectos
se tratan como sinónimos; en otros, la gestión de proyectos constituye un
subconjunto de la gestión de programas. Esta diversidad de significado hace que
sea imperativo que cualquier análisis o debate de la gestión de proyectos versus la
gestión de programas sea precedida por un acuerdo respecto de una definición
clara y consistente de cada término.

Subproyectos. Los proyectos se dividen frecuentemente en componentes más

manejables o subproyectos. Los subproyectos se contratan, generalmente, a una
empresa externa o a otra unidad funcional de la organización ejecutante. Entre los
ejemplos se incluyen:

. Los subproyectos basados en el proceso del proyecto, como una

sola fase.
. Los subproyectos de conformidad con los requerimientos de
habilidades en recursos humanos, como son la instalación de sanitarios o de
dispositivos eléctricos en un proyecto de construcción.
. Los subproyectos que implican tecnología, como son las
evaluaciones automatizadas de programas computacionales de un proyecto de
desarrollo de software.

Los subproyectos son considerados comúnmente como proyectos y son

gestionados como tales.

Gestión de Portafolio de Proyectos. La gestión de portafolio de proyectos se

refiere a la selección y soporte de proyectos o inversiones de programas. Estas
inversiones en proyectos y programas son guiadas por el plan estratégico de la
organización y por los recursos disponibles.

Los proyectos y la gestión de proyectos operan en un ambiente más amplio que el

del proyecto en sí. El equipo de gestión del proyecto debe entender este contexto
más amplio – la gestión de las actividades diarias del proyecto es una actividad
necesaria para el éxito, pero no es suficiente. Este capítulo describe los aspectos
claves del contexto de gestión de proyectos que no se describen en ninguna otra
parte de este documento. Entre los tópicos cubiertos se incluyen:

1. 2.1 Fases del Proyecto y el Ciclo de Vida del Proyecto

2. 2.2 Clientes de Proyectos
3. 2.3 Influencias Organizacionales
4. 2.4 Habilidades Claves de la Gestión General
5. 2.5 Influencias Sociales-Económicas-Ambientales
2.1 FASES DEL PROYECTO Y EL CICLO DE VIDA DEL PROYECTO

Dado que los proyectos son empresas únicas, estos implican un grado de
incertidumbre. Las organizaciones que ejecutan proyectos dividirán, generalmente,
cada proyecto en varias fases de proyecto a fin de mejorar el control de la gestión
y para establecer vínculos con las operaciones continuas de la organización
ejecutante. De forma colectiva, las fases del proyecto se conocen como ciclo de
vida del proyecto.

2.1.1 Características de las Fases del Proyecto

Cada fase del proyecto está determinada con el término de una o más
prestaciones. Una prestación es un producto de trabajo tangible y verificable como
puede ser un estudio de factibilidad, un diseño de detalle, o un prototipo funcional.
Las prestaciones y, por ende las fases, son parte de una lógica generalmente
secuencial diseñada para asegurar la correcta definición del producto del proyecto.

La conclusión de una fase de proyecto está marcada, generalmente, por una

revisión tanto de las prestaciones claves como del rendimiento / desempeño del
proyecto a la fecha, a fin de a) determinar si el proyecto debe continuar a su
siguiente fase y, b) detectar y corregir errores de forma costo-efectiva. Estas
revisiones de fin de fases se conocen, comúnmente, como salidas de fase,
puertas de etapas o puntos muertos.

Normalmente, cada fase de proyecto incluye un conjunto de prestaciones

definidas diseñadas para establecer el nivel deseado de control de gestión. La
mayoría de estos ítemes dice relación con la principal prestación de la fase, y las
fases típicamente toman sus nombres a partir de estos ítemes: requerimientos,
diseño, construcción, prueba, puesta en marcha, etc., según sea el caso. La
sección 2.1.3 describe varios ciclos de vida representativos de proyectos.

2.1.2 Características del Ciclo de Vida del Proyecto

El ciclo de vida del proyecto sirve para definir el inicio y el término de un proyecto.
Por ejemplo, cuando una organización identifica una oportunidad a la cual le
gustaría responder, a menudo esta autorizará una evaluación de necesidades y/o
un estudio de factibilidad con el objeto de decidir si debe o no abordar un proyecto.
La definición del ciclo de vida del proyecto determinará si el estudio de factibilidad
será o no tratado como la primera fase del proyecto o como un proyecto separado
y singular.

La definición del ciclo de vida del proyecto determinará, además, que tipo de
acciones de transición se incluyen al comienzo y al término del proyecto, y cuáles
no. De esta manera, la definición del ciclo de vida del proyecto puede utilizarse
para ligar el proyecto con las operaciones continuas de la organización ejecutante.
La secuencia de fases definida por la mayor parte de los ciclos de vida del
proyecto, generalmente implica cierta forma de transferencia o manejo de
tecnología, como son los requerimientos para el diseño, la construcción para las
operaciones, o el diseño para la fabricación. Las prestaciones de la fase anterior
se aprueban, generalmente, antes de que comience el trabajo en la siguiente fase.
No obstante, a veces se inicia una fase posterior antes de la aprobación de las
prestaciones de la fase previa, toda vez que los riesgos involucrados sean
considerados como aceptables. Esta práctica de traslapar fases se conoce a
menudo como fast tracking.

Los ciclos de vida del proyecto definen generalmente:

. ¿Qué tipo de trabajo técnico se debe realizar en cada una de las

fases? (por ejemplo, ¿Corresponde el trabajo a la parte arquitectónica de la fase
de definición o a la parte de la fase de ejecución?
. ¿Quién debería participar en cada una de las fases? (Por ejemplo,
las personas a cargo de la implementación, quienes deben estar involucrados con
los requerimientos y el diseño).

Las descripciones de los ciclos de vida del proyecto pueden ser muy generales o
muy detalladas. Las descripciones altamente detalladas pueden tener numerosos
formatos, gráficos y listas de verificación con el objeto de proporcionar una
estructura y consistencia. Tales enfoques o metodologías detalladas reciben
frecuentemente el nombre de metodologías para la gestión de proyectos.

La mayor parte de las descripciones de ciclo de vida de los proyectos comparten

una cantidad común de características:

. los niveles de costos y dotación son bajos al comienzo, más altos

hacia el final y caen rápidamente a medida que el proyecto se acerca a su término.
Este patrón queda ilustrado en la Figura 2-1.
. La probabilidad de terminar exitosamente el proyecto es la más baja
y, por ende, tanto el riesgo como la incertidumbre son los más altos al inicio del
proyecto. La probabilidad de alcanzar un término exitoso se hace progresivamente
mayor a medida que el proyecto continúa.
. La capacidad de los clientes para influenciar en las características
finales del producto del proyecto y en el costo final del proyecto es la más alta al
principio y se hace progresivamente menor a medida que el proyecto continúa.
Uno de los principales causantes de este fenómeno es que el costo cambia y,
generalmente, aumenta la corrección de errores a medida que el proyecto
continúa.
Hay que tener cuidado al momento de distinguir entre el ciclo de vida del proyecto
y el ciclo de vida del producto. Por ejemplo, la realización de proyecto para
introducir un nuevo computador al mercado es sólo una fase o etapa del ciclo de
vida del producto.

Aunque muchos ciclos de vida de proyectos tienen nombres de fases similares

donde se requieren prestaciones similares, sólo unos pocos son idénticos. La
mayoría tiene cuatro o cinco fases, pero hay algunos que tienen nueve o más.
Incluso dentro de una sola área de aplicación, puede haber variaciones
importantes – el ciclo de vida del desarrollo de software de una organización
puede tener una sola fase de diseño, mientras que otro tiene fases separadas en
cuanto a diseño funcional y de detalle.

Los sub-proyectos dentro de los proyectos pueden tener también distintos ciclos
de vida de proyectos. Por ejemplo, una oficina arquitectónica contratada para
diseñar un nuevo edificio de oficinas se involucra primero con la fase de definición
del dueño al momento de realizar el diseño, y en la fase de implementación del
dueño, cuando se respalda la tarea de construcción. No obstante, el proyecto de
diseño del arquitecto tendrá su propia serie de fases desde la de desarrollo
conceptual, pasando por la de definición e implementación hasta llegar finalmente
a la de cierre. El arquitecto puede incluso tratar de diseñar la instalación y de
respaldar la construcción como proyectos separados con sus propias fases
distintas.

2.1.3 Ciclos Representativos de Vida del Proyecto

Se han seleccionado los siguientes ciclos de vida de proyectos de forma tal de

ilustrar la diversidad de las metodologías que se utilizan. Los ejemplos que se
muestran son típicos; no son ni los preferidos ni los recomendados. En cada caso,
los nombres de las fases y las principales prestaciones son aquellos descritos por
el autor para cada una de las figuras.
Adquisición de defensa. El Instructivo 5000.2 del Departamento de Defensa de los
Estados Unidos, en su Borrador Final de Coordinación, Abril del 2000, describe
una serie de hitos de adquisición y cuyas fases se ilustran en la Figura 2
2.

. Desarrollo de concepto y tecnología -estudios de los conceptos

alternativos para cumplir una necesidad de misión; desarrollo de subsistemas /
componentes y demostración del concepto / tecnología de los nuevos conceptos
sistémicos. Termina con la selección de una arquitectura de sistemas y una
tecnología madura a ser utilizadas.
. Desarrollo y demostración del sistema – integración del sistema;
reducción del riesgo; demostración de los modelos de desarrollo de ingeniería;
desarrollo y prueba operacional prematura y evaluación. Termina con la
demostración del sistema en un ambiente operacional.
. Producción y despliegue – producción inicial de baja velocidad
(LRIP); desarrollo completo de la capacidad de fabricación; la fase se traslapa con
las operaciones continuas y de soporte.
. Soporte – esta fase es parte del ciclo de vida del producto, pero
corresponde en realidad a una gestión continua. Durante esta fase, se pueden
llevar a cabo varios proyectos de forma tal de mejorar la capacidad, corregir los
defectos, etc.

Construcción. Adaptada de Morris (1) describe el ciclo de vida de un proyecto de

construcción, como se ilustra en la Figura 2-3.

. Factibilidad -formulación del proyecto, estudios de factibilidad, diseño

de la estrategia y aprobación. Se toma la decisión de continuar o no al final de
esta fase.
. Planificación y diseño – diseño base, costo y programa, términos y
condiciones de contrato, y planificación detallada. Los principales contratos se
dejan para el final de esta fase.
. Construcción – fabricación, entrega, obras civiles, instalación y
pruebas. La instalación queda significativamente terminada al final de esta fase.
. Entrega y puesta en marcha -prueba final y mantención. Al final de
esta fase, la instalación queda totalmente operativa.

Farmacia. Murphy (2) describe el ciclo de vida de un proyecto para el desarrollo de

un nuevo producto farmacéutico en los Estados Unidos, como se ilustra en la
Figura 2-4.

. Descubrimiento y selección – incluye la investigación básica y

aplicada para identificar a los candidatos para las pruebas pre-clínicas.
. Desarrollo pre-clínico -incluye las pruebas de laboratorio y en
animales para determinar la seguridad y eficacia, como así también la preparación
y registro de una solicitud de Investigación de una Nueva droga (IND).
. Trabajo de registro(s) – incluye las pruebas de las Fases Clínicas I, II
y III, como así también la preparación y registro de una Solicitud de Nueva Droga
(NDA).
. Actividad post-presentación -incluye el trabajo adicional requerido
para respaldar la revisión de la NDA por parte de la Secretaría de Salud Pública.
Desarrollo de software. Existe una serie de modelos de ciclo de vida del software
actualmente en uso como es el modelo de cascada. Muench, y otros (3) describen
un modelo espiral para el desarrollo de software con cuatro ciclos y cuatro
cuadrantes, como se puede apreciar en la Figura 2-5.

. Ciclo de prueba del concepto – captura de los requerimientos del

negocio, definición de los objetivos de la prueba del concepto, producción del
diseño conceptual del sistema y diseño de la lógica, construcción de la prueba del
concepto, producción de los planes de aceptación de pruebas, realización del
análisis de riesgo y recomendaciones.
. Primer ciclo de construcción -derivación de los requerimientos del
sistema, definición de los objetivos para la primera construcción, producción del
diseño del sistema lógico, construcción de la primera partida, producción de los
planes de prueba del sistema, evaluación de la primera partida, y
recomendaciones.
. Segundo ciclo de construcción – derivación de los requerimientos de
los subsistemas, definición de los objetivos para la segunda partida, evaluación de
la segunda partida y recomendaciones.
. Ciclo final -completar los requerimientos de las unidades y diseño
final; construcción final y ejecución de las pruebas de unidades, subsistemas,
sistemas y de aceptación.

2.2 CLIENTES DEL PROYECTO

Los clientes del proyecto son aquellos individuos u organizaciones que están
activamente involucrados en el proyecto, o cuyos intereses pueden verse
afectados, positiva o negativamente, como resultado de la ejecución y término del
proyecto; también pueden ejercer influencia en el proyecto y sus resultados. El
equipo de gestión de proyectos debe identificar a los clientes, determinar sus
requerimientos y, luego, gestionar e influenciar aquellos requerimientos, de modo
tal de asegurar un proyecto exitoso. La identificación de los clientes o usuarios es
a menudo especialmente difícil. Por ejemplo, ¿Es cliente o usuario un trabajador
de la línea de montaje, cuyo empleo a futuro depende del resultado de un nuevo
proyecto diseño – producto?

Entre los clientes o usuarios claves de cada proyecto se incluyen:

. El gerente de proyectos – la persona responsable de gestionar el

proyecto.
. El usuario – el individuo o la organización que utilizará el producto
del proyecto. Pueden existir múltiples niveles de usuarios. Por ejemplo, los clientes
de un nuevo producto farmacéutico pueden incluir a doctores que lo receten, a los
pacientes que lo toman, a y a los aseguradores que pagan por éste. En algunas
áreas de aplicación, cliente y usuario son sinónimos, mientras que en otros el
cliente se refiere a la entidad que compra los resultados del proyecto y los
usuarios aquellos que utilizarán directamente el producto del proyecto.
. Organización ejecutante – la empresa cuyos trabajadores están más
directamente involucrados en realizar el trabajo del proyecto.
. Los miembros del equipo de proyectos – el grupo que está
realizando el trabajo del proyecto.
. Auspiciador – el individuo o grupo interno o externo a la organización
ejecutante que otorga los recursos financieros, en efectivo o al cambio para el
proyecto.

Además de estos, existen muchos nombres y categorías diferentes de clientes de

proyectos – internos y externos, dueños y fundadores, vendedores y contratistas,
miembros del equipo de contratistas y sus familias, las instituciones fiscales y los
mercados de tamaño promedio, ciudadanos, organizaciones de apoyo temporal o
permanente, y la sociedad por el todo. El nombramiento o la agrupación de
clientes es principalmente una ayuda para identificar que individuos y
organizaciones e confundieron como accionistas. Los roles y responsabilidades de
los clientes pueden traslaparse, como cuando una empresa de ingeniería traslapa
los aspectos financieros de una planta que se está diseñando.

La gestión de las expectativas de los clientes puede ser dificultosa, dado que los
clientes a menudo tienen objetivos muy diferentes que pueden entrar en conflicto.
Por ejemplo:

. El gerente de un departamento que ha solicitado un nuevo sistema

informático de gestión puede desear un costo bajo, el arquitecto del sistema puede
enfatizar la excelencia técnica, mientras que el contratista de programación puede
estar más interesado en maximizar su beneficio económico.
. El vice-presidente de investigación de una empresa electrónica que
define el éxito de los nuevos productos como la tecnología más moderna, el
vicepresidente de fabricación puede definirlo como prácticas de clase mundial, y el
vice-presidente de marketing puede estar principalmente involucrado con el
número de nuevas características.
. El dueño de un proyecto de desarrollo de bienes raíces puede estar
preocupado del rendimiento o desempeño puntual, el organismo regulador local
puede desear maximizar los ingresos por impuestos, un grupo ambientalista
puede desear maximizar los impactos ambientales adversos, mientras que los
residentes cerca del lugar pueden esperar la reubicación del proyecto.

En general, las diferencias entre clientes deben ser resueltas a favor del usuario.
Sin embargo, esto no significa que se puedan dejar de lado las necesidades y
expectativas de otros accionistas o clientes. Encontrar las soluciones adecuadas a
tales diferencias puede ser uno de los grandes y más importantes desafíos de la
gestión de proyectos.

2.3 INFLUENCIAS ORGANIZACIONALES

Los proyectos son comúnmente parte de una organización más grande que el
proyecto – corporaciones, agencias gubernamentales, instituciones de salud,
organismos internacionales, asociaciones profesionales y otros. Aun cuando el
proyecto sea la organización (sociedades contractuales, sociedades), el proyecto
continuará siendo influenciado por la organización u organizaciones que lo
forjaron. También puede influir en el proyecto la madurez de la organización con
respecto a sus sistemas de gestión de proyectos, la cultura, el estilo, la estructura
organizacional y la oficina de gestión de proyectos. Las siguientes secciones
describen los aspectos claves de estas estructuras organizacionales más grandes
con probabilidades de influir en los proyectos.

2.3.1 Sistemas Organizacionales

Las organizaciones basadas en proyectos son aquellas operaciones que

consisten, principalmente, en proyectos. Estas organizaciones se dividen en dos
categorías:

. Organizaciones que obtienen sus utilidades principalmente de la

ejecución de proyectos para otros -oficinas arquitectónicas, empresas de
ingeniería, consultores, contratistas de la construcción, contratistas
gubernamentales, organizaciones no-gubernamentales, etc.
. Las organizaciones que han adoptado la gestión por proyectos (ver
Sección 1.3).

Estas organizaciones tienden a tener implementados sistemas de gestión a fin de

facilitar la gestión de proyectos. Por ejemplo, sus sistemas financieros son, a
menudo, diseñados para la contabilidad, seguimiento y reporte de múltiples
proyectos simultáneos.

Las organizaciones que no se basan en proyectos carecen , a menudo, de

sistemas de gestión diseñados para respaldar eficiente y eficazmente las
necesidades del proyecto. La ausencia de sistemas orientados a proyectos
generalmente hace que la gestión de proyectos sea más difícil. En algunos casos,
las organizaciones basadas en proyectos tendrán departamentos u otras sub-
unidades que operen como organizaciones basadas en proyectos con sistemas
que deban concordar.

El equipo de gestión de proyectos debe estar perfectamente conciente de cómo

afectan al proyecto los sistemas de la organización. Por ejemplo, si la organización
recompensa al gerente funcional por cambiar el tiempo del personal en los
proyectos, entonces el equipo de gestión del proyecto puede necesitar
implementar los controles de forma tal de asegurarse de que los miembros del
personal asignado sean utilizados en forma efectiva durante el proyecto.

2.3.2 Culturas y Estilos Organizacionales

La mayoría de las organizaciones han desarrollado culturas únicas y descriptibles.

Estas culturas se reflejan en sus valores, normas, creencias y expectativas
compartidas; en sus políticas y procedimientos; en su visión de la relación de
autoridad; y en numerosos otros factores. Las culturas organizacionales tienen, a
menudo, una influencia directa en el proyecto. Por ejemplo:

. Un equipo que propone una metodología inusual o de alto riesgo

está más propenso a garantizar la aprobación en una organización agresiva o
empresarial.
. Un gerente de proyecto con un estilo altamente participativo está
propenso a encontrarse con problemas en una organización rígidamente
jerárquica; en tanto que un gerente de proyecto con un estilo autoritario será
igualmente desafiado en una organización participativa.
 Estructura de la

Organización Matriz
Características

del Proyecto Funcional Matriz Débil Matriz Balanceada Matriz Fuerte Proyectizada
Auoridad del Gerente del Poca Limitada Baja a Moderada Alta a
Proyecto o Nada Moderada a Alta Casi Total

Porcentaje del Personal de

la Organización Ejecutante Casi 0 - 25% 15 - 60% 50 - 95% 85 - 100%

Asignado a Tiempo Completo Nada

al Trabajo del Proyecto

Rol del Gerente del Medio Medio Tiempo Tiempo Tiempo
Proyecto Tiempo Tiempo Completo Completo Completo
Títulos Comunes para Coordinador Coordinador Gerente de Gerente de Gerente de
el Rol de Gerente del de Proyectos/ de Proyectos/ Proyecto/ Proyecto / Proyecto /
Lider de Lider de Ejecutivo de Gerente de Gerente de
Proyecto
Proyectos Proyectos Proyecto Programa Programa
Personal Administrativo Medio Medio Medio Tiempo Tiempo
de Gestión del Proyecto Tiempo Tiempo Tiempo Completo Completo

Figura 2-6. Influencias

de la Estructura
Organizacional en los
Proyectos.
2.3.3
Estructura
Organizacional

La estructura de
la organización
ejecutante a
menudo
restringe la
disponibilidad
de
o los términos
bajo los cuales
los recursos se
hacen
disponibles
para el
proyecto. Las
estructuras
organizacionale
s se pueden
caracterizar
como una
expansión del
espectro, de
funcional a
proyectizada,
con una
variedad de
estructuras
estructuras matrices entremedio. La Figura 2-6 muestra las características claves
relacionadas a proyectos de los principales tipos de estructuras organizacionales
de empresas.
En la Sección 9.1, Planificación Organizacional, se analiza la organización del
proyecto.

La organización funcional clásica, que aparece en la Figura 2-7, es una jerarquía

donde el empleado tiene un superior claro. Los miembros del personal están
agrupados por especialidad, como por ejemplo producción, marketing, ingeniería y
contabilidad en el nivel superior, sub-dividiéndose la ingeniería más adelante en
organizaciones funcionales que apoyan el negocio dela organización más grande
(por ejemplo, ingeniería mecánica y eléctrica). Las organizaciones funcionales
siguen teniendo proyectos, pero el alcance que se percibe del proyecto se limita a
los límites de la función: el departamento de ingeniería de una organización
funcional realizará su trabajo de manera independiente de los departamentos de
fabricación o marketing. Por ejemplo, cuando se asume el desarrollo de un nuevo
producto en una organización netamente funcional, la fase de diseño recibe, a
menudo, el nombre de proyecto de diseño e incluye sólo al personal del
departamento de ingeniería. En caso de surgir preguntas respecto de la
fabricación, éstas son dirigidas jerárquicamente al jefe del departamento, quien
consulta con el jefe del departamento de fabricación. El jefe del departamento de
ingeniería traspasa luego la pregunta jerárquicamente al gerente de proyectos de
ingeniería.

En el extremo opuesto del espectro se haya la organización proyectizada, que se

muestra en la Figura 2-8. En una organización proyectizada, los miembros del
equipo son con frecuencia individuos designados. Gran parte de los recursos de la
organización están involucrados en el trabajo del proyecto, y los gerentes de
proyectos tienen una gran independencia y autoridad. Las organizaciones
proyectizadas tienen, a menudo, unidades organizacionales llamadas
departamentos, pero estos grupos, ya sea, se reportan directamente al gerente de
proyectos o bien prestan servicios de apoyo a los distintos proyectos.

Las organizaciones matrices, como se ilustra en las Figuras 2-9 a la 2-11, son una
mezcla de las características funcionales y proyectizadas. Las matrices débiles
conservar muchas de las características de una organización funcional, y el rol del
gerente de proyectos es más que la de un coordinador o más expedita que la de
un gerente. De forma similar, las matrices fuertes reúnen muchas de las
características de la organización proyectizada – gerentes de proyecto de tiempo
completo con gran autoridad y personal administrativo de proyecto de tiempo
completo.

Las organizaciones más modernas involucran a todas estas estructuras en varios

niveles, como se aprecia en la Figura 2-12. Por ejemplo, incluso una organización
fundamentalmente funcional puede crear un equipo especial de proyectos a fin de
manejar un proyecto crítico. Dicho equipo puede reunir muchas de las
características de un proyecto de una organización proyectizada. El equipo puede
incluir personal de tiempo completo proveniente de distintos departamentos
funcionales, puede desarrollar su propio conjunto de procedimientos de operación
y, puede operar fuera de la estructura de reporte formalizada y estandarizada.
2.3.4 Oficina de Proyectos

Hay una variedad de usos para lo que constituye una oficina de proyectos. Una
oficina de proyectos puede operar en forma continua, prestando funciones de
apoyo a los gerentes de proyectos en la forma de capacitación, software,
plantillas, etc., hasta realmente convertirse en el responsable de los resultados del
proyecto.

2.4 HABILIDADES CLAVES DE LA GESTIÓN GENERAL

La gestión general es un tema amplio que trata cada uno de los aspectos de la
gestión de una empresa continua. Entre otros tópicos, está incluye:

. Finanzas y contabilidad, ventas y marketing, investigación y

desarrollo, y fabricación y distribución.
. Planificación estratégica, planificación táctica y planificación
operacional.
. Estructuras organizacionales, comportamiento organizacional,
administración de personal, compensación, beneficios y trayectorias profesionales.
. Gestiona las relaciones laborales a través de la motivación,
delegación, supervisión, formación de equipos, manejo de conflictos y otras
técnicas.
. Se gestiona a sí mismo mediante la gestión de tiempo del personal,
la gestión del stress y otras técnicas.

Las habilidades en gestión general representan gran parte de la base para formar
las habilidades en gestión de proyectos. Estas son, con frecuencia, esenciales
para el gerente de proyectos. En todo proyecto, es posible que se exija tener
habilidades en cada una de las áreas de gestión general. Esta sección describe
las habilidades claves de la gestión general que tienen una alta probabilidad de
afectar a la mayoría de los proyectos y que no se analizan en ninguna otra parte
de este documento.

Estas habilidades están bien documentadas en la literatura referida a la gestión

general, y su aplicación es fundamentalmente la misma en un proyecto.

2.4.1 Liderazgo

Kotter (4) distingue entre liderar y gestionar, enfatizando al mismo tiempo la

necesidad de ambos: el uno sin el otro está propenso a producir malos resultados.
Señala que gestionar tiene que ver principalmente con “producir consistentemente
los resultados claves que esperan los clientes”, mientras que liderar implica:
. Establecer una dirección – desarrollar tanto una visión del futuro
como las estrategias para producir los cambios que sean necesario para lograr
dicha visión.
. Alinear a las personas – comunicar la visión por medio de palabras y
hechos a todos aquellos cuya cooperación puede ser necesaria para lograr la
visión.
. Motivar e inspirar -ayudar a las personas a energizarse con el objeto
de superar las barreras políticas, burocráticas y de recursos y lograr el cambio.

En un proyecto, especialmente en un proyecto de gran envergadura, por lo

general se espera que el gerente del proyecto sea además el líder del proyecto.
No obstante, el liderazgo no se limita al gerente de proyecto: éste puede ser
demostrado por muchos individuos diferentes en distintas oportunidades durante
el proyecto. El liderazgo se puede demostrar a todos los niveles del proyecto
(liderazgo de proyecto, liderazgo técnico y liderazgo de equipo).

2.4.2 Comunicación

La comunicación implica el intercambio de información. El emisor es el

responsable de que la información sea clara, sin ambigüedades y completa, de
modo tal que el receptor la pueda recibir correctamente. El receptor es
responsable de asegurarse de que la información se reciba en su totalidad y de
que se entienda correctamente. La comunicación tiene muchas dimensiones:

. Escrita y oral, oída y hablada.

. Interna (dentro del proyecto) y externa (al cliente, a los medios, al
público, etc.)
. Formal (reportes, entrevistas, etc.) e informal (memorandos,
conversaciones ad hoc, etc.).
. Verticales (hacia arriba y hacia abajo en la organización) y
horizontales (con nuestros compañeros y colegas en la organización).

La habilidad de la gestión general para comunicarse se relaciona con, aunque no

es igual a, la Gestión de Comunicaciones del Proyecto (que se describe en el
Capítulo 10). La comunicación es el tópico más amplio e implica una importante
estructura de conocimiento que no es única al contexto del proyecto; por ejemplo:

. Modelos de emisor-receptor – lazos de retroalimentación, barreras a

las comunicaciones, etc.
. Selección de medios – cuando se hace necesario comunicar por
escrito, cuando se desea comunicar en forma oral, cuando se quiere escribir un
memorando informal, al escribir un informe formal, etc.
. Estilo de redacción -voz activa versus voz pasiva, estructura de las
frases, elección de las palabras, etc.
. Técnicas de presentación – lenguaje corporal, diseño de las ayudas
audiovisuales, etc.
. Técnicas de gestión de reuniones – preparación de una agenda,
desarrollo del conflicto, etc.
La Gestión de Comunicación del Proyecto representa la aplicación de estos
amplios conceptos a las necesidades específicas de un proyecto – por ejemplo,
decidir el cómo, cuando, en qué forma y a quién reportar el rendimiento /
desempeño del proyecto.

2.4.3 Negociación

Negociar implica conferenciar con otros para llevar a términos con ellos o alcanzar
un acuerdo. Los acuerdos se pueden negociar directamente o con ayuda;
mediación y arbitraje son dos tipos de negociación asistida.

Las negociaciones se producen en torno a muchos temas, en muchas

oportunidad, y a varios niveles del proyecto. Durante el curso de un proyecto
típico, es probable que el personal del proyecto negocie por cualquiera o por todo
lo que sigue:

. Alcance, costo y objetivos del programa

. Cambios de alcance, costo o programa
. Términos contractuales y condiciones
. Designaciones.
. Recursos.

2.4.4 Solución de Problemas

La solución de problemas es una combinación entre definición del problema y la

toma de decisiones.

La definición del problema requiere distinguir entre las causas y los síntomas. Los
problemas pueden ser internos (un empleado clave es reasignado a otro proyecto)
o externos (se atrasó el permiso requerido para iniciar el trabajo). Los problemas
pueden ser técnicos (diferencias de opinión respecto de la mejor forma de diseñar
un producto), gerenciales (un grupo funcional no tiene el desempeño planificado) o
interpersonal (choque de personalidades o estilos).

La toma de decisiones implica analizar el problema para identificar las soluciones

viables y, luego, elegir una opción de entre todas ellas. Las decisiones se pueden
tomar u obtener (de parte del cliente, del equipo o de un gerente funcional). Una
vez tomadas, las decisiones deben implementarse. Las decisiones tienen ligado
además un elemento de tiempo – la decisión “correcta” puede no ser la “mejor”
decisión si se toma en forma muy anticipada o demasiado tarde.

2.4.5 Influenciar a la Organización

Influenciar a la organización implica tener la habilidad para hacer “que las cosas
se hagan”. Lo anterior exige un entendimiento de las estructuras tanto formales
como informales de todas las organizaciones involucradas –la organización
ejecutante, el cliente, los socios, los contratistas, y de numerosas otras, según sea
el caso. Para influir en la organización se precisa, además, comprender la
mecánica del poder y de la política.

Tanto el poder como la política se utilizan aquí en sus sentidos positivos. Pfeffer
(5) define el poder como “la capacidad potencial para influir en la conducta, para
cambiar el curso de los eventos, para superar la resistencia, y para hacer que las
personas hagan las cosas que no harían en caso contrario”. De manera similar,
Eccles y otro (6) señala que “política es obtener la acción colectiva de un grupo de
personas que pueden tener intereses bastante diferentes. Se trata de estar
dispuesto a utilizar el conflicto y el desorden en forma creativa. El sentido
negativo, obviamente, surge del hecho de que los intentos por reconciliar estos
intereses dan como resultados pugnas de poder y juegos organizacionales que
pueden, a veces, adoptar por sí mismos un estilo de vida totalmente improductivo”.

2.5 INFLUENCIAS SOCIALES – ECONÓMICAS – AMBIENTALES

Al igual que la gestión general, las influencias socioeconómicas incluyen una

amplia variedad de tópicos y temas. El equipo de gestión de proyectos debe
entender que las actuales condiciones y tendencias en esta área pueden tener un
efecto mayor en su proyecto: un pequeño cambio aquí puede traducirse,
generalmente con un intervalo de tiempo, en trastornos catastróficos del proyecto
en sí. De las diversas influencias socioeconómicas potenciales, a continuación se
describen brevemente varias de las principales categorías que afectan con mayor
frecuencia a los proyectos.

2.5.1 Normas y Regulaciones

La Organización Internacional para la Normalización (ISO) hace una distinción

entre normas y regulaciones (7):
. Una norma es un “documento aprobado por un organismo
reconocido, que establece, para un uso común y repetido, las reglas, pautas o
características de los productos, procesos o servicios con los que no es obligatorio
cumplir”. Existen numerosas normas actualmente en uso que abarcan todo desde
estabilidad térmica de los fluidos hidráulicos al tamaño de los disquetes de
computación.
. Una regulación es un “documento, que describe las características
de un producto, proceso o servicio, incluidas las disposiciones administrativas que
sean aplicables, con las que es obligatorio cumplir. Los códigos de construcción
son un ejemplo de regulaciones.

No obstante, se debe tener mucho cuidado al analizar las normas y las

regulaciones, por cuando existe una vasta área gris entre las dos; por ejemplo:

. Las normas a menudo comienzan como pautas que describen un

método preferido, y más tarde, con una amplia adopción, pasan a ser regulaciones
de ipso (por ejemplo, el uso del Método de Trayectorias Críticas para programar
los principales proyectos de construcción).
. El acatamiento puede ser obligado a distintos niveles (por ejemplo,
por una entidad estatal, por la gerencia de la organización ejecutante, o por el
equipo de gestión del proyecto).

Para muchos proyectos, las normas y regulaciones (cualquiera sea su definición)

son bien conocidas, y los planes del proyecto pueden reflejar sus efectos. En
otros casos, la influencia es desconocida o incierta y deben ser consideradas en el
ámbito de la Gestión de Riesgos del Proyecto (que se describe en el Capítulo 11).

2.5.2 Internacionalización

A medida que más y más organizaciones participan en trabajos que traspasan los
límites nacionales, más y más proyectos traspasan también las fronteras
nacionales. Además de las inquietudes tradicionales del alcance, costo, tiempo y
calidad, el equipo de gestión del proyecto debe considerar además el efecto de las
diferencias de las zonas horarias, los feriados nacionales y regionales, los
requerimientos de viajes para reuniones “cara-a-cara”, la logística de la tele
conferencia y, a menudo, las volátiles diferencias políticas.

2.5.3 Influencias Culturales

Cultura es la “totalidad de los patrones de conducta, artes, creencias, instituciones

y todos los demás productos del trabajo y razonamiento humanos que se
transmiten socialmente” (8). Todo proyecto debe operar dentro de un contexto con
una o más normas culturales. Esta área de influencia incluye las áreas políticas,
económicas, demográficas, educacionales, éticas, étnicas, religiosas y otras áreas
de práctica, creencia y actitudes que afectan la forma con que interactúan las
personas y las organizaciones.
2.5.4 Sustentabilidad Social-Económica- Ambiental

Prácticamente todos los proyectos se planifican e implementan en un contexto

social, económico y ambiental, y tienen impactos positivos y/o negativos
intencionales o no intencionales. Las organizaciones son cada vez más
responsables de los impactos que surgen como resultado de un proyecto (por
ejemplo, la destrucción accidentadle sitios arqueológicos en un proyecto de
construcción de carreteras), como así también de los efectos de un proyecto sobre
las personas, la economía y el ambiente, tiempo después de que éste ha
concluido (por ejemplo, un camino puede facilitar el acceso a, y la destrucción de,
un ambiente una vez prístino).
La gestión de proyectos es una tarea integradora – una acción, o el fracaso en la
toma de la acción, en un área afectará generalmente a las demás áreas. Las
interacciones pueden ser directas y bien entendidas, o pueden ser sutiles e
inciertas. Por ejemplo, un cambio de alcance afectará casi siempre el costo del
proyecto, pero podría o no afectar la moral del equipo o la calidad del producto.

Estas interacciones requieren, con frecuencia, de compensaciones entre los

objetivos del proyecto -el desempeño en un área puede mejorarse sólo
sacrificando el desempeño en otra. Las compensaciones específicas en
desempeño pueden variar de un proyecto a otro y de una a otra organización. La
gestión de proyectos exitosa requiere del manejo activo de estas interacciones.
Muchos expertos en materia de gestión de proyectos se refieren a la triple
restricción de los proyectos como a una estructura para evaluar las demandas por
competencia. La triple restricción de los proyectos se grafica, casi siempre, como
un triángulo donde cada lado o las esquinas representan uno de los parámetros
que está gestionando el equipo del proyecto.

Para ayudar a entender la naturaleza integradora de la gestión de proyectos, y

para acentuar la importancia de la integración, este documento describe la gestión
de proyectos en términos de sus procesos componentes y sus interacciones. Este
capítulo sirve de introducción para el concepto de gestión de proyectos como un
número de procesos interrelacionados y, así, establece una base esencial para
comprender las descripciones delos procesos contenidos en los Capítulos 4 al 12.
Este incluye las siguientes secciones principales:

3.1 Procesos de los Proyectos

3.2 Grupos de Procesos
3.3 Interacciones de los Procesos
3.4 Adaptación de las Interacciones de Procesos
3.5 Mapeo de los Procesos de Gestión de Proyectos
3.1 PROCESOS DE LOS PROYECTOS

Los proyectos se componen de procesos. Un proceso es “una serie de acciones

en pro de un resultado” (1). Los procesos de proyectos son ejecutados por
personas, y generalmente entran en una de las dos principales categorías:
. Los procesos de gestión de proyectos describe, organizan y
completan el trabajo del proyecto. Los procesos de gestión de proyectos que son
aplicables a la mayoría de los proyectos, la mayor de las veces, se describen
brevemente en este capítulo y detalladamente en los Capítulos 4 al 12.
. Los procesos orientados al producto especifican y crean el producto
del proyecto. Los procesos orientados al producto son definidos, comúnmente por
el ciclo de vida del proyecto (analizado en la Sección 2.1) y varían según el área
de aplicación (que se analiza en el Apéndice E).

Los procesos de gestión de proyectos y los procesos orientados al producto se

traslapan e interactúan a lo largo del proyecto. Por ejemplo, el alcance del
proyecto no se puede definir en ausencia de cierta comprensión básica de cómo
crear el producto.

3.2 GRUPOS DE PROCESOS

Los procesos de gestión de proyectos se pueden organizar en cinco grupos de

uno o más procesos cada uno:

. Procesos de iniciación – que autoriza el proyecto o fase.

. Procesos de planificación – que definen y refinan los objetivos y que
seleccionan la mejor de las vías alternativas de acción, con el fin de lograr los
objetivos que el proyecto se ha propuesto abordar.
. Procesos de ejecución – que coordinan las personas y los demás
recursos para llevar a cabo el plan.
. Procesos de control – que aseguran el cumplimiento de los objetivos
del proyecto, monitoreando y midiendo el avance regularmente, a objeto de
identificar las variaciones respecto del plan, de modo tal de que sea posible tomar
la acción correctiva cuando sea necesario.
. Procesos de cierre – que formalizan la aceptación del proyecto o de
la fase y que lo(a) llevan a un fin ordenadamente,

Los grupos de procesos están vinculados por medio de los resultados que
producen –el resultado o la consecuencia de uno, se convierte a menudo en la
entrada para otro. Entre los grupos de procesos centrales, se repiten los vínculos
– planificación entrega a ejecución un plan de proyecto documentado con
antelación y, luego, proporciona las actualizaciones documentadas para el plan a
medida que avance el proyecto. Estas conexiones se ilustran en la Figura 3-1. Por
otra parte, los grupos de procesos de gestión de proyectos no son eventos
discretos que ocurren una sola vez; se trata de actividades traslapadas que
ocurren a distintos niveles de intensidad durante el desarrollo de cada una de las
fases del proyecto. La Figura 3-2 ilustra de qué manera se traslapan los grupos
 de proceso y cómo varían estos dentro de una fase.,

Finalmente, las interacciones de los grupos de procesos también traspasan las

fases, de forma tal que el cierre de una fase sirva de entrada para iniciar la
próxima. Por ejemplo, el cierre de una fase de diseño requiere de la aceptación,
por parte del cliente, del documento que contiene el diseño. Simultáneamente, el
documento del diseño define la descripción del producto para la fase de
implementación que sigue. Esta interacción se ilustra en la Figura 3-3.

La repetición de los procesos de iniciación al comienzo de cada fase ayuda a

mantener el proyecto enfocado en la necesidad de negocios que se comprometió
abordar. También debe servir para asegurarse de que el proyecto se interrumpa y
se detenga toda vez que la necesidad de negocios ya no exista, o si es improbable
que el proyecto satisfaga tal necesidad. Las necesidades de negocios se analizan
más detalladamente en la introducción a la Sección 5.1, Iniciación.

Es importante hacer notar que las entradas y salidas reales de los procesos
dependen de la fase en la que se lleven a cabo. Aun cuando la Figura 3-3 se
dibujó con fases y procesos discretos, en un proyecto real habrá muchos
traslapes. Por ejemplo, el proceso de planificación no sólo debe entregar detalles
del trabajo a realizar para llevar a buen final la actual fase del proyecto, sino que
además debe proveer cierta descripción preliminar del trabajo a realizar en las
fases siguientes. Este detalle progresivo del plan del proyecto se conoce a
menudo como planificación en olas, que indica que la planificación es un proceso
iterativo y continuo.

La participación de los clientes en las fases del proyecto, generalmente logra

mejorar la probabilidad de satisfacer los requerimientos de los usuarios y da lugar
a la propiedad compartida o buy-in del proyecto por parte de los clientes o
accionistas, que es casi siempre crítico para el éxito del proyecto.

3.3 INTERACCIONES DE PROCESOS

Dentro de cada grupo de procesos, los procesos individuales están unidos por sus
entradas y sus salidas. Al centrarse en estos vínculos, podemos describir cada
proceso en términos de sus:

. Entradas – documentos o ítemes documentables sobre los cuales se

actuará
. Herramientas y técnicas – mecanismos aplicados a las entradas para
crear las salidas.
. Salidas – documentos o ítemes documentables que son el resultado
del proceso.

Los procesos de gestión de proyectos comunes a la mayoría de los proyectos en

la mayor parte de las áreas de aplicación se listan aquí y se describen en detalle
en los Capítulos 4 al 12. Los números entre paréntesis luego de los nombres de
proceso, identifican el capítulo y la sección, donde se describen cada uno de ellos.
Las interacciones de los procesos aquí ilustradas son también típicas de la
mayoría de los proyectos en muchas áreas de aplicación. La Sección 3.4 analiza
la adaptación tanto de las descripciones como de las interacciones de los
proyectos.

3.3.1 Procesos de Iniciación

La Figura 3-4 ilustra el único proceso en este grupo de procesos.

Iniciación (5.1) – que autoriza que el proyecto o fase es parte de la gestión

del alcance del proyecto.
3.3.2 Procesos de Planificación

La planificación es de mayor importancia para un proyecto, ya que el proyecto

implica realizar algo que no se ha hecho antes. Como resultado de lo anterior, hay
relativamente más procesos en esta sección. No obstante, la cantidad de procesos
no significa que la gestión de proyectos sea principalmente la planificación - la
cantidad de planificación realizada debe ser conmensurada con el alcance del
proyecto y la utilidad de la información desarrollada. La planificación es un
esfuerzo continuo durante toda la vida del proyecto.
La Figura 3-5 muestra las relaciones entre los procesos de planificación del
proyecto (este gráfico es una explosión de la elipse denominada “Procesos de
Planificación” de la Figura 3-1). Estos procesos están sujetos a iteraciones
frecuentes antes de completar el plan del proyecto. Por ejemplo, si fuera
inaceptable la fecha inicial de término, no sería necesario redefinir los recursos del
proyecto, el costo ni siquiera el alcance. Además, la planificación no es una
ciencia exacta – dos grupos diferentes podrían generan planes muy diferentes
para el mismo proyecto.

Los procesos centrales. Algunos procesos de planificación tienen claras

dependencias que hacer que sean ejecutados esencialmente en el mismo orden
en la mayoría de los proyectos. Por ejemplo, las actividades deben definirse antes
de que se puedan programar o costear. Estos proceso centrales de planificación
pueden ser iterados varias veces durante cualquier fase de un proyecto. Estas
incluyen:

. Planificación del Alcance (5.2) – desarrollar una declaración escrita

del alcance como base para las futuras decisiones del proyecto.
. Definición del Alcance (5.3) – subdividir las principales prestaciones
del proyecto en componentes más manejables y más pequeños.
. Definición de las Actividades (6.1) – identificar las actividades
específicas que se deben ejecutar con el objeto de producir las distintas
prestaciones del proyecto.
. Secuencia de Actividades (6.2) – identificar y documentar las
dependencias interactividades.
. Estimación de la Duración de las Actividades (6.3) – estimación del
número de periodos de trabajo que serán necesarios para completar las
actividades individuales.
. Desarrollo de Programas (6.4) – analizar las secuencias de
actividades, las duraciones de las actividades y los requerimientos de recursos
para crear el programa del proyecto.
. Planificación de la Gestión de Riesgos (11.1) – decidir cómo abordar
y planificar la gestión de riesgos en un proyecto.
. Planificación de los Recursos (7.1) – determinar qué recursos
(personas, equipos, materiales, etc.) y en qué cantidades de cada uno, se deben
utilizar para desarrollar las actividades del proyecto.
. Estimación de los Costos (7.2) – desarrollar una aproximación
(estimación) de los costos de los recursos requeridos para completar las
actividades del proyecto.
. Presupuestación de Costos (7.3) – asignar la estimación global de
costos a paquetes de trabajo individuales.
. Desarrollo del Plan del Proyecto (4.1) – tomar los resultados de los
demás procesos de planificación y colocarlos en un documento consistente y
coherente.

Procesos Facilitadores. Las interacciones entre los demás procesos de

planificación son más dependientes de la naturaleza del proyecto. Por ejemplo, en
algunos proyectos, puede haber poco o ningún riesgo identificable sino hasta
después que se haya realizado gran parte de la planificación y el equipo
reconozca que las metas de costo y programa son extremadamente agresivas y,
por lo tanto, implican un riesgo considerable. Aunque estos procesos facilitadores
se llevan a cabo en forma intermitente y según sean necesarios durante la
planificación del proyecto, estos no son opcionales e incluyen:

. Planificación de la Calidad (8.1) – identificar que normas de calidad

son relevantes para el proyecto y determinar cómo satisfacerlas.
. Planificación Organizacional (9.1) – identificar, documentar y asignar
roles de proyecto, responsabilidades y relaciones de reporte.
. Contratación de Personal (9.2) – obtener los recursos humanos que
es necesario asignar a y trabajar en el proyecto.
. Planificación de las Comunicaciones (10.1) – determinar las
necesidades de comunicación e información de parte de los clientes o accionistas:
quién necesita qué información, cuándo la va a necesitar y cómo se le proveerá
dicha información.
. Identificación de los Riesgos (11.2) -determinar cuáles son los
riesgos que podrían llegar a afectar el proyecto y documentar las características
de cada uno de ellos.
. Análisis Cualitativo del Riesgo (11.3) – realizar un análisis cualitativo
de los riesgos y condiciones a fin de priorizar sus efectos en los objetivos del
proyecto.
. Análisis Cuantitativo del Riesgo (11.4) – medir la probabilidad e
impacto de los riesgos y estimar sus implicancias para con los objetivos del
proyecto.
. Planificación de la Respuesta ante el Riesgo (11.5) –desarrollar los
procedimientos y técnicas para aumentar las oportunidades y reducir las
amenazas de riesgo para los objetivos del proyecto.
. Planificación del Abastecimiento (12.1) – determinar qué se debe
adquirir, cuánto se debe comprar y cuándo.
. Planificación de la Requisición (12.2) – documentar los
requerimientos de productos e identificar las fuentes potenciales.

3.3.3 Procesos de Ejecutores

Los procesos ejecutores incluyen los procesos centrales y los procesos
facilitadores.. La Figura 3-6 ilustra la forma cómo interactúan los siguientes
procesos centrales y facilitadores:

. Ejecución del Plan de Proyecto (4.2) – llevar a cabo el plan de

proyecto, ejecutando las actividades previstas en éste.
. Aseguramiento de la Calidad (8.2) – evaluar el desempeño /
rendimiento global del proyecto de forma regular a fin de determinar el nivel de
confianza de que el proyecto cumplirá las normas de calidad relevantes.
. Desarrollo del Equipo (9.3) – desarrollar las habilidades /
competencias de los individuos o grupos para mejorar el desempeño del proyecto.
. Distribución de la Información (10.2) – hacer que la información
necesaria disponible llegue a los clientes y accionistas del proyecto en forma
oportuna.
. Requisición (12.3) – obtener las cotizaciones, ofertas o propuestas
según sea el caso.
. Selección de la Fuente (12.4) – elegir de entre los potenciales
vendedores.
. Administración del Contrato (12.5) – gestionar la relación con el
vendedor.

3.3.4 Procesos de Control

A fin de identificar las distintas desviaciones con respecto al plan, se hace

necesario monitorear y medir regularmente el rendimiento / desempeño del
proyecto. Dichas desviaciones o varianzas son ingresadas en los procesos de
control de las distintas áreas de conocimiento. En caso de observarse varianzas
significativas (es decir, aquellas que ponen en peligro los objetivos del proyecto),
se realizan ajustes en el plan, repitiendo los procesos de planificación del proyecto
que correspondan. Por ejemplo, la falta de una fecha de término de actividad
puede requerir de ajustes al actual plan de contratación de personal, la
dependencia en el sobretiempo, o de compensaciones entre los objetivos de
presupuesto y de programa. Tener control implica, además, tomar una acción
preventiva anticipándose a posibles problemas.

El grupo de procesos de control contiene los procesos centrales y los procesos

facilitadores.

La Figura 3-7 ilustra la forma cómo interactúan los procesos centrales y los
procesos facilitadores:

. Control Integrado de Cambios (4.3) -coordinar los cambios dentro de

todo el proyecto.
. Verificación del Alcance (5.4) – formalizar la aceptación del alcance
del proyecto.
. Control de Cambios de Alcance (5.5) – controlar los cambios al
alcance del proyecto.
. Control de Programa (6.5) – controlar los cambios al programa del
proyecto.
. Control de Costos (7.4) – controlar los cambios al presupuesto del
proyecto.
. Control de Calidad (8.3) – monitorear los resultados específicos del
proyecto con el objeto de determinar si estos cumplen con las normas de calidad
relevantes, e identificar las formas de eliminar las causas de rendimiento /
desempeño insatisfactorio.
. Reporte de Desempeño / Rendimiento (10.3) – recopilar y diseminar
la información sobre el rendimiento / desempeño. Esto incluye informar sobre los
estados, la medición del avance y de las predicciones.
. Control y Monitoreo de los Riesgos (11.6) – hacer un seguimiento de
los riesgos identificados, monitorear los riesgos residuales e identificar los nuevos
riesgos, asegurando la ejecución de los planes de riesgos y evaluar su eficacia en
la reducción del riesgo.
3.3.5 Procesos de Cierre

La Figura 3-8 ilustra la forma como interactúan los siguientes procesos centrales:

. Término de Contrato (12.6) – término y cierre del contrato, incluida la

resolución de cualquier ítem abierto.
. Cierre Administrativo (10.4) – generar, reunir y diseminar la
información a fin de formalizar el término de fase o del proyecto, incluida la
evaluación del proyecto y compilar las lecciones aprendidas para utilizarlas en la
planificación de futuros proyectos o fases.

3.4 ADAPTACIÓN DE LAS INTERACCIONES DE PROCESOS

Los procesos y las interacciones de la Sección 3.3 cumplen la prueba de

aceptación general -son aplicable a la mayoría de los proyectos, gran parte de las
veces. Sin embargo, no todos los procesos serán necesarios en todos los
proyectos, y no todas las interacciones serán aplicables a todos los proyectos.
Por ejemplo:

. Una organización que hace un uso extensivo de contratistas puede,

explícitamente, describir cuándo ocurre, en el proceso de planificación, cada uno
de los procesos de abastecimiento.
. La ausencia de un proceso no significa que éste no deba ser
realizado. El equipo de gestión de proyectos debe identificar y manejar todos los
procesos que son necesarios para asegurar un proyecto exitoso.
. Los proyectos que son dependientes de recursos únicos (desarrollo
de software comercial, biofarmacia, etc.) pueden definir roles y responsabilidades
antes de la definición del alcance, por cuanto lo que se pueda hacer podría estar
en función de quién estará disponible para hacerlo.

Algunos resultados o consecuencias de procesos pueden estar predefinidos como

restricciones. Por ejemplo, la gerencia podría especificar una fecha para lograr los
objetivos, en vez de permitir que ésta sea determinada por el proceso de
planificación. Una fecha de término impuesta puede aumentar el riesgo del
proyecto, agregar costos y comprometer la calidad.
. Los proyectos más grandes pueden necesitar relativamente más
detalle. Por ejemplo, la identificación de los riesgos podría seguir subdividiéndose
a fin de centrarse, separadamente, en la identificación de los riesgos de costos,
riesgos de programa, riesgos técnicos y riesgos en calidad.
. En los subproyectos y en los proyectos más pequeños, muy poco
esfuerzo será dedicado a aquellos procesos cuyas consecuencias o resultados
(salidas) se hayan definido a nivel de proyecto (por ejemplo, un subcontratista
puede ignorar explícitamente los riesgos asumidos por el contratista principal), o
en procesos que proporcionan sólo una utilidad marginal (por ejemplo, puede que
no haya un plan formal de comunicaciones en un proyecto con cuatro personas).

A Guide to the Project Management Body of

Knowledge (PMBOK® Guide) Edición 2000 ©2000,
Instituto de Gestión de Proyectos, Four Campus
Boulevard, Newtown Square, PA 19073-3299 USA
3.5 MAPEO DE LOS PROCESOS DE GESTIÓN DE PROYECTOS

La Figura 3-9 refleja el mapeo de los treinta y nueve procesos de gestión de

proyectos para los cinco grupos de procesos de gestión de proyectos, iniciación,
planificación, ejecución, control y cierre, y las nueve áreas de conocimiento de la
gestión de proyectos contenidas en los Capítulos 4 al 12.

Este diagrama no tiene como objeto ser exclusivo, sino más bien indicar dónde
encajan generalmente los procesos de gestión de proyectos, tanto en los grupos
de procesos de gestión de proyectos como en las áreas de conocimiento de la
gestión de proyectos.

1. 4. Gestión de Integración del Proyecto

2. 5. Gestión de Alcance del Proyecto
3. 6. Gestión del Tiempo del Proyecto
4. 7. Gestión del Costo del Proyecto
5. 8. Gestión de la Calidad del Proyecto
6. 9. Gestión de Recursos Humanos del Proyecto
7. 10. Gestión de Comunicaciones del Proyecto
8. 11. Gestión de Riesgos del Proyecto
9. 12. Gestión de Abastecimiento del Proyecto

Capítulo 4
La Gestión de Integración del Proyecto incluye los procesos requeridos para
asegurar que se coordinen adecuadamente los distintos elementos del proyecto.
Esto implica llevar a cabo las compensaciones entre los objetivos y alternativas
competentes , a fin de cumplir o sobre-satisfacer las necesidades y expectativas
de los accionistas o clientes. Aunque todos los procesos de gestión de proyectos
son, hasta cierto punto, integradores, los procesos descritos en este capítulo son
primeramente integradores. La Figura 4-1 constituye una descripción general de
los siguientes procesos principales:

1. 4.1 Desarrollo del Plan del Proyecto – integrar y coordinar todos los
planes del proyecto, a fin de crear un documento consistente y coherente.
2. 4.2 Ejecución del Plan del Proyecto – llevar a cabo el plan del
proyecto, ejecutando las actividades contempladas por éste.
3. 4.3 Control Integrado de Cambios – coordinar los cambios a nivel de
todo el proyecto.

Estos procesos interactúan unos con otros y también con los procesos de las
demás áreas de conocimiento. Cada proceso puede implicar el esfuerzo de uno o
más individuos o grupos de individuos, según sean las necesidades del proyecto.
Cada proceso ocurre, generalmente, al menos una vez en cada fase del proyecto.

Aunque los procesos se presentan aquí como elementos discretos con interfaces
bien definidas, en la práctica estos se traslapan e interactúan en formas que aquí
no se detallan. En el Capítulo 3 se detallan las interacciones de los procesos.

El presente capítulo se centra en los procesos, herramientas y técnicas empleadas

para integrar los procesos de gestión de proyectos. Por ejemplo, la gestión de
integración de proyectos se inicia cuando se hace necesaria una estimación de
costos para un plan de contingencia, o cuando se deben identificar los riesgos
asociados con las distintas alternativas de contratación de personal. No obstante,
para que un proyecto sea completamente exitoso, es necesario que la integración
ocurra también en una serie de otras áreas. Por ejemplo:

. El trabajo del proyecto se debe integrar con las operaciones

continuas de la organización ejecutante.
. Se deben integrar el alcance del proyecto y el del proyecto (la
diferencia entre el alcance del producto y del proyecto se analiza en la
introducción al Capítulo 5).

Una de las técnicas empleadas tanto para integrar los distintos procesos como
para medir el rendimiento del proyecto, a medida que éste se mueve desde la
iniciación a su término, es la Gestión del Valor Ganado (GVG). La GVG se
analizará en este capítulo como una metodología de integración de proyectos,
mientras que el valor ganado (VG), la técnica, será descrita en otros capítulos
como una herramienta para medir el rendimiento / desempeño con respecto al
plan del proyecto.
El software de gestión de proyectos es una herramienta que ayuda a la integración
dentro de un proyecto, y puede proyectarse a todos los procesos de gestión de
proyectos.

4.1 DESARROLLO DEL PLAN DE PROYECTOS

El desarrollo del plan de proyectos utiliza los resultados de otros procesos de

planificación, incluida la planificación estratégica, con objeto de crear documento
consistente y coherente que se pueda utilizar para guiar tanto la ejecución del
proyecto como el control del mismo. Este proceso es casi siempre reiterativo. Por
ejemplo, el borrador inicial puede incluir requerimientos de recursos genéricos y
una secuencia sin tiempo de las actividades, mientras que las versiones
posteriores del plan incluirán recursos específicos y fechas explícitas. El alcance
del trabajo del proyecto es un proceso iterativo que es generalmente realizado por
el equipo del proyecto para capturar y, luego, descomponer todo el trabajo del
proyecto. Todo el trabajo definido debe planificarse, estimarse, programarse y
autorizarse con el uso de planes de control de gestión integrados y detallados, en
ocasiones llamados Planes de Cuentas de Control, o CAPs, en el proceso GVG.
La suma de todos los planes de control de gestión integrada constituirán el
alcance total del proyecto.
El plan del proyecto se utiliza para:

. Guiar la ejecución del proyecto

. Documentar los supuestos de planificación del proyecto
. Documentar las decisiones de planificación del proyecto respecto de
las alternativas elegidas
. Facilitar la comunicación entre los clientes / accionistas
. Definir las revisiones claves de la gestión en cuanto a contenido,
extensión y sincronismo.
. Proveer una línea base para la medición del avance y el control del
proyecto.

4.1.1 Entradas para el Desarrollo del Plan del Proyecto

.1 Otros resultados de la planificación. Todas las salidas o resultados de

los procesos de planificación de las demás áreas de conocimiento (la
Sección 3.3 presenta un resumen de estos procesos de planificación de
proyectos) constituyen entradas para el desarrollo del plan del proyecto.
Las demás salidas de planificación incluyen tanto los documentos de
consulta, como son las EDT, como el detalle de respaldo. Muchos
proyectos requerirán también las entradas específicas del área de
aplicación (por ejemplo, la mayoría de los principales proyectos requerirán
una predicción del flujo de caja).
.2 Información histórica. La información histórica disponible (por ejemplo,
bases de datos para estimación, registros de rendimiento de proyectos
pasados) debe haber sido revisada durante los demás procesos de
planificación del proyecto. Esta información también debe estar disponible
durante el desarrollo del plan de proyectos de modo tal de ayudar a verificar
los supuestos y evaluar las alternativas que se identifican como parte de
este proceso.

.3 Políticas Organizacionales. Cualquiera y todas las organizaciones

involucradas en el proyecto tienen políticas formales e informales, cuyos
efectos se deben considerar. Las políticas organizacionales que
comúnmente se deben considerar, incluyen, pero sin limitarse a:
. La gestión de calidad – auditorías a procesos, metas de
mejoramiento continuo.
. La administración de personal – pautas de contratación y de despido,
revisiones de desempeño de empleados.
. Controles financieros – reportes de tiempo, revisiones de gastos y
desembolsos requeridos, códigos contables, disposiciones contractuales
estándares.

.4 Limitaciones. Una limitación es una restricción aplicable que afectará el

rendimiento / desempeño del proyecto. Por ejemplo, un presupuesto
previamente definido es una restricción que es altamente probable que
limite las opciones del equipo respecto del alcance, contratación de
personal y el programa. Cuando se ejecuta un proyecto por contrato, las
disposiciones contractuales constituirán generalmente restricciones.

.5 Supuestos. Los supuestos son factores que, para propósitos de

planificación, se consideran verdaderos, reales o ciertos. Los supuestos
afectan todos los aspectos de planificación del proyecto y, son parte de la
elaboración progresiva del proyecto. Los equipos de proyectos están
frecuentemente identificando, documentando y validando los supuestos,
como parte de su proceso de planificación. Si es incierta la fecha en que
una persona clave estará disponible, el equipo podrá suponer una fecha de
inicio específica. Los supuestos generalmente implican un grado de riesgo.

4.1.2 Herramientas y Técnicas para el Desarrollo del Plan del Proyecto

.1 Metodología de planificación del proyecto. Una metodología de

planificación del proyecto es cualquier enfoque estructurado que se utiliza
para guiar al equipo del proyecto durante el desarrollo del plan del proyecto.
Esta puede ser tan simple como los formularios y plantillas estándares (ya
sea en papel o electrónicas, formales o informales) o tan complejas como
una serie de simulaciones requeridas (por ejemplo, el análisis Monte Carlo
del riesgo del programa). La mayoría de las metodologías de planificación
de proyectos hace uso de una combinación de herramientas “duras”, tales
como el software de gestión de proyectos, y herramientas “blandas” tales
como las reuniones de puesta en marcha.

.2 Habilidades y Conocimiento de los Accionistas. Cada accionista tiene

habilidades y conocimiento que pueden ser útiles en el desarrollo del plan
del proyecto. El equipo de gestión del proyecto debe crear un ambiente en
el que los accionistas / clientes puedan hacer adecuadamente sus aportes
(ver también la Sección 9.3, Desarrollo de Equipos). Variará quién
contribuye, en qué contribuye y cuándo contribuye. Por ejemplo:

. En un proyecto de construcción que se esté realizando bajo un

contrato a suma alzada, el ingeniero de costos profesional hará un aporte
importante al objetivo de rentabilidad durante la preparación de las propuestas,
cuando se esté determinando el monto del contrato.
. En un proyecto donde se define la contratación de personal en forma
anticipada, los individuos pueden contribuir significativamente al cumplimiento de
los objetivos de costos y de programa, verificando si son o no razonables las
estimaciones de duración y de esfuerzo.

.3 Sistema de información de gestión del proyecto (SIGP). Un SIGP lo

componen las herramientas y técnicas utilizadas para recopilar, integrar y
diseminar los resultados de los procesos de gestión del proyecto. Este se
utiliza para respaldar todos los aspectos del proyecto desde la iniciación al
cierre, y puede incluir tanto sistemas manuales como automatizados.
.4 Gestión del valor ganado (GVG). Una técnica empleada para integrar el
alcance, el programa y los recursos del proyecto y para medir y reportar el
rendimiento del proyecto desde la iniciación a cierre. Mayores descripciones
sobre la GVG puede hallarlas en la Sección 7.4.2.3.

4.1.3 Consecuencias del Desarrollo del Plan del Proyecto

.1 Plan del Proyecto. El plan del proyecto es un documento formal aprobado

que se utiliza para gestionar la ejecución del proyecto. El programa del
proyecto lista las fechas planificadas para ejecutar las actividades y cumplir
los hitos identificados en el plan del proyecto (ver Sección 6.4.3.1). El plan
y programa del proyecto deben distribuirse según se defina en el plan de
gestión de las comunicaciones (por ejemplo, la gestión de organización
ejecutante puede hacer necesaria una amplia cobertura con poco detalle,
mientras que un contratista podría requerir detalles completos de un solo
tema). En algunas áreas de aplicación, para referirse a este documento se
utiliza el término plan de proyecto integrado.

Se debe hacer una clara distinción entre las pautas de medición del rendimiento
del proyecto y el plan del proyecto. El plan del proyecto es un documento o
recopilación de documentos de qué es lo que se espera deba cambiar con el
tiempo a medida que haya disponible más información acerca del proyecto. Las
pautas de medición de desempeño / rendimiento sólo cambiarán, generalmente,
en forma intermitente, y luego comúnmente sólo en respuesta a un alcance de
trabajo aprobado o de un cambio de prestación.

Existen muchas formas de organizar y de presentar el plan del proyecto, pero

comúnmente éste incluye todo lo que se describe a continuación (estos ítemes se
analizan más elaboradamente en otro punto de este documento):

. Gráfico del proyecto

. Una descripción del enfoque o estrategia de gestión del proyecto (un
resumen de los planes individuales de gestión a partir de las demás áreas de
conocimiento)
. Declaración del alcance, que incluye los objetivos del proyecto y las
prestaciones del mismo.
. La EDT al nivel con que se ejercerá control, como un documento del
alcance de la pauta.
. Las estimaciones de costos, las fechas de inicio y término
programadas (programa), y las asignaciones de responsabilidad para cada una de
las prestaciones dentro de la EDT al nivel con que se ejercerá control.
. Las pautas de medición del rendimiento / desempeño del alcance
técnico, programa y costo – es decir, la línea base del programa (el programa del
proyecto) el la línea base del costo (el presupuesto del proyecto por fases y
tiempo).
. Los principales hitos y fechas establecidas para cada uno de estos.
. El personal clave o requerido y su costo y/o esfuerzo esperado.
. El plan de gestión del riesgo, que incluya: los principales riesgos
(incluidas las restricciones y los supuestos, y las respuestas y contingencias
planificadas (según corresponda) para cada uno.
. Planes de gestión subsidiarios, a saber:

Plan de gestión del alcance (Sección 5.2.3.3)

Plan de gestión del programa (Sección 6.4.3.3)

Plan de gestión de costos (Sección 7.2.3.3)

Plan de gestión de calidad (Sección 8.1.3.1)

Plan de gestión de personal (Sección 9.1.3.2)

Plan de gestión de comunicaciones (Sección 10.1.3.1)

Plan de respuesta al riesgo (Sección 11.5.3.1)

Plan de gestión del abastecimiento (Sección 12.1.3.1)

De ser necesario se podría incluir cada uno de estos planes y con un

grado de detalle al nivel que sea requerido por cada proyecto
específico.
Temas abiertos y decisiones pendientes.

Dentro del plan formal, se deberían incluir otros resultados de la

planificación del proyecto, según sean las necesidades del proyecto
individual. Por ejemplo, el plan de proyecto para un proyecto grande
incluirá generalmente un organigrama del proyecto.

.2 Detalle de respaldo. El detalle de respaldo para el plan del proyecto

incluye:

. Resultados de otros procesos de planificación que no están incluidos

dentro del plan del proyecto.
. Información o documentación adicional generada durante el
desarrollo del plan del proyecto (por ejemplo, las restricciones y supuestos que no
se conocían previamente).
. Documentación sobre normas relevantes.
. Especificaciones de la planificación anterior del desarrollo del
proyecto.

Este material debe organizarse en la medida que sea necesario, de modo

tal de facilitar su uso durante la ejecución del plan del proyecto.

4.2 EJECUCIÓN DEL PLAN DEL PROYECTO

La ejecución del plan del proyecto es el principal proceso para llevar a cabo el plan
del proyecto – la vasta mayoría del presupuesto del proyecto se gastará en la
realización de este proceso. En este proceso, el gerente del proyecto y el equipo
de gestión del proyecto deberán coordinar y dirigir las distintas interfaces técnicas
y organizacionales que existan en el proyecto. Es, precisamente, el proceso del
proyecto que más directamente afectado se ve por parte del área de aplicación del
proyecto, en el sentido de que el producto del proyecto se crea aquí en realidad.
Se debe monitorear continuamente el rendimiento / desempeño con respecto a la
línea base del proyecto, de modo tal que se puedan tomar las acciones correctivas
sobre la base del rendimiento / desempeño real con relación al plan del proyecto.
Para respaldar este análisis, se llevarán a cabo predicciones periódicas de los
resultados finales de costo y programa.

4.2.1 Entradas para la Ejecución del Plan del Proyecto

.1 Plan del proyecto. El plan del proyecto se describe en la Sección 4.1.3.1.

Los planes de gestión subsidiarios (plan de gestión del alcance, plan de
gestión del riesgo, plan de gestión de abastecimiento, plan de gestión de
configuración, etc.) y las bases de medición de rendimiento / desempeño
constituyen las entradas claves para la ejecución del plan del proyecto.
.2 Detalle de respaldo. El detalle de respaldo se describe en la sección
4.1.3.2.
.3 Políticas organizacionales. Las políticas organizacionales se describen en
la Sección 4.1.1.3. Cualquiera o todas las organizaciones involucradas en el
proyecto pueden tener políticas formales e informales que afecten la
ejecución del plan del proyecto.
.4 Acción preventiva. La acción preventiva es todo aquello que reduzca la
probabilidad de consecuencias potenciales de eventos de riesgo para el
 proyecto.
.5 Acción correctiva. La acción correctiva es todo aquello que se realiza para
hacer que el rendimiento del proyecto esperado a futuro, concuerde con el
plan del proyecto. La acción correctiva es una salida o consecuencia de los
distintos procesos de control – como entrada, aquí ésta completa el lazo de
retroalimentación necesario para asegurarla gestión eficaz del proyecto.

4.2.2 Herramientas y Técnicas para la Ejecución del Plan del Proyecto

.1 Habilidades generales de gestión. Las habilidades generales de gestión

como son liderazgo, comunicación y negociación, son esenciales para la
ejecución eficaz y efectiva del plan del proyecto. Las habilidades de gestión
general se describen en la Sección 2.4.
.2 Habilidades y conocimiento del producto. El equipo del proyecto debe
tener acceso a un conjunto adecuado de habilidades y conocimiento del
producto del proyecto. Las habilidades necesarias se definen como parte de
la planificación (especialmente en lo que se refiere a la planificación de
recursos, Sección 7.1) y se entregan a través del proceso de adquisición de
personal (descrita en la Sección 9.2).
.3 Sistema de autorización del trabajo. Un sistema de autorización del
trabajo es un procedimiento formal para sancionar el trabajo del proyecto,
de modo tal de asegurar que el trabajo se realice en el momento preciso y
en la secuencia debida. El principal mecanismo es, por lo general, una
autorización escrita para comenzar el trabajo en una actividad específica o
paquete de trabajo.

El diseño de un sistema de autorización de trabajo debe equilibrar el valor

del control con respecto a los costos de dicho control. Por ejemplo, en
varios proyectos menores, bastarían las autorizaciones verbales.

.4 Reuniones de revisiones de estados. Las reuniones de revisión de

estados son reuniones programadas regularmente que se llevan a cabo
para intercambiar información acerca del proyecto. En la mayoría de los
proyectos, las reuniones de revisión de estados se llevarán a cabo a
distintas frecuencias y en niveles diferentes (por ejemplo, el equipo de
gestión del proyecto puede reunirse solo en forma semanal y
mensualmente con el cliente o usuario).
.5 Sistema de información de gestión del proyecto. Los SIGP se describen
en la Sección 4.1.2.3.
.6 Procedimientos organizacionales. Cualquiera y todas las organizaciones
involucradas en el proyecto pueden tener procedimientos formales e
informales que sean útiles durante la ejecución del proyecto.

4.2.3 Consecuencias de la Ejecución del Plan del Proyecto

.1 Resultados del trabajo. Los resultados del trabajo son las consecuencias
 de las actividades realizadas para llevar a cabo el proyecto. La información
sobre los resultados del trabajo – que prestaciones se han terminado y
cuáles no, hasta qué grado se están cumpliendo las normas de calidad, en
qué costos se ha incurrido o cometido, etc. – se recopila como parte de la
ejecución del plan del proyecto y se ingresa en el proceso de reporte de
rendimiento / desempeño (para una descripción más detallada del informe
de desempeño / rendimiento, sírvase consultar la Sección 10.3). Cabe
señalar que aunque las consecuencias son, a menudo, prestaciones
tangibles como por ejemplo edificios, carreteras, etc., éstas son también a
menudo intangibles como, es el caso, de las personas capacitadas quienes
puede eficaz y efectivamente aplicar dicha capacitación.
.2 Solicitudes de cambio. Las solicitudes de cambio (por ejemplo, para
expandir o contraer el alcance del proyecto, para modificar el costo
[presupuestos] o estimaciones de programa [fechas, etc.] se identifican, con
frecuencia, mientras se lleva a cabo el trabajo del proyecto.
4.3 CONTROL DE CAMBIOS INTEGRADO

El control de cambios integrado tiene que ver con a)influir en los factores que
crean cambios, de modo tal de asegurar que los cambios estén sujetos a
acuerdos, b) determinar que se haya realizado un cambio y, c) gestionar o
manejar los cambios reales cuándo y como estos ocurran. El alcance original
definido para el proyecto junto con la pauta de rendimiento / desempeño integrado
se deben mantener controlando continuamente los cambios a la pauta, ya sea
rechazando nuevos cambios o aprobando cambios e incorporándolos en una
pauta de proyecto revisada. El control de cambios integrado requiere:

. Mantener la integridad de las pautas de medición del rendimiento /

desempeño
. Asegurar que los cambios al alcance del producto se reflejen en la
definición del alcance del proyecto. (La diferencia entre el alcance del producto y
del proyecto se analiza en la introducción al Capítulo 5).
. Coordinar los cambios entre las áreas de conocimiento, como se
ilustra en

la Figura 4-2. Por ejemplo, un cambio al programa propuesto afectará,

ocasionalmente, el costo, el riesgo, la calidad y el personal.
4.3.1 Entradas para el Control de Cambios Integrado

.1 Plan del proyecto. El plan del proyecto establece la base con respecto a la
cual se controlarán los cambios (ver Sección 4.1.3.1).
.2 Reportes de rendimiento / desempeño. Los reportes de rendimiento /
desempeño (descritos en la Sección 10.3) proporcionan información
respecto del rendimiento del proyecto. Estos informes pueden además
alertar al equipo del proyecto sobre temas que podrían causar problemas a
futuro.
.3 Solicitudes de cambio. Las solicitudes de cambio se pueden presentar de
diversas formas – orales o escritas, directas o indirectas, iniciadas interna o
externamente, y ordenadas legalmente u opcionales.

4.3.2 Herramientas y Técnicas para el Control de Cambios Integrado

.1 Sistema de control de cambios. Un sistema de control de cambios es una

compilación de procedimientos documentados formales que definen de qué
manera será monitoreado y evaluado el rendimiento / desempeño del
 proyecto, e incluye los pasos con que se pueden cambiar los documentos
oficinales del proyecto. Esto incluye el papeleo, los sistemas de
seguimiento, procesos y los niveles de autorización necesarios para
autorizarlos cambios.

En muchos casos, la organización ejecutante contará con un sistema de

control de cambios que pueda adoptarse “tal cual es” para que sea utilizado
por el proyecto. Sin embargo, en caso de no contar con un sistema
adecuado, el equipo de gestión del proyecto tendrá que desarrollar uno
como parte del proyecto.

Hay muchos sistemas de control de cambios que incluyen a un grupo

responsable de aprobar o rechazar los cambios que se propongan. Los
roles y responsabilidades de estos grupos están claramente definidos
dentro del sistema de control de cambios y son acordados por todos los
accionistas claves. Las organizaciones son distintas según sea la definición
del directorio; sin embargo, algunas ocurrencias comunes son el Consejo
de Control de Configuraciones (DCC), el Consejo de Revisión de Ingeniería
(CRI), el Consejo de Evaluación Técnica (CET) y una variedad de otros. El
sistema de control de cambios debe también incluir los procedimientos para
manejar los cambios que puedan ser aprobados sin la revisión previa, por
ejemplo, como resultado de emergencias. Comúnmente, un sistema de
control de cambios deberá permitir la aprobación “automática” de categorías
definidas de cambios. Aún así estos cambios deben estar documentados y
registrados de modo tal de que sea posible documentar la evolución de la
línea base.
.2 Gestión de la configuración. La gestión de configuración es cualquier
procedimiento documentado que se utilice para aplicar direccionamiento y
vigilancia técnica y administrativa para:

. Identificar y documentar las características funcionales y físicas de

un ítem o sistema.
. Controlar cualquier cambio en dichas características.
. Registrar e informar el cambio y su estado de implementación.
. Revisar los ítemes y el sistema de forma tal de verificar el
cumplimiento de los requerimientos.

En muchas áreas de aplicación, la gestión de configuración es un

subconjunto del sistema de control de cambios y se utiliza para asegurar
que la descripción del producto del proyecto sea correcta y completa. En
otras áreas de aplicación, el control de cambio se refiere a cualquier
esfuerzo sistemático para controlar el cambio del proyecto.
.3 Medición del rendimiento / desempeño. Las técnicas de medición del
rendimiento / desempeño como es el caso del VG (descrita en la Sección
10.3.2.4) ayudan a evaluar si los desvíos del plan requieren o no una acción
correctiva.
 .4 Planificación adicional. Los proyectos rara vez se desarrollan
exactamente a como se establece en el plan. Los cambios potenciales
pueden hacer necesario estimaciones de costos nuevas o revisadas,
secuencias modificadas de actividades, programas, requerimientos de
recursos, análisis de alternativas de respuesta al riesgo, u otros ajustes al
plan del proyecto.
.5 Sistema de información de gestión del proyecto. El SIGP se describe en
la Sección 4.1.2.3.

4.3.3 Resultados del Control de Cambios Integrado

.1 Actualizaciones del plan del proyecto. Las actualizaciones del plan del
proyecto son cualquier modificación a los contenidos del plan del proyecto
o al detalle de respaldo (descrito en las Secciones 4.1.3.1 y 4.1.3.2,
respectivamente). Según sea necesario, se deberá notificar a los
accionistas correspondientes.
.2 Acción correctiva. La acción correctiva se describe en la Sección 4.2.1.5.
.3 Lecciones aprendidas. Las causas de las varianzas, el razonamiento que
exista detrás de la acción correctiva que se haya elegido, y otros tipos de
lecciones aprendidas, deberán ser documentadas de modo tal que pasen a
ser parte de la base de datos histórica tanto para este proyecto como para
otros proyectos de la organización ejecutante. La base de datos representa,
además, la base para la gestión del conocimiento.

Gestión del Alcance del Proyecto

La gestión del alcance del proyecto incluye los procesos requeridos para asegurar
que el proyecto incluya todo el trabajo requerido, y solamente el trabajo requerido,
de manera tal de completar exitosamente el proyecto (1). Este vela principalmente
por definir y controlar lo que se incluye y lo que no se incluye en el proyecto. La
Figura 5-1 presenta una descripción de los principales procesos de gestión del
alcance del proyecto:

1. 5.1 Iniciación – autorizar el proyecto o fase.

2. 5.2 Planificación del Alcance -desarrollar una declaración escrita del
alcance como base para futuras decisiones del proyecto.
3. 5.3 Definición del Alcance – subdividir las principales prestaciones del
proyecto en componentes más pequeños y manejables.
4. 5.4 Verificación del Alcance – formalizar la aceptación del alcance del
proyecto.
5. 5.5 Control de Cambio del Alcance -controlar los cambios en el
alcance del proyecto.
Estos procesos interactúan unos con otros y con los procesos de las demás áreas
de conocimiento también. Cada proceso puede involucrar el esfuerzo de uno o
más individuos o grupos de individuos, según sean las necesidades del proyecto.
Cada proceso tiene lugar, generalmente, al menos una vez en cada fase del
proyecto.

Aunque los procesos se presentan aquí como componentes discretos con

interfaces bien definidas, en la práctica estos pueden traslaparse e interactuar de
formas que aquí no se detallan. Las interacciones de los procesos se analizan
detalladamente en el Capítulo 3.

En el contexto del proyecto, el término alcance puede referirse a:

. Alcance del producto – las características y funciones que

caracterizan a un producto o servicio.
. Alcance del proyecto – el trabajo que se debe ejecutar para proveer
un producto con las características y funciones especificadas.

Los procesos, herramientas y técnicas empleadas para gestionar el alcance del

proyecto constituyen el enfoque central de este capítulo. Los procesos,
herramientas y técnicas empleadas para gestionar el alcance del producto varían
según su área de aplicación y son definidas, generalmente, como parte del ciclo
de vida del proyecto (el ciclo de vida del proyecto se describe en la Sección 2.1).

Un proyecto da origen, generalmente, a un solo producto, aunque ese producto

puede incluir componentes subsidiarios, cada uno con sus propios alcances de
producto separados pero independientes. Por ejemplo, un nuevo sistema
telefónico incluiría, por lo general, cuatro componentes subsidiarios – hardware,
software, capacitación e implementación.
El logro del alcance del proyecto se mide con respecto al plan del proyecto, pero el
logro del alcance del producto se mide en relación a los requerimientos del
producto. Ambos tipos de gestión del alcance deben estar bien integradas de
modo tal de asegurar que el trabajo del proyecto de cómo resultado la provisión
del producto especificado.
5.1 INICIACIÓN

La iniciación es el proceso de autorizar formalmente un nuevo proyecto o la de

permitir que un proyecto ya existente continúe en su fase siguiente (en cuanto al
detalle de las fases del proyecto, ver Sección 2.1). Esta iniciación formal vincula el
proyecto con el trabajo continuo de la organización ejecutante. En algunas
organizaciones, un proyecto no se inicia formalmente sino hasta haber
completado una evaluación de las necesidades, un estudio de factibilidad, un plan
preliminar o alguna otra forma equivalente de análisis que haya sido iniciado por si
mismo en forma separada. Algunos tipos de proyectos, especialmente aquellos de
servicios internos y los proyectos de desarrollo de nuevos productos, se inician
informalmente y, se lleva a cabo cierta cantidad de trabajo limitado con el fin de
asegurar las aprobaciones necesarias para la iniciación formal. Los proyectos se
autorizan, comúnmente, como resultado de una o más de lo siguiente:

. Una demanda de mercado (por ejemplo, una fabrica automotriz

autoriza un proyecto para fabricar autos más económicos en el consumo de
combustible en respuesta a la escasez de gasolina).
. Una necesidad del negocio (por ejemplo, una compañía eléctrica
autoriza un proyecto para construir una nueva subestación para abastecer un
nuevo parque industrial).
. Un desarrollo tecnológico (por ejemplo, una empresa electrónica
autoriza un proyecto para desarrollar una consola de video juego luego de haber
logrado mejorar las memorias de las computadoras).
. Un requerimiento legal (por ejemplo, un fabricante de pinturas
autoriza un proyecto para establecer las pautas para la manipulación de
materiales tóxicos).
. Una necesidad social (por ejemplo, una organización no
gubernamental de un país en desarrollo autoriza un proyecto para proveer de
sistemas de agua potable, alcantarillados y educación sanitaria a las comunidades
de bajos ingresos que sufren de altos índices de cólera).

Estos estímulos pueden ser llamados también problemas, oportunidades o

requerimientos de negocios. El tema central de todos estos términos es que la
gestión debe, generalmente, tomar una decisión respecto de como responder ante
ellos.
5.1.1 Entradas para la Iniciación

.1 Descripción del producto. La descripción del producto documenta las

características del producto o servicio cuya creación asume el proyecto. La
descripción del producto tendrá, generalmente menos detalles en sus
primeras fases y más detalle en las fases posteriores, a medida que se
vayan elaborando progresivamente las características del producto.

La descripción del producto debe documentar además la relación entre el

producto o servicio que se esté creando y la necesidad del negocio u otro
estímulo que haya dado lugar al proyecto (ver listado en la Sección 5.1).
Aun cuando la forma y la esencia de la descripción del producto pueden
variar, ésta debe ser siempre lo suficientemente detallada como para servir
de soporte en la posterior planificación del proyecto.

Muchos proyectos implican una organización (el vendedor) que realiza el

trabajo por medio de un contrato con otro (el comprador). En tales
circunstancias, la descripción inicial del producto es proporcionada,
generalmente, por el comprador.

.2 Plan estratégico. Todos los proyectos deben respaldar las metas

estratégicas de la organización ejecutante – el plan estratégico de la
organización ejecutante debe considerarse como un factor en las
decisiones de selección del proyecto.
.3 Criterios de selección de proyectos. Los criterios de selección del
proyecto se definen comúnmente en términos de los méritos del producto
del proyecto y, pueden abarcar todo el rango posible de inquietudes de
gestión (retorno financiero, participación de mercado, percepciones
públicas, etc.).
.4 Información histórica. La información histórica tanto de los resultados de
las decisiones de selección previas del proyecto como del rendimiento /

desempeño anterior del proyecto, debe ser objeto de consideración siempre

y cuando ésta se encuentre disponible. Cuando la iniciación implica la
aprobación para la siguiente fase de un proyecto, a menudo es crítica la
información referente a los resultados de las fases anteriores.
5.1.2 Herramientas y Técnicas para la Iniciación

.1 Métodos de selección de proyectos. Los métodos de selección de

proyectos implican medir el valor o el atractivo que éste tiene para el dueño
del proyecto. Los métodos de selección del proyecto incluyen considerar el
criterio de decisión (en caso de utilizar criterios múltiples, estos deben
combinarse en una sola función de valor) y una forma de calcular el valor
en condiciones de incertidumbre. Estos se conocen como modelo de
decisión y método de cálculo. La selección del proyecto se aplica también a
la selección de las formas alternativas de realizar el proyecto. Se pueden
utilizar las herramientas de optimización con el objeto de investigar la
combinación óptima de las variables de decisión. Los métodos de selección
de proyectos se clasifican, generalmente, en una de dos amplias categorías
(2):

Métodos de medición del beneficio – enfoques comparativos, modelos de

ponderación, aporte de beneficio o modelos económicos. Métodos de
optimización restringida – modelos matemáticos que utilizan algoritmos
lineales, no lineales, dinámicos, integrales y de programación multi-
objetivos.

Estos métodos se conocen, con frecuencia, como modelos de decisión. Los

modelos de decisión incluyen técnicas generalizadas (Árboles de Decisión,
Selección Forzada y otros), como así también algunos especializados
(Proceso de Jerarquías Analíticas, Análisis de Estructuras Lógicas, y otros).
La aplicación de criterios complejos de selección de proyectos en un
modelo sofisticado es, frecuentemente, tema de una fase de proyecto
aparte.

.2 Juicio experto. A menudo, será necesario el juicio experto con el fin de

evaluar las entradas para este proceso. Dicha experticia puede ser
proporcionada por cualquier grupo o individuo con conocimiento o
entrenamiento especializado, y se puede obtener de muchas fuentes, que
incluyen:

. Otras unidades dentro de la organización ejecutante.

. Consultores
. Accionistas, incluidos los clientes.
. Asociaciones profesionales y técnicas
. Grupos industriales.

5.1.3 Resultados de la Iniciación

.1 Permiso legal del proyecto. Un permiso legal del proyecto es un

documento que autoriza formalmente un proyecto. Este debe incluir, ya sea
directamente o por referencia, otros documentos:
. La necesidad del negocio que pretende abordar el proyecto en
cuestión.
. La descripción del producto (descrita en la Sección 5.1.1.1).

El permiso legal debe ser emitido por una gerente externo al proyecto y, a
un nivel adecuado a las necesidades del proyecto. Este otorga al gerente
del proyecto la autoridad para aplicar los recursos organizacionales a las
actividades del proyecto.

Cuando se ejecuta un proyecto por medio de un contrato, el contrato

firmado servirá, generalmente, como permiso legal del proyecto para el
vendedor.

.2 Gerente de proyecto identificado / asignado. En general, el gerente de

proyecto debe ser identificado y designado tan anticipadamente como sea
posible en el proyecto. El gerente del proyecto debe ser designado siempre
antes de que se inicie la ejecución del plan del proyecto (descrito en la
Sección 4.2) y preferiblemente antes de que se haya realizado gran parte
de la planificación del proyecto (los procesos de planificación del proyecto
se describen en la Sección 3.3.2).
.3 Restricciones. Las restricciones son factores que limitarán las opciones del
equipo de gestión del proyecto. Por ejemplo, un presupuesto previamente
definido es una restricción que es altamente probable que limite las
opciones del equipo respecto del alcance, contratación de personal y el
programa.

Cuando se ejecuta un proyecto por contrato, las disposiciones contractuales

constituirán generalmente restricciones. Otro ejemplo es un requerimiento
de que el producto del proyecto sea social, económica y ambientalmente
sustentable, lo que también afectará el alcance, el personal y el programa
del proyecto.

.4 Supuestos. Ver Sección 4.1.1.5.

5.2 PLANIFICACIÓN DEL ALCANCE

La planificación del alcance es el proceso de elaborar y documentar

progresivamente el trabajo del proyecto (alcance del proyecto) que da lugar al
producto del proyecto. La planificación del alcance del proyecto comienza con las
entradas iniciales de la descripción del producto, el permiso legal del proyecto y la
definición inicial de las restricciones y supuestos. Cabe indicar que la descripción
del proyecto incorpora los requerimientos del producto que refleja las necesidades
del cliente que se han acordado y el diseño del producto que cumple con los
requerimientos del producto. Los resultados o consecuencias de la planificación
del alcance son la declaración del alcance y el plan de gestión del alcance, junto el
detalle de respaldo. La declaración del alcance forma la base de un acuerdo entre
el proyecto y el cliente del proyecto, identificando tanto los objetivos del proyecto
como las prestaciones del mismo. Los equipos de proyecto desarrollan múltiples
declaraciones de alcance que son las adecuadas para el nivel de descomposición
del trabajo del proyecto.

5.2.1 Entradas para la Planificación del Alcance

.1 Descripción del producto. La descripción del producto se analiza en la

Sección 5.1.1.1.
.2 Permiso legal del proyecto. El permiso legal del proyecto se describe en
la Sección 5.1.3.1.
.3 Restricciones. Las restricciones se describen en la Sección 5.1.3.3.
.4 Supuestos. Los supuestos se describen en la Sección
4.1.1.5.

5.2.2 Herramientas y Técnicas para la Planificación del Alcance

.1 Análisis del producto. El análisis del producto implica desarrollar una

mejor comprensión del producto del proyecto. Este incluye técnicas tales
como ingeniería de sistemas de análisis desglosado del producto,
ingeniería del valor, análisis del valor, análisis de funciones y despliegue de
funciones de calidad.
.2 Análisis costo / beneficio. El análisis costo / beneficio implica estimar los
costos tangibles e intangibles (gastos) y los beneficios (retornos) de las
distintas alternativas de proyectos y productos, y luego usar las medidas
financieras, como es el caso del retorno sobre la inversión o el periodo de
amortización, para evaluar el anhelo o deseo relativo de las alternativas
identificadas.
.3 Identificación de alternativas. Este es un términos general para cualquier
técnica empleada para generar diferentes metodologías para el proyecto.
Existe un variedad de técnicas generales de gestión comúnmente utilizadas
para este caso, siendo las más típicas la inspiración súbita y el
pensamiento lateral.
.4 Juicio experto. El juicio experto se describe en la Sección 5.1.2.2.

5.2.3 Resultados de la Planificación del Alcance

 .1 Declaración del Alcance. La declaración del alcance establece una base
documentada para tomar las futuras decisiones del proyecto y para
confirmar o desarrollar una comprensión común del alcance del proyecto
entre los accionistas. A medida que avanza el proyecto, puede llegar a ser
necesaria una revisión o un refinamiento de la declaración del alcance, con
el objeto de reflejar los cambios aprobados al alcance del proyecto. La
declaración del alcance debe incluir, ya sea en forma directa o por
referencia a otros documentos:

. La justificación del proyecto – la necesidad del negocio que el

proyecto pretende abordar. La justificación del proyecto sienta la base para
evaluar las futuras compensaciones.
. El producto del proyecto. Un breve resumen de la descripción del
producto (la descripción del producto se analiza en la Sección 5.1.1.1).
. Las prestaciones del proyecto – un listado de los subproductos a
nivel de resumen, cuya provisión completa o satisfactoria marca el término del
proyecto. Por ejemplo, las principales prestaciones para un proyecto de desarrollo
de software podrían incluir el código de operación de la computadora, un manual
de usuario y una guía de operación interactiva. Cuando sean conocidas, se deben
identificar las exclusiones, pero todo aquello que no sea incluido explícitamente
queda implícitamente excluido.
. Los objetivos del proyecto – los criterios cuantificables que se deben
cumplir para que el proyecto pueda ser considerado como exitoso. Los objetivos
del proyecto deben incluir al menos el costo, el programa y las medidas de
calidad. Los objetivos del proyecto deben tener un atributo (por ejemplo, costo),
una métrica (por ejemplo, dólares americanos (US$)) y, un valor absoluto o
relativo (por ejemplo, menos de 1.5 millón). Los objetivos no cuantificados

(por ejemplo, “la satisfacción del cliente”) conllevan un alto riesgo

para el logro exitoso.

.2 Detalle de respaldo. El detalle de respaldo para la declaración del alcance

debe documentarse y organizarse según sea necesario para facilitar su uso
por parte de otros procesos de gestión del proyecto. El detalle de respaldo
debe incluir siempre la documentación de todas las restricciones y
supuestos que se hayan identificado. La cantidad adicionadle detalle puede
variar según el área de aplicación.
.3 Plan de gestión del alcance. Este documento describe de qué forma se
gestionará el alcance del proyecto y cómo se integrarán los cambios de
alcance en el proyecto. Este debe incluir también una evaluación de la
estabilidad esperada del alcance del proyecto (es decir, qué probabilidad
tiene de cambiar, con qué frecuencia, y cuánto). El plan de gestión del
alcance también debe incluir una descripción clara de cómo se identificar y
clasificar los cambios de alcance. (Esto es particularmente difícil – y por lo
tanto absolutamente esencial – cuando todavía se están elaborando las
características del producto).
 Un plan de gestión del alcance puede ser formal o informal, altamente
detallado o ampliamente estructurado, según las necesidades del proyecto.
Se trata pues de un componente subsidiario del plan del proyecto (descrito
en la Sección 4.1.3.1).

5.3 DEFINICIÓN DEL ALCANCE

La definición del alcance implica la subdivisión de las principales prestaciones del

proyecto (según lo identificado en la declaración del alcance, como se definiera en
la Sección 5.2.3.1) en componentes más pequeños y más manejables, con el
objeto de:

. Mejorar la precisión en las estimaciones de costo, duración y

recursos.
. Definir una base para la medición y control del rendimiento /
desempeño.
. Facilitar las claras asignaciones de responsabilidades.

La adecuada definición del alcance es crítica para el éxito del proyecto. “Cuando
hay una mala o inadecuada definición del alcance, se puede esperar que los
costos finales del proyecto sean mayores, debido a cambios inevitables que
interrumpen el ritmo del proyecto, provocan la reelaboración, aumentan el tiempo
del proyecto y reducen la productividad y la moral de la fuerza laboral” (3).

5.3.1 Entradas para la Definición del Alcance

.1 Declaración del alcance. La declaración del alcance se describe en la

Sección 5.2.3.1.
.2 Restricciones. Las restricciones se describen en la Sección 5.1.3.3.
Cuando se ejecuta un proyecto por contrato, las restricciones definidas por
las disposiciones contractuales son, a menudo, importantes
consideraciones durante la definición del alcance.
.3 Supuestos. Los supuestos se describen en la Sección 4.1.1.5.
.4 Otros resultados de la planificación. Se deben revisar las salidas o
resultados de los procesos de otras áreas de conocimiento, de modo tal de
verificar el posible impacto en la definición del alcance del proyecto.
 .5 Información histórica. Durante la definición del alcance, se debe
considerar la información histórica respecto de proyectos anteriores. La
información respecto de errores u omisiones en proyectos previos debe ser
especialmente útil.

5.3.2 Herramientas y Técnicas para la Definición del Alcance

.1 Plantillas de estructuras de división del trabajo. La EDT (que se

describe en la Sección 5.3.3.1) de un proyecto anterior, puede ser utilizada
a menudo como plantilla para un nuevo proyecto. Aun cuando cada
proyecto es único, a menudo es posible “reutilizar” las EDT’s dado que la
mayoría de los proyectos serán, de cierto modo, similares a otros. Por
ejemplo, gran parte de los proyectos de una determinada organización
tendrán ciclos de vida de proyectos iguales o similares y, por lo tanto,
tendrán las mismas prestaciones u otras similares a las requeridas de cada
fase.

Muchas áreas de aplicación u organizaciones ejecutantes tienen EDT’s

estándares o semi-estándares que se pueden utilizar como plantillas. Por
ejemplo, el Departamento de Defensa de los Estados Unidos ha
recomendado EDT’s estándares para los Ítemes de Materiales de Defensa
(MIL-HDBK-881). La Figura 5-2 muestra una parte de una de estas plantillas.

.2 Descomposición. La descomposición implica subdividir las principales

 prestaciones o sub-prestaciones del proyecto en componentes más
pequeños y más manejables, hasta que se definan las prestaciones con
suficiente nivel de detalle como para respaldar el desarrollo de las
actividades del proyecto (planificación, ejecución, control y término). La
descomposición implica los principales pasos que a continuación se
indican:

.(1) Identificar las principales prestaciones del proyecto, incluida la gestión del
proyecto. Las principales prestaciones deben definirse siempre en términos de
cómo se organizará realmente el proyecto. Por ejemplo:
. Se pueden utilizar las fases del ciclo de vida del proyecto como
primer nivel de descomposición, repitiendo las prestaciones del proyecto en el
segundo nivel, como se ilustra en la Figura 5-3.
. El principio de organización dentro de cada rama de la EDT’s puede
variar, como se ilustra en la Figura 5-4.
.(2) Decidir si se pueden desarrollar estimaciones de costos y duración
adecuadas con este nivel de detalle para cada una de las prestaciones. El
significado de adecuado puede cambiar durante el curso del proyecto – la
descomposición de una prestación que ocurrirá muy a futuro no puede ser posible.
Para cada prestación, proceda con el Paso 4, si existiera suficiente detalle, con el
Paso 3 si no lo hubiera – esto significa que diferentes prestaciones pueden tener
distintos niveles de descomposición.
.(3) Identificar los componentes que formen parte de la prestación. Estos
componentes se deben describir en términos de resultados tangibles y
verificables, con el objeto de facilitar la medición del rendimiento / desempeño.
Como con los principales componentes los componentes que forman parte de la
prestación se deben definir en términos de cómo se organizará realmente el
trabajo del proyecto y del trabajo del proyecto que se haya llevado a cabo. Los
resultados tangibles y verificables pueden incluir tanto servicios como productos
(por ejemplo, se puede describir el reporte de estado o de avances como informes
semanales de estados o avances; para un ítem fabricado, los componentes
constituyentes podrían incluir varios componentes individuales más el montaje
final). Repita el Paso 2 en cada componente constituyente.
.(4) Verificar que la descomposición se haya realizado correctamente:
. ¿Son los ítemes de menor nivel tanto necesarios como suficientes
para completar el ítem descompuesto? Si no fuera así, se deberán modificar los
componentes constituyentes (sumarse a, borrarse de, o redefinirse).
. ¿Se ha definido cada uno de los ítemes clara y completamente? Si
no fuera así, se deberán revisar o expandir las descripciones.
. ¿Es posible programar cada ítem en forma adecuada? ¿Es posible
presupuestarlo? Si fuera asignado a una unidad organizacional específica (por
ejemplo, departamento, equipo o persona), ¿quién aceptará la responsabilidad de
completar satisfactoriamente el ítem? Si no fuera así, se deberán realizar las
revisiones que sean necesarias para proveer el adecuado control de la gestión.
5.3.3 Resultados de la Definición del Alcance

.1 Estructura de división del trabajo. Una EDT es una agrupación orientada

a la prestación de los componentes del proyecto, la cual organiza y define
el alcance total del proyecto; todo trabajo que no esté contemplado en la
EDT está fuera del alcance del proyecto. Al igual que la declaración del
alcance, la EDT se utiliza, con frecuencia, para desarrollar o confirmar una
comprensión común del alcance del proyecto. Cada nivel descendente
representa una descripción significativamente detalla de las prestaciones
del proyecto. La Sección 5.3.2.2 describe la metodología más común para
desarrollar una EDT. La EDT se presenta normalmente en forma de
diagrama, como se ilustra en las Figuras 5-2, 5-3 y 5-4. Sin embargo, no
se debe confundir la EDT con el método de presentación – el hecho de
dibujar una lista de actividades sin estructuración en forma de diagrama no
hace de ésta una EDT.

A cada ítem de la EDT se le asigna generalmente un identificador único;

estos identificadores pueden establecer una estructura para una sumatoria
 jerárquica de los costos y recursos. Los ítemes del nivel más bajo de la EDT
pueden ser referidos como paquetes de trabajo, especialmente en aquellas
organizaciones que siguen prácticas de gestión por valor ganado. Estos
paquetes de trabajo pueden, a su vez, seguir descomponiéndose en una
estructura de división del trabajo del subproyecto. Por lo general, este tipo
de metodología se utiliza cuando se le asigna al gerente del proyecto un
alcance de proyecto para otra organización, y esta otra organización debe
planificar y gestionar el alcance del trabajo a un nivel más detallado que el
gerente de proyecto en el proyecto principal. Estos paquetes de trabajo
pueden seguir descomponiéndose en el plan y programa del proyecto,
según como se describe en las Secciones 5.3.2.2 y 6.1.2.1.

Las descripciones de los componentes del trabajo son, a menudo,

recopilados en un diccionario de EDT’s. Este diccionario de EDT’s incluirá,
comúnmente, las descripciones de los paquetes de trabajo, como así
también otra información de planificación como son las fechas de
programas, los presupuestos de costos y las designaciones de personal.

No se debe confundir la EDT con otros tipos de estructuras de “división”

utilizadas para presentar la información del proyecto. Entre las demás
estructuras que se utilizan típicamente en alguna área de aplicación se
incluyen:

. La EDT contractual (EDTC), que se utiliza para definir el nivel de

reporte que el vendedor proveerá al comprador. La EDTC incluye, por lo general,
menos detalle que la EDT utilizada por el vendedor para gestionar el trabajo de
éste.
. La estructura de división organizacional (EDO), que se utiliza para
mostrar cuáles componentes del trabajo se han asignado a qué unidades
organizacionales.
. La estructura de división de los recursos (EDR), que es una variación
de la EDO y se utiliza comúnmente cuando se asignan componentes de trabajo a
individuos.
. El listado de materiales (LDM), que representa una visión jerárquica
de los conjuntos físicos, subconjuntos y componentes necesarios para fabricar un
producto manufacturado.
. La estructura de división del proyecto (EDP), que es
fundamentalmente los mismo que una EDT correctamente realizada. El término
EDP es empleado ampliamente en áreas de aplicación donde se utiliza
incorrectamente la EDT para referirse a un LDM.

.2 Actualizaciones de la declaración del alcance. Incluye cualquier

modificación de los contenidos de la declaración del alcance (descritos en
la Sección 5.2.3.1). Se debe notificar a los accionistas que corresponda,
según sea necesario.
5.4 VERIFICACIÓN DEL ALCANCE

La verificación del alcance es el proceso de obtención de la aceptación formal del

alcance del proyecto por parte de los accionistas (auspiciador, cliente, cliente,
etc.). Esto hace necesario la revisión de las prestaciones y los resultados del
trabajo, de forma tal de asegurarse de que todos hayan sido completados correcta
y satisfactoriamente. Si se termina anticipadamente el proyecto, el proceso de
verificación del alcance debe establecer y documentar el nivel y porcentaje de
cumplimiento. La verificación del alcance se diferencia del control de calidad
(descrita en la Sección 8.3) en el sentido de que se preocupa principalmente de la
aceptación de los resultados del trabajo, mientras que el control de calidad tiene
que ver principalmente con lo correcto de los resultados del trabajo. Estos
procesos se desarrollan, generalmente, en paralelo, de forma tal de garantizar su
corrección y aceptación.

5.4.1 Entradas para la Verificación del Alcance

.1 Resultados del trabajo. Los resultados del trabajo – cuáles prestaciones

se han completado total o parcialmente – son una consecuencia de la
ejecución del plan del proyecto (que se describe en la Sección 4.2).
.2 Documentación del producto. Los documentos producidos para describir
los productos del proyecto deben estar disponibles para su revisión. Los
términos empleados para describir esta documentación (planes,
especificaciones, documentación técnica, planos, etc.) varía según el área
de aplicación.
.3 Estructura de división del trabajo. La EDT ayuda en la definición del
alcance y se debe utilizar para verificar el trabajo del proyecto (ver Sección
5.3.3.1).
.4 Declaración del alcance. La declaración del alcance define el alcance con
cierto nivel de detalle, y por lo tanto se debe verificar (ver Sección 5.2.3.1).
.5 Plan del proyecto. El plan del proyecto se describe en la Sección
4.1.3.1.

5.4.2 Herramientas y Técnicas para la Verificación del Alcance

 .1 Inspección. La inspección incluye aquellas actividades como la medición,
evaluación y prueba, que se llevan a cabo con el objeto de determinar si los
resultados conforman o no los requerimientos. Las inspecciones reciben,
variadamente, los nombres de revisiones, revisiones de producto y
auditorías; en algunas áreas de aplicación, estos diferentes términos tienen
significados más específicos.

5.4.3 Resultados de la Verificación del Alcance

.1 Aceptación formal. Se debe preparar y distribuir aquella

documentación de que el cliente o el auspiciador ha aceptado el
producto de la fase del proyecto o la(s) principal(es) prestación(es).
Dicha aceptación debe ser condicional, especialmente al final de una
fase.

5.5 CONTROL DE CAMBIO DEL ALCANCE

El control de cambio del alcance tiene que ver con (a) influenciar los factores que
crean cambios de alcance, de tal manera de asegurar que se acuerden los
cambios; (b) determinar que se ha producido el cambio del alcance, y (c) manejar
los cambios reales cuando y si estos ocurren. El control de cambio del alcance
debe estar completa y cabalmente integrado con los demás procesos de
control(control de programa, control de costos, control de calidad y otros, de la
forma como se describe en la Sección 4.3).

5.5.1 Entradas para el Control de Cambio del Alcance

.1 Estructura de división del trabajo. La EDT se describe en la Sección

5.3.3.1. Esta define la base del alcance del proyecto.
.2 Informes de rendimiento / desempeño. Los informes de rendimiento,
analizados en la Sección 10.3.3.1, proporcionan información sobre el
rendimiento del alcance, como por ejemplo cuáles prestaciones internas se
han completado y cuáles no. Los informes de rendimiento pueden, además,
alertar al equipo del proyecto sobre temas que pudieran causar problemas
en el futuro.
.3 Solicitudes de cambio. Las solicitudes de cambio se pueden presentar de
varias maneras – oral o escrita, directa o indirecta, iniciada en forma
 externa o interna, por mandato legal u opcional. Los cambios pueden
requerir la expansión del alcance o bien pueden permitir la reducción de
éste. La mayoría de las solicitudes de cambio son resultado de:

. Un evento externo (por ejemplo, un cambio en una regulación

gubernamental).
. Un error u omisión en la definición del alcance del producto (por
ejemplo, la no inclusión de una característica requerida en el diseño de un sistema
de telecomunicaciones).
. Un error u omisión en la definición del alcance del proyecto (por
ejemplo, la utilización de una LDM en lugar de una EDT9.
. Un cambio de valor agregado (por ejemplo, un proyecto
gubernamental de compensación puede reducir los costos, tomando ventaja de la
tecnología que no estaba disponible cuando se definiera originalmente el alcance).
. Implementación de un plan de contingencia o plan de emergencia
para responder a un riesgo, tal como se describe en la Sección

11.6.3.3.

.4 Plan de gestión del alcance. El plan de gestión del alcance se describe en

la Sección 5.2.3.3.
5.5.2 Herramientas y Técnicas para el Control de Cambio del Alcance

.6 El control de cambio del alcance. Un control de cambio del alcance

define los procedimientos por medio de los cuales se puede modificar el
alcance del proyecto. Este incluye el papeleo los sistemas de seguimiento,
procesos y los niveles de autorización necesarios para autorizarlos
cambios. El control de cambio del alcance debe integrarse con el control
integrado de cambios, descrito en la Sección 4.3 y, en particular, con
cualquier sistema o sistemas establecidos tendiente a controlar el alcance
del producto. Cuando se ejecuta un proyecto por medio de un contrato, el
control de cambio del alcance debe cumplir, además, con todas las
disposiciones contractuales aplicables.
.7 Medición del rendimiento. Las técnicas de medición del rendimiento /
desempeño, descritas en la Sección 10.3.2, ayudan a evaluar la magnitud
de cualquier variación que si ocurra. Determinar qué está causando la
varianza en relación a la base y, decidir si la varianza requiere o no de una
acción correctiva, son todas partes importantes del control de cambio del
alcance.
.8 Planificación adicional. Son pocos los proyectos que se desarrollan
exactamente de conformidad con un plan. Los potenciales cambios de
alcance pueden requerir modificaciones en las EDT’s o en análisis de
enfoques alternativos (ver Secciones 5.3.3.1 y 5.2.2.3, respectivamente).

5.5.3 Resultados del Control de Cambio del Alcance

 .1 Cambios de alcance. Un cambio de alcance es cualquier modificación con
el alcance acordado del proyecto, como lo define la EDT aprobado. Los
cambios de alcance requieren, frecuentemente, de ajustes en términos de
costo, tiempo, calidad u otros objetivos del proyecto.

Los cambios de alcance del proyecto se vuelven a introducir en el proceso de

planificación y se actualizan los documentos técnicos y de planificación según
sea necesario, además de notificar a los accionistas que corresponda.

.2 Acción correctiva. La acción correctiva es todo aquello que se realiza para

alinear el rendimiento de proyecto esperado a futuro con el plan del
proyecto.
.3 Lecciones aprendidas. Las causas de las varianzas, el razonamiento
detrás de la acción correctiva elegida, y otros tipos de lecciones aprendidas
a partir del cambio de control del alcance, todo se debe documentar, de
modo tal que la información pase a ser parte de la base de datos histórica
tanto de este proyecto como de otros proyectos de la organización
ejecutante.
.4 Base ajustada. Dependiendo de la naturaleza del cambio, se debe revisar y
reeditar el documento base correspondiente de modo tal de reflejar el cambio
aprobado y formar la nueva base de referencia para futuros cambios.

Gestión del Tiempo del Proyecto

La gestión del tiempo del proyecto incluye los procesos requeridos para asegurar
que el proyecto se complete a tiempo o puntualmente. La Figura 6-1 presenta una
descripción general de los principales procesos involucrados en el desarrollo del
programa o calendario del proyecto, que se indican a continuación:

1. 6.1 Definición de las Actividades -identificar las actividades

específicas que se deben desarrollar a fin de producir las distintas prestaciones
del proyecto.
2. 6.2 Secuencia de las Actividades -identificar y documentar
interactivamente las relaciones de dependencia.
3. 6.3 Estimación de la Duración de las Actividades -estimar el número
de periodos de trabajo que serán necesarios para completar las actividades
individuales.
4. 6.4 Desarrollo del Programa -analizar las secuencias de actividades,
duraciones y requerimientos de recursos a fin de crear el programa del proyecto.
5. 6.5 Control del Programa – controlar los cambios al programa del
proyecto.
Estos procesos interactúan unos con otros y con los procesos de las demás áreas
de conocimiento también. Cada proceso puede involucrar el esfuerzo de uno o
más individuos o grupos de individuos, según sean las necesidades del proyecto.
Cada proceso tiene lugar, generalmente, al menos una vez en cada fase del
proyecto.

Aunque los procesos se presentan aquí como componentes discretos con

interfaces bien definidas, en la práctica estos pueden traslaparse e interactuar de
formas que aquí no se detallan. Las interacciones de los procesos se analizan
detalladamente en el Capítulo 3.

En algunos proyectos, especialmente en los más pequeños, la secuencia de las

actividades, la estimación de la duración de las actividades y el desarrollo del
programa están tan estrechamente ligados que son considerados como un solo
proceso (por ejemplo, pueden ser desarrollados por un solo individuo durante un
periodo de tiempo relativamente corto). Aquí se les presenta como procesos
diferentes, debido a que las herramientas y técnicas para cada uno son diferentes.
6.1 DEFINICIÓN DE LAS ACTIVIDADES

La definición de las actividades implica la identificación y documentación de las

actividades específicas que se deberán ejecutan con el objeto de producir las
prestaciones y subprestaciones identificadas en la Estructura de División del
Trabajo (EDT). Este proceso tiene implícita la necesidad de definir las actividades,
de modo tal que se cumplan los objetivos del proyecto.

6.1.1 Entradas para la Definición de las Actividades

.6 Estructura de división del trabajo. La EDT constituye la principal entrada

para la definición de las actividades (para una descripción más detallada de
la EDT, sírvase consultar la Sección 5.3.3.1).
.7 Declaración del alcance. Durante la definición de las actividades, se
deben considerar explícitamente la justificación del proyecto y los objetivos
del mismo contenidos en la declaración del alcance. (Para más detalles
sobre la declaración del alcance, ver Sección 5.2.3.1).
.8 Información histórica. En la definición de las actividades del proyecto, se
debe considerar la información histórica (cuáles fueron las actividades que
realmente fueron necesarias en proyectos previos similares).
.9 Restricciones. Las restricciones son aquellos factores que limitarán las
opciones del equipo de gestión del proyecto; un ejemplo podría ser el uso
de las máximas duraciones deseadas para las actividades.
.10 Supuestos. Ver Sección 4.1.1.5.
.11 Juicio experto. El juicio experto se analiza en las Secciones 5.1.2.2 y
6.3.2.1.

6.1.2 Herramientas y Técnicas para la Definición de las Actividades

.1 Descomposición. Dentro del contexto del proceso de Definición de las

Actividades, la descomposición implica subdividir los paquetes de trabajo
del proyecto en componentes más pequeños y más manejables, a fin de
permitir un mejor control de gestión. La técnica de descomposición se
describe con más detalles en la Sección 5.3.2.2. La principal diferencia
entre la modalidad de descomposición que tratamos aquí y la descrita en la
Definición del Alcance, está en que las consecuencias o resultados finales
en este caso se describen como actividades en vez de cómo prestaciones.
La EDT y la lista de actividades se desarrollan, por lo general, en forma
 secuencial, siendo la EDT la base de desarrollo de la lista final de
actividades. En algunas áreas de aplicación, la EDT y la lista de
actividades se desarrollan de manera concurrente.
.2 Plantillas. A menudo, se utiliza como plantilla para un nuevo proyecto una
lista de actividades (descrita en la Sección 6.1.3.1) o una parte de la lista de
actividades de un proyecto anterior. Las actividades de las plantillas pueden
contener, también, una lista de las habilidades (recursos) y sus horas de
trabajo requeridas, una identificación de los riesgos, las prestaciones
esperadas y cualquier otra información descriptiva.

6.1.3 Resultados de la Definición de Actividades

.1 Lista de actividades. La lista de actividades debe incluir todas las

actividades que se llevarán a cabo en el proyecto. Esta debe organizarse
como una extensión de la EDT, a fin de ayudar a garantizar que ésta se
encuentre completa, y que no incluye ninguna actividad que no sea
requerida como parte del alcance del proyecto. Como con la EDT, la lista de
actividades debe incluir descripciones de cada actividad, a fin de
asegurarse de que los miembros del equipo del proyecto entienda cómo se
va a realizar el trabajo.
.2 Detalle de respaldo. El detalle de respaldo para la lista de actividades
debe documentarse y organizarse según sea necesario para facilitar su uso
por parte de los demás procesos de gestión del proyecto. El detalle de
respaldo debe incluir siempre la documentación de todas las restricciones y
supuestos que se hayan identificado. La cantidad adicional de detalle puede
variar según el área de aplicación.
.3 Actualizaciones de la estructura de división del trabajo. Al utilizar la
EDT para identificar qué actividades son necesarias, el equipo del proyecto
puede identificar aquellas prestaciones que falten o bien puede determinar
que es necesario aclarar o corregir las descripciones de las prestaciones.
Cualquiera de tales actualizaciones debe reflejarse en la EDT y en toda
documentación relacionada, como por ejemplo las estimaciones de costos.
Estas actualizaciones son llamadas, con frecuencia, refinamientos y son
más probables cuando el proyecto conlleva una tecnología nueva o no
probada con anterioridad.

6.2 SECUENCIA DE LAS ACTIVIDADES

La secuencia de las actividades implica identificar y documentar las relaciones

lógicas interactividades. Las actividades se deben secuenciar de manera exacta, a
fin de respaldar el posterior desarrollo de un programa realista y alcanzable.
Esta secuencia se puede llevar a cabo con la ayuda de un computador (por
ejemplo, utilizando el software de gestión de proyectos) o bien por medio de
técnicas manuales. A menudo, las técnicas manuales son más efectivas en
proyectos más pequeños y en las primeras etapas o fases de aquellos proyectos
de mayor envergadura, cuando se dispone de poco detalle. También es posible
utilizar las técnicas manuales y automatizadas en forma combinada.

6.2.1 Entradas para la Secuencia de las Actividades

.1 Lista de actividades. La lista de actividades se describe en la Sección

6.1.3.1.
.2 Descripción del producto. La descripción del producto se describe en la
Sección 5.1.1.1. Con frecuencia, la secuencia de las actividades se ve
afectada por las características del producto (por ejemplo, la distribución
física de una planta a construir, las interfaces de subsistemas en un
proyecto de software). Aun cuando estos efectos son, la mayor de las
veces, aparentes en la lista de actividades, por lo general se debe revisar la
descripción del producto a fin de garantizar la precisión.
.3 Relaciones de dependencia obligada. Las relaciones de dependencia
obligada son aquellas que son inherentes a la naturaleza del trabajo que se
está realizando. A menudo, se trata de limitaciones físicas. (En un proyecto
de construcción, es imposible edificar la superestructura sino hasta después
que se haya construido la fundación; en un proyecto electrónico, se debe
construir un prototipo antes de que se pueda probar). Las relaciones de
dependencia obligada son conocidas también como lógica dura.
.4 Relaciones de dependencia discreta. Las relaciones de dependencia
discreta son aquellas que son definidas por el equipo de gestión del
proyecto. Estas deben utilizarse con cuidado (y deben ser documentadas
completamente), ya que pueden llegar a limitar más adelante las opciones
de programación. Las relaciones de dependencia discreta se definen,
comúnmente, basándose en el conocimiento que se tenga de:

. “Las mejores prácticas” dentro de un área de aplicación particular.

. Cierto aspecto inusual del proyecto donde se desea una secuencia
específica, aunque existan otras secuencias aceptables.

Las relaciones de dependencia discreta pueden ser denominadas también

como lógica preferida, lógica preferencial o lógica blanda.

.5 Relaciones de dependencia externa. Las relaciones de dependencia

 externa son aquellas que implican una relación entre las actividades del
proyecto y las actividades que no guardan relación alguna con el proyecto.
Por ejemplo, la actividad de prueba o evaluación de un proyecto de
software puede ser dependiente de la entrega de hardware de parte de una
fuente externa, o bien es posible que sea necesario realizar audiencias
ambientales antes de que puede iniciarse la preparación del área en un
proyecto de construcción.
.6 Hitos. Es necesario que los hitos o eventos más importantes sean parte de
la secuencia de actividades a fin de asegurar que se cumplan los
requerimientos para el(los) hito(s).

6.2.2 Herramientas y Técnicas para la Secuencia de las Actividades

.1 Método de diagramación de precedencias (MDP). Este es un método de

construcción de un diagrama de red de proyecto que utiliza cuadros o
rectángulos (nodos) para representar las actividades y las conecta con
flechas que muestran las relaciones de dependencia (ver también la
Sección 6.2.3.1). La Figura 6-2 muestra un diagrama lógico de red simple
utilizando el MDP. Esta técnica se conoce también como actividad en nodo
(AON)y es el método empleado por la mayoría de los paquetes de software
sobre gestión de proyectos. El MDP se puede llevar a cabo en forma
manual o bien en un computador.

Este método incluye cuatro tipos de relaciones de dependencia o

precedencia:
. Terminar-para-comenzar – el inicio del trabajo del sucesor depende
del término del trabajo del predecesor.
. Terminar-para-terminar –el término del trabajo del sucesor depende
del término del trabajo del predecesor.
. Comenzar-para-comenzar – el inicio del trabajo del sucesor depende
del inicio del trabajo del predecesor.
. Comenzar-para terminar – el término del sucesor es dependiente del
inicio del predecesor.

En el MDP, se utiliza más comúnmente el tipo de relación lógica terminar-para-

comenzar. Las relaciones comenzar-para-terminar son rara vez empleadas, y
son la mayor de las veces sólo utilizadas por ingenieros profesionales en
programación de proyectos. La utilización de las relaciones comenzar-para-
comenzar, terminar-para-terminar o comenzar-para-terminar con el software de
gestión de proyectos pueden dar lugar a resultados inesperados, dado que
estos tipos de relaciones no han sido implementadas de manera consistente.

.2 Método de diagramación con flechas (MDF). Este método de

construcción de un diagrama de red de proyecto utiliza flechas para
representar las actividades y las conecta en los nodos para demostrar sus
relaciones de dependencia (ver también la Sección 6.2.3.1). La Figura 6-3
muestra un diagrama lógico de red simple, que se dibujó utilizando MDF.
Esta técnica se conoce también como actividad-en-la-flecha (AOA) y,
aunque es menos común que la MDP, sigue siendo la técnica predilecta en
algunas áreas de aplicación. El MDF utiliza únicamente relaciones de
dependencia terminar-para-empezar y puede requerir el uso de actividades
reiterativas con el objeto de definir correctamente todas las relaciones
lógicas. El MDF puede realizarse manualmente o en un computador.
.3 Métodos de diagramación condicional. Las técnicas de diagramación
tales como la Técnica de Revisión y Evaluación Gráfica (TREG) y los
modelos de Dinámica de Sistemas, permiten desarrollar actividades no-
secuenciales como lazos (“loops”) (por ejemplo, una prueba que se debe
repetir más de una vez) o ramas condicionales (por ejemplo, una
actualización de diseño que sólo es necesaria si la inspección detecta
errores). Ni el MDF ni el MDP permiten lazos o ramas condicionales.
.4 Plantillas de red. Con el objeto de acelerar la preparación de los
diagramas de red del proyecto, es posible recurrir redes estandarizadas.
Estas pueden incluir un proyecto completo o bien sólo una parte de éste.
Las partes de una red se conocen a menudo como subredes o fragnets.
Las subredes son especialmente útiles cuando un proyecto incluye varias
características idénticas o casi idénticas, tales como los pisos de un edificio
de oficinas, los ensayos clínicos de un proyecto de investigación
farmacéutica, los módulos de programación de un proyecto de software o la
fase de puesta en marcha de un proyecto de desarrollo.
6.2.3 Resultados de la Secuencia de las Actividades

.1 Diagramas de redes del proyecto. Los diagramas de red del proyecto son
despliegues esquemáticos de las actividades del proyecto y las relaciones
lógicas (de dependencia) entre ellas. Las Figuras 6-2 y 6-3 ilustran dos
metodologías diferentes para dibujar un diagrama de red del proyecto. El
diagrama de red del proyecto se puede producir manualmente
o por medio de un computador. Este puede incluir detalles acabados del
proyecto, o bien puede tener una o más actividades resumidas. El
diagrama debe ir acompañado de una descripción resumida (narrativa) que
defina el enfoque básico de la secuencia. Se deberá describir
completamente cualquier secuencia inusual.

El diagrama de red del proyecto se denomina, comúnmente, como gráfico

PERT. Históricamente el PERT (Técnica de Evaluación y Revisión de
Programa) fue el tipo específico de diagrama de red (ver también la Sección
6.4.2.1).
.2 Actualizaciones de la lista de actividades. En gran parte de la misma
manera que el proceso de definición de actividades puede generar
actualizaciones a la EDT, la preparación de los diagramas de red del
proyecto puede revelar instancias en donde se deba dividir una actividad o,
en otro sentido, se deba redefinir a fin de diagramar las relaciones lógicas
correctas.

6.3 ESTIMACIÓN DE LA DURACIÓN DE LAS ACTIVIDADES

La estimación de la duración de las actividades es el proceso de tomar

información sobre el alcance del proyecto y de los recursos y, luego, desarrollar
las duraciones para ingresarlas en los programas. Las entradas para las
estimaciones de duración se originan, comúnmente, a partir de la persona o grupo
del equipo del proyecto que está más familiarizado con la naturaleza de una
actividad específica. La estimación se elabora, a menudo, en forma progresiva, y
el proceso considera la calidad y la disponibilidad de la información de entrada.
Así, es posible suponer que la estimación será progresivamente más exacta y de
calidad conocida. La persona o grupo del equipo del proyecto que esté más
familiarizado con la naturaleza de una actividad específica debe llevar a cabo, o al
menos aprobar, la estimación.

La estimación de la cantidad de periodos de trabajo requeridos para completar una

actividad requerirán, a menudo, también de la consideración del tiempo
transcurrido. Por ejemplo, si el “fraguado del hormigón” requerirá de cuatro días de
tiempo transcurrido, es probable que sean necesarios de dos a cuatro periodos de
trabajo, sobre la base de (a) qué día de la semana se inicia, y (b) si los fines de
semana son o no tratados como periodos de trabajo. La mayoría del software de
programación computarizado manejará este problema, utilizando calendarios
alternativos de periodos de trabajo.
La duración global del proyecto se puede estimar, utilizando las herramientas y
técnicas aquí presentadas, pero se calcula más adecuadamente como
consecuencia del desarrollo del programa (descrito en la Sección 6.4). El equipo
del proyecto puede considerar la duración del proyecto como una distribución de
probabilidades (utilizando técnicas probabilísticas) o bien como una estimación de
un solo punto (utilizando técnicas determinísticas).

6.3.1 Entradas para la Estimación de la Duración de las Actividades

.1 Lista de actividades. La lista de actividades se describe en la Sección

6.1.3.1. .2 Restricciones. Las restricciones se describen en la Sección
6.1.1.4. .3 Supuestos. Los supuestos se describen en la Sección 4.1.1.5. Un
ejemplo
de ellos podrían ser los periodos de reporte por la duración del proyecto
que podrían determinan las duraciones máximas; es decir, dos periodos de
reporte.
.4 Requerimientos de recursos. Los requerimientos de recursos se
describen en la Sección 7.1.3.1. La duración de la mayoría de las
actividades se verá significativamente influenciada por los recursos que se
les asignen. Por ejemplo, dos personas que trabajen juntas pueden ser
capaces de completar una actividad de diseño en la mitad del tiempo que
les demoraría si lo hicieran en forma individual, en tanto que una persona
que trabaje medio tiempo en una actividad generalmente demoraría, al
menos, el doble del tiempo que la misma persona trabajando a tiempo
completo. No obstante, a medida que se van agregando recursos
adicionales, los proyectos pueden experimentar una sobrecarga
comunicacional que reduce la productividad y que hace que la producción
mejore proporcionalmente menos que el incremento en los recursos.
.5 Capacidades de los recursos. La duración de la mayoría de las
actividades se verá significativamente influenciada por las capacidades de
los recursos humanos y materiales que se les asignen. Por ejemplo, si
ambos fueran asignados a tiempo completo, se puede esperar, por lo
general, que un miembro antiguo del personal complete una determinada
actividad en menos tiempo que un miembro más nuevo.
.6 Información histórica. La información histórica sobre las duraciones
 probables de muchas categorías de actividades, es posible de obtener, con
frecuencia, a partir de una o más de las siguientes fuentes:

. Archivos del proyecto – es probable que una o más organizaciones

involucradas en el proyecto mantenga registros de resultados previos del proyecto,
que estén lo suficientemente detallados como para servir de ayuda en el desarrollo
de estimaciones de duración. En algunas áreas de aplicación, los miembros
individuales del equipo pueden mantener tales registros.
. Bases de datos comerciales de estimaciones de duración – con
frecuencia, la información histórica se encuentra comercialmente disponible.
Estas bases de datos tienden a ser específicamente útiles cuando las duraciones
de las actividades no son impulsadas por el contenido real del trabajo (por
ejemplo, cuánto demora el hormigón en fraguarse; cuánto demora, por lo general,
una agencia estatal en responder a ciertos tipos de solicitudes).
. Conocimiento del equipo del proyecto – los miembros individuales
del equipo del proyecto pueden recordar realidades o estimaciones anteriores.
Aun cuando dichas recopilaciones pueden ser útiles, éstas son significativamente
menos confiables que los resultados documentados.

.7 Riesgos identificados. El equipo del proyecto considera la información

sobre riesgos identificados (ver Sección 11.2) al momento de producir las
estimaciones de duración de las actividades, ya que los riesgos (ya sean
amenazas u oportunidades) pueden tener una influencia significativa en la
duración. El equipo del proyecto considera hasta qué grado se incluye el
efecto de los riesgos en la estimación base de la duración de cada
actividad, incluidos los riesgos con altas probabilidades o impacto.

6.3.2 Herramientas y Técnicas para la Estimación de Duración de las

Actividades

.1 Juicio experto. El juicio experto se describe en la Sección 5.1.2.2. Las

duraciones son, a menudo, difíciles de estimar, debido a la serie de factores
que pueden influenciarlas (por ejemplo, los niveles de recursos, la
productividad de los recursos). Toda vez que sea posible, se debe recurrir
al juicio experto guiado por la información histórica. Si no se cuenta con
dicha experticia, las estimaciones serán inherentemente inciertas y
riesgosas (ver Capítulo 11, Gestión del Riesgo del Proyecto).
.2 Estimación análoga. La estimación análoga, también conocida como
estimación de arriba-hacia-abajo, significa utilizar la duración real de una
actividad previa similar como base para estimar la duración de una
actividad futura. Se le utiliza frecuentemente para estimar la duración del
proyecto cuando existe una cantidad limitada de información detallada
acerca del proyecto (por ejemplo, en las primeras fases). La estimación
análoga es una forma de juicio experto (descrito en la Sección 6.3.2.1).

La estimación análoga es más confiable cuando (a) las actividades previas

 son similares de hecho y no sólo en apariencia y, (b) los individuos que
preparan las estimaciones reúnen la experticia necesaria.

.3 Duraciones cuantitativamente basadas. Para estimar las duraciones de

las actividades, se pueden utilizar las cantidades a realizar para cada
categoría específica de trabajo (es decir, el número de dibujos, metros de
cable, toneladas de acero, etc.) definidas por ingeniería / diseño, cuando se
multiplica por la tarifa o precio unitario de productividad (es decir, horas por
dibujo, metros de cable por hora, etc.).
.4 Tiempo de reserva (contingencia). Los equipos de proyectos pueden
optar por incorporar una fracción de tiempo adicional, denominada tiempo
de reserva, contingencia o buffer, que se puede sumar a la duración de la
actividad o a otra parte del programa, como un reconocimiento del riesgo
del programa. Este tiempo de reserva puede ser un porcentaje de la
duración estimada, o bien un número fijo de periodos de trabajo. Más
adelante, se puede reducir o eliminar el tiempo de reserva, en la medida
que se disponga de información más precisa acerca del proyecto. Dicho
tiempo de reserva debe documentarse junto con cualquier otra información
y supuesto.

6.3.3 Resultados de la Estimación de Duración de las Actividades

.1 Estimaciones de duración de las actividades. Las estimaciones de

duración de las actividades son evaluaciones cuantitativas del número
probable de periodos de trabajo que se requerirán para completar una
actividad.

Las estimaciones de duración de las actividades deben incluir siempre

cierta indicación del rango de los posibles resultados. Por ejemplo:

. 2 semanas + 2 días para indicar que la actividad demorará, al

menos, ocho días y no más de doce (suponiendo una semana laboral de 5 días).
. Probabilidad de 15 por ciento de exceder las tres semanas, a fin de
indicar una alta probabilidad – 85 por ciento – de que la actividad demorará tres
semanas o menos.

El Capítulo 11 referido a la Gestión del Riesgo del Proyecto incluye un

análisis más detallado de la incertidumbre de la estimación.

.2 Bases de las estimaciones. Se deben documentar los supuestos

realizados en el desarrollo de las estimaciones. .3
Actualizaciones de la lista de actividades. Las actualizaciones
de la lista de actividades se describen en la Sección 6.2.3.2.

6.4 DESARROLLO DEL PROGRAMA

Desarrollo del programa significa determinar las fechas de inicio y término de las
actividades del proyecto. Si no son realistas las fechas de inicio y término,
entonces es improbable que el proyecto se termine de acuerdo a lo programado.
El proceso de desarrollo del programa debe ser, a menudo, iterativo (junto con los
procesos que proveen las entradas, especialmente el de estimación de las
duraciones y el de estimación de costos) en forma previa a la determinación del
programa del proyecto.

6.4.1 Entradas para el Desarrollo del Programa

.1 Diagramas de red del proyecto. Los diagramas de red del

proyecto se describen en la Sección 6.2.3.1. .2 Estimaciones
de duración de las actividades. Las estimaciones de
duración de las actividades se describen en la Sección
6.3.3.1.
.3 Requerimientos de recursos. Los requerimientos de recursos se describen en
la Sección 6.3.1.4.

.4 Descripción del pool de recursos. El desarrollo del programa requiere el

conocimiento de cuáles serán los recursos disponibles en qué momentos y
en que patrones. Por ejemplo, los recursos críticos o compartidos pueden
ser especialmente difíciles de programar, dado que su disponibilidad puede
ser altamente variable. La cantidad de detalle y el nivel de especificidad en
la descripción del pool de recursos será variable. Por ejemplo, sólo se
necesita conocer que habrá dos consultores disponibles en una fracción
particular de tiempo para el desarrollo preliminar del programa de un
proyecto de consultoría. Sin embargo, el programa final del mismo proyecto
identifica qué consultores estarán disponibles específicamente.
.5 Calendarios. Los calendarios del proyecto y de los recursos identifican los
periodos en que se autorizará el trabajo. Los calendarios de proyecto
afectan a todos los recursos (por ejemplo, algunos proyectos sólo se
desarrollarán durante horario normal de oficina, mientras que otros lo harán
en tres turnos completos). Una semana de cinco días hábiles es un ejemplo
del uso del calendario. Los calendarios de recursos afectan a un recurso
específico o categoría de recursos (por ejemplo, un miembro del equipo del
 proyecto puede estar en vacaciones o bien en un programa de
capacitación; un contrato de trabajo puede limitarse a ciertos trabajadores
durante ciertos días de la semana).
.6 Restricciones. Las restricciones son aquellos factores que limitarán las
opciones del equipo de gestión del proyecto. Existen dos categorías
principales de restricciones de tiempo que se consideran durante el
desarrollo del programa:

Fechas impuestas –las fechas impuestas para el inicio o término de

las actividades pueden ser utilizadas para restringir que el inicio o término ocurran,
ya sea, no antes de una fecha específica o bien no más allá de una fecha
determinada. Aun cuando las cuatro restricciones de fechas se encuentran
comúnmente disponibles en el software de gestión de proyectos, las restricciones
“Comenzar No
Antes de” y “Terminar No Más Allá de” son los tipos más típicamente
empleados. Los usos típicos de las restricciones de fechas incluyen situaciones
tales como un nicho de mercado en un proyecto tecnológico, las restricciones
climáticas para las actividades a la intemperie, el acatamiento de mandatos
gubernamentales con solución a problemas ambientales, la entrega de material de
parte de terceras partes que no están representadas en el programa del proyecto,
etc.
. Eventos claves o principales hitos -el auspiciador del proyecto, el
cliente o cualquier otro accionista del proyecto, puede requerir el término de
ciertas prestaciones en una fecha específica. Una vez programadas, estas fechas
son inamovibles y, a menudo, sólo pueden ser modificadas con gran dificultad. Los
hitos se pueden utilizar, además, para indicar interfaces con trabajo fuera del
proyecto. Dicho trabajo no está, comúnmente, incorporado dentro de la base de
datos del proyecto y, los hitos con las fechas de restricción pueden convertirse en
interfaces adecuadas para el programa.

.7 Supuestos: Ver Sección 4.1.1.5.

.8 Adelantos y atrasos. Toda relación de dependencia puede requerir de la
especificación de un adelanto o de un atraso para definir con exactitud la
relación. Un ejemplo de atraso: podría haber un deseo de programar una
demora (atraso) de dos semanas, entre la orden de una pieza de equipo y
la instalación o uso de ésta. Un ejemplo de un adelanto, en una relación de
dependencia terminar-para-empezar con un adelanto de diez días: la
actividad sucesora comienza diez días antes que se haya terminado la
actividad predecesora.
.9 Plan de gestión del riesgo. El plan de gestión del riesgo se analiza en la
Sección 11.1.3.
.10 Atributos de las actividades. Los atributos de las actividades – incluida la
responsabilidad (es decir, quién realizará el trabajo), el área geográfica o
lugar (dónde se va a ejecutar el trabajo) y el tipo de actividad (es decir, un
resumen o detalle) – son consideraciones muy importantes para continuar
con la selección y clasificación de las actividades planificadas en forma
 conveniente para los usuarios. La clasificación de la EDT es también un
atributo importante que permite la clasificación y ordenamiento expedito de
las actividades.

6.4.2 Herramientas y Técnicas para el Desarrollo del Programa

.1 Análisis matemático. El análisis matemático implica calcular las fechas de

inicio y término adelantadas y atrasadas teóricas para todas las actividades
del proyecto sin considerar ninguna limitación en el pool de recursos. Las
fechas resultantes no constituyen el programa, sino que más bien indican
los periodos de tiempo dentro de los cuales se podría programar la
actividad, dados los límites de recursos y otras restricciones conocidas. Las
técnicas de análisis matemático más ampliamente conocidas son:

. El Método de Trayectorias Críticas (MTC) – calcula una sola fecha

de inicio y término adelantada o atrasada determinística para cada actividad,
basándose en la lógica de red secuencial específica y en una sola estimación de
duración. El enfoque del MTC está en calcular el punto flotante para determinar
cuáles son las actividades que tienen la menor flexibilidad de programación. Los
algoritmos básicos del MTC son a menudo utilizados en otros tipos de análisis
matemático.
. Técnica de Evaluación y Revisión Gráfica (TERG) –permite el
tratamiento probabilístico tanto de la lógica de red como de las estimaciones de
duración de las actividades (es decir, algunas actividades no se ejecutarán en
absoluto, algunas pueden ser desarrolladas sólo en parte, y otras pueden ser
ejecutadas más de una vez).

La Técnica de Evaluación y Revisión de Programa (TERP [PERT]) –

utiliza una estimación de duración de promedio ponderado para calcular
las duraciones de las actividades. Aunque existen diferencias
superficiales, PERT se diferencia de MTC principalmente en que ésta
utiliza la media de la distribución (valor esperado) en lugar de la
estimación más probable utilizada originalmente en el método MTC (ver
Figura 6-4). La PERT como tal es rara vez utilizada en la actualidad.

.2 Compresión de la duración. La compresión de la duración es un caso

específico de análisis matemático que busca los medios para acortar el
programa del proyecto sin cambiar el alcance del mismo (por ejemplo, para
cumplir las fechas impuestas u otros objetivos del programa). La compresión
de la duración incluye el uso de técnicas tales como:

. Comprensión intensiva (“Crashing”) – en la que se analizan las

compensaciones de costo y programa a fin de determinar cómo, si es el todo
posible, obtener la mayor cantidad de compresión al menos costo incremental. La
compresión intensiva no siempre produce una alternativa viable y resulta, a
menudo, en un mayor costo.
. Compresión por vía rápida (“Fast Track”) – realizarlas actividades en
paralelo en lugar de cómo se harían normalmente en secuencia (por ejemplo,
comenzar a escribir el código de un proyecto de software antes de que se
complete el diseño, o comenzar a construir la fundación de una planta de
procesamiento de petróleo antes de alcanzar el punto de ingeniería del 25 por
ciento). La vía rápida a menudo tiene como

consecuencia la reejecución de la actividad y usualmente aumenta el

riesgo.

.3 Simulación. La simulación implica calcular múltiples duraciones del

proyecto con diferentes conjuntos de supuestos de actividades. La técnica
más común es el Análisis de Monte Carlo, en el que se define la distribución
de los resultados probables para el total del proyecto (ver también la
Sección 11.4.2.4). Además, se pueden utilizar análisis “que pasaría si”,
utilizando la red lógica para simular diferentes escenarios, como por
ejemplo demorar la entrega de un componente importante, prolongar las
duraciones de ingeniería específica o introducir factores externos (como por
ejemplo, una huelga o un cambio en el proceso de solicitud de permisos).
La consecuencia o resultado de las simulaciones qué-pasaría-si pueden
utilizarse para evaluar la factibilidad del programa en condiciones adversas,
y en la preparación de planes de respuesta / contingencia para superar o
mitigar el impacto de situaciones inesperadas.
.4 Heurística de nivelación de recursos. El análisis matemático a menudo
produce un programa preliminar de inicio adelantado que requiere de mayores
recursos que los disponibles durante ciertos periodos de tiempo,
o que requiere cambios en los niveles de recursos que no son manejables. La
Heurística, como por ejemplo, “asignar los recursos escasos primero a aquellas
actividades de trayectorias críticas”, puede aplicarse para desarrollar un
programa que refleje tales restricciones. La nivelación de recursos a menudo
da lugar a una duración de proyecto que es mayor que el programa preliminar.
Esta técnica recibe el nombre, a veces, de método a base de recursos,
especialmente cuando se implementa con optimización computarizada. La
reasignación de recursos a partir de actividades nocríticas a actividades
críticas, es una forma común de atrasar el programa o, de llevarlo lo más cerca
posible, a su duración global que se pretendiera originalmente. También se
debe considerar la utilización de horas de sobretiempo, fines de semana, o
turnos múltiples, con el objeto de reducir las duraciones de las actividades
críticas. Los incrementos en productividad basados en el uso de diferentes
tecnologías y/o maquinarias (es decir, soldadura automática, cortadoras
eléctricas de cañerías, etc.) son otra forma de acortar las duraciones que han
extendido el programa preliminar. La vía rápida (fast tracking), si fuera factible
(de acuerdo a lo descrito en la Sección 6.4.2.2), es otra forma de reducir la
duración global del proyecto. Algunos proyectos pueden tener un recurso de
proyecto finito y crítico, que exige que este recurso se programa a la inversa, a
partir de la fecha de término del proyecto; esto se conoce como programación
por asignación invertida de recursos. La cadena crítica es una técnica que
modifica el programa del proyecto con el objeto de considerar aquellos
recursos limitados.
 .5 Software de gestión de proyectos. El software de gestión de proyectos es
ampliamente utilizado para facilitar el desarrollo del programa. Existen otros
software que pueden ser capaces de interactuar directa o indirectamente
entre ellos mismos, o con otros software, con el propósito de llevar a cabo
los requerimientos de otras áreas de conocimiento. Estos productos
automatizan el cálculo del análisis matemático y de la nivelación de los
recursos, y permiten así una rápida consideración de muchas alternativas
de programas. Estos paquetes de software son utilizados ampliamente para
imprimir o desplegar las salidas del desarrollo del programa.
.6 Estructura de codificación. Las actividades deben contar con una
estructura de codificación que permita la clasificación y/o extracciones
basándose en los diferentes atributos asignados a las actividades, como
por ejemplo, responsabilidad, área geográfica o lugar, fase del proyecto,
nivel del programa, tipo de actividad y clasificación de la EDT.

6.4.3 Resultados del Desarrollo del Programa

.1 Programa del proyecto. El programa del proyecto incluye, al menos, las

fechas de inicio planificada y de término esperada. (Nota: El programa del
proyecto permanece como preliminar hasta que se hayan confirmado las
asignaciones de recursos. Esto debería suceder no más halladle término
del Desarrollo del Plan del Proyecto, Sección 4.1).
 El programa del proyecto se puede presentar en forma resumida (el programa
maestro), o en detalle. Aunque se puede presentar en forma
tabulada, se presenta más frecuentemente en forma gráfica, utilizando uno
o más de los siguientes formatos:

. Diagramas de red del proyecto con información agregada de fechas

(ver Figura 6-5). Estos gráficos muestran generalmente tanto la lógica del
proyecto como las actividades de trayectoria crítica del proyecto (para más
información sobre los diagramas de red del proyecto, sírvase consultar la Sección
6.2.3.1).
. Gráficos de barras, también llamados cartas Gantt (ver Figura 6-6),
muestran las fechas de inicio y término de la actividad, como así también las
duraciones esperadas, y a veces muestran las relaciones de dependencia. Estos
gráficos son relativamente fáciles de leer, y son frecuentemente utilizados en
presentaciones gerenciales.
. Gráficos de hitos (ver Figura 6-7) son similares a los gráficos de
barras, pero sólo identifican el inicio programado o el término de las principales
prestaciones y las interfaces externas claves.
.2 Detalle de respaldo. El detalle de respaldo para el programa del proyecto
incluye al menos aquella documentación de todos los supuestos y restricciones
que se hayan identificado. La cantidad de detalle adicional varía según el área
de aplicación. Por ejemplo:

. En un proyecto de construcción, es muy probable que se incluyan

aquellos ítemes tales como histogramas de recursos, proyecciones de flujo de caja
y los programas para los despachos de órdenes y las entregas.
. En un proyecto electrónico, es muy probable que se incluyan los
histogramas de recursos solamente. La información frecuentemente suministrada
como detalle de respaldo incluye, pero sin limitarse a ello:

 Los requerimientos de recursos por periodo de tiempo, a

menudo en forma de un histograma de recursos.

 Los programas alternativos (por ejemplo, el mejor o el peor
caso, con recursos nivelados o no, con o sin fechas
impuestas).

 Las reservas por contingencia del programa (ver Sección
11.4).

.3 Plan de gestión del programa. Un plan de gestión de programa define

cómo se gestionarán los cambios al programa. Este puede ser formal o
informal, altamente detallado o ampliamente estructurado, según las
necesidades del proyecto. Se trata de un elemento subsidiario del plan
global del proyecto (ver Sección 4.1).
.4 Actualizaciones de los requerimientos de los recursos. Las
actualizaciones de nivelaciones de recursos pueden tener un efecto
significativo en las estimaciones preliminares de los requerimientos de
recursos.
6.5 CONTROL DEL PROGRAMA

El control del programa tiene que ver con (a) influir en los factores que crean
cambios en el programa, de forma tal de asegurar que tales cambios sean
convenidos, (b) determinar que se haya modificado el programa y, (c) gestionar los
cambios reales cuando y a medida que estos se produzcan. El control del
programa debe integrarse cabalmente con los demás procesos de control, según
lo descrito en la Sección 4.3, Control Integrado de Cambios.

6.5.1 Entradas para el Control del Programa

.1 Programa del proyecto. El programa del proyecto se describe en la

Sección 6.4.3.1. El programa de proyecto aprobado, denominado base del
programa (que debe ser técnicamente factible y estar dado en términos de
los recursos), es un componente del plan del proyecto que se describe en la
Sección 4.1.3.1. Este sienta las bases para medir y reportar el rendimiento /
desempeño del programa.
.2 Informes de rendimiento / desempeño. Los informes de rendimiento /
desempeño, analizados en la Sección 10.3.3.1, suministran información
sobre el rendimiento del programa, como por ejemplo qué fechas
planificadas se han cumplido y cuáles no. Los informes de rendimiento
pueden, además, alertar al equipo del proyecto sobre temas que pueden
llegar a causar problemas en el futuro.
.3 Solicitudes de cambio. Las solicitudes de cambios pueden ocurrir de
varias formas – orales o escritas, directas indirectas, de iniciación externa o
interna y, por mandato legal u opcionales. Los cambios pueden requerir la
ampliación del programa o bien permitir la aceleración de éste (ver Sección
4.3.1.3).
.4 Plan de gestión del programa. El plan de gestión del programa se
describe en la Sección 6.4.3.3.

6.5.2 Herramientas y Técnicas para el Control del Programa

.1 Sistema de control de cambios de programa. Un sistema de control de

cambios de programa define los procedimientos por medio de los cuales se
puede modificar o cambiar el programa del proyecto. Este incluye el
 papeleo, los sistemas de seguimiento y los niveles de aprobación
necesarios para autorizar los cambios. El control de cambios de programa
se debe integrar al sistema de control integrado de cambios que se
describe en la Sección 4.3.
.2 Medición del rendimiento / desempeño. Las técnicas de medición del
rendimiento / desempeño, como aquellas descritas en la Sección 10.3.2,
ayudan a evaluar la magnitud de cualquier variación que llegue a ocurrir.
Una parte importante del control del programa es la de decidir si la variación
del programa requiere de una acción correctiva. Por ejemplo, un atraso
mayor de una actividad no-crítica puede tener un efecto menor en el
proyecto como un todo, mientras que un atraso menos prolongado de una
actividad crítica o casi-crítica puede requerir la aplicación de una acción
inmediata.
.3 Planificación adicional. Son pocos los proyectos que se ejecutan
exactamente de acuerdo a lo planificado. Los cambios potenciales pueden
requerir de estimaciones nuevas o revisadas de duración de las
actividades, secuencias modificadas de las actividades o el análisis de
programas alternativos.
.4 Software de gestión de proyectos. El software de gestión de proyectos se
describe en la Sección 6.4.2.5. La capacidad del software de gestión de
proyectos para hacer un seguimiento de las fechas planificadas versus las
fechas reales y para predecir los efectos de los cambios de programa,
reales o potenciales, lo convierten en una herramienta de mucha utilidad
para el control del programa.
.5 Análisis de la varianza. El rendimiento del análisis de la varianza durante
el proceso de monitoreo del programa es un elemento clave para el control
del tiempo. La comparación de las fechas metas con las fechas de inicio y
término reales / estimadas, proporciona información útil para la detección
de las desviaciones y para la implementación de soluciones correctivas en
caso de atrasos o demoras. La varianza flotante es también un componente
esencial de la planificación, de forma tal de evaluar el rendimiento del
tiempo del proyecto. Se debe prestar una atención especial a las
actividades criticas y sub-críticas (es decir, analizar las diez trayectorias
sub-críticas, con el fin de ascender el punto flotante).

6.5.3 Resultados del Control del Programa

.1 Actualizaciones del programa. Una actualización del programa es

cualquier modificación de la información del programa que se utiliza para
gestionar el proyecto. Se debe notificar de ello a los accionistas
correspondientes, según sea necesario. Las actualizaciones de programa
pueden o no requerir ajustes en otros aspectos del plan del proyecto.

Las revisiones son una categoría especial de actualizaciones de programa.

Las revisiones son los cambios realizados a las fechas de inicio y término
del programa aprobado del proyecto. Estos cambios son, generalmente,
 incorporados en respuesta a los cambios de alcance o a cambios de las
estimaciones. En algunos casos, los atrasos de programa pueden ser tan
graves que hace necesario un replanteamiento de las bases, a fin de
proporcionar información realista para medir el rendimiento. Sin embargo,
se debe ser muy cuidadoso antes de replantear las bases, por cuanto se
perderá información histórica para el programa del proyecto. El
replanteamiento de las bases sólo se debe utilizar como último recurso en
el control del programa; el modo normal de revisión del programa deben ser
nuevos programas metas.

.2 Acción correctiva. La acción correctiva es todo aquello que se realiza

para alinear el rendimiento esperado del programa a futuro con el plan del
proyecto. La acción correctiva en el área de gestión de tiempo implica, a
menudo, emitir: acciones especiales que se llevan a cabo con el objeto de
asegurar el término de una actividad a tiempo o con el menor atraso
posible. La acción correctiva requiere, frecuentemente, el análisis de las
causas básicas, a fin de identificar la causa de la variación, y se puede
planificar y ejecutar la recuperación del programa para aquellas actividades
desalineadas más adelante, y no sólo abordando la actividad que causa la
desviación.
.3 Lecciones aprendidas. Se deben documentar las causas de las variaciones,
el razonamiento que impulsa la acción correctiva elegida y, otros tipos de
lecciones aprendidas del control del programa, de modo tal que éstas sean
incorporadas a la base de datos histórica tanto de este proyecto como de otros
proyectos de la organización ejecutante.

Gestión del Costo del Proyecto

La gestión del costo del proyecto incluye los procesos requeridos para asegurar
que el proyecto se complete dentro del presupuesto aprobado. La Figura 7-1
presenta una descripción general de los principales procesos que se indican a
continuación:

1. 7.1 Planificación de los Recursos – determinar qué recursos

(personas, equipos, materiales) y en qué cantidades de cada uno se deben utilizar
para desarrollar las actividades del proyecto.
2. 7.2 Estimación de los Costos -desarrollar una aproximación
(estimación) de los costos de los recursos necesarios para completar las
actividades del proyecto.
3. 7.3 Presupuestación de los Costos – asignar la estimación de costo
global a las actividades individuales de trabajo.
4. 7.4 Control del Costo – controlar los cambios al presupuesto del
proyecto.

Estos procesos interactúan unos con otros y con los procesos de las demás áreas
de conocimiento también. Cada proceso puede involucrar el esfuerzo de uno o
más individuos o grupos de individuos, según sean las necesidades del proyecto.
Cada proceso tiene lugar, generalmente, al menos una vez en cada fase del
proyecto.

Aunque los procesos se presentan aquí como componentes discretos con

interfaces bien definidas, en la práctica estos pueden traslaparse e interactuar de
formas que aquí no se detallan. Las interacciones de los procesos se analizan
detalladamente en el Capítulo 3.

La gestión del costo del proyecto se preocupa principalmente del costo de los
recursos necesarios para completar las actividades del proyecto. Sin embargo, la
gestión del costo del proyecto debe considerar además el efecto de las decisiones
del proyecto en el costo de utilizar el producto del proyecto. Por ejemplo, limitar el
número de revisiones de diseño puede reducir el costo del proyecto a expensas de
un aumento en los costos de operación del cliente. Esta visión más amplia de la
gestión del costo del proyecto se conoce, a menudo, como costeo del ciclo de
vida. El costeo del ciclo de vida junto con las técnicas de Ingeniería del Valor, se
utilizan con el objeto de reducir el costo y el tiempo, mejorar la calidad y el
rendimiento / desempeño, y optimizar el proceso de toma de decisiones.
En muchas áreas de aplicación, la predicción y el análisis del rendimiento
financiero potencial del producto del proyecto, se lleva a cabo fuera del proyecto.
En otros (por ejemplo, en los proyectos de bienes de capital), la gestión de costo
del proyecto incluye, además, este último trabajo. Cuando se incluyen tales
predicciones y análisis, la gestión del costo del proyecto incluirá los procesos
adicionales y numerosas técnicas de gestión general, tales como el retorno de la
inversión, el flujo de caja descontado, el análisis de amortización y otros.

La gestión del costo del proyecto debe considerar las necesidades de información
de los accionistas del proyecto -distintos accionistas podrían medir los costos del
proyecto de distintas formas y en diferentes momentos. Por ejemplo, el costo de
un ítem de abastecimiento puede medirse al momento de ser comprometido,
ordenado, entregado, incurrido o registrado para propósitos contables.

Cuando se utilizan los costos del proyecto como un componente de un sistema de

compensaciones y reconocimientos (descrito en la Sección 9.3.2.3), se deben
estimar separadamente los costos controlables e incontrolables, de modo tal de
asegurar que las compensaciones reflejen el actual rendimiento / desempeño.

En algunos proyectos, especialmente en los más pequeños, la planificación de los

recursos, la estimación de los costos y la presupuestación de los costos, están tan
íntimamente ligados que son vistos como un solo proceso (por ejemplo, estos
pueden ser ejecutados por un solo individuo durante un periodo de tiempo
relativamente corto). Aquí, se les presenta como procesos distintos, dado que las
herramientas y técnicas de cada uno son diferentes. La capacidad de influenciar
los costos es mayor en las primeras etapas del proyecto y, es esta la razón de
porqué es tan crítica una definición temprana del alcance, como así también una
completa identificación de los requerimientos y la ejecución de un plan sólido.

7.1 PLANIFICACIÓN DE LOS RECURSOS

La planificación de los recursos implica determinar qué recursos físicos (personas,

equipos, materiales) y en qué cantidades de cada cual se deben utilizar y cuándo
serían necesarios para llevar a cabo las actividades del proyecto. Este proceso
debe estar estrechamente coordinado con la estimación de los costos (que se
describe en la sección 7.2). Por ejemplo:

. El equipo de un proyecto de construcción tendrá que estar

familiarizado con los códigos de construcción locales. La mayor de las veces, los
vendedores locales ya cuentan con dicho conocimiento. Sin embargo, si los
grupos de mano de obra locales carecen de experiencia en técnicas de
construcción inusuales o especializada, el costo adicional de un consultor podría
ser la forma más efectiva de garantizar el conocimiento de los códigos de
construcción locales.
. El equipo de un proyecto de diseño automotriz deberá estar
familiarizado con las técnicas más recientes en montaje automatizado. El
conocimiento requerido podría obtenerse, contratando a un consultor, enviando un
diseñador a un seminario sobre robótica, o bien incorporando a alguien de
manufacturación como miembro del equipo.
7.1.1 Entradas para la Planificación de los Recursos

.1 Estructura de división del trabajo. La estructura de división del trabajo

(EDT, descrita en la Sección 5.3.3.1) identifica las prestaciones del proyecto
y los procesos que necesitarán recursos. Así, se trata de la principal
entrada para la planificación de los recursos. Cualquier resultado o
consecuencia relevante de los demás procesos de planificación se deben
obtener a través de la EDT a fin de garantizar un correcto control.
.2 Información histórica. De ser posible, se debe utilizar la información
histórica respecto de qué tipos de recursos fueron requeridos para trabajos
similares en proyectos anteriores.
.3 Declaración del Alcance. La declaración del alcance (descrita en la
Sección 5.2.3.1) contiene la justificación de y los objetivos del proyecto,
debiendo considerarse ambos en forma explícita durante la planificación de
los recursos.
.4 Descripción del pool de recursos. El conocimiento de qué recursos
(personas, equipos, materiales) se encuentran potencialmente disponibles
constituye una necesidad para la planificación de los recursos. La cantidad
de detalle y el nivel de especificidad de la descripción del pool de recursos
será variable. Por ejemplo, durante las primeras etapas de un proyecto de
diseño de ingeniería, el pool podría incluir “ingenieros sénior y júnior” en
grandes cantidades. No obstante, durante las últimas etapas del mismo
proyecto, el pool puede verse limitado a aquellos individuos que están
familiarizados con el proyecto, como resultado de haber trabajo en las
primeras fases del mismo.
.5 Políticas organizacionales. Durante la planificación de los recursos, se
deben considerar las políticas de la organización ejecutante respecto de los
recursos humanos y el arriendo o compra de insumos y equipos.
.6 Estimaciones de la duración de las actividades. Las duraciones
(descritas en las Sección 6.3.3.1).

7.1.2 Herramientas y Técnicas para la Planificación de los Recursos

.3 Juicio experto. . A menudo, será necesario el juicio experto con el fin de

evaluar las entradas para este proceso. Dicha experticia puede ser
proporcionado por cualquier grupo o individuo con conocimiento o
 entrenamiento especializado, y se puede obtener de muchas fuentes, que
incluyen:

. Otras unidades dentro de la organización ejecutante.

. Consultores
. Accionistas, incluidos los clientes.
. Asociaciones profesionales y técnicas

Grupos industriales .4 Identificación de

alternativas. La identificación de alternativas se analiza
en la Sección 5.2.2.3.
.5 Software de gestión del proyecto. El software de gestión del proyecto
reúne la capacidad para ayudar a organizar los pools de recursos.
Dependiendo del grado de sofisticación del software, se pueden definir las
disponibilidad y las tarifas de los recursos, como así también los
calendarios de recursos.

7.1.3 Resultados de la Planificación de los Recursos

.1 Requerimientos de recursos. El resultado del proceso de planificación de

los recursos es una descripción de qué tipos de recursos se necesitan y en
qué cantidades de cada elemento al nivel más bajo de la EDT. Los
requerimientos de recursos para los niveles más altos dentro de la EDT, se
pueden calcular sobre la base de los valores de los niveles más bajos.
Estos recursos se obtendrán, ya sea por medio de la adquisición de
personal (que se describe en la Sección 9.2) o por medio del
abastecimiento (descrito en el Capítulo 12).

7.2 ESTIMACIÓN DE LOS COSTOS

La estimación de los costos implica desarrollar una aproximación (estimación) de

los costos de los recursos necesarios para completar las actividades del proyecto.
En el proceso de aproximar los costos, el estimador considera las causas de
variación de la estimación final con el fin de lograr una mejor gestión del proyecto.

Cuando se ejecuta un proyecto por medio de un contrato, se debe tener cuidado al

momento de distinguir entre estimación de costos y preciación. La estimación de
costos implica desarrollar una evaluación del resultado cuantitativo probable -
¿Cuánto le costará a la organización ejecutante proveer el producto o servicio
involucrado? La preciación es una decisión de negocios -¿Cuánto cobrará la
organización ejecutante por el producto o servicio? – que utiliza la estimación de
los costos como una consideración de muchas.
La estimación de los costos incluye identificar y considerar las diversas
alternativas de costos. Por ejemplo, en la mayoría de las áreas de aplicación, se
sostiene ampliamente que el trabajo adicional durante una fase de diseño tiene el
potencial de reducir el costo de la fase de producción. El proceso de estimación de
los costos debe considerar si el costo del trabajo de diseño adicional será
recuperado por los ahorros esperados.

7.2.1 Entradas para la Estimación de los costos

.1 Estructura de división del trabajo. La EDT se describe en la Sección

5.3.3.1. Esta se utiliza para organizar las estimaciones de costo y
asegurar de que todo el trabajo identificado haya sido estimado. .2
Requerimientos de recursos. Los requerimientos de recursos se
describen en la Sección 7.1.3.1.
.3 Tarifas de los recursos. El individuo o grupo que prepare las estimaciones
de costos debe conocer los precios unitarios (por ejemplo, el costo por hora
del personal, el costo por metro cúbico de material) de cada recurso para
calcular los costos del proyecto. Si no se conocen las tarifas
o precios reales, se tendrá entonces que estimar o predecir las mismas
tarifas.
.4 Estimaciones de duración de las actividades. Las estimaciones de
duración de las actividades (descritas en la Sección 6.3.3.1) afectarán las
estimaciones de costos de cualquier proyecto en donde el presupuesto
incluya una consideración para el costo de financiamiento (es decir, las
tasas de interés).
.5 Publicación de las estimaciones. Información comercialmente disponible
sobre las estimaciones de costos.
.6 Información histórica. La información sobre el costo de muchas
categorías de recursos, puede obtenerse muchas veces a partir de una o
más de las siguientes fuentes:
. Archivos de proyectos – una o más de las organizaciones
involucradas con el proyecto pueden mantener un registro de los resultados de
proyectos previos que esté lo suficientemente detallado como para ayudar en el
desarrollo de las estimaciones de costos. En algunas áreas de aplicación, los
mismos miembros del equipo pueden mantener tales registros.
. Bases de datos comerciales de estimación de costos – con
frecuencia, se puede obtener comercialmente la información histórica.
. Conocimiento del equipo del proyecto – los mismos miembros del
equipo del proyecto pueden recordar los totales o estimaciones previas. Aunque
dichas recopilaciones pueden ser útiles, estas son por lo general lejos menos
confiables que los resultados documentados.

.7 Libro de cuentas. Un libro de cuentas describe la estructura de códigos

utilizada por la organización ejecutante para reportar la información
financiera en su bitácora general. Se debe asignar a las estimaciones de
costos del proyecto la categoría contable correcta.
.8 Riesgos. El equipo del proyecto considera la información sobre los riesgos
(ver Sección 11.2.3.1) cuando produce las estimaciones de costos, ya que
los riesgos (ya sea las amenazas u oportunidades) pueden tener un
impacto significativo en el costo. El equipo del proyecto considera el grado
al cual se incluye el efecto del riesgo en las estimaciones de costos de cada
actividad.

7.2.2 Herramientas y Técnicas para la Estimación de los Costos

.1 Estimación análoga. La estimación análoga, también conocida como

estimación de arriba-a-abajo, significa utilizar el costo real de un proyecto
similar anterior, como base para la estimación del costo del proyecto actual.
Se le emplea frecuentemente para estimar los costos totales del proyecto
cuando existe una cantidad limitada de información detallada acerca del
proyecto (por ejemplo, en las primeras fases). La estimación análoga es
una forma de juicio experto (que se describe en la Sección 7.1.2.1).

La estimación análoga es generalmente menos costosa que otras técnicas,

pero por lo general es menos exacta. Es más confiable cuando (a) los
proyectos anteriores son similares de hecho y no sólo en apariencia, y (b)
cuando los individuos o grupos que preparan las estimaciones tiene la
experticia necesaria.
.2 Modelamiento paramétrico. El modelamiento paramétrico implica utilizar
características del proyecto (parámetros) en un modelo matemático de
forma tal de predecir los costos del proyecto. Los modelos pueden ser
simples (la construcción de una casa costará una cierta cantidad por metro
cuadrado de espacio habitable) o complejos (un modelo de costos para el
desarrollo de software utiliza trece factores de ajuste separados, cada uno
de estos tiene de cinco a siete puntos).

Tanto el costo como la precisión de los modelos paramétricos varían

considerablemente. Es más probable que sean confiables cuando (a) la
información histórica empleada para desarrollar el modelo sea exacta, (b)
los parámetros utilizados en el modelo sean fácilmente cuantificables, y (c)
el modelo sea escalable (es decir, que funcione bien tanto para los
 proyectos muy grandes como para los proyectos muy pequeños).
.3 Estimación de Abajo-hacia-Arriba. Esta técnica implica estimar el costo
de las actividades individuales o paquetes de trabajo, luego sumar o
totalizar las estimaciones individuales de forma tal de obtener un total del
proyecto.

El costo y precisión de la estimación de abajo-hacia-arriba son

dependientes del tamaño y complejidad de la actividad individual o paquete
de trabajo: las actividades más pequeñas aumentan tanto el costo como la
exactitud del proceso de estimación. El equipo de gestión del proyecto debe
sopesar la precisión adicional con respecto al costo adicional.

.4 Herramientas computarizadas. Las herramientas computarizadas, tales

como las planillas de software de gestión de proyectos y las herramientas
estadísticas y de simulación, son ampliamente utilizadas para facilitar la
estimación de los costos. Dichos productos pueden simplificar el uso de las
herramientas descritas anteriormente y, por ende, facilitar la rápida
consideración de muchas alternativas de costos.
.5 Otros métodos de estimación de costos. Por ejemplo, el análisis de las
ofertas de proveedores.

7.2.3 Resultados de la Estimación de los Costos

.1 Estimaciones de costos. Las estimaciones de costos son evaluaciones

cuantitativas de los costos probables de los recursos requeridos para
completar las actividades del proyecto. Estas se pueden presentar en
forma resumida o detallada.

Se deben estimar los costos de todos los recursos que serán cargados al
proyecto. Esto incluye, pero sin limitarse a, la mano de obra, los materiales,
los insumos y las categorías especiales tales como una provisión por
inflación o reserva de costos.
Las estimaciones de costos se expresan generalmente en unidades de
moneda corriente (dólares, euros, yenes, etc.) de forma de facilitar las
comparaciones tanto dentro como entre proyectos. En algunos casos, el
estimador puede utilizar unidades de medida para estimar el costo, como por
ejemplo las horas o días de personal, junto con sus estimaciones de costos a
fin de facilitar el adecuado control de la gestión. La estimación de los costos
incluye, generalmente, que se considere una planificación apropiada de
respuesta al riesgo, como por ejemplo planes de contingencia.

Las estimaciones de costos se pueden beneficiar realizando un refinamiento

durante el curso del proyecto, de forma tal de reflejar todo detalle adicional
disponible. En algunas áreas de aplicación, existen pautas respecto de cuándo
se deben llevar a cabo dichos refinamientos y qué grado de precisión se
espera de ellos. Por ejemplo, la Association for the Advancement of Cost
 Engineering (AACE) [Asociación Internacional para el Progreso de la Ingeniería
de Costos] ha identificado una progresión de cinco tipos de estimaciones de
costos de construcción durante la ingeniería: orden de magnitud, conceptual,
preliminar, definitivo y control.

.2 Detalla de respaldo. El detalle de respaldo para las estimaciones de

costos debe incluir:

. Una descripción del alcance del trabajo estimado. Esta está dada, a
menudo, por una referencia a la EDT.
. Documentación de la base para la estimación; es decir, cómo se
desarrolló.
. Documentación de cualquier supuesto que se haya realizado.
. Una indicación del rango de los posibles resultados; por ejemplo,
US$10.000 + US$1.000 para indicar que se espera que el ítem cueste entre
US$9.000 y US$11.000.

La cantidad y tipo de detalles adicionales variará según el área de aplicación

de que se trate. La consideración incluso de notas no elaboradas puede ser de
gran valor, al procurar un mejor entendimiento de cómo se desarrolló la
estimación.

.3 Plan de gestión del costo. El plan de gestión del costo describe cómo se
manejarán las varianzas de costos (por ejemplo, respuestas diferentes a
problemas mayores y no a problemas menores). Un plan de gestión del
costo puede ser formal o informal, altamente detallado o estructurado,
según sean las necesidades de los accionistas del proyecto. Se trata de un
elemento subsidiario del plan del proyecto (analizado en la Sección 4.1.3.1).
7.3 PRESUPUESTACIÓN DE LOS COSTOS

Presupuestar los costos implica designar las estimaciones de costo globales a las
actividades individuales o paquetes de trabajo, de forma tal de establecer una
base de costos para medir el rendimiento / desempeño del proyecto. La realidad
podría requerir que se realizaran las estimaciones luego de haberse otorgado la
aprobación presupuestaria, aunque en la medida de lo posible, las estimaciones
deberían de realizarse antes dela solicitud de presupuesto.
7.3.1 Entradas para la Presupuestación de los Costos

.1 Estimaciones de costos. Las estimaciones de costos se describen en la

Sección 7.2.3.1.
.2 Estructura de división del trabajo. La EDT (descrita en la Sección
5.3.3.1) identifica los elementos del proyecto a los que se les asignarán los
costos.
.3 Programa del proyecto. El programa del proyecto (descrito en la Sección
6.4.3.1) incluye las fechas de inicio planificadas y de término esperadas
para los componentes del proyecto a los que se les debe asignar costos.
Esta información es necesaria con el objeto de asignar los costos al periodo
de tiempo en el que se incurrirá en el costo.
.4 Plan de gestión del riesgo. El plan de gestión del riesgo se analiza en la
Sección 11.1.3. Además de esto, el plan de gestión del riesgo incluye, a
menudo, la contingencia del costo, que se puede determinar sobre la base
de la precisión esperada de la estimación.

7.3.2 Herramientas y Técnicas para la Presupuestación de los Costos

.1 Herramientas y técnicas para la presupuestación de los costos. Las

herramientas y técnicas descritas en la Sección 7.2.2 para desarrollar las
estimaciones del proyecto, se utilizan para desarrollar presupuestos para
las actividades o paquetes de trabajo también.
7.3.3 Resultados de la Presupuestación de los Costos

.1 Base de costos. La base de costo es un presupuesto de fase tiempo que

se utilizará para medir y monitorear el rendimiento de los costos en el
proyecto. Este se desarrolla sumando los costos estimados por periodo y,
por lo común, se despliega en forma de una curva S, como se ilustra en la
Figura 7-2.
Muchos proyectos, especialmente los más grandes, pueden tener múltiples bases
de costo para medir los distintos aspectos del rendimiento del costo. Por ejemplo,
un plan de gastos o predicción de flujo de caja, es una base de datos de costo
para medir los desembolso.

7.4 CONTROL DE LOS COSTOS

El control de los costos tiene que ver con (a) influir en los factores que originan
cambios a la base de costos, a fin de asegurarse de que los “cambios” hayan sido
acordados, (b)determinar que se haya cambiando la base de costos; y (c) manejar
los actuales cambios cuando y a medida que ocurran. El control del costo incluye:

. Monitorear el rendimiento de los costos para detectar y entender las

variaciones con respecto al plan.
. Asegurar que se registren todos los cambios correspondientes en
forma exacta en la base de costos.
. Evitar que se incluyan en la base de costos aquellos cambios
incorrectos, inadecuados y no autorizados.
. Accionar a los respectivos accionistas acerca de los cambios
autorizados.
. Actuar para llevar los costos esperados dentro de límites aceptables.

El control de los costos incluye buscar los “por qué” tanto de las variaciones
positivas como de las negativas. Este control se debe integrar cabalmente con los
demás procesos de control (control de cambio del alcance, control del programa,
control de calidad y otros, como se analizara en la Sección 4.3). Por ejemplo, las
respuestas inadecuadas a las variaciones en los costos pueden provocar
problemas de calidad o de programa o bien producir un nivel inaceptable de riesgo
más adelante en el proyecto.
7.4.1 Entradas para el Control de Costos

.1 Base de costos. La base de costos se describe en la Sección 7.3.3.1.

.2 Informes de rendimiento. Los informes de rendimiento (analizados en la
Sección 10.3.3.1) dan información acerca del alcance del proyecto y el
rendimiento de los costos, como por ejemplo cuáles han sido los
presupuestos que se han cumplido y cuáles no. Los informes de
rendimiento pueden, además, alertar al equipo del proyecto sobre temas o
materias que podrían llegar a causar problemas en el futuro.
.3 Solicitudes de cambio. Las solicitudes de cambios pueden ocurrir de
muchas maneras – orales o escritas, directas o indirectas, iniciadas en
forma externa o interna, por mandato legal u opcionales. Los cambios
pueden hacer necesario un aumento del presupuesto, o por el contrario
permitir una reducción de éste.
.4 Plan de gestión del costo. El plan de gestión del costo se describe en la
Sección 7.2.3.3.

7.4.2 Herramientas y Técnicas para el Control de Costos

.1 Sistema de control de cambios en los costos. Un sistema de control de

cambios de costos define los procedimientos por medio de los cuales se
puede cambiar la base de costos. Este incluye el papeleo, los sistemas de
seguimiento, y los niveles de aprobación necesarios para autorizar los
cambios. El sistema de control de cambios de costos debe integrarse con el
sistema de control de cambios integrados, que se analizara en la Sección
4.3.
.2 Medición del rendimiento / desempeño. Las técnicas de medición del
rendimiento / desempeño, descritas en la Sección 10.3.2, ayudan a evaluar
la magnitud de cualquier variación que llegase a ocurrir. La Gestión del
Valor Ganado (GVG), descrita en las Secciones 7.4.2.3 y 10.3.2.4, es
especialmente útil para el control de los costos. Una parte importante del
control de costos es la determinación de qué está provocando la variación y
la decisión de si dicha modificación requiere o no de una acción correctiva.
.3 Gestión del valor ganado (GVG). Todos los Planes de Control de Cuentas
GVG (PCC’s) deben medir continuamente el rendimiento del proyecto,
 relacionando tres variables independientes: 1) El Valor Planificado, el
trabajo físico que se ha programado realizar, incluido el valor estimado de
este trabajo (previamente denominado Costos Presupuestados para el
Trabajo Programado [CPTP]), en comparación con el (2) Valor Ganado, el
trabajo físico que realmente se llevó a cabo, incluido el valor estimado de
este trabajo (previamente denominado Costos Presupuestados para el
Trabajo Realizado [CPTR]) y, con (3) los Costos Reales incurridos para
lograr el Valor Ganado. La relación de (2) el Valor Ganado menos (1) el
Valor Planificado menos (3) los Costos Reales, constituye la Varianza de
Costos (VC) del proyecto. Ver también la Sección 10.3.2.4.
.4 Planificación adicional. Son pocos los proyectos que se ejecutan
exactamente de acuerdo a lo planificado. Los cambios potenciales pueden
requerir estimaciones de costos nuevas o revisadas o un análisis de los
enfoques alternativos.
.5 Herramientas computarizadas. A menudo, herramientas computarizadas
tales como software de gestión de proyectos y planillas de cálculo, se
utilizan para hacer un seguimiento de los costos planificados versus los
costos reales, y para predecir los efectos de los cambios en los costos.

7.4.3 Resultados del Control de Costos

.1 Estimaciones revisadas de costos. Las estimaciones revisadas de costos

son modificaciones a la información utilizada para manejar el proyecto. Se
debe notificar, según sea necesario, a los accionistas que corresponda. Las
estimaciones revisadas de costos pueden o no requerir ajustes en otros
aspectos del plan del proyecto.
.2 Actualizaciones presupuestarias. Las actualizaciones presupuestarias
son una categoría especial de estimaciones de costos revisadas. Las
actualizaciones presupuestadas son los cambios a una base de costos
aprobada. Estos números se revisan generalmente sólo en respuesta a los
cambios de alcance. En algunos casos, las variaciones de los costos
pueden ser tan graves que es necesario volver a crear una base a fin de
proveer una medida realista del rendimiento.
.3 Acción correctiva. La acción correctiva es todo aquello que se realiza para
alinear el rendimiento a futuro esperado del proyecto con el plan del
proyecto.
.4 Estimación al término. Una Estimación al Término (EAT) es una predicción
de los costos totales del proyecto más probables, sobre la base del rendimiento
del proyecto y la cuantificación de los riesgos, que se describe en la Sección
11.4.3. Las técnicas de predicción más comunes son cierta variación de:

EAT = Las reales a la fecha más una nueva estimación de todo el

trabajo restante. Este enfoque es más frecuentemente utilizado cuando
el rendimiento pasado muestra que los supuestos de estimación
originales fueron fundamentalmente incorrectos, o que ya no son
relevantes a un cambio de las condiciones. Fórmula: EAT = AC + ETC.
 EAT = Las reales a la fecha más el presupuesto restante (BAC – EV).
Este enfoque se utiliza con mayor frecuencia cuando se ven las actuales
variaciones como típicas y las expectativas del equipo de gestión del
proyecto son que no ocurrirán variaciones similares en el futuro.
Fórmula: EAT = AC + BAC – VG.
EAT = Las reales a la fecha más el presupuesto restante del proyecto
(BAC – EV) modificado por un factor de rendimiento, a menudo un
índice de rendimiento por costo acumulativo (IRC). Esta metodología se
utiliza con mayor frecuencia cuando las actuales variaciones son
consideradas como típicas variaciones a futuro. Fórmula: EAT = (AC +
(BAC –VG)/IRC) –este IRC es el IRC acumulativo.

Cada uno de estos enfoques o metodologías podría ser el correcto para un

determinado proyecto y dará al equipo de gestión del proyecto una señal de si
las predicciones del EAT más allá de las tolerancias aceptables.

.5 Cierre del proyecto. Se deben desarrollar procesos y procedimientos para el

cierre o cancelación de los proyectos. Por ejemplo, la Declaración de Posición
(SOP 98-1 emitida por el Instituto Norteamericano de Cuentas Públicas
Certificadas – AICPA) exige que todos los costos de un proyecto de tecnología
de la información que haya fracasado sean castigados en el trimestre en que
se canceló el proyecto.
.6 Lecciones aprendidas. Las causas de las variaciones, el razonamiento de la
acción correctiva elegida y, otros tipos de lecciones aprendidas a partir del
control de los costos, deben documentarse de forma tal que pasen a ser parte
de la base de datos histórica tanto para este proyecto como para otros
proyectos de la organización ejecutante (ver Sección 4.3.3.3).

Gestión de Calidad del Proyecto

La gestión de calidad del proyecto incluye los procesos requeridos para asegurar
que el proyecto satisfaga todas las necesidades para las cuales se lleva a cabo.
Esto incluye “todas las actividades de la función global de gestión que determinan
la política de calidad, los objetivos y las responsabilidades, e implementarlas por
medios tales como la planificación de la calidad, el aseguramiento de la calidad, el
control de calidad y el mejoramiento de la calidad, dentro del sistema de calidad”
(1). La Figura 8-1 presenta una descripción general de los principales procesos de
la gestión de calidad del proyecto:

1. 8.1 Planificación de la Calidad – identificar cuáles son las normas de

calidad relevantes para el proyecto y determinar la forma cómo satisfacerlas.
2. 8.2 Aseguramiento de la Calidad – evaluar el rendimiento / desempeño
global del proyecto en forma regular a fin de tener la confianza de que el proyecto
satisfará las normas de calidad relevantes.
3. 8.3 Control de Calidad – monitorear resultados específicos del proyecto
con el objeto de determinar si estos cumplen con las normas de calidad relevantes
e identificar las formas para eliminar las causas de rendimiento / desempeño
insatisfactorio.

Estos procesos interactúan unos con otros y con los procesos de las demás áreas
de conocimiento también. Cada proceso puede involucrar el esfuerzo de uno o
más individuos o grupos de individuos, según sean las necesidades del proyecto.
Cada proceso tiene lugar, generalmente, al menos una vez en cada fase del
proyecto.

Aunque los procesos se presentan aquí como componentes discretos con

interfaces bien definidas, en la práctica estos pueden traslaparse e interactuar de
formas que aquí no se detallan. Las interacciones de los procesos se analizan
detalladamente en el Capítulo 3.

El enfoque básico para la gestión de calidad que se describe en esta sección tiene
como propósito ser compatible con aquél de la Organización Internacional para la
Normalización (ISO), como se detalla en las normas y pautas ISO Series 9000 y
10000. Este enfoque generalizado también debe ser compatible con (a) los
enfoques o metodologías de gestión de calidad patentadas, como aquellas
recomendadas por Deming, Juran, Crosby y otros, y (b) enfoques no patentados
como por ejemplo la Gestión de Calidad Total (GCT), el Mejoramiento Continuo, y
otros.
La gestión de calidad del proyecto debe abordar tanto la gestión del proyecto
como el producto del proyecto. El término genérico producto se utiliza,
ocasionalmente, en la literatura relacionada con calidad, para referirse tanto a los
bienes como a los servicios. El no cumplimiento de los requerimientos de calidad,
cualquiera sea su dimensión, puede tener serias consecuencias negativas para
cualquiera o todos los accionistas o impulsores del proyecto. Por ejemplo:

. El cumplimiento de los requerimientos del cliente mediante la sobre-

explotación del equipo del proyecto puede producir consecuencias negativas en
forma de aumento del desgaste de los empleados.
. El cumplimiento de los objetivos del proyecto, apurando las
inspecciones de calidad planificadas puede producir consecuencias negativas
cuando los errores pasan sin ser detectados.

Calidad es “la totalidad de las características de una entidad que se mantiene en

su capacidad para satisfacer las necesidades declaradas o implícitas” (2). Las
necesidades declaradas o implícitas son las entradas para el desarrollo de los
requerimientos del proyecto. Un aspecto crítico de la gestión de calidad en el
contexto del proyecto es la necesidad de convertir las necesidades implícitas en
requerimientos, por medio de la gestión del alcance del proyecto, que se describe
en el Capítulo 5.
El equipo de gestión del proyecto debe procurar no confundir calidad con grado.
Grado es “una categoría o rango que se les otorga a las entidades que tienen el
mismo uso funcional, pero diferentes características técnicas” (3) La baja calidad
es siempre un problema, bajo grado puede no serlo. Por ejemplo, un producto de
software puede ser de alta calidad (no tiene errores lógicos, el manual es legible) y
grado bajo (un limitado número de características), o bien puede ser de baja
calidad (muchos errores, documentos de usuario mal organizados) y de alto grado
(numerosas características). La determinación y establecimiento de los niveles
requeridos tanto de calidad como de grado son responsabilidades del gerente del
proyecto y del equipo de gestión del proyecto.

El equipo de gestión del proyecto debe estar conciente de que la gestión de

calidad moderna complementa la gestión del proyecto. Por ejemplo, ambas
disciplinas reconocen la importancia de:

. La satisfacción del cliente – entender, gestionar e influenciar las

necesidades de manera que se cumplan las expectativas del cliente. Lo anterior
requiere una combinación de cumplimiento de los requerimientos (el proyecto
debe producir lo que señaló que produciría) y idoneidad de uso (el producto o
servicio producido debe satisfacer las verdaderas necesidades).
. Prevención versus inspección – el costo de prevenir los errores es
siempre mucho menor que el costo de corregirlos, cuando son revelados por la
inspección.
. Responsabilidad de la administración – el éxito requiere de la
participación de todos los miembros del equipo, pero sigue siendo la
responsabilidad de la administración proveer los recursos necesarios para tener
éxito.
. Los procesos dentro de las fases – el repetido ciclo planificar-
realizar-revisar-actuar descrito por Deming y otros, es altamente similar a la
combinación de fases y procesos discutidos en el Capítulo 3, Procesos de Gestión
del Proyecto.

Además, las iniciativas de mejoramiento de la calidad asumidas por la

organización ejecutante (por ejemplo, TQM, Mejoramiento Continuo, y otros)
pueden mejorar la calidad de la gestión del proyecto, como así también la calidad
del producto del proyecto.

Sin embargo, existe una importante diferencia de cuál equipo de gestión del
proyecto debe estar agudamente consciente – la naturaleza temporal del proyecto
significa que las inversiones en el mejoramiento de calidad del producto,
especialmente en revisión y prevención de defectos, debe ser tenida siempre en
cuenta por la organización ejecutante, dado que el proyecto puede no durar
demasiado como para cosechar las recompensas.

8.1 PLANIFICACIÓN DE LA CALIDAD

Planificar la calidad significa identificar cuáles son las normas de calidad
relevantes para el proyecto, y determinar cómo satisfacerlas. Este es uno de los
procesos facilitadores claves durante la planificación del proyecto (ver Sección
3.3.2, Procesos de Planificación) y se deben ejecutar regularmente y en paralelo
con los demás procesos de planificación de proyectos. Por ejemplo, los cambios
en el producto del proyecto requeridos con el objeto de cumplir las normas de
calidad identificadas pueden implicar ajustes de costos y de programa, o bien la
calidad deseada del producto puede exigir un análisis de riesgo detallado de un
problema identificado. Antes del desarrollo de la Serie ISO 9000, las actividades
que aquí se describen como planificación de la calidad eran discutidas y
analizadas ampliamente como parte del aseguramiento de la calidad.

Las técnicas de planificación de la calidad que aquí se describen son aquellas que
se utilizan con mayor frecuencia en los proyectos. Existen muchas otras que
podrían ser útiles en ciertos proyectos o en algunas áreas de aplicación.

El equipo del proyecto debe estar también conciente de uno de los principios
fundamentales de la gestión moderna de la calidad – la calidad se planifica, no se
inspecciona.

8.1.1 Entradas para la Planificación de la Calidad

.1 Política de calidad. La política de calidad es “las intenciones generales y la

dirección de una organización con respecto a la calidad, como lo expresa
formalmente la gerencia superior” (4). La política de calidad de la
organización ejecutante puede, a menudo, ser adoptada “tal cual es” para
ser utilizada por el proyecto. No obstante, si la organización ejecutante
carece de una política de calidad formal, o si el proyecto involucra a varias
organizaciones ejecutantes (como con un joint venture), entonces el equipo
de gestión del proyecto necesitará desarrollar una política de calidad para el
proyecto.

Cualquiera sea el origen de la política de calidad, el equipo de gestión del

 proyecto es responsable de asegurar que los accionistas del proyecto estén
plenamente concientes de ésta (por ejemplo, por medio de la distribución
adecuada de la información, como se describe en la Sección 10.2).

.2 Declaración del alcance. La declaración del alcance (descrita en la

Sección 5.2.3.1) es una entrada clave para la planificación de la calidad, ya
que documenta las principales prestaciones del proyecto, como también los
objetivos del proyecto que sirven para definir los requerimientos importantes
de los accionistas.
.3 Descripción del producto. Aunque los elementos descriptivos del
producto (descritos en la Sección 5.1.1.1) pueden estar incorporados en la
declaración del alcance, la descripción del producto contendrá, a menudo,
detalles de temas técnicos y otras inquietudes que pueden afectar la
planificación de la calidad.
.4 Normas y regulaciones. El equipo de gestión del proyecto debe considerar
cualquier aplicación de normas o regulaciones específicas de áreas que
puedan afectar al proyecto. La Sección 2.5.1 analiza la temática de las
normas y regulaciones.
.5 Otros resultados de procesos. Además de la declaración del alcance y de
la descripción del producto, los procesos de las demás áreas de
conocimiento pueden producir resultados que deben ser considerados
como parte de la planificación de la calidad. Por ejemplo, la planificación
del abastecimiento (que se describe en la Sección 12.1) puede llegar a
identificar los requerimientos de calidad del contratista que deben reflejarse
en el plan global de gestión de calidad.

8.1.2 Herramientas y Técnicas para la Planificación de la Calidad

.1 Análisis costo / beneficio. El proceso de planificación de la calidad debe

considerar las evaluaciones costo / beneficio, como se detalla en la Sección
5.2.2.2. El principal beneficio que se obtiene al cumplir con los
requerimientos de calidad es una menor reelaboración, lo que significa una
mayor productividad, menores costos y aumento de la satisfacción de los
accionistas. El principal costo de cumplir con los requerimientos de calidad
es el gasto asociado con las actividades de gestión de calidad del proyecto.
Es un axioma de la disciplina de gestión de la calidad que los beneficios
superen los costos.
.2 Benchmarking (evaluación comparativa). Benchmarking implica comparar
las prácticas reales o planificadas del proyecto con aquellas de otros
proyectos, a fin de generar ideas para mejorar o para establecer una norma por
medio de la cual medir el rendimiento / desempeño. Los demás proyectos
pueden estar dentro de la organización ejecutante o fuera de ésta; dentro de la
misma área de aplicación o en otra.
.3 Diagrama de flujo. Un diagrama de flujo es cualquier diagrama que muestre
de qué manera se relacionan los distintos elementos de un sistema. Entre las
técnicas de diagramación de flujos más comúnmente utilizadas en la gestión
 de calidad se incluyen:

. Diagrama de causa-y-efecto, también llamados diagramas de

ishikawa o diagramas de espina de pescado, que ilustran cómo se podrían
relacionar los distintos factores con los problemas o efectos potenciales. La Figura
8-2 es un ejemplo de un diagrama genérico de causa-y-efecto.
. Diagramas de flujo de procesos o sistemas, que muestran cómo se

interrelacionan los distintos elementos de un sistema. La Figura 8-3 es

un ejemplo de un diagrama de flujo de procesos para revisiones de
diseño.

El diagrama de flujo puede ayudar al equipo del proyecto a anticipar qué

problemas de calidad podrían ocurrir y dónde, y así pueden ayudar a
desarrollar enfoques o metodologías que los aborden.

.4 Diseño de experimentos. El diseño de experimentos es un método

estadístico que ayuda a identificar cuáles son los factores que podrían
influenciar variables específicas. La técnica se aplica con mayor frecuencia
al producto del proyecto (por ejemplo, los diseñadores de autos podrían
desear determinar qué combinación de suspensión y neumáticos producirá
las características de conducción más deseables a un costo razonable).
Sin embargo, también se puede aplicar a temas relacionados con la gestión del
proyecto, como son las compensaciones de costo y programa. Por ejemplo,
los ingenieros sénior tendrán un costo mayor que los ingenieros júnior, pero
también se puede esperar que los primeros terminen el trabajo asignado en
menos tiempo. Un “experimento” correctamente diseñado (en este caso,
calcular los costos y las duraciones del proyecto para distintas combinaciones
de ingenieros sénior y júnior) permitirá, a menudo, determinar la solución
óptima a partir de un número relativamente limitado de casos.

.5 Costo de la calidad. El costo de la calidad se refiere al costo total de

todos los esfuerzos por lograr la calidad del producto / servicio, e incluye
 todo el trabajo requerido para asegurar el cumplimiento de los
requerimientos, como así también el trabajo resultante del incumplimiento
de los requerimientos. Son tres los tipos de costos en los que se incurre:
costos de prevención, costos de evaluación y costos por falla, donde los
últimos se dividen en costos internos y externos.

8.1.3 Resultados de la Planificación de la Calidad

.1 Plan de gestión de calidad. El plan de gestión de calidad debe describir la

forma cómo el equipo de gestión del proyecto implementará su política de
calidad. Utilizando terminología de la ISO 9000, debe describir el sistema
de calidad del proyecto: “la estructura organizacional, las
responsabilidades, los procedimientos, los procesos y los recursos
necesarios para implementar la gestión de calidad” (5).

El plan de gestión de la calidad sirve como entrada para todo el plan del
proyecto (descrito en la Sección 4.1, Desarrollo del Plan del Proyecto),y
debe abordar el control de calidad, el aseguramiento de la calidad y el
mejoramiento de la misma para el proyecto.

El plan de gestión de calidad puede ser formal o informal, altamente detallado

o ampliamente estructurado, dependiendo de los requerimientos del proyecto.

.2 Definiciones operacionales. Una definición operacional describe, en

términos bien específicos, lo qué algo es y cómo es medido ello por medio
del proceso de control de calidad. Por ejemplo, no basta con decir que
cumplir las fechas planificadas por programa es una medida de la calidad
de la gestión; el equipo de gestión del proyecto debe además indicar si
cada actividad debe comenzar a tiempo o sólo terminar a tiempo; si se
medirán las actividades individuales, o solamente ciertas prestaciones, y si
así fuera, cuáles. Las definiciones operacionales son conocidas también
como métricas en algunas áreas de aplicación.
.3 Listas de verificación (checklists). Una lista de verificación o “checklist” es
una herramienta estructurada, por lo general específica al ítem, utilizada para
verificar que se hayan realizado un conjunto de etapas requeridas. Las listas
de verificación pueden ser simples o complejas. Generalmente, son fraseadas
como imperativos (“¡¡Haga esto!!”) o interrogativas (“¿Ha hecho esto?”). En
muchas organizaciones existen listas de verificación estandarizadas de forma
tal de asegurar la consistencia en tareas ejecutadas con frecuencia. En
algunas áreas de aplicación, también existen listas de verificación
proporcionadas por asociaciones profesionales
o proveedores de servicios comerciales.
.4 Entradas para otros procesos. El proceso de planificación de la calidad
 puede identificar una necesidad de mayor actividad en otra área.

8.2 ASEGURAMIENTO DE LA CALIDAD

Aseguramiento de la calidad son todas las actividades planificadas y sistemáticas

que se implementan dentro del sistema de calidad con el objeto de dar confianza
de que el proyecto satisfará las normas de calidad relevantes (6). Este proceso
debe desarrollarse durante todo el proyecto. Antes del desarrollo de las Series
ISO 9000, las actividades descritas en planificación de la calidad eran
ampliamente incluidas como parte del aseguramiento de la calidad.

El aseguramiento de la calidad es, con frecuencia, desarrollado por un

Departamento de Aseguramiento de la Calidad o una unidad organizacional con
un nombre similar, aunque no necesariamente.

Este aseguramiento puede ser proporcionado al equipo de gestión del proyecto y

a la administración o gerencia de la organización ejecutante (aseguramiento
interno de la calidad), o puede ser proporcionado al cliente y a terceros que no
estén activamente involucrados con el trabajo del proyecto (aseguramiento
externo de la calidad).

8.2.1 Entradas para el Aseguramiento de la Calidad

.1 Plan de gestión de la calidad. El plan de gestión de la calidad se describe

en la Sección 8.1.3.1.
.2 Resultados de las mediciones de control de calidad. Las mediciones de
control de calidad son los registros de pruebas y mediciones de control de
calidad en un formato que permita su comparación y análisis.
.3 Definiciones operacionales. Las definiciones operacionales se describen
en la Sección 8.1.3.2.

8.2.2 Herramientas y Técnicas para el Aseguramiento de la Calidad

 .1 Herramientas y técnicas de planificación de la calidad. Para el
aseguramiento de la calidad, también se pueden utilizar las herramientas y
técnicas de planificación de la calidad se describen en la Sección 8.1.2.
.2 Auditorías a la calidad. Una auditoría a la calidad es una revisión
estructurada de las demás actividades de gestión de la calidad. El objetivo
de una auditoría a la calidad es el de identificar las lecciones aprendidas
que pueden mejorar el rendimiento de este proyecto o el de otros proyectos
dentro de la organización ejecutante. Las auditorías a la calidad pueden
ser programadas o aleatorias (al azar), y pueden ser llevadas a cabo por
auditores internos entrenados o bien por terceras partes, como por ejemplo
las agencias de registro de sistemas de calidad.

8.2.3 Resultados del Aseguramiento de la Calidad

.1 Mejoramiento de la calidad. El mejoramiento de la calidad incluye tomar

acciones para aumentar la eficacia y eficiencia del proyecto para
proporcionar beneficios agregados a los accionistas del proyecto. En la
mayoría de los casos, la implementación de mejoramientos en la calidad
demandará la preparación de solicitudes de cambio o la toma de acciones
correctivas y, serán manejadas de conformidad con los procedimientos para
el control integrado de cambios, como se describe en la Sección 4.3.

8.3 CONTROL DE CALIDAD

El control de calidad implica monitorear los resultados específicos del proyecto de

forma tal de determinar si estos cumplen con las normas de calidad aplicables, e
identificar las formas que permitan eliminar las causas de resultados
insatisfactorios. Este proceso se debe llevar a cabo durante todo el proyecto. Los
resultados del proyecto incluyen tanto los resultados del producto, como son las
prestaciones, y los resultados de la gestión del proyecto, como son el rendimiento
de los costos y del programa. El control de calidad es realizado, a menudo, por un
Departamento de Control de Calidad, o una unidad organizacional con titulo
similar, aunque no necesariamente.

El equipo de gestión del proyecto debe contar con un conocimiento práctico del
control estadístico de la calidad, especialmente en muestreo y probabilidad, de
modo tal de facilitar la evaluación de los resultados del control de calidad. Entre
otros temas, puede ser útil para el equipo conocer las diferencias entre:
. Prevención (evitar los errores del proceso) e inspección (evitar los
errores de parte del usuario).
. Muestreo de atributos (el resultado cumple o no cumple) y el
muestreo de variables (el resultado se clasifica en una escala continua que mide el
grado de cumplimiento).
. Causas especiales (eventos inusuales) y causas aleatorias (variación
normal del proceso).
. Tolerancias (el resultado es aceptable si este clasifica dentro del
rango especificado por la tolerancia) y los límites de control (el proceso está
controlado si el resultado está dentro de los límites de control).

8.3.1 Entradas para el Control de Calidad

.1 Resultados del trabajo. Los resultados del trabajo (descritos en la Sección

4.2.3.1) incluyen tanto los resultados del proceso como los resultados del
producto. Se debe contar con la información respecto de los resultados
planificados o esperados (del plan del proyecto) y con información respecto
de los resultados reales.
.2 Plan de gestión de la calidad. El plan de gestión de la calidad se describe
en la Sección 8.1.3.1.
.3 Definiciones operacionales. Las definiciones operacionales se describen
en la Sección 8.1.3.2.
.4 Listas de verificación. Las listas de verificación se describen en la Sección
8.1.3.3.

8.3.2 Herramientas y Técnicas para el Control de Calidad

.1 Inspección. La inspección incluye aquellas actividades tales como

medición, revisión y prueba que se llevan a cabo con el objeto de
determinar si los resultados cumplen o no con los requerimientos. Las
inspecciones se pueden realizar a cualquier nivel (por ejemplo, se pueden
inspeccionar los resultados de una sola actividad, o bien se puede
inspeccionar el producto final del proyecto). Las inspecciones reciben
variados nombres: revisiones, revisiones de productos y auditorías; en
algunas áreas de aplicación, estos términos tienen significados más
determinados y específicos.
.2 Gráficos de control. Los gráficos de control son un despliegue gráfico de los
resultados, a la fecha, de un proceso. Estos se utilizan para determinar si el
proceso está “bajo control” (por ejemplo,¿ Son las diferencias de los resultados
creadas por variaciones aleatorias, o son ocurrencias de eventos inusuales
cuyas causas se pueden identificar y corregir?). Cuando un proceso está
controlado, no se debe ajustar el proceso. El proceso puede modificarse para
lograr los mejoramientos, pero no debe ser ajustado si está bajo control.

Los gráficos de control se pueden utilizar para monitorear cualquier tipo de

variable de salida. Aunque se les utiliza con mayor frecuencia para realizar un
seguimiento de aquellas actividades repetitivas, como son los lotes
manufacturados, los gráficos de control se pueden utilizar, además, para
monitorear las variaciones de costos y programa, el volumen y frecuencia de
los cambios de alcance, los errores en los documentos del proyecto, u otros
resultados de gestión, de forma tal de ayudar a determinar si el proceso de
gestión del proyecto está bajo control. La Figura 8-4 es un gráfico de control
del rendimiento del programa de un proyecto.

.3 Diagramas Pareto. Un diagrama Pareto es un histograma, ordenado por

frecuencia de ocurrencia, que muestra cómo muchos resultados fueron
generados por tipo o categoría de causa identificada (ver Figura 8-5). La
clasificación de rangos se utiliza para guiar u orientar la acción correctiva – en
primer lugar, el equipo del proyecto debe tomar acción para corregir los
problemas que están causando el mayor número de defectos. Los diagramas
Pareto están conceptualmente relacionados con la Ley de Pareto, que sostiene
que un número relativamente pequeño de causas producirá, generalmente,
una gran mayoría de problemas o defectos. Esto se conoce comúnmente como
el principio del 80/20, donde el 80 por ciento de los problemas se deben al 20
por ciento de las causas.
.4 Muestreo estadístico. El muestreo estadístico implica seleccionar una parte
de una población de interés con fines de inspección (por ejemplo, seleccionar
diez planos de ingeniería al azar, de una lista de setenta y cinco). A menudo, el
muestreo adecuado puede llegar a reducir el costo del control de calidad.
Existe un importante contexto informativo sobre muestreo estadístico; en
algunas áreas de aplicación, se hace necesario que el equipo del proyecto se
familiarice con una variedad de técnicas de muestreo.
.5 Diagramas de flujo. Los diagramas de flujo se describen en la Sección
8.1.2.3. Los diagramas de flujo se utilizan en el control de calidad para ayudar
a analizar de qué manera ocurren los problemas.
.6 Análisis de tendencias. Los análisis de tendencias implican la utilización de
técnicas matemáticas para predecir las consecuencias futuras, sobre la
base de los resultados históricos. El análisis de tendencia se utiliza, a menudo,
para monitorear:

. El rendimiento técnico – cuántos errores o defectos se han

identificado, cuántos siguen sin corregir.
. El rendimiento del costo y del programa – cuántas actividades por
periodo se terminaron con variaciones de importancia.

8.3.3 Resultados del Control de Calidad

.1 Mejoramiento de la calidad. El mejoramiento de la calidad se describe en

la Sección 8.2.3.1.
.2 Decisiones de aceptación. Los ítemes inspeccionados serán, ya sea,
aceptados o rechazados. Los ítemes rechazados pueden demandar la
repetición del trabajo (descrito en la Sección 8.3.3.3).
.3 Repetición del trabajo. La repetición del trabajo es la acción que se
adopta para que un ítem defectuoso o inconforme, cumpla con los
requerimientos o especificaciones. La repetición del trabajo, especialmente
la repetición del trabajo de forma no anticipada, constituye una causa
frecuente de atrasos de proyectos en la mayoría de las áreas de
aplicación. El equipo del proyecto debe hacer todo el esfuerzo razonable
para minimizar la repetición de trabajo (rework).
.4 Ajustes del proceso. Los ajustes de proceso implican la aplicación
inmediata de una acción correctiva o preventiva, como resultado de las
mediciones de control de calidad. En algunos casos, el ajuste de proceso
puede hacer necesario que se maneje de conformidad con los
procedimientos para el control integrado de cambios, como se describe en
la Sección 4.3.
Gestión de Recursos Humanos del Proyecto
La Gestión de Recursos Humanos del proyecto incluye los procesos requeridos
para lograr la utilización más efectiva de las personas involucradas con el
proyecto. Esto incluye a todos los accionistas del proyecto – auspiciadores,
clientes, socios, contribuyentes particulares y otros que se describen en la Sección
1. 2.2. La Figura 9-1 presenta una descripción general de los principales
procesos de la gestión de recursos humanos del proyecto:
2. 9.1 Planificación Organizacional –identificar, documentar y designar
los roles, responsabilidades y relaciones de mando del proyecto.
3. 9.2 Adquisición de Personal -obtenerlos recursos humanos que son
necesarios designar y trabajar en el proyecto.
4. 9.3 Desarrollo del Equipo – desarrollar las competencias individuales y
grupales para mejorar el desempeño / rendimiento del proyecto.

Estos procesos interactúan unos con otros y con los procesos de las demás áreas
de conocimiento también. Cada proceso puede involucrar el esfuerzo de uno o
más individuos o grupos de individuos, según sean las necesidades del proyecto.

Aunque los procesos se presentan aquí como componentes discretos con

interfaces bien definidas, en la práctica estos pueden traslaparse e interactuar de
formas que aquí no se detallan. Las interacciones de los procesos se analizan
detalladamente en el Capítulo 3.

Existe una importante cantidad de literatura que versa acerca de cómo tratar con
las personas en un contexto operacional y continuo. De entre los múltiples y
variados tópicos se incluyen:

. Liderazgo, comunicación, negociación y otros que se analizan en la

Sección 2.4, Habilidades Claves de la Gestión General.
. Delegación, motivación, capacitación, tutoría y otros temas
relacionados con el trato con individuos.
. Formación de equipos, manejo de conflictos y otros temas
relacionados con el trabajo de grupos.
. Evaluación del desempeño, contratación, retención, relaciones
laborales, normas de higiene y seguridad y otros temas relacionados con la
administración de la función de recursos humanos.

La mayor parte de este material es directamente aplicable al direccionamiento y

manejo de las personas en los proyectos, y el gerente del proyecto y el equipo de
gestión del proyecto deben estar familiarizados con esto. Sin embargo, deben
estar además alertas a cómo se aplique este conocimiento en el proyecto. Por
ejemplo:

. La naturaleza temporal de los proyectos implica que las relaciones

personales y organizacionales serán, por lo general, tanto temporales como
nuevas. El equipo de gestión del proyecto debe ser cuidadoso al seleccionar las
técnicas que sean adecuadas para este tipo de relaciones transitorias.
. La naturaleza y número de accionistas del proyecto cambiarán a
menudo a medida que el proyecto avance de una fase a otra en su ciclo de vida.
Como resultado de lo anterior, aquellas técnicas que resultan efectivas en una
fase, pueden no serlo tanto en otra. El equipo de gestión del proyecto debe
procurar utilizar técnicas que sean adecuadas a las actuales necesidades del
proyecto.
. Las actividades administrativas de los recursos humanos rara vez
son una responsabilidad directa del equipo de gestión del proyecto. No obstante,
el

equipo debe estar lo suficientemente conciente de los requerimientos

administrativos de modo tal de asegurar su cumplimiento.

Nota: Los gerentes de proyecto también pueden tener responsabilidades con

respecto a la redesignación y liberación de los recursos humanos, dependiendo de
la industria u organización a la que pertenezcan.

9.1 PLANIFICACIÓN ORGANIZACIONAL

La planificación organizacional implica identificar, documentar y designar los roles,

responsabilidad y relaciones de mando del proyecto. Se pueden asignar roles,
responsabilidades y relaciones de mando individuos o a grupos. Los individuos y
grupos pueden ser parte de la organización que ejecuta el proyecto, o bien pueden
ser externas a ésta. Los grupos internos están a menudo relacionados con un
departamento funcional específico, como por ejemplo: ingeniería, marketing o
contabilidad.

En la mayoría delos proyectos, gran parte de la planificación organizacional se

lleva a cabo como parte de las primeras fases del proyecto. Sin embargo, se
deben revisar regularmente los resultados de este proceso durante todo el
proyecto, a fin de asegurar su continua aplicabilidad. Si ya no es efectiva la
organización inicial, entonces ésta debe revisarse a la brevedad.
La planificación organizacional está a menudo fuertemente ligada con la
planificación de las comunicaciones (descrita en la Sección 10.1), dado que la
estructura organizacional del proyecto tendrá un efecto mayor en los
requerimientos de comunicaciones del proyecto.

9.1.1 Entradas para la Planificación Organizacional

.1 Interfaces del proyecto. Las interfaces del proyecto son clasificadas,

generalmente, en una de tres categorías:
. Interfaces organizacionales -relaciones de mando formales e
informales entre las distintas unidades organizacionales. Las interfaces
organizacionales pueden ser altamente complejas o muy simples. Por ejemplo, el
desarrollo de un complejo sistema de telecomunicaciones puede requerir la
coordinación de numerosos subcontratistas durante varios años, mientras que la
corrección de un error de programación en un sistema instalado en un solo lugar
puede hacer necesaria la sola notificación del usuario y del personal de
operaciones al término de dicha reparación.
. Interfaces técnicas – relaciones de mando formales e informales
entre las distintas disciplinas técnicas. Las interfaces técnicas tienen lugar tanto
dentro de las fases del proyecto (por ejemplo, el diseño del sitio desarrollado por
los ingenieros civiles puede ser compatible con la superestructura desarrollada por
los ingenieros estructurales) y entre las fases del proyecto (por ejemplo, cuando
un equipo de diseño automotriz traspasa los resultados de su trabajo al equipo de
maquetería que debe crear la capacidad de fabricación del vehículo).
. Interfaces interpersonales – relaciones de mando formales e
informales entre los distintos individuos que trabajan en un proyecto.

Estas interfaces suelen ocurrir simultáneamente, como cuando un arquitecto

empleado por una empresa de diseño explica las consideraciones claves del
diseño a un equipo de gestión de proyecto de un contratista en construcción no
relacionado.

.2 Requerimientos de personal. Los requerimientos de personal son los que

definen qué tipos de competencias son las que se requieren de parte de
qué tipo de individuos o grupos y en qué momentos. Los requerimientos de
 personal son un subconjunto de requerimientos de recursos globales que
se identifican durante la planificación de los recursos (descrito en la Sección
7.1)
.3 Restricciones. Las restricciones son aquellos factores que limitan las
opciones del equipo del proyecto. Las opciones organizacionales del
proyecto pueden verse restringidas de muchas formas. Entre los factores
comunes que pueden restringir la forma como se organice el equipo, se
encuentran, pero sin limitarse a, los siguientes:

. La estructura organizacional de la organización ejecutante – el que

una organización tenga una estructura básica del tipo matriz fuerte quiere decir
que el gerente del proyecto tiene un rol relativamente más fuerte que el de aquella
organización cuya estructura básica sea una matriz débil (para una descripción
más detallada de las estructuras organizacionales, sírvase consultar la Sección
2.3.3).
. Acuerdos de negociación colectiva – los acuerdos contractuales con
sindicatos u otras agrupaciones de empleados puede requerir de ciertos roles o
relaciones de mando (en esencia, el grupo de empleados es un accionista).
. Preferencias del equipo de gestión del proyecto – si los miembros del
equipo de gestión del proyecto han tenido éxito con ciertas estructuras durante
gestiones pasadas, entonces es probable que consientan estructuras similares en
el futuro.
. Designaciones de personas esperadas -la forma cómo se organice el
proyecto es, a menudo, influenciada por las competencias de individuos
específicos.

9.1.2 Herramientas y Técnicas para la Planificación Organizacional

.1 Plantillas. Aunque cada proyecto es único, la mayoría de los proyectos

tendrán similitudes con otro proyecto, hasta cierto punto. La utilización de
definiciones de rol y responsabilidad o de relaciones de mando de un
proyecto similar puede ayudar a acelerar el proceso de planificación
organizacional.
.2 Prácticas de recursos humanos. Muchas organizaciones tienen una
variedad de políticas, pautas y procedimientos que pueden ayudar al equipo
de gestión del proyecto con los distintos aspectos de la planificación
organizacional. Por ejemplo, una organización que ve a los gerentes como
“instructores” es probable que posea documentación sobre cómo se debe
cumplir el rol de “entrenador”.
.3 Teoría organizacional. Existe una abundante literatura que describe la
forma cómo pueden y deben estructurarse las organizaciones. Aunque solo
un pequeño sub-conjunto de esta copiosa literatura está específicamente
orientada hacia la organización de proyectos, el equipo de gestión del
proyecto debe estar, por lo general, familiarizado con el tema de la teoría
organizacional, de modo tal de estar mejor preparado para responder a los
requerimientos del proyecto.
 .4 Análisis de accionistas. Se deberá analizar la identificación de los
accionistas y las necesidades de los distintos accionistas, de forma tal de
asegurar que se cumplan sus necesidades. La Sección 10.1.2.1 describe el
análisis de los accionistas en forma más detallada.

9.1.3 Resultados de la Planificación Organizacional

.1 Designaciones de roles y responsabilidades. Los roles (quién hace qué)

y las responsabilidades (quién decide qué) del proyecto deben ser
asignadas a los accionistas adecuados del proyecto. Los roles y
responsabilidades pueden variar con el tiempo. Muchos roles y
responsabilidades serán asignadas a los accionistas que estén más
activamente involucrados con el trabajo del proyecto, como por ejemplo el
gerente del proyecto, otros miembros del equipo de gestión y
contribuyentes individuales.

Los roles y responsabilidades del gerente del proyecto son generalmente críticas
en la gran mayoría de los proyectos, pero varían significativamente según el área
de aplicación.

Los roles y responsabilidades del proyecto deben estar estrechamente ligadas

a la definición del alcance del proyecto. Para este propósito, es frecuente que
se utilice una Matriz de Asignación de Responsabilidades (o MAR, ver Figura
9-2). En el caso de los grandes proyectos, se pueden desarrollar MAR’s en
distintos niveles. Por ejemplo, un MAR de alto nivel puede definir qué grupo o
unidad es la responsable de cada uno delos componentes de la estructura de
división del trabajo; en tanto que las MAR’s de bajo nivel se utilizan dentro del
grupo para asignar los roles y responsabilidades por actividades específicas a
determinados individuos.
 .2 Plan de gestión del personal. El plan de gestión del personal describe
cómo y cuándo se incorporarán y retirarán los recursos humanos del equipo
del proyecto. El plan del personal puede ser formal o informal, altamente
detallado o ampliamente estructurado, según sean las necesidades del
proyecto. Se trata de un elemento subsidiario del plan global del proyecto
(ver Sección 4.1, Desarrollo del Plan del Proyecto).

El plan de gestión del personal normalmente incluye los histogramas de

recursos, como se puede apreciar en la Figura 9-3.
Se debe prestar especial atención a cómo se liberan los miembros del equipo
de proyectos (individuos o grupos) a medida que ya no son necesarios dentro
del proyecto. Los procedimientos adecuados de reasignación pueden:

. Reducir los costos, disminuyendo o eliminando la tendencia a “hacer

trabajo” para llenar el tiempo entre esta asignación y la siguiente.
. Mejorar la moral, reduciendo o eliminando la incertidumbre respecto
de futuras oportunidades de empleo.

.3 Organigrama. El organigrama es cualquier despliegue gráfico de las

relaciones de mando del proyecto. Este puede ser formal o informal, altamente
detallado o ampliamente estructurado, según sean las necesidades del
proyecto. Por ejemplo, es improbable que el organigrama de un proyecto de
servicios internos compuesto por tres a cuatro personas, tenga el rigor y el
detalle del organigrama de un equipo de respuesta ante accidentes compuesto
por 3.000 personas.
 La Estructura de División Organizacional (EDO) es un tipo específico de
organigrama que muestra cuáles son las unidades organizacionales
responsables de cuáles paquetes de trabajo.

.4 Detalle de respaldo. El detalle de respaldo para la planificación

organizacional varía según el área de aplicación y el tamaño del proyecto.
Entre la información que frecuentemente se suministra como detalle de
respaldo se incluye, pero sin limitarse a:

. Impacto organizacional – qué alternativas se obstaculizan al

organizarse de esta manera.
. Descripciones de cargo – descripciones escritas por tipo de trabajo
de las competencias, responsabilidades, autoridad, ambiente físico y otras
características relacionadas con el desempeño de un determinado trabajo.
También se conocen como descripciones laborales.
. Necesidades de capacitación – en caso que se espere que el
personal a ser asignado no tenga las competencias necesarias por el proyecto,
dichas competencias tendrán que ser desarrolladas como parte del proyecto.

9.2 ADQUISICIÓN DE PERSONAL

La adquisición de personal implica obtener los recursos humanos (individuos o
grupos) asignados a y trabajar en el proyecto. En la mayoría de los ambientes, es
posible que no estén disponibles los “mejores” recursos, y que el equipo de
gestión del proyecto deba asegurarse de que los recursos disponibles cumplan
con los requerimientos del proyecto.

9.2.1 Entradas para la Adquisición de Personal

.1 Plan de gestión del personal. El plan de gestión del personal se describe

en la Sección 9.1.3.2. Este incluye los requerimientos de personal del
proyecto, como se describe en la Sección 9.1.1.2.
.2 Descripción del pool de personal. Cuando el equipo de gestión del
proyecto tiene la capacidad de influir en o de dirigir las asignaciones de
personal, éste debe considerar las características del personal
potencialmente disponible. Dichas consideraciones incluyen, sin limitarse
a:

. Experiencia previa -¿Han realizado los individuos o grupos un trabajo

similar o relacionado con éste? ¿L o han hecho bien?
. Intereses personales - ¿Están los individuos o grupos interesados en
trabajar en este proyecto?
. Características personales -¿Existe probabilidad de que los
individuos o grupos trabajen bien en conjunto como equipo?
. Disponibilidad - ¿Estarán disponibles en los momentos necesarios
aquellos individuos o grupos más deseables?
. Competencias y destrezas -¿Cuáles son las competencias
requeridas y a qué nivel?

.3 Prácticas de contratación. Es posible que una o más de las

organizaciones involucradas en el proyecto tenga políticas, pautas o
procedimientos que normen las asignaciones de personal. En estos casos,
tales prácticas actúan como una restricción en el proceso de adquisición de
personal.

9.2.2. Herramientas y Técnicas para la Adquisición de Personal

 .1 Negociaciones. En la gran mayoría de los proyectos, las asignaciones de
personal deben negociarse. Por ejemplo, el equipo de gestión del proyecto
puede tener que negociar con:

. Los gerentes funcionales responsables de asegurar que el proyecto

reciba adecuadamente el personal componente en el momento oportuno.
. Otros equipos de gestión de proyecto dentro de la organización
ejecutante, con el objeto de asignar adecuadamente los recursos especializados o
escasos.

Las competencias para influenciar del equipo (ver Sección 2.4.5, Influir en
la Organización) juegan un papel importante en la negociación de las
asignaciones de personal, al igual que la política de las organizaciones
involucradas. Por ejemplo, se puede premiar a un gerente funcional sobre la
base de la utilización del personal. Esto crea un incentivo para que el
gerente asigne al personal disponible que probablemente no cumpla con
todos los requerimientos del proyecto.

.2 Preasignación. En algunos casos, es posible preasignar personal al

proyecto. Este es frecuentemente el caso cuando (a) el proyecto es el
resultado de una propuesta competitiva, y se comprometió personal
específico como parte de la propuesta, o (b) el proyecto es un proyecto de
servicios internos y, las asignaciones de personal fueron definidas dentro
del permiso de ejecución del proyecto.
.3 Abastecimiento. La gestión de abastecimiento del proyecto (descrita en el
Capítulo 12) puede utilizarse para obtener que los servicios de individuos o
grupos de individuos específicos ejecuten las actividades del proyecto. Se
hace necesario del abastecimiento cuando la organización ejecutante
carece de personal interno para completar el proyecto (por ejemplo, como
resultado de una decisión consciente de no contratar a los individuos como
empleados de tiempo completo; como resultado de tener todo el personal
debidamente competente comprometido con otros proyectos; o como
resultado de otras circunstancias).

9.2.2 Resultados de la Adquisición de Personal

.1 Personal de proyecto asignado. El proyecto está dotado cuando se han

asignado confiablemente las personas adecuadas para trabajar en él. El
personal puede ser asignado a tiempo completo, a media jornada o, de
forma variable, según sean las necesidades del proyecto.
.2 Directorio del equipo del proyecto. El directorio del equipo del proyecto
lista todos los miembros del equipo del proyecto y otros accionistas. El
directorio puede ser formal o informal, altamente detallado o ampliamente
estructurado, según sean las necesidades del proyecto.

9.3 DESARROLLO DEL EQUIPO

El desarrollo del equipo implica tanto mejorar la capacidad de los accionistas para
contribuir como individuos, como así también mejorar o ampliar la capacidad del
equipo para funcionar como tal. El desarrollo individual (gerencial y técnico) es la
base necesaria para desarrollar el equipo. El desarrollo como equipo es crítico
para la capacidad del proyecto de cumplir sus objetivos.

Con frecuencia, el desarrollo del equipo de un proyecto se complica cuando los

miembros individuales del equipo están a cargo tanto de un gerente funcional
como del gerente del proyecto (para un análisis de las estructuras
organizacionales tipo matriz, sírvase consultar la Sección 2.3.3). La gestión
efectiva de esta doble relación jerárquica suele ser un factor crítico del éxito para
el proyecto y, generalmente, es de responsabilidad del gerente del proyecto.

Aun cuando el desarrollo de un equipo es descrito en el Capítulo 3 como uno de

los procesos ejecutores, el desarrollo del equipo ocurre a lo largo de todo el
proyecto.

9.3.1 Entradas para el Desarrollo de Equipos

.1 Personal del proyecto. El personal del proyecto se describe en la

Sección 9.2.3.1. Las asignaciones de personal definen implícitamente
las competencias de individuos y equipos disponibles.
.2 Plan del proyecto. El plan del proyecto se describe en la Sección
4.1.3.1. El plan del proyecto describe el contexto técnico
dentro del cual opera el equipo. .3 Plan de gestión del
personal. El plan de gestión del personal se describe en la
Sección 9.1.3.2.
.4 Informes de desempeño. Los informes de desempeño (descritos en la
Sección 10.3.3.1) dan una referencia al equipo del proyecto respecto del
desempeño con respecto al plan del proyecto.
.5 Retroalimentación externa. El equipo del proyecto debe medirse
periódicamente con respecto a las expectativas de aquellos que están
fuera del proyecto.
9.3.2 Herramientas y Técnicas para el Desarrollo del Equipo

.1 Actividades de formación de equipos. Las actividades de formación de

equipos incluyen la gestión y las acciones individuales realizadas específica
y principalmente con el propósito de mejorar el desempeño del equipo.
Muchas acciones- como la participación de miembros de equipo a nivel no-
gerencial en el proceso de planificación, o el establecimiento de reglas
básicas para arbitrar y tratar un conflicto-pueden producir el mejoramiento
del desempeño del equipo como un efecto secundario. Las actividades de
formación de equipos pueden ir de un ítem de agenda de cinco minutos en
una reunión de revisión de avances regulares a una experiencia extendida,
fuera del área y profesionalmente dirigida, diseñada para mejorar las
relaciones interpersonales entre los principales accionistas.

Esta una cantidad importante de literatura referida al tema de formación de

equipos. Por lo general, el equipo de gestión del proyecto debe estar
familiarizado con una serie de actividades de formación de equipos.

.2 Habilidades gerenciales generales. Las habilidades para la gestión

general (analizadas en la Sección 2.4) son de particular importancia para el
desarrollo del equipo.
.3 Sistemas de compensación y reconocimiento. Los sistemas de
compensación y reconocimiento son acciones de gestión formales que
promueven o refuerzan la conducta deseada. Para que sean efectivos y
eficaces, dichos sistemas deben servir de enlace entre el desempeño del
proyecto y la recompensa clara, explícita y alcanzable. Por ejemplo, un
gerente de proyectos que va a ser recompensado por alcanzar el objetivo
de costos del proyecto debe tener un nivel adecuado de control con
respecto a las decisiones de personal y abastecimiento. A menudo, los
proyectos deben contar con sistemas de reconocimiento y compensación
que sean propios, ya que es probable que la organización ejecutante no
sean los adecuados. Por ejemplo, se debe reconocer o recompensar la
voluntar por trabajar en sobretiempo, a fin de cumplir el objetivo de un
agresivo plan; la necesidad de trabajar sobretiempo como resultado de una
mala planificación no debiera ser objeto de ninguna consideración.

Los sistemas de compensación y reconocimiento deben considerar además las

diferencias culturales. Por ejemplo, es muy difícil desarrollar un mecanismo
adecuado de compensación de equipo en una cultura que premia el
individualismo.

.4 Colocación. Colocación implica colocar todos, o casi todos, los miembros

más activos del equipo del proyecto en la misma designación física, con el
objeto de mejorar su capacidad para desempeñarse como equipo. La
colocación es ampliamente utilizada en los proyectos más grandes y puede
resultar efectiva también en los proyectos más pequeños. En algunos
 proyectos, la colocación puede ser una opción; cuando ello no sea factible,
una alternativa puede ser la programación frecuente de reuniones cara-a-
cara para fomentar la interacción.
.5 Capacitación. La capacitación incluye todas las actividades diseñadas para
mejorar las competencias del equipo del proyecto. Algunos autores hacen
una distinción entre capacitación, educación y desarrollo, pero no obstante,
las distinciones no son ni consistentes ni ampliamente aceptadas.
La capacitación puede ser formal (por ejemplo, la capacitación en aula, la
capacitación por computadores) o informal (por ejemplo, la
retroalimentación de parte de otros miembros del equipo). Existe una
abundante literatura referida a como dar capacitación a los adultos.

Si los miembros del equipo del proyecto carecen de las habilidades técnicas
o gerenciales necesarias, será imprescindible que dichas habilidades se
desarrollen como parte del proyecto; en caso contrario, se deberán tomar
los pasos que permitan re-dotar adecuadamente el proyecto. Los costos
directos o indirectos por capacitación son generalmente pagados por la
organización ejecutante.

9.3.3 Resultados del Desarrollo del Equipo

.1 Mejoramientos en el desempeño. Los mejoramientos en materia de

desempeño del equipo pueden provenir de varias fuentes y pueden afectar
muchas áreas específicas de desempeño del equipo; por ejemplo:

. Los mejoramiento de habilidades de individuos que puedan permitir

que una persona especifica realice las mismas actividades de manera más eficaz.
. Los mejoramientos en las conductas del equipo (por ejemplo, arbitrar
y tratar el conflicto),pueden permitir que miembros del equipo del proyecto
dediquen un mayor porcentaje de sus esfuerzos a actividades técnicas.
. Los mejoramientos en las competencias del individuo o del equipo
pueden facilitar la identificación y desarrollo de mejores formas de realizar el
trabajo del proyecto.

.2 Entrada para las evaluaciones de desempeño. El personal del proyecto

debe por lo general proveer las pautas o entradas para las evaluaciones de
cualquier miembro del personal del proyecto con quienes interactúen en
forma significativa.

Gestión de las Comunicaciones del Proyecto

La Gestión de las Comunicaciones del Proyecto incluye los procesos requeridos
para asegurar la generación, recopilación, diseminación, almacenamiento y,
finalmente, la disposición puntual y adecuada, de la información del proyecto. Esta
establece los vínculos críticos entre personas, ideas e información que son
necesarios para el éxito. Todo aquel que esté involucrado con el proyecto debe
estar preparado para enviar y recibir comunicaciones, y debe entender cómo las
comunicaciones en las que están involucrados como individuos, afectan el
proyecto como un todo. La Figura 10-1 presenta una descripción general de los
siguientes procesos principales:

1. 10.1 Planificación de las Comunicaciones – determinar las

necesidades de información y de comunicación de los accionistas: quién necesita
qué información, cuándo la necesitarán y cómo se les hará llegar.
2. 10.2 Distribución de la Información – hacer que la información
necesaria esté disponible para los accionistas del proyecto en forma oportuna.
3. 10.3 Reporte de Desempeño / Rendimiento – recopilar y diseminar la
información de desempeño / rendimiento. Esto incluye los informes de estado,
mediciones de avance y predicciones.
4. 10.4 Cierre Administrativo – generación, recopilación y diseminación de
información para formalizar el término de una fase o proyecto.

Estos procesos interactúan unos con otros y con los procesos de las demás áreas
de conocimiento también. Cada proceso puede involucrar el esfuerzo de uno o
más individuos o grupos de individuos, según sean las necesidades del proyecto.
Cada proceso suele ocurrir, al menos, una vez en cada fase del proyecto.

Aunque los procesos se presentan aquí como componentes discretos con

interfaces bien definidas, en la práctica estos pueden traslaparse e interactuar de
formas que aquí no se detallan. Las interacciones de los procesos se analizan
detalladamente en el Capítulo 3.

La capacidad de comunicar de la gestión general (descrita en la Sección 2.4.2) se

relaciona con, pero no igual que, la gestión de las comunicaciones del proyecto.
Comunicar es un tema más amplio e involucra una estructura importante de
conocimiento que no es única para el contexto del proyecto. Por ejemplo:
. Modelos de emisor – receptor – lazos de referencia, barreras para
las comunicaciones, etc.
. Selección de los medios – cuándo comunicarse por escrito versus
cuándo comunicarse oralmente, cuándo escribir un memo informal versus cuándo
escribir un informe formal.
. Estilo de redacción – voz activa versus voz pasiva, estructura de las
frases, elección de las palabras, etc.
. Técnicas de presentación – lenguaje corporal, diseño de las ayudas
audiovisuales, etc.
. Técnicas de gestión de reuniones – preparación de una agenda,
manejo de conflictos

10.1 PLANIFICACIÓN DE LAS COMUNICACIONES

La planificación de las comunicaciones implica determinar las necesidades de

información y de comunicación de los accionistas: quién necesita qué información,
cuándo la necesitarán, cómo se les entregará, y por quién. Aunque todos los
proyectos comparten la necesidad de comunicar información del proyecto, las
necesidades informativas y los métodos de distribución varían significativamente.
Un factor importante para el éxito del proyecto es la identificación de las
necesidades informativas de los accionistas y determinar los medios adecuados
para satisfacer aquellas necesidades.

En la mayoría de los proyectos, gran parte de la planificación de las

comunicaciones se lleva a cabo como parte de las primeras fases del proyecto.
Sin embargo, se deben revisar regularmente los resultados de este proceso a lo
largo de todo el proyecto, realizando una evaluación de lo necesario para asegurar
su continua aplicabilidad.

La planificación de las comunicaciones suele estar estrechamente ligada a la

planificación organizacional (que se describe en la Sección 9.1), dado que
la
estructura organizacional del proyecto tendrá un efecto preponderante en los
requerimientos de comunicaciones del proyecto.

10.1.1 Entradas para la Planificación de las Comunicaciones

.1 Requerimientos de comunicaciones. Los requerimientos de

comunicaciones son la suma de los requerimientos de información de los
 accionistas del proyecto. Los requerimientos se definen, combinando el
tipoy formato de la información requerida con un análisis del valor de esa
información. Los recursos del proyecto sólo se desembolsan en el acto de
comunicar la información que contribuya al éxito, o de hacerlo en donde la
falta de comunicación puede conducir al fracaso. La información
comúnmente requerida para determinar los requerimientos de
comunicaciones del proyecto incluye:
. Organización del proyecto y relaciones de responsabilidad de los
accionistas.
. Disciplinas, departamentos y especialidades involucrados con el
proyecto.
. Logística de cómo los muchos individuos se verán involucrados con
el proyecto y en qué lugares.
. Necesidades de información externa (por ejemplo, comunicarse con
los medios).

.2 Tecnología de las comunicaciones. Las tecnologías o métodos

empleados para transferir información desde y hacia los accionistas del
proyecto, pueden variar significativamente: de breves conversaciones a
extensas reuniones, de simples documentos escritos a programas y bases
de datos inmediatamente accesibles en línea.

Entre los factores de la tecnología de la comunicación que pueden afectar

al proyecto, se incluyen:

. La inmediatez de la necesidad de información -¿es el éxito del

proyecto dependiente de contar con información frecuentemente actualizada o
basta con los reportes escritos emitidos en forma regular?
. La disponibilidad de tecnología - ¿Son adecuados los sistemas ya
instalados o las necesidades del proyecto demandan que se les cambie?
. El personal esperado del proyecto -¿son compatibles los sistemas de
comunicación propuestos con la experiencia y experticia de los participantes del
proyecto, o serán necesarios una capacitación y aprendizaje extensivos?
. La longitud del proyecto -¿Es probable que la tecnología existente
cambie antes de que termine el proyecto?

.3 Restricciones. Las restricciones son factores que limitarán las opciones del
equipo de gestión del proyecto. Por ejemplo, si se van a comprar recursos
importantes para el proyecto, se deberá prestar mayor atención al manejo
de la información contractual.

Cuando se ejecuta un proyecto por contrato, por lo general existen

disposiciones contractuales específicas que afectan la planificación de las
comunicaciones.

.4 Supuestos. Ver Sección 4.1.1.5.

10.1.2 Herramientas y Técnicas para la Planificación de las Comunicaciones

.1 Análisis de accionistas. Se deben analizar las necesidades de

información de los distintos accionistas, de modo tal de desarrollar una
visión metódica y lógica de sus necesidades de información y las fuentes
que permitan satisfacer aquellos requerimientos (el tema de los accionistas
del proyecto se analiza más detalladamente en la Sección 2.2). Este
análisis debe considerar los métodos y tecnologías adecuadas al proyecto
que permitan proveer la información requerida. Se debe procurar evitar el
gasto de recursos en tecnología inadecuada o en información innecesaria.

10.1.3 Resultados de la Planificación de las Comunicaciones

.1 Plan de gestión de las comunicaciones. Un plan de gestión de las

comunicaciones es un documento que entrega:

. Una estructura de recopilación y archivo que detalle los métodos que

se emplearán para recopilar y guardar los distintos tipos de información. Los
procedimientos deben referirse, además, a la compilación y diseminación de
actualizaciones y correcciones de material previamente distribuido.
. Una estructura de distribución que detalla a quién fluirá la
información (informes de avances, datos, programas, documentación técnica,
etc.), y qué métodos (informes escritos, reuniones, etc.) se utilizarán para distribuir
los distintos tipos de información. Esta estructura debe ser compatible con las
responsabilidades y relaciones de mando descritas por el organigrama del
proyecto.
. Una descripción de la información que se va a distribuir, incluido el
formato, contenido, nivel de detalle y convenciones / definiciones que se
emplearán.
. Programas de producción que muestren cuándo se producirá cada
tipo de comunicación.
. Métodos para acceder a la información entre las comunicaciones
programadas.
. Un método para actualizar y refinar el plan de gestión de las
comunicaciones, a medida que el proyecto avance y se desarrolle.

El plan de gestión de las comunicaciones puede ser formal o informal,

altamente detallado o ampliamente estructurado, según sean las
necesidades del proyecto. Se trata de un componente subsidiario del plan
global del proyecto (descrito en la Sección 4.1).

10.2 DISTRIBUCIÓN DE LA INFORMACIÓN

La distribución de la información implica lograr que la información requerida esté

disponible para los accionistas del proyecto en forma oportuna. Esto incluye la
implementación del plan de gestión de las comunicaciones, como así también
responder a las solicitudes inesperadas de información.

10.2.1 Entradas para la Distribución de la Información

.1 Resultados del trabajo. Los resultados del trabajo se describen en la

Sección 4.2.3.1.
.2 Plan de gestión de las comunicaciones. El plan de gestión de las
comunicaciones se describe en la Sección 10.1.3.1.
.3 Plan del proyecto. El plan del proyecto se describe en la Sección 4.1.3.1.

10.2.2 Herramientas y Técnicas para la Distribución de la Información

.1 Habilidades de comunicación. Las habilidades de comunicación se

utilizan para intercambiar información. El emisor es el responsable de que
la información sea clara, inambigüa y completa, de modo tal que el receptor
pueda recibirla correctamente y confirmar que se ha entendido
adecuadamente. El receptor es responsable de asegurarse de que la
información sea recibida en su cabalidad y correctamente entendida. El
acto de comunicar tiene muchas dimensiones:

. Escrita y oral, oír y hablar.

. Interna (dentro del proyecto) y externa (al cliente, los medios, el
público, etc.).
. Formal (informes, resúmenes, etc.) e informal (memos,
conversaciones ad hoc, etc.).
. Vertical (hacia arriba y hacia debajo de la organización) y horizontal
(con colegas).

.2 Sistemas de recuperación de información. La información puede ser

compartida por los miembros del equipo y por los accionistas a través de
una variedad de métodos, que incluyen sistemas de archivo manuales,
bases de datos electrónicas, software de gestión de proyectos y sistemas
que permiten el acceso a documentación electrónica como son los planos
de ingeniería, especificaciones de diseño, planos de prueba, etc.
 .3 Métodos de distribución de la información. La información del proyecto
se puede distribuir, utilizando una variedad de métodos incluidas las
reuniones de proyecto, la distribución de documentos en copia dura, el
acceso compartido a bases de datos electrónicas en red, facsímil, correo
electrónico, correo de voz, video conferencia e redes internas al proyecto
(Intranet).

10.2.3 Resultados de la Distribución de la Información

.1 Registros del proyecto. Los registros del proyecto pueden incluir

correspondencia, memorandos y documentos que describan el proyecto.
Esta información debe, hasta donde sea posible y adecuado, mantenerse
en un modo organizado. Los miembros del equipo del proyecto pueden, a
menudo, mantener registros personales en un computador portátil del
proyecto.
.2 Informes de proyecto. Informes formales del proyecto sobre estado o
avance del proyecto y/o asuntos del mismo.
.3 Presentaciones del proyecto. El equipo del proyecto suministra
información de manera formal, o informal, a cualquiera o a todos los
accionistas del proyecto. La información es relevante a las necesidades de
la audiencia, y el método de presentación es adecuado.
10.3 REPORTE DE DESEMPEÑO / RENDIMIENTO

El reporte de rendimiento / desempeño implica la recopilación y diseminación de la

información de rendimiento / desempeño para proveer a los accionistas con
información acerca de cómo se están utilizando los recursos para lograr los
objetivos del proyecto. Este proceso incluye:

Informe de estado – describe en qué punto se encuentra ahora el

proyecto
– por ejemplo, el estado de avance en relación al programa y a la métrica
del presupuesto.
. Informe de avance – describe qué ha logrado el equipo del proyecto
– por ejemplo, porcentaje terminado de acuerdo a programa, o qué se ha
terminado versus que está en proceso.
. Predicción – predecir el estado y avance del proyecto a futuro.

El informe o reporte de rendimiento / desempeño debe proveer generalmente

información acerca del alcance, programa, costo y calidad. Muchos proyectos
también requieren información sobre riesgos y abastecimiento. Los informes se
pueden preparar en forma exhaustiva o por excepción.
10.3.1 Entradas para el Reporte de Desempeño / Rendimiento

.1 Plan del proyecto. El plan del proyecto se analiza en la Sección 4.1.3.1. El

plan del proyecto contiene las distintas bases o pautas que se utilizarán
para evaluar el desempeño / rendimiento del proyecto.
.2 Resultados del trabajo. Los resultados del trabajo – qué prestaciones han
sido total o parcialmente terminadas, qué costos (y/o recursos) se han
realizado o comprometido, etc. – son un consecuencia o resultado de la
ejecución del plan del proyecto (analizado en la Sección 4.2.3.1). Los
resultados del trabajo deben ser informados dentro de la estructura
establecida por el plan de gestión de las comunicaciones. Con el objeto de
realizar informes útiles sobre el desempeño / rendimiento, es esencial que
la información sobre los resultados del trabajo sea exacta y uniforme.
.3 Otros registros del proyecto. Los registros del proyecto se analizan en la
Sección 10.2.3.1. Además del plan del proyecto y de los resultados del
trabajo del proyecto, a menudo existen otros documentos del proyecto que
contienen información relacionada con el contexto del proyecto, y que, por
tanto, debe ser considerada al momento de evaluar el desempeño /
rendimiento del proyecto.

10.3.2 Herramientas y Técnicas para el Reporte de Rendimiento / Desempeño

.1 Revisiones de rendimiento / desempeño. Las revisiones de rendimiento /

desempeño son reuniones que se llevan a cabo con el objeto de evaluar el
estado y/o el avance del proyecto. Estas revisiones se utilizan,
comúnmente, en conjunto con una o más de las técnicas de reporte de
rendimiento / desempeño que se describen más abajo.
.2 Análisis de la varianza. El análisis de la varianza implica comparar los
resultados reales del proyecto con los resultados planificados o esperados.
Las varianzas de costo y programa son las más frecuentemente analizadas,
pero las variaciones con respecto al plan en áreas de alcance, recursos,
calidad y riesgos suelen ser de igual o mayor importancia.
.3 Análisis de tendencias. El análisis de tendencias implica examinar los
resultados del proyecto con el pasar del tiempo, a fin de determinar si el
 rendimiento / desempeño está mejorándose o deteriorándose.
.4 Análisis del valor ganado. El análisis del valor ganado en sus distintas
formas es el método más comúnmente utilizado para la medición del
rendimiento / desempeño. Este integra el alcance, el costo ( o el recurso) y
las medidas del programa para ayudar al equipo de gestión del proyecto a
evaluar el rendimiento / desempeño del mismo. El valor ganado (VG)
implica calcular los tres valores claves de cada actividad.

. El Valor Planificado (VP), previamente denominado el costo

presupuestado del trabajo programado (CPTP), es aquella porción de la
estimación de costo aprobada que se va a gastar en la actividad durante un
determinado periodo.
. El Costo Real (CR), previamente denominado el costo real del
trabajo realizado (CRTR), es el total de costos realizados en la realización del
trabajo de la actividad durante un determinado periodo. Este Costo Real debe
corresponder con lo que se haya presupuestado como VP y el VG (ejemplo: las
horas directas solamente, sólo los costos directos, o todos los costos incluidos los
costos indirectos).
. El VG, previamente denominado costo presupuestado del trabajo
realizado (CPTR), es el valor del trabajo realmente realizado.

Estos tres valores se utilizan en forma combinada para establecer las medidas que
permitan señalar si se está o no realizando el trabajo de acuerdo a lo planificado.
Las medidas más comúnmente empleadas son la varianza de costos (VC) (VC =
VG – CR), y la varianza del programa (VP) (VP = VG – Vplanificado). Estos dos
valores, la VC y la VP se pueden convertir o transformar en indicadores de
eficiencia, de forma tal de reflejar el rendimiento de los costos y del programa de
cualquier proyecto. El índice del rendimiento de los costos (IRC = VG/CR) es el
más comúnmente utilizando indicador de costo-eficiencia. El IRC acumulativo (la
suma de todos los presupuestos de VG individuales divididos por la suma de todos
los CRs individuales) se utiliza, ampliamente, para predecir los costos del proyecto
al término de éste. Además, a veces se utiliza el índice de rendimiento del
programa (IRP = VG/Vplanificado) en conjunto con el IRC para predecir las
estimaciones de término del proyecto.

.5 Herramientas y técnicas de distribución de la información. Los informes

de rendimiento / desempeño se distribuyen utilizando las herramientas y
técnicas descritas en la Sección 10.2.2.

10.3.3 Resultados del Reporte de Rendimiento / Desempeño

.1 Informes de rendimiento / desempeño. Estos informes organizan y

resumen la información recopilada y presenta los resultados de cualquier
tipo de análisis. Los informes deben suministrar los tipos de información y el
nivel de detalle que sea exigido por los distintos accionistas, según lo
documentado en el plan de gestión de las comunicaciones.

Los formatos para comunes para los informes de rendimiento / desempeño

incluyen gráficos de barras (también llamados cartas Gantt), curvas S y
tablas. La Figura 10-2 utiliza curvas S para desplegar los datos del análisis
cumulativo del VG; mientras que la Figura 10-3 despliega un conjunto
diferente de información de VG en forma tabular.

.2 Solicitudes de cambio. El análisis del rendimiento del proyecto suele

generar una solicitud de cambio en algún aspecto de éste. Estas
solicitudes de cambio son manejadas de la forma como se describe en los
distintos procesos de control de cambios (por ejemplo, gestión de cambio
de alcance, control de programa, etc.).

10.4 CIERRE ADMINISTRATIVO

El proyecto o fase, luego de ya sea lograr sus objetivos o de terminarse por otras
razones, requiere de su cierre o término. El cierre administrativo consiste en
documentar los resultados del proyecto para formalizar la aceptación del producto
del proyecto por parte del auspiciador, o cliente. Este incluye recopilar los registros
del proyecto; asegurarse de que estos reflejen las especificaciones finales;
analizar el éxito del proyecto, la eficacia y las lecciones aprendidas; y, archivar
dicha información para futura referencia.

Las actividades del cierre administrativo no deben postergarse hasta el término del
proyecto. Cada fase del proyecto debe terminarse en forma adecuada, de modo
tal de asegurar que no se pierda información útil o importante. Además, se deben
actualizar las habilidades de los empleados en la base de datos del pool de
personal, a fin de reflejar las nuevas habilidades y los aumentos de sus destrezas.

10.4.1 Entradas para el Cierre Administrativo

.1 Documentación de medición del rendimiento / desempeño. Debe estar

disponible para su revisión durante el cierre administrativo toda la
documentación producida para registrar y analizar el rendimiento del
proyecto, incluidos los documentos de planificación que establecieron la
estructura para la medición del rendimiento / desempeño.
.2 Documentación del producto. Debe estar disponible para su revisión
durante el cierre administrativo los documentos producidos para describir el
producto del proyecto (planes, especificaciones, documentación técnica,
planos, archivos electrónicos, etc. – la terminología varía según el área de
aplicación).
.3 Otros registros del proyecto. Los registros del proyecto se analizan en la
Sección 10.2.3.1.

10.4.2 Herramientas y Técnicas para el Cierre Administrativo

.1 Herramientas y técnicas para el reporte de rendimiento / desempeño.

Las herramientas y técnicas se analizan en la Sección 10.3.2.
.2 Informes del proyecto. Ver Sección 10.2.3.2.
.3 Presentaciones del proyecto. Ver la Sección 10.3.3.3.
10.4.3 Resultados del Cierre Administrativo

.1 Archivos del proyecto. Se debe preparar un conjunto completo de

registros indexados del proyecto para fines de archivo de las partes
respectivas. Se deberá actualizar cualquier base de datos histórica
específica del proyecto o del programa. Cuando los contratos sean
ejecutados por contrato, o cuando estos impliquen una gestión de
abastecimiento importante, se deberá prestar una especial atención al
proceso de archivo de los registros financieros.
.2 Cierre del proyecto. La confirmación de que el proyecto ha cumplido
todos los requerimientos de los usuarios del producto del proyecto (el
usuario ha aceptado formalmente los resultados y las prestaciones del
proyecto y los requerimientos de la organización que los provee – por
ejemplo, las evaluaciones de personal, los informes de presupuestos, las
lecciones aprendidas, etc.).
.3 Lecciones aprendidas. Las lecciones aprendidas son analizadas en la
Sección 4.3.3.3.

Gestión de Riesgos del Proyecto

La Gestión de Riesgos del Proyecto es un proceso sistemático que consiste en
identificar, analizar y responder al riesgo del proyecto. Esto incluye maximizar la
probabilidad y las consecuencias de eventos positivos y, minimizar la probabilidad
y consecuencias de eventos adversos para con los objetivos del proyecto. La
Figura 11-1 presenta una descripción general de los siguientes procesos
principales:

1. 11.1 Planificación de la Gestión de Riesgos – decidir cómo abordar y

planificar las actividades de gestión de riesgos de un proyecto.
2. 11.2 Identificación del riesgo – determinar qué riesgos podrían afectar
al proyecto y documentar sus características.
3. 11.3 Análisis Cualitativo del Riesgo – realizar un análisis cualitativo de
los riesgos y las condiciones para priorizar sus efectos en los objetivos del
proyecto.
4. 11.4 Análisis Cuantitativo del Riesgo – medir la probabilidad y las
consecuencias de los riesgos y predecir sus implicaciones para con los objetivos
del proyecto.
5. 11.5 Planificación de la Respuesta a los Riesgos – desarrollar los
procedimientos y técnicas para mejorar las oportunidades y reducir las amenazas
a los objetivos del proyecto.
6. 11.6 Monitoreo y Control de los Riesgos – monitorear los riesgos
residuales, identificar los nuevos riesgos, ejecutar los planes de reducción del
riesgo, y evaluar su eficacia a través del ciclo de vida del proyecto.
Estos procesos interactúan unos con otros y con los procesos de las demás áreas
de conocimiento. Cada proceso ocurre, generalmente, al menos una vez en cada
proyecto. Aunque los procesos se presentan aquí como componentes discretos
con interfaces bien definidas, en la práctica estos pueden traslaparse e interactuar
de formas que aquí no se detallan. Las interacciones de los procesos se analizan
detalladamente en el Capítulo 3.

El riesgo del proyecto es un evento o condición inciertos que, si ocurriera, tiene un

efecto positivo o bien uno negativo en un objetivo del proyecto. Un riesgo tiene
una causa y, si ésta llegara a ocurrir, una consecuencia. Por ejemplo, una causa
puede ser la solicitud de un permiso o contar con personal limitado asignado al
proyecto. El evento de riesgo es que el permiso puede demorar más de lo
planificado, o que el personal puede no ser el adecuado para la tarea. Si ocurriera
cualesquiera de estos eventos inciertos, habrá una consecuencia en el costo,
programa, o calidad del proyecto. Las condiciones de riesgos podrían incluir
aquellos aspectos del ambiente del proyecto que pueden contribuir al riesgo del
mismo, como por ejemplo malas prácticas de gestión de proyectos, o la
dependencia en participantes externos que no se pueden controlar.

El riesgo del proyecto incluye tanto las amenazas para con los objetivos del
proyecto como las oportunidades para mejorar aquellos objetivos. Esto tiene su
origen en la incertidumbre que tienen incorporadas todos los proyectos. Los
riesgos conocidos son aquellos que han sido identificados y analizados, y para los
que puede ser posible contar con un plan de mitigación. Los riesgos desconocidos
no se pueden controlar, aunque los gerentes de proyectos pueden abordarlos,
aplicando un contingencia general basada en la experiencia pasada con proyectos
similares.

Las organizaciones perciben el riesgo en la medida que éste dice relación con las
amenazas al éxito del proyecto. Los riesgos que son amenazadas para el proyecto
pueden aceptarse si estos están en equilibrio con la compensación que se puede
obtener al asumir el riesgo. Por ejemplo, aceptar que un programa “fast track” (por
vía rápida) puede atrasarse es un riesgo que se asume para lograr una fecha de
término más anticipada. Los riesgos que son oportunidades pueden ser
aprovechados para beneficio de los objetivos del proyecto.

Para tener éxito, la organización debe comprometerse en abordar una gestión del
riesgo a lo largo de todo el proyecto. Una medida del compromiso organizacional
es la dedicación para recopilar información de alta calidad respecto de los riesgos
del proyecto y sus características

11.1 PLANIFICACIÓN DE LA GESTIÓN DEL RIESGO

La planificación de la gestión de riesgos es el proceso de decidir cómo abordar y

planificar las actividades de gestión del riesgo de un proyecto. Es importante
planificar los procesos de gestión de riesgos que se indican a continuación, de
forma tal de asegurar que el nivel, tipo y visibilidad de la gestión del riesgo sean
conmensurados tanto con el riesgo como con la importancia del proyecto para con
la organización.

11.1.1 Entradas para la Planificación del Riesgo

.1 Permiso legal del proyecto. El permiso legal del proyecto se analiza en la

 Sección 5.1.3.1.
.2 Políticas de gestión de riesgos de la organización. Algunas
organizaciones pueden tener enfoques predefinidos para el análisis y
respuesta el riesgo que tienen que ser acordes para un proyecto en
particular.
.3 Roles y responsabilidades definidas. La planificación se verá afectada
por los roles, responsabilidades y niveles de autoridad predefinidos para el
proceso de toma de decisiones.
.4 Plantilla para el plan de gestión del riesgo de la organización. Algunas
organizaciones tienen plantillas desarrolladas (o una norma pro-forma) para
que sean utilizadas por el equipo del proyecto. La organización irá
mejorando continuamente la plantilla, según sea su aplicación y utilidad en
el proyecto.
.5 Estructura de división del trabajo (EDT). La EDT se describe en la
Sección 5.3.3.1.

11.1.2 Herramientas y Técnicas para la Planificación de la Gestión de Riesgo

.1 Reuniones de planificación. Los equipos del proyecto realizan reuniones

de planificación con el propósito de desarrollar el plan de gestión de
riesgos. Entre los asistentes se incluye al gerente del proyecto, a los líderes
de equipos del proyecto, a todo aquellos que dentro de la organización
tienen la responsabilidad de administrarla planificación del riesgo y las
actividades de ejecución, los accionistas claves y otros, según sea
necesario. Estos utilizan las plantillas de gestión de riesgos y otras entradas
según corresponda.

11.1.3 Resultados de la Planificación de la Gestión de Riesgo

.1 Plan de gestión de riesgos. El plan de gestión de riesgos describe la

forma como se estructurará y ejecutará la identificación, los análisis
cualitativo y cuantitativo, la planificación de la respuesta, el monitoreo y el
control de los riesgos durante el ciclo de vida del proyecto. El plan de
gestión de riesgo no aborda las respuestas a los riesgos individuales – esto
es llevado a cabo en el plan de respuesta al riesgo, que se analiza en la
Sección 11.5.3.1. El plan de gestión de riesgo puede incluir lo siguiente:

Metodología. Define los enfoques, herramientas, y fuentes de

información que se pueden utilizar para ejecutar la gestión de riesgos en este
proyecto. Pueden ser adecuadas varios tipos diferentes de evaluaciones,
dependiendo de la etapa del proyecto, la cantidad de
información disponible y la flexibilidad que tenga la gestión de riesgos.
. Roles y responsabilidades. Define el liderazgo, el soporte y la
membresía del equipo de gestión de riesgos para cada tipo de acción del plan de
gestión de riesgos. Los equipos de gestión de riesgos organizados fuera de la
oficina de proyectos pueden ser capaces de realizan análisis de riesgos del
proyecto más independientes e insesgados que aquellos realizados por el equipo
de proyectos auspiciante.
. Presupuesto. Establece un presupuesto para la gestión de riesgos
del proyecto.
. Frecuencia. Define la frecuencia con que se realizará el proceso de
gestión de riesgos durante todo el ciclo de vida del proyecto. Los resultados deben
ser evaluados con suficiente antelación como para influir en las decisiones. Las
decisiones deben ser reevaluadas periódicamente durante la ejecución del
proyecto.
. Ponderación e interpretación. Se deberá contar con métodos de
puntuación e interpretación que sean adecuados al tipo y frecuencia de los análisis
de riesgos cualitativos y cuantitativos que se estén realizando. Los métodos en
cuestión deben determinarse en forma anticipada de modo tal de asegurar una
consistencia.
. Umbrales. Los criterios de umbral para los riesgos sobre los que se
va a actuar, por parte de quién y de qué manera. El dueño del proyecto, el cliente
o el auspiciador pueden tener un umbral de riesgo diferente. El umbral aceptable
forma la meta con respecto a la cual el equipo del proyecto medirá la eficacia de la
ejecución del plan de respuesta al riesgo.
. Formatos de reporte. Describe el contenido y el formato del plan de
respuesta al riesgo que se describe en la Sección 11.5.3.1. Define la forma como
se documentarán, analizarán y comunicarán los resultados de los procesos de
gestión de riesgo al equipo del proyecto, a los accionistas internos y externos, a
los auspiciadores y a terceros.
. Seguimiento. Documenta cómo se registrarán todas las facetas de
las actividades de riesgos para beneficio del actual proyecto, futuras necesidades
y lecciones aprendidas. Documenta si se auditarán o no los procesos de riesgos y
de qué manera.

11.2 IDENTIFICACIÓN DE LOS RIESGOS

La identificación de los riesgos implica determinar cuáles son los riesgos que
podrían afectar el proyecto y documentar sus características.
Entre los participantes de la identificación de los riesgos, generalmente se incluyen
los siguientes, en la medida de lo posible: el equipo del proyecto, el equipo de
gestión de riesgos, los expertos en temas particulares de otras partes de la
compañía, clientes, usuarios finales, otros gerentes del proyecto, accionistas y
expertos externos.

La identificación de los riesgos es un proceso iterativo. La primera iteración puede

ser realizada por una parte del equipo del proyecto, o bien por el equipo de gestión
de riesgos. Todo el equipo de proyectos y los principales accionistas pueden
realizar una segunda iteración. Para lograr un análisis insesgado , la iteración final
puede ser realizada por personas que no sean parte del proyecto.

A menudo, se pueden desarrollar e incluso implementar respuestas simples y

efectivas frente al riesgo, tan pronto como éste sea identificado.

11.2.1 Entradas para la Identificación de los Riesgos

.1 Plan de gestión de riesgos. Este plan se describe en la Sección 11.1.3.

.2 Resultados de la planificación del proyecto. La identificación de los
riesgos requiere de la comprensión de la misión, alcance y objetivos de
proyecto para el dueño, el auspiciador o los accionistas. Se deberán revisar
los resultados de los demás procesos de forma tal de identificar posibles
riesgos durante todo el proyecto. Estos pueden incluir, pero sin limitarse a
ello:

. Permiso legal del proyecto

. EDT.
. Descripción del producto.
. Programa y estimaciones de costos.
. Plan de recursos.
. Listas de supuestos y restricciones.

.3 Categorías de riesgos. Los riesgos que pueden afectar al proyecto para

peor o mejor pueden identificarse y organizarse en categorías de riesgos.
Las categorías de riesgos deben ser bien definidas y deben reflejar fuentes
comunes de riesgo para la industria o área de aplicación. Las categorías
incluyen lo siguiente:

. Riesgos técnicos, de calidad o de rendimiento / desempeño- como

por ejemplo la dependencia en tecnología compleja o no probada, metas de
rendimiento irreales, cambios a la tecnología utilizada o a las normas de la
industria durante el proyecto.
. Riesgos de la gestión del proyecto – como por ejemplo la mala
asignación de tiempo y recursos, calidad inadecuada del plan del proyecto, mal
uso de las disciplinas de gestión del proyecto.
. Riesgos organizacionales – como son los objetivos de costo, tiempo
y alcance que son internamente inconsistentes, falta de prioridad de los proyectos,
falta o interrupción del financiamiento y conflictos de recursos con otros proyectos
de la organización.
. Riesgos externos – como por ejemplo ambiente regulador o legal
variable, temas laborales, cambio de las prioridades del dueño, riesgo del país y el
clima. Los riesgos force majeure (“fuerza mayor) como son los terremotos, las
inundaciones y la rebelión civil, requieren generalmente de acciones de
recuperación contra desastres en vez de una gestión de riesgo.

.4 Información histórica. La información sobre proyectos anteriores que

pueda obtenerse de las siguientes fuentes:

. Archivos de proyecto – una o más de las organizaciones

involucradas en el proyecto pueden mantener registros de resultados de proyectos
previos, que se puedan utilizar para identificar riesgos. Estos pueden ser informes
finales de proyectos o planes de respuesta al riesgo. Además, pueden incluirse las
lecciones organizadas aprendidas que describan los problemas y sus
resoluciones, o bien pueden estar disponibles por medio de la experiencia de los
accionistas del proyecto u otros de la organización.
. Información publicada – bases de datos comerciales, estudios
académicos, benchmarking, y otros estudios publicados que puedan estar
disponibles para muchas áreas de aplicación.

11.2.2 Herramientas y Técnicas para la Identificación de los Riesgos

.1 Revisiones de documentación. Por lo general, los equipos de proyectos

realizan a modo de etapa inicial una revisión estructura de los planes y
supuestos del proyecto, tanto a niveles de alcance detallado como del
proyecto total, archivos de proyectos anteriores y otra información de tipo
similar. .2 Técnicas de recopilación de información. Entre los ejemplos de
las
técnicas de recopilación de información utilizadas en la identificación de
riesgos, se pueden incluir brainstorming; delphi; entrevistas y análisis de
fortalezas, debilidades, oportunidades y amenazas (FDOA).

Brainstorming. Esta es quizás la técnica de identificación de riesgos

más frecuentemente empleada. El objetivo es obtener una lista amplia de los
riesgos que pueden ser abordados más tarde en los procesos de análisis
cualitativo y cuantitativo.
El Brainstorming es realizado, generalmente, por el equipo del proyecto,
aunque esta técnica también puede ser ejecutada por un grupo multidisciplinario
de expertos. Bajo el liderazgo de un facilitador, estas personas generan ideas
acerca del riesgo del proyecto. Se identifican a gran escala las fuentes de riesgos,
y se dejan planteadas para que todos la revisen durante la reunión. A
continuación, se categorizar los riesgos por tipo de riesgo, y se perfeccionan sus
definiciones.
. Técnica de Delphi. Esta técnica es una manera de lograr el consenso
de los expertos respecto de un tema como puede ser el riesgo del proyecto. Se
identifican los expertos en riesgos de proyecto, pero estos participan en forma
anónima.

Un facilitador utiliza un cuestionario para solicitar ideas acerca de los riesgos

importantes del proyecto. Se presentan las respuestas y, luego, son hechas llegar
ante los expertos para mayores comentarios. En unas cuantas iteraciones de este
proceso, se puede llegar a un consenso. La técnica Delphi ayudar a reducir el
sesgo de la información y evita que cualquier persona tenga influencia indebida en
la consecuencia.

. Entrevistas. Es posible identificar los riesgos mediante entrevistas

con expertos en asuntos específicos o por expertos temáticos. La persona
responsable de la identificación de los riesgos identifica a los individuos
responsables, les resume el proyecto y les entrega información como puede ser la
EDT y el listado de supuestos. Las entrevistas identifican los riesgos del proyecto
sobre la base de su experiencia, información del proyecto u otras fuentes que
estos puedan encontrar útiles.
. Análisis de Fortalezas, Oportunidades Debilidades, y Amenazas
(FODA). Asegura la revisión del proyecto desde cada una de las

perspectivas del FODA, de modo tal de aumentar la extensión de los

riesgos considerados.

.3 Listas de verificación. Se pueden desarrollar listas para la identificación

de los riesgos, basándose en la información histórica y en el conocimiento
que se ha acumulado de proyectos previos similares o de otras fuentes de
información. Una de las ventajas de utilizar una lista de verificación es que
la identificación del riesgo es rápida y sencilla. Una desventaja sería que es
imposible construir una lista exhaustiva de los riesgos y, el usuario puede
efectivamente limitarse a las categorías que aparecen en el listado. Se
debe procurar explorar en aquellos ítemes que no aparezcan en una lista
de verificación estándar si se considera que estos son relevantes al
proyecto en cuestión. La lista debe itemizar todos los tipos de riesgos
posibles para el proyecto. Es importante que se revise la lista de
verificación como si fuera una etapa formal de cada procedimiento de cierre
de proyecto, a objetivo de mejorar el listado de riesgos potenciales, para
mejorar la descripción de los riesgos.
.4 Análisis de los supuestos. Cada proyecto se concibe y desarrolla sobre la
base de un conjunto de hipótesis, escenarios o supuestos. El análisis de los
supuestos es una técnica que explora la validez de los mismos. La técnica
permite identificar los riesgos para el proyecto a partir de supuestos
inexactos, inconsistentes o incompletos.
.5 Técnicas de diagramación. Las técnicas de diagramación pueden incluir:

. Diagramas de causa-y-efecto (también conocidas como diagramas

ishikawa o de espina de pescado) – son útiles para la identificación de las causas
de los riesgos (descritos en la Sección 8.1.2.3).
. Diagramas de flujo de sistemas o procesos – muestran de qué
manera los distintos elementos de un sistema se interrelacionan y su mecanismo
de causa (descritos en la Sección 8.1.2.3).
. Diagramas de influencia – una representación gráfica de un
problema que muestra las influencias causales, ordenamiento temporal de los
eventos y otras relaciones entre variables y consecuencias.

11.2.3 Resultados de la Identificación de los Riesgos

.1 Riesgos. Un riesgo es un evento o condición incierta que, de llegar a

ocurrir, tiene un efecto negativo o positivo en un objetivo del proyecto.
.2 Gatilladores. Los gatilladores, o algunas veces denominados síntomas del
riesgo o signos de advertencia, son indicaciones de que se ha producido un
riesgo o bien de que está a punto de ocurrir. Por ejemplo, el no
cumplimiento de los hitos intermedios puede ser una señal de advertencia
temprana de un atraso importante del programa. .3 Entradas a otros
procesos. La identificación de los riesgos puede identificar una
necesidad de mayor acción en otra área. Por ejemplo, la EDT puede no
tener detalles suficientes como para permitir la adecuada identificación de
los riesgos, o bien puede que el programa no esté completo o que no sea
completamente lógico.

11.3 ANÁLISIS CUALITATIVO DEL RIESGO

El análisis cualitativo del riesgo es el proceso por el cual se evalúa el impacto y la

probabilidad de los riesgos identificados. Este proceso prioriza los riesgos de
acuerdo a su efecto potencial en los objetivos del proyecto. El análisis cualitativo
de los riesgos es una forma de determinar la importancia de abordar los riesgos
específicos y de guiar las respuestas al riesgo. La criticidad puntual de las
acciones relacionadas con los riesgos puede magnificar la importancia de un
riesgo. La verificación de la calidad de la información disponible ayuda, también, a
modificar la evaluación del riesgo. El análisis cualitativo de los riesgos requiere
que se estudien la probabilidad y las consecuencias de los riesgos que se estén
considerando, mediante el empleo de métodos y herramientas de análisis
cualitativo establecidos. Las tendencias en los resultados cuando se repiten los
análisis cualitativos, pueden indicar a necesidad de más o menos acción de
gestión del riesgo. El uso de estas herramientas ayuda a corregir los sesgos que
suele haber en un plan de proyecto. El análisis cualitativo de los riesgos debe ser
revisado durante el ciclo de vida del proyecto para estar al día de los cambios en
los riesgos del proyecto. Este proceso puede conllevar un mayor estudio en el
análisis cuantitativo de los riesgos (11.4) o directamente a la planificación de las
respuestas a los riesgos (11.5).
11.3.1 Entradas para el Análisis Cualitativo de los Riesgos

.1 Plan de gestión de riesgos. Este plan se describe en la Sección 11.1.3.

.2 Riesgos identificados. Se evalúan los riesgos descubiertos durante el
proceso de identificación de riesgos en conjunto con sus impactos
potenciales para con el proyecto.
.3 Avance del proyecto. La incertidumbre de un riesgo suele depender del
avance del proyecto a través de su ciclo de vida. En la parte inicial del
proyecto, muchos riesgos aún no han aparecido, el diseño del proyecto es
inmaduro y puede haber cambios, lo que aumenta la probabilidad de que se
descubran más riesgos.
.4 Tipo de proyecto. Los proyectos de un tipo común o recurrente tienden a
tener una probabilidad mejor entendida de la ocurrencia de los eventos de
riesgos y sus consecuencias. Los proyectos que utilizan tecnología de
última generación o “la primera de su tipo” – o los proyectos altamente
complejos – tienden a tener más incertidumbre.
.5 Precisión de la información. La precisión describe el grado hasta donde
se conoce y se entiende el riesgo. Esta mide el grado de información
disponible, como así mismo la confiabilidad de los datos. Se debe evaluar
además la fuente de la información que se utilizó para identificar el riesgo.
.6 Escalas de probabilidad e impacto. Estas escalas, tal como se señala en
la Sección 11.3.2.2, han de utilizarse para evaluar las dos dimensiones
claves del riesgo, descritas en la Sección 11.3.2.1.
.7 Supuestos. Se evalúan como riesgos potenciales los supuestos
identificados durante el proceso de identificación de los riesgos (ver
Secciones 4.1.1.5 y 11.2.2.4).

11.3.2 Herramientas y Técnicas para el Análisis Cualitativo de los Riesgos

.1 Probabilidad e impacto del riesgo. Se pueden describir la probabilidad las

consecuencias de los riesgos en términos cualitativos como por ejemplo:
muy alto, alto, moderado, bajo y muy bajo.

La probabilidad del riesgo es la posibilidad de que ocurrirá un riesgo.

Las consecuencias del riesgo es el efecto en los objetivos del proyecto, si

 llegara a ocurrir el evento de riesgo.

Estas dos dimensiones del riesgo se aplican a eventos de riesgos

específicos, no a todo el proyecto. El análisis de los riesgos utilizando la
probabilidad y las consecuencias ayuda a identificar aquellos riesgos que
deben ser controlados o manejados de manera agresiva.

.2 Matriz de ponderación de probabilidad / impacto del riesgo. Se puede

construir una matriz que asigne una ponderación a los riesgos (muy baja,
baja, moderada, alta y muy alta) a los riesgos o condiciones, sobre la base
de combinar las escalas de probabilidad e impacto. Los riesgos con alta
probabilidad y alto impacto, están propensos a requerir un mayor análisis,
incluida la cuantificación y una gestión agresiva del riesgo. La ponderación
de los riesgos se lleva a cabo utilizando una matriz y las escalas de riesgos
para cada uno de estos eventos o condiciones.

Naturalmente, la escala de probabilidad del riesgo oscila entre 0.0 (ninguna

probabilidad) y 1.0 (certeza). La evaluación de la probabilidad del riesgo puede ser
difícil dado que se utiliza el juicio experto, a menudo sin el beneficio de la
información histórica. Se podría utilizar una escala ordinal, que represente valores
de probabilidad relativa desde muy probable a casi cierto. De modo alternativo, se
podrían asignar probabilidades específicas, utilizando una escala general (por
ejemplo: .1/ .3/ .5/ .7/ .9).

La escala de impacto del riesgo refleja la gravedad de su efecto en el objetivo del

proyecto. El impacto puede ser ordinal o cardinal, dependiendo de la cultura de la
organización que realice el análisis. Las escalas ordinales son simplemente
valores ordenados por rangos, como por ejemplo: muy bajo, bajo, moderado, alto
y muy alto. Las escalas cardinales asignan valores a estos impactos. Estos
valores son generalmente lineales (por ejemplo: .1/ .3/ .5/ 7./ .9/), pero suelen ser
no lineales (por ejemplo, .05/ .1/ .2/ .4/ .8), lo que refleja el deseo de la
organización de evitar los riesgos de alto impacto. El intento de ambos enfoques o
metodologías es el de asignar un valor relativo al impacto para con los objetivos
del proyecto si llegara a ocurrir el riesgo en cuestión. Es posible desarrollar
escalas bien definidas, sean estas ordinales o cardinales, utilizando las
definiciones acordadas por la organización. Estas definiciones mejoran la calidad
de la información y hacen que el proceso sea más repetible.

La Figura 11-2 es un ejemplo de evaluación de los impactos de los riesgos por

medio del objetivo del proyecto. Esta ilustra su utilización de, ya sea, la
metodología ordinal o cardinal. Estos descriptores escalados de impacto relativo
deben ser preparados por la organización antes de que se inicie el
proyecto.

La Figura 11-3 es una matriz de Probabilidad-Impacto (P-I). Esta ilustra la

multiplicación simple de los valores de la escala asignados a las estimaciones de
probabilidad e impacto, una forma común de combinar estas dos dimensiones,
para determinar si acaso el riesgo considerado es bajo, moderado o alto. Esta
figura presenta una escala no-lineal como un ejemplo de la aversión a los riesgos
de alto impacto, aunque se suelen utilizar escalas lineales. De modo alternativo,
se puede desarrollar la matriz P-I, usando escalas ordinales. La organización
debe determinar cuáles combinaciones de probabilidad e impacto dan como
resultado que un riesgo sea clasificado como alto riesgo (condición roja), riesgo
moderado (condición amarilla) y riesgo bajo (condición verde) para cada uno de
los enfoques. La puntuación del riesgo ayuda a clasificar el riesgo en una
categoría que ayude a las acciones de respuesta.

.3 Evaluación de los supuestos del proyecto. Los supuestos probados deben

ser evaluados con respecto a dos criterios: la estabilidad del supuesto y las
consecuencias para con el proyecto en caso que el supuesto sea falto. Se
deben identificar los supuestos alternativos; en tanto que sus consecuencias
para con los objetivos del proyecto deben ser evaluadas en el proceso de
análisis cualitativo de los riesgos.
.4 Clasificación de la precisión de la información. El análisis cualitativo de los
riesgos requiere de información exacta e insesgada si es que ha de ser útil a la
gestión del proyecto. La clasificación de la precisión de la información es una
técnica que permite evaluar el grado hasta donde es útil para la gestión la
información acerca de los riesgos. Esto implica:

. Nivel de comprensión del riesgo.

. Información disponible acerca del riesgo.
. Calidad de los datos.
. Confiabilidad e integridad de la información.
El uso de información de baja precisión – por ejemplo, si no se entiende bien un
riesgo – puede conducir a un análisis cualitativo del riesgo de poco uso para el
gerente del proyecto. Si fuera inaceptable la clasificación de la precisión de la
información, podría ser posible la recopilación de mejores datos.

11.3.3 Resultados del Análisis Cualitativo de los Riesgos

 .1 Clasificación global del riesgo para el proyecto. La clasificación del
riesgo puede indicar que la posición global de riesgo de un proyecto en
relación a otros proyectos, mediante la comparación de las puntuaciones de
riesgo. Este se puede utilizar para asignar personal u otros recursos a
proyectos con diferentes clasificaciones de riesgo, para tomar una decisión
de análisis costo-beneficio acerca del proyecto, o para respaldar una
recomendación para la iniciación, continuación o cancelación del proyecto.
.2 Lista de riesgos priorizados. Se pueden priorizar los riesgos y
condiciones por medio de una serie de criterios. Estos incluyen clasificación
(alto, moderado y bajo) o nivel de la EDT. Los riesgos pueden ser
agrupados también por aquellos que requieren una respuesta inmediata y
aquellos que pueden ser manejados más adelante. Los riesgos que afectan
el costo, programa funcionalidad y calidad se pueden evaluar
separadamente con diferentes clasificaciones. Los riesgos significativos
deben tener una descripción de la base para la probabilidad e impacto
evaluados.
.3 Lista de riesgos para análisis y gestión adicionales. Los riesgos
clasificados como altos o moderados serían los primeros candidatos a
mayores análisis, incluido el análisis cuantitativo de los riesgos y los para la
acción de gestión del riesgo.
.4 Tendencias de los resultados del análisis cualitativo de los riesgos.
En la medida que se repita el análisis, puede hacerse notar una tendencia
de los resultados, y puede hacer que la respuesta al riesgo o el análisis
adicional sea más o menos urgente e importante.

11.4 ANALISIS CUANTITATIVO DE LOS RIESGOS

El proceso del análisis cuantitativo de los riesgos está orientado a analizar

numéricamente la probabilidad de cada uno de los riesgos y sus consecuencias
para con los objetivos del proyecto, como así también el grado de riesgo al
proyecto global. Este proceso utiliza como la decisiones Monte Carlo y en análisis
de decisiones para:

. Determinar la probabilidad de lograr un objetivo específico del

proyecto.
. Cuantificar la exposición al riesgo para el proyecto, y determinar el
tamaño de las reservas de contingencia de costo y programa que puedan ser
necesarias.
. Identificar los riesgos que requieran mayor atención, cuantificando su
contribución relativa al riesgo del proyecto.
. Identificar las metas realistas y alcanzables de costo, programa o
alcance.
El análisis cuantitativo de los riesgos es que generalmente sigue al análisis
cualitativo. Este requiere de la identificación de los riesgos. Los procesos de
análisis cualitativo y cuantitativo de los riesgos pueden ser utilizados en forma
separada o en conjunto. Las consideraciones de tiempo y de disponibilidad de
presupuesto y la necesidad de afirmaciones cualitativas o cuantitativas acerca del
riesgo y los impactos, determinarán cuál de los métodos utilizar. Las tendencias en
los resultados, cuando se repite el análisis cuantitativo, pueden indicar la
necesidad de más o menos acción de control del riesgo.
11.4.1 Entradas para el Análisis Cuantitativo de los Riesgos

.1 Plan de gestión de riesgos. Este plan se describe en la Sección 11.1.3. .2

Riesgos identificados. Estos se describen en la Sección 11.2.3.1. .3 Lista de
riesgos priorizados. Esta lista se describe en la Sección
11.3.3.2. .4 Lista de riesgos para análisis
y gestión adicionales. Este listado se
describe en la Sección 11.3.3.3.
.5 Información histórica. La información sobre proyectos terminados
anteriores y similares, los estudios realizados a proyectos similares por
especialistas de riesgos y las bases de datos de riesgos que pudieran estar
disponibles a partir de fuentes propias o industriales (ver Sección 11.2.1.4.).
.6 Juicio experto. La entrada puede provenir del equipo del proyecto, otros
expertos en la materia de la organización y de otros fuera de la
organización. Las demás fuentes de información incluyen a expertos en
ingeniería o estadística (ver Sección 5.1.2.2.).
.7 Otros resultados de planificación. Los resultados más útiles son la lógica
del proyecto y las estimaciones de duración que se emplean para
determinar los programas, el listado de EDT’s de todos los elementos de
costo con sus respectivas estimaciones y los modelos de objetivos técnicos
del proyecto.

11.4.2 Herramientas y Técnicas para el Análisis Cuantitativo de los Riesgos

.1 Entrevista. Las técnicas de entrevistas se utilizan para cuantificar la

probabilidad y las consecuencias de los riesgos en los objetivos del
proyecto. Una primera etapa en la cuantificación de los riesgos puede ser
 una entrevista de riesgos con los accionistas del proyecto y los expertos en
materias particulares. La información necesaria depende del tipo de
distribuciones probabilísticas que se emplearán. Por ejemplo, se recopilaría
información sobre escenarios optimistas (bajo), pesimistas (alto) y sobre los
escenarios más probables en caso que se utilizarán distribuciones
triangulares; o bien sobre la media y la desviación estándar en el caso de
distribuciones normales o normales logarítmicas. La Figura 11-4 ilustra
ejemplos de estimaciones de tres puntos para una estimación de costos.

En el análisis cuantitativo de riesgos se suelen emplear distribuciones

probabilísticas continuas. Las distribuciones representan tanto la
probabilidad como las consecuencias del componente del proyecto. entre
los tipos de distribución comunes se incluyen: uniforme, normal, triangular,
beta y logarítmica normal. La Figura 11-5 nos muestra dos ejemplos de
estas distribuciones (en donde el eje vertical se refiere a la probabilidad y el
eje horizontal, al impacto).
Un componente importante de la entrevista de riesgos es la documentación de
lo racional de los rangos de riesgos, dado que ello puede conducirnos a
estrategias efectivas para la respuesta al riesgo durante el proceso de
planificación de la respuesta al riesgo, descrito en la Sección 11.5

.2 Análisis de sensibilidad. El análisis de sensibilidad ayuda a determinar

cuáles riesgos tienen el mayor impacto potencial en el proyecto. Este
análisis revise el grado con el cual la incertidumbre de cada elemento del
proyecto afecta el objetivo que se está revisando, una vez que se colocan
en sus valores básicos todos los demás elementos inciertos.
.3 Análisis de árbol de decisiones. El análisis de decisiones se estructura
generalmente como un árbol de decisión. El árbol de decisión es un
diagrama que describe una determinada decisión y las implicancias de
elegir una u otra de las alternativas disponibles. Este incorpora las
probabilidades de riesgos y los costos o recompensas de cada trayectoria
lógica de eventos y las decisiones futuras. La solución del árbol de decisión
indica cuál de las decisiones arroja el mayor valor esperado para el
encargado de la toma de decisiones, una vez que se hayan cuantificado
todas las implicancias, costos, recompensas inciertas y las decisiones
subsecuentes. La Figura 11-6 nos muestra un árbol de decisión.
.4 Simulación. La simulación de un proyecto utiliza un modelo que traduce las
incertidumbres especificadas a un nivel de detalle en su impacto potencial
en los objetivos que se expresan a nivel del proyecto total. Las
simulaciones de proyectos son realizadas, por lo general, utilizando la
técnica de Monte Carlo.
En el caso de un análisis de riesgos de costos, la simulación puede utilizar como
modelo a la EDT tradicional del proyecto. Para el análisis de riesgos del programa,
se utiliza el programa del Método de Diagramación de Precedencias (MDP) (ver
Sección 6.2.2.1).

La Figura 11-7 ilustra el resultado de una simulación de riesgos de costos.

11.4.3Resultados del Análisis Cuantitativo de los Riesgos

.1 Listado priorizado de riesgos cuantificados. Este listado de riesgos

incluye a aquellos que representan la mayor amenaza o que implican la
mayor oportunidad para el proyecto, junto con una medida de su impacto.
.2 Análisis probabilístico del proyecto. Las predicciones de los resultados
del programa y de los costos potenciales del proyecto, que listan las
posibles fechas de término o la duración del proyecto y los costos con sus
respectivos niveles de confianza.
.3 Probabilidad de lograrlos objetivos de costo y tiempo. Con el uso del
riesgo cuantitativo, es posible calcular la probabilidad de lograr los objetivos
del proyecto de conformidad con el actual plan y con el conocimiento que
hoy se tiene de los riesgos que enfrenta el proyecto.
.4 Tendencias de los resultados del análisis cuantitativo de los riesgos.
En la medida que se repite el análisis, puede hacerse notoria una tendencia
de los resultados.
11.5 PLANIFICACIÓN DE LA RESPUESTA FRENTE AL RIESGO

La planificación de la respuesta al riesgo es el proceso por el cual se desarrollan

las opciones y se determinan las acciones para mejorar las oportunidades y
reducir las amenazas a los objetivos del proyecto. Esto incluye la identificación y
asignación de individuos o partes para que asuman su responsabilidad por cada
respuesta al riesgo que se acuerde. Este proceso asegura que los riesgos
identificados sean adecuadamente abordados. La efectividad de la planificación de
la respuesta determinará directamente si aumenta o disminuye el riesgo para el
proyecto.

La planificación de la respuesta frente al riesgo debe ser adecuada a la gravedad

del riesgo, costo-efectiva en la consecución del desafío, puntual para ser exitoso,
realista dentro del contexto del proyecto, convenida por todas las partes
involucradas, y estar a cargo de una persona responsable. A menudo, es
necesario hacer una selección de la mejor respuesta al riesgo.

11.5.1 Entradas para la Planificación de la Respuesta al Riesgo

.1 Plan de gestión de riesgos. Este plan se describe en la

Sección 11.1.3. .2 Listado de riesgos priorizados. Esta lista del
análisis cualitativo de los riesgos se describe en la Sección
11.3.3.2. .3 Clasificación de los riesgos del proyecto. Esta se
describe en la Sección 11.3.3.1. .4 Listado priorizado de
riesgos cuantificados. Esta lista del análisis cuantitativo de los
riesgos se describe en la Sección 11.4.3.1. .5 Análisis
probabilístico del proyecto. Este se describe en la Sección
11.4.3.2. .6 Probabilidad de lograr los
objetivos de costo y tiempo. Esta se describe
en la Sección 11.4.3.3.
.7 Listado de respuestas potenciales. En el proceso de identificación de los
riesgos, se pueden identificar las acciones que respondan a riesgos
individuales o categorías de riesgos.
.8 Umbrales de riesgos. El nivel de riesgo que es aceptable para la
organización influirá en la planificación de la respuesta al riesgo.
.9 Dueños de riesgos. Una lista de accionistas de proyectos capaces de
actuar como dueños de respuestas de riesgos. Los dueños de los riesgos
deben involucrarse en el desarrollo de respuestas a los riesgos.
.10 Causas comunes de riesgos. Son varios los riesgos que pueden ser
provocados por una causa común. Esta situación puede revelar
oportunidades para mitigar dos o más riesgos del proyecto con una
respuesta genérica.
.11 Tendencias en los resultados de los análisis cualitativo y cuantitativo.
Estos se describen en las Secciones 11.3.3.4 y 11.4.3.4. Las tendencias en
los resultados pueden hacer que la respuesta al riesgo o la necesidad de un
mayor análisis sea más o menos urgente e importante.
11.5.2 Herramientas y Técnicas para la Planificación de la Respuesta al
Riesgo

Existen varias estrategias de respuesta al riesgo. Por cada riesgo, se debe

seleccionar la estrategia que tenga la mayor probabilidad de ser efectiva. Luego,
se deben desarrollar acciones específicas a fin de implementar dicha estrategia.
Se pueden seleccionar estrategias principales y de respaldo.

.1 Prevención. La prevención de riesgos está cambiando el plan del proyecto

para eliminar el riesgo o la condición o para proteger de su impacto a los
objetivos del proyecto. Aunque el equipo del proyecto no podrá eliminar
nunca todos los eventos de riesgo, es posible evitar algunos riesgos
específicos.

Algunos eventos de riesgo que aparecen tempranamente en el proyecto, se

pueden tratar mediante requerimientos de aclaración, obteniendo
información, mejorando la comunicación o adquiriendo experticia. Algunos
ejemplos de prevención podrían ser: reducir el alcance para evitar aquellas
actividades de alto riesgo; agregar recursos o tiempo; adoptar un enfoque
familiar en vez de uno innovador, o bien evitar un subcontratista que no esté
familiarizado.
.2 Transferencia. La transferencia de los riesgos busca trasladar la
consecuencia de un riesgo a una tercera parte, en conjunto con la
propiedad o responsabilidad de la respuesta. La transferencia del riesgo
simplemente le da a la otra parte la responsabilidad por su gestión; no lo
elimina.

La transferencia de la responsabilidad por el riesgo resulta más efectiva en el

manejo la exposición al riesgo financiero. La transferencia del riesgo casi
siempre implica el pago de una prima de seguro ala parte que asume el riesgo.
Esto incluye el uso de seguros, bonos de rendimiento y garantías. Para la
transferencia de una responsabilidad por riesgos específicos a otra parte, se
pueden utilizar contratos. La utilización de un contrato a precio fijo puede
transferir el riesgo al vendedor, si el diseño del proyecto es estable. Aunque el
contrato por costos reembolsables deja más riesgo en manos del usuario o
auspiciador, éste puede ayudar a reducir el costo en caso de haber cambios a
mitad del proyecto.

.3 Mitigación. La mitigación busca reducir la probabilidad y/o las

consecuencias de un evento de riesgo adverso hasta un umbral aceptable.
La adopción de una acción temprana para reducir la probabilidad de que
ocurra un riesgo o para minimizar su impacto en el proyecto, es más
efectiva que tratar de reparar las consecuencias una vez que dicho riesgo
ha ocurrido. Los costos de la acción de mitigación deben ser adecuados,
dada la probabilidad del riesgo y de sus consecuencias.
 La mitigación del riesgo puede tomar la forma de implementar un nuevo
curso de acción que permita reducir el problema – por ejemplo, adoptando
procesos menos complejos, realizando más pruebas sísmicas o de
ingeniería, o seleccionando a un vendedor o proveedor más estable. Esto
puede implicar la modificación de las condiciones, de manera tal de reducir
la probabilidad de que ocúrrale riesgo – por ejemplo, agregando más
recursos o tiempo al programa. Ello puede requerir el desarrollo de
prototipos para reducir el riesgo de ampliar a partir de un modelo de escala
de banco.

En casos en los que no sea posible reducir la probabilidad, una respuesta

de mitigación podría abordar el impacto del riesgo, fijando vínculos que
determinen la gravedad o seriedad. Por ejemplo, incorporando redundancia
en un subsistema puede reducir el impacto que resulta de la falladle
componente original.

.4 Aceptación. Esta técnica indica que el equipo del proyecto ha decidido no

modificar el plan del proyecto para manejar un riesgo, o bien que es
incapaz de identificar cualquier otra estrategia de respuesta adecuada. La
aceptación activa puede incluir el desarrollo de un plan de contingencia que
se ejecutaría en caso de que ocurriera el riesgo. De deben definir y realizar
un seguimiento de los gatilladores del riesgo, como por ejemplo la falta de
hitos intermedios. En caso de que el riesgo tuviera un alto impacto, o si la
estrategia seleccionada no fuera completamente efectiva, se desarrolla un
plan de retroceso. Esto podría implicar la asignación de un fondo por
contingencia, el desarrollo de opciones alternativas o la modificación del
alcance del proyecto.

La respuesta más usual frente a la aceptación del riesgo consiste en

establecer un recurso por contingencia, o reserva, incluidas las cantidades
de tiempo, dinero o recursos que den cuenta por aquellos riesgos
conocidos. Dicho recurso deberá estar determinado por los impactos,
calculados a un nivel aceptable de exposición al riesgo, de los riesgos que
se hayan aceptado.

11.5.3 Resultados de la Planificación de la Respuesta Frente al Riesgo

.1 Plan de respuesta al riesgo. El plan de respuesta al riesgo (algunas veces

denominado registro o catastro de riesgos) debe redactarse con el nivel de
detalle con que se realizarán las acciones. Este debe incluir una parte o
todo lo que se indica a continuación:

. Riesgos identificados, sus descripciones, el(las) área(s) del proyecto

(por ejemplo, elemento de la EDT) afectadas, sus causas y de qué manera estos
podrían llegar a afectar los objetivos.
. Propietarios de los riesgos y las responsabilidades asignadas.
. Resultados delos procesos de análisis cuantitativo y cualitativo de los
riesgos.
. Respuestas convenidas, incluida la prevención, transferencia,
mitigación o aceptación de cada riesgo en el plan de respuesta al riesgo.
. El nivel de riesgo residual que se espera exista luego de
implementada la estrategia.
. Acciones específicas para implementar la estrategia de respuesta
que se haya seleccionado.
. Presupuesto y tiempos de las respuestas.
. Planes de contingencia y planes de retroceso.

.2 Riesgos residuales. Los riesgos residuales son aquellos que permanecen aun
después de haberse adoptado las respuestas de prevención, transferencia o
mitigación. Esto incluye también riesgos menores que se hayan aceptado y
abordado; por ejemplo, la adición de fondos por contingencia al costo o tiempo
permisible.
.3 Riesgos secundarios. Son aquellos riesgos que surgen como resultado
directo de la implementación de una respuesta al riesgo. Estos deben
identificarse y planificar las respuestas frente a ellos.
.4 Acuerdos contractuales. Se pueden efectuar acuerdos o convenios
contractuales de forma tal de especificar la responsabilidad de cada una de las
partes por riesgos específicos, en caso de ocurrir estos, y por el seguro,
servicios y otros ítemes, según sea adecuado, para evitar o mitigar las
amenazas.
.5 Cantidades de reservas por contingencia necesarias. El análisis
probabilístico del proyecto(11.4.3.2) y los umbrales o niveles de riesgo
(11.1.3.1) ayudan al gerente del proyecto a determinar la cantidad derespaldo
o contingencia necesaria para reducir el riesgo de excederse en los objetivos
del proyecto a un nivel aceptable para la organización.
.6 Entradas para otros procesos. La mayoría de las respuestas frente a
riesgos implican el gasto adicional de tiempo, costo o recursos y, demandan
cambios al plan del proyecto. Las organizaciones necesitan asegurarse de
que lo que se gaste esté justificado por el nivel de reducción del riesgo. Se
deben incorporar estrategias alternativas en los procesos adecuados de
otras áreas de conocimiento.
.7 Entradas para un plan de proyecto revisado. Los resultados del proceso
de planificación de la respuesta debe estar incorporado en el plan del
proyecto, de forma tal de asegurar que se implementen y monitoreen las
acciones convenidas como parte del proyecto en ejecución.

11.6 MONITOREO Y CONTROL DE LOS RIESGOS

El monitoreo y control de los riesgos es el proceso de mantener un registro de los

riesgos identificados, monitorear los riesgos residuales e identificar los nuevos
riesgos, asegurando la ejecución de los planes de riesgo y, evaluando su eficacia
en la reducción del riesgo. El monitoreo y control de los riesgos registra las
métricas de riesgos que guardan relación con la implementación de planes de
contingencia. El monitoreo y control de riesgos es un proceso continuo que se
lleva a cabo durante toda la vida útil del proyecto. Los riesgos cambian a medida
que el proyecto madura, se desarrollan nuevos riesgos o desaparecen los riesgos
anticipados.

Los buenos procesos de monitoreo y control de riesgos dan información que

ayuda en la toma de decisiones efectivas antes de que ocurra el riesgo. Se hace
necesaria la comunicación con todos los demás accionistas del proyecto, de forma
tal de evaluar periódicamente la aceptabilidad del nivel de riesgo del proyecto.

El propósito del monitoreo de los riesgos consiste en determinar si:

. Se han implementado las respuestas a los riesgos de acuerdo a lo

planificado.
. Las acciones de respuesta a los riesgos son tan efectivas como se
esperaba, o si es necesario desarrollar nuevas respuestas.
. Los supuestos del proyecto son válidos aún.
. La exposición al riesgo ha cambiado en relación a su estado anterior,
con el análisis de las tendencias.
. Se ha producido un gatillador de riesgo.
. Se han seguido las políticas y procedimientos adecuados.
. Se han producido o han surgido riesgos que no estaban previamente
identificados.

El control del riesgo puede implicar la selección de estrategias alternativas, la

implementación de un plan de contingencia, la realización de una acción correctiva
o bien la re-planificación del proyecto. El dueño o responsable de la respuesta al
riesgo debe informar periódicamente al gerente del proyecto y al líder del equipo
de proyecto sobre la efectividad del plan, de cualquier efecto no anticipado, y de
cualquier otra corrección de a mitad de curso que sea necesaria para mitigar el
riesgo.

11.6.1 Entradas para el Monitoreo y Control de los Riesgos

 .1 Plan de gestión de riesgos. El plan de gestión de
riesgos se describe en la Sección 11.1.3. .2 Plan de
respuesta al riesgo. El plan de respuesta al riesgo se
describe en la Sección 11.5.3.1.
.3 Comunicación del proyecto. Los resultados del trabajo y otros registros
del proyecto descritos en la Sección 10.3.1, proveen información acerca del
rendimiento / desempeño del proyecto y de los riesgos del mismo. Entre
los informes utilizados comúnmente para monitorear y controlar los riesgos,
se incluyen: Libros de Obras, Listados de Ítemes de Acción, Advertencias o
Notas de Escalamiento.
.4 Identificación y Análisis Adicionales de Riesgos. A medida que se mide
e informa de, el rendimiento / desempeño de un proyecto, pueden aparecer
riesgos potenciales que no hayan aparecido anteriormente. Para estos
riesgos, se hace necesario implementar el ciclo de los seis procesos de
riesgo.
.5 Cambios del alcance. Los cambios de alcance suelen requerir de nuevos
análisis de riesgos y de nuevos planes de respuesta. Los cambios de
alcance se describen la Sección 5.5.3.1.

11.6.2 Herramientas y Técnicas para el Monitoreo y Control de los Riesgos

.1 Auditorías a las respuestas de riesgos del proyecto. Los auditores de

riesgos revisan y documentar la efectividad de la respuesta al riesgo en
prevención, transferencia o mitigación de la ocurrencia del riesgo, como así
también la efectividad del dueño o responsable del riesgo. Las auditorías
de riesgos se realizan durante todo el ciclo que dure el proyecto, de modo
tal de controlar el riesgo.
.2 Revisiones periódicas de los riesgos del proyecto. Se deben programar
regularmente revisiones de los riesgos del proyecto. El riesgo del proyecto
deben ser un tema de la agenda de todas las reuniones del equipo del
proyecto. Durante el ciclo de vida del proyecto, es posible que las
clasificaciones y la prioridad de los riesgos cambie. Todo cambio puede
demandar análisis cuantitativo y cualitativo adicionales.
.3 Análisis del valor ganado. El valor ganado se utiliza para monitorear el
rendimiento / desempeño global del proyecto a razón de un plan básico.
Los resultados de un análisis de valor ganado pueden indicar la desviación
potencial del proyecto al momento de su término, a partir de las metas de
costo y programas. Cuando un proyecto se desvía considerablemente de la
línea base, se deben llevar a cabo una identificación y análisis actualizados
de los riesgos. El análisis del valor ganado se describe en la Sección
10.3.2.4.
.4 Medición del rendimiento técnico. La medición del rendimiento técnico
compara los logros técnicos durante la ejecución del proyecto con el
programa de logros técnicos del plan del proyecto. Toda desviación, como
por ejemplo la no demostración de funcionalidad según lo planificado en un
hito, puede implicar un riesgo para el logro del alcance del proyecto.
 .5 Planificación adicional de la respuesta al riesgo. Si surgiera un riesgo
que no se haya anticipado en el plan de respuesta al riesgo, o cuyo impacto
en los objetivos sea mayor que el esperado, es posible que la respuesta
planificada no sea la adecuada. En este caso, será necesario realizar una
planificación adicional de respuesta a fin de controlar el riesgo.

11.6.3 Resultados del Monitoreo y Control de los Riesgos

.1 Planes Workaround. Los workarounds son respuestas no planificadas ante

riesgos emergentes que no fueron identificados ni aceptados previamente.
Los workaround deben ser correctamente documentados e incorporados en
el plan de proyecto y en el plan de respuesta al riesgo.
.2 Acción correctiva. La acción correctiva consiste en realizar el plan de
contingencia o workaround.
.3 Solicitudes de cambio del proyecto. La implementación de planes de
contingencia o workaround conlleva, frecuentemente, a un requerimiento de
cambiar el plan de proyecto para responder a los riesgos. El resultado es la
emisión de una solicitud de cambio que es gestionada por el control
integrado de cambios, como se describe en la Sección 4.3.
.4 Actualizaciones al plan de respuesta al riesgo. Los riesgos pueden o no
ocurrir. Los riesgos que no lo hacen, deben ser documentados y evaluados.
La implementación de controles de riesgos puede reducir el impacto o
probabilidad de los riesgos identificados. Se deben reevaluar las
clasificaciones o categorizaciones de riesgos de modo tal de que sea
posible controlar, correctamente, los nuevos riesgos importantes. Los
riesgos que no ocurran se deben documentar y cerrar en el plan de
respuesta al riesgo.
.5 Base de datos de los riesgos. Un depositario que cuenta con una
recopilación, mantención y análisis de los datos recogidos y utilizados en
los procesos de gestión de riesgos. El uso de esta base de datos ayudará
en la gestión de riesgos a través de toda la organización y, con el transcurrir
del tiempo, formará las bases de un programa de lecciones de riesgo
aprendidas.
.6 Actualizaciones de las listas de identificación de riesgos. Los listados
actualizados a base de experiencia ayudarán en la gestión de riesgos de
futuros proyectos.

La Gestión de Abastecimiento del Proyecto incluye los procesos requeridos para

adquirir bienes y servicios, con el objeto de lograr el alcance del proyecto, desde el
exterior de la organización que lo está llevando a cabo. Para mayor simplicidad,
los bienes y servicios, sean estos uno o varios, serán referidos generalmente
como un producto. La Figura 12-1 muestra una descripción de los siguientes
procesos principales:

1. 12.1 Planificación del Abastecimiento – determinación de qué se debe

adquirir y cuándo.
2. 12.2 Planificación del Requerimiento – documentación de los
requerimientos de productos e identificación de las fuentes potenciales.
3. 12.3 Requisición – obtención de cotizaciones, licitaciones, ofertas o
propuestas, según sea el caso.
4. 12.4 Selección de la Fuente – elección de entre los potenciales
vendedores.
5. 12.5 Administración del Contrato – gestión de la relación con el
vendedor.
6. 12.6 Cierre de Contrato – terminación y cancelación del contrato, que
incluye la resolución de cualquier ítem abierto.

Estos procesos interactúan unos con otros y también con los procesos de las
demás áreas de conocimiento. Cada proceso puede demandar el esfuerzo de uno
o más individuos o grupos de individuos, según sean las necesidades del
proyecto. Aun cuando los procesos son presentados aquí como elementos
discretos con interfaces bien definidas, en la práctica estos pueden traslaparse e
interactuar de formas no detalladas aquí. Las interacciones de los procesos se
analizan con detalle en el Capítulo 3.

La Gestión de Abastecimiento del Proyecto se analiza desde la perspectiva del

comprador en la relación comprador-vendedor. La relación comprador-vendedor
puede darse en muchos niveles de un proyecto. Dependiendo de cuál sea el área
de aplicación, el vendedor puede recibir el nombre de subcontratista, vendedor o
proveedor.
Comúnmente, el vendedor gestionará su trabajo como un proyecto. En tales
casos:

. El comprador pasa a ser el usuario o cliente y, por ende, es el

accionista clave para el vendedor.
. El equipo de gestión de proyecto del vendedor debe preocuparse de
todos los procesos de gestión del proyecto, no sólo de aquellos de esta área de
conocimiento.
. Los términos y condiciones del contrato pasan a ser una entrada
clave para muchos de los procesos del vendedor. El contrato puede contener, en
realidad, la entrada (por ejemplo, principales prestaciones, hitos claves, objetivos
de costos), o bien puede limitar las opciones del equipo de proyecto (por ejemplo,
en los proyectos de diseño, a menudo se requiere de la aprobación del comprador
en cuanto a las decisiones de contratación).

Este capítulo supone que el vendedor es un agente externo a la organización

ejecutante. No obstante, gran parte del análisis es igualmente aplicable a los
acuerdos formales convenidos con otras unidades de la organización ejecutante.
Cuando hay involucrados acuerdos informales, es mucho más probable que se
apliquen los procesos descritos en Gestión de Recursos Humanos del Proyecto,
Capítulo 9, y en Gestión de Comunicaciones del Proyecto, Capítulo 10.

12.1 PLANIFICACIÓN DEL ABASTECIMIENTO

La planificación del abastecimiento es el proceso de identificar qué necesidades

del proyecto pueden satisfacerse mejor mediante la adquisición de productos o
servicios fuera de la organización del proyecto, proceso que debe realizarse
durante la etapa de definición del alcance. Esto implica considerar si se debe o no
realizar el abastecimiento, cómo se va a realizar, qué se va a adquirir, cuánto se
va a comprar y cuándo se va realizar el abastecimiento.

Cuando el proyecto obtiene productos y servicios (alcance del proyecto) desde

fuera de la organización ejecutante, los procesos que van desde la planificación
del requerimiento (Sección 12.2) a la terminación del contrato (Sección 12.6) se
realizarían una vez por cada producto o servicio. El equipo de gestión del proyecto
podría desear buscar el apoyo de especialistas en aquellas disciplinas de
contratación y abastecimiento, cuando así sea necesario, e involucrarlos
tempranamente en el proceso como un miembro más del equipo de proyecto.

Cuando el proyecto no obtiene los productos y servicios desde el exterior de la

organización ejecutante, no se realizarían los procesos contemplados desde la
planificación del requerimiento (Sección12.2) a la terminación del contrato
(Sección 12.6).

La planificación del abastecimiento debe incluir, además, la consideración de los

potenciales vendedores, especialmente si el comprador desea ejercer cierto grado
de influencia o control sobre las decisiones de contratación.

12.1.1 Entradas para la Planificación del Abastecimiento

.1 Declaración del alcance. La declaración del alcance (ver Sección 5.2.3.1)

describe los actuales límites del proyecto. Proporciona información
importante acerca de las necesidades y estrategias del proyecto que deben
ser consideradas durante la planificación del abastecimiento.
.2 Descripción del producto. La descripción del producto del proyecto
(descrita en la Sección 5.1.1.1) proporciona información importante acerca
de cualquier tema o inquietud de índole técnica que sería necesario
considerar durante la planificación del abastecimiento. La descripción del
producto es, por lo general, más amplia que una declaración del trabajo. La
descripción de un producto describe el producto final del proyecto; una
declaración del trabajo (analizada en la Sección 12.1.3.2) describe la
porción de aquel producto que será proporcionada al proyecto por parte de
un vendedor. Sin embargo, si la organización ejecutante optara por
suministrar el producto completo, entonces desaparece la distinción entre
los dos términos.
.3 Recursos de abastecimiento. Si la organización ejecutante no tuene un
grupo de contratación formal, entonces el equipo de proyecto tendrá que
suministrar tanto los recursos como la experticia para apoyar las
actividades de abastecimiento del proyecto.
.4 Condiciones de mercado. El proceso de planificación del abastecimiento
debe considerar qué productos y servicios están disponibles en el mercado,
desde quién, y bajo qué términos y condiciones.
.5 Otras resultados de la planificación. Si hubiera disponibles otras
consecuencias de la planificación, éstas deberían considerarse durante la
planificación del abastecimiento. Entre las demás consecuencias de la
planificación que a menudo se deben considerar, se incluyen la
estimaciones de costo y programa preliminares, los planes de gestión de
calidad, las proyecciones de flujo de caja, la estructura de división del
trabajo, los riesgos identificados y la dotación planificada.
.6 Restricciones. Las restricciones son aquellos factores que limitan las
opciones del comprador. Una de las restricciones más comunes para
muchos proyectos es la disponibilidad de fondos.
.7 Supuestos. Los supuestos son aquellos factores que, para propósitos de
planificación, serán considerados como verdaderos, reales y ciertos.

12.1.2 Herramientas y Técnicas para la Planificación del Abastecimiento

 .1 Análisis Fabricar-o-Comprar. Esta es una técnica de gestión general y
constituye una parte del proceso inicial de definición del alcance, que se
puede utilizar para determinar si la organización ejecutante puede o no
producir un producto en particular, de forma costo-efectiva. El análisis
debiera incluir tanto los costos directos como también los indirectos. Por
ejemplo, el opción “comprar” del análisis debe incluir tanto el costo real de
sacar del bolsillo para comprar el producto, como así también los costos
indirectos de gestionar el proceso de compra.

Un análisis fabricar-o-comprar debe reflejar, además, la perspectiva de la

organización ejecutante, al igual que las necesidades inmediatas del
proyecto. Por ejemplo, la compra de un ítem de capital (cualquier cosa
desde una grúa de construcción a un computador personal) en lugar de
arrendarlo o de obtenerlo vía “leasing”, podría o no ser algo costo-efectivo.
Sin embargo, si la organización ejecutante tiene una necesidad continua
por dicho ítem, la porción del costo de compra asignado al proyecto podría
ser menor que el costo del arriendo.

.2 Juicio experto. A menudo, será necesario contar con el juicio técnico del
experto con el propósito de evaluar las entradas a este proceso. Dicha
experticia puede ser proporcionada por cualquier grupo o individuo con
conocimiento o entrenamiento especializado y, se obtiene desde muchas
fuentes que incluyen:

. Otras unidades dentro de la organización ejecutante.

. Consultores
. Asociaciones profesionales y técnicas
. Grupos industriales

.3 Selección del tipo de contrato. Diferentes tipos de contratos son más o

menos adecuados para diferentes tipos de adquisiciones. Los contratos se
clasifican generalmente en una de tres amplias categorías:
. Contratos de precio fijo o de suma alzada – esta categoría de
contrato implica un precio total fijo por un producto bien definido. En tanto que el
producto no esté bien definido, tanto el comprador como el vendedor están
sometidos a un riesgo – el comprador podría no recibir el producto deseado o bien
el vendedor podría verse en la necesidad de incurrir en costos adicionales con el
objeto de obtenerlo. Los contratos de precio fijo puede además incluir incentivos
por el cumplimiento o la sobre satisfacción de los objetivos seleccionados del
proyecto, como por ejemplo las metas de programa.
. Los contratos de costos reembolsables – esta categoría de contrato
implica el pago (reembolso) al vendedor por sus costos reales, más comúnmente
una tarifa que represente la utilidad del vendedor. Los costos se clasifican, por lo
general, como costos directos o costos indirectos. Los costos directos son los
costos incurridos por el beneficio exclusivo del proyecto (por ejemplo, salarios de
personal de proyecto de tiempo completo). Los costos indirectos, también
llamados costos generales, son los costos asignados al proyecto por parte de la
organización ejecutante como un costo de realizar el negocio (por ejemplo, los
sueldos de ejecutivos corporativos). Los costos indirectos se calculan,
generalmente, como un porcentaje de los costos directos. Los contratos de costos
reembolsables incluyen, a menudo, incentivos por el cumplimiento o la sobre
satisfacción de los objetivos seleccionados del proyecto, como son las metas por
programa o el costo total.
. Contratos por Tiempo y Material (T&M) – los contratos T&M son un
tipo de acuerdo contractual híbrido que contiene aspectos tanto de los acuerdos
de costos reembolsables como de los del tipo precio fijo. Los contratos T&M se
asemejan a los acuerdos contractuales del tipo costo en el sentido de que tienen
su término abierto, dado que el valor total del acuerdo no se define al momento del
pago. Así, los contratos T&M pueden crecer en valor de contrato como si se
tratase de acuerdos del tipo costos reembolsables. Por otro lado, los acuerdos
contractuales T&M pueden además asemejarse a los acuerdos de unidad fija
cuando, por ejemplo, el comprador y el vendedor preestablecen los precios
unitarios, como es el caso cuando ambas partes acuerdan sobre las tarifas por la
categoría de “ingenieros sénior”.

12.1.3 Resultados de la Planificación del Abastecimiento

.1 Plan de gestión del abastecimiento. El plan de gestión del abastecimiento

debe describir la forma cómo se gestionarán el resto de los procesos de
abastecimiento (desde la planificación de la requisición al cierre o término
de contrato). Por ejemplo:

. ¿Qué tipos de contratos se utilizarán?

. Si se van a necesitar estimaciones independientes como criterios de
evaluación, ¿Quién los preparará y Cuándo?
. Si la organización ejecutante cuenta con un departamento de
abastecimiento, ¿Qué acciones puede tomar por sí mismo el equipo de gestión del
proyecto?
. Si es necesario contar con documentos de compra estandarizados,
¿Dónde se pueden encontrar estos?
. ¿Cómo se gestionará a los proveedores múltiples?
. ¿Cómo se coordinará el abastecimiento con los demás aspectos del
proyecto, como son reporte de programación y rendimiento / desempeño?

Un plan de gestión de abastecimiento puede ser formal o informal,

altamente detallado o ampliamente estructurado, basado en las
necesidades del proyecto. Se trata de un elemento subsidiario del plan de
proyecto descrito en la Sección 4.1, Departamento de Planificación de
Proyectos.

.2 Declaración(es) del trabajo. La declaración del trabajo (SOW) describe el

ítem del abastecimiento con suficiente nivel de detalle como para permitir a
 los potenciales vendedores a determinar si son o no capaces de proveer el
ítem. El aspecto “suficiente detalle” podría variar, dependiendo de la
naturaleza del ítem, las necesidades del comprador, o la forma de contrato
esperada.

Algunas áreas de aplicación reconocen distintos tipos de SOW. Por

ejemplo, en algunas jurisdicciones gubernamentales, el término SOW está
reservado para un ítem de abastecimiento que es un producto o servicio
claramente especificado, mientras que el término Declaración de los
Objetivos (SOO) es utilizado por un ítem de abastecimiento que es
presentado como un problema a resolver.

La declaración del trabajo puede revisarse y refinarse en la medida que

vaya avanzando en el proceso de abastecimiento. Por ejemplo, un
vendedor potencial podría sugerir una metodología más eficiente o un
producto menos costoso que aquél especificado originalmente. Cada ítem
individual de abastecimiento requiere una declaración de trabajo aparte. No
obstante, es posible agrupar múltiples productos o servicios como un solo
ítem de abastecimiento con una sola SOW.

La declaración de trabajo debe ser tan clara, tan completa y tan concisa
como sea posible. Debe incluir una descripción de cualquier servicio
colateral que sea requerido, como puede ser el reporte de rendimiento /
desempeño o el soporte operacional post-proyecto para el ítem adquirido.
En algunas áreas de aplicación, existen requerimientos específicos de
contenido y formato para un SOW.

12.2 PLANIFICACIÓN DEL REQUERIMIENTO

La planificación del requerimiento implica la preparación de los documentos

necesarios para respaldar la requisición (el proceso de requisición se describe en
la Sección 12.3).

12.2.1 Entradas para la Planificación del Requerimiento

 .1 Plan de gestión de abastecimiento. El plan de gestión de abastecimiento
se describe en la Sección 12.1.3.1.
.2 Declaración(es) del trabajo. La declaración del trabajo se describe en la
Sección 12.1.3.2.
.3 Otros resultados de la planificación. Las demás consecuencias o
resultados de la planificación (ver Sección 12.1.1.5), que pudieran haber
sido modificadas desde el momento en que fueron consideradas como
parte de la planificación del abastecimiento, deben revisarse nuevamente
como parte de la requisición. De forma especial, la planificación del
requerimiento debe estar estrechamente ligada con el programa del
proyecto.
12.2.2 Herramientas y Técnicas para la Planificación del Requerimiento

.1 Formularios estándares. Los formularios estándares pueden incluir

contratos y descripciones de ítemes de abastecimiento estándares, o
versiones estandarizadas, de todo o de partes de los documentos de
licitación necesarios (ver Sección 12.2.3.1). Aquellas organizaciones que
realizan cantidades importantes de adquisiciones podrían contar con
muchos de estos documentos estandarizados.
.2 Juicio experto. El juicio experto se describe en la Sección 12.1.2.2.

12.2.3 Consecuencias de la Planificación del Requerimiento

.1 Documentos del requerimiento. Los documentos de requisición se utilizan

con el objeto de obtener las propuestas de parte de los vendedores
potenciales. Los términos licitación y cotización se utilizan, por lo general,
cuando la selección sobre la selección de la fuente o proveedor, estará
basada en el precio (como cuando se compran ítemes comerciales o
estándares), mientras que el término propuesta se utiliza, generalmente,
cuando se tomarán en cuenta otras consideraciones, como son las
habilidades técnicas o el enfoque técnico. Sin embargo, los términos antes
señalados se utilizan indistintamente, y se debe tener cuidado de no hacer
supuestos ingarantizados acerca de las implicancias del término empleado.
Entre los nombres comunes que reciben los distintos tipos de documentos
de adquisición se incluyen: la Invitación a Licitación (IFB), la Solicitud de
Propuesta (RFP), la Solicitud de Cotización (RFQ), la Invitación a
Negociación y la Respuesta Inicial del Contratista.

Los documentos de adquisición o abastecimiento deben ser estructurados

de forma tal de facilitar respuestas exactas y completas de parte de los
potenciales vendedores. Estos deben incluir siempre la SOW relevante, una
descripción de la forma de respuesta deseada y cualquier otra disposición
contractual que sea requerida (por ejemplo, una copia de un contrato
modelo, disposiciones de confidencialidad). En el caso de la contratación
gubernamental, una parte o todo el contenido y estructura de los
documentos de adquisición pueden verse definidos por normativas.
 Los documentos de adquisición deben ser lo suficientemente rigurosos
como para garantizar la obtención de respuestas consistentes y
comparativas, pero lo suficientemente flexible a la vez como para permitir
que se consideren las sugerencias del vendedor respecto de mejores
formas de satisfacer los requerimientos.

.2 Criterios de evaluación. Los criterios de evaluación se utilizan para

ponderar o clasificar las propuestas. Estos pueden ser objetivos (por
ejemplo: “El gerente de proyectos propuestos debe ser un Profesional en
Gestión de Proyectos certificado, PMP®”) o bien subjetivos (por ejemplo,
“El gerente de proyectos propuesto debe poseer experiencia previa
documentada con proyectos similares”). Los criterios de evaluación se
incluyen, normalmente, como parte de los documentos de abastecimiento.

Los criterios de evaluación pueden limitarse al precio de compra toda vez

que el ítem de requisición estuviera ya disponible a partir de una serie de
fuentes aceptables (el precio de compra en este contexto incluye tanto el
costo del ítem como las gastos auxiliares como son la entrega o despacho).
Si éste no fuera el caso, se deberán identificar y documentos otros criterios
de selección de modo tal de respaldar una evaluación. Por ejemplo:

. Comprensión de la necesidad – según lo demostrado por la

propuesta del vendedor.
. Costo global o costo del ciclo de vida -¿Producirá el vendedor
seleccionado el costo total más bajo (costo de compra más costo de operación)?
. Capacidad técnica -¿Tiene el vendedor, o puede el vendedor
razonablemente esperar adquirir, las habilidades y el conocimiento técnicos
necesarios?
. Enfoque de la gestión -¿Reúne el vendedor, o puede el vendedor
razonablemente esperar desarrollar, los procesos y procedimientos de gestión de
forma tal de asegurar el éxito del proyecto?
. Capacidad financiera -¿Tiene el vendedor, o puede el vendedor
razonablemente esperar obtener, los recursos financieros necesarios?

.3 Declaración de las actualizaciones del trabajo. La declaración del trabajo

se describe en la Sección 12.1.3.2. Aquellas modificaciones a una o más
declaraciones de trabajo pueden identificarse durante la planificación del
abastecimiento.

12.3 REQUISICIÓN

La Requisición implica la obtención de respuestas (ofertas y propuestas) de parte

de vendedores potenciales sobre cómo se pueden satisfacer las necesidades del
proyecto. La mayor parte del esfuerzo real de este proceso es consumido por los
vendedores potenciales, normalmente sin costo para el proyecto.
12.3.1 Entradas para la Requisición

.1 Documentos de Adquisición. Los documentos de adquisición se

describen en la Sección 12.2.3.1.
.2 Listados de vendedores calificados. Algunas organizaciones mantienen
listas o archivos con información respecto de los potenciales vendedores.
Estos listados contendrán, por lo general, información sobre experiencia
pasada relevante y otras características de los potenciales vendedores.

Si dichas listas no estuvieran disponibles, entonces el equipo del proyecto

tendrá que desarrollar sus propias fuentes. Es posible obtener información
general a través de Internet, directorios de bibliotecas, asociaciones locales
relevantes, catálogos comerciales y fuentes similares. La recopilación de
información detallada respecto de fuentes específicas puede requerir un
esfuerzo más extensivo, como son las visitas a terreno o el contacto con
clientes o usuarios anteriores.

Los documentos de adquisición pueden ser enviados a algunos o todos los

potenciales vendedores.

12.3.2 Herramientas y Técnicas para la Requisición

.1 Conferencias con los oferentes. Las conferencias con los oferentes

(también llamadas conferencias con contratistas, conferencias con
vendedores y reuniones pre-licitaciones) son reuniones que se tienen con
los potenciales vendedores antes de la preparación de una propuesta.
Estas se llevan a cabo con el objeto de asegurar que todos los potenciales
vendedores tengan un entendimiento claro y común de la requisición
(requerimientos técnicos, requerimientos contractuales, etc.). Las
respuestas a las preguntas pueden ser incorporadas a los documentos de
la requisición en la forma de anexos. Todos los potenciales vendedores
deben permanecer en igual posición durante este proceso.
.2 Publicidad. A menudo, es posible expandir los listados existentes de
potenciales vendedores, colocando avisos en publicaciones de circulación
general, como son periódicos o en publicaciones de especialidades como
son las revistas profesionales. Algunas jurisdicciones estatales exigen la
 propaganda pública de ciertos ítemes de requisición; la mayoría de las
jurisdicciones gubernamentales exigen el llamado público de los
subcontratistas para un contrato estatal.

12.3.3 Resultados de la Requisición

.1 Propuestas. Las propuestas (ver también el análisis de las ofertas,

cotizaciones y propuestas en la Sección 12.2.3.1) son documentos
preparados por el vendedores, que describen la capacidad y la
disponibilidad (voluntad) del vendedor para proveer el producto solicitado.
Estos son preparados de conformidad con los requerimientos establecidos
en los documentos de requisición que corresponda. Las propuestas
pueden complementarse con una presentación oral.

12.4 SELECCIÓN DE LA FUENTE

La selección de la fuente implica la recepción de las ofertas o propuestas y la

aplicación de los criterios de evaluación con el objeto de seleccionar a un
proveedor. Durante el proceso de decisión de la selección de la fuente, puede ser
necesario la evaluación de muchos factores, aparte del costo o precio.

. El precio puede ser el principal determinante para un ítem de

inventario, pero el precio propuesto más bajo podría no ser el costo más bajo, si el
vendedor demuestra ser incapaz de proveer el producto en forma puntual.
. Las propuestas se separan, con frecuencia, en secciones técnica
(alcance) y comercial (precio), donde cada una se evalúa en forma separada.
. Es posible que sean necesarias múltiples fuentes para aquellos
productos críticos.

Las herramientas y técnicas aquí descritas se pueden utilizar en forma singular o

en forma combinada. Por ejemplo, se podría utilizar un sistema de ponderación
para:

. Seleccionar una sola fuente a quién se le solicitará firmar un contrato

estándar.
. Clasificar por orden todas las propuestas de forma de establecer una
secuencia de negociación.

En cuanto a los principales ítemes de requisición, este proceso podría verse

repetido. Se puede seleccionar un breve listado de los vendedores calificados,
sobre la base de una propuesta preliminar y, luego, realizando una evaluación
más detallada basada en una propuesta más amplia y minuciosa.
12.4.1 Entradas para la Selección de la Fuente

.1 Propuestas. Las propuestas se describen en la Sección 12.3.3.1

.2 Criterios de evaluación. Los criterios de evaluación pueden incluir
muestras de los productos / servicios previamente producidos por los
proveedores, con el propósito de establecer una forma de evaluar sus
capacidades y la calidad de los productos. Estos criterios pueden incluir,
además, una revisión del historial del proveedor con la organización
ejecutante. Los criterios de evaluación se describen en la Sección 12.2.3.2.
.3 Políticas organizacionales. Las organizaciones comprometidas con el
abastecimiento de proyectos comúnmente cuentan con políticas formales
que afectan la evaluación de las propuestas.

12.4.2 Herramientas y Técnicas para la Selección de la Fuente

.1 Negociación del contrato. La negociación del contrato conlleva la

aclaración y el acuerdo mutuo sobre la estructura y los requerimientos del
contrato antes de la firma de éste. Hasta donde sea posible, el lenguaje del
contrato final debe reflejar todos los acuerdos alcanzados. Los temas
cubiertos incluyen, por lo general, pero sin limitación, las responsabilidades
y autoridades, los términos aplicables y la ley, los alcances en materia de
gestión técnica y comercial, el financiamiento del contrato y el precio.

Para aquellos ítemes de requisición compleja, la negociación del contrato

pueden ser, en sí, un proceso independiente con entradas (por ejemplo, un
listado de temas o ítemes abiertos) y salidas (por ejemplo, un memorando
de entendimiento) .

.2 Sistema de ponderación. Un sistema de ponderación es un método para

cuantificar la información cualitativa de forma tal de minimizar el efecto del
prejuicio personal en la selección de la fuente. La mayoría de tales sistemas
implica 1) asignar una ponderación numérica a cada uno de los criterios de
evaluación, 2) clasificar a los potenciales vendedores en cada criterio, 3)
multiplicar la ponderación por la clasificación y, 4) totalizar los productos
resultantes para calcular un puntaje global.
 .3 Sistema de selección. Un sistema de selección implica establecer los
requerimientos mínimos de rendimiento (desempeño) para uno o más de
los criterios de evaluación. Por ejemplo, podría requerirse que un vendedor
potencial propusiera un gerente de proyecto que tuviera cualidades
específicas – por ejemplo, un PMP® - antes de que se pudiera considerar el
resto de la propuesta.
.4 Estimaciones independientes. Para muchos ítemes de requisición, la
organización que adquiere podría preparar sus propias estimaciones
independientes como una verificación de la preciación propuesta. Las
diferencias significativas de estas estimaciones puede ser una indicación de
que la SOW no fue adecuada, o bien que el potencial vendedor
malentendió o no pudo responder cabalmente con la SOW. Las
estimaciones independientes se conocen a menudo como estimaciones de
costos obligados.

12.4.3 Resultados de la Sección de la Fuente

.1 Contrato. Un contrato es un acuerdo de mutuo compromiso que obliga al

vendedor a proveer el producto especificado y que obliga al comprador a
pagar por éste. Un contracto es una relación legal sujeta a la revisión de las
cortes. El acuerdo puede ser simple o complejo, generalmente (pero no
siempre), que refleje la simplicidad o la complejidad del producto. Los
contratos pueden ser llamados, entre otros nombre, como contrato,
acuerdo, subcontrato, orden de compra o bien memorando de
entendimiento. La mayoría de las organizaciones cuentan con políticas y
procedimientos documentados que definen específicamente quién debe
firmar dichos acuerdos en nombre de la organización, comúnmente
denominada una delegación de autoridad de requisición.

Aunque todos los documentos del proyecto están sujetos a alguna forma
revisión y aprobación, la naturaleza de obligación legal de un contrato
significa, comúnmente, que se someterá a un proceso de aprobación más
extensivo. En todos los casos, el principal enfoque del proceso de revisión y
aprobación debe ser el de asegurar que el lenguaje del contrato describa un
producto o servicio que satisfará la necesidad identificada. En el caso de
los principales proyectos llevados a cabo por entidades públicas, el proceso
de revisión podría, incluso, incluir la revisión pública del acuerdo.
12.5 ADMINISTRACIÓN DEL CONTRATO

La administración del contrato es el proceso de asegurar que el rendimiento /

desempeño del proveedor cumpla los requerimientos contractuales. En los
proyectos más grandes con múltiples proveedores de productos y servicios, un
aspecto clave de la administración del contrato, es la gestión de las interfases
entre los diversos proveedores. La naturaleza legal de la relación contractual hace
que sea imperativo que el equipo del proyecto esté absolutamente consciente de
las implicancias legales de las acciones tomadas al momento de administrar el
contrato.

La administración del contrato incluye la aplicación de los procesos de gestión de

proyecto que corresponda a la(s) relación(es) contractual(es) y la integración de
los resultados de estos procesos en la gestión global del proyecto. Esta
integración y coordinación se producirá, a menudo, a múltiples niveles, cuando
existan múltiples vendedores y múltiples productos involucrados. Entre los
procesos de gestión de proyectos que se deben aplicar se incluyen:

. La ejecución del plan de proyecto, descrita en la Sección 4.2, con el

fin de autorizar el trabajo del contratista en el tiempo adecuado.
. El informe de rendimiento / desempeño, descrito en la Sección 10.3,
de forma de monitorear el costo, programa y rendimiento técnico del contratista.
. El control de calidad, descrito en la Sección 8.3, para inspeccionar y
verificar la idoneidad del producto del contratista.
. El control de cambios, descrito en la Sección 4.3, con el propósito de
asegurar que los cambios sean debidamente aprobados y de que todos aquellos
que tengan necesidad de saber estén conscientes de tales cambios.

La administración del contrato tiene además un componente de gestión financiera.

Los términos de pagos deben estar definidos en el contrato y deben involucrar un
vínculo específico entre el avance realizado por el vendedor y la compensación
pagada al vendedor.

12.5.1 Entradas para la Administración del Contrato

.1 Contrato. Los contratos se describen en la Sección 12.4.3.1.

.2 Resultados del trabajo. Los resultados del trabajo del vendedor – qué
prestaciones se han terminado y cuáles no, hasta que grado se están
cumpliendo las normas de calidad, qué costos se han incurrido o
comprometido, etc. -se recopilan como parte de la ejecución del plan del
proyecto. (La Sección 4.2 entrega mayores detalles sobre la ejecución del
plan del proyecto).
.3 Solicitudes de cambio. Las solicitudes de cambio pueden incluir
modificaciones a los términos del contrato o a la descripción del producto o
 servicio que se va a proveer. Si el trabajo del vendedor es insatisfactorio,
entonces también se podría considerar, a modo de solicitud de cambio, una
decisión de terminar el contrato. Los cambios polémicos, aquellos en los
que ni el vendedor ni el equipo de gestión del proyecto pueden acordar una
compensación por el cambio, son denominados indistintamente como
reclamos, disputas o apelaciones.
.4 Facturas del vendedor. El vendedor debe presentar facturas de tiempo en
tiempo para solicitar el pago por el trabajo realizado. Los requerimientos de
facturación, incluida la documentación de respaldo necesaria, se definen
dentro del contrato.

12.5.2 Herramientas y Técnicas para la Administración del Contrato

1. 1. Sistema de control de cambios de contrato. Un sistema de control

de cambio de contrato define el proceso mediante el cual es posible modificar el
contrato. Este incluye el papeleo, los sistemas de seguimiento, los procedimientos
de resolución de disputas y los niveles de aprobación necesarios para autorizar los
cambios. El sistema de control de cambio de contrato debe integrarse con el
sistema de control de cambios integrados. (La Sección 4.3 describe el sistema de
control de cambios integrados).
2. 2. Informes de rendimiento / desempeño. El reporte o informe de
rendimiento / desempeño provee a la administración la información respecto de
cuán eficaz y efectivamente está el vendedor logrando los objetivos contractuales.
El informe de rendimiento contractual debe integrarse con el reporte de
rendimiento / desempeño integrado del proyecto, el que se describe en la Sección
10.3.
3. 3. Sistema de pagos. Los pagos al vendedor son, generalmente,
manejados por el sistema de cuentas por pagar de la organización ejecutante. En
proyectos más grandes con muchos o complejos requerimientos de
abastecimiento, el proyecto puede desarrollar su propio sistema. Cualquiera sea el
caso, el sistema de pagos debe incluir las revisiones y aprobaciones que
correspondan por parte del equipo de gestión del proyecto.

12.5.3 Resultados de la Administración del Contrato

.1 Correspondencia. Los términos y condiciones contractuales requieren,

frecuentemente, la documentación escrita de ciertos aspectos de las
comunicaciones del comprador / vendedor, como son los comunicados o
advertencias de rendimiento / desempeño insatisfactorio y los cambios de
contrato o aclaraciones.
.2 Cambios de contrato. Los cambios (aprobados y desaprobados) son
retroalimentados por medio de los respectivos procesos de planificación y
abastecimiento del proyecto, y se actualiza el plan del proyecto o cualquier
otra documentación relevante, según corresponda.
.3 Solicitudes de pago. Esto supone que el proyecto está utilizando un
sistema de pagos externo. Si el proyecto contara con su propio sistema
 interno, la consecuencia o salida aquí sería simplemente “los pagos”.

12.6 TERMINO DE CONTRATO

El término de contrato es similar al cierre administrativo (descrito en la Sección

10.4) en el sentido de que implica tanto una verificación del producto (¿Se
completó correcta y satisfactoriamente todo el trabajo?) como el cierre
administrativo (actualización de los registros a fin de reflejar los resultados finales
y archivar dicha información para futura referencia). Los términos y condiciones
contractuales pueden prescribir los procedimientos específicos para el cierre del
contrato. La terminación anticipada de un contrato es un caso especial de término
de contrato.

12.6.1 Entradas para el Término de Contrato

.1 Documentación del contrato. La documentación del contrato incluye,

aunque sin limitarse a, el contrato en sí junto con todos los programas de
respaldo, los cambios de contrato solicitados y aprobados, cualquier
documentación técnica desarrollada por el vendedor, los informes de
rendimiento / desempeño del vendedor, los documentos financieros tales
como facturas y registros de pagos y, los resultados de cualquier inspección
que diga relación con el contrato.

12.6.2 Herramientas y Técnicas para el Término de Contrato

.1 Auditorías en Abastecimiento. La auditoría a abastecimiento es una

revisión estructurada del proceso de requisición desde la planificación de la
misma a la administración del contrato. El objetivo de la auditoría es el de
identificar los éxitos y fracasos que se pueden transferir a otros ítemes del
abastecimiento en este proyecto o a otros proyectos dentro de la
organización ejecutante.

12.6.3 Resultados del Término de Contrato

.1 Archivo del contrato. Se debe preparar un conjunto completo de registros
indexados a fin de que sea adjunto a los registros finales del proyecto
(consultar Sección 10.4 para un análisis más detallado del cierre
administrativo y los archivos del proyecto).
.2 Aceptación formal y cierre. La persona u organización responsable de la
administración del contrato debe entregar al vendedor una notificación
formal escrita de que se ha terminado el contrato. Los requerimientos de
aceptación y cierre formales son comúnmente definidos en el contrato.