Está en la página 1de 24

Suscríbete a DeepL Pro para poder editar este documento.

Entra en www.DeepL.com/pro para más información.

CAPÍTULO 3

Actividad del proyecto y planificación de riesgos

Si surgen problemas durante la vida de un proyecto, nuestra primera corazonada sería que el proyecto no fue
planeado adecuadamente. La mayoría de las veces nuestra corazonada sería correcta. La planificación inadecuada
es más el caso que la excepción. Sólo podemos adivinar por qué. Tal vez la razón sea que la alta dirección y/o el
primer ministro y/o el equipo del proyecto están impacientes. Quieren"seguir adelante". Posiblemente algunas de
las personas que deberían estar involucradas en la planificación han escuchado a Tom Peters, un conocido buscador
de la excelencia y gurú de la gestión, comentar que una buena planificación casi nunca reduce el tiempo de
implementación y que "Ready, Fire, Aim" es la forma en que los buenos negocios lo hacen.

De hecho, Peters está equivocado. Hay una tonelada de investigación que concluye que una planificación cuidadosa
está fuertemente asociada con el éxito del proyecto - y hasta donde sabemos, no hay investigación que apoye la
posición opuesta. Claramente, la planificación puede ser exagerada, una condición a menudo llamada "parálisis por
análisis". En algún lugar entre los extremos se encuentra el medio feliz que todo el mundo desearía alcanzar, pero
este capítulo no pretende definir la media de oro entre la falta de planificación y la sobreplanificación (Langley,
1995). Sin embargo, examinamos la naturaleza de una buena planificación y describimos métodos probados para
generar planes que sean adecuados para la tarea de dirigir una fuerza de trabajo del proyecto desde el comienzo
hasta su conclusión exitosa. Debemos empezar por decidir qué cosas deben formar parte de un plan de proyecto.

3.1 DE LA CARTA DEL PROYECTO AL PLAN DEL PROYECTO

Antes de considerar cómo planear, debemos decidir por qué estamos planeando y qué información debe contener
el plan. El proceso de planificación del proyecto comienza con el desarrollo de una carta de proyecto, una
descripción de alto nivel del proyecto. Aunque los elementos de la carta del proyecto varían de una organización a
otra, siempre deben incluir una declaración de trabajo y el caso de negocio del proyecto. La declaración de trabajo
describe los principales resultados del proyecto, mientras que el caso de negocio proporciona la justificación
financiera y estratégica del proyecto (por ejemplo, análisis de costo-beneficio, análisis de la demanda del mercado).
Se recomienda encarecidamente que el Primer Ministro participe en la elaboración de la carta del proyecto. Más
allá de la declaración del trabajo y del caso de negocio, el PMBOK sugiere que se incluyan los siguientes puntos
adicionales en la carta del proyecto:

- La necesidad empresarial del proyecto.

- Los supuestos en los que se basa el proyecto (por ejemplo, las preferencias de los clientes, el estado de la
economía).

- Principales limitaciones.

- Requerimientos del cliente.

- Identificación de riesgos de alto nivel.

- Hitos clave del proyecto.

- Un presupuesto de alto nivel.

- Una lista de las principales partes interesadas.

- El PM asignado al proyecto.

- Los límites del proyecto (es decir, lo que está dentro y fuera del alcance del proyecto).

Una vez aprobada la carta del proyecto, éste se considera oficialmente autorizado y se puede comenzar a trabajar
en el desarrollo de un plan de proyecto más detallado. Mientras que la carta del proyecto proporciona una
descripción de alto nivel del proyecto, el plan del proyecto define con mayor detalle el trabajo del proyecto que
debe ser completado. Más específicamente, el plan del proyecto detalla cómo el trabajo del proyecto será
ejecutado, monitoreado y controlado. Como tal, el plan del proyecto incluye descripciones detalladas del trabajo
que necesita ser completado, cómo se ejecutará el trabajo, el proceso de aprobación de los cambios al plan y los
planes para comunicarse con las partes interesadas. En su forma final, el plan de proyecto reúne todos los
documentos de planificación relacionados con el proyecto. Según el PMBOK, un plan de proyecto adecuado incluye
lo siguiente:

- El proceso de gestión del cambio

- Un plan de comunicación y gestión con los grupos de interés

- Especificar el proceso para establecer las características clave del proyecto a entregar (técnicamente denominado
gestión de configuración).

- Establecer la línea de base de costos para el proyecto y desarrollar un plan para administrar los costos del proyecto.

- Elaborar un plan de gestión de los recursos humanos asignados al proyecto.

- Desarrollar un plan para monitorear y mejorar continuamente los procesos de trabajo de los proyectos.

- Elaborar directrices para la adquisición de materiales y recursos del proyecto

- Definir el alcance del proyecto y establecer prácticas para gestionar el alcance del mismo.

- Desarrollo del plan de la estructura del proyecto

- Desarrollo de prácticas para la gestión de la calidad de los entregables del proyecto.

- Definir cómo se gestionarán los requisitos del proyecto

- Establecimiento de prácticas para la gestión del riesgo

- Establecer la línea de base del cronograma y desarrollar un plan para administrar el cronograma del proyecto.

Un sesgo hacia la realidad requiere que observemos que los diferentes actores tienen diferentes niveles de
influencia. Si la alta gerencia y el cliente están a favor de un cambio en el alcance del proyecto, el gerente del
proyecto y su equipo harían bien en aceptar el cambio de buena voluntad, a menos que haya alguna razón
primordial por la cual dicho cambio no sea factible. Ocasionalmente, las partes interesadas que no están
directamente relacionadas con la organización que lleva a cabo el proyecto o el cliente que lo compra pueden ser
tan exigentes que se les exige que aprueben cambios específicos. Consideremos, por ejemplo, People for the Ethical
Treatment of Animals (PETA) y sus batallas con las empresas de cosméticos sobre el uso de la experimentación
animal para productos cosméticos.

Un uso adicional para un plan de proyecto cuidadoso y completo es cuando el proyecto puede ser pequeño y
rutinario, pero también se lleva a cabo con frecuencia, como en algunos proyectos de mantenimiento. El proceso
completo de planificación puede llevarse a cabo para formar una plantilla para tales proyectos, con especial énfasis
en los métodos de evaluación. Con esta plantilla, la planificación de proyectos similares es sencilla, sólo tiene que
rellenar los espacios en blanco. Si se contemplan cambios en el plan, se pueden emplear los métodos de evaluación
prescritos. Esto permite que se implemente un programa de "mejora continua", a veces llamado planificación de
"onda rodante", con una evaluación continua de los cambios sugeridos.

La carta del proyecto es una versión preliminar de alto nivel del plan del proyecto para que todas las partes
interesadas la discutan y acuerden. Una vez aprobado, el plan del proyecto puede ser completado en detalle.

3.2 LA VISIÓN GENERAL DEL PROCESO DE PLANIFICACIÓN

Se ha escrito mucho sobre la planificación. Parte de la literatura se centra en el aspecto estratégico de la


planificación (por ejemplo, Webster, Reif y Bracker, 1989), la elección y planificación de proyectos que contribuyan
a los objetivos de la organización (véase la introducción a la Sección 1.5). Otro cuerpo de escritura está dirigido a
las técnicas de cómo planificar en lugar de qué planificar (por ejemplo, Pells, 1993; Prentis, 1989). Estas técnicas, si
queremos creer lo que leemos, difieren de una industria a otra, de un tema a otro. La arquitectura tiene un proceso
de planificación, el desarrollo de software, la construcción, los proyectos de I+D farmacéutica y las campañas de
recaudación de fondos para la beneficencia.

Hasta donde podemos determinar, la forma en que las técnicas de planificación varían en estos diferentes casos
tiene más que ver con la nomenclatura que con la sustancia. Considere, por ejemplo, el siguiente proceso de
planificación que se ha dividido en ocho pasos distintos.

1. Desarrollar y evaluar el concepto del proyecto. Describa lo que desea desarrollar, incluyendo sus características
básicas de rendimiento, y decida si vale la pena obtener dicho producto. Si es así, continúe.

2. Identifique y explique cuidadosamente las capacidades reales que debe tener el proyecto para que tenga éxito.
Diseñar un sistema (producto o servicio) que tenga las capacidades necesarias.

3. Crear tal sistema (producto o servicio), es decir, construir un prototipo entregable.

4. Pruebe el prototipo para ver si, de hecho, tiene las capacidades deseadas. Si es necesario, vuelva al paso 3 para
modificar el prototipo y volver a probarlo. Continúe hasta que la entrega cumpla con los requisitos preestablecidos.

5. Integrar el entregable en el sistema para el que fue diseñado. En otras palabras, instale el entregable en la
configuración requerida.

6. Validar el entregable, lo que responde a la pregunta: "Ahora que hemos instalado el entregable, ¿sigue
funcionando correctamente?

7. Si el entregable ha sido validado, deje que el cliente lo pruebe. ¿Puede el cliente operar el sistema? Si no es así,
instruya a la cliente.

8. Si el cliente puede operar (y acepta) el entregable, asegúrese de que entiende todos los requisitos estándar de
operación y mantenimiento. Luego, déle la mano al cliente, preséntele una copia escrita de las instrucciones de
mantenimiento y operación, entréguele la cuenta y váyase.

Vuelva a leer los ocho pasos. ¿No son una descripción adecuada del proceso de planificación para el diseño de una
nueva camioneta, de una habitación de hotel de lujo, de una cocina de restaurante, de una máquina herramienta,
de una línea de juguetes, etc.? Necesitarían un poco de ajustes para algunos proyectos. Un proyecto de I+D
necesitaría un análisis de riesgos más amplio. Si el proyecto es un nuevo fármaco, por ejemplo, necesitaría pruebas
de toxicidad y eficacia, y la aprobación de la FDA, pero la estructura general del proceso de planificación sigue
siendo adecuada.

Los ocho pasos anteriores fueron escritos originalmente para describir el proceso de planificación de software de
computación (Aaron, Bratta y Smith, 1993). Parece que hay tantas secuencias y pasos de planificación diferentes
como autores que escriben sobre la planificación. Casi todos ellos, independientemente del número de pasos,
cumplen los mismos criterios si están destinados a guiar un proyecto hacia una conclusión satisfactoria. El plan final
debe tener los elementos descritos en la sección anterior de este capítulo.

Hay muchas técnicas para desarrollar un plan de proyecto y una Carta de Proyecto. Son fundamentalmente
similares. Todos ellos utilizan un análisis sistemático para identificar y enumerar las cosas que deben
emprenderse para lograr los objetivos del proyecto, para probar y validar el plan y para entregarlo al usuario.

3.3 EL PROCESO DE PLANIFICACIÓN - TUERCAS Y PERNOS

Esta sección trata el problema de determinar y enumerar las diversas tareas que deben realizarse para completar
un proyecto. Los asuntos importantes de generar un presupuesto de proyecto y desarrollar un cronograma preciso
del proyecto se dejan para los capítulos siguientes, aunque gran parte de la materia prima para hacer esas cosas
importantes provendrá del proceso de planificación descrito aquí.

La reunión de lanzamiento y las reuniones subsiguientes

Una vez que el personal directivo superior haya decidido financiar un proyecto de gran envergadura, o un proyecto
pequeño de gran envergadura, se debe convocar una reunión de lanzamiento del proyecto. Se requiere preparación
para esta reunión (Knutson, 1995; Martin y Tate, 1998).
Cuando un Primer Ministro es designado para dirigir un nuevo proyecto, el primer trabajo del Primer Ministro es
revisar los objetivos del proyecto (el alcance del proyecto más los resultados deseables esperados que se derivan
para las partes interesadas de asuntos que van más allá de los entregables del proyecto) con el gerente principal
que tiene la responsabilidad fundamental del proyecto. El propósito de esta entrevista es triple: (1) asegurarse de
que el PM comprende las expectativas que la organización, el cliente y otras partes interesadas tienen para el
proyecto; (2) identificar a los altos directivos (además del directivo que participa en esta entrevista) que tienen un
interés importante en el proyecto; y (3) determinar si algo del proyecto es atípico para proyectos del mismo tipo
general (por ejemplo, un proyecto de desarrollo de productos/servicios emprendido con el fin de extender el
mercado de la empresa a una nueva área).

Con estos antecedentes, el Primer Ministro debe estudiar brevemente el proyecto con miras a preparar una lista
de invitados para la reunión de lanzamiento del proyecto. En la parte superior de la lista debe figurar por lo menos
un representante de la alta gerencia, una fuerte preferencia dada a la persona con mayor interés en el proyecto, el
probable campeón del proyecto. (El campeón suele ser, aunque no necesariamente, el gerente principal
responsable del proyecto). Recordemos que en el Capítulo 2 se señaló que el promotor del proyecto podría prestar
la influencia política que ocasionalmente se necesita para superar los obstáculos a la cooperación de los gerentes
funcionales, si tales obstáculos no fueran susceptibles de ser disueltos por el Primer Ministro.

A continuación en la lista de invitados se encuentran los gerentes de las áreas funcionales que serán llamados a
aportar competencias o capacidades al proyecto o a los miembros del equipo del proyecto si ya han sido
seleccionados. Si se necesitan expertos técnicos altamente especializados, el Primer Ministro puede añadir a la lista
a personas con la experiencia necesaria, después de despejar la invitación con sus jefes inmediatos, por supuesto.

El Primer Ministro puede presidir la reunión de lanzamiento, pero el gerente principal presenta el proyecto al grupo
y discute sus contribuciones a la organización matriz. Si se conoce y es pertinente, se puede anunciar la prioridad
provisional del proyecto, al igual que la estimación presupuestaria provisional utilizada en el proceso de selección
del proyecto. Si se han contratado los plazos de entrega de los productos, esto también debe quedar claro. El
objetivo de la presencia de la alta dirección es asegurar que el grupo comprende el compromiso de la empresa con
el proyecto. Es particularmente importante que los gerentes funcionales comprendan que la gerencia está
asumiendo un compromiso real, y no simplemente hablando de boquilla.

En este punto, el Primer Ministro puede hacerse cargo de la reunión y comenzar una discusión de grupo sobre el
proyecto. Sin embargo, es importante que el/los alto(s) directivo(s) permanezca(n) en esta discusión. La presencia
continua de estas augustas personas asegura más o menos la cooperación de las unidades funcionales. El propósito
de la discusión es desarrollar un entendimiento general de qué insumos funcionales necesitará el proyecto.

Algunas reuniones de lanzamiento se limitan a una lluvia de ideas sobre un problema. El resultado de dicha reunión
se muestra en la Tabla 3-1. En este caso, el Director de Recursos Humanos (RRHH) de una empresa mediana fue
invitado por el Director General a establecer un programa para mejorar la retención de los empleados. En ese
momento, la empresa tenía una tasa de rotación ligeramente superior al 60 por ciento anual entre sus empleados
técnicos. El Director de Recursos Humanos celebró una reunión de lanzamiento de todos los jefes de departamento.
En esta reunión, el grupo elaboró una lista de "elementos de acción", cada uno de los cuales se convirtió en un
proyecto.

Cuando se trata de un solo proyecto, es común que se genere un plan preliminar en la reunión de lanzamiento,
pero nos preguntamos si es aconsejable. No es prudente que los gerentes funcionales o el Primer Ministro adivinen
los presupuestos o calendarios sin un estudio real de los resultados del proyecto. En primer lugar, la transición de
un "cálculo aproximado" tímido y descabellado realizado por los altos directivos o la EPMO a un "pero prometido"
es instantánea en estos casos. En segundo lugar, no hay base para la discusión o negociación mutua sobre las
diferentes posiciones tomadas públicamente y basadas en tan poco conocimiento o pensamiento. Es suficiente, a
nuestro juicio, obtener un compromiso firme de los gerentes funcionales para estudiar el proyecto propuesto y
regresar para otra reunión con un plan técnicamente (y políticamente) viable para la contribución de su grupo al
proyecto.

Tabla- 31 Salida de la reunión de lanzamiento del programa: Desarrollo de los recursos humanos

Objetivo del Programa: Reducir la rotación de empleados del 60 por ciento al 40 por ciento de Gerente de
Programa: Director de Recursos Humanos
Objetivo Medida a tomar
Mejorar la moral de los empleados - Recopilar datos de:
- Entrevistas de salida
- Encuesta de empleados
- Auditoría cultural
- Entrevistar a los empleados "retenidos
- Seminarios para todo el personal sobre tipos de personalidad y estilos de
trabajo
- Se implementó un gimnasio para empleados
- Almuerzos para nuevos empleados con los jefes de departamento
- Reuniones de "30 días" de nuevas contrataciones
- Formulario completo para la apertura de una guardería infantil
- Revisión del programa de orientación de empleados
-Análisis competitivo de los salarios y ajustes realizados
Ampliar las competencias del - Se han completado las competencias para todos los puestos y se ha
personal establecido un sistema para mantener las competencias en curso
Lograr un mayor compromiso de los - Serie de seis semanas sobre gestión y liderazgo para directivos
empleados con los estándares de la - Capacitación en liderazgo para supervisores
organización en cuanto a - Desarrollo de un sistema de remuneración basado en el rendimiento
productividad, resultados y - El formato de las descripciones de puestos de trabajo se ha rediseñado
satisfacción del cliente. en torno a las normas de eficacia de la organización
Mejorar los esfuerzos de - Aumentar los esfuerzos de reclutamiento, publicidad adicional, tres ferias
reclutamiento de empleo
- Contratar a un reclutador
- Implementar un plan de pensiones de contribución definida para los
nuevos empleados
- Línea directa de empleo por Internet
- Anuncios de radio

Se ha dicho: "Si esto significa muchas reuniones de planificación y un uso extensivo de la toma de decisiones
participativa, entonces bien vale la pena el esfuerzo (Ford y McLaughlin, 1992, p. 316). Si el énfasis está en la "toma
de decisiones participativa", estamos de acuerdo. La planificación real en la reunión de lanzamiento no debe ir más
allá del nivel más agregado, a menos que se comprendan bien los resultados o que la fecha de entrega sea concreta
y la organización tenga una experiencia considerable con proyectos similares. Por supuesto, si este es el caso, puede
que no sea necesaria una reunión de lanzamiento importante.

Los resultados de la reunión de lanzamiento deberían ser los siguientes: (1) el alcance del proyecto se entiende y
se fija temporalmente; (2) los diversos gerentes funcionales o miembros del equipo entienden sus
responsabilidades y se han comprometido a desarrollar una tarea inicial y un plan de recursos; y (3) se anotan todos
los beneficios potenciales para la organización fuera del alcance del proyecto. En las reuniones siguientes, el plan
del proyecto será cada vez más detallado y firme. Cuando el grupo ha desarrollado lo que parece ser un plan viable
con un cronograma y un presupuesto que parecen factibles, el plan se mueve a través de los niveles de manejo
apropiados donde es aprobado, o alterado y aprobado. Si se modifica, debe ser verificado con los que hicieron la
planificación. Los planificadores pueden aceptar las modificaciones o hacer una contrapropuesta. El plan de
proyecto puede subir y bajar la escala gerencial varias veces antes de recibir la aprobación final, momento en el
cual no se pueden hacer más cambios sin una orden de cambio formal (un procedimiento también descrito en el
plan).

Independientemente de quién altere (o sugiera alteraciones) el plan del proyecto durante el proceso descrito
anteriormente, es imperativo que todos estén plenamente informados. No es más equitativo para un alto directivo
cambiar un plan sin consultar con el Primer Ministro (y, por lo tanto, con el equipo del proyecto) de lo que sería
para el Primer Ministro o el equipo alterar el plan sin consultar y obtener la aprobación de la alta dirección. Si se
trata de un cliente en condiciones de independencia mutua, se requiere la aprobación del cliente para cualquier
cambio que tenga un efecto en el cronograma, el costo o los resultados. Evidentemente, la PMO (o EPMO) puede
facilitar este proceso.
Una herramienta útil para facilitar la gestión de los cambios en el alcance de un proyecto es la Matriz de Trazabilidad
de Requisitos. Con esta matriz, se crea una tabla que vincula la fuente de cada requisito del proyecto con los
objetivos del proyecto, los entregables del PEP, y así sucesivamente con la intención de satisfacerlo. Una variedad
de campos (columnas) pueden ser incorporados en la Matriz de Trazabilidad de Requisitos dependiendo del uso
previsto de la matriz. Una búsqueda rápida en la Web dará como resultado una variedad de plantillas listas para su
uso. Un ejemplo se muestra en PMBOK, 5ª ed., Fig. 5-6 (p. 119).

La comunicación abierta, honesta y frecuente entre las partes interesadas es fundamental para el éxito de la
planificación. Lo que surge de este proceso a veces se denomina plan de línea de base del proyecto. Contiene todos
los elementos mencionados en la sección 3.1 y todas las modificaciones del plan adoptadas a medida que se lleva
a cabo el proyecto.

Clasificación del proyecto: el plan de la estructura del proyecto (PEP)

Una planificación inicial inadecuada, especialmente si no se identifican todas las tareas importantes, es uno de los
principales factores que contribuyen a que un proyecto no logre sus objetivos de costo y tiempo. Por lo tanto, uno
de los principales objetivos del desarrollo de un PEP es garantizar que no se pase por alto ninguna tarea necesaria
para producir un producto final y que, por lo tanto, no se contabilice ni planifique. El PMBOK describe la
construcción del PEP principalmente en el Capítulo 5 sobre Alcance, pero también se aborda en los Capítulos 6
(Tiempo), 7 (Costo) y 8 (Calidad).

En la subsección anterior se discutió el proceso de planificación visto desde el exterior. El Primer Ministro y los
gerentes funcionales desarrollaron planes como por arte de magia. Ahora es el momento de ser específicos sobre
cómo se pueden generar dichos planes. Para desarrollar un plan de proyecto que nos lleve de principio a fin de un
proyecto, necesitamos saber exactamente qué se debe hacer, por quién, cuándo y con qué recursos. Cada tarea,
por pequeña que sea, que deba ser completada para completar el proyecto debe ser enumerada junto con cualquier
recurso material o humano requerido.

Hacer tal lista no es un trabajo trivial. Requiere un procedimiento sistemático. Si bien hay varios procedimientos
sistemáticos que pueden utilizarse, aconsejamos una manera directa y conceptualmente simple de atacar el
problema -el proceso de planificación jerárquica- que es cómo construir una Estructura de División del Trabajo (EDT)
para el proyecto.

Para utilizar este proceso, uno debe comenzar con el objetivo u objetivos del proyecto. El planificador, a menudo
el Primer Ministro, hace una lista de las principales actividades que deben completarse para lograr los objetivos. La
lista puede ser tan corta como dos o tres actividades, o tan grande como 20. Normalmente el número está entre 5
y 15. A estas actividades las llamamos de Nivel 1. El planificador ahora toma cada actividad del Nivel 1 y la delega a
un grupo individual o funcional. (El Primer Ministro puede delegar una o más tareas de Nivel 1 en sí mismo.) El
delegado se ocupa de la tarea como si fuera en sí mismo un proyecto y hace un plan para llevarlo a cabo; es decir,
enumera un conjunto específico de tareas de Nivel 2 necesarias para completar cada tarea de Nivel 1. Una vez más,
el desglose suele ser de entre 5 y 15 tareas, pero unas cuantas más o menos no importan. El proceso continúa. Para
cada tarea de Nivel 2, se delega en alguien o en algún grupo la responsabilidad de preparar un plan de acción de
subtareas de Nivel 3. El procedimiento de descomponer sucesivamente las tareas de mayor envergadura en sus
componentes continúa hasta que las subtareas de menor nivel se entienden lo suficiente como para que no haya
razón para continuar. Como regla general, las tareas de nivel más bajo en un proyecto típico tendrán una duración
de unas pocas horas a unos pocos días. Si el equipo está bastante familiarizado con el trabajo, se aceptan duraciones
más largas para las tareas de menor nivel.

Otro enfoque sencillo para crear el PEP consiste en reunir al equipo del proyecto y proporcionar a cada miembro
un bloc de notas adhesivas. Después de definir los objetivos del proyecto y las tareas del Nivel 1, los miembros del
equipo escriben en las notas adhesivas todas las tareas que se les ocurran y que son necesarias para completar el
proyecto. Las notas adhesivas pueden colocarse en la pared y colocarse de varias maneras. Una de las ventajas de
este enfoque es que proporciona a todo el equipo una mejor comprensión del trabajo necesario para completar el
proyecto. El hecho de que sea un ejercicio de cooperación también ayuda al equipo del proyecto a establecer
vínculos. Finalmente, este ejercicio puede generar un árbol PEP. La Figura 3-1 ilustra el árbol. Un colega llamó a
esto una"carta de Gozinto". (Dijo que fue nombrado en honor a un famoso matemático italiano, el Prof. Zepartzat
Gozinto. El nombre se ha pegado.)
Microsoft Project (MSP) creará una lista WBS (pero no un gráfico de árbol) con sólo tocar una tecla. Los niveles de
tarea se identifican adecuadamente; por ejemplo, el número de PEP "7.5.4" se refiere al "Nivel 3, tarea número 4"
que se necesita para el "Nivel 2, tarea 5" que forma parte del "Nivel 1, tarea 7". (El PM tiene la opción de utilizar
cualquier otro sistema de identificación que desee, pero debe introducir los identificadores manualmente.)

Los niveles de tareas se organizan adecuadamente en la impresión MSP, con las tareas de Nivel 1 a la izquierda y
otras sangradas por nivel. Si se utiliza un diagrama de árbol y cada tarea está representada por una casilla con el
número de identificador PEP, se puede añadir cualquier información que se desee, dado que cabrá en la casilla. Tal
entrada podría ser el número de cuenta apropiado para cobrar por el trabajo realizado en esa tarea, o el nombre
de la persona (o departamento) con la responsabilidad de la tarea, o con un espacio para la firma de la parte
responsable que denote que la persona ha aceptado la rendición de cuentas mediante la "firma". Como veremos,
a menudo se añade información adicional convirtiendo el "árbol" en una lista con columnas para los datos
adicionales.

Al realizar la planificación jerárquica, sólo una regla parece ser obligatoria. En cualquier nivel, la "generalidad" o el
"grado de detalle" de las tareas debería estar aproximadamente al mismo nivel. No se deben utilizar tareas muy
detalladas para los planes de Nivel 1, y no se deben añadir tareas muy generales en el Nivel 3 o más. La mejor
manera de hacer esto es encontrar todas las subtareas de Nivel 2 para cada tarea de Nivel 1 antes de mover la
atención a las subtareas de Nivel 3. Del mismo modo, divida todas las tareas del Nivel 2 en sus respectivas tareas
del Nivel 3 antes de considerar cualquier subtarea del Nivel 4, si el desglose llega tan lejos. Un amigo nuestro que
era un artista de renombre internacional y profesor de diseño industrial nos explicó por qué. Al producir una pintura
o un dibujo, el artista dibuja primero en las líneas principales de la composición de la escena. El artista luego agrega
detalles, poco a poco, sobre todo el dibujo, continuando este proceso hasta que la obra esté terminada. Si esto se
hace, la obra terminada tendrá "unidad". La unidad no se logra si las áreas individuales del cuadro se completan en
detalle antes de pasar a otras áreas. Luego, una joven estudiante de arte hizo un bosquejo con pluma y tinta de
otra estudiante, mostrando su progreso en tres etapas diferentes (ver Figura 3-2).

Figura- 31 Un WBS parcial (gráfico de Gozinto) para un proyecto de Cena Tributo Anual.

Hemos dicho que el desglose de las tareas del nivel 1 debería delegarse en alguien que lleve a cabo las tareas del
nivel 2. Lo mismo ocurre con las tareas de nivel 2 que se delegan a alguien que diseñará y llevará a cabo las tareas
de nivel 3 requeridas. Una pregunta relevante es: "¿Quiénes son todos estos delegados?" Supongamos que el
proyecto en cuestión es de un tamaño razonable, ni muy grande ni muy pequeño. Supongamos además que el
Primer Ministro y los directores funcionales tienen una experiencia razonable en proyectos similares. En tal caso,
el Primer Ministro probablemente comenzaría por trabajar en el Nivel 1. Basándose en sus antecedentes, el Primer
Ministro podría trabajar en el Nivel 2 de una o más de las tareas del Nivel 1. En los casos en que faltara experiencia
reciente, delegaría en el gerente funcional adecuado la tarea de especificar las tareas del nivel 2. De la misma
manera, este último delegaría la especificación de las tareas del Nivel 3 a las personas que tengan los conocimientos
adecuados.

En general, el trabajo de planificación debe delegarse al nivel de competencia más bajo. En el Nivel 1, éste suele
ser el primer ministro. En los niveles inferiores, los gerentes funcionales y los especialistas son los mejores
planificadores. En el Capítulo 2 (Sección 2.1) describimos ese extraño bugbear, el micromanager. Es común que los
microadministradores se adelanten a la función de planificación de los subordinados o, como alternativa, que
permitan al subalterno desarrollar un plan inicial que el microadministrador modificará con resultados
potencialmente desastrosos. Este último es un evento reportado con cierta frecuencia (y precisión) en Dilbert©.

Figura- 32 Tres niveles de detalle en la planificación jerárquica.

Extensiones del PEP de todos los días

El PEP se puede remodelar y reforzar con algunos datos adicionales que a menudo no se incluyen en el PEP del
proyecto. El PEP está generalmente orientado hacia los resultados del proyecto. Las adiciones aumentan su
orientación hacia la planificación y administración de la obra. Para ello, utiliza el material disponible y adopta un
formato que no suele utilizar el PEP. La Figura 3-3 ilustra una disposición que ayuda a organizar la información
requerida. Nos referimos a estos layouts como PEP "modificados". Los datos adicionales en las columnas son: (1)
estimaciones de los recursos necesarios para cada tarea del plan, (2) el tiempo estimado necesario para llevar a
cabo cada tarea, (3) información sobre quién tiene la responsabilidad de la tarea, y (4) datos que permitan
secuenciar las tareas para que el conjunto pueda completarse en el menor tiempo posible. Una vez que se conoce
la fecha de inicio del proyecto, el punto 2 de la lista anterior se puede cambiar del tiempo requerido para la
finalización de una subtarea a la fecha en la que está programada su finalización.

Para entender la importancia del punto 4 de la lista, considere una serie de subtareas, todas las cuales deben ser
completadas para lograr una tarea de los padres en un nivel superior. Es común en tal conjunto que una o más
subtareas (A) deben ser completadas antes de que una o más subtareas (B) puedan ser iniciadas. Se dice que las
tareas anteriores (A) son las predecesoras de las tareas sucesivas (B). Por ejemplo, si nuestro proyecto es pintar las
paredes de una habitación, sabemos que antes de aplicar la pintura a una pared, debemos realizar una serie de
tareas previas. Estos predecesores incluyen: limpiar el área del piso cerca de la pared que se va a pintar y cubrir con
paños de gota; quitar los cuadros de la pared; limpiar la suciedad suelta, el aceite, la grasa, las manchas y similares
de la pared; rellenar y alisar cualquier grieta u hoyo en la pared; lijar ligeramente o rayar la pared si se ha pintado
previamente con pintura de alto brillo; limpiar con un paño húmedo o una esponja para quitar el polvo del lijado;
y enmascarar cualquier área circundante donde no se desee pintar esta pintura. Todas estas tareas son
predecesoras de la tarea "Pintar las paredes".
Figura- 33 Un formulario para ayudar a la planificación jerárquica.

Las tareas previas para "pintar las paredes" se han enumerado en el orden en que podrían realizarse si sólo trabajara
una persona. Si hay varias personas disponibles, se pueden realizar varias de estas tareas al mismo tiempo. Tenga
en cuenta que si se pueden realizar tres tareas simultáneamente, el tiempo total requerido es el tiempo necesario
para el más largo de los tres, no la suma de los tres tiempos de las tareas. Este concepto es crítico para la
programación, por lo que los predecesores deben estar listados en el PEP. Una convención es importante. Cuando
se enumeran los predecesores, sólo se enumeran los predecesores inmediatos. Si A precede a B y B precede a C,
sólo B es un predecesor de C.

El PEP no sólo identifica el entregable, sino que también puede anotar la fecha de inicio si se conoce u otra
información que se desee mostrar. Una vez que las subtareas y sus predecesores han sido listados junto con los
tiempos estimados de actividad de las subtareas, la duración probable del conjunto de subtareas, y por lo tanto la
fecha de vencimiento de la tarea, puede ser determinada como veremos en el Capítulo 5. Si las estimaciones de la
duración y los requisitos de recursos para llevar a cabo las subtareas están sujetas a limitaciones (por ejemplo, no
se permiten horas extras) o suposiciones (por ejemplo, no habrá paros de trabajo en la planta de nuestro
subcontratista), éstas se deben anotar en el PEP.

Si se desea, la información en la forma mostrada en la Figura 3-3 puede ser introducida directamente en Microsoft
Project® (MSP). Alternativamente, se puede producir un PEP usando MSP, directamente, como se muestra en la
Figura 3-4. El título del proyecto puede introducirse en un encabezado o pie de página del formulario, al igual que
otra información como una breve descripción de los entregables, el nombre del PM o del administrador de tareas,
las fechas de inicio y/o vencimiento del proyecto, y otros datos similares.

La Tabla 3-2 muestra un PEP generado en MSP con la duración de las tareas y las horas de inicio y finalización de
las tareas de Nivel 1 en un proyecto de control de infecciones. El proyecto comienza el 12 de septiembre y termina
el 30 de noviembre. Como es habitual, las personas trabajan una semana de cinco días, de modo que una tarea de
tres semanas tiene 15 días laborables y 21 días naturales (tres semanas), suponiendo que el individuo o equipo esté
trabajando a tiempo completo en la tarea. Como veremos en el Capítulo 5, uno usualmente no se atreve a hacer
esa suposición y debe revisar cuidadosamente para determinar si es o no un hecho. Si la persona que realiza la
tarea trabaja a tiempo parcial, una tarea que requiere 5 días de trabajo, por ejemplo, puede requerir varias semanas
de tiempo de calendario. Volveremos a tratar este problema en el capítulo 5.

MSP hace que la tarea de planificación del Nivel 1 de las tareas generales del proyecto sea bastante sencilla. Lo
mismo ocurre cuando los planificadores desean generar una lista más detallada de todos los pasos que intervienen
en un proyecto. El Primer Ministro simplemente enumera las tareas generales identificadas por el equipo de
planificación como las actividades necesarias para producir los resultados del proyecto, por ejemplo, los resultados
de una sesión de lluvia de ideas. El PM y el equipo de planificación pueden entonces estimar la duración de las
tareas y utilizar MSP para crear un PEP. La Tabla 3-3 muestra una plantilla de planificación utilizada por una
compañía de software cuando tienen sus reuniones iniciales de lluvia de ideas sobre la entrega a petición del cliente.

MSP tiene un asistente de planificación que guía al PM a través del proceso de identificación de todo lo que es
necesario para tomar una idea para una actividad de proyecto y convertirla en un PEP útil.

Una empresa de soporte de sistemas informáticos realizó repetidamente los mismos pasos cuando los clientes
solicitaban la instalación de una red de área local (LAN). Trataron cada trabajo como si fuera un nuevo proyecto,
porque los costos y las asignaciones de recursos variaban con cada asignación. Para mejorar la eficiencia,
desarrollaron una plantilla de planificación utilizando MSP. Después de reunirse con un cliente, el gerente de
proyecto puede agregar la fecha de inicio del proyecto acordada, y cualquier restricción en el cronograma requerido
por el cliente. Los pasos para instalar la LAN siguen siendo los mismos. Las fechas de inicio y finalización, y el número
de recursos necesarios para cumplir con el cronograma se ajustaron para cada cliente individual, pero los ajustes
fueron generalmente pequeños. Una vez que se ha decidido el calendario de un trabajo específico, el Primer
Ministro puede determinar los recursos necesarios para cumplir con ese calendario y determinar el costo del
proyecto. Si el PM desea incluir otra información en el PEP modificado del proyecto, no hay razón para no hacerlo.
Algunos incluyen una columna para listar el estado de disponibilidad de recursos o personal. Otros enumeran las
fechas de inicio de las tareas.

Figura- 34 Un PEP como salida de MSP.

Tabla- 32 Un PEP que muestra tareas de nivel 1 para un proyecto de control de infecciones (MSP)
Tabla- 33 Plantilla para una reunión de planificación de lluvia de ideas

La reunión de lanzamiento del proyecto establece el alcance del proyecto, suscita la cooperación de otros en
la organización, demuestra el compromiso de la gerencia con el proyecto e inicia el plan del proyecto. El plan
en sí mismo se genera a través de un proceso de planificación jerárquica mediante el cual las partes del plan
se desglosan secuencialmente en niveles más finos de detalle por parte de los individuos o grupos que las
implementarán. El resultado es un PEP que lista todas las tareas necesarias para llevar a cabo el plan junto
con las necesidades de recursos de la tarea, las duraciones, los predecesores y la identificación de los
responsables de cada tarea.

3.4 MÁS SOBRE EL PLAN DE LA OBRA Y OTRAS AYUDAS

A veces, los movimientos populares parecen olvidar que muchos de los formularios, gráficos y tablas
convencionales que deben rellenar tienen la intención de servir de ayuda, no de castigo. También olvidan que las
formas, tablas y tablas no están fundidas en bronce, pero, al igual que las recetas de Emeril, pueden ser cambiadas
para que se ajusten al gusto del Primer Ministro. Además de los temas que acabamos de tratar, hay más sobre el
PEP y otras dos ayudas útiles -la Matriz Responsable-Contable-Consultas-Informada (Matriz RACI), y el Mapeo
Mental- que merecen ser discutidas.

El proceso de creación de un PEP es significativo. El Primer Ministro y los miembros individuales del equipo pueden
diferir en el enfoque técnico para trabajar en la tarea, el tipo y la cantidad de recursos necesarios, o la duración de
cada subtarea. Si es así, la negociación puede acompañar el proceso de planificación. Como de costumbre, el
manejo participativo y la negociación a menudo conducen a un mejor desempeño del proyecto y a mejores formas
de alcanzar sus objetivos.

La Matriz RACI

Al igual que el WBS, la Matriz RACI viene en una variedad de tamaños y formas. Típicamente, la matriz RACI tiene
la forma de una tabla con las tareas del proyecto derivadas del PEP listadas en las filas y departamentos o individuos
en las columnas. El PMBOK describe la matriz de la RACI en el Capítulo 9 sobre Recursos Humanos. El valor de la
Matriz RACI es que ayuda a organizar el equipo del proyecto al aclarar las responsabilidades de los miembros del
equipo del proyecto. Para un ejemplo de una simple Matriz RACI, vea la Figura 3-5.

En la Figura 3-5, las letras se utilizan para indicar la naturaleza del vínculo de responsabilidad entre una persona y
una tarea. Tenga en cuenta que debe haber al menos una A en cada fila, lo que significa que alguien debe ser
responsable de la realización de cada tarea. Por ejemplo, examine la línea con la tarea "Solicitar ofertas". En este
caso, el Ingeniero de Proyecto es responsable de la tarea que se está llevando a cabo, mientras que el Gerente de
Campo será responsable de realizar el trabajo asociado con la solicitud de cotizaciones. El Administrador de
Contratos del proyecto y el Oficial de Cumplimiento/Gerente de Riesgos deben ser consultados sobre el proceso de
solicitud. Se debe informar al PM antes de enviar los documentos a los proveedores potenciales. Tenga en cuenta
que a un individuo o departamento en particular se le pueden asignar múltiples enlaces de responsabilidad. Por
ejemplo, es común que una persona sea responsable de una tarea en particular.

Se dispone de plantillas de matrices RACI estándar para facilitar su desarrollo. Uno puede usar símbolos o números
en lugar de letras para referirse a diferentes relaciones de responsabilidad, y las referencias pueden ser a
departamentos, títulos de trabajo o nombres. Sólo la imaginación y las necesidades del proyecto y de PM unieron
la variedad potencial. Asimismo, se pueden agregar columnas adicionales a la Matriz RACI para capturar las fechas
de vencimiento de las tareas, las fechas reales de finalización, el estado de las tareas, las métricas de rendimiento,
etc.
Es necesario hacer una última observación sobre este tema. Cuando hablamos con los gerentes funcionales sobre
la gestión de proyectos, un comentario que escuchamos a menudo es la ira sobre los cambios en el plan del
proyecto sin notificar a las personas que se supone que deben llevar a cabo las tareas o prestar servicios al proyecto.
Una cita del jefe de un laboratorio de estadísticas en una gran empresa de consultoría es típica. El jefe del
laboratorio hablaba del director de un proyecto de consultoría para una agencia gubernamental cuando dijo:
"Saqué a tres de mis mejores personas de otros trabajos para reservarlas para el análisis de datos sobre el proyecto
XYZ. Se sentaron durante días esperando los datos. Ese idiota[el Primer Ministro] sabía que los datos llegarían tarde
y nunca se molestó en decírmelo. y me pidió que acelerara nuestro análisis para que pudiera recuperar el tiempo
perdido".

Asegúrese de utilizar la categoría Informar, no sólo para informar sobre el progreso, sino también para informar
sobre los cambios en las fechas de vencimiento, los requisitos de recursos, etc.

Figura- 35 Un ejemplo de la Matriz RACI.

Un enfoque integral de la planificación de proyectos

En el entorno tan competitivo de hoy en día, los equipos de proyecto se enfrentan a una presión cada vez mayor
para alcanzar los objetivos de rendimiento de los proyectos, al mismo tiempo que completan sus proyectos a
tiempo y a tiempo. Típicamente, los gerentes de proyecto y los miembros del equipo de proyecto dependen del
lado "izquierdo" o de la parte analítica del cerebro para abordar los desafíos. De hecho, si usted es un estudiante
de negocios o de ingeniería, la gran mayoría de las técnicas a las que ha estado expuesto en sus estudios se basan
en el lado izquierdo lógico y analítico de su cerebro. Por otro lado, los estudiantes de arte y diseño tienden a estar
expuestos a técnicas que dependen más de la imaginación y de imágenes que utilizan el lado "derecho" creativo
del cerebro. Es importante destacar que muchas de las actividades asociadas con la gestión de proyectos pueden
facilitarse en gran medida mediante el uso de un enfoque integral más equilibrado (Brown y Hyer, 2002).

Un enfoque integral que es particularmente aplicable a la gestión de proyectos en general, y a la planificación de


proyectos en particular, es el mapeo mental. El mapeo mental es esencialmente un enfoque visual que refleja
fielmente la forma en que el cerebro humano registra y almacena la información. Además de su naturaleza visual,
otra ventaja clave asociada con el mapeo mental es que ayuda a aprovechar el potencial creativo de todo el equipo
del proyecto, lo que, a su vez, ayuda a aumentar tanto la cantidad como la calidad de las ideas generadas. Debido
a que los miembros del equipo del proyecto tienden a encontrar entretenido el mapeo mental, también ayuda a
generar entusiasmo, ayuda a conseguir la aceptación de los miembros del equipo y a menudo hace que los
miembros del equipo más silenciosos se involucren más en el proceso de planificación.

Para ilustrar la creación de un mapa mental, considere un proyecto lanzado en una escuela de negocios de
postgrado para mejorar su programa de MBA vespertino a tiempo parcial para profesionales en activo. El ejercicio
de mapeo mental se inicia pegando una hoja de papel grande (por ejemplo, 6 pies × 3 pies) en una pared. (Una
buena fuente de este tipo de papel es un rollo de papel de envoltura de carnicero. Se pueden pegar varias hojas
juntas para crear un área más grande si es necesario.) Se recomienda que el papel se oriente en modo horizontal
para ayudar a estimular la creatividad del equipo, ya que la gente está acostumbrada a trabajar en modo vertical.
Además, los miembros del equipo deben estar de pie durante el ejercicio de mapeo mental.
El proceso comienza escribiendo la meta del proyecto en el centro de la página. Como se ilustra en la Figura 3-6, el
equipo del proyecto MBA a tiempo parcial definió el objetivo del proyecto como la generación de ideas para un
rendimiento innovador en el programa MBA a tiempo parcial. En particular, observe el lenguaje inspirador utilizado
para definir el objetivo del proyecto, que ayuda a motivar aún más a los miembros del equipo y a estimular su
creatividad.

Una vez definida la meta del proyecto, los miembros del equipo pueden hacer una lluvia de ideas para identificar
las tareas principales que se deben hacer para lograr esta meta. Al desarrollar el mapa mental para el proyecto, el
equipo de MBA identificó inicialmente cuatro tareas principales: (1) definir el papel de los programas profesionales
de trabajo (WPPs), (2) generar ideas para mejorar los programas actuales, (3) generar ideas para la diversificación
y (4) evaluar las ideas generadas. Como se ilustra en la Figura 3-7, estas tareas principales se separan del objetivo
del proyecto.

El desarrollo del mapa mental procede de esta manera, por lo que los componentes del mapa mental se dividen
continuamente en tareas más detalladas. Por ejemplo, la Figura 3-8 muestra cómo se dividió la función de definición
de la tarea del WPP en tareas más detalladas. La Figura 3-9 proporciona el mapa final para el proyecto de MBA.

Figura- 36 Comience el mapeo mental con una declaración del objetivo del proyecto.

Figura- 37 Las tareas principales se ramifican a partir de la meta del proyecto.


Figura- 38 Las tareas principales se dividen a su vez en tareas más detalladas.

Figura- 39 Mapa mental final para un proyecto de MBA a tiempo parcial.

Un par de comentarios sobre el proceso de mapeo mental están en orden. En primer lugar, el color, el tamaño de
la palabra, la forma de la palabra y las imágenes deben utilizarse para añadir énfasis. De hecho, se debe animar a
los miembros del equipo a utilizar imágenes e imágenes en el mapa mental sobre el uso de palabras. El cerebro
procesa y responde a los símbolos e imágenes de manera diferente que a las palabras. Cuando se usan palabras, se
deben usar palabras clave en lugar de oraciones completas. Además, debe tenerse en cuenta que está bien ser
desordenado cuando se desarrolla el mapa mental original. De hecho, uno no debería esperar que el mapa mental
original se asemeje a algo tan pulido como el mapa mental mostrado en la Figura 3-9. Más bien, el mapa mental
típicamente necesitará pasar por varias iteraciones de pulido y refinamiento. También debe tenerse en cuenta que
el pulido y el refinado pueden ser facilitados en gran medida con el uso de un programa de gráficos por ordenador.

Además, múltiples miembros del equipo pueden y deben contribuir al mapa mental simultáneamente. De hecho,
se debe designar formalmente a un miembro del equipo como facilitador para asegurar que todos los miembros
del equipo estén contribuyendo, para mantener a los miembros del equipo enfocados en el proyecto, y para
asegurar que los miembros del equipo estén enfocados en las tareas del proyecto y no en las metas. Finalmente,
en el nivel más detallado, las tareas deben ser expresadas usando un sustantivo y un verbo (por ejemplo, desarrollar
medidas, generar ideas, definir resultados).

Desafortunadamente, es muy común que los proyectos excedan el presupuesto y/o se completen tarde. En muchos
casos, la falta de planificación inicial es el principal culpable. Con una planificación inicial inadecuada, se pasan por
alto tareas importantes, lo que a su vez da como resultado una subestimación del presupuesto y la duración del
proyecto. El mapeo mental es una herramienta rápida y efectiva que puede facilitar enormemente la planificación
de proyectos y ayudar a minimizar los problemas que resultan de una planificación inicial inadecuada.

Un mapa mental pulido y refinado facilita una serie de otras actividades relacionadas con el proyecto. Por ejemplo,
el mapa mental puede convertirse fácilmente en el PEP tradicional. Además, el mapa mental puede utilizarse para
facilitar el análisis de riesgos, establecer agendas de reuniones del equipo del proyecto, asignar recursos a las
actividades del proyecto y desarrollar el cronograma del proyecto (véase Brown y Hyer, 2002, para más detalles
sobre el uso del mapa mental para la gestión del proyecto).

La Matriz de Estructura de Diseño

El enfoque de mapeo mental que se acaba de describir es un excelente complemento de las herramientas
tradicionales de gestión de proyectos, como la estructura de desglose del trabajo, para ayudar a identificar las
tareas que deben ejecutarse para completar un proyecto. Otras herramientas de planificación de la gestión de
proyectos, como los diagramas de Gantt y los diagramas de precedencia (ambos tratados en el Capítulo 5), se
desarrollaron principalmente para coordinar la ejecución de estas tareas. Estas herramientas se desarrollaron
originalmente para ayudar a gestionar proyectos de gran envergadura pero relativamente bien estructurados,
como proyectos de construcción y construcción naval. Sin embargo, en algunos casos, como en los proyectos de
desarrollo de nuevos productos, la cuestión de los flujos de información puede ser tan importante como la
secuencia de tareas. En esencia, las herramientas tradicionales de planificación de la gestión de proyectos ayudan
a identificar las tareas que deben completarse para que se puedan iniciar otras tareas. Sin embargo, a menudo, una
cuestión más importante es qué información se necesita de otras tareas para completar una tarea específica.

Para abordar la cuestión de los flujos de información, Steven Eppinger (2001), profesor de la Sloan School of
Management del MIT, propone el desarrollo y uso de una Matriz de Estructura de Diseño (DSM). El primer paso
para desarrollar un DSM es identificar todas las tareas del proyecto y enumerarlas en el orden en que se llevan a
cabo normalmente. Esta lista de tareas constituye tanto las filas como las columnas del DSM. A continuación,
moviéndose a través de una fila a la vez, se anotan todas las tareas que suministran información a la tarea que se
está evaluando. Cuando se completa el DSM, todas las tareas que proporcionan la información necesaria para
completar una tarea dada se pueden determinar mirando a través de la fila de esa tarea en particular. Del mismo
modo, al mover hacia abajo la columna de una tarea en particular, se muestran todas las demás tareas que
dependen de ella para obtener información.

En la Figura 3-10 se muestra un ejemplo de DSM correspondiente a un proyecto con seis actividades. Según el
gráfico, para completar la actividad c es necesario reunir información de las actividades b y f. Además, el gráfico
indica que ambas actividades c y f dependen de la información de la actividad b.

Como ilustra el ejemplo, un beneficio clave de la construcción de un DSM es la capacidad de identificar rápidamente
y comprender mejor cómo se necesita la información. También puede poner de relieve posibles problemas de flujo
de información incluso antes de que se inicie el proyecto. Por ejemplo, todas las X por encima de la diagonal en la
Figura 3-10 están relacionadas con situaciones en las que la información obtenida de una tarea posterior podría
requerir la repetición de una tarea completada anteriormente. Para ilustrar, en la segunda fila observamos que la
actividad b requiere información de la actividad e. Dado que la actividad e se completa después de la actividad b,
es posible que la actividad b tenga que ser revisada y reformulada dependiendo de lo que se aprenda después de
completar la actividad e.

El DSM también ayuda a evaluar qué tan bien se ha anticipado la necesidad de coordinar los flujos de información
en la etapa de planificación del proyecto. Para hacer esta evaluación, se agrega un cuadro sombreado al DSM
alrededor de todas las tareas que se planifican para ser ejecutadas simultáneamente. Por ejemplo, el DSM
aparecería como se muestra en la Figura 3-11 si se hubiera planeado que las tareas c, d y e se realizaran
simultáneamente. Observe también que en la Figura 3-11, cualquier entrada que quede por encima de la diagonal
de la matriz se resalta como una posible repetición reemplazando cada X por una O.

Al examinar la Figura 3-11, hay dos situaciones potenciales de retrabajo. Afortunadamente, hay un par de acciones
que se pueden tomar para minimizar o incluso eliminar situaciones potenciales de retrabajo. Una opción es
investigar si la secuencia de las actividades del proyecto puede ser cambiada para que las situaciones potenciales
de trabajo de repaso se muevan por debajo de la diagonal. Otra opción es investigar formas de completar
actividades adicionales simultáneamente. Esta última opción es un poco más compleja y puede requerir cambiar la
ubicación física del lugar donde se completan las tareas.

Figura- 310 Ejemplo de DSM para un proyecto con seis actividades.

Figura 311- DSM modificado para mostrar las actividades que deben completarse simultáneamente.

Gestión ágil de proyectos

En un esfuerzo por reducir costos, mejorar los resultados de los proyectos y reducir los tiempos de finalización de
los mismos, un grupo de desarrolladores de software en 2001 aprovechó los principios de gestión lean y otras
metodologías de mejora continua para desarrollar un nuevo enfoque de la gestión de proyectos. Este nuevo
enfoque fue explicado en un documento titulado "Manifiesto Ágil" y a partir de este documento se desarrolló un
conjunto de 12 Principios Ágiles para guiar la implementación de la Gestión Ágil de Proyectos (APM).

Con APM, un proyecto se completa en etapas que duran de 1 a 4 semanas. Estas etapas se conocen comúnmente
como iteraciones, sprints o hitos. Durante cada etapa, los miembros del equipo del proyecto reciben instrucciones
detalladas sobre el trabajo que debe completarse durante la etapa. Además, un elemento clave del APM es que la
calidad del trabajo para una etapa dada debe ser aprobada antes de que se pueda iniciar la siguiente etapa. Verificar
que se cumplan los estándares de calidad al final de cada etapa posiciona bien al equipo de proyecto para identificar
las causas de los problemas y hacer ajustes rápidos. En los enfoques más tradicionales de la gestión de proyectos,
las largas distancias entre la creación y la identificación de problemas pueden impedir la corrección de los mismos.

En contraste con el enfoque tradicional de gestión de proyectos en cascada, en el que el progreso fluye de una
etapa a otra, APM utiliza etapas o iteraciones de longitud fija. También, basado en principios lean, APM enfatiza la
maximización del valor del proyecto según lo definido por el cliente. Otra característica clave de APM es que
incorpora la planificación adaptativa de manera que el plan de proyecto se actualiza a medida que cambian las
circunstancias. La Tabla 3-4 contrasta con el enfoque tradicional de cascada.
Aunque APM se desarrolló originalmente para el desarrollo de software, se ha aplicado a otras áreas, incluyendo el
desarrollo de productos y la ingeniería. Una serie de beneficios son comúnmente atribuidos a APM, incluyendo:

- Mejores resultados del proyecto como resultado de los problemas que se identificaron anteriormente.

- Aumento de la satisfacción del cliente como resultado de la recepción de sus comentarios y sugerencias a lo largo
de todo el proyecto.

- Mejora de la moral de los miembros del equipo del proyecto como resultado del uso de equipos autogestionados
y con mayor autonomía. Además, las iteraciones cortas ayudan a mitigar el agotamiento de los empleados.

- Mayor colaboración y visibilidad del proyecto como resultado de las revisiones diarias de sprint.

Dimensión Gestión ágil de proyectos Enfoque tradicional de las cascadas


Planificación Planes a corto plazo que se ajustan Intentos de atenerse a los planes a
a medida que avanza el proyecto largo plazo hechos por adelantado
Participación del cliente Inicio y finalización del proyecto A lo largo del proyecto
Ejecución del proyecto Se dividen en etapas incrementales Trabajo realizado en base a un plan
llamadas iteraciones integral y altamente estructurado
Comunicación Fomento de la comunicación Principalmente para el control de
abierta y frecuente (diaria) entre las proyectos
partes interesadas.
Retroalimentación sobre los Al final de cada iteración Al final del proyecto
resultados
Estructura de trabajo Equipo interfuncional integrado Los miembros del equipo tienden a
trabajar de forma independiente y
confían en el director del proyecto
para coordinar las tareas.
Liderazgo de proyectos Equipos autogestionados El jefe de proyecto asigna el
trabajo a los miembros del equipo
Comentarios de los miembros del Comunicación abierta fomentada Retroalimentación típicamente
equipo por todos los miembros del equipo proporcionada confidencialmente
por el gerente de proyecto
Propiedad del proceso Equipo Gestor de proyectos
Experimentación Se le anima a identificar las Desanimado para cumplir con la
mejores formas de satisfacer las fecha límite del proyecto y
necesidades de los clientes. mantenerse dentro del
presupuesto
Ámbito de aplicación Flexible Rígido
Cambiar Bienvenida y parte esperada del Se resistió y a menudo requiere
proyecto una solicitud formal de orden de
cambio

Con toda la atención que APM está recibiendo, es importante señalar que muchos de sus inquilinos pueden ser
fácilmente incorporados en enfoques de gestión de proyectos más tradicionales. Por ejemplo, no hay nada que
impida aumentar la participación de los clientes en el enfoque tradicional de las cascadas. Del mismo modo, no hay
nada inherente a la gestión tradicional de proyectos que prohíba una mayor experimentación. El punto es que en
lugar de ver el MAP como un enfoque de gestión de proyectos de todo o nada, no hay nada que impida que un
gerente de proyecto adopte un subconjunto de las mejores prácticas de MAP. Finalmente, cabe destacar que en
relación a la popularidad de APM, el Project Management Institute ofrece una certificación en APM-el Agile
Certified Practitioner (PMI-ACP).
Desde el plan de la estructura del proyecto, se puede extraer una lista de todas las tareas organizadas por nivel
de tarea. El PEP mostrará identificadores numéricos para cada tarea más otra información según se desee. El
PEP puede adoptar una amplia variedad de formas. Desde el PEP también se puede desarrollar la Matriz RACI
que detalla la naturaleza de la responsabilidad de cada individuo o grupo involucrado en el proyecto hasta las
tareas específicas requeridas para completar el proyecto. El mapeo mental puede enriquecer enormemente el
proceso de planificación y la matriz de estructura de diseño puede facilitar los flujos de información necesarios
para ejecutar cada una de las tareas del proyecto. La gestión ágil de proyectos divide un proyecto en iteraciones
de duración fija y se centra en la planificación adaptativa y en proporcionar valor para el cliente.

3.5 GESTIÓN DE RIESGOS

En el Capítulo 1 se señaló que una de las funciones principales del gerente de proyecto es la gestión de las
compensaciones entre tiempo, presupuesto y alcance. Como discutimos en esta sección, hay una serie de
actividades que se pueden completar durante la fase de planificación del proyecto que facilitan enormemente la
gestión de los riesgos relacionados con el proyecto.

El campo de la gestión de riesgos ha crecido considerablemente en la última década. El PMBOK (2013) del Project
Management Institute dedica el Capítulo 11 a este tema. En general, la gestión de riesgos incluye tres áreas: (1)
identificación de riesgos, (2) análisis de riesgos y (3) respuesta al riesgo. El proceso de realización de estas tres
tareas se divide en seis subprocesos:

1. Gestión de riesgos. Planificación Desarrollar un plan para las actividades de gestión de riesgos.

2. Identificación de riesgos. Encontrar aquellos riesgos que puedan afectar al proyecto.

3. Análisis cualitativo de riesgos. Evaluar la gravedad del riesgo y la probabilidad de que afecte al proyecto.

4. Análisis Cuantitativo de Riesgos. Desarrollo de medidas para la probabilidad del riesgo y su impacto en el
proyecto.

5. Planificación de la respuesta al riesgo. Encontrar formas de reducir los impactos negativos en el proyecto, así
como de mejorar los impactos positivos.

6. Seguimiento y control de riesgos. Mantener registros y evaluar los subprocesos anteriores con el fin de mejorar
la gestión de riesgos.

1. Planificación de la gestión de riesgos. Este proceso de planificación es como cualquier otro proceso de
planificación. En primer lugar, se debe diseñar un método para llevar a cabo los pasos 2 a 5 de cualquier proyecto.
Se debe tener cuidado para asegurar que los recursos necesarios se puedan aplicar de manera oportuna y bien
organizada. El proceso de planificación, al igual que la tarea de gestionar el riesgo, es un proceso continuo. Los
factores que causan incertidumbre aparecen, desaparecen y cambian de fuerza a medida que pasa el tiempo y
cambia el entorno de un proyecto. Tenga en cuenta que la planificación de cómo manejar la incertidumbre es un
problema organizacional, no un problema específico del proyecto. El resultado es que muchas empresas crean un
grupo formal de gestión de riesgos, cuyo trabajo es ayudar al equipo de gestión de proyectos a realizar los pasos 2
a 5. El grupo general de gestión de riesgos desarrolla planes y mantiene la base de datos resultante de la etapa 6.

Algunos de los insumos y productos de los pasos 2 a 5 son exclusivos del proyecto, y otros son comunes a todos los
proyectos. El grupo en su conjunto ayuda a los equipos individuales de riesgo del proyecto con las técnicas analíticas
necesarias, la recopilación de información, el desarrollo de opciones de respuesta, y el seguimiento y evaluación de
los resultados.

2–3. Identificación de riesgos y análisis cualitativo de riesgos. Enumeramos estos pasos juntos porque en la
práctica a menudo se llevan a cabo juntos. A medida que se identifica un riesgo, a menudo se intenta medir su
tiempo, probabilidad e impacto de forma simultánea.

La identificación de riesgos consiste en un estudio exhaustivo de todas las fuentes de riesgo del proyecto. Las
fuentes comunes de riesgo incluyen la organización del proyecto en sí; la dirección superior de la organización del
proyecto; el cliente; las habilidades y el carácter de los miembros del equipo del proyecto, incluido el Primer
Ministro; y los actos de la naturaleza.
Análisis de escenarios. El análisis de escenarios es un método bien conocido para identificar riesgos graves. Implica
prever escenarios probables que puedan tener repercusiones importantes en la organización y luego identificar los
posibles resultados de eventos como un huracán en Nueva Orleáns, una huelga laboral prolongada, la congelación
de un río o la falla de un pozo petrolero que se encuentra a 5.000 pies bajo la superficie del agua en el golfo de
México. Estos tipos de riesgo a menudo pueden ser identificados y evaluados por las partes interesadas en el
proyecto o por partes externas con experiencia previa en proyectos similares. Más allá de esto, un análisis detallado
del plan del proyecto, el PEP y la Matriz RACI, así como el gráfico PERT (Capítulo 5), a menudo identificará los riesgos
altamente probables, los riesgos extremadamente graves o las áreas altamente vulnerables, en caso de que algo
salga mal.

Después de identificar los principales riesgos, se deben obtener los siguientes datos sobre cada uno de ellos para
facilitar un análisis más profundo: la probabilidad de que ocurra cada evento de riesgo, el rango o distribución de
los posibles resultados en caso de que ocurra, las probabilidades de cada resultado y el momento esperado de cada
uno de ellos. En la mayoría de los casos, no se dispondrá de buenas estimaciones, pero obtener la mayor cantidad
de datos y estimaciones tan precisas como sea posible será crucial para el seguimiento del análisis de riesgos. Sobre
todo, recuerde que una "mejor conjetura" es siempre mejor que no tener información.

Análisis de Modo y Efecto de Fallas (FMEA). FMEA es un enfoque estructurado similar a los métodos de puntaje
discutidos en el Capítulo 1 para ayudar a identificar, priorizar y manejar mejor el riesgo. Desarrollado por el
programa espacial en la década de 1960, el FMEA puede aplicarse a proyectos utilizando los siguientes seis pasos.

1. Enumere las formas en que el proyecto podría fallar.

2. Enumere las consecuencias de cada falla y evalúe su gravedad. A menudo la severidad, S, se clasifica usando una
escala de diez puntos, donde "1" representa fallas sin efecto y "10" representa fallas muy severas y peligrosas como
la pérdida de vidas humanas.

3. Enumere las causas de cada falla y estime la probabilidad de que ocurra. La probabilidad de que ocurra un fallo,
L, también se clasifica habitualmente en una escala de diez puntos, con un "1" que indica que el fallo es bastante
remoto y no es probable que ocurra y un "10" que indica que el fallo es casi seguro que ocurra.

4. Estimar la capacidad de detectar cada falla identificada. Una vez más, la detectabilidad de fallos, D, se clasifica
habitualmente mediante una escala de diez puntos, en la que se utiliza un "1" cuando los sistemas de
monitorización y control tienen casi la certeza de detectar el fallo y un "10" cuando es prácticamente seguro que el
fallo no será detectado.

5. Calcule el Número de Prioridad de Riesgo (RPN) multiplicando S, L y D juntos.

6. Clasificar la lista de fallos potenciales por sus RPNs y considerar formas de reducir el riesgo asociado a los fallos
con RPNs altos.

La Tabla 3-5 ilustra los resultados de un FMEA realizado para evaluar el riesgo de un nuevo proyecto de desarrollo
de medicamentos en una compañía farmacéutica. Como se muestra en el cuadro, se identificaron cinco posibles
fallos para el proyecto: (1) El nuevo medicamento no es efectivo para tratar la enfermedad en cuestión, (2) el
medicamento no es seguro, (3) el medicamento interactúa con otros medicamentos, (4) otra compañía lo lanza al
mercado con un medicamento similar, y (5) la compañía no es capaz de producir el medicamento en cantidades
masivas. Según los resultados, el riesgo más significativo es el riesgo de desarrollar un nuevo medicamento que no
es efectivo. Aunque es poco probable que se pueda hacer mucho para reducir la gravedad de este resultado, se
pueden tomar medidas para reducir la probabilidad de este resultado y aumentar su detectabilidad. Por ejemplo,
se pueden utilizar tecnologías informáticas avanzadas para generar productos químicos con efectos más
predecibles. De la misma manera, tal vez se puedan utilizar ensayos clínicos en humanos y en animales más
tempranos para ayudar a detectar la efectividad de los nuevos medicamentos más pronto. En este caso, si tanto L
como D pudieran reducirse en uno, el RPN global se reduciría de 240 a 160.

4. Análisis Cuantitativo de Riesgos. Hertz y Thomas (1983) y el ganador del Premio Nobel Herbert Simon (1997)
han escrito dos libros clásicos sobre este tema. Como señalamos en el Capítulo 1, la esencia del análisis de riesgos
es establecer los diversos resultados de una decisión como distribuciones de probabilidad y usar estas
distribuciones para evaluar la conveniencia de ciertas decisiones gerenciales. El objetivo es ilustrar al gestor la
distribución o el perfil de riesgo de los resultados (por ejemplo, beneficios, fechas de finalización, rendimiento de
la inversión) de la inversión en algún proyecto. Estos perfiles de riesgo son un factor a tener en cuenta a la hora de
tomar la decisión, junto con muchos otros como los intangibles, las preocupaciones estratégicas, los problemas de
comportamiento, el encaje con la organización, etc.

Un ejemplo de ello es Sydney, el túnel M5 East Tunnel de Australia (PMI, marzo de 2005). Fue construido bajo
estrictos requisitos presupuestarios y de calendario, pero dadas las enormes demoras de tráfico que ahora
dificultan a los viajeros, es posible que los requisitos se hayan subestimado seriamente. Debido a un sistema
informático barato con un alto índice de fallos, las cámaras de seguridad del túnel fallan con frecuencia, obligando
a los operadores a cerrar el túnel debido a la incapacidad de reaccionar ante un accidente, incendio o contaminación
excesiva dentro del túnel. El túnel fue construido para manejar 70.000 vehículos al día, pero transporta 100.000,
por lo que cualquier fallo puede causar problemas de tráfico inmediatos. Un análisis de riesgos, incluyendo el riesgo
de uso excesivo, probablemente habría anticipado estos problemas y ordenado un conjunto más confiable de
computadoras una vez que se hubieran incluido los costos de la falla.

Cuadro- 35 FMEA para el Proyecto de Desarrollo de Nuevos Productos en la Compañía Farmacéutica

Estimaciones. Antes de discutir las técnicas de análisis de riesgos, necesitamos discutir algunos temas relacionados
con los datos de entrada que provienen del análisis cualitativo de la etapa 3. Suponemos aquí que estimar el rango
y el momento de los posibles resultados de un evento de riesgo no es un problema, pero que las probabilidades de
cada uno pueden ser más difíciles de establecer. Dado que no hay datos reales sobre las probabilidades, las mejores
conjeturas de las personas familiarizadas con el problema son un sustituto razonable. Un ejemplo de tales
suposiciones (también conocidas como estimaciones) para una parte del proyecto puede verse en la Tabla 3-6.

Se pide a las personas conocedoras que hagan tres estimaciones del costo de cada actividad, una estimación normal
más estimaciones optimistas y pesimistas del costo de cada una de ellas. A partir de estos se puede encontrar un
valor esperado para el costo de una actividad, pero vamos a retrasar la discusión de este cálculo hasta el Capítulo
5, donde mostramos dichos cálculos para la duración de los costos o de las tareas.

Si no se pueden hacer aproximaciones, hay otros enfoques que se pueden utilizar. Un enfoque es asumir que todos
los resultados son igualmente probables, aunque no hay más justificación para esta suposición que asumir cualquier
otro valor de probabilidad elegido arbitrariamente. Tenga en cuenta que cuando se utiliza el enfoque común del
valor esperado (véase más adelante) para ayudar a tomar una decisión, el resultado puede ser engañoso. Por
ejemplo, la probabilidad de que se produzca un desastre puede ser muy baja (lo que da lugar a un valor esperado
bajo), pero, no obstante, esos riesgos deben gestionarse cuidadosamente, por ejemplo, con un seguro o una amplia
planificación para imprevistos. Es por eso que es tan importante, si no más importante, considerar la distribución
de los resultados como lo defendemos en este libro.

Valor esperado. Cuando la información de probabilidad está disponible o puede ser estimada, muchas técnicas de
análisis de riesgo utilizan el concepto de valor esperado de un resultado, es decir, el valor de un resultado
multiplicado por la probabilidad de que ese resultado ocurra. Por ejemplo, en un lanzamiento de moneda usando
un cuarto, hay dos resultados posibles y el valor esperado del juego es la suma de los valores esperados de todos
los resultados. Es fácil de calcular. Supongamos que si la moneda sale "cabeza" ganas un cuarto, pero si sale "cruz"
pierdes un cuarto. También asumimos que la moneda que se tira es una moneda "justa" y que tiene una
probabilidad de 0,5 de salir cara o cruz. El valor esperado de este juego es.

Una tabla de decisión (también conocida como matriz de resultados), como la ilustrada en la Tabla 3-7, es una
técnica comúnmente utilizada para situaciones de decisión de un solo período en las que hay un número limitado
de opciones de decisión y un número limitado de posibles resultados. En la siguiente tabla de decisiones, hay cuatro
características:

1. Tres opciones de decisión o alternativas, Ai.

2. Cuatro estados de la naturaleza, Sj, que pueden ocurrir.

3. Cada estado de la naturaleza tiene su propia probabilidad de ocurrir, pj , pero la suma de las probabilidades debe
ser 1.0.

4. Los resultados asociados con cada combinación de alternativa y estado de naturaleza, Aij, se muestran en el
cuerpo de la tabla.

Tabla- 36 Estimaciones de costos optimistas, normales y pesimistas para la Cena Anual de Homenaje

A cada persona responsable de una tarea en este proyecto se le pidió que tomara los costos estimados y
determinara un presupuesto más preciso. La hoja de cálculo incluye la información de costes. Este proyecto no
incluye ningún costo por el tiempo del personal. Cada miembro del equipo del proyecto es considerado parte de
los Salarios Generales y de la Administración, y su tiempo asociado no se gastará a través de este proyecto.
Tabla- 37 Tabla de decisiones (o matriz de resultados) para el problema de la muestra

Si se elige una alternativa en particular, Ai ,, se calcula el valor esperado de esa alternativa de la siguiente manera:

Por ejemplo, usando los datos de la Tabla 3-7 para la alternativa "Fast" obtenemos

El lector recordará que utilizamos una matriz de resultados similar en el Capítulo 1, cuando consideramos el
problema de seleccionar un proveedor para diseñar e imprimir pegatinas para parachoques. En ese ejemplo, las
ponderaciones de criterios jugaron el mismo papel que las probabilidades en el ejemplo anterior.

Simulación. Demostraremos la simulación en el próximo capítulo (4) y lo demostraremos más en capítulos


posteriores. En los últimos años, el software de simulación ha hecho que el proceso sea fácil de usar y mucho más
simple que a mediados del siglo XX. Se ha convertido en una de las técnicas más poderosas para hacer frente a los
riesgos que se pueden describir en términos numéricos. Los problemas más difíciles relacionados con el uso de la
simulación son (1) explicar el poder de usar estimaciones de tres puntos (más probable, optimista y pesimista) en
lugar de las estimaciones de un solo punto que siempre han utilizado los responsables de la toma de decisiones; y
(2) explicar la noción de distribuciones estadísticas a las personas cuyo único conocimiento de las distribuciones
estadísticas es la noción (errónea) de que las calificaciones en el aula se distribuyen, o deberían distribuirse, por "la
curva". Una vez que se entienden las ideas fundamentales detrás de una simulación de Monte Carlo, el poder de la
técnica en el manejo del riesgo es obvio. Aún más potente es la noción de que uno puede estimar la probabilidad
de que ocurran ciertos resultados riesgosos, tales como la probabilidad de que los costos del proyecto estén en o
por debajo de un límite dado, o la posibilidad de que un proyecto se complete según lo programado.

Hay otro problema con el uso de la simulación, o cualquier proceso que involucre estimaciones de costos de
proyectos, cronogramas, etc. Es convencer a cualquier persona relacionada con un proyecto de que haga
estimaciones honestas de la duración, los costos o cualquier otra variable relacionada con un proyecto. El problema
es el mismo ya sea que se pida una estimación de un solo punto o de tres puntos. Pedir a las personas que rindan
cuentas de sus estimaciones siempre es difícil para el askee, y se aconseja a los gerentes de proyecto que utilicen
sus mejores estilos de comunicación interpersonal cuando traten de mejorar las estimaciones de costos y tiempo
del proyecto. El código de ética del PMI exige honestidad, y los movimientos populares deben esforzarse por
garantizarla. Sin embargo, muchas personas suelen tomar una decisión basada en el peor resultado posible que
podría ocurrir (llamado la decisión pesimista) y en unos pocos casos ("la Sra. Lucky") en el mejor resultado posible
que podría ocurrir (llamado la decisión optimista). Algunos problemas al final del capítulo incluyen estas reglas de
decisión.

5. Planificación de la respuesta al riesgo. La respuesta al riesgo suele implicar decisiones sobre los riesgos para los
que hay que prepararse y para los que hay que ignorar y aceptar simplemente como amenazas potenciales. La
principal preparación para un riesgo es el desarrollo de un plan de respuesta al riesgo. Dicho plan incluye planes de
contingencia y gráficos lógicos que detallan exactamente qué hacer dependiendo de eventos particulares (Mallak,
Kurstedt y Patzak, 1997). Por ejemplo, Islandia está sometida con frecuencia a avalanchas inesperadas y, por lo
tanto, ha preparado un plan de respuesta detallado para tales acontecimientos, en el que se indica quién está a
cargo, las tareas que deben realizar los distintos organismos en determinados momentos, etc. Practicar esas
respuestas con ensayos generales es particularmente importante si el riesgo es potencialmente una emergencia de
vida o muerte.

Plan de Contingencia. Un plan de contingencia es un respaldo para alguna emergencia o evento no planeado, a
menudo referido coloquialmente como "plan B", y también puede ser necesario un plan C y un plan D, para una
emergencia aún más profunda como un derrame de petróleo en el golfo de México, para dar un ejemplo muy
improbable. El plan de contingencia incluye quién está a cargo, qué recursos están disponibles para la persona,
dónde se pueden ubicar las instalaciones de respaldo, quién apoyará a la persona a cargo y de qué manera, y así
sucesivamente.

En otro ejemplo, cuando el huracán Katrina azotó Mississippi y Nueva Orleans en agosto de 2005, Melvin Wilson,
de Mississippi Power, una subsidiaria de 1.250 empleados, se convirtió en "Director de Logística de Tormentas" por
la duración del evento. Como contingencia, Mississippi Power se suscribe a tres servicios de pronóstico del tiempo
y en este caso decidió que el pronóstico más severo era el correcto. Wilson pidió que se retirara del cuartel general
de la compañía en la playa a una oficina de contingencia de respaldo en una planta de energía a 8 kilómetros tierra
adentro. Para el mediodía, la planta de energía de respaldo se inundó y perdió energía, lo cual no estaba en el plan,
y los autos en el estacionamiento estaban flotando. Una camioneta de seguridad de la compañía logró llevar al
equipo de tormentas a una tercera opción para un centro de tormentas -una oficina de servicio en North Gulfport
que había sobrevivido al huracán Camille en 1969- no había una cuarta opción. La oficina estaba seca pero sin
electricidad ni agua corriente. Las líneas telefónicas estaban caídas, y los teléfonos celulares eran inútiles, pero los
1.100 teléfonos celulares de la compañía más 500 extras para prestar tenían una función de radio única, y eso
funcionó. Fueron las únicas comunicaciones de trabajo durante las primeras 72 horas en la costa del golfo. Los
planes de contingencia de la compañía en el peor de los casos nunca se habían imaginado la gestión de un equipo
de reparación de más de 4.000 personas procedentes del exterior. Pero Wilson se hizo responsable de dirigir y
apoyar a 11.000 reparadores de 24 estados y Canadá, alimentándolos y alojándolos en 30 áreas de montaje,
incluyendo seis ciudades de tiendas de campaña con servicio completo que albergaban a 1.800 cada una. Tuvo que
encontrar 5.000 camiones y 140.000 galones de gasolina al día para ayudar a restaurar la energía a 195.000 clientes.
A los 12 días de la tormenta, se había restablecido la electricidad a todos los clientes, excepto a unos pocos miles
cuyas líneas estaban demasiado dañadas para recibir electricidad. Claramente, Mississippi Power no había hecho
planes de contingencia para un evento tan extremo, pero los planes que habían hecho, y los respaldos a esos planes,
eran suficientes para dar a un equipo inteligente de respondedores de emergencia la oportunidad de manejar
exitosamente esta crisis.

Gráfico de lógica. Los gráficos lógicos muestran el flujo de actividades una vez que se inicia un plan de respaldo.
Obligan a los gerentes a pensar en los pasos críticos que se deben dar en una crisis, y proporcionan una visión
general de los eventos de respuesta y las operaciones de recuperación. Incluyen decisiones, tareas, notificaciones,
necesidades de apoyo, flujos de información y otras actividades similares. Son independientes del tiempo e ilustran
las muchas tareas, así como las dependencias e interdependencias que surgen de los pasos iniciales de respuesta,
como por ejemplo: "Si X ha ocurrido, haz esto; de lo contrario, hazlo."

6. Seguimiento y control de riesgos. Al igual que la planificación de la gestión de riesgos, el seguimiento y el control
son tareas para la organización matriz, así como para el proyecto. Si el grupo de gestión de riesgos en general no
participa junto con el proyecto en la realización de las tareas de registrar y mantener registros de los riesgos que se
identificaron, cómo se analizaron y respondieron y qué resultó de las respuestas, los registros tienen una alta
probabilidad de perderse para siempre cuando el proyecto esté terminado (o abandonado). Si los registros se
pierden o no están fácilmente disponibles, la probabilidad de que otros proyectos "aprendan de las experiencias
de otros" es muy baja.

El trabajo del grupo de gestión de riesgos consiste en mantener registros de la forma en que todos los proyectos
abordan los riesgos. El grupo, sin embargo, no es simplemente un poseedor pasivo de récords. Debe participar en
la búsqueda de nuevos riesgos, en el desarrollo de nuevas y mejores técnicas de medición y manejo de riesgos, y
en la estimación del impacto de los riesgos en los proyectos. Por lo tanto, el grupo debe convertirse en asesor de
los equipos de gestión de riesgos del proyecto. Debe proporcionar una evaluación continua de las técnicas actuales
de identificación, medición, análisis y respuesta a los riesgos. Fundamentalmente, el grupo se dedica a la mejora de
las actividades de gestión de riesgos de la organización.

La gestión de riesgos consiste en la planificación e identificación de riesgos, el análisis cualitativo y cuantitativo


de riesgos, la respuesta a los mismos y el seguimiento y control de los mismos. Tratamos el riesgo principalmente
a través de medios tales como tablas de decisión, simulación y respuesta, que implican la identificación de los
riesgos para los que se prepararán y para los que se ignorarán y simplemente se aceptarán.

En el siguiente capítulo, usamos el plan del proyecto para desarrollar un presupuesto del proyecto. Discutimos el
conflicto en torno al proceso presupuestario. Luego nos ocupamos de la incertidumbre, la constante compañera
del proyecto (y del Primer Ministro).

PREGUNTAS DE REPASO

1. ¿Cuáles son algunos de los beneficios de establecer un plan de proyecto para proyectos similares y frecuentes?
2. Discuta las razones para invitar a los gerentes funcionales a una reunión de lanzamiento del proyecto en lugar de
a sus subordinados que pueden estar haciendo el trabajo.

3. Discuta los pros y los contras de identificar e incluir al equipo del proyecto en la reunión de lanzamiento del
proyecto.

4. ¿Por qué el manejo participativo es beneficioso para la planificación de proyectos? ¿Cómo funciona realmente
el proceso de manejo participativo en la planificación?

5. ¿Cuál es la diferencia entre la columna Recurso en el PEP (que incluiría el personal necesario para el proyecto) y
la columna Asignado a?

6. ¿En qué circunstancias es sensato prescindir de una reunión de lanzamiento del proyecto?

7. Distinguir entre riesgos altamente probables, riesgos extremadamente graves y áreas altamente vulnerables en
la identificación de riesgos.

8. ¿Qué limitaciones asociadas a las técnicas tradicionales de gestión de proyectos, como los diagramas de Gantt y
los diagramas de precedencia, supera la Matriz de Estructura de Diseño?

9. Contraste el enfoque tradicional de gestión de proyectos en cascada con la gestión ágil de proyectos.

10. Contraste el plan de proyecto y la estructura del proyecto.