Después de semanas sin tocar esto toca retomarlo con la última parte dedicada a la introducción de conceptos comunes.
Sección I, Estructura de la Gestión de Proyectos.
Capítulo 3, Los procesos de la Gestión de Proyectos
La gestión de proyectos se ocupa de cuidar la relación de muchas variables, relacionadas siempre a través de los conceptos de coste, tiempo y alcance.
Esta competencia clásicamente se expresa en la forma del Triángulo de la gestión de proyectos: algo muy simple pero también muy gráfico. En sus vértices tenemos los conceptos de coste, tiempo y alcance.
Debemos ser conscientes de que existe una dependencia entre estas variables, de tal manera que no es posible desplazar uno de los vértices sin que esto afecte a los demás. En estas relaciones debemos buscar lo imposible para conseguir lo improbable sin perder de vista la realidad.
En el tiempo en el que la calidad se ha convertido en un concepto en tendencia, se han propuesto esquemas en los que el triángulo se convierte en un cuadrilátero, con el vértice calidad compitiendo frente a los tres originales. A mi entender esto no debe plantearse de esta manera, ya que se puede convertir en un factor de fiabilidad exigible al resultado del proyecto frente al mismo proyecto, cuando toda la fiabilidad es exigible. Si de lo que realmente hablamos es de calidad del producto, esta debe ir especificada en el alcance, bien sea en tolerancias de fabricación industrial o en los tristes planes de obsolescencia.
Para poder observar las relaciones que forman cualquier proyecto es necesario primero fraccionarlo, identificar sus unidades fundamentales y clasificarlas según su orientación y función. Anteriormente en esta serie de entradas hablé de las fases de los proyectos. Cada fase tiene múltiples subfases y se articulará sobre distintas tareas y funciones.
Por ello y en paralelo a las fases del proyecto debemos establecer un concepto relacionado, el proceso. Un proceso es una serie de acciones que busca un resultado. Una fase es un contenedor con cara a un resultado, un proceso es un contenedor de acciones conexas. Directamente ligado a las fases del proyecto aparecen los procesos orientados al producto. Son aquellos que influirán en el producto del proyecto. Son aquellos procesos que influyen directamente en el producto del proyecto. Por otro lado, están los procesos de gestión de proyectos, aquellos que darán soporte a la planificación, control y evaluación del proyecto. Son aquellos procesos que podemos entender como parte de la burocracia proyectual, tienen influencia en el proyecto, pero no se verá de un modo. Los procesos orientados a la gestión y los orientados al producto se retroalimentan, tanto en datos como en funcionamiento. No es posible documentar el resultado de un prototipado sin que exista tal prototipo.
Según el PMBOK, los procesos orientados a la gestión del proyecto se clasifican en:
Los grupos de procesos se entrelazan a diferentes niveles; primero iterativamente dentro de cada fase, repitiendo el ciclo Planificación – Ejecución – Control: planificamos, ejecutamos y controlamos la conceptualización, también planificamos ejecutamos y controlamos la industrialización y cualquier otra fase. Posteriormente, fase tras fase, los Procesos de Cierre dan paso e incluso se solapan con los Procesos de Iniciación. Si vamos a escalas menores, a las subfases, sucederá exactamente lo mismo.
Esta estructura es muy fácil de extrapolar a un proyecto de diseño de producto. Es claro el paralelismo entre Planificación – Ejecución – Control y la iteración que existirá en las fases de de-brief, conceptualización, desarrollo. Simplemente hay que recordar de que Planificación, Ejecución y Control son grupos de procesos orientados a la gestión del proyecto. Se planificará, ejecutará y controlará el desarrollo del proyecto. Esto significará que se planificarán acciones enfocadas al de-brief, se ejecutarán las tareas desarrolladas en el plan y finalmente de controlarán los resultados y procesos empleados en el de-brief. Una vez más, lo que vincula un grupo de procesos con el siguiente es el tránsito de información de unos a otros.
Que un proceso no esté descrito en el planteamiento del proyecto no quiere decir que no se pueda hacer. Es necesaria una flexibilidad que permita incluir un testeo no previsto o la cotización de un servicio que inicialmente se iba a realizar inhouse.
La lista de procesos dentro de cada grupo descrita en la Guía del PMBOK es muy larga, con mucha información que puede ser interesante aunque debe tomarse con cierta perspectiva. El encargado de la planificación debe tener en cuenta que sobrecargar de burocracia el proyecto puede ser tan negativo como dejar que funcione sin control. Es una fuente de herramientas, pero no es necesario siempre emplearlas todas. También, en el extremo opuesto, algunos proyectos concretos pueden necesitar acciones concretas, a fin de fragmentar el trabajo y la información a tratar.
Todos los grupos están someramente explicados por su nombre y deberían ser fáciles de entender para diseñadores, dedicados a la práctica proyectual. Sin embargo, teniendo en mente la aplicación de estas técnicas al Diseño, puede ser interesante profundizar en la definición de los Procesos de iniciación.
Estos son los que permiten una relectura del proyecto y comprobar si estamos dentro del alcance. En equipos pequeños y compactos, con poca variabilidad en su composición puede ser suficiente con una recapitulación y puesta en común. Sin embargo, si en un cambio de fase tenemos una entrada de nuevo personal será muy importante mostrar cómo se ha llegado a este punto, hacer que los procesos de iniciación sean participativos y el ingeniero eléctrico que ha de dar soporte a los diseñadores llegados a la fase de preproducción comprenda no sólo los resultados si no también el camino transitado. Esto puede evitar trabajar sobre campo ya arado y tropezar varias veces con la misma piedra.
El bonus de hoy no guardaba relación con el texto, pero esta parte es tan árida como necesaria y sonreír un poco con Eugenio no está de más.
Uncategorized | No hay comentarios »