Evaluar el riesgo

Los tres ejes

Es normal que a veces el director de proyectos esté desconcertado debido a la cantidad de elementos que debe organizar para tener éxito. ¿En qué dirección ir? ¿Por dónde empezar y cómo continuar?

Para responder a estas preguntas, en primer lugar se debe imaginar el proceso del proyecto como se describe en el capítulo Iniciar un proyecto informático. En esta ocasión, elegimos un espacio estructurado por tres ejes, tiempo (ciclo de vida), análisis y control.

Cada dimensión de este espacio se corresponde con un método más o menos estándar, que dará lugar a un proceso que el director de proyectos tendrá que seguir.

El primer eje (abscisa horizontal) es el que describe las fases del proyecto, tal y como las podemos preconfigurar. El diagrama anterior propone un modelo de desarrollo bastante estándar, a partir de la expresión de necesidades, evolucionando hasta la entrega (producción) y el mantenimiento del proyecto. Estrictamente hablando, deberíamos introducir el final del ciclo de vida del proyecto, porque sabemos que el marco de soporte no es infinito. Como veremos más adelante, existen otros modelos de desarrollo que proponen diferentes organizaciones.

A continuación, nos encontramos con el eje de análisis (ordenadas, verticales). Este representa el nivel de abstracción del proyecto....

El modelo de desarrollo

El modelo de desarrollo es una de las primeras elecciones que debe tomar el director de proyectos. Da forma explícita a la organización temporal del proyecto y tiene una gran influencia en el resultado final.

No existe un modelo correcto o incorrecto, al menos entre las grandes clases enumeradas a continuación. Sin embargo, cada proyecto tiene características que hacen que la aplicación de un modelo sea adecuada o, por el contrario, ineficaz. 

1. El modelo en cascada

También se llama modelo lineal o modelo nominal. Sin lugar a dudas se trata del modelo más sencillo, aunque no por ello deja de tener éxito.

En este modelo, cada etapa sigue a la anterior, sin necesidad de "esperar" su resultado. Tan pronto como se completa la expresión de las necesidades o requisitos, se escriben las especificaciones. Al final de este trabajo, se lleva a cabo el desarrollo hasta su finalización. Las pruebas unitarias se suceden entre sí, y así sucesivamente.

Antes de explicar por qué se llama en cascada, veamos las diferentes etapas previstas por este modelo.

Idea - inicio	Este es el punto de partida del proyecto, el momento en que se cumplen las condiciones de hardware y materiales y el equipo comparte la visión del proyecto.
Expresión de las necesidades	Tras tomar la decisión de comenzar un proyecto, volvemos a recopilar información de los usuarios para obtener más detalles. Estas peticiones se registran en un documento (papel u hoja de cálculo), se identifican y, finalmente, se agrupan y se buscan sinergias entre ellas.
Especificaciones	Todas las peticiones se consideran en función de los diferentes enfoques dictados por el modelo de análisis: importancia, prioridad, dificultad técnica, riesgos, etc. Las especificaciones muestran un desglose técnico-funcional de la aplicación.
Desarrollo	Las especificaciones se traducen en código, proyectando la segmentación modular (componentes) en la plataforma elegida por el arquitecto.
Pruebas unitarias	Cada componente se prueba independientemente del resto. Su comportamiento debe cumplir con las especificaciones, dentro del rango de operativo y de funcionamiento previsto.
Pruebas de integración	Los componentes se ensamblan con mayor frecuencia en una plataforma técnicamente heterogénea....

El modelo de análisis

Este modelo gobierna el estudio del sistema en formación. La mayoría de los métodos (modelos) empiezan dibujando los límites de este sistema para evitar centrarse en detalles externos. Seguidamente, el sistema se estudia desde el ángulo de los estímulos del usuario y luego se formaliza. Obviamente, toda la dificultad del ejercicio radica en la ausencia de una existencia concreta del sistema.

Antes de describir las líneas principales de los métodos más utilizados, Merise y UML, descubriremos cómo proceder para modelar sistemas informáticos.

1. El principio del modelado en análisis

El modelado es una abstracción de la realidad. Simplemente plasmar una situación en un documento constituye una abstracción. ¿Cuáles son los objetivos que perseguimos? En primer lugar, se trata de describir el sistema objetivo con un mínimo de formalismo. A ese respecto, Merise habla de un subconjunto representativo (SER). Esta "simplificación" es esencial para aquellos que quieren participar en las especificaciones de un proyecto sin disponer del producto final. El modelado también es una técnica para definir prioridades en un proyecto. Algunos detalles que se encuentran en las piezas del usuario no tienen un significado real, mientras que otros resultarán ser extremadamente importantes.

Para el director de proyectos, el modelado es un proceso que, recordemos, le permitirá tratar mejor su asunto priorizando la reutilización y la genericidad. A continuación, indicamos cómo.

El modelado se realiza en tres pasos: abstracción, instanciación y verificación.

La abstracción es el paso más complicado. Se trata de analizar aquello que existe para identificar lo esencial sin introducir sesgos. El obstáculo principal con el que se encuentran los programadores novatos es introducir de manera poco apropiada detalles que se pueden traducir en sesgos y esfuerzos inútiles en el resultado final. En nuestro ejemplo, la equipación del jugador de fútbol, su forma de celebrar los goles y el color de la pelota no importan.

La abstracción proporciona modelos que son una representación formalizada y subjetiva de la realidad.

Posteriormente, viene la instanciación. Por lo general, se obtiene...

El modelo de control

Conocemos la máxima "dirigir significa prever" y podríamos preguntarnos si se puede aplicar a la gestión de proyectos. Este es precisamente el propósito del control, es decir, prever la aparición de peligros y anticipar cambios críticos en el proceso del proyecto.

Ahí radica la principal diferencia entre la asociación del desarrollo y el análisis con el control. Los dos primeros modelos están anidados y son los que conforman el proceso del proyecto. El control gestiona el proceso con una visión externa, más sistémica. El proyecto, como proceso, forma parte de un conjunto de flujos de trabajo que caracteriza la actividad de la empresa. Esta actividad no solo es introspectiva, sino que conecta a la empresa con socios, clientes, proveedores y subcontratistas.

Por lo tanto, la gestión o control de un proyecto es una técnica de control del proyecto (un proceso "local") a nivel de empresa. Esto significa que el comité de control involucra solo a una parte del equipo del proyecto (generalmente el director del proyecto) y también a representantes del comité de dirección de la empresa, así como a sus homólogos que son miembros de las organizaciones asociadas al proyecto (socios, clientes, etc.).

Al igual que muchas actividades que se tratan en este nivel, la visión no se basa en detalles, sino en agregados de información básica llamados indicadores clave de rendimiento (Key Performance Indicator o KPI). Con estos indicadores, el comité de control proporciona nuevas direcciones y cambia las prioridades.

El riesgo se evalúa continuamente y, en última instancia, corresponderá al comité de control decidir sobre el resultado del proyecto, en caso de un aumento significativo en el nivel de riesgo o la aparición de peligros con consecuencias adversas.

Tener en cuenta el contexto de negocio y de los procesos, es otra de las ocupaciones del comité de control. Es necesario evitar a toda costa que especialistas técnicos...

Tener en cuenta el riesgo

Estudio de riesgos para el proyecto CRM

La empresa consultora Plus encargó a Guillaume, informático, que ayudara a la dirección de marketing, en la que también se encuentra la directora de proyectos, Annie. Juntos, identifican los riesgos aplicables a su proyecto de implementación de CRM. El producto de su reflexión tendrá un doble impacto. En primer lugar, el nivel de riesgo se actualizará en cada comité de control, para que se puedan anticipar los períodos clave durante los cuales se debe prestar atención a aspectos particulares del proyecto. Por otro lado, la evaluación del perfil de riesgo guiará la elección de un proveedor y proveedor de servicios, para implementar la solución en función de una determinada metodología adaptada.