Recuperación de Proyectos en Crisis

Recuperación de
Proyectos en Crisis
Andrés Felipe Gómez
Marzo 22 y 23 de 2007 1
Agenda
{ Necesidad de la recuperación
de proyectos en crisis
{ Síntomas de que un proyecto
necesita recuperación
{ Metodología
{ Herramientas
{ Conclusiones
{ Bibliografía
V Jornada de Gerencia de 2
Proyectos de TI
1
Agenda
{ Metodología
{ Herramientas
{ Conclusiones
{ Bibliografía
Proyectos de TI
Dura realidad
Cuándo fue la última vez que usted trabajó en
un proyecto que fue planeado y se ejecutó
perfectamente y donde usted cumplió las
expectativas en términos de presupuesto, de
plazo de entrega y de la calidad del producto?
Ah, y además usted tuvo una relación cordial y

profesional con sus usuarios/clientes. En otras
palabras – no se presentó ningún problema.
Por qué tanto silencio???? No es para tanto!!!!
Proyectos de TI
2
Dura realidad
Si usted ha tenido suerte, puede ser que
realmente pueda pensar en uno o dos proyectos
que pudieran ser candidatos.
Además es fácil olvidarse que muchos proyectos

terminan realmente con éxito.
Aunque probablemente no hay un proyecto

absolutamente perfecto, hay muchos proyectos
que se terminan con una cantidad mínima de
problemas y de estrés.
Proyectos de TI
Dura realidad
Ahh, y por supuesto, están los proyectos
“enproblemados". Éstos son aquellos que tienen
problemas tales como:
z El proyecto está excediendo en 30% o más su
presupuesto estimado.
z El proyecto está excediendo en 30% o más su
duración estimada (aunque éste puede no ser tan
importante si el presupuesto no se excede en 30% o
más).
z El proyecto está dentro de presupuesto y de
cronograma, pero comprometiendo la calidad a tal
punto que el valor y la integridad de los entregables es
cuestionable.
z El cliente está muy descontento con el desempeño del
equipo de proyecto. Si el cliente tuviera que hacer el
proyecto otra vez, no utilizaría el mismo equipo de
proyecto.
Proyectos de TI
3
Dura realidad
Aquí hay un par de ejemplos de los síntomas
que contribuyen a la necesidad de una
evaluación y una recuperación rápidos :
z Nadie en el proyecto sabe cuándo se va acabar
z Los entregables del proyecto están llenos de errores y
defectos
z Los miembros del equipo están trabajando horas
extras de manera excesiva
z El gerente de proyecto no puede pronosticar una fecha
o una estimación de la terminación del proyecto
z Los requerimientos no paran de cambiar
z Las relaciones interpersonales entre los miembros del
equipo de proyecto son altamente tensionantes
z El cliente está considerando la cancelación del
proyecto
Proyectos de TI
Dura realidad
El darle vuelta a un proyecto en problemas
nunca es fácil, pero hay técnicas que le pueden
proveer una mayor probabilidad de "éxito".
El "éxito" puede significar lograr renegociar el

presupuesto, la duración y las expectativas de
los entregables.
Proyectos de TI
4
Dura realidad
Los proyectos pueden fracasar por una gran
variedad de razones:
z mala estimación inicial
z carencia del planeación
z inadecuada atención al plan de trabajo
z mala gerencia del control de cambios al

alcance
z falta de revisiones de los riesgos del
proyecto
z etc.
z etc.
Proyectos de TI
Estadísticas de proyectos
Incompleto
Exitoso Terminado y operativo, a destiempo, Fracasado
por encima de presupuesto, y
Terminados a tiempo, dentro de Cancelado antes de
presupuesto, y con la funcionalidad con menos funcionalidad y terminarse o nunca se
características de las especificadas
y características especificadas implementó
2004 29% 53% 18%
2002 28% 33% 39%
2000 28% 49% 23%
1998 26% 46% 28%
1996 27% 33% 40%
1994 16% 53% 31%
Estadísticas del Standish Group

V Jornada de Gerencia de International 10
Proyectos de TI
5
Razones para el éxito de un
proyecto
{ Para el Standish Group las razones más
importante para el éxito son:
> 6 meses de duración
> 6 personas
> US$750,000 en costo
z Involucramiento de los usuarios
z Apoyo de la Alta Gerencia
z Gerente de Proyectos con experiencia
z Objetivos de negocio claros
z Buenas comunicaciones
Proyectos de TI
Razones para el éxito de un

proyecto
{ “... hay innumerables maneras de fallar al construir
grandes sistemas de información. Hay muy pocas maneras
de tener éxito. Todas los caminos que llevan al desarrollo
exitoso de software tienen estas doce cualidades
esenciales…” Software Quality -- Analysis and Guidelines
for Success, Capers Jones
{ 12 Atributos esenciales para SW exitoso de Capers Jones:
1. Efectiva planeación del proyecto 7. Efectivo desarrollo de procesos

2. Efectiva estimación de costos del proyecto 8. Efectivas comunicaciones
3. Efectiva medición del proyecto 9. Gerentes de proyecto competentes
4. Efectivo seguimiento de hitos del proyecto 10. Personal técnico competente
5. Efectivo control de calidad del proyecto 11. Buen uso de los especialistas
6. Efectivo manejo del cambio en el proyecto 12. Grandes volúmenes de material
reutilizable
Proyectos de TI
6
Agenda
{ Metodología
{ Herramientas
{ Conclusiones
{ Bibliografía
Proyectos de TI
Síntomas
“El que no haya cometido un error es que

nunca se ha atrevido a hacer nada nuevo.” -- Albert Einstein
14
7
Premisas
{ Uno de los retos del gerente de proyectos es
identificar un proyecto que se puede estar
descarrilando (entrando en crisis) y tener la
habilidad para volver a encarrilarlo (hacerle
reingeniería a los problemas).
{ Una cosa es cierta: si no se hace nada, el
proyecto está condenado a fracasar. Por eso
queremos proveer la metodología para llevar un
proyecto en problemas nuevamente a su rumbo
original o a uno que permita su éxito.
Proyectos de TI
Escenario típico
{ Después de ser llamado para determinar por
qué un proyecto importante había incumplido
su tercer plazo en más de tres meses, el
gerente de proyecto comenzó una revisión del
presupuesto y de los gastos de proyecto, que
tan completa estaba la carpeta del proyecto
con respecto a las especificaciones, planes,
correos electrónicos, etc., y después procedió
a entrevistarse con todos los stakeholders.
Proyectos de TI
8
Escenario típico
{ Algunos de los síntomas de problemas:
z “El proyecto tenía una pérdida $80 millones luego de 6
meses.”
z “No había evidencia de un sistema de control de
cambios.”
z “El personal era muy flojo.”
z “Lo peor de todo, muchos miembros del equipo de
proyecto no podían esperar para expresar su opinión
acerca de quién pensaban ellos que tenía la culpa.”
z “La Alta Gerencia no entiende por qué el proyecto está
saliéndose de rumbo si en todos los reportes de estado
de meses anteriores se indica lo contrario.”
z “El proyecto es supremamente crítico para el plan
estratégico de la compañía y no hay ninguna otra
opción que continuar.”
Proyectos de TI
Escenario típico
{ Después de sesiones exhaustivas, el paso
siguiente llegó a ser obvio: parar todas las
actividades del proyecto por un período de dos
semanas para volver a planear, modificar el
diseño, mejorar las comunicaciones y
finalmente realinear todos los recursos
necesarios.
{ Es un acto de gran valentía dar la orden de
parar el proyecto. Pero es la cosa más sensata
y, a largo plazo, lo más responsable de hacer.
Proyectos de TI
9
10 síntomas de que su proyecto
1. Falta de comunicación
2. Planeación del proyecto y administración del plan
inadecuados
3. Requerimientos inestables
4. Falta de entrenamiento/acompañamiento para los

gerentes de proyecto
5. Cronogramas no realistas/no realizables
6. Alta rotación del personal del proyecto
7. Uso inadecuado de recursos externos
8. Ambiente de trabajo inadecuado
9. Personal “atado” a una tecnología obsoleta
10.Carencia de compromiso a largo plazo

Proyectos de TI
1. Falta de comunicación
{ La comunicación es clave para asegurarse que todos los
stakeholders entienden lo que se espera del proyecto
{ El Gerente de Proyecto es la interfaz de comunicación
más importante en todos los aspectos de un proyecto
exitoso. Comunicación con:
z Usuarios finales/Clientes
z Equipo de proyecto
Usuario
final
z Alta Gerencia
{ El Gerente de Proyecto debe estar GP

empoderado y poseer habilidades Personal
para comunicar sus necesidades y Proyecto Alta
Gerencia
decisiones.
Proyectos de TI
10
2. Planeación del proyecto y
administración del plan inadecuados
{ La falta de planeación o la planeación

inadecuada es la causa que más se oye en el
fracaso de un proyecto.
{ La administración del plan es clave. No olvide
que la planeación es un proceso iterativo.
{ Planeación de riesgos que incluya mitigación y
planes de contingencia
● Mirar qué puede salir mal y determinar
maneras de aliviar o reducir el impacto si
salen mal
Proyectos de TI
Gerencia de Riesgos? Para qué?
Proyectos de TI
11
3. Requerimientos inestables
{ La causa más común del fracaso de proyectos
es de requerimientos mal entendidos o sin
control.
{ Existen muchas herramientas, manuales y
automáticas para administrar requerimientos
z Es recomendable que todo proyecto use una
herramienta independientemente del tamaño.
{ Las tareas básicas de administración de
requerimientos incluyen:
z Recabar, analizar, documentar y administrar
los requerimientos.
Proyectos de TI
Y el peso si es el adecuado?
Proyectos de TI
12
4. Falta de entrenamiento
para los gerentes de proyecto
{ Tomar un gran técnico y ponerlo a cargo del
proyecto puede causar muchos de los
problemas más graves en un proyecto.
{ Se recomienda que a cada nuevo Gerente de
Proyecto se le dé entrenamiento o se le haga
acompañamiento en Gerencia de Proyectos
z Por experiencia, el mejor método es una
combinación de entrenamiento y de
acompañamiento.
Proyectos de TI
5. Cronogramas no realistas/
no realizables
{ Los cronogramas son una herramienta esencial
para los staleholders (y una obligatoria para el
Gerente de Proyecto)
{ Se debe entender y controlar la ruta crítica y las
dependencias de las actividades que la
componen
● Un atraso de más de 25% es una “buena” señal
de problemas insuperables
{ Hacer análisis de compresión del cronograma
(crashing o fast-tracking)
Proyectos de TI
13
Nueva funcionalidad
de MS® Project?
Proyectos de TI
6. Alta rotación del personal

del proyecto
{ Una alta rotación de personal es un indicativo
de baja moral que puede llevar al fracaso del
proyecto.
{ Construya un equipo de proyecto que trabaje
bien en conjunto.
{ Construya un ambiente de confianza y
motivación en el equipo y manténgalo
enfocado.
{ Recuerde que el personal nuevo le quita
productividad al personal existente.
Proyectos de TI
14
En dónde estamos?
Lo que ve el sponsor o el cliente
Iniciación
Especificación
Diseño
Producción
Pruebas y
Evaluación
Lo que ve el equipo de proyecto
???
Proyectos de TI
7. Uso inadecuado de recursos

externos
{ El Outsourcing puede ayudar:
z Proveyendo experiencia técnica y de gerencia
sin el riesgo y costos de una contratación
directa
z No teniendo que hacer un aumento de personal
por poco tiempo
{ Sin embargo, la falta de control y el poco
compromiso son aspectos negativos.
{ Seleccione recursos que provean una
transferencia de conocimiento para el personal
existente. No confíe mucho en un sólo recurso en
especial.
Proyectos de TI
15
8. Ambiente de trabajo inadecuado
{ La falta de equipos adecuados puede ir en
detrimento de un proyecto:
z Personal insatisfecho es muy poco productivo
z Imposibilidad de cumplir sus tareas
{ Provea espacio de oficina tranquilo

z Cada organización debe determinar su
ambiente de trabajo óptimo con base en sus
propias necesidades
Proyectos de TI
9. Personal “atado” a una

tecnología obsoleta
{ Si el personal está muy atado a lo viejo nunca

verá los beneficios de progresar.
{ Las tecnologías de punta son la base para el
desarrollo de sistemas progresivos que son la
base de los avances de hoy.
{ Los Gerentes deben caminar por una línea muy
fina entre la adopción de nuevas tecnologías y
el riesgo involucrado en su adaptación.
Proyectos de TI
16
10. Carencia de compromiso a
largo plazo
{ Alta Gerencia
z Debe involucrarse activamente haciendo
revisiones periódicas con el Gerente de
Proyecto
z Carencia de compromiso de la Alta
Gerencia:
● carencia de recursos adecuados ($, gente,
equipos,…)
● carencia de visibilidad con el personal
{ Personal
z Alta rotación de personal
z Baja moral
Proyectos de TI
Agenda
{ Metodología
{ Herramientas
{ Conclusiones
{ Bibliografía
Proyectos de TI
17
Resultados y
preocupación
Plazo: una línea o un límite que no debe ser sobrepasado
significado original - una línea dibujada alrededor de una prisión

militar más allá de la cual disparaban a matar a los prisioneros
35
Resultados de un Proyecto
Objetivos excedidos Objetivos ideales
Todos los objetivos cumplidos Objetivos planeados
Objetivos clave cumplidos
Algunos objetivos cumplidos
Ningún objetivo cumplido
Se obtuvieron valores
negativos
Proyectos de TI
18
Cambio aceptable de los
resultados en el tiempo
Fecha de
implementación del
Objetivos excedidos proyecto
Todos los objetivos cumplidos
Objetivos clave cumplidos
Algunos objetivos cumplidos
Ningún objetivo cumplido
Se obtuvieron valores Umbral de

fracaso
negativos
Tiempo
Proyectos de TI
Preocupación en un Proyecto
Optimismo Preocupación PÁNICO!!!! Asúmalo

Nivel de preocupación
desinformado vaga
Tiempo
Semana 1 Semana 16
(Plazo final)
Proyectos de TI
19
Fases de preocupación
{ Fase de Optimismo desinformado
z Período de tiempo al principio del proyecto cuando la
preocupación y el estrés son bajos.
{ Fase Preocupación vaga
z Fase de un proyecto cuando la preocupación comienza
a aumentar.
{ Fase de PÁNICO!!!!
z Fase de preocupación cuando el Gerente de Proyecto
se da cuenta que debe realizar un esfuerzo enorme
para cumplir con las actividades.
{ Asúmalo (con o sin mueca de dolor)
z Fase de un proyecto cuando el Gerente de Proyecto
tiene que aceptar el resultado, que normalmente no
es muy agradable.
Proyectos de TI
Detección de
problemas
40
20
Detección de problemas en
un proyecto
D
I Indicadores de Síntomas
S Alerta
T Apuntan a
R
A
Problemas del proyecto
C Mitigue estos riesgos
T Llevan a
O
R
Fuentes de problemas Adminístrelas para
E Gerente de
cambiar el resultado
S
Proyecto
TIEMPO
Proyectos de TI
Indicadores de Síntomas
o Actúan como alertas para riesgos que se han
materializado y para problemas en un proyecto.
o El Gerente de Proyecto debe decidir si los
síntomas son suficientes para autorizar
corrección al proyecto o definir una
recuperación parcial o total.
o Ejemplos:
o No cumplir plazos (o no tenerlos)
o Requerimientos que cambian
o Decisiones de negocio que nunca se toman
o Finalización del proyecto atascada en el 90%
o Ningún reporte de problemas
o Problemas interpersonales
o Demasiados problemas de calidad
Proyectos de TI
21
Problemas del proyecto
o Es una lista estándar de problemas del proyecto
que pueden impactar las iniciativas del
proyecto.
o Sirve como lista de chequeo para el proceso de
evaluación de riesgos que precede el
lanzamiento de un proyecto.
o No todos se materializan, así que un síntoma es
el que muestra que el problema va a ocurrir.
o Es necesario administrarlos y controlarlos
continuamente.
Proyectos de TI
Categorías de problemas
Categoría Problema potencial
1. Equipo de proyecto 1. Falta de entrenamiento
2. Requerimientos 2. Falta de claridad,
ambigüedad
3. Planeación 3. Detalles insuficientes
4. Tecnología 4. Tecnología nueva
5. Expectativas 5. Muy altas o irreales
6. Presupuesto 6. Falta de asignación
7. Entrenamiento de 7. No suficiente
usuarios
Proyectos de TI
22
Fuentes de problemas
o Los problemas se pueden remontar a estas
causas comunes.
o Es necesario tratarlas cuando los síntomas
muestran que están ocurriendo problemas en el
proyecto.
o Un catálogo de fuentes también provee una
entrada a la identificación de riesgos y a su
evaluación a través de una lista de chequeo.
o Ejemplos:
o Falta de liderazgo
o Comunicaciones pobres
o Falta de claridad
o Política
o Demasiado optimismo
o Ignorancia/hábito
o Suposiciones incorrectas
Proyectos de TI
Fuentes de problema por

categoría
Categoría Causa común del problema
1. Equipo de proyecto 1. Desalineación entre los
objetivos personales y las
necesidades del proyecto
2. Requerimientos 2. Traducción inapropiada de los
requerimientos deseados con
lo que realmente se está
construyendo
3. Planeación 3. Planeación sin validación
4. Tecnología 4. Problemas de integración
5. Expectativas 5. Sin ninguna justificación
6. Presupuesto 6. Tratar de ajustarse a un
número asignado sin
justificación
7. Entrenamiento de 7. Desalineación entre las
usuarios habilidades existentes y las
que se requieren
Proyectos de TI
23
Distractores
o Hay ciertos comportamientos o eventos que
distraen o esconden el hecho que un proyecto
está teniendo problemas. Esta es la razón por la
cual muchos proyectos que están en problemas
no se diagnostican apropiadamente y terminan
llevando a resultados con pocos de los
beneficios proyectados.
Proyectos de TI
Lista de distractores comunes

{ Negación de la realidad
{ Miedo de ser culpado/a
{ Miedo de parecer estúpido/a
{ Pereza
{ Incentivos negativos
{ No deseo de admitir estar equivocado
{ “Eso es problema de ellos”
{ Síndrome de “Eso no se hizo aquí”
Proyectos de TI
24
Marco de referencia
49
Procesos
Reconocimiento
Evaluación
de síntomas
Planeación de la Ejecución de la
recuperación recuperación
Revisión
pos-recuperación
Proyectos de TI
25
Procesos
1. Reconocimiento de síntomas
2. Evaluación
3. Planeación de la recuperación
4. Ejecución de la recuperación
5. Revisión pos-recuperación
Proyectos de TI
Procesos
2. Evaluación
Proyectos de TI
26
Problemas de definición?
o Es esto un problema o es ……?
o Una suposición
o Una situación problemática
o Problema
o Riesgo
Proyectos de TI
Problemas de definición?
o Es esto un problema o es ……?
o Una suposición debe verificarse
o Una situación problemática debe

investigarse
o Problema debe ser tratado
o Riesgo debe eliminarse o reducirse
Proyectos de TI
27
Gerencia de Proyectos
{ Diferentes investigaciones demuestran que la
Gerencia de Proyectos es clave el éxito de un
proyecto.
z Enfoque proactivo de la Gerencia de
Proyectos:
● Planeación del proyecto
● Gerencia de riesgos
● Seguimiento y control del proyecto
● Administración de requerimientos
● Comunicaciones
Proyectos de TI
Administración de crisis vs.

Administración Proactiva
{ Qué es proactivo: “Actuar en anticipación a
problemas, necesidades o cambios futuros”
(Definición diccionario)
z Los proyectos en crisis consumen mucho
tiempo apagando incendios:
● El equipo del proyecto sólo tiene tiempo para
reaccionar y no para mejorar.
● Acuérdense que los bomberos también se
“queman”.
z Identificación temprana de los problemas:
● Alivia malas decisiones tomadas durante la
crisis
● Promueve las decisiones basadas en hechos.
Proyectos de TI
28
Proyectos de TI
Procesos
2. Evaluación
Proyectos de TI
29
Lista de chequeo desempeño
programático *
1 SOW
1a The SOW was properly defined Explain No Yes
1b The SOW is within our capabilities Explain No Yes
1c The SOW was properly interpreted Explain No Yes
1d The SOW was properly negotiated Explain No Yes
1e The SOW is properly monitored Explain No Yes
1f The SOW is being properly performed Explain No Yes
1g Explain No Yes
2 SPECIFICATION
2a The Specification was properly defined Explain No Yes
2b The Specification is within our capabilities Explain No Yes
2c The Specification was properly interpreted Explain No Yes
2d The Specification was properly negotiated Explain No Yes
2e The Specification was properly monitored Explain No Yes
2f The Specification was properly performed Explain No Yes
2g Explain No Yes
4 ORGANIZATION
4a The numbers of personnel assigned to each task are Explain No Yes
correct
4b The mix of personnel to accomplish the task is Explain No Yes
appropriate
4c The personnel are acting and reacting as a team Explain No Yes
4d Explain No Yes
4e Explain No Yes
4f Explain No Yes
4g Explain No Yes
*Blueprint for project Recovery, Robert B. Cagle, AMACOM, pág. 11

Proyectos de TI
Lista de chequeo desempeño

técnico *
51 ARCHITECTURE
51a All Critical Success Factors (CSFs) such as MTTR,
MTBF, etc., have been documented and understood Explain No Yes
51b All modules/subsystems are well defined Explain No Yes

51c All key functions, such as time, length, weight,
performance requirements, and interfaces, etc., listed
in the requirements, are appropriately covered Explain No Yes
51d All major elements (physical and data) are described

and justified Explain No Yes
51e All key aspects of user interfaces are well defined
Explain No Yes
51f The Architecture hangs together conceptually Explain No Yes
51g Explain No Yes
52 DESIGN
52a The design process is correct and traceable to
enterprise, customer, and standard processes. Explain No Yes
52b The design is correct and traceable to the
requirements Explain No Yes
52c The design is efficient Explain No Yes
52d The design adequately addresses issues that were
identified and deferred to design at the architectural Explain No Yes
level
52e The design is partitioned into manageable segments
Explain No Yes
52f The design accounts for supportability, Life Cycle Cost
(LCC), total cost of ownership, and future expansions Explain No Yes
52g Technical Performance Measures (TPMs) such as

data retrieval time, weight, error rate, etc., have been Explain No Yes
defined and accommodated
*Blueprint for project Recovery, Robert B. Cagle, AMACOM, pág. 57

Proyectos de TI
30
Evaluación
{ Se necesita rescatar un proyecto cuando:
z Los hitos se mantienen cambiando.
z Está fuera de control y es imposible
establecer qué progreso se ha hecho.
z Se han excedido los límites del presupuesto y
los estimativos de costos cambian cada rato.
z Los miembros del equipo están trabajando
más del 100% (típicamente más de 60 horas
a la semana).
z El producto o el servicio están llenos de
defectos.
z Está al borde de ser cancelado.
Proyectos de TI
Evaluación
{ Los proyectos no se salen de control “así como
así”. Siempre hay signos de alerta tempranos
que nos indican que un proyecto está en
problemas.
{ Identificar un proyecto en crisis (o un que
potencialmente puede llegar a estar en crisis)
consiste en reconocer los signos de alerta
temprana que preceden al fracaso de un
proyecto.
Proyectos de TI
31
Estrategias para recuperar un
proyecto descarrilado
{ Hay varias opciones para recuperar un proyecto
descarrilado:
z Reducir el alcance del producto de modo que se
pueda acabar en el plazo establecido y dentro del
presupuesto previsto.
z Aumentar la productividad implementando
mejoras continuas de corto plazo.
z Desplazar el cronograma, aumentar el
presupuesto y continuar con el alcance original.
z Proceder con el control de los problemas,
incluyendo cancelar el proyecto anticipadamente.
z Implementar una combinación de las opciones
anteriores.
Proyectos de TI
Estrategias para recuperar un

proyecto descarrilado
{ Se debe comenzar el plan de recuperación
cuando cada todo el mundo está listo.
{ Los stakeholders clave, tales como el cliente, la
Alta Gerencia y el equipo de proyecto, deben
estar comprometidos y listos para realizar las
acciones requeridas para recuperar el proyecto
descarrilado.
z Si se lanza la recuperación demasiado
pronto, los stakeholders no creerán que es
necesario.
z Si se lanza la recuperación demasiado tarde,
las consecuencias serán más severas.
Proyectos de TI
32
Solicitud de requerimientos
No se le olvide que lo más importante

para mi es lo amplio de la cabina. El
resto hágalo como quiera. Me
entendió???
Proyectos de TI
Creo que le ”cogió” la idea, o no?
Proyectos de TI
33
Solicitud de requerimientos
“Yo sé que usted cree que entendió lo que

usted cree que yo dije, pero yo no estoy
seguro que usted se da cuenta que lo que
oyó no es lo que yo quería decir.”
Proyectos de TI
Marco de referencia
2. Evaluación
Proyectos de TI
34
Planeación
{ Como la ejecución debe ser perfecta, la
planeación detallada es clave.
{ Está en juego no sólo el proyecto sino también
el equipo de proyecto, el gerente de proyecto y
el cliente o usuario final que deben estar
motivados y comprometidos.
{ Si es necesario se debe asignar un nuevo
gerente de proyecto para la recuperación.
{ A continuación vamos a detallar las categorías
principales de la recuperación y el mapa de
recuperación que es lo que comúnmente es el
plan de proyecto en nuestra metodología de
gerencia de proyectos.
Proyectos de TI
Categorías de recuperación
{ Hay tres categorías principales de recuperación:
z Personal
z Procesos y herramientas
z Producto
{ El equipo de evaluación y recuperación debe

evaluar estas tres categorías para cada uno de
los siguientes stakeholders:
z Patrocinador del proyecto
z Cliente/usuario
z Gerente de Proyecto
z Personal Técnico
z Personal de aseguramiento de la calidad
z Personal de apoyo y de mantenimiento
Proyectos de TI
35
Personal
{ Necesitamos centrarnos en arreglar lo
concerniente a la gente si deseamos arreglar el
proyecto. Esto incluye sustituir al gerente de
proyecto en caso que se considere necesario.
{ Necesitamos arreglar los problemas de personal
y de liderazgo identificados en la fase de
evaluación. Detectar estas situaciones
problemáticas no es ni obvio ni claro. Sin
embargo, roles y responsabilidades confusos
casi siempre llevan a problemas de liderazgo.
{ Necesitamos desarrollar planes que se enfoquen
en el esfuerzo y el tiempo de la gente.
Proyectos de TI
Personal
{ Algunos de los puntos a considerar son:
z Restaurar la moral del equipo.
z Resolver los problemas de personal.
z Determinar si se necesita agregar más

recursos.
z Administrar el tiempo de la gente con
eficacia.
Proyectos de TI
36
Procesos y herramientas
{ En la fase de evaluación normalmente
identificamos varios procesos de la gerencia de
proyecto que no se están cumpliendo.
Necesitamos arreglar estos procesos ya que es
más rentable ocuparse de la fuente del
problema que de sus síntomas.
Proyectos de TI
Procesos y herramientas
{ Algunos puntos a considerar son:
z Hacer reingeniería a aquellos procesos que no se
están cumpliendo.
z Implementar los procesos críticos que no existen.
z Definir un cronograma detallado basado en hitos
de corto plazo.
z Cerciorarse de hacer seguimiento al progreso del
proyecto de una manera constante.
z Redefinir la línea de base del proyecto con base
en el avance real.
z Cerciorarse de implementar un plan completo de
gerencia de riesgos.
Proyectos de TI
37
Producto
{ Como parte del proceso de la recuperación, se
necesita recuperar algunos de los entregables
del proyecto.
{ La mayoría de las veces, el problema está en
los requerimientos. Se debe evaluar la
estabilidad de los requerimientos y la buena
voluntad de los stakeholders del proyecto para
congelarlos.
{ Es crítico determinar los requisitos mínimos.
Proyectos de TI
Producto
{ Algunos puntos a considerar incluyen:
z Se tiene un conjunto de requerimientos bien

definidos?
z Son estables los requerimientos del
producto/servicio?
z Se necesita/puede disminuir el alcance del
producto/servicio?
z Se puede reducir el número de defectos y
mantenerlo en un bajo nivel?
Proyectos de TI
38
Marco de referencia
2. Evaluación
Proyectos de TI
Ejecución de la recuperación
{ Se necesita ejecutar la recuperación del
proyecto simultáneamente con la revisión de los
flujos de trabajo.
{ Los factores críticos de éxito para ejecutar la
recuperación son:
z compromiso
z habilidades
z capacidades
z entendimiento del verdadero estado del proyecto
z revisión constante el estado
z foco
z priorización de amenazas y oportunidades
z Manejo de la política
Proyectos de TI
39
Ejecución de la recuperación
{ Los objetivos principales de esta fase son:
z Ejecutar el plan de recuperación para encarrilar el
proyecto
z Hacer pronósticos exactos de la terminación del
proyecto.
{ El desarrollo del plan de recuperación debe
centrarse en la gente, los procesos y los
productos.
{ La gente es la clave de la recuperación.
{ El equipo de la evaluación y de la recuperación
necesita implementar un sistema de
información para hacer el seguimiento y el
control de los paquetes del trabajo del WBS.
Proyectos de TI
Mapa de recuperación
del proyecto
“Cuando la gente está altamente motivada, es fácil lograr lo imposible.
Cuando no lo está, es imposible lograr lo fácil.”
BOB COLLINGS
80
40
Mapa de Recuperación
1. Construir un Grupo de Recuperación
2. Analizar las Situaciones Problemáticas
3. Determinar el Problema
4. Arreglar el Problema
5. Monitorear el Proyecto
6. Comenzar de nuevo, si es necesario
Proyectos de TI
Mapa de Recuperación :
Construir un grupo de recuperación
{ Grupo de recuperación = equipo de personas
comisionadas para determinar y arreglar los
problemas
z Mantenga el grupo de recuperación pequeño
● El tamaño puede ser de una o más personas
dependiendo:
z Del alcance del proyecto y de los problemas
z De los conocimientos y de la experiencia de los
miembros del equipo
z Seleccione los miembros adecuados que
sean críticos para el éxito del proyecto
● Miembros inadecuados pueden causar más
problemas en el proyecto
z Dé la autoridad para realizar los cambios
necesarios
Proyectos de TI
41
Determinar qué salió mal?
{ Cada organización es única. Sin embargo,
diferentes investigaciones muestran que cada
proyecto fracasado de una organización sigue
pasos similares.
{ Busque los problemas/las situaciones
problemáticas “reales”
z “Busque debajo del tapete”
{ Analice los errores
z No busque culpables!!!
{ Aplique las lecciones aprendidas.
Proyectos de TI
Qué se puede hacer para volver al curso?
1. Disminuir/Limitar el alcance del proyecto
2. Utilizar un enfoque iterativo
3. Revisar su plan
4. Entender sus requerimientos
5. Mejorar el entrenamiento
6. Conseguir que el personal de proyecto, los
usuarios y la Alta Gerencia “compren la idea”
7. Capturar/Implementar los procesos de sus
proyectos
Proyectos de TI
42
1. Disminuir/Limitar el alcance del proyecto
{ El éxito de los proyectos es inversamente
proporcional al tamaño (The Standish Group,
Estudio CHAOS 1998)
z > $750,000 = 55% tasa de éxito
z $1M - $2M = 18% tasa de éxito
z $5M - $10M = 7% tasa de éxito

Éxito de los proyectos basado en
60 el tamaño
50
40
30
20
10
0
V Jornada de Gerencia de > US$750,000 US$1M-US$2M US$5M-
85
US$10M
Proyectos de TI
2. Utilizar un enfoque iterativo
{ Descomponga el proyecto en paquetes de
trabajo que se puedan manejar.
{ El replanear un proyecto puede tener un gran
impacto positivo.
{ Utilice una metodología incremental.
Proyectos de TI
43
3. Revisar su plan
{ La planeación es un proceso iterativo.
{ Los cronogramas se deben actualizar
periódicamente para reflejar el estado actual
del proyecto.
{ El plan debe involucrar el equipo de proyecto.
El equipo debe adoptar el plan como suyo.
{ Tenga siempre planes de contingencia que
tengan en cuenta los riesgos potenciales.
{ NUNCA abandone el plan cuando lo empiecen a
presionar, es en este momento cuando usted
más lo necesita para mantener el curso.
z No deje que su proyecto caiga en el modo “desarrolle
y corrija”
Proyectos de TI
4. Entender sus requerimientos
{ Entienda totalmente cada requerimiento
{ Asegúrese que el equipo de proyecto y los

usuarios están de acuerdo en el
entendimiento de cada requerimiento
{ Controle los requerimientos
z Administre los cambios a los requerimientos
z Obtenga aprobación del Comité de Control de
Cambios para la adición de requerimientos
{ Comience por documentar los requerimientos,
si no lo ha hecho.
Proyectos de TI
44
5. Mejorar el entrenamiento
{ “Nosotros somos conocidos por nuestro
entrenamiento en el trabajo (on-the-job
training).”
{ Siempre hay campo para más entrenamiento.
{ Entrene a sus ingenieros, entrene a sus

gerentes, entrene a sus usuarios!!!
Proyectos de TI
6. Conseguir que el personal de proyecto, los
usuarios y la Alta Gerencia “compren la idea”
{ Todos los stakeholders del proyecto deben:
Caminar por el mismo camino

{ En las fases críticas del proyecto usted
necesita que todos estén leyendo la misma
partitura.
{ Como Gerente de Proyecto usted es el que
ayuda a que todo esto suceda.
Proyectos de TI
45
Mapa de Recuperación:
7. Capturar/Implementar los procesos de sus
proyectos
{ No hay fórmulas mágicas
z No se pierde peso sin hacer ejercicio o con

dietas mágicas
{ El cambio en la cultura de proyectos/ de la
organización son claves.
{ Deje que los ingenieros sean ingenieros y que
los administradores sean administradores
dándoles las herramientas que ellos necesitan
{ Comience con lo que usted ya hace bien y
hágalo mejor.
Proyectos de TI
Marco de referencia
2. Evaluación
Proyectos de TI
46
Respiro
{ Luego de la recuperación del proyecto (ojalá
totalmente exitosa) es necesario revisar si la
evaluación nos dio todos los elementos para
realizar la recuperación.
{ Revise que herramientas le sirvieron y cuáles
no.
{ Uno de los resultados más útiles para otros
proyectos es la documentación de las lecciones
aprendidas.
Proyectos de TI
Agenda
{ Metodología
{ Herramientas
{ Conclusiones
{ Bibliografía
Proyectos de TI
47
Algunas herramientas
{ Libro de proyecto
{ Semáforo
{ Reporte de estado
{ Identificación de riesgos
{ Registro de situaciones problemáticas
{ Matriz de comunicaciones
{ Lecciones aprendidas
“EL PROBLEMA de no hacer nada es que uno no sabe cuando terminó. “

Benjamin Franklin (1706-1790)
Proyectos de TI
Libro de proyecto
{ Las buenas prácticas de la Gerencia de
Proyectos dicen que se debe tener y
mantener un libro de proyecto.
{ El libro de proyecto no es sólo una pasta
argollada en el escritorio del gerente de
proyecto. Es una serie de archivos (físicos y
electrónicos) que permiten un acceso rápido
y fácil a todos los documentos de definición y
del estado del proyecto.
Proyectos de TI
48
Libro de proyecto
{ Un libro de proyecto típicamente contiene las siguientes
secciones:
Acta de Proyecto Formatos de acta de los
entregables
Planes de Proyecto Documentos de
implementación
Acuerdos externos Reportes de estado
Hojas de tiempo Gerencia del riesgo
Definición de Gerencia de situaciones
requerimientos problemáticas
Documentos de análisis Control de cambios
Documentos de diseño Planes, casos y resultados
de Pruebas
Proyectos de TI
Semáforo
Estado acumulado general a: Febrero 27 de 2007 Cronograma aplicado Ver 2.0
Jue Vie Lun Mar Mie Jue Vie Lun Mar Mie Jue Vie Lun Mar Mie Jue Vie
15 16 19 20 21 22 23 26 27 28 01 02 05 06 07 08 09
Requerimientos
Contratistas
Cronograma
Alcance
Pruebas
Contratistas
Cronograma
Alcance
Documentación
Contratistas
Cronograma
Alcance
Plan de Capacitación
Contratistas
Cronograma
Alcance
Planes de recuperación
Presupuesto
Cronograma
Alcance
Proyectos de TI
49
Reporte de estado
Estado del Proyecto Piramide – XXX Ltda..
Marzo 2 - 2007
Información del Proyecto
Calificación Gerente de Proyecto: Andrés Felipe Gómez
Cuadro de
Sponsor del Proyecto: E. D. XXX Ltda..
control
Fecha de Inicio fase: 15/02/2007
AMARILLO
Fase del ciclo de vida: Implementación Fecha de Finalización fase: 09/03/2007
3 Riesgos más importantes
Clasi ID Enunciado Riesgo Mitigación Impacto Prob. Exposi.
Definición prioridad manuales para
1 01 Retraso en entrega manuales capacitación (Manual de operación en Crítico 75% Rojo
caso de falla)
Seguimiento diario actividades
2 02 Incumplimiento contratistas Significante 50% Amarillo
contratistas
Asegurarse que el servidor de back up
3 03 Falla servidores principales Significante 20% Verde
está operando correctamente
Resumen Estado
Se
Categoría requiere
Clasifi. Comentarios
acción
Gerencia?
Alcance Verde El alcance del proyecto se mantiene igual al replanteado.
Cronograma Verde La entrada en producción controlada comienza el lunes 5 de marzo
Presupuesto Amarillo Todavía no se sabe si se necesita un consultor especializado
Contratistas Amarillo Sólo quedan algunos equipos por probar
Proyectos de TI
Identificación de Riesgos
ia
ad
nc
ilid
ue
Riesgo Acción
cto
ec
ab
pa
ns
b
Pro
Im
Co
Red de XXX Ltda. con problemas de desempeño en

determinadas horas del día. 67% 33% 0.220 Monitorear tráfico de red
Que no se solucione el problema de las cámaras con la luz. 33% 75% 0.250 Cambiar a cámaras fotodinámicas
Que se quemé una tarjeta controladora de periféricos 10% 50% 0.050 Tener tarjetas en stock
Que se dañe la talanquera 10% 33% 0.033 Monitorear al proveedor

Que se dañe una de las tarjetas que comunican las cámaras con
el portal 10% 50% 0.050 Tener tarjetas en stock
Asegurarse que XXX Ltda. ejecute
Actualización del maestro de materiales 50% 100% 0.500 la tarea
Creación de usuarios en productivo 10% 75% 0.075 la tarea
Configuración productivo de personas que reciben correos 10% 50% 0.050 la tarea
Autorizaciones en SAP 10% 33% 0.033 la tarea

Proyectos de TI
50
Registro de situaciones
problemáticas
Prioridad: Para el proyecto
Fecha de
Número Situación Problemática Descripción Asignado a vencimiento Estado
La interfaz con Oracle Financials no Juan Carlos
1 Interfaz Oracle Financials funciona correctamente Ramírez 7-Mar-07 Rojo
2
3
4
5
6
7
8
Prioridad: Alta
Fecha de
Número Situación Problemática Descripción Asignado a vencimiento Estado
La casa matriz no ha enviado los

1 Manuales Equipos RFID manuales actualizados de los equipos Juan Rodríguez 9-Mar-07 Amarillo
2
3
4
5
6
7
8

Proyectos de TI
Matriz de comunicaciones
MATRIZ DE COMUNICACIONES
PROYECTO: XXXXXXX LTDA.
Fecha: Marzo 2 de 2007
Comunicaciones Responsable Interesados (Stakeholders)
Medio Frecuencia
Proyecto GPT
Proyecto GPT
Gerente de
R = Reunión D = diaria
Equipo de
Gerente de
E = E-mail S = semanal Equipo de
Proyecto
I = Informe M = mensual Comité Proyecto Sponsor Proyecto Usuarios Contratistas
XXXXXXX
W = Web (intranet) C = según cronograma XXXXXX LTDA.
LTDA.
Reuniones
Seguimiento con el equipo X X R/S R/S
Comité Proyecto X R/C R/C R/C
Desarrollo del cronograma de recuperación I/C R/C R/C

X X
Desarrollo de listado de riesgos X R/C R/C I/C
Documentos de seguimiento X I/C
Revisión de contenido requerimientos X X R/C R/C R/C I/C
Revisiones de calidad X X R/C R/C R/C I/C
Cierre de la recuperación X X R/C R/C R/C
Reportes / Informes
Agenda de reuniones X E E E E E E
Conclusiones de las reuniones X E E E E E E
Progreso del Proyecto X X E R R R
Estado detallado X X R R R
Reporte de diferencias o variaciones X R R R

Proyectos de TI
51
Lecciones aprendidas
LECCIONES APRENDIDAS
Proyecto: XXX Ltda.

Fecha: Marzo 2 de 2007
No. Lecciones Aprendidas Si Impacto Observaciones

Bajo ---------------- Alto
1 2 3 4 5
1. Fallas en satisfacer las necesidades o requerimientos de los X Faltó involucrar algunos
usuarios usuarios de producción
2. Definición de objetivos incompleta o inadecuada X Se gastó muy poco tiempo
en las entrevistas iniciales
3. El proyecto se desvió de los objetivos originales X No se utilizó un sistema de
control de cambios
4 Definición inadecuada del proyecto X La Alta gerencia sólo se
involucró al ver el proyecto
en problemas
5 Riesgo muy alto X No se hizo suficiente
monitoreo y control a los
riesgos identificados y ni a
sus planes de respuesta
6 Tecnología no probada X X
• Uso del marco de referencia transaccional. Nadie del equipo
conocía la tecnología y la capacitación fue insuficiente. Tuvimos
que acudir a consultores externos. Faltó capacitación
7 Demasiados proyectos simultáneos X X
• El equipo estaba trabajando en la versión de Enero
concurrentemente con la implantación, lo cual causó sobrecarga
en los programadores en algunos casos y pudo contribuir a los Coordinar mejor los
retrasos en nuestra entrega. proyectos
• Se requirió balancear la carga de trabajo de algunos
miembros del equipo para reducir su presión y estrés.

Proyectos de TI
Agenda
{ Metodología
{ Herramientas
{ Conclusiones
{ Bibliografía

Proyectos de TI
52
Cosas para aprender de Noé
• No se le olvide el arca.
• Acuérdese que todos estamos en el mismo
bote.
• Planee por adelantado. Cuando Noé
construyó el arca no estaba lloviendo.
• Manténgase en forma. Cuando usted tiene
600 años alguien le puede pedir que haga
algo especial.
• No le ponga atención a las críticas; sólo haga
el trabajo que hay que hacer.
• Construya su futuro en tierra firme.

Proyectos de TI
Cosas para aprender de Noé

• Por razones de seguridad; siempre viaje en
pares.
• La velocidad no siempre es una ventaja. Las
culebras y los leopardos iban ambos a
bordo.
• Si se estresa, flote un rato.
• Acuérdese, el arca fue construida por
aficionados; el TITANIC por profesionales.
• No importa la tormenta, si usted está con
Dios siempre hay un arco iris esperándolo.

Proyectos de TI
53
Conclusiones
{ Revise si realmente el proyecto necesita una
recuperación o si se puede encarrilar definiendo algunas
acciones correctivas menores.
{ Los stakeholders son la clave para la recuperación dado
que se necesita su compromiso y colaboración.
{ Con una detección temprana de síntomas y siguiendo la
metodología la mayoría de proyectos en problemas
pueden controlarse.
{ El fracaso no tiene que ser el destino de un proyecto en
problemas.
{ Y todo esto para qué? Para garantizar el

éxito de sus proyectos y no tener que
recuperarlos de una crisis.
Proyectos de TI
Agenda
{ Metodología
{ Herramientas
{ Conclusiones
{ Bibliografía

Proyectos de TI
54
Bibliografía
1. Blueprint for Project Recovery, Cagle, R., AMACOM, 2003
2. Project Rescue, Purba, S. and Zucchero, J.J., MC Graw
Hill, 2004
3. Turning Derailed IT Projects Around, RCG Information
Technology, Inc., 2003
4. Salvage a derailed project with these assessment and
recovery strategies, Sifri, G., TechRepublic, 2005
5. Validate whether a project is really in trouble before
applying project rescue techniques, TechRepublic, 2005
6. No-Nonsense Advice for Successful Projects, Neal
Whitten, Management Concepts Inc., 2005
7. Successful IT Project Delivery, David Yardley, Pearson
Education Ltd., 2002
8. Identifying and Rescuing Runaway Projects, The Casey
Group, 2003
9. Project Success: A Cultural Framework, Korin Kendra,
Laura J. Taplin, Project Management Journal, April 2004
10. Beyond the Nightmare on Project X, Deb Jacobs, Project
Engineering Technologies, 2006

Proyectos de TI
Bibliografía
11. Project Success: Looking outside traditional project
metrics, Brian K. Willard, Roosvelt University, August
2005
12. CHAOS: A Recipe for Success, The Standish Group
International INC., 1999
13. Why do IT (Information Technology) projects fail? (and
how to avoid such failures), Hitech Dimensions Inc, 2002
14. PMI® Standard, A Guide to the Project Management
Body of Knowledge PMBOK ®, PMI ® 3rd Edition, 2004
15. Fundamentals of Project Management, Lewis, J. P.,
AMACOM, 2002
16. Information Technology Project Management, 4th
Edition, Schwalbe, K., Course Technology, Thompson
Learning Inc., 2005
17. Project Management – Planning and Control Techniques,
Third Edition, Burke, R., Wiley, 2005
18. Fundamentals of Technology Project Management,
Garton, C. and McCulloch E., MC Press, 2006
Proyectos de TI
55
ALGUNA
ALGUNAPREGUNTA???
PREGUNTA???
Andrés Felipe Gómez, IT CPM, PMP

Gerente General Alex Oberst
Gómez Project and Training
[email protected]

Proyectos de TI

Proyectos de TI
56

Recuperación de Proyectos en Crisis

Cargado por

Copyright:

Formatos disponibles

Recuperación de Proyectos en Crisis

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Recuperación de Proyectos en Crisis

Cargado por

Copyright:

Formatos disponibles

Recuperación de

Ah, y además usted tuvo una relación cordial y

Por qué tanto silencio???? No es para tanto!!!!

Además es fácil olvidarse que muchos proyectos

Aunque probablemente no hay un proyecto

El "éxito" puede significar lograr renegociar el

z carencia del planeación

z inadecuada atención al plan de trabajo

z mala gerencia del control de cambios al

2004 29% 53% 18%

2002 28% 33% 39%

2000 28% 49% 23%

1998 26% 46% 28%

1996 27% 33% 40%

1994 16% 53% 31%

Estadísticas del Standish Group

Razones para el éxito de un

1. Efectiva planeación del proyecto 7. Efectivo desarrollo de procesos

“El que no haya cometido un error es que

4. Falta de entrenamiento/acompañamiento para los

6. Alta rotación del personal del proyecto

7. Uso inadecuado de recursos externos

8. Ambiente de trabajo inadecuado

9. Personal “atado” a una tecnología obsoleta

10.Carencia de compromiso a largo plazo

{ El Gerente de Proyecto debe estar GP

{ La falta de planeación o la planeación

Gerencia de Riesgos? Para qué?

6. Alta rotación del personal

Lo que ve el equipo de proyecto

7. Uso inadecuado de recursos

z Imposibilidad de cumplir sus tareas

{ Provea espacio de oficina tranquilo

9. Personal “atado” a una

{ Si el personal está muy atado a lo viejo nunca

Plazo: una línea o un límite que no debe ser sobrepasado

significado original - una línea dibujada alrededor de una prisión

Objetivos excedidos Objetivos ideales

Todos los objetivos cumplidos Objetivos planeados

Objetivos clave cumplidos

Algunos objetivos cumplidos

Ningún objetivo cumplido

Todos los objetivos cumplidos

Objetivos clave cumplidos

Algunos objetivos cumplidos

Ningún objetivo cumplido

Se obtuvieron valores Umbral de

Optimismo Preocupación PÁNICO!!!! Asúmalo

Fuentes de problema por

Lista de distractores comunes

o Una situación problemática

o Una suposición debe verificarse

o Una situación problemática debe

o Problema debe ser tratado

o Riesgo debe eliminarse o reducirse

Administración de crisis vs.

*Blueprint for project Recovery, Robert B. Cagle, AMACOM, pág. 11

Lista de chequeo desempeño

51b All modules/subsystems are well defined Explain No Yes