¿Qué muestran los datos?
Que incumplir es lo normal, no la excepción. Apenas
9 de 40 proyectos (22,5%) se
entregaron el día prometido, y en promedio tardamos
68,6% más de lo ofertado:
6,88 días frente a 4,08.
Y muestran algo que no esperaba: que mi propio diagnóstico estaba
exagerado. En la fase anterior dije, a ojo, que las entregas tomaban
«entre 9 y 14 días». Medido, la mitad de los proyectos se cierra en
6,5 días o menos, y el rango real va de
3 a 14. Los 14 días existen, pero son el peor caso,
no la costumbre. Me quedé con los proyectos que más me dolieron y los
tomé por la regla. Eso es justamente lo que uno deja de hacer cuando
empieza a medir.
¿Qué patrones aparecen?
El problema no está repartido. Electrónica y domótica
acumula 4,2 días de retraso medio y no cumplió plazo ni una vez,
mientras custodia digital se queda en 1,4 días y cumple el
38% de las veces. Migración Unix-Linux queda en medio:
3,3 días y 23%.
Hay un punto donde el equipo se quiebra. Con cuatro
proyectos o menos a la vez, el retraso medio es de 2 días;
pasando de cuatro salta a 4,91, unas
2,5 veces más. No se degrada poco a poco: se rompe de golpe.
Pocas causas explican casi todo. Tres de las seis se
llevan el 80% de los 112 días perdidos:
sobrecarga del equipo (40%), falta de repuestos
(27%) y cambios de alcance (13%).
Y el cliente lo nota. Quien recibe a tiempo califica
4,78 sobre 5; quien espera cinco días de más baja a
3,21. La relación entre retraso y satisfacción es de las más
fuertes que salieron (r = -0,92).
¿Cuáles son las causas probables?
La de más peso es de capacidad, no de habilidad técnica:
aceptamos más trabajo simultáneo del que el equipo aguanta. Cuando se
juntan más de cuatro proyectos, ninguno recibe la atención que necesita
y terminan atrasándose todos a la vez.
La segunda es de abastecimiento, y explica por qué
domótica es la peor línea: en el 46% de sus proyectos
faltaba equipo de terceros el día de arrancar, y cuando eso pasa el
retraso sube a 5,5 días contra 2,12. El fallo
está antes de empezar, al comprometer una fecha sin confirmar que el
material llega, no en cómo se ejecuta el trabajo.
La tercera es de alcance mal cerrado: el
42% de los proyectos recibió cambios del cliente ya
empezados, y eso duplica el retraso (de 1,9 a 4 días).
Con todo, conviene no pasarse de confiado: esto es correlación,
no causa demostrada. La relación entre carga y retraso es
moderada (r = 0,37), bastante más floja que la de retraso con
satisfacción. Bien puede haber una tercera variable (la complejidad del
proyecto, por ejemplo) empujando las dos cosas a la vez. Y los extremos
de la muestra son frágiles: en los niveles de carga 1 y 7 hay un solo
proyecto, así que la tendencia solo se sostiene entre 3 y 6.
¿Qué decisiones tomar?
Los datos confirman las tres decisiones que ya había
propuesto, pero cambian el orden. Lo que planteé como decisión
estratégica a un año (poner un tope de proyectos por técnico) resulta
ser la de mayor impacto, porque ataca el 40% de los días
perdidos. Habría que adelantarla.
Para esta semana: no dar fecha en un proyecto de domótica sin
confirmar antes que el equipo de terceros llega. No cuesta
nada y ataca la segunda causa del Pareto.
Para los próximos meses: cerrar el alcance por escrito antes de
empezar, y volver a cotizar el plazo si el cliente pide
cambios en el camino.
Y una que los datos sugieren pero que tomaría con pinzas:
ajustar los plazos que ofertamos según la línea de
servicio. Prometer cuatro días parejos cuando domótica entrega
en 8,3 es una promesa que nace rota. Pero subir el plazo
sin arreglar la operación solo maquilla el indicador: el
cliente esperaría más y el equipo seguiría igual de ahogado. Sirve
acompañando a las dos medidas anteriores, nunca en lugar de ellas.
Custronix