Capítulo Lima, Perú

Congreso Internacional de
Gerencia de Proyectos PMI – Mendoza 2009

Recuperación de Proyectos con Problemas

Alfonso Núñez, MBA, PMP

Presidente del Capítulo del PMI Lima,
Perú
 Agenda
Introducción
1. Síntomas de un proyecto en problemas.
2. Causas de un proyecto en problemas.
3. Procesos de recuperación.
3.1 Identificación.
3.2 Diagnóstico.
3.3 Inicio de la recuperación.
3.4 Plan de la recuperación.
3.5 Ejecución y control.
3.6 Cierre de la recuperación.
4. Lecciones aprendidas.
Introducción
Introducción.

• Hace un año, de 3,874 proyectos, 1,830 (47%) concluyeron con

problemas, recuperados con problemas, o con problemas y con
fallas.

• Organizaciones que en promedio invirtieron aproximadamente US$

65 M en proyectos, por lo menos unos US$ 30 M de esa inversión
correrá el riesgo de fallar.

Troubled Projects, Project Failure or Project Recovery

Center for Business Practices 2006
Referencia: http://www.cbponline.com/ProductDetails.asp?ProductCode=1929576226

Proyecto en problemas: Es un proyecto que va camino a estar

fuera de control, o actualmente ya está fuera de control.
Introducción.

Portafolio ¿Qué pasó?

esperado

¿Qué proyectos tuvieron

problemas?

Periodos
1 2 3 4
¿Cuáles son los
efectos en la
organización?
Portafolio
real

Periodos
1 2 3 4
1. Síntomas de un
proyecto en
problemas
1. Síntomas de un proyecto en problemas.
Reconocer cuando un proyecto esta en problemas no es una tarea fácil y aún si el project manager no
esta conciente del rumbo que está tomando su proyecto. Para ese fin es importante reconocer cuales
son los síntomas de un proyecto en problemas.

• Personal no tiene claro

el alcance del proyecto. ?
¿?
• No se conocen los entregables del proyecto.

• No hay un control de cambios de alcance

efectivo.

• Cronograma desviado significativamente. AC PV

• No se cumplen los entregables en las
EV
fechas programadas.

• Recursos con sobrecarga de trabajo o

esfuerzos mal distribuidos (horas
hombre/periodo).
1. Síntomas de un proyecto en problemas.

• Los costos del proyecto están desviados

AC PV
significativamente (Ejemplo 20% o el límite
definido para el proyecto). EV

• Alto número de errores en los entregables.

• El personal siente que el proyecto no

tiene un objetivo claro.

• No hay ejecutivos que respalden

significativamente al proyecto.

• Cambios continuos en los proyectos sin un

control formal e integrado de los mismos
(costos, tiempos, calidad y alcance).
1. Síntomas de un proyecto en problemas.
•Poca comunicación y/o pocos canales de
comunicación.
• No se maneja documentación escrita
ni centralizada.

• Moral baja del personal.

• No se sabe quien es responsable de los entregables.

• Existen conflictos intensivos entre los
recursos.

• Hay una sobre confianza en que todo

saldrá bien por lo que no se identifica
riesgos ni se establece acciones
específicas para minimizarlos.

? • No se sabe cuantos contratos están

involucrados en el proyecto ni cuales son
los compromisos de cada uno de ellos.
Ejemplo de un proyecto en problemas en base al tiempo y costo
Valores Fecha de Corte
acumulativos

PV

AC CV < 0

SV < 0

EV

Tiempo
•Valor Planificado: PV
•Valor Ganado: EV •Variación del Cronograma: SV
•Costo Real: AC •Variación de Costos: CV
 Fecha de Corte Fecha de Corte
SPI CPI

1 1

0 0
Tiempo Tiempo

• Índice de rendimiento del Cronograma: SPI

• Índice de rendimiento del Costo: CPI
1. Síntomas de un proyecto en problemas.
Sintomas - Percentil Superior
4.90

4.90
4.70

4.70
4.50

4.50

4.20 4.20
4.30
4.10 4.10 4.10

4.00
4.10

3.90

3.70

3.50
Integración - Personal no tiene claro el alcance del proyecto 1 Integración - Cambios continuos en los proyectos sin un control formal e integrado de los mismos

Recursos Humanos - Sobre asignación de recursos Alcance - Alcance no claro

Comunicaciones - Poca comunicación y/o pocos canales de comunicación. Tiempos - Retraso continuo en la entrega de los entregables del proyecto

Tiempo y costos - Varianzas significativa en costo y cronograma (basedo en la última línea base) Calidad - Alto número de errores en los entregables

Integración - Falta de apoyo ejecutivo para el proyecto

2. Causas de un
proyecto en
problemas.
2. Causas de un Proyecto en problemas.
Síntomas
• Personal no tiene claro el
alcance del proyecto.
• No se conocen los
entregables del proyecto.
• No hay un control de
cambios de alcance
efectivo.
Causas
• Alcance no específico.
? • Alcances muy cambiantes.
• No hay línea base.
¿ • Carencia/Informalidad de
? metodología de Project
Management.

• El cronograma esta desviado

significativamente (Ejemplo 20%
o el limite definido para el • Competencias del personal
proyecto). AC
PV
no adecuadas.
• No se cumplen los
EV • Mala organización del
entregables en las fechas
programadas. trabajo.
• Los costos del proyecto están • Riesgos inesperados.
desviados significativamente (Ejemplo • No hay cultura de riesgos.
20% o el limite definido para el
• Estimaciones optimistas
proyecto).
(tiempo, costo y recurso).
 2. Causas de un Proyecto en problemas.
Síntomas Causas
• Recursos con sobrecarga
• Roles y responsabilidades no
de trabajo o esfuerzos claros
mal distribuidos (horas • Cronogramas no balanceados
hombre/periodo).

• Falta de planes de
control y aseguramiento
• Alto número de errores
en los entregables. de la calidad.

• Múltiples objetivos.
• Sponsor y/o stakeholders no
• El equipo del
involucrados.
proyecto siente que el • Falta de casos de negocios.
proyecto no tiene un • Entorno organizacional complejo.

objetivo claro. • Informalidad en los procesos de

gestión de procura.
• Restricciones contractuales.
• No hay cultura de
comunicaciones.
 2. Causas de un Proyecto en problemas.
Causas - Percentil Superior
4.60

4.60
4.50

4.50
4.40 4.40

4.40
4.30

4.30
4.20

4.20
4.10 4.10 4.10

4.10
4.00

4.00

3.90

3.80

3.70
1
Alcance - Falta de alcance específico y detallado Alcance - Cambios continuos de alcance legales y del entorno

Recursos Humanos - Carencia de compromiso del Sponsor y Stakeholders con el proyecto Recursos Humanos - Falta de experiencia/competencias del project manager y stakeholders

Falta de línea base - alcance, tiempo, costo y calidad Integración - Falta de metodología en gestión de proyectos

Riesgo - Falta de cultura de riesgos Integración - Estrategias de negocio no alineado a los objetivos del proyecto

Integración - Falta de caso de negocio Comunicaciones - Falta de cultura de comunicación

3. Procesos de
recuperación
3. Proceso de recuperación.

Identificación

Portafolio de
Proyectos
Diagnóstico

Cancelar / Inicio de la Plan de Ejecución y Cierre

Congelar Recuperación Recuperación Control

Acta de Plan del Reportes de Informes

recuperación Proyecto estado de Cierre
del proyecto
3.1 Identificación.
La identificación de proyectos en problemas se realiza en base a los síntomas que emiten los proyectos.
De acuerdo a lo visto en las páginas anteriores mostraremos como ejemplo dos criterios muy objetivos:
(1) % de Desviación del cronograma, y (2) % de Desviación del costo.
Fecha de corte
(fase tardía)
Valores
acumulativos Fecha de corte Fecha de corte
(fase temprana) (fase media)

PV % Desv. Crong =
1 - SPI

AC % Desv. Costos =
1 - CPI

EV
SV < 0

SPI = EV / PV
CPI = EV / AC
Tiempo
3.1 Identificación.
3.1.1 Identificando los proyectos en problemas dentro de un portafolio.

Para identificar proyectos en problemas, debemos de aplicar periódicamente criterios como los
mostrados abajo al portafolio de proyectos
Bajo clima del % % Calidad no Alcance no claro Riesgo no Ranking
proyecto con moral Desviación Desviación planificada y con indefiniciones, planificados
baja y alto nivel de de costos de tiempos controlada entregables no ni
conflictos identificados y falta controlados
negativos entre de control de en forma
miembros del cambios, alto especifica
equipo número de cambios

Ampliación de 4 4 5 4 4 3 24
planta

CRM 2 2 2 2 2 2 12

ISO 2 1 1 1 2 3 10

Migración 2 2 3 3 5 3 18
W2003

Nuevo 2 4 5 5 5 4 25
Producto
 3.1 Identificación.
3.1.2 Criterios de Identificación de proyectos en problemas

Muy bajo Bajo Medio Alto Muy Alto

Criterios NA 1 2 3 4 5 Puntos

Bajo clima del proyecto con moral baja y alto

nivel de conflictos negativos entre miembros x 4
del equipo

% Desviación de costos x 5

% Desviación de tiempos x 4

Calidad de los entregables defectuosa x 5

Alcance no claro con indefiniciones,

entregables no identificados y falta de control x 4
de cambios, alto número de cambios

Riesgo promedio del proyecto x 2

24
3.1 Identificación.
3.1.2 Criterios de identificación de proyectos en problemas

Tabla de puntuaciones por cada criterio Muy Bajo Medio Alto Muy Alto
bajo
Criterios 1 2 3 4 5

Bajo clima del proyecto con moral baja y Según

alto nivel de conflictos negativos entre encuesta del 1
miembros del equipo al 5

Porcentaje de desviación de costos <= 3% 3a5 5 a 10 10 a 15 >15%

Porcentaje de desviación de tiempos <= 3% 3a5 5 a 10 10 a 15 >15%

% de
desviación de
Calidad de los entregables <= 10% <20% <30% <50% >50%
defectos
esperados

Alcance no claro con indefiniciones,

entregables no identificados y falta de Número de
2 4 6 10 >10
control de cambios, alto número de cambios
cambios

Riesgo promedio del proyecto <= 2 3 4 5 >6

3.1 Identificación.
3.1.3 Comunicación y Venta a la gerencia de la Recuperación del proyecto
Problemas
• Jefes de proyectos reacios a
aceptar que su proyectos está en
problemas.
• Poco uso de metodología de
gestión de proyectos que no hace
evidente los proyectos en
problemas.
• Poca disposición de los
ejecutivos a evidenciar un
proyecto en problemas.
• Cultura de convivir con
proyectos en problemas.
Estrategia
• Vender el proceso de
recuperación de proyectos como
apoyo al éxito de los proyectos.
• Mostrar los efectos de un
proyecto en problemas sobre el
portafolio.
• Hacer del proceso de
recuperación un proceso formal
con políticas claras y no
influenciadas por intereses de
ciertos stakeholders.
• Integrar el proceso a las
funciones de la PMO.
3.1 Identificación.
3.1 Identificación.

Comité de portafolio • Gerentes

de proyectos Ejecutivos

Proyecto en
problemas
PMO
• Metodología
• Soporte
• Entrenamiento
Portafolio de • QA
Proyectos • Portafolio
Proceso de
• Recuperación
recuperación

Proyecto
recuperado
Proceso de recuperación.

Identificación

Portafolio de
Proyectos
Diagnóstico

Inicio de la Plan de Ejecución y Cierre

Cancelar / Recuperación Recuperación Control
Congelar

Acta de Plan del Reportes de Informes

recuperación Proyecto estado de Cierre
del proyecto
3.2 Diagnóstico.
El proceso de diagnóstico consiste en entrevistar a los stakeholders principales del proyecto, revisar las
evidencias del proyecto para determinar en forma detallada cual es su estado actual, y plantear las
acciones necesarias para su recuperación.

Comité y Project
Diagnostico del Proyecto : Implementación CRM de Oracle Sponsor Manager
Equipo

1. Inicio y Planificación Calificación Evidencias

1.1 Integraciòn
1.1.1 ¿Se ha creado un acta de constitución de proyecto y se ha comunicado a todos P.Charter y Acta
los involucrados del proyecto? x x 3

1.1.2 ¿Se ha establecido objetivos claros, medibles, relevantes y alcanzables? x x 4 Plan de Alcance

1.1.3 ¿Los objetivos del proyecto están alineados a los objetivos del negocio y sus P.Charter, Plan Estrategico
beneficios justifican la razón de ser del proyecto? x x 3

1.1.4 ¿Se obtuvo el compromiso del Sponsor y de la gerencia desde los inicios del Acta y % de tiempo asignado del
x x 5 Sponsor
proyecto?
1.1.5 ¿Se ha planificado el apoyo ejecutivo del Sponsor en por lo menos 20% de su Plan de Alcance
tiempo? x x 2

Calificación:
1: Muy Bajo
2: Bajo
3: Medio
4: Bueno
5: Muy Bueno
3.2 Diagnóstico.
2. Ejecución y Control
2.1 Integración

1.1.7 ¿Los objetivos, restricciones y premisas estan 1. Reevaluar objetivos, restricciones y premisas. En caso de cambios debera
rigiendo claramente la direccion del proyecto ? replanificarse el proyecto.
2. Validar y comprometer a los stakeholders a seguirlas.
2.1.1 ¿El proyecto se ejecuta diariam ente siguiendo el plan 1. Actualizar el plan del proyecto a la semana actual
del proyecto ? (cronograma, costos, alcance, calidad, etc) 2. Comunicar y comprometer a todos los stakeholders en su cum plimiento
2. Generar reportes semanales de seguim iento tomando como base el plan
2.1.2 ¿Se estan generando solicitudes de cam bio y estan 1. Form alizar las solicitudes de cambios a través de los canales de comunicación
siendo tramitadas via el proceso de gestion de cambios y 2. Elaborar formato de control de cam bios que contengan la descripción del
respetando los beneficios de la organización? (no hay alto cambio, y el impacto en el costo, tiem po, calidad y alcance; asi com o tam bien el
numero de cambios ni intereses particulares para impacto en los entregables del proyecto
aceptarlos). 3. Responder a los cambios del proyecto de manera oportuna

2.1.3 ¿Se realizan las mediciones de las métricas de 1. Monitorear semanalmente las métricas de la linea base del proyecto en
tiempo, costo, alcance y calidad semanalmente? terminos de tiempo, costo, alcance y calidad; y compararlas con las metricas
de la linea base de recuperacion.
2.2 Alcance
2.2.1 ¿Todos los entregables del proyecto cuentan con 1. Definir criterios de aceptación de los entregables y verificar que los
una aprobaciòn formal del cliente siguiendo los requerimientos de cada uno de ellos sean claros y específicos. Especificar la
criterios de aceptación de los entregables? palabrá "el entregable será aprobado cuando ..........."
2. Comunicar los criterios de aceptación a los stakeholders.
2.2.2 ¿Se realiza la trazabilidad de los requerim ientos al 1. Elaborar una matriz de trazabilidad de los requerimientos en donde se visualice
térm ino de cada fase del proyecto? el avance durante las fases del proyecto
2. Comprometer a los responsables de los entregables en el uso de esta m atriz de
trazabilidad
2.3 Tiempos
2.3.1 ¿Se esta llevando registro de los av ances del 1. Comparar las variaciones de tiem po respecto a la línea base.
cronograma asi como de los cam bios al m ismo?. ¿Son las 2. Ante desviaciones significativas cuestionar precedencias y buscar
desviaciones significativas respecto a los limites de desarrollar cosas en paralelo. Hacer micromanagement es decir que
variacion?. ¿Es el cronograma del proyecto lo planificar y hacer seguimiento de actividades en forma micro (diaria)
suficientemente efectivo para asegurar el seguimiento de 3. Registrar los av ances del proyecto, asi com o el trabajo restante
todo el proyecto ? 4. Reev aluar la efectiv adad del cronograma para el seguim iento del proyecto
2.3.2 ¿Se usan m étricas de valor ganado para el 1. Implem entar las métricas de valor ganado.
seguimiento del cronograma ?. ¿Es efectiv o ? 2. Registrar los av ances del proyecto, asi com o el trabajo restante
3. Reev aluar la efectiv idad de su m edición y proyección

2.4 Costos
 3.2 Diagnóstico.
2. Ejecución y Control
2. Ejecución y Control
2.12.1
Integración
Integración

1.1.7 ¿Los objetivos, restricciones y premisas estan 1. Reevaluar objetivos, restricciones y premisas. En caso de cambios debera
1.1.7 ¿Los objetivos,
rigiendo claramenterestricciones y prem
la direccion del isas estan
proyecto ? 1.replanificarse
Reevaluar objetivos, restricciones y premisas. En caso de cambios debera
el proyecto.
rigiendo claramente la direccion del proyecto ? replanificarse el proyecto.a los stakeholders a seguirlas.
2. Validar y comprometer
2.1.1 ¿El proyecto se ejecuta diariam ente siguiendo el plan 1. Actualizar el plan del proyecto a la semana actual
2.2. Validar y comprometer a los stakeholders a seguirlas.
Comunicar y comprometer a todos los stakeholders en su cum plimiento
del proyecto ? (cronograma, costos, alcance, calidad, etc)
2. Generar reportes semanales de seguim iento tomando como base el plan
2.1.1 ¿El proyecto se ejecuta diariamente siguiendo el plan 1. Actualizar el plan del proyecto a la semana actual
2.1.2 ¿Se estan generando solicitudes de cam bio y estan 1. Form alizar las solicitudes de cambios a través de los canales de comunicación
delsiendo
proyecto ? (cronograma, costos, alcance, calidad, etc)
tramitadas via el proceso de gestion de cambios y 2.
2. Comunicar y comprometer
Elaborar formato de control a
detodos los stakeholders
cam bios que contenganenlasudescripción
cumplimiento
del
cambio,
respetando los beneficios de la organización? (no hay alto 2. y el impacto en el costo, tiem po, calidad y alcance; asi com
Generar reportes semanales de seguimiento tomando como base el plan o tam bien el
numero de cambios ni intereses particulares para impacto en los entregables del proyecto
2.1.2 ¿Se estan generando solicitudes de cambio y estan
aceptarlos). 1.3. Formalizar
Responder las solicitudes
a los de cambios
cambios del a través
proyecto de deoportuna
manera los canales de comunicación
siendo
2.2 Alcancetramitadas via el proceso de gestion de cambios y 2.1. Elaborar
2.1.3 ¿Se realizan las mediciones de las métricas de
formato de control de cambios que contengan la descripción del
Monitorear semanalmente las métricas de la linea base del proyecto en
respetando
2.2.1 ¿Todos loslos
tiempo, costo, beneficios
alcance de
entregables la organización?
y calidad (no hay alto
semanalmente?
del proyecto cuentan cambio,
terminos
con 1. Definiry criterios
el
deimpacto
tiempo,en
de el costo,
costo, tiempo,
alcance
aceptación deylos calidad
calidad; yycompararlas
alcance;
entregables asi como
con las
y verificar quetambien
metricas
los el
de la linea
impacto en base de recuperacion.
los entregables del de
proyecto
numero
una de cambios
aprobaciòn formni al
intereses particulares
del cliente siguiendo para los requerim ientos de cada uno ellos sean claros y específicos. Especificar la
2.2 Alcance
aceptarlos). 3. Responder a los cambios del proyecto de manera oportuna
criterios de aceptación
2.2.1 ¿Todos de los entregables?
los entregables del proyecto cuentan con palabrá1. Definir"elcriterios
entregable será aprobado
de aceptación de loscuando ..........."
entregables y verificar que los
una aprobaciòn formal del cliente siguiendo los 2. Comunicar los criterios de aceptación a los stakeholders. Especificar la
requerimientos de cada uno de ellos sean claros y específicos.
criterios de aceptación de los entregables? palabrá "el entregable será aprobado cuando ..........."
2.1.3 ¿Se realizan las mediciones de las métricas de 1.2. Monitorear semcriterios
analmente las métricasa de la linea base del proyecto en
2.2.2 ¿Se realiza la trazabilidad de los requerimientos al 1. Elaborar Comunicar unalosmatriz de trazabilidad
de aceptaciónde los requerimientos
los stakeholders. en donde se visualice
tiem po,
2.2.2 costo,
¿Se alcance
realiza la y calidad
trazabilidad
término de cada fase del proyecto? desem
los analm ente?
requerim ientos al term
1. inos
Elaborar de tiem
una po,
matriz costo,
de alcance
trazabilidad
el avance durante las fases del proyecto y
de calidad;
los y com
requerimientos pararlas
en conselas
donde metricas
visualice
2.3 Tiempos
térm ino de cada fase del proyecto? el avance
deComprometerdurante
la linea baseade las fases del
recuperacion.proyecto
2.3.1 ¿Se esta llevando registro de los avances del 2.
2. Comparar
1. Comprometer a los responsables
los responsables
las variaciones de tiempodelos
de los entregables
entregables
respecto en
a la líneaenelel usodedeesta
uso
base. estammatriz
atriz dede
2.2 Alcance trazabilidad
trazabilidad
2.3 Tiemposasi como de los cambios al mismo?. ¿Son las 2. Ante desviaciones significativas cuestionar precedencias y buscar
cronograma
2.3 Tiem
2.3.1pos
desviaciones significativas
¿Se esta respecto
llevando registro de losaavlos limites
ances del de desarrollar
1. Compararcosas en paralelo.
las variaciones Hacer
de tiem micromanagement
po respecto a la línea base. es decir que
cronograma asi como de los cam bios al m ismo?. ¿Son las 2. Ante desviaciones significativas cuestionar precedencias y buscar
variacion?. ¿Es el cronograma del proyecto lo
desviaciones significativas respecto a los limites de
planificar y hacer seguimiento de actividades en forma micro (diaria)
desarrollar cosas en paralelo. Hacer micromanagement es decir que
suficientemente
variacion?. ¿Es efectivo para asegurar
el cronograma el seguimiento
del proyecto lo de 3.planificar
Registrary los avances
hacer del proyecto,
seguimiento asi como el
de actividades entrabajo
forma restante
micro (diaria)
suficientemente
todo 3. Registrar los av ances del proyecto, asi com o el trabajo
el proyecto ? efectivo para asegurar el seguimiento de 4. Reevaluar la efectivadad del cronograma para el seguimiento del proyecto restante
todo el proyecto ? 4. Reev aluar la efectiv adad del cronograma para el seguim iento del proyecto
2.3.2 ¿Se
2.3.2 usan
¿Se usanmétricas dedevalor
m étricas valorganado
ganadopara
paraelel 1.1. Implementar
Implem entar las
las métricas devalor
métricas de valorganado.
ganado.
seguimiento deldelcronograma
seguimiento cronograma?.?.¿Es
¿Esefectivo
efectiv o?? 2.2. Registrar
Registrar los avances del proyecto,
av ances del proyecto,asi
asicom
como
o eleltrabajo
trabajorestante
restante
3. Reev aluar la efectiv idad de su m edición y proyección
3. Reevaluar la efectividad de su medición y proyección
2.4 Costos
2.4 Costos
3.2 Diagnóstico.
3.2.1 Informe de diagnóstico del proyecto
Para el inicio y planificación se tiene: 56%
In ic io y p la n if ic a ció n

Pr o c u r a

Rie s g o s

RR.HH

Ca lid a d

Comu nic a c ion e s

Co s to

Tiemp o s
Prom. inicio y planificación +
A lc an c e 2 (Prom. ejecución y control)
In teg r a c io n Promedio =
0 .0 0 0.2 0 0 .4 0 0.6 0 0 .8 0 1 .00 3

Para la ejecución y el control se tiene: 36%

Eje cu ció n y C o n tr o l

Proc ura

Ries gos

RR.HH

Calidad

Comunic ac iones

Cos to

Tiempos

A lc anc e

Integrac ion

0.00 0.20 0.40 0.60 0.80 1.00

 Proceso de recuperación.

Identificación

Portafolio de
Proyectos
Diagnóstico

Inicio de la Plan de Ejecución y Cierre

Cancelar / Recuperación Recuperación Control
Congelar

Acta de Plan del Reportes de Informes

recuperación Proyecto estado de Cierre
del proyecto
3.3 Inicio de la recuperación.
3.3.1 Determinar el nivel de recuperación

Según el diagnóstico del proyecto

Inicio y planificación

Procura

Riesgos

RR.HH

Calidad
Se establecen niveles de recuperación
Comunicaciones

Costo (según diagnóstico):

Tiempos

Alcance
• Nivel de recuperación 1 (> del 70%)
Integracion

0.00 0.20 0.40 0.60 0.80 1.00

• Nivel de recuperación 2 (> del 50%)
Ejecución y Control
• Nivel de recuperación 3 (< del 50%)
Procura

Riesgos

RR.HH

Calidad Mayor necesidad

Comunicaciones

Costo
de recuperación
Tiempos

Alcance

Integracion

0.00 0.20 0.40 0.60 0.80 1.00

3.3 Inicio de la recuperación.
3.3.1 Determinar el nivel de recuperación

Niveles Recomendaciones
1 (>70%) • Aplicar acciones correctivas y preventivas puntuales
incorporadas al plan del proyecto como parte de una
solicitud de cambio.
• El baseline de todo el proyecto se mantiene.
• No sigue todo el proceso de recuperación
2 (>50%) • Sigue el proceso de recuperación para el cual crea un acta
de constitución de recuperación de proyecto
Ambos niveles involucran
• Se planifican las acciones correctivas y preventivas
recomendadas en el diagnostico, verificándose la evaluar :
implementación básica de procesos de Gestión de proyectos.
• Cambio de sponsor(s)
• Se establece una línea de base de recuperación, la cual es • Cambio de Project
comparada con la línea base del proyecto.
Manager
3 (<50%) • Sigue el proceso de recuperación • Cambio de responsable
• Se detiene el proyecto y se usa todos los recursos para re- y/o miembro de equipo
planificar completamente el proyecto. • Objetivos del proyecto y
• Se espera cambios significativos en algunos de las alcance
restricciones de costo, tiempo, calidad y alcance.
3.3 Inicio de la recuperación.
Nivel 1 (> del 70%)
Nombre de tarea Duración

Proyecto "Sistema Tecnológico para la industria" 42 días

Planeación 9 días • No es necesario que siga
Inicio 0 días
Elaborar acta de inicio del proyecto 1 día todo el proceso de
Describir marco teórico-metodológico 2 días recuperación.
Definir sectores industriales para prueba piloto. 2 días
Preparar lista de nodos estratégicos de la red 1 día
Validar el plan del proyecto
Informar acuerdos básicos para el proyecto.
1 día
2 días
Estado actual
Fin 0 días Valores
Diseño y Desarrollo del Sistema 21 días acumulativos EAC
Inicio 0 días
Diseñar y listar Indicadores de Innovación 3 días
Preparar modelo del Sistema 5 días AC
Desarrollar el sistema 10 días
PV
Elaborar casos de pruebas 3 días
Fin 0 días
Puesta en Marcha y Prueba Piloto 12 días
Inicio 0 días
Puesta en marcha de un programa interdisciplinario
4 días EV
Lanzar un Portal en Internet 5 días
Ofrecer ciclo de conferencias y paneles sobre las
3 días
mejores prácticas
Fin 0 días
t1 t2
3.3 Inicio de la recuperación.
Nivel 2 (> del 50 %)
Nombre de tarea Duración

Proyecto "Sistema Tecnológico para la industria" 49 días?

Planeación 12 días?
Inicio 0 días
Elaborar acta de inicio del proyecto 1 día
Describir marco teórico-metodológico 2 días
Elaborar EDT y alinear objetivos con el alcance 1 día
Definir sectores industriales para prueba piloto. 2 días
Preparar lista de nodos estratégicos de la red 1 día
Elaborar el plan del proyecto 1 día
Elaborar métricas de calidad 1 día?
Informar acuerdos básicos para el proyecto. 2 días Estado actual
Definir claramente los procedimientos de cambio 1 día
Fin 0 días Valores
Diseño y Desarrollo del Sistema 24 días? acumulativos EAC
Inicio 0 días
Diseñar y listar Indicadores de Innovación 3 días
Preparar modelo del Sistema 5 días
Validación de control de calidad del modelo 1 día?
AC
Desarrollar el sistema 10 días PV
Documentar desarrollo y cambios 20 días
Baseline de
Elaborar casos de pruebas 3 días
recuperación
Monitorear los riesgos y problemas 20 días
Reportar estados de los entregables 2 días
Fin 0 días
Puesta en Marcha y Prueba Piloto 13 días EV
Inicio 0 días
Puesta en marcha de un programa interdisciplinario 4 días
Lanzar un Portal en Internet 5 días
Aprobar los entregables por el comité directivo 1 día t1 t2
Ofrecer ciclo de conferencias y paneles sobre las mejores prácticas 3 días
Fin 0 días
3.3 Inicio de la recuperación.
Nivel 3 (< del 50%)
Nombre de tarea Duración

Proyecto "Implementar CRM" 125 días

Administracion de Proyectos 125 días
Inicio y Planificacion 30 días
Elaborar acta de inicio del proyecto 2 días
Describir marco teórico-metodológico 2 días
3 días
Elaborar EDT y alinear objetivos con el alcance
Definir requerimientos 10 días
Elaborar el plan del proyecto 2 días
Elaborar métricas de calidad 4 días
Informar acuerdos básicos para el proyecto. 2 días Estado actual
Definir los procedimientos de cambio 5 días
Fin de Inicio y Planificación 0 días Valores
Monitoreo y Control 85 días acumulativos EAC
Monitorear los riesgos y problemas 85 días
Reporte semanal de actividades 85 días
Controlar los cambios del proyecto 85 días
Cierre del Proyecto 10 días
AC
Elaborar reporte de cierre 10 días PV
Diseño y Desarrollo del Sistema 80 días
Inicio 0 días
Diseñar funcionalidades 3 días
Preparar modelo del Sistema 10 días
Validación de control de calidad del modelo 5 días
Implementar los modulos del sistema 40 días
Documentar cambios en los entregables 7 días EV
Elaborar y ejecutar casos de pruebas 15 días
Fin 0 días
Puesta en Marcha y Prueba Piloto 11 días t1 t2
3.3 Inicio de la recuperación.
Nivel 3 (< del 50%)
Nombre de tarea Duración

Proyecto "Implementar CRM" 125 días

Administracion de Proyectos 125 días
Inicio y Planificacion 30 días
Elaborar acta de inicio del proyecto 2 días
Describir marco teórico-metodológico 2 días Curva re
3 días
Elaborar EDT y alinear objetivos con el alcance planificada
Definir requerimientos 10 días Valores fase
acumulativos tardía EAC
Elaborar el plan del proyecto 2 días
Elaborar métricas de calidad 4 días fase fase BAC
Informar acuerdos básicos para el proyecto. 2 días temprana media
Definir los procedimientos de cambio 5 días
Fin de Inicio y Planificación 0 días AC
Monitoreo y Control 85 días
Monitorear los riesgos y problemas 85 días
Reporte semanal de actividades 85 días
Controlar los cambios del proyecto 85 días
Cierre del Proyecto 10 días
Elaborar reporte de cierre 10 días
Diseño y Desarrollo del Sistema 80 días
Inicio 0 días
Diseñar funcionalidades 3 días
Preparar modelo del Sistema 10 días
Validación de control de calidad del modelo 5 días
Implementar los modulos del sistema 40 días t1 t3 Tiempo
Documentar cambios en los entregables 7 días
Elaborar y ejecutar casos de pruebas 15 días
Fin 0 días Se re-planifa el proyecto y se
Puesta en Marcha y Prueba Piloto 11 días hace un rebaseline general
 Proceso de recuperación.

Identificación

Portafolio de
Proyectos
Diagnóstico
Nivel 2 y 3

Inicio de la Plan de Ejecución y Cierre

Cancelar / Recuperación Recuperación Control
Congelar

Acta de Plan del Reportes de Informes

recuperación Proyecto estado de Cierre
del proyecto
3.3 Inicio de la recuperación.
3.3.2 Acta de Constitución del Proyecto a recuperar

Se inicia realizando un Project Charter de la recuperación, comprometiendo al Comité Directivo, así

como al Sponsor y equipo recuperador del proyecto para cumplir con los objetivos y calendario.

Project Charter
(Recuperación)
A. Información general del proyecto a recuperar
Nombre del proyecto Implementación CRM de Oracle Project manager Jesús Domínguez

Fecha de inicio de la 15/03/2006 Autorizado Por: Director de PMO

recuperación
B. Objetivos de la recuperación del proyecto
Recuperar el proyecto y llevarlo a condiciones normales de su limite de variación en el lapso de 8 semanas.
C. Alcance de la recuperación (Dentro de Alcance)
• Describir requerimientos en forma especifica
• Descomponer el WBS a un nivel 4 especificando los entregables correspondientes a los terceros.
• Completar cronograma con lo especificado arriba e incluir las acciones correctivas y preventivas del informe del
diagnostico (definir micro actividades, validar hitos, asegurar interdependencias, etc)
• Implementar los procesos de costos, tiempos y riesgos, y definir métricas de desempeño de ellas.
• Hacer seguimiento exhaustivo semanal con reuniones de seguimiento de riesgos y problemas semanales.
D. Nivel de la Recuperación : Nivel 3
 Proceso de recuperación.

Identificación

Portafolio de
Proyectos

Diagnóstico
Nivel 2 y 3

Inicio de la Plan de Ejecución y Cierre

Cancelar / Recuperación Control
Recuperación
Congelar

Acta de Plan del Reportes de Informes

recuperación Proyecto estado de Cierre
del proyecto
3.4 Plan de Recuperación.
3.4.1 Plan Nivel 2

Estado actual Baseline de Recuperación

Valores Valores
acumulativos EAC acumulativos EAC

AC AC
PV PV
Baseline de
recuperación

EV EV

t1 t2 t1 t2
 3.4 Plan de Recuperación.
3.4.1 Plan Nivel 3 (Recuperación extrema)

Curva re
planificada
Valores fase Valores fase
tardía acumulativos tardía EAC
acumulativos
fase fase EAC fase fase BAC
temprana media temprana media

AC AC

PV

EV

t1 t2 t1 t3 Tiempo

Se re-planifa el proyecto y se hace

un rebaseline general
 Proceso de recuperación.

Identificación

Portafolio de
Proyectos
Diagnóstico
Nivel 2 y 3

Inicio de la Plan de Ejecución y Cierre

Cancelar / Recuperación Recuperación Control
Congelar

Acta de Plan del Reportes de Informes

recuperación Proyecto estado de Cierre
del proyecto
3.5 Ejecución y Control de la recuperación.

Se preparan los reportes de estado correspondientes a los Informes de avance de la recuperación,

reportes de riesgos y problemas, y solicitudes de cambios.

Valores
acumulativos EAC

Seguimient
o y control
AC PV sobre las
acciones
correctivas

Baseline de
recuperación T2 % Avance
Baseline 78%
original
EV
Baseline de 70%
recuperación
Real 72%
t1 t2 t3 Reportes
de estado
3.5 Ejecución y Control de la recuperación.

Se preparan los reportes de estado correspondientes a los Informes de avance de la recuperación,

reportes de riesgos y problemas, y solicitudes de cambios.

Valores Inicio
acumulativos Recuperación BAC

EAC
Seguimient
o y control
AC sobre las
acciones
correctivas

Tx % Avance
Rebaseline 80%
Curva re
planificada Real 82%

t1 tx t3 Tiempo Reportes
de estado
 Proceso de recuperación.

Identificación

Portafolio de
Proyectos
Diagnóstico
Nivel 2 y 3

Inicio de la Plan de Ejecución y Cierre

Cancelar / Recuperación Recuperación Control
Congelar

Acta de Plan del Reportes de Informes

recuperación Proyecto estado de Cierre
del proyecto
3.6 Cierre de la recuperación.
Luego de haber ejecutado el plan de recuperación del proyecto, y la desviación del proyecto en tiempos,
costos y alcance haya alcanzado una salud general verde, se comunicará a la gerencia los resultados del
proceso de recuperación, así como las lecciones aprendidas obtenidas.

Cierre de la recuperación
Valores Inicio
acumulativos Recuperación BAC

EAC

AC
Reporte de
cierre

t1 tx t3 Tiempo Lecciones
aprendidas
4. Lecciones
aprendidas
4. Lecciones aprendidas.

• Tomar al proceso de recuperación como un aliado para el éxito del

portafolio de proyectos y el plan estratégico de la organización.

• Promover a los Project Managers que pasaron por el proceso de

recuperación sean los nuevos asesores en la recuperación de otros
proyectos.

• Todos los proyectos no tienen el mismo nivel de problemas por lo

tanto no deben seguir el mismo proceso de recuperación.

• Incorporar el proceso de recuperación a las funciones de la Oficina

de gestión de proyectos – PMO.

• Para recuperar proyectos evalúe a los stakeholders, haga micro-

management, preste mucha atención a los detalles y póngale
pasión.
4. Lecciones aprendidas.

Beneficios
• Organizaciones con un proceso estándar tuvieron aproximadamente un
80% más de proyectos exitosos, 195% menos proyectos que
permanecieron con problemas, y 120% menos proyectos que fallaron,
que esas organizaciones sin procesos formales.
• Intervenciones para recuperar proyectos con problemas alcanzaron un
80% de éxito en las organizaciones; un 47% de ellos fueron proyectos
recuperados y completados con éxito, y un 37% fueron redefinidos como
nuevos proyectos y alcanzado con éxito las expectativas de estos nuevos
requerimientos.
• Empresas que carecen de un proceso de revisión y recuperación estándar
recuperarán exitosamente solo el 37% de los proyectos con problemas.

Troubled Projects, Project Failure or Project Recovery

Center for Business Practices 2006
Referencia: http://www.cbponline.com/ProductDetails.asp?ProductCode=1929576226
! Un minuto de silencio por todos
los proyectos caídos !
Muchas gracias

Alfonso Núñez, MBA, PMP

alfonso.nunez@pmi.org.pe
alfonso.nunez@bie.pe
 Alfonso Núñez, MBA, PMP

• Capítulo del PMI Lima, Perú

• Phone Contact: 51+1+568-9601

51+1+9-9467-3048

• alfonso.nunez@pmi.org.pe
alfonso.nunez@bie.pe
 Capítulo Lima, Perú

Congreso Internacional de
Gerencia de Proyectos PMI – Mendoza 2009

Recuperación de Proyectos con Problemas

Alfonso Núñez, MBA, PMP

Presidente del Capítulo del PMI Lima,
Perú