Professional Documents
Culture Documents
Alcance
Es mi deseo en este captulo mostrarles todo lo relacionado con los aspectos te-
ricos de la gestin del alcance del proyecto, como tambin compartir con ustedes
algunas experiencias y sugerencias en cuanto a cmo proceder para obtener un do-
cumento de alcance y sus requerimientos asociados y que stos resulten realmente
tiles para llevar adelante sus proyectos.
Adems detallar los procesos que propone el estndar para mantener bajo control
lo definido. Veamos a continuacin los temas a tratar en este captulo:
4. Definir el alcance
6. Verificar el alcance
7. Controlar el alcance
CAPITULO 03 // Alcance
Presentacin
En este captulo les presento el contenido del rea de conocimiento de Alcance. Los procesos que a continua-
cin se explican son utilizados para captar, documentar y resolver las necesidades del cliente y otros interesados,
mediante el trabajo del proyecto.
Les comento que la complejidad de la definicin del alcance del proyecto est dada por la naturaleza de la
situacin que debemos atravesar para llegar a su concrecin. Quien pide un producto o servicio nos describe
en forma generalmente abstracta qu es lo que l cree que necesita, mientras que quienes desarrollarn ese
producto o servicio tienen como primera tarea interpretar correctamente su necesidad. Por eso, en este captulo
se explica un concepto fundamental de la metodologa, la piedra basal del estndar, denominada Estructura de
Desglose del Trabajo (EDT).
Tambin se analizan otros conceptos clave, como la recoleccin de requerimientos, la verificacin y el control del
alcance.
Objetivos
Describir el proceso completo del alcance.
Desarrollar el concepto de EDT y su importancia.
Evaluar el procedimiento de recoleccin de requerimientos y las tcnicas y herramientas dis-
ponibles.
Entender las diferencias entre verificacin y control de alcance.
Analizar la necesidad y las ventajas de mantener el alcance bajo control.
Napolen Bonaparte
El fin de la cita de Napolen es graficar aquello que es inherente a la definicin del alcance: Cmo puedo com-
prometerme a hacer algo por un determinado monto o en determinado perodo de tiempo, si no s qu es lo que
tengo que hacer? Un gerente de proyectos experimentado basa todas sus estimaciones en una definicin clara
y precisa de lo que hay que hacer. Y en el caso de no tener una buena definicin de lo que el cliente espera del
proyecto, tiene que trabajar para lograrlo.
Hace no mucho tiempo me pidieron que desarrolle un reporte para que un cliente pueda ver informacin de
ventas de su industria y que esos datos se actualicen todos los meses automticamente. Cuando me lleg este
pedido por mail, fui a ver a la persona que me envi esa informacin y le ped ms detalle. Me dijo que no saba
mucho ms que eso y, acto seguido, me pregunt para cuando lo iba a tener listo. Mi respuesta fue que lo nico
que poda estimar en ese momento es que deberamos trabajar una semana en la definicin del alcance de lo
que hay que hacer.
La gestin del alcance del proyecto es el conjunto de los procesos necesarios para asegurar que se incluya todo
el trabajo requerido para completar el proyecto satisfactoriamente. Las funciones primordiales de la gestin del
alcance son la definicin y el control de lo que est y lo que no est incluido en el proyecto.
Luego de haber gestionado muchos proyectos puedo asegurar sin temor a equivocarme que la definicin del
alcance del proyecto, es decir, qu es lo que hay que producir, es una de las tareas ms difciles de realizar.
El proceso de entender qu es lo que nos estn pidiendo y el hecho de poder traducir ese pedido en algo tangible
y mensurable son uno de los desafos ms importantes que tiene un gerente de proyectos.
Como cualquier otro desafo, la definicin del alcance requiere de dedicacin, esfuerzo y conocimiento. La
dedicacin y el esfuerzo estn relacionadas con el tiempo que necesitamos para a entender qu pretenden los
clientes que hagamos a travs del proyecto, cul es para ellos el resultado esperado.
El conocimiento del producto o servicio a generar est de nuestro lado; el cliente nos vino a buscar porque no-
sotros somos lo que sabemos cmo desarrollar eso que el cliente quiere. Por lo tanto es una obligacin nuestra
(como gerentes de proyectos y como equipo de trabajo) ayudar a al cliente a definir eso que ellos quieren pero
que, probablemente, no puedan ponerlo en palabras.
Este estndar, en su rea de conocimiento del alcance nos ayudar a poder relevar las necesidades del cliente
con mayor precisin y profesionalismo, y as poder plasmarlas en papel a travs de los procesos de definicin del
alcance y requerimientos del proyecto.
A ver, pensemos, cul es la necesidad de pasar por estos procesos de definicin del alcance?
Existen varias razones por las cuales necesitamos analizar y gestionar mejor el alcance de nuestros proyectos.
Por un lado, una pobre definicin de lo que hay que hacer inexorablemente nos lleva a gastar ms dinero y ms
tiempo en realizar el trabajo. Si no tenemos en claro qu tenemos que hacer, gran parte de nuestro esfuerzo es-
tar orientado a descubrir qu es lo que realmente el cliente me pidi mediante una de las formas de trabajo que
mejor conocemos: prueba y error. Esto tambin nos arrastra a un desgaste de la relacin con nuestros clientes
luego de mostrar varias veces un resultado que no es el esperado, el cliente comenzar a preguntarse si real-
mente tengo la capacidad de hacer lo que ellos me encomendaron-.
Por todo esto, mejor hagamos las cosas bien, desde el principio. Utilicemos los procesos de alcance aqu deta-
llados, que son una herramienta fundamental para entender y hacer lo que nos pidieron bien y, rpidamente, y
como resultado de ello, ganemos prestigio como gerente de proyectos.
TOMEN NOTA:
REFLEXIONEMOS:
Qu opina respecto de la idea de no prometer lo que se duda de poder cumplir? Debata con sus compaeros de
curso o colegas de trabajo a partir de esta pregunta.
Ahora, examinemos cules son las entradas, herramientas y tcnicas y salidas de los procesos de alcance:
Hemos revisado hasta el momento cmo se deber gestionar el alcance del proyecto y cules son los procesos
del rea de conocimiento, ahora pasemos a una cuestin no menos importante: describir cmo planificar y ad-
ministrar el alcance.
El objetivo principal de este proceso es la creacin del plan de gestin del alcance. Aqu se describe cmo se
definir, validar y controlar el proyecto. Este documento formar parte del plan de gestin.
La versin inicial del plan de gestin del alcance se basar en el anlisis de lo documentado en el acta Project
Charter, en el plan de gestin del proyecto y en los factores del entorno organizacional.
Una prctica saludable en la administracin de proyectos es la recoleccin de los requerimientos. Para hacer
esto, repasemos qu aspectos tericos debemos tener en cuenta:
Es el proceso mediante el cual se relevan y documentan las necesidades de los interesados. El xito del proyecto
est directamente relacionado con la recoleccin y gestin cuidadosa de los requerimientos. stos sintetizan las
expectativas del cliente.
Los requerimientos apuntan a cuantificar los deseos de los interesados. Por ello, debe
haber un esfuerzo importante en el proceso de anlisis, de manera tal de que nos permita
llegar a un detalle preciso de todos los requerimientos, para que puedan ser clasificados,
cuantificados y medidos adecuadamente durante la ejecucin del proyecto. Los requeri-
mientos son la base fundamental de la EDT. Los costos, el cronograma y la planificacin
de la calidad, entre otras cosas, se construyen a partir de estos requerimientos.
Los requerimientos funcionales definen las funciones que el producto o servicio ser capaz de
ofrecer.
Los requerimientos no funcionales tienen que ver con caractersticas que de una u otra forma
puedan limitar el producto del proyecto, como por ejemplo, el rendimiento (en tiempo y espa-
cio), fiabilidad, mantenimiento, seguridad, etc.
Aqu se describen los requisitos de comunicacin y el grado de influencia de los interesados con el fin de evaluar
su participacin en las actividades relacionadas con los requerimientos.
Registro de interesados
Este registro contendr la lista de interesados debidamente identificados para un proyecto en particular. Pueden
ser personas fsicas, grupos, instituciones, organizaciones, etc. stos son quienes proporcionarn una informa-
cin ms detallada de los requerimientos del producto y del proyecto.
El registro de los interesados no es otra cosa que una lista de nombres de gente,
grupos u organizaciones relacionadas con el proyecto, con alguna nota que nos gua
sobre en qu situacin nos puede ser til cada uno de ellos. Veamos:
Gerardo Martnez: Ingeniero (nos podr dar una mano con los temas tcnicos del
sistema); Oscar Glvez: Abogado (proveer una gua legal sobre las implicancias del
proyecto); Ramn Soldi: Contador (es quien maneja el presupuesto para este proyec-
to); BitConsulting: Empresa de software (son especialistas en seguridad de sistemas,
nos podrn ayudar con este tema).
Grupos de anlisis
Estn conformados por interesados y expertos en determinados asuntos que fueron previamente seleccionados
para formar parte del grupo. El objetivo es escuchar sus necesidades y evaluar sus expectativas. Las reuniones
son llevadas adelante por un moderador entrenado, quien se encarga de guiar al grupo hacia determinados te-
mas de discusin. Generalmente, los grupos de anlisis son homogneos.
Talleres
Se basan en la reunin en un lugar determinado de un conjunto de personas con diferentes intereses, funciones,
conocimientos y formaciones. El objetivo es la definicin de los requerimientos del producto. En estos talleres
pueden participar todo tipo de interesados (clientes, especialistas, usurarios, tcnicos). Esta tcnica es til para
definir rpidamente los requerimientos y conciliar diferencias entre los interesados. Generalmente, los talleres son
heterogneos.
Mi experiencia dice que una decisin dictatorial nunca es vista con bue-
nos ojos y que puede ser mal recibida por el equipo de trabajo, mientras que una decisin en que la mayora est
de acuerdo es siempre positiva y bien recibida.
Sin embargo, puedo asegurarles que cada tcnica es ms o menos til o efectiva dependiendo del momento y
la situacin en que se aplica. Como gerente de proyectos, varias veces van a tener que tomar una decisin
del tipo dictatorial. El PM es quien tiene en la cabeza todas las variables del proyecto, por lo que cuenta con
mayor informacin para tomar decisiones. El problema de tomar una decisin en forma individual no genera un
conflicto por s misma, sino que el conflicto se puede generar ante la falta de explicaciones al grupo en cuanto
a su justificacin.
Cuestionarios y encuestas
Los cuestionarios y encuestas son grupos de preguntas escritas, diseadas para ser respondidas rpidamente
por un gran nmero de participantes.
Observacin
Consiste en la observacin directa de las personas en su lugar de trabajo. Este mtodo es til cuando se necesita
analizar un proceso detallado, o cuando las personas que usan el producto encuentran dificultoso explicar los
requerimientos relacionados a ste.
Prototipos
Un prototipo es un modelo (representacin, demostracin o simulacin) del futuro producto a desarrollar. A partir
de stos se obtiene una retroalimentacin rpida sobre los requerimientos. Dado que los prototipos son tangibles,
permiten que los interesados interacten con el modelo del producto final, evitando discutir sobre representacio-
nes abstractas de los requerimientos. Los prototipos siguen el concepto de elaboracin progresiva: se utilizan
interactivamente con el cliente en diferentes ciclos de creacin, experimentacin, retroalimentacin y revisin.
Cuando se ha realizado una cantidad de ciclos aceptable, los requerimientos obtenidos del prototipo estn sufi-
cientemente completos como para pasar a la siguiente fase.
REFLEXIONEMOS:
Referencias (Benchmarking)
Es el proceso mediante el cual se recopila informacin y se obtienen nuevas ideas mediante la comparacin de
aspectos de la empresa con los lderes o los competidores del mercado.
Diagramas de contexto
Herramienta que se utiliza para mostrar grficamente el alcance del proyecto, a travs del dibujo de los procesos,
los sistemas y las personas y mostrando la interaccin existente entre stos.
Anlisis de documentacin
Es la revisin y evaluacin de la documentacin que pueda ayudar a definir correctamente los requerimientos. Pueden
tener el formato de contratos, cartas de intensin, planes de negocio, propuestas, grficos, procedimientos o polticas.
Les aconsejo que, ms all de la tcnica que elijan, el mensaje que deben tener en cuenta es que hay que juntar a los
interesados a hablar y discutir sobre el proyecto y su producto. Los avances tecnolgicos an no han podido reempla-
zar los beneficios de sentarse a discutir frente a frente los temas relacionados con lo que hay que hacer y cmo hacerlo.
Mi consejo es que ningn proyecto debera comenzar sin un documento de requerimientos. No digo que
tengamos todos los requerimientos del proyecto perfectamente definidos antes de empezar a trabajar en
el producto del proyecto, pero s remarco la necesidad de que solamente avancemos en el desarrollo de
aquellos requisitos que s tengamos en claro y que estn bien definidos. Mientras parte del equipo se con-
centra en desarrollar lo que ya se sabe, otra parte se debera abocar a definir lo que an no se tiene claro.
Les propongo que sus documentos de requerimientos contemplen como mnimo lo siguiente:
Restricciones Supuestos
TOMEN NOTA:
La matriz ayuda a asegurar que los requerimientos definidos y aprobados que estn en la documentacin del
proyecto se desarrollen, implementen, testeen y aprueben dentro del producto del proyecto, y sean efectivamente
parte del producto o servicio final entregado al cliente. Adems, esta matriz conforma una estructura til para la
administracin de los cambios de alcance del producto. Cada requerimiento puede tener una serie de atributos
asociados que ayudan a describirlo con ms detalle.
Un identificador nico
Una descripcin textual del requerimiento
El dueo del requerimiento
La fuente
La prioridad
El estado
La fecha de aprobacin
Describa, a partir de un trabajo en grupo, cules son los pasos habituales que se siguen en su empresa
cuando deben recolectar requerimientos. Escrbalos y comprelos con lo descripto en esta seccin.
Qu similitudes y diferencias encuentra?
Lo visto hasta el momento nos ayuda a entender definimos cmo gestionamos el alcance del proyecto y para
qu recolectamos los requerimientos. Ahora, estos dos elementos nos van a servir para definir correctamente el
alcance, proceso que descubriremos a continuacin:
En este proceso se detalla el alcance del producto y del proyecto. La preparacin del enunciado del alcance es
fundamental para lograr los objetivos. Aqu se definen los lmites del proyecto.
El enunciado del alcance se construye a partir del documento de requerimientos. A medida que se avanza, se
debe ir analizando qu requerimientos sern incluidos dentro del alcance del proyecto.
Generacin de alternativas
La generacin de alternativas invita a pensar diferentes formas de realizar el mismo trabajo, o producir el mismo
producto o servicio. Existen varias tcnicas que se pueden utilizar para lograr este fin, como la tormenta de ideas
o el pensamiento lateral.1
Talleres
1 El Pensamiento lateral (del ingls lateral thinking) es un mtodo de pensamiento que se emplea para la resolucin de problemas de manera creativa. El trmino fue
acuado por Edward de Bono, en su libro New Think: The Use of Lateral Thinking, publicado en 1967. Se refiere a la tcnica que permite la resolucin de problemas de una
manera indirecta y con un enfoque creativo. El pensamiento lateral es una forma especfica de organizar los procesos de pensamiento, que busca una solucin mediante
estrategias o algoritmos no ortodoxos que normalmente son ignorados por el pensamiento lgico.
Supongamos que estamos definiendo el alcance del proyecto pintar la casa. Recin
contactamos a los pintores y estamos en plena definicin del alcance. El papel escrito
dice El trabajo incluye: Pintar con 3 manos de pintura blanca mate las aberturas y
puertas interiores de madera de la casa. Pintar con 2 manos las paredes exteriores
de la casa con ltex blanco. Qu pasa con las aberturas que no son de madera? Y
las aberturas exteriores de la casa? Esta situacin lo podemos enmendar agregando
la siguiente frase: El trabajo NO incluye: Pintar aberturas internas de aluminio, ni
aberturas externas de madera. Nunca d nada por supuesto
A continuacin voy a detallarles qu elementos deben ser incluidos cuando desarrollen la definicin del alcance
un sus prximos proyectos:
Generalmente el Project Charter y el enunciado del alcance suelen percibirse como documentacin redundante.
Sin embargo, el contenido y el detalle de cada documento es diferente. El Project Charter contiene informacin de
alto nivel, mientras que en el enunciado del alcance se desarrolla una descripcin detallada de los elementos que
hacen al proyecto y que progresivamente se irn precisando con mayor minuciosidad a medida que se avanza en
el entendimiento del producto o servicio a generar.
REFLEXIONEMOS:
Registro de interesados.
Documento de requerimientos.
Matriz de trazabilidad de requerimientos.
En el prximo punto les voy a mostrar una herramienta clave para definir el alcance del proyecto:
El proceso de creacin de la EDT (WBS Work Breakdown Structure) consiste en la subdivisin de los productos
entregables y el trabajo del proyecto en componentes de menor tamao, con el fin de hacerlos ms manejables.
Nivel 1
Nivel 2
Nivel 3 PT PT
Nivel 4 PT PT PT
Nivel 5 PT PT PT PT
Nivel 6 PT PT PT PT
PT = Paquete de Trabajo
Fuente: Propia
entregables que son resultado del esfuerzo realizado para producirlos, y no al esfuerzo en s mismo.
Como gerentes de proyecto deben lograr que los interesados vean la EDT como lo que realmente es: la repre-
sentacin grfica del alcance del proyecto. All ustedes muestran todo el trabajo a realizar y solamente el trabajo a
realizar. Lo que no est en la EDT no es parte del proyecto. Asegrese que todo el equipo del proyecto participe
de su creacin.
Los pasos bsicos para la descomposicin del trabajo total del proyecto son los siguientes:
Verificar el grado de descomposicin significa determinar si los niveles ms bajos de la EDT son los necesarios y
suficientes para completar los productos entregables inmediatamente superiores a stos. Cada producto entre-
gable de un proyecto puede requerir distintos niveles de descomposicin.
Sabemos muy bien que a menudo sucede que no es posible descomponer un entregable en las etapas tempra-
nas del proyecto debido a que se conoce poco sobre ste o porque su ejecucin se dar mucho ms adelante
en el tiempo. Ante esta situacin, el equipo del proyecto puede optar por postergar la descomposicin de ese
entregable hasta tanto se tenga ms informacin.
De acuerdo a lo experimentado en distintos proyectos, me di cuenta de que, si bien el trabajo de desglosar o sub-
dividir el proyecto en productos entregables de menor tamao aparenta ser relativamente sencillo, hay que tener
en cuenta un detalle: la utilizacin de la herramienta es simple, ya que cualquier persona sin mayor experiencia
puede dibujar un diagrama jerrquico para subdividir un producto en subcomponentes menores. Sin embargo,
lograr el dominio de la tcnica que har que ese diagrama jerrquico represente exactamente el alcance del pro-
yecto lleva mucho tiempo, prctica y experiencia.
Usando las fases del ciclo de vida del proyecto como nivel inicial de la EDT (inicio, planificacin,
ejecucin, testeo, cierre).
Usando los productos entregables de ms alto nivel como niveles iniciales (ver ejemplo de la
EDT del auto).
Usando cada rama como un subproyecto, que luego podr ser asignado a otros grupos u
organizaciones para que se encarguen de la posterior descomposicin y ejecucin.
El siguiente es un grfico en el que se muestra una EDT bsica para un proyecto de desarrollo de
un auto:
Fuente: Propia
TOMEN NOTA:
Piensen que unos de los tantos beneficios de la EDT es que el contenido del diccionario de la EDT puede ser
utilizado tambin como medida de verificacin de una correcta descomposicin de un producto entregable. Si
una entrada particular del diccionario de
la EDT contiene demasiadas tareas del
TOMEN NOTA:
cronograma asociadas a un paquete de
trabajo o tiene asignados muchos re- Lnea base del alcance = Documento de alcance + EDT
cursos, o su costo es alto en proporcin + Diccionario de la EDT
al total del proyecto, podra ser que ese
paquete de trabajo necesite uno (o ms) A medida que avanza el proyecto y surgen cambios que son aprobados
niveles de descomposicin. oportunamente, la lnea base = alcance original + cambios aprobados
Veamos ahora qu hacer cuando tenemos un entregable terminado y se lo queremos mostrar a nuestro cliente
para que nos de su aprobacin:
La validacin del alcance es el proceso mediante el cual se formaliza la aceptacin de los productos entregables
terminados. El proceso incluye la revisin de los productos del proyecto junto el cliente o el patrocinador, con el
fin de asegurarse que est completamente satisfecho con el resultado y los acepta.
Solicitud de cambios
Las razones por las cuales se rechaza un producto entregable completado se deben documentar. Esto podr
generar una solicitud de cambio.
REFLEXIONEMOS:
La documentacin de los proyectos de su compaa se actualiza cada vez que surge un Cambio? Por qu?
Hasta aqu vimos qu hacer cuando terminamos un entregable y queremos que el cliente lo acepte. Ahora vea-
mos cmo controlamos que lo que estamos haciendo est realmente alineado a lo que dijimos que bamos a
hacer y qu hacer si lo previamente definido cambi:
7. Controlar el alcance
Es el proceso mediante el cual se realiza el seguimiento y control del alcance del proyecto y se manejan los cam-
bios sobre la lnea base del alcance para
mantenerla actualizada. Realizar el con-
trol del alcance del proyecto asegura TOMEN NOTA:
que todas las solicitudes de cambio
La diferencia entre la validacin y el control del alcance es
y las acciones preventivas y correcti-
que, durante el proceso de validacin del alcance se debe
vas recomendadas sean enviadas al
lograr la aceptacin de los productos entregables del proyecto por
proceso Ejecutar el control integrado
parte de los interesados, mientras que durante el proceso de control
de cambios. Los cambios que no se
del alcance se pretende tener bajo control todas las solicitudes de
controlan son aquellos que luego cola-
cambio que surjan durante el proyecto.
borarn con la alteracin descontrola-
da del alcance. Los cambios son inevitables, por lo tanto, siempre es necesario con-
tar con un procedimiento que los controle.
Documento de requerimientos
Matriz de trazabilidad de los requerimientos
Datos sobre rendimiento
Aqu se pueden incluir los datos sobre la cantidad de solicitudes de cambio pedidas, aprobadas y rechazadas.
Volviendo al ejemplo de la construccin del edificio, sabemos que la estructura del edi-
ficio y la loza estn terminadas y aceptadas por el cliente y, de acuerdo a nuestro crono-
grama, se termin en tiempo. El trabajo de pintura comenz hace 2 semanas, a tiempo
de acuerdo al cronograma, aunque sabemos que vamos a gastar aproximadamente un
7% ms de dinero debido a un ajuste salarial pactado por el gremio de los pintores.
REFLEXIONEMOS:
Solicitud de cambios
Actualizacin del plan de gestin del proyecto
Actualizacin de la lnea base del alcance: si los cambios aprobados afectan el
alcance del proyecto, entonces el enunciado del alcance, la EDT y el diccionario
de la EDT deben ser actualizados para reflejar esas modificaciones.
Documento de requerimientos.
Matriz de trazabilidad de los requerimientos.
A modo de cierre
En este captulo les he mostrado los conceptos relacionados con el alcance del Proyecto.
Aqu les detall los pasos a seguir para plasmar los deseos del cliente en un documento de alcance
y requerimientos, a los efectos obtener la ms clara y concisa definicin del producto o servicio
esperado a travs de la ejecucin del trabajo del proyecto.
En el siguiente captulo exploraremos los temas esenciales del rea de conocimiento de pla-
zos, en el cual aprendern a evaluar y asignar el esfuerzo necesario para la ejecucin del tra-
bajo del proyecto.
Bibliografa consultada