Dirigir efectivamente el alcance de un
proyecto
Por César A. Portillo, PMP
ualquiera que haya leído alguna vez
C 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
Centro de Conocimiento del PMI | www.PMI.org/latam | © 2010 César A. Portillo
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
Edición de La Guía de los Fundamentos para la
Dirección de Proyectos (Guía PMBOK®) 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
1
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
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,
Centro de Conocimiento del PMI | www.PMI.org/latam | © 2010 César A. Portillo
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
2
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
Centro de Conocimiento del PMI | www.PMI.org/latam | © 2010 César A. Portillo
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,
3
¿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.
Centro de Conocimiento del PMI | www.PMI.org/latam | © 2010 César A. Portillo
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:
4
 (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.
Centro de Conocimiento del PMI | www.PMI.org/latam | © 2010 César A. Portillo
Project Management Institute. (2008). Cuarta
Edición. La Guía de los Fundamentos para la
Dirección de Proyectos (Guía PMBOK ®). Newtown
Square, PA.
Sobre el autor
Cesar A. Portillo tiene más de 13 años de
experiencia en dirección de programas y proyectos
en las industrias de manufactura, transporte,
seguros, y tecnologías de la información, así como
en trabajo en equipo, comportamiento y cambio
organizacional, calidad y Lean SixSigma. Tiene un
título universitario en sistemas de información y
negocios, y una maestría en tecnologías de la
información. Es titular de la certificación PMP® y
está certificado como Gerente Certificado en
Calidad y Excelencia Organizacional por la
Sociedad Americana de Calidad, así como es
Cinturón Verde Certificado de ASQ Six Sigma.
Además, en Baker College Center for Graduate
Studies, en Flint, Michigan, USA es candidato en
el doctorado en administración de negocios con
una concentración en desempeño y cambio
organizacional. Lo puede contactar a
cesarportillo@sbsglobal.net.
Artículo traducido del original en inglés 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 traducción al español
puede enviarla a LASpanishNews@pmi.org
5