GTD para dummies: la gestión de proyectos

GTD para dummies: la gestión de proyectos

Uno de los aspectos más confusos y menos comprendidos de GTD es la gestión de proyectos. Para empezar, la definición de proyecto que hace David Allen es poco común –cualquier tarea que requiera de 2 o más acciones físicas. Por otro lado, muchas personas tienen dificultades para seguir la pista a los proyectos, organizar la documentación de apoyo, o desglosarlos en acciones.

Para poder hacer una buena gestión de proyectos es necesario entender que no todos los proyectos son iguales, ni necesitan de la misma estrategia para ser gestionados eficazmente. A grandes rasgos, yo divido los proyectos en 2 grandes grupos: los proyectos autogestionados y los proyectos formales.

Proyectos autogestionados

La palabra “proyecto” está revestida de cierto halo de importancia, pero la realidad es que un gran porcentaje de las cosas que hacemos cada día son proyectos. Es difícil pensar en tareas que no requieran de al menos un par de acciones físicas para ser terminadas.

Por ejemplo, algo tan simple como cambiar el cartucho gastado de la impresora puede ser un proyecto. Dependiendo de nuestro caso, tendremos que 1) ver qué tipo de cartucho utiliza la impresora; 2) ir a la tienda a comprarlo; 3) cambiar el cartucho; y opcionalmente 4) llevar el cartucho gastado a reciclar.

La buena noticia es que la mayoría de esos mini-proyectos suelen ser lo que yo llamo proyectos autogestionados. Dada una acción –por ejemplo, comprar un cartucho nuevo–, generalmente habrá una sola acción siguiente posible, que suele resultar obvia a partir de la propia naturaleza del proyecto –si ya he comprado un cartucho nuevo, el siguiente paso lógico será instalarlo en la impresora.

Estos proyectos son autogestionados porque basta con tener un recordatorio de lo que perseguimos –hacer que la impresora imprima de nuevo– en la lista de proyectos, y de la única siguiente acción en la lista contextual correspondiente. Una vez terminada la acción, la tachamos y añadimos la siguiente, y así sucesivamente hasta terminar el proyecto.

Los proyectos autogestionados raramente necesitan de documentación de apoyo, ni mapas mentales, ni planes detallados, ni absolutamente nada más. En el momento en que surge el proyecto durante el procesamiento, está listo para ser llevado a cabo sin más preámbulos.

En realidad, desde un punto de vista de gestión, un proyecto autogestionado es casi idéntico a una próxima acción. La única diferencia es que querremos tener un recordatorio en la lista de proyectos para no olvidar que todavía no hemos obtenido el resultado deseado –nuestra impresora imprimiendo de nuevo y, quizá, el cartucho viejo reciclado.

Proyectos formales

Los proyectos formales son una bestia completamente diferente. En proporción, constituyen una gran minoría de los proyectos, pero suelen ser lo que tienen mayor impacto en la consecución de nuestros objetivos a medio y largo plazo.

El comienzo de un proyecto formal es casi idéntico al de cualquier proyecto autogestionado: a resultas del procesamiento de alguna idea nueva, surge la necesidad de llevar a cabo una tarea compleja. La gran diferencia es que sus siguientes acciones no resultan obvias a primera vista.

Y esa es la clave. Lo único que sabemos antes de iniciar un proyecto formal es que primero tenemos que aclarar su propósito, definir los objetivos que queremos alcanzar, acotar las restricciones –económicas, temporales o del tipo que sea–, generar todas las ideas que podamos, organizar dichas ideas de algún modo útil, definir las siguientes acciones… En una palabra, tenemos que planificar el proyecto.

Una vez tenemos esto claro, resulta muy sencillo empezar a gestionar un proyecto formal. En primer lugar, añadimos un recordatorio a la lista de proyectos para tener siempre presente el objetivo que perseguimos. Y después, una primera acción que, invariablemente, siempre será la misma: “planificar el proyecto”.

Como podemos ver, una vez planificado, la gestión de un proyecto formal es casi idéntica a la de un proyecto autogestionado, salvo que las siguientes acciones no surgirán de forma automática de la propia naturaleza del proyecto, sino a partir del plan escrito que realicemos.

Cómo desarrollar un plan de proyecto que funcione es un tema complejo que dejaremos para la siguiente entrega de esta serie.

Seguimiento de proyectos

Una vez puesto en marcha un proyecto, ya sea autogestionado o formal, solo nos queda asegurarnos de que marcha a buen ritmo y dentro de los límites que nos hemos impuesto.

En general, el mejor momento para hacer una evaluación de nuestros proyectos es durante la revisión semanal de nuestro sistema GTD –una práctica fundamental de la que hablaremos muy pronto. Durante dicha revisión, repasaremos la lista de proyectos y nos aseguraremos de que todos tienen al menos una siguiente acción definida.

Para los proyectos formales, revisaremos además todo el material de apoyo que hayamos acumulado –normalmente en una carpeta manila o una carpeta en el ordenador–, para determinar cuáles serán las siguientes acciones, analizar si hay desviaciones en el plan y tomar las medidas correctivas que sean necesarias.

Divide y vencerás

Algunas veces nos topamos con proyectos tan complejos que no resultan fáciles de gestionar ni siquiera con GTD. En general, esto es debido a que estamos tratando de “morder” más de lo que podemos. Cuando esto sucede, merece la pena analizar si lo que estamos tratando de gestionar como un proyecto no se trata en realidad de algo de naturaleza superior, como una meta a largo plazo.

Si nos encontramos antes un proyecto que parece dividirse en varios subproyectos, una buena estrategia suele ser mover un recordatorio del proyecto a una lista de objetivos a medio y largo plazo –convirtiéndolo ahora en un objetivo, no en un proyecto–, y crear un proyecto más pequeño para cada subobjetivo.

Esta misma estrategia también puede aplicarse para próximas acciones demasiado grandes, que no puedes terminar en una sola sentada. Por ejemplo, en lugar de añadir la acción “Pasar CDs de música a iTunes”, es mejor crear un proyecto y añadir varias acciones del tipo “Pasar CDs del 1 al 10 a iTunes”, “Pasar CDs del 11 al 20 a iTunes”, etc.

De este modo tendrás más sensación de avance, pues podrás tachar acciones terminadas de forma regular, en lugar de tener una acción demasiado “grande” que parece que nunca termina.

Artículo original escrito por Jero Sánchez. Sígueme en Twitter.

Foto por k0a1a.net (via Flickr)

24 comentarios

  1. Genial, Jero. Me ha gustado mucho ya que estoy de acuerdo contigo en que la gestión de proyectos es la parte más dificil de entender de GTD. Ya que eres un máquina en esto del GTD, ¿como has resuelto, para proyectos formales, la duplicidad de tener un planning en alguna herramienta de seguimiento de proyectos y tener también las siguientes acciones en tu sistema GTD? ¿qué pones en cada sitio?

    Gracias.

    • @santagu:

      La que manda siempre es la herramienta de gestión de proyectos, si es que usas alguna. Tus listas GTD solo deben contener –idealmente– las próximas acciones.

      Hay una forma de eliminar la necesidad del doble mantenimiento, y es crear una sola próximas acción, del tipo “Trabajar en el proyecto”, asumiendo que los detalles los encontrarás en la herramienta de gestión de proyectos o en la documentación de apoyo. Sin embargo, creo que esto reduce mucho el potencial de las listas de GTD: la acción es poco descriptiva, y no puedes tacharla como completada hasta que termines el proyecto –prescindiendo de los beneficios psicológicos y la sensación de avance que da el poder marcar tareas terminadas.

      Mi consejo, si lo quieres, es que pases a tus listas GTD las próximas acciones que puedas hacer en este momento cada vez que te quedes sin acciones para ese proyecto.

  2. Hola,

    Un gran artículo, me ha gustado esa distinción entre los tipos de proyectos y la forma de gestionarlos. Generalmente me asaltan muchas dudas a la hora de definir que va a la lista de proyectos y que no, algunos los veo tan sencillos, que pesar de conllevar más de 1 acción, me cuesta considerarlos como un proyecto (ya que siempre he identificado proyecto = complejo), supongo que me da cierto rechazo tener una lista demasiado larga de proyectos.
    Por mi trabajo, comparto varios equipos en distintas ubicaciones y necesito tener el material accesible. Me cuesta integrar todo eso en la nube.

    Saludos

    • @valenciana21:

      El truco para que no te de pereza “crear” esos mini proyectos es no pensar que creas proyectos. Me explico. En realidad todos esos proyectos pequeños no necesitan carpeta ni nada especial. Lo único que necesitan es un recordatorio en la lista de proyectos. De esa forma, cuando revises la lista de proyectos, recordarás que todavía tienes que cerrar ese tema pendiente –probablemente con alguna siguiente acción. Nada más.

      Estoy seguro que si cambias tu enfoque por algo parecido a lo que acabo de explicar, ya no volverás a tener ese problema ;-)

  3. Llevo ¿años? leyéndote y siempre me sorprendes, Jero. Enhorabuena. Tu artículo ha generado una depuración formal de un asunto que no terminaba de “agarrar”. Merci.
    Cambio de tercio: esta plantilla y esta vista me resulta más agradable y “seria” que la que tenías antes.

  4. Me ha encantado. Creo que es la primera vez que leo algo sobre gestión de proyectos en GTD y no tengo la sensación de haber entendido menos de la mitad o de que esto no es para mí.

    • @Mariano:

      Parece que hoy sí di en el clavo :-) Me alegra de que este punto haya quedado claro de una vez por todas.

      Ya no hay excusas para gestionar los proyectos como Dios manda :-P

  5. Hola Jero,
    me alegra ver que has solucionado los problemas con el blog y continuas con esta serie de GTD “paso a paso”. El nuevo diseño del blog me resulta agradable; me parece más claro y ordenado que el anterior.
    Muy buen artículo sobre proyectos ¡muchas gracias!
    Tus últimos artículos me van ayudando a enfocar con mayor claridad conceptos que tengo un poco confusos.
    Voy viendo que ciertamente no lo voy desencaminado en mi forma de organizarme, pero es muy gratificante ir entendiendo mejor los conceptos y las razones que hay detrás. Me está gustando esto especialmente pues lo que vas explicando no se queda para mi en teoría sino que siento que lo voy incorporando.
    Comentarte que utilizo Things (en Mac). Algo sobre lo que seguir aprendiendo es incorporar esta gestión de proyectos que describes en esta aplicación de la manera más efectiva y sencilla posible.

  6. Hola Jero, tengo una pequeña duda:¿La próxima acción de un proyecto termina en la misma lista que las acciones simples o próximas acciones?
    Gracias por compartir tus conocimientos.

    • @Juan Carlos:

      Exactamente, las próximas acciones de los proyectos van a las listas contextuales, junto con las demás próximas acciones :-)

      El análisis de las acciones de un proyecto suele hacerse por separado, en la documentación del proyecto. A las listas contextuales solo deben ir las próximas acciones que ya estén listas para hacer en este momento. Evita mover próximas acciones futuras, porque tu sistema se volverá muy confuso –si haces una revisión semanal de tus proyectos, tendrás oportunidad de ir moviendo nuevas próximas acciones según sea necesario.

  7. Jero,
    Una duda, cuando se trata de un proyecto formal, ya he adoptado el hábito de escribirlo en mi lista de proyectos, y crear una primera acción que es “Definir el proyecto”. Pero…que debemos hacer en esa definición? Entiendo que deberíamos aplicar el método de planificación natural, lo que nos llevaría a crear un mapa mental y de ahí extraer las siguientes acciones? Aconsejas apuntar todas las próximas acciones? No puede resultar eso demasiado abrumador? Si no las apuntamos, como procedemos, del resultado de próximas acciones que nos ha sugerido el mapa mental, escogemos algunas y las anotamos? Y el resto? Se quedan en el mapa mental?

    Jero, me has ayudado muchísimo con la adopción del sistema GTD. Había leído mucha teoría sobre GTD, pero me hacía falta algo más práctico, como esta serie. Muchas gracias. Creo que ahora si he salido del bloqueo en el que me encontraba, aunque como puedes ver aún tengo serias dudas sobre algunos aspectos del sistema.

    Gracias!

    • @kovemc:

      Me encanta que hayas salido del bloqueo. En realidad, el objetivo de esta serie era ayudar a toda la gente que pudiera a salir de ese bloqueo que mencionas, y pudieran implementar GTD de una vez por todas. Así que tu comentario quiere decir que estoy consiguiendo el objetivo.

      Y regresando a tu duda, casi te respondes solo ;-) Efectivamente, la acción “Definir el proyecto” consiste en aclarar el propósito, establecer las restricciones que tengamos, y por supuesto, identificar todas las próximas acciones que podamos. La mejor forma de identificar las próximas acciones es mediante una sesión de brainstorming, y registrarlas utilizando mapas mentales, como bien apuntas.

      Una vez tengamos el mapa mental listo, pasaremos a las listas contextuales solo las próximas acciones que podamos realizar en este momento, es decir, ninguna próxima acción futura –estas se quedan en el mapa mental. Poner acciones futuras en las listas solo causará confusión y reducirá la efectividad de las listas, pues antes de seleccionar una acción deberemos determinar si realmente podemos hacerla o no.

      Si haces una revisión periódica de tus proyectos –por ejemplo, durante la revisión GTD semanal–, tendrás ocasión de revisar tus mapas mentales y traspasar nuevas acciones a las listas según proceda.

  8. Pingback: Surfeando la web a fin de mes: 5 artículos sobresalientes en Abril 11 – Lo que le diga es mentira

  9. Al gestionar mis proyectos, últimamente me surge una duda. Según todos los blogs de gtd, según david allen, etc, todo proyecto “activo” debe tener, al menos, una acción siguiente (es decir, una acción en “Proximo”, en su contexto correspondiente). En mis proyectos actuales, se me da la circunstancia de que tengo algún proyecto cuya acción siguiente a realizar esta… “En Espera” (es decir, delegada, que depende de alguien). Incluso, en mi sistema GTD tengo tambien una lista CALENDARIO que son tareas que se hacen un dia concreto (sincronizada con GCalendar para verlo de un modo más “grafico”), y alguna de ellas pertenece a un proyecto, con lo que en algún momento, alguno de mis proyectos activos, si siguiente acción es una acción del calendario. Yo creo que esto es correcto, pero como en ningún sitio aclaran ni ponen un ejemplo con esta casuistica, a veces dudo si esto debe hacerse así. ¿tu como lo ves?

    gracias,
    un saludo!

  10. Pingback: Como seguir a una lista de consejos

  11. Pingback: GTD no es un sistema de gestión de proyectos « beta permanente

  12. Pingback: gtd y gestion de proyectos

  13. Pingback: GTD no es un sistema de gestión de proyectos - Beta permanente

Deja un comentario