No realizamos tareas en tanto y en cuanto no tengamos un propósito claro

No debes realizar ninguna tarea sin antes tener una razón válida por la cual efectuarla. Imagina dos mundos paralelos donde todo es igual, salvo una sola cosa, que es la que tú estás considerando actualmente: ¿Cuán diferentes podrían ser estos mundos? ¿Vale la pena dedicar tu esfuerzo a realizar esta tarea?

Si no cuentas con un propósito claro en mente y solo lo haces porque todos lo están haciendo o todos dicen que es importante que este hecho, entonces:

• Puede ser que no tenga un beneficio claro en tu caso, y por lo tanto no saques ningún beneficio de ello, o que
• A pesar de tener potenciales beneficios en tu caso, pero debido a que no tienes el propósito claro, la forma en la que lo realices no ayude a materializar estos potenciales beneficios.

Ejemplo: Portfolios y programas

Si estás involucrado en seleccionar e iniciar proyectos, debes asegurarte de que tu atención esté centrada en los beneficios y en solucionar aquellos potenciales incidentes que puedan surgir a causa de desarrollar el producto. El ejemplo clásico es una compañía que fabrica ascensores que solía recibir quejas sobre la velocidad de sus ascensores y había intentado conducir, sin éxito, varios proyectos para aumentar la velocidad de sus ascensores.

Esta situación fue una constante hasta que decidieron centrarse en el problema (el aburrimiento de la gente o la incomodidad) en vez de la solución “natural” (ascensores más rápidos).

El resultado fue, añadirle espejos a los ascensores, lo que resolvió de forma simple el problema.

Recuerda que gestionar proyectos es básicamente hacer las cosas bien, mientras que gestionar portfolios es hacer las cosas correctas. No importa que tan bueno seas gestionando proyectos, no funcionara si estas realizando los proyectos equivocados. Tener un propósito lo es todo.

Ejemplo: El proyecto como un conjunto

La flexibilidad del producto varia de proyecto en proyecto. En algunos proyectos de desarrollo de aplicaciones de IT, el producto es completamente flexible, y su forma final depende de la respuesta que se vaya generando a los incrementos entregados del producto durante el proyecto, que requiere un enfoque adaptativo (Ágil). Esto es, en la práctica, es una combinación de las distintas capas de gestión - portfolio, programa y proyecto- y requiere que prestemos máxima atención al propósito global. Es una buena idea documentar el propósito y tenerlo siempre accesible. Es uno de los propósitos de la “Visión de producto” utilizado en alguno de los proyectos, como por ejemplo en Scrum. La atención al valor de negocio que nuestros incrementos brindan es la forma de asegurar, en este caso en los proyectos bajo la metodología ágil, la correcta alineación del proyecto con el propósito.

En otro tipo de proyectos, cuando el alcance del producto esta medianamente definido y existen otros mecanismos para asegurarse de que el producto identificado valdrá para el propósito establecido, es posible para los miembros del equipo desviar una gran parte de la atención del propósito al producto (Como el principio de “Enfoque en los productos” de PRINCE2^®). Sin embargo, siempre debe dedicarse un mínimo de atención a propósito a fin de asegurarse de que el resultado del producto que se está construyendo pueda satisfacer el propósito, pudiéndose comprobar con simplemente comparar el pronóstico de los beneficios con los beneficios esperados (Como el principio “Justificación comercial continua” y la temática “Business Case”, ambos en PRINCE2^®.)

Cuando el proyecto es realizado para clientes externos, el cliente tendrá su propio propósito por el cual realizar el proyecto, distinto generalmente del de tu organización. Debes entender y tener en cuenta ambos para tener éxito.

Ejemplo: Controlar el proyecto

Utilizar el propósito global es necesario, pero puede ser demasiado abstracto para su aplicación en las tareas diarias. Por lo cual, establecer una jerarquía efectiva de razones es necesario para poder tener un enfoque práctico. En primer lugar, la justificación y beneficios del proyecto son definidos de acuerdo al propósito global. Como resultado, tendrás objetivos implícitos y explícitos aplicables a las diferentes variables (tiempo, coste, calidad, etc.) que satisfarán la justificación y que, resultará a su vez en lograr el propósito global. Estos son propósitos de bajo nivel que son útiles para mucha de nuestras tareas diarias.

Cuando se trata de controlar el proyecto, gestionar los propósitos de bajo nivel será llevado a cabo utilizando las variables que también conforman el espectro de bajo nivel, ya que no sería posible de otra forma controlar el propósito global. En este caso, también debes tener en cuenta los propósitos. ¿Cuál es el real significado de llevar a cabo tareas de control sobre un proyecto?

Una respuesta válida seria para ver si nuestro proyecto está en la línea correcta y sino, poner en marcha ciertas acciones que nos hagan volver a nuestro cauce o bien ajustar los objetivos y asegurarnos de que todavía podemos seguir cumpliendo con el propósito global. Por lo tanto, nuestros indicadores deberían complementar estos propósitos de bajo nivel, siendo sus indicadores – cuando están definidos y aplicados de forma correcta – pronósticos para las variables una vez completas. Ejemplo: ¿Cuándo podré terminar este proyecto? ¿Cuánto dinero necesitaría para terminar este proyecto?

Todos aquellos indicadores adicionales, tales como los valores planeados y actuales, solo conforman un grupo de valores que necesitas para realizar pronósticos, no formando parte de aquellos que utilizas para gestionar el proyecto en sí.

Ejemplo: Documentos

Sin importar que enfoque de desarrollo utilices en tu proyecto, planear siempre es una parte necesaria. La cuestión importante es definir el nivel de detalle en cada tipo de plan. Si el plan no está lo suficientemente detallado, el plan en sí mismo no podrá contribuir de forma sustancial al proyecto y su ejecución radicara más en decisiones tomadas en una situación particular en vez de decisiones que forman parte de un enfoque integrado y, por lo tanto, holístico.

Por otra parte, mucha gente es reticente a la hora detallar más de la cuenta sus planes, ya que, de esta forma, el plan se convierte en un elemento difícil de preparar, mantener y puede ser demasiado rígido para las incertidumbres que el proyecto pueda presentar, convirtiéndose en un elemento irrealista y por lo tanto, carente de uso práctico.

La mejor forma de decidir el nivel de detalle de un plan es tener un propósito en mente o bien tener presente cada elemento en el plan. Por ejemplo, si estáis considerando añadir recursos al plan, se debe de tener un propósito claro: ¿Cómo los vais a utilizar?, ¿Cómo van a ayudar al proyecto?, ¿Cuánto esfuerzo requiere?, ¿Vale la pena?

Algunas veces, se debe decidir qué elementos se deben incluir en el plan y otras veces la forma en la que quieres planear o preparar algo. Escoge un business case, un acta de constitución de proyecto o un reporte: debes preguntarte a tu mismo la razón por la cual preparas este documento y de qué forma puede ayudar al mismo.

Buscar una plantilla pre-hecha es lo opuesto a realizar algo basado en un propósito.

Ejemplo: Reportar el estado

Es muy común tener reportes de estado muy largos en distintos proyectos. Basándonos en este NUP, tenemos que preguntarnos a nosotros mismos cual es realmente el propósito de reportar y cómo podemos lograr nuestro propósito indistintamente de cómo la gente lleva a cabo sus tareas.

Esto puede, en muchos casos, llevarnos a preparar reportes muy simples y limpios de una página que los interesados pueden leer y entender de forma clara, en vez de los tradicionales reportes con gran cantidad de páginas. Esto es prestar atención al propósito.

Sin embargo, si preparas reportes de una página, algunas personas pueden pensar que no tienes un sistema de control “adecuado” establecido. Esto prácticamente crea un segundo propósito para ti (aparte del primero, que es ayudar a los interesados a entender el estatus del proyecto), y para satisfacerlo, puedes crear simplemente un segundo tipo de reporte que sea muy extenso. Sin embargo, no es recomendable mezclarlos entre sí, porque su propósito es distinto.

Ejemplo: Business case y acta de constitución del proyecto

Preparar documentos como estos es considerado generalmente aburrido, sin sentido, una necesidad burocrática para la mayor cantidad de personas, siendo el caso de que todos estos documentos tienen, de hecho, un propósito valido para la mayoría de los proyectos.

Si intentas encontrar una plantilla pre-hecha y rellenarla, este trabajo simplemente no tiene sentido. En cambio, podrías experimentar el propósito real de estos documentos, analizando cómo son útiles para tu proyecto y luego preparar un documento en la forma que desees, solo para satisfacer los propósitos existentes: ése es el documento correcto.

Mientras piensas la forma en la cual debes preparar estos documentos para satisfacer los propósitos establecidos, tal vez no pienses en el escenario y puedas dejar algo de lado. Para evitar esto, puedes consultar los recursos sugeridos en PRINCE2^®, la Guía Del PMBOK^®, P3.express y DSDM^®, y evaluarlos de basado siempre en los propósitos.

Ejemplo: Después del proyecto / Post-Project

Mientras que el proyecto tiene un propósito definido y debe ser considerado a lo largo de todo el proyecto, la realización del propósito esta mayormente basada en pronósticos realizados durante el proyecto. No debemos olvidarnos de esto cuando el proyecto se da por finalizado. Es importante comparar la realización de los objetivos una vez finalizado el proyecto, ya que:

• Podemos inspeccionar como los objetivos globales son realizados y aprender de ellos en futuros proyectos y,
• muchas veces, los objetivos son logrados solo cuando realizamos algunas tareas adicionales una vez terminado el proyecto. Para entender la necesidad de aquellas tareas adicionales, se requiere control.

El control una vez finalizado el proyecto es un paso necesario y está basado estrictamente en el propósito. Es una de las responsabilidades principales de los sistemas de gestión de programas y portfolios, que muchas veces es inexistente en las organizaciones, y por lo tanto, ignorada. Por esta razón, metodologías como P3.express y DSDM^® añaden este paso a su metodología de gestión de proyectos.

Ejemplo: Mantener las cosas simples

En este mundo complejo y caótico, nuestros modelos son aproximaciones abstractas que reflejan partes del mismo. Sin embargo, estos pueden ser simples. Además, los sistemas simples suelen trabajar mejor, ya que permiten concentrarnos en la idea principal.

Muchas de nosotros tratamos de lograr mejores resultados a cambio de añadir complejidad a nuestros sistemas, deseando que estos coincidan con la complejidad del mundo, aunque esto signifique que el sistema se vuelva complejo, de difícil gestión y que usualmente nos impida lograr el propósito principal.

Ejemplo: Adaptación

Los proyectos varían entre sí. Una pieza de software para publicar música por internet tiene una condición muy distinta que una pieza para un equipamiento de un hospital o un avión, donde la vida de mucha gente depende de ello, o de un software que será utilizado en un satélite que se supone tiene que funcionar muchos años sin fallar. Todos ellos, a su vez, son distintos de, por ejemplo, la construcción de una residencia de verano, una estación de bomberos o una planta de procesamiento.

Cuando tienes claro los propósitos, podrás lograr un mejor entendimiento de cómo adaptar los sistemas y los artefactos para los distintos proyectos que gestiones.

▼ PDF