En realidad, y en referencia a la entrada anterior, “gestión por proyecto(s)” no es una terminología que me guste mucho –de hecho, sincerándome más, no me gusta. Suena raro. Nadie va por ahí diciéndote que gestiona por operaciones; gestiona o dirige operaciones y punto.
Sin embargo, en el ámbito de los proyectos se ha tenido que acuñar la atípica expresión para hacer hincapié que se hace referencia a una metodología de gestión específica para la Dirección de Proyectos, y diferente de la que se utiliza en la Dirección de Operaciones –y de la que tradicionalmente se ha ido empleando, y aún se hace hoy de manera muy común, en el contenido semántico tradicional, aunque mayormente aceptado, de “gestión de proyectos”-, e inluso de un estilo de gestión global para una ogranización -lo que se conoce como organización orientada a proyectos.
Llegará un día en que la distinción será innecesaria y “Dirección –o gestión- de Proyectos” tenga un significado propio independiente.
17 julio 2008
16 julio 2008
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.
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.
Extraña petición (una de gestión de expectativas... y de la incertidumbre)
“Lo que necesito es una lista especificando los problemas desconocidos con los que nos encontraremos”.
Jefe anónimo (no necesariamente el mismo que aquí).
Jefe anónimo (no necesariamente el mismo que aquí).
03 julio 2008
7, buen número para una lista de algo
Siete libros que, aunque no lo parezca, pueden ayudar a un Director de Proyecto:
Efecto secundario: su lectura puede expandir la mente.
El error de Descartes, Antonio Damasio.
Mean genes, Terry Burnham & Jay Phelan.
Cómo funciona la mente, Steven Pinker.
La mujer de blanco, Wilkie Collins.
El cisne negro, Nassim Taleb.
Against the gods: the remarkable story of risk, Peter Bernstein.
Los siete mensajeros y otros relatos, Dino Buzzati.
Efecto secundario: su lectura puede expandir la mente.
02 julio 2008
C'est la vie
La mente humana trata una nueva idea de la misma forma que el cuerpo trata una proteína extraña; la rechaza.
Sir Peter Medawar
30 junio 2008
Quiero ser proyectario
Hace un tiempo me contaban que en los EEUU, creo que es, existe una competición –o alguna vez se hizo una competición- que consistía en premiar al equipo que construyera una casa en el menor tiempo –una casa de madera-. Dicha competición se utilizó como ejemplo sobre cómo, con una buena organización, se puede reducir el plazo de un proyecto: el ganador empleó algo más de dos horas –si no recuerdo mal- en construir la casa.Pues bien, permitidme que, desde mi humilde experiencia y opinión, no esté de acuerdo en que a eso se le pueda llamar proyecto, al menos desde el punto de vista de un mariscal de campo y toda su tropa en plena refriega. Veamos:
- En primer lugar, el objetivo no era construir una casa, sino ganar un concurso.
- Todo el equipo estaba aislado y despreocupado de cualquier otro tipo de actividad que no estuviera relacionada con la construcción de la casa –durante dos horas y pico tampoco era muy difícil-.
- Todos y cada uno de los materiales necesarios para la construcción habían sido cuidadosamente seleccionados con antelación –no sabemos cuan dilatada había tenido que ser la antelación ni los problemas sufridos, era irrelevante para el desarrollo del concurso- y estaban disponibles en el lugar y momento de la construcción.
- No había que dedicar tiempo, ni enfrentarse a la humana reticencia, a informar sobre el progreso de las actividades –de hecho hubiera sido ridículo, pero ya nos gustaría que todos los proyectos fueran así, me refiero a que no tengan la necesidad de informar, porque a lo otro…
- El alcance estaba más claro que el agua desde el principio de los tiempos –hecho que, entre otras cosas, podía permitir esa preselección de materiales citada anteriormente-.
Este ambiente parece muy aséptico si lo comparamos con la cruda realidad:
- El equipo, aunque, en el mejor de los casos, tenga una dedicación exclusiva a un proyecto, siempre tiene que dedicar parte de su tiempo a otro tipo de actividades organizacionales no relacionadas con el proyecto. En un caso típico, cohabita en un medio multiproyecto y, pese a los intentos de evangelización, batiéndose en solitario contra sí mismo en una ciénaga de multitarea.
- Todo el equipamiento y materiales necesarios se van adquiriendo a lo largo del proyecto, según una programación previa en el mejor de los casos. No es extraño que el material adecuado no se encuentre disponible en el momento preciso debido a múltiples razones que estoy pensando y que os podéis imaginar. Tampoco es una rareza que ni tan siquiera se hubiera caído en la cuenta de que tal material fuera necesario en un momento dado.
- En proyectos de cierta entidad su seguimiento se hace necesario para asegurar que transcurre dentro de cierto margen razonable –lo que no quita que no se tome realmente en serio-. La comunicación y compartición de información son conceptos muy loables –y necesarios-, aunque la cruda realidad es que siempre nos encontramos con actitudes que conspiran en contra de la obtención en un momento dado de un sistema completo de datos acerca del progreso del proyecto.
- Es difícil disponer de un alcance por el que se han comprometido todas las partes. Pero, incluso antes que eso, raras veces se puede afinar el alcance de un proyecto a la primera, siendo más normal que ese refinamiento se vaya realizado de forma progresiva a lo largo del proyecto –hay que analizar pero no paralizarse por el análisis-.
El concurso es como un experimento controlado que se realiza dentro de una probeta: el efecto de agentes externos, y sus posibles e inciertos efectos, se han reducido de forma considerable. Sin embargo, un proyecto real es un proceso que se realiza al aire libre, a merced de todos los agentes que nos podamos imaginar y los que no. La gestión de riesgos intenta mitigar los posibles efectos adversos de aquellos agentes que podemos imaginar –aunque seguro que no al reducido nivel que se puede conseguir en el aislamiento de la probeta-, y nada hacen sobre los efectos de aquellos que no podemos imaginar por el simple desconocimiento –lo que podemos denominar verdadera incertidumbre. La probeta es un experimento ideal en el cual no se tiene en cuenta este hecho, así como la naturaleza humana. En el mundo real es imposible obviarlos. Y modifican y difuminan la ecuación que no veas.
18 junio 2008
Desarrollo profesional en Dirección de Proyectos
En entradas anteriores de este blog he manifestado mi convicción de que la Dirección de Proyectos es ante todo una profesión, dotada de un cuerpo de conocimiento y un conjunto de buenas prácticas que le confieren una entidad propia bien diferenciada. Y como toda profesión que se precie, los individuos que la practican experimentan un desarrollo profesional y personal mediante su uso diario, siendo la formación y la capacitación unos catalizadores clave de este proceso.Desde hace cinco años en nuestro país, y desde 1981, año en que se fundó en EEUU, ESI International está jugando un papel muy importante en el desarrollo de nuestros jefes de proyecto a través de su Programa de Desarrollo Profesional en Dirección de Proyectos, un programa que cubre de forma extensa todos los conocimientos y competencias necesarios para el desempeño de la profesión. Sus contenidos están basados en los estándares del PMI –ampliamente reconocidos, junto con su sistema de certificaciones, como de facto a nivel internacional- y avalados por el mismo PMI y la Universidad George Washington.
Las temáticas de los cursos abarcan tanto la dimensión de gestión como la interpersonal. En la dimensión de gestión nos encontramos, a su vez, con cursos que tratan el proyecto como una entidad hasta la visión multiproyecto con la gestión de programas y portfolios, y la implantación de oficinas de proyecto. En la dimensión interpersonal se abordan temas de comunicación, pensamiento crítico, liderazgo y negociación, siempre dentro del contexto de la Dirección de Proyectos. Existen tres modalidades en las que tomar parte en uno de los cursos. Dos de ellas son presenciales, bien en las sesiones programadas en Madrid y Barcelona a lo largo del año, o bien contratando una solución In Company en el seno de una organización –que puede formar parte de un programa de desarrollo de la propia organización y que ofrece la ventaja de personalizar los cursos a su propia realidad-. La tercera modalidad es online a través de su solución e-Training.
Una gran variedad entre la que elegir aquellos aspectos en los que se desea profundizar o mejorar, de qué forma y a qué ritmo.
Suscribirse a:
Entradas (Atom)