Definición de Proyectos

Hace unos años no teníamos metodologías que permitieran indicar las mejores prácticas para llevar a cabo un proyecto y garantizar el cumplimiento de sus objetivos con el uso de los recursos asignados al mismo.  Hoy contamos con el cuerpo de conocimiento sobre estas mejores prácticas en un documento que se conoce como el PMBok (Project Management Body of Knowledge), PrInCE2, metodología europea para gestión de proyectos, e ISO21500 para soportar los mas complejos..

La teoría indica que lo primero que se debe estructurar, aparte de unos documentos formales de establecimiento y lanzamiento, es el alcance del proyecto.  Se debe llegar a un claro entendimiento entre el cliente y el proveedor (quien recibirá el “producto” del proyecto y quien desarrollará actividades para elaborar el “producto” del proyecto.)

Por lo general el cliente del proyecto, quien recibe el producto del mismo, va a querer que haya la menor definición posible para poder cambiar el alcance, y el proveedor del producto del proyecto,  querrá el mayor nivel de definición para evitar desfases y reducir el riesgo de imprevistos.  Este balance es difícil de lograr en la medida que el cliente no quiera concretar lo que necesita, y que el proveedor no pueda manejar la incertidumbre.

Es necesario entonces un proceso de negociación que permita definir no solo el alcance sino el mecanismo para manejo del alcance.  Una de las mejores herramientas para esta tarea es precisamente la construcción de la estructura de desglose de trabajo (EDT, o WBS del inglés Work Breakdown Structure).

Desarrollar la estructura de desglose de trabajo bajo la metodología propuesta invita a descomponer el o los productos finales en componentes y cada componente en sub-componentes hasta que no se puedan hacer más divisiones.  Es importante recordar que seguimos hablando del QUE, es decir del alcance, no del COMO que vendrían a ser las actividades.

Cada elemento,  cada componente de esta estructura, debe tener definido un alcance, que permita determinar que se ha logrado el objetivo.  Cada elemento “madre” o que tenga sub-componentes se deberá construir a partir de los elementos debajo de él, y no con trabajo adicional.  Son principios sencillos pero por nuestra característica occidental de concentrarnos en el cómo, omitimos desde el principio.

Al final del día, la suma de todos los QUE que se van a construir, deben dar el total de lo que el dueño del proyecto espera que se le entregue.  En ocasiones se omiten algunas cosas obvias, como los manuales para un producto de software, o la capacitación cuando hacemos una máquina nueva, los nuevos planos en un edificio que se acaba de construir (que obviamente no tiene nada que ver con los planos originales), entre muchos otros ejemplos.  Lo que si es claro es que si no está en la EDT, solo se logrará de suerte, porque se pierde completamente de vista.

Tenemos claro que la vida real no responde a procesos perfectos, ni se puede encajar en una metodología rígida.  Pero por lo menos debemos tener claridad en buena parte del contenido de esta EDT, y en especial en aquellos elementos que su variabilidad pueda ocasionar un desvío grande en el desarrollo del proyecto.  Cualquier omisión en este aspecto puede por si sola llevar al fracaso el proyecto, por pequeño que sea.  Ahora bien, para proyectos ágiles, se incluye en estos «impulsos» o sprints, los criterios bajo los cuales podríamos indicar también si se continúa con el siguiente paso o si se para el proyecto.

En la medida que el equipo humano del proyecto es más numeroso, y que su ubicación geográfica pueda ser dispersa, con mayor razón se hace indispensable tener una definición clara del alcance, de ese objetivo a donde debemos llegar, para que cada miembro del equipo pueda tener su norte establecido y determinar las actividades a desarrollar bajo su responsabilidad que le permitan lograr los entregables a su cargo.

Por alguna razón que no logro identificar, la mayoría de proyectos que planeábamos (si a eso que hacíamos se le podía llamar planear) siempre iniciaba con una lista de actividades y sub actividades, seguidas de la asignación de tiempos a las mismas, responsables, y en ocasiones hasta los recursos requeridos para desarrollar las actividades.  ¿Y el alcance? De eso no sabíamos mucho.

Ahora tenemos las herramientas que nos permiten sugerir que hasta que la WBS no esté definida, en buena parte todos sus entregables, tendremos un alto riesgo de incumplir, no porque no seamos capaces de hacer lo que se nos encomiende, sino porque el norte, además de no estar claro, puede ser sujeto a variaciones.  ¡No arranque a hacer hasta que no termine de planear el que!  Si las definiciones del PMBok no le son suficientes, consulte en PRINCE2, o en ISO21500 o asístase de la definición del Caso de Negocio como lo indica ValIT en proyectos de tecnología informática.

¿Se lo permitirán las restricciones de tiempo del proyecto? ¿Se lo permitirá su cliente? De usted depende manifestar los beneficios de planear el alcance, para garantizar que durante el hacer haya claridad en el curso de acción además de mayor certeza en el cumplimiento.