03 - Pm-Integración
03 - Pm-Integración
03 - Pm-Integración
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:
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.
Como PM experto en el estándar del PMI tengo respuestas para estas preguntas:
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.
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.
¿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.
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.
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.
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
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:
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.
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.
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.
• 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.
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.
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.
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.
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
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.
• 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:
¿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?”
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.
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
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:
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.
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
• Juicio de expertos
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
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:
TOMEN NOTA:
• 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?
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:
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.
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)
• 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.
• 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:
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:
Mantener información pr
ecisa y oportunarelacionada con el/los pr
oducto/s del proyecto
TOMEN NOTA:
Los datos de rendimiento recolectados el proceso anterior son analizados para poder tomar decisiones.
Información
Datos sobre el Análisis de
sobre el
rendimiento los datos
rendimiento
• 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.
• Análisis de regresión
• Agrupamiento
• Paretto
• FMEA
• Diagrama causa-efecto
• Gráficos de tendencia
• 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.
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.
Pasemos a ver ahora qué tenemos que hacer cuando, mientras estamos ejecutando el trabajo planificado, sur-
gen 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.
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.
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.
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 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?
• 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:
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:
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
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.
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.
Bibliografía consultada