Fechas límite y proyectos GTD

‘Liquid Carbon’ by Mike Krüger

Cuando hablamos de efectividad, las fechas lo son todo. Como muchos ya sabéis, ser efectivo significa, por un lado, ser eficientes —hacer las cosas utilizando la menor cantidad de recursos posible, incluido el tiempo—, y por otro, ser eficaces —conseguir los resultados que se persiguen, en tiempo y forma. Como se puede ver, ambas partes de la ecuación de la efectividad consideran el tiempo: la eficacia nos sirve para poder cumplir las fechas límite, y la eficiencia para hacer las cosas en el menor tiempo posible.

Sin embargo, lo que sucede habitualmente es que sólo consideramos el tiempo en la medida en que afecta a nuestra eficacia, rara vez en relación a nuestra eficiencia. Y eso, como veremos enseguida, tiene un gran impacto en cómo gestionamos nuestra atención y, por ende, nos suele meter en bastantes líos a la hora de trabajar.

Cuando iniciamos un proyecto en GTD, un primer error a evitar es poner como fecha límite la fecha en la que nos gustaría tener el proyecto terminado, ya que eso supone un gravísimo problema. Como ya he explicado en otra ocasión, sólo deberíamos utilizar fechas objetivas, es decir, fechas verdaderamente impuestas por condiciones externas a nosotros. De otro modo, estaríamos introduciendo elementos de presión extras innecesarios, pues una fecha autoimpuesta —subjetiva—, siempre puede cambiarse llegado el momento sin necesidad de negociar con nadie. Por tanto, mejor no utilizarlas desde un principio.

Asumiendo que utilizamos sólo fechas limite objetivas, es decir, fechas que vienen impuestas por condiciones externas, como por ejemplo la fecha comprometida por contrato para la entrega de una obra, de todos modos solemos hacerlo mal. David Allen deja meridianamente claro en su libro Getting Things Done que los proyectos no se hacen, lo que se hacen son las acciones dentro de un proyecto. Es decir, que un proyecto no es más que la expresión de un resultado que queremos conseguir, suma de los resultados conseguido por las distintas acciones que lo componen. Por eso, como muy bien argumenta mi amigo y maestro Antonio José Masiá en su blog, decimos que en GTD los proyectos no tienen fecha. Lo único que podría tener una fecha límite son las acciones que debemos ejecutar para conseguir el resultado final.

Entonces, si un proyecto no tiene fecha límite, ¿cómo podemos controlar la fecha de entrega final? Bueno, si un proyecto GTD es un resultado que queremos alcanzar, podemos decir que se trata de un objetivo a corto-medio plazo y, por tanto, se le pueden aplicar los mismos criterios S.M.A.R.T. que utilizamos para la definición de objetivos inteligentes, o como el mismo Antonio José dice, podemos “esmartizar” el nombre del proyecto. Es decir, incluir la fecha límite como parte del nombre del proyecto. La fecha límite sería la “T” de S.M.A.R.T. —del inglés time-bound, o limitado en el tiempo. Así, por ejemplo, en el caso de la obra, en lugar de registrar en nuestra herramienta “Obra de X terminada” con fecha límite 1 de agosto, registraríamos “Obra de X entregada antes del día 1 de agosto” sin fecha límite.

Estoy seguro de que para muchos esto es casi un sacrilegio. Acostumbrados a ponerle fechas de vencimiento a todo, el prescindir de fechas de vencimiento formales para los proyectos debe sonar irreal, por decirlo suavemente. Sin embargo, hay una razón de peso para hacerlo. Ponerle fecha límite a un proyecto hace que vayamos retrasando su ejecución todo lo que podemos, hasta que consideramos que ya no se puede esperar más, en lugar de intentar acometer cada siguiente acción lo antes que nos permitan las circunstancias. Este es un fenómeno que seguro habéis experimentado muchas veces, no me lo estoy inventando, y además está respaldado científicamente. El Dr. Piers Steel ya lo documenta exhaustivamente en su libro Procrastinación, cuya lectura os recomiendo.

Por tanto, la gestión de proyectos clásica fomenta que nos centremos en la eficacia y nos olvidemos de la eficiencia. No hacer las cosas lo antes que podamos, simplemente porque aún queda tiempo, es casi un suicidio productivo. Dado que vivimos en un mundo líquido, donde los imprevistos surgen todos los días por doquier, y como las cosas tienen la manía de complicarse todo el tiempo contra ¿toda lógica y pronóstico?, lo que suele suceder al final es que nos pilla el toro, terminamos corriendo y estresados para poder cumplir con las fechas, cuando no directamente las incumplimos.

En OPTIMA LAB, la red de consultores artesanos en las que trabajamos juntos Antonio José Masiá y yo, entre otros colegas, tenemos comprobado que, manteniendo un equilibrio adecuado entre eficacia y eficiencia —lo que implica no usar fechas límite para los proyectos ni para ninguna de sus acciones, salvo la última—, los proyectos generalmente se terminan antes de fecha. ¿El secreto para conseguirlo? Revisar, revisar y revisar, la piedra angular de GTD.

4 comentarios

  1. Desde mi punto de vista, da igual en qué campo apuntas la fecha final del proyecto: en el campo ‘fecha de vencimiento’ o como parte de la descripción del proyecto. Lo importante es apuntarlo en algún lugar para tenerlo claro cuando revisas el proyecto.

    Lo que sí que es importante es distinguir entre fechas finales objetivos y tus deseos. Justo por esta razón no soy muy fan de ‘esmartizar’ todos los proyectos. Si es un proyecto sin fecha final, simplemente hay que terminarlo lo antes posible y es mejor no ponerlo fecha final. Si revisas tus proyectos con frecuencia tendrás el progreso asegurado.

  2. el asunto de no usar fechas no objetivas, tanto en proyectos como en acciones es una de las cosas que más revuelo causa en la gente. Seguramente también te lo hayas encontrado en aula al igual que yo.

    Me gusta en especial lo que comentas de que al poner fecha a un proyecto que no debería tenerla (es decir, que se tiene que hacer lo antes posible), se consigue el efecto contrario: se va dejando sin hacer hasta que se acerca la concreta.

    El poner fecha objetiva a un proyecto es interesante porque te permite saber que, las acciones que tienes que hacer para completar el proyecto, las tienes que hacer antes de esa fecha. De esa manera, a la hora de revisar qué hacer tienes un criterio objetivo de por donde empezar.

    Un abrazo!

  3. Me ha gustado mucho tu artículo Jerónimo. Independientemente de si poner fecha límite o no nos ayude realmente a terminar el proyecto “a tiempo”, lo fundamental es, como dices, “revisar, revisar y revisar” , piedra angular del GTD y el time tracking cuando se usa no para control de tiempos sino para mejorar el desempeño :)
    Saludos de primaERP!

    • El problema, Mónica, es que poner fechas de vencimiento “ficticias”, al igual que el vicio de utilizar alarmas para todo, es que desincentiva el hábito fundamental de la revisión, que tiene mucho más valor productivo. De hecho, con una frecuencia de revisión adecuada de cada lista y del calendario, como explico en todos mis talleres, la necesidad de inventarte fechas y poner alarmas desaparece por completo.

      Es una idea que genera mucha fricción al principio, porque creemos que sólo mediante alarmas y fechas de vencimiento por doquier podemos tener el control de las cosas. Pero eso es una creencia falsa. La realidad es que, cuando te molestas en poner a prueba esa creencia, te das cuenta de que no tiene ningún fundamento. Si fuera verdad, todo el mundo sería muy eficiente simplemente poniendo alarmas a todo.

Deja un comentario