Notas de Clase Semana 2

Recuperación de Proyectos

Maestría en Dirección de
Proyectos
MC Juan Francisco Monroy E
Webgrafía

 “Project Management a Systems Approach to planning”,

https://docs.google.com/open?id=0B_TfIql9aGrlV1FWY0dBWU5I
MlU

 “PMBOK Sixth Edition, PMI”,

https://drive.google.com/file/d/1TdTCWWQtT6JpS3FKsB17a6G6
LjngpcAn/view?usp=sharing

 The Rapid Assessment and Recovery of Troubled Projects

 ESI International. Recuperado de: https://www.projectsmart.co.uk/white-
papers/rapid-assessment-and-recovery-of-troubled-projects.pdf
Video introductorio de esta semana
En carácter introductorio a los temas que analizaremos esta semana, favor de
atender a los siguientes videos:

 Video 1: Medina Alvaro, ESIIntSpain (Octubre 2018). Vídeo 2: ¿Quién debe

integrar el equipo de Evaluación? ¿Cuál es la mejor aproximación?.
Recuperado de: https://www.youtube.com/watch?v=GDSID2dG2BU

 Video 2. Medina Alvaro, ESIIntSpain (Octubre 2018). Vídeo 3: ¿Quién debe

integrar el Equipo de Evaluación? ¿Cuál es la mejor aproximación?.
Recuperado de: https://www.youtube.com/watch?v=06mATaVf_wI

 Video 3. Medina Alvaro, ESIIntSpain (Octubre 2018). Vídeo 4: ¿Cómo es el

Proceso de Evaluación Rápida y cuáles son sus principales Retos?.
Recuperado de: https://www.youtube.com/watch?v=lxYMGd8z-ZM

 Video 4. Holmer José (Octubre 2018). Técnicas de Negociación.

Recuperado: https://www.youtube.com/watch?v=KOtiXPF0fc
3. Tácticas aplicables a proyectos con fallas en la
gobernanza del proyecto o en el caso de negocio / business
case
3.1. Consideraciones para el análisis

 Cuando un Caso de Negocio es defectuoso al inicio del proyecto, es

usualmente debido a la falta de tiempo para realizar una investigación que
permita validar los objetivos. Los Líderes de Proyecto usualmente asumen que
los casos de negocio como válidos cuando inician un proyecto.

 Cuando los stakeholders cambian sobre la vida de un proyecto, la probabilidad

que el caso de negocio cambie se incrementa significativamente.

 Algunos de los Stakeholders tomarán decisiones del proyecto pensando más en

posicionamientos personales, que el verdadero interés del proyecto

 Si el proyecto va bien, algunos stakeholders tratarán de acelerar los procesos relacionados

con costo o riesgos para llevar a éxito al proyecto y ellos sean reconocidos.
 Si el proyecto va mal, serán renuentes a admitir la falla con la toma de decisiones o bien
esconderán el problema para no ser mal vistos.
3.2. Revalidación de premisas y requerimientos
iniciales

 Error crítico: una falla para revalidar los supuestos del proyecto
identificados en el caso de negocio. El líder de proyecto equivocarse
creyendo que los supuestos son correctos y aún válidos.
 El problema es que el proyecto podría haber sido aprobado meses
atrás.
 Usualmente los líderes de proyecto cuentan con herramientas para
medir, costo, tiempo y esfuerzo, sin embargo no cuentan con
herramientas para medir y dar seguimiento a la validez de los
supuestos y caso de negocio.
 Algunos de los supuestos que suelen cambiar en el tiempo y deben ser
considerados son:
1. El costos del dinero y financiamiento del proyecto permanecerán sin cambios
2. Los costos de adquisiciones no incrementarán
3. Los recursos con los conocimientos necesarios serán provistos cuando sean requeridos
4. El mercado aceptará el producto
5. Nuestros competidores no nos alcanzarán
6. Los riesgos son bajos y pueden fácilmente ser mitigados
7. El ambiente político en la organización no cambiará.
3.2. Revalidación de premisas y requerimientos
iniciales

 Una forma de mitigar los riesgos asociados con las premisas o

supuestos es ejecutar con frecuencia el siguiente checklist:

Checklist para validar supuestos Yes No

Los supuestos se encuentran fuera del control del proyecto

Los supuestos se encuentran fuera del control de los Stakeholders
Los supuestos pueden ser validados como correctos
Los cambios en los supuestos pueden ser controlados
La condición asumida es NO fatal
Las consecuencias de este supuesto representan un riesgo serio para el proyecto
Cambios no favorables en el supuesto pueden ser fatales en el proyecto
3.3. Revisión del marco de referencia de gobernanza para
el proyecto

 El gobierno del proyecto es actualmente un Marco de Trabajo por el cual son

tomadas las decisiones del proyecto.
 Adecuado gobierno del proyecto permite eficacia y eficiencia en la toma de
decisiones, mientras se mantiene el valor esperado del resultado del proyecto.
 Los grupos de gobierno deben entender los beneficios del proyecto, el valor de
negocio esperado, la adaptación de la estrategia y la probabilidad de éxito.
 Cada proyecto puede tener diferentes gobiernos, inclusive si cada proyecto
usa la misma metodología de administración de proyectos empresarial.
 La función del Gobierno puede operar como un proceso separado o como
parte del liderazgo de la administración del proyecto.
 Gobierno del proyecto no es lo mismo que gobierno corporativo.
 Gobierno corporativo: consiste en una serie de procesos, políticas y reglas que
afectan la forma en cómo la gente administra y controla una corporación.
 Gobierno en los proyectos y programas algunas veces falla, por que la gente
confunde gobierno de proyecto con gobierno corporativo.
3.3. Revisión del marco de referencia de gobernanza para
el proyecto

 Algunas diferencias entre gobierno de proyecto y gobierno corporativo pueden

ser:

 1. Alineación: gobierno corporativo pone foco en como el portafolio de

proyectos es alineado con los objetivos del negocio en global. Gobierno de
proyecto pone foco en la forma de mantener un proyecto en seguimiento y
verificar que el valor esperado será conseguido al finalizar el proyecto.
 2. Dirección: gobierno corporativo provee dirección estratégica, mientras que
gobierno de proyecto es mas dirección operacional en relación a métricas de
alcance, tiempo, costo y funcionalidad del proyecto.
 3. Dashboards: gobierno corporativo coloca foco sobre métricas de finanzas,
mercado y ventas, mientras que dashboard de gobierno de proyecto coloca
foco a métricas de alcance, costo y tiempo.
 4. Membership: los comités de gobierno corporativo son compuestos por los
niveles sr de administración, mientras que el gobierno del proyecto es
usualmente compuesto por administradores de proyecto de rango medio.
3.4. Redefinición de roles, responsabilidades y
autoridad para la toma de decisiones
 La pregunta obligada siempre es: ¿qué decisiones deben ser tomadas por el comité de
gobierno y cuales por el Líder de Proyecto?
1. Los roles y responsabilidades ambiguos o sobrepuestos dirigen siempre al caos.

 La siguiente tabla muestra algunas diferencias entre responsabilidades:

Gobierno

Definir los resultados finales Desarrollar planes tácticos

esperados Determinar necesidades de
Definir entregables intermedios recursos
Definir metas estratégicas Buscar disponibilidad de recursos

Definir objetivos estratégicos
Definir limitantes de
financiamiento
Definir los factores del ambiente
Definir el involucramiento de los
ejecutivos
Líderes de Proyecto
Buscar planeación de capacidad
Establecer las líneas base
Evaluar riesgos de
implementación
Identificar las métricas o KPIs
Controlar el recorte de alcance
3.4. Redefinición de roles, responsabilidades y
autoridad para la toma de decisiones
 La siguiente tabla muestra algunas diferencias entre la autoridad para la toma de
decisiones:
Gobierno

Decisiones de Preparación de Líneas

planeación estratégica Base
Cambiar los objetivos de Mantenimiento de

Líderes de Proyecto
negocio Líneas Base
Aprobación de cambios Negociación de recursos
de alcance Mitigación LIMITADA de
Frecuencia de chequeos riesgos
de salud
Cancelación de
proyectos
3.4. Redefinición de roles, responsabilidades y
autoridad para la toma de decisiones
 A continuación se muestra una estructura típica de gobierno de proyecto:

Comité de clientes
o Stakeholders

Comité de
inversión

Dueño externo del

negocio

Patrocinador del
Proyecto (Dueño Comité de
interno del Gobierno
negocio)

Líder de Proyecto
3.4. Redefinición de roles, responsabilidades y
autoridad para la toma de decisiones
 A continuación una lista de causas comunes de fallas en proyectos debido a gobierno
pobre:

1. No hay una clara propiedad definida del proyecto

2. El equipo de gobierno no concuerda con los objetivos del proyecto
3. El caso de negocio del proyecto es pobre o simplemente no existe
4. El equipo de gobierno es demasiado grande o demasiado pequeño para el proyecto
5. No existe una clara responsabilidad sobre el éxito del proyecto, así que falla el proceso de toma
de decisiones
6. Los roles y responsabilidades de los miembros del comité no son claramente definidos
7. El equipo de gobierno limita la autoridad en la toma de decisiones, así que retrasa el ciclo de
vida del proyecto
8. Los miembros del equipo de gobierno continuamente cambian.
9. Nuevos miembros llegan con sus agendas ocultas
10. El equipo de gobierno no es provisto de la información correcta sobre la cual ejecutar una toma
de decisiones.
3.7. Gestión a través de la innovación

 Mientras que la meta de la innovación exitosa es agregar valor a un

proyecto, el resultado puede ser negativo o en ocasiones destructivo si
resulta en: una caída en la moral del equipo, un cambio de cultura no
favorable o una salida radical de las formas existentes de realizar el trabajo.

 Las características de los proyectos de innovación podrían incluir/requerir:

 Herramientas de innovación específicas y técnicas de tomas de decisiones

 Puede ser posible preparar una calendario detallado mostrando cuando el
desarrollo de la innovación ocurrirá
 Puede ser posible requerir determinar un presupuesto realista para la innovación
 Este tipo de escenarios ocurren con frecuencia con proyectos de plazo largo y
relacionados con innovación (i.e. tecnológica).
3.9. Análisis de caso

 Un ejemplo de cambios en el caso de negocio es el histórico proyecto de

Motorola conocido como Iridium. Ver el siguiente recurso:
 https://es.slideshare.net/AndresQuintanilla2/group5-failed-productiridium-case

 Los cambios pueden resultar a partir de nuevas tecnologías, nuevos clientes, nuevos
competidores, cambios en el mercado, cambios en las condiciones de la economía y en
algunas ocasiones cambios resultados de intervenciones políticas.

 Situación:
 Cuando el proyecto de Iridium fue por primera vez desarrollado, la necesidad de telefonía celular
inalámbrica era claramente necesaria. Pero el proyecto Iridium era un proyecto de 11 años. Como
era esperado nuevos competidores entraron en el mercado y dieron a los usuarios nuevas
opciones de celulares inalámbricos menos caros y con tarifas de larga distancia más baratas.
Pasados los 11 años del desarrollo del proyecto Iridium la tecnología cambió al punto donde
Iridium no podía garantizar más la base de cliente que permitiera cubrir la carga de la deuda. El
caso de negocio que inicio con objetivos válidos comenzaba a súbitamente convertirse en
inviables.

 Lección aprendida:
 Cuando el sistema es altamente complejo o toman un tiempo largo para ser completados y son
diseñados para crear productos o servicios únicos, el riesgo es grande por que puede ser
imposible saber si el usuario final apreciará esa complejidad. La necesidad al inicio de un
proyecto de largo plazo, puede no ser la misma necesidad al final de ese periodo.
3.9. Análisis de caso

 Resumen de Lecciones aprendidas:

 Cuando los caso de negocio son casi totalmente dependientes de las condiciones de mercado,
es extremadamente importante entender el presente y tener la habilidad de predecir el futuro.
 Sin duda una de las causas de proyectos en problemas reside en: caso de negocio pobre o caso
de negocio que cambia
 Un checklist de técnicas para administrar casos de negocio pueden incluir:

Trabajar con el cliente y los stakeholders para identificar los casos de negocio

Configurar una tabla de tiempo para revisiones periódicas del caso de negocio

Asegurar el completo entendimiento de los factores del ambiente y su impacto al caso de negocio

Establecer métricas para el seguimiento de supuestos en el caso de negocio

Determinar el impacto de todos los cambios de alcance aprobados tendrán con el caso de negocio

 Administración de riesgos
 Los buenos casos de negocio deben tener la capacidad de identificar a los riesgos que el
proyecto debe considerar, los tipos de riesgos que deberían considerarse son los siguientes:
 Riesgos asociados con la tecnología
 Riesgos de desarrollo
 Riesgos Financieros
 Riesgos de mercado
3.9. Análisis de caso

 Administración de Proyecto en Motorola (Iridium)

 Motorola finalmente entendió la necesidad una buena administración del proyecto en un esfuerzo
de esta magnitud. Construir, lanzar y posicionar satélites requeriría de más de 6,000 empleados
distribuidos en USA, Irlanda, Italia, Canada, China, India y Alemania. Los siguientes fueron
algunas de las acciones clave que realizaron en relación al tema de gestión de proyectos:

1. Selección de proveedores (partners): Motorola tuvo que encontrar los mejores proveedores que
le ayudarán a enfrentar el problema con alto nivel de calificación y con actitud de equipo de
trabajo y comunicación abierta.
2. Tecnología actual versus nueva tecnología: Motorola buscó utilizar muchas de la tecnología
existente en lugar de intentar “reinventar la rueda”
3. Usar el Capability Maturity Model (CMM): Motorola adoptó el CMM Model desarrollado por el
SEI (Software Engineerin Institute)
4. El WBS: el WBS fue descompuesto desde sistemas mayores, después subsistemas y hasta
llevarlo a productos.
5. Sistemas de Calendario: la primera herramienta utilizada por Motorola para la gestión del
proyecto fue Primavera Project Planner, que proporcionaba al menos 4 niveles de detalle en la
planeación para los distintos niveles del proyecto.
6. Compensaciones (Tradeoffs): proceso de control de cambios de alcance fueron establecidos
para compensar alcance, costo, calendario y riesgos.
4. Tácticas aplicables a proyectos afectados por agendas
políticas no identificadas
4.2. Razones para tomar en cuenta los aspectos políticos de un proyecto
 Comprensión política es en la actualidad un conocimiento esencial que debe poseer el
Líder de Proyecto.
 El Líder de Proyecto debe entender y saber manejar la naturaleza política de la gente y
organizaciones.
 Se debe tener presente que política y conflictos son inevitables y son una forma de vida
en la Administración de proyectos.
 Existen diversas razones del porqué la gente juega juegos políticos. Algunas razones
comunes son:
1. Querer mantener el control sobre los recursos escasos
2. Búsqueda de recompensas, poder o reconocimiento
3. Mantener una imagen propia y valores personales
4. Tener agendas ocultas
5. Miedo a lo desconocido
6. Control sobre información importante, dado que la información es fuente de poder
7. Buscar que otros hagan su propio trabajo
8. Ver únicamente aquello que quieres ver (actitud)
9. Rechazo a admitir derrotas o fallas
10. Ver las malas noticias como las fallas personales
11. Miedo a exponer errores a otros
12. Ver una falla como un signo de debilidad o daño a tu propia reputación
4. Tácticas aplicables a proyectos afectados por agendas
políticas no identificadas
Existen también políticos negativos donde juego políticos son jugados con la intención de dañar a
otros, algunos ejemplos son:

1. Desear ver el proyecto fallido

2. Miedo al cambio, si el proyecto es exitoso
3. Querer dañar la imagen o reputación de alguien más, especialmente si ellos están en el camino de tu
crecimiento profesional
4. Rechazar las ideas de otros para fortalecer tu posición

4.5. Acciones defensivas versus ofensivas

 No toda la gente que tiene una agenda política son enemigos, algunas personas pueden jugar sus juegos
políticos para su mejor interés, en ese contexto es importante lograr identificar en lo posible si las
agendas personales que la gente tiene los convierte en amigo o enemigos.

 Lo anterior implica que debes comunicarte con ellos, preferible más informal que formal para lograr
justamente entender sus agendas.

 Cuando la gente juega juegos políticos en proyectos podemos confirmar dos cosas:
 Esta gente es experta en jugar este tipo de juegos políticos
 Ellos esperan ganar

 Dado el escenario anterior, tu tienes que decidir entre atacar agresivamente o retraerse. No hacer nada te
condiciona perder la batalla.

 La primer regla en la batalla es conseguir la mayor información de tu enemigo

4.4 Mapeo de poder e influencia de promotores y
detractores del proyecto
En el escenario anterior, se sugiere mapear a los stakeholders en la siguiente clasificación:

High
Mantener Gestionar
satisfecho de cerca

Power

Mantener
Monitorear
informado
Low
Low High
Nivel de
interés
4.4 Mapeo de poder e influencia de promotores y
detractores del proyecto
Mientras las Cartas del Proyecto dan a los Líderes de Proyecto algún grado de
autoridad de un proyecto dado, la mayoría de los líderes aún tienen limitaciones
porque:

 Los líderes de proyecto deben negociar con los líderes funcionales para conseguir
recursos calificados.
 Los Líderes de proyecto no pueden o no tienen la autoridad para remover empleados de
un proyecto sin la autorización del Líder Funcional
 Los líderes de proyecto generalmente no tienen la responsabilidad directa sobre la
administración de los salarios
 Los gerentes de proyecto pueden poseer virtualmente ninguna recompensa o castigo.
 SI los empleados son asignados a múltiples proyectos, los Líderes de Proyecto no
pueden forzar a los empleados de dedicar mayor tiempo a sus proyectos.
 Entender las limitaciones del Líder de Proyecto cuando se escalan los problemas con el
Comité de Gobierno.
 Entender la importancia de la Gestión de Riesgos y la comunicación efectiva en
presencia de situaciones políticas.
4.6. Acciones para mejorar la efectividad en la
comunicación
Para minimizar el impacto político en un proyecto, el líder de proyecto debería considerar
usar las siguientes prácticas:

1. Escuchar con atención antes de hablar y no brincarse a las conclusiones

2. Asegurar entender la problemática de lo que los otros dicen y tratar de ver el problema
desde el punto de vista de ellos
3. Todas las comunicaciones informales deberían ser seguidas por una minuta y
asegurar con ellos no haya malos entendidos.
4. Antes de establecer tu punto de vista, asegúrate de haber obtenido toda la información
de soporte necesaria
5. Asegúrate de tener un claro entendimiento de cómo la cultura impacta en la forma que
la gente se comunica contigo
6. Si tienes que proveer críticas, asegúrate que éstas sean constructivas en lugar de
críticas personales.
7. Cuando se resuelven problemas políticos siempre hay ganadores y perdedores, debes
explicar a todos el porqué se ha tomado esa decisión para el ganador y el porque otras
soluciones no fueron consideradas.
8. Si la situación no puede ser manejada de manera efectiva, no dudes en involucrar al
Administrador Sr para un consejo o asistencia.
Recuperación de un proyecto
Enfoques fundamentales para recuperar el proyecto:

 Reducir el tamaño del Alcance.

 Incrementar la productividad a costa de lo que sea, centrándose en las
mejoras a corto plazo.
 Partiendo del hecho que el producto/servicio no va a quedar en tiempo,
retrase la planeación y continúe con el control del problema,
considerando la posibilidad de cancelar el proyecto.
 Combinación de los anteriores:
 Omitir una parte de los requerimientos, aumentar la productividad tanto
como sea posible y retrasar la planificación lo necesario.
 La causa más común de que los proyectos tengan problemas es
principalmente la falta de un control adecuado.
Recuperación de un proyecto
 Este es el momento para entrar en acción con decisión. Si se ha
decidido hacer cambios, realice todos los cambios de una sola vez. Es
más fácil volver a recuperar todo el control de una vez que intentar
recuperarlo poco a poco.
 “un pequeño intento de tratar de recuperar el proyecto puede conducir
a una falsa sensación de seguridad”

Las directrices están relacionadas con:

 Personas
 Proceso
 Producto
Plan de recuperación

Primeros
Personas Proceso Producto
pasos
Plan de recuperación
1. Primeros pasos
 Evalúe la situación
 Aplique el análisis Teory-W
 ¿Qué necesita usted y su equipo para triunfar?
 ¿Qué necesitan sus clientes?
 ¿Qué necesita hacer para salvar la situación con sus clientes?
 Prepárese para corregir el proyecto
 Pregunte al equipo sobre lo que se necesita hacer
 Sea realista

2. Personal
 Haga todo lo que sea necesario para recuperar la moral del grupo
 Elimine los problemas de personal más importantes
 Elimine los problemas principales con los responsables
 Si tiene que hacerlo aumente el número de personas con cuidado
 Céntrese en el tiempo de las personas
 Permitir que los miembros del equipo sean diferentes
 Permitir que los desarrolladores marquen su propio ritmo
Plan de recuperación
3. Proceso
 Identifique y resuelva los errores clásicos
 Detecte y corrija las partes del proceso de desarrollo que obviamente están destrozadas.
 Creación de puntos de revisión (hitos) miniatura detallados.
 Establecer una planificación vinculada a la terminación de hitos.
 Siga meticulosamente el progreso de la planificación
 Anotar las razones por las que no se han alcanzado los hitos
 Recalibrar después de un periodo corto de tiempo (una o dos semanas)
 No se comprometa con una nueva planificación hasta que pueda crear una significativa.
 Gestione los riesgos con esmero.

4. Producto
 Estabilizar los requerimientos
 Recorte del conjunto de requerimientos
 Evalúe su posición política
 Eliminar la basura
 Reducir el número de defectos y mantenerlos a raya
 Alcanzar un estado correcto conocido y partir del mismo (Milestones)
 Semana 2 - Actividad 2 (15%):
 Parte 1: Realizar un Mapa Mental/Conceptual de la lectura
“Strategies for Project Recovery” (consultar Guía para la
elaboración de un mapa mental).
 Instrucciones: debes leer con cuidado el reporte en cuestión y con la información
anterior debes elaborar un Mapa Mental o Conceptual.
 Rúbrica: las características del producto a entregar están definidas en la rúbrica
correspondiente en la Sección de Rúbricas de la Plataforma.
 Formato de entrega: WORD 2003, 2007 o PDF
 Guía para la elaboración de un mapa mental:
http://www.uaeh.edu.mx/docencia/VI_Lectura/educ_continua/LECT24.pdf
 Recursos:
https://www.pmsolutions.com/audio/Strategies_for_Project_Recovery_Research_Repor
t.pdf
 Si requiere un traductor para el documento puede utilizar el siguiente link:
http://www.onlinedoctranslator.com/translationform o
 http://translate.google.com/#en/es/
 Descarga en tu equipo el reporte en cuestión
 Clic en el link traduce documento
 Selecciona el archivo
 Clic en Traducir
 Semana 1 - Actividad 1 (15%):
 Parte 2
 Instrucciones: selecciona alguno de los dos casos de estudio
propuestos (opción 1 o 2) y con ello completa el Template adjunto que
describa la propuesta de un Plan de recuperación del Proyecto
seleccionado.
 Casos de estudio:
 Opción 1: https://www.theprojectlab.com/case-studies/project-recovery
 Opción 2: https://www.pmi.org/learning/library/project-recovery-dont-always-recover-
project-5998
 Rúbrica: las características del producto a entregar están definidas en la rúbrica
correspondiente en la Sección de Rúbricas de la Plataforma.
 Formato de entrega: WORD, POWERPOINT 2003, 2007 o PDF
 Recursos: TemplatePlanRecuperacionProyecto.docx
 Si requiere un traductor para el documento puede utilizar el siguiente link:
http://www.onlinedoctranslator.com/translationform o
 http://translate.google.com/#en/es/
 Descarga en tu equipo el reporte en cuestión
 Clic en el link traduce documento
 Selecciona el archivo
 Clic en Traducir
Semana 2 - Foro de discusión 5%:
 Después de revisar los contenidos de la semana 2:
 Responder a la pregunta inicial
 Retroalimentar por lo menos a dos de sus compañeros
 Agregar referencia sobre su comentario o aportación en el foro.
 Revisen por favor la rúbrica de evaluación de la actividad

 PREGUNTA DETONANTE:
 Desde tu punto de vista, ¿en qué momento (síntomas)
se debe considerar que el proyecto ya se encuentra
en estado de crisis?