22 mayo 2007

Cómo acabar de una vez por todas con el Management (1)

Plagi-variaciones sobre un tema de Woody Allen


Primera parte


Estaba sentado en mi despacho jugueteando con las 3.000 páginas del informe con las conclusiones del análisis estratégico que habíamos realizado para una importante multinacional y preguntándome cuál sería mi próximo proyecto. Me gusta ser socio director. Cierto, tiene sus inconvenientes, más de una vez han dicho cosas desagradables de mí en la máquina del café, pero el contorno precioso de los cinco dígitos de mi nómina y la reconfortante satisfacción de estar en la parte superior de una pirámide formada por un gran capital humano, alrededor de unas siete mil cabezas, tiene también sus ventajas. En el momento en que sonó el teléfono a mis espaldas, mis pensamientos se perdían entrelazados en el reflejo gélido de la mañana sobre la bahía del lago Ontario junto a mi mirada que se escapaba a través de la ventana del piso 31 del 79 de Wellington Street West, acompañados de la banda sonora que producía el paso de las hojas del informe entre mis dedos cual cartas danzando en las hábiles manos de un croupier. Un pequeño impulso y una media vuelta de mi silla me hizo alcanzar el teléfono y descolgar el auricular.

Una dulce voz femenina anglosajona, con ese acento norteamericano tan poco considerado al otro lado del océano, aunque sea canadiense, ejecutó una sinfonía en mi auricular. No era yo la única persona consciente de los efectos de su voz. Ella también lo era. Se llamaba Rachel Quest y era la directora de recursos humanos de un importante banco. El liderazgo de su organización había desaparecido y quería que lo encontrara. Le pregunté qué tipo de liderazgo aplicaban: carismático, autocrático, participativo, transaccional…
- Ninguno de ellos –respondió.
- Entonces, ¿qué aspecto tiene? –volví a preguntar intentado que el gradiente de presión de su cántico no me absorbiera a través del auricular.
- Nunca lo hemos visto. Está en todas partes, en el Karma y el Dharma.
- Ya.
Así que la chica resultaba ser seguidora de las teorías de Deepak Chopra. Tomé nota mental del dato y le dije que tendría que pasarme por el banco para recabar más detalles. Su canto de sirena pareció desentonar un poco cuando me replicó que no hacía falta, que podíamos quedar para almorzar y me contaría los detalles. Pero, sin una Circe que me aconsejara, acepté la proposición.

Quince minutos antes del mediodía cogí el ascensor y bajé hasta la calle. Afuera hacía un frío de mil demonios, cero grados Fahrenheit marcaban los dígitos de un letrero luminoso, unos dieciocho bajo cero en unidades patrias para entendernos, aunque el sol lucía deslucido en su cenit como sólo puede hacerlo en Toronto un frío mediodía de finales de enero. Pero, a pesar de ello, preferí recorrer los pocos metros que me separaban de BCE place por la calle, y no por el subsuelo. Así que, envuelto en la bufanda y parapetado dentro del abrigo, comencé a andar hacia el este por Wellington West hasta que llegué enseguida a la altura de Bay, donde torcí a la derecha para darme de bruces con la estructura catedralicia, diseñada por mi tocayo y paisano Calatrava, que aloja la galería Allen Lambert y constituye una de las innumerables entradas al queso de gruyère subterráneo formado por una compleja red de 27 km. de pasillos que unen alrededor de 1200 tiendas, servicios y entretenimiento, y donde los toronteses, nativos o no, consumimos como hormigas gran parte de nuestro tiempo de ocio durante los crudos meses de invierno. Si hubiera continuado por Wellington West, tras cruzar Yonge, como si de Greenwich se tratara, la calle hubiera pasado a llamarse Wellington East.

Una vez dentro de la galería, bajé desabrochándome el abrigo por unas escaleras que me introdujeron en el subsuelo. En la puerta del restaurante japonés se encontraba una rubia esculpida sobre pura geometría riemaniana, capaz de confinar toda la luz que se atreviera a acercar su trayectoria hasta cierta frontera de no retorno. A medida que me acercaba hacia el restaurante, mi mirada intentó, no sin cierta dificultad, comprobar si había alguna otra mujer esperando. Rachel debió intuir mi mirada inquisitiva, porque cuando traspasé la frontera de no retorno, su voz de sirena, pronunciando una o larga casi acabada en u, preguntó:
- ¿Santiago Margaix?
Debería medir un metro setenta y cinco, aunque con la ayuda de unos pequeños tacones. Llevaba un elegante traje de corte perfectamente diseñado para abrazar con delicadeza su geometría. Tenía lo que debía ser una abundante cabellera recogida en un moño. Y olía como una imagen de los jardines de Versalles a la luz de la luna. Decir que era impresionante es no decir nada.
- ¿Y bien? – dije cuando estuvimos sentados en una mesa y me hube recuperado parcialmente de la impresión.
- Tiene que ayudarme Santiago. El año pasado abandonamos la práctica del liderazgo situacional porque comprobamos que en tiempos de fusiones y adquisiciones, el éxito ya no dependía de la situación organizacional y el estilo del líder. Había que adoptar una estrategia más posmoderna para enfrentarnos a los tiempos de cambio, basada en los pensamientos positivos de la mística cuántica y la totalidad del orden implicado. -A lo largo de mi carrera profesional he tenido que soportar mucho humo, e incluso materializarlo, pero a un pibón como el que tenía enfrente había que escucharlo hasta el final.
- ¿Y qué es lo que ha sucedido con ese nuevo estilo de liderazgo? –pregunté como arrastrado hacia una singularidad infinita.
- Pues que un buen día desapareció y nos dejó sin rumbo.
- ¿Desapareció? ¿Así como así? ¿Sin firmar el finiquito?
- Santiago; tiene que encontrarlo –su rostro se tornó frágil y desamparado cuando pronunció estas palabras.
- Me temo, señorita Quest, que como no aporte más información…
- Por favor, llámeme Rachel –interrumpió ella.
- Rachel, tiene que ofrecerme alguna pista, algo por donde empezar a buscar –dije buscando el lado más favorable del sushi para atacarle con los palillos.
Tras unos instantes de reconsideración, repuso:
- Quantum Consulting, una firma compuesta por gente de Harvard, fue quien nos hizo la gestión del cambio –el sushi se quedó suspendido en el aire sujeto de forma metaestable entre mis palillos. Así que los tipos listos de Harvard andaban metidos en el ajo. Sentía que el asunto no presentaba un buen cariz, que podía ser realmente complicado, pero la desolación y la melancolía de las últimas palabras de Rachel me enternecieron, y decidí que aceptaría el reto. Con el postre y mi aceptación pareció recobrar su temple inicial. Quedamos para la tarde del día siguiente y abandonamos el restaurante.

Rachel se alejó por uno de los pasillos del gruyère, marcando una danza especialmente coreografiada para ella. Yo, antes de regresar a la oficina, hice una escala en el Starbucks para enchufarme un vaso de medio litro de regular y reflexionar sobre lo que tenía por delante. Cuando finalmente salí a la calle hacía menos frío, unos cinco bajo cero, y el cielo había tomado el color del acero pesado. No tardaría en ponerse a nevar. No estaba seguro de si el liderazgo del que me había hablado Rachel existía de verdad o no. De lo que sí estaba seguro es de que ahí afuera me iba a encontrar con un montón de consultores que iban a tratar de impedirme averiguarlo.

Continúa leyendo la segunda parte de esta historia

20 mayo 2007

Yogi Berra y el alcance de un proyecto

Yogi Berra es una de las leyendas vivas del béisbol americano, que participó en el desembarco de Normandía durante la segunda guerra mundial, y famoso también por sus peculiares y divertidos aforismos, repletos de tautologías y oximorones, conocidos como yogiismos; por cierto, nuestros periodistas deportivos no se quedan cortos en dicha práctica: esto no acaba hasta que se cruza la línea de meta, el fútbol es así, etc. Se cuenta que Yogi Berra pidió una vez una pizza y el camarero le preguntó en cuántas porciones quería que se la partiera, a lo que Yogi contestó que en cuatro porque no estaba lo suficientemente hambriento como para comerse ocho. Gracioso, ¿no? Cambiemos ahora el contexto. Como jefe de proyecto le entregan a Yogi un cronograma de proyecto compuesto por una red de 200 actividades, plan que rechaza porque dice que no puede dimensionar de forma precisa más de 90, ni mucho menos gestionarlas de forma eficiente. A ver quien se ríe ahora.

A veces, cuando nos ponemos a detallar actividades, y nos emocionamos con eso del detalle y del divide y vencerás, parecemos tontos con una tiza –escribas ante un teclado y un archivo en blanco de MS Project recién abierto esperando con ansia ser colmado de tareas, en versión era del conocimiento. Y el exceso de detalle nos hace marcar un gol en propia puerta; porque no tenemos en cuenta hechos como los siguientes:

  • La incertidumbre global del proyecto absorberá todo el nivel de detalle que esté por debajo del nivel de ruido: sería como intentar hacerse oír dentro de una sala donde todo el mundo está gritando.

  • Un exceso de detalle incrementa el trabajo para crear y mantener el plan de proyecto: al final es más la salsa que los caracoles –o, puestos a comer pizza, comerse una pizza Hut con masa pan pizza.

  • Un mayor nivel de detalle incrementa la probabilidad de cometer errores en el plan: tendríamos un mayor número de estimaciones que exigirían un mayor nivel de precisión, además de un mayor número de interrelaciones entre actividades.

  • Existen proyectos en los que no todo el alcance se puede desmenuzar desde el principio y hay que hacerlo de forma progresiva a medida que el proyecto avanza: partir la pizza en 8 trozos, comerse 4 y guardar el resto en la nevera para calentarlo en el microondas al día siguiente.

Quizás Yogi Berra también podría haber triunfado como jefe de proyecto. De hecho, después de hacerlo como jugador, lo hizo como entrenador. Y para finalizar, otro yogiismo inspirador para la gestión de riesgos: “si te encuentras un tenedor por el camino, cógelo”.

06 mayo 2007

Por qué cuesta tanto planificar

“La vida se debe vivir hacia delante
aunque se entiende hacia detrás.”
Soren Kierkegaard.

No hay nada como ver las cosas en retrospectiva. Cuando todo ha finalizado y el humo de la batalla se ha disipado, dejando a la vista sus restos reposando junto al curso que han seguido los acontecimientos, todo cobra sentido repentinamente, incluso para aquellos que se mantuvieron agazapados a lo largo del proyecto eludiendo cualquier responsabilidad ante el cariz que suele tomar la coyuntura a poco que la cosa se ha puesto en marcha. Suele ser así. Es ley de vida. Y de naturaleza humana. El fin de un proyecto es el típico momento en el que uno puede encontrar, sin buscarlos, plétoras de expertos en gestión de proyectos, con un buen surtido de explicaciones de los errores, identificación de los culpables y con las decisiones que deberían haberse tomado; ahora que ya son obvias. ¡Quién los hubiera tenido en el momento en que se estaba planificando!, teniendo en cuenta que dicho momento haya existido alguna vez.

La gente se resiste a planificar por diversas y variopintas razones, pero quizás una que subyace en el fondo de todas ellas es la pereza de esforzarse en intentar predecir el futuro, Deming ya dijo que “gestión es predicción”. Una excusa muy común es que no se puede planificar lo incierto. Creo que detrás de esta afirmación reside una confusión semántica, ¿qué es planificar si no? La certidumbre, la evidencia de los hechos pasados, no se planifica; se documenta, y para eso ya están los historiadores, no los jefes de proyecto. Aunque no conozcamos el camino de antemano, debemos trazarlo. Pero aún podemos aprovechar el efecto de la retrospectiva: una vez visualizados los objetivos del proyecto, en vez de andar a tientas hacia ellos podemos intentar construir el camino inverso hacia el punto de partida. ¿Qué deberíamos haber hecho, y cómo, para obtener este resultado? Y así de forma sucesiva hacia atrás. No deja de ser una forma de intentar predecir resultados inciertos, pero quizás alivia ese estrés, o nos disuade de escondernos ante la toma de decisiones, que se genera ante la incertidumbre. Inventa un futuro e intenta reconstruir y entender el pasado que lo originó pudo haberlo originado.

25 abril 2007

Los chicos de la radio

A lo largo de una primavera de hace 20 años, mientras la naturaleza se desperezaba después de un nuevo despertar del letargo invernal, unos chavales de entre 16 y 18 primaveras lograron la culminación de una visión que habían compartido durante el último año. Muchos de ellos lograríamos a su vez otra culminación; la de entrar en ese intervalo indefinido de tiempo que hace de frontera entre la turbulenta primavera de nuestra vidas y su largo y cálido verano. Por lo que respecta a la primera culminación, la cual debió influir mucho en la segunda, aquel mayo de 1987 salía por primera vez al aire de nuestro pueblo, modulado en las ondas electromagnéticas generadas por nuestra emisora de radio, todo aquello que habíamos visionado durante el tiempo que la idea estuvo en proyecto. El propio proyecto tuvo su fase de selección -viabilidades técnica y económica incluidas-, pues en el invierno de 1986 ya competían dos alternativas en las conversaciones de tardes lluviosas de sábado. Dichas alternativas consistían en la creación de una emisora de radio o la construcción de un kart. La primera fue finalmente elegida; quien sabe si de haber sido elegida la segunda Alonso no hubiera sido el primero, y en vez de habernos sonado el nombre de Schumacher lo hubiera hecho el de un tal Quique.

El de aquél año fue también el curso en el que Yolanda dejó el instituto, dejando tras de sí una ausencia desconocida hasta entonces. Y su nombre escrito entre las páginas de mi libro de física y química del curso anterior, cuando ni tan siquiera sabíamos que el amor era precisamente física y química. U2 acababa de lanzar su gran álbum “The Joshua Tree”; fallecía Rita Hayworth, cuyo póster ayudaba a fugarse de una prisión al personaje de un relato de Stephen King de aquella década. Y el curso de aquél año debió incorporarse a nuestro instituto de bachillerato una chica con la que debí coincidir varias veces en el autobús escolar y que, años más tarde, un antiguo compañero me tuvo que decir que era Nuria Roca –si yo fuera un personaje público, y tuviera una entrada en la Wikipedia, también sería fácil acordarse de mí. Los días de aquella primavera discurrían de forma pausada entre sentimientos de pérdida y de expectación por lo que iba a sobrevenir. El aroma a azahar proveniente de los campos de naranjos floridos que rodeaban el instituto se apoderaba del ambiente, y unos pocos kilómetros más hacia el noroeste, a los pies de una pequeña sierra que viene a morir en el mar, quizás con el ánimo de perpetuar su existencia hinchiendo con su mirada la profundidad de su horizonte, se ultimaban los preparativos durante fines de semana que se hacían cortos. Y finalmente logramos nuestra culminación.


La emisora de radio fue el entretenimiento del verano. Después llegarían las tormentas anunciando el próximo cambio de estación, y finalmente el cielo se tornó limpio y muy azul como solía ser el cielo de otoño. Y con los cambios la actividad operacional de nuestra emisora devino en una discontinuidad de desapariciones y resurgimientos continuos. Pero nunca fue ya como aquel verano primordial. Para financiar y mantener la actividad tuvimos que idear pequeños negocios temporales que ahora, curiosamente, sólo se les enseña a los adolescentes en simuladores informáticos. Tuvimos discusiones acaloradas, sufrimos la necesidad de limitar nuestras visiones para poder llegar a acuerdos y tomar decisiones de continuidad. El mundo parecía no tener límites. Nos sentíamos orgullosos por lo que estábamos haciendo y nos sentíamos importantes. Realizábamos programaciones que luego no se cumplían; pasábamos las tardes de sofocante calor dentro de la pecera, poniendo música y hablando de cosas que se nos antojaban importantes; noches cálidas en las que andábamos dos kilómetros para subir a la colina en la que se situaba el Zenital, terraza y discoteca con una vista impresionante de la ciudad de Valencia y su área metropolitana iluminada y recortando el oscuro mediterráneo en el fondo, una vista que para nosotros nada tenía que envidiar a la del Mulholand Drive que veíamos en la teleserie Colombo.

Quizás las de aquel verano sean las últimas imágenes inocentes que reposen dispersas y calidoscópicas entre los poros de mi memoria sobre el lugar en el que crecí, las que forjaron la baseline del proyecto de una vida, esa vara que constituye la medida de todas las cosas. Luego vinieron otros lugares, otras personas y otras experiencias. Aprendí a amar otros lugares, otras personas y otras culturas, y esa vara de medir se tuvo que adaptar a esos nuevos entornos. Veinte años después los cambios en aquellos paisajes de la adolescencia se aperciben. Pero a veces uno cree que puede entrever esa baseline primigenia, cuando entre la bruma y la resaca de una tarde de primavera, a orillas de ese mediterráneo viejo y sabio, uno casi recuerda aquellos momentos iniciáticos de su vida y a las personas con quienes los compartió.

23 abril 2007

Cómo calcular la Programación Ganada con Microsoft Project


Novedades 16/01/14: Una nueva versión que funciona con Microsoft Project Professional 2013 ya se puede descargar desde aquí.

Novedades 11/03/11: La versión MSP 2007 de la nota anterior también funciona con MSP 2010.

Novedades 27/02/09: Una nueva versión que funciona con MSP 2007 ya se puede descargar desde aquí.

Novedades 14/06/07: la primera versión se ha sustituido por una nueva en la que se ha corregido un error de cálculo.

La técnica de la Programación Ganada (ES de su acrónimo en inglés) es una extensión del Análisis del Valor Ganado (AVG) que ha sido reconocida recientemente como una práctica emergente por el Project Management Institute (PMI). Este enfoque novedoso se basa en el potente concepto de Programación Ganada (PG) introducido por Walt Lipke en su artículo pionero “Schedule is Different”. La razón que dio lugar a esta extensión fue el hecho bien conocido de que, en algunos escenarios concretos, algunos indicadores del AVG, como la desviación en programación SV y el índice de eficiencia en coste SPI, se comportan de forma inesperada a partir de cierto momento hacia el final de un proyecto, perdiendo todo su poder predictivo. Para conocer más sobre esta técnica ver la documentación de dominio público que se encuentra en Earned Schedule. Dado que es una práctica muy reciente, hasta donde sé los principales paquetes de software sobre programación de proyectos aún no la incorporan. El propio Lipke ha puesto a disposición una hoja de cálculo para automatizar el cálculo de la PG partiendo del coste planificado BCWS y del valor ganado BCWP.

Quiero mostrar aquí una macro realizada en VBA para MS Project (MSP) que prepara informes mensuales en Excel de los indicadores del AVG y de la PG con el propósito de que pueda ser útil para proyectos de pequeña y mediana entidad cuya programación se lleva con MSP. Y solamente su programación, es decir que el coste se lleva a parte –práctica nada extraña por otro lado. El tipo de proyecto para el que se utiliza la macro es aquél compuesto por actividades desempeñadas por recursos del tipo de mano de obra, en la que su duración se puede condicionar a su esfuerzo. De esta forma, tanto el coste como su duración son proporcionales al esfuerzo, horas-hombre por ejemplo. De esta manera, con seguir las horas es suficiente. Por mi experiencia, la tipología propia de estos proyectos unida a la inmadurez relativa de las organizaciones que suelen desempeñarlos hacen que efectuar un seguimiento del coste, además de la programación, sea con bastante frecuencia una empresa infructuosa. Otro inconveniente de MSP es que posee una implementación del AVG muy pobre, ya que no permite llevar un seguimiento histórico de las curvas S para los costes BCWS, BCWP, ACWP y sus magnitudes derivadas, y por tanto tampoco permite mostrar una representación gráfica de las mismas. Por otro lado, como adelantaba al principio, no incorpora la PG.

En el siguiente archivo de MSP, versión 2003, se puede encontrar un ejemplo del funcionamiento de la macro. Si el fichero se va a abrir con una versión diferente saldrá un mensaje de error y habrá que seleccionar las librerías adecuadas desde el menú del editor de Visual Basic de MSP: Herramientas-->Preferencias. Estas librerías son "Microsoft Project xx.x Object Library" and "Microsoft Excel xx.x Object Library", donde xx.x es la versión correspondiente a la versión de MSP -11.0 para MSP 2003. No olvidar tampoco comprobar el nivel de seguridad de macros de manera que permita su ejecución. Una vez abierto el archivo, aparecerá un nuevo menú llamado “Reports” en la barra de menús. Pinchando sobre el mismo se obtiene el informe en Excel del proyecto. El archivo contiene un ejemplo de proyecto con una duración de 18 meses que se ha actualizado de forma mensual seis veces desde su inicio. Para que el informe se pueda generar, debe haberse guardado una línea base con la planificación inicial del proyecto, y asignar una fecha de estado adecuada. Cada vez que se genera un informe mensual, el archivo va guardando estos datos de forma que va creando un histórico mensual de los indicadores que aparece actualizado cada vez que se genera el informe en Excel, pudiendo así descartar los informes generados con anterioridad. De esta manera, el informe muestra de forma gráfica la evolución de las curvas S y el resto de indicadores. Las magnitudes de tipo coste están medidas en horas-hombre y las de tiempo en semanas o días.

11 abril 2007

Performing Earned Schedule Analysis with Microsoft Project


News Jan16, 14: A new file that works under Microsoft Project Professional 2013 is now available.

News Mar11, 11: The MSP 2007 version file of the former note also works with MSP 2010 version.

News Feb27, 09: A new file that works under MSP 2007 is now available.

News Jun14, 07: MSP file replaced by a new one with a bug fixed.

The Earned Schedule (ES) Technique is an extension of the Earned Value Management (EVM) technique that has recently been recognized by the Project Management Institute (PMI) as an emerging practice. This new approach lies on the powerful concept of Earned Schedule, which was first introduced by Walt Lipke in his seminal paper “Schedule is Different”. The reason that motivated this extension was the well-known feature that there are several project scenarios where some EVM schedule indicators such as SV and SPI show an unexpected behavior at certain state of the project turning out useless to make predictions. You can go into this technique by visiting the Earned Schedule website and reading the public domain documentation you will find there. Because it is a very recent practice, major scheduling software packages do not incorporate it as far as I know. In order to perform automated calculations of ES magnitudes you can use Lipke’s ES Calculator, an Excel Workbook that works out these magnitudes from the corresponding BCWS and BCWP project costs.

With the aim to make use of ES in some kind of medium and small projects usually scheduled, and only scheduled with Microsoft Project (MSP) –I mean by this that cost constraint is not managed with it; I have developed a VBA macro that arranges monthly reports of both EVM and ES indicators. This macro has been written thinking of projects which activities are mainly performed by labor resources so you can set up them as effort-driven activities. In such a way, activity costs are proportional to the activity effort, labor-hours for instance, as well as it is its duration. Then you do not need to track costs but just work. In my experience with this kind of projects and the relative immaturity of organizations that normally perform them, trying to track projects with MSP within both time and cost constraints becomes quite often unsuccessful. Another drawback of MSP is that there is no way to keep record on the same file of the EVM indicators of former reports; you are not able to plot S curves too. Finally, ES technique is not yet implemented.

You can see how it works on this sample MSP file. This file has been created with a MSP 2003 version, so if you are to open it with a different version you have to select the right versions for the following libraries "Microsoft Project xx.x Object Library" and "Microsoft Excel xx.x Object Library", where xx.x is the library version for the corresponding MSP version -for instance 11.0 for MSP 2003. You can find these libraries on the Visual Basic editor by clicking on the menu: Tools-->References. Also, in order to get the file open you must check your macro’s security level in order it allows running not signed macros. Once the file is open, a new menu called “Reports” appears on the menu bar; click on it to run the macro and get an Excel report. The project you see is an 18-month one that has been rescheduled monthly six times since its beginning. If you want the macro to run properly you must record a baseline when the project plan is done, and assign an appropriate status date each time you perform the project update. Every time you run the macro in a monthly basis, the MSP file records at the same time the values of EVM and ES indicators of the corresponding period. So you can see the values for the period preceded by the values corresponding to previous periods (months); then you do not need to get a different Excel file for every period. This feature allows plotting the S curves and indicator evolutions. The cost magnitudes are measured in labor-hour units, and the time magnitudes in either month or day units.

04 abril 2007

Dirección de proyectos: ¿profesión o pasatiempo?

Uno de los escollos más importantes con que nos encontramos a la hora de institucionalizar en una organización un conjunto de hábitos o buenas prácticas para la gestión de proyectos es, precisamente, el poco reconocimiento, por no decir nulo, que puede llegar a tener esta labor. Como ya decía en una entrada anterior, la gestión de un proyecto, y todo lo que ello conlleva, es algo que está en un segundo plano; o tercero, o cuarto, o enésimo. Así como a nadie se le ocurriría encargar la construcción de una central nuclear – por citar un ejemplo políticamente no correcto en estos tiempos de desaforada y burbujeante sensibilización por el medio ambiente- a nadie que no tuviera ni idea sobre energía e ingeniería nuclear, abundan, por el contrario, los ejemplos de poner al cargo de un proyecto complejo, que no complicado, ojo que no es lo mismo, a alguien sin conocimientos sobre organización, técnicas y herramientas de gestión de proyectos. No es por nada. Simplemente casi nadie admitiría que organizar y gestionar un proyecto sea una competencia digna de ser tenida en consideración; con poseer el conocimiento técnico es suficiente. El resto voluntad.

Así, una situación típica con la que uno se encuentra en una no menos típica reunión de seguimiento de un proyecto, en los casos esperanzadores en que tales reuniones existen, es la de perder el tiempo discutiendo el intrincado problema técnico que está impidiendo que cierta tarea se esté resistiendo. Nada de si esa tarea va con retraso o no –en muchos casos ni tan siquiera se ha estimado una duración en que debería ser realizada, o simplemente no se ha comunicado-; si su retraso afecta al proyecto; si se está invirtiendo más esfuerzo en ella del necesario; en qué situación se encuentran el resto de actividades en curso; cuál es el estado global del proyecto –en realidad en muchos proyectos ni tan siquiera hay una percepción del proyecto como una entidad única-; en definitiva, no se habla de nada de eso porque simple y llanamente no es de relevancia comparado con la dimensión técnica del proyecto. No existe la sensación de que se está perdiendo el tiempo porque, en realidad, se está invirtiendo en lo que realmente se considera que es importante en un proyecto. Esa desorganización invisible puede que tenga consecuencias negativas sobre el proyecto. Pero, al final, con algún que otro puñetazo en la mesa y, eso sí, con voluntad se acaban terminando las cosas.

De la misma manera, a la hora de buscar ineficiencias de costes, buscamos antes entre el entramado tecnológico del producto: coste de materiales, modificar el proceso de elaboración, incluso coste de mano de obra, que en el propio sistema de gestión y organización del proyecto. Así pues, como seguía diciendo en aquella entrada, no es de extrañar que a muchos profesionales del ámbito de los proyectos los temas de los que habla el PMBOK, por citar un ejemplo, les resulten alejados de lo que es su práctica diaria. Hace alrededor de un año, cuando difundí entre mis amigos la URL de mi blog para que hicieran publicidad del mismo, me encontré con una de ellos que había alucinado sobremanera con sus contenidos. “¿Qué cosas más raras son esas que escribes en el blog?”, me decía; “¿y qué tiene eso que ver con la gestión de proyectos?”. De hecho lo comentó con unos jefes de proyecto de TI de cierta administración pública que, según decía, tenían una gran experiencia, y que constataron su asombro y le aseguraron que eso no tenía nada que ver con la gestión de proyectos (¿!). Lo dicho, la gestión de proyectos es de Júpiter y muchos jefes de proyecto de Neptuno, el portador de la voluntad.

Esta tendencia parece que ha tendido a invertirse tímidamente durante el último lustro con la aparición de cursos de postgrado, masters y mucha formación in company en materia de dirección de proyectos, contribuyendo al reconocimiento de la disciplina como una competencia profesional digna de ser tenida en cuenta. Otra cosa es que nuestras organizaciones estén preparadas para asimilar una terminología, una serie de técnicas y herramientas, que precisan del respaldo de una forma muy concreta de organización, la de gestión por proyecto, que no coincide con la tradicional. He asistido a muchos casos en los que una organización ha intentado capacitar a sus profesionales en el oficio de director de proyecto para que luego no hayan podido utilizar esos conocimientos en la práctica diaria, simplemente porque el proceder diario de la organización no permite dichos usos. Por eso me preocupa que estos tímidos intentos acaben por quedarse en una moda pasajera. Para evitarlo debemos ser conscientes de que la dirección de proyectos, y su cuerpo de conocimiento, no es un pasatiempo sino una verdadera profesión. Ser voluntarioso, siempre que no sea en la dirección equivocada, puede ser una buena virtud; pero ser un profesional…, bueno la palabra profesional lo dice todo.