Taller de Proyectos de Sistemas e Informatica - A0465

UNIVERSIDAD CONTINENTAL VIRTUAL
MANUAL AUTOFORMATIVO
ASIGNATURA
TALLER DE PROYECTOS DE SISTEMAS E
INFORMTICA
Autor:
Ing. Pedro Segundo Castaeda Vargas
NDICE
INTRODUCCIN
DIAGRAMA DE PRESENTACIN DE LA ASIGNATURA
UNIDAD I: Introduccin a la Gestin de Proyectos
Diagrama de Presentacin de la Unidad I
Tema N1: Introduccin al PMBOK
1. Qu es un Proyecto?
2. Qu es la Direccin de Proyectos?
3. Relaciones entre Direccin de Portafolios, Direccin de Programas, Direccin de
Proyectos y Direccin Organizacional de Proyectos
4. Relacin entre Direccin de Proyectos, Gestin de las Operaciones y Estrategia
Organizacional
5. Valor del Negocio
6. Influencia de la Organizacin y Ciclo de Vida del Proyecto
Tema N2: Procesos de la Direccin de Proyectos
1. Interacciones Comunes entre los Procesos de la Direccin de Proyectos
2. Grupos de Procesos de la Direccin de Proyectos
3. Informacin del Proyecto
4. El Rol de las reas de Conocimiento
Lectura seleccionada N 1: Sistemas de Informacin Gerencial: Motorola re-
curre a la Administracin de Cartera de Proyectos
Actividad formativa N1
Tema N3: Introduccin a las Metodologas giles
1. Generalidades
2. Manifiesto gil
3. Principios giles
4. Declaracin de Interdependencia
Tema N4: Fundamentos de SCRUM
1. Visin General de SCRUM
2. Teora de SCRUM
3. El Equipo SCRUM (Scrum Team)
4. Eventos de SCRUM
5. Artefactos de SCRUM
6. Transparencia de los Artefactos
Lectura seleccionada N 2: Sistemas de Informacin Gerencial: DST Systems
gana con SCRUM y la Administracin del ciclo de vida de las aplicaciones.
Glosario de unidad
Bibliografa de la Unidad I
Autoevaluacin No. 01
2
UNIDAD II: Iniciacin del Proyecto
Diagrama de Presentacin de la Unidad II
Tema N1: Seleccin de Proyectos
1. Estructura gerencial para los proyectos de sistemas de informacin
2. Vinculacin de proyectos de sistemas con el plan de negocios
3. Factores crticos de xito
4. Anlisis de cartera
5. Modelos de puntuacin
Lectura seleccionada N 1: Agencia para el voluntariado y la participacin
social Manuales de Gestin: Cmo hacer proyectos
Tema N2: Acta de Constitucin del Proyecto
1. Desarrollo del Acta de Constitucin del Proyecto: Entradas
2. Desarrollo del Acta de Constitucin del Proyecto: Herramientas y Tcnicas
3. Desarrollo del Acta de Constitucin del Proyecto: Salidas
Lectura seleccionada N 2: Gua de los Fundamentos para la Direccin de
Proyectos (Gua del PMBOK): Desarrollar el Acta de Constitucin del Pro-
yecto.
Glosario de Unidad
Bibliografa de la Unidad II
UNIDAD III: Planificacin del Proyecto

Diagrama de Presentacin de la Unidad III
Tema N1: Gestin del Alcance del Proyecto
1. Planificar la Gestin del Alcance
2. Recopilar Requisitos
3. Definir el Alcance
4. Crear la EDT/WBS
5. Definicin de la Pila de Producto
5.1. Definicin del Tamao del Sprint
5.2. Elaboracin de la Pila de Producto
5.3. Elaboracin de Historias de Usuario
5.4. Priorizacin de la Pila de Producto
Tema N2: Gestin de Tiempo y Costes del Proyecto
1. Planificar la Gestin del Cronograma
2. Definir las Actividades
3. Secuenciar las Actividades
4. Estimar los Recursos de las Actividades
5. Estimar la Duracin de las Actividades
6. Desarrollar el Cronograma
7. Planificar la Gestin de los Costos
8. Estimar los Costos
9. Determinar el Presupuesto
Proyectos (Gua del PMBOK): Crear la EDT/WBS
Tema N3: Gestin de la Calidad, Recursos Humanos y Comunicaciones del
Proyecto
3
1. Planificar la Gestin de la Calidad
2. Planificar la Gestin de los Recursos Humanos
3. Planificar la Gestin de las Comunicaciones
Tema N4: Gestin de Riesgos del Proyecto

1. Planificar la Gestin de los Riesgos
2. Identificar los Riesgos
3. Realizar el Anlisis Cualitativo de Riesgos
4. Realizar el Anlisis Cuantitativo de Riesgos
5. Planificar la Respuesta a los Riesgos
Lectura seleccionada N 2: Instituto Nacional de Tecnologas de la Comuni-
cacin: Gua Prctica de Gestin de Riesgos
Glosario de unidad
Bibliografa de la Unidad III
UNIDAD IV: Planificacin y Cierre del Proyecto

Diagrama de Presentacin de la Unidad IV
Tema N1: Gestin de las Adquisiciones del Proyecto
1. Planificar la Gestin de las Adquisiciones
Tema N 2: Gestin de los Interesados del Proyecto

1. Planificar la Gestin de los Interesados
Tema N3: Plan de Direccin de Proyectos
1. Integracin de planes subsidiarios
2. Desarrollo del Plan de Direccin de Proyectos: Entradas
3. Desarrollo del Plan de Direccin de Proyectos: Herramientas y Tcnicas
4. Desarrollo del Plan de Direccin de Proyectos: Salidas
Tema N4: Activos de la Organizacin

1. Lecciones Aprendidas del Proyecto
2. Memoria Final del Proyecto
Proyectos (Gua del PMBOK): Desarrollar el Plan para la Direccin del Pro-
yecto
Glosario de unidad
Bibliografa de la Unidad IV
4
INTRODUCCIN
En la actualidad las empresas se enfrentan a mercados globalizados, lo que las ex-

pone a un alto nivel de competencia y exigencia de los clientes en relacin a los
tiempos de entrega, costos y calidad. Para afrontar estos desafos de manera efectiva
y eficiente, es importante ser metdicos y rigurosos a la hora de gestionar los pro-
yectos si se quiere lograr el xito, afirma el director de la firma Projects, Martn Ro-
driguez.
El Project Management Institute (PMI) (www.pmi.org), en su gua A Guide to the
Project Management Body of Knowledge (PMBOK Guide) define a un proyecto como
un esfuerzo temporal que se lleva a cabo para crear un producto, servicio o resultado
nico. El PMI tambin define la Gestin de Proyectos como la aplicacin de cono-
cimientos, habilidades, herramientas y tcnicas a las actividades de un proyecto para
satisfacer los requisitos del proyecto. La gestin de proyectos se logra mediante la
aplicacin e integracin de los procesos de gestin de proyectos de inicio, planifica-
cin, ejecucin, seguimiento y control, y cierre.
En este manual se presenta una serie de tcnicas y herramientas para la gestin de
proyectos que permitirn que las organizaciones sean ms eficientes y eficaces en la
ejecucin de los mismos, de tal manera que puedan cumplir con los objetivos orga-
nizacionales. Asimismo, se toma como referencia el PMBOK que expone las mejores
prcticas para la gestin de los proyectos en la organizacin.
Este material te acompaar durante el desarrollo del Mdulo I de esta modalidad de
educacin virtual, convirtindose en el material didctico ms importante para el en-
tendimiento del curso, lo cual se ver reflejado en las autoevaluaciones que se apli-
quen al trmino del mismo, por lo cual te sugiero algunas recomendaciones:
Realizar el estudio de los contenidos, de manera analtica y reflexiva, realizando
resmenes que te permitan asimilar la informacin.
Estudiar las lecturas seleccionadas, que te facilitarn la comprensin de la teora
desarrollada a travs del mdulo.
Desarrollar la autoevaluacin, que es una preparacin para la prueba final de la
asignatura.
Desarrollar las actividades programadas para cada semana en el aula virtual.
Recuerda que cuentas con mi apoyo a lo largo de todo el curso, a fin de darte mayor
detalle y hacer ms fcil el camino a esta nueva experiencia.
Mg. Pedro S. Castaeda Vargas
5
PRESENTACIN
DE LA ASIGNATURA
COMPETENCIA DE LA ASIGNATURA:
Aplica buenas prcticas de la gestin de proyectos, empleando herramientas y

tcnicas para la iniciacin, planificacin, seguimiento, control y cierre del proyecto,
con base en principios y buenas prcticas propuestos por el PMBOK de acuerdo
con las necesidades y expectativas del negocio hacia el que est dirigido, poniendo
nfasis en la fase de planificacin de un proyecto de desarrollo de software.
UNIDADES DIDCTICAS:
UNIDAD I UNIDAD II Unidad III Unidad IV

Introduccin a Iniciacin del Planificacin del Planificacin y
la Gestin de Proyecto Proyecto Cierre del Pro-
Proyectos yecto
TIEMPO MNIMO DE ESTUDIO:
UNIDAD I UNIDAD II UNIDAD III UNIDAD IV
1era. Semana y 3era. Semana y 5ta. Semana y 7ma. Semana y

2da. Semana 4ta. Semana 6ta. Semana 8va. Semana
16 horas 16 horas 16 horas 16 horas
6
UNIDAD I: INTRODUCCIN A LA GESTIN DE PROYECTOS
DIAGRAMA DE PRESENTACIN DE LA UNIDAD I
ORGANIZACIN DE LOS APRENDIZAJES
CONOCIMIENTOS PROCEDIMIENTOS ACTITUDES
Video de presentacin de la 1. Identifica y reconoce los

asignatura. fundamentos y concep-
tos generales de la Di- 1. Reconoce y describe la
Unidad I: Introduccin a la reccin de Proyectos. importancia de imple-
Gestin de Proyectos. mentar una metodolo-
1 Videoclase (Video confe- 2. Describe y sintetiza los ga de gestin de pro-
rencia). Procesos de la Direccin yectos en la empresa.
Tema N 1: Introduccin al de Proyectos de
PMBOK. acuerdo al PMBOK. 2. Reconoce y describe la
1. Qu es un Proyecto? importancia de la ges-
2. Qu es la Direccin de Pro- Actividad N 1 tin de proyectos para
yectos? Elabora un listado de las una implementacin
3. Relaciones entre Direccin de causas ms comunes de exitosa que conlleve al
Portafolios, Direccin de Pro- fracaso en los proyectos y mejoramiento de una
gramas, Direccin de Proyec- categoriza cada uno de empresa y para las ac-
tos y Direccin Organizacio- ellos. tividades o procesos a
nal de Proyectos. realizar.
4. Relacin entre Direccin de 3. Interpreta los funda-
Proyectos, Gestin de las mentos y conceptos ge- 3. Fomenta el trabajo en
Operaciones y Estrategia Or- nerales de las Metodo- equipo aplicando tc-
ganizacional. logas giles. nicas y herramientas
5. Valor del Negocio. de gestin de proyec-
6. Influencia de la Organizacin 4. Comprende los Proce- tos para una consecu-
y Ciclo de Vida del Proyecto. sos de la Direccin de cin de los objetivos
Proyectos de acuerdo a organizacionales.
Tema N 2: Procesos de la Di- lo descrito en SCRUM.
reccin de Proyectos 4. Acta con tica y ba-
sado en valores.
Control de Lectura N 1
7
1. Interacciones Comunes entre Evaluacin escrita de los si-
los Procesos de la Direccin guientes puntos:
de Proyectos. Fundamentos tericos
2. Grupos de Procesos de la Di- desarrollados en las se-
reccin de Proyectos. manas N 1 y 2.
3. Informacin del Proyecto. Lecturas seleccionadas N
4. El Rol de las reas de Conoci- 1 y 2.
miento.
5.
Lectura seleccionada 1
Sistemas de Informacin Geren-
cial: Motorola recurre a la Admi-
nistracin de Cartera de Proyec-
tos. LAUDON, K.C. & LAUDON,
J.P., (2012), pginas 550 551.
2 Videoclase
UZILITY. (2014). Introduction to
Scrum 7 Minutes. Recuperado 5. Desarrolla liderazgo,
de capacidad de negocia-
https://www.youtube.com/watc cin y trabajo en
h?v=9TycLR0TqFA equipo que permita es-
tablecer un trabajo ali-
Tema N 3: Introduccin a las neado a los entornos
Metodologas giles. organizacionales.
1. Generalidades.
2. Manifiesto gil.
3. Principios giles.
4. Declaracin de Interdepen-
dencia.
Tema N 4: Fundamentos de
SCRUM.
1. Visin General de SCRUM.
2. Teora de SCRUM.
3. El Equipo SCRUM (Scrum
Team).
4. Eventos de SCRUM.
5. Artefactos de SCRUM.
6. Transparencia de los Artefac-
tos.
Sistemas de Informacin Geren-
cial: DST Systems gana con
SCRUM y la Administracin del ci-
clo de vida de las aplicaciones.
LAUDON, K.C. & LAUDON, J.P.,
(2012), pginas 547 548.
Autoevaluacin N 1
8
UNIDAD I:
INTRODUCCIN A LA GESTIN DE PROYECTOS
TEMA N 1: INTRODUCCIN AL PMBOK
INTRODUCCIN
En la Gestin de Proyectos, el PMBOK puede ser considerado como la Biblia de la

Gerencia de Proyectos. Sin embargo, si uno no ha profundizado mucho en el rea de
proyectos, pero busca direccionar su carrera hacia esta rea de especializacin, co-
nocer qu es el PMBOK es el paso inicial para poder comprender la amplitud de la
gestin de proyectos y su importancia para una organizacin.
La Gua de los Fundamentos para la Direccin de Proyectos (Gua del PMBOK)

Quinta Edicin proporciona pautas para la direccin de proyectos individuales y define
conceptos relacionados con la direccin de proyectos. Describe asimismo el ciclo de
vida de la direccin de proyectos y los procesos relacionados, as como el ciclo de
vida del proyecto.
La Gua del PMBOK contiene el estndar, reconocido a nivel global y la gua para la
profesin de la direccin de proyectos. Por estndar se entiende un documento formal
que describe normas, mtodos, procesos y prcticas establecidos. Al igual que en
otras profesiones, el conocimiento contenido en este estndar evolucion a partir de
las buenas prcticas reconocidas de los profesionales dedicados a la direccin de
proyectos que han contribuido a su desarrollo.
Para poder profundizar la temtica relacionada a la Gestin de Proyectos, es necesa-

rio que se definan conceptos y definiciones que facilitarn el entendimiento y apren-
dizaje de esta materia.
1. Qu es un proyecto?
De acuerdo al PMBOK, un proyecto es un esfuerzo temporal que se lleva a cabo

para crear un producto, servicio o resultado nico. La naturaleza temporal de los
proyectos implica que un proyecto tiene un principio y un final definidos.
El final se alcanza cuando se logran los objetivos del proyecto, cuando se termina
el proyecto porque sus objetivos no se cumplirn o no pueden ser cumplidos, o
cuando ya no existe la necesidad que dio origen al proyecto. Asimismo, se puede
poner fin a un proyecto si el cliente (cliente, patrocinador o lder) desea terminar
el proyecto. Que sea temporal no significa necesariamente que la duracin del
proyecto haya de ser corta. Se refiere a los compromisos del proyecto y a su
9
longevidad. En general, esta cualidad de temporalidad no se aplica al producto,
servicio o resultado creado por el proyecto; la mayor parte de los proyectos se
emprenden para crear un resultado duradero. Por ejemplo, un proyecto para
construir un monumento nacional crear un resultado que se espera perdure du-
rante siglos. Por otra parte, los proyectos pueden tener impactos sociales, eco-
nmicos y ambientales susceptibles de perdurar mucho ms que los propios pro-
yectos.
Un proyecto puede generar:
Un producto, que puede ser un componente de otro elemento, una mejora de

un elemento o un elemento final en s mismo,
Un servicio o la capacidad de realizar un servicio (p.ej., una funcin de negocio

que brinda apoyo a la produccin o distribucin),
Una mejora de las lneas de productos o servicios existentes (p.ej., Un pro-

yecto Seis Sigma cuyo objetivo es reducir defectos), o
Un resultado, tal como una conclusin o un documento (p.ej., un proyecto de

investigacin que desarrolla conocimientos que se pueden emplear para de-
terminar si existe una tendencia o si un nuevo proceso beneficiar a la socie-
dad).
Los ejemplos de proyectos, incluyen entre otros:
El desarrollo de un nuevo producto, servicio o resultado,
La implementacin de un cambio en la estructura, los procesos, el personal o

el estilo de una organizacin,
El desarrollo o la adquisicin de un sistema de informacin nuevo o modificado

(hardware o software),
La realizacin de un trabajo de investigacin cuyo resultado ser adecuada-

mente registrado,
La construccin de un edificio, planta industrial o infraestructura, o
La implementacin, mejora o potenciacin de los procesos y procedimientos

de negocios existentes.
2. Qu es la Direccin de Proyectos?
De acuerdo al PMBOK, la direccin de proyectos es la aplicacin de conocimientos,

habilidades, herramientas y tcnicas a las actividades del proyecto para cumplir
con los requisitos del mismo. Se logra mediante la aplicacin e integracin ade-
cuadas de los 47 procesos de la direccin de proyectos, agrupados de manera
lgica, categorizados en cinco Grupos de Procesos. Estos cinco Grupos de Proce-
sos son: Inicio, Planificacin, Ejecucin, Monitoreo y Control, y Cierre.
10
3. Relaciones entre Direccin de Portafolios, Direccin de Programas, Di-
reccin de Proyectos y Direccin Organizacional de Proyectos.
Para entender los conceptos de direccin de portafolios, direccin de programas

y direccin de proyectos es importante reconocer las similitudes y las diferencias
que existen entre cada una de estas disciplinas.
Grfico N 01 1: Relacin Portafolio, Programa y Proyecto.
Fuente: PM Certifica.
La direccin de portafolios, la direccin de programas y la direccin de proyectos

se alinean o son impulsadas por las estrategias organizacionales. Sin embargo,
la direccin de portafolios, la direccin de programas y la direccin de proyectos
difieren en la manera en que cada una contribuye al logro de los objetivos estra-
tgicos. La direccin de portafolios se alinea con las estrategias organizacionales
mediante la seleccin de los programas o proyectos adecuados, el establecimiento
de prioridades con respecto al trabajo a realizar y la provisin de los recursos
necesarios, mientras que la direccin de programas adecua sus proyectos y com-
ponentes de programas y controla las interdependencias a fin de lograr los bene-
ficios estipulados. La direccin de proyectos desarrolla e implementa planes para
lograr un alcance determinado, que viene dado por los objetivos del programa o
del portafolio al cual est vinculado, y, en ltimo trmino, por las estrategias
organizacionales.
La Tabla N 01-1 muestra una comparacin entre las perspectivas de proyecto,

programa y portafolio a travs de diferentes dimensiones de la organizacin.
11
Tabla N 01: Presentacin Comparativa de la Direccin de Proyectos, la
Direccin de Programas y la Direccin de Portafolios
Proyectos Programas Portafolios

Alcance Los proyectos tienen Los programas tienen Los portafolios tie-
objetivos definidos. El un alcance mayor y nen un alcance orga-
alcance se elabora proporcionan benefi- nizacional que vara
progresivamente a lo cios ms significati- en funcin de los ob-
largo del ciclo de vida vos. jetivos de la misma.
del proyecto.
Cambio Los directores de pro- Los directores de pro- Los directores de
yecto prevn cambios gramas prevn cam- portafolios monito-
e implementan proce- bios, que podrn sur- rean permanente-
sos para mantener di- gir tanto a nivel in- mente los cambios
chos cambios adminis- terno como a nivel ex- en un entorno ms
trados y controlados. terno al programa, y amplio, tanto a nivel
estn preparados para interno como ex-
gestionarlos. terno.
Planifica- Los directores de pro- Los directores de pro- Los directores de
cin yecto transforman grama desarrollan el portafolios crean y
progresivamente la in- plan general del pro- mantienen los pro-
formacin de alto nivel grama y crean planes cesos y la comunica-
en planes detallados a de alto nivel para cin necesaria rela-
lo largo del ciclo de guiar la planificacin cionada con el porta-
vida del proyecto. detallada a nivel de folio global.
los componentes.
Direccin Los directores de pro- Los directores de pro- Los directores de
yecto dirigen al equipo grama dirigen al per- portafolios pueden
del proyecto de modo sonal del programa y dirigir o coordinar al
que se cumplan los ob- a los directores de personal de direc-
jetivos del mismo. proyecto; brindan vi- cin de portafolios o
sin y liderazgo glo- de programas y pro-
bal. yectos que tuviera
responsabilidad de
informar al portafo-
lio global.
xito El xito se mide por la El xito se mide por el El xito se mide en
calidad del producto y grado en que el pro- trminos del rendi-
del proyecto, la opor- grama satisface las miento de la inver-
tunidad, el cumpli- necesidades y benefi- sin global y de la
miento del presu- cios que le dieron ori- obtencin de benefi-
puesto y el grado de gen. cios del portafolio.
satisfaccin del
cliente.
Monitoreo Los directores de pro- Los directores de pro- Los directores de
yecto monitorean y grama monitorean el portafolios monito-
controlan el trabajo progreso de los com- rean los cambios es-
realizado para obtener ponentes del pro- tratgicos y la asig-
los productos, servi- grama con el fin de nacin global de re-
cios o resultados para asegurar que se cum- cursos, los resulta-
los cuales el proyecto plan los objetivos glo- dos de desempeo y
fue emprendido. bales, cronogramas, el riesgo del portafo-
presupuesto y benefi- lio.
cios del mismo.
Fuente: PMBOK
12
4. Relacin entre Direccin de Proyectos, Gestin de las Operaciones y Es-
trategia Organizacional.
La gestin de las operaciones es responsable de la supervisin, la direccin y el

control de las operaciones del negocio. Las operaciones evolucionan para dar so-
porte al negocio en el da a da, y son necesarias para alcanzar los objetivos
estratgicos y tcticos del negocio. Algunos tipos de operaciones son por ejemplo
las operaciones de produccin, las operaciones de fabricacin, las operaciones
contables, el soporte de software y el mantenimiento.
A pesar de su naturaleza temporal, los proyectos pueden contribuir al logro de

los objetivos de la organizacin cuando estn alineados con su estrategia. Las
organizaciones modifican a veces sus operaciones, productos o sistemas me-
diante la generacin de iniciativas estratgicas de negocio que se desarrollan e
implementan a travs de proyectos. Los proyectos requieren actividades de di-
reccin de proyectos y conjuntos de habilidades, mientras que las operaciones
requieren gestin de procesos de negocio, actividades de gestin de las opera-
ciones y conjuntos de habilidades.
5. Valor del Negocio.
El valor del negocio es un concepto nico para cada organizacin. El valor del
negocio se define como el valor del negocio en su totalidad, como la suma total
de sus elementos tangibles e intangibles. Como ejemplos de elementos tangibles
se pueden citar los activos monetarios, los equipos, la participacin de los accio-
nistas y los servicios. Como ejemplos de elementos intangibles se pueden citar la
buena voluntad, el reconocimiento de marca, el beneficio pblico y las marcas
registradas. Dependiendo de la organizacin, el alcance del valor del negocio
puede ser a corto, mediano o largo plazo. Se puede crear valor a travs de la
gestin eficaz de las operaciones permanentes. No obstante, a travs del uso
eficaz de la direccin de portafolios, la direccin de programas y la direccin de
proyectos, las organizaciones tendrn la capacidad de emplear procesos estable-
cidos y confiables para cumplir con los objetivos estratgicos y obtener mayor
valor de negocio a partir de sus inversiones en proyectos. Si bien no todas las
organizaciones estn orientadas al negocio, todas ellas desarrollan actividades
relacionadas con el negocio.
Ya sea que se trate de una agencia gubernamental o de una organizacin sin fines
de lucro, todas las organizaciones se centran en lograr valor de negocio para sus
actividades.
6. Influencia de la Organizacin y Ciclo de Vida del Proyecto.
Los proyectos y la direccin de proyectos se llevan a cabo en un entorno ms

amplio que el del proyecto en s. La comprensin de este contexto contribuye a
asegurar que el trabajo se lleva a cabo de acuerdo con los objetivos de la orga-
nizacin y se gestiona de conformidad con las prcticas establecidas en la orga-
nizacin.
13
6.1.Influencia de la Organizacin en la Direccin de Proyectos
La cultura, estilo y estructura de una organizacin influyen en la forma en que

se llevan a cabo sus proyectos.
6.1.1. Culturas y Estilos de Organizacin
Las organizaciones son estructuras sistemticas de entidades (personas

y/o departamentos) destinados a lograr un objetivo, el cual puede impli-
car el emprendimiento de proyectos. La cultura y el estilo de una orga-
nizacin afectan a su forma de llevar a cabo los proyectos. Las culturas
y estilos son fenmenos de tipo grupal, conocidos como normas cultura-
les, que se desarrollan con el tiempo. Las normas incluyen enfoques es-
tablecidos para iniciar y planificar proyectos, los medios considerados
aceptables para realizar el trabajo y las autoridades reconocidas que to-
man o influyen en las decisiones.
6.1.2. Comunicaciones en la Organizacin
El xito en la direccin de proyectos de una organizacin depende en

gran medida de un estilo de comunicacin efectivo dentro de la organi-
zacin, sobre todo si se considera la globalizacin de la profesin de di-
reccin de proyectos. Las capacidades de comunicacin dentro de la or-
ganizacin tienen gran influencia en la forma en que se llevan a cabo los
proyectos. En consecuencia, los directores de proyecto en ubicaciones
distantes pueden comunicarse de manera ms efectiva con todos los in-
teresados relevantes dentro de la estructura de la organizacin para fa-
cilitar la toma de decisiones.
Los interesados y miembros del equipo del proyecto tambin pueden uti-
lizar comunicaciones electrnicas (incluido correo electrnico, mensaje-
ra de texto, mensajera instantnea, redes sociales, videoconferencia y
conferencia por Internet y otros medios electrnicos) para comunicarse
formal o informalmente con el director del proyecto.
6.1.3. Estructuras de la Organizacin
La estructura de la organizacin es un factor ambiental de la empresa

que puede afectar a la disponibilidad de recursos e influir en el modo de
dirigir los proyectos. Las estructuras abarcan desde una estructura fun-
cional hasta una estructura orientada a proyectos, con una variedad de
estructuras matriciales entre ellas.
La Tabla N 02 muestra las caractersticas clave de los principales tipos

de estructuras de una organizacin en relacin con los proyectos.
14
Tabla N 02 1: Influencia de la Estructura de la Organizacin en los
Proyectos
Estructura de la Organizacin
Caractersticas
del Proyecto Matricial
Matricial Orientada a
Funcional Matricial Equili-
Fuerte Proyectos
brada
Autoridad del Di- Poca o Baja a Mo- Moderada Alta a Casi To-
Baja
Ninguna derada a Alta tal
rector del Proyecto
Disponibilidad de Poca o Baja a Mo- Moderada Alta a Casi To-

Baja
Ninguna derada a Alta tal
Recursos
Quin gestiona el Director

Gerente Gerente Director del
Mixta del Pro-
presupuesto del Funcional Funcional Proyecto
yecto
proyecto
Rol del Director del Tiempo Tiempo Tiempo Tiempo Tiempo Com-
Parcial Parcial Completo Completo pleto
Proyecto
Personal Adminis- Tiempo Tiempo Tiempo Tiempo Tiempo Com-

trativo de la Direc- Parcial Parcial Parcial Completo pleto
cin de Proyectos
Fuente: PMBOK.
6.1.4. Activos de los Procesos de la Organizacin
Los activos de los procesos de la organizacin son los planes, los proce-
sos, las polticas, los procedimientos y las bases de conocimiento espe-
cficos de la organizacin ejecutora y utilizados por la misma. Estos in-
cluyen cualquier objeto, prctica o conocimiento de alguna o de todas las
organizaciones que participan en el proyecto y que pueden usarse para
ejecutar o gobernar el proyecto. Los activos de procesos tambin inclu-
yen bases de conocimiento de la organizacin como lecciones aprendidas
e informacin histrica.
6.1.5. Factores Ambientales de la Empresa
Los factores ambientales de la empresa hacen referencia a condiciones

que no estn bajo el control del equipo del proyecto y que influyen, res-
tringen o dirigen el proyecto. Los factores ambientales de la empresa se
consideran entradas para la mayor parte de los procesos de planificacin,
pueden mejorar o restringir las opciones de la direccin de proyectos, y
pueden influir de manera positiva o negativa sobre el resultado.
15
6.2.Interesados y Gobierno del Proyecto
Un interesado es un individuo, grupo u organizacin que puede afectar, verse

afectado, o percibirse a s mismo como afectado por una decisin, actividad
o resultado de un proyecto. Los interesados pueden participar activamente
en el proyecto o tener intereses a los que puede afectar positiva o negativa-
mente la ejecucin o la terminacin del proyecto. Los diferentes interesados
pueden tener expectativas contrapuestas susceptibles de generar conflictos
dentro del proyecto. Los interesados tambin pueden ejercer influencia sobre
el proyecto, los entregables y el equipo del proyecto a fin de lograr un con-
junto de resultados que satisfagan los objetivos estratgicos del negocio u
otras necesidades.
6.3.Equipo del Proyecto
El equipo del proyecto incluye al director del proyecto y al grupo de individuos

que actan conjuntamente en la realizacin del trabajo del proyecto para
alcanzar sus objetivos. El equipo del proyecto incluye al director del proyecto,
al personal de direccin del proyecto y a otros miembros del equipo que desa-
rrollan el trabajo, pero que no necesariamente participan en la direccin del
proyecto. Este equipo est compuesto por individuos procedentes de diferen-
tes grupos, con conocimientos en una materia especfica o con un conjunto
de habilidades especficas para llevar a cabo el trabajo del proyecto. La es-
tructura y las caractersticas de un equipo de proyecto pueden variar amplia-
mente, pero una constante es el rol del director del proyecto como lder del
equipo, independientemente de la autoridad que ste pueda tener sobre sus
miembros.
6.4.Ciclo de Vida del Proyecto
El ciclo de vida de un proyecto es la serie de fases por las que atraviesa un

proyecto desde su inicio hasta su cierre. Las fases son generalmente secuen-
ciales y sus nombres y nmeros se determinan en funcin de las necesidades
de gestin y control de la organizacin u organizaciones que participan en el
proyecto, la naturaleza propia del proyecto y su rea de aplicacin. Las fases
se pueden dividir por objetivos funcionales o parciales, resultados o entrega-
bles intermedios, hitos especficos dentro del alcance global del trabajo o
disponibilidad financiera. Las fases son generalmente acotadas en el tiempo,
con un inicio y un final o punto de control. Un ciclo de vida se puede docu-
mentar dentro de una metodologa. Se puede determinar o conformar el ciclo
de vida del proyecto sobre la base de los aspectos nicos de la organizacin,
de la industria o de la tecnologa empleada. Mientras que cada proyecto tiene
un inicio y un final definido, los entregables especficos y las actividades que
se llevan a cabo variarn ampliamente dependiendo del proyecto. El ciclo de
vida proporciona el marco de referencia bsico para dirigir el proyecto, inde-
pendientemente del trabajo especfico involucrado.
16
TEMA N 2: PROCESOS DE LA DIRECCIN DE PROYECTOS
INTRODUCCIN
La direccin de proyectos es la aplicacin de conocimientos, habilidades, herramien-

tas y tcnicas a las actividades del proyecto para cumplir con los requisitos del
mismo. Esta aplicacin de conocimientos requiere de la gestin eficaz de los procesos
de direccin de proyectos.
Un proceso es un conjunto de acciones y actividades, relacionadas entre s, que se

realizan para crear un producto, resultado o servicio predefinido. Cada proceso se
caracteriza por sus entradas, por las herramientas y tcnicas que se pueden aplicar
y por las salidas que se obtienen. El director de proyecto ha de tener en cuenta los
activos de los procesos de la organizacin y los factores ambientales de la empresa.
stos deberan tenerse en cuenta para cada proceso, incluso si no estn enumerados
de manera explcita como entradas en las especificaciones del proceso. Los activos
de los procesos de la organizacin proporcionan guas y criterios para adaptar dichos
procesos a las necesidades especficas del proyecto. Los factores ambientales de la
empresa pueden restringir las opciones de la direccin de proyectos.
1. Interacciones Comunes entre los Procesos de la Direccin de Proyectos.
Los procesos de la direccin de proyectos se presentan como elementos diferen-

ciados con interfaces bien definidas. Sin embargo, en la prctica se superponen
y actan unos sobre otros de mltiples formas que no se detallan exhaustiva-
mente en este documento. La mayora de los profesionales con experiencia en
este mbito reconocen que existe ms de una forma de dirigir un proyecto. Los
Grupos de Procesos requeridos y los procesos que los constituyen sirven de gua
para aplicar los conocimientos y las habilidades adecuados en materia de direc-
cin de proyectos durante el desarrollo del proyecto. La aplicacin de los procesos
de la direccin de proyectos es iterativa y muchos procesos se repiten a lo largo
del proyecto.
La naturaleza integradora de la direccin de proyectos requiere que el Grupo de

Procesos de Monitoreo y Control y el resto de Grupos de Procesos ejerzan acciones
uno sobre los otros de manera recproca, como muestra el Grfico N 02. Los
procesos de Monitoreo y Control transcurren al mismo tiempo que los procesos
pertenecientes a otros Grupos de Procesos. Por lo tanto, el Grupo de Procesos de
Monitoreo y Control se considera como un Grupo de Procesos de fondo para los
otros cuatro Grupos de Procesos que muestra el Grfico N 01 - 2.
17
Grfico N 02. Grupos de Procesos de la Direccin de Proyectos
Fuente: PMBOK
Los Grupos de Procesos de la Direccin de Proyectos se vinculan entre s a travs

de las salidas que producen. Los Grupos de Procesos rara vez son eventos dis-
cretos o nicos; son actividades superpuestas que tienen lugar a lo largo del pro-
yecto. La salida de un proceso normalmente se convierte en la entrada para otro
proceso o constituye un entregable del proyecto, subproyecto o fase del proyecto.
Los entregables a nivel del subproyecto o del proyecto pueden llamarse entrega-
bles incrementales. El Grupo de Procesos de Planificacin suministra al Grupo de
Procesos de Ejecucin el plan para la direccin del proyecto y los documentos del
proyecto y, conforme el proyecto avanza, a menudo genera actualizaciones al
plan para la direccin del proyecto y a los documentos del proyecto. El Grfico N
01 - 3 ilustra cmo actan entre s los Grupos de Procesos y muestra el nivel de
superposicin en distintas etapas. Cuando el proyecto est dividido en fases, los
Grupos de Procesos interactan dentro de cada fase.
Grfico N 01 3: Los Grupos de Procesos interactan en una Fase o

Proyecto
Fuente: PMBOK.
18
Un ejemplo de esta interaccin es la salida de una fase de diseo, la cual requiere
la aceptacin del documento de diseo por parte del patrocinador. El documento
de diseo proporciona, una vez disponible, la descripcin del producto para los
Grupos de Procesos de Planificacin y de Ejecucin en una o ms fases sucesivas.
Cuando un proyecto se divide en fases, los Grupos de Procesos se utilizan segn
resulte adecuado, a fin de conducir el proyecto de manera eficaz hacia su cierre
controlado. En proyectos de mltiples fases, los procesos se repiten dentro de
cada fase hasta que se cumplen los criterios para concluir la misma.
2. Grupos de Procesos de la Direccin de Proyectos
En las siguientes secciones se identifican y describen los cinco Grupos de Procesos

de la Direccin de Proyectos necesarios en todo proyecto. Estos cinco Grupos de
Procesos cuentan con dependencias bien definidas; normalmente se ejecutan en
cada proyecto y tienen un elevado grado de interaccin entre s. Estos cinco Gru-
pos de Procesos son independientes de las reas de aplicacin y del enfoque de
las industrias. Los Grupos de Procesos individuales y los procesos individuales a
menudo se repiten antes de concluir el proyecto y pueden presentar interacciones
dentro de un Grupo de Procesos y entre Grupos de Procesos.
Estas interacciones, cuya naturaleza vara de un proyecto a otro, pueden reali-

zarse o no en un orden determinado.
2.1.Grupo de Procesos de Inicio
El Grupo de Procesos de Inicio est compuesto por aquellos procesos realiza-

dos para definir un nuevo proyecto o una nueva fase de un proyecto existente
al obtener la autorizacin para iniciar el proyecto o fase.
Dentro del mbito de los procesos de inicio es donde se define el alcance inicial
y se comprometen los recursos financieros iniciales. Adems, se identifican
los interesados internos y externos que van a participar y ejercer alguna in-
fluencia sobre el resultado global del proyecto. Finalmente, si an no hubiera
sido nombrado, se selecciona el director del proyecto. Esta informacin se
registra en el acta de constitucin del proyecto y en el registro de interesados.
En el momento en que se aprueba el acta de constitucin del proyecto, ste
se considera oficialmente autorizado. Aunque el equipo de direccin del pro-
yecto puede colaborar en la redaccin de esta acta, este estndar supone que
la evaluacin, la aprobacin y el financiamiento del caso de negocio se mane-
jan fuera de los lmites del proyecto (Grfico N 01 -4). El lmite de un proyecto
se define como el momento en que se autoriza el inicio o la finalizacin de un
proyecto o de una fase de un proyecto. El propsito clave de este Grupo de
Procesos es alinear las expectativas de los interesados con el propsito del
proyecto, darles visibilidad sobre el alcance y los objetivos, y mostrar cmo
su participacin en el proyecto y sus fases asociadas puede asegurar el logro
de sus expectativas. Estos procesos ayudan a establecer la visin del pro-
yecto: qu es lo que se necesita realizar.
19
Grfico N 01 -4: Lmites del Proyecto
Fuente: PMBOK.
Los procesos de inicio podran realizarse a nivel de la organizacin, programa

o portafolio y estaran, en este caso, fuera del nivel de control del proyecto.
Por ejemplo, antes de iniciar un proyecto, podra documentarse la necesidad
de requisitos de alto nivel como parte de una iniciativa ms amplia de la or-
ganizacin. Podra utilizarse un proceso de evaluacin de alternativas para
establecer la viabilidad de la nueva tarea. Podran describirse los objetivos del
proyecto con claridad, e incluir las razones por las que un proyecto especfico
resulta la mejor alternativa para cumplir los requisitos.
2.2.Grupo de Procesos de Planificacin
El Grupo de Procesos de Planificacin est compuesto por aquellos procesos

realizados para establecer el alcance total del esfuerzo, definir y refinar los
objetivos, y desarrollar la lnea de accin requerida para alcanzar dichos ob-
jetivos. Los procesos de Planificacin desarrollan el plan para la direccin del
proyecto y los documentos del proyecto que se utilizarn para llevarlo a cabo.
La naturaleza compleja de la direccin de proyectos puede requerir el uso de
reiterados ciclos de retroalimentacin para un anlisis adicional. A medida que
se va recopilando y comprendiendo ms informacin o ms caractersticas del
proyecto, es probable que se requiera una planificacin adicional. Los cambios
importantes que ocurren a lo largo del ciclo de vida del proyecto generan la
necesidad de reconsiderar uno o ms de los procesos de planificacin y posi-
blemente algunos de los procesos de inicio. Esta incorporacin progresiva de
detalles al plan para la direccin del proyecto recibe el nombre de elaboracin
progresiva, para indicar que la planificacin y la documentacin son activida-
des iterativas y continuas. El beneficio clave de este Grupo de Procesos con-
siste en trazar la estrategia y las tcticas, as como la lnea de accin o ruta
para completar con xito el proyecto o fase. Cuando se gestiona correcta-
mente el Grupo de Procesos de Planificacin, resulta mucho ms sencillo con-
20
seguir la aceptacin y la participacin de los interesados. Estos procesos ex-
presan cmo se llevar esto a cabo y establecen la ruta hasta el objetivo
deseado.
El plan para la direccin del proyecto y los documentos del proyecto, desarro-
llados como salidas del Grupo de Procesos de Planificacin, explorarn todos
los aspectos de alcance, tiempo, costo, calidad, comunicaciones, recursos hu-
manos, riesgos, adquisiciones y participacin de los interesados.
Las actualizaciones surgidas de los cambios aprobados a lo largo del proyecto

(en general durante los procesos de Monitoreo y Control y especficamente
durante el proceso Dirigir y Gestionar el Trabajo del Proyecto) pueden tener
un impacto considerable en determinadas partes del plan para la direccin del
proyecto y en los documentos del proyecto. Las actualizaciones de estos do-
cumentos aportan mayor precisin en torno al cronograma, a los costos y a
los recursos requeridos para cumplir con el alcance definido para el proyecto.
El equipo del proyecto persigue el aporte y estimula la participacin de todos

los interesados tanto durante la planificacin del proyecto como en el desa-
rrollo del plan para la direccin del proyecto y de los documentos del mismo.
Dado que el acto de obtener retroalimentacin y refinar los documentos no
puede prolongarse de manera indefinida, son los procedimientos establecidos
por la organizacin los que dictan en qu momento se termina la planificacin
inicial. Estos procedimientos se vern afectados por la naturaleza del pro-
yecto, por los lmites establecidos del proyecto, por las actividades de moni-
toreo y control adecuadas y por el entorno en que el proyecto se llevar a
cabo.
2.3.Grupo de Procesos de Ejecucin
El Grupo de Procesos de Ejecucin est compuesto por aquellos procesos rea-

lizados para completar el trabajo definido en el plan para la direccin del pro-
yecto a fin de cumplir con las especificaciones del mismo.
Este Grupo de Procesos implica coordinar personas y recursos, gestionar las

expectativas de los interesados; as como, integrar y realizar las actividades
del proyecto conforme al plan para la direccin del proyecto.
Durante la ejecucin del proyecto, en funcin de los resultados obtenidos, se

puede requerir una actualizacin de la planificacin y una revisin de la lnea
base. Esto puede incluir cambios en la duracin prevista de las actividades,
cambios en la disponibilidad y productividad de los recursos; as como, riesgos
no previstos. Tales variaciones pueden afectar al plan para la direccin del
proyecto o a los documentos del proyecto, y pueden requerir un anlisis de-
tallado y el desarrollo de respuestas de direccin de proyectos adecuadas. Los
resultados del anlisis pueden dar lugar a solicitudes de cambio que, en caso
de ser aprobadas, podran modificar el plan para la direccin del proyecto u
otros documentos del mismo, y posiblemente requerir el establecimiento de
21
nuevas lneas de base. Gran parte del presupuesto del proyecto se utilizar
en la realizacin de los procesos del Grupo de Procesos de Ejecucin.
2.4.Grupo de Procesos de Monitoreo y Control
El Grupo de Procesos de Monitoreo y Control est compuesto por aquellos

procesos requeridos para rastrear, analizar y dirigir el progreso y el desem-
peo del proyecto, para identificar reas en las que el plan requiera cambios
y para iniciar los cambios correspondientes. El beneficio clave de este Grupo
de Procesos radica en que el desempeo del proyecto se mide y se analiza a
intervalos regulares, y tambin como consecuencia de eventos adecuados o
de determinadas condiciones de excepcin, a fin de identificar variaciones res-
pecto del plan para la direccin del proyecto. El Grupo de Procesos de Moni-
toreo y Control tambin implica:
Controlar los cambios y recomendar acciones correctivas o preventivas

para anticipar posibles problemas,
Monitorear las actividades del proyecto, comparndolas con el plan para

la direccin del proyecto y con la lnea base para la medicin del desem-
peo del proyecto, e
Influir en los factores que podran eludir el control integrado de cambios o

la gestin de la configuracin, de modo que nicamente se implementen
cambios aprobados.
Este monitoreo continuo proporciona al equipo del proyecto conocimiento so-

bre la salud del proyecto y permite identificar las reas que requieren ms
atencin. El Grupo de Procesos de Monitoreo y Control no slo monitorea y
controla el trabajo que se est realizando dentro de un Grupo de Procesos,
sino que tambin monitorea y controla el esfuerzo global dedicado al proyecto.
En proyectos de varias fases, el Grupo de Procesos de Monitoreo y Control
coordina las fases del proyecto a fin de implementar las acciones correctivas
o preventivas necesarias para que el proyecto cumpla con el plan para la di-
reccin del proyecto. Esta revisin puede dar lugar a actualizaciones recomen-
dadas y aprobadas del plan para la direccin del proyecto. Por ejemplo, el
incumplimiento de la fecha de finalizacin de una actividad puede requerir
ajustes y soluciones de compromiso entre los objetivos de presupuesto y de
cronograma. Con el fin de reducir o controlar los gastos generales, se puede
considerar la implantacin de procedimientos de gestin por excepcin y otras
tcnicas de gestin.
2.5.Grupo de Procesos de Cierre
El Grupo de Procesos de Cierre est compuesto por aquellos procesos realiza-

dos para finalizar todas las actividades a travs de todos los Grupos de Pro-
cesos de la Direccin de Proyectos, a fin de completar formalmente el pro-
yecto, una fase del mismo u otras obligaciones contractuales. Este Grupo de
22
Procesos, una vez completado, verifica que los procesos definidos se han com-
pletado dentro de todos los Grupos de Procesos a fin de cerrar el proyecto o
una fase del mismo, segn corresponda, y establece formalmente que el pro-
yecto o fase del mismo ha finalizado.
Este Grupo de Procesos tambin establece formalmente el cierre prematuro

del proyecto. Los proyectos cerrados prematuramente podran incluir, por
ejemplo, proyectos abortados, proyectos cancelados y proyectos en crisis. En
casos particulares, cuando algunos contratos no pueden cerrarse formalmente
(p.ej., reclamaciones, clusulas de rescisin, etc.) o algunas actividades han
de transferirse a otras unidades de la organizacin, es posible organizar y
finalizar procedimientos de transferencia especficos.
En el cierre del proyecto o fase, puede ocurrir lo siguiente:
Que se obtenga la aceptacin del cliente o del patrocinador para cerrar

formalmente el proyecto o fase,
Que se realice una revisin tras el cierre del proyecto o la finalizacin de

una fase,
Que se registren los impactos de la adaptacin a un proceso,
Que se documenten las lecciones aprendidas,
Que se apliquen las actualizaciones adecuadas a los activos de los procesos

de la organizacin,
Que se archiven todos los documentos relevantes del proyecto en el sis-

tema de informacin para la direccin de proyectos (PMIS) para utilizarlos
como datos histricos,
Que se cierren todas las actividades de adquisicin y se asegure la finali-

zacin de todos los acuerdos relevantes, y
Que se realicen las evaluaciones de los miembros del equipo y se liberen

los recursos del proyecto.
A lo largo del ciclo de vida del proyecto, se recopila, analiza, transforma y distri-
buye a los miembros del equipo del proyecto y a otros interesados una cantidad
significativa de datos e informacin en diversos formatos.
Los datos del proyecto se recopilan como resultado de varios procesos de Ejecu-
cin y se comparten en el mbito del equipo del proyecto. Los datos recopilados
se analizan en contexto, se agregan y se transforman para convertirse en infor-
macin del proyecto en el curso de varios procesos de Control. La informacin
puede entonces comunicarse verbalmente o almacenarse y distribuirse como in-
formes en diversos formatos.
23
Los datos del proyecto se recopilan y analizan de forma continua durante el con-
texto dinmico de la ejecucin del proyecto. En consecuencia, los trminos "da-
tos" e "informacin" a menudo se utilizan indistintamente en la prctica. El uso
indiscriminado de estos trminos puede llevar a confusin y mala interpretacin
por parte de los diferentes interesados en el proyecto. Las siguientes pautas con-
tribuyen a minimizar los errores en la comunicacin y ayudan al equipo del pro-
yecto a utilizar la terminologa adecuada:
Datos de desempeo del trabajo. Son las observaciones y mediciones directas

identificadas durante las actividades ejecutadas para llevar a cabo el trabajo
del proyecto,
Informacin de desempeo del trabajo. Son los datos de desempeo recopi-

lados de varios procesos de control, analizados en contexto e integrados en
base a las relaciones entre las reas, e
Informes de desempeo del trabajo. Constituyen la representacin fsica o

electrnica de la informacin de desempeo del trabajo recogida en documen-
tos del proyecto para la toma de decisiones, el planteamiento de incidentes,
el emprendimiento de acciones y la generacin de conocimiento.
Los 47 procesos de la direccin de proyectos identificados en la Gua del PMBOK

se agrupan a su vez en diez reas de Conocimiento diferenciadas. Un rea de
Conocimiento representa un conjunto completo de conceptos, trminos y activi-
dades que conforman un mbito profesional, un mbito de la direccin de pro-
yectos o un rea de especializacin. Estas diez reas de Conocimiento se utilizan
en la mayora de los proyectos, durante la mayor parte del tiempo. Los equipos
de proyecto deben utilizar estas diez reas de Conocimiento, as como otras reas
de conocimiento, de la manera ms adecuada en su proyecto especfico.
Las reas de Conocimiento son: Gestin de la Integracin del Proyecto, Gestin

del Alcance del Proyecto, Gestin del Tiempo del Proyecto, Gestin de los Costos
del Proyecto, Gestin de la Calidad del Proyecto, Gestin de los Recursos Huma-
nos del Proyecto, Gestin de las Comunicaciones del Proyecto, Gestin de los
Riesgos del Proyecto, Gestin de las Adquisiciones del Proyecto y Gestin de los
Interesados del Proyecto.
24
LECTURA SELECCIONADA No 1:
MOTOROLA RECURRE A LA ADMINISTRACIN DE CARTERA DE
PROYECTOS
Sistemas de Informacin Gerencial, LAUDON, K.C. & LAUDON, J.P., 2012, pginas
550 551
tura y el equipo que utilizan los opera-

Motorola Inc. es una enorme compaa dores de cable, los proveedores de ser-
de tecnologa multinacional con base vicios inalmbricos y otros proveedo-
en Schaumburg, Illinois; se especializa res de comunicaciones; su segmento
en la infraestructura de comunicacio- de soluciones de movilidad empresarial
nes de banda ancha, la movilidad em- (Enterprise Mobility Solutions) desa-
presarial, las soluciones de seguridad rrolla y comercializa productos de co-
pblica, el video de alta definicin, los municaciones de voz y datos, sistemas
dispositivos mviles y una amplia va- de banda ancha inalmbricos y una
riedad de tecnologas mviles adiciona- gran cantidad de aplicaciones y dispo-
les. Motorola obtuvo ingresos de $22 sitivos para una variedad de clientes
miles de millones en 2009, con 53 000 empresariales. Las condiciones econ-
empleados en todo el mundo. Esta micas dbiles haban provocado que
compaa ha crecido de manera org- disminuyeran las cifras de Motorola en
nica por medio de fusiones y adquisi- todos los principales segmentos del ne-
ciones, por lo cual tiene miles de siste- gocio. La compaa utiliz esta baja
mas que desempean diversas funcio- para revisar a profundidad su negocio
nes en todos sus negocios. Motorola y localizar las reas en las que se po-
saba que, si era capaz de mejorar el dra volver ms eficiente. Primero ana-
manejo de sus sistemas y sus proyec- liz cada una de sus funciones de ne-
tos, podra reducir de manera conside- gocios en trminos de su importancia y
rable sus costos de operacin. En el valor para el negocio. Despus analiz
entorno econmico debilitado de la ac- la complejidad y el costo de esa fun-
tualidad, los conceptos de ahorrar di- cin. Por ejemplo, la ingeniera en Mo-
nero y aumentar la eficiencia se han torola es muy importante para el xito
vuelto ms importantes que nunca. de la compaa, adems de que la dis-
Motorola est organizada en tres seg- tingue de sus competidores. La inge-
mentos principales. El segmento de niera es tambin una de las funciones
dispositivos mviles (Mobile Devices) de negocios ms complicada y costosa
del negocio disea, fabrica, vende y da de Motorola. La compaa repiti este
servicio a dispositivos porttiles anlisis para todas sus funciones de
inalmbricos, entre ellos telfonos in- negocios y despus determin cules
teligentes. Motorola espera enfrentar reas requeran de un ajuste. Los pro-
una competencia cada vez ms intensa cesos que no eran tan crticos para el
en este segmento por parte de un n- xito de la compaa, pero que aun as
mero cada vez mayor de retadores que eran demasiado complejos y costosos,
esperan sacar provecho a la moda de se convirtieron en candidatos para su
los telfonos inteligentes. El segmento simplificacin. Los procesos que eran
de hogar y redes (Home and Network) crticos para la compaa, pero estaban
de Motorola desarrolla la infraestruc- mal patrocinados se convirtieron en
25
candidatos para un mejor apoyo. Des- sirve como la fuente centralizada de
pus de llevar a cabo este ejercicio, otra informacin crtica, como la canti-
Motorola esperaba automatizar mu- dad de dlares de inversin utilizados
chas de las tareas gerenciales que ha- por un proceso y las prioridades de las
ba clasificado como menos complejas, solicitudes de negocios que pasan por
pero tan slo el tamao de la compaa los sistemas de Motorola. HP PPM per-
haca de la automatizacin un desafo. mite a los empleados y gerentes de TI
Motorola tiene 1,800 sistemas de infor- de Motorola acceder con rapidez y fa-
macin y 1,500 empleados de sistemas cilidad a cualquier dato que pertenezca
de informacin que son responsables a los procesos de negocios de la com-
de 1,000 proyectos al ao. La compa- paa. HP PPM permite que Motorola
a tambin subcontrata la mayor gobierne toda su cartera de Ti me-
parte de su trabajo de TI a contratistas diante una amplia gama de herramien-
externos, con lo cual aumenta el n- tas, como la asignacin de prioridades
mero de usuarios regulares de sus sis- a los objetivos; varios niveles de en-
temas. Administrar todos esos trabaja- trada, revisin y aprobacin; y visibili-
dores es difcil y a menudo conduce a dad en tiempo real en todas las reas
la ineficiencia. Muchos de los emplea- del negocio. Los usuarios de HP PPM
dos de la compaa estaban trabajando tienen los datos ms recientes sobre
en proyectos similares o compilando los recursos, presupuestos, pronsti-
los mismos conjuntos de datos, sin sa- cos, costos, programas, proyectos y la
ber que otros grupos dentro de la com- demanda de TI en general. Los em-
paa estaban haciendo lo mismo. Mo- pleados de Motorola pueden acceder a
torola tena la esperanza de identificar HP PPM dentro de la empresa o en
y eliminar estos grupos, tambin cono- forma de software como un servicio
cidos como silos redundantes de ac- (SaaS). Motorola utilizaba la versin
tividad dentro de la compaa, tanto dentro del sitio, pero se convirti a
para reducir los costos como para au- SaaS sin sufrir ningn efecto en cuanto
mentar la productividad. La gerencia a la facilidad de uso. Los empleados de
tambin esperaba poder asignar priori- Motorola afirman que HP ha sido muy
dades al uso de los recursos, de modo receptiva y confiable con su servicio y
que los proyectos ms valiosos para la soporte al cliente. El uso de SaaS re-
compaa recibieran primero los recur- duce los costos de soporte de Motorola
sos que necesitaban para tener xito. hasta en un 50 por ciento. HP PPM uti-
Los gerentes de Motorola esperaban liza una serie de pantallas grficas y
lograr sus objetivos de automatizar los datos muy especficos para capturar
procesos y reducir los costos de opera- con efectividad el estado en tiempo
cin al adoptar el software Project and real del programa y los proyectos de
Portfolio Management Center de HP, o TI. Tambin cuenta con planificacin
HP PPM. Este software ayuda a los ge- de escenarios del tipo qu pasara
rentes a comparar propuestas, proyec- s?, que crea de manera automtica
tos y actividades operacionales con los una mezcla ptima de proyectos, pro-
presupuestos y niveles de capacidad puestas y activos. Esto significa que los
de los recursos. Toda la informacin usuarios pueden usar HP PPM para rea-
que recopil Motorola de su anlisis de lizar un anlisis de los procesos de ne-
procesos se encuentra en una ubica- gocios similar al que realiz Motorola
cin central con HP PPM, que tambin en un principio en forma manual para
26
empezar a poner a punto su infraes- yectos ms grandes en los que se uti-
tructura de TI y para generar recomen- liz HP PPM, Motorola ha obtenido un
daciones con base en ese anlisis. Los promedio de rendimiento sobre la in-
usuarios tambin pueden usar las he- versin (ROI) del 150 por ciento. Los
rramientas de planificacin de escena- costos de soporte de TI de Motorola
rios qu pasara s? para predecir el disminuyeron un 25 por ciento. Los si-
valor y la utilidad de los nuevos pro- los redundantes de trabajadores que
yectos. realizaban las mismas tareas se elimi-
naron casi en su totalidad, con lo cual
Los resultados han sido justo lo que se suprimi el 25 por ciento del tra-
Motorola esperaba. En dos aos, la bajo desperdiciado de la compaa.
compaa redujo su estructura de cos- Motorola tambin tiene planes de utili-
tos en un 40 por ciento, y en los pro- zar HP PPM para la administracin de
recursos y el soporte de aplicaciones.
Fuentes: HP, Motorola: Excellence in Cost Optimization (2010) y HP Project and Portfolio Management
(PPM) Portfolio Management Module Data Sheet, www.hp.com, visitado el 9 de noviembre de 2010; Dana
Gardner, Motorola Shows Dramatic Savings in IT Operations Costs with ERP for IT Tools, ZD Net, 18 de
junio de 2010; Formulario 10-K de Motorola Inc., para el ao fiscal que termin el 31 de diciembre de
2009, visitado a travs de www.sec.gov.
27
ACTIVIDAD FORMATIVA N 1
INSTRUCCIONES
1. Elaborar un listado de las causas ms comunes de xito y fracaso en los proyec-
tos de desarrollo de software. Mnimo se deben identificar quince (15) causas de
xito y quince (15) causas de fracaso.
2. Elaborar una lista de categoras en el proceso de desarrollo de software. Ejem-
plo: Requerimientos, Cliente, entre otros.
3. Agrupar las causas identificadas en cada categora, de acuerdo al siguiente ejem-
plo:
Tipo (xito o Fra-

N Categora Causa
caso)
Requerimien- Mala definicin del Requeri-

01 Fracaso
tos miento.
02
28
TEMA N 3: INTRODUCCIN A LAS METODOLOGAS GILES
INTRODUCCIN
La alta competitividad actual hace que los sistemas de informacin se tengan que
desarrollar de forma rpida para adaptarse a la organizacin. Las prisas hacen que
lo primero que se deseche en esta carrera "loca" hacia un rpido desarrollo sea un
anlisis exhaustivo y se sustituye por uno superficial o simplemente se elimina. ste
es sin duda el gran error, deseamos tener un sistema desarrollado rpidamente, pero
con lo que realmente nos encontramos entre las manos es con un sistema lleno de
errores, inmanejable y que no se puede mantener.
Es difcil cambiar las reglas del mercado mundial, as que lo que se ha pensado es
adaptar las metodologas de especificacin y desarrollo a este entorno cambiante y
lleno de presiones, en el que obtener un resultado rpido, algo que se pueda ver,
mostrar y sobre todo utilizar, se ha vuelto crucial para el xito de las organizaciones.
La metodologa necesariamente ha de ser gil, debe tener un ciclo corto de desarrollo
y debe incrementar las funcionalidades en cada iteracin del mismo preservando las
existentes, ayudando al negocio en lugar de darle la espalda.
Tal como se menciona en el artculo de Jorge Fernndez (s.f.) que las metodologas
giles no son la gran solucin a todos los problemas del desarrollo de aplicaciones,
ni tan siquiera se pueden aplicar en todos los casos, pero s que nos aportan otro
punto de vista de cmo se pueden llegar a hacer las cosas, de forma ms rpida,
ms adaptable y sin tener que perder la rigurosidad de las metodologas clsicas.
En los siguientes puntos se explicarn trminos que nos permitan entender el enfo-
que de las metodologas giles para el desarrollo de software.
1. Generalidades
El trmino agile (gil) generalmente se refiere a ser capaz de moverse o respon-

der rpidamente y fcilmente. En cualquier tipo de disciplina de gestin, ser gil
es una cualidad, por lo tanto, esto debe ser una meta que se debe tratar de
alcanzar. La gestin de proyectos gil especialmente, implica la adaptabilidad du-
rante la creacin de un producto, servicio, o cualquier otro resultado.
Es importante entender que a pesar de que el desarrollo de los mtodos giles es

altamente adaptable, de todos modos, es necesario tener en cuenta la estabilidad
en sus procesos de adaptacin.
1.1.Historias de los Procesos de Desarrollo
Uno de los grandes pasos dados en la industria del software fue aquel en que
se plasm el denominado modelo de cascada ya que sirvi como base para la
formulacin del anlisis estructurado, el cual fue uno de los precursores en el
camino hacia la aplicacin de prcticas estandarizadas dentro de la ingeniera
de software. Este modelo surge como respuesta al modelo codificar y probar
29
que era el que predominaba en la dcada de los sesenta. En esta poca ya
existan modelos iterativos e incrementales, pero no eran disciplinados ni es-
taban formalizados.
A consecuencia de esta realidad, la idea de tener un modelo que ordenara el

proceso de desarrollo y que pareca bastante sencillo de llevar a la prctica
hizo que el modelo en cascada tuviese gran promocin. Este modelo se basaba
en el desarrollo en forma de cascada ya que se requera de la finalizacin de
la etapa anterior para empezar la siguiente. Esto degeneraba en un congela-
miento temprano de los requerimientos, los cuales al presentar cambios re-
queran gran esfuerzo en trabajo. Otra opcin era no permitir cambio alguno
a los requerimientos una vez que se iniciara el desarrollo lo que traa apare-
jado que el usuario no vea la aplicacin hasta que ya estaba construida y una
vez que interactuaba no cubra sus necesidades.
Asimismo, dadas las caractersticas inherentes del modelo, la fase de imple-

mentacin del mismo requera el desarrollo de los mdulos en forma indepen-
diente con las correspondientes pruebas unitarias, y en la siguiente fase, se
realizaba la integracin de los mismos. Esto traa grandes inconvenientes de-
bido a que todo estaba probado en forma unitaria sin interaccin con los de-
ms mdulos. Las sorpresas llegaban cuando se integraban estas piezas para
formar la aplicacin; lo cual inevitablemente desembocaba en un retraso del
proyecto, sacrificando la calidad del mismo.
De esta forma y en forma bastante temprana en algunos casos, fueron sur-

giendo diversos procesos denominados iterativos que proponan lidiar con la
impredictibilidad del software (subsanando muchas de las falencias del modelo
en cascada) mitigando los riesgos en forma temprana. Los procesos iterativos
de los cuales se desprenderan diversas instancias, como son el modelo itera-
tivo e incremental, el modelo en espiral, el modelo basado en prototipo, el
modelo SLCD, el MBASE, el RUP, etc.
Del modelo en espiral desarrollado por Barry Boehm surgi una de las ideas
fundamentales que las metodologas posteriores adoptaran: el temprano an-
lisis de riesgos. El modelo en espiral, de carcter iterativo en sus primeras
fases, plantea la necesidad de realizar al principio diversas iteraciones dirigi-
das a mitigar los riesgos ms crticos relevados en el proyecto mediante la
realizacin de prototipos o simulaciones de tipo desechables tendientes a pro-
bar algn concepto.
Una vez que esos prototipos son validados se suceden iteraciones del tipo:
determinar objetivos, evaluar, desarrollar y planear. Una vez que se tena el
diseo detallado y validado por el cliente, se implementaba el software si-
guiendo las etapas de un modelo en cascada. Esta es una falla importante del
modelo ya que no se acomoda a la posibilidad de cambios una vez que se
inicia la construccin. Todas las crticas que se le hacan al modelo en cascada
se aplican a estas fases del modelo en espiral.
30
Fue el mismo Barry Boehm (1988), quien en un artculo describe tres hitos
crticos a ser utilizados en cualquier proyecto para poder planificar y controlar
el progreso del mismo, dando visibilidad a los interesados. Estos hitos estn
relacionados con las etapas de avance que se van dando a lo largo de un
proyecto de acuerdo a como ocurren las actividades de ingeniera (que com-
ponen los espirales del modelo en espiral) a las actividades de produccin
(que componen la construccin en cascada del software). Su impacto en la
industria del software ha sido tan importante que uno de los procesos ms
utilizados en la actualidad, el RUP, los incorpora. Estos hitos son:
Objetivos del Ciclo de Vida.

Arquitectura del Ciclo de Vida.
Capacidad de Operacin Inicial.
El primer hito finaliza con la definicin del alcance del software a construir, la
identificacin de los interesados, y el delineamiento del plan de desarrollo del
sistema. El mismo ocurre al final de la fase de Concepcin segn el RUP.
El segundo hito finaliza con el delineamiento de la arquitectura del sistema, la

resolucin de todos los riesgos crticos del proyecto, y el refinamiento de los
objetivos y el alcance del sistema. A partir de este hito, se comienza la cons-
truccin en forma masiva del sistema, llegndose a utilizar el mximo de re-
cursos en el proyecto.
Asimismo, comienzan las fases ms predecibles en cierta medida del desarro-

llo. El mismo corresponde al hito final de la fase de Elaboracin segn el RUP.
El ltimo de los hitos corresponde a la entrega del primer release del soft-
ware, que incorpora la funcionalidad definida en la correspondiente iteracin.
Tambin se espera el tener material de entrenamiento, como un Manual del

Usuario y Manual de Operaciones. Este hito se corresponde con el hito final
de la fase de Construccin segn el RUP. Lo que result interesante de estos
hitos propuestos por Boehm es que los mismos son independientes del pro-
ceso de desarrollo elegido.
Como se ha mencionado, uno de los procesos con ms influencia en la comu-

nidad del software ha sido el RUP, el cual, es uno de los primeros procesos
que es vendido como un producto. La idea de los creadores del RUP es que el
mismo fuera un repositorio de todas las ideas vigentes y las denominadas
buenas prcticas de la Ingeniera de Software. Sin embargo, al intentar abar-
car proyectos de envergaduras tan dispares como podran ser la construccin
de un sistema de radares para portaviones versus la construccin de una re-
gistracin de usuarios para una pequea consultora, el RUP pierde la granu-
laridad necesaria para describir en detalle uno de los factores ms trascen-
dentes de cualquier desarrollo de software: las personas.
Esta es una de las razones principales del advenimiento de las denominadas

Metodologas giles.
31
1.2.El gran inters por gil
Los rpidos cambios en la tecnologa, las demandas y expectativas del mer-

cado han creado grandes desafos en relacin a los productos y servicios en
desarrollo que usan los modelos tradicionales de gestin de proyectos. Esto
abri el camino para la conceptualizacin e implementacin de mtodos y va-
lores giles en muchas organizaciones. Los modelos de desarrollo gil atien-
den las deficiencias asociadas con los modelos tradicionales de gestin de pro-
yectos para satisfacer las crecientes demandas ambientales y expectativas
que las organizaciones encaran. Dado a que los modelos tradicionales de ges-
tin de proyectos en general hacen hincapi en una amplia planificacin por
adelantada y que se ajustan al plan una vez que se establece, tales modelos
no tuvieron xito al encarar la realidad de los frecuentes cambios ambientales.
gil se basa en la planificacin de adaptacin y en el desarrollo y la entrega

iterativa. Se centra principalmente en que las personas hagan el trabajo con
eficacia. Aunque las metodologas adaptivas e incrementales han existido
desde la dcada de 1950, slo las metodologas que se ajustan al Manifiesto
gil son generalmente consideradas verdaderamente como "gil".
2. Manifiesto gil.
En febrero del 2001, un grupo de 17 gurs de la informtica, desarrolladores de

software y administradores se reunieron para discutir los mtodos de desarrollo
de software de peso ligero. Formaron Agile Alliance y las deliberaciones de esas
reuniones ms tarde dieron lugar al Manifesto for Agile Software Development.
El manifiesto fue escrito por Fowler y Highsmith (2001) y luego fue firmado por
todos los participantes para establecer los lineamientos bsicos para cualquier
metodologa gil.
El propsito de The Agile Manifesto fue distribuido de la siguiente manera:
Estamos descubriendo mejores formas de desarrollar
software hacindolo y ayudando a que otros lo hagan.
A travs de este trabajo hemos llegado a valorar:
32
Grfico N 01 5: Manifiesto gil
Fuente: Elaboracin propia
Es decir, mientras que hay valor en los elementos de

la derecha, valoramos ms los elementos a la izquierda.
Las cuatro compensaciones de The Agile Manifesto se elaboran de la siguiente

manera:
a. Individuos e interacciones sobre procesos y herramientas
Aunque los procesos y las herramientas ayudan a completar con xito un pro-
yecto, son las personas que se dedican, participan, determinar qu procesos
y herramientas se han de utilizar e implementan un proyecto. Los principales
en cualquier proyecto son, por lo tanto, los individuos, por lo que el nfasis
debe estar en ellos y sus interacciones, en lugar de poner nfasis en procesos
e herramientas complicados.
b. Software de buen rendimiento sobre la documentacin detallada

Aunque la documentacin es necesaria y til para cualquier proyecto, muchos
equipos se centran en la recopilacin y el registro de las descripciones cuali-
tativas y cuantitativas de los entregables, cuando el valor real que se le en-
trega al cliente es en forma de un software de buen rendimiento. Por lo tanto,
el enfoque gil se encuentra en la entrega de un software de buen funciona-
miento en incrementos a lo largo del ciclo de vida del producto en lugar de la
documentacin detallada.
c. Colaboracin con el Cliente sobre la negociacin del contrato

Tradicionalmente, los clientes han sido vistos como participantes exteriores
que estn envueltos principalmente al inicio y al final del ciclo de vida del
producto y cuyas relaciones se basaban en contratos y el cumplimiento de
stos. gil cree en un enfoque de valor compartido en el que los clientes son
33
vistos como colaboradores. El equipo de desarrollo y el cliente trabajan juntos
para evolucionar y desarrollar el producto.
d. Responder al cambio en vez de seguir un plan

En el mercado actual en el que los requisitos del cliente, las tecnologas dis-
ponibles, y los patrones de negocio estn cambiando constantemente, es
esencial abordar el desarrollo de productos de una manera adaptativa que
permita la incorporacin de cambios y los ciclos de vida de desarrollo de pro-
ductos de forma rpida, en lugar de enfatizar el concepto de seguir planes que
fueron creados quizs con datos obsoletos.
3. Principios giles.
Los 12 principios del Agile Manifesto (Manifiesto gil) por Fowler y Highsmith
(2001) son los siguientes:
I. Nuestra mxima prioridad es satisfacer al cliente a travs de la entrega tem-
prana y continua de un software de gran utilidad.
II. Darles la bienvenida a requisitos cambiantes incluso tarde en el desarrollo.
Los procesos giles aprovechan el cambio y lo transforman en una ventaja
competitiva para el cliente.
III. Entregar software de buen funcionamiento con frecuencia, a partir de un par
de semanas a un par de meses, con una preferencia por el tiempo ms corto.
IV. La gente de negocios y los desarrolladores deben trabajar juntos todos los
das durante todo el proyecto.
V. Construir proyectos alrededor de individuos motivados, darles el entorno y el
apoyo que necesitan y confiar en ellos para hacer el trabajo.
VI. El mtodo ms eficiente y eficaz de comunicacin con y dentro de un equipo
de desarrollo es cara a cara.
VII. Un software funcional es la medida de progreso principal.
VIII. Los procesos giles promueven el desarrollo sostenible. Los patrocinadores,
desarrolladores y usuarios deben ser capaces de mantener un ritmo constante
de forma indefinida.
IX. La atencin continua a la excelencia tcnica y el buen diseo mejora la agili-
dad.
X. Simplicidad el arte de maximizar la cantidad de trabajo no realizadoes
esencial.
XI. Las mejores arquitecturas, requisitos y diseos emergen de equipos auto-or-
ganizados.
XII. En intervalos regulares, el equipo reflexiona sobre cmo ser ms eficaz, y en
base a eso ajusta su comportamiento.
4. Declaracin de Interdependencia.
La gestin de proyectos Agile Declaration of Interdependence (Declaracin de in-
dependencia) fue escrita a principios del 2005 por un grupo de 15 lderes de
proyectos como un suplemento a El Manifiesto gil.
34
Enumera seis valores de gestin necesarios para reforzar una mentalidad de
desarrollo gil, particularmente en la gestin de proyectos complejos e inciertos.
La declaracin destaca que los equipos de proyectos, clientes y otros interesados
son interdependientes y estn conectados, algo que deben reconocer para tener
xito. Los valores tambin son interdependientes.
Nosotros...
Aumentamos el Return on Investiment, al enfocarnos en el flujo continuo
de valor.
Ofrecemos resultados fiables mediante la participacin de clientes en las
interacciones frecuentes, donde tambin son responsables por el trabajo.
Asumimos que habr incertidumbre y las superamos a travs de iteracio-
nes, anticipacin y adaptacin.
Damos rienda suelta a la creatividad y la innovacin al reconocer que
las personas son la fuente mxima de valor y creamos un entorno en el que
puedan tener un impacto positivo.
Aumentamos el rendimiento a travs de la rendicin de cuentas por parte
del grupo en cuestin de resultados y eficacia del equipo, responsabilidades
que todos comparten.
Mejoramos la eficacia y la fiabilidad a travs de estrategias situacional-
mente especficas, procesos y prcticas.
(Anderson. D., Augustine, S., Avery, C., Cockburn, A., Cohn, M., et al. 2005).
35
TEMA N 4: FUNDAMENTOS DE SCRUM
INTRODUCCIN
De acuerdo al SBOK, un proyecto Scrum implica un esfuerzo de colaboracin para
crear un nuevo producto, servicio, o cualquier otro resultado como se define en el
Declaracin de la Visin del Proyecto. Los proyectos se ven afectados por las limita-
ciones de tiempo, costo, alcance, calidad, recursos, capacidades organizativas, y
otras limitaciones que los hacen difciles de planificar, ejecutar, administrar y final-
mente tener xito. Sin embargo, la implementacin exitosa de los resultados de un
proyecto acabado le proporciona ventajas econmicas significativas a una organiza-
cin. Por lo tanto, es importante que las organizaciones seleccionen y practiquen una
metodologa adecuada de gestin de proyectos.
Scrum es una de las metodologas giles ms populares. Es una metodologa de
adaptacin, iterativa, rpida, flexible y eficaz, diseada para ofrecer un valor signifi-
cativo de forma rpida en todo el proyecto.
Scrum garantiza transparencia en la comunicacin y crea un ambiente de responsa-
bilidad colectiva y de progreso continuo. El marco de Scrum, tal como se define en
la Gua SBOK, est estructurado de tal manera que es compatible con los productos
y el desarrollo de servicio en todo tipo de industrias y en cualquier tipo de proyecto,
independientemente de su complejidad.
Una fortaleza clave de Scrum radica en el uso de equipos multifuncionales, auto-
organizados, y con poder que dividen su trabajo en ciclos de trabajo cortos y con-
centrados llamados Sprints.
En los siguientes prrafos se explicar a detalle el marco de trabajo Scrum.
1. Visin General de Scrum.

Scrum es en marco de trabajo por el cual las personas pueden acometer proble-
mas complejos adaptativos, a la vez que entregar productos del mximo valor
posible productiva y creativamente. Scrum es:
Ligero,
Fcil de entender, y
Extremadamente difcil de llegar a dominar.
Scrum, es un marco de trabajo de procesos que ha sido usado para gestionar el

desarrollo de productos complejos desde principios de los aos 90. Scrum no es
un proceso o una tcnica para construir productos; en lugar de eso, es un marco
de trabajo dentro del cual se pueden emplear varias tcnicas y procesos. Scrum
muestra la eficacia relativa de las prcticas de gestin de producto y las prcticas
de desarrollo, de modo que podamos mejorar.
El marco de trabajo Scrum consiste en los Equipos Scrum, roles, eventos, arte-
factos y reglas asociadas. Cada componente dentro del marco de trabajo sirve a
un propsito especfico y es esencial para el xito de Scrum y para su uso.
Las reglas de Scrum relacionan los eventos, roles y artefactos, gobernando las
relaciones e interacciones entre ellos. Las reglas de Scrum se describen en el
presente documento.
Las estrategias especficas para usar el marco de trabajo Scrum son diversas y
estn descritas en otros lugares.
36
2. Teora de Scrum.
Scrum se basa en la teora de control de procesos emprica o empirismo. El em-
pirismo asegura que el conocimiento procede de la experiencia y de tomar deci-
siones basndose en lo que se conoce. Scrum emplea un enfoque iterativo e in-
cremental para optimizar la predictibilidad y el control del riesgo.
Tres pilares soportan toda la implementacin del control de procesos emprico:
transparencia, inspeccin y adaptacin.
a. Transparencia
Los aspectos significativos del proceso deben ser visibles para aquellos que
son responsables del resultado. La transparencia requiere que dichos aspectos
sean definidos por un estndar comn, de tal modo que los observadores
compartan un entendimiento comn de lo que se est viendo.
Por ejemplo:
Todos los participantes deben compartir un lenguaje comn para referirse
al proceso; y,
Aquellos que desempean el trabajo y aquellos que aceptan el producto
de dicho trabajo deben compartir una definicin comn de Terminado 1.
b. Inspeccin
Los usuarios de Scrum deben inspeccionar frecuentemente los artefactos de
Scrum y el progreso hacia un objetivo, para detectar variaciones. Su inspec-
cin no debe ser tan frecuente como para que interfiera en el trabajo. Las
inspecciones son ms beneficiosas cuando se realizan de forma diligente por
inspectores expertos, en el mismo lugar de trabajo.
c. Adaptacin
Si un inspector determina que uno o ms aspectos de un proceso se desvan
de lmites aceptables, y que el producto resultante no ser aceptable, el pro-
ceso o el material que est siendo procesado deben ser ajustados. Dicho
ajuste debe realizarse cuanto antes para minimizar desviaciones mayores.
Scrum prescribe cuatro eventos formales, contenidos dentro del Sprint, para
la inspeccin y adaptacin, tal y como se describen en la seccin Eventos de
Scrum del presente documento.
Reunin de Planificacin del Sprint (Sprint Planning Meeting),
Scrum Diario (Daily Scrum),
Revisin del Sprint (Sprint Review), y
Retrospectiva del Sprint (Sprint Retrospective).
3. El Equipo Scrum (Scrum Team).

El Equipo Scrum consiste en un Dueo de Producto (Product Owner), el Equipo
de Desarrollo (Development Team) y un Scrum Master. Los Equipos Scrum son
autos organizados y multifuncionales. Los equipos auto organizados eligen la me-
jor forma de llevar a cabo su trabajo y no son dirigidos por personas externas al
equipo. Los equipos multifuncionales tienen todas las competencias necesarias
para llevar a cabo el trabajo sin depender de otras personas que no son parte del
equipo. El modelo de equipo en Scrum est diseado para optimizar la flexibilidad,
la creatividad y la productividad.
37
Los Equipos Scrum entregan productos de forma iterativa e incremental, maxi-
mizando las oportunidades de obtener retroalimentacin. Las entregas incremen-
tales de producto Terminado aseguran que siempre estar disponible una ver-
sin potencialmente til y funcional del producto.
3.1.El Dueo de Producto (Product Owner)

El Dueo de Producto es el responsable de maximizar el valor del producto y
del trabajo del Equipo de Desarrollo. El cmo se lleva a cabo esto podra
variar ampliamente entre distintas organizaciones, Equipos Scrum e indivi-
duos.
El Dueo de Producto es la nica persona responsable de gestionar la Lista
del Producto (Product Backlog).
El Dueo de Producto podra hacer el trabajo anterior, o delegarlo en el
Equipo de Desarrollo. Sin embargo, en ambos casos el Dueo de Producto
sigue siendo el responsable de dicho trabajo.
El Dueo de Producto es una nica persona, no un comit. El Dueo de Pro-
ducto podra representar los deseos de un comit en la Lista del Producto,
pero aquellos que quieran cambiar la prioridad de un elemento de la Lista
deben hacerlo a travs del Dueo de Producto.
Para que el Dueo de Producto pueda hacer bien su trabajo, toda la organi-
zacin debe respetar sus decisiones. Las decisiones del Dueo de Producto
se reflejan en el contenido y en la priorizacin de la Lista del Producto. No
est permitido que nadie pida al Equipo de Desarrollo que trabaje con base
en un conjunto diferente de requerimientos, y el Equipo de Desarrollo no
debe actuar con base en lo que diga cualquier otra persona.
3.2.El Equipo de Desarrollo (Development Team)

El Equipo de Desarrollo consiste en los profesionales que desempean el tra-
bajo de entregar un Incremento de producto Terminado, que potencial-
mente se pueda poner en produccin, al final de cada Sprint. Solo los miem-
bros del Equipo de Desarrollo participan en la creacin del Incremento.
Los Equipos de Desarrollo son estructurados y empoderados por la organiza-
cin para organizar y gestionar su propio trabajo. La sinergia resultante op-
timiza la eficiencia y efectividad del Equipo de Desarrollo.
Tamao del Equipo de Desarrollo

El tamao ptimo del Equipo de Desarrollo es lo suficientemente pequeo
como para permanecer gil y lo suficientemente grande como para completar
una cantidad de trabajo significativa. Tener menos de tres miembros en el
Equipo de Desarrollo reduce la interaccin y resulta en ganancias de produc-
tividad ms pequeas. Los Equipos de Desarrollo ms pequeos podran en-
contrar limitaciones en cuanto a las habilidades necesarias durante un Sprint,
haciendo que el Equipo de Desarrollo no pudiese entregar un Incremento que
potencialmente se pueda poner en produccin. Tener ms de nueve miem-
bros en el equipo requiere demasiada coordinacin. Los Equipos de Desarrollo
grandes generan demasiada complejidad como para que pueda gestionarse
mediante un proceso emprico. Los roles de Dueo de Producto y Scrum Mas-
ter no cuentan en el clculo del tamao del equipo a menos que tambin
estn contribuyendo a trabajar en la Lista de Pendientes de Sprint (Sprint
Backlog).
38
3.3.El Scrum Master
El Scrum Master es el responsable de asegurar que Scrum es entendido y
adoptado. Los Scrum Masters hacen esto asegurndose de que el Equipo
Scrum trabaja ajustndose a la teora, prcticas y reglas de Scrum.
El Scrum Master es un lder que est al servicio del Equipo Scrum. El Scrum
Master ayuda a las personas externas al Equipo Scrum a entender qu inter-
acciones con el Equipo Scrum pueden ser de ayuda y cules no. El Scrum
Master ayuda a todos a modificar estas interacciones para maximizar el valor
creado por el Equipo Scrum.
4. Eventos de Scrum
En Scrum existen eventos predefinidos con el fin de crear regularidad y minimizar
la necesidad de reuniones no definidas en Scrum. Todos los eventos son bloques
de tiempo (time-boxes), de tal modo que todos tienen una duracin mxima. Una
vez que comienza un Sprint, su duracin es fija y no puede acortarse o alargarse.
Los dems eventos pueden terminar siempre que se alcance el objetivo del
evento, asegurando que se emplee una cantidad apropiada de tiempo sin permitir
desperdicio en el proceso.
Adems del propio Sprint, que es un contenedor del resto de eventos, cada uno
de los eventos de Scrum constituye una oportunidad formal para la inspeccin y
adaptacin de algn aspecto. Estos eventos estn diseados especficamente
para habilitar las vitales transparencia e inspeccin. La falta de alguno de estos
eventos da como resultado una reduccin de la transparencia y constituye una
oportunidad perdida para inspeccionar y adaptarse.
4.1.El Sprint
El corazn de Scrum es el Sprint, es un bloque de tiempo (time-box) de un
mes o menos durante el cual se crea un incremento de producto Terminado,
utilizable y potencialmente desplegable. Es ms conveniente si la duracin
de los Sprints es consistente a lo largo del esfuerzo de desarrollo. Cada nuevo
Sprint comienza inmediatamente despus de la finalizacin del Sprint previo.
Los Sprints contienen y consisten de la Reunin de Planificacin del Sprint
(Sprint Planning Meeting), los Scrums Diarios (Daily Scrums), el trabajo de
desarrollo, la Revisin del Sprint (Sprint Review), y la Retrospectiva del Sprint
(Sprint Retrospective).
4.2.Reunin de Planificacin de Sprint (Sprint Planning Meeting)

El trabajo a realizar durante el Sprint se planifica en la Reunin de Planifica-
cin de Sprint. Este plan se crea mediante el trabajo colaborativo del Equipo
Scrum completo.
La Reunin de Planificacin de Sprint tiene un mximo de duracin de ocho
horas para un Sprint de un mes. Para Sprints ms cortos, el evento es usual-
mente ms corto. El Scrum Master se asegura de que el evento se lleve a
cabo y que los asistentes entiendan su propsito. El Scrum Master ensea al
Equipo Scrum a mantenerse dentro del bloque de tiempo.
4.3.Objetivo del Sprint (Sprint Goal)
39
El Objetivo del Sprint es una meta establecida para el Sprint que puede ser
alcanzada mediante la implementacin de la Lista de Producto. Proporciona
una gua al Equipo de Desarrollo acerca de por qu est construyendo el
incremento. Es creado durante la reunin de Planificacin del Sprint. El obje-
tivo del Sprint ofrece al equipo de desarrollo cierta flexibilidad con respecto
a la funcionalidad implementada en el Sprint. Los elementos de la Lista del
Producto seleccionados ofrecen una funcin coherente, que puede ser el ob-
jetivo del Sprint. El objetivo del Sprint puede representar otro nexo de unin
que haga que el Equipo de Desarrollo trabaje en conjunto y no en iniciativas
separadas.
A medida que el equipo de desarrollo trabaja, se mantiene el objetivo del
Sprint en mente. Con el fin de satisfacer el objetivo del Sprint se implementa
la funcionalidad y la tecnologa. Si el trabajo resulta ser diferente de lo que
el Equipo de Desarrollo espera, ellos colaboran con el Dueo del Producto
para negociar el alcance de la Lista de pendientes del Sprint (Sprint Backlog).
4.4.Scrum Diario (Daily Scrum)

El Scrum Diario es una reunin con un bloque de tiempo de 15 minutos para
que el Equipo de Desarrollo sincronice sus actividades y cree un plan para las
siguientes 24 horas. Esto se lleva a cabo inspeccionando el trabajo avanzado
desde el ltimo Scrum Diario y haciendo una proyeccin acerca del trabajo
que podra completarse antes del siguiente.
El Scrum Diario se realiza a la misma hora y en el mismo lugar todos los das
para reducir la complejidad. Durante la reunin, cada miembro del Equipo de
Desarrollo explica:
Qu hice ayer que ayud al Equipo de Desarrollo a lograr el Objetivo del
Sprint?
Qu har hoy para ayudar al Equipo de Desarrollo a lograr el Objetivo
del Sprint?
Veo algn impedimento que evite que el Equipo de Desarrollo o yo lo-
gremos el Objetivo del Sprint?
4.5.Revisin de Sprint (Sprint Review)

Al final del Sprint se lleva a cabo una Revisin de Sprint para inspeccionar el
Incremento y adaptar la Lista de Producto si fuese necesario. Durante la Re-
visin de Sprint, el Equipo Scrum y los interesados colaboran acerca de lo
que se hizo durante el Sprint. Basndose en esto, y en cualquier cambio a la
Lista de Producto durante el Sprint, los asistentes colaboran para determinar
las siguientes cosas que podran hacerse para optimizar el valor. Se trata de
una reunin informal, no una reunin de seguimiento, y la presentacin del
Incremento tiene como objetivo facilitar la retroalimentacin de informacin
y fomentar la colaboracin.
Se trata de una reunin restringida a un bloque de tiempo de cuatro horas
para Sprints de un mes. Para Sprints ms cortos, se reserva un tiempo pro-
porcionalmente menor. El Scrum Master se asegura de que el evento se lleve
a cabo y que los asistentes entiendan su propsito. El Scrum Master ensea
a todos a mantener el evento dentro del bloque de tiempo fijado.
4.6.Retrospectiva de Sprint (Sprint Retrospective)
40
La Retrospectiva de Sprint es una oportunidad para el Equipo Scrum de ins-
peccionarse a s mismo y crear un plan de mejoras que sean abordadas du-
rante el siguiente Sprint.
La Retrospectiva de Sprint tiene lugar despus de la Revisin de Sprint y
antes de la siguiente Reunin de Planificacin de Sprint. Se trata de una
reunin restringida a un bloque de tiempo de tres horas para Sprints de un
mes. Para Sprints ms cortos se reserva un tiempo proporcionalmente me-
nor. El Scrum Master se asegura de que el evento se lleve a cabo y que los
asistentes entiendan su propsito. El Scrum Master ensea a todos a mante-
ner el evento dentro del bloque de tiempo fijado. El Scrum Master participa
en la reunin como un miembro del equipo ya que la responsabilidad del
proceso Scrum recae sobre l.
5. Artefactos de Scrum
Los artefactos de Scrum representan trabajo o valor en diversas formas que son
tiles para proporcionar transparencia y oportunidades para la inspeccin y adap-
tacin. Los artefactos definidos por Scrum estn diseados especficamente para
maximizar la transparencia de la informacin clave, que es necesaria para ase-
gurar que todos tengan el mismo entendimiento del artefacto.
5.1.Lista de Producto (Product Backlog)

La Lista de Producto es una lista ordenada de todo lo que podra ser necesario
en el producto, y es la nica fuente de requisitos para cualquier cambio a
realizarse en el producto. El Dueo de Producto (Product Owner) es el res-
ponsable de la Lista de Producto, incluyendo su contenido, disponibilidad y
ordenacin.
Una Lista de Producto nunca est completa. El desarrollo ms temprano de
la misma solo refleja los requisitos conocidos y mejor entendidos al principio.
La Lista de Producto evoluciona a medida que el producto y el entorno en el
que se usar tambin lo hacen. La Lista de Producto es dinmica; cambia
constantemente para identificar lo que el producto necesita para ser ade-
cuado, competitivo y til. Mientras el producto exista, su Lista de Producto
tambin existe.
La Lista de Producto enumera todas las caractersticas, funcionalidades, re-
quisitos, mejoras y correcciones que constituyen cambios a ser hechos sobre
el producto para entregas futuras. Los elementos de la Lista de Producto
tienen como atributos la descripcin, la ordenacin, la estimacin y el valor.
5.2.Lista de Pendientes del Sprint (Sprint Backlog)

La Lista de Pendientes del Sprint es el conjunto de elementos de la Lista de
Producto seleccionados para el Sprint, ms un plan para entregar el Incre-
mento de producto y conseguir el Objetivo del Sprint. La Lista de Pendientes
del Sprint es una prediccin hecha por el Equipo de Desarrollo acerca de qu
funcionalidad formar parte del prximo Incremento y del trabajo necesario
para entregar esa funcionalidad en un Incremento Terminado.
La Lista de Pendientes del Sprint hace visible todo el trabajo que el Equipo
de Desarrollo identifica como necesario para alcanzar el Objetivo del Sprint.
41
5.3.Incremento
El Incremento es la suma de todos los elementos de la Lista de Producto
completados durante un Sprint y el valor de los incrementos de todos los
Sprints anteriores. Al final de un Sprint, el nuevo Incremento debe estar Ter-
minado, lo cual significa que est en condiciones de ser utilizado y que cum-
ple la Definicin de Terminado del Equipo Scrum. El incremento debe estar
en condiciones de utilizarse sin importar si el Dueo de Producto decide libe-
rarlo o no.
6. Transparencia de los Artefactos

Scrum se basa en la transparencia. Las decisiones para optimizar el valor y con-
trolar el riesgo se toman basadas en el estado percibido de los artefactos. En la
medida en que la transparencia sea completa, estas decisiones tienen unas bases
slidas. En la medida en que los artefactos no son completamente transparentes,
estas decisiones pueden ser errneas, el valor puede disminuir y el riesgo puede
aumentar.
El Scrum Master debe trabajar con el Dueo de Producto, el Equipo de Desarrollo
y otras partes involucradas para entender si los artefactos son completamente
transparentes. Hay prcticas para hacer frente a la falta de transparencia; el
Scrum Master debe ayudar a todos a aplicar las prcticas ms apropiadas si no
hay una transparencia completa. Un Scrum Master puede detectar la falta de
transparencia inspeccionando artefactos, reconociendo patrones, escuchando
atentamente lo que se dice y detectando diferencias entre los resultados espera-
dos y los reales.
La labor del Scrum Master es trabajar con el Equipo Scrum y la organizacin para
mejorar la transparencia de los artefactos. Este trabajo usualmente incluye
aprendizaje, conviccin y cambio. La transparencia no ocurre de la noche a la
maana, sino que es un camino.
42
DST SYSTEMS GANA CON SCRUM Y LA ADMINISTRACIN DEL
CICLO DE VIDA DE LAS APLICACIONES
Sistemas de Informacin Gerencial, LAUDON, K.C. & LAUDON, J.P., 2012, pginas
547 548
como una cascada; cada uno de estos

Las compaas como DST Systems han
pasos no puede empezar sino hasta
reconocido el valor en el desarrollo
que se haya completado el paso ante-
Scrum para sus resultados netos, pero
rior. Aunque DST haba utilizado antes
realizar la transicin de los mtodos de
este mtodo con muy buenos resulta-
desarrollo tradicionales al desarrollo
dos, empez a buscar alternativas via-
Scrum puede ser un desafo. DST Sys-
bles. El grupo de desarrollo empez a
tems es una compaa de desarrollo de
explorar Scrum, un marco de trabajo
software cuyo producto insignia, Auto-
para el desarrollo gil de software en
mated Work Distributor (AWD), incre-
donde los proyectos progresan a travs
menta la eficiencia del apoyo de la
de una serie de iteraciones conocidas
parte administrativa y ayuda a que las
como sprints. Los proyectos de
oficinas dejen de usar papel. DST se
Scrum progresan en una serie de
fund en 1969 y tiene sus oficinas ge-
sprints, que son iteraciones con una
nerales en Kansas City, Missouri. La
duracin fija de no ms de un mes. Al
compaa tiene cerca de 10 000 em-
inicio de un sprint, los miembros del
pleados, de los cuales 1 200 son desa-
equipo se comprometen a entregar
rrolladores de software. Este grupo de
cierto nmero de caractersticas que se
desarrollo haba utilizado una mezcla
mencionan en la lista de espera de pro-
de herramientas, procesos y sistemas
ductos del proyecto. Se supone que es-
de control de cdigo fuente sin ningn
tas caractersticas deben estar comple-
almacn unificado para el cdigo o un
tas al final del sprint: codificadas, pro-
conjunto de herramientas estandariza-
badas e integradas en el producto o
das para los desarrolladores. Los dis-
sistema en desarrollo. Al final del
tintos grupos dentro de la organizacin
sprint, un revisor de sprints permite al
utilizaban herramientas muy diferen-
equipo demostrar la nueva funcionali-
tes para el desarrollo de software,
dad al propietario del producto y a
como Serena PVCS, Eclipse u otros pa-
otras partes interesadas, con el fin de
quetes de cdigo abierto. A menudo los
que provean retroalimentacin que
procesos eran manuales y consuman
pueda influir en el siguiente sprint.
mucho tiempo. Para los gerentes no
Scrum se basa en equipos auto organi-
era fcil determinar cmo se asignaban
zados y multifuncionales apoyados por
los recursos, qu empleados trabaja-
un ScrumMaster y el propietario del
ban en ciertos proyectos o el estado de
producto. El ScrumMaster acta como
ciertos activos especficos. Todo esto
entrenador para el equipo, mientras
significaba que DST luchaba por actua-
que el propietario del producto repre-
lizar su producto ms importante,
senta a la empresa, los clientes o los
AWD, de una manera oportuna. Su
usuarios para guiar al equipo a que
programa comn de desarrollo era li-
construya el producto correcto. DST
berar una nueva versin una vez cada
prob la metodologa Scrum con sus
dos aos, pero los competidores esta-
herramientas de desarrollo de software
ban liberando versiones mucho antes
existentes y experiment resultados
que eso. DST saba que necesitaba
convincentes. La compaa aceler su
algo mejor que el tradicional mtodo
ciclo de desarrollo de software de 24 a
de cascada para disear, codificar,
6 meses y la productividad de los desa-
evaluar e integrar sus productos. En el
rrolladores aument un 20 por ciento,
modelo de cascada del desarrollo de
pero Scrum no funcion tan bien como
software, la progresin fluye de ma-
nera secuencial de un paso al siguiente
43
DST haba esperado con sus herra- de los proyectos almacenada en forma
mientas existentes. Los procesos co- de archivos. DST adopt en tan slo 10
lapsaron y la falta de estandarizacin semanas los productos de CollabNet;
entre las herramientas y procesos uti- ahora los desarrolladores de DST reali-
lizados por DST evit que Scrum pu- zan todo su trabajo dentro de esta pla-
diera proveer su mximo beneficio taforma de ALM. Nadie oblig a los
para la compa- a. DST necesitaba un desarrolladores a usar TeamForge,
producto de administracin del ciclo de sino que la plataforma de ALM era tan
vida (ALM) que pudiera unificar su en- atractiva en comparacin con el en-
torno de desarrollo de software. DST torno anterior de DST que los desarro-
estableci un equipo de evaluacin de lladores adoptaron el producto en
proyectos para identificar el entorno de forma viral. Jerry Tubbs, el gerente de
desarrollo apropiado. Los factores desarrollo de sistemas en DST Sys-
clave fueron la rentabilidad, facilidad tems, dice que DST tuvo xito en sus
de adopcin y la efectividad de las ca- intentos por modernizar su grupo de
ractersticas. DST quera la habilidad software debido a unos cuantos facto-
de usar el nuevo software sin necesi- res. En primer lugar, busc la simpleza
dad de una capacitacin considerable, en vez de los ofrecimientos complica-
adems de poder adoptar el software dos que se hacen cargo de todo. Bus-
con rapidez sin poner en riesgo el ciclo car lo ms simple no slo era mejor
de desarrollo de AWD. Despus de con- para DST; tambin era menos costoso
siderar varios productos de ALM y de que algunas de las alternativas. DST
llevar a cabo proyectos de prueba con tambin involucr a los desarrolladores
cada uno, DST se decidi por Team- en el proceso de toma de decisiones
Forge, el ofrecimiento de CollabNet, para asegurar que los cambios se reci-
para su plataforma de ALM. CollabNet bieran con entusiasmo. Por ltimo, al
se especializa en software diseado permitir que los desarrolladores adop-
para funcionar bien con los mtodos de taran el software de ALM por su
desarrollo gil de software tales como cuenta, DST evit el resentimiento
Scrum. Su producto bsico es Team- asociado con un cambio forzoso inde-
Forge, una suite integrada de herra- seado. El cambio de DST del desarrollo
mientas de desarrollo y colaboracin en cascada a Scrum fue un xito,
basadas en Web para el desarrollo gil puesto que la compaa seleccion el
de software, la cual centraliza la admi- marco de trabajo de desarrollo co-
nistracin de usuarios, proyectos, pro- rrecto adems del software apropiado
cesos y activos. DST tambin adopt el para convertir ese cambio en realidad,
producto Subversion de CollabNet para y logr manejar con destreza el pro-
que ayudara con la administracin y el ceso de cambio.
control de los cambios en los documen-
tos, programas y dems informacin
Fuentes: Jerry Tubbs, Team Building Goes Viral, Information Week, 22 de febrero de 2010, www.co-
llab.net, visitado en agosto de 2010, Mountain Goat Software, Introduction to Scrum An Agile Process,
www.mountaingoatsoftware.com/topics/scrum, visitado en agosto de 2010.
44
GLOSARIO DE LA UNIDAD
1. Caracterstica. Funcionalidad simple y poco costosa de desarrollar que aporta

valor al cliente del software a utilizar.
2. Historias de usuario. Descripciones cortas de la usabilidad y funcionalidad que

se espera del sistema, escritas por el cliente final, en su lenguaje y sin tecnicis-
mos.
3. Manifiesto gil. Manifiesto que recoge los valores que deberan cumplir las me-
todologas de desarrollo de software. Fue firmado por Kent Beck, Mike Beedle,
Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James
Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Ro-
bert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland y Dave Thomas.
4. Metfora del negocio. Historia comn compartida por el usuario y el equipo de

desarrollo que describe cmo deben comportarse las diferentes partes del sistema
que se quiere implementar.
5. Metodologas giles. Metodologas que cumplen el manifiesto gil.
6. Refactorizacin. Modificar el cdigo para dejarlo en buen estado, volviendo a

escribir las partes que sean necesarias, pero siempre desde un punto de vista
global a la funcionalidad independientemente del cambio que hagamos.
7. Spike arquitectnico. Periodo durante el cual el equipo de desarrollo, prueba la

tecnologa y se familiariza con la metodologa que se aplicar durante el proyecto.
8. Test de aceptacin. Test creado conjuntamente con el cliente final que debe
reflejar las necesidades funcionales del primero.
9. Test de integridad. Test creado por el equipo de desarrollo para probar que
todo el conjunto funciona correctamente con la nueva modificacin.
10. Test unitario. Test creado por el programador para ver que todos los mtodos
de la clase funcionan correctamente.
45
BIBLIOGRAFA
Project Management Institute. (2013). Gua de los Fundamentos para la Direc-

cin de Proyectos (5ta ed.). EEUU: PMI.
SCRUMstudy. (2013). Una gua para el conocimiento de SCRUM (ed. 2013).
EEUU: SCRUMstudy.
Laudon, K.C., & Laudon, J.P. (2012). Sistemas de Informacin Gerencial (12da
ed.). Mxico: Pearson.
Schwaber, K. & Sutherland, J. (2013). La Gua Definitiva de SCRUM: Las Reglas
del Juego.
Office of Government Commerce. (2009). xito en la Gestin de Proyectos con
PRINCE2 (9na ed.). The Stationery Office.
Kerzner, H.D. (2013). Project Management: A Systems Approach to Planning,
Scheduling, and Controlling (11th ed.). John Wiley & Sons.
Fernndez, J. (s.f.). Introduccin a las Metodologas giles: Otras formas de ana-
lizar y desarrollar, Universitat Oberta de Catalunya.
Boehm, Barry W. (Mayo 1988). A Spiral Model of Software Development and
Enhancement, IEEE Computer, Vol.21, No 15, pp.61-72.
46
AUTOEVALUACIN No 1
1. En el comienzo de un proyecto, la definicin del problema:
A) Suele ser difuso.

B) Est claramente especificada.
C) Requiere mucho tiempo a pesar de no tener mucha trascendencia.
D) Todas las anteriores se dan.
2. Las fases genricas de un proyecto son:
A) Planeacin, codificacin y pruebas.

B) Puesta en marcha y conclusin del proyecto.
C) Planeacin y ejecucin del proyecto.
D) Todas las anteriores son correctas.
3. El software es:
A) Fcil de desarrollar y en pocas ocasiones se habla de proyectos fracasados.

B) Fcil de verificar por el usuario ya que este tiene visibilidad del mismo.
C) No suele ser complejo.
D) Todas las anteriores son incorrectas.
4. Cul de las siguientes NO es una fase de la Metodologa RUP?
A) Construccin.
B) Elaboracin.
C) Iniciacin.
D) Potenciacin.
5. Cul es el significado de las siglas RUP?
A) Relational Unified Programs.

B) Rational Underline Process.
C) Relational Unified Programs.
D)
E) Rational Unified Process.
6. Por qu es importante que el acta de constitucin del proyecto sea fir-

mada por una persona altamente ubicada en la organizacin?
A) Porque indica la importancia relativa y la prioridad del proyecto dentro de la

organizacin.
B) Porque proporciona autoridad al gerente del proyecto para cruzar lmites fun-
cionales cuando se est realizando planes y actividades del proyecto.
C) Porque da una mayor credibilidad frente a la gente que est fuera del pro-
yecto a la que se le puede pedir contribuir con recursos o unirse al equipo del
proyecto.
47
7. Un proyecto gil es:
A) Un desarrollo iterativo.
B) Un desarrollo en cascada con equipos auto organizados y colaborativos.
C) Una manera de enfocar el desarrollo software mediante un ciclo iterativo e
incremental, con equipos que trabajan de manera altamente colaborativa y
auto organizados.
D) Ninguna de las anteriores.
8. Las funciones del Product Owner son:
A) Tener una visin muy clara del producto que se quiere realizar, poder trans-
mitirlo al grupo de desarrollo y gestionar la comunicacin entre equipos y el
orden en el que se desarrollarn las tareas.
B) Ser el Jefe de Proyecto.
C) No son prioritarias sus funciones, es un elemento opcional en un proyecto gil.
9. Seleccione la opcin correcta sobre Scrum:
A) Se adapta de forma temprana a los cambios de requisitos.

B) Est especialmente indicado para proyectos sin cambio en los requisitos.
C) No se tiene en cuenta el valor aportado al cliente.
10.Elegir la afirmacin correcta:
A) No pueden existir dependencias entre historias de usuario.

B) Para mejorar la creatividad del equipo es necesario evitar la realizacin de
estimaciones.
C) El valor lo da el Product Owner.
48
49
UNIDAD II: INICIACIN DEL PROYECTO
DIAGRAMA DE PRESENTACIN DE LA UNIDAD II

3 Videoclase: 1. Reconoce la importan-
SELVV. (2013). Ideas de negocio, cia de la elaboracin de 1. Reconoce y
simples para ser exitosos. Recupe- entregables de la Fase describe la im-
rado de de Inicio del Proyecto. portancia de
https://www.youtube.com/watch? 2. Analiza los elementos implementar
v=cPfixZ0cqqI necesarios para la ela- una metodolo-
boracin de la idea del ga de gestin
Tema N 1: Seleccin de Pro- Proyecto. de proyectos
yectos en la empresa.
1. Estructura gerencial para los Actividad N 2 2. Reconoce y
proyectos de sistemas de infor- Desarrolla una idea de pro- describe la im-
macin. yecto teniendo en conside- portancia de la
2. Vinculacin de proyectos de racin los puntos descritos gestin de pro-
sistemas con el plan de nego- en la plantilla denominada yectos para
cios. Idea de Proyecto. una implemen-
3. Factores crticos de xito. tacin exitosa
4. Anlisis de cartera. 3. Fundamenta la impor- que conlleve al
5. Modelos de puntuacin. tancia de la elaboracin mejoramiento
de entregables de la de una em-
Lectura seleccionada 1. Fase de Inicio del Pro- presa y para
yecto. las actividades
Bolunta, Agencia para el volunta- o procesos a
riado y la participacin social Ma- 4. Comprende y disea los
elementos necesarios realizar.
nuales de Gestin: Cmo hacer 3. Fomenta el tra-
proyectos. SOLABARRIA, E., (s.f.), para la elaboracin del
Acta de Constitucin del bajo en equipo
pginas 1-21. aplicando tc-
Proyecto.
nicas y herra-
4 Videoclase: mientas de
PACHERRES, L. (2015). Desarro- Tarea Acadmica N 1
gestin de pro-
llar el Acta de Constitucin del Pro- Desarrolla el Acta de Cons- yectos para
yecto. Recuperado de: titucin del Proyecto de una consecu-
https://www.youtube.com/watch? acuerdo a los lineamientos cin de los ob-
v=l_gLbLrBrjk&index=13&list descritos en la plantilla de- jetivos organi-
=PLlpx2GAbD- nominada Acta de Consti- zacionales.
geigFQPvtSECcpI4ojCpGJKE
50
tucin del Proyecto, es- 4. Acta con tica
Tema N 2: Acta de Constitu- tructura basada en las bue- y basado en
cin del Proyecto nas prcticas descritas en valores.
1. Desarrollo del Acta de Consti- el PMBOK. 5. Desarrolla lide-
tucin del Proyecto: Entradas. razgo, capaci-
2. Desarrollo del Acta de Consti- dad de nego-
tucin del Proyecto: Herra- ciacin y tra-
mientas y Tcnicas. bajo en equipo
3. Desarrollo del Acta de Consti- que permita
tucin del Proyecto: Salidas. establecer un
trabajo ali-
Lectura seleccionada 2. neado a los en-
Gua de los Fundamentos para la tornos organi-
Direccin de Proyectos (Gua del zacionales.
PMBOK): Desarrollar el Acta de
Constitucin del Proyecto. PRO-
JECT MANAGEMENT INSTITUTE,
(2013), pginas 66 72.
Autoevaluacin N 2.
51
UNIDAD II:
INICIACIN DEL PROYECTO
TEMA N 1: SELECCIN DE PROYECTOS
INTRODUCCIN
Por lo general las compaas tienen que lidiar con muchos proyectos distintos para
resolver problemas y mejorar el desempeo. Hay muchas ms ideas que recursos
para los proyectos de sistemas. Las firmas tendrn que seleccionar de este grupo los
proyectos que prometan el mayor beneficio para los negocios. No cabe duda que la
seleccin de los proyectos se debera basar en la estrategia de negocios en general
de la firma.
Para poder profundizar la temtica relacionada a la Seleccin de Proyectos, es nece-

sario que se definan conceptos y definiciones que facilitarn el entendimiento y
aprendizaje de esta materia.
1. Estructura gerencial para los proyectos de sistemas de informacin.
El Grfico N 02-1 muestra los elementos de una estructura gerencial para los
proyectos de sistemas de informacin en una corporacin de gran tamao. Ayuda
a asegurar que se d prioridad a los proyectos ms importantes. En la cumbre de
esta estructura se encuentra el grupo corporativo de planeacin estratgica y el
comit de direccin de sistemas de informacin. El grupo corporativo de planea-
cin estratgica es responsable de desarrollar el plan estratgico de la firma, que
puede requerir el desarrollo de nuevos sistemas. El comit de direccin de siste-
mas de informacin es el grupo gerencial de nivel superior con la responsabilidad
del desarrollo y la operacin de los sistemas. Est compuesto por los jefes de
departamento de las reas tanto de los usuarios finales como de sistemas de
informacin. El comit de direccin revisa y aprueba los planes para los sistemas
en todas las divisiones, busca coordinar e integrar sistemas y en ocasiones se
involucra en la seleccin de proyectos especficos de sistemas de informacin. Un
grupo de gerentes de proyecto se encarga de supervisar al equipo de cada pro-
yecto. Este grupo est compuesto por gerentes de sistemas de informacin y
gerentes de usuarios finales responsables de supervisar varios proyectos espec-
ficos de sistemas de informacin. Cada equipo es el responsable directo de ese
proyecto de sistemas individual. Est formado por analistas de sistemas, espe-
cialistas relevantes de las reas de negocios de los usuarios finales, programado-
res y tal vez especialistas de bases de datos. La mezcla de habilidades y el tamao
del equipo del proyecto dependen de la naturaleza especfica de la solucin del
sistema.
52
Grfico N 02-1. Control Gerencial de los Proyectos de Sistemas
Fuente: Laudon, K.C., & Laudon, J.P. (2012)
2. Vinculacin de Proyectos de Sistemas con el Plan de Negocios
Para poder identificar los proyectos de sistemas de informacin que puedan ofre-
cer el mayor valor de negocios, las organizaciones necesitan desarrollar un plan
de sistemas de informacin que apoye su plan de negocios en general y en el que
se incorporen los sistemas estratgicos a la planeacin de nivel superior. El plan
sirve como mapa para indicar la direccin del desarrollo de sistemas (el propsito
del plan), el fundamento, la situacin actual de sistemas, los nuevos desarrollos
a tener en cuenta, la estrategia gerencial, el plan de implementacin y el presu-
puesto (vea la Tabla N 02-1).
El plan contiene una declaracin de los objetivos estratgicos y especifica el tipo

de apoyo que ofrecer la tecnologa de la informacin para lograrlos. El informe
muestra cmo se lograrn los objetivos generales por medio de proyectos de
sistemas especficos. Identifica las fechas lmite y los hitos especficos que se
pueden usar despus para evaluar el avance del plan, en trminos de cuntos
objetivos se lograron dentro del marco de tiempo especificado en el mismo.
El plan indica las decisiones gerenciales clave en relacin con la adquisicin de

hardware; las telecomunicaciones; la centralizacin/descentralizacin de la auto-
ridad, los datos y el hardware; adems del cambio organizacional requerido. Por
lo general tambin se describen los cambios organizacionales, como los requeri-
mientos de capacitacin para gerentes y empleados, los esfuerzos de recluta-
miento, los cambios en los procesos de negocios, en la autoridad, en la estructura
53
o en la prctica gerencial. Para poder planear con efectividad, las firmas tendrn
que realizar un inventario y documentar todas sus aplicaciones de sistemas de
informacin, adems de los componentes de la infraestructura de TI. Para los
proyectos en donde los beneficios implican una mejora en la toma de decisiones,
los gerentes deberan tratar de identificar las mejoras en las decisiones que pue-
dan proveer el mayor valor agregado para la firma. Despus deberan desarrollar
un conjunto de medidas para cuantificar el valor de la informacin ms oportuna
y precisa sobre el resultado de la decisin.
Tabla N 02-1: Plan de Sistemas de Informacin
N Contenido
Propsito del plan.

Generalidades del contenido del plan.
1 Organizacin de negocios actual y organizacin a futuro.
Procesos de negocios clave.
Estrategia gerencial.
Fundamentos del plan de negocios estratgico.
Situacin actual.
Organizacin de negocios actual.
2
Entornos cambiantes.
Principales objetivos del plan de negocios.
Plan estratgico de la firma.
Sistemas actuales.
Principales sistemas que dan soporte a las funciones y procesos de ne-
gocios.
Capacidades actuales de la infraestructura.
Hardware.
3
Software.
Bases de datos.
Telecomunicaciones e Internet.
Dificultades para cumplir los requerimientos de negocios.
Futuras demandas anticipadas.
Nuevos desarrollos.
Nuevos proyectos de sistemas.
4 Descripciones de proyectos.
Fundamentos de negocios.
Rol de las aplicaciones en la estrategia.
54
Nuevas capacidades requeridas de la infraestructura.
Hardware.
Software.
Bases de datos.
Telecomunicaciones e Internet.
Estrategia gerencial.
Planes de adquisicin.
Hitos y sincronizacin.
Realineacin organizacional.
5
Reorganizacin interna.
Controles gerenciales.
Principales iniciativas de capacitacin.
Estrategia del personal.
Plan de implementacin.
6 Dificultades anticipadas en la implementacin.
Informes del progreso.
Requerimientos de presupuesto.
Requerimientos.
7 Ahorros potenciales.
Financiamiento.
Ciclo de adquisicin.
3. Factores Crticos de xito
Para desarrollar un plan efectivo de sistemas de informacin, la firma debe tener

una clara comprensin de sus requerimientos de informacin, tanto de largo como
de corto plazo. La metodologa del anlisis estratgico, o los factores crticos de
xito, argumenta que los requerimientos de informacin se determinan mediante
un pequeo nmero de factores crticos de xito (CSF) de los gerentes. Si se
pueden obtener estos objetivos, se garantiza el xito de la organizacin (Rockart,
1979; Rockart y Treacy, 1982). Los CSF se modelan a travs de la industria, la
firma, el gerente y el entorno en general. Por ejemplo, los CSF para la industria
automotriz podran incluir estilo, calidad y costo para cumplir los objetivos de una
participacin creciente en el mercado y elevar las ganancias. Los nuevos sistemas
de informacin se deberan enfocar en proveer informacin que ayude a la firma
a cumplir con esos objetivos.
El principal mtodo utilizado en el anlisis de CSF es el de las entrevistas perso-

nales (tres o cuatro) con varios gerentes de nivel superior para identificar sus
objetivos y los CSF resultantes. Estos CSF personales se acumulan para desarro-
llar una perspectiva de los CSF de la firma. Despus se crean sistemas para en-
tregar la informacin sobre estos CSF (para el mtodo de desarrollar los CSF en
55
una organizacin, vea el Grfico N 02-2). Slo se entrevistan los gerentes de
nivel superior y las preguntas se enfocan en un pequeo nmero de CSF, en vez
de pedirles que expliquen con detenimiento qu informacin se utiliza en la orga-
nizacin. Esto es muy adecuado para la gerencia de nivel superior y para el desa-
rrollo tanto de los sistemas de soporte de decisiones (DSS) como de los sistemas
de soporte a ejecutivos (ESS). El mtodo de los CSF concentra la atencin de la
organizacin en la forma en que se debe manejar la informacin. La principal
debilidad del mtodo es que no hay una forma especfica y rigurosa en la que se
puedan acumular los CSF individuales de modo que se forme un patrn claro para
la compaa. Adems, es comn que los entrevistados (y los entrevistadores) se
confundan al tratar de diferenciar los CSF individuales de los organizacionales.
Estos tipos de CSF no son necesariamente los mismos. Lo que un gerente podra
considerar fundamental tal vez no sea importante para la organizacin en general.
Sin duda, este mtodo est dirigido a los gerentes de nivel superior, aunque se
podra extender, de modo que sea posible obtener ideas de los miembros de ni-
veles inferiores de la organizacin para nuevos sistemas prometedores (Peffers y
Gengler, 2003).
Grfico N 02-2: Uso de CSF para Desarrollar Sistemas
4. Anlisis de Cartera
Una vez que los anlisis estratgicos han determinado la direccin general del
desarrollo de sistemas, se puede utilizar el anlisis de cartera para evaluar pro-
yectos de sistemas alternativos. El anlisis de cartera realiza un inventario de
todos los proyectos y activos de sistemas de informacin de la firma, que abarca
infraestructura, contratos de outsourcing y licencias. Podemos describir esta car-
tera de inversiones en sistemas de informacin como algo que presenta cierto
perfil de riesgo y beneficio para la firma (vea el Grfico N 02-3), de manera
56
similar a una cartera financiera. Cada proyecto de sistemas de informacin aca-
rrea su propio conjunto de riesgos y beneficios.
Las firmas deberan tratar de mejorar el rendimiento sobre sus carteras de activos
de TI mediante un balance del riesgo y el rendimiento de sus inversiones en sis-
temas. Aunque no hay un perfil ideal para todas las firmas, las industrias en las
que se utiliza mucha informacin (como en finanzas) deberan tener unos cuantos
proyectos de alto riesgo y muchos beneficios para asegurar que puedan estar al
corriente con la tecnologa.
Las firmas en las industrias que no utilizan mucha informacin deberan enfocarse
en los proyectos con muchos beneficios y poco riesgo. Desde luego que son ms
deseables los sistemas con muchos beneficios y bajo nivel de riesgo. stos pro-
meten rendimientos anticipados y pocos riesgos.
En segundo lugar, se deberan examinar los sistemas con muchos beneficios y

alto riesgo; habra que evitar los sistemas de alto riesgo por completo; y se de-
beran reexaminar los sistemas con pocos beneficios y riesgos en cuanto a la
posibilidad de reconstruirlos y reemplazarlos con sistemas ms deseables que
tengan mayores beneficios.
Al utilizar el anlisis de cartera, la gerencia puede terminar la mezcla ptima de

riesgo en la inversin y la recompensa para sus firmas, mediante un balance entre
los proyectos ms riesgosos que ofrezcan mayores recompensas y los que sean
ms seguros, pero ofrezcan menos recompensas.
Se ha descubierto que las firmas en donde el anlisis de cartera se alinea con la

estrategia de negocios tienen un rendimiento superior sobre sus activos de TI,
una mejor alineacin de las inversiones de TI con los objetivos de negocios, y una
mejor coordinacin en toda la organizacin en cuanto a las inversiones en TI
(Jeffrey y Leliveld, 2004).
Grfico N 02-3: Una cartera de Sistemas
57
5. Modelos de Puntuacin
Un modelo de puntuacin es til para seleccionar proyectos en donde hay que

considerar muchos criterios. Asigna ponderaciones a las diversas caractersticas
de un sistema y despus calcula los totales ponderados. Mediante el uso de la
Tabla N 02-2, la firma debe decidir entre dos sistemas alternativos de planifica-
cin de recursos empresariales (ERP).
La primera columna indica los criterios que utilizarn los encargados de tomar
decisiones para evaluar los sistemas. Por lo general, estos criterios son el resul-
tado de extensas discusiones entre el grupo que toma las decisiones. A menudo
el resultado ms importante de un modelo de puntuacin no es la puntuacin;
sino, el acuerdo en cuanto a los criterios utilizados para juzgar un sistema.
La Tabla N 02-2 muestra que esta compaa en especial otorga la mayor impor-
tancia a las herramientas para el procesamiento de los pedidos de ventas, la
administracin del inventario y el almacn. La segunda columna en la Tabla N
02-2 indica las ponderaciones que los encargados de tomar decisiones asignaron
a los criterios de decisin. Las columnas 3 y 5 muestran el porcentaje de reque-
rimientos para cada funcin que puede proveer cada uno de los sistemas ERP
alternativos.
Para calcular la puntuacin de cada distribuidor hay que multiplicar el porcentaje

de los requerimientos que se cumplieron para cada funcin por la ponderacin
asignada a esa funcin. El sistema ERP B tiene la puntuacin total ms alta. Al
igual que con todas las tcnicas objetivas, existen muchas opiniones cualitativas
implicadas en el uso del modelo de puntuacin.
Este modelo requiere expertos que comprendan las cuestiones y la tecnologa. Es

apropiado repasar el modelo de puntuacin varias veces, modificando los criterios
y ponderaciones para ver qu tan sensible es el resultado a los cambios razona-
bles en los criterios.
El uso ms comn de los modelos de puntuacin es para confirmar, racionalizar

y apoyar las decisiones, en vez de utilizarlos como rbitros finales de la seleccin
del sistema.
58
Tabla N 02-2: Ejemplo de un modelo de puntuacin para un Sistema
ERP
59
Cmo hacer Proyectos?
Manuales de Gestin Bolunta, SOLABARRIA, E., pginas 1 21.
El proyecto es, al mismo tiempo, carta realista, que est al alcance de

de presentacin, gua para la accin y nuestros recursos;
argumento para la financiacin. Es, por transformadora, que provoque al-
tanto, un instrumento clave en el desa- gn tipo de cambio.
rrollo de nuestra entidad. Este manual Y para centrar nuestra idea responda-
pretende mostrarnos las herramientas mos a estas preguntas:
y las pautas que hemos de utilizar para Qu queremos hacer?
elaborar correctamente un proyecto Por qu?
eficaz, desde su planteamiento inicial Para qu?
hasta su redaccin final. Dirigido a quin?
Cmo?
1. Qu es un proyecto? Con quin?
Con qu recursos?
Es el documento que delimita lo qu Cundo?
queremos hacer y detalla todos los as- Dnde?
pectos de nuestra idea:
La realidad que queremos Cuando tengamos claras las respues-
cambiar, tas podremos empezar a redactar
Los objetivos a conseguir, nuestro proyecto.
La metodologa,
Los plazos de realizacin, 3. Elaborar el proyecto
Las actividades a desarrollar:
Los recursos econmicos, ma- 3.1. Criterios generales
teriales y humanos,
Los resultados que queremos Un proyecto ha de estar redactado
obtener. con claridad, en un lenguaje com-
prensible;
Para qu sirve un proyecto con precisin, explicando lo necesa-
Para ordenar, concretar, comunicar y rio de forma rigurosa;
compartir nuestras ideas. con coherencia, relacionando bien
todas sus partes;
y por qu es importante con concisin, diciendo slo lo esen-
Porque nos ayuda a reflexionar, a re- cial.
solver dudas, a aclarar y a madurar las
ideas, a definir bien lo que queremos Y ha de tener en cuenta los siguientes
hacer, cmo y cundo. temas transversales.
Gnero. Participacin de la mujer y
2. Lo primero: la idea aportacin a la igualdad.
El primer paso es tener una buena Participacin. Implicacin la pobla-

idea, es decir cin destinataria, cuyos intereses han
clara, bien definida; de primar sobre los de la entidad.
innovadora, diferente a otras pro-
puestas;
60
Interculturalidad. Recoger la diversi- a. Nombre. El proyecto ha de tener
dad cultural de nuestro entorno, tanto nombre y ha de ser atractivo. Es
en el desarrollo del proyecto como en conveniente que sea corto y de fcil
sus resultados. pronunciacin.
Sostenibilidad. El proyecto debe de
ser factible y ha de poder continuar b. Portada. Es la tarjeta de presenta-
despus de que termine la ayuda. cin: es importante cuidar su est-
tica, debe ser clara y ligera. Siem-
Medio Ambiente. Respetuoso con los pre debe incluir al menos estos tres
aspectos ambientales. elementos: el nombre del proyecto,
Al finalizar la redaccin de un proyecto, las fechas de realizacin y las insti-
es conveniente revisarlo a fin de corre- tuciones que lo promueven.
gir errores y de garantizar la coheren-
cia del texto. Su diseo ha de ser 3.2.2. Descripcin
atractivo, pero sin adornos intiles, Antes de abordar en profundidad el
con pginas desahogadas y limpias, proyecto es necesario hacer una breve
con mrgenes y particiones que rom- descripcin a modo de presentacin.
pan la monotona en un texto que ha Debe mostrar su finalidad y sus carac-
de estar bien estructurado y ordenado. tersticas generales, ha de ser breve e
Y no ha de tener demasiadas pginas, incluir los siguientes aspectos:
la brevedad es una virtud. Si se estima La idea y el objetivo principal.
necesaria, se puede encuadernar. El contenido de la intervencin.
La poblacin beneficiaria.
3.2. Partes del proyecto El resultado que se espera ob-
Los apartados que debe contener un tener.
buen proyecto son, como mnimo, los
siguientes. Ejemplo:
1. Ttulo. Este proyecto propone incorporar per-
2. Descripcin. sonas voluntarias para colaborar con
3. Justificacin. familias que tienen a su cargo personas
4. Marco institucional. con discapacidades, que no pueden
5. Objetivos. contar con ayuda de otras personas
6. Personas destinatarias. para atenderlas, facilitando el cuidado
7. Localizacin fsica y mbito te- de las mismas durante determinados
rritorial. das y horas, de manera que puedan
8. Actividades y tareas. disponer de tiempo libre.
9. Metodologa.
10. Calendario de trabajo y activi- 3.2.3. Justificacin
dades. Consiste en identificar el problema so-
11. Administracin del proyecto. bre el que vamos a trabajar, aportando
12. Recursos necesarios. datos como la realidad social y cultural
13. Presupuesto. del lugar donde se va a desarrollar el
14. Evaluacin. proyecto, las caractersticas socioeco-
15. Factores externos. nmicas de las personas destinatarias,
estudios de poblacin, etc. Igual-
Vayamos uno a uno. mente, es necesario argumentar por
qu es necesario el proyecto y las ra-
3.2.1. Ttulo zones que nos llevan a plantearlo.
61
Por eso, el proyecto debe iniciarse con es una de las partes ms importantes.
una fundamentacin que exprese: No hay que escatimar tiempo para de-
La situacin de partida. finirlos lo mejor posible. Y recordemos
Los beneficios que aporta. que para su redaccin suele emplearse
Las circunstancias que avalan el infinitivo.
su pertinencia. Ejemplos:
La innovacin o mejora que Luchar contra las desigualdades
propone. entre hombres y mujeres.
Dar a conocer la realidad en que
Al final, la justificacin es la defensa de viven las personas de los pases
nuestro proyecto, para lo cual nos ayu- empobrecidos.
dar mucho el anlisis previo de la Ofrecer un servicio de atencin
realidad que hayamos realizado. permanente para personas in-
Un consejo: la fundamentacin debe migrantes.
de ser el texto ms literario del pro-
yecto. Su lectura debe resultar com- Los objetivos se estructuran en tres ni-
prensible y atractiva. Hay que esmerar veles: generales, especficos y operati-
la redaccin y lograr un texto bien vos.
construido que combine la emotividad
que impulsa el cambio con el rigor tc- Objetivo general
nico. Define lo que se quiere conseguir; es
Pero nuevamente es conveniente la el fin ltimo, la misin del proyecto.
concisin y la precisin. Una sola p-
gina suele ser suficiente. El proyecto Objetivos especficos
debe de ser un documento de fcil lec- Concretan el objetivo general defi-
tura y comprensin, y no un discurso niendo lo que desea lograrse para las y
genrico. los beneficiarios, e indican la manera
en la que conseguiremos el objetivo
3.2.4. Marco institucional general.
Se trata de presentar a la organizacin
responsable del proyecto de manera Objetivos operativos
que queden claros sus objetivos, su Expresan lo que se prev obtener al fi-
forma de trabajo, sus actividades, su nal del proyecto, definiendo cmo con-
estructura en resumen, un currculo seguir los objetivos especficos. Llevan
de la entidad. asociados indicadores cuya funcin es
Es por tanto interesante que aparezcan medir los resultados alcanzados.
los siguientes datos: naturaleza de la
organizacin, su situacin jurdica y 3.2.6. Personas destinatarias
administrativa, sus instalaciones y ser- Son las personas a las que va dirigido
vicios, sus polticas y prioridades, y el proyecto. Podemos distinguir entre
sus relaciones con otras instituciones y destinatarias directas e indirectas.
programas. Directas: las beneficiadas direc-
Para proyectos presentados a financia- tamente por el proyecto.
cin, es ms prctico adjuntar esta in- Ejemplo: mujeres maltratadas
formacin en un dossier separado. por sus parejas.
Indirectas: personas en las que
3.2.5. Objetivos repercuten indirectamente los
Los objetivos indican aquello que se beneficios del proyecto.
pretende alcanzar y, en consecuencia,
62
Ejemplo: los hijos e hijas de s- 3.2.11. Administracin del pro-
tas mujeres. yecto
Cuando el destinatario sea un grupo, En este apartado se deber explicar
se deben identificar todas las variables cmo va a ser la gestin del proyecto.
que lo definen de la forma ms precisa Deben indicarse los aspectos siguien-
posible. tes.
Ejemplo:
Adultos / con edades comprendidas Organizacin interna. mbito de ges-
entre 35 y 50 aos / residentes en Bil- tin del proyecto (departamento, ser-
bao / que no finalizaron el bachillerato vicio, unidad, etc.); equipo responsa-
/ y que tienen trabajos ocasionales. ble (personas, cualificacin profesio-
nal, responsabilidad en la organiza-
3.2.7. Localizacin fsica y m- cin); persona coordinadora del
bito territorial equipo; dinmica de trabajo (reunio-
La localizacin fsica hace referencia al nes, acciones, etc.).
lugar concreto donde se desarrolla el
proyecto. El mbito territorial al rea Coordinacin externa. Relacin con
geogrfica que abarca. otros agentes indicando cules son,
Ejemplo: por qu y para qu con ellos, modo de
El proyecto se desarrolla en Bilbao, coordinacin, periodicidad, entre otros.
pero se atiende a personas de toda Biz-
kaia. Promocin y difusin. Mtodos para
Localizacin fsica: Bilbao. dar a conocer el proyecto entre las per-
mbito territorial: Bizkaia. sonas destinatarias o colectivos ms
amplios, indicando el contenido, el p-
3.2.8. Actividades y tareas blico a quien se dirige y los instrumen-
Actividad es cada una de las acciones tos a utilizar (folletos, apariciones en
llevadas a cabo para la consecucin de medios, etc.).
un objetivo. Tarea, cada una de las
funciones necesarias para el desarrollo Participacin. Puede referirse a las per-
de una actividad. sonas destinatarias del proyecto o a
entidades o personas del entorno en el
3.2.9. Metodologa que se va a llevar a cabo. En cualquier
Es el modo, los procedimientos y las caso, ser necesario precisar el alcance
tcnicas que vamos a emplear para de esta participacin, quines van a
desarrollar el proyecto. As, hemos de participar y a travs de qu cauces.
explicar cmo vamos a llevar a cabo la Conviene que la participacin de la
intervencin, qu protocolos vamos a gente implicada est planteada desde
seguir, qu herramientas vamos a uti- el inicio y que sus pasos sean acorda-
lizar, qu tipo de relaciones vamos a dos con ellos y ellas, de modo que las
establecer, etc. personas beneficiarias sean efectiva-
mente sujetos de su accin y no meras
3.2.10. Calendario de trabajo comparsas.
Tiene que elaborarse un programa de
actividades especificando las fechas de Adems de estos cuatro puntos, tam-
inicio y de finalizacin de cada una. bin es interesante sealar las vas de
Hay que ordenarlas en el tiempo di- financiacin del proyecto y su capaci-
ciendo cul es la relacin de sucesin o dad de autogestin y continuidad aten-
simultaneidad entre ellas. diendo a criterios de sostenibilidad.
63
3.2.12. Recursos necesarios del proyecto, que va en el captulo si-
Los recursos humanos guiente de presupuesto.
Primero describiremos las personas re-
muneradas, es decir, el personal con- 3.2.13. Presupuesto
tratado necesario: nmero, competen- Un buen presupuesto debe identificar
cias profesionales, funciones, horas de todos los gastos y los ingresos, incor-
trabajo semanales, retribucin bruta porarlos y buscar una relacin equili-
total, salario y retenciones segn con- brada entre ellos.
venio, seguridad social y total del coste
laboral. Posteriormente, establecere- 3.2.14. Evaluacin
mos el personal voluntario sealando Ningn proyecto puede darse por con-
su nmero, tareas y dedicacin. cluido hasta que no se evala, es decir,
hasta que no vemos si se han cumplido
Los recursos materiales y tcnicos los objetivos previstos y si han sido
Nos referimos a instalaciones, maqui- adecuados la metodologa, las activi-
naria, vehculos, materiales fungibles dades, los plazos la gestin, los recur-
Es preciso enumerar todos los recursos sos, el presupuesto es decir, todos
necesarios, incluso cuando no repre- los elementos que componen el pro-
senten costes. Se debe sealar cmo yecto.
ser su vinculacin al proyecto: adqui-
sicin, alquiler, cesin, edicin, repara- 3.2.15. Factores externos
cin, entre otros. Son factores sobre los que no tenemos
control pero que son necesarios para
Los recursos monetarios que el proyecto logre sus objetivos. Los
Nos referimos a fondos necesarios para ejemplos son mltiples, desde el clima
prestar ayuda econmica a personas, a la concesin de una subvencin o la
familias o grupos como parte de la in- necesidad de incorporar personas vo-
tervencin prevista, siempre que el luntarias. Han de conocerse y, si se ve
proyecto lo contemple. No estamos ha- necesario, especificarse con realismo,
blando, por lo tanto, de la financiacin precisin y con buena fundamentacin.
64
INSTRUCCIONES
1. Desarrolla una idea de proyecto teniendo en consideracin los puntos descritos

a continuacin:
1.1. ANTECEDENTES.
1.2. PROBLEMA.
1.3. JUSTIFICACIN DEL PROBLEMA.
1.4. SOLUCIN PROPUESTA.
1.5. BIBLIOGRAFA.
1.6. ANEXOS.
65
TEMA N 2: ACTA DE CONSTITUCIN DEL PROYECTO
INTRODUCCIN
Desarrollar el Acta de Constitucin del Proyecto es el proceso de desarrollar un do-

cumento que autoriza formalmente la existencia de un proyecto y confiere al director
de proyecto la autoridad para asignar los recursos de la organizacin a las actividades
del proyecto. El beneficio clave de este proceso es un inicio y unos lmites del proyecto
bien definidos, la creacin de un registro formal del proyecto y el establecimiento de
una forma directa para que la direccin general acepte formalmente y se comprometa
con el proyecto.
5. Desarrollar el Acta de Constitucin del Proyecto: Entradas
5.1.Enunciado del Trabajo del Proyecto
El Enunciado del Trabajo del Proyecto (SOW) es una descripcin narrativa de

los productos, servicios o resultados que debe entregar el proyecto. En el
caso de proyectos internos, el iniciador del proyecto o patrocinador propor-
ciona el enunciado del trabajo sobre la base de las necesidades de la empresa
o de los requisitos del producto o servicio. En el caso de proyectos externos,
el enunciado del trabajo puede ser proporcionado por el cliente como parte
de un documento de licitacin (p.ej., una solicitud de propuesta, una solicitud
de informacin, o una solicitud de oferta), o como parte de un contrato. El
SOW del proyecto hace referencia a:
Necesidad de negocio. Las necesidades de negocio de una organizacin

pueden provenir de una demanda del mercado, de un avance tecnolgico,
de un requisito legal, de una reglamentacin gubernamental o de consi-
deraciones medioambientales. Por regla general la necesidad de negocio
y el anlisis costo-beneficio se incluyen en el caso de negocio para justi-
ficar el proyecto.
Descripcin del alcance del producto. La descripcin del alcance del

producto documenta las caractersticas del producto, servicio o resultados
que el proyecto se encargar de crear. La descripcin tambin debera
documentar la relacin entre los productos, servicios o resultados que se
estn creando y la necesidad de negocio a la que responde el proyecto.
Plan estratgico. El plan estratgico documenta la visin, metas y ob-

jetivos estratgicos de la organizacin y puede contener una declaracin
de alto nivel de su misin. Todos los proyectos deben estar alineados con
el plan estratgico de la organizacin. La alineacin con el plan estratgico
asegura que cada uno de los proyectos contribuye a lograr los objetivos
generales de la organizacin.
66
5.2.Caso de Negocio
El caso de negocio o documento similar proporciona la informacin necesaria

desde una perspectiva de negocio para determinar si el proyecto es viable o
no en trminos de la inversin requerida. Normalmente se utiliza para la toma
de decisiones por parte de la direccin o ejecutivos de un nivel superior al del
proyecto.
Normalmente, necesidad de negocio y anlisis costo-beneficio se incluyen en

el caso de negocio para justificar y establecer los lmites del proyecto y el
anlisis se suele llevar a cabo por un analista de negocio sobre la base de las
diversas aportaciones de los interesados. El patrocinador debera estar de
acuerdo con el alcance y las limitaciones del caso de negocio. El caso de
negocio se crea como resultado de una o ms de las siguientes razones:
Demanda del mercado (p.ej., una compaa automotriz que autoriza un

proyecto para construir ms automviles de bajo consumo en respuesta
a la escasez de combustible),
Necesidad de la organizacin (p.ej., debido a los altos costos generales

una compaa puede combinar funciones del personal y racionalizar pro-
cesos para reducir costos),
Solicitud de un cliente (p.ej., una compaa elctrica que autoriza un pro-

yecto para construir una nueva subestacin a fin de abastecer un nuevo
parque industrial),
Avance tecnolgico (p.ej. una compaa area que autoriza un nuevo pro-
yecto para desarrollar el billete electrnico y sustituir los billetes en papel,
sobre la base de los avances tecnolgicos),
Requisito legal (p.ej., un fabricante de pinturas que autoriza un proyecto

para establecer guas para el manejo de materiales txicos),
Impacto ecolgico (p.ej., una compaa que autoriza un proyecto para

disminuir su impacto ambiental), o
Necesidad social (p.ej., una organizacin no gubernamental en un pas en

vas de desarrollo que autoriza un proyecto para dotar de sistemas de
agua potable, baos y educacin sanitaria a comunidades que padecen
altos ndices de clera).
Cada uno de los ejemplos de esta lista puede conllevar elementos de riesgo
que deberan tenerse en consideracin. En el caso de proyectos de fases ml-
tiples, se puede revisar peridicamente el caso de negocio para asegurar que
el proyecto sigue orientado hacia el logro de los beneficios de negocio esta-
blecidos. En las primeras etapas del ciclo de vida del proyecto, la revisin
peridica del caso de negocio por parte de la organizacin patrocinadora tam-
bin ayuda a confirmar que el proyecto sigue alineado con el caso de negocio.
67
El director del proyecto es responsable de garantizar que el proyecto cumple
los objetivos de la organizacin y los requisitos de un amplio conjunto de
interesados de manera eficaz y eficiente, como se define en el caso de nego-
cio.
5.3.Acuerdos
Los acuerdos se establecen para definir las intenciones iniciales de un pro-

yecto. Los acuerdos pueden tomar la forma de contratos, memorandos de
entendimiento (MOUs), acuerdos de nivel de servicio (SLA), cartas de
acuerdo, declaraciones de intenciones, acuerdos verbales, correos electrni-
cos u otros acuerdos escritos. Normalmente se utiliza un contrato cuando se
lleva a cabo el proyecto para un cliente externo.
5.4.Factores Ambientales de la Empresa
Los factores ambientales de la empresa que pueden influir en el proceso

Desarrollar el Acta de Constitucin del Proyecto incluyen, entre otros:
Estndares gubernamentales, estndares de la industria o reglamentos

(p.ej., cdigos de conducta, estndares de calidad o estndares de pro-
teccin del trabajador);
Cultura y estructura de la organizacin, y
Condiciones del mercado.
5.5.Activos de los Procesos de la Organizacin

Los activos de los procesos de la organizacin que pueden influir en el proceso
Desarrollar el Acta de Constitucin del Proyecto incluyen, entre otros:
Procesos estndar de la organizacin, polticas y definiciones de procesos,
Plantillas (p.ej., plantilla del acta de constitucin del proyecto), e
Informacin histrica y base de conocimientos de lecciones aprendidas
(p.ej., proyectos, registros y documentos, toda la informacin y docu-
mentacin de cierre del proyecto, informacin tanto sobre los resultados
de las decisiones de seleccin de proyectos anteriores y sobre el desem-
peo de proyectos anteriores, como sobre las actividades de gestin de
riesgos).
68
6. Desarrollar el Acta de Constitucin del Proyecto: Herramientas y Tcnicas
6.1.Juicio de Expertos
A menudo se utiliza el juicio de expertos para evaluar las entradas que se

usan para elaborar el Acta de Constitucin del Proyecto. El juicio de expertos
se aplica a todos los detalles tcnicos y de gestin a lo largo de este proceso.
Esta experiencia puede ser proporcionada por cualquier grupo o individuo con
conocimientos o formacin especializados, y se encuentra disponible a travs
de diferentes fuentes, entre las que se incluyen:
Otras unidades dentro de la organizacin,

Consultores,
Interesados, incluidos clientes y patrocinadores,
Asociaciones profesionales y tcnicas,
Grupos industriales,
Expertos en la materia (SME), y
Oficina de direccin de proyectos (PMO).
6.2.Tcnicas de Facilitacin
Las tcnicas de facilitacin tienen una amplia aplicacin en el mbito de los

procesos de la direccin de proyectos y guan el desarrollo del acta de cons-
titucin del proyecto. Tormentas de ideas, resolucin de conflictos, solucin
de problemas y gestin de reuniones son ejemplos de tcnicas clave que
utilizan los facilitadores para ayudar a equipos e individuos a llevar a cabo
las actividades del proyecto.
6.2.1. Tormenta de Ideas
La tormenta de ideas (lluvia de ideas o brainstorming) es una tcnica

de pensamiento creativo utilizada para estimular la produccin de un
elevado nmero de ideas, por parte de un grupo, acerca de un pro-
blema y de sus soluciones o, en general, sobre un tema que requiere
de ideas originales.
La tormenta de ideas fue propuesta en 1939 por Alex F. Osborn, quien

comenz a utilizar un procedimiento que permitiera el surgimiento de
ideas creativas y originales como mtodo de resolucin de problemas.
Ms adelante, en 1953, sistematiz su mtodo creativo de resolucin
de problemas.
Propuso un mtodo destinado a estimular la formulacin de ideas de

modo que se facilitara la libertad de pensamiento al intentar resolver
un problema. ste consista en un procedimiento por el que un grupo
intenta encontrar una solucin a un problema especfico mediante la
acumulacin de todas las ideas expresadas, de forma espontnea, por
sus miembros.
69
Los principios para el desarrollo de la tormenta de ideas son:
La crtica no est permitida.

La libertad de pensamiento es indispensable.
La cantidad es fundamental.
La combinacin y la mejora deben ponerse en prctica.
La creatividad y la produccin de un gran nmero de ideas es el ele-
mento central de esta tcnica. El hecho de obtener un elevado nmero
de ellas no parece influir negativamente sobre la calidad.
De forma muy general las fases de una sesin de tormenta de ideas
son:
a. Presentacin de la sesin de tormenta de ideas.
La sesin debe comenzar con una explicacin de la tarea, de sus obje-
tivos, del procedimiento a seguir y de la duracin de la sesin de tra-
bajo.
b. Generacin de ideas.
El tema se muestra de manera visible en una pizarra, soporte o panta-
lla, de modo que no haya dudas sobre el mismo. Hay que asegurar que
se ha comprendido correctamente por parte de todos los participantes.
Es aconsejable que est planteado en forma de pregunta.
Es conveniente establecer un objetivo sobre el nmero de ideas a al-
canzar. Como mnimo, proponer que se produzcan 40 o 50 ideas para
un grupo en torno a 6 personas. Est demostrado que el objetivo tiende
a cumplirse.
c. Mejora de ideas
El papel dinamizador del facilitador es aqu crtico. Una vez expuestas
todas las ideas, es preciso asegurarse de que han sido comprendidas.
Para ello se revisarn, preguntando a los participantes si hay dudas o
se quiere hacer algn comentario.
Se aplica la combinacin, la reelaboracin, la sntesis de una o ms
ideas.
d. Evaluacin
La evaluacin de las ideas puede hacerse en la misma sesin de tor-
menta de ideas, en un momento posterior. Resultado de la evaluacin
es la reduccin de la lista de ideas hasta un nmero en el que es factible
trabajar con ellas, siendo el voto individual para la seleccin de las
ideas finales el mejor mtodo para predecir las ideas de xito. En este
sentido, es imprescindible contar con un procedimiento estructurado,
como el de Votacin Mltiple.
7. Desarrollar el Acta de Constitucin del Proyecto: Salidas
7.1.Acta de Constitucin del Proyecto

El Acta de Constitucin del Proyecto es un documento emitido por el iniciador
del proyecto o patrocinador, que autoriza formalmente la existencia de un
proyecto y confiere al director del proyecto la autoridad para asignar los re-
70
cursos de la organizacin a las actividades del proyecto. Documenta las ne-
cesidades de negocio, los supuestos, las restricciones, el conocimiento de las
necesidades y requisitos de alto nivel del cliente y el nuevo producto, servicio
o resultado que el proyecto debe proporcionar, como, por ejemplo:
El propsito o la justificacin del proyecto,
Los objetivos medibles del proyecto y los criterios de xito asociados,
Los requisitos de alto nivel,
Los supuestos y las restricciones,
La descripcin de alto nivel del proyecto y sus lmites,
Los riesgos de alto nivel,
El resumen del cronograma de hitos,
El resumen del presupuesto,
La lista de interesados,
Los requisitos de aprobacin del proyecto (es decir, en qu consiste el
xito del proyecto, quin decide si el proyecto tiene xito y quin firma la
aprobacin del proyecto),
El director del proyecto asignado, su responsabilidad y su nivel de auto-
ridad,
El nombre y el nivel de autoridad del patrocinador o de quienes autorizan
el acta de constitucin del proyecto.
71
Desarrollar el Acta de Constitucin del Proyecto
Gua de los Fundamentos para la Direccin de Proyectos (Gua del PMBOK., 2013,
pginas 66 72.
El Grfico 02-4 muestra las entradas, herramientas y tcnicas, y salidas de este pro-
ceso. El Grfico 02-5 representa el diagrama de flujo de datos del proceso.
Grfico 02-4: Desarrollar el Acta de Constitucin del Proyecto
Fuente: PMBOK (2013)
Grfico N 02-5: Diagrama de Flujo de Datos de Desarrollar el Acta de

Constitucin del Proyecto
Fuente: PMBOK (2013).
72
El acta de constitucin del proyecto es- requisitos fundamentales del proyecto.
tablece una relacin de colaboracin Este conocimiento favorecer una
entre la organizacin ejecutora y la or- asignacin eficiente de los recursos a
ganizacin solicitante. En el caso de las actividades del proyecto.
proyectos externos generalmente se
opta por establecer este acuerdo a tra- Los proyectos son iniciados por una en-
vs de un contrato formal. En este caso tidad externa a los mismos, como un
el equipo del proyecto juega el papel patrocinador, un programa o una per-
del vendedor que responde a las con- sona de la oficina de direccin de pro-
diciones de una oferta de compra de yectos (PMO), o el presidente de un r-
una entidad externa. El acta de consti- gano de gobierno del portafolio o su re-
tucin de un proyecto se utiliza incluso presentante autorizado. El iniciador del
para establecer acuerdos internos en el proyecto o patrocinador debe encon-
seno de una organizacin con objeto trarse en el nivel adecuado para obte-
de asegurar la entrega adecuada de ner la financiacin del proyecto y com-
acuerdo con el contrato. El proyecto se prometer recursos para el mismo. Los
inicia formalmente con la aprobacin proyectos se inician como consecuen-
del acta de constitucin del proyecto. cia de necesidades internas de la em-
Se selecciona y asigna un director del presa o de influencias externas. Estas
proyecto tan pronto como sea posible, necesidades o influencias a menudo
preferiblemente durante la elaboracin motivan la realizacin de un anlisis de
del acta de constitucin del proyecto, y necesidades, un estudio de viabilidad,
siempre antes de comenzar la planifi- un caso de negocio o la descripcin de
cacin. La entidad patrocinadora debe- la situacin que abordar el proyecto.
ra ser la encargada de redactar el acta
de constitucin del proyecto. La elaboracin del acta de constitucin
de un proyecto confirma la alineacin
El acta de constitucin del proyecto del proyecto en cuestin con la estra-
confiere al director del proyecto la au- tegia y el trabajo en curso de la orga-
toridad necesaria para planificar y lle- nizacin. El acta de constitucin del
var a cabo el proyecto. Se recomienda proyecto no se considera un contrato
que el director del proyecto participe porque no existen consideraciones,
en la elaboracin del acta de constitu- compromisos o intercambios moneta-
cin del proyecto para que de este rios en su creacin.
modo adquiera el conocimiento de los
GLOSARIO DE LA UNIDAD
1. Acta de Constitucin del Proyecto / Project Charter. Un documento emi-

tido por el iniciador del proyecto o patrocinador, que autoriza formalmente la
existencia de un proyecto y confiere al director de proyecto la autoridad para
aplicar los recursos de la organizacin a las actividades del proyecto.
2. Activos de los Procesos de la Organizacin / Organizational Process

Assets. Planes, procesos, polticas, procedimientos y bases de conocimiento
que son especficos de la organizacin ejecutante y que son utilizados por la
misma.
3. Acuerdos / Agreements. Cualquier documento o comunicacin que defina

las intenciones iniciales de un proyecto. Puede adoptar la forma de un con-
trato, memorndum de entendimiento (MOU), cartas de acuerdo, acuerdos
verbales, correo electrnico, etc.
4. Acuerdos Negociados / Negotiated Settlements. El proceso de alcanzar

un acuerdo definitivo y equitativo de todos los incidentes, reclamaciones y
controversias pendientes a travs de la negociacin.
BIBLIOGRAFA DE LA UNIDAD II
Project Management Institute. (2013). Gua de los Fundamentos para la Direccin de

Proyectos (5ta ed.). EEUU: PMI.
SCRUMstudy. (2013). Una gua para el conocimiento de SCRUM (ed. 2013). EEUU:
SCRUMstudy.
Laudon, K.C., & Laudon, J.P. (2012). Sistemas de Informacin Gerencial (12da ed.).
Mxico: Pearson.
Schwaber, K. & Sutherland, J. (2013). La Gua Definitiva de SCRUM: Las Reglas del
Juego.
Kerzner, H.D. (2013). Project Management: A Systems Approach to Planning, Sche-
duling, and Controlling (11th ed.). John Wiley & Sons.
Fernndez, J. (s.f.). Introduccin a las Metodologas giles: Otras formas de analizar
y desarrollar, Universitat Oberta de Catalunya.
Boehm, Barry W. (Mayo 1988). A Spiral Model of Software Development and Enhan-
cement, IEEE Computer, Vol.21, No 15, pp.61-72.
Rockart, John F. y Michael E. Treacy. (enero-febrero de 1982). The CEO Goes On-
Line. Harvard Business Review.
Jeffrey, Mark e Ingmar Leliveld. (2004). Best Practices in IT Portfolio Management.
MIT Sloan.
75
AUTOEVALUACIN No 2
1. Por qu es importante que el acta de constitucin del proyecto sea

firmada por una persona altamente ubicada en la organizacin?
A) Porque indica la importancia relativa y la prioridad del proyecto dentro de la

organizacin.
B) Porque proporciona autoridad al gerente del proyecto para cruzar lmites fun-
cionales cuando se est realizando planes y actividades del proyecto.
C) Porque da una mayor credibilidad frente a la gente que est fuera del pro-
yecto a la que se le puede pedir contribuir con recursos o unirse al equipo del
proyecto.
2. En general, las habilidades tcnicas de un gerente de proyecto:
A) Tienen que ser suficientemente altas para entender cuestiones tcnicas y ex-
plicar decisiones tcnicas a otros.
B) Tienen que ser iguales o ms altas que las habilidades tcnicas de cualquier
otro miembro del equipo.
C) No deberan ser consideradas cuando se selecciona a un gerente de proyecto.
D) Son el criterio ms importante para seleccionar a un gerente de proyecto.
3. El acta de constitucin del proyecto es un documento expedido por:
A) Los interesados.
B) El director del proyecto.
C) El cliente que da inicio al proyecto.
D) La Gerencia.
4. Las lecciones aprendidas durante el proyecto:
A) Deben ser documentadas slo en el informe de cierre.

B) Deben componerse slo de datos del proyecto.
C) Deben ser documentadas a lo largo del proyecto.
D) Deben componerse slo de cosas que marcharon durante la ejecucin del
proyecto.
5. Insistir en que todos los miembros del equipo y proveedores

usen procedimientos organizacionales y terminologas estndar
A) Es una mala prctica de gestin porque reprime la creatividad.

B) Es una mala prctica de gestin porque ordena prcticas que no pueden ser
las mejores prcticas de estndares industriales.
C) Es una buena prctica de gestin porque brinda los resultados ms predeci-
bles.
D) Es una buena prctica de gestin porque destaca la autoridad absoluta
del gerente del proyecto sobre el proyecto.
76
6. De las selecciones siguientes Cul es la habilidad MS importante
que un gerente de proyecto puede tener?
A) Habilidades de comunicacin.
B) Habilidades para la solucin de problemas.
C) Habilidades de influencia.
D) Habilidades de negociacin.
7. Cul de las siguientes NO es una Metodologa de Desarrollo de Soft-

ware?
A) Unified Modeling Language (UML).

B) Crystal Clear.
C) Agile Unified Process (AUP).
D) Feature Driven Development (FDD).
8. En el comienzo de un proyecto, la definicin del problema:
A) Suele ser difuso.

B) Est claramente especificada.
C) Requiere mucho tiempo a pesar de no tener mucha trascendencia.
D) Todas las anteriores se dan.
9. No son caractersticas tpicas de los proyectos:
A) Tener un objetivo claro.

B) Las economas de escala.
C) Que se puedan identificar tareas.
D) Que existan limitaciones de recursos.
10.Las fases genricas de un proyecto son:
A) Planeacin, codificacin y pruebas.

B) Puesta en marcha y conclusin del proyecto.
C) Planeacin y ejecucin del proyecto.
77
UNIDAD III:
PLANIFICACIN DEL PROYECTO
TEMA N 1: GESTIN DEL ALCANCE DEL PROYECTO
INTRODUCCIN
La Gestin del Alcance del Proyecto, incluye los procesos necesarios para garantizar
que, el proyecto incluya todo el trabajo requerido para completarlo con xito. El ob-
jetivo principal de la Gestin del Alcance del Proyecto, es definir y controlar que, se
incluye y que, no se incluye en el proyecto.
El concepto de alcance es un trmino relativamente ambiguo, que origina interpre-
taciones dispares y a veces encontradas entre cliente y proveedor, pero que resulta
esencial en proyectos. Para el efecto del presente manual, se definir como sigue:
El alcance del proyecto es una descripcin del trabajo requerido para entregar el
producto, servicio o resultado del proyecto. El alcance del proyecto gua a su director,
en las decisiones de aadir, cambiar o eliminar trabajo del proyecto. El alcance del
proyecto junto con los costes y tiempos, conforman la triple restriccin en la gestin
de proyectos.
En otras palabras, se puede definir como alcance del proyecto a, la combinacin de
los objetivos del proyecto ms el trabajo necesario para alcanzar dichos objetivos
(suma de productos y servicios que deben ser realizados en el proyecto).
Por lo tanto, el alcance tiene dos dimensiones de las que a su vez, se deducen las
definiciones siguientes:
- Alcance del producto: Caractersticas y funciones que caracterizan a un pro-
ducto o servicio. stas incluyen tanto caractersticas de tipo tcnico, como carac-
tersticas del producto relacionadas con el plazo de terminacin (time-to-market)
y coste de producto final. El alcance de proyecto se mide contra el plan de pro-
yecto. Por ejemplo, el alcance del proyecto para construir una casa incluir todo
el trabajo necesario para llevar con xito la edificacin con las caractersticas
especificadas.
- Alcance del proyecto: Trabajo que debe ser realizado para entregar el producto
(del proyecto) con las caractersticas y funciones especificadas. En el caso de la
edificacin de la casa sera el conjunto de caractersticas (calidades) que debera
tener la casa una vez finalizada. El grado de cumplimiento del alcance del pro-
ducto se mide comparndolo con los requisitos establecidos al inicio.
En el fondo, ambas dimensiones son las caras de una misma moneda ya que, para
que un proyecto tenga xito es condicin necesaria, en primer lugar, definir el pro-
ducto adecuadamente, de acuerdo a las necesidades del cliente. La definicin del
producto adecuado no es algo inmediato, siendo en muchos casos un proyecto en s
mismo, el que puede precisar la realizacin de estudios de viabilidad tcnica y co-
mercial proceso de gestin de proyecto conocido como iniciacin - con objeto de
establecer los objetivos del proyecto.
78
1. Planificar la Gestin del Alcance.
Planificar la Gestin del Alcance es el proceso de crear un plan de gestin del
alcance que documente cmo se va a definir, validar y controlar el alcance del
proyecto. El beneficio clave de este proceso es que proporciona gua y direccin
sobre cmo se gestionar el alcance a lo largo del proyecto. El Grfico 03-1 mues-
tra las entradas, herramientas y tcnicas, y salidas de este proceso.
Grfico N 03-1. Planificar la Gestin del Alcance: Entradas, Herramien-

tas, Tcnicas y Salidas
El plan de gestin del alcance, es un componente del plan para la direccin del
proyecto o programa que, describe cmo ser definido, desarrollado, monito-
reado, controlado y verificado el alcance. El desarrollo del plan de gestin del
alcance y de los detalles del alcance del proyecto comienzan con el anlisis de la
informacin contenida en el acta de constitucin del proyecto, en los ltimos pla-
nes secundarios aprobados del plan para la direccin del proyecto, en la informa-
cin histrica contenida en los activos de los procesos de la organizacin, en cual-
quier otro factor ambiental relevante de la empresa. Este plan ayuda a reducir el
riesgo de deformacin del alcance del proyecto.
2. Recopilar Requisitos.
Recopilar Requisitos es el proceso de determinar, documentar y gestionar las ne-
cesidades y los requisitos de los interesados para cumplir con los objetivos del
proyecto. El beneficio clave de este proceso es que, proporciona la base para
definir y gestionar el alcance del proyecto, incluyendo el alcance del producto. El
Grfico 03-2 muestra las entradas, herramientas y tcnicas, y salidas de este
proceso.
79
Grfico N 03-2. Recopilar Requisitos: Entradas, Herramientas, Tcnicas
y Salidas
El xito del proyecto depende directamente de la participacin activa de los in-

teresados en el descubrimiento y la descomposicin de las necesidades en requi-
sitos, y del cuidado que se tenga al determinar, documentar y gestionar los re-
quisitos del producto, servicio o resultado del proyecto. Los requisitos incluyen
condiciones o capacidades que el proyecto debe cumplir o que deben estar pre-
sentes en el producto, servicio o resultado para satisfacer un acuerdo u otra es-
pecificacin formalmente impuesta. Los requisitos incluyen las necesidades y ex-
pectativas cuantificadas y documentadas del patrocinador, del cliente y de otros
interesados.
Estos requisitos deben recopilarse, analizarse y registrarse con un nivel de detalle
suficiente que permita incluirlos en la lnea base del alcance y medirlos una vez
que se inicie el proyecto. Los requisitos constituyen la base de la EDT/WBS. La
planificacin del costo, del cronograma, de la calidad y, en ocasiones, las adqui-
siciones, se basa en estos requisitos. El desarrollo de los requisitos comienza con
un anlisis de la informacin contenida en el acta de constitucin del proyecto, el
registro de interesados y el plan de gestin de los interesados.
3. Definir el Alcance.
Definir el Alcance es el proceso que consiste en desarrollar una descripcin deta-
llada del proyecto y del producto. El beneficio clave de este proceso es que des-
cribe los lmites del producto, servicio o resultado mediante la especificacin de
cuales de los requisitos recopilados sern incluidos y cuales excluidos del alcance
del proyecto.
El Grfico 03-3 muestra las entradas, herramientas y tcnicas, y salidas de este
proceso.
80
Grfico N 03-3. Definir el Alcance: Entradas, Herramientas, Tcnicas y
Salidas
Dado que, es posible que, no todos los requisitos identificados en el proceso Re-
copilar Requisitos se puedan incluir en el proyecto, el proceso Definir el Alcance,
selecciona los requisitos definitivos del proyecto a partir de la documentacin de
requisitos entregada durante el proceso Recopilar Requisitos. A continuacin,
desarrolla una descripcin detallada del proyecto y del producto, servicio o resul-
tado.
La preparacin de un enunciado detallado del alcance del proyecto es fundamen-
tal para el xito del proyecto, y se elabora a partir de los entregables principales,
los supuestos y las restricciones documentados durante el inicio del proyecto.
Durante la planificacin del proyecto, el alcance del proyecto se define y se des-
cribe de manera ms especfica conforme se va recopilando mayor informacin
acerca del proyecto. Los riesgos, los supuestos y las restricciones existentes se
analizan para verificar que estn completos y se actualizan o se incorporan nue-
vos, segn sea necesario.
El proceso Definir el Alcance puede ser altamente iterativo. En el caso de pro-
yectos de ciclo de vida iterativo, se desarrollar una visin de alto nivel para el
proyecto global, pero el alcance detallado se determina para una iteracin a la
vez y la planificacin detallada de la siguiente iteracin, se va realizando conforme
avanza el trabajo en el alcance y los entregables actuales del proyecto.
4. Crear la EDT/WBS.
Crear la EDT/WBS es el proceso de subdividir los entregables del proyecto y el
trabajo del proyecto en componentes ms pequeos y ms fciles de manejar. El
beneficio clave de este proceso es que proporciona una visin estructurada de lo
que se debe entregar.
proceso.
81
Grfico N 03-4. Crear la EDT/WBS: Entradas, Herramientas, Tcnicas y
Salidas
La EDT/WBS es una descomposicin jerrquica del alcance total del trabajo a

realizar por el equipo del proyecto, para cumplir con los objetivos del proyecto y
crear los entregables requeridos. La EDT/WBS organiza y define el alcance total
del proyecto; representa el trabajo especificado en el enunciado del alcance del
proyecto aprobado y vigente.
El trabajo planificado est contenido en el nivel ms bajo de los componentes de
la EDT/WBS, denominados paquetes de trabajo. Un paquete de trabajo se puede
utilizar para agrupar las actividades donde el trabajo es programado, estimado,
seguido y controlado. En el contexto de la EDT/WBS, la palabra trabajo se refiere
a los productos o entregables del trabajo, que son el resultado de la actividad
realizada, y no a la actividad en s misma.
5. Definicin de la Pila de Producto.

La Lista de Producto es una lista ordenada de todo lo que podra ser necesario en
el producto, y es la nica fuente de requisitos para cualquier cambio a realizarse
en el producto. El Dueo de Producto es el responsable de la Lista de Producto,
incluyendo su contenido, disponibilidad y ordenacin.
Una Lista de Producto nunca est completa. El desarrollo ms temprano de la
misma solo refleja los requisitos conocidos y mejor entendidos al principio. La
Lista de Producto evoluciona a medida que el producto y el entorno en el que se
usar tambin lo hacen. La Lista de Producto es dinmica; cambia constante-
mente para identificar lo que el producto necesita para ser adecuado, competitivo
y til. Mientras el producto exista, su Lista de Producto tambin existe.
La Lista de Producto enumera todas las caractersticas, funcionalidades, requisi-
tos, mejoras y correcciones que constituyen cambios a ser hechos sobre el pro-
ducto para entregas futuras. Los elementos de la Lista de Producto tienen como
atributos la descripcin, la ordenacin, la estimacin y el valor.
5.1. Definicin del Tamao del Sprint.

Un Sprint es una iteracin Time-boxed de una a seis semanas de duracin
durante el cual el Scrum Master gua, facilita y protege al Equipo Scrum de
impedimentos, tanto internos como externos, durante el desarrollo de crea-
cin de los entregables. Esto ayuda a evitar el arrastramiento, o lentitud, de
la visin que podra afectar la meta del Sprint. Durante este tiempo, el equipo
trabaja para convertir las necesidades de la Lista de Producto Priorizada, en
82
funcionalidades de productos fciles de enviar. Para obtener los mximos be-
neficios de un proyecto Scrum, siempre se recomienda mantener el Sprint
Time-boxed a 4 semanas, a menos que, existan proyectos con requisitos muy
estables, donde los Sprints se pueden extender hasta 6 semanas.
5.2. Elaboracin de la Pila de Producto.

A medida que un producto es utilizado y se incrementa su valor, y el mercado
proporciona retroalimentacin, la Lista de Producto se convierte en una lista
ms larga y exhaustiva. Los requisitos nunca dejan de cambiar, as que la
Lista de Producto es un artefacto vivo. Los cambios en los requisitos de ne-
gocio, las condiciones del mercado o la tecnologa, podran causar cambios
en la Lista de Producto.
A menudo, varios Equipos Scrum trabajan juntos en el mismo producto. Para
describir el trabajo a realizar sobre el producto, se utiliza una nica Lista de
Producto. En ese caso podra emplearse un atributo de la Lista de Producto
para agrupar los elementos.
El refinamiento de la Lista de Producto es el acto de aadir detalle, estima-
ciones y orden a los elementos de la Lista de Producto. Se trata de un proceso
continuo, en el cual el Dueo de Producto y el Equipo de Desarrollo colaboran
acerca de los detalles de los elementos de la Lista de Producto. Durante el
refinamiento de la Lista de Producto, se examinan y revisan sus elementos.
El Equipo Scrum decide cmo? y cundo?, se hace el refinamiento. Este
usualmente consume no ms del 10% de la capacidad del Equipo de Desa-
rrollo. Sin embargo, los elementos de la Lista de Producto pueden actuali-
zarse en cualquier momento por el Dueo de Producto o a criterio suyo.
5.3. Elaboracin de Historias de Usuario.

Las Historias de Usuario surgieron en Xtreme Programming (XP) como una
respuesta a una situacin habitual en los proyectos de desarrollo de software:
los clientes o especialistas de negocio se comunican con los equipos de desa-
rrollo a travs de extensos documentos conocidos como especificaciones fun-
cionales. A su vez, las especificaciones funcionales son la documentacin de
supuestos y estn sujetas a interpretaciones, lo que causa malos entendidos
y que finalmente el software construido no se corresponda con la realidad
esperada.
Una de las principales razones por las cuales la utilizacin de especificaciones
detalladas, como medio de comunicacin, no conduce a resultados satisfac-
torios es porque solo cubre una porcin mnima (7%) del espectro de la co-
municacin humana: el contenido. Segn Albert Mehrabian, la comunicacin
humana se compone de tres partes:
En un 7%: El contenido (las palabras, lo dicho)
En un 38%: El tono de la voz
En un 55%: Las expresiones faciales
Por esto, se concluye que, para tener una comunicacin slida, completa, es
necesario el contacto cara a cara entre los interlocutores. En un esfuerzo
orientado a que esas conversaciones existan, podemos decir que las Historias
de Usuario son especificaciones funcionales que invitan a la conversacin,
para que el detalle sea consecuencia de esta ltima y no un remplazo.
Se recomienda que toda Historia de Usuario cumpla con 6 caractersticas que
podemos recordar bajo la regla mnemotcnica INVEST
83
Independientes (I): Las Historias de Usuario deben ser independientes
de forma tal que no se superpongan en funcionalidades y que puedan
planificarse y desarrollarse en cualquier orden. Muchas veces esta carac-
terstica no puede cumplirse para el 100% de las Historias. El objetivo
que debemos perseguir es preguntarnos y cuestionarnos en cada Historia
de Usuario, si hemos hecho todo lo posible para que esta sea indepen-
diente del resto.
Negociable (N): Una buena Historia de Usuario es Negociable. No es un
contrato explicito por el cual se debe entregar todo o nada. Por el contra-
rio, el alcance de las Historias (sus criterios de aceptacin) podran ser
variables: pueden incrementarse o eliminarse con el correr del desarrollo
y en funcin de la retroalimentacin del usuario y/o la performance del
Equipo. En el caso de que uno o varios criterios de aceptacin se eliminen
de una Historia de Usuario, estos se transformarn en una o varias His-
torias de Usuario nuevas. Esta es la herramienta que el Propietario del
Producto y el Equipo tienen para negociar el alcance de cada Sprint.
Valorable (V): Una Historia de Usuario debe ser Valorable por el Propie-
tario del Producto. Los Desarrolladores pueden tener actividades tcnicas
como parte de la Pila de Producto, pero para que puedan ser consideradas
una Historia de Usuario, deben ser enmarcadas de forma tal que el Pro-
pietario del Producto las considere importantes, caso contrario, no debe-
ran formar parte de la Pila del Producto.
Estimable (E): Una Historia de Usuario debera ser estimable. Mike

Cohn, identifica tres razones principales por las cuales una Historia de
Usuario no podra estimarse:
- La Historia de Usuario es demasiado grande. En este caso, la solucin
sera dividir la Historia de Usuario en historias ms pequeas, que sean
estimables.
- Falta de conocimiento funcional. En este caso la Historia de Usuario
vuelve al Propietario del Producto para bajar en detalle la Historia o
inclusive, es recomendable, tener una conversacin con el Equipo de
Desarrollo.
- Falta de conocimiento tcnico. Muchas veces el Equipo de Desarrollo
no tiene el conocimiento tcnico suficiente para realizar la estimacin.
En estos casos el Equipo de Desarrollo puede dividir la historia en 1)
un time-box conocido como spike que le permita investigar la solu-
cin y proveer una estimacin ms certera y 2) la funcionalidad a desa-
rrollar como parte de la Historia en s misma.
Pequea (Small): Toda Historia de Usuario debe ser lo suficientemente
pequea, de forma tal, que permita ser estimada por el Equipo de Desa-
rrollo. Algunos Equipos fijan el tamao de una Historia de usuario como
no ms de dos semanas de una persona. Si bien no es una medida expl-
cita, tener entre 4 y 6 Historias de Usuario por Sprint es una buena seal
de tamao. Las descripciones de las Historias de Usuario tambin debe-
ran ser pequeas, y escribirlas en fichas pequeas ayuda a que eso su-
ceda.
Verificable (Testeable): Una buena Historia de Usuario es Verificable.
Se espera que el Propietario del Producto no solo pueda describir la fun-
cionalidad que necesita, sino que tambin logre verificarla (probarla). Al-
gunos Equipos acostumbran solicitar los criterios de aceptacin antes de
desarrollar la Historia de Usuario. Si el Propietario del Producto no sabe
84
cmo verificar una Historia de Usuario o no puede enumerar los criterios
de aceptacin, esto podra ser una seal de que la Historia en cuestin no
est siendo lo suficientemente clara.
5.4. Priorizacin de la Pila de Producto.

La priorizacin se basa en tres factores principales: el valor, riesgo o incerti-
dumbre, y dependencias.
Valor: Es la responsabilidad del Propietario del Producto asegurar en pri-
mer lugar la entrega de los productos que ofrezcan el mayor valor. Incluso
un producto de gran valor no puede ser parte del primer relase, si hay
otros productos de mayor valor que son suficientes para un primer lan-
zamiento.
Riesgo e Incertidumbre: Cuanta ms incertidumbre existe, ms riesgoso
es el proyecto. Por lo tanto, es importante que los productos de mayor riesgo
en la Pila de Producto se les d mayor prioridad. Los productos que llevan un
mayor nivel de riesgo tambin requerirn acciones de mitigacin de riesgos.
Tratar con riesgos al principio del proyecto no garantiza que el proyecto ser
un xito, pero s mejorar la capacidad del equipo para hacer frente a los
riesgos.
Dependencias: Por lo general, no es posible crear una Pila de Producto en
la que no existen dependencias entre las Historias de Usuario. Los requisitos
funcionales, a menudo, dependen de otros requisitos funcionales e incluso no
funcionales. Estas dependencias pueden afectar. como se priorizan las Histo-
rias de Usuario en la Pila de Producto. Dos de las formas ms comunes para
resolver dependencias son, bien dividir una sola historia en varias partes, o
combinar historias interdependientes.
85
TEMA N 2: GESTIN DE TIEMPO Y COSTES DEL PROYECTO
INTRODUCCIN
La gestin del tiempo incluye todas las actividades necesarias para conseguir cumplir
con el objetivo de fecha de entrega del producto del proyecto. Incluye las siguientes
actividades: identificacin de actividades, secuenciamiento lgico de actividades, es-
timacin de duracin de las actividades y elaboracin del cronograma de proyecto.
Para la elaboracin del cronograma se aplican diversos mtodos como el PERT-CPM
con nivelado de recursos, la simulacin, y el mtodo de cadena crtica.
La Gestin de los Costos del Proyecto incluye los procesos involucrados en estimar,
presupuestar y controlar los costos de modo que se complete el proyecto dentro del
presupuesto aprobado.
Estos procesos interactan entre s y con procesos de las otras reas de conoci-
miento. Dependiendo de las necesidades del proyecto, cada proceso puede implicar
el esfuerzo de una persona o grupo de personas. Cada proceso se ejecuta por lo
menos una vez en cada proyecto y en una o ms fases del proyecto, en caso de que
el mismo est dividido en fases. En algunos proyectos, especialmente en aquellos de
alcance ms pequeo, la estimacin de costos y la preparacin del presupuesto de
costos estn tan estrechamente ligados que se consideran un solo proceso, que
puede realizar una sola persona en un periodo de tiempo relativamente corto.
1. Planificar la Gestin del Cronograma

Planificar la Gestin del Cronograma es el proceso de establecer las polticas, los
procedimientos y la documentacin necesarios para planificar, desarrollar, ges-
tionar, ejecutar y controlar el cronograma del proyecto. El beneficio clave de este
proceso es que proporciona gua y direccin sobre cmo se gestionar el crono-
grama del proyecto a lo largo del mismo. El Grfico 03-5 muestra las entradas,
herramientas y tcnicas, y salidas de este proceso.
Grfico N 03-5. Planificar la Gestin del Cronograma: Entradas, Herra-
mientas, Tcnicas y Salidas
El plan de gestin del cronograma es un componente del plan para la direccin del
proyecto. Segn las necesidades del proyecto, el plan de gestin del cronograma
puede ser formal o informal, de carcter detallado o ms general, e incluye los um-
brales de control apropiados. El plan de gestin del cronograma define la forma en
que se informar sobre las contingencias relativas al cronograma y la forma en que
se evaluarn las mismas. El plan de gestin del cronograma puede ser actualizado
para reflejar cualquier cambio en la manera de gestionar el cronograma.
86
2. Definir las Actividades
Definir las Actividades es el proceso de identificar y documentar las acciones es-
pecficas que se deben realizar para generar los entregables del proyecto. El be-
neficio clave de este proceso es el desglose de los paquetes de trabajo en activi-
dades que proporcionan una base para la estimacin, programacin, ejecucin,
monitoreo y control del trabajo del proyecto. El Grfico 03-6 muestra las entra-
das, herramientas y tcnicas, y salidas de este proceso.
Grfico N 03-6. Definir las Actividades: Entradas, Herramientas, Tcni-

cas y Salidas
En este proceso se encuentran implcitas la definicin y la planificacin de las

actividades del cronograma de modo que se cumplan los objetivos del proyecto.
El proceso Crear la EDT/WBS identifica los entregables del nivel ms bajo de la
EDT/WBS: el paquete de trabajo. Los paquetes de trabajo se descomponen nor-
malmente en componentes ms pequeos denominados actividades, que repre-
sentan el trabajo necesario para completar los paquetes de trabajo.
3. Secuenciar las Actividades

Secuenciar las Actividades es el proceso que consiste en identificar y documentar
las relaciones entre las actividades del proyecto. El beneficio clave de este proceso
reside en la definicin de la secuencia lgica de trabajo para obtener la mxima
eficiencia teniendo en cuenta todas las restricciones del proyecto. El Grfico 03-
7 muestra las entradas, herramientas y tcnicas, y salidas de este proceso.
Grfico N 03-7. Secuenciar las Actividades: Entradas, Herramientas,

Tcnicas y Salidas
87
Cada actividad e hito, a excepcin del primero y del ltimo, se conecta con al
menos un predecesor con una relacin lgica entre ellos, de final a inicio o de
inicio a inicio, y con al menos un sucesor con una relacin lgica entre ellos, de
final a inicio o final a final. Se deben disear las relaciones lgicas de manera que
se genere un cronograma del proyecto realista. Podra ser necesario incluir ade-
lantos o retrasos entre las actividades para poder sustentar un cronograma del
proyecto realista y viable. La secuenciacin puede llevarse a cabo mediante la
utilizacin de un software de gestin de proyectos o mediante tcnicas manuales
o automatizadas.
4. Estimar los Recursos de las Actividades

Estimar los Recursos de las Actividades es el proceso de estimar tipo y cantidades
de materiales, personas, equipos o suministros requeridos para llevar a cabo cada
una de las actividades. El beneficio clave de este proceso es que identifica el tipo,
cantidad y caractersticas de los recursos necesarios para completar la actividad,
lo que permite estimar el costo y la duracin de manera ms precisa. El Grfico
03-8 muestra las entradas, herramientas y tcnicas, y salidas de este proceso.
Grfico N 03-8. Estimar los Recursos de las Actividades: Entradas, He-

rramientas, Tcnicas y Salidas
El proceso Estimar los Recursos de las Actividades est estrechamente coordinado

con el proceso Estimar los Costos. Por ejemplo:
El equipo de un proyecto de construccin deber estar familiarizado con los
cdigos de edificacin locales. A menudo, es posible acceder fcilmente a este
conocimiento a travs de los vendedores locales. Sin embargo, si la mano de
obra local carece de experiencia en el uso de tcnicas de construcciones
inusuales o especializadas, el costo adicional de la contratacin de un consul-
tor puede resultar la manera ms eficaz de asegurar el conocimiento de los
cdigos de edificacin locales.
Un equipo de diseo de un automvil deber estar familiarizado con las tc-
nicas de ensamblado automtico ms recientes. El conocimiento requerido
puede obtenerse mediante la contratacin de un consultor, el envo de un
diseador a un seminario de robtica o la incorporacin en el equipo de pro-
yecto de alguna persona del departamento de produccin.
88
5. Estimar la Duracin de las Actividades
Estimar la Duracin de las Actividades es el proceso de realizar una estimacin
de la cantidad de perodos de trabajo necesarios para finalizar las actividades
individuales con los recursos estimados. El beneficio clave de este proceso es que
establece la cantidad de tiempo necesario para finalizar cada una de las activida-
des, lo cual constituye una entrada fundamental para el proceso Desarrollar el
Cronograma. El Grfico 03-9 muestra las entradas, herramientas y tcnicas, y
salidas de este proceso.
Grfico N 03-9. Estimar la Duracin de las Actividades: Entradas, He-

La estimacin de la duracin de las actividades utiliza informacin sobre el alcance

del trabajo que conlleva la actividad, los tipos de recursos necesarios, las canti-
dades estimadas de los mismos y sus calendarios de utilizacin. Las entradas para
las estimaciones de la duracin de las actividades, provienen de la persona o
grupo del equipo del proyecto que est ms familiarizado con la naturaleza del
trabajo a desarrollar en cada actividad especfica. La estimacin de la duracin se
elabora de manera progresiva, y el proceso tiene en cuenta la calidad y la dispo-
nibilidad de los datos de entrada.
Por ejemplo, conforme van estando disponibles datos ms detallados y precisos
sobre el trabajo de ingeniera y de diseo del proyecto, va aumentando la exac-
titud de las estimaciones de la duracin. Se puede asumir por lo tanto que la
estimacin de la duracin ser cada vez ms precisa y de mejor calidad.
El proceso Estimar la Duracin de las Actividades requiere que se realice una
estimacin del esfuerzo requerido y de la cantidad de recursos disponibles esti-
mados para completar la actividad. Estas estimaciones se utilizan para deducir de
manera aproximada la cantidad de perodos de trabajo (duracin de la actividad)
necesarios para completar la actividad, mediante la utilizacin de los calendarios
adecuados de proyecto y de recursos.
Para cada estimacin de duracin de una actividad se documentan todos los datos
y supuestos que la sustentan.
89
6. Desarrollar el Cronograma.
Desarrollar el Cronograma es el proceso de analizar las secuencias de actividades,

las duraciones, los requisitos de recursos y las restricciones del cronograma para
crear el modelo de programacin del proyecto.
El beneficio clave de este proceso es que, al incorporar actividades del crono-
grama, duraciones, recursos, disponibilidad de los recursos y relaciones lgicas
en la herramienta de programacin, sta genera un modelo de programacin con
fechas planificadas para completar las actividades del proyecto. El Grfico 03-10
muestra las entradas, herramientas y tcnicas, y salidas de este proceso.
Grfico N 03-10. Desarrollar el Cronograma: Entradas, Herramientas,

Tcnicas y Salidas
El desarrollo de un cronograma aceptable del proyecto es a menudo un proceso

iterativo. Se utiliza el modelo de programacin para determinar las fechas plani-
ficadas de inicio y fin de las actividades del proyecto, as como los hitos del mismo,
sobre la base de la exactitud de los datos de entrada. El desarrollo del cronograma
puede requerir el repaso y la revisin de las estimaciones de duracin as como
de recursos, para crear el modelo de programacin del proyecto que establezca
un cronograma aprobado del mismo, que pueda a su vez servir como lnea base
con respecto a la cual se pueda medir el avance. Por regla general, una vez de-
terminadas las fechas de inicio y fin de una actividad, se encomienda al personal
asignado a las tareas, la revisin de las mismas y la confirmacin de que las
fechas de inicio y fin establecidas no entren en conflicto con los calendarios de los
recursos ni con las actividades asignadas en el mbito de otros proyectos o ta-
reas; de este modo siguen siendo vlidas. Conforme el trabajo avanza, la revisin
90
y el mantenimiento del modelo de programacin del proyecto continan a lo largo
del mismo para mantener un cronograma realista.
7. Planificar la Gestin de los Costos

Planificar la Gestin de los Costos es el proceso que establece las polticas, los
procedimientos y la documentacin necesarios para planificar, gestionar, ejecutar
el gasto y controlar los costos del proyecto. El beneficio clave de este proceso es
que proporciona gua y direccin sobre cmo se gestionarn los costos del pro-
yecto a lo largo del mismo. El Grfico 03-11 muestra las entradas, herramientas
y tcnicas, y salidas de este proceso.
Grfico N 03-11. Planificar la Gestin de los Costos: Entradas, Herra-

Los procesos de gestin de costos, as como sus herramientas y tcnicas asocia-

das, se documentan en el plan de gestin de los costos. El plan de gestin de los
costos es un componente del plan para la direccin del proyecto.
8. Estimar los Costos.

Estimar los Costos es el proceso que consiste en desarrollar una estimacin apro-
ximada de los recursos monetarios necesarios para completar las actividades del
proyecto. El beneficio clave de este proceso es que determina el monto de los
costos requerido para completar el trabajo del proyecto. El Grfico 03-12 muestra
las entradas, herramientas y tcnicas, y salidas de este proceso.
Grfico N 03-12. Estimar los Costos: Entradas, Herramientas, Tcnicas

y Salidas
91
Las estimaciones de costos son una prediccin basada sobre la informacin dis-
ponible en un momento determinado. Las estimaciones de costos incluyen la iden-
tificacin y consideracin de diversas alternativas para el clculo de costos de
cara a iniciar y completar el proyecto. Para lograr un costo ptimo para el pro-
yecto, se debe tener en cuenta el balance entre costos y riesgos, tal como, hacer
en lugar de comprar; comprar en lugar de alquilar y la distribucin los recursos.
Las estimaciones de costos se expresan normalmente en unidades de alguna mo-
neda (p.ej., dlares, euros, yenes, etc.), aunque en algunos casos pueden em-
plearse otras unidades de medida, como las horas o los das de trabajo del per-
sonal para facilitar las comparaciones, al eliminar el efecto de las fluctuaciones
de las divisas.
Se deben revisar y refinar las estimaciones de costos a lo largo del proyecto para
ir reflejando los detalles adicionales a medida que stos se van conociendo y que
se van probando los supuestos de partida. La exactitud de la estimacin del costo
de un proyecto, aumenta conforme el proyecto avanza a travs de su ciclo de
vida. Un proyecto en su fase de inicio, por ejemplo, puede tener una estimacin
aproximada por orden de magnitud (ROM) en el rango de 25% a +75%.
En una etapa posterior del proyecto, conforme se va contando con ms informa-
cin, el rango de exactitud de las estimaciones puede reducirse a -5% a +10%.
En algunas organizaciones existen pautas sobre: cundo pueden efectuarse esos
refinamientos? y cul es el grado de confianza o exactitud esperado?
Las fuentes de informacin de entrada se derivan de las salidas de los procesos
del proyecto en otras reas de Conocimiento. Una vez recibida, toda esta infor-
macin permanecer disponible como entradas para todos los procesos de gestin
de los costos del proyecto.
Se estiman los costos para todos los recursos que se van a asignar al proyecto.
Estos incluyen, entre otros, el personal, los materiales, el equipamiento, los ser-
vicios y las instalaciones, as como otras categoras especiales, tales como el fac-
tor de inflacin, el costo de financiacin o el costo de contingencia.
Una estimacin de costos consiste en una evaluacin cuantitativa de los costos
probables que implican los recursos necesarios para completar la actividad. Las
estimaciones de costos se pueden presentar a nivel de actividad o en formato
resumido.
9. Determinar el Presupuesto.
Determinar el Presupuesto es el proceso que consiste en sumar los costos esti-
mados de las actividades individuales o paquetes de trabajo de cara a establecer
una lnea base de costos autorizada.
El beneficio clave de este proceso es que determina la lnea base de costos con
respecto a la cual se puede monitorear y controlar el desempeo del proyecto.
proceso.
92
Grfico N 03-13. Determinar el Presupuesto: Entradas, Herramientas,
Tcnicas y Salidas
El presupuesto de un proyecto contempla todos los fondos autorizados para eje-

cutar el proyecto. La lnea base de costos es la versin aprobada del presupuesto
del proyecto desde la perspectiva de sus diferentes fases, pero no incluye las
reservas de gestin.
93
LECTURA SELECCIONADA No 1: CREAR LA EDT/WBS
pginas 125 132.
Crear la EDT/WBS es el proceso de subdividir los entregables del proyecto y el trabajo

del proyecto en componentes ms pequeos y ms fciles de manejar. El beneficio
clave de este proceso es que proporciona una visin estructurada de lo que se debe
entregar.
proceso. El Grfico 03-15 representa el diagrama de flujo de datos del proceso.
Grfico 03-14: Crear la EDT/WBS: Entradas, Herramientas y Tcnicas, y Sa-

lidas
La EDT/WBS es una descomposicin jerrquica del alcance total del trabajo a realizar
por el equipo del proyecto para cumplir con los objetivos del proyecto y crear los
entregables requeridos. La EDT/WBS organiza y define el alcance total del proyecto
y representa el trabajo especificado en el enunciado del alcance del proyecto apro-
bado y vigente.
El trabajo planificado est contenido en el nivel ms bajo de los componentes de la
EDT/WBS, denominados paquetes de trabajo. Un paquete de trabajo se puede utilizar
para agrupar las actividades donde el trabajo es programado y estimado, seguido y
controlado.
En el contexto de la EDT/WBS, la palabra trabajo se refiere a los productos o entre-
gables del trabajo que son el resultado de la actividad realizada, y no a la actividad
en s misma.
94
Grfico N 03-15: Diagrama de Flujo de Datos de Crear la EDT/WBS
Crear la EDT/WBS: Herramientas y Tcnicas

1. Descomposicin
La descomposicin es una tcnica utilizada para dividir y subdividir el alcance del
proyecto y los entregables del proyecto en partes ms pequeas y manejables. El
paquete de trabajo es el trabajo definido en el nivel ms bajo de la EDT/WBS para el
cual se puede estimar y gestionar el costo y la duracin. El nivel de descomposicin
es a menudo guiado por el grado de control necesario para dirigir el proyecto de
manera efectiva. El nivel de detalle para los paquetes de trabajo vara en funcin del
tamao y la complejidad del proyecto. La descomposicin de la totalidad del trabajo
del proyecto en paquetes de trabajo generalmente implica las siguientes actividades:
Identificar y analizar los entregables y el trabajo relacionado;
Estructurar y organizar la EDT/WBS;
Descomponer los niveles superiores de la EDT/WBS en componentes detallados
de nivel inferior;
Desarrollar y asignar cdigos de identificacin a los componentes de la EDT/WBS;
y
Verificar que el grado de descomposicin de los entregables sea el adecuado.
95
El Grfico 03-16 muestra una parte de una EDT/WBS con algunas ramas desglosadas
hasta el nivel de los paquetes de trabajo.
Grfico 03-16: Ejemplo de una EDT/WBS desglosada hasta el nivel de Pa-
quetes de Trabajo
2. Juicio de Expertos
A menudo se utiliza el juicio de expertos para analizar la informacin necesaria para
descomponer los entregables del proyecto en componentes ms pequeos a fin de
crear una EDT/WBS eficaz. Dicho juicio y experiencia se aplican a los detalles tcnicos
del alcance del proyecto y se utilizan para conciliar las diferencias de opinin sobre
cmo desglosar el alcance global del proyecto de la mejor manera posible. Cualquier
grupo o individuo con capacitacin, conocimientos o experiencia relevantes en pro-
yectos o reas de negocio similares puede proporcionar este nivel de experiencia.
Tambin se puede acceder al juicio de expertos a travs de plantillas predefinidas
que proporcionan orientacin sobre cmo desglosar los entregables comunes de ma-
nera efectiva. Dichas plantillas pueden ser especficas de la industria o disciplina o
pueden provenir de la experiencia adquirida en proyectos similares. El director del
proyecto, en colaboracin con el equipo del proyecto, determina la descomposicin
final del alcance del proyecto en los paquetes de trabajo especficos que se utilizarn
para gestionar el trabajo del proyecto de manera eficaz.
La estructura de EDT/WBS se puede crear a travs de varios enfoques. Entre los
mtodos ms habituales se cuentan el enfoque descendente, el uso de guas espec-
ficas de la organizacin y el uso de plantillas de la EDT/WBS. Durante la integracin
de componentes de nivel inferior puede utilizarse un enfoque ascendente. La estruc-
tura de la EDT/WBS se puede representar de diferentes maneras, tales como:
Utilizando las fases del ciclo de vida del proyecto como segundo nivel de descom-
posicin, con los entregables del producto y del proyecto insertados en el tercer
nivel, como se ilustra en el Grfico 03-17.
96
Utilizando los entregables principales como segundo nivel de descomposicin,
como se muestra en el Grfico 03-18.
Incorporando componentes de nivel inferior que pueden desarrollar organizacio-
nes externas al equipo del proyecto, como por ejemplo trabajo contratado. As,
el proveedor desarrollar la EDT/WBS para el contrato como parte del trabajo
contratado.
Grfico 03-17: Ejemplo de una EDT/WBS organizada por Fases
La descomposicin de los componentes del nivel superior de la EDT/WBS requiere

subdividir el trabajo para cada uno de los entregables o componentes de nivel inferior
en sus elementos ms fundamentales, hasta el nivel en que los componentes de la
EDT/WBS representen productos, servicios o resultados verificables.
La EDT/WBS se puede estructurar como un esquema, como un organigrama, o me-
diante otro mtodo que represente un desglose jerrquico. La verificacin de la exac-
titud de la descomposicin requiere determinar que efectivamente los componentes
de nivel inferior de la EDT/WBS sean los necesarios y suficientes para completar los
entregables de alto nivel correspondientes. Cada entregable especfico puede tener
diferentes niveles de descomposicin. Para llegar al nivel del paquete de trabajo, en
el caso de algunos entregables slo se necesitar descomponer el trabajo hasta el
siguiente nivel, mientras que en otros casos ser necesario aadir niveles adicionales
de descomposicin. Conforme se descompone el trabajo en niveles de mayor detalle,
mejora la capacidad de planificar, gestionar y controlar el trabajo.
Sin embargo, una descomposicin excesiva puede ocasionar un esfuerzo de gestin
improductivo, un uso ineficiente de recursos, una disminucin de la eficiencia en la
realizacin del trabajo y una dificultad para agregar datos en diferentes niveles de la
EDT/WBS.
97
Grfico 03-18: Ejemplo de una EDT/WBS basada en los Entregables
Principales
En el caso de entregables o componentes cuya realizacin se site en un futuro le-

jano, es posible que no pueda realizarse la descomposicin. Por lo general el equipo
de direccin del proyecto espera hasta alcanzar un acuerdo en relacin con el entre-
gable o componente, para poder desarrollar los detalles de la EDT/WBS.
Esta tcnica se denomina a veces planificacin gradual.
La EDT/WBS representa todo el trabajo necesario para realizar el producto y el pro-
yecto, e incluye el trabajo de direccin del proyecto. El total del trabajo correspon-
diente a los niveles inferiores debera corresponder al acumulado para los niveles
superiores, de modo que no se omita nada y que no se efecte ningn trabajo extra.
Esto se denomina en ocasiones la regla del 100%.
98
INSTRUCCIONES
1. Desarrolla la pila de producto y su descomposicin en Historias de Usuario te-

niendo en consideracin los puntos descritos en la plantilla denominada Pila de
Producto.
99
TEMA N 3: GESTIN DE LA CALIDAD, RECURSOS HUMANOS Y
COMUNICACIONES DEL PROYECTO
INTRODUCCIN
La Gestin de la Calidad del Proyecto incluye los procesos y actividades de la organi-

zacin ejecutora que establecen las polticas de calidad, los objetivos y las responsa-
bilidades de calidad para que el proyecto satisfaga las necesidades para las que fue
acometido. La Gestin de la Calidad del Proyecto utiliza polticas y procedimientos
para implementar el sistema de gestin de la calidad de la organizacin en el contexto
del proyecto, y, en la forma que resulte adecuada, apoya las actividades de mejora
continua del proceso, tal y como las lleva a cabo la organizacin ejecutora. La Gestin
de la Calidad del Proyecto trabaja para asegurar que se alcancen y se validen los
requisitos del proyecto, incluidos los del producto.
La Gestin de los Recursos Humanos del Proyecto incluye los procesos que organizan,
gestionan y conducen al equipo del proyecto. El equipo del proyecto est compuesto
por las personas a las que se han asignado roles y responsabilidades para completar
el proyecto. Los miembros del equipo del proyecto pueden tener diferentes conjuntos
de habilidades, pueden estar asignados a tiempo completo o a tiempo parcial y se
pueden incorporar o retirar del equipo conforme avanza el proyecto. Tambin se
puede referir a los miembros del equipo del proyecto como personal del proyecto. Si
bien se asignan roles y responsabilidades especficos a cada miembro del equipo del
proyecto, la participacin de todos los miembros en la toma de decisiones y en la
planificacin del proyecto es beneficiosa. La participacin de los miembros del equipo
en la planificacin aporta su experiencia al proceso y fortalece su compromiso con el
proyecto.
La Gestin de las Comunicaciones del Proyecto incluye los procesos requeridos para
asegurar que la planificacin, recopilacin, creacin, distribucin, almacenamiento,
recuperacin, gestin, control, monitoreo y disposicin final de la informacin del
proyecto sean oportunos y adecuados. Los directores de proyecto emplean la mayor
parte de su tiempo comunicndose con los miembros del equipo y otros interesados
en el proyecto, tanto si son internos (en todos los niveles de la organizacin) como
externos a la misma.
Una comunicacin eficaz crea un puente entre diferentes interesados que pueden
tener diferentes antecedentes culturales y organizacionales, diferentes niveles de ex-
periencia, y diferentes perspectivas e intereses, lo cual impacta o influye en la eje-
cucin o resultado del proyecto.
1. Planificar la Gestin de la Calidad

Planificar la Gestin de la Calidad es el proceso de identificar los requisitos y/o
estndares de calidad para el proyecto y sus entregables, as como de documen-
tar cmo el proyecto demostrar el cumplimiento con los mismos. El beneficio
clave de este proceso es que proporciona gua y direccin sobre cmo se gestio-
nar y validar la calidad a lo largo del proyecto. El Grfico 03-19 muestra las
entradas, herramientas y tcnicas, y salidas de este proceso.
100
Grfico N 03-19. Planificar la Gestin de la Calidad: Entradas, Herra-
La planificacin de la calidad debe realizarse en paralelo con los dems procesos

de planificacin del proyecto. Por ejemplo, los cambios propuestos en los entre-
gables de cara a cumplir con las normas de calidad identificadas, pueden requerir
ajustes en el costo o en el cronograma, as como un anlisis de riesgo detallado
del impacto en los planes.
Las tcnicas de planificacin de calidad que se describen en esta seccin son las
que se emplean con ms frecuencia en los proyectos. Existen muchas otras que
pueden ser tiles para cierto tipo de proyectos o en determinadas reas de apli-
cacin.
2. Planificar la Gestin de los Recursos Humanos

Planificar la Gestin de los Recursos Humanos es el proceso de identificar y do-
cumentar los roles dentro de un proyecto, las responsabilidades, las habilidades
requeridas y las relaciones de comunicacin, as como de crear un plan para la
gestin de personal. El beneficio clave de este proceso es que establece los roles
y responsabilidades del proyecto, los organigramas del proyecto y el plan para la
gestin de personal, el cual incluye el cronograma para la adquisicin y liberacin
del personal. El Grfico 03-20 muestra las entradas, herramientas y tcnicas, y
salidas de este proceso.
Grfico N 03-20. Planificar la Gestin de los Recursos Humanos: Entra-

das, Herramientas, Tcnicas y Salidas
101
La planificacin de los recursos humanos se utiliza para determinar e identificar
aquellos recursos humanos que posean las habilidades requeridas para el xito
del proyecto. El plan de gestin de los recursos humanos describe la manera en
que se tratarn y estructurarn, en el mbito de un proyecto, los roles y respon-
sabilidades, las relaciones de comunicacin y la gestin de personal. Tambin
contiene el plan para la gestin de personal, el cual incluye los cronogramas para
la adquisicin y liberacin del personal, la identificacin de necesidades de capa-
citacin, las estrategias para desarrollar el espritu de equipo, los planes para los
programas de reconocimiento y recompensas, las consideraciones relativas al
cumplimiento, los asuntos relativos a la seguridad y el impacto del plan para la
gestin de personal en la organizacin.
Una planificacin de los recursos humanos eficaz debe tener en cuenta y planificar
la disponibilidad o la competencia por los recursos humanos escasos. En el mbito
del proyecto se pueden asignar roles tanto a equipos como a miembros del
equipo. Dichos equipos o miembros del equipo pueden pertenecer o no a la orga-
nizacin que lleva a cabo el proyecto. Es posible que otros proyectos compitan
por recursos humanos con las mismas competencias o conjuntos de habilidades.
Dados estos factores, los costos, cronogramas, riesgos, calidad y otras reas del
proyecto pueden verse afectados considerablemente.
3. Planificar la Gestin de las Comunicaciones

Planificar la Gestin de las Comunicaciones es el proceso de desarrollar un enfo-
que y un plan adecuados para las comunicaciones del proyecto sobre la base de
las necesidades y los requisitos de informacin de los interesados y de los activos
de la organizacin disponibles. El beneficio clave de este proceso es que identifica
y documenta el enfoque a utilizar para comunicarse con los interesados de la
manera ms eficaz y eficiente. El Grfico 03-21 muestra las entradas, herramien-
tas y tcnicas, y salidas de este proceso.
Grfico N 03-21. Planificar la Gestin de las Comunicaciones: Entradas,

Herramientas, Tcnicas y Salidas
Planificar las comunicaciones del proyecto es importante para lograr el xito final
de cualquier proyecto.
Una planificacin incorrecta de las comunicaciones puede dar lugar a problemas
tales como demoras en la entrega de mensajes, comunicacin de informacin a
102
la audiencia equivocada, o comunicacin insuficiente con los interesados y mala
interpretacin o comprensin del mensaje transmitido.
En la mayora de los proyectos, la planificacin de las comunicaciones se realiza
de forma muy temprana, por ejemplo, durante el desarrollo del plan para la di-
reccin del proyecto. Esto permite la asignacin de los recursos adecuados, tales
como tiempo y presupuesto, a las actividades de comunicacin. Una comunicacin
eficaz significa que la informacin se suministra en el formato adecuado, en el
momento preciso, a la audiencia correcta y con el impacto deseado. Una comu-
nicacin eficiente implica proporcionar exclusivamente la informacin necesaria.
Si bien todos los proyectos comparten la necesidad de comunicar informacin
sobre el proyecto, las necesidades de informacin y los mtodos de distribucin
pueden variar ampliamente. Adems, durante este proceso se han de tener en
cuenta y documentar adecuadamente los mtodos de almacenamiento, recupe-
racin y disposicin final de la informacin del proyecto. Las consideraciones im-
portantes que puede ser necesario tener en cuenta incluyen, entre otras:
Quin necesita la informacin?, Qu informacin necesita? y Quin est
autorizado para acceder a ella?;
Cundo van a necesitar la informacin?;
Dnde se debe almacenar la informacin?;
En qu formato se debe almacenar la informacin?;
Cmo se puede recuperar la informacin?; y
Si es necesario tener en cuenta zonas horarias, barreras de idioma y conside-
raciones interculturales.
Los resultados del proceso Planificar la Gestin de las Comunicaciones deben re-
visarse con regularidad a lo largo del proyecto y modificarse segn sea necesario
para asegurar la continuidad de su aplicabilidad.
103
TEMA N 4: GESTIN DE RIESGOS DEL PROYECTO
INTRODUCCIN
El riesgo de un proyecto es un evento o condicin incierta que, de producirse, tiene

un efecto positivo o negativo en uno o ms de los objetivos del proyecto, tales como
el alcance, el cronograma, el costo y la calidad.
Un riesgo puede tener una o ms causas y, de materializarse, uno o ms impactos.
Una causa puede ser un requisito especificado o potencial, un supuesto, una restric-
cin o una condicin que crea la posibilidad de consecuencias tanto negativas como
positivas. Por ejemplo, entre las causas se podra incluir el requisito de obtener un
permiso ambiental para realizar el trabajo, o contar con una cantidad limitada de
personal asignado para el diseo del proyecto. El riesgo consiste en que la agencia
que otorga el permiso pueda tardar ms de lo previsto en emitir el permiso o, en el
caso de una oportunidad, que se disponga de ms personal de desarrollo capaz de
participar en el diseo y de ser asignado al proyecto. Si se produjese alguno de estos
eventos inciertos, podra haber un impacto en el alcance, el costo, el cronograma, la
calidad o el desempeo del proyecto. Las condiciones de riesgo pueden incluir aspec-
tos del entorno del proyecto o de la organizacin que contribuyan a poner en riesgo
el proyecto, tales como las prcticas deficientes de direccin de proyectos, la falta de
sistemas de gestin integrados, la concurrencia de varios proyectos o la dependencia
de participantes externos fuera del mbito de control directo del proyecto.
Los riesgos del proyecto tienen su origen en la incertidumbre que est presente en
todos los proyectos.
Los riesgos conocidos son aquellos que han sido identificados y analizados, lo que
hace posible planificar respuestas para tales riesgos. A los riesgos conocidos que no
se pueden gestionar de manera proactiva se les debe asignar una reserva para con-
tingencias. Los riesgos desconocidos no se pueden gestionar de manera proactiva y
por lo tanto se les puede asignar una reserva de gestin. Un riesgo negativo del
proyecto que se ha materializado se considera un problema.
Los riesgos individuales del proyecto son diferentes del riesgo global del proyecto. El
riesgo global del proyecto representa el efecto de la incertidumbre sobre el proyecto
en su conjunto. Es ms que la suma de los riesgos individuales del proyecto, ya que
incluye todas las fuentes de incertidumbre del proyecto. Representa la exposicin de
los interesados a las implicaciones de las variaciones en los resultados del proyecto,
tanto positiva como negativa.
Las organizaciones perciben el riesgo como el efecto de la incertidumbre sobre los
objetivos del proyecto y de la organizacin. Las organizaciones y los interesados es-
tn dispuestos a aceptar diferentes niveles de riesgo, en funcin de su actitud frente
al riesgo. Las actitudes frente al riesgo de la organizacin y de los interesados pueden
verse afectadas por una serie de factores, los cuales se clasifican a grandes rasgos
en tres categoras:
Apetito de riesgo, que es el grado de incertidumbre que una entidad est dis-
puesta a aceptar, con miras a una recompensa.
Tolerancia al riesgo, que es el grado, cantidad o volumen de riesgo que podr
resistir una organizacin o individuo.
Umbral de riesgo, que se refiere a la medida del nivel de incertidumbre o el
nivel de impacto en el que un interesado pueda tener particular inters. Por de-
bajo de ese umbral de riesgo, la organizacin aceptar el riesgo. Por encima de
ese umbral de riesgo, la organizacin no tolerar el riesgo.
104
1. Planificar la Gestin de los Riesgos
Planificar la Gestin de los Riesgos es el proceso de definir cmo realizar las ac-
tividades de gestin de riesgos de un proyecto. El beneficio clave de este proceso
es que asegura que el nivel, el tipo y la visibilidad de la gestin de riesgos son
acordes tanto con los riesgos como con la importancia del proyecto para la orga-
nizacin.
El plan de gestin de los riesgos es vital para comunicarse y obtener el acuerdo
as como el apoyo de todos los interesados, a fin de asegurar que el proceso de
gestin de riesgos sea respaldado y llevado a cabo de manera eficaz a lo largo
del ciclo de vida del proyecto.
proceso.
Grfico N 03-22. Planificar la Gestin de los Riesgos: Entradas,

Una planificacin cuidadosa y explcita mejora la probabilidad de xito de los otros

procesos de gestin de riesgos. La planificacin tambin es importante para pro-
porcionar los recursos y el tiempo suficientes para las actividades de gestin de
riesgos y para establecer una base acordada para la evaluacin de riesgos.
El proceso Planificar la Gestin de los Riesgos debe iniciarse tan pronto como se
concibe el proyecto, adems, debe completarse en las fases tempranas de plani-
ficacin del mismo.
2. Identificar los Riesgos

Identificar los Riesgos es el proceso de determinar los riesgos que pueden afectar
al proyecto y documentar sus caractersticas. El beneficio clave de este proceso
es la documentacin de los riesgos existentes y el conocimiento y la capacidad
que confiere al equipo del proyecto para anticipar eventos.
proceso.
105
Grfico N 03-23. Identificar los Riesgos: Entradas, Herramientas,
Tcnicas y Salidas
Los participantes en las actividades de identificacin de riesgos pueden incluir: el

director del proyecto, los miembros del equipo del proyecto, el equipo de gestin
de riesgos (si est asignado), clientes, expertos en la materia externos al equipo
del proyecto, usuarios finales, otros directores de proyecto, interesados y exper-
tos en gestin de riesgos. Si bien estas personas son a menudo participantes
clave en la identificacin de riesgos, se debera fomentar la identificacin de ries-
gos potenciales por parte de todo el personal del proyecto.
Identificar los riesgos es un proceso iterativo debido a que pueden evolucionar o
se pueden descubrir nuevos riesgos conforme el proyecto avanza a lo largo de su
ciclo de vida. La frecuencia de iteracin y la participacin en cada ciclo vara de
una situacin a otra. El formato de las declaraciones de riesgos debe ser consis-
tente para asegurar que cada riesgo se comprenda claramente y sin ambigeda-
des a fin de poder llevar a cabo un anlisis y un desarrollo de respuestas eficaces.
La declaracin de riesgos debe reforzar la capacidad de comparar el efecto rela-
tivo de un riesgo con respecto a otros riesgos del proyecto. El proceso debe invo-
lucrar al equipo del proyecto de modo que pueda desarrollar y mantener un sen-
tido de propiedad y responsabilidad por los riesgos y las acciones de respuesta
asociadas. Los interesados externos al equipo del proyecto pueden proporcionar
informacin objetiva adicional.
3. Realizar el Anlisis Cualitativo de Riesgos

Realizar el Anlisis Cualitativo de Riesgos es el proceso de priorizar riesgos para
anlisis o accin posterior, evaluando y combinando la probabilidad de ocurrencia
e impacto de dichos riesgos. El beneficio clave de este proceso es que permite a
los directores de proyecto reducir el nivel de incertidumbre y concentrarse en los
riesgos de alta prioridad.
proceso.
106
Grfico N 03-24. Realizar el Anlisis Cualitativo de Riesgos: Entradas,
Realizar el Anlisis Cualitativo de Riesgos evala la prioridad de los riesgos iden-

tificados a travs de la probabilidad relativa de ocurrencia, del impacto corres-
pondiente sobre los objetivos del proyecto si los riesgos llegaran a presentarse,
as como de otros factores, tales como el plazo de respuesta y la tolerancia al
riesgo por parte de la organizacin, asociados con las restricciones del proyecto
en trminos de costo, cronograma, alcance y calidad. Dichas evaluaciones refle-
jan la actitud frente a los riesgos, tanto del equipo del proyecto como de otros
interesados. Por lo tanto, una evaluacin eficaz requiere la identificacin explcita
y la gestin de los enfoques frente al riesgo por parte de los participantes clave
en el marco del proceso Realizar el Anlisis Cualitativo de Riesgos. Cuando estos
enfoques, frente al riesgo, introducen sesgos en la evaluacin de los riesgos iden-
tificados, debe prestarse atencin en la identificacin de dichos sesgos y en su
correccin.
La definicin de niveles de probabilidad e impacto puede reducir la influencia de
sesgos. La criticidad temporal de las acciones relacionadas con los riesgos puede
magnificar la importancia de un riesgo. Una evaluacin de la calidad de la infor-
macin disponible sobre los riesgos del proyecto tambin ayuda a clarificar la
evaluacin de la importancia del riesgo para el proyecto.
Realizar el Anlisis Cualitativo de Riesgos es por lo general un medio rpido y
econmico de establecer prioridades para Planificar la Respuesta a los Riesgos y
sienta las bases para Realizar el Anlisis Cuantitativo de Riesgos, si fuera nece-
sario. El proceso Realizar el Anlisis Cualitativo de Riesgos se lleva a cabo de
manera regular a lo largo del ciclo de vida del proyecto, tal como se define en el
plan de gestin de los riesgos del proyecto.
Este proceso puede conducir al proceso Realizar el Anlisis Cuantitativo de Ries-
gos o directamente al proceso Planificar la Respuesta a los Riesgos.
4. Realizar el Anlisis Cuantitativo de Riesgos

Realizar el Anlisis Cuantitativo de Riesgos es el proceso de analizar numrica-
mente el efecto de los riesgos identificados sobre los objetivos generales del pro-
yecto. El beneficio clave de este proceso es que genera informacin cuantitativa
sobre los riesgos para apoyar la toma de decisiones a fin de reducir la incertidum-
bre del proyecto.
proceso.
107
Grfico N 03-25. Realizar el Anlisis Cuantitativo de Riesgos: Entradas,
El proceso Realizar el Anlisis Cuantitativo de Riesgos se aplica a los riesgos prio-

rizados mediante el proceso Realizar el Anlisis Cualitativo de Riesgos por tener
un posible impacto significativo sobre las demandas concurrentes del proyecto.
El proceso Realizar el Anlisis Cuantitativo de Riesgos analiza el efecto de dichos
riesgos sobre los objetivos del proyecto. Se utiliza fundamentalmente para eva-
luar el efecto acumulativo de todos los riesgos que afectan el proyecto. Cuando
los riesgos guan el anlisis cuantitativo, el proceso se puede utilizar para asignar
a esos riesgos una prioridad numrica individual.
Por lo general, el proceso Realizar el Anlisis Cuantitativo de Riesgos se realiza
despus del proceso Realizar el Anlisis Cualitativo de Riesgos. En algunos casos
puede que no sea posible llevar a cabo el proceso Realizar el Anlisis Cuantitativo
de Riesgos, debido a la falta de datos suficientes para desarrollar los modelos
adecuados. El director del proyecto debe utilizar el juicio de expertos para deter-
minar la necesidad y la viabilidad del anlisis cuantitativo de riesgos. La disponi-
bilidad de tiempo y presupuesto, as como la necesidad de declaraciones cualita-
tivas o cuantitativas acerca de los riesgos y sus impactos, determinarn, el m-
todo o mtodos a emplear para un determinado proyecto.
El proceso Realizar el Anlisis Cuantitativo de Riesgos debe repetirse, segn las
necesidades, como parte del proceso Controlar los Riesgos, para determinar si se
ha reducido satisfactoriamente el riesgo global del proyecto. Las tendencias pue-
den indicar la necesidad de una mayor o menor atencin a las actividades ade-
cuadas en materia de gestin de riesgos.
5. Planificar la Respuesta a los Riesgos

Planificar la Respuesta a los Riesgos es el proceso de desarrollar opciones y ac-
ciones para mejorar las oportunidades y reducir las amenazas a los objetivos del
proyecto. El beneficio clave de este proceso es que aborda los riesgos en funcin
de su prioridad, introduciendo recursos y actividades en el presupuesto, el crono-
grama, as como en el plan para la direccin del proyecto; segn las necesidades.
proceso.
108
Grfico N 03-26. Planificar la Respuesta a los Riesgos: Entradas,
El proceso Planificar la Respuesta a los Riesgos se realiza despus del proceso

Realizar el Anlisis Cuantitativo de Riesgos (en caso de que se utilice). Cada res-
puesta a un riesgo requiere una comprensin del mecanismo por el cual se abor-
dar el riesgo. Este es el mecanismo utilizado para analizar si el plan de respuesta
a los riesgos est teniendo el efecto deseado. Incluye la identificacin y asignacin
de una persona (un propietario de la respuesta a los riesgos) para que asuma la
responsabilidad de cada una de las respuestas a los riesgos acordadas y financia-
das. Las respuestas a los riesgos deben adecuarse a la importancia del riesgo, ser
rentables con relacin al desafo a cumplir, realistas dentro del contexto del pro-
yecto, acordadas por todas las partes involucradas y deben estar a cargo de una
persona responsable. A menudo es necesario seleccionar la respuesta ptima a
los riesgos entre varias opciones.
El proceso Planificar la Respuesta a los Riesgos presenta las metodologas comn-
mente utilizadas para planificar las respuestas a los riesgos. Los riesgos incluyen,
tanto las amenazas como las oportunidades, que pueden afectar al xito del pro-
yecto, y se debaten las respuestas para cada una de ellas.
109
GUA PRCTICA DE GESTIN DE RIESGOS
Instituto Nacional de Tecnologas de la Comunicacin, (2008), pginas 6 20.
La gua rpida de gestin de riesgos forma satisfactoria. Una fuente de

pretende proporcionar una visin intro- amenazas no plantea un riesgo
ductoria de este proceso. Se expon- cuando no hay vulnerabilidades
drn algunos conceptos clave para en- que puedan ser activadas.
tender el proceso, se resaltar la im-
Impacto. El impacto es la materia-
portancia que tiene la gestin de ries-
lizacin de un riesgo; una medida
gos en el desarrollo de productos soft-
del grado de dao o cambio sobre
ware. Tambin se mencionarn los
un activo, entendiendo como riesgo
principales roles que intervienen en el
la probabilidad de que un evento
proceso de gestin de riesgos y cules
desfavorable ocurra y que tendra
son sus responsabilidades.
un impacto negativo si se llegase a
En el segundo apartado de la gua se materializar.
describen las distintas actividades que
conforman el proceso de gestin de
riesgos, indicando en cada una de ellas Suposiciones. Las suposiciones
entradas, salidas, herramientas, ta- son afirmaciones aceptadas como
reas, etc. reales, pero sin ningn tipo de
prueba que las sustente. Tambin
es verdad que con el tiempo se
1. Conceptos puede determinar si las suposicio-
nes son verdaderas o falsas.
Es importante saber diferenciar
ciertos conceptos que a menudo se
confunden o incluso se utilizan in-
distintamente para hacer referen- 2. Qu es un Riesgo?
cia al riesgo. A lo largo de esta gua En el apartado anterior ya se defi-
van a parecer conceptos tales como ni de forma breve qu es un
amenaza, impacto, vulnerabilidad, riesgo, pero de forma genrica.
para definir y describir aspectos re- Esta gua se centrar en los riesgos
lacionados con los riesgos. Por ello, dentro de un proyecto.
en este apartado van a aclararse
ciertos conceptos de tal forma que Un riesgo de un proyecto es un
al leer el resto de la gua no haya evento o condicin incierto que, si
confusiones. se produce, tendr un efecto posi-
tivo o negativo sobre al menos un
Activo. Cualquier recurso de SW, objetivo del proyecto, como
HW, datos, administrativo, fsico, tiempo, coste, alcance o calidad, es
de personal, de comunicaciones. decir, cuando el objetivo de tiempo
Vulnerabilidad. Una vulnerabili- de un proyecto es cumplir con el
dad es una debilidad que puede ser cronograma acordado; cuando el
activada de forma accidental o in- objetivo de coste del proyecto es
tencionadamente. Es un factor de cumplir con el coste acordado, etc.
riesgo interno de un elemento ex- Las organizaciones perciben los
puesto a una amenaza de ser sus- riesgos por:
ceptible a sufrir un dao y de en-
contrar dificultades en recuperarse - su relacin con las amenazas al
posteriormente. xito del proyecto, o
Amenaza. Una amenaza es la po- - por las oportunidades de mejo-

sibilidad de que se produzca una rar las posibilidades de xito del
determinada vulnerabilidad de proyecto.
110
Los riesgos que son amenazas para ser monitorizados para beneficiar
el proyecto pueden ser aceptados si los objetivos del proyecto.
el riesgo est en equilibrio con el
Para tener xito, la organizacin
beneficio que puede obtenerse al
debe estar comprometida a tratar
tomarlo.
la gestin de riesgos de forma
Los riesgos que constituyen opor- proactiva y consistente durante
tunidades, como la aceleracin del todo el proyecto.
trabajo que puede lograrse asig-
nando personal adicional, pueden
Grfico 03-27: Relacin coste - riesgo
El riesgo del proyecto tiene su ori-

gen en la incertidumbre que est
Un riesgo puede tener una o ms
presente en todos los proyectos.
causas y, si se produce, uno o ms
Existen distintos tipos de riesgos:
impactos. Por ejemplo, una causa
puede ser necesitar un permiso - Los riesgos conocidos son
ambiental para hacer el trabajo, o aquellos que han sido identifi-
que se asigne personal limitado cados y analizados, y es posible
para disear el proyecto. El evento planificar las acciones a tomar
de riesgo en ambos casos sera que al respecto tal y como se ver
la agencia que otorga el permiso en apartados sucesivos.
podra tardar ms de lo previsto en
- Los riesgos desconocidos no
emitir el permiso, o que el personal
pueden gestionarse de forma
de diseo disponible y asignado no
proactiva, y una respuesta pru-
sea suficiente para la actividad. Si
dente del equipo del proyecto
ocurre alguno de estos eventos in-
puede ser asignar una contin-
ciertos, puede haber un impacto
gencia general contra dichos
sobre el coste, el cronograma o el
riesgos, as como contra los
rendimiento del proyecto.
riesgos conocidos para los cua-
111
les quizs no sea rentable o po- - Se reducen los costes del pro-
sible desarrollar respuestas yecto
proactivas.
- Se mejora la satisfaccin del
El riesgo est compuesto de tres cliente
componentes esenciales:
- Se incrementa la capacidad y
- un evento definible probabilidades de xito
- probabilidad de ocurrencia - Facilita el desarrollo del pro-
yecto
- consecuencia de la ocurrencia
(impacto) - Disminuye drsticamente las
sorpresas en los proyectos
- Ayuda a la empresa a conseguir
3. En qu consiste la gestin de
los objetivos de negocio y pro-
riesgos de un proyecto?
yecto evitando problemas que
La gestin de riesgos es un proceso podran causar prdidas inespe-
iterativo y recurrente a lo largo de radas y no planificadas.
toda la vida del proyecto. El prop-
En toda gestin de riesgos es nece-
sito de la gestin de riesgos es mi-
sario desarrollar un plan de gestin
nimizar la probabilidad y conse-
de riesgos, que debera describir:
cuencias de los riesgos negativos
(o amenazas) y maximizar la pro- - Una estrategia de gestin de
babilidad y consecuencias de los riesgos.
riesgos positivos (u oportunidades)
- Alcance del esfuerzo en gestin
identificados para el proyecto de tal
de riesgos.
forma que los objetivos de los pro-
yectos se cumplan. Esto se consi- - Cmo se piensa llevar a cabo la
gue siguiendo una serie de pautas: identificacin de riesgos.
- Identificar todos los riesgos co- - Cmo se va a llevar a cabo el
nocidos del proyecto anlisis de riesgos (cualitativo,
cuantitativo, priorizacin).
- Realizar una evaluacin de la
probabilidad de ocurrencia y del - Cmo se va a llevar a cabo el
impacto potencial plan de respuesta. (no debe
contener los propios planes de
- Cuantificar cual sera el coste
respuesta ni tratar riesgos con-
de los riesgos en caso de que
cretos).
ocurrieran
- Cmo se va a llevar a cabo la
- Crear planes de accin para
monitorizacin y control.
gestionar los riesgos de alta
prioridad - Presupuesto de gestin de ries-
gos.
- Reconocer y gestionar los ries-
gos lo antes posible - Calendario de actividades de
gestin de riesgos.
Los beneficios que se obtienen al
llevar a cabo una buena gestin de - Roles y responsabilidades.
los riesgos son:
112
GLOSARIO DE LA UNIDAD III
1. Aceptar el Riesgo. Una estrategia de respuesta a los riesgos segn la cual

el equipo del proyecto decide reconocer el riesgo y no tomar ninguna medida
a menos que el riesgo ocurra.
2. Alcance. La suma de productos, servicios y resultados a ser proporcionados
como un proyecto. Vase tambin Alcance del Proyecto y Alcance del Pro-
ducto.
3. Alcance del Producto. Los rasgos y funciones que caracterizan a un pro-
ducto, servicio o resultado.
4. Alcance del Proyecto. El trabajo realizado para entregar un producto, ser-
vicio o resultado con las funciones y caractersticas especificadas.
5. Anlisis Mediante rbol de Decisiones. Una tcnica de diagramacin y
clculo para evaluar las implicancias de una cadena de opciones mltiples en
presencia de incertidumbre.
6. Anlisis Monte Carlo. Tcnica que calcula o itera el costo del proyecto o el
cronograma del proyecto muchas veces utilizando valores de entrada selec-
cionados al azar a partir de distribuciones de probabilidad de costos o dura-
ciones posibles, para calcular una distribucin de los costos totales del pro-
yecto o fechas de conclusin posibles.
7. Apetito al Riesgo. El grado de incertidumbre que una entidad est dispuesta
a aceptar, con miras a una recompensa.
113
BIBLIOGRAFA DE LA UNIDAD III

SCRUMstudy.
Mxico: Pearson.
Juego.




MIT Sloan.
114
AUTOEVALUACIN No 3
1. Es el proceso que radica en definir y documentar las necesidades de

los interesados en aras de cumplir con los objetivos del proyecto.
A) Definir el Alcance
B) Recopilar Requisitos
C) Asegurar el Alcance
D) Crear la Estructura de Desglose del Trabajo (EDT)
2. Son entradas del proceso Recopilar Requisitos las siguientes:
A) El Plan de Gestin del Proyecto y las Entrevistas

B) Las Entrevistas y la Estructura de Desglose del Trabajo (EDT)
C) Acta de Constitucin del Proyecto y el Registro de los Interesados
D) El Registro de los Interesados y el Plan de Gestin del Proyecto
3. Tcnica en la cual un grupo seleccionado de expertos contesta de ma-

nera annima y proporciona realimentacin al Administrador de Pro-
yectos se conoce como:
A) La Tcnica Delphi
B) Tormenta de Ideas
C) Diagrama de Afinidad
D) Ninguna de las opciones es correcta
4. Luisa determina las salidas del proceso Recopilar Requisitos. Cul

de las opciones NO es una salida de este proceso?
A) Matriz de los Interesados

B) Documentacin de los Requisitos
C) Plan de Gestin de los Requisitos
D) Matriz de Rastreabilidad
5. Durante cul proceso se elabora la Declaracin del Alcance del Pro-

yecto?
A) Inicio
B) Planeacin
C) Ejecucin
D) Monitoreo y Control
6. Rita, quien acaba de asumir un nuevo rol como Administradora de

Proyectos, requiere evaluar un proceso que conste en subdividir en
componentes ms pequeos los entregables del proyecto. Rita est
ante la gestin de:
A) Identificar los Involucrados

B) Identificar el plan de las comunicaciones
115
C) Verificar el Alcance del Proyecto
D) Crear la EDT (Estructura de Desglose del Trabajo)
7. La Estructura de Desglose de Trabajo es una herramienta efectiva de

comunicacin mejor utilizada por:
A) El Equipo de diseo de Tecnologa e Infraestructura

B) El Gerente Funcional
C) El Cliente
D) Los involucrados
8. Cul de las siguientes afirmaciones es FALSA referente a la Estruc-

tura de Desglose de Trabajo (EDT)?
A) Las actividades deben estar organizadas en la secuencia que van a realizarse.

B) Cada tem tiene un nico identificador.
C) La EDT representa el 100% del trabajo a realizarse en el proyecto.
D) Cada nivel de la EDT provee una representacin ms pequea del trabajo.
9. Cul de las siguientes actividades se realiza PRIMERO?
A) Elaborar la documentacin de los requerimientos

B) Elaborar la EDT del proyecto
C) Elaborar la lista de actividades del proyecto
D) Elaborar la lnea base del alcance del proyecto
10.Un nuevo gerente de proyectos consulta sobre la elaboracin de la

EDT y el tipo de software que se debe utilizar. Siendo usted un ge-
rente con amplia experiencia le indica que el software no es relevante,
lo ms importante en referencia a la EDT es:
A) El diagrama de Gantt
B) El involucramiento del equipo del proyecto y su compromiso
C) Las actividades de alto nivel
D) Los riesgos de bajo nivel
116
UNIDAD IV: PLANIFICACIN Y CIERRE DEL PROYECTO
DIAGRAMA DE PRESENTACIN DE LA UNIDAD IV

7 Videoclase. 1. Comprende la impor- 1. Reconoce y
PACHERRES, L. (2015). Planificar tancia de la elaboracin describe la im-
la Gestin de los Interesados. Re- de entregables de la portancia de
cuperado de Fase de Planificacin del implementar
https://www.youtube.com/watch? Proyecto. una metodolo-
v=tiE1Zvt7m9w&list= 2. Evala y aplica tcnicas ga de gestin
PLlpx2GAbD- y herramientas para la de proyectos
geigFQPvtSECcpI4ojCpGJKE&in- planificacin de la ges- en la empresa.
dex=54 tin de adquisiciones 2. Reconoce y
del proyecto. describe la im-
Tema N 1: Gestin de las Ad- 3. Analiza y aplica tcnicas portancia de la
quisiciones del Proyecto. y herramientas para la gestin de pro-
1. Planificar la Gestin de las Ad- identificacin de los in- yectos para
quisiciones. teresados del proyecto. una implemen-
tacin exitosa
Tema N 2: Gestin de los In- Actividad N 4 que conlleve al
teresados del Proyecto. mejoramiento
Desarrolla la matriz de
1. Planificar la Gestin de los In- de una em-
identificacin de interesa-
teresados. presa y para
dos teniendo en considera-
las actividades
cin los puntos descritos en
8 Videoclase. o procesos a
la plantilla denominada
PACHERRES, L. (2015). Desarro- realizar.
Identificacin de Interesa-
llar el Plan para la Direccin. Recu- 3. Fomenta el tra-
dos
perado de bajo en equipo
4. Reconoce la importan-
https://www.youtube.com/watch? aplicando tc-
cia de la elaboracin de
v=iWZ8K6NHjkk&index= nicas y herra-
entregables de la Fase
12&list=PLlpx2GAbD- mientas de
de Cierre del Proyecto.
geigFQPvtSECcpI4ojCpGJKE gestin de pro-
5. Integra los documentos
yectos para
elaborados en un nico
Tema N 3: Plan de Direccin una consecu-
documento denomi-
de Proyectos. cin de los ob-
nado Plan de Direccin
1. Integracin de planes subsi- jetivos organi-
del Proyecto.
diarios zacionales.
117
2. Desarrollo del Plan de Direc- 6. Identifica y recopila las 4. Acta con tica
cin de Proyectos: Entradas. lecciones aprendidas y y basado en
3. Desarrollo del Plan de Direc- buenas prcticas del valores.
cin de Proyectos: Herramien- proyecto. 5. Desarrolla lide-
tas y Tcnicas. razgo, capaci-
4. Desarrollo del Plan de Direc- Tarea Acadmica N 2 dad de nego-
cin de Proyectos: Salidas. ciacin y tra-
Desarrolla el Plan de Direc-
bajo en equipo
cin del Proyecto de
Tema N 4: Activos de la Orga- que permita
acuerdo a los lineamientos
nizacin. establecer un
descritos en la plantilla de-
1. Lecciones Aprendidas del Pro- trabajo ali-
nominada Plan de Direc-
yecto. neado a los en-
cin del Proyecto, estruc-
2. Memoria Final del Proyecto. tornos organi-
tura basada en las buenas
zacionales.
prcticas descritas en el
PMBOK.
Gua de los Fundamentos para la
Direccin de Proyectos (Gua del
PMBOK): Desarrollar el Plan para
la Direccin del Proyecto. PROJECT
MANAGEMENT INSTITUTE, (2013),
pginas 72 78.
Autoevaluacin N 4.
118
UNIDAD IV:
PLANIFICACIN Y CIERRE DEL PROYECTO
TEMA N 1: GESTIN DE LAS ADQUISICIONES DEL PROYECTO
INTRODUCCIN
La Gestin de las Adquisiciones del Proyecto incluye los procesos necesarios para
comprar o adquirir productos, servicios o resultados que es preciso obtener fuera del
equipo del proyecto. La organizacin puede ser la compradora o vendedora de los
productos, servicios o resultados de un proyecto.
La Gestin de las Adquisiciones del Proyecto incluye, los procesos de gestin del
contrato y de control de cambios, requeridos para desarrollar y administrar contratos
u rdenes de compra emitidos por miembros autorizados del equipo del proyecto.
La Gestin de las Adquisiciones del Proyecto tambin incluye el control de cualquier
contrato emitido por una organizacin externa (el comprador), que est adquiriendo
entregables del proyecto a la organizacin ejecutora (el vendedor), as como la ad-
ministracin de las obligaciones contractuales contradas por el equipo del proyecto
en virtud del contrato.
El Grfico 04-1 presenta una descripcin general de los procesos de Gestin de las
Adquisiciones del Proyecto, que incluyen:
Planificar la Gestin de las Adquisiciones: El proceso de documentar las de-
cisiones de adquisiciones del proyecto, especificar el enfoque e identificar a los
proveedores potenciales.
Efectuar las Adquisiciones: El proceso de obtener respuestas de los proveedo-
res, seleccionarlos y adjudicarles un contrato.
Controlar las Adquisiciones: El proceso de gestionar las relaciones de adquisi-
ciones, monitorear la ejecucin de los contratos y efectuar cambios y correcciones
segn corresponda.
Cerrar las Adquisiciones: El proceso de finalizar cada adquisicin para el pro-
yecto.
Estos procesos interactan entre s y con procesos de otras reas de Conocimiento.
119
Grfico N 04-1. Descripcin General de la Gestin de las Adquisiciones
del Proyecto
Los procesos de Gestin de las Adquisiciones del Proyecto involucran acuerdos, in-
cluidos los contratos, que son documentos legales que se establecen entre un com-
prador y un vendedor. Un contrato representa un acuerdo vinculante para las partes
120
en virtud del cual el vendedor se obliga a proporcionar algn valor (p.ej., productos,
servicios o resultados especificados) y el comprador se obliga a proporcionar dinero
o cualquier otra compensacin de valor. Un acuerdo puede ser simple o complejo, y
puede reflejar la simplicidad o complejidad de los entregables o del esfuerzo reque-
rido.
Un contrato de adquisicin incluye trminos y condiciones y puede incorporar otros
aspectos especificados por el comprador respecto a lo que el vendedor debe realizar
o proporcionar. Es responsabilidad del equipo de direccin del proyecto garantizar
que todas las adquisiciones satisfagan las necesidades especficas del proyecto y que
a la vez se respeten las polticas de la organizacin en materia de adquisiciones.
Segn el rea de aplicacin, los contratos tambin pueden denominarse acuerdos,
convenios, subcontratos u rdenes de compra. La mayora de las organizaciones
cuentan con polticas y procedimientos documentados que definen especficamente
las reglas de adquisicin, as como quin est autorizado a firmar y administrar dichos
acuerdos en nombre de la organizacin.
Si bien todos los documentos del proyecto pueden estar sujetos a algn tipo de revi-
sin y aprobacin, el carcter jurdicamente vinculante de un contrato o acuerdo por
lo general significa que estar sujeto a un proceso de aprobacin ms exhaustivo. En
todos los casos, el objetivo fundamental del proceso de revisin y aprobacin es,
asegurar que el lenguaje del contrato describa los productos, servicios o resultados
que satisfarn la necesidad identificada del proyecto.
En las fases iniciales, el equipo de direccin del proyecto puede buscar el respaldo de
especialistas en contratacin, adquisiciones, derecho y disciplinas tcnicas. Dicha
participacin puede ser impuesta por la poltica de una organizacin.
Las diferentes actividades involucradas en los procesos de Gestin de las Adquisicio-
nes del Proyecto conforman el ciclo de vida de un acuerdo. Mediante la gestin activa
del ciclo de vida del acuerdo y la redaccin cuidadosa de los trminos y condiciones
de una adquisicin, algunos de los riesgos identificables del proyecto se pueden com-
partir o transferir a un vendedor. Establecer un acuerdo sobre productos o servicios
es un mtodo para asignar la responsabilidad de gestionar o compartir riesgos po-
tenciales.
Un proyecto complejo puede implicar la gestin simultnea o secuencial de mltiples
contratos o subcontratos. En tales casos, el ciclo de vida de cada contrato puede
finalizar durante cualquier fase del ciclo de vida del proyecto. La Gestin de las Ad-
quisiciones del Proyecto se aborda desde la perspectiva de la relacin entre el com-
prador y el vendedor. La relacin comprador-vendedor puede existir a muchos niveles
en cualquier proyecto, y entre organizaciones internas y externas a la organizacin
compradora.
Dependiendo del rea de aplicacin, el vendedor puede identificarse como contra-
tista, subcontratista, proveedor, proveedor de servicios o distribuidor. Dependiendo
de la posicin del comprador en el ciclo de adquisicin del proyecto, ste puede de-
nominarse cliente, contratista principal, contratista, organizacin compradora, solici-
tante de servicios o simplemente comprador. Durante el ciclo de vida del contrato, el
vendedor puede ser considerado en primer lugar como licitador, luego como la fuente
seleccionada y finalmente como el proveedor o vendedor contratado.
Por lo general, el vendedor dirigir el trabajo como un proyecto siempre que la ad-
quisicin no se limite a materiales listos para la venta, a bienes o a productos comu-
nes. En dichos casos:
El comprador se transforma en el cliente y, por lo tanto, en un interesado clave
del proyecto para el vendedor.
121
El equipo de direccin del proyecto del vendedor debe ocuparse de todos los pro-
cesos de la direccin de proyectos y no exclusivamente de los de esta rea de
Conocimiento.
Los trminos y condiciones del contrato se transforman en entradas clave de mu-
chos de los procesos de direccin del vendedor. El contrato puede efectivamente
contener las entradas (p.ej. principales entregables, hitos clave, objetivos de cos-
tos) o limitar las opciones del equipo del proyecto (p.ej., en proyectos de diseo,
se requiere a menudo que el comprador apruebe las decisiones relacionadas con
los recursos humanos).
En esta seccin, se supone que, el comprador de un elemento para el proyecto est
asignado al equipo del proyecto, mientras que el vendedor es externo al equipo del
proyecto, desde el punto de vista de la organizacin.
Tambin se supone que entre el comprador y el vendedor se desarrollar y existir
una relacin contractual formal. Sin embargo, la mayor parte del contenido de esta
seccin se puede aplicar tambin a trabajo no contractual desarrollado con otras
unidades de la organizacin del equipo del proyecto.
1. Planificar la Gestin de las Adquisiciones.

Planificar la Gestin de las Adquisiciones es el proceso de documentar las deci-
siones de adquisiciones del proyecto, especificar el enfoque e identificar a los
proveedores potenciales. El beneficio clave de este proceso es que determina si
es preciso obtener apoyo externo y, si fuera el caso, qu adquirir, de qu manera,
en qu cantidad y cundo hacerlo. El Grfico 04-2 muestra las entradas, herra-
mientas y tcnicas, y salidas de este proceso.
Grfico N 04-2. Planificar la Gestin de las Adquisiciones: Entradas,

El proceso Planificar la Gestin de las Adquisiciones identifica aquellas necesida-

des del proyecto que, se pueden satisfacer mejor o que deben satisfacerse me-
diante la adquisicin de productos, servicios o resultados fuera de la organizacin
del proyecto, frente a las necesidades del mismo, que pueden ser resueltas por
el propio equipo. Cuando el proyecto obtiene productos, servicios y resultados
necesarios para su desempeo, fuera de la organizacin ejecutora, los procesos
122
desde Planificar la Gestin de las Adquisiciones hasta Cerrar las Adquisiciones se
ejecutan para cada uno de los elementos que se va a adquirir.
El proceso Planificar la Gestin de las Adquisiciones tambin incluye la evaluacin
de posibles vendedores, especialmente si el comprador desea ejercer algn grado
de influencia o control sobre las decisiones de compra. Tambin se deber prever
quin ser el responsable de obtener o ser titular de permisos y licencias profe-
sionales relevantes que puedan ser exigidos por la legislacin, alguna regulacin
o poltica de la organizacin para ejecutar el proyecto.
Los requisitos del cronograma del proyecto pueden influir considerablemente en
la estrategia durante el proceso Planificar la Gestin de las Adquisiciones. Las
decisiones tomadas durante el desarrollo del plan de gestin de las adquisiciones,
tambin pueden influir en el cronograma del proyecto y estn integradas con los
procesos Desarrollar el Cronograma, Estimar los Recursos de las Actividades y
con los anlisis de hacer o comprar.
El proceso Planificar la Gestin de las Adquisiciones incluye, la evaluacin de los
riesgos derivados de cada anlisis de hacer o comprar. Tambin incluye la revisin
del tipo de contrato que se prev utilizar para evitar o mitigar los riesgos, que en
ocasiones consiste en transferir el riesgo al vendedor.
123
TEMA N 2: GESTIN DE LOS INTERESADOS DEL PROYECTO
INTRODUCCIN
La Gestin de los Interesados del Proyecto incluye los procesos necesarios para iden-
tificar a las personas, grupos u organizaciones que pueden afectar o ser afectados
por el proyecto, para analizar las expectativas de los interesados y su impacto en el
proyecto, asmismo, para desarrollar estrategias de gestin adecuadas a fin de lograr
la participacin eficaz de los interesados en las decisiones y en la ejecucin del pro-
yecto.
La gestin de los interesados tambin se centra en la comunicacin continua con los
interesados para comprender sus necesidades y expectativas, abordando los inciden-
tes en el momento en que ocurren, gestionando conflictos de intereses y fomentando
una adecuada participacin de los interesados en las decisiones y actividades del
proyecto. La satisfaccin de los interesados debe gestionarse como uno de los obje-
tivos clave del proyecto.
El Grfico 04-3 brinda una descripcin general de los procesos de Gestin de los
Interesados del Proyecto, a saber:
Identificar a los Interesados: El proceso de identificar las personas, grupos u

organizaciones que podran afectar o ser afectados por una decisin, actividad o
resultado del proyecto, as como de analizar y documentar informacin relevante
relativa a sus intereses, participacin, interdependencias, influencia y posible im-
pacto en el xito del proyecto.
Planificar la Gestin de los Interesados: El proceso de desarrollar estrategias
de gestin adecuadas para lograr la participacin eficaz de los interesados a lo
largo del ciclo de vida del proyecto, con base en el anlisis de sus necesidades,
intereses y el posible impacto en el xito del proyecto.
Gestionar la Participacin de los Interesados: El proceso de comunicarse y
trabajar con los interesados para satisfacer sus necesidades/expectativas, abor-
dar los incidentes en el momento en que ocurren y fomentar la participacin ade-
cuada de ellos, en las actividades del proyecto a lo largo del ciclo de vida del
mismo.
Controlar la Participacin de los Interesados: El proceso de monitorear glo-
balmente las relaciones de los interesados del proyecto y ajustar las estrategias
y los planes para involucrar a los interesados.
Estos procesos interactan entre s y con procesos de otras reas de Conocimiento.
Cada proyecto tendr interesados que se vern afectados o podrn afectarlo, ya sea
de forma positiva o negativa. Si bien algunos interesados pueden tener una capacidad
limitada para influir en el proyecto, otros pueden tener una influencia significativa
sobre el mismo y sobre sus resultados esperados. La capacidad del director del pro-
yecto para identificar correctamente y gestionar a dichos interesados de manera ade-
cuada puede constituir la diferencia entre el xito y el fracaso.
124
Grfico N 04-3. Descripcin General de la Gestin de los Interesados
del Proyecto
1. Identificar a los Interesados.

Identificar a los Interesados es el proceso de identificar a las personas, grupos u
organizaciones que podran afectar o ser afectados por una decisin, actividad o
resultado del proyecto, as como de analizar y documentar informacin relevante
relativa a sus intereses, participacin, interdependencias, influencia y posible im-
pacto en el xito del proyecto. El beneficio clave de este proceso es que permite
al director del proyecto identificar el enfoque adecuado para cada interesado o
grupo de interesados. El Grfico 04-4 muestra las entradas, herramientas y tc-
nicas, y salidas de este proceso.
125
Grfico N 04-4. Identificar a los Interesados: Entradas, Herramientas,
Tcnicas y Salidas
Los interesados del proyecto son individuos, grupos u organizaciones que pueden
afectar, verse afectados o percibirse a s mismos como afectados por una deci-
sin, actividad o resultado de un proyecto. Comprenden personas y organizacio-
nes como clientes, patrocinadores, la organizacin ejecutora o el pblico, que
estn involucrados activamente en el proyecto, o cuyos intereses pueden verse
afectados de manera positiva o negativa por la ejecucin o la conclusin del pro-
yecto. Tambin pueden influir sobre el proyecto y sus entregables. Los interesa-
dos pueden encontrarse en diferentes niveles dentro de la organizacin y poseer
diferentes niveles de autoridad, o bien pueden ser externos a la organizacin
ejecutora del proyecto.
Para el xito del proyecto, resulta fundamental identificar a los interesados desde
el comienzo del proyecto o la fase y analizar sus niveles de inters y sus expec-
tativas individuales, as como su importancia y su influencia. Esta evaluacin ini-
cial debe ser revisada y actualizada con regularidad. La mayora de los proyectos
tendr un nmero diverso de interesados en funcin de su tamao, tipo y com-
plejidad. Aunque el tiempo con que cuenta el director del proyecto es limitado y
debe usarse con la mayor eficiencia posible, estos interesados se deberan clasi-
ficar segn su inters, influencia y participacin en el proyecto, teniendo en
cuenta el hecho de que la afectacin o influencia de un interesado puede no darse
o tornarse evidente hasta etapas posteriores del proyecto o fase. Esto permite
que el director del proyecto se concentre en las relaciones necesarias para ase-
gurar el xito del proyecto.
2. Planificar la Gestin de los Interesados.

Planificar la Gestin de los Interesados es el proceso de desarrollar estrategias de
gestin adecuadas para lograr la participacin eficaz de los interesados a lo largo
del ciclo de vida del proyecto, con base en el anlisis de sus necesidades, intere-
ses y el posible impacto en el xito del proyecto. El beneficio clave de este proceso
es que proporciona un plan claro y factible para interactuar con los interesados
del proyecto, a fin de apoyar los intereses del mismo. El Grfico 04-5 muestra las
entradas, herramientas y tcnicas, y salidas de este proceso.
126
Grfico N 04-5. Planificar la Gestin de los Interesados: Entradas, He-
El proceso Planificar la Gestin de los Interesados identifica el modo en que el

proyecto afectar a los interesados, lo que permite al director del proyecto desa-
rrollar diferentes formas de lograr la participacin eficaz de los interesados en el
proyecto, gestionar sus expectativas y en ltima instancia, alcanzar los objetivos
del proyecto. La gestin de los interesados es algo ms que la mejora de las
comunicaciones y requiere algo ms que la direccin de un equipo. La gestin de
los interesados, trata de la creacin y el mantenimiento de las relaciones entre el
equipo del proyecto y los interesados, con objeto de satisfacer sus necesidades y
requisitos respectivos dentro de los lmites del proyecto.
Este proceso genera el plan de gestin de los interesados, que a su vez contiene
planes detallados sobre cmo lograr una gestin eficaz de los interesados. A me-
dida que avanza el proyecto, los miembros de la comunidad de interesados y el
nivel requerido de participacin pueden cambiar; por tanto, la planificacin de la
gestin de los interesados es un proceso iterativo que el director del proyecto
revisa regularmente.
127
INSTRUCCIONES
1. Desarrolla la matriz de identificacin de interesados teniendo en consideracin los

puntos descritos en la plantilla denominada Identificacin de Interesados.
128
TEMA N 3: PLAN DE DIRECCIN DE PROYECTOS
INTRODUCCIN
La Gestin de la Integracin del Proyecto incluye los procesos y actividades necesa-
rios para identificar, definir, combinar, unificar y coordinar los diversos procesos y
actividades de direccin del proyecto, dentro de los Grupos de Procesos de la Direc-
cin de Proyectos. En el contexto de la direccin de proyectos, la integracin incluye
caractersticas de unificacin, consolidacin, comunicacin y acciones integradoras
cruciales para que el proyecto se lleve a cabo de manera controlada, de modo que
se complete, se manejen con xito las expectativas de los interesados y se cumpla
con los requisitos. La Gestin de la Integracin del Proyecto implica tomar decisiones
en cuanto a la asignacin de recursos, equilibrar objetivos y alternativas contrapues-
tas, y manejar las interdependencias entre las reas de Conocimiento de la direccin
de proyectos. Los procesos de la direccin de proyectos se presentan normalmente
como procesos diferenciados con interfaces definidas, aunque en la prctica se su-
perponen e interactan entre ellos de formas que no pueden detallarse en su totali-
dad dentro de la Gua del PMBOK.
1. Integracin de Planes Subsidiarios

Los casos de interaccin entre procesos individuales ponen de manifiesto la ne-
cesidad de Gestin de la Integracin del Proyecto. Por ejemplo, una estimacin
de costos necesaria para un plan de contingencia implica la integracin de los
procesos de las reas de Conocimiento de Costo, Tiempo y Gestin de Riesgos
del Proyecto. La identificacin de riesgos adicionales asociados a diversas alter-
nativas de adquisicin de personal, puede generar la necesidad de reconsiderar
uno o varios de estos procesos. Tambin puede ser necesario integrar los entre-
gables del proyecto con las operaciones en curso, ya sean de la organizacin
ejecutora o de la organizacin solicitante, o con la planificacin estratgica a largo
plazo que toma en cuenta los problemas y oportunidades futuros. La Gestin de
la Integracin del Proyecto, tambin abarca las actividades necesarias para ges-
tionar los documentos del proyecto, de cara a asegurar la coherencia con el plan
para la direccin del proyecto y con los entregables del producto, servicio o ca-
pacidad.
La mayora de los profesionales con experiencia en la direccin de proyectos sa-
ben que no existe una nica forma de dirigir los proyectos. Aplican sus conoci-
mientos y habilidades e implementan los procesos necesarios de direccin de pro-
yectos en el orden de su preferencia y con niveles de rigor variables para lograr
el desempeo esperado del proyecto. Sin embargo, la determinacin de que un
proceso concreto no es necesario, no significa que no deba ser considerado. El
director y equipo del proyecto deben abordar cada proceso y el entorno del pro-
yecto, para determinar el nivel de implementacin de cada proceso dentro del
mismo. Si consta de ms de una fase, se debe aplicar el nivel de rigor adecuado
para cada una de las fases. Esta determinacin tambin es responsabilidad del
director y el equipo del proyecto.
Para comprender la naturaleza integradora de los proyectos y de la direccin de
proyectos se puede pensar en otros tipos de actividades que se realizan durante
su ejecucin. Los siguientes son algunos ejemplos de las actividades llevadas a
cabo por el equipo de direccin del proyecto:
Desarrollar, revisar, analizar y comprender el alcance. Esto incluye requisitos
del proyecto y del producto, criterios, supuestos, restricciones y otras influen-
cias relacionadas con un determinado proyecto, as como el modo en que s-
tas se gestionarn o abordarn en el mbito del proyecto;
129
Convertir la informacin que se ha recopilado sobre el proyecto en un plan
para la direccin del proyecto mediante la utilizacin de un enfoque estructu-
rado como el que se describe en la Gua del PMBOK;
Realizar actividades para producir los entregables del proyecto; y
Medir y monitorear el avance del proyecto y realizar las acciones adecuadas
para cumplir con los objetivos del mismo.
Desarrollar el Plan para la Direccin del Proyecto es el proceso de definir, preparar
y coordinar todos los planes secundarios e incorporarlos en un plan integral para
la direccin del proyecto. El beneficio clave de este proceso es un documento
central que define la base para todo el trabajo del proyecto. El Grfico 04-6 mues-
tra las entradas, herramientas y tcnicas, y salidas de este proceso.
Grfico N 04-6. Desarrollar el Plan para la Direccin del Proyecto
El plan para la direccin del proyecto define la manera en que el proyecto se

ejecuta, se monitorea, se controla y se cierra. El contenido del plan para la direc-
cin del proyecto es variable en funcin del rea de aplicacin y de la complejidad
del proyecto. Se desarrolla a travs de una serie de procesos integrados que se
extienden hasta el cierre del proyecto. Este proceso da lugar a un plan para la
direccin del proyecto que se elabora progresivamente por medio de actualiza-
ciones, y que se controla y aprueba a travs del proceso Realizar el Control Inte-
grado de Cambios. Los proyectos que se encuentran en el mbito de un programa
deberan desarrollar un plan para la direccin del proyecto coherente con el plan
para la direccin del programa correspondiente. Por ejemplo, si el plan para la
direccin del programa indica que todos los cambios que excedan un costo deter-
minado debern ser revisados por el comit de control de cambios (CCB), se
deber definir este proceso y el umbral de costo correspondiente en el plan para
la direccin del proyecto.
2. Desarrollo del Plan de Direccin de Proyectos: Entradas
2.1.Acta de Constitucin del Proyecto

El tamao del acta de constitucin del proyecto es variable en funcin de la com-
plejidad del proyecto y de la informacin que se conoce en el momento de su
creacin. El acta de constitucin del proyecto debera como mnimo definir los
lmites de alto nivel del proyecto. El equipo del proyecto utiliza el acta de consti-
tucin del proyecto como punto de partida para establecer la planificacin inicial
del mismo.
2.2.Salidas de Otros Procesos

Las salidas de muchos de los otros procesos se integran para crear el plan para
la direccin del proyecto. Cualquier lnea base y plan secundario que constituya
130
una salida de otros procesos de planificacin constituye una entrada para este
proceso. Adems, los cambios realizados sobre estos documentos pueden reque-
rir actualizaciones al plan para la direccin del proyecto.
2.3.Factores Ambientales de la Empresa

Los factores ambientales de la empresa que pueden influir en el proceso Desa-
rrollar el Plan para la Direccin del Proyecto incluyen, entre otros:
Estndares gubernamentales o industriales;
Fundamentos para la direccin de proyectos especficos para el mercado ver-
tical (p.ej., construccin) y/o rea de especializacin (p.ej. medio ambiente,
seguridad, riesgos o desarrollo gil de software);
Sistema de informacin para la direccin de proyectos (p.ej., herramientas
automticas, tales como una herramienta de software para programacin, un
sistema de gestin de la configuracin, un sistema de recopilacin y distribu-
cin de la informacin o las interfaces web a otros sistemas automticos en
lnea);
Estructura y cultura de la organizacin, prcticas de gestin y sostenibilidad;
Infraestructura (p.ej., instalaciones existentes y bienes de capital); y
Gestin de personal (p.ej., guas para la contratacin y el despido, revisiones
del desempeo de los empleados y registros de desarrollo y capacitacin de
los empleados).
2.4.Activos de los Procesos de la Organizacin

Los activos de los procesos de la organizacin que pueden influir en el proceso
Desarrollar el Plan para la Direccin del Proyecto incluyen, entre otros:
Guas estandarizadas, instrucciones de trabajo, criterios para la evaluacin de
propuestas y criterios para la medicin del desempeo.
Plantilla del plan para la direccin del proyecto, que incluye:
o Guas y criterios para adaptar el conjunto de procesos estndar de la
organizacin con el fin de que satisfagan las necesidades especficas
del proyecto; y
o Guas o requisitos para el cierre del proyecto, tales como los criterios
de validacin y aceptacin del producto.
Procedimientos de control de cambios, incluidos los pasos segn los cuales se
modificarn los estndares, polticas, planes y procedimientos oficiales de la
organizacin, o cualquier documento del proyecto, y la manera en que se
aprobar y validar cualquier cambio.
Archivos de proyectos anteriores (p.ej., lneas base del alcance, de costos, del
cronograma y de medicin del desempeo, calendario del proyecto, diagra-
mas de red del cronograma del proyecto y registros de riesgos).
Informacin histrica y base de conocimientos de lecciones aprendidas; y
Base de conocimiento de gestin de la configuracin, que contiene las versio-
nes y lneas base de todos los estndares, polticas y procedimientos oficiales
de la organizacin, y cualquier otro documento del proyecto.
131
3. Desarrollo del Plan de Direccin de Proyectos: Herramientas y Tcnicas
3.1.Juicio de Expertos
Cuando se desarrolla el plan para la direccin del proyecto, se utiliza el juicio de
expertos para:
Adaptar el proceso para cumplir con las necesidades del proyecto.
Desarrollar los detalles tcnicos y de gestin que se incluirn en el plan para
la direccin del proyecto.
Determinar los recursos y los niveles de habilidad necesarios para llevar a
cabo el trabajo del proyecto.
Determinar el nivel de gestin de la configuracin que se aplicar al proyecto.
Determinar qu documentos del proyecto estarn sujetos al proceso formal
de control de cambios; y
Establecer las prioridades en el trabajo a realizar en el proyecto para asegurar
que, los recursos del proyecto se asignan al trabajo adecuado en el momento
adecuado.
3.2.Tcnicas de Facilitacin
Las tcnicas de facilitacin tienen una amplia aplicacin en el mbito de los pro-
cesos de la direccin de proyectos y se utilizan como gua en el desarrollo del plan
para la direccin del proyecto. Tormentas de ideas, resolucin de conflictos, so-
lucin de problemas y gestin de reuniones son algunas tcnicas clave que utilizan
los facilitadores para ayudar a equipos e individuos a alcanzar acuerdos para lle-
var a cabo las actividades del proyecto.
4. Desarrollo del Plan de Direccin de Proyectos: Salidas
4.1.Plan para la Direccin del Proyecto

El plan para la direccin del proyecto es el documento que describe el modo en
que el proyecto ser ejecutado, monitoreado y controlado. Integra y consolida
todos los planes y lneas base secundarios de los procesos de planificacin.
Las lneas base del proyecto incluyen, entre otras:
Lnea base del alcance.
Lnea base del cronograma; y
Lnea base de costos.
Los planes secundarios incluyen, entre otros:
Plan de gestin del alcance.
Plan de gestin de los requisitos.
Plan de gestin del cronograma.
Plan de gestin de los costos.
Plan de gestin de la calidad.
Plan de mejoras del proceso.
Plan de gestin de los recursos humanos.
Plan de gestin de las comunicaciones.
132
Plan de gestin de los riesgos.
Plan de gestin de las adquisiciones; y
Plan de gestin de los interesados.
El plan para la direccin del proyecto puede asimismo incluir, entre otras cosas:
El ciclo de vida seleccionado para el proyecto y los procesos que se aplicarn
en cada fase.
Detalles de las decisiones para la adaptacin especificadas por el equipo de
direccin del proyecto, a saber:
o Procesos de la direccin de proyectos seleccionados por el equipo de
direccin del proyecto.
o Nivel de implementacin de cada uno de los procesos seleccionados.
o Descripciones de las herramientas y tcnicas que se utilizarn para
llevar a cabo esos procesos; y
o Descripcin del modo en que se utilizarn los procesos seleccionados
para gestionar el proyecto especfico, incluyendo las dependencias e
interacciones entre dichos procesos y las entradas y salidas fundamen-
tales.
Descripcin del modo en que se realizar el trabajo para alcanzar los objetivos
del proyecto.
Plan de gestin de cambios que documente el modo en que se monitorearn
y controlarn los cambios.
Plan de gestin de la configuracin que documente cmo se llevar a cabo
dicha gestin.
Descripcin del modo en que se mantendr la integridad de las lneas base
del proyecto.
Requisitos y tcnicas de comunicacin entre los interesados; y
Revisiones clave de gestin del contenido, el alcance y el tiempo para abordar
los incidentes sin resolver y las decisiones pendientes.
El plan para la direccin del proyecto puede presentarse en forma resumida o
detallada y puede estar compuesto por uno o ms planes secundarios. Cada uno
de los planes secundarios se detalla hasta el nivel que requiera el proyecto espe-
cfico. Una vez que las lneas base del plan para la direccin del proyecto han sido
definidas, este ltimo slo podr ser modificado como resultado de la generacin
y aprobacin de una solicitud de cambio a travs del proceso Realizar el Control
Integrado de Cambios.
Aunque el plan para la direccin del proyecto es uno de los documentos principa-
les que se utilizan para la gestin de un proyecto, se utilizan asimismo otros
documentos. Estos otros documentos no forman parte del plan para la direccin
del proyecto.
133
TEMA N 4: ACTIVOS DE LA ORGANIZACIN
INTRODUCCIN
Los activos de los procesos de la organizacin son los planes, los procesos, las pol-
ticas, los procedimientos y las bases de conocimiento especficos de la organizacin
ejecutora y utilizados por la misma. Estos incluyen cualquier objeto, prctica o cono-
cimiento de alguna o de todas las organizaciones que participan en el proyecto y que
pueden usarse para ejecutar o gobernar el proyecto. Los activos de procesos tambin
incluyen bases de conocimiento de la organizacin como lecciones aprendidas e in-
formacin histrica. Los activos de los procesos de la organizacin pueden incluir
cronogramas, datos sobre riesgos y datos sobre el valor ganado. Los activos de los
procesos de la organizacin constituyen entradas para la mayora de los procesos de
planificacin. A lo largo del proyecto, los miembros del equipo del proyecto pueden
efectuar actualizaciones y adiciones a los activos de los procesos de la organizacin,
segn sea necesario. Los activos de los procesos de la organizacin pueden agruparse
en dos categoras: (1) procesos y procedimientos, y (2) base de conocimiento cor-
porativa.
Los activos de los procesos de la organizacin abarcan alguno o todos los activos
relativos a procesos de, alguna o todas las organizaciones participantes en el pro-
yecto que pueden usarse para influir en el xito del proyecto. Estos activos de pro-
cesos abarcan planes, polticas, procedimientos y lineamientos, ya sean formales o
informales. Los activos de procesos tambin abarcan las bases de conocimiento de
la organizacin, como las lecciones aprendidas y la informacin histrica.
Los activos de los procesos de la organizacin pueden incluir cronogramas completa-
dos, datos sobre riesgos y datos sobre el valor ganado. Las actualizaciones y adicio-
nes que sea necesario efectuar a lo largo del proyecto con relacin a los activos de
los procesos de la organizacin, son por lo general responsabilidad de los miembros
del equipo del proyecto.
El director del proyecto debe considerar los activos de los procesos de la organizacin
y los factores ambientales de la empresa.
Los activos de los procesos de la organizacin proporcionan pautas y criterios para
adaptar dichos procesos a las necesidades especficas del proyecto. Los factores am-
bientales de la empresa pueden restringir las opciones de la direccin de proyectos.
1. Lecciones Aprendidas del Proyecto

Ser capaz de documentar las lecciones aprendidas una vez que un proyecto ha
llegado a su fin es una de las mayores responsabilidades de un Director de Pro-
yecto. De esta informacin depender alcanzar un buen nivel de comprensin de
los propios errores, muy necesario para proyectos futuros, y nica forma de evitar
que se repitan los mismos fallos una y otra vez. Sin embargo, no todo vale y, por
eso mismo, el modo de documentar estas lecciones aprendidas tambin debe ser
examinado con lupa.
A la hora de dejar constancia de la experiencia de un proyecto, no slo hay que
centrarse en los errores que se cometieron, sino que los aspectos positivos y
reseables tambin deben ser recogidos ya que, de lo contrario, todos los proce-
sos y decisiones que contribuyeron al xito del proyecto podran perderse y los
efectos de este olvido seran tan negativos como no tratar de aprender de los
errores que se cometieron.
134
Por eso, podra resumirse que, entre las lecciones aprendidas de un proyecto hay
que contabilizar:
Los errores cometidos.
Los riesgos a que el proyecto se vio expuesto.
Las decisiones que mejor funcionaron.
Los procesos y tcnicas que ms eficiencia y efectividad aportaron.
Cundo debe el Director de Proyecto enfrentarse con esta obligacin?

Como muy tarde, al final. En la etapa de finalizacin de proyecto, todo checklist
informa de la necesidad de dejar recogidas las enseanzas y lecciones aprendidas
de la experiencia. Sin embargo, en la prctica y, sobre todo, cuando se trata
de proyectos de gran complejidad o de muy extensa duracin; relegar esta acti-
vidad a ltima hora no es lo ms acertado.
Los riesgos de dejar para el final la recogida de las lecciones aprendidas son:
Olvidarse de incluir algn suceso o dato importante.
Carecer del enfoque adecuado, por prdida de perspectiva.
Cometer algn error y no tener posibilidad de comprobar o revisar lo anotado.
Por ello, el mejor lugar y momento de capturar las lecciones aprendidas es
cuando se producen, a medida que transcurre el proyecto, en pleno progreso. La
forma de hacerlo es documentndolas justo despus de que hayan ocurrido,
cuando acaban de producirse.
Es importante no procrastinar, aunque resulte complicado, puesto que el Director
de Proyecto siempre tendr asuntos que resolver, cuestiones urgentes y decisio-
nes importantes que tomar. Sin embargo, la veracidad, consistencia, completitud
y fiabilidad de la informacin que se recoja en forma de lecciones aprendidas de-
pender en gran medida de la puntualidad de su recogida.
Cuando el proyecto entre en la etapa de finalizacin, todos los datos que se hayan
recopilado habrn de ser revisados con objeto de completarlos, si se puede apor-
tar nueva informacin o enriquecerlos, si mirando atrs se gana en perspectiva
y es posible adquirir una mejor comprensin de lo sucedido. Adems, es el mo-
mento de terminar de completar las lecciones aprendidas para que, stas resulten
un documento til y sean realmente el reflejo de la experiencia adquirida en el
curso del proyecto.
Lecciones aprendidas de un proyecto: las claves del xito

El esfuerzo individual del Director de Proyecto, su precisin, su punto de vista y
su claridad a la hora de analizar y reflejar lo acontecido son elementos impres-
cindibles para aumentar la utilidad de este recurso. Pero no hay que olvidar que,
igual que sucede con el propio proyecto, las lecciones aprendidas no son cosa de
uno, sino que han de entenderse como el fruto del trabajo de todos y, por eso,
entre las claves de su xito se encuentran las siguientes:
Fomentar la participacin de los involucrados en el proyecto para que s-
tos aporten su visin de las lecciones aprendidas y sus ideas.
Tratar de incluir este asunto en la rutina de proyecto, por ejemplo, como tema
a tratar en alguna reunin con la periodicidad que se considere oportuna.
135
A la vez que se desarrolla el documento continente de las lecciones aprendi-
das, se debe incorporar dicha informacin en la gestin de proyecto, para be-
neficiarse de ella desde el principio.
Una vez que toda la informacin se ha recogido, revisado y corregido debe
ser publicada, para que todos los involucrados en el proyecto conozcan su
contenido y puedan aprender de l y mejorar.
Por ltimo, hay que asegurarse de que se conserva esta informacin, para
que la organizacin y los equipos de proyecto puedan disponer de ella cuando
sea necesario.
2. Memoria Final del Proyecto

Documento que describe de manera estructurada, las diferentes actividades que
se han realizado durante la ejecucin del proyecto.
La memoria es el documento que describe el proyecto, que debe contener como
mnimo la siguiente informacin:
Debe hacer constar claramente las motivaciones y los condicionantes del pro-
yecto.
Debe contemplar las alternativas que se han manejado y las razones por las
que se llega a una eleccin determinada.
Debe describir la tecnologa del proyecto, las normas para su explotacin, el
presupuesto y la evaluacin del proyecto.
En la memoria no debe haber clculos, sino resultados; los clculos van en los
anexos.
Es el ltimo documento que se elabora del proyecto, resumindolo.
Los anexos a la memoria tienen la misin de recoger toda la informacin es-
tadstica (clculos, grficos, entre otros) y explicaciones ms profundas que
justifican la seleccin de una u otra alternativa.
Constituyen una justificacin de las decisiones del proyectista, pero no hay
que consultarlo para ejecutar el proyecto.
136
Desarrollar el Plan para la Direccin del Proyecto
pginas 72 78.
El beneficio clave de este proceso es un

Desarrollar el Plan para la Direccin del
documento central que define la base
Proyecto es el proceso de definir, pre-
para todo el trabajo del proyecto. El
parar y coordinar todos los planes se-
Grfico 04-7 muestra las entradas, he-
cundarios e incorporarlos en un plan
rramientas y tcnicas, y salidas de este
integral para la direccin del proyecto.
proceso.
Grfico N 04-7. Desarrollar el Plan para la Direccin del Proyecto
El plan para la direccin del proyecto define la manera en que el proyecto se ejecuta,
se monitorea, se controla y se cierra. El contenido del plan para la direccin del pro-
yecto es variable en funcin del rea de aplicacin y de la complejidad del proyecto.
Se desarrolla a travs de una serie de procesos integrados que se extienden hasta el
cierre del proyecto. Este proceso da lugar a un plan para la direccin del proyecto
que se elabora progresivamente por medio de actualizaciones, y que se controla y
aprueba a travs del proceso Realizar el Control Integrado de Cambios. Los proyectos
que se encuentran en el mbito de un programa deberan desarrollar un plan para la
direccin del proyecto, coherente con el plan para la direccin del programa corres-
pondiente. Por ejemplo, si el plan para la direccin del programa indica que todos los
cambios que excedan un costo determinado debern ser revisados por el comit de
control de cambios (CCB), se deber definir este proceso y el umbral de costo co-
rrespondiente en el plan para la direccin del proyecto.
Aunque el plan para la direccin del proyecto es uno de los documentos principales
que se utilizan para la gestin de un proyecto, se utilizan asimismo otros documentos.
Estos otros documentos no forman parte del plan para la direccin del proyecto. La
Tabla 04-1 contiene una lista representativa de los componentes del plan para la
direccin del proyecto y de los documentos del proyecto.
137
Tabla N 04-1. Diferenciacin entre el Plan para la Direccin del Proyecto y
los Documentos del Proyecto
Plan para la Direccin

Documentos del Proyecto
del Proyecto
Plan de gestin de los cam- Asignaciones de personal al
Atributos de las actividades.
bios. proyecto.
Plan de gestin de las comu- Estimacin de costos de las Enunciado del trabajo del
nicaciones. actividades. proyecto.
Plan de gestin de la configu- Estimacin de la duracin de Listas de verificacin de cali-
racin. las actividades. dad.
Mediciones de control de ca-
Lnea base de costos. Lista de actividades.
lidad.
Plan de gestin de los costos. Plan de gestin de los costos. Mtricas de calidad.
Plan de gestin de los recur- Documentacin de requisi-
Acuerdos.
sos humanos. tos.
Matriz de trazabilidad de re-
Plan de mejoras del proceso. Base de las estimaciones.
quisitos.
Plan de gestin de las adqui- Estructura de desglose de
Registro de cambios.
siciones. recursos.
Lnea base del alcance:
Enunciado del alcance del
proyecto.
Solicitudes de cambio. Calendarios de recursos.
EDT/WBS.
Diccionario de la
EDT/WBS.
Pronsticos:
Pronsticos de costos.
Plan de gestin de la calidad. Registro de riesgos.
Pronstico del. Crono-
grama.
Plan de gestin de los requi-
Registro de incidentes. Datos del cronograma.
sitos.
Plan de gestin de los ries- Propuestas de los vendedo-
Lista de hitos.
gos. res.
Documentos de las adquisicio- Criterios de seleccin de
Lnea base del cronograma.
nes. proveedores.
Plan de gestin del crono- Enunciado del trabajo relativo
Registro de interesados.
grama. a adquisiciones.
Evaluaciones del desempeo
Plan de gestin del alcance. Calendarios del proyecto.
del equipo.
Acta de constitucin del

proyecto. Datos de desempeo del
Requisitos de financia- trabajo.
miento del
Plan de gestin de los intere- Informacin de desem-
Proyecto.
sados. peo del trabajo.
Cronograma del proyecto.
Diagramas de red del cro- Informes de desempeo
nograma del trabajo.
del proyecto.
138
GLOSARIO DE LA UNIDAD IV
1. Base de Conocimientos de Lecciones Aprendidas. Almacenamiento de

informacin histrica y lecciones aprendidas, tanto de los resultados de deci-
siones de seleccin de proyectos anteriores como de desempeo de proyectos
anteriores.
2. Calendario de Recursos. Un calendario que identifica los das y turnos de

trabajo en que cada recurso especfico est disponible.
3. Calendario del Proyecto. Un calendario que identifica los das y turnos de

trabajo disponibles para las actividades del cronograma.
4. Cerrar el Proyecto o Fase. El proceso de culminacin de todas las activida-

des de los Grupos de Procesos de la Direccin de Proyectos, para completar
formalmente un proyecto o una fase del mismo.
5. Cerrar las Adquisiciones. El proceso de finalizar cada adquisicin para el

proyecto.
6. Desarrollar el Plan para la Direccin del Proyecto. El proceso de definir,

preparar y coordinar todos los planes subsidiarios e incorporarlos en un plan
integral para la direccin del proyecto.
139
BIBLIOGRAFA DE LA UNIDAD IV

SCRUMstudy.
Mxico: Pearson.
Juego.
MIT Sloan.
140
AUTOEVALUACIN No 4
1. La Estructura de Desglose de Trabajo es una herramienta efectiva de

comunicacin mejor utilizada por:
A) El Equipo de diseo de Tecnologa e Infraestructura

B) El Gerente Funcional
C) El Cliente
D) Los involucrados
2. Cul de las siguientes afirmaciones es FALSA referente a la Estruc-

tura de Desglose de Trabajo (EDT)?
A) Las actividades deben estar organizadas en la secuencia que van a realizarse.

B) Cada tem tiene un nico identificador.
C) La EDT representa el 100% del trabajo a realizarse en el proyecto.
D) Cada nivel de la EDT provee una representacin ms pequea del trabajo.
3. Frank tiene a su equipo de proyecto ejecutando cuando de forma ines-

perada se presenta una discusin sobre el Alcance de la gestin.
Cmo debe ser resuelta esta situacin?
A) El equipo del proyecto debe decidir la mejor solucin

B) La discusin debe ser resuelta en favor del cliente
C) La discusin debe ser resuelta en favor de la Alta Gerencia del Proyecto
D) El Gerente de Proyectos debe revisar el Acta de Constitucin como referencia
4. Los activos de los procesos de la organizacin incluyen los siguientes

documentos excepto:
A) Plantillas
B) Archivos de proyectos anteriores
C) Lecciones aprendidas
D) Los sistemas de informacin para la administracin del proyecto
5. El Plan para la Direccin del Proyecto contiene los siguientes elemen-

tos excepto:
A) La lnea base del alcance

B) El plan de gestin de cambios
C) El plan de gestin de requisitos
D) Anlisis de Causa y Efecto
6. Un proyecto de TI se encuentra en la fase final de desarrollo. La si-

guiente fase es implementacin. No obstante, el proyecto est ade-
lantado en el cronograma. Antes de continuar, que debe ser lo MAS
trascendental para el gerente de proyectos?
A) Verificar el alcance.
141
B) Controlar la calidad.
C) Desarrollar reportes de control.
D) Controlar el cronograma.
7. El plan de proyecto para remodelar el Teatro Nacional requiere de un

manejo estratgico de todos los entes con el afn de no afectar el
cronograma, el presupuesto y la calidad del producto final de la obra.
Revisando la minuta de la ltima reunin, el gerente de proyectos
analiza que existen todava algunos grupos de inters que se oponen
a los trabajos arquitectnicos. Cul de los procesos de administra-
cin debe el gerente de proyectos evaluar primero?
A) Administracin de los involucrados

B) Administracin del alcance
C) Administracin de los costos
D) Administracin de la calidad
8. Los estndares del PMI y sus mejores prcticas para la gestin de

proyectos constantemente indican que el Gerente de Proyectos debe:
A) Castigar al equipo del proyecto

B) Representar al equipo de proyectos nicamente si todo est bien
C) Reconocer y recompensar al equipo del proyecto
D) Brindar extras al equipo del proyecto en funcin del cliente
9. En el proyecto de Laura, uno de los principales aspectos a considerar

es que la organizacin es funcional. Por ende, Laura tendr que revi-
sar cuidadosamente el cronograma, as como el calendario de los re-
cursos humanos dado que:
A) Los recursos son limitados

B) Los recursos estn 100% disponibles
C) Los recursos los ofrece el gerente de operaciones
D) No existe este tipo de organizacin
10.La habilidad ms importante que el Gerente de Proyectos debe poseer

es:
A) Buenas habilidades administrativas

B) Buenas habilidades de planificacin
C) Buenas habilidades para determinar costos
D) Buenas habilidades de comunicacin
142
ANEXO N 1
Respuestas de la Autoevaluacin de la Unidad I
Nmero Respuesta
1 A
2 C
3 D
4 D
5 D
6 D
7 C
8 A
9 A
10 C
Respuestas de la Autoevaluacin de la Unidad II
Nmero Respuesta
1 D
2 A
3 D
4 C
5 C
6 A
7 A
8 A
9 B
10 C
Respuestas de la Autoevaluacin de la Unidad III
Nmero Respuesta
1 B
2 C
3 A
4 A
5 B
6 D
7 D
8 A
9 A
10 B
143
Respuestas de la Autoevaluacin de la Unidad IV
Nmero Respuesta
1 D
2 A
3 B
4 D
5 D
6 A
7 A
8 C
9 A
10 D
144

Taller de Proyectos de Sistemas e Informatica - A0465

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Taller de Proyectos de Sistemas e Informatica - A0465

Загружено:

Авторское право:

Доступные форматы

UNIVERSIDAD CONTINENTAL VIRTUAL

UNIDAD III: Planificacin del Proyecto

Tema N4: Gestin de Riesgos del Proyecto

UNIDAD IV: Planificacin y Cierre del Proyecto

Tema N 2: Gestin de los Interesados del Proyecto

Tema N4: Activos de la Organizacin

En la actualidad las empresas se enfrentan a mercados globalizados, lo que las ex-

Mg. Pedro S. Castaeda Vargas

Aplica buenas prcticas de la gestin de proyectos, empleando herramientas y

UNIDAD I UNIDAD II Unidad III Unidad IV

TIEMPO MNIMO DE ESTUDIO:

UNIDAD I UNIDAD II UNIDAD III UNIDAD IV

1era. Semana y 3era. Semana y 5ta. Semana y 7ma. Semana y

DIAGRAMA DE PRESENTACIN DE LA UNIDAD I

ORGANIZACIN DE LOS APRENDIZAJES

CONOCIMIENTOS PROCEDIMIENTOS ACTITUDES

Video de presentacin de la 1. Identifica y reconoce los

TEMA N 1: INTRODUCCIN AL PMBOK

En la Gestin de Proyectos, el PMBOK puede ser considerado como la Biblia de la

La Gua de los Fundamentos para la Direccin de Proyectos (Gua del PMBOK)

Para poder profundizar la temtica relacionada a la Gestin de Proyectos, es necesa-

De acuerdo al PMBOK, un proyecto es un esfuerzo temporal que se lleva a cabo

Un proyecto puede generar:

Un producto, que puede ser un componente de otro elemento, una mejora de

Un servicio o la capacidad de realizar un servicio (p.ej., una funcin de negocio

Una mejora de las lneas de productos o servicios existentes (p.ej., Un pro-

Un resultado, tal como una conclusin o un documento (p.ej., un proyecto de

Los ejemplos de proyectos, incluyen entre otros:

El desarrollo de un nuevo producto, servicio o resultado,

La implementacin de un cambio en la estructura, los procesos, el personal o

El desarrollo o la adquisicin de un sistema de informacin nuevo o modificado

La realizacin de un trabajo de investigacin cuyo resultado ser adecuada-

La construccin de un edificio, planta industrial o infraestructura, o

La implementacin, mejora o potenciacin de los procesos y procedimientos

De acuerdo al PMBOK, la direccin de proyectos es la aplicacin de conocimientos,

Para entender los conceptos de direccin de portafolios, direccin de programas

Grfico N 01 1: Relacin Portafolio, Programa y Proyecto.

La direccin de portafolios, la direccin de programas y la direccin de proyectos

La Tabla N 01-1 muestra una comparacin entre las perspectivas de proyecto,

Proyectos Programas Portafolios

La gestin de las operaciones es responsable de la supervisin, la direccin y el

A pesar de su naturaleza temporal, los proyectos pueden contribuir al logro de

5. Valor del Negocio.

6. Influencia de la Organizacin y Ciclo de Vida del Proyecto.

Los proyectos y la direccin de proyectos se llevan a cabo en un entorno ms

La cultura, estilo y estructura de una organizacin influyen en la forma en que

6.1.1. Culturas y Estilos de Organizacin

Las organizaciones son estructuras sistemticas de entidades (personas

6.1.2. Comunicaciones en la Organizacin

El xito en la direccin de proyectos de una organizacin depende en

6.1.3. Estructuras de la Organizacin

La estructura de la organizacin es un factor ambiental de la empresa

La Tabla N 02 muestra las caractersticas clave de los principales tipos

Disponibilidad de Poca o Baja a Mo- Moderada Alta a Casi To-

Quin gestiona el Director

Personal Adminis- Tiempo Tiempo Tiempo Tiempo Tiempo Com-

6.1.4. Activos de los Procesos de la Organizacin

6.1.5. Factores Ambientales de la Empresa

Los factores ambientales de la empresa hacen referencia a condiciones

Un interesado es un individuo, grupo u organizacin que puede afectar, verse

6.3.Equipo del Proyecto

El equipo del proyecto incluye al director del proyecto y al grupo de individuos

6.4.Ciclo de Vida del Proyecto