Beruflich Dokumente
Kultur Dokumente
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
Actividad formativa N2
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
Autoevaluacin No. 02
3
1. Planificar la Gestin de la Calidad
2. Planificar la Gestin de los Recursos Humanos
3. Planificar la Gestin de las Comunicaciones
4
INTRODUCCIN
5
PRESENTACIN
DE LA ASIGNATURA
COMPETENCIA DE LA ASIGNATURA:
UNIDADES DIDCTICAS:
6
UNIDAD I: INTRODUCCIN A LA GESTIN DE PROYECTOS
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.
Lectura seleccionada 2
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
INTRODUCCIN
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.
1. Qu es un proyecto?
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.
2. Qu es la Direccin de Proyectos?
10
3. Relaciones entre Direccin de Portafolios, Direccin de Programas, Di-
reccin de Proyectos y Direccin Organizacional de Proyectos.
Fuente: PM Certifica.
11
Tabla N 01: Presentacin Comparativa de la Direccin de Proyectos, la
Direccin de Programas y la Direccin de Portafolios
Fuente: PMBOK
12
4. Relacin entre Direccin de Proyectos, Gestin de las Operaciones y Es-
trategia Organizacional.
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.
13
6.1.Influencia de la Organizacin en la Direccin de Proyectos
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.
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
Rol del Director del Tiempo Tiempo Tiempo Tiempo Tiempo Com-
Parcial Parcial Completo Completo pleto
Proyecto
Fuente: PMBOK.
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.
15
6.2.Interesados y Gobierno del Proyecto
16
TEMA N 2: PROCESOS DE LA DIRECCIN DE PROYECTOS
INTRODUCCIN
17
Grfico N 02. Grupos de Procesos de la Direccin de Proyectos
Fuente: PMBOK
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.
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.
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.
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.
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.
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:
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
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:
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
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.
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:
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.
31
1.2.El gran inters por gil
2. Manifiesto gil.
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.
32
Grfico N 01 5: Manifiesto gil
33
vistos como colaboradores. El equipo de desarrollo y el cliente trabajan juntos
para evolucionar y desarrollar el producto.
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.
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).
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.
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).
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).
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.
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.
42
LECTURA SELECCIONADA No 2:
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
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
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.
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
46
AUTOEVALUACIN No 1
3. El software es:
A) Construccin.
B) Elaboracin.
C) Iniciacin.
D) Potenciacin.
47
D) Todas las anteriores son correctas.
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.
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.
48
49
UNIDAD II: INICIACIN DEL PROYECTO
50
CONOCIMIENTOS PROCEDIMIENTOS ACTITUDES
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
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.
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
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).
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.
N Contenido
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.
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).
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.
57
5. Modelos de Puntuacin
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.
58
Tabla N 02-2: Ejemplo de un modelo de puntuacin para un Sistema
ERP
59
LECTURA SELECCIONADA No 1:
Cmo hacer Proyectos?
Manuales de Gestin Bolunta, SOLABARRIA, E., pginas 1 21.
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
ACTIVIDAD FORMATIVA N 2
INSTRUCCIONES
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
66
5.2.Caso de Negocio
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),
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
68
6. Desarrollar el Acta de Constitucin del Proyecto: Herramientas y Tcnicas
6.1.Juicio de Expertos
6.2.Tcnicas de Facilitacin
69
Los principios para el desarrollo de la tormenta de ideas son:
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
LECTURA SELECCIONADA No 2:
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.
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
75
AUTOEVALUACIN No 2
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.
A) Los interesados.
B) El director del proyecto.
C) El cliente que da inicio al proyecto.
D) La Gerencia.
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.
77
UNIDAD III:
PLANIFICACIN 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.
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
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.
El Grfico 03-4 muestra las entradas, herramientas y tcnicas, y salidas de este
proceso.
81
Grfico N 03-4. Crear la EDT/WBS: Entradas, Herramientas, Tcnicas y
Salidas
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.
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.
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.
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.
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.
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.
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.
89
6. Desarrollar el Cronograma.
90
y el mantenimiento del modelo de programacin del proyecto continan a lo largo
del mismo para mantener un cronograma realista.
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.
El Grfico 03-13 muestra las entradas, herramientas y tcnicas, y salidas de este
proceso.
92
Grfico N 03-13. Determinar el Presupuesto: Entradas, Herramientas,
Tcnicas y Salidas
93
LECTURA SELECCIONADA No 1: CREAR LA EDT/WBS
Gua de los Fundamentos para la Direccin de Proyectos (Gua del PMBOK., 2013,
pginas 125 132.
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
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.
97
Grfico 03-18: Ejemplo de una EDT/WBS basada en los Entregables
Principales
98
ACTIVIDAD FORMATIVA N 3
INSTRUCCIONES
99
TEMA N 3: GESTIN DE LA CALIDAD, RECURSOS HUMANOS Y
COMUNICACIONES DEL PROYECTO
INTRODUCCIN
100
Grfico N 03-19. Planificar la Gestin de la Calidad: Entradas, Herra-
mientas, 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.
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
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.
El Grfico 03-22 muestra las entradas, herramientas y tcnicas, y salidas de este
proceso.
105
Grfico N 03-23. Identificar los Riesgos: Entradas, Herramientas,
Tcnicas y Salidas
106
Grfico N 03-24. Realizar el Anlisis Cualitativo de Riesgos: Entradas,
Herramientas, Tcnicas y Salidas
107
Grfico N 03-25. Realizar el Anlisis Cuantitativo de Riesgos: Entradas,
Herramientas, Tcnicas y Salidas
108
Grfico N 03-26. Planificar la Respuesta a los Riesgos: Entradas,
Herramientas, Tcnicas y Salidas
109
LECTURA SELECCIONADA No 2:
GUA PRCTICA DE GESTIN DE RIESGOS
Instituto Nacional de Tecnologas de la Comunicacin, (2008), pginas 6 20.
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
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
113
BIBLIOGRAFA DE LA UNIDAD III
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.
114
AUTOEVALUACIN No 3
A) Definir el Alcance
B) Recopilar Requisitos
C) Asegurar el Alcance
D) Crear la Estructura de Desglose del Trabajo (EDT)
A) La Tcnica Delphi
B) Tormenta de Ideas
C) Diagrama de Afinidad
D) Ninguna de las opciones es correcta
A) Inicio
B) Planeacin
C) Ejecucin
D) Monitoreo y Control
115
C) Verificar el Alcance del Proyecto
D) Crear la EDT (Estructura de Desglose del Trabajo)
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
117
CONOCIMIENTOS PROCEDIMIENTOS ACTITUDES
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
Lectura seleccionada 1
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
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.
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.
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:
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
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.
126
Grfico N 04-5. Planificar la Gestin de los Interesados: Entradas, He-
rramientas, Tcnicas y Salidas
127
ACTIVIDAD FORMATIVA N 4
INSTRUCCIONES
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.
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
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.
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.
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.
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.
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.
136
LECTURA SELECCIONADA No 1:
Desarrollar el Plan para la Direccin del Proyecto
Gua de los Fundamentos para la Direccin de Proyectos (Gua del PMBOK., 2013,
pginas 72 78.
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
138
GLOSARIO DE LA UNIDAD IV
139
BIBLIOGRAFA DE LA UNIDAD IV
140
AUTOEVALUACIN No 4
A) Plantillas
B) Archivos de proyectos anteriores
C) Lecciones aprendidas
D) Los sistemas de informacin para la administracin del proyecto
A) Verificar el alcance.
141
B) Controlar la calidad.
C) Desarrollar reportes de control.
D) Controlar el cronograma.
142
ANEXO N 1
Nmero Respuesta
1 A
2 C
3 D
4 D
5 D
6 D
7 C
8 A
9 A
10 C
Nmero Respuesta
1 D
2 A
3 D
4 C
5 C
6 A
7 A
8 A
9 B
10 C
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