24 julio 2008

Gestión del miedo

Parece ser que una vez le preguntaron a Einstein cómo trabajaba. Sin ningún tipo de complejo respondió que “a tientas”. En verdad, algo muy propio de la investigación científica que se realiza en la misma frontera del conocimiento. No voy a decir que en un proyecto se trabaje completamente a tientas –desde luego sería un enfoque nefasto durante sus fases de ejecución-, pero existen dos estadios –durante su gestación y su planificación- en los que sí se trabaja en la penumbra y, en algunas regiones, incluso a tientas. La penumbra podría traducirse en una gestión de riesgos y andar a tientas en incertidumbre propiamente dicha –riesgo no es incertidumbre, vaya.

Pero no es de esto de lo que quería hablar, sino de la inocencia de la respuesta de Einstein. En el mundo particular de los proyectos, y empresarial en general e incluso académico, es difícil encontrarse con alguien respondiendo “no lo sé”, “no lo entiendo” o “no estoy seguro”, entre otras respuestas similares. Considero que hacen falta unas altas dosis de autoconfianza, integridad intelectual y experiencia en tener una idea general sobre de qué va este mundo –aunque, ojo, no cómo van los fenómenos concretos de este mundo; son cosas diferentes-, para manejarse con franqueza con estas respuestas. Y eso, a pesar que, de hecho, es imposible ser tan categórico cuando navegamos en contextos interdisciplinares, en condiciones de penumbra y, a veces, incluso a tientas. No hay nada malo ni deshonroso en reconocer lo obvio. Pero mira que cuesta –incluso llegando a aprender por experiencias dolorosas las situaciones complicadas en las que nos metemos por no hacer uno de esos sanos reconocimientos a tiempo. Creo que debido a las consideraciones que hacía anteriormente y a la dificultad de gestionar los miedos propios.

Sí que es verdad que, en bastantes casos, la alta dirección fomenta dichos comportamientos por no saber interpretarlos de forma adecuada –el que se mueve no sale en la foto- y, lo que es más grave, castigándolos. Pero hay que reconocerlo de forma clara: una clave fundamental en los proyectos es la incertidumbre, y gestionar la incertidumbre no tiene nada que ver con los riesgos (falta parcial de certidumbre, penumbra), ni mucho menos con la certidumbre (lo que sabemos con certeza). Gestionar la incertidumbre es lidiar con lo que no se sabe, ir a tientas. Y para ello, mejor nos irá si, para comenzar, dejamos los miedos atrás y reconocemos nuestra ignorancia.

18 julio 2008

Reflexión

No sólo de voluntad vive el hombre. A veces necesita dar en el clavo.

17 julio 2008

Gestión por proyecto

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.

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.

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í).

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:

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.




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