Planificacin del proyecto

3.3. PLANIFICAR EL ALCANCE DEL PROYECTO

Una vez definidas las lneas maestras del Plan de Direccin -ciclo de vida del
proyecto y procesos que se van a aplicar y el grado de detalle que se har- y el
Plan de Gestin de Interesados -a qu personas u organizaciones vamos a tener en
cuenta a la hora de definir los requerimientos del producto, servicio o resultado y
del proyecto-, podemos proceder a planificar el Alcance del proyecto.
3.3.1. LA GESTIN DEL ALCANCE DEL PROYECTO
Antes de centrarnos en la planificacin del alcance, hacemos una breve introduccin
a la gestin del alcance del proyecto y los procesos que se ejecutan a lo largo de su
vida.
La gestin del alcance del proyecto (project scope management) es un rea de
conocimiento que incluye los siguientes seis procesos:
Planificar la gestin del alcance (plan scope management).
Recopilar requisitos (collect requirements).
Definir el alcance (define scope).
Crear la Estructura de Desglose de Tareas, EDT (create Work Breakdown
Structure).
Validar el alcance (validate scope).
Controlar el alcance (control scope).
Mediante los cuales:
Por una parte se define cmo se va planificar y gestionar el alcance y se definen
qu trabajos estn incluidos en el proyecto y cules no.
Y, por otra, se establece los mecanismos para asegurar que todo el trabajo que
hay que hacer, y slo el que hay que hacer, se haga.
Se definirn los requerimientos que debe cumplir el proyecto y, para eso, se tendr
en cuenta a todas las partes interesadas, actividad que llevar su tiempo pero que
garantizar que lo que incluye el proyecto recoge sus necesidades y expectativas.
Se incluirn las actividades encaminadas a planificar con antelacin cmo se va a
definir el alcance del proyecto, cmo se va a controlar su cumplimiento, cmo se va
a verificar su alcance y aprobar formalmente antes de iniciar los trabajos.
Si estas fases previas han sido realizadas de forma detallada y organizada, durante
la fase de proyecto se podr controlar las actividades que ya se han completado,
las que estn en curso, y comprobar que, estas ltimas, realmente estn incluidas
en la EDT.
Si hay nuevas actividades por solicitudes de cambios que afecten al alcance, stas
debern ser evaluadas conforme a un proceso establecido que valore su impacto en
el coste, el plazo, la calidad, los riesgos, los recursos..., como condicin previa a su
aprobacin o rechazo.
En definitiva, el Plan de Gestin del alcance del proyecto (Scope Management Plan)
tratar de responder a las siguientes preguntas:
Cmo va a ser planificado el alcance.
Cmo se va a crear la EDT y su Diccionario.
Cmo va a ser ejecutado el alcance y cmo va a ser controlado y validado.
Un error habitual es comenzar a trabajar en un proyecto antes de finalizar el
alcance del producto y del proyecto y, sin tener claro qu es lo que hay que hacer,

definir, entonces, sobre la marcha cmo hacerlo. Esto lleva a que en la fase de
ejecucin del proyecto aparezcan cambios en el alcance incontrolados, que nadie se
haba preguntado qu efecto podran tener sobre el plazo, coste, calidad o
necesidad de recursos del proyecto.
Los seis procesos incluidos en el rea de conocimiento de gestin del alcance del
proyecto (Project scope management) tienen por objetivos:
Definir cmo se va a identificar todo el trabajo que el equipo tendr que realizar
durante el proyecto,
Asegurarse de que se va a realizar todo el trabajo escrito y documentado y nada
ms que ese.
Asegurarse de que, cuando cambien las cosas en el proyecto, se mantenga el
alcance actualizado para que el equipo de proyecto est realizando el trabajo
correcto.
Todo ello se deber recoger en el Plan de Gestin del Alcance (Scope Management
Plan) que evitar que el equipo no sepa por dnde empezar, que haya varios
amagos de comienzo, que las partes interesadas sean impredecibles y vayan
apareciendo y dando sus aportaciones sobre la marcha, que haya cambios sin aviso
en los trabajos a realizar, en su alcance, en sus prioridades...
En el esquema siguiente se observa el grupo de procesos relacionados con la
planificacin y gestin del alcance del proyecto (project scope management) que se
vern de forma individualizada a continuacin. Como se puede observar los
procesos se centran en los grupos de planificacin y supervisin y Control.

Como vimos en el primer captulo existen algunas diferencias entre los procesos de
la Gua del PMBOK y la ISO21500 en lo que a gestin del alcance se refiere. En el
siguiente cuadro se reflejan los procesos de PMBOK y los de ISO21500 (stos
ltimos en cursiva).
Inicio

Planificacin
Ejecucin
Control
Cierre
Planificar la gestin
del alcance
Controlar el
Recoger requisitos
alcance
Definir el alcance
Validar el alcance
Crear la EDT
(Controlar el
(Definir el alcance)
alcance)
(Crear la EDT)
(Definir actividades)
Estos seis procesos, que se presentan con ms detalle en los prximos puntos, se
introducen brevemente en la siguiente tabla:

La gestin del alcance del proyecto (project scope management) garantiza que el
proyecto incluya todo -y nicamente- el trabajo necesario para completarlo con
xito: define qu est incluido y qu no est incluido en el proyecto.
Como se indicaba en la lista de actividades de Mulcahy (2011), la planificacin del
alcance comienza con:
La recogida de requerimientos del producto y del proyecto, completando y
concretando los requerimientos de alto nivel recogidos al elaborar el Acta de
Constitucin (project charter).
Y la elaboracin del Enunciado del alcance del proyecto (project scope statement).
Completadas estas tareas, el project manager debe hacer una valoracin preliminar
de:
Los paquetes de trabajo (work packages) que conviene subcontratar que se
completar y ajustar antes de cerrar el proceso de planificar las adquisiciones
(plan procurements).
El equipo de proyecto necesario para abordar aquellas tareas que se van a
realizar con equipos propios y que se completar y ajustar antes de cerrar el
proceso de planificar los recursos humanos (plan human resources).
Predefinidos los recursos necesarios y las actividades a subcontratar, se elabora la
estructura de desglose del trabajo EDT (work breakdown structure) que cierra,
provisionalmente, la planificacin del alcance del proyecto. Su cierre definitivo ser
cuando se incorporen las tareas procedentes del Plan de Calidad y el Plan de
Respuesta a los Riesgos, reflejo una vez ms de que la planificacin no es un
proceso lineal sino iterativo.

Antes de proceder a describir en detalle los tres procesos de planificacin del

alcance -recoger requerimientos, definir el alcance y elaborar la estructura
desglosada de tareas- trataremos de aclarar algunos conceptos:
Alcance del producto (Product scope) y alcance del proyecto (Project
scope)
Son dos conceptos que conviene no confundir. El alcance del producto (product
scope) es el conjunto de caractersticas y funciones que definen un producto
mientras que el alcance del proyecto (project scope) es el trabajo que hay que
realizar para entregar el producto que lleve incorporadas dichas caractersticas y
funciones.
El alcance del producto (product scope) se refiere, por tanto, a las caractersticas,
componentes, requerimientos, funcionalidades que debe tener el producto o
servicio final que entreguemos al cliente o patrocinador. Por ejemplo, si estamos
diseando un programa informtico sern alcances del producto: la necesidad de
que tenga grficos en tres dimensiones, que sean compatible con diferentes
sistemas operativos, que haya cuatro niveles de dificultad o que puedan jugar 2
jugadores a la vez.
Por su parte, el alcance del proyecto recoge todas las actividades de definicin,
planificacin, ejecucin, seguimiento y control necesarias para que ese producto,
con ese alcance, sea entregado al cliente cumpliendo adems con los requisitos
contractuales de plazo, coste y calidad. En el caso del programa informtico seran
alcance del proyecto: la programacin, el diseo grfico, las pruebas de ensayo, la
elaboracin del cronograma, el documento de requisitos, el seguimiento y control
de los riesgos...
En el caso de que el resultado final sea un producto (mvil, planta de fabricacin,
modelo de coche...) el project/product manager debe:
Empezar con el anlisis de los requisitos y alcance del producto.
Teniendo claro este alcance:
- Definir el trabajo que tienen que hacer el project manager y su equipo

para desarrollarlo y llevarlo a buen puerto -alcance del proyecto con todas
sus fases de planificacin, ejecucin, seguimiento...- (project scope
management).

- Pensar cmo lograrlo (project management plan).

Un producto, o un servicio, o un nuevo proceso organizativo, son el resultado de un

proyecto, y si el resultado es un producto (no un servicio) podramos asimilar al
responsable del producto (product manager) como un director del proyecto (project
manager) cuyo objetivo es crear o lanzar ese producto asignado.
Enunciado del Trabajo de Proyecto, Enunciado del alcance del proyecto y
Documentacin de requisitos
En ocasiones tambin se confunden estos dos conceptos:
- El Enunciado del Trabajo de Proyecto es la documentacin que entrega el cliente y
que describe el alcance de los trabajos a realizar. En una entrada para elaborar el
Acta de Constitucin.

- La Documentacin de requisitos que es el resultado del proceso de Recopilar

requisitos, que tiene por objeto identificar y documentar todos los requisitos de
producto y proyecto de todos los interesados del proyecto.
- El Enunciado del alcance del proyecto es el resultado del proceso de Definir el
Alcance y refleja el alcance del producto y del proyecto, es decir, lo que est
incluido en el proyecto.
La lnea base del alcance del proyecto (Project scope baseline)
Este concepto es muy importante ya que permitir supervisar, controlar y verificar,
durante la vida del proyecto, las variaciones del alcance del proyecto. Est
compuesta por:
Enunciado del alcance del proyecto (Project Scope Statement).
Estructura de Desglose de Trabajo (Work breakdown structure).
Diccionario de la EDT (WBS Dictionary).
El avance real del proyecto se comparar con esta lnea de base y de esta
comparacin se identificarn los adelantos y retrasos y se tomarn las medidas
pertinentes para reconducirlo.
Pasamos a ir describiendo con ms detalle los tres procesos de planificacin del
alcance de un proyecto.
3.3.2. PLANIFICAR LA GESTIN DEL ALCANCE
Una vez abierto el Plan de Direccin de Proyecto, el primer paso a dar es la
definicin de cmo se va a definir, planificar el alcance. Estos aspectos se deben
recoger en el Plan de Gestin del Alcance. Si est bien definido, los siguientes pasos
-recoger requisitos, definir el alcance y crear la EDT- se realizarn de forma ms
coordinada y eficiente.
Este proceso tiene por objetivo definir cmo, quin y con quin, se va a definir el
alcance del producto y proyecto, se va a controlar y verificar el alcance, se van a
evaluar y aprobar o no los cambios propuestos en el alcance y se van a definir y
gestionar los requisitos del producto o resultado.
Es un proceso que conviene que est definido, por parte de la organizacin, como
un proceso estndar que todos los project managers tomarn como base y que
cada uno aplicar y adaptar a las peculiaridades de su proyecto.
En el siguiente esquema vemos su ubicacin dentro del rea de conocimiento de
alcance y el grupo de procesos de planificacin:

En el siguiente esquema se presentan las entradas, tcnicas y herramientas y

salidas que se detallarn a continuacin:

Como se ha comentado anteriormente ISO21500 no tiene un proceso especfico

para elaborar el Plan de Gestin del Alcance si bien se considera entre las labores a
realizar en el proceso "Elaborar los Planes de Proyecto".

PLANIFICAR LA GESTIN DEL ALCANCE (PLAN SCOPE MANAGEMENT):

Este proceso tiene por objetivo definir cmo, quin y con quin se va a definir el
alcance del producto y proyecto, se va a controlar y verificar el alcance, se van a
evaluar y aprobar o no los cambios propuestos en el alcance y se van a definir y
gestionar los requisitos del producto o resultado.
ENTRADAS (INPUTS):
Para elaborarlo se tendrn en cuenta el Acta de Constitucin -del rea de "gestin
de la integracin" y que supone el inicio de un proyecto dentro de la organizacin
donde se define el contexto del proyecto, se incluye una descripcin general del
proyecto y se recogen los requisitos de alto nivel del producto-, los factores
ambientales de la empresa que puedan condicionar este plan -cultura, estructura,
infraestructura..., de la organizacin-, las polticas, procesos y procedimientos
preestablecidos por la organizacin y la informacin histrica y lecciones aprendidas
de otros proyectos.
Plan de Direccin del Proyecto (Project management Plan)
El Plan de Direccin del Proyecto es el plan que recoge e integra el resto de planes.
Si bien el Plan de Gestin del alcance es una entrada para el Plan de Direccin, el
Plan de Direccin es, a su vez, una entrada para el de Gestin del Alcance ya que
dar criterios generales que pueden afectar a la Gestin del Alcance como son los
procesos que se van a realizar y con qu grado de detalle -que depender de la
novedad, complejidad, duracin..., del proyecto- as como si, por ejemplo, se va a
dividir en varias fases -lo que afectar a la gestin del alcance-.
Acta de Constitucin (Project charter)
El Acta de Constitucin recoge los requerimientos de alto nivel, una descripcin
general del producto y sus caractersticas y los principales entregables. Esta
informacin ser la que el project manager utilice para, con las partes interesadas
identificadas, proceder a la recogida de requisitos. Es, por ello, informacin
relevante para planificar cmo se va a gestionar el alcance.

Factores ambientales de la empresa (Enterprise environmental factors)

Entre los factores que pueden afectar a la forma de gestionar el alcance estn, por
ejemplo, la cultura y estructura organizativa -y las asignaciones de funciones y
responsabilidades en el mbito de la gestin de los proyectos y, ms
concretamente, el alcance-, la infraestructura y equipos, las condiciones de
mercado...
Activos de los procesos de la organizacin (Organizational process assets)
La forma de gestionar el alcance puede venir definida o influenciada por las polticas
y procedimientos establecidos en la empresa y la informacin histrica y lecciones
aprendidas sobre cmo definir, planificar, controlar y validar el alcance.
TCNICAS Y HERRAMIENTAS (TOOLS AND TECHNIQUES):
Con esta informacin como base y la experiencia de cmo se ha gestionado el
alcance en proyectos similares, el project manager y su equipo deben mantener
reuniones con todas aquellas partes interesadas que tengan algo que decir sobre el
alcance del producto y del proyecto, y acordar la forma concreta en que va a definir
y gestionar el alcance del proyecto.
Juicio de expertos (Expert judgement)
El project manager har bien en recoger la experiencia de expertos de fuera y
dentro de la organizacin sobre cul es la mejor manera de definir, planificar,
validar y controlar el alcance.
Reuniones (Meetings)
Con la informacin de las entradas como base y la experiencia de cmo se ha
gestionado el alcance en proyectos similares, el project manager y su equipo deben
mantener reuniones con todas aquellas partes interesadas que tengan algo que
decir sobre el alcance del producto y del proyecto, y acordar la forma concreta en
que se va a definir y gestionar el alcance del proyecto.
SALIDAS (OUTPUTS):
El Plan de Gestin del Alcance (Scope management plan)
El Plan de Gestin del Alcance describir cmo se va a definir, desarrollar,
monitorizar, controlar y validar el alcance. Contendr los procedimientos para
recoger los requisitos, preparar un Enunciado del Alcance detallado, preparar la EDT
a partir del anterior, mantener y actualizar cambios aprobados en la EDT, obtener
la aprobacin formal de los entregables por parte del cliente y controlar cmo se
procesan las propuestas de cambio al alcance del proyecto.
El Plan de Gestin del Alcance ser entrada a su vez para los procesos de:
- Recopilar requisitos.
- Definir el alcance.
- Crear la EDT.
El Plan de Gestin de Requisitos (Requirements management plan)
El Plan de Gestin de Requisitos que describir cmo se van a definir, analizar,
documentar y gestionar los requisitos del proyecto.
Debe definir:
- Quin y cmo planificar, seguir y reportar las actividades asociadas a los
requisitos -cmo se iniciarn los cambios en el producto, cmo se analizarn su
impacto, cmo y quin aprobar los cambios y supervisar su implementacin-.
- Cmo se priorizarn los requerimientos.
- Qu mtricas de producto se utilizarn para asegurar que los requisitos se
cumplen.

- Cmo se garantizar su trazabilidad.

El Plan de Gestin de Requisitos ser entrada a su vez para el proceso de Recogida
de requisitos.
3.3.3. RECOPILAR REQUISITOS
En este proceso se definen y documentan las necesidades y expectativas de las
partes interesadas y se traducen a requisitos medibles que al cumplirlos permitan
alcanzar los objetivos del proyecto. El xito del proyecto est muy directamente
relacionado con el cuidado que se tome en la planificacin y recogida de requisitos
del proyecto, en general, y del producto, servicio o resultado, en particular.
Los requisitos incluyen condiciones o capacidades que debe cumplir el proyecto o
que deben estar presentes en el producto, servicio o resultado para satisfacer lo
establecido por contrato o por una especificacin. Los requisitos incluyen tambin
las necesidades y expectativas cuantificadas y documentadas del sponsor, cliente y
otras partes interesadas.
El reto es descubrir los requisitos -no siempre estn claros y explcitos-, analizarlos
y registrarlos con suficiente detalle para ser incluidos en el alcance, poder utilizarlos
en la elaboracin de la EDT y poder ser medidos una vez comience su ejecucin.
En este proceso se definen y documentan, por tanto, las necesidades, deseos y
expectativas del patrocinador (sponsor), del cliente (client) y dems interesados
(stakeholders) para poder cumplir as los objetivos del proyecto. En especial se
requiere un esfuerzo importante de definicin y gestin de las expectativas del
cliente sin descuidar la del resto de interesados.
En todos los casos, sea la tcnica o herramienta que se elija, ser clave equilibrar
los intereses de todas las partes interesadas para lo que el project manager
apoyado y respaldado por el patrocinador debe:
Identificar las partes interesadas y dejar bien claros los requerimientos del
producto y proyecto.
Identificar los intereses confluyentes y buscar soluciones que satisfagan a todas
las partes.
Priorizar los requerimientos segn los objetivos del proyecto y estratgicos de la
empresa teniendo siempre claro que, en caso de duda, los que prevalecen son los
del cliente.
Los criterios para aceptar o rechazar un trabajo en el proyecto sern, por este
orden:
Que satisfaga la necesidad que dio lugar al proyecto, si no se rechaza.
Que est incluido dentro del Acta de Constitucin, si no, se rechaza.
Que pueda integrarse en el Enunciado del alcance del proyecto.
Que no sea incompatible con restricciones impuestas al proyecto.
La ubicacin de este proceso dentro de su rea de conocimiento y los grupos de
procesos se refleja en la siguiente figura:

En
ocasiones, la recogida de requerimientos no se realiza dentro del proyecto sino que
es una entrada externa que, en forma de proyecto constructivo o especificaciones
tcnicas, incluye ya los requerimientos del producto. Tanto en PMBOK como en ese
Manual consideramos que los requisitos se definen dentro del proyecto.
Los requisitos de alto nivel han sido ya establecidos en el inicio del proyecto en el
Acta de Constitucin. En este proceso se afinarn, completarn y convertirn en
requerimientos, cuyo xito sea medible, y en entregables, cuya inspeccin y
aceptacin, de acuerdo a ellos, sea inequvoca.
Los requerimientos del producto son lo que las partes interesadas necesitan que
cumpla el producto o servicio, porque resuelven unos problemas o alcanzan unos
objetivos. Pueden referirse a:
Cmo debe funcionar el sistema (opciones de seguridad y definicin de perfiles).
Funcionalidades que debe tener el producto (compatibilidad con determinado
sistema operativo).
Calidad de sus componentes (utilizando determinado material aislante).
Procesos de negocio (que permita realizar un seguimiento y aprobacin digital de
facturas).
Procesos de seguridad, salud y control de riesgos (que cumpla una determinada
normativa, no necesariamente obligatoria).
Este proceso es crtico ya que un requerimiento no identificado y no incluido puede
llevar al traste con el proyecto y que, llegado el momento de la entrega, el cliente
no lo acepte con las consiguientes consecuencias econmicas y de prdida de la
confianza de ste.
En este esquema se presenta, de forma resumida y esquemtica, las partes de que
consta el proceso de recopilacin de requisitos, sus entradas (inputs), las tcnicas y
herramientas (techniques and tools) utilizadas y las salidas (outputs) del proceso
que, a su vez, alimentarn otros procesos posteriores.

Como se ha comentado anteriormente ISO21500 no tiene un proceso especfico

para recoger los requisitos si bien se considera entre las labores a realizar en el
proceso "Definir el alcance".

RECOPILAR REQUISITOS (COLLECT REQUIREMENTS):

En este proceso se definen y documentan las necesidades y expectativas de las
partes interesadas y se traducen a requisitos medibles que al cumplirlos permitan
alcanzar los objetivos del proyecto.
ENTRADAS (INPUTS):
Para realizar esta recogida de requisitos se necesitarn el Plan de Gestin del
Alcance -resultado del proceso anterior-, que indica cmo gestionar el alcance; el
Plan de Gestin de Requisitos -tambin resultado del proceso anterior-, que indica
cmo proceder en la gestin de requisitos; el Plan de Gestin de Interesados y su
Registro -donde se han recogido las necesidades y expectativas de cada una de
ellas-, y el Acta de Constitucin -que facilita los requerimientos de alto nivel y una
definicin general del producto-.
Plan de Gestin del Alcance (Scope management plan)
Este plan indica a los miembros del equipo de proyecto cmo deben determinar el
alcance del proyecto y, dentro de l, el tipo de requisitos que deben recoger y cmo
recogerlos.
Plan de Gestin de Requisitos (Requirements management plan)
Este plan define cmo se van a gestionar los requisitos a lo largo de la vida del
proyecto garantizando su trazabilidad, integrando las propuestas de cambios en el
proceso general del proyecto, para que, al final, el producto tenga todos y solo los
requisitos establecidos en el proyecto.
Plan de Gestin de los Interesados (Stakeholders management plan)
Este plan define cmo se van a gestionar las necesidades y expectativas de las
partes interesadas muy especialmente en el proceso de recoger requisitos. La
importancia de una determinada parte interesada ser clave para definir la
prioridad de sus requisitos respecto a los de otras partes interesadas.
Acta de Constitucin del Proyecto (Project charter)

Es un documento que autoriza formalmente el proyecto, concede autoridad al

project manager y define a alto nivel el alcance aprobado del proyecto y qu se
supone que tiene que lograr.
Registro de Interesados (Stakeholders register)
Es la lista de las personas con las que el project manager tiene que hablar para
identificar los requisitos y expectativas respecto al producto y el proyecto, ya
porque vayan a verse afectados, porque deban entregar o recibir informacin, o
deban estar informados.
TCNICAS Y HERRAMIENTAS (TECHNIQUES AND TOOLS):
Con toda esa informacin, el project manager y su equipo podrn mantener
entrevistas, organizar grupos de trabajo especficos o transversales, utilizar
tcnicas como los mapas mentales, elaborar cuestionarios y encuestas, proponer la
elaboracin de prototipos, analizar todos los documentos relevantes..., para tratar
de realizar una identificacin completa de los requisitos del producto, servicio o
resultado y del proyecto.
Entrevistas (Interviews)
El project manager entrevista a las partes interesadas en un dilogo directo y
preferentemente individualizado para as identificar sus requerimientos para un
determinado elemento del producto o del proyecto en general. Estos encuentros
pueden ser llevados a cabo va videoconferencia, telfono, presencial...
Grupos de opinin (Focus groups)
En este caso un grupo determinado de partes interesadas o expertos en una
materia comparten y discuten sobre sus ideas y puntos de vista en relacin al
proyecto, siendo moderado por un agente externo que puede ser el project
manager.
Talleres facilitadores (Facilitated workshops)
En estos casos, lo que se pretende es que diferentes partes interesadas
procedentes de diferentes reas de conocimiento (marketing, ingeniera, financiero,
innovacin...) de la empresa:
Hablen e intercambien ideas sobre el producto.
Traten de buscar consenso en relacin a los requerimientos.
En ocasiones, los clasifiquen y ordenen por prioridad.
Se establezcan acciones y objetivos para cumplirlos.
Tcnicas grupales de creatividad (Group creativity techniques)
Entre estas tcnicas podemos encontrarnos:
Desde las que buscan generar ideas:
- Clsicas como la tormenta de ideas (brainstorming).
- El mtodo delphi (delphi technique) que debe ser annimo -los participantes
conocen la aportacin del resto pero no quienes son- y que, muy importante, debe
acabar en una nica solucin consensuada.
- Los mapas mentales (mind maps) -diagramas en los que conforme salen ideas se
van plasmando y permite identificar relaciones entre ellas-. Cuando se ha acabado
el trabajo sobre una idea suele ayudar crear un mapa en el que se vean las ideas
que han surgido, cmo se ha llegado a ellas y tratar de agruparlas por algn
criterio. La siguiente figura sera un mapa mental simplificado:

 Otras tratan de establecer prioridades, relaciones y afinidades entre ellas como:

- Las tcnicas del grupo nominal (nominal group techniques), mediante un proceso
de votacin, se usan para priorizar o jerarquizar las ideas que hayan surgido en
otros ejercicios.
- Los diagramas de afinidad (affinity diagrams) que tratan de agrupar las ideas
surgidas de acuerdo a algn tipo de criterio (similitud, riesgo...). En el ejemplo
siguiente, surgieron diferentes aspectos a tener en cuenta en un proyecto de una
instalacin elica y se agruparon por temas o reas de responsabilidad:

Tcnicas de toma de decisiones (Decisin making techniques)

Todos los esfuerzos para identificar requerimientos de grupos de personas suelen
provocar conflictos ms o menos importantes. Cuando esto ocurre se pueden tomar
las decisiones:
porque as lo decide el cliente,
por unanimidad, mayora absoluta, mayora simple, o
algo ms difcil, mediante consenso.
En cualquier caso, la opcin ms votada debe ser respaldada por todos los
componentes del grupo y solidariamente asumida como propia.
Cuestionarios y encuestas (Questionnaires and surveys)
Se usan sobre todo para grupos grandes donde adems puede ser conveniente
realizar anlisis estadsticos.
El project manager, o quien haga de moderador y coordinador, elabora
cuestionarios que ayuden a identificar requerimientos por parte de los
participantes.
Un ejemplo: preguntar a los clientes, potenciales compradores de un nuevo
telfono mvil, sobre las funcionalidades que ms agradeceran que tuviera el
nuevo modelo que va a sacar la compaa.
Observaciones (Observations)
Con una tcnica similar al comprador invisible (invisible buyer) -una persona va a
comprar a una tienda y observa y anota cmo le atienden-, se observa desde el
anonimato (job shadowing) cmo trabajan los empleados para tratar de identificar
ineficiencias, reas de mejora, riesgos..., o se propone que un "observador
participante" se ponga a hacer el trabajo para experimentar cmo se hace y
descubrir requisitos o puntos de mejora.
Prototipos (Prototypes)
Se crea un modelo operativo del producto esperado antes de construirlo para que
los interesados puedan experimentar y hacerse una idea a escala del resultado
final.
Si bien es una herramienta ms cara y que puede llevar ms tiempo, el prototipo
pretende que el cliente o las partes interesadas vean una versin beta de su
producto o servicio para, sobre ella, ir detectando mejoras, requerimientos nuevos
que puede sugerirle su uso... En definitiva, sigue el concepto de elaboracin gradual
(progressive elaboration) al usar ciclos iterativos.
Ver cmo se comporta el cliente u el usuario final con un prototipo o con un
producto similar puede dar muchas ideas sobre el uso que se le da, las
funcionalidades que se utilizan mucho y las que apenas se utilizan.
Es una herramienta muy til si el proyecto se est desarrollando con tcnicas
iterativas.
Estos mtodos son muy usados en el desarrollo de proyectos informticos, muy
especialmente si se utilizan herramientas y metodologas Agile, donde los
requerimientos del cliente se van definiendo conforme avanza el producto y con una
sistemtica que implica una relacin estrecha y fluida entre cliente y equipo de
proyecto.
Benchmarking
El benchmarking es un proceso sistemtico y continuo para evaluar los productos,
servicios y procesos de trabajo de las organizaciones reconocidas como las que
aplican mejores prcticas.

Podemos identificar tres tipos de benchmarking:

- Interno: Se suele dar en grandes empresas formadas por numerosos
departamentos y/o divisiones, en las que es muy comn comparar los niveles
alcanzados dentro de la misma organizacin.
- Competitivo: Se utiliza cuando hay una competencia agresiva, comparando
algunos aspectos con los competidores ms directos, o con los lderes del mercado,
sobre un cierto producto.
- Funcional: Consiste en compararse con empresas que no pertencen a tu misma
industria; con este consigues la ventaja de obtener la informacin necesaria al no
ser competidor de la empresa.
Diagramas de contexto (Context diagrams)
El diagrama de contexto es un caso especial del diagrama de flujo de datos, en
donde una sola burbuja representa todo el sistema.
El diagrama de contexto muestra a travs de flujos de datos las interacciones
existentes entre los agentes externos y el sistema, sin describir en ningn
momento la estructura del sistema de informacin.
En este tipo de diagrama, el sistema de informacin debe representarse como un
nico proceso de muy alto nivel, con entradas y salidas hacia los agentes externos
que lo limitan, de forma equivalente a una caja negra.
Teniendo en cuenta que este diagrama debe de ser comprensible, no es posible
representar todos los flujos de datos del sistema en l, sino ms bien debe
representarse en l una visin general del sistema desde la perspectiva de los
propietarios de sistemas siguiendo dos lineamientos bsicos:
Representar nicamente los flujos de datos que tengan algo que ver con el
objetivo principal del sistema.
Utilizar flujos de datos compuestos que representen a aquellos que sean
similares.
Dentro de ste diagrama se enfatizan varias caractersticas importantes del
sistema:
Las personas, organizaciones y sistemas con los que se comunica el sistema. Son
conocidos como terminadores.
Los datos que el sistema recibe del mundo exterior y que deben procesarse de
alguna forma.
Los datos producidos por el sistema y que se enviarn al exterior.
Los almacenes de datos que el sistema comparte con los terminadores.
La frontera entre el sistema y el resto del mundo.

El siguiente esquema presenta un buen ejemplo:

Anlisis de documentos (Documents analysis)

Una fuente de requerimientos sern los documentos de proyecto como el contrato,

el caso de negocio, la documentacin de requisitos de otros proyectos... y otros
como registros de incidencias, polticas, procedimientos, documentacin sobre
legislacin y reglamentaciones...
SALIDAS (OUTPUTS):
Como resultado de este proceso se obtendr:
Documentacin de requisitos (Requirements documentation)
La documentacin de requisitos recoger todos los requisitos identificados, que
sean medibles, comprobables, trazables, completos, consistentes y aceptados por
las partes interesadas clave; su impacto en otras reas de la organizacin, en otras
entidades internas o externas a la organizacin; y los supuestos y restricciones
detrs de cada requisito.
Estos requisitos pueden ser, de acuerdo a PMBOK:
- Requisitos de negocio como los objetivos de trazabilidad de los objetivos de la
organizacin, los principios que guan la organizacin...
- Requisitos de interesados como el impacto en otras reas de la organizacin, el
impacto en otras entidades dentro y fuera de la organizacin o los requisitos de
comunicacin y reporte de los interesados.
- Requisitos de solucin como las funcionales y no funcionales, los de cumplimiento
de estndares, los de soporte y formacin, los de calidad, los de reporte...
- Requisitos del proyecto como los niveles de servicio, desempeo, seguridad...

- Requisitos de transicin como capacidades temporales, migracin, puesta en

marcha...
- Restricciones, dependencias e hiptesis relativas a los requisitos.
Esta documentacin de requisitos se utilizar como entrada - los procesos de definir
el alcance y elaborar la EDT, - los de planificar la gestin de las compras (rea de
conocimiento de gestin de las adquisiciones), si parte del trabajo se decide
externalizar - y planificar la gestin de la calidad (rea de conocimiento de gestin
de la calidad).
Todos los requisitos recogidos con cualquiera de los mtodos anteriores -cada
project manager, en funcin de las caractersticas de la compaa y del proyecto,
elegir el o los ms apropiados- se deben documentar, siendo esta documentacin
una salida del proceso.
Este proceso y esta documentacin deben garantizar que los requisitos estn
claramente definidos y no son ambiguos.
Por ello, se debe preguntar al cliente qu va a hacerle decidir que el producto es
aceptable, cmo define que el producto sea un xito. Por una parte estaremos
seguros de que hemos entendido el requerimiento de la parte interesada y, por
otra, el project manager se asegura que el trabajo que haga ser aceptado. Un
ejemplo de este documento podra ser el siguiente:
Documento de Requisitos del Proyecto (Project requirements
document)
Antecedentes/Resumen del proyecto
Impacto en la Organizacin
Necesidad comercial
Objetivos de la empresa y el proyecto
Requerimientos Funcionales (Functional requirements)
Nombre
7896-S
Sntesis

Posibilidad de que jueguen hasta 4

jugadores

Justificacin

Es un juego con potencial para uso

familiar

Requerimiento

El juego debe permitir la seleccin del

nmero de jugadores as como el
hndicap de cada uno

Requerimientos NO funcionales (Non functional requierements)

Nombre

456-O Funcionamiento ms rpido

Sntesis

Se desea que la visualizacin grfica

sea mejor

Justificacin

Los usuarios se quejan de que el juego

va lento

Requerimiento

La velocidad de carga y descarga de

nuevas ventanas no debe tardar ms
de 2 segundos

Requerimientos de Calidad y Criterios de aceptacin (Acceptance

criteria)
Requisitos de recursos principales (Key resources)
Supuestos (assumptions) si no se cumplen son riesgos
Restricciones del proyecto (Restrictions)
Fases/Entregables (deliverables) del proyecto (lo que se entrega al
cliente y lo que el entrega a la compaa)
Hitos (milestones) principales
Tabla de inclusiones (lo que s incluye el proyecto) y exclusiones (lo
que no est incluido)
Otros aspectos como el impacto sobre otros proyectos, sobre otras
entidades, requisitos de apoyo y capacitacin
Otra forma de representarlos es mediante una tabla de requisitos con un esquema
como el siguiente:
Parte
Criterio de
Requisito Justificacin
Prioridad
Interesada
aceptacin
Matriz de trazabilidad de requisitos (Requirements traceability matrix)
Una de las cosas que no debe pasar nunca en un proyecto es que, durante la fase
de ejecucin y los sucesivos cambios que se puedan producir, se pierda algn
requerimiento o no se tenga la documentacin descriptiva que aclare sus razones y
alcance. La matriz de trazabilidad de requisitos trata de evitar este hecho siguiendo
la traza de toda esa informacin y analizando los requerimientos cuando hay
cambios en el alcance del producto o el proyecto.
La matriz de trazabilidad de requisitos relaciona cada requisito con su origen, la
parte interesada que lo solicit, su justificacin, el objetivo de negocio relacionado,
el paquete de trabajo asociado, el diseo del producto, el control de calidad... .
Entre los atributos que suelen incorporarse son un identificador nico, la descripcin
del requisito, el propietario, la prioridad, la versin, el estado (activo, cancelado,
aadido, aprobado...) y la fecha de cierre.
Esta matriz nos ayudar a asegurarnos de que cada requisito tiene un valor de
negocio identificado, que, en caso de tener que modificarlo, tenemos claro el origen
y razn de ser del mismo y podemos seguirlo a lo largo de la vida del proyecto para
que, al final, todos los requisitos aprobados, y solo los aprobados, estn
incorporados al producto o resultado. Esta matriz de trazabilidad se utilizar como
entrada para los procesos de controlar el alcance y validar el alcance.
Esta matriz suele ser una tabla con la siguiente informacin:
Un nmero de cdigo del requerimiento.
La descripcin del requisito.
El origen y la razn del mismo.
Quin es el responsable del mismo.
La prioridad.
El historial de cambios.
La versin vigente.
El estado actual.
La fecha prevista de cumplimiento.

Otro ejemplo sera el de la siguiente tabla:

Necesidad Objetivos
Diseo Actividad
Componente
Cdigo Requisito
de
de
de
de
de la EDT
Negocio
proyecto
Producto Calidad

Los aspectos que se puede trazar pueden ser relativos a las necesidades, los
objetivos y alcance del producto, diseo y desarrollo del producto y estrategias y
escenarios de prueba.
El project manager suele designar un responsable de este tema dentro del equipo.
3.3.4. DEFINIR EL ALCANCE
Una vez identificados los requisitos del producto, servicio o resultado y del
proyecto, este proceso tiene por objetivo elaborar una descripcin detallada del
producto y del proyecto y, muy especialmente, una clarificacin de sus lmites, lo
que estar incluido y lo que no.
Para ello, el project manager y su equipo deben evaluar las soluciones alternativas
posibles y proponer aquella que, cumpliendo con los requisitos de producto y
proyecto, cumple las restricciones establecidas al proyecto.
En este proceso se seleccionan -puede no ser posible incorporar todas- las
caractersticas/requisitos del proceso anterior y se elabora una descripcin detallada
del producto o resultado y del proyecto a ejecutar. La preparacin del Enunciado del
alcance del proyecto detallado es crtico para el xito del proyecto y se basa en los
entregables principales definidos, las restricciones y supuestos definidos y
documentados en la fase de inicio -recogidos en el Acta de Constitucin-.
Durante este proceso, por tanto, se define qu est y qu no est incluido en el
proyecto y sus entregables. Utiliza:
Las salidas del proceso Planificar la Gestin del Alcance.
Los requisitos recogidos.
El Acta de Constitucin.
Otra informacin que se haya ido aadiendo sobre hiptesis de partida y
limitaciones.
Con todo ello, se define finalmente el alcance del producto (product scope) y del
proyecto (project scope statement).
Como ocurre con otros aspectos, el alcance ser casi con toda probabilidad
cambiante a lo largo del proyecto, ya sea por:
la nueva introduccin de requisitos por parte del cliente,
por restricciones no previstas de personal,
por eventos de riesgo que se hacen realidad,
por cambios en las expectativas de los interesados, o
por otras razones.
Por ello, se producirn cambios en la triple restriccin tiempo, coste y alcance, que
afectar al resto de documentos del proyecto.
Por ello, el alcance se definir al inicio del proyecto o fase pero se revisar cada vez
que se produzca un evento, un cambio... que lo altere, manteniendo as un proceso
iterativo.

Este proceso es clave en el proyecto, como todos los que se tratan en este captulo
ya que condicionan todos los dems -duracin, costes, recursos...-. Si no se define
y gestiona bien el alcance, el producto final puede tener requisitos que ya no se
desean y, al contrario, no tener otros que a lo largo del proyecto han sido
solicitados y aprobados.
La ubicacin de este proceso dentro de su rea de conocimiento y en el grupo de
procesos general es el siguiente:

El
siguiente esquema muestra las entradas (inputs), tcnicas y herramientas
(techniques and tools) y salidas (outputs) del proceso concreto:

En ISO21500 se propone el proceso "Definir el alcance (Define scope)" cuyo

objetivo es definir claramente el alcance del proyecto, lo que incluye definir sus
objetivos, entregables, requisitos y lmites mediante la descripcin clara del
resultado final esperado.
El alcance debe dejar claro en qu manera contribuye el proyecto a los objetivos de
negocio y/o estratgicos de la organizacin que lo promueve. Se utilizar como
base para futuras decisiones as como para comunicar la importancia del proyecto y
sus beneficios a las diferentes partes intervinientes.
En la siguiente tabla se indican las entradas y salidas propuestas por ISO21500 (no
indica tcnicas ni herramientas):

Entradas

Salidas
Enunciado del
Acta de Constitucin
Alcance
Cambios aprobados
Requisitos
Observamos cmo aunque en ISO21500 no hay un proceso especfico como el de
"Recopilar requisitos" de PMBOK, estas actividades se realizan en este proceso de
"Definir el alcance", razn por la cual las dos salidas son definir el Enunciado del
Alcance (del proyecto) y los requisitos.

DEFINIR EL ALCANCE (DEFINE SCOPE):

Es el proceso en el que se elabora una descripcin detallada del proyecto y el
producto.
ENTRADAS (INPUTS):
Para definir el alcance se utilizan el Plan de Gestin del Alcance -que define cmo
definir el alcance del producto y servicio-, el Acta de Constitucin -que incluye una
descripcin general del producto y sus caractersticas y los criterios de aprobacin
del proyecto-, la documentacin de requisitos -resultado del proceso anterior y de
la que se seleccionan las caractersticas que se incluirn en el alcance del productoy polticas, procesos y plantillas predefinidas por la organizacin, ficheros de
proyectos anteriores similares y lecciones aprendidas de proyectos o fases previas.
Plan de Gestin del Alcance (Scope management plan)
Es precisamente el documento que indica cmo recoger los requisitos, cmo definir
el alcance y elaborar la EDT.
Acta de Constitucin del Proyecto (Project charter)
Como en otros casos, indicar las necesidades del negocio, quin es el patrocinador
o cliente, quienes son las partes interesadas y una descripcin general del proyecto.
Documentacin de requisitos (Requirements documentation)
Salida del proceso anterior, recoge todos los requisitos del producto final que
debemos tener en cuenta a la hora de definir el alcance y que, adems, han sido
consensuadas con todas las partes interesadas.
Activos de los procesos de la organizacin (Organizational process assets)
Donde se podrn encontrar -si existen en la organizacin- procedimientos,
instrucciones, plantillas, formularios..., para realizar la definicin del alcance con el
conocimiento corporativo de la compaa y adaptarlo a las particularidades del
proyecto.
TCNICAS Y HERRAMIENTAS (TECHNIQUES AND TOOLS):
El project manager, tomando como base la informacin anterior, se reunir con el
cliente, otras unidades de la organizacin, expertos en la materia..., analizar el
producto solicitado utilizando diferentes tcnicas -desglose del producto, el anlisis
de sistemas, el anlisis de requisitos, ingeniera de valor...- para traducir las
descripciones del producto a entregables tangibles, estudiar diferentes alternativas
de ejecutar el proyecto, u organizar talleres de trabajo transversales con el
objetivo final de definir adecuadamente el alcance del proyecto.
Juicios de expertos (Experts judgement)

Como en otros casos, un experto en el sector o tecnologa en la que se desarrolla el

proyecto puede ser de gran ayuda. Estos expertos podrn proceder de otras
unidades de la organizacin, consultores externos, partes interesadas, asociaciones
tcnicas y profesionales...
Anlisis del producto (Product analysis)
Esta herramienta tiene por objetivo analizar los objetivos y describir el producto tal
y como ha sido definido por el cliente, y traducirlo al trabajo que hay que hacer
durante el proyecto y entregas concretas que en conjunto formen el producto
requerido.
Incluye tcnicas como el desglose del producto, el anlisis de sus componentes, el
anlisis de los requisitos, la ingeniera de sistemas, la ingeniera de valor (value
engineering) y el anlisis del valor (added value analysis).
Generacin de alternativas (Alternatives generation)
Lo que busca esta herramienta son diferentes maneras de realizar el mismo trabajo
que puedan llegar a ser ms eficientes. Pueden referirse a una tarea concreta o a
un rea de trabajo: podemos programar un mdulo de programacin, modificar uno
existente para el uso concreto actual o contratar un software especfico.
Se podrn utilizar tcnicas como la tormenta de ideas (brainstorming), el
pensamiento lateral (lateral thinking)... que permitan generar diferentes soluciones
para afrontar el problema.
Talleres facilitadores (Facilitated workshops)
Al llevar a cabo estos talleres con las partes interesadas, se trata de que el alcance
finalmente recogido y definido incluya sus necesidades, requerimientos y
expectativas, identificndolas y documentndolas para traducirlas en trabajos
concretos que el equipo de proyecto va a tener que realizar para entregar el
producto o servicio solicitado.
Durante este trabajo ser clave, aunque difcil, incluir en el alcance objetivos
cuantificables, medibles, que hagan ms fcil ver si se han cumplido o no, si el
producto est correcto o no -sobre todo en lo que se refiere a las expectativas,
menos precisas, de las partes interesadas-.
SALIDAS (OUTPUTS):
Se obtiene el Enunciado del alcance del proyecto.
Enunciado del alcance del proyecto (Project Scope Statement)
Es el principal resultado de este proceso. Es la descripcin del alcance del proyecto,
explicitando lo que est incluido y excluido, los principales entregables y el trabajo
necesario para completarlos, los criterios de aceptacin que deben cumplir, los
supuestos -y el impacto de que no se cumplan-y las restricciones -internas y
externas- del proyecto.
Se centra en qu es lo que realmente se va a hacer en el proyecto y, adems, en
qu va a ser revisado y aprobado por el cliente, partes interesadas y, en ocasiones,
expertos externos a la organizacin.
Es muy importante definir bien el alcance y tenerlo claro ya que ser la base para la
planificacin ms detallada de los trabajos, guiar el trabajo del equipo durante su
ejecucin y ser la base para evaluar si las propuestas de cambio o trabajos
adicionales estn o no incluidos en el proyecto.
El Enunciado del alcance del proyecto ser una entrada para otros procesos como el
de Crear la estructura de desglose del trabajo, EDT, o los encaminados a elaborar el
cronograma del proyecto -del rea de conocimiento de gestin del tiempo-.

El project manager no deber aceptar nuevos alcances que no estn en este

documento por mucho que haya partes interesadas muy insistentes en incluir
elementos de su gusto. Por eso suele ser clave incluir una tabla de exclusiones e
inclusiones dejando claro qu est y qu no est incluido en el proyecto para evitar
estas situaciones.
Este documento, junto con la EDT (WBS) y el Diccionario de la EDT (WBS
Dictionary) forman la lnea de base inicial del alcance (scope baseline) que, a su
vez, forma parte del Plan de Direccin del Proyecto (Project Management Plan).
Este documento puede tener un contenido y organizacin como la de la siguiente
tabla:
Enunciado del alcance del proyecto (Project scope statement)

Objetivos del proyecto

(Project goals)

Todos los objetivos del proyecto

deben ser especficos, medibles,
acordados, realistas, y con un plazo.
Podrn tener que ver con el coste, el
plazo, objetivos tcnicos, de calidad
o de mercado.
Ej. El producto debe reducir el
nmero de quejas en un 5% desde
su puesta en marcha.

Es una breve descripcin del alcance

del producto que facilite la
planificacin de los trabajadores
necesarios. El producto por su parte
Descripcin del alcance del producto
podr ir definindose con ms detalle
(Product scope statement)
conforme avance el proyecto.
Ej. Construir un prototipo de coche
urbano con motor elctrico y con una
autonoma de 3 horas.

Enunciado del alcance del proyecto (Project scope statement)

Requerimientos del proyecto

(Project requirements)

Describir las condiciones o

capacidades que deben cumplir los
entregables para satisfacer el
contrato o estndares impuestos.
Aunque no se puedan indicar todos
aqu se har referencia a
documentos adicionales.
Ej. El programa debe poder utilizarse
en un Pc con 1 GB de memoria o
menos en un plazo de tres meses y
presentando una prueba beta al mes.

Inclusiones y exclusiones del

proyecto
(Project inclusions and exclusions)

Indicar bien claro todo el trabajo que

no est incluido y no se va a hacer.
Ej. El diseo de interiores no est
recogido en la oferta arquitectnica.

Entregables del proyecto

(Project deliverables)

Es todo lo que el proyecto crear

incluidos el producto y los
documentos relativos al proyecto.
Ej. Maqueta escala 1:100 de la
propuesta de urbanizacin.

Criterios de aceptacin del producto

(Acceptance criteria)

Definen los procesos y criterios de

aceptacin del producto. Aunque no
se puedan indicar todos aqu se har
referencia a documentos adicionales.
Ej. El tiempo de arranque del juego
de ordenador debe ser inferior a 2
segundos con una probabilidad de
que el Pc se quede colgado del
0,001.

Enunciado del alcance del proyecto (Project scope statement)

Restricciones del proyecto

Las restricciones sern factores

externos al equipo de proyecto sobre
los que no tienen poder de influir
(limitaciones en plazo, presupuesto,
legislacin sectorial). Son
limitaciones conocidas asociadas o
relacionadas con el alcance que
limitan las opciones del equipo de
proyecto.
Son entradas muy importantes en el
proceso de gestin del proyecto.
Adems, como ocurre con el alcance,
son variables a lo largo del proyecto
por lo que una vez definidas
inicialmente, habr que gestionarlas,
seguir su validez y actualizarlas si
procede.
Ej. Solamente se podr utilizar un
tcnico senior a tiempo parcial y uno
junior a tiempo completo.

Enunciado del alcance del proyecto (Project scope statement)

Hiptesis del proyecto

Son datos o aspectos que, al

desconocerse los datos reales, el
equipo supone que son verdaderos o
que su valor va a estar en un rango
definido. Es importante tener en
cuenta que detrs de cada hiptesis,
hay un riesgo que la hiptesis no
sea cierta.
Como ocurra con las restricciones,
pueden variar a lo largo del proyecto
por lo que una vez definidas
inicialmente, habr que gestionarlas,
seguir su validez y actualizarlas si
procede.
Ej. Suponemos que la nueva
plataforma de programacin nos ser
entregada la primera semana de
junio.

Organizacin inicial del proyecto

Miembros del equipo, partes

interesadas y organizacin del
proyecto.

Riesgos inicialmente previstos

Riesgos conocidos por la experiencia

de proyectos similares.

Requisitos de aprobacin

Identifica los requisitos de

aprobacin tanto para los objetivos
del proyecto, como para los
entregables o la documentacin del
proyecto.

Tener la informacin as documentada y ordenada facilitar la labor de planificar el

trabajo a ejecutar de acuerdo a lo establecido. Tambin facilitar su supervisin y
control a partir de una lnea base del alcance (scope baseline) clara que indique los
lmites del proyecto.
El Enunciado del alcance del proyecto ser entrada para los procesos de:
- crear la EDT (rea de conocimiento de gestin del alcance),
- secuenciar actividades (rea de conocimiento de gestin del tiempo),

- estimar duracin de actividades (rea de conocimiento de gestin del tiempo),

- desarrollar el cronograma (rea de conocimiento de gestin del tiempo).
Actualizaciones a los documentos del proyecto (Project documents
updates)
Al elaborar el Enunciado del alcance del proyecto, pueden surgir cambios, nuevas
ideas, nuevas partes interesadas, con nuevos requisitos. Por ello, como resultado
de este proceso, se podrn actualizar el Plan de Gestin del Alcance (scope
management plan) por la inclusin de solicitudes de cambio aprobadas (approved
change requests), as como el registro de interesados (stakeholders register), la
documentacin de requisitos (requierements documents) o la matriz de trazabilidad
de requisitos (requirements traceability matrix).
3.3.5. CREAR LA ESTRUCTURA DE DESGLOSE DEL TRABAJO (EDT)
Definido el alcance, se inicia el proceso de creacin de la EDT, que es uno de los
ms importantes del rea de gestin del alcance del proyecto porque es donde
realmente se refleja todo el trabajo que va a haber que hacer (aunque est
orientada a entregables, debe incluir el alcance del producto, el alcance del
proyecto y las propias tareas administrativas y de gestin del proyecto).
Los resultados de los procesos de recopilar datos (collect requirements) y de definir
del alcance (define scope) son entradas (inputs) a su vez del proceso de crear la
EDT (Create WBS).
Mediante este proceso se subdividen el proyecto y sus entregables principales en
componentes ms pequeos y manejables. El resultado es la EDT, descomposicin
jerrquica del alcance total del trabajo a realizar para cumplir con los objetivos del
proyecto y completar los entregables requeridos. La EDT ayuda a tener una visin
estructurada de los trabajos que hay que abordar. El trabajo total ser la suma de
los trabajos que contienen y describen los componentes de menor nivel de la EDT,
los paquetes de trabajo, que deben permitir estimar su duracin y coste,
monitorizar su avance y verificar el cumplimiento de sus criterios de aceptacin.
La EDT debe incluir todo lo que cualquier persona del proyecto vaya a hacer. Lo que
no est, no se har.
La ubicacin de este proceso dentro de su rea de conocimiento y el grupo de
procesos es el siguiente:

detalle del mismo se refleja en este esquema:

Y
el

En ISO21500 existe tambin un proceso similar denominado "Crear la Estructura de

Desglose del Trabajo (Create work breakdown structure)" cuyo objetivo es facilitar
una descomposicin jerrquica de los trabajos que deben ser completados para
alcanzar los objetivos del proyecto.
De acuerdo a ISO21500 la EDT facilita un marco para subdividir el trabajo del
proyecto en partes ms pequeas y manejables que pueden ser estructuradas
siguiendo las fases de un proyecto, los principales entregables u otro criterio que se
considere vlido y adecuado.
En la siguiente tabla se indican las entradas y salidas propuestas por ISO21500 (no
indica tcnicas ni herramientas):
Entradas
Salidas
Planes de proyecto
Requisitos
Cambios aprobados

Estructura de desglose del

trabajo, EDT
Diccionario de la EDT

Observamos cmo no aparece como entrada el Enunciado del alcance del proyecto,
salida del proceso "Definir el Proyecto" cosa que s sucede en PMBOK.

CREAR LA ESTRUCTURA DE DESGLOSE DEL TRABAJO, EDT (CREATE WORK

BREAKDOWN STRUCTURE, WBS)
Es el proceso que consiste en subdividir los entregables (deliverables) y el trabajo
del proyecto en componentes ms pequeos y ms fciles de manejar: los
paquetes de trabajo (work packages).
ENTRADAS (INPUTS):
Para elaborar la EDT se necesitan el Plan de Gestin del Alcance -que especifica
quin, cmo, con qu detalle..., se elabora, aprueba y actualiza la EDT-, el
Enunciado del alcance del proyecto -resultante del proceso anterior y que describe
los trabajos necesarios y lo que est excluido-, la documentacin de requisitos necesaria para saber cul es el resultado final esperado-, los procesos, plantillas de
EDT de la organizacin, archivos de proyectos anteriores y lecciones aprendidas.
El Plan de Gestin del Alcance (scope management plan)
Este documento especifica, entre otras cosas, quien, cmo, con qu detalle... se
elabora, aprueba y actualiza la EDT.
Enunciado del alcance del proyecto (Project scope statement)
Describe en detalle los entregables (deliverables) del proyecto y sus caractersticas
y proporciona un entendimiento comn del alcance del producto (product scope)
entre todos los interesados.
Documentacin de requisitos (Requirements documents)
Caractersticas y requerimientos que el producto o servicio deben cumplir para
satisfacer las necesidades y expectativas del cliente, definidas en el proceso de
Recopilar requisitos.
Factores ambientales de la empresa (Entreprise environmental factors)
Se considerarn como factores ambientales de la empresa las EDTs que posea la
organizacin, EDTs estndar de la industria o de los clientes, por ejemplo.
Activos de los procesos de organizacin (Organization process assets)
Se utilizarn los procedimientos, instrucciones y plantillas establecidas por la
organizacin como mejores prcticas para elaborar la EDT.
TCNICAS Y HERRAMIENTAS (TECHNIQUES AND TOOLS):
Con la informacin anterior, el project manager y su equipo proceden a
descomponer el alcance del proyecto y sus entregables en partes ms pequeas y
manejables. Para ello, identifican y analizan los entregables principales, estructuran
y organizan la EDT -por fases del proyecto, por partes del proyecto...-,
descomponen los niveles superiores de la EDT en componentes de menor nivel ms
detallados y pequeos, asignan cdigos a cada paquete de trabajo y verifican que la
suma de los trabajos contenidos en los paquetes de trabajo de menor nivel es igual
al alcance total del proyecto.
Descomposicin (Decomposition)
Crear la EDT tiene que ver con identificar los entregables principales e ir
desgranndolos hasta llegar a los paquetes de trabajo, lo que se denomina
descomposicin, que es la principal herramienta para elaborar la EDT. De esta
manera, cada entregable se divide en paquetes de trabajo ms manejables, de
menor duracin pero que sean verificables.
El nmero de niveles de descomposicin ser tal que permita una buena
planificacin, gestin y control del trabajo sin llegar a ser tan detallada que

aumente innecesariamente las tareas administrativas y no productivas de gestin.

En concreto el paquete de trabajo del ltimo nivel debe ser tal que:
pueda ser estimado (su coste y tiempo) de forma rpida y precisa,
no sean trabajos de larga duracin,
que se pueden realizar sin interrupcin ya que toda la informacin est disponible,
que pueda asignarse a una persona o grupo de personas especfica (o
subcontratarlo completo).
Los pasos a dar son:
1. Obtener las entradas para elaborar la EDT:
a. La documentacin de requisitos y su matriz de trazabilidad.
b. El Enunciado del alcance del proyecto.
c. Plantillas y procesos de la organizacin.

2. Definir el equipo que elaborar la EDT:

a. El responsable de proyecto y el equipo de direccin de proyecto.
b. El responsable de proyecto y personas asignadas al proyecto.

3. Analizar los trabajos necesarios para cumplir con objetivos del proyecto.
4. Seleccin, si procede, de la Plantilla de la EDT de un Proyecto similar.
5. Decidir cmo se va a estructurar y organizar el trabajo (subproyectos, fases,
reas funcionales).
6. Determinar el tipo de presentacin (estructura rbol, tabla, ndice...).
7. Aplicar la tcnica de descomposicin hasta el nivel que permita una adecuada
gestin. Para ello, el responsable del proyecto y el equipo de proyecto deben
preguntarse si:
a. Dado el nivel de descomposicin se puede asignar el trabajo a una

persona.
b. Ser capaz el equipo de estimar adecuadamente su coste y duracin.
c. Ser capaz el equipo de identificar las actividades necesarias para

ejecutarlo.

d. Ser el responsable de proyecto capaz de monitorizar y controlar su

avance.
e. Se puede ejecutar en mx. 2 semanas, tiempo entre 2 reuniones de

seguimiento.
8. Aplicar la regla del 100% para verificar si todo el trabajo y solo el trabajo
necesario est incluido en la EDT (y que no hay trabajos redundantes).
9. Asignar el Cdigo a cada componente de la EDT.
10. Definir el nivel de Cuentas de Control en el que se consoliden los resultados de
gestin.
11. Obtener inputs de otras partes interesadas relevantes.
12. Crear y cumplimentar los 7 primeros apartados del Diccionario de la EDT.
13. Obtener la aprobacin interna de la EDT.
PMBOK denomina "hammocks" a las tareas que se dejan a un nivel muy general
por ser demasiado pronto o no disponer de suficiente informacin sobre ellas.
Para obtener una buena EDT se debe:

 Realizar con la colaboracin del equipo de proyecto (no debe hacerla el project
manager por su cuenta).
Completar el nivel superior -que contendr todo el alcance del proyecto- antes de
pasar al siguiente.
Cada nivel inferior constar de paquetes de trabajo ms pequeos.
Incluir todo el trabajo que hay que hacer y no incluir nada que no sea realmente
necesario.
Juicio de expertos (Expert judgement)
Se utilizar el juicio de expertos para analizar la informacin de partida necesaria
para elaborar la EDT, para establecer criterios de descomposicin, definir el nivel de
destalle final de los paquetes de trabajo...
SALIDAS (OUTPUTS):
El resultado ser la lnea de base del alcance que incluye el Enunciado del Alcance del proceso anterior-, la EDT y el diccionario de la EDT, compuesto ste por fichas
para cada paquete de trabajo en las que se recoge: el cdigo, la descripcin del
trabajo, los supuestos y restricciones a la hora de ejecutar ese paquete de trabajo,
la persona o departamento responsable, la lista de hitos del cronograma asociados
a ese paquete, las actividades o paquetes relacionados, los recursos requeridos, las
estimaciones de coste, los requisitos de calidad y criterios de aceptacin del
paquete de trabajo, las referencias tcnicas y las referencias al contrato.
La lnea de base del alcance, resultado de este proceso, se utilizar como entrada
para los procesos de controlar y validar el alcance, estimar costes y elaborar el
presupuesto -rea de conocimiento de gestin de costes- e identificar riesgos y
evaluarlos cualitativamente -rea de gestin de riesgos-.
La lnea de base del alcance (scope baseline)
Conforme avance el proyecto, el project manager querr comparar el avance real y
su alcance con el inicialmente establecido. Por otra parte, cuando haya que aadir
nuevas funcionalidades que den lugar a nuevos entregables y paquetes de trabajo,
el project manager debe cambiar la lnea de base para incluir esos nuevos trabajos,
guardando a lo largo del proyecto las diferentes lneas de base incluida la inicial.
La lnea de base del alcance est compuesta por:
El Enunciado del Alcance del producto (product scope statement).
La EDT (WBS).
Su diccionario (WBS Dictionary).
Ser el elemento con el que se comparar el avance del proyecto y su grado de
cumplimiento en las fases de seguimiento y control y permitir decidir si la
actividad concreta est acabada. Esta lnea base del alcance (scope baseline)
formar parte del Plan de Direccin del Proyecto.
La Lnea de Base del Alcance ser entrada para los procesos de:
Validar el Alcance.
Elaborar el plan de Direccin del Proyecto.
Definir las actividades.
Estimar los costes.
Determinar el presupuesto.
Identificar riesgos.
Realizar el Anlisis Cualitativo de Riesgos.

Estructura de desglose de tareas, EDT (Work Breakdown Structure, WBS).

Una EDT no es una lista de tareas. Una EDT es mucho ms que una lista de tareas.
Son varias las diferencias entre ellas:
La EDT incluye -y est definida y orientada a- entregables.
Una lista no permite hacer un desglose de cada actividad en tareas ms pequeas
y manejables.
Una lista no da una imagen general del trabajo total, ni de cmo un paquete de
trabajo se relaciona con el total.
La EDT obliga al equipo a pensar sobre el proyecto, a revisar relaciones, partes que
faltan y el producto final es mucho ms completo y til y es mejor comprendido,
asumido por el equipo participante y ms realista.
Frente a un diagrama de red -que se tratar en la planificacin del tiempo- no
muestra precedencias entre tareas ya que no indica qu tarea se hace antes que
otra -si es necesario acabar una para empezar otra-.
A cada paquete de trabajo (work package) se le asocia un cdigo de identificacin
que indique el paquete de trabajo, el nivel de la EDT en el que est y facilite su
bsqueda en el diccionario de la EDT.
La estructura de la EDT se puede hacer:
Utilizando las fases del ciclo de vida del proyecto como primer nivel de
descomposicin y los entregables en segundo nivel.
O usando los entregables como primer nivel o utilizando subproyectos que pueden
ser ejecutados por proveedores.
Ejemplos seran los tres siguientes -la ejecucin de un chalet, una planta
depuradora o la apertura de una cadena de tiendas franquiciadas-, si bien en cada
caso y debido a la diferente complejidad del proyecto, cabra hacer desgloses ms
detallados:

En la elaboracin de la EDT, como en la recopilacin de requisitos, se puede

abordar una elaboracin gradual (Progressive elaboration), ms detallada en los
paquetes de trabajo ms definidos y menos detallada en los que estn por venir.
Algunos aspectos muy importantes a no olvidar en relacin a la EDT (WBS):
Los entregables (deliverables) o actividades (activities) que aparece en la EDT
aprobada son los realmente necesarios y los que se abordarn en el proyecto. Los
que no aparecen, no forman parte del proyecto.
Los paquetes de trabajo, elemento de inferior nivel deben incluir entregables:
- cuyo trabajo y duracin se puede estimar de forma realista y confiable,
- se pueden completar en un plazo corto, que puede ser el espacio entre dos

reuniones semanales de seguimiento del equipo,

- del que se dispone de toda la informacin por lo que se puede ejecutar sin

interrupcin,
- e, incluso, puede subcontratarse al estar perfectamente acotado y

definido.
Deben estar codificados para que el cdigo identifique unvocamente cada
componente e identifique el nivel de descomposicin al que se puede encontrar el
componente.
Entre los muchos beneficios de la EDT se destacan que:
Evita dejarse tareas importantes.
Da una idea general de dnde est cada pieza dentro del cuadro general y esto da
a su responsable una mayor capacidad de realizarlo mejor.

 El equipo se centra en lo que realmente hay que hacer.

Es la base para estimar costes, duraciones, riesgos, recursos necesarios...
Si ha participado el equipo ste lo hace suyo y su motivacin aumenta.
Facilita la comunicacin y cooperacin con los interesados.
Es, en definitiva, la base del proyecto a la que referirse prcticamente en todos los
procesos que se describan en los prximos captulos. Un project manager
profesional no puede comenzar un proyecto sin tener una EDT (WBS) elaborada con
su equipo, con entradas de las partes interesadas y que cumpla con los
requerimientos del producto y el proyecto.
Por ltimo, durante la fase de ejecucin el EDT se utilizar:
para valorar cambios en el alcance propuestos o necesarios,
para identificar el impacto que los cambios propuestos tengan sobre el proyecto,
como una herramienta de comunicacin, y
como una ayuda para que cada miembro del equipo comprenda sus tareas, sus
funciones y su interrelacin con la de otros.
Diccionario de la EDT (WBS Dictionary)
Como se ha podido observar en los ejemplos, la EDT da descripciones cortas de una
o dos palabras de las actividades a realizar pero no deja claro cul es el trabajo
realmente incluido en ella. Por ello se debe definir, como complemento a la EDT, un
Diccionario de la EDT.
ste contendr una descripcin del trabajo que asegure que el responsable de
ejecutarlo sepa lo que tiene que hacer, los pasos que debe dar y su alcance
concreto, las relaciones con otras tareas, la fecha de inicio, los hitos... Por todo ello
este diccionario puede utilizarse como parte del sistema de autorizacin del inicio
de los trabajos.
Las entradas de un diccionario de la EDT puede tener un esquema similar al que se
presenta en la tabla siguiente:
Testado del prototipo por parte del cliente
Fecha de actualizacin

12/07/2010

Identificador y nombre

3.1 Prueba del prototipo por cliente

Testado del prototipo por parte del cliente

Descripcin del Trabajo

El objeto de esta prueba es que el

cliente vea una prueba beta del
modelo que le permita probarlo y ver
si las funcionalidades implantadas
son correctas, son excesivas o
conviene complementarlas.

Responsable

Equipo de prototipado con el cliente

Entregables (deliverables)

Informe preliminar
Informe definitivo
Maqueta

Hitos (milestones)

4-abril: entrega al cliente y

formacin por equipo
10-abril: visita al cliente y entrevista
para anotar opiniones, sugerencias,
problemas
20-abril: ajuste y aprobacin final
por el cliente

El prototipo debe cumplir los

requerimientos establecidos por el
Requerimientos de calidad y aceptacin
cliente y recogidos en el documento
de requisitos.

Duracin

7 meses

Fecha de entrega

12/02/2011

Cdigo de proyecto

RRTT-2010

Testado del prototipo por parte del cliente

Recursos necesarios y coste estimado

Formacin al equipo (tcnico junior):

1.000 euros
Entrevista con cliente (tcnico snior
y junior): 3.000 euros
Ajuste final y aprobacin (2 tcnicos
junior): 2.000 euros

Interdependencias con otros proyectos

No

Aprobado por

Project manager

Actualizaciones a los documentos del proyecto (Project documents

updates)
Los cambios que hemos detectado y que hemos recogido en el alcance del producto
actualizado afectarn a otros documentos como el cronograma, el presupuesto...,
que debern ser actualizados para mantener un Plan de Gestin del Proyecto
coherente.
Si durante el proceso de crear la EDT se produce una peticin de cambio que es
aprobada ser necesario actualizar el Enunciado del alcance del proyecto (project
scope statement), la EDT (WBS) y su Diccionario (WBS Dictionary).

3.4. PLAN (PRELIMINAR) DE RECURSOS HUMANOS Y ADQUISICIONES

3.4.1. PLAN (PRELIMINAR) DE RECURSOS HUMANOS
Comentamos al hablar de los grupos de procesos de inicio que ISO21500 propone
un tercer proceso llamado "Establecer el equipo de proyecto". PMBOK no lo tiene
expresamente pero parece lgico pensar que, para proceder a elaborar el Plan de
Direccin, sea necesario que el project manager presente el proyecto a los
departamentos implicados y que stos asignen personas que ayuden al project
manager a planificar el proyecto.
Tambin es cierto que, aunque no aparezcan como tal en PMBOK, el project
manager debe tener una primera idea de qu recursos va a disponer y qu
elementos de la EDT va a subcontratar para poder hacer estimaciones de costes y
plazos.

Por tanto, aunque el proceso "Planificar la Gestin de Recursos Humanos" se

cerrar una vez completado el proceso de "Estimar los recursos de cada actividad"
correspondiente al rea de conocimiento de gestin del tiempo, es bien cierto que,
una vez definida la lnea de base del alcance, se puede proceder a identificar y
documentar:
- los trabajos que se realizarn internamente,
- los trabajos que, en principio, se externalizarn.
De esta forma se podrn tambin definir de forma preliminar los roles y
responsabilidades del proyecto, las habilidades requeridas, las relaciones y flujos de
reporte.
Este planteamiento es coherente con el hecho de que, de acuerdo a la Gua del
PMBOK, el calendario de recursos (resource calendar) y la asignacin del personal
al proyecto (Project staff asigments) -que son resultado del proceso "Adquirir el
equipo de proyecto" cuya principal entrada es a su vez el Plan de Recursos
Humanos (human resources plan) del proceso "Planificar los recursos humanos
(plan human resources management)- sean entradas para la estimacin de las
duraciones de las actividades (estimate activity durations) y la elaboracin del
cronograma (develop schedule).
Para hacer un primer Plan de Recursos se tendr en cuenta el Plan de Direccin del
Proyecto -que define cmo se va a ejecutar el trabajo necesario para lograr los
objetivos del proyecto...-, la lnea de base del alcance, los factores ambientales de
la organizacin -cultura y estructura, recursos humanos disponibles, polticas de
recursos humanos vigentes...- y los activos de los procesos de la organizacin descripciones de roles existentes, plantillas de organigramas y matrices de
asignacin de responsabilidades, informacin histrica y lecciones aprendidas sobre
gestin de recursos humanos en proyectos anteriores...-.
Mediante el uso de herramientas como el organigrama y matrices de asignacin de
responsabilidades de la organizacin o descripciones de perfiles, autoridades,
competencias y responsabilidades, se elaborar un organigrama de proyecto, una
definicin de perfiles necesarios y, dependiendo de la complejidad del proyecto, una
matriz de asignacin de responsabilidades preliminar.
3.4.2. ADQUIRIR EL EQUIPO (PRELIMINAR) DE PROYECTO
Teniendo en cuenta el Plan de Direccin de Proyecto, la lnea de base del alcance y
el plan (provisional) de recursos humanos se realizarn:
- asignaciones provisionales de personal al proyecto -que se pueden reflejar en los
organigramas, matrices de asignacin de responsabilidades...-,
- y un calendario de recursos -perodos de tiempo en los que debern trabajar los
recursos en el proyecto-, que sern entradas para los procesos de estimar la
duracin de las actividades y elaborar el cronograma -rea de gestin del tiempo- y
definir los recursos necesarios para cada actividad y elaborar el presupuesto -del
rea de gestin de costes-.
Teniendo en cuenta este equipo preliminar se puede continuar y completar la
planificacin.
3.4.3. PLAN (PRELIMINAR) DE GESTIN DE LAS ADQUISICIONES
Las decisiones de adquisicin pueden realizarse:
- Directamente una vez definido el alcance del proyecto y el trabajo desglosado en
la correspondiente EDT.

- Tras el proceso de planificacin en el que se hayan analizado los recursos

disponibles, se haya realizado el anlisis de riesgos asociado a la ejecucin de los
diferentes componentes de la EDT...
Este planteamiento es compatible con el hecho de que de acuerdo a la gua de
PMBOK:
- Los documentos de compras -salidas del proceso de "Planificar la gestin de
compras"-, sean una entrada para el proceso de identificacin de riesgos.
- O los acuerdos o contratos -salidas del proceso "Efectuar las compras"- sean
entradas para el proceso de "Determinar el Presupuesto".
Es por ello, que a efectos de este manual, se considere que, como por otra parte
muestra la experiencia:
- Se puede realizar una primera valoracin de aquellos paquetes de trabajo que se
van a externalizar, realizando para ello un anlisis "hacer o comprar", contactando
si procede con proveedores a los que se les haya enviado una primera versin de
los documentos de proyecto.
- Se pueda cerrar la planificacin de la gestin de adquisiciones una vez cerrado el
proceso de identificacin de riesgos y previamente al cierre del Plan de Direccin de
Proyecto.