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. 

Cambios en los proyectos

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

Proyect On Track

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.

 southern-cross-railway-station

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

Change Control Board

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.

Scope Creep

La versión en ingles de este artículo fue publicado originalmente por Carlos J. Pampliega, PMP en ProjectManagers.org

Si te ha interesado  –  SUSCRÍBETE a nuestra NEWSLETTER

Architect & Project Manager Professional, PMP Seeking Excellence by Design. Carlos en Google+

2 comments to 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… Czytaj dalej: Gestión de Cambios en el Alcance del Proyecto […]

  • Fernando Rodriguez  says:

    Excelente articulo. Tener en consideracion la triple restriccion alcance – tiempo – costo para la gestion de proyectos resulta muy importante. Muchos proyectos se planean a partir de la fecha de finalizacion o entrega, por ello no pueden haber retrasos. . Saludos!

Dejar un comentario

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>