Project Management Toy Models

En el principio fue el proyecto. Y luego vinieron las operaciones.

Desde un punto de vista operativo –signifíquese como sinónimo de acción, y no de operacional o relativo a la Dirección de Operaciones-, es un hecho que la primera actividad de envergadura que emprendió la humanidad fue un proyecto –al menos por aquello de realizar algo que no se había acometido antes-. Luego, bastante más tarde, llegó la producción en serie y las tareas repetitivas. Es decir, las operaciones. Esta nueva actividad cobrará su máxima dimensión con la Revolución Industrial y, sobretodo, con el advenimiento de la sociedad de consumo –un consumo masivo que justifica la producción en serie y continuada.

Sin embargo, desde un punto de vista directivo –managerial, cuánto echo de menos un adjetivo en castellano para gestión-, la realidad es que en un principio fueron las operaciones y luego vino el proyecto. Y si no, hablad con un consultor en Dirección de Proyectos, si es que esa cosa existe o está reconocida… Con un jefe de proyecto en activo, permitidme la duda, la conversación ya no sería tan clara, pues aunque sí podríamos llegar a una distinción operativa –en la acción- entre proyecto y operaciones, quizás legáramos tarde o temprano a descubrir que lo dirige, más o menos, matiz aquí o allá, como si estuviera dirigiendo operaciones. Volviendo a la línea inicial de este párrafo, la primera racionalización directiva de un proceso de negocio que se efectuó en la historia tuvo lugar en el mundo de las operaciones, bien porque éstas devinieron en negocios prósperos, bien porque son más sencillas de racionalizar que un proyecto, o bien por cualquier combinación de las dos junto con otros factores. El hecho es que el primer enfoque racional, sistémico y sistemático en la gestión y la dirección nace a finales del siglo XIX con el trabajo de Frederick W. Taylor, “Los principios de la gestión científica” –lo de “científica” quizás queda algo rimbombante, pero es muy representativo de la época, tan decimonónica-. Y se aplicó a la producción en masa, a las operaciones.

Y nos vamos ya a los años 50 y 60 del pasado siglo para encontrarnos con las primeras técnicas pensadas especialmente para los proyectos, como el CPM, el PERT y el AVG. Para el modelado de una filosofía de gestión y el desarrollo de una metodología y forma de organización propia, incluso más tarde. Y para que sea una moda, menos de 20 años ha. Pero para entonces, la Dirección de Operaciones ya era una disciplina muy poderosa, ampliamente aceptada y profundamente asentada en las organizaciones. De hecho, no es extraño encontrar aún la gestión de proyectos como un área de la Dirección de Operaciones –como muestra, el enlace anterior al que lleva PERT-. Todo esto creo que hace que, aunque hoy en día se habla mucho de proyectos, lo que uno encuentra por detrás, a poco que rasque, es una filosofía de operaciones –de hecho, creo que una de las razones principales del fracaso en proyectos se debe a ello: la aplicación de unas técnicas y herramientas, y una filosofía, fuera de su contexto y en otro diferente en el que su validez es poco menos que dudosa-.

Vamos a ver algunas de las diferencias cruciales mediante unos ejemplos de juguete, cortesía de LEGO. En primer lugar, veamos el siguiente video:



Una línea de ensamblado de cochecitos hechos con piezas de LEGO, hecha también con piezas de LEGO. Pero lo que nos interesa es la propia línea de ensamble como todo un arquetipo de lo que representan las operaciones. Sirve para producir de forma masiva un producto. Posee una forma de programar el trabajo y acopiar materiales muy específicos que nada tiene que ver con la forma en que se hace en un proyecto. Se realizan tareas repetitivas y continuadas, mientras que en un proyecto son únicas y discontinuas. El objetivo de la línea es mantener un negocio, el del trueque de cochecitos LEGO con otros niños a cambio de piruletas, digamos, mientras que el de un proyecto es el de alcanzar los suyos propios y finalizar –el propio diseño y construcción de la línea de ensamble sí es un proyecto, que finaliza cuando está lista para entrar en producción-. En cambio, cuando las operaciones alcanzan sus objetivos –venta de tantas unidades de cierto modelo-, adquieren unos nuevos –producción de tantas otras unidades de otro modelo-. Para ello, la organización ejecutará un proyecto consistente en la modificación de la línea para las nuevas necesidades o su sustitución por otra nueva.

La organización de los recursos humanos también será diferente, pues su uso en el trabajo en la línea de ensamble puede ser más continuado que en el trabajo en tareas discontinuas en uno o varios proyectos; los problemas de asignación son diferentes. El acopio de materiales también es diferente: en la planta necesito muchas unidades de un mismo tipo de material, que puedo organizar en estocajes e inventarios de los que se alimenta la línea sin importar el orden de recepción, pues las unidades son indistintas. En cambio, en un proyecto no es habitual disponer de más de una unidad de cierto tipo de material, y aunque se necesite de más de una son pocas y no muchas como en el caso de la línea de ensamble, y aunque haya mas dos o más unidades iguales no se pueden organizar como un estocaje pues no son requeridas de forma continuada sino discontinua en diferentes y separados instantes de tiempo. Es decir, aunque haya unidades iguales de material, en la práctica son distinguibles. En realidad, el concepto de inventario, crucial en las operaciones, no tiene sentido en un proyecto.

La calidad, al menos cuantitativamente, es un concepto estadístico de gran utilidad natural en las operaciones: producir un gran número de unidades permite definir estándares de calidad como valores medios. Un proyecto tiene como resultado un producto único –hoy en día también servicios, por lo que siempre que nos refiramos a producto debemos considerar también servicio-, por lo que no tiene sentido hablar en términos estadísticos. Se puede, y se debe, gestionar la calidad, pero desde luego no extrapolando las técnicas utilizadas en operaciones.

Creo que todas estas diferencias son bastante evidentes. A pesar de ello, no es extraño encontrar una organización que fabrica, digamos, líneas de ensamble como la del video –pero para coches de verdad- y que está organizada como si fuera a producir en masa un gran número de ellas exactamente iguales, como si fueran un mismo modelo de coche. Las operaciones pesan mucho –de hecho, el equipo gestor tendrá una formación en Dirección de Operaciones- y la inercia es inexorable. Sin embargo, así como un fabricante de coches está orientado a operaciones, un fabricante de líneas de ensamble, todas ellas variopintas, debería estar orientado a proyectos. Poco a poco.

Veamos un último ejemplo. El de la siguiente imagen:


Imágenes de este tipo aún se utilizan para ilustrar el WBS (Desglose Estructurado del Trabajo) de un proyecto. Desafortunadamente, el trabajo no se ve por ningún lado en la imagen: sólo una relación de piezas de algo. Bueno, de lo siguiente:


En realidad, la primera imagen es un ejemplo de BOM (Bill of Materials), un concepto proveniente de las operaciones que suele deslizarse en el mundo de los proyectos y rebautizado como WBS. En el video anterior, el BOM sería la lista de todas las piezas necesarias para que la línea ensamble el producto final. Luego, mediante un MRP, otro concepto proveniente de las operaciones, se calculan las necesidades de acopio de materiales y estocaje de inventario según la programación de la línea de ensamble. Por tanto, teniendo en cuenta lo discutido cuatro párrafos antes, habría que reflexionar acerca de si un MRP es realmente una buena forma de planificar la producción de líneas de ensamble.

El WBS es más que un BOM. Es el resultado del último proceso a realizar durante la planificación del alcance de un proyecto, en el que se ha detallado todo el trabajo que se ha de realizar, y solamente el que se ha de realizar, para la creación de los resultados del proyecto. El PMBOK sugiere una clasificación intermedia entre “Alcance Producto”, que define como “las características y funciones que caracterizan a un producto, servicio o resultado” –el equivalente al BOM de las operaciones-, y “Alcance Proyecto”, que define como el “trabajo que debe realizarse para entregar un producto, servicio o resultado con las funciones y características especificadas” –que se manifiesta de forma explícita con el WBS-. Para el producto de las imágenes anteriores, el WBS podría contener ítems como los siguientes: comprar pieza 6, pintar de rojo pieza 8, unir lateralmente las piezas 6 y 11, celebrar reunión de seguimiento, documentar la fase 2 del proyecto, reunirse con el cliente, preparar informe de progreso, etc.

Moraleja: no es lo mismo gestionar un proyecto que gestionar por proyecto. Lo primero ya lo hace casi todo el mundo como buenamente puede. Lo segundo... estamos en ello.