Gestión de proyectos

Lecturas adicionales

Autor: José D. Esterkin, PMP

1
¿Cómo estructurar un proyecto correctamente?

La situación se da siempre del mismo modo: tu jefe te llama a su oficina y te cuenta que en la
última reunión de Directorio se tomaron medidas estratégicas que nos llevan a implementar el
Proyecto X. El Proyecto X es ese que comentamos hace dos semanas, y debe estar finalizado
antes del 1 de marzo del próximo año. Supuestamente hoy ya lo comenzamos a implementar.
Ya vacunado contra este tipo de situación, volvés a tu oficina con una fuerte ansiedad por
comenzar a planificar y ejecutar el Proyecto X lo más rápido posible. Antes de pensar en las
tareas del proyecto y comenzar a delegarlas... esperá. Seguí caminando hacia tu oficina, pero
cuando te sientes frente a tu PC, en vez de abrir la pantalla del paquete de software de
administración de proyectos que tanto dominás, y clickear en Nuevo Proyecto, reflexioná en lo
siguiente:

* ¿Qué es lo mejor que puedo hacer para estructurar el Proyecto X después de una reunión
como esta?
* ¿Cómo se estructura correctamente el Proyecto X?

Para estructurar correctamente cualquier proyecto y crear cimientos fuertes para lo que
vendrá, deberías pensar en los siguientes cinco puntos, y deberías encontrar el tiempo
necesario para analizarlos cuidadosamente y ejecutarlos:

1. Desarrollá una relación personal con los patrocinadores del proyecto: los patrocinadores
(sponsors) son aquellas personas que apostaron por el proyecto y que te ayudarán a conseguir
los recursos financieros y humanos para implementarlo. Un buen patrocinador deberá ser tu
socio en las decisiones acerca de cómo usar los fondos destinados para el proyecto, ser tu
socio en el manejo y negociación de los cambios al alcance, y deberá tener la visibilidad
necesaria en la organización para hacerse oír y transformar el proyecto en algo significativo. Si
tus patrocinadores tienen esas características, son buenos patrocinadores del proyecto.

2. Desarrollá y publicá el Acta del Proyecto: el primer paso para ganar visibilidad es desarrollar
conjuntamente con los patrocinadores el Acta del Proyecto (Project Charter). El Acta del
Proyecto es el documento que describe qué es y qué no es tu proyecto, es el contrato interno
dentro de la organización que legitima la existencia del proyecto, explica su nacimiento y sobre
todo, legitima el poder que te fue otorgado como Gerente del Proyecto. El Acta del Proyecto
debe contener como mínimo los siguientes capítulos:
* Sumario Ejecutivo.
* Entorno de negocios y objetivos de negocios que generaron el proyecto.
* Objetivos del Proyecto.
* Una descripción general del alcance del proyecto en términos de entregables.

2
* Una lista de los entregables del proyecto y su descripción.
* Quiénes son los participantes del proyecto: patrocinadores, gerente del proyecto, equipo del
proyecto, otros recursos que participan, etc.
* Cuáles son los factores de riesgo del proyecto y cómo se manejará cada uno.

Este documento es un documento que prepara el líder de proyecto pero que preferiblemente
debería está firmado por el patrocinador u otro ejecutivo de la alta gerencia de la compañía.
Su principal utilidad es que explica claramente y en palabras simples en qué consiste el
proyecto a implementarse. ¿A quién se le entrega el Acta del Proyecto? A ejecutivos de otras
áreas de la organización, a los miembros del equipo a medida que se van incorporando, a
proveedores, a recursos de otras áreas, etc.

3. Realizá un Análisis de Interesados: los interesados del proyecto (stakeholders) son todos
aquellos que tienen algún interés en el proyecto o que se verán afectados positiva o
negativamente por su resultado. Lo importante es identificarlos antes de empezar pero...
¿Cómo hacerlo? Me debo preguntar: "Este proyecto, ¿sobre quién influirá en la organización o
fuera de ella? ¿A quién le interesa el resultado de este proyecto? ¿Quién se verá afectado
aunque no esté involucrado?"
Una vez que los tenés identificados, deberías averiguar acerca de cada uno lo siguiente
(preferiblemente por medio de una entrevista):
* ¿Cuál es el alcance del proyecto según él/ella?
* ¿Cómo define la calidad de los entregables?
* ¿Cuáles son los riesgos del proyecto según él/ella?
* ¿Cuáles son los factores críticos de éxito del proyecto?
* ¿Cómo quiere ser reportado acerca del avance del proyecto? ¿Con qué frecuencia y por qué
medios?

4. Desarrollá el alcance del proyecto: tu objetivo con el alcance del proyecto en la fase de
estructuración es definirlo claramente para todos en forma objetiva. La alineación de
expectativas entre todos los interesados te dice qué está y qué no está en el proyecto. Eso es
lo que tenés que definir, documentar y publicar en esta etapa. El alcance de tu proyecto está
dado por los entregables que se deben producir: si tu proyecto fuese una fábrica, los
entregables son lo que produce esa fábrica. Estos entregables pueden ser tangibles o
intangibles.

5. Desarrollá el Plan del Proyecto: es el documento usado para definir el Qué, Quién, Cómo,
Cuándo y Dónde de tu proyecto. No confundir con el Cronograma del Proyecto. El Cronograma
del Proyecto es una parte del Plan del Proyecto.

3
Un buen Plan del Proyecto debe contener por lo menos los siguientes capítulos:
* Enfoque del Proyecto.
* Plan de Administración de Alcance.
* Plan de Comunicación.
* Plan de Administración de Riesgos.
* Plan de Administración de Calidad.
* Plan de Administración de los Recursos Humanos del Proyecto.
* EDT (Estructura de Descomposición del Trabajo) o WBS (Work Breakdown Structure).
* Cronograma del Proyecto.

4
¿Sabés trabajar en equipo?

Esta pregunta siempre surge en cualquier entrevista laboral, y la respuesta siempre es rápida,
como si fuera obvio: "Sí, por supuesto". Reunir a un grupo de personas en el mismo lugar a
trabajar no significa que lo hagan en equipo; crear y desarrollar un verdadero equipo de
trabajo en un proyecto es mucho más complejo de lo que parece, y va más allá del solo hecho
de reunir personas con un objetivo específico. En la actualidad el concepto de "trabajo en
equipo" es muy borroso. Pareciera que si todos en el equipo se conocen, se llevan
relativamente bien, comparten las metas, se comprometen, aceptan los trabajos asignados y
los cumplen, y además toman cerveza juntos en los happy hours, eso significa que son un
equipo de trabajo. La cooperación y el entendimiento de que "ese es su problema" debe
cambiarse por "ese es nuestro problema", son la base de un equipo de buen desempeño.
Según el Diccionario de la RAE, un equipo comprende a cualquier grupo de tres o más
personas unidas con un objetivo común (una investigación o un servicio determinado). Y ojo
con el número tres. Un grupo en sí mismo no necesariamente constituye un equipo.

La sinergia es también un concepto clave en el trabajo de equipo: las acciones simultáneas de

diferentes personas tienen en su conjunto un efecto mayor a la suma de sus efectos
individuales. La contribución más importante que un líder puede hacer en un equipo es
producir sinergia en su grupo de trabajo.

5
Las cuatro dimensiones básicas de un equipo de trabajo

¿Eres parte de un grupo de trabajo? Entonces debes contestarte estas preguntas:

¿Quiénes somos?
¿Qué hacemos?
¿Cómo y dónde trabajamos?
¿Quién nos dirige?

Esas son las cuatro dimensiones de cualquier equipo de trabajo, que son las respuestas a las
preguntas de arriba:

[Link] miembros
El equipo está formado por miembros con perfiles profesionales que se complementan. El tipo
de relaciones que se desarrollen entre los miembros y la calidad del trabajo dependerán de sus
aptitudes técnicas, de sus habilidades interpersonales y de la personalidad de cada uno.

[Link] proyecto
La existencia de un proyecto común marcará el objetivo del equipo. Es necesario que se trate
de un proyecto motivador con el que cada miembro del equipo se identifique. La persona que
coordine el equipo tendrá un papel relevante en este aspecto.

[Link] clima de trabajo

Un clima emocional óptimo, basado en la cooperación, la comunicación y la confianza son
ingredientes esenciales para la vida del equipo. También es muy importante un ambiente físico
agradable. Debe cuidarse el espacio de trabajo: amplitud, iluminación, nivel de ruido, limpieza,
contaminación, temperatura, decoración.

[Link] liderazgo
El equipo necesita de un o una líder que coordine las distintas funciones y tareas que se
establecen para conseguir los objetivos pactados. El papel del líder o la líder es decisivo para el
buen funcionamiento del equipo y para lograr su cohesión.

6
Es un tema de ansiedad

Hay mucha ansiedad alrededor de un proyecto. El o la gerente de proyecto se pregunta si

podrá cumplir con la triple limitación. Los patrocinadores se preguntan si el o la gerente de
proyecto es la persona correcta para dirigirlo, y si el proyecto es el proyecto correcto dentro de
todas las elecciones posibles. Los miembros del equipo se preguntan si progresarán en su
carrera y si tienen las habilidades necesarias para llegar a buen puerto. El proyecto dura 10
meses, pasaron 6 y todavía no se produjo ningún entregable externo que tenga que aprobar el
cliente. ¿Qué paso en este período? El equipo del proyecto trabajó dentro de su oficina, como
en un laboratorio, preparando documentos y trabajando en paralelo en varios entregables,
pero todavía ninguno de ellos ha sido finalizado. Peligro. La ansiedad aumenta, todos quieren
ver lo que va a salir de la fábrica, pero todavía no se puede mostrar nada. El gerente de
proyecto se siente observado.

Consejo: cuando planifiques el proyecto y diseñes el cronograma, piensa en algún entregable

rápido y fácil de elaborar que puedas mostrar tempranamente en el proyecto. Muestra
resultados rápidos, aunque sean resultados simples. Eso va a inspirar confianza a todos los
que están afuera y también a tu propio equipo. ¿Tu proyecto tiene un solo entregable, es muy
grande y se puede mostrar sólo al final? ¿Quizás se pueda hacer un prototipo? ¿Quizás se
pueda hacer una demo cuando vayan al 40% de avance, al 60%, al 80%? ¿Quizás se pueda
realizar el equivalente a una maqueta de una obra, similar a la que preparan los arquitectos?
Hay un proverbio chino que dice “Cree más en tus ojos que en tus oídos”: lo que ves es más
real que lo que te cuentan. Planifica logros rápidos, muestra tu trabajo, los interesados deben
ver, no escuchar. Cuando hablamos de gestionar expectativas tenemos que tener en cuenta
dos partes: la definición de la expectativa (la semilla que plantamos) y el modo en que luego
la vamos a satisfacer (regar la planta). Si no trabajamos sobre ambos ejes, los conflictos
aparecerán (la planta se secará). La clave entonces es detectar la necesidad real, el
requerimiento. No se trata tanto de convencer al cliente, sino de trabajar con él o ella para que
quede evidenciado cuál es el problema a solucionar y cuál es el mejor modo de lograrlo.
Ahondar en el requerimiento con actitud honesta ayudará a guiarlo. Y trabajar con soluciones
escalables le permitirá manejar la expectativa en el tiempo y canalizar todos los atributos
deseados, porque no, en futuras fases y proyectos. Quién dice que los usuarios no le
terminarán agradeciendo la discreta pero efectiva planilla de cálculos, por su contundencia y
funcionalidad, antes que por sus atributos marketineros estilo vendedor. Terminas un proyecto,
lo entregas a tu cliente y cuando le preguntas qué le parece, este te sorprende con la fatídica
frase: “no es lo que quería”. ¿Por qué te ha sucedido esto? ¿Qué has hecho mal? Has tomado
nota de sus requerimientos, has hecho todo lo que quería, incluso cuando ha cambiado de
opinión sin motivo aparente. ¿Por qué sus expectativas no están satisfechas? La respuesta a
estas preguntas no es simple. Lo que suele suceder en estos casos es que el cliente tiene

7
necesidades o deseos ocultos que no hemos sabido descubrir ni entender. La mayoría de los
proyectos son largos y complejos en el tiempo, y tu cliente se juega, entre otras cosas, su
reputación dentro de su compañía, algo que es muy importante para él o ella. Un buen gestor
de proyectos acompaña a su cliente en todo momento, se adelanta a sus necesidades, evalúa
sus expectativas en cada fase. ¿Haces tú todo esto? Por otro lado, ten en cuenta que tu cliente
puede ser “múltiple”. Esto sucede, sobre todo, en casos en los que tu proyecto consiste en el
desarrollo de un producto para un consumidor final. ¿Quién es tu cliente en este caso? ¿La
persona que paga el proyecto o las que utilizarán el producto? En este caso, debes tener en
cuenta las necesidades de todos los implicados. Si tu cliente – el que te paga – está satisfecho
con el producto que le entregas pero luego, cuando lo distribuye entre sus consumidores, no
tiene éxito, te culpará a ti de esos fracasos. Para que esta situación no se convierta en un
riesgo, debes analizar a los consumidores con pruebas piloto, encuestas y entrevistas. De esta
manera puedes comprobar que los requerimientos iniciales de tu interlocutor son válidos y
puedes también mejorar el producto final agregando otras características y funcionalidades
que detectes como importantes durante el proceso. Tu cliente te lo agradecerá y acabarás
mejorando sus expectativas iniciales.

Un error habitual, especialmente en proyectos de corto alcance, consiste en olvidar realizar

entregas intermedias al finalizar cada etapa. Las validaciones parciales permiten confirmar que
las expectativas del cliente se están cumpliendo o reformular el proyecto cuando todavía se
está a tiempo. Muchas veces los clientes no saben explicar exactamente lo que quieren. Tú
realizas tu propia interpretación de su necesidad y te pones a trabajar. Cuando llegas con tu
proyecto finalizado, se produce una conversación similar a esta:
Cliente: esto no es lo que quería.
Tú: bueno, esto fue lo que me pediste.
Cliente: OK pero esto no es lo que yo quería, no me has entendido.

¿Te suena familiar? No confíes nunca en que has entendido todo lo que tu cliente te ha
explicado. Aprende a preguntar para profundizar mejor en su necesidad y para confirmar que
lo que te está pidiendo es realmente lo que quiere. Documenta esa necesidad y haz que tu
cliente la revise.

8
¿Qué es el equipo extendido?

En muchos proyectos hay un grupo de personas de la organización que participan

puntualmente en tareas del cronograma y que generalmente no están asignados al equipo,
pero su participación es clave ya que sus tareas influirán en muchas personas del proyecto que
dependen de ellas. Estas personas están en el equipo extendido y su participación debe ser
negociada. También el momento preciso es importante: esas tareas deben realizarse según lo
planificado, ya que de lo contrario retrasarán al cronograma significativamente. Estas personas
pertenecen a otras áreas y el líder de proyecto debe comprometer su participación a pesar de
no tener poder formal sobre ellos.

El problema del equipo extendido es la negociación con los gerentes de línea para conseguir la
participación de los recursos en el proyecto. A veces la organización promueve este tipo de
formación de equipos, pero a veces es algo nuevo que hay que explicar, aclarar y negociar.
¿Qué madurez tiene tu organización para promover la participación en proyectos de personas
de diferentes áreas como equipo extendido?

9
El ciclo de vida reduce las decepciones

Uno de los fenómenos que queremos evitar en nuestro proyecto son las decepciones. El ciclo
de vida asume un orden para el desarrollo del proyecto que es el más recomendable, el más
utilizado y el más seguro. Debemos estructurar el proyecto, planificarlo, ejecutar las tareas del
cronograma y cerrarlo elegantemente. Así de simple. Y lo que queremos es que este ciclo de
vida esté legitimado: que haya tiempo asignado para estructurar y planificar antes de ejecutar
tareas, por ejemplo. Que haya tiempo para cerrar el proyecto elegantemente, por ejemplo.
Que haya un kick off si es necesario, por ejemplo.

Otro de los problemas típicos, sobre todo en Latinoamérica, es que no le damos o nos dejan
darle mucha importancia a la planificación. Cada hora gastada en planificación nos va a hacer
ahorrar 10 horas en la ejecución. Somos buenos improvisando, pero la improvisación no puede
ser una estrategia. La improvisación debería ser el último recurso.

El ciclo de vida debe ser reproducido según las mejores prácticas, buscando las variaciones
más convenientes dependiendo del proyecto: ¿el proyecto dura 3 semanas? No hace falta un
plan muy detallado... ¿El proyecto tiene pocos interesados alrededor? No hace falta un kick
off... ¿El equipo de proyecto está compuesto por tres personas? No tendremos mucha
oportunidad de desarrollar el equipo o de reasignar roles o tareas...

Todas estas son decisiones del líder o la líder de proyecto, y legitimar el ciclo de vida del
proyecto es su responsabilidad.

10
¿Por qué la gestión del cambio es obligatoria?

Un proyecto es una iniciativa en una organización para trasladarla desde un Escenario A a un

Escenario B. Ese traslado implica un cambio, y esto es algo que los diferentes involucrados
absorben en forma diferente. Tu proyecto puede haber salido bien, puede haber cumplido con
la triple limitación perfectamente, pero si la organización no absorbe el cambio el proyecto
fracasa: el cliente interno no usará lo que se construyó, habrá saboteadores internos,
opositores encubiertos al proyecto. Y todo esto provocará el fracaso.

El proceso de gestión del cambio se relaciona con la necesidad de organizar y monitorear

cualquier cambio organizacional que suponga una variación importante en los sistemas de
trabajo o en las tecnologías operativas. Este tipo de cambios generalmente modifican las
prácticas y la interacción entre las personas. ¿Por qué gestionar el cambio? Hasta hace pocas
décadas cualquier cambio operativo importante en un sector de una organización podía ser
decidido por los responsables directos, quienes establecían un plan de trabajo y administraban
la implementación como otra parte más de sus responsabilidades operativas. Hoy esa
independencia de criterios es en la práctica imposible, porque la creciente integración de los
procesos y sistemas provoca que cada cambio importante en un sector genere ondas
expansivas muy intensas en los otros sectores ligados a los mismos ciclos de negocios. Debes
tener esto en cuenta para gestionar el cambio:

Consecuencias típicas del cambio en las personas:

* Inestabilidad emocional.
* Alto estrés.
* Baja productividad.
* Ansiedad.
* Miedo a lo desconocido.
* Conflictos crecientes en cantidad e intensidad.

¿Cómo absorbemos el cambio?

* Las personas necesitan un período de madurez intelectual y emocional para asimilar el
cambio.
* “Asimilar el Cambio” significa convertir algo “Nuevo” en algo “Normal”, de la misma forma
que un niño se acostumbra a una nueva escuela.
* El esfuerzo de asimilación del cambio varía de acuerdo a las características de cada persona.

Una de las mejores prácticas para solucionar este problema es detectar tempranamente los
Agentes de Cambio (“Change Agents”) dentro de la organización y asignarles un papel activo
en el proyecto para que “vendan” el proyecto entre sus pares. Un agente de cambio es alguien

11
que supera el rechazo inicial en forma temprana y se compromete con el cambio para un
futuro mejor. No necesariamente es alguien de jerarquía en la organización: puede ser alguien
joven, flexible, dinámico/a que esté entusiasmado con el proyecto y aliente a los demás a
recorrer el camino. Siempre será mejor que un agente de cambio de la misma organización
“venda” el proyecto y no el consultor externo que está implementándolo.

12
¿Quiénes son los interesados de un proyecto?

Los interesados del proyecto son individuos, grupos u organizaciones que pueden afectar,
verse afectados o percibirse a sí mismos como afectados por una decisión, actividad o
resultado de un proyecto. Estos pueden influir sobre el proyecto y sus entregables, y pueden
encontrarse dentro o fuera de la organización. Resulta fundamental para el éxito del proyecto
identificar a los interesados, individualmente o en grupos, y analizar sus niveles de interés,
expectativas e influencia. Esta evaluación inicial debe ser actualizada regularmente en el ciclo
de vida. Aunque el tiempo con que se cuenta en un proyecto es muy limitado esta
identificación debe hacerse, ya que parte del trabajo es enfocarse en las relaciones humanas
necesarias para el éxito. La identificación de los interesados es la tarea más importante.

13
¿Qué es el alcance?

El alcance del proyecto es la especificación de lo que el proyecto incluye y no incluye. La

definición del alcance de un proyecto es el proceso de subdividir los entregables principales en
componentes administrables con el objetivo de
1. Mejorar la exactitud de los estimados de costo y tiempo.
2. Definir una línea de base para medición y control del proyecto.
3. Facilitar una clara asignación de roles y responsabilidades.

La principal herramienta para definir el alcance es el EDT (Estructura de Descomposición del

Trabajo) o WBS (Work Breakdown Structure), un diagrama en forma de árbol que detalla
cuáles son los entregables y subentregables del proyecto. Para construirlo se utiliza la técnica
de descomposición: esta técnica consiste en identificar los principales entregables y sus
componentes en forma recursiva, para poder administrarlos más fácilmente. El primer nivel de
la descomposición puede hacerse en base a los principales entregables del proyecto. Los
niveles subsiguientes del EDT ayudan a identificar componentes más pequeños que podrán ser
delegados a miembros del equipo, proveedores u otros involucrados. Lo importante es que la
subdivisión de un componente en el nivel (N) en m subcomponentes (N1), (N2), .... (Nm) sea
necesaria y suficiente: que no haya un componente que falte o que sobre. En muchas
organizaciones existe el interés por guardar cronogramas de proyectos anteriores con el
objetivo de reutilizarlos. Es más importante guardar un EDT.

El EDT es la columna vertebral de tu proyecto, ya que las estimaciones de las tareas, la

planificación del trabajo, la descripción del avance del proyecto y los pagos a proveedores se
harán en base a entregables. Además, una de las principales responsabilidades del líder o la
líder del proyecto es la integración: hacer que el EDT funcione y de beneficios, aunque sea
construido por diferentes grupos internos o externos a la organización.

14
¿Cómo asignamos recursos a las tareas?

Con una estructura de tareas ya establecidas llega el momento asignar recursos. Estos pueden
ser humanos o materiales pero, en cualquier caso, ambos pueden sernos necesarios para
llevar a cabo determinadas tareas.

Recursos humanos: empleados, contratados, consultores, especialistas, etc.

Recursos materiales: una grúa, una sala de capacitación, combustible, una computadora, etc.

El proceso de asignación es simple: pasar por todas las tareas y asignarles los recursos
necesarios. En función de las características de la tarea asignaremos unos u otros según su
experiencia, conocimiento, etc. Este paso no tiene mayor dificultad, pero las decisiones que
tomemos pueden llegar a ejercer una gran influencia en el proyecto. Por ejemplo, colocar en la
tarea recursos con más experiencia puede provocar un aumento en la calidad del resultado
final, pero a la vez un aumento de costos.

También hay que solucionar el problema de sobreasignación: este se da cuando una persona X
tiene asignadas tareas para trabajar en el mismo día.

15
La definición de roles y responsabilidades

Una de las principales tareas a realizar al momento de comenzar a planificar un proyecto es la

definición de roles, donde se describan las responsabilidades de cada colaborador. Existen
diferentes formatos para documentar los roles y las responsabilidades de los miembros del
equipo. Una herramienta muy conocida para esta tarea es la Matriz de Responsabilidades
(RAM, Responsibility Assignment Matrix), una tabla en donde:

* Las columnas son los nombres de las personas en el equipo y el equipo extendido.

* Las filas son las tareas o actividades a desarrollar en el proyecto.

* Las celdas contienen una letra: R-Responsable, C-Consultado, L-Lidera, P-Participa, I-

Informado y algunos más que describan qué rol juega esa persona en esa tarea.

16
¿A quién invitar a la reunión de lanzamiento del proyecto?

En la reunión de lanzamiento del proyecto deben estar presentes por lo menos los
patrocinadores, el equipo el proyecto y el equipo extendido. También podemos invitar a
proveedores externos, personas clave de otras áreas de la organización, socios de negocios. La
reunión no es una reunión confidencial, al contrario: es una reunión informativa para
comunicar en qué consiste el proyecto. Los más importantes son los miembros del equipo
extendido, porque justamente son los que queremos comprometer para que ejecuten sus
tareas del cronograma en el momento adecuado. Hacer una reunión de lanzamiento solamente
con los miembros de tu equipo no es muy útil, porque los miembros del equipo siempre
estarán y siempre harán las tareas que les delegues. Es el equipo extendido el que te interesa,
y también los patrocinadores. Estos últimos deben venir a la reunión de lanzamiento para
conocer los componentes básicos del proyecto y para conocer a las personas que participarán.

17
Entregables y luego tareas, en ese orden

¿Cómo identificar qué tareas debemos ejecutar en el proyecto? Es muy difícil adivinar la lista
de tareas sin tener un método. El Modelo OEP aconseja elaborar el EDT del proyecto, y para
cada componente pequeño en el EDT pensar en las tareas a realizar para construirlo. Este
enfoque es contratintuitivo, ya que cuando estamos en esta situación de querer identificar las
tareas del plan, corremos hacia nuestra oficina y comenzamos a escribir una lista de tareas
con fechas tentativas.

Una buena forma de escribir un cronograma que no le falten tareas es pensar en los
entregables primero, pensar en qué es lo que hay que construir y cómo se subdivide, antes del
quién o del cuándo.

18
Pensá en términos de entregables

Las expectativas de cualquier interesado en el proyecto, incluyendo los patrocinadores, deben

ser traducidas a entregables. Cuando organizamos una fiesta, las expectativas son traducidas
a entregables: ¿qué comida vamos a servir? ¿qué bebida? ¿qué música habrá? ¿cómo estarán
sentados los invitados? No hay proyecto si no pasamos por el concepto de entregables. De la
misma forma se debe comportar tu equipo para manejar las expectativas con los
patrocinadores: cuando un patrocinador expresa una expectativa acerca del proyecto, debe
inmediatamente traducirse a entregables. "Quiero una mejor atención al cliente en las
sucursales", "¿Usted quiere lograr esto a través de un nuevo sistema informático para los
cajeros o solamente a través de un programa de capacitación, o quizás rediseñando las filas y
las salas de espera?".

Pensá en términos de entregables, trabajá en términos de entregables. "¿Qué es lo que

tenemos que construir en este proyecto?". Esa es la pregunta.

19
La Corrupción del Alcance (Scope Creep) en el proyecto

Existe un concepto en inglés que se llama Scope Creep, que está asociado a problemas con el
alcance del proyecto en la fase de ejecución: es cuando el equipo del proyecto agrega
funcionalidades al producto sin saber que no estaban pactadas en la definición original, o
cuando acepta nuevas funcionalidades pedidas por el cliente porque no sabe decir que no, o
porque no se da cuenta de que eso causará problemas en el futuro. "Creep " tiene muchas
acepciones, pero la más acertada para nuestro caso es "escalofrío" o "estremecimiento".
"Tener escalofríos de alcance" en la ejecución, esa es la interpretación correcta. Este término
ha sido traducido como Corrupción del Alcance.
La Corrupción del Alcance ("Scope Creep") es la adición de funciones y funcionalidad sin
considerar los efectos sobre el tiempo, los costos y los recursos, o sin la aprobación del cliente.
También conocido como: Adiciones al Alcance; Alteración del Alcance; o Cambio Mayor del
Alcance; o Deslizamiento de Alcance. La premisa más importante a tener en cuenta en este
proceso es: "Habrá cambios al alcance". Esto es un dato, un supuesto del proyecto. La
responsabilidad del gerente de proyecto es definir e implementar un proceso para analizar y
rechazar o aceptar esos cambios. El control del alcance del proyecto también se utiliza para
gestionar los cambios reales cuando suceden y se integra a los otros procesos de control. Los
cambios no controlados se denominan corrupción del alcance del proyecto (Scope Creep =
cambios no controlados). Es decir: los cambios no controlados deberían hacerte estremecer.

20
El control de cambios en el proyecto

No existe un proyecto sin cambios en el alcance original. Un cambio al alcance es cualquier

modificación al alcance del proyecto tal como se define por el EDT aprobado. Los controles al
alcance muchas veces requieren ajustes al costo, tiempo y calidad u otros objetivos del
proyecto (por ejemplo, funcionalidad o características del producto a desarrollar).

Para controlar y manejar los cambios al alcance del proyecto se debe usar un sistema de
control de cambios. Este define los procedimientos por los cuales se aprobarán o rechazarán
los cambios en el proyecto. Esto generalmente incluye una bitácora de incidentes (“Issue Log”)
compartida y accesible por todos los involucrados, un sistema de seguimiento de los cambios
aprobados y un mecanismo de niveles de aprobación para autorizar los cambios, como así
también un sistema para actualizar el plan original del proyecto con los cambios agregados en
la ejecución.

21
Habrá cambios al alcance, superalo

A veces es muy difícil definir todo el alcance en los primeros días del proyecto. Cuanto más
definas mejor, pero a veces es imposible. Deberías prepararte para las modificaciones al
alcance durante la ejecución, tomándolo en forma natural y creando un sistema formal de
administración de cambios al alcance. También debes comunicar cómo se usa, preferiblemente
en la reunión de lanzamiento del proyecto. Va a haber cambios al alcance, eso es un supuesto.
La pregunta es qué tamaño tendrán. Si no logras definir todo el alcance desde un principio,
deberías comunicar esto a los patrocinadores, preparándolos para cambios posteriores.

Otro camino posible cuando no se puede definir el 100% del EDT es utilizar Metodologías
Ágiles en el proyecto, ya que estas preparan a todos para cambios posteriores, y toman a los
cambios de alcance como algo natural, no como un desgracia.

22
Para hacer el cronograma hay que definir el alcance antes

Una de las herramientas más útiles que tiene el equipo del proyecto para definir el alcance es
el EDT (Estructura de Descomposición del Trabajo). Con la ayuda del EDT el equipo del
proyecto puede definir cuáles son y cómo se descomponen los entregables del proyecto. De
esta forma es posible crear un cronograma de trabajo basado en el EDT que aumente las
probabilidades de éxito: "Si ejecutamos todas las tareas del cronograma entonces
construiremos todos los entregables y subentregables del EDT, y por lo tanto cumpliremos con
el alcance prometido". Pero la vida no es tan fácil: a veces esta última afirmación ("Si A,
entonces B, por lo tanto C") no se cumple, porque las expectativas del cliente del proyecto son
diferentes a los entregables construidos. ¿Cómo solucionar este problema? Un consejo:
"Empezá del final". Una buena técnica es hablar, formal o informalmente, con los clientes del
proyecto, con los futuros usuarios, con las personas que usarán los entregables, acerca de qué
esperan de ellos. Y aquí no se trata solamente del "Qué", sino de las 5 preguntas básicas:
"Qué", "Cómo", "Quién", "Cuándo", "Dónde", y una sexta que podría ser "Para qué". Utiliza
estas 6 preguntas para obtener esta información importantísima para el proyecto:

"Qué": ¿qué entregables espera el cliente, qué funcionalidad espera, qué comportamiento
espera de los entregables?

"Cómo": ¿cómo deben funcionar, cómo deben verse, cómo se usarán?

"Quién": ¿quién usará los entregables, quién se verá beneficiado por su creación?

"Cuándo": ¿cuándo los comenzarán a usar, cuándo terminarán de usarlos, los usarán durante
todos los días, en períodos?

"Dónde": ¿en la organización, fuera de la organización, en todo el mundo, sólo en el país, en la

casa matriz, en las sucursales?

"Para qué": ¿para qué quieren los entregables, para qué serán usados, qué cosas hoy no
pueden hacer que sí podrán hacer después del proyecto?

23
¿No conocés la ruta crítica?

Muchos profesionales preguntan para qué sirve saber la ruta crítica del proyecto. Una de las
respuestas posibles es: "Mirá qué errores serios podés cometer si no la sabés":

1. Le pedís a tu equipo que venga a trabajar un sábado en una tarea que no está en la ruta
crítica. "¿Para qué?".

2. Te atrasaste en una tarea con holgura, eso te preocupa, y no estás poniéndole atención a
las tareas críticas con holgura cero. "Elegí tus batallas".

3. Asignás recursos con poca experiencia a tareas con holgura cero. "Riesgoso".

4. Asignás recursos con mucha experiencia a tareas no críticas (con holgura mayor que cero).
"¿Para qué?".

24
El control de los cambios al alcance

La gestión del alcance es una de las labores críticas del equipo del proyecto, porque es una
tarea intrínseca muy relacionada al aspecto humano. Los objetivos de los proyectos están
definidos por personas, y aunque pensemos en los proyectos como un proceso racional, la
toma de decisiones de las personas y los criterios de elección está influenciados por nuestra
naturaleza humana, muchas veces emocional. Todo este proceso se complica cuando en el
proyecto están involucrados algunos interesados que intentarán imponer su criterio. Las
circunstancias en las que se van a ejecutar los proyectos van a cambiar con el tiempo,
especialmente en sectores en los que el mercado, la competencia y los clientes cambian
vertiginosamente. Hay muchas circunstancias en las que se van a producir cambios en el
alcance. No vamos a poder evitar los cambios pero sí vamos a controlarlos.

25
¿Cómo evitar la catarsis en las reuniones de estado?

Las reuniones de estado deberían ser un algoritmo desprovisto de sentimientos, en donde se

sigue una rutina a la cual se acostumbra el equipo de proyecto rápidamente. Se habla en
ronda de las tareas que cada uno realizó esta semana, de las tareas que realizará la próxima
semana y de los problemas que se han encontrado, sobre todo excepciones al alcance. Y este
último punto debe estar claro: las excepciones al alcance se reportan en una lista de
pendientes. No se habla de un problema si no ha sido registrado antes. Todos deben leer la
lista de pendientes antes de la reunión. Esto evita la catarsis y la queja constante.

No trates de resolver problemas en la reunión de estado porque generalmente no están en la

reunión las personas que pueden resolverlos. La reunión de estado es para registrar
problemas, no para resolverlos. Si se presenta un problema encontrado al equipo en la reunión
de estado, este problema debe estar dado de alta previamente en el listado de pendientes.
Uno de los objetivos de la reunión de estado es dar a conocer los problemas, que el equipo
esté consciente de que existen, pero no resolverlos. La reunión de estado debe generar
reuniones futuras, cada una orientada a resolver un problema del listado de pendientes.

26
¿Cómo cerrar un proyecto apropiadamente?

El cierre del proyecto es la última fase en el ciclo de vida. En esta fase se debe acordar la
finalización de los entregables con el cliente, validarlos y cerrar el proyecto formalmente. Esto
incluye pasar la documentación del proyecto al sector de operaciones de la compañía, cancelar
los contratos con proveedores, liberar a los recursos humanos en el proyecto e informar a los
interesados acerca de la finalización. Muchas veces se realiza una revisión post-
implementación para identificar lecciones aprendidas y usarlas en próximos proyectos.
En los proyectos el equipo ejecuta las tareas del cronograma durante el 80% del período. En la
mayoría de ellos, el equipo finaliza la construcción de entregables, la conclusión del proyecto
lleva media hora y el equipo desaparece. En muchas ocasiones, a medida que los trabajos van
concluyendo nos retiran los recursos para otros proyectos, por lo que el concepto de cerrar el
proyecto parece no tener razón de ser. ¿Qué debería realizar el gerente de proyecto para
concluir en forma apropiada las tareas, y en qué consistiría un cierre de proyecto perfecto, o
por lo menos deseable?

1. El equipo del proyecto comunica que finalizó los entregables, señalando que los criterios de
calidad fueron aprobados.

2. El gerente del proyecto debe llamar al patrocinador y/o al cliente y solicitarles que validen
los entregables. En ocasiones, se redacta un documento formal que expresa esa validación.

3. El gerente de proyecto debe cerrar formalmente el proceso de administración de las

contrataciones. Como gerentes, somos responsables de este proceso y por lo tanto cuando
finaliza el proyecto debemos verificar todos los contratos que se pactaron. Por ejemplo, si un
proveedor cumplió con las cláusulas y condiciones y además, si se le pagó en tiempo y forma.
Es decir, debemos estar presentes hasta último momento y unir todos los cabos sueltos en
este proceso de cierre. En tal sentido, aun cuando el proyecto hubiese sido interrumpido o
detenido o se hayan retirado los proveedores, debemos efectuar el trámite administrativo de
cierre de contratos. Se recomienda llevar una carpeta que incluya todos los contratos del
proyecto y su verificación, así como la descripción del desempeño de los proveedores.
Asimismo, debemos proporcionarle al proveedor una hoja firmada informándole que su
contrato ha finalizado, y recién a continuación realizar el cierre administrativo.

4. El cierre formal de las obligaciones con los proveedores implica que debemos supervisar que
el área de compras también haya cerrado los contratos con dichos proveedores (si esto aplica
en la organización).

27
5. Junto con el equipo llevaremos a cabo un análisis de las lecciones aprendidas durante el
desarrollo del proyecto, no con la intención de criticar sino para que esta experiencia pueda ser
aprovechada en proyectos futuros. Por ejemplo, un miembro del equipo que cuente acerca de
algún obstáculo que encontró en el proyecto y de cómo lo solucionó. O de cuestiones
importantes a tener en cuenta para proyectos similares. ¿Cómo lograr que el equipo se
exprese, que no se sienta inhibido? Es responsabilidad del gerente de proyecto crear un clima
propicio para esto, quizás sacando al equipo de la oficina, o coordinando una actividad especial
para lecciones aprendidas.

6. Precisamente, uno de los últimos outputs del proyecto consiste en la evaluación del
desempeño de nuestro equipo, sobre todo si el proyecto tuvo una considerable extensión o si
nos encontramos en una organización matricial, en la que los integrantes del proyecto reportan
al gerente de proyecto y al gerente funcional.

7. Debemos archivar los documentos del proyecto para poder volver a utilizarlos. Es decir,
procuraremos que cada miembro del equipo vuelque la información en un repositorio común
utilizado por toda la organización. Debemos impedir que a la finalización del proyecto la
información quede en cada una de las PCs de los miembros del equipo y por eso debemos
impulsar una cultura de compartir los documentos y pensar en los que vendrán.

8. Finalmente, luego de archivar los documentos con la colaboración de nuestro equipo,

realizamos un proceso de transferencia de conocimiento que servirá para la operación del
producto que hemos creado. Es indispensable realizar este paso, porque si no lo efectuamos,
significará que el proyecto no se finalizó en forma adecuada y que nadie sabrá cómo se usa lo
que construimos.

28
Checklist para cerrar un proyecto

1. Asegurate que el cliente del proyecto revise los entregables producidos y los apruebe,
preferiblemente por escrito. Hacé una demo de los entregables, mostralos, hacé que los
miembros de tu equipo los muestren a diferentes personas del cliente.

2. Cerrá los pagos finales a proveedores externos, consultores y recursos contratados. Un

gerente de proyecto es responsable de las contrataciones provocadas por el proyecto. No
hagas que el departamento de compras o de recursos humanos te persiga por meses para
asegurarse que los proveedores hicieron su trabajo y se le pueda pagar. Revisá el trabajo de
todos los contratados y averiguá qué pagos quedan pendientes. Hacé el seguimiento de esos
pagos pendientes después de finalizado el proyecto.

3. Organizá una sesión de Lecciones Aprendidas con tu equipo. ¿Qué hicimos mal? ¿Qué
hicimos bien? ¿Qué haríamos diferente si tuviéramos otra oportunidad? ¿Qué le aconsejarías a
los que van a trabajar con estas herramientas o con este cliente en el futuro? Para que tu
equipo hable de estos temas se necesita un ambiente distendido, una cerveza o un café.

4. Comunicá formalmente a los patrocinadores el cierre del proyecto. El proyecto terminó, hacé
una presentación de cómo terminaron los principales indicadores, del dinero gastado, de las
horas incurridas. Podrías presentar las Lecciones Aprendidas, podrías presentar mejoras
sugeridas a los entregables para una "Fase 2".

5. Clasificá, almacená la información producida para proyectos futuros. Pensá en los que
vendrán, pensá en los próximos proyectos, en las próximas actividades de capacitación. Aportá
capital intelectual a tu organización.

29
¿Qué son las sesiones de lecciones aprendidas?

Es una actividad que se realiza en el cierre de todo proyecto, cuyo objetivo es analizar con el
equipo qué salió bien, qué salió mal, qué conclusiones, consejos, advertencias, podemos
rescatar para proyectos futuros. Para que esta actividad se realice, debe existir en la
organización una cultura de administración del conocimiento, una cultura de nutrir el capital
intelectual de la organización.

Las Lecciones Aprendidas son la última oportunidad que tiene el gerente de proyecto de
intercambiar opiniones y vivencias del proyecto con su equipo antes que este se disuelva. Es
una actividad que podría llevar solamente unas horas al final del proyecto, pero que sus frutos
son inmensamente valiosos para los proyectos futuros en la organización.

30