Cualquiera que haya leído alguna vez literatura sobre dirección de proyectos, seguramente sabe lo importante que es definir y controlar apropiadamente el alcance del proyecto. El problema con el alcance es que puede ser más difícil de gestionar de lo que se piensa. Dichas dificultades pueden surgir por ejemplo, de un vendedor que trata de complacer a su cliente prometiéndole más entregables en el proyecto; o de un director quién le agrega entregables al proyecto sin consultarlo con el equipo del proyecto; o de un integrante del equipo técnico que decide ampliar el alcance sin consultarlo con el equipo; o, de un cliente que se da cuenta o decide que necesita cambios en el alcance.

En el mundo real, es de esperar que ocurran cambios al alcance durante el ciclo de vida de la mayoría de los proyectos. Los cambios al alcance que se implementan luego de que comenzó el trabajo, tendrán un efecto mayor sobre el cronograma y el costo del proyecto, que los cambios que se implementan durante la fase de inicio o planificación; por lo tanto, es de suma importancia que se defina bien el alcance del proyecto antes de comenzar el trabajo. En el caso de que se necesiten cambios al alcance luego que el trabajo del proyecto haya comenzado, los interesados (especialmente el patrocinador, el cliente, y el equipo) deben entender exactamente cómo el alcance adicional va a impactar las fechas de entrega (el cronograma) de los entregables del proyecto y sus recursos (el costo).

El propósito de este artículo es ayudar al lector a definir mejor el alcance del proyecto, dar ejemplos de algunas de las dificultades que se encuentran al dirigir el alcance del proyecto, y las consecuencias y recomendaciones para tratar dichas dificultades. Sin embargo, primero necesitamos definir qué es el alcance del proyecto. El Dr. Harold Kerzner (2006) lo define como: “la suma de todos los entregables necesarios del proyecto. Esto incluye todos los productos, servicios, y resultados. La Guía de los Fundamentos para la Dirección de Proyectos PMBOK® Guide define el alcance del proyecto como: “El trabajo que se debe realizar para entregar un producto, servicio, o resultado con las características y funciones especificadas” (p. 444). Mediante estas dos definiciones vemos que el alcance del proyecto incluye todo el trabajo y los entregables que se necesitan para completar el proyecto.

¨Los cambios del alcance del proyecto pueden impactar el cronograma y los costos del proyecto de modo diferente dependiendo de cuándo se implementen los mismos durante el ciclo de vida del proyecto¨.

Durante el inicio del proyecto, cuando se está desarrollando el alcance, cualquier agregado al alcance tendrá el menor impacto en el cronograma o en el costo del proyecto, dado que aún no se han terminado las estimaciones del cronograma y del costo y no será necesario desechar ningún trabajo. Durante la fase de planificación, los cambios al alcance tendrán un mayor impacto sobre el cronograma y el costo porque probablemente requerirán que se planifique más. Esta planificación adicional precisará más recursos humanos y tiempo extra para realizarle los ajustes al plan. La planificación adicional también puede incluir un análisis adicional de un sistema informático, cambios a los planos de ingeniería, y compras adicionales, entre otros. Todas esas tareas le agregarán un costo al proyecto y provocarán demoras en el cronograma. En un proyecto, una vez que su trabajo ha comenzado, y luego en su ciclo de vida, los cambios al alcance aumentarán dramáticamente su costo y las demoras del cronograma. Otro impacto negativo de los cambios al alcance es el impacto sobre la motivación del equipo. En mi experiencia, los cambios que se hacen tarde en el ciclo de vida del proyecto, pueden crear sentimientos negativos dentro del equipo, lo cual puede tener un efecto perjudicial en la dinámica del equipo así como en su motivación, trabajo en equipo, y en la organización en general. A continuación hay algunos ejemplos de esto:

Unos años atrás, en una pequeña compañía nacional de seguros, acepté una posición en una Project Management Office (PMO), que recién se había establecido. En dicha posición, mis responsabilidades eran dirigir los programas y proyectos estratégicos, ser mentor para los directores de proyectos principiantes, y ayudar a desarrollar los procesos de dirección de proyectos a través de toda la organización. Uno de mis desafíos más importantes en la organización fue definir y contralar el alcance, dado que los empleados creían que el ciclo de vida de cada proyecto incluía cambios de alcance que se hacían tarde, ningún proyecto terminaba a tiempo, y los costos de los proyectos no surgían de estimaciones precisas del trabajo que se necesitaba para completarlos. Los empleados también creían que todo el trabajo del proyecto era frustrante, y que todas las tareas del proyecto necesitarían ser hechas al menos dos veces. ¿Cuáles eran los orígenes de estos problemas? La raíz de estas dificultades era una definición y un control pobre del alcance.

Antes de establecer la oficina de dirección de proyectos, cuando en la organización se iniciaban y planificaban proyectos, solo se invitaba a unos pocos gerentes a las reuniones de inicio,
planificación, o monitoreo y control; y sólo a ellos se los consultaba sobre los proyectos. Excluir a interesados importantes durante las reuniones de inicio, planificación, monitoreo y control provocó que se omitieran requisitos de alcance que eran necesarios. Por ejemplo, durante un proyecto de informática para corregir un problema de un sistema de facturación en el estado de Arizona en USA, solo se invitaba a los gerentes a asistir a las reuniones de planificación; también se dejaba de lado de estas reuniones a aquellas personas quienes procesaban los formularios de facturación. Al no tener un programador o un experto en facturación que estuviera familiarizado con el sistema en cuestión, hacía que el alcance del proyecto no incluyera todo el trabajo que se necesitaba para completar el proyecto. Al final, se comenzaba el proyecto varias veces pero no se completaba porque había que volver a planificarlo y a rehacercosas varias veces, y la alta gerencia congelaba los proyectos dado que se necesitaban los recursos en otra parte. Se trabajó sobre este proyecto varias veces por unos años sin mucho avance. Luego de que se estableció la PMO, yo reinicié este proyecto y measeguré de incluir y consultar a todos los interesados. El resultado final fue que el equipo completó el proyecto con éxito en menos de dos meses. Esto no se logró fácilmente, dado que había muchos otros desafíos dentro de la cultura de la organización; sin embargo, el incluir a todos los interesados durante el inicio, la planificación, y el monitoreo y el control del proyecto le permitió al equipo del proyecto completar el proyecto según lo planificado.

Otro desafío que tenía la organización era controlar el alcance una vez que se había analizado el trabajo y que éste ya había comenzado. Los gerentes de la organización veían a los proyectos como una oportunidad para arreglar los problemas sin incluir en sus presupuestos el costo para corregir esos problemas.

Por ejemplo, se inició un proyecto de mantenimiento de un sistema para actualizar el software que generaba las cotizaciones de las políticas de automóviles de Nueva York, USA, dependiendo del año, del modelo (un sistema de tasación), y de la marca. ¡Este sistema terminaría incluyendo trabajo para corregir el sistema de tasación de otros estados también! Si el patrocinador del proyecto o cualquier otro interesado quería tratar también con otros problemas relacionados al sistema de tasación, al comienzo del proyecto se debería haber analizado el trabajo necesario para corregir esos problemas y el patrocinador lo debería haber aprobado. Sin esta aprobación del patrocinador, el trabajo del proyecto debería incluir solo el trabajo necesario para actualizar el sistema de tasación de Nueva York. En esta organización sin embargo, los gerentes a menudo le “pedían” a los empleados de informática que trabajaran en tareas que tratarían con problemas de otros sistemas. Desde la perspectiva de los gerentes, el hecho de tener a los empleados informáticos trabajando en otros incidentes conocidos durante el proyecto, les ahorraría dinero (por ejemplo, sus propios presupuestos) dado que de todos modos se estaba trabajando en el sistema. Como no se había hecho ningún análisis del trabajo que se agregaba al sistema, los cambios al sistema creaban otros problemas dentro del mismo que se debían corregir. Esto no solo creaba mucha frustración al agregar trabajo sino que también demoraba los proyectos y le sumaba costos al mismo. Una vez que se implementó la PMO y se hicieron respetar sus políticas para limitar el trabajo del proyecto en el alcance del mismo, los proyectos se completaron más a tiempo, los costos se redujeron un 60% aproximadamente, y los empleados estaban menos frustrados.

¿Qué pasa si quienes piden los cambios son los patrocinadores o el cliente? En mi opinión, esto pasa típicamente por dos razones: (A) El equipo del proyecto no se comunicó efectivamente con el cliente para recopilar los requisitos necesarios, y/o 2) cambió el entorno del proyecto y los cambios al alcance eran necesarios. Aquí hay otro ejemplo: trabajé en una organización que diseña y construye centros de datos. Algunos de los problemas en esta organización eran que los centros de datos estaban siendo comercializados y vendidos por un vendedor, el equipo del proyecto no opinaba o casi no lo hacía respecto de la factibilidad del proyecto, y la comunicación entre el cliente y el equipo era inefectiva. El escenario era el siguiente: se vendió un centro de datos a un cliente y se debía entregar el producto final dentro de 22 semanas. El vendedor prometió los entregables XYZ. La alta gerencia diseñó los contratos pero en la planificación del proyecto no se incluyó al equipo. En este caso, no se hicieron preguntas sobre los requisitos del proyecto ni se pensaron antes de firmar el contrato, lo cual resultó en un alcance del trabajo que era incompleto. Para corregir esas deficiencias del alcance, la alta gerencia muy a menudo estuvo de acuerdo en hacer cambios al alcance del proyecto luego de que ya se había hecho el análisis y la planificación del mismo, y a menudo, luego de que ya había comenzado el trabajo. Ya sabemos lo que pasa en los cronogramas y en los costos de los proyectos debido a cambios tardíos en el alcance, asique no voy a repetir los resultados aquí.

Otra fuente de cambios al alcance hechos en forma tardía eran los que solicitaba el cliente; algunos de esos cambios se debían a una definición pobre del alcance y de su planificación (como se mencionó antes), o se debían a cambios en el entorno de negocios del cliente. El cliente solicitaba cambios al alcance del proyecto, la gerencia ordenaba esos cambios sin consultar con el equipo, y no se consideraban los efectos que los mismos tendrían sobre el cronograma y el costo del proyecto. En esta organización, la alta gerencia y el cliente no eran la única razón de los cambios tardíos al alcance. Por ejemplo, los integrantes del equipo de ingeniería implementaban a menudo cambios al alcance en forma tardía cuando el cliente les pedía algo o debido a limitaciones tecnológicas. Dichos cambios también se implementaban sin ser informados al resto del equipo o sin haberles realizado un análisis apropiado, ambos impactaban negativamente al proyecto. Este entorno disfuncional de proyectos, como vimos en el ejemplo de la compañía de seguros, provocó proyectos que se entregaron tarde, habiendo excedido su presupuesto, y con una fuerza de trabajo muy descontenta. Por ello, ¿qué podemos hacer nosotros (directores de proyectos y/o programas) para asegurar que el alcance del proyecto está bien definido para minimizar los cambios tardíos durante el ciclo de vida del proyecto, y para asegurar que los interesados entienden el impacto que tienen los cambios al alcance?

Recomendaciones

A continuación se presenta un resumen de las actividades que deberían conducir a asegurar que se define bien el alcance del proyecto para eliminar, o para reducir drásticamente, los cambios al alcance luego de que se haya planificado. En el caso de que sean necesarios cambios del alcance luego de la planificación, incluí qué se debe hacer para gestionar adecuadamente los cambios al alcance.

Durante el inicio del proyecto

1. El proyecto debería ser patrocinado por un ejecutivo o una persona de la alta gerencia cuyo trabajo sea eliminar las piedras del camino que puedan tener impactos negativos sobre el equipo del proyecto y sus entregables.
2. Asegurarse de que se incluyen a todos los interesados cuando se desarrolla el acta de constitución del proyecto, y que se desarrolla el alcance preliminar.
3. Asegurarse de que se entienden los requisitos del proyecto lo mejor posible. Estos requisitos evolucionarán durante la planificación del proyecto, pero un mejor entendimiento durante la fase de iniciación facilitará la definición del alcance durante la fase de
planificación.
4. Desarrollar el acta de constitución del proyecto.

Durante la planificación del proyecto

1. Asegurarse de responder las preguntas que tiene el equipo del proyecto sobre aspectos técnicos, entregables, y sobre el cronograma.
2. Asegurarse de que el equipo del proyecto, el patrocinador y el cliente, están de acuerdo con los entregables.
3. El acta de constitución del proyecto debería incluir una lista completa de tareas y de
entregables que están fuera del alcance del proyecto.
4. Asegurarse de que toda esta información se actualiza en el acta de constitución del proyecto.
5. Asegurarse de que el patrocinador, el cliente, y el equipo, firman el acta de constitución del proyecto.
6. Asegurarse de que se desarrolla un plan de proyecto preciso.

Durante la ejecución del proyecto

1. Asegurarse de no realizar trabajo que esté fuera del alcance del proyecto.
2. Asegurarse de que las solicitudes de cambio al alcance del proyecto se comunican efectivamente al cliente y que éste las entiende.
3. Si un miembro del equipo, un gerente, o un cliente solicita cambios, asegurarse de que estos cambios se analicen bien, que se expliquen todos los impactos que tendrán sobre el proyecto, y que lo firme el patrocinador y/o el cliente.
4. Asegurarse de que el acta de constitución del proyecto, y el plan, reflejen los cambios aprobados al alcance, los cuales muy probablemente incluirán cambios al cronograma, a los recursos, y a los costos.
5. Si la alta gerencia demanda que se implementen cambios al alcance que se habían rechazado, discuta el incidente con el patrocinador y pídale ayuda. Ponga lo mejor para resolver esta situación y asegúrese de que
todos los interesados entiendan los efectos que tendrán en el proyecto los cambios solicitados.
6. En el mundo real, hay veces que la alta gerencia ordena que se implementen cambios al alcance, sin importar el impacto en el proyecto; en esos casos, Ud. tiene dos opciones:

(1) pedir que lo asignen a otro proyecto o que lo saquen del proyecto, lo cual sería una opción bien difícil en la economía de hoy; o (2) implementar los cambios pero solicitar que el gerente que lo solicita apruebe por escrito los cambios y los efectos sobre el proyecto.

Conclusión

Los cambios al alcance del proyecto tendrán un impacto sobre el cronograma y/o los recursos del proyecto. Este impacto puede aumentar dramáticamente cuanto más tarde se pidan los cambios en el ciclo de vida del proyecto. Como personas que practicamos la dirección de proyectos y como profesionales, es crítico minimizar los cambios al alcance, especialmente una vez que comenzó el trabajo. Para hacerlo, tenemos que desarrollar lo más exactamente posible el alcance del proyecto, lo cual se puede lograr asegurando de involucrar a todos los interesados que participarán en las tareas; respondiendo a todas las preguntas, alcanzando un acuerdo sobre el alcance del trabajo y los entregables, documentando este alcance, y asegurándose de que no se realizará trabajo que esté fuera del alcance del proyecto. Si un alto gerente le fuerza para que realice cambios al alcance, asegúrese de analizar todos los efectos que tendrán estos cambios sobre el proyecto, y asegúrese de obtener la firma, del gerente que los solicita, en el formulario de solicitud de cambios

Temas relacionados:
10 Consejos para la Prosperidad de la Gestión de Proyectos