GTD Fácil: Proyectos (I)

“Hay que pensar en las grandes cosas mientras se hacen las pequeñas para que éstas vayan en la dirección correcta” [Alvin Toffler]
Los proyectos merecen un apartado propio en esta introducción a la teoría del GTD. Personalmente manejo dos tipos de proyectos:
1) Lo que David Allen llama proyectos, es decir, resultados que requieren de más de una acción para ser obtenidos. Siendo puristas del GTD, “organizar una reunión” es un proyecto ya que conlleva varias acciones: reservar la sala, convocar a los asistentes, preparar la documentación, etc.
Este tipo de proyectos son bastante básicos y Allen así lo remarca en su libro. Yo no suelo registrarlos como proyectos en mi sistema GTD y me limito a ir atacando sus acciones por separado. Si algo es más complicado o repetitivo me creo una checklist o lista de control que me ayude a llevar a cabo todos los pasos o acciones requeridos. No me complico más. Creo que buscar el equilibrio entre lo que dice GTD y lo que nos funciona es una premisa fundamental.
No obstante, uso lo que Allen llama proyectos para definir y controlar mis áreas de responsabilidad en el trabajo. Y para esto sí que registro tres elementos que considero fundamentales:
a) Objetivos: Me indican qué voy a conseguir con el proyecto.
b) Resultados: Fijan los “entregables” del proyecto, es decir, qué voy a obtener como consecuencia de realizar el proyecto.
Quiero aclarar este punto porque puede llevar a confusión incluso en proyectos gestionados por profesionales en toda regla. Por ejemplo, el resultado de un proyecto puede ser construir una aplicación informática que gestiones las colas de atención a usuarios. Ese es el resultado tangible del proyecto. Pero el objetivo puede ser reducir el personal dedicado a dar tickets a los usuarios o reducir los tiempos de espera presenciales pudiendo solicitar el ticket por internet mediante esta nueva aplicación.
Los jefes de proyecto suelen estar tan centrados en la realización del mismo que confunden resultado con objetivo. De hecho, usualmente se olvidan del objetivo. El objetivo es lo que persigue conseguir el cliente mediante (o a partir de) la ejecución del proyecto.
Reflexionad un momento al respecto y os daréis cuenta de que a veces coinciden pero muchas veces, no lo hacen. Hablando de GTD, y si se trata de un proyecto en que nosotros somos nuestro propio cliente y los ejecutores del mismo (nuestro propio jefe de proyectos), convendría ponernos los dos sombreros en las revisiones periódicas del proyecto.
c) Acciones planificadas: Es una simple lista de las acciones que pretendo seguir, ordenadas en secuencia de ejecución prevista. Es necesario saber en qué punto estamos, es decir qué acción está en proceso de ejecución dentro de nuestro sistema GTD.
Si lo complicamos un poco más podemos hacer una tabla con alguna columna más que el orden de ejecución y una descripción breve de la acción. Podemos añadir el nombre la persona responsable de la acción (nos vendrá fenomenal para las acciones delegadas en otros) y una fecha prevista de fin de la acción (o fecha de fin obligada por plazos legales u otro tipo de requisitos que tengamos).
Con lo anterior me sobra para el 100% de mis proyectos “no comerciales”, es decir, que no requieren una gestión de proyectos basada en alguna metodología específica.
2) Proyectos “comerciales”: Lo que yo llamo proyectos comerciales tienen unas fases determinadas por el propio proceso comercial y las necesidades de registros en sistemas de calidad, bases de datos de conocimiento, etc.
Por mi orientación al mundo TI he manejado metodologías como METRICA para el desarrollo de aplicaciones informáticas Para proyectos de implantación de Infraestructuras se usan metodologías como PMBOK del PMI (Project Management Institute) o cualquiera de los cientos de adaptaciones que te van a ofrecer si eres un “apetitoso cliente”. Es el mundo de los estudios de viabilidad, ofertas, análisis de requisitos, casos de uso, diagramas de Gantt, seguimientos, pruebas unitarias, pruebas de aceptación, etc.
No le tengo excesiva simpatía a este mundo porque considero que “engorda” demasiado los costes de un proyecto y lo dilata en el tiempo, muchas veces innecesariamente. Además, no se analiza si el proyecto requiere de este esfuerzo extra sino que suele hacerse “de serie” para todos los proyectos, anegando la ejecución de los mismos con un mar de hitos, entregables, reuniones y documentación variada.
Hay una excelente cita de George Santayana que dice que “el fanatismo consiste en redoblar los esfuerzos cuando se ha olvidado el objetivo”. Mucho ojito con esto y con ser expertos en hacer perfectamente lo que no es necesario hacer. La mente clara y el chocolate espeso.
Para ser justos, creo que también se pueden sacar ideas interesantes de estas metodologías que puedan ser aplicables de manera efectiva a nuestras necesidades GTDianas.
Bueno, como al final me he alargado excesivamente en lo que pretendía ser mi punto de vista de los proyectos (en todo un alarde de improductividad que espero a alguien le resulte mínimamente interesante) le dedicaré próximamente una entrada específica a cada tipo de proyecto citado, mezclando el punto de vista de Allen con mi propia experiencia.