Perspectiva GTD: Los Proyectos

En este segundo «horizonte de enfoque», que David Allen identifica metafóricamente con el nivel de vuelo de un avión a 3.000 metros, se encuentra lo que en GTD se denomina «proyectos». Dice Allen que «[proyectos son] los resultados a los que se puede llegar en un año y que conllevan más de una acción». La razón para incorporar el parámetro de un año – explica Allen – es que cualquier obligación que haya que completar en este período de tiempo se va a tener que revisar al menos una vez a la semana.

Por otra parte, Allen nos propone una lista de verbos que dan lugar a resultados, que es precisamente a lo que en GTD se llama proyectos. Finalizar, investigar, distribuir, maximizar, aprender, organizar, diseñar, presentar o resolver son algunos ejemplos de estos verbos. En general, aunque Allen no lo dice de forma explícita, cualquier verbo que corresponda con «acciones no físicas y visibles» es un «verbo de proyecto». Una «acción física» es aquella que se ve cuando está hecha. Por ejemplo, escribir, enviar un email, llamar por teléfono, imprimir o dibujar son verbos de acción.

La mayoría de los verbos que empleamos para expresar lo que tenemos que hacer no cumplen su cometido, ya que en realidad no expresan lo que tenemos que hacer sino lo que queremos conseguir. Cuando dices que tienes que «organizar una reunión» lo que realmente estás diciendo es que quieres o necesitas «que la reunión esté organizada». Para conseguir este resultado, lo que vas a tener que «hacer» es llamar a gente, escribir textos, enviar emails, etc. Comprender y aplicar esta distinción entre «acción» y «proyecto» es clave para ganar claridad sobre lo que de verdad tienes que hacer para conseguir los resultados que buscas.

Por otra parte, David Allen insiste en que resistas la tentación de «filtrar» los proyectos, algo que, en mi experiencia, constituye uno de los principales «errores de novato» y es, además, una de las formas más fáciles y rápidas de saber si alguien «usa GTD» o «cree que usa GTD». Un proyecto es un resultado. Punto. «Presupuesto para 2016 terminado y distribuido al comité de dirección» es tan proyecto en GTD como «aceite del coche cambiado». ¿Por qué? Porque en ambos casos vas a tener que «hacer» más de una «acción» para lograr el resultado esperado.

Otro aspecto que trata Allen es cómo organizar los proyectos. Lo ideal, según él, es gestionarlos en una lista, al igual que harías con una lista de llamadas. Yo comparto su opinión. A la mayoría de las personas esta propuesta le resulta extraña, ya que están acostumbradas a organizar conjuntamente los proyectos y sus acciones relacionadas. Sin embargo, hacer esto en GTD esto no tiene mucho sentido, ya que la lista de proyectos y las listas de acciones tienen finalidades distintas.

En cuanto a cuándo llevar a cabo la revisión de este nivel, David Allen propone tres tiempos diferentes:

  1. Por una parte, durante la revisión semanal del sistema.
  2. Por otra, cada vez que tengas la sensación de que tus proyectos clave se están quedando atrás.
  3. Por último, siempre que creas que has perdido el control de tus prioridades a corto plazo.

En mi experiencia, si realmente haces las revisiones semanales, las situaciones 2 y 3 rara vez se dan.

En «Haz que funcione», Allen aprovecha la explicación de este segundo nivel de perspectiva para enfatizar una vez más la importancia de la revisión semanal. Esta revisión nos sirve, dice Allen, para mantenernos despiertos, actualizados y creativos.  ¿Qué significa esto?

  • La revisión para «mantenerse despierto» consiste en capturar todos los aspectos que se han podido ir quedando en tu entorno o en tu mente, fuera de GTD. En otras palabras, se trata de recopilar o capturar todo aquello que deberíamos haber recopilado o capturado en su momento y, por una razón u otra, no lo hicimos.
  • La revisión para«mantenerse actualizado» consiste en poner al día las listas de tu sistema GTD. Durante este ejercicio de revisión es muy habitual, por ejemplo, encontrar acciones en tus listas que ya han sido completadas pero siguen ahí sin tachar. Esta revisión también incluye la agenda o calendario.
  • La revisión para «mantenerse creativo» se supone que es algo que se produce de manera espontánea cuando llevas a cabo las otras dos, así que Allen no aporta detalles relevantes sobre cómo hacerla.

Personalmente, me parece que todo lo anterior puede llegar a complicar innecesariamente algo que, al aplicarlo, resulta mucho más sencillo. Lo cierto es que el día a día «te come» y eso hace que, en la práctica, tiendas a revisar únicamente tu agenda y tus contextos. El impacto de esta realidad es que la fiabilidad de tu sistema se ve afectada de forma negativa por la falta de revisión. Para compensar esta «degradación natural» de la fiabilidad de tu sistema, necesitas hacer una revisión de mantenimiento o, dicho de otra forma, la revisión semanal sirve para mantener la fiabilidad de tu sistema.

Por otro lado, no me parece pedagógicamente acertado mezclar la explicación de la revisión semanal (cuándo se revisan los proyectos) con la explicación de este segundo nivel de perspectiva (para qué se revisan los proyectos y cómo se hace). Que los proyectos se revisen generalmente durante la revisión semanal es independiente de la perspectiva que proporciona la revisión de los proyectos. Si el nivel de acciones se revisa para decidir qué hacer, el nivel de los proyectos se revisa para ganar perspectiva a corto plazo sobre la evolución de nuestros proyectos, es decir, en qué medida nos estamos acercando al ritmo esperado a los resultados en los que estamos trabajando. La revisión semanal sirve para mantener el sistema fiable. La revisión de los proyectos sirve para saber cómo avanzan nuestros proyectos.

En resumen, el nivel «3.000 metros»:

  • Contiene los resultados (proyectos) que quieres conseguir y en los que ya estás trabajando
  • Sirve para ganar perspectiva sobre el estado actual y la evolución temporal de tus proyectos, profundizando en la perspectiva vertical de tu sistema
  • Se revisa para asegurarte de que todos tus proyectos activos avanzan al ritmo que deben y tienen al menos una siguiente acción identificada en alguna parte del sistema (agenda, lista a la espera, archivo de seguimiento o contextos)
  • La perspectiva que nos ofrece es una perspectiva a corto plazo, que típicamente abarca la semana que acaba de terminar y la semana que va a empezar

Para finalizar, esta revisión forma parte del proceso de revisión semanal, que en general será cada siete días pero puede hacerse también cada seis o cada ocho días. La revisión de los proyectos, si están todos los que tienen que estar y se hace bien, puede llevar entre 30 y 60 minutos y es, con diferencia, la parte más importante de toda la revisión semanal.

9 comments to Perspectiva GTD: Los Proyectos

  • Hola JM,

    En mi experiencia los proyectos son una de las cosas que más cuesta entender a la gente. ¿Te pasa lo mismo?

    Cuadno entiendes que cualquier cosas que requiere más de una acción es un proyecto, descubres un nuevo mundo lleno de “cosas” que comienzas a terminar.

    A mi me costó mucho darme cuenta de eso, porque pensaba, como voy a hacer de esto un proyecto, si la secuencia es lógica. Pues reconozco que la hacer proyecto, en vez de acción he conseguido mejorar mucho.

    Una pregunta para todos, si me lo permites:

    Cuando estáis procesando la bandeja de entrada y ves una “cosa” que se hace nuevo proyecto. Las acciones para conseguir el objetivo del proyeto las escribís en ese momento, o seguís procesando la bandeja de entrada y colocáis esas ideas que se os vienen a la cabeza en la misma bandeja de entrar y luego las metéis en el proyecto.

    Es decir: proceso, veo que es un proyecto, me surgen ideas para este proyecto y las meto ya en el proyecto, o las capturo como “cosas” independientes y las pongo en la bandeja de entrada, y ya las procesaré (meterlas en el proyecto) cuando les toque.

    Un abrazo,
    J.

    • Jose Miguel Bolivar
      Twitter: jmbolivar

      Hola Jose,
      Sí. Me pasa igual. Reconozco que la palabra a lo mejor no es la más acertada. De hecho, yo prefiero usar «resultados», que suele generar menos fricción.
      En cuanto a lo que preguntas, un proyecto en GTD da lugar a una variedad de entradas en diversas partes del sistema:
      1) Una entrada en la lista de proyectos
      2) Una siguiente acción en alguna otra parte del sistema: la agenda, un contexto, la lista a la espera…
      3) Material de apoyo del proyecto, es decir, información o material que necesitaré o me podrá ser útil para el proyecto
      Cuando al procesar ves que algo es un proyecto, las ideas del proyecto se deben mantener aparte, como material de apoyo. Luego, durante las revisiones, esas ideas pueden dar lugar a acciones del proyecto. Es más fluido y natural que meterlas como cosas en la bandeja de entrada.
      Un abrazo,

      • Gracias JM,

        Vuelvo con el proceso de procesar 😉

        Caso práctico:

        Estás trabajando y te llama tu pareja para decirte que en agosto quiere ir de vacaciones. Imaginemos que capturas ir de vacaciones o vacaciones.

        Cuando pasado un tiempo tienes 25 cosas capturadas para procesar, y llegar a la cosa “Ir de Vacaciones”, yo lo convertiría a proyecto, pero al hacerlo éste tiene cero acciones, se me viene una lluvia de acciones a la cabeza que debo capturar (llamar a amigos para que se apunten, buscar ofertas de sitios, ver que nos apetece más, buscar fechas, hablar con mi jefe, etc…). La pregunta es: Cómo lo háceis? Las capturas directamente en el proyecto, o las pasas a la bandeja de entrada (quedarían como cosas últimas capturadas) y ya las procesarás cuando llegues a ellas.

        Buen finde!

        • Jose Miguel Bolivar
          Twitter: jmbolivar

          Hola Jose,

          En GTD hay dos tipos de proyectos: los evidentes y los no evidentes. Los evidentes son aquellos que sabes de antemano cual es la secuencia de pasos que conduce al resultado. Los no evidentes son aquellos en los que desconoces la secuencia. El ejemplo que pones de las vacaciones es un proyecto no evidente. Los proyectos no evidentes hay que planificarlos (en el sentido que tiene «planificar» en GTD) aplicando el método de planificación natural de proyectos. Cuando proceso algo que he recopilado y veo que se trata de un proyecto no evidente, la acción que va a mi sistema es «hacer planificación natural del proyecto X», generalmente en un contexto asociado a mucho tiempo y energía alta. Una vez completada la planificación natural, ya dispondrás de una serie de siguientes acciones claras y, si quieres, de un esquema general con otras posibles acciones futuras del proyecto. Las siguientes acciones deben ir a parar a su lista correspondiente (contextos por lo general).

          Buen finde!

  • vepascual

    Hola José Miguel.
    Enhorabuena por tu blog y por tu libro.
    Soy novato en el uso de GTD, y me surge una duda. Está claro que un proyecto = un resultado, y que los proyectos se definen porque necesita varias acciones para alcanzar esos resultados. De dichas acciones, aquellas que ya podemos realizar, son próximas acciones.
    Propones que en la revisión semanal, se identifiquen las próximas acciones para trasladarlas a la agenda o a su contexto, en función de si hay fecha objetiva o no, respectivamente. En la medida en que en un proyecto, las acciones que lo definen sean secuenciales (es decir, no puedo hacer una acción, hasta no completar una acción anterior, como en el ejemplo de “aceite del motor cambiado” de tu libro), solo podré pasar al contexto o a la agenda una próxima acción relativa a ese proyecto. ¿Qué hago cuando acabe con esa próxima acción? Realmente, hasta la revisión semanal no pasaré al contexto o agenda la siguiente próxima acción de ese proyecto, porque en la revisión diaria solamente revisamos los contextos y la agenda. De esa manera, proyectos con varias acciones de ejecución secuencial, se realizarán a razón de una próxima acción por semana.
    ¿Tiene sentido la reflexión? ¿Cómo solucionarlo para no eternizar la finalización de los proyectos?
    Gracias anticipadas.
    Vicente

    • Jose Miguel Bolivar
      Twitter: jmbolivar

      Hola Vicente,
      Muchas gracias y muy interesante el tema que planteas. La revisión de los proyectos y de las acciones delegadas es uno de los aspectos que en mi opinión es muy mejorable en GTD. Por eso, la mayoría de los usuarios veteranos que conozco, utilizamos dos listas de proyectos y dos listas «a la espera». En ambos casos, una de las listas es de revisión diaria y la otra es de revisión semanal. Lo importante aquí es usar bien este sistema de doble lista para que sea funcional y no al contrario. Como referencia, en las listas de revisión diaria no debería haber más de un 10% del total de tus proyectos y acciones delegadas y su uso debe limitarse exclusivamente a temas que realmente no pueden esperar a las revisiones semanales porque su «ciclo de vida» es inferior a la semana.
      Por otra parte, el que los proyectos se eternizen ni es bueno ni es malo. Que un proyecto hecho en poco tiempo sea mejor que uno hecho en más tiempo es una creencia sin fundamento. Lo que se propone en metodologías como GTD es transformar «intensidad» en «amplitud», ya que aumenta la eficiencia global. Trabajamos a menor ritmo en cada proyecto pero, a cambio, trabajamos en muchos más proyectos. Si en lugar de adelantar 10 acciones de 10 proyectos cada semana adelantas 1 acción de 100 proyectos, el trabajo que realizas es el mismo pero la posibilidad de sinergias entre proyectos (aprovechamiento de contextos, por ejemplo), la tolerancia a imprevistos (acciones delegadas que no se resuelven según nuestras expectativas, por ejemplo) y la sensación de control general es considerablemente mayor en el segundo caso. Además, el empezar los proyectos con fecha tan pronto como sea posible se traduce en que, por lo general, se terminan antes de fecha y no el día antes, deprisa y corriendo 🙂
      Espero haberte sido útil.
      Un saludo

  • Juan Antonio

    Hola José Miguel

    Estoy leyendo tu libro, y repasando el tema de proyectos, he dado con este post y sus comentarios (tendría que haberlo leído en su día, cierto) que me han aclarado algunos puntos. Me surge una duda en la línea del comentario previo de José: al procesar el inbox, según tu esquema de flujo de GTD, sólo pasaría a convertirse en acción si:
    “1-Tiene fecha límite objetiva, es decir, otra persona la ha definido.
    2-No hacer nada antes de la próxima revisión semanal tendrá consecuencias indeseables.
    3-Tienes un compromiso firme e irrevocablede hacer algo antes de la próxima revisión semanal.”

    Con estas condiciones, la mayoría de proyectos no evidentes nunca se procesarán como acciones, y por tanto irían a incubar con algo como crear proyecto para XXX en vez de a la lista de proyectos. ¿Estoy en lo cierto, y no hay que perder tiempo en ese momento, y aplazar la creación del proyecto para cuando decidamos sacar esa acción de la incubadora?
    Gracias por tu blog y enhorabuena por tu libro, es el complemento indispensable a los de David Allen.
    Un saludo
    Juan Antonio

    • José Miguel Bolívar
      Twitter: jmbolivar

      Hola Juan Antonio,
      Muchas gracias. La clave reside más en determinar si es o no un proyecto que cumple alguno de los tres requisitos que en que sea evidente o no. La evidencia del proyecto tiene que ver con la necesidad de llevar a cabo una «planificación natural de proyectos» y es independiente de que el proyecto tenga fecha objetiva, etc.
      Con el tiempo, mis colegas de la red OPTIMA LAB y yo hemos comprobado consistentemente que el cambio de planteamiento de «a ver si puedo hacerlo» a «a ver si puedo NO hacerlo» tiene consecuencias espectaculares en la efectividad personal. Gran parte de nuestros problemas se deben al autosabotaje. Listas de tareas interminables, más compromisos de los que podemos abarcar con un mínimo de realismo, información falsa (fechas subjetivas, por ejemplo)… Todo ello complica innecesaria y extraordinariamente el proceso de toma de decisiones sobre qué hacer en cada momento.
      La clave, como decía Drucker, no es priorizar, sino posteriorizar. La incubación masiva en la lista «Esta Semana No» se traduce en una lista de proyectos de extensión razonable y en unos contextos ligeros y manejables. Y eso ayuda a «ejecutar» y a «lograr».
      Y por responder a tu pregunta, el proyecto solo debe tratarse como tal cuando requiere acción inmediata. Si no, en realidad no es un proyecto sino una «posibilidad» de proyecto (incubamos posibilidades) y por tanto, como bien dices, no hay que perder tiempo en ese momento (ya que podría darse el caso de que nunca llegara a convertirse en proyecto). Por el contrario, si es un proyecto que sí requiere acción inmediata, debemos hacer el esfuerzo de definir con la mayor precisión posible el resultado del mismo, así como la primera acción que nos conducirá al resultado. Resultados claros y una primera acción son casi medio proyecto hecho.
      Un saludo.

  • […] de las últimas semanas los cinco niveles anteriores, es decir, las siguientes acciones,  los proyectos, las áreas de enfoque y responsabilidad, las metas y objetivos y la visión, llegamos […]

Logo redca
sigue este blog en feedly
FacileThings

Categorías