Actualizado al

Peter M. Yamakawa T.
Ph.D., MBA, Msc. Ing., PMP
pyamakawa@esan.edu.pe
Introduccin
Gerencia de Proyectos
14/07/2014



Entender la importancia de la gerencia de
proyectos

Explicar que es la gerencia de proyectos y sus
elementos clave

Conocer los errores clsicos en proyectos
respecto de las personas, procesos, productos
y tecnologa
1
2
Objetivos de aprendizaje
3

Agenda
Gerencia de proyectos
Qu pasa con los proyectos?
Procesos de direccin de proyectos
Ciclo de vida de proyectos
Errores clsicos



Qu pasa con los proyectos?

Qu es un proyecto?
Es una combinacin de recursos en un tiempo determinado,
generalmente para una organizacin y para lograr un
propsito especfico
Crea un producto, servicio o un resultado.

Atributos:
Un propsito nico
Es temporal
Uso de mltiples recursos
Debera contar con un patrocinador o un cliente principal
Incertidumbre



El mundo gast casi $2.4 trillones en el 2007

Ms de 16 millones de personas estn
involucradas en proyectos en el mundo

Tom Peters nos dice: Para ganar hoy debemos
dominar el arte de la gerencia de proyectos
Informacin sobre la gerencia de
proyectos
Fuente: Chaos

Ventajas de la gerencia de proyectos
Mejor control financiero, fsico y recursos humanos
Mejora la relacin con los clientes
Reduce lo tiempos de desarrollo
Reduce los costos
Mejora la calidad y la confiabilidad
Mayores mrgenes
Mejora la productividad
Mejora la coordinacin interna
Mejora el ambiente de trabajo


La triple restriccin de la gerencia de
proyectos

Una visin expandida de las
3 restricciones
Satisfaccin al
cliente
tiempo
Costo
Alcance
Calidad
Riesgo

Portafolio de proyectos
Programa
Portafolio
Proyectos Programas
Programas Proyectos
Proyectos
Portafolio
Proyectos Proyectos Proyectos



Gerencia de Proyectos

Qu es gerencia de proyectos?
Es la aplicacin de conocimientos, habilidades, herramientas a
las actividades de los proyectos para satisfacer los
requerimientos de los proyectos
Los gerentes de proyectos trabajan para satisfacer la triple
restriccin

10 reas de gerencia de proyectos
Las reas describen las competencias claves que todo gerente de
proyectos debe desarrollar:
4 reas principales de conocimiento principales para lograr los
objetivos
(Gestin del alcance, tiempo, costo, calidad)
5 reas de apoyo como medio por el cual los objetivos son
logrados
(Gestin de recursos humanos, comunicacin, riesgo,
compras, interesados)
1 rea de integracin

Grupos de Inters
Gente involucrada en el proyecto o es afectada por sus
actividades, incluye:
Sponsor
Gerente de proyecto
Equipo
Clientes
Usuarios
Proveedores
Opositores del proyecto??

Relacin entre los interesados y el
proyecto

Herramientas y tcnicas de gestin de
proyectos
Acta de constitucin
Definicin del alcance
EDT
Diagrama de gantt
Estimacin de tiempos
Ruta critica, etc.

Super- herramientas
Son las herramientas que tiene un alto uso y alto impacto en el
xito del proyecto, tales como:
Reporte de lecciones aprendidas
Software
Definicin del alcance
Reporte de los avances
Requerimientos de cambios
Kick-off meeting
Diagrama de gantt

Qu ayuda a tener xito en los
Proyectos?
Apoyo de la alta gerencia
Compromiso del usuario
Experiencia del gerente de proyectos
Claros objetivos de negocios
Objetivos reales
Infraestructura estndar de Sw y Hw
Metodologas formales
Estimaciones confiables
Otros criterios como hitos, apropiado plan, equipo competente,
aduearse del proyecto

Qu hacen los ganadores?
Utilizar herramientas y tcnicas de la gerencia de proyectos
(muchas plantillas por ejemplo).
Dan nfasis en el negocio
Desarrollan un proceso simple de gerencia de proyectos
Miden la salud del proyecto utilizando mtricas como
satisfaccin del cliente, retorno de la inversin



Sugerencias para los gerentes de
proyectos
Deben tener una serie de habilidades
Adecuarse a los cambios
Entender las organizaciones donde trabajan
Ser capaz de guiar al equipo a cumplir los objetivos del
proyecto

Las 10 habilidades y competencias de
los gerentes de proyectos
Habilidades para llegar a la gente
Liderazgo
Capaz de escuchar
Integridad
Capaz de construir confianza
Habilidad de comunicacin
Gestin de conflicto
Pensamiento crtico, solucionar problemas
Entender y balancear prioridades

Diferentes habilidades en diferentes
situaciones
Proyectos grandes: Liderazgo, experiencia, planeamiento,
manejo de gente, comunicacin, team building son los ms
importantes
Proyectos altamente inciertos: gestin de riesgos, gestin de
las expectativas, liderazgo, manejo de gente, habilidades de
planeamiento son los ms importantes
Proyectos novedosos: Liderazgo, manejo de gente, visin,
confianza, manejo de las expectativas, habilidades de
escuchar son los ms importantes



Ciclo de Vida de los Proyectos

Estructura del ciclo de vida
Inicio
Organizacin
y preparacin
Ejecucin
Cierre

Costos y dotacin de personal durante
el ciclo de vida del proyecto
Inicio

Organizacin
y preparacin
Ejecucin

Cierre

Plan de
Direccin del
Proyecto
Entregables
Aceptados
Documentos
del Proyecto
Aceptados
Salidas de la
gestin de
proyectos
Acta de
constitucin
N
i
v
e
l

d
e

c
o
s
t
o

y

p
e
r
s
o
n
a
l

Tiempo

Impacto de los interesados, riesgos y la
incertidumbre
Bajo
Costo de los
cambios
N
i
v
e
l

Tiempo
Alto
Influencia de los
interesados,
riesgo e incertidumbre

Fases del proyecto
Son las divisiones dentro del mismo proyecto, donde es
necesario un control adicional con el fin de gestionar
eficazmente la conclusin de un entregable mayor.
Las fases pueden completarse de manera secuencial, pero en
determinados casos de un proyecto pueden superponerse.
La estructuracin de fases permite la divisin del proyecto en
subconjuntos lgicos para facilitar su direccin, planificacin y
control.

Proyecto de una sola fase

Proyecto de tres fases
Proyecto de fases superpuestas

Activos de los procesos de la
organizacin
Son algunos o todos los activos relativos a procesos de alguna
o todas las organizaciones participantes en el proyecto que
puedan utilizarse para influir en el xito de un proyecto.
Estos activos contemplan planes, polticas, procedimientos y
lineamientos, formales e informales.

Procesos de la organizacin
Procesos y procedimientos

Procesos estndar de la organizacin
Lineamientos, instrucciones de trabajo,
etc.
Lineamientos y criterios para adaptar el
conjunto de procesos
Requisitos de comunicacin de la
organizacin
Lineamientos del cierre del proyecto
Procedimientos de control financiero
Procedimientos para la gestin de
problemas y defectos
Procedimientos de control de cambios
Procedimientos de control de riesgos
Procedimientos para priorizar, aprobar y
emitir autorizaciones de trabajo.
Base corporativa del conocimiento
Base de datos para la medicin de
procesos
Archivo de proyectos
Informacin histrica y bases del
conocimiento de lecciones aprendidas
Base de datos sobre la gestin de
problemas y defectos
Base del conocimiento de la gestin de la
configuracin
Base de datos financieros que contienen
informaciones como horas de trabajo,
costos incurridos, presupuestos y dficit
presupuestario.



Procesos de Direccin de
Proyectos
Procesos de direccin de proyectos

El grupo de procesos de la gestin de
proyectos
Procesos de
iniciacin
Proceso de
Planificacin
Procesos de control
Procesos de ejecucin
Procesos de cierre

Grupos de procesos de la direccin de
proyectos

Grupo de procesos que interactan en
una fase o proyecto



Errores en los proyectos

Errores clsicos que se comenten en
los proyectos
PERSONAS PROCESOS
PRODUCTOS TECNOLOGA
Fuente: Rapid development Steve McConnel

Motivacin dbil o mediocre
Motivacin dbil
Estudio tras estudio se ha mostrado que la
motivacin probablemente tiene mayor efecto sobre
la productividad y la calidad que ningn otro factor
(Boehm, 1981).
Personal Mediocre
Despus de la motivacin la capacidad individual de
los miembros del equipo, as como sus relaciones
como equipo, probablemente tienen la mayor
influencia en la productividad (Boehm, 1981;
Lakhanpal, 1993).


Empleados problemticos incontrolados
Un fallo al tratar con personal problemtico tambin
amenaza la velocidad de desarrollo. Es un problema
habitual, y se ha comprendido bien, al menos desde
que (Gerald Weinber, 1971)
Un fallo al tomar una decisin cuando se trata con
un empleado problemtico es una de las quejas mas
comunes que tienen los miembros del equipo
respecto de sus responsables (Larson y LaFasto,
1989)

Aadir mas personal a un proyecto
retrasado
Esta es quizs el mas clsico de los errores
clsicos. Cuando un proyecto se alarga, aadir mas
gente puede quitar mas productividad a los
miembros del equipo existente de la que aaden los
nuevos miembros. Fred Brooks compara aadir
gente a un proyecto retrasado con echar gasolina en
un fuego (Brooks, 1975)

Oficinas repletas y ruidosas
La mayora de los desarrolladores consideran sus
condiciones de trabajo como insatisfactorias.
Alrededor del 60 por 100 indican que no tienen
suficiente silencio ni privacidad (De-Marco y Liste,
1987).


Fricciones entre los clientes y los
desarrolladores
Las fricciones entre los clientes y los desarrolladores pueden
presentarse de distintas formas. A los clientes puede
parecerles que los desarrolladores no cooperan cuando
rehsan comprometerse con el plan de desarrollo que desean
los clientes o cuando fallan al entregar lo prometido.
A los desarrolladores puede parecerles que los clientes no son
razonables porque insisten en planes irreales o cambios en los
requerimientos despus de que estos hayan sido fijados.
En el caso medio, las fricciones entre clientes y desarrolladores
de software llegan a ser tan severas que ambas partes
consideran la cancelacin del proyecto (Jones, 1994)

Expectativas poco realistas
Una de las causas mas comunes de fricciones entre
los desarrolladores y sus clientes o los directivos
son las expectativas poco realistas.
Una inspeccin de Standish Group marc las
expectativas realistas como uno de los cinco
factores principales necesarios para asegurar el
xito de los proyectos internos de software de
gestin (Standish Group, 1994)

Falta de un patrocinador efectivo del
proyecto
Para soportar muchos de los aspectos del desarrollo
rpido es necesario un promotor del proyecto de alto
nivel, incluyendo una planificacin realista, el control
de cambios y la introduccin de nuevos mtodos de
desarrollo.
El consultor Australiano Rob Thomsett afirma que
la falta de un promotor efectivo garantiza
virtualmente el fracaso del proyecto (Thomsett,
1995).


Falta de participacin de stakeholders
Falta de participacin de los implicados
Todos los principales participantes del esfuerzo de
desarrollo de software deben implicarse en el
proyecto. Incluyendo a los promotores, ejecutivos,
responsables del equipo, miembros del equipo,
personal de ventas, usuarios finales, clientes y
cualquiera que se juegue algo con el proyecto.
Falta de participacin del usuario
La inspeccin de Standish Group descubri que la
razn numero uno de que los proyectos de Sistemas
de Informacin tuviesen xito es la implicacin del
usuario. (Standish Group, 1994)

Poltica antes que desarrollo
Larry Constantine indic que si hay cuatro equipos
hay cuatro tipos diferentes de orientaciones polticas
(Constantine, 1995).
Los polticos estn especializados en la gestin,
centrndose en las relaciones con sus directivos.
Los investigadores se centran en explorar y reunir
informacin.

Ilusiones
Cuantas veces hemos escuchado cosas como estas a distintas
personas: Ninguno de los miembros del proyecto cree
realmente que pueda completarse el proyecto de acuerdo
con el plan que tiene, pero piensan que quizs se trabajan
duro, y nada va mal, y tienen un poco de suerte, sern
capaces de concluir con xito..
Las Ilusiones no son slo optimismo. Realmente consisten en
cerrar los ojos y esperara que todo funciones cuando no se
tienen las bases razonables para pensar que ser as. Las
Ilusiones al comienzo del proyecto llevan a grandes
explosiones al final. Impiden llevar a cabo una planificacin
coherente y pueden ser la raz de mas problemas en el
software que todas las otras causas combinadas.


Errores clsicos que se comenten en
los proyectos
PERSONAS PROCESOS
PRODUCTOS TECNOLOGA
Fuente: Rapid development Steve McConnel

Planificacin excesivamente optimista
Fijar un plan excesivamente optimista predispone a que el
proyecto falle por infravalorar el alcance del proyecto, minando
la planificacin efectiva y reduciendo las actividades criticas
para el desarrollo, como anlisis de requerimientos o el diseo.
Tambin supone una excesiva presin para los
desarrolladores, quienes a largo plazo se ven afectados en su
moral y su productividad.


Si no ejercemos una gestin activa de los riesgos, con que solo
vaya mal una cosa se pasara de tener un proyecto con un
desarrollo rpido a uno con un desarrollo lento. El fallo de no
gestionar uno solo de estos riesgos es un error clsico.
Gestin de riesgos insuficientes

Fallos de los contratados
Las empresas a veces contratan la realizacin de partes de un
proyecto cuando tienen demasiada prisa para hacer el trabajo
en casa. Pero los contratados frecuentemente entregan su
trabajo tarde, con una calidad inaceptable o que falla al no
coincidir con la especificacin (Bohem, 1989).
El problema no esta en el abandono del plan, sino mas bien en
fallar al no crear un plan alternativo, y caer entonces en el
modo de trabajo de codificar y corregir.


Si no planificamos para conseguir un desarrollo rpido, no
podemos esperar obtenerlo.
Planificacin insuficiente

Abandono de la planificacin bajo
presin
Los equipos de desarrollo hacen planes y rutinariamente los
abandonan cuando se tropiezan con un problema en la
planificacin (Humphrey, 1989).
El problema no est en el abandono del plan, sino mas bien en
fallar al no crear un plan alternativo, y caer entonces en el
modo de trabajo de codificar y corregir.



El inicio difuso es el tiempo que trascurre antes de que
comience el proyecto; este tiempo normalmente se pierde en el
proceso de aprobar y hacer el presupuesto.
Perdida de tiempo en el inicio difuso

Escatimar en las actividades iniciales
Los proyectos que se aceleran intentando acortar las
actividades no esenciales, y puesto que el anlisis de
requerimientos, la arquitectura y el diseo no producen cdigo
directamente, son los candidatos fciles.


Un caso especial de escatimar en las actividades iniciales es el
diseo inadecuado. Proyectos acelerados generan un diseo
indeterminado, no asignando suficiente tiempo para l y
originando un entorno de alta presin que hace difcil la
posibilidad de considerar alternativas en el diseo.
Diseo inadecuado

Escatimar en el control de calidad
En los proyectos que se hacen con prisa se suele cortar por lo
sano, eliminando las revisiones del diseo y del cdigo,
eliminando la planificacin de las pruebas y realizando solo
pruebas superficiales.
Acortar en un da las actividades de control de calidad al
comienzo del proyecto probablemente supondr de 3 a 10 das
de actividades finales (Jones, 1994). Esta reduccin va contra
la velocidad de desarrollo.


Poco control de la directiva para detectar a tiempo los signos
de posibles retrasos en el plan, y los pocos controles definidos
al comienzo se abandonan cuando el proyecto comenz a
tener problemas. Antes de encarrilar un proyecto, en primer
lugar debemos ser capaces de decir si va por buen camino.
Control insuficiente de la directiva

Convergencia prematura o
excesivamente frecuente
Bastante antes de que se haya programado entregar un
producto, hay un impulso para preparar el producto para la
entrega, mejorar el rendimiento del producto, imprimir la
documentacin final, incorporar entradas en el sistemas final
de ayuda, pulir el programa de instalacin, eliminar las
funciones que no van a estar listas a tiempo y dems.


Si la gente no guarda cuidadosamente datos de proyectos
anteriores, olvida las tareas menos visibles, pero son tareas
que se han de aadir. El esfuerzo omitido suele aumentar el
plan de desarrollo en un %20 o %30 (Van Genuchten, 1991).
Omitir tareas necesarias en la estimacin

Planificar ponerse al da mas adelante
Un tipo de estimacin es responder inapropiadamente al
retraso del plan. Si hemos trabajado en un proyecto durante 6
meses, y hemos empleado tres meses en llegar al hito
correspondiente a los dos meses, Que hacer? En muchos
proyectos simplemente se plantea recupera el retraso mas
tarde, pero nunca se hace.
Otro tipo de error en la reestimacin se debe a cambios en el
producto. Si el producto que estamos construyendo cambia, la
cantidad de tiempo necesaria para construirlo cambiara
tambin.

Errores clsicos que se comenten en
los proyectos
PERSONAS PROCESOS
PRODUCTOS TECNOLOGA
Fuente: Rapid development Steve McConnel

Exceso de Requerimientos
Algunos proyectos tiene mas requerimientos de los que
necesitan, desde el mismo inicio. La eficiencia se fija como
requisito mas a menudo de lo que es necesario, y puede
generar una planificacin del software innecesariamente larga.


Incluso si hemos evitado con xito los requerimientos
excesivos, los proyectos sufren como media sobre un %25 de
cambios en los requerimientos a lo largo de su vida (Jones,
1994).
Un cambio de este calibre puede producir un aumento en el
plan de al menos %25, lo que puede ser fatal para los
proyectos de desarrollo rpido.
Cambio de las prestaciones

Desarrolladores meticulosos
Los desarrolladores encuentran fascinante la nueva tecnologa,
y a veces estn ansiosos por probar nuevas prestaciones de
su lenguaje o entorno, o por crear su propia implementacin de
una utilidad bonita que han visto en otro producto, la necesite o
no su producto. El esfuerzo requerido para disear,
implementar, probar, documentar o mantener estas
prestaciones innecesarias alarga el plan.

Tiras y aflojas en la negociacin
Cuando un directivo aprueba un retraso en el plan e un
proyecto que progresa mas lento de lo esperado, y entonces
aade tareas completamente nuevas despus de un cambio en
el plan, se produce una situacin curiosa.
La razn subyacente de esto es difcil de localizar, puesto que
el directivo que aprueba el retraso en el plan lo hace sabiendo
implcitamente que el plan estaba equivocado. Pero una vez
que se corrige, la misma persona realiza acciones explicitas
para volver a equivocarse. Esto solo puede ir en contra del
plan.

Desarrollo orientado a la investigacin
Seymour Cray, el diseador de los supercomputadores Cray,
dijo que no intentaba sobrepasar los limites de la ingeniera en
mas de dos reas a la vez, por que el riesgo de fallo es
demasiado alto (Gilb, 1988).
Si el proyecto fuerza los limites de la informtica por que
necesita la creacin de nuevos algoritmos o de nuevas
tcnicas de computacin, no estamos desarrollando software;
estamos investigando en software. Los planes de desarrollo de
software son razonablemente predecibles; los planes en la
investigacin sobre software ni siquiera son predecibles
tericamente.

Errores clsicos que se comenten en
los proyectos
PERSONAS PROCESOS
PRODUCTOS TECNOLOGA
Fuente: Rapid development Steve McConnel

Sndrome de la panacea
Cuando un equipo de proyecto se aferra solo a una nueva
tcnica, una nueva tecnologa o un proceso rgido, y espera
resolver con ello sus problemas de planificacin, esta
inevitablemente equivocado (Jones, 1994)



Es un viejo recurso que funciona raramente. A veces puede
tener sentido actualizar incrementalmente dentro de la misma
lnea de productos, de la versin 3 a la 3.1 o incluso a la 4.
Pero cuando estamos a la mitad de un proyecto, la curva de
aprendizaje, rehacer el trabajo y los inevitables errores
cometidos con una herramienta totalmente nueva,
normalmente anulan cualquier posible beneficio.

Cambiar de herramientas a mitad del
proyecto

Sobreestimacin de las ventajas del empleo de
nuevas herramientas o mtodos
Las organizaciones mejoran raramente su productividad a
grandes saltos, sin importar cuantas nuevas herramientas o
mtodos empleen o lo buenos que sean.
Los beneficios de las nuevas tcnicas son parcialmente
desplazados por las curvas de aprendizaje que llevan
asociadas, y aprender a utilizar nuevas tcnicas para
aprovecharlas al mximo lleva su tiempo.
Un caso especial de sobreestimaciones de las mejoras se
produce cuando se reutiliza cdigo d e proyectos anteriores.
Este tipo de reutilizacin puede ser una tcnica muy efectiva,
pero el tiempo que se gana no es tan grande como se espera.

Cambiar de herramientas a mitad del
proyecto
Es un viejo recurso que funciona raramente. A veces puede
tener sentido actualizar incrementalmente dentro de la misma
lnea de productos, de la versin 3 a la 3.1 o incluso a la 4.
Pero cuando estamos a la mitad de un proyecto, la curva de
aprendizaje, rehacer el trabajo y los inevitables errores
cometidos con una herramienta totalmente nueva,
normalmente anulan cualquier posible beneficio.

Falta de control automtico del cdigo
fuente
Un fallo en la utilizacin del control automtico del cdigo
fuente expone a los proyectos a riesgos innecesarios. Sin el, si
dos desarrolladores estn trabajando en la misma parte del
programa, deben coordinar su trabajo manualmente. Deberan
ponerse de acuerdo para poner la ultima versin de cada
archivo en el directorio maestro y verificarlos con los dems
antes de copiarlas en este directorio. Pero invariablemente
alguno sobrescribir el trabajo del otro.
Se desarrolla nuevo cdigo con interfaces desfasadas, y
despus se tiene que re-disear el cdigo al descubrir que se
ha utilizado una versin equivocada de la interfaz.
Como media, los cambios en el cdigo fuente suelen ser de un
%10 al mes y con un control manual del cdigo fuente no
deberan crecer.