Estimación de proyectos de tecnología: presente un rango
Lleve a la dirección un rango de coste con disparadores de revisión, no un número único. En un estudio de 1.471 proyectos de TI, el coste se desvió un 27% de media, pero la media oculta el riesgo: cerca de uno de cada seis proyectos superó el coste en un 200%. Un número único promete una precisión que el historial no respalda.
¿Por qué un número único es el formato equivocado?
Porque convierte una estimación en una promesa. Cuando usted dice "240.000 €" y el proyecto cierra en 300.000 €, la conversación deja de tratar sobre lo que cambió y pasa a tratar sobre quién se equivocó. Muchas direcciones ya han visto esto y descuentan el número antes de oír el resto.
El rango cambia lo que se discute. Muestra dónde la estimación es firme y dónde no, y cuánto puede costar la diferencia. Quien presenta un rango con supuestos escritos demuestra que conoce el riesgo, en lugar de ocultarlo.
¿Qué dicen los datos sobre los sobrecostes en proyectos de tecnología?
Dicen que el problema está en la cola, no en la media. Bent Flyvbjerg y Alexander Budzier, de la Saïd Business School de la Universidad de Oxford, analizaron 1.471 proyectos de TI y publicaron el resultado en Harvard Business Review en 2011. El sobrecoste medio fue del 27%. Cerca de uno de cada seis proyectos, sin embargo, tuvo un sobrecoste medio del 200%, con un retraso de casi el 70%.
En 2022, Flyvbjerg y otros cinco autores ampliaron la base a 5.392 proyectos de TI, en el Journal of Management Information Systems. Su hallazgo es que los sobrecostes siguen una ley de potencias: muchos proyectos con desviaciones pequeñas y pocos con desviaciones extremas. Quien planifica como si el error fuera simétrico alrededor de una media subestima la probabilidad de un sobrecoste grande. Los autores proponen, con simulación, que la interdependencia entre componentes tecnológicos ayuda a explicar la cola: un problema en un componente desencadena otros.
Hay un límite que conviene decir con claridad. La muestra de 2011 es de proyectos grandes, con un coste medio de 167 millones de dólares por proyecto, y el 92% procedía de organismos públicos. Los porcentajes no son una previsión para un proyecto de su tamaño. Lo que se lleva de ellos es la forma del riesgo: pocos proyectos concentran la mayor parte del sobrecoste, y la media no avisa cuál será el suyo.
El Tesoro del Reino Unido llega a la misma conclusión desde el sector público. Su guía complementaria del Green Book sobre el sesgo de optimismo afirma que quienes evalúan proyectos tienden a ser demasiado optimistas y que costes, beneficios y plazos deben ajustarse de forma explícita, con base en proyectos pasados o similares. La guía adjunta a esa página ofrece porcentajes de ajuste por categoría genérica de proyecto, para usar cuando faltan datos propios más fiables, y aquí no los reproducimos.
¿Cómo montar un rango que la dirección pueda aprobar?
Con tres decisiones: dividir el proyecto en etapas, escribir los supuestos de cada una y definir de antemano qué obliga a tomar una nueva decisión.
La primera es dividir. La propia recomendación de Flyvbjerg y Budzier es partir los proyectos grandes en partes de tamaño, complejidad y duración limitados, y cada parte limita cuánto puede costar un sobrecoste. Cada etapa debe entregar algo que funcione por sí solo, para que la dirección pueda detenerse ahí sin perder lo que ya pagó.
La segunda es escribir los supuestos. El rango de cada etapa depende de cosas que usted aún no ha verificado, como la calidad de los datos que se migrarán y el número de integraciones. Anote cada una. Cuando una falla, el disparador se activa por una razón que todos conocían, no por sorpresa.
La tercera es el disparador. Acuerde antes cuándo vuelve el proyecto a la dirección: cuando el coste acumulado de la etapa supere el tope del rango, cuando un supuesto resulte falso o cuando aparezca un alcance que no estaba en la solicitud. Sin esa regla, el rango se convierte en una excusa para gastar más.
El rango nace de su propio historial cuando existe. Si la empresa ya entregó proyectos parecidos, compare la estimación original con el coste final de cada uno y use la dispersión como base. Si no hay historial, el rango debe ser más amplio y la primera etapa más pequeña, para que el primer proyecto genere el dato que falta.
Un ejemplo práctico: la solicitud de un sistema de órdenes de producción
El escenario es hipotético y las cifras son ilustrativas, no mediciones. Un fabricante de envases con 120 empleados quiere sustituir el control de órdenes de producción, hoy repartido entre hojas de cálculo y el ERP, por un sistema interno. La responsable de innovación tiene dos maneras de llevar la solicitud a la dirección.
En la primera, presenta un presupuesto de 240.000 €. Si la cuenta cierra en 300.000 €, la discusión girará en torno a su error.
En la segunda, presenta tres etapas, cada una con su rango y su supuesto principal escrito. La etapa 1, el núcleo de órdenes y registro de producción, va de 60.000 € a 85.000 € y supone que el maestro de productos está limpio. La etapa 2, la integración con el ERP y con expedición, va de 90.000 € a 130.000 € y supone que el ERP expone los datos necesarios. La etapa 3, los paneles de gestión y el portal de clientes, va de 60.000 € a 85.000 €. La suma es un rango de 210.000 € a 300.000 €.
La solicitud inmediata es solo la etapa 1, con un tope de 85.000 €. Antes de aprobarla, ella plantea a la dirección una pregunta sencilla: si la etapa 1 cuesta el doble, ¿la empresa continúa? La pregunta es nuestra, no una regla de los estudios, pero aplica su idea de comprobar si la empresa puede absorber un sobrecoste. Si la respuesta es no, el problema es el tamaño de la etapa, y la etapa se reduce antes de empezar.
El disparador también queda acordado: si el coste acumulado de la etapa 1 supera los 85.000 €, o si el maestro de productos resulta peor de lo supuesto, el proyecto vuelve a la dirección antes de empezar la etapa 2. El dato de la etapa 1 se convierte en el historial que estrecha el rango de las siguientes.
Entregar por etapas no es teoría para nosotros. En el caso UniTrust, un IMO de seguros de Estados Unidos, Yowpi fue contratada en agosto de 2022 y puso el primer sistema en producción en dos semanas. La plataforma evolucionó sobre esa base durante los años siguientes.
Dónde encaja el rango entre los demás argumentos de la solicitud
El rango resuelve la cuestión del coste, y la solicitud aún necesita sus otros argumentos. Aplazar un proyecto de tecnología tiene un costo trata el otro lado de la cuenta: lo que la empresa paga mientras espera. Y la solicitud debe vincularse a un resultado que la dirección ya sigue. El rango de coste evita que ambos argumentos queden desmentidos por el primer sobrecoste.
Preguntas frecuentes
No puedo justificar la inversión ahora. ¿Un rango debilita la solicitud?
No necesariamente. El rango muestra que se consideró el riesgo, y un primer compromiso pequeño, solo la etapa 1 con tope, es más fácil de aprobar que un proyecto entero a precio cerrado. Lo que debilita la solicitud es un rango sin supuestos.
La implementación exigirá demasiado tiempo del equipo. ¿Cómo ayudan las etapas?
Limitan cuánto tiempo se pide cada vez. En lugar de reservar al equipo durante meses, se piden las horas de la etapa 1 y se usa lo que muestre para estimar la siguiente. La revisión en el disparador es breve: coste acumulado frente al rango y estado de los supuestos.
No veo cómo medir el resultado. ¿Cambia algo con el rango?
Cambia el momento en que se mide. Defina en la etapa 1 qué indicador mostrará la ganancia y mida la línea base antes de empezar. Así, en la revisión, la dirección ve coste y resultado juntos, y la decisión de pasar a la etapa 2 se apoya en datos, no en expectativas.
El siguiente paso
Si hoy su solicitud de inversión depende de un número único, el Diagnóstico de Arquitectura Operacional, una conversación de 30 minutos, es una invitación a diseñar las etapas, los supuestos y los disparadores antes de llevar el proyecto a la dirección: hable con Yowpi.
Cases relacionados
¿Reconociste tu operación en este artículo?
Agenda el Diagnóstico de Arquitectura Operacional: 30 minutos para mapear dónde está el cuello de botella de tu operación. Sin propuesta en la primera conversación.
Agendar diagnóstico