Blog.

Hoy va de generalidades.

Sección I, Estructura de la Gestión de Proyectos.
Capítulo 2, El contexto de la Gestión de Proyectos

Para un equipo de diseño el empleo de las técnicas de la gestión de proyectos debe aportar orden, certeza y seguridad. A mi modo de ver, junto a una clara y compartida definición del alcance, la planificación de las fases del proyecto es la mayor motivación para adoptar estas herramientas en el mundo del diseño. De esta manera se establece el ciclo de vida del proyecto, lo que es el comienzo no sólo para marcar tareas a lo largo del tiempo, si no además quién participará en ellas, los recursos necesarios o qué información debe ser comunicada en cada momento. Es la base.

La planificación de las fases debe entenderse como una estratificación: cada estrato se define por la interfase entre él y los que lo separan. Esta interfase será cada entrega, cada cambio de proceso, cada aprobación. Comúnmente, a este momento se le llama hito, y al cambio de estado del proyecto que hace que exista un hito se le llama prestación. No tiene sentido marcar un número exagerado de hitos en la planificación del ciclo de vida de un proyecto de diseño, esto puede afectar negativamente al trabajo de los diseñadores, con cambios de rumbo cuando se encuentran trabajando. El diseño es iterativo; y romper el proceso abductivo será contraproducente. Es importante ver resultados y que estos se presenten en tiempo. Pero no es tan importante que cada semana haya una revisión.

Los hitos no deben ser vistos únicamente como una meta volante a la que se ha llegado olvidando el camino recorrido y con la vista puesta en la siguiente meta. Deben servir como puntos de reflexión en los que se evalúe el proceso y el resultado, es el momento de hacerse preguntas. En caso de que sea necesario deben ser también puntos de inflexión en los que aplicar las medidas necesarias para que el proyecto llegue a buen fin.

Son pocos (o ninguno…) los proyectos desarrollados de una manera completamente lineal en los que una fase no comienza si no se ha terminado la anterior. Lo más normal es que las fases discurran con solapamientos o con tramos en paralelo. Los solapamientos tienen un cierto riesgo que hay que considerar, ya que permiten que comencemos la fase X sin haber terminado la Y. Seguro que necesitaremos información proveniente de Y para completar X, y si existen cambios cuando la segunda fase ya ha comenzado lo que parecía una manera de ganar tiempo puede convertirse en un derroche de esfuerzos. Además no conoceremos el resultado de la evaluación del proceso que tantos beneficios puede traer.

Un ejemplo muy sencillo. La fase III de un proyecto consiste en el modelado mecánico de un equipo de maquinaria industrial, la fase IV preparará los planos. Cuando las primeras piezas están modeladas puede ganarse tiempo haciendo sus planos. Sin embargo esto puede ser una pérdida de tiempo si en el ensamble del conjunto se encuentran problemas en una pieza y esta debe ser rediseñada. Avanzar empleando el fast tracking¹ puede hacernos ganar tiempo, pero el riesgo debe estar siempre bajo control.

Hay infinitas maneras de llamar a las fases, y no todos los proyectos tendrán las mismas. Es muy fácil justificar una estructura en un manual y venderla como la más adecuada, pero lo importante no es definir si la conceptualización es parte del anteproyecto, o si los testeos forman parte del desarrollo del producto. Lo importante es que la estructura esté interiorizada y sea muy fácil de entender. Esto es lo que ayudará a que seamos capaces de distinguir dónde comienza una fase y termina la siguiente, en qué tarea y con que requerimientos. Permitirá además flexibilizarla o adaptarla a distintos proyectos.

Cada manera de presentar el ciclo de vida del proyecto se va a adecuar a las necesidades de un tipo de proyecto concreto. Sin embargo, para el campo del diseño yo crearía un diagrama de Gantt² muy simple acompañado por una hoja de tareas. ¿Por qué? El diagrama de Gantt es un clásico, casi un estándar, cualquier programa de gestión de proyectos lo emplea como base, es muy fácil extraer la ruta crítica a partir de él y, sobre todo, es extremadamente fácil de leer. Es visual y es muy sencillo aprender su lenguaje. Si lo acompañamos de una hoja de tareas en texto exponiendo en qué consiste cada tarea, quién la desarrollará, la información necesaria como imput y la información exigida como output, cualquier miembro del equipo puede tener acceso a un montón de información de un modo muy sencillo y sin necesidad de recibir formación sobre el tema. Se trata de ganar tiempo y seguridad, no de perderlos.

Hay también muchas maneras de llamar a aquellos a los que afecta el proyecto: stakeholders, clientes, usuarios… Cada nombre tiene sus matices, pero no es mi objetivo teorizar sobre esto. Lo importante es ser consciente de qué personas, grupos y organizaciones se van a ver afectados por el proyecto y su resultado y cómo serán afectados. Posiblemente el punto más peliagudo sea controlar las expectativas de todos, mantenerlas dentro de la realidad y en la misma dirección. En mi humilde opinión, ante un conflicto de intereses el usuario debe ser el que salga ganando, así ganará el producto y finalmente el cliente. Esto es muy simple pero hace falta recordarlo.

La gestión de proyectos no es una atalaya desde la que se controle el desarrollo del diseño, está en contacto y bajo la influencia de muchas otras actividades. El PMBOK describe las características de aquel que debe tener las responsabilidades de PM dentro del equipo de diseño: liderazgo, capacidad de comunicación, habilidades de negociación y solución de problemas, tener un espíritu inspirador… Dejando a un lado las apreciaciones personales, todas estas características son ciertas y deseadas, pero en la mayor parte de los casos, lamentablemente, el gestor de proyectos será el diseñador con más años o uno de los socios de la empresa, sin tener en cuenta que cumpla con estos requerimientos o que tenga conocimientos sobre gestión de proyectos. Esto es algo que debe cambiar.

Bonus: Video del Maestro Herbert von Karajan en un ensayo. Muchas veces he oído que el project manager tiene que ser un director de orquesta, capaz de tocar todos los instrumentos, que debe saberse la partitura de memoria y motivar a todos los los miembros de la orquesta. Creo que es bueno quitar a todo esto un poco (bastante) de importancia. Por favor, que cada Karajan que nazca se convierta en director de orquesta, que no se le ocurra gestionar proyectos.

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.

1. Fast tracking es el nombre que se da a los solapamientos en fases o tareas. Consiste en poner a trabajar en paralalo procesos que en otro caso discurrían uno tras otro, siendo los outputs del primero los imputs del segundo. ↩
2. El diagrama de Gantt es una representación gráfica sobre unos ejes ortogonales de las tareas de un proyecto frente al tiempo y de sus interacciones. ↩

Publicado el 18 de Mayo de 2010

Diseño | 1 comentario »