Está en la página 1de 11

Gestión de Cambios en el Alcance del

Proyecto
Alcance del Proyecto y Scope Creep

La gestión del Alcance es una de las labores críticas del Director de Proyectos, y el área de
conocimiento que más difícil es de definir y de controlar.

Esta dificultad es intrínseca a los proyectos, y se debe a que no podemos prescindir del lado
humano de los proyectos. Los objetivos de los proyectos los definen personas, a las que les
asaltan dudas, indecisiones, y que dependen de procesos en sus organizaciones que
dificultan la propia definición del alcance (distintos departamentos, mala comunicación
dentro de la organización, etc).

Aunque pensemos en los proyectos como un proceso racionalmente establecido, la toma de


decisiones de las personas y los criterios de elección que tenemos las personas, están muy
influenciados por nuestra naturaleza humana. Todo este proceso se complica cuando en el
proyecto están involucrados, y siempre lo están, varios agentes interesados
(stakeholders), que intentarán imponer su criterio sobre el objetivo del proyecto.
Además, 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, los clientes
cambian vertiginosamente.

Si consideramos el ALCANCE como una componente de la triple restricción, luego está


afectado por los cambios que hagamos en las otras dos, TIEMPO y COSTES, incluso,
la CALIDAD como parte central de las tres. Cualquier cambio en las otras restricciones, va
a afectar en el alcance, para bien o para mal. So, hay muchas circunstancias en las que se
van a producir cambios en el alcance. No vamos a parar evitar los cambios, pero sí vamos a
controlarlos.

Luego, de todo este proceso en el que participan muchas personas con diferentes criterios
y motivaciones, podemos esperar la aparición de cambios a la definición original del
alcance del proyecto.

Cómo controlar el alcance de los proyectos es una de las principales inquietudes de los
directivos, CEO´s e interesados del proyecto. Nos hace sentir que no tenemos el control!

¿Somos los Directores de Proyectos unos maniáticos del control?

La actitud del Director de Proyectos suele ser la de un profesional maniático del control,
que evitará los cambios a toda costa. Esta actitud es comprensible porque una vez que nos
hemos hecho cargo de nuestro proyecto y tenemos nuestro plan de control bajo control, no
queremos cambiarlo porque a alguien se la hayan ocurrido alguna sugerencia de última
hora al proyecto.

¿Queremos tener todos los aspectos relacionados con nuestro proyecto totalmente
controlados?

SI, sería deseable. Sin embargo, como hemos visto, no podemos evitar que se produzcan
cambios en el proyecto. “CONTROL” no significa evitar el cambio, convertirse en un
obstáculo del cambio.

Los cambios en nuestro maravillosa Línea Base del Alcance se producirán, y no los
podemos evitar, no es nuestro objetivo, luego ten en cuenta la primera regla:

CHANGE HAPPENS!
…y nosotros no estamos en la mejor posición para oponernos a las decisiones estratégicas
de la dirección, o los clientes.
Nuestra labor entonces es CONTROLAR, VERIFICAR, MONITORIZAR, y cuando el alcance
está fuera de control (descarrilado) devolverlo a la línea base.

Podemos agrupar los siguientes puntos relacionados con la Gestión de Cambios en el


Alcance en tres ideas fundamentales para controlar la Corrupción del Alcance (Scope
Creep)

1. PLANIFICACIÓN del Alcance del Proyecto


2. PRIORIZAR los recursos y los requisitos imprescindibles del proyecto frente a los
Cambios
3. CONTROL Y SEGUIMIENTO del Alcance y sus cambios, lo que genera una continua
Comunicación con interesados y equipo de proyecto

1. PLANIFICAR EL ALCANCE DEL PROYECTO


El alcance debe estar definido en la fase de planificación con la participación de los
interesados.

Esto parece obvio porque lo hemos leído en infinidad de bibliografía, pero no


siempre se hace con el suficiente detalle.

El principal motivo por el que los proyectos fracasan es por una planificación
somera, poco realista o directamente, falta de planificación. En este punto, la
restricción que supone el alcance del proyecto está íntimamente relacionada con las otras
dos componentes, tiempo y costes, por lo que una planificación poco realista de cualquiera
de las anteriores afectará al alcance, obligando a incorporar posteriormente elementos al
alcance que no teníamos previstos inicialmente.

Es importante verificar con las partes interesadas (stakeholders) los requisitos y el


alcance del proyecto, de forma que comprobemos que estamos alineados con lo que los
interesados entienden por el alcance del proyecto. Que el alcance se ajuste a lo que
los interesados esperan y tienen en mente. De ahí que sea importante hacer partícipes a
todos los interesados en el proyecto en las fases más tempranas del mismo, de forma que
seamos capaces de reflejar en la planificación del proyecto el interés de los interesados.

La Estructura de Desglose de Tareas, (work breakdown structure – WBS) es una


herramienta de comunicación con todos los interesados, de modo que deberíamos
usarla como tal y discutirla con aquellos agentes que puedan aportar información y
comentar su criterio. A la vista de nuestra planificación, los interesados pueden visualizar
si hemos interpretado bien sus necesidades, o de lo contrario, comunicarnos cómo
desearían que se modificara la planificación. En cualquier caso, siempre es mejor modificar
la planificación del proyecto antes de haber comenzado a ejecutarlo, que tener que discutir
sobre este cambio durante el proceso de validación del alcance.

Estas reuniones de verificación de los requisitos también sirven para explicar el


procedimiento que establezcamos para gestionar los cambios, lo que nos hace reflexionar
a todos: por una parte a nosotros, si hemos interpretado bien todos los requisitos de los
interesados, confrontándolos con los requisitos de otras partes interesadas, etc; y por otra
parte a los interesados (stakeholders), les hará pensar en que los cambios que deban
introducirse posteriormente serán más costosos y deberán insertarse en un proceso de
gestión aprobado por todos. Por lo tanto, deberán ser muy cuidadosos en la correcta
definición de sus requisitos para evitar costosos cambios.

El principal motivo por el que los proyectos fracasan es

por una planificación somera o poco realista.CLIC PARA TUITEAR

Definir el Proceso de Gestión de Cambios

Como ya hemos visto, change happens, y lo que queremos es controlar y monitorizar el


proyecto para que estos cambios no descarrilen el proyecto.
Lo que necesitamos para establecer este control es un procedimiento en el que cada cambio
pueda documentarse, analizarse, estudiar el posible impacto que tendría en el proyecto,
aprobarse en su caso, comunicarlo y monitorizar su resultado.

Durante el proceso de planificación pactaremos con los interesados este procedimiento que
nos permita a todos gestionar y estar informados sobre los cambios que se puedan
introducir más adelante. El procedimiento establecerá cómo se solicitan los cambios,
cuándo se aprueban y por quién.

También deben servir estas reuniones para establecer un Comité de Gestión de Cambios,
(Change Control Board), que será el encargado de aprobar, o dejar pendiente, los cambios
solicitados según el procedimiento establecido anteriormente. El PM, por si solo, no puede
tomar las decisiones que afectan a las prioridades que se hayan tomado sobre los requisitos
del proyecto. Luego será el comité de cambios, en el que estarán representados aquellos
interesados que sea conveniente, cliente, sponsor, etc, los que entenderán la idoneidad o
no de cada cambio.

La mayoría de las veces los cambios de aprueban en función a criterios de prioridad,


de interés o de negocio, y no tanto en función del impacto que puedan tener en la
línea base del proyecto, su alcance, tiempo o sobrecoste.

El proceso de Gestión de Cambios establece cómo se

solicitan, cuándo se aprueban y por quién.CLIC PARA TUITEAR

Usar herramientas PPM Program and Project Management 2.0

La planificación de un proyecto se puede documentar y visualizar de muy diversas maneras


y a través de distintas herramientas, pero siempre supone un arduo trabajo para el PM y su
equipo.

Tradicionalmente se han venido utilizando plantillas, hojas de cálculo, o software no


especializado para la gestión de proyectos, y cada empresa adaptaba las herramientas que
necesitaba a su forma de trabajar. Las herramientas actuales son un avance sustancial en la
gestión. Cuando los proyectos se vuelven más complejos y se producen cambios durante la
ejecución que nos obligan a replanificar, la gestión de toda esta documentación y del Plan
de Proyecto condiciona la agilidad con que apliquemos los cambios necesarios al proyecto.
La burocracia y el papeleo no pueden ser una excusa para demorar la replanificación y
aplicar un cambio al proyecto. Si no utilizamos un software especializado en la gestión de
proyectos y programas PPM, este trabajo puede hacerse muy engorroso.

La tecnología actual, el software y los entornos de trabajo colaborativos PM2.0, en los que
la toma de datos se hace desde cualquier dispositivo en tiempo real, facilita mucho la tarea
de actualización de la información y la replanificación del proyecto.

Cualquiera de los softwares PPM que están en el mercado introducen las dependencias de
cada una de las tareas conectadas unas con otras, con lo que podemos analizar cualquier
cambio introducido en el proyecto y ver su impacto en las previsiones futuras en cuestión
de segundos.

2. PRIORIZACIÓN DE LOS RECURSOS FRENTE A LOS CAMBIOS


Durante la planificación, nos encontraremos que los intereses de los distintos agentes serán
contrapuestos: distintos departamentos dentro de la organización, varios proyectos que
comparten recursos, interesados externos con motivaciones contrapuestas, etc. Cada parte
intentará ejercer su influencia y buscará sus intereses introduciendo cambios en el alcance
del proyecto.
Para evitar confrontamientos y tener un criterio que sirva para decidir la orientación
de los cambios, es conveniente establecer prioridades en la planificación. En la toma
de requisitos, deberíamos haber establecido unas prioridades sobre el alcance del
proyecto, es decir, qué es prioritario para el proyecto, aquellos objetivos imprescindibles,
y qué otros requisitos añaden valor para alguno de los interesados pero no son
imprescindibles para el negocio.

Cuál es el objetivo del proyecto, qué requisitos son prioritarios para las necesidades del
negocio, y cuáles son requisitos o deseos que responden al criterio individual de un
interesado. Estas prioridades se establecerán en el Plan de Gestión de Requisitos, y es un
documento que convienen consensuarlo con los interesados.

Con estos criterios de prioridades, el change control board tendrá una herramienta para
decidir posteriormente aprobar los cambios que se proponen si están alineados con los
objetivos del proyecto, del negocio. Aquellas peticiones de cambios que no están basadas
en las prioridades del proyecto, y tienen un impacto negativo en su alcance, se deberían
rechazar.

¿Qué requisitos son prioritarios para el proyecto?CLIC PARA


TUITEAR

3. CONTROL Y SEGUIMIENTO
En la mayoría de los casos relacionados con el Scope Creep o corrupción del alcance, las
solicitudes de cambios que se realizan durante la ejecución del proyecto no estaban
documentados, porque muchos interesados prefieren no dejar constancia de solicitudes
de cambios que desearían pero no forman parte de las prioridades del proyecto. Este es el
ejemplo típico del cliente que se acerca al miembro del equipo y le “comenta” la posibilidad
de introducir un cambio “sin importancia”.

Si las peticiones de cambio no se registran, es imposible realizar un seguimiento de las


mismas; y si se llegan a ejecutar estos cambios “indocumentados”, seremos incapaces de
realizar un control sobre el proyecto, se nos escapará de las manos.

Documentar las peticiones de cambio sirve para hacer un seguimiento, evaluar su impacto
y aprobarlo si es el caso. Incluso en el caso de que las peticiones de cambio no se hayan
aprobado, la documentación y el análisis que hayamos realizado sobre su impacto nos
servirá para establecer criterios de aceptación en el futuro.

Si hemos establecido un proceso de Proceso de Gestión de Cambios, las peticiones de


cambio se registrarán, bien de forma interna por parte del equipo de proyecto, o externa
por el cliente u otro interesado externo, y se documentarán para que quede constancia y se
pueda hacer un seguimiento. El PM y su equipo estudiarán el impacto que pudiera
tener el cambio sobre el proyecto, analizará si existen alternativas, y aportará esta
documentación al Comité de Gestión de Cambios, que aprobará o rechazará la
solicitud de cambio. En caso de que los cambios se aprueben, éstos deberán incorporarse
al plan, pero además, habrá que comunicar este nuevo escenario a aquellos interesados que
se vean afectados, empezando por el propio equipo de proyecto.

El proceso de estudiar el impacto y replanificar, incluye asignar los recursos y el


presupuesto necesario para llevar a cabo los cambios en el proyecto. Este es el momento
en que se pone de manifiesto si las peticiones de cambio son justificadas y están alineadas
con las prioridades del proyecto, en cuyo caso habrá que asignar mas recursos o tiempo
extra para implementar los cambios. Por el contrario, si el cambio no justifica la necesidad
de más recursos, será un criterio objetivo para rechazar la petición.

Durante este proceso debemos ser capaces de comunicar la necesidad de más recursos para
implementar los cambios, lo que influye directamente en la percepción que el sponsor y el
cliente tendrán sobre los cambios.

Comité de Gestión de Cambios

Como vemos, el PM no puede tomar las decisiones que afectan a las prioridades en los
requisitos del proyecto. Debe contar con el cliente y los grupos más importantes de
interesados que puedan formar parte del Comité de Gestión de Cambios. Ellos aprobarán
los cambios en función de las prioridades que establecimos y cómo afecten a las
restricciones del proyecto.

El PM aporta la información y el análisis del impacto sobre el proyecto, pero evita la presión
de tomar la decisión de aprobar o rechazar los cambios.

¿Qué ocurre en aquellos proyectos en los que no existe un Comité de Gestión de


Cambios?

En este caso, se ejerce una mayor presión sobre el PM para que apruebe los cambios
solicitados, y esta presión puede afectar a la toma de decisiones y al trabajo del PM.
Deberemos ser cautos y consensuar esta toma de decisiones, haciendo partícipes e
informando de ello a las partes interesadas, principalmente sponsor y cliente para que sean
conscientes y aprueben los cambios.

Aprobar los cambios conlleva incorporarlos al proyecto, y por tanto replanificar y


actualizar el Plan de Proyecto (Project Plan), que será más sencillo si utilizamos las
herramientas adecuadas, como hemos visto.

Del porcentaje de proyectos que fracasan, la mayoría fracasan en este punto (75%),
no se actualizan los cambios implementados, y se pierde el control sobre ellos. Y más
importante es que esta documentación no se actualiza, con lo que los interesados, el cliente,
etc, no reciben la información sobre estos cambios, dando pie a posibles conflictos.

Si estamos trabajando con documentación no actualizada, las comunicaciones fracasarán ,


o no nos sirve de nada el seguimiento que hagamos ahora de una línea base del proyecto
desactualizada.

La mayoría de proyectos que fracasan (75%), no se

actualizan los cambios y se pierde el control sobre

ellos.CLIC PARA TUITEAR

EXTRA BONUS:

EL EQUIPO DE PROYECTO
Los miembros del equipo de proyecto están en contacto directo con el terreno, con el
proyecto. Ellos son los que más información tienen sobre pequeños cambios, y ven las
inquietudes de los interesados antes de que se produzca una solicitud de cambio. Una
manera práctica de evitar la Corrupción del Alcance (Scope Creep) es recoger el
feedback del equipo que está en contacto con el entorno del proyecto, miden su avance y
tienen la información de primera mano.

Comunicar todo el proceso de Cambio al Equipo de Proyecto

Por otra parte, al equipo de trabajo es al que más le afectan los cambios, dado que el trabajo
lo hacen las personas, nuestro equipo.

¿Cómo te sientes cuando tu trabajo cambia constantemente y hay que rehacer lo que
ya estaba terminado?

Debemos ser conscientes de la componente psicológica de todo este proceso. Los miembros
del equipo de proyecto deben estar motivados, y rehacer constantemente su trabajo, sin
entender los motivos o sin estar informados de los criterios que impulsan estos cambios,
no afecta al clima de trabajo.

Todos en la empresa quieren cambiar el proyecto, departamentos, unidades de negocio ,


usuarios, etc, y el último en enterarse es el equipo de proyecto.

La mejor manera de motivar al equipo, de que se sienta parte de los cambios y los tome
como suyos es hacerles participes en la toma de decisiones. Podemos darles libertad para
que interactúen con con los interesados, interesándose así por sus criterios sobre los
cambios. De este contacto seguro que aparecen ideas y alternativas a estos cambios que nos
pueden ahorrar tiempo y recursos. Y más importante, los cambios serán valorados y
entendidos por las personas que lo tienen que implementar.

Por contra, este contacto directo del equipo de proyecto con la fuente/origen de los
cambios también les debe capacitar para decir NO cuando se les plantean cambios fuera de
los canales establecidos.

¿Cómo te sientes cuando tu trabajo cambia

constantemente y hay que rehacerlo?CLIC PARA TUITEAR


Empodera a tu Equipo de Proyecto para que tengan la capacidad y la opción de decir
que NO a los miembros de la organización, departamentos, etc, cuando les comentan este
tipo de frases informales en la oficina:

“Ya que estamos, ¿Por qué no hacemos también esto?”

“Si sólo tienes que añadir un poco por aquí…”

“No te llevará mucho tiempo…”

Estas situaciones son típicas en las oficinas de proyectos, y son el claro ejemplo de scope
creep, cambios aparentemente sin importancia que se van introduciendo en el alcance del
proyecto, sin valorar ni estimar el impacto que pueda suponer para el resultado final. Y se
realizan de forma informal, indocumentada y sin basarse en ningún criterio ni experiencia
previa.

Por esto es tan importante, que el equipo de proyecto esté informado del proceso de gestión
de cambios, y tenga el empoderamiento para evitar estas trampas.

Facilita al equipo de proyecto para que tengan la capacidad de evitar este tipo de cambios
informales que pueden descarrilar el proyecto.

CONCLUSIONES
Seremos poco realistas si pensamos que podemos evitar los cambios en nuestro proyecto.

Los cambios ocurren – Change Happens!

Mi recomendación:

 Establecer PROCESOS DE GESTIÓN DE CAMBIOS y tener claras


unas PRIORIDADES sobre los criterios de éxito del proyecto.
 Ser disciplinado en la gestión y documentación de las solicitudes de cambios y
la REPLANIFICACIÓN del proyecto.
 COMUNICAR y empoderar al equipo de proyecto

No te conviertas en un maniático del control. Controlar el alcance no significa evitar los


cambios, sino gestionar, analizar y monitorizar que los cambios introducidos obedecen a
unos prioridades establecidas por todos, y no afecten a los objetivos principales del
proyecto.