03 - Pm-Integración

Capítulo 2
Integración
Mi experiencia como PM dicta que en la gestión de los proyectos, todo tiene que
ver con todo: La duración de una tarea está influenciada por los recursos que la
ejecutarán y, entre otras cosas, puede ser modificada por los riesgos relacionados
a la misma. También esa tarea tiene un costo de ejecución que, a su vez, puede ser
modificado par alguna de las dos variables anteriormente descriptas. El área de co-
nocimiento de integración es la que se encarga de coordinar todo el trabajo realizado
en las otras aéreas de conocimiento del estándar. Veamos los temas a través de los
cuales iremos entendiendo cómo funciona este proceso integrador:
1. Los procesos para la integración del proyecto
2. El desarrollo del acta de constitución del proyecto

(Project Charter)
3. El desarrollo del plan de gestión del proyecto
4. La dirección y gestión de la ejecución del proyecto
5. El monitoreo y control del trabajo del proyecto
6. La ejecución del control integrado de cambios
7. El cierre del proyecto o de una de sus fases

CAPITULO 02 // Integración
Presentación
En este capítulo se desarrolla el contenido de la primera área de conocimiento del estándar del PMI: la integra-
ción del proyecto. Aquí se describen los elementos que la componen: entradas, herramientas, técnicas y salidas.
También se presentan conceptos relevantes que son utilizados continuamente, como el “acta de constitución del
proyecto”, “el plan de gestión del proyecto”, o el “juicio de expertos”, entre otros. Además, se detalla el sistema
de solicitud y control de los cambios en el proyecto y los pasos que lo componen.
Objetivos
• Describir el proceso completo de integración, comprendiendo la función que cumple cada uno
de sus componentes.
• Asimilar los conceptos de entradas, salidas, herramientas y técnicas.
• Comprender el significado de juicio de expertos.
• Enumerar los distintos planes de gestión.
• Desarrollar el concepto de acta de constitución del proyecto.
• Entender la diferencia entre los Factores del entorno organizacional y los activos y procesos
de la organización.
• Discutir la utilización y utilidad del sistema de control de los cambios.
Las respuestas a algunas preguntas básicas sobre la

integración
Como PM experto en el estándar del PMI tengo respuestas para estas preguntas:
¿Por qué “integración” es la primera de las áreas del estándar?
Siempre me pregunté si para entender el estándar del PMI es necesario empezar por la integración, o dejarla para
el final. Esta área de conocimiento utiliza la información generada por todas las otras áreas por lo tanto, la termi-
nología empleada es desconocida para el lector que quiere interiorizarse en el estándar por primera vez. Como el
PMI presenta la integración como primera área de conocimiento la mantendremos en ese lugar de privilegio, sin
embargo le sugiero a los que recién empiezan que lean el contenido del área de la integración sin detenerse de-
masiado en los detalles y que, luego de pasar por todas las áreas de conocimiento del estándar vuelvan a leerla.
Ahí verán que podrán entender mejor que pasa allí, pues habrán incorporado todos los conceptos necesarios.
¿Cuál es la importancia de esta área de conocimiento?
Como todo tiene que ver con todo, el área de conocimiento de integración se encarga de juntar todo lo analizado
desde distintos ángulos y verificar que haya cohesión entre todo lo relevado. En otras palabras, por cada reque-
rimiento del proyecto que va a ser analizado desde el punto de vista del alcance, el costo, los plazos, los riesgos
o recursos, mediante la integración verificamos que todo lo relacionado con ese requisito tenga sentido.
25 Centro de Estudios de Project Management - SCEU UTN BA

¿Cuál es el valor de una concepción holística de las actividades y procesos que se requieren para la
administración de proyectos?
Sabemos que cualquier cosa que hagamos en un proyecto estará influenciada por varios factores. Pensar que
esos factores son compartimientos estancos es un primer error. Y un segundo es creer que esos factores se
mantienen estáticos en el tiempo. Todos los procesos del estándar apuntan a que el profesional en la dirección
de proyectos se vea obligado a evaluar un mismo factor desde distintos ángulos. Esa necesidad nos fuerza a
pensar que, ante la necesidad de hacer algo, tengo que pensar en la definición de eso que hay que hacer, es
decir, detallar la actividad, evaluar qué personas deben llevarla adelante y qué deben saber, cuánto dinero cuesta,
qué materiales son necesarios, cuánto tiempo demanda su ejecución, qué debo saber sobre esa actividad, qué
problemas me puedo encontrar en el camino, a quién hay que informarle de lo que se está haciendo.
Si no evaluamos lo que debemos hacer desde todos los ángulos, lo que haremos es realizar algo que está poco
claro, con mucha incertidumbre y con poca certeza de lograr el objetivo deseado. La concepción holística del
estándar basa su fuerza en esto: si puedo analizar la situación desde distintos ángulos y si puedo lograr que todo
ese análisis se complemente y tenga sentido, el resultado es un entendimiento claro y preciso de lo que tengo
que hacer.
A su vez, se que la comprensión y manejo de totalidad de las actividades y procesos requeridos para administrar
eficientemente proyectos, es una competencia fundamental. El estándar del PMI nos brinda un conjunto de co-
nocimientos para ser competentes en la integración de las actividades y procesos.
Comencemos viendo cuáles son esos procesos:
1. Los procesos para la integración del proyecto
Como puede verse en el gráfico, el área de conocimiento de integración está compuesta por una serie de pro-
cesos que articulan a las otras áreas de conocimiento. Incluye las actividades necesarias para identificar, definir,
combinar, unificar y coordinar los procesos y actividades de la administración de proyectos. La integración inclu-
ye actividades de consolidación y articulación, cruciales para completar el proyecto, gestionar las expectativas de
los interesados y cumplir con los requerimientos.
Los procesos de la administración de proyectos son presentados usualmente como procesos discretos con inter-
faces bien definidas, pero en la práctica, estos procesos pueden superponerse e interactuar de manera
que no están completamente detalladas en el estándar del PMI.

Proceso del área de conocimiento de Integración
Repasemos esta tabla:
¿Para qué es necesario el proceso de integración?
Les comento que esta es una pregunta que todo PM debe hacerse. La respuesta no es compleja: para organizar
la interacción de todos los procesos del estándar y asegurar que existe una relación coherente entre la documen-
tación generada en los planes y los productos entregables del proyecto.
Por ejemplo, la estimación de los costos para un plan

de contingencia involucra la integración de procesos de TOMEN NOTA:
las áreas de conocimiento de costos, plazos y riesgos.
El gerente de proyecto es el integrador
de todo el trabajo realizado en el pro-
yecto. Pero cuidado, es el equipo quien ejecuta
las tareas del proyecto.
Por experiencia les comento que la mayoría de los
gerentes de proyectos saben que no existe una for-
ma única de administrar proyectos. De acuerdo a la naturaleza del proyecto se aplican con mayor o menor
rigurosidad ciertos conocimientos en administración de proyectos, habilidades y procesos para alcanzar la
performance esperada.
Sin embargo, la percepción de que un proceso en particular no es requerido para un proyecto no necesariamente
significa que no debe ser ejecutado.
Tanto el gerente de proyecto como su equipo de trabajo deben revisar todos y cada uno de los procesos del
estándar y definir qué grado de implementación tendrá cada uno. Este análisis debe realizarse para todos
los proyectos.

Les muestro en un gráfico el detalle de entradas, herramientas y técnicas y salidas de los procesos de integración
Integración
Desarrollar el acta de Desarrollar el plan de Dirigir y gestionar el

constitución del proyecto gestión del proyecto trabajo del proyecto
Entradas Entradas Entradas

• Enunciado del Trabajo • Acta de constitución del • Plan de gestión del
• Caso de negocio proyecto proyecto
• Acuerdos • Salidas de otros procesos • Solicitudes de cambio
• Factores del entorno • Factores del entorno aprobadas
organizacional organizacional • Factores del entorno
• Activos y procesos • Activos y procesos organizacional
organizacionales organizacionales • Activos y procesos
organizacionales
Herramientas y técnicas Herramientas y técnicas
• Juicio de expertos • Juicio de expertos Herramientas y técnicas
• Técnicas facilitadoras • Técnicas facilitadoras • Juicio de expertos
• Sistema de información
Salidas Salidas de la gestión de proyectos
• Acta de constitución del • Plan de gestión del • Reuniones
proyecto proyecto
Salidas
• Productos entregables
• Datos sobre el rendimiento
• Solicitudes de cambio
Monitorear y controlar el Ejecutar el control
integrado de cambios • Actualización del plan de
trabajo del proyecto
gestión del proyecto
• Actualización de la
Entradas Entradas documentación del pr oyecto
• Plan de gestión del • Plan de gestión del
proyecto proyecto
• Información sobre el • Reportes de rendimiento
rendimiento • Solicitudes de cambio
Monitorear y controlar el
• Pronóstico sobre el • Factores del entorno
trabajo del proyecto
cronograma organizacional
• Pronóstico sobre los costos • Activos y procesos
• Cambios validados organizacionales Entradas
• Factores del entorno • Plan de gestión del
organizacional Herramientas y técnicas proyecto
• Activos y procesos • Juicio de expertos • Productos entregables
organizacionales • Reuniones de control de aceptados
cambios • Activos y procesos
Herramientas y técnicas • Herramientas para el organizacionales
• Juicio de expertos control de cambios
• Técnicas de análisis Herramientas y técnicas
• Sistema de información Salidas • Juicio de expertos
de la gestión de proyectos • Solicitudes de cambio • Técnicas de análisis
• Reuniones aprobadas • Reuniones
• Registro de cambios
Salidas • Actualización del plan de Salidas
• Solicitudes de cambio gestión del proyecto • Traspaso final del
• Reportes de rendimiento • Actualización de la producto, servicio, o
• Actualización del plan de documentación del resultado
gestión del proyecto proyecto • Actualización de los
• Actualización de la activos y procesos
documentación del organizacionales
proyecto
Fuente: PMBOK Fifth Edition

Sería bueno que lo repasaran con cuidado para adquirir conciencia de todas las actividades y procesos que están
involucrados en la integración.
REFLEXIONEMOS
Para aquellos que tienen alguna experiencia en administración de proyectos, ¿qué opinan respecto de las activida-
des y tareas? ¿Son muchas? ¿Son las que se requieren? ¿Se podría prescindir de algunas?
Comencemos por el principio, veamos uno de los pilares fundamentales del estándar:
2. El desarrollo del acta de constitución del proyecto

(Project Charter)
En este proceso se desarrolla el documento que autoriza formalmente la iniciación de un proyecto. En él se

documentan los requisitos fundamentales del producto o servicio requerido y da autoridad al PM para aplicar
recursos a las actividades del proyecto. Además, vincula al proyecto con la estrategia de la compañía y sus
operaciones. Este documento también sirve para establecer una relación entre la organización que ejecutará
el trabajo y el cliente.
De acuerdo al mandato del estándar, el Project Charter debe ser escrito por alguien de alto rango en la organiza-
ción, el sponsor, o quien en definitiva aprobará este documento. Sin embargo mi experiencia dice que difícilmente
estas personas tengan tiempo o deseos de ponerse a escribir este documento. Como gerenete de proyecto sé
que el acta debe ser escrita sí o s, por lo tanto ´tengo que tomar la iniciativa: lo que suelo hacer es avisarle al spon-
sor o quien corresponda que voy a crear
el Project charter y una vez que lo tenga
TOMEN NOTA:
hecho se lo pasaré para su aprobación.
La definición de proyecto dice que éste tiene un
inicio claro y definido. El acta de constitución del
Si bien el gerente del proyecto es identifi- proyecto (Project Charter), una vez aprobada, indica el ini-
cado en el Project Charter, éste debería ser cio formal del proyecto.
asignado lo antes posible al proyecto, pre-
Recursos = gente, tiempo, dinero, materiales, espacio físico, in-
ferentemente antes de comenzar el desa-
sumos, teléfono, electricidad…
rrollo del acta de constitución del proyecto.
La participación temprana del gerente de

proyecto en el desarrollo del Project Charter es importante para poder influir sobre los interesados y los objetivos
del proyecto.
No es lo mismo que un gerente de proyecto sea asignado a un proyecto mediante un acta de constitución luego
que ésta fue confeccionada, pues incluye, entre otras cosas, el presupuesto y las fechas de entrega del producto
o servicio a desarrollar que el PM deberá cumplir. En este caso, el PM está condicionado por objetivos de costo
y plazos impuestos por terceros. En el caso de haber participado en el desarrollo del Project Charter, esas varia-
bles podrían haber sido manejadas y negociadas de antemano para llegar a un acuerdo realista y consensuado.
La compañía evalúa mi rendimiento de acuerdo al cumplimiento de los objetivos fundamentales del proyecto: Alcan-
ce, plazos y costo. El beneficio de participar al inicio del proyecto, cuando esas variables aún están en discusión es,
justamente, asegurarme que puedo cumplir con esos objetivos e influenciarlos cuando creo que no puedo lograrlos.

REFLEXIONEMOS
¿Quién aprueba el acta de constitución del proyecto? Alguien de nivel jerárquico alto en la organización –sponsor,
PMO, comité de dirección o gerente de alto rango- que esté en condiciones de proveer fondos para el proyecto.
Ejemplo de acta de constitución del proyecto:
Buenos Aires, 1 de enero
De mi consideración:
Con el fin de comenzar los trabajos necesarios para el proyecto de análisis de facti-
bilidad de la fabricación del primer sistema aeroportuario de detección automática de
sustancias explosivas mediante el escaneo de las valijas de los pasajeros (SADASE),
se asigna este proyecto al señor José Alameda, quien actuará como gerente del
proyecto y de quien se espera que a la fecha de finalización del trabajo, entregue la
documentación técnica en la cual se expliciten los tiempos y costos necesarios de la
fabricación de dicho sistema. A la fecha, el presupuesto estimado para el estudio de
factibilidad es de $300.000 y la fecha de finalización del mismo está estipulada para
el 4 de agosto del año próximo.
Sin más, lo saluda atte.

Herman González
Director de inversiones estratégicas
REALICEMOS LA SIGUIENTE ACTIVIDAD
Busquen en la Web modelos de actas de constitución de proyectos y compárenlas con el ejemplo.

Saquen conclusiones al respecto.
Entradas del proceso de desarrollo del acta

• Enunciado del trabajo (Statement of work)
Descripción narrativa del producto o servicio a ser entregado por el proyecto. El SOW hace referencia a:
• La necesidad del negocio (por qué se necesita el producto o servicio).

• La descripción del producto (qué características deberá tener).
• El plan estratégico de la organización (cómo se alinea con los objetivos de la compañía).
Estos tres elementos deben estar alineados y ser coherentes entre sí para que el producto del proyecto contribu-
ya con la estrategia de la compañía y sea funcional a la consecución de los objetivos de la organización.
• Caso de negocio (Business Case)

Provee la información necesaria desde el punto de vista del negocio para determinar si el proyecto amerita la in-
versión. Dentro de este documento se evalúa la necesidad del negocio y se desarrolla un análisis costo-beneficio.

• Acuerdos
Son documentos utilizados para establecer las intensiones iniciales de las partes para dar, eventualmente, inicio a
un proyecto. Pueden tener el formato de cartas de intensión, memorándums, correos, etc. Los contratos son un
tipo de acuerdo formal desarrollados dentro de un marco legal. Son utilizados cuando el proyecto se realiza por
o para terceros externos a la empresa.
• Factores del entorno organizacional

Hay varios factores que pueden influenciar el desarrollo de nuestro proyecto, a saber:
Estándares industriales
En el caso de que alguna de las características del proyecto no concuerde con los estándares de la industria, el
proyecto puede no ser aprobado, o puede requerir la modificación de esa funcionalidad en particular, como condi-
ción de aprobación.
Infraestructura y cultura organizacional
Puede darse el caso de que el proyecto en cuestión sobrepase la capacidad instalada de la organización, o
sus conocimientos sobre el producto o servicio a desarrollar.
Condiciones del mercado
La aprobación para la ejecución de cualquier proyecto de cualquier naturaleza se puede ver afectada por un ciclo
económico recesivo, aunque la causa de la recesión no esté relacionado directamente con el mercado al que
está destinado el producto del proyecto: desplome de las ventas de automóviles a causa de una burbuja
inmobiliaria.
Sistema de información de la gestión de proyectos
Es un sistema de información compuesto por herramientas y técnicas utilizado para recabar, integrar y difundir
los resultados de los procesos de dirección de proyectos. Se usa para respaldar todos los aspectos del proyecto
desde el comienzo hasta el cierre, y puede incluir tanto sistemas manuales como automatizados.
Administración de personal
Políticas de contratación de recursos, evaluación de desempeño, entrenamientos.
Tolerancia a los riesgos
Cada organización tiene un umbral diferente de tolerancia a los riesgos. Mientras las empresas de tecnología
están más dispuestas a arriesgarse a probar cosas nuevas, probablemente no ocurra lo mismo en una
compañía aseguradora de bienes.
• Activos y procesos organizacionales

Durante el desarrollo del acta de constitución del proyecto se debe tener en cuenta los siguientes activos y pro-
cesos de la organización:
• Políticas organizacionales
• Procesos estándar de la organización
• Plantillas (Templates)
• Información histórica
• Lecciones aprendidas
• Requisitos de comunicación
• Controles financieros

TOMEN NOTA:
Las lecciones aprendidas son toda la documentación generada durante el

proyecto y contiene información sobre lo que falló, lo que anduvo bien o
lo que se debería modificar. Las lecciones aprendidas de proyectos completados se
convierten en información histórica útil para proyectos que comienzan.
¿De qué manera afectan mi proyecto los activos y procesos organizacionales? Re-
cordemos que estamos en el proceso de creación del acta de constitución del pro-
yecto, por lo tanto, todas las entradas del proceso apuntan a generar esta acta, es
decir, iniciar formalmente el proyecto, o a rechazar la ejecución del mismo. Es por
esto que debemos analizar todos los factores y variables que atentan contra el cum-
plimiento de los objetivos del proyecto. Tanto los factores del entorno organizacional
como sus activos y procesos nos obligan a pensar más allá de la capacidad de venta
de un producto o de su potencial facturación; nos lleva a pensar “¿podemos hacer-
lo?”, “¿tenemos todo lo necesario?”, “¿va en contra de alguna política, estándar o
ley?”, “¿contribuye a cumplir con los objetivos estratégicos de la empresa?”,”¿los
procesos de la empresa son aptos para acompañar el desarrollo del proyecto?”
REALICE LA SIGUIENTE ACTIVIDAD
Enumere los activos y procesos organizacionales de su empresa. Anótelos en una hoja y discuta
grupalmente cómo, cuándo, para qué y por qué son utilizados.
Herramientas y técnicas del proceso de desarrollo del acta

• Juicio de expertos
Es la opinión de una persona (empleado, jefe, supervisor, cliente, consultor) o grupo de personas (área de la or-
ganización, entidades, organizaciones externas, instituciones) que utilizan su experiencia y conocimientos con el
fin de proveer una respuesta apropiada a una consulta puntual.
Veamos el siguiente ejemplo
Supóngase que fue asignado como líder de un proyecto para la instalación de la

línea eléctrica de un edificio de oficinas que se inaugurará próximamente. Si bien
su organización se dedica hace más de 50 años a realizar este tipo de instalaciones
en edificios nuevos, usted trabaja allí como técnico sólo hace 8 meses. Ni bien llega
el pedido de trabajo, el cliente nos pide una estimación rápida y aproximada de la
cantidad de metros de cables que creemos que vamos a necesitar, ya que ellos se
encargarán de proveernos de los materiales necesarios. Sus conocimientos aún no
son suficientes como para darle una respuesta fehaciente a su cliente, pero sabe que
puede contar con el Ingeniero Carlos Calvo, con 25 años de experiencia en el rubro.
Carlos, sin dudar, le dijo: “dígale que vamos a necesitar 4500 metros de cable bipolar
de 5 milímetros”. Esta, y todas las respuestas que le dé el Ingeniero Carlos (o cual-
quier otra persona de la empresa con suficiente experiencia) es lo que se denomina
juicio de expertos.

En general noto que los gerentes de proyectos suelen TOMEN NOTA:

acudir al juicio de expertos y quedarse con esa estima-
ción inicial, considerando que será válida a lo largo de El juicio de expertos es útil al principio
todo el proyecto y que no se necesita mayor análisis. del proyecto, pero deberá ser convalida-
Sin embargo, el juicio de expertos debe ser conside- do a medida que avanzamos en las estimaciones
rado como el puntapié inicial de una estimación más y modificado, actualizado y documentado en caso
precisa que se logrará mediante un mayor análisis de de ser necesario.
la situación.
REFLEXIONEMOS
¿Cuántas veces recurrió a alguien con más experimentado que Ud. para que lo ayude a clarificar algún tema?
• Técnicas facilitadoras
Son utilizadas para ayudar al equipo a encontrar soluciones y respuestas ante determinadas situaciones. También
sirven para que las personas puedan ejecutar tareas del proyecto. A continuación se detallan algunas de éstas
técnicas:
Técnicas
facilitadoras
Brainstorming
Resolución de conflicto
s
Resolución de problemas
Manejo de reuniones
Salidas del proceso de desarrollo del acta

• Acta de constitución del proyecto (Project Charter)
El acta de constitución del proyecto contiene, entre otras cosas:
El propósito o La identificación del Los requerimientos El presupuesto

justificación del gerente de proyecto de alto nive l preliminar
proyecto asignado y su nivel
de autorida d
Las fechas de Los criterios de El sponsor del Límites del pr oyecto

entrega preliminares aprobación de los proyecto que
requerimiento s proveerá los fondos
Riesgos Identificación inicial

preliminares de interesados

Son incontables la cantidad de veces que se inician los proyectos sin saber bien que hay que hacer, por qué hay
que hacerlo o cuál es el objetivo. A esta situación le di el nombre de “gestión de proyectos orientada al parche”. Es
decir, no tengo mucha idea de lo que hay que hacer así que, a medida que avanzo, voy emparchando lo que hice
mal porque no lo entendía. Mi experiencia me dicta que no hay forma de que un proyecto entregue el resultado
que espera el cliente si no se sabe qué hay que hacer. Y esto se explica inicialmente en el Project Charter. Sé que
avanzar si tener claro qué hay que hacer es, indefectiblemente, caro y malo.
Cree junto a su equipo de trabajo el Acta de constitución del proyecto en el que actualmente esté
trabajando. No interesa cuán avanzado esté el proyecto.
Luego de haber precisado todo lo necesario para entender y armar el acta de constitución de proyectos, pase-
mos a analizar otro de los documentos fundamentales:
3. Desarrollo del plan de gestión del proyecto
Aquí vamos a documentar todo lo relacionado con la definición, planificación, coordinación e integración de los
planes de todas las áreas de conocimiento. El plan de gestión del proyecto define el trabajo a realizar (cómo se
hará y cómo se controlará). Su contenido varía de acuerdo a la naturaleza de los proyectos y es elaborado pro-
gresivamente a través de actualizaciones y controles.
Nada sale tal cual se planifica. Es por esto que los planes se irán modificando y
actualizando a medida que se avanza en el proyecto. El estándar del PMI posee una
serie de procesos que tienen en cuenta el manejo de los cambios dentro del marco
del Control Integrado de Cambios.
Entradas del proceso de desarrollo del plan de gestión del proyecto

• Acta de constitución del proyecto (Project Charter)
• Salidas de otros procesos
Muchas de las salidas de otros procesos de las áreas de conocimiento descriptas a lo largo de este libro se
integran para crear el plan de gestión del proyecto. Entre esas salidas podemos encontrar la estimación final de
costos, cronogramas y alcance.


Herramientas y técnicas del proceso desarrollo del plan de gestión del proyec-
to
Aquí, el juicio de expertos se utiliza para adaptar los procesos para cumplir con las necesidades del proyecto,
desarrollar detalles técnicos que se incluirán en el plan de gestión, o determinar los conocimientos necesarios del
personal a utilizar.
• Técnicas facilitadoras
Salidas del proceso desarrollo del plan de gestión del proyecto
• Plan de gestión del proyecto

Los planes de las distintas áreas de conocimiento formar parte del plan de gestión del proyecto. Estos son:
Plan de gestión
del Alcance
Plan de gestión
de los RRHH
Plan de gestión
del Tiempo
Plan de gestión
de los Contratos
Plan de gestión Plan de gestión
del Proyecto del Costo A medida que avancen en la lectura
Plan de gestión de de este libro, verán que cada área de
las Comunicaciones conocimiento genera su propio plan
Plan de gestión de gestión. El plan de gestión del pro-
de la Calidad yecto no es otra cosa que todos los
Plan de gestión planes juntos bajo un mismo nombre.
de los Riesgos El plan de gestión del proyecto puedo
Plan de gestión ser extenso y detallado o corto y resu-
de los Interesados mido, dependiendo de la naturaleza, la
duración y los requerimientos de cada
proyecto.
TOMEN NOTA:
El plan de gestión del proyecto puede contener lo
siguiente: Una vez que el plan de gestión del pro-
yecto está finalizado (es decir, su versión
• Los resultados de la adaptación de los procesos
original fue aprobada) éste se convierte en un do-
( procesos seleccionados y su nivel de implemen-
cumento que sólo se puede alterar a través de una
tación, descripción de las herramientas y técnicas
solicitud de cambio formal, aprobada por el proceso
a utilizar).
integrado de control de cambios.
• Cómo se ejecutará y controlará el trabajo.
• Cómo se cumplirán los objetivos del proyecto.
• El plan de gestión de cambios en el cual estará do-
cumentado cómo se informarán, documentarán, aprobarán o rechazarán y controlarán los cambios.
• Las métricas de rendimiento.
• Las necesidades de comunicación entre los interesados.
• Las reuniones de revisión de estado, contenido y avance del trabajo del proyecto.
• Las líneas base del proyecto
• El ciclo de vida seleccionado

Dentro del plan de gestión del proyecto se pueden encontrar las siguientes líneas base:
Líneas base Línea base Línea base del

del alcance de los costo s cronograma
TOMEN NOTA:
Línea Base (Baseline) = documento original acordado entre las partes.
• Es el documento de referencia a partir del cual se realiza el trabajo

en éste definido. Por ejemplo, la línea base del cronograma es el documento en
el cual se encuentran las referencias en cuanto a duraciones y fechas a cumplir
en el desarrollo del proyecto.
• Toda línea base solamente puede ser modificada a través de una solicitud de
cambio formal, aprobada por el proceso integrado de control de cambios. La
evolución de los cambios debe ser documentada.
• Las líneas base se utilizan para el seguimiento y control del avance del trabajo
realizado en el proyecto. También se utilizan para pronosticar la progresión de
costos y tiempos a futuro y compararlos con éstas.
Una de las cosas que llaman mi atención es cómo hacen algunos gerentes de proyectos para analizar lo bien
(o mal) que están desarrollando el producto o servicio que genera el proyecto si no desarrollan sus líneas base.
¿Cómo saber si avancé lo que tenía que avanzar si no puedo compararlo con nada? ¿Estoy bien, regular o mal
de acuerdo a qué parámetros? En esta situación, el estado del proyecto es bueno, regular o malo de acuerdo a
la percepción del gerente de proyectos o de la organización. Como profesionales en la administración de proyec-
tos, no podemos dejar en manos de la subjetividad el estado real del proyecto. Debemos poder comparar lo que
realmente pasó con algo tangible: lo que planifiqué que había que hacer.
EJEMPLO
Supongamos que nos encargan armar una bicicleta nueva con determinadas ca-
racterísticas. Nos reunimos con nuestro cliente y definimos los requerimientos, los
costos y plazos de ejecución. Acordamos que la nueva bicicleta será un rodado 28,
color rojo, con canasto al frente, 15 cambios manuales, frenos tipo patín en ambas
ruedas, asiento clásico triangular negro y manubrio cromado. Estos requerimientos,
en principio, serán mi línea base de alcance. También acordamos que el presupuesto
del proyecto es de $1000, a pagar 30% al inicio del proyecto y el 70% restante con-
tra entrega del producto terminado. Esta es, inicialmente, mi línea base de costos. Por
último, nos pusimos de acuerdo en que el armado llevará 15 días hábiles de trabajo,
empezando el lunes 1ro y terminando el 19, y se utilizarán los primeros 5 días para
la pintura del marco y la compra de las partes, los siguientes 5 días para el armado y
los últimos 5 días para ajustes. Esta es, básicamente, mi línea base de plazos.
REFLEXIONEMOS:
¿Su equipo ha desarrollado las líneas base del proyecto en el que están trabajando actualmente? ¿Contra qué
documentación compara su grado de avance?

A continuación veamos un proceso clave en la gestión de proyectos:
4. Dirigir y gestionar el trabajo del proyecto
En este proceso se ejecuta el trabajo que fue documentado en el plan de gestión del proyecto, con el fin de
cumplir con los objetivos del proyecto. El conjunto de actividades a realizar dentro de este proceso puede incluir:
• Realizar las tareas para cumplir con los requerimientos del proyecto.
• Crear los productos entregables.
• Obtener, entrenar y administrar al equipo de trabajo del proyecto.
• Adquirir y usar materiales, herramientas, equipamiento e instalaciones.
• Implementar los métodos y estándares planificados.
• Establecer y gestionar los canales de comunicación internos y externos.
• Generar datos del proyecto como avances en costos, plazos y calidad.
• Dar a conocer los cambios aprobados de alcance, plazos u otros planes.
• Gestionar riesgos.
• Gestionar proveedores.
• Recolectar y documentar lecciones aprendidas.
TOMEN NOTA:
¿Cuándo se recolectan y documentan

las lecciones aprendidas? Cada vez
que ocurre un evento que nos haga aprender
algo nuevo. En la práctica, existe la creencia de
A medida que se avanza en la ejecución del trabajo, el que las lecciones aprendidas se discuten y docu-
gerente de proyecto y su equipo de dirección son quie- mentan sólo al final del proyecto. El problema de
nes se encargan de dirigir y guiar al equipo del proyecto. esta práctica es que, sobre el cierre del proyecto,
La ejecución progresiva de las tareas hace que se pue- sólo recordaremos parcialmente aquellos hechos
da comenzar a recabar datos relevantes en cuanto al más traumáticos o los eventos más cercanos en el
ritmo de ejecución de las tareas, resultados obtenidos tiempo, perdiendo en el camino una gran cantidad
o problemas encontrados para compararlos con lo que de experiencia adquirida las etapas tempranas y
se esperaba realizar de acuerdo a lo planificado previa- medias del proyecto.
mente. Esos datos relevados serán utilizados como en-
tradas al proceso de información de rendimiento. Dado
que nada sale tal cual se planifica, dirigir y gestionar el trabajo del proyecto también requiere de la implementación
de los cambios aprobados, de acuerdo a la siguiente clasificación:

Entradas del proceso de dirección y gestión del trabajo

• Solicitudes de cambio aprobados
Los pedidos de cambio aprobados son cambios documentados y autorizados a ser ejecutados y que modificarán
el alcance. A medida que avanzamos en la ejecución del proyecto, habrá cambios que serán aprobados y otros
que no. Los cambios aprobados deberán ser programados para su implementación por el equipo del proyecto.
Cualquier cambio aprobado puede requerir la implementación de acciones preventivas o correctivas.

Herramientas y técnicas del proceso de dirección y gestión del trabajo

• Sistema de información de la ges-
tión de proyectos TOMEN NOTA:
Es el sistema de información está com- Cuando se habla del sistema de información de la

puesto por herramientas y técnicas uti- gestión de proyectos generalmente se piensa en un
lizadas para recoger, procesar y dar a software que maneja electrónicamente los archivos y la do-
conocer la marcha y los resultados del cumentación generada por el proyecto. Pero en realidad, un
proyectos. Este sistema es parte de los simple estante con carpetas y hojas impresas con la documen-
factores del entorno organizacional. tación también es considerado un sistema de información.
REFLEXIONEMOS
¿De qué forma se recolecta, se procesa y se difunde la información generada por los proyectos de su empresa?
¿Su organización tiene definido formalmente un sistema de información de la gestión de proyectos?
• Reuniones
Se utilizan para analizar, discutir y buscar soluciones consensuadas a los problemas del proyecto. Suelen tocarse
temas relacionados con los riesgos o posibles cambios en el alcance, plazos o costos. Se debe evaluar correcta-
mente quienes deberán participar. Es necesario desarrollar una agenda definiendo claramente los temas a tratar y
enviarla a los participantes con antelación. Una vez concluida la reunión, el gerente de proyectos deberá generar
un documento (minuta de reunión) donde se volcarán las decisiones tomadas.
Salidas del proceso de dirección y gestión del trabajo

• Productos entregables (Deliverables)
Son aquellos productos o resultados únicos y verificables, producidos para completar un proceso, fase o proyecto.

EJEMPLO
Si nuestro cliente nos solicitó que le construyamos edificio de oficinas, los productos
entregables (deliverables) serían, entre otros, la maqueta (producto entregable de
una fase temprana del proyecto), el edificio (el producto entregable final) y los planos
(la documentación de la construcción)
• Datos sobre el rendimiento

Es la información recabada sobre la situación de las actividades del cronograma del proyecto que se estén llevan-
do a cabo. Esta información puede incluir:
• El estado de los productos entregables.

• El estado de implementación de solicitudes de cambio, acciones correctivas, acciones preven-
tivas y reparación de defectos.
• Las estimaciones pronosticadas.
• El porcentaje del trabajo físicamente terminado.
• Las fechas de inicio y finalización reales de las actividades del cronograma.
•
Algunas páginas atrás escribí sobre la imposibilidad de evaluar el cuán bien o mal estoy avanzando en la ejecución
del proyecto si no puedo contrastar el avance real con lo que se debería haber hecho. En la misma línea, se hace
imposible medir el rendimiento del trabajo realizado, del personal o de la utilización del los materiales cuando no
sé cuál debería ser el rendimiento esperado. Sin embargo, he visto muchos proyectos con cero planificación que
emiten regularmente estados de avance muy pintorescos que incluyen evaluaciones de rendimiento del personal,
de acuerdo al… buen o mal humor de quien escribe los reportes, pues no tienen ningún asidero real.
• Solicitud de cambio
A medida que se avanza en la ejecución de las actividades del proyecto, van surgiendo inconvenientes. Si bien es-
tos hechos son inevitables, lo importante es
mantener esos desvíos bajo control. La emi-
sión de una solicitud de cambio formal y por TOMEN NOTA:
escrito ayuda a mantener el proyecto con- ¿Quiénes emiten las solicitudes de cambio? Un inte-
trolado. Las solicitudes de cambio no sola- grante del equipo de trabajo, el gerente de proyec-
mente pueden sugerir cambios a productos tos, el gerente funcional, el director, el sponsor, el cliente, la
entregables, sino que también pueden ser organización, etc. Note la diferencia entre solicitud de cambio
emitidas con el fin de modificar, entre otras (es un pedido de modificación) y solicitud de cambio aprobada
cosas, cronogramas, planes, procesos, po- (pedido de modificación analizado, documentado y aceptado).
líticas, estructuras o presupuestos.
• Actualizaciones del plan de gestión del proyecto

Todo cambio implica que se necesitará actualizar uno, El plan de gestión del alcance
alguno o todos los siguientes elementos: El plan de gestión de los requerimientos
El plan de gestión del cronograma
El plan de gestión de la calidad
Actualice lo que El plan de gestión de los costos
corresponda El plan de mejora de los procesos
El plan de gestión de recursos humanos
El plan de gestión de riesgos
El plan de gestión de comunicaciones
El plan de gestión de contrataciones
Las líneas base del proyecto

• Actualización de los documentos del proyecto

Los documentos que pueden ser modificados:
• Documento de requerimientos.
• Registro de riesgos.
• Registro de interesados.
• Registro de las solicitudes de cambio.
Mientras nos avocamos a la dirección del proyecto, no nos podemos descuidar de controlar lo que se está ha-
ciendo, por lo que ahora vamos a ahondar en ese proceso:
5. Monitoreo y control del trabajo del proyecto
En este proceso se realiza el seguimiento y la revisión del progreso del trabajo, con el fin de cumplir los objetivos
de desempeño definidos en el plan de gestión del proyecto. La supervisión consiste en la recolección, medición
y distribución de información de desempeño, y la evaluación de las mediciones y tendencias para mejorar los
procesos. Mediante la supervisión continua, el gerente del proyecto crea una percepción de la salud del proyecto
y le permite identificar las áreas en las cuales se necesita prestar mayor atención.
Mediante esta información, los interesados pueden estar al tanto del estado real del proyecto, lo que se ha hecho
y lo que queda por hacer. El control incluye la determinación de las acciones preventivas o correctivas a tomar,
o la re-planificación y posterior seguimiento sobre las acciones tomadas para evaluar si éstas solucionaron los
problemas. El proceso de supervisar y controlar el trabajo del proyecto se ocupa de:
Comparar el desempeño real versus el planeado
Evaluar el desempeño para determinar si es necesario recomendar acciones

preventivas o correctivas
Identificar nuevos riesgos y monitorear riesgos existentes
Mantener información pr
ecisa y oportunarelacionada con el/los pr
oducto/s del proyecto
Proporcionar información para reportar estatus, progreso y pronósticos
Proporcionar pronósticos para actualizar información sobre costos y cronograma
Supervisar la implementación de los cambios aprobados

TOMEN NOTA:
Una vez implementado un cambio, es necesario verificar

que éste ha surtido el efecto esperado. Es muy común
que, una vez que se detecta un problema y se define un curso de
acción, los cambios realizados no se evalúan, ya que se da por
supuesto que el cambio en sí mismo es la solución al problema.
Entradas del proceso de control del trabajo

• Información sobre el rendimiento
Los datos de rendimiento recolectados el proceso anterior son analizados para poder tomar decisiones.
Algunos ejemplos de informes sobre el rendimiento:
Información
Datos sobre el Análisis de
sobre el
rendimiento los datos
rendimiento
• Estado de los entregables

• Estado de implementación de un cambio
• Estado del proyecto
• Logros dentro del período de evaluación
• Pronósticos
• Pronósticos sobre el cronograma

Se realizan mediante la comparación de la línea base del cronograma versus el avance real. Así se puede de-
terminar si el proyecto se está llevando a cabo al paso que estaba planificado o si se necesitan realizar ajustes.
• Pronósticos sobre los costos

Se realizan mediante la comparación del presupuesto versus los gatos incurridos. Esta comparación arrojará
como resultado si se está gastando el dinero de acuerdo a lo planificado.
• Cambios validados
Los cambios aprobados y ejecutados necesitan ser controlados para verificar si su aplicación surtió el efecto esperado.
Doy fe que soy uno de los tantos que durante mucho tiempo pensó que, ante un problema dado se buscaba una
solución y esa solución per se remediaba el problema. Sin embargo con el tiempo me fui dando cuenta que era
necesario verificar que la solución pensada e implementada realmente arreglara el problema. No me alcanzaría
las hojas de este libro para enumerar las veces que implementé una solución a un problema en particular y, por

no verificar el resultado, el problema no sólo no se solucionó sino que la solución empeoró las cosas.

Herramientas y técnicas del proceso de control del trabajo

• Técnicas de análisis
Se utilizan para prever el impacto de los cambios potenciales basándose en la observación del comportamiento
de las variables del proyecto. Algunos ejemplos de técnicas de análisis pueden ser:
• Análisis de regresión
• Agrupamiento
• Paretto
• FMEA
• Diagrama causa-efecto
• Gráficos de tendencia
• Sistema de información de la gestión de proyectos

• Reuniones
Salidas del proceso de control del trabajo

• Solicitud de cambios
Al comparar la realidad con lo planificado, seguramente surgirán solicitudes de cambios que modificarán el al-
cance del proyecto o del producto. Los cambios pueden impactar sobre el plan de gestión o los documentos del
proyecto, o los productos entregables.
• Reportes de rendimiento
La información de rendimiento obtenida es volcada en documentos y comunicada a los interesados. Esta infor-
mación será utilizada como parte del proceso de toma de decisiones.
• Actualizaciones del plan de gestión del proyecto

• Actualización de documentos del proyecto
Basándose en el ejemplo anterior, discuta en grupo qué decisión tomaría, cómo la justificaría y des-
criba por qué no eligió la otra opción.
Antes de continuar con el siguiente proceso del área de conocimiento de integración,

retomemos por un momento nuestro ejemplo del armado de la bicicleta: Ya empe-

zamos a trabajar en el proyecto y nos toca, de acuerdo a lo previsto en el plan de
gestión, realizar una evaluación del desempeño de nuestro proyecto. Situados en el
sexto día del cronograma, detectamos que el secado de la pintura del cuadro de la
bicicleta tomó más tiempo que el planificado, dado que ya se debería haber secado
la pintura de acuerdo a nuestra estimación original, pero no ocurrió. Esto implica que
tengo que tomar una acción correctiva (mi plan ya no refleja la realidad, lo que está
pasando). Debo modificar el cronograma y agregar un día extra para el secado del
cuadro, lo que hará que no pueda comenzar con el armado en la fecha planificada,
sino un día después. Aquí tengo dos posibilidades para evaluar: modifico el crono-
grama, agregando un día de trabajo y le informo a mi cliente que voy a tardar más
de lo previsto o modifico el cronograma, agregando un día de trabajo y evalúo cómo
puedo reducir los tiempos de armado o de pruebas para absorber esta demora y no
impactar la fecha comprometida con el cliente.
Pasemos a ver ahora qué tenemos que hacer cuando, mientras estamos ejecutando el trabajo planificado, sur-
gen cambios:
6. Ejecutar el control integrado de cambios
En este proceso se realiza la revisión, aprobación y administración de todas las solicitudes de cambio que afecten
a los productos entregables, los procesos de la organización, la documentación o el plan de gestión del proyecto.
Toda la documentación relacionada con el proyecto se debe mantener actualizada. Este proceso de modificación
se realiza mediante una cuidadosa y continua administración de los cambios.

Durante el control integrado de cambios se realizan las siguientes actividades:
Es un hecho común que ante la urgencia para la aplicación de un

Impedir los intentos de eludir
cambio se tienda a evitar la necesidad de pasar por los controles
el proceso de ejecución del preestablecidos,introduciendo cambios que no fueron analizadosni
control integrado de cambios, documentados
de manera de que solamente Es un hecho común que ante la urgencia para la aplicación de un
los cambios aprobados sean cambio se tienda a evitar la necesidad de pasar por los controles
implementados. preestablecidos,introduciendo cambios que no fueron analizadosni
documentados, por lo que su impactoeal r es desconocido.
Revisar, analizar y aprobar las Cualquier solicitud de cambio tiene su razón de ser. El sistema de
solicitudes de cambio rápidamen - control de cambios debe ser un proceso de formalización de
te, pues es esencial tomar deci - cambios, mas no una traba burocrática. Aplicar un cambio en
siones oportunas. Una decisión forma tardía puede generar peores resultados que no haberlo
tardía puede afectar negativa- aplicado nunca.
mente los plazos, costos o la
factibilidad de aplicar el cambio.
Gestionar los cambios Para cada cambio aprobado, asignar un responsable, implemen-
aprobados. tarlo y verificar su utilidad también es parte del proceso de control
de los cambios.
Mantener la integridad de las La documentación debe ser actualizada inmediatamente luego

líneas base, actualizándolas de que un cambio es aplicado, y solamente cuando ese cambio
únicamente con cambios pasó por el proceso de aprobación adecuado.
aprobados.
Revisar, aprobar o rechazar Ninguna solicitud de cambio se debe dejar sin respuesta. Ya sea
todas las acciones correctivas o por sí o por no, la respuesta debe existir y ser documentada y
preventivas recomendadas. fundamentada.
Coordinar los cambios a Un cambio en el cronograma afectará costos, riesgos y calidad,

través de todo el pr
oyecto. entre otras cosas. Se debe evaluar cómo impacta el cambio en
todos los aspectos del proyecto (productos entregables, docu-
mentación, procesos, políticas, etc.)
Una vez evaluado el impacto del cambio, se debe describir la

Documentar el impacto de los situación por escrito.
cambios.
Los cambios pueden ser solicitados por cualquier interesado del proyecto. Aunque generalmente son iniciados
en forma verbal, siempre se deberán registrar en forma escrita y ser formalmente ingresados en el proceso de
gestión de cambios. Toda solicitud de cambio debe ser aprobada o rechazada por alguna autoridad interna del
equipo de dirección del proyecto u organización externa.
En muchos proyectos, el PM tiene la autoridad para aprobar o rechazar cierto tipo de solicitudes de cambio. En
otros casos, la aprobación o rechazo de los cambios queda en mano del Comité de control de cambios. Este
organismo está generalmente conformado por un grupo de interesados en el proyecto y que poseen cierta auto-
ridad y conocimientos específicos (finanzas, tecnología, legal, ventas). Sea quien fuere el responsable de aprobar
o rechazar los cambios solicitados en un proyecto, lo importante es que esa responsabilidad esté claramente de-

finida en el documento de roles y responsabilidades del proyecto en cuestión. También debe estar correctamente
definido el tipo de solicitudes de cambios para las cuales se tiene autoridad suficiente para tomar decisiones.
Muchos años de experiencia en la administración de proyectos me indican que la gestión de los cambios no de-
bería ser tomada como algo trivial. Para complacer a nuestros cliente, y con la falsa idea de agilizar el desarrollo
del proyecto y evitar trámites burocráticos, dejamos que cualquier persona le pida cambios a cualquier miembro
del equipo de trabajo, sin tener un control cierto de las implicancias de esas modificaciones. Como gerente de
proyectos tengo la responsabilidad de
gestionar TODOS los cambios solicita-
TOMEN NOTA:
dos, aunque inicialmente sean percibi-
dos como menores a de bajo riesgo. El objetivo del sistema de gestión de la configuración
En general solemos minimizar los cam- es mantener actualizados todos los documentos que se
bios solicitados porque los analizamos generan durante el ciclo de vida del proyecto. Este sistema está
a la ligera y no pensamos en profun- conformado por una serie de procedimientos que ayudan a:
didad qué se estará impactando. Ge-
neralmente los problemas que surjan • Identificar y documentar las características funcionales y
de esa modificación implementada sin físicas de un producto, resultado, servicio o componente
mayor análisis estarán relacionados • Controlar cualquier cambio a dichas características
con más trabajo no planificado (y su • Registrar e informar cada cambio y su estado de imple-
costo asociado). mentación
• Verificar que los productos o resultados cumplen con los
requisitos.
El sistema de control de cambios es un subsistema del de ges-

tión de la configuración. Está conformado por un conjunto de
procedimientos formalmente documentados que definen cómo se
controlarán, cambiarán y aprobarán los productos entregables, y
cualquier otra documentación del proyecto.
Entradas del proceso de

control de cambios
• Reportes de rendimiento
• Solicitud de cambios
Herramientas y técnicas del proceso de control de cambios

• Reuniones de control de cambios
El comité de control de cambios es responsable de reunirse y revisar las solicitudes de cambios y de aprobarlas
o rechazarlas. Los roles y responsabilidades deben estar claramente definidas y acordadas con los interesados
del proyecto. Las decisiones tomadas por el comité deben documentarse y comunicarse oportunamente a todos
los interesados.
REFLEXIONEMOS

¿Su organización cuenta con un comité de control de cambios? ¿Quiénes lo conforman? ¿Cuáles son sus fun-
ciones? ¿Con qué frecuencia se reúnen?
• Herramientas para el control de cambios

Facilitan el levantamiento, seguimiento, comunicación y registro de los cambios. Son particularmente útiles para
facilitar su gestión y control. Pueden ser herramientas manuales o automatizadas.
Salidas del proceso de control de cambios

• Solicitudes de cambio aprobadas
• Registro de cambios
Es el documento en el cual se asientan todos los cambios que se van sucediendo en el proyecto. En éste constan
las decisiones tomadas para cada uno de los cambios.
• Actualización del plan de gestión del proyecto

Los cambios de las líneas bases del proyecto solamente deberán mostrar los cambios desde el momento de su
aprobación en adelante. Ningún documento del proyecto se corrige en forma retroactiva por los cambios ocurri-
dos. De esta manera, se protege la integridad de las líneas base del proyecto y sus documentos, como también
la información histórica de desempeño.
• Actualización de documentos
Es necesario realizar actualizaciones en toda la documentación impactada por el cambio.
Hasta el momento hemos visto cómo planificar el trabajo a realizar, cómo documentarlo, gestionarlo y controlarlo.
Ahora veamos qué hacer una vez que terminamos nuestro trabajo:
7. Cerrar el proyecto o fase
En el proceso de cierre del proyecto o fase se trabaja en finalizar todas las tareas que queden pendientes de cie-
rre. Mediante este proceso se formalizala conclusión del proyecto o fase. El Gerente de proyecto deberá revisar
toda la información asociada con los cierres de fases anteriores y asegurar que todo el trabajo se ha completado
satisfactoriamente y que el proyecto ha cumplido sus objetivos. También se deberán analizar las causas en el
caso que el proyecto o fase se hayan cancelado antes de su finalización planeada.
Uno de los momentos más esperados por el gerente de proyectos y su equipo de trabajo es llegar al final del pro-
yecto y entregar el resultado esperado al cliente. Y una vez que esto sucede, la sensación de “misión cumplida”
inunda nuestro ser y nos hace olvidar que… aún no terminamos el trabajo! ¿Cómo es eso? Un profesional en la
gestión de proyectos debe saber que entregar el producto del proyecto es una de las dos partes relacionadas

con terminar el trabajo. La otra es completar la documentación, asegurarse de que está actualizada, guardarla
en un lugar apropiado y reunir al equipo para hacer una evaluación final de lo que salió bien y lo que salió mal en
el proyecto. No olvidemos que apenas termina un proyecto empieza otro nuevo, y que no hay nada peor que
no haber aprendido de los errores cometidos (¡y de las cosas que se hicieron bien!) en los proyectos terminados
En este proceso se incluye todas las actividades necesarias para lograr el cierre administrativo del proyecto:
Acciones necesarias Acciones necesarias

para satisfacer los para transferir el
criterios de cierre producto, servicio o
documentados resultado a la próxima
fase o al cliente Producto / Servicio
Cierre Administrativo del proyecto o fase
Documentación
Acciones necesarias para recolectar los
registros, lecciones aprendidas del proyecto,
auditar éxitos o fracasos y archivar la inform
a-
ción para su uso futuro
Entradas del proceso de cierre

• Productos entregables aceptados
Aceptación de aquellos productos entregables.
Herramientas y técnicas del proceso

• Técnicas de análisis
• Reuniones
Salidas del proceso de cierre

• Traspaso final del producto, servicio o resultado
Esta salida hace referencia a la entrega del producto, servicio o resultado del proyecto al cliente, otro grupo de
trabajo o hacia la siguiente fase.
• Actualización de los activos y procesos organizacionales

• Archivos de proyecto: son todos los documentos generados durante el ciclo de vida del pro-
yecto (por ejemplo: documentos de alcance, plazos, costos, registro de riesgos, documenta-
ción de cambios).
• Documentos de cierre del proyecto o de la fase: documentación formal que indica la finaliza-
ción del proyecto o fase y la transferencia del producto entregable del proyecto o fase a otros,
como el área de operaciones o la fase siguiente. Esta documentación es revisada por el PM

para asegurarse que todo el trabajo del proyecto ha sido completado y que el proyecto ha
cumplido sus objetivos.
• Información histórica: la documentación generada por el proyecto se archiva en los reposito-
rios de información para usarlas en futuros proyectos.
Aquí podemos ver que la información histórica no es otra cosa que la documentación archivada de proyectos an-
teriores. ¿Qué documentos conforman la información histórica? Documentos sobre tareas, reportes, estimaciones,
planes, lecciones aprendidas, riesgos, recursos, cronogramas, costos, etc. La mayoría de las empresas no cuentan
con información histórica de proyectos anteriores por el simple hecho de que no existe la cultura o el procedimiento
de archivado de la documentación generada en los proyectos o, probablemente, ni siquiera exista la cultura o el
proceso formal para generar, en primera instancia, esos documentos durante el proyecto. Por esto, cada nuevo
proyecto se debe planificar y estimar de cero, con la consecuente pérdida de tiempo y la propensión a repetir erro-
res del pasado. Es importante revisar, al finalizar el proyecto, cómo se fueron sucediendo los cambios: qué cambió,
por qué, cuántas veces, cómo impactaron los cambios en el proyecto, con el fin de analizar tendencias, sucesos
recurrentes, y otros hechos que sirvan como aprendizaje para futuros proyectos.
VEAN ESTE EJEMPLO
En nuestro ejemplo del armado de la bicicleta, una vez que cerramos el proyecto
(entregamos la bicicleta terminada, fue aceptada por nuestro cliente y cobramos por
nuestro trabajo), deberíamos revisar aquel inconveniente que tuvimos cuando inicial-
mente estimamos el tiempo de secado de la pintura. El análisis debería buscar las
respuestas a preguntas del tipo: ¿Cómo llegué a la estimación original? ¿Por qué no
se cumplió? La respuesta que obtengamos deberá ser escrita y utilizada en nuestra
próxima bicicleta.

A modo de cierre
Si bien la Integración del proyecto es la primera área de conocimiento descripta en detalle en la
secuencia de capítulos que presenta el PMI en su estándar, se sugiere una lectura inicial rápida,
sin detenerse demasiado en detalles, ya que, para comprender completamente el significado y
los procesos e interrelaciones que esta área de conocimiento encierra, es necesario conocer con
cierta profundidad las otras ocho áreas de conocimiento que se desarrollarán y explicarán en los
módulos subsiguientes.
En el siguiente capítulo se verá el área de conocimiento de Alcance. Allí se comenzarán a disipar

ciertas dudas que seguramente ha dejado la lectura inicial de este capítulo. Finalmente, recomen-
damos releer este capítulo de Integración una vez leídas y estudiadas las otras áreas de conoci-
miento de la administración de proyectos.
Bibliografía consultada
• A guide to the Project Management Book of Knowledge (PMBOK Guide) Fifth

edition – PMI 2012
• PMP exam preparation – Rita Mulkahy - Fifth edition 2012

03 - Pm-Integración

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

03 - Pm-Integración

Cargado por

Copyright:

Formatos disponibles

Capítulo 2

1. Los procesos para la integración del proyecto

2. El desarrollo del acta de constitución del proyecto

3. El desarrollo del plan de gestión del proyecto

4. La dirección y gestión de la ejecución del proyecto

5. El monitoreo y control del trabajo del proyecto

6. La ejecución del control integrado de cambios

7. El cierre del proyecto o de una de sus fases

Las respuestas a algunas preguntas básicas sobre la

¿Por qué “integración” es la primera de las áreas del estándar?

¿Cuál es la importancia de esta área de conocimiento?

25 Centro de Estudios de Project Management - SCEU UTN BA

Comencemos viendo cuáles son esos procesos:

1. Los procesos para la integración del proyecto

26 Centro de Estudios de Project Management - SCEU UTN BA

Proceso del área de conocimiento de Integración

Repasemos esta tabla:

¿Para qué es necesario el proceso de integración?

Por ejemplo, la estimación de los costos para un plan

27 Centro de Estudios de Project Management - SCEU UTN BA

Desarrollar el acta de Desarrollar el plan de Dirigir y gestionar el

Entradas Entradas Entradas

28 Centro de Estudios de Project Management - SCEU UTN BA

2. El desarrollo del acta de constitución del proyecto

En este proceso se desarrolla el documento que autoriza formalmente la iniciación de un proyecto. En él se

La participación temprana del gerente de

29 Centro de Estudios de Project Management - SCEU UTN BA

Ejemplo de acta de constitución del proyecto:

Buenos Aires, 1 de enero

Sin más, lo saluda atte.

REALICEMOS LA SIGUIENTE ACTIVIDAD

Busquen en la Web modelos de actas de constitución de proyectos y compárenlas con el ejemplo.

Entradas del proceso de desarrollo del acta

• La necesidad del negocio (por qué se necesita el producto o servicio).

• Caso de negocio (Business Case)

30 Centro de Estudios de Project Management - SCEU UTN BA

• Factores del entorno organizacional

Infraestructura y cultura organizacional

Condiciones del mercado

Sistema de información de la gestión de proyectos

Políticas de contratación de recursos, evaluación de desempeño, entrenamientos.

Tolerancia a los riesgos

• Activos y procesos organizacionales

31 Centro de Estudios de Project Management - SCEU UTN BA

Las lecciones aprendidas son toda la documentación generada durante el

REALICE LA SIGUIENTE ACTIVIDAD

Herramientas y técnicas del proceso de desarrollo del acta

Veamos el siguiente ejemplo

Supóngase que fue asignado como líder de un proyecto para la instalación de la

32 Centro de Estudios de Project Management - SCEU UTN BA

En general noto que los gerentes de proyectos suelen TOMEN NOTA:

Salidas del proceso de desarrollo del acta

El propósito o La identificación del Los requerimientos El presupuesto

Las fechas de Los criterios de El sponsor del Límites del pr oyecto

Riesgos Identificación inicial

33 Centro de Estudios de Project Management - SCEU UTN BA

REALICEMOS LA SIGUIENTE ACTIVIDAD

3. Desarrollo del plan de gestión del proyecto

Entradas del proceso de desarrollo del plan de gestión del proyecto

• Factores del entorno organizacional

34 Centro de Estudios de Project Management - SCEU UTN BA

Salidas del proceso desarrollo del plan de gestión del proyecto

• Plan de gestión del proyecto