Dirigir efectivamente el alcance de

un proyecto
Por César A. Portillo, PMP César A. Portillo

Unos años atrás, en una pequeña compañía nacional de seguros, acepté una posición
en una oficina de dirección de proyectos (PMO, por sus siglas en inglés) 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 rehacer cosas 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 me aseguré 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

Referencias Kerzner, H. (2006). Project management: A systems approach to planning,

scheduling, and controlling. Hoboken, NJ: John Wiley & Sons, Inc.