Si habéis seguido la serie GTD para dummies que terminó hace poco, recordaréis que identificaba dos tipos de proyectos: los autogestionados y los formales. Los primeros prácticamente no necesitaban planificación, porque dada una acción, era fácil determinar cuál sería la siguiente –por ejemplo, para cambiar el cartucho de la impresora existe una serie de acciones obvias bien definidas: revisar el modelo del cartucho, ir a comprarlo, cambiarlo…
Por el contrario, los proyectos formales –como la publicación de un libro electrónico–, necesitaban algún tipo de gestión. En este caso, las siguientes acciones no necesariamente resultan obvias a partir del simple enunciado del objetivo. Antes de iniciar la ejecución del proyecto es necesario realizar algún tipo de trabajo previo que nos ayude a aclarar el camino a seguir.
Gracias al método de los 6 pasos para planificar proyectos resulta sencillo determinar el objetivo de un proyecto, descubrir la secuencia de fases, identificar a los responsables de cada tarea y analizar los riesgos. No importa lo grande o pequeño que sea, todo proyecto formal, en el sentido expresado anteriormente, debería empezar documentando estos puntos, ya sea en papel o en archivo de ordenador.
A mi me gusta hacer la planificación de proyectos con mapas mentales. Comienzo poniendo lo que quiero conseguir del proyecto en el centro, y luego creo una rama por cada fase principal. Después voy “colgando” subramas de las fases, cada una con un hito u objetivo parcial que identifico. En un tercer nivel añado las tareas de las que están compuestos los hitos.
Si el proyecto no es muy complejo, o existe alguna fase, hito o tarea críticos, a veces “decoro” cada nodo del árbol con prioridades, fechas tope, responsables y posibles riesgos, de manera que el mapa mental me sirve para empezar a trabajar sin más preámbulos. Si el proyecto es muy complejo y requiere un WBS (Work Breakdown Structure), o cuadro de desglose de tareas formal, entonces incluyo estos datos en el WBS y no en el mapa mental.
Finalmente, ya sea en el mapa mental o en el WBS, desgloso cada tarea en próximas acciones. Las tareas normalmente necesitarán de varias próximas acciones para ser terminadas –aunque a veces hay tareas tan sencillas que solo necesitan una acción, y son ellas mismas la próxima acción. De lo que se deduce que, en general, cada tarea del proyecto estará representada por un proyecto a-la-GTD.
Y ahora viene el paso crítico: cuando termino la planificación del proyecto no muevo todas las próximas acciones a las listas contextuales de GTD. Las acciones se quedan en el mapa mental o WBS –que constituyen parte de la documentación del proyecto. Sólo traslado a mi sistema GTD aquellas próximas acciones que puedo hacer inmediatamente, o como se dice técnicamente, aquellas que no tienen dependencias. Las demás se deben gestionar como acciones futuras.
De esta forma, utilizando mis listas contextuales puedo concentrarme en el detalle del trabajo, sin necesidad de tener delante todas las complejidades del proyecto.
Una vez que el proyecto ya está en marcha lo incluyo en las revisiones del sistema GTD. En cada revisión de control –semanal–, o si el proyecto lo requiere, en cada revisión operativa –diaria–, verifico las próximas acciones terminadas, marco las tareas, hitos y fases completadas, y traslado nuevas próximas acciones a las listas contextuales. Y por supuesto, aprovecho cada revisión para pulir, añadir o modificar elementos del mapa mental o WBS, conforme aumenta mi conocimiento del proyecto o surgen cambios.
Y tú, ¿cómo desglosas tu plan de proyecto en próximas acciones de GTD? Comparte tus conocimientos y experiencia en un comentario.
Artículo original escrito por Jero Sánchez. Sígueme en Twitter.
Foto por Dave Bleasdale (via Flickr)