Proyectos GTD (avanzado): Los errores más frecuentes

En el primer post de esta serie – «Proyectos GTD® (avanzado): Conceptos, diferencias y relaciones» veíamos precisamente eso: los principales conceptos relacionados con los proyectos en GTD^®, así como las diversas diferencias y relaciones entre dichos conceptos.

En este segundo post de la serie vamos a centrarnos sobre los errores más frecuentes que se cometen al trabajar con los proyectos en GTD^®.

Malinterpretar el concepto «proyecto» de GTD^®

Este es, probablemente, el error principal que cometen las personas que se acercan por primera vez a GTD^® y al concepto de «proyecto» en particular.

Para la mayoría de quienes desconocen GTD^®, un proyecto es algo típicamente complejo, en el que normalmente se trabaja durante un periodo de tiempo considerable en una diversidad de asuntos orientados a un tema concreto.

Los proyectos «normales» suelen costar dinero, a menudo bastante, e involucrar a colectivos relativamente amplios. Por otra parte, los proyectos se suelen percibir como una actividad profesional de más valor que el trabajo rutinario.

Ante esta idea predefinida de «proyecto», es muy habitual un cierto rechazo al concepto de «proyecto» que plantea GTD^®, ya que en un gran porcentaje de los casos estos «proyectos» están relacionados con temas mucho más sencillos y cotidianos.

A raíz de este rechazo, muchas personas cometen el error de no aplicar el criterio de GTD^® para decidir si algo es o no es un proyecto, y en su lugar ser ellas las que «deciden» llamar proyectos únicamente a lo que ellas «creen» que es un proyecto.

La consecuencia del error anterior es que los sistemas GTD^® de estas personas carecen de un inventario completo y actualizado de resultados, lo que hace imposible que puedan contar con una «mente extendida».

Confundir los proyectos de GTD^® con inventarios de acciones

Otro error muy habitual es creer que los proyectos son contenedores de acciones, es decir, esquemas o listas con todas las acciones que hay que completar para dar por concluido el proyecto. Este error se ve potenciado por el planteamiento erróneo que hacen muchas aplicaciones «supuestamente» específicas para GTD^®.

Además, este error se ve también reforzado por la costumbre que tienen muchas personas de trabajar «por proyecto», es decir, poniéndose a trabajar sobre las diversas acciones de un proyecto, con la intención de completar cuantas más, mejor. Esta forma de trabajar es muy distinta de la que propone GTD^®, que es trabajar en función del contexto, tiempo y energía disponibles.

Explicado con otras palabras, en lugar de «encadenar» la ejecución de acciones simplemente porque pertenecen a un proyecto, en GTD^® se «encadenan» porque tienen algo en común que es necesario para poder ejecutarlas: estar en un sitio concreto, disponer de una herramienta determinada, estar hablando o reunidos con una persona o grupo de personas específicos, independientemente de a qué «proyecto» pertenezcan las acciones que se están completando.

Otro problema derivado de este error es que se mezclan las «siguientes acciones» (las que ya se pueden hacer, sin necesidad de completar acciones previas) con las «acciones» (que aún no se pueden hacer, ya que previamente hay que completar otras acciones). Ya sabemos que mezclar elementos con significados distintos en un mismo sitio es contrario a organizar con efectividad.

Creer que todos los proyectos de GTD^® tienen que estar en la «Lista de proyectos»

La «lista de proyectos» de GTD^® es, ante todo, una lista de temas pendientes en los que quieres, tienes o necesitas pensar durante tu revisión semanal.

En línea con lo que comentaba hace un momento acerca de «evitar mezclar al organizar», incluir «proyectos» sobre los que no va a ser necesario pensar en ninguna «revisión semanal» junto con aquellos otros sobre los que sí va a ser necesario pensar, es una mala práctica.

Que algo sea un «proyecto» es distinto de que tenga que estar en la «lista de proyectos».

En este sentido, podemos distinguir entre «proyectos evidentes» y «proyectos no evidentes». Otra posible forma de referirnos a ellos es como «proyectos autogestionados» y «proyectos no autogestionados». En ambos casos, hablamos de lo mismo.

Hay «proyectos», es decir, resultados, que requieren más de un paso y que podemos alcanzar en un año, que son evidentes/autogestionados. Esto significa que no es preciso pensar sobre ellos durante la «revisión semanal» porque las nuevas «siguientes acciones» van apareciendo de forma natural y espontánea en la medida que vamos completando las anteriores.

Un ejemplo de proyecto evidente o autogestionado sería «hacerme una revisión dental». La siguiente acción sería «llamar al dentista para pedir cita» y, una vez tuviéramos la cita, la siguiente acción sería «ir al dentista». Según la definición de GTD^®, «hacerme una revisión dental» es un proyecto, ya que a) requiere más de un paso y b) lo puedo conseguir en menos de un año. Sin embargo, añadir «hacerme una revisión dental» a la «lista de proyectos», sería absurdo.

Veamos por qué es innecesario tener «hacerme una revisión dental» en la «lista de proyectos»:

1. Cuando el proyecto aparece por primera vez en mi radar, lo capturo.
2. Cuando lo aclare y organice en mi sistema GTD^®, tendré una siguiente acción «llamar al dentista para pedir cita» en mi contexto @llamadas o @teléfono.
3. Cuando llame al dentista, me darán hora. Esa hora puedo bien capturarla, bien ponerme directamente un recordatorio en mi «calendario».
4. Cuando haya ido al dentista, habré conseguido el resultado.

Como puede observarse, en ningún momento se corre el riesgo de que el «proyecto» desaparezca de nuestro sistema por error, ni tampoco se ve ninguna necesidad de pensar en él durante nuestra «revisión semanal».

Por desgracia, hay otros muchos proyectos que sí necesitan esta «revisión semanal» para asegurar que siguen avanzando, del mismo modo que también hay proyectos en los que sí corremos el riesgo real de que desaparezcan de nuestro sistema al completar una «siguiente acción» si no hay un recordatorio en la «lista de proyectos» indicando que siguen siendo estando pendientes.

En cualquier caso, el criterio para incluir o excluir un proyecto de la «lista de proyectos» nunca debería ser si tú «crees» que es o no es un proyecto, sino si a) necesitas revisarlo regularmente o b) podría desaparecer inadvertidamente de tu sistema antes de completarse.

Confundir los proyectos con los objetivos o con las áreas de enfoque y responsabilidad

Otro error habitual es confundir los «proyectos» con «objetivos» o con «áreas de enfoque y responsabilidad».

El primer error es bastante lógico, ya que la mayoría de lo que en el lenguaje profesional se suele llamar «proyecto» en GTD^® se corresponde más con un «objetivo».

Un objetivo es un resultado que requiere más de un paso y más de un año para completarse. Normalmente, un objetivo va a incluir varios «proyectos». «Cambiarme de casa», por ejemplo, es probable que sea más un «objetivo» que un «proyecto». «Encontrar una nueva casa» o «hacer la mudanza a la nueva casa» serían «proyectos» que formarían parte de este «objetivo».

Algo parecido ocurre con las áreas de «enfoque y responsabilidad». Recuerda que las «áreas de enfoque y responsabilidad» nunca se completan, sino que siempre están activas. «Hacer deporte», por tanto, es un «área de enfoque o responsabilidad», mientras que «encontrar un nuevo gimnasio cerca de casa» sería un «proyecto» perteneciente a ese «área de enfoque o responsabilidad».

Del mismo modo, ir al gimnasio el martes y el jueves de 18:30 a 20:30 serían «siguientes acciones» recurrentes pertenecientes a esa misma «área de enfoque o responsabilidad», pero no pertenecen a ningún proyecto.

No revisar la «lista de proyectos»

Este es también un error muy habitual. La revisión de la «lista de proyectos» es – probablemente – uno de los pasos de mayor valor añadido de toda la «revisión semanal».

El paso «Reflexionar» significa, entre otras cosas, evaluar semanalmente en qué estado están todos y cada uno de nuestros proyectos de la «lista de proyectos», asegurarnos de que todos ellos tienen al menos una «siguiente acción» activa en alguna de las demás listas de GTD^® y pensar si hay que hacer algo en relación a ellos (añadir, eliminar, cambiar…).

Aunque parezca una perogrullada, una lista que no se usa es una lista que no sirve para nada. Tener una «lista de proyectos» y no revisarla a fondo en la «revisión semanal» es tener una lista «de adorno» que solo sirve para darte trabajo extra.

Próximos posts

Hay más, pero en este post he querido centrarme en cinco errores «clásicos» que se cometen con los «proyectos» de GTD^®. En próximas entradas comenzaré a responder a las dudas más habituales que me plantean sobre este tema, y aprovecharé también, cuando tenga sentido, para dar visibilidad a otros errores menos frecuentes, pero también comunes.

Recuerda que, si te interesan los proyectos GTD^® y quieres saber más sobre ellos, en el grupo de Slack «Aprendiendo GTD^®», en el canal #gtd-alt-2-proyectos, hay un hilo en el que puedes plantear tu dudas o preguntas y que, para formar parte de esta comunidad de aprendizaje y plantear tus dudas, debes previamente registrarte, lo cual puedes hacer directamente desde su página web.

[DISCLAIMER: «Aprendiendo GTD^®» es una iniciativa particular promovida y gestionada por Manolo Molero, Luis Sánchez Blasco y Sergio Pantiga de forma completamente autónoma e independiente de OPTIMA LAB y la David Allen Company. Tanto mi participación como la participación de otros nodos de OPTIMA LAB en dicha iniciativa es únicamente en calidad de usuarios de GTD^® y nuestra presencia en esta comunidad de aprendizaje no constituye ni implica en ningún caso el aval, respaldo o apoyo a los contenidos, afirmaciones u opiniones particulares expresadas por los restantes miembros de dicha comunidad.]