Al turrón
Sección I, Estructura de la Gestión de Proyectos.
Capítulo 1, Introducción
El PMBOK comienza definiendo qué es un proyecto, y lo hace contraponiéndolo a la otra manera de ejecutar el trabajo, las operaciones. Simplificando, los proyectos se desarrollarán una vez, durante un tiempo determinado, mientras que las operaciones se desarrollan repetidas veces a lo largo del tiempo. La búsqueda de clientes por parte del equipo comercial de un estudio puede ser una operación, desarrollar un nuevo producto para uno de ellos un proyecto: existirá un único resultado – un modelo 3D, un fichero .ai, unos planos – y se desarrollará a lo largo de un período de tiempo limitado.
Profundizo un poco más en la idea de temporal. Esto significa que todo proyecto tendrá un inicio, un desarrollo y un final. ¿Cuándo llega este final? La respuesta parece sencilla: cuando se entregue al cliente. Esto no es necesariamente así, porque habrá casos en que se detecte la imposibilidad de resolver el problema o el proyecto se enfríe. Esta última es la peor de las situaciones, ya que deja el proyecto en el limbo y seguramente una relación enrarecida entre el equipo de diseño y el cliente. La temporalidad se refiere sólo al proyecto, no al producto. A Dieter Rams le tomó un tiempo determinado crear el Shelving System 606, pero hoy día Vitsœ sigue vendiéndolo y el público apreciándolo.
Es muy complicado delimitar más qué es un proyecto genéricamente, ya que su estructura, duración, fuerza de trabajo o forma legal son totalmente variables, y no harán otra cosa que ajustarse a las necesidades en cada caso. Muchas veces los proyectos forman parte de una jerarquía estratégica: programa > proyecto > subproyecto. Esto puede afectar al equipo de diseño de dos maneras. La primera es si tiene la suerte de influir en el programa, afectando la línea estratégica de la empresa. La segunda, quizá menos afortunada, es cuando tiene que trabajar bajo los requerimientos de un programa definido por otros que pueda encorsetar su trabajo.
El concepto probablemente más interesante a introducir en este punto es el de alcance. El alcance es aquello que queremos conseguir, y en ocasiones incluso cómo queremos conseguirlo. Para el mundo del diseño debemos contemplar tanto el alcance del proyecto como el alcance del producto. El alcance del proyecto es sencillamente qué objetivo tiene el proyecto: “un conjunto de archivos IGES con la carcasa de una aspiradora de mano e indicaciones previas para la inyección en plástico“. Debe definirse desde el principio, puede tener variaciones, pero estas deben ser más depuraciones que evoluciones. Debe mantenerse bajo control y ser reconocido por diseñador y cliente.
El alcance del producto es un concepto completamente distinto. Es el resultado, no el objetivo. La respuesta al problema “carcasa de aspiradora de mano en formato IGES” puede tener infinitas soluciones posibles. Si el alcance del proyecto debe estar controlado dentro de unos límites, el alcance del producto tiene una sanísima incerteza. Por muy planificado que esté el proceso, por muchos exámenes, modelos, datos y experiencias pasadas que se hayan analizado, las soluciones se conseguirán de un modo más o menos iterativo, más o menos progresivo. Nos acercaremos con el tiempo y el trabajo. El propio avance del proyecto lo definirá más y más. La gestión de proyectos aporta certezas desde el momento del planteamiento, pero esta mayor seguridad no borra las incertidumbres naturales del diseño. Es muy sencillo: al diseñar se crea algo nuevo, y por tanto algo con aspectos desconocidos que no es posible controlar por completo. El resultado es predecible, pero no anticipable.
Algo a tener en cuenta: no siempre se puede culpar al cliente de los cambios en el alcance. Los diseñadores también se alejan del brief en busca de la innovación, de conseguir un mejor producto o mayor repercusión. Además las responsabilidades en un proyecto son compartidas. Siempre. Incluso cuando el cliente intenta salirse del camino planteado es responsabilidad de quien gestione el proyecto desde el equipo de diseño recordarle la ruta.
Los campos de intersección entre las responsabilidades funcionales de la gestión tradicional y la gestión de proyectos son múltiples, yendo desde la selección de personal a la gestión de la información. Los equipos de diseño, sobre todo aquellas estructuras más reducidas, están muy acostumbrados a manejar muchas responsabilidades ajenas al diseño, a realizar labores comerciales o de comunicación y suelen ser muy flexibles.
Creo que es muy interesante aclarar que las técnicas que describe el PMBOK o cualquier otra filosofía de gestión de proyectos no son herramientas de productividad personal del estilo de GTD. Estas herramientas, muy populares actualmente, ayudan a ser más productivo en el día a día, a sentirse mejor con el trabajo realizado, a mantener el estrés bajo, y estoy seguro de que son complementarios, pero en ningún caso sustitutivos. Estas herramientas tienen un campo de actuación distinto que se extiende hasta las operaciones, pero no sirven para planificar el diseño de una nueva lámpara aunque ayuden a que aquellos encargados de modelar sus piezas a cumplir con las tareas asignadas dentro de una fase concreta en el tiempo y forma debidos.
Bonus: El vídeo de 2′ 52” que acompaña a esta entrada es un triple bonus. Se trata de Mark Adams, Director de Vitsœ, hablando sobre la atemporalidad del resultado de los proyectos temporales que desarrollan. En cristiano, de la sana pervivencia de sus productos. Solo una cita, que daría para muchas entradas:
The concept is to reuse your furniture… We see recycling as a defeat.
Esta entrada forma parte de un conjunto de anotaciones sobre las técnicas y herramientas descritas en el PMBOK del PMI para la gestión de proyectos, enfocadas a la gestión de proyectos de diseño.