Académique Documents
Professionnel Documents
Culture Documents
Recuperación de Proyectos
Maestría en Dirección de
Proyectos
MC Juan Francisco Monroy E
Webgrafía
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
Líderes de Proyecto
Definir objetivos estratégicos Buscar planeación de capacidad
Definir limitantes de Establecer las líneas base
financiamiento Evaluar riesgos de
Definir los factores del ambiente implementación
Definir el involucramiento de los Identificar las métricas o KPIs
ejecutivos 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
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
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:
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
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
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
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:
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.
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:
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?