Lo que no se puede hacer, no se puede hacer con fecha

Sigo a Jeroen Sangers desde hace muchísimo tiempo, y he aprendido mucho y sobre todo seguiré haciéndolo leyendo sus publicaciones en El Canasto. Hace unas semanas Jeroen compartía uno de mis últimos post del año pasado en el que hacía una reflexión acerca del uso de las fechas en los proyectos. Me hubiese encantado haber podido conversar con él en su blog a raíz de sus comentarios, pero al no ser posible he decidido abrir conversación sobre el tema de forma abierta mediante este post.

La intención del post que publiqué hace unos meses, fue básicamente la de provocar una reflexión acerca de las consecuencias del uso aleatorio de las fechas, de forma más concreta sobre los proyectos. En él afirmaba que los proyectos en GTD© no tienen fecha, porque como dice David Allen «You don’t actually do a project; you can only do action steps related to it», y algo que no se puede hacer, no puede hacerse en una fecha o antes.

Comenta Jeroen que la idea que planteo, que emerge de la propia definición de proyecto que hace el propio David Allen y de mi última afirmación, no tiene nada que ver con GTD©, dado que en ningún momento habla David Allen de la relación entre los proyectos y las fechas. Esto último es cierto, en ningún momento habla de ello, pero ni en un sentido ni en otro. Es más, tampoco habla en ningún momento de fechas de forma concreta, salvo cuando explica el uso de la herramienta calendario.

Cuando llevas tiempo usando GTD© te das cuenta que muchos aspectos del método no quedan bien explicados e incluso en algunos casos las explicaciones que aporta la bibliografía resultan contradictorias ante ciertos principios fundamentales de la metodología, como comentaba José Miguel Bolívar en uno de sus últimos post.

«I define a project as any desired result than can be accomplished within a year that requires more de one action step.»

David Allen es coach, y como tal, sabe que para definir un resultado hay que hacerlo de forma específica, concreta, medible, realista, alcanzable y acotado en el tiempo. Lo que ocurre es que no lo explica. La propia definición de proyecto ya acota los resultados al ámbito máximo de un año, quedando acotado en el tiempo de forma implícita. Ahora bien, si el resultado ha de alcanzarse antes de una fecha o en una fecha concreta, esta condición ha de reflejarse en la propia definición del resultado, quedando igualmente acotado en el tiempo. En este sentido podríamos tener un resultado definido de la siguiente forma: «informe de balance XXX enviado al departamento YYY el 17 de abril», o bien «informe de balance XXX enviado al departamento YYY antes del viernes 17 de abril».

La tendencia general cuando se comienza a usar GTD©, es la de asignar a todas las acciones del proyecto el plazo de vencimiento definido en el resultado que se pretende alcanzar. Esto es un error. Cuando se da este caso, como explicaba en mi post anterior, la única acción que deberá tener fecha objetiva es la última, ya que es la que te permitirá alcanzar el resultado, siendo además la única a la que realmente podrías llegar tarde.

Cuando te encuentras ante proyectos con plazos en tus revisiones semanales e incluso diarias, tu cerebro sabe a la hora de priorizar sobre tus listas de siguientes acciones, cuáles son las opciones que has de elegir en primer lugar. Esta habilidad se consigue desarrollando el hábito de revisar. Mientras no tengas este hábito, seguirás teniendo la tentación de asignar fechas subjetivas a las acciones intermedias del proyecto, dado que no te fías ni de tus hábitos ni de tu sistema.

Del critical path hablaré otro día. Sólo comentaré que lo usé durante muchos años en proyectos de toda índole y no me sirvió jamas ya que es una técnica del pasado que sólo funciona en entornos plenamente estables y predecibles.

Conclusión: en GTD© los proyectos no tienen fecha, porque lo que no se puede hacer, no se puede hacer con fecha.

Esta entrada Lo que no se puede hacer, no se puede hacer con fecha has sido publicada por Antonio José Masiá