Casi ningún proyecto IT termina cuando se planificó. No es mala suerte ni falta de talento: es la forma en que subestimamos el tiempo y, sobre todo, cómo lo gestionamos. Después de más de dos décadas operando IT en Argentina, en Novatium vemos las mismas causas repetirse, las mismas señales de alerta ignoradas y una diferencia concreta cuando el tiempo se gestiona como parte del servicio.
Preguntá en cualquier empresa cuándo fue la última vez que un proyecto IT terminó exactamente en la fecha prometida. La respuesta suele ser un silencio incómodo, seguido de una sonrisa.
No es un problema de una industria en particular. Es estructural. Y después de más de veinte años viendo proyectos arrancar, atrasarse y —a veces— llegar a buen puerto, en Novatium aprendimos que el retraso casi nunca aparece donde uno lo busca.
El tiempo no se subestima por optimismo. Se subestima por diseño.
La explicación fácil es que somos demasiado optimistas al planificar. Es cierto, pero es apenas la superficie. El problema más profundo es que estimamos el tiempo del trabajo visible e ignoramos el del trabajo invisible: las validaciones que dependen de terceros, las integraciones que “deberían andar”, los accesos que tardan semanas, las decisiones que quedan esperando a alguien que estaba de vacaciones.
Ese trabajo invisible casi nunca se mide, y sin embargo es el que más pesa. Una buena estimación no es la que asume que todo saldrá bien: es la que reserva un margen explícito para dependencias e imprevistos. Como regla práctica, un proyecto que no contempla al menos un 15% o 20% del tiempo para lo que no depende del equipo técnico, no está estimado: está apostado.
Por eso un proyecto no se atrasa el día que se cae un servidor. Se atrasa mucho antes, en todas esas horas que nadie contó porque no figuraban en el plan.
Las cuatro causas que vemos repetirse
- Alcance que crece en silencio. Cada “ya que estamos, agreguemos esto” parece menor. Sumados, redefinen el proyecto sin que nadie haya movido la fecha de entrega.
- Dependencias que no se gestionan. El equipo técnico puede ser excelente, pero si depende de un tercero que responde cuando puede, el cronograma lo maneja el eslabón más lento, no el más rápido.
- Estimaciones sin margen para lo imprevisto. Se planifica para el escenario en que todo sale bien. Y en operaciones reales, algo siempre sale distinto a lo previsto.
- Falta de un responsable claro del tiempo. Cuando todos son dueños del proyecto, nadie es dueño del plazo. Y lo que no tiene responsable, se estira.
Cinco señales de que tu proyecto ya está atrasado, aunque figure “en fecha”
El atraso rara vez se anuncia. Se acumula en silencio y recién se hace visible cuando ya no hay margen. Estas son las señales tempranas que conviene mirar antes de que el cronograma lo confirme:
- Hay tareas bloqueadas esperando a terceros —y ese bloqueo se toma como “normal” en lugar de tratarse como un riesgo activo.
- El equipo empieza a trabajar sobre supuestos porque todavía faltan definiciones. Avanza, sí, pero sobre una base que puede tener que rehacerse.
- Se agregan pequeñas tareas que no modifican formalmente el alcance. Nadie firma un cambio, pero el proyecto que se está ejecutando ya no es el que se planificó.
- El avance se mide por tareas terminadas, no por hitos cumplidos. Se puede estar “al 80%” de las tareas y al 40% de los hitos que realmente importan.
- La fecha final sigue intacta aunque ya se hayan consumido los buffers. Si el margen de imprevistos se gastó en la primera mitad y la fecha no se movió, el atraso ya existe: todavía no se declaró.
Ninguna de estas señales es técnica. Todas son de gestión. Y ahí está la distinción más importante: un atraso puntual se resuelve con esfuerzo; un problema estructural se repite proyecto tras proyecto, siempre por las mismas causas. Si el retraso vuelve a aparecer con equipos distintos y tecnologías distintas, el problema no es de estimación. Es del modelo con el que se gestiona.
Cómo se gestiona el tiempo cuando es parte del servicio
La diferencia entre un proyecto que se estira sin control y uno que se atrasa poco y avisa a tiempo no está en la tecnología. Está en el modelo de gestión. Y ese modelo se apoya en decisiones concretas:
- Un responsable único del plazo, distinto del responsable técnico. Alguien cuya tarea es proteger la fecha, no ejecutar las tareas.
- Las dependencias, gestionadas formalmente: identificadas al inicio, con responsable y fecha comprometida por cada tercero, y seguimiento antes de que bloqueen, no después.
- El alcance, controlado con criterio: cada pedido nuevo se acepta, pero se hace visible su impacto en tiempo. No se trata de frenar al negocio, sino de que la decisión de sumar algo sea consciente.
- Indicadores semanales que miran hitos y buffers, no solo tareas cerradas: cuánto margen queda, qué dependencias están en riesgo, qué desvíos aparecieron. Los desvíos se detectan cuando todavía se pueden corregir.
Cuando el tiempo se trata como una variable que se mide y se gobierna —y no como una promesa que se hace al inicio y se olvida— el proyecto deja de sorprender. No porque no haya imprevistos, sino porque hay un modelo que los anticipa, los contiene y los comunica.
La pregunta que conviene hacerle a tu proveedor IT
Acá está el punto que más importa. Un buen proveedor IT no se limita a ejecutar tareas y reportar avances. Gestiona dependencias, riesgos, tiempos y comunicación para que el cliente tenga algo que vale más que la velocidad: previsibilidad.
Por eso, más que preguntar “¿vas a terminar a tiempo?” —una promesa fácil de hacer y difícil de sostener— conviene preguntar cómo se gestiona el proyecto: ¿Hay un responsable del plazo, además del responsable técnico? ¿Cómo se identifican y se siguen las dependencias con terceros? ¿Qué pasa, en concreto, cuando el atraso depende de alguien que no sos vos ni el proveedor? ¿Qué indicadores vas a ver cada semana, y muestran hitos y márgenes o solo tareas cerradas?
Las respuestas a esas preguntas separan al proveedor que “hace la tarea” del partner que se hace cargo del resultado. La próxima vez que un proyecto IT se atrase, antes de preguntar qué falló técnicamente, vale la pena preguntar algo distinto: ¿había alguien realmente gestionando el tiempo, o simplemente lo estábamos esperando?
Porque la mayoría de los retrasos que cuestan caro no eran técnicos. Eran previsibles. Solo que nadie los estaba mirando.
Si tus proyectos IT tienden a estirarse más de lo previsto, hablemos.
Conversemos sobre cómo gestionar el tiempo de tus proyectos IT.