Dirigir efectivamente el alcance de un

proyecto
Por Csar A. Portillo, PMP

ualquiera que haya ledo alguna vez

literatura sobre direccin 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 ms difcil de gestionar de lo que se piensa.
Dichas dificultades pueden surgir por ejemplo, de
un vendedor que trata de complacer a su cliente
prometindole ms entregables en el proyecto; o
de un director quin le agrega entregables al
proyecto sin consultarlo con el equipo del
proyecto; o de un integrante del equipo tcnico
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
mayora de los proyectos. Los cambios al alcance
que se implementan luego de que comenz el
trabajo, tendrn un efecto mayor sobre el
cronograma y el costo del proyecto, que los
cambios que se implementan durante la fase de
inicio o planificacin; 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
cmo el alcance adicional va a impactar las fechas
de entrega (el cronograma) de los entregables del
proyecto y sus recursos (el costo).
El propsito de este artculo 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. (p. 406). La Cuarta
Edicin de La Gua de los Fundamentos para la
Direccin de Proyectos (Gua PMBOK) define el
alcance del proyecto como: El trabajo que se debe
realizar para entregar un producto, servicio, o
resultado con las caractersticas 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 cundo 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 an no se han
terminado las estimaciones del cronograma y del
costo y no ser necesario desechar ningn trabajo.
Durante la fase de planificacin, los cambios al
alcance tendrn un mayor impacto sobre el
cronograma y el costo porque probablemente
requerirn que se planifique ms. Esta
planificacin adicional precisar ms recursos

Centro de Conocimiento del PMI | www.PMI.org/latam | 2010 Csar A. Portillo

humanos y tiempo extra para realizarle los ajustes

al plan. La planificacin adicional tambin puede
incluir un anlisis adicional de un sistema
informtico, cambios a los planos de ingeniera, y
compras adicionales, entre otros. Todas esas tareas
le agregarn un costo al proyecto y provocarn
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 aumentarn
dramticamente su costo y las demoras del
cronograma. Otro impacto negativo de los
cambios al alcance es el impacto sobre la
motivacin 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 dinmica del equipo as como en
su motivacin, trabajo en equipo, y en la
organizacin en general. A continuacin hay
algunos ejemplos de esto:
Unos aos atrs, en una pequea compaa
nacional de seguros, acept una posicin en una
oficina de direccin de proyectos (PMO, por sus
siglas en ingls) que recin se haba establecido. En
dicha posicin, mis responsabilidades eran dirigir
los programas y proyectos estratgicos, ser mentor
para los directores de proyectos principiantes, y
ayudar a desarrollar los procesos de direccin de
proyectos a travs de toda la organizacin. Uno de
mis desafos ms importantes en la organizacin
fue definir y contralar el alcance, dado que los
empleados crean que el ciclo de vida de cada
proyecto inclua cambios de alcance que se hacan
tarde, ningn proyecto terminaba a tiempo, y los
costos de los proyectos no surgan de estimaciones
precisas del trabajo que se necesitaba para
completarlos. Los empleados tambin crean que
todo el trabajo del proyecto era frustrante, y que
todas las tareas del proyecto necesitaran ser hechas
al menos dos veces. Cules eran los orgenes de
estos problemas? La raz de estas dificultades era
una definicin y un control pobre del alcance.
Antes de establecer la oficina de direccin
de proyectos, cuando en la organizacin se
iniciaban y planificaban proyectos, solo se invitaba
a unos pocos gerentes a las reuniones de inicio,

planificacin, o monitoreo y control; y slo a ellos

se los consultaba sobre los proyectos. Excluir a
interesados importantes durante las reuniones de
inicio, planificacin, monitoreo y control provoc
que se omitieran requisitos de alcance que eran
necesarios. Por ejemplo, durante un proyecto de
informtica para corregir un problema de un
sistema de facturacin en el estado de Arizona en
USA, solo se invitaba a los gerentes a asistir a las
reuniones de planificacin; tambin se dejaba de
lado de estas reuniones a aquellas personas quienes
procesaban los formularios de facturacin. Al no
tener un programador o un experto en facturacin
que estuviera familiarizado con el sistema en
cuestin, haca 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 haba 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 aos 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 fcilmente, dado que haba
muchos otros desafos dentro de la cultura de la
organizacin; sin embargo, el incluir a todos los
interesados durante el inicio, la planificacin, y el
monitoreo y el control del proyecto le permiti al
equipo del proyecto completar el proyecto segn
lo planificado.
Otro desafo que tena la organizacin era
controlar el alcance una vez que se haba analizado
el trabajo y que ste ya haba comenzado. Los
gerentes de la organizacin vean 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
polticas de automviles de Nueva York, USA,
dependiendo del ao, del modelo (un sistema de

Centro de Conocimiento del PMI | www.PMI.org/latam | 2010 Csar A. Portillo

tasacin), y de la marca. Este sistema terminara

incluyendo trabajo para corregir el sistema de
tasacin de otros estados tambin! Si el
patrocinador del proyecto o cualquier otro
interesado quera tratar tambin con otros
problemas relacionados al sistema de tasacin, al
comienzo del proyecto se debera haber analizado
el trabajo necesario para corregir esos problemas y
el patrocinador lo debera haber aprobado. Sin esta
aprobacin del patrocinador, el trabajo del
proyecto debera incluir solo el trabajo necesario
para actualizar el sistema de tasacin de Nueva
York. En esta organizacin sin embargo, los
gerentes a menudo le pedan a los empleados de
informtica que trabajaran en tareas que trataran
con problemas de otros sistemas. Desde la
perspectiva de los gerentes, el hecho de tener a los
empleados informticos trabajando en otros
incidentes conocidos durante el proyecto, les
ahorrara dinero (por ejemplo, sus propios
presupuestos) dado que de todos modos se estaba
trabajando en el sistema. Como no se haba hecho
ningn anlisis del trabajo que se agregaba al
sistema, los cambios al sistema creaban otros
problemas dentro del mismo que se deban
corregir. Esto no solo creaba mucha frustracin al
agregar trabajo sino que tambin demoraba los
proyectos y le sumaba costos al mismo. Una vez
que se implement la PMO y se hicieron respetar
sus polticas para limitar el trabajo del proyecto en
el alcance del mismo, los proyectos se completaron
ms 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 opinin, esto
pasa tpicamente 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 organizacin que disea y construye
centros de datos. Algunos de los problemas en esta
organizacin eran que los centros de datos estaban
siendo comercializados y vendidos por un
vendedor, el equipo del proyecto no opinaba o casi

no lo haca respecto de la factibilidad del proyecto,

y la comunicacin entre el cliente y el equipo era
inefectiva. El escenario era el siguiente: se vendi
un centro de datos a un cliente y se deba entregar
el producto final dentro de 22 semanas. El
vendedor prometi los entregables XYZ. La alta
gerencia dise los contratos pero en la
planificacin 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 haba
hecho el anlisis y la planificacin del mismo, y a
menudo, luego de que ya haba comenzado el
trabajo. Ya sabemos lo que pasa en los
cronogramas y en los costos de los proyectos
debido a cambios tardos en el alcance, asique no
voy a repetir los resultados aqu.
Otra fuente de cambios al alcance hechos en
forma tarda eran los que solicitaba el cliente;
algunos de esos cambios se deban a una definicin
pobre del alcance y de su planificacin (como se
mencion antes), o se deban 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 tendran sobre el cronograma y el costo
del proyecto. En esta organizacin, la alta gerencia
y el cliente no eran la nica razn de los cambios
tardos al alcance. Por ejemplo, los integrantes del
equipo de ingeniera implementaban a menudo
cambios al alcance en forma tarda cuando el
cliente les peda algo o debido a limitaciones
tecnolgicas. Dichos cambios tambin se
implementaban sin ser informados al resto del
equipo o sin haberles realizado un anlisis
apropiado, ambos impactaban negativamente al
proyecto. Este entorno disfuncional de proyectos,
como vimos en el ejemplo de la compaa de
seguros, provoc proyectos que se entregaron
tarde, habiendo excedido su presupuesto, y con
una fuerza de trabajo muy descontenta. Por ello,

Centro de Conocimiento del PMI | www.PMI.org/latam | 2010 Csar A. Portillo

qu podemos hacer nosotros (directores de

proyectos y/o programas) para asegurar que el
alcance del proyecto est bien definido para
minimizar los cambios tardos durante el ciclo de
vida del proyecto, y para asegurar que los
interesados entienden el impacto que tienen los
cambios al alcance?

Recomendaciones

A continuacin se presenta un resumen de las

actividades que deberan conducir a asegurar que
se define bien el alcance del proyecto para
eliminar, o para reducir drsticamente, los cambios
al alcance luego de que se haya planificado. En el
caso de que sean necesarios cambios del alcance
luego de la planificacin, inclu qu se debe hacer
para gestionar adecuadamente los cambios al
alcance.

Durante el inicio del proyecto

1. El proyecto debera 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
constitucin del proyecto, y que se desarrolla
el alcance preliminar.
3. Asegurarse de que se entienden los requisitos
del proyecto lo mejor posible. Estos requisitos
evolucionarn durante la planificacin del
proyecto, pero un mejor entendimiento
durante la fase de iniciacin facilitar la
definicin del alcance durante la fase de
planificacin.
4. Desarrollar el acta de constitucin del
proyecto.

Durante la planificacin del proyecto

1. Asegurarse de responder las preguntas que
tiene el equipo del proyecto sobre aspectos
tcnicos, entregables, y sobre el cronograma.

2. Asegurarse de que el equipo del proyecto, el

patrocinador y el cliente, estn de acuerdo con
los entregables.
3. El acta de constitucin del proyecto debera
incluir una lista completa de tareas y de
entregables que estn fuera del alcance del
proyecto.
4. Asegurarse de que toda esta informacin se
actualiza en el acta de constitucin del
proyecto.
5. Asegurarse de que el patrocinador, el cliente, y
el equipo, firman el acta de constitucin del
proyecto.
6. Asegurarse de que se desarrolla un plan de
proyecto preciso.

Durante la ejecucin 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 tendrn
sobre el proyecto, y que lo firme el
patrocinador y/o el cliente.
4. Asegurarse de que el acta de constitucin del
proyecto, y el plan, reflejen los cambios
aprobados al alcance, los cuales muy
probablemente
incluirn
cambios
al
cronograma, a los recursos, y a los costos.
5. Si la alta gerencia demanda que se
implementen cambios al alcance que se haban
rechazado, discuta el incidente con el
patrocinador y pdale ayuda. Ponga lo mejor
para resolver esta situacin y asegrese de que
todos los interesados entiendan los efectos que
tendrn 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:

Centro de Conocimiento del PMI | www.PMI.org/latam | 2010 Csar A. Portillo

(1) pedir que lo asignen a otro proyecto o que

lo saquen del proyecto, lo cual sera una
opcin bien difcil en la economa 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.

Conclusin

Los cambios al alcance del proyecto tendrn un

impacto sobre el cronograma y/o los recursos del
proyecto. Este impacto puede aumentar
dramticamente cuanto ms tarde se pidan los
cambios en el ciclo de vida del proyecto. Como
personas que practicamos la direccin de proyectos
y como profesionales, es crtico minimizar los
cambios al alcance, especialmente una vez que
comenz el trabajo. Para hacerlo, tenemos que
desarrollar lo ms exactamente posible el alcance
del proyecto, lo cual se puede lograr asegurando de
involucrar a todos los interesados que participarn
en las tareas; respondiendo a todas las preguntas,
alcanzando un acuerdo sobre el alcance del trabajo
y los entregables, documentando este alcance, y
asegurndose 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, asegrese de analizar todos los efectos que
tendrn estos cambios sobre el proyecto, y
asegrese 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.

Project Management Institute. (2008). Cuarta

Edicin. La Gua de los Fundamentos para la
Direccin de Proyectos (Gua PMBOK ). Newtown
Square, PA.

Sobre el autor

Cesar A. Portillo tiene ms de 13 aos de

experiencia en direccin de programas y proyectos
en las industrias de manufactura, transporte,
seguros, y tecnologas de la informacin, as como
en trabajo en equipo, comportamiento y cambio
organizacional, calidad y Lean SixSigma. Tiene un
ttulo universitario en sistemas de informacin y
negocios, y una maestra en tecnologas de la
informacin. Es titular de la certificacin PMP y
est certificado como Gerente Certificado en
Calidad y Excelencia Organizacional por la
Sociedad Americana de Calidad, as como es
Cinturn Verde Certificado de ASQ Six Sigma.
Adems, en Baker College Center for Graduate
Studies, en Flint, Michigan, USA es candidato en
el doctorado en administracin de negocios con
una concentracin en desempeo y cambio
organizacional.
Lo
puede
contactar
a
cesarportillo@sbsglobal.net.
Artculo traducido del original en ingls titulado Effective project
scope management en la Biblioteca Virtual del PMI (PMI Virtual
Library) de www.PMI.org
Si tiene alguna sugerencia de mejora de esta traduccin al espaol
puede enviarla a LASpanishNews@pmi.org

Centro de Conocimiento del PMI | www.PMI.org/latam | 2010 Csar A. Portillo