En mi último post “Proyectos con éxito: foco en el tiempo” hablaba del uso que podemos dar a la herramienta de la triple restricción para gestionar proyectos con éxito.

En concreto, hablaba de la restricción temporal, entendida como una fecha límite y no como un periodo de tiempo. Básicamente exponía que en un proyecto con una fecha inamovible, todas las decisiones a tomar debían basarse en ello y proponía una estrategia de desarrollo de proyecto.

Hoy me voy a focalizar en la restricción del alcance.

Focalizando en el alcance

Ahora vamos a suponer que tenemos frente a nosotros un proyecto de innovación, en el que el cliente sabe lo que quiere pero con mucha incertidumbre.

Sí, aquel proyecto que era muy claro al principio pero que a la hora de aterrizarlo, salen nuevas ideas sobre cómo debe ser el producto… y como siempre, en un escenario en el que tanto el alcance como el coste y el tiempo están limitados igualmente.

Desde mi punto de vista, es la situación ideal para hacer foco en el alcance. El valor más apreciado del proyecto es que el producto final sea capaz de conseguir los objetivos de nuestro cliente.

No es tan importante que fijemos una fecha final en la que tener el producto, como que el resultado sea el que realmente queremos. La gestión de los costes tiene que ir asociada al desarrollo del producto, partiendo siempre de un producto mínimo viable (PMV).

Al contrario de lo que hacíamos cuando poníamos el foco en el tiempo, ahora la estrategia de desarrollo no es tener todos los componentes mínimos para lanzar el producto al mercado en una fecha concreta. Se trata de ir obteniendo el producto lo suficientemente valioso como para lanzarlo y testarlo en el mercado lo antes posible.

Alcance y fecha límite

Si el proyecto tiene un exceso de alcance y además, tiene una fecha límite muy marcada, estamos en una situación peligrosa y el cliente debe tener muy claro los riesgos a los que nos exponemos (sobre todo si la fecha es ajustada).

Hemos de decidirnos por una de las dos estrategias. Pero ¿cómo tener todos los componentes mínimos sin saber qué componentes son ni cómo son? En el mundo del desarrollo software nos encontramos con que el alcance parece muy bien definido y cuando empiezas a escarbar, te encuentras con que no es así… y el deadline sigue estando allí.

Es en este momento que entra de pleno el desarrollo ágil . La clave está en validar conjuntamente con el cliente un producto mínimo viable en un plazo corto de tiempo (basándonos en SCRUM, y haciedo sprints).

Y digo clave porque si el cliente no está involucrado, no entiende el modo de ejecutar el proyecto o no está de acuerdo con ir desarrollando el PMV hasta la fecha final (y sólo hasta aquí), el proyecto no funcionará.

Y eso significa la necesidad de su colaboración e implicación, desde el inicio, hasta el final. Si esto no es así, en este escenario se acentúa la probabilidad de que el proyecto no sea un éxito o no tenga el éxito esperado. Más vale prevenir y avisar.

En mi próximo artículo hablaré de poner el foco en el coste, el escenario que podemos encontrar y las diferentes estrategias de desarrollar el proyecto, aunque creo que ya puedes suponer cómo lo plantearía yo en base a lo expuesto ¿te aventuras a avanzarte?


If you're not an innovator, please don't click here.


¿Y tú qué dices?

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.