El extraño caso del PM por minutos

Gantt comprimido

El amigo de un amigo me ha explicado un divertido caso (o no, según se mire) y que comparto a continuación.

Resulta que un proyecto de implantación de un ERP que tiene que arrancar, sí o sí, a principios del año que viene, ve retrasado su inicio por causas diversas, por lo que una planificación que inicialmente eran unos razonables ocho meses se tiene que comprimir a menos de cinco.

Para ello se ha realizado ajustes: a la baja en el alcance (menos países, algún proceso se deja para más adelante, etc.) y al alza en la intensidad del proyecto (más dedicación del equipo en menos tiempo). Bueno, no de todo el equipo, porque resulta que el cliente quiere recortar proporcionalmente la dedicación del Project Manager, con lo que que ésta queda en un día por semana.

Y es un error, un grave error, por varios motivos:

  • Con una dedicación de menos de un día por semana, mientras llegas y te explican lo que ha pasado durante la semana, sólo te queda tiempo para despedirte hasta la semana que viene, por lo que al final el PM se convierte en un lastre. Pierde totalmente su sentido.
  • En un proyecto con tanta intensidad, la velocidad tan alta a la que pasan las cosas (y cosas en estos proyectos pasan, creedme) requiere respuestas muy rápidas, sin capas intermedias, entre lo que pasa y el PM.
  • El PM pasa gradualmente a intervenir reactivamente, más como apagafuegos, que gestionando el proyecto. El proyecto siempre irá por delante.
  • Desde el punto de vista del PM es también muy ineficiente porque acaba fragmentando su dedicación durante la semana – por goteo y si está en más proyectos acaba en una multitarea excesiva.

Por eso le he dicho a mi amigo que a su vez le transmita a su amigo de que debe convencer a su cliente de que, en realidad, cuando aumenta la intensidad de un proyecto, aunque se acorte su calendario, lo que se requiere es aún más dedicación del PM.

De medir Proyectos (II)

En una entrada anterior introducía el tema de cómo el hecho de cómo medir un proyecto puede distorsionarlo y ser incluso de un coste comparable al mismo proyecto.

Como medir los proyectos es algo necesario (¿seguro?), en esta entrada pretendo aportar mi pequeño granito de arena a la discusión de cómo evitar esos males antes mencionados, para que la ingrata tarea de medir realmente aporte valor al proyecto.

Para ello me basaré en un puñado de principios básicos que creo que hay que tener siempre en cuenta: Continuar leyendo

De medir proyectos (I)

Principio de Indeterminación de HeisenbergEs la ecuación que enuncia matemáticamente y de forma elegantísima por sencilla (al menos para mí) el Principio de Incertidumbre de Heisenberg.

En lenguaje llano viene a decir que no es posible medir de forma exacta y a la vez la velocidad (1) a la que se mueve un objeto y su posición – que siempre hay un margen de imprecisión en la medida de alguna o ambas de las magnitudes, y que el producto de esas imprecisiones es una constante, concretamente la de Planck dividida por dos.

Este principio básico de la física cuántica es frecuentemente interpretado en el sentido de que cualquier cualquier acción de medir altera de alguna forma al objeto medido y falsea, por tanto y aquí está el quid de la cuestión, el resultado de la propia medida. Es curioso porque a una conclusión similar se llega en otros ámbitos tan distintos (o no) de la física cuántica como la psicología del trabajo o sociología donde se habla del Efecto Hawthorne (los sujetos que saben que siendo sometidos a un experimento modifican los comportamientos que están siendo experimentalmente medidos)

Aterrizando dentro del ámbito de la temática de este blog, ¡cuántas veces nos empeñamos en medir proyectos y equipos… y sólo por este hecho de medir, aparentemente inocuo, estamos condicionando el desarrollo de lo que estamos midiendo!

No creo que nadie discuta la necesidad de medir de alguna forma cómo van los proyectos. La cuestión está en hacerlo de forma que no haga entrar en dinámicas dañinas a las personas protagonistas del proyecto ni a distorsionarlo. Y esta es una de las reflexiones recurrentes y retos con las que me tengo que enfrentar proyecto a proyecto.

Es muy conocido y cuestionado, por ejemplo, el modo de medir el avance de un proyecto por el tiempo que se invierte (o gasta, no sé qué término es mejor) en él. Este método de medir el avance por horas invertidas/gastadas provoca que las personas de los equipos no se vean motivadas por la calidad o eficiencia de lo que hacen – no son factores que se midan al fin y al cabo – y que los proyectos se alarguen y alarguen para alborozo de la consultora cárnico-industrial de turno y desesperación del pagano cliente.

Otra situación perniciosa tiene que ver con las reuniones de seguimiento e informes de progreso, donde a veces (me resisto a decir frecuentemente) se pierde de vista el objetivo del proyecto y el informe de marras se convierte en un objeto en sí mismo… el esfuerzo del equipo, el tempo y las tareas del proyecto se centran en la redacción del consabido informe – que para acabar de arreglarlo se plasma en uno de esos powerpoints infumables con fuentes a tamaño 10.

¿Cabe algo más perverso que el que el objeto de un proyecto sea la propia medición del mismo?

¿Y qué decir cuando el coste de medir es desproporcionado, del mismo orden de magnitud y comparable al coste del objeto medido, verbigracia el proyecto?.

Cuando analizo para mis clientes el coste de sus proyectos a donde primero apunto es a lo que se denomina eufemísticamente, la capa de gestión o de calidad que suele poner el proveedor. No digo que no haga falta pero hay que escrutar con detenimiento y siempre cuantas de las funciones de esas capas son sólo meramente administrativas, es decir para contar horas en un excel y dibujar bonitos (?) diagramas de Gantt.

En alguno de mis proyectos de selección de aplicaciones de gestión, medio en broma, le he llegado a proponer a mi cliente que dominar el Microsoft Project sea directamente un criterio de exclusión/veto (o al menos penalizador) de la persona propuesta como jefe de proyecto por los proveedores ofertantes (hay que aclarar que en las ofertas siempre exigimos que adjunten los CVs del equipo que proponen para hacer el proyecto).

Y a todo esto, alguno de mis hipotéticos lectores se dirá: vale, cierto, es verdad… este tipo saca todo esto a relucir y no aporta nada para cambiarlo o mejorarlo. Pues sí, tendría toda la razón (al menos eso es lo que yo pensaría). El problema es que esta entrada ya me está saliendo demasiado larga. Mejor lo dejo para un post posterior.

Por supuesto tus comentarios son más que bienvenidos.

 
(1) En realidad no es la velocidad sino la cantidad de movimiento o lo que es lo mismo, el producto de la masa por la velocidad del objeto en cuestión. Para simplificar se suele obviar el concepto masa para no tener que meternos en berenjenales de definir masa y considerar equivalencias con energía, etc. A efectos de esta entrada esta simplificación no tiene relevancia.
 
 (2): Esta entrada es una actualización de una publicada anteriormente.

Tipos de proyecto, visión resultadista

Al final, hay sólo unos pocos tipos de proyecto:

  • Proyectos Aspirina: los que arreglan problemas existentes.
  • Proyectos Vitamina: los que permiten conseguir beneficios nuevos.
  • Proyectos Veneno: los que crean problemas que no existían.
  • Proyectos Placebo: los que no tenían una justificación objetiva pero ayudan de alguna forma.

Ahí queda eso.

* * *

Si necesitas ayuda en temas relacionados con los contenidos de este blog no dudes en contactarme. En cualquier caso gracias por tu visita y tiempo.

Si este contenido te ha gustado te agradecería que lo compartieras y dieras difusión. Estaré encantado de conocer la opinión de mis colegas.

Fricciones y proyectos

Project Manager en acción :)

Recuerdo de mis tiempos de estudiante en la Escuela de Ingeniería un problema de física donde se debía determinar la velocidad máxima que podía alcanzar un cuerpo en caida libre en la atmósfera terrestre. La gracia del planteamiento del problema era entender como la fuerza de rozamiento podía llegar a compensar a la fuerza de la gravedad y el concepto de coeficiente de rozamiento. Y lo que me llamó la atención era el hecho de que se alcanzaba una velocidad máxima.

En los proyectos que he conocido creo que pasa algo parecido con el avance. Llega un momento en el que la velocidad de avance del proyecto (se mida como se mida) llega a un máximo y por muchas acciones, técnicas o metodologías que como Project Manager apliques, hay un entorno que frena y que te hace llegar inexorablemente a esa velocidad de avance máxima.

¿Cómo romper, superar o desbloquear ese límite?

Lo primero es identificar el punto de saturación, porque es el momento en el que debes dejar de aplicar tus metodologías (sean las que sean) para incrementar la velocidad de avance del proyecto (no significa que las abandones, pues serán necesarias para que la velocidad se mantenga). Cualquier esfuerzo en ese sentido, traspasado ese punto de saturación o velocidad de avance máxima, será inútil o poco favorable en términos de coste/beneficio.

Nos queda después, identificar y actuar sobre otros elementos del entorno del proyecto, concretamente sobre lo equivalente al coeficiente de rozamiento – factores que frenan o friccionan. Y esto ya es más un arte que una ciencia pues nos metemos en terrenos de las organizaciones y relaciones humanas dentro de las empresas. Aquí cada cual tendrá sus habilidades.

¿Te atreves a poner ejemplos?

 

* * *

Si este contenido te ha gustado te agradecería que lo compartieras y dieras difusión. Estaré encantado de conocer la opinión de mis colegas.

Si necesitas ayuda o soporte en temas relacionados con los contenidos de este blog no dudes en contactarme. En cualquier caso gracias por tu visita y tiempo.

Avanzar… o no, quien sabe

Leyendo el libro de Eduardo MendozaEl enredo de la bolsa y la vida, me he encontrado esta perla de discurso que pronuncia el protagonista del libro tras reunirse con su equipo, por llamarle de alguna forma (el que haya leído el libro me entenderá) :

Este intercambio de ideas ha sido muy provechoso y os agradezco a todos vuestras respectivas aportaciones. Ni una sola ha caído en saco roto, os lo puedo asegurar. Es cierto, haciendo balance de la situación, que parece que no hayamos avanzado, y es muy probable que no hayamos avanzado. Incluso es posible que hayamos retrocedido, cosas ambas difíciles de determinar cuando no se conoce el punto de partida ni el objetivo último de nuestro caminar. Pero también puede darse lo contrario, es decir, que hayamos avanzado sin darnos cuenta. Bien es verdad que avanzar sin enterarse de que se avanza es lo mismo que no avanzar, al menos para el que avanza o pretende avanzar.

A mí esta situación me es muy familiar, ¿a alguien más?

PD. El libro, muy recomendable

Proyectos para el «Sr. Lobo»

Proyectos IT hay de muchas clases, colores, sabores y hasta olores. Los hay para crear cosas nuevas (por ejemplo un producto), para mejorar algo existente y los hay para arreglar destrozos producidos por otros proyectos, anteriores.

Para tener éxito en todos pero sobre todo en estos últimos, se requiere que el Project Manager adopte una actitud «especial», que yo llamo de Project Manager Sr. Lobo«, apodo o denominación que he sacado de un personaje peculiar de la película Pulp Fiction.

Antes de seguir mejor que lo veas antes por tí mismo:

;

Yo destacaría:

  • Actitud clara y meridiana: Es genial cómo se presenta «Soy el Sr. Lobo, soluciono problemas»
  • Conocimiento del entorno del proyecto: equipo (sabe los nombres de todos), marco temporal (tiempo hasta que tienen visita), tareas (cada uno tiene una que hacer), anticipar riesgos (lo de chequear el funcionamiento de coche), …
  • Identificación del problema: En este caso «un cadáver sin cabeza en el coche»
  • Visión priorizada: «al grano»
  • Estilo de dirección adecuado a la coyuntura concreta del proyecto: nada de «por favor» ni «visión colaborativa» con estas urgencias… cuando se tiene que evacuar un edificio por incendio, «el equipo» no se reúne para consensuar un plan de acción (este es un tema que puede dar de sí para más posts).

 

Escribo esta entrada porque un cliente, un excelente cliente, me ha pedido que le eche una mano para encauzar un proyecto que se les ha torcido. Va a ser un proyecto duro y de mucho desgaste, además de con riesgo porque afecta al día a día de todos los empleados de la compañía. Pero como dice mi colega @avallesalas, con los clientes hay que estar para lo bueno y para lo malo. A ver que sale…

* * *

Si este contenido te ha gustado te agradecería que lo compartieras y dieras difusión. Estaré encantado de conocer la opinión de mis colegas.

Si necesitas ayuda o soporte en temas relacionados con los contenidos de este blog no dudes en contactarme. En cualquier caso gracias por tu visita y tiempo.

Proyectizar la empresa

En un proyecto, hablando en términos generales, hay que obtener unos resultados/objetivos en un tiempo determinado y con un equipo y recursos dados, balanceando estos tres términos y gestionando los potenciales riesgos que te puedan romper ese equilibrio. Ya sé que esta definición puede parecer tosca y que no recoge los infinitos matices que se pueden tener en cuenta al hablar de proyectos, pero para el propósito de este artículo creo que basta.

Y es que creo que la situación y la gestión de las empresas sería mejor si se incorporara a esa gestión, a todos sus niveles, una visión de Proyecto – que la empresa se proyectizase, perdón por el palabro, considerando estos conceptos de tiempo/resultados/equipo/recursos/riesgos en nuestro quehacer diario.

No se trata de que nos gobierne un diagrama de Gantt o una matriz de riesgos, sino de que cada uno de nosotros actuemos, en nuestro día a día,  teniendo en cuenta el valor del tiempo, los objetivos y resultados a obtener, los medios con los que contamos y su coste, las consecuencias de no hacer bien nuestro trabajo, las alternativas a situaciones dadas o no dadas (o precisamente por eso), la anticipación a problemas, …

Y no hacen falta grandes acciones, pequeños gestos son suficientes, como no llegar tarde a las reuniones, entregar a tiempo aquello a lo que nos hemos comprometido (y avisar con tiempo de ello si no lo conseguimos), mejorar el uso del correo electrónico (no pongas en copia a todo el mundo si no es necesario, y menos aún no respondas a todos para contestar a uno sólo), preparar las reuniones y  limitar (time-boxing) el tiempo dedicado a ellas, …

Y si me tuviera que quedar con un único punto, me quedaría con el de valorar el tiempo (sobre todo el de los demás).

¿Y tú, propones otros pequeños gestos, te quedas con otro de los puntos?

 

Imagen: Dilbert

Bonus: Time Management en Dilbert

 

Antes y de forma frecuente

 

En un debate reciente en nodoERP, el grupo de LinkedIn que modero, Romina Moncalvi citaba de un estudio de Evaluando Software: los clientes en 21012 exigirán que los proyectos de implementación se aceleren.

Yo creo que más que se aceleren lo que se necesita es que entreguen valor antes, que sus beneficios se reciban antes. Claro que eso implica pasar del tradicional modelo de planificación y ejecución Waterfall de proyectos de implantación a modelos ágiles, donde se entrega valor antes y de forma frecuente.

¿Es eso posible en entornos de aplicaciones de gestión empresarial?  Estoy convencido que sí.

 

 

Uso de cookies

Este sitio web y subdominios asociados utilizan cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pinche el enlace para mayor información.plugin cookies

ACEPTAR
Aviso de cookies