Gestión presupuestaria en proyectos de TI: gobernanza, realidades de costos y modelos modernos
Pierre Henriet — Una guía experta sobre presupuestación de proyectos TI: datos empíricos de sobrecostes (Flyvbjerg), línea base PMBOK y EVM, taxonomía TBM, transición CapEx/OpEx FinOps y modelos reales en Capital One, ING y el gobierno federal de EE. UU.
En la ingeniería corporativa, la gestión presupuestaria de un proyecto de Sistemas de Información (TI) difiere radicalmente de la presupuestación en la ingeniería civil o la manufactura tradicional. Mientras que las obras civiles operan con materiales físicos sujetos a leyes mecánicas comprobadas y mano de obra estandarizada, los proyectos de software se desenvuelven en un entorno de activos intangibles, requisitos de negocio volátiles, deuda técnica oculta y arquitecturas multi-cloud con complejas dependencias de integración.
Asimismo, el gasto informático corporativo se divide en dos fuerzas contrapuestas: Run-the-Business (RTB)—el presupuesto operativo obligatorio destinado al mantenimiento en condiciones operativas (MCO) de los ERP, bases de datos, redes e infraestructura existente (estimado por Gartner entre el 65% y el 70% del gasto total de TI)—y Change-the-Business (CTB)—el capital discrecional asignado a proyectos de transformación digital e innovación de software (representando únicamente entre el 30% y el 35%). Cuando los proyectos de software sufren desvíos presupuestarios incontrolados, canibalizan directamente la capacidad de innovación de la empresa.
Esta guía avanzada examina las realidades empíricas de los sobrecostes en proyectos de software, analiza el marco de referencia del Project Management Institute (PMI PMBOK® 7.ª edición), aborda la transición de CapEx a OpEx mediante Cloud FinOps y expone los modelos de gobernanza aplicados por organizaciones líderes como Capital One, ING Group, Netflix y el Gobierno Federal de EE. UU.
1. La realidad empírica: por qué los proyectos de TI superan el presupuesto
Antes de aplicar metodologías de control de costos, los directores de proyectos deben confrontar la evidencia estadística. Las desviaciones presupuestarias en el software no son fallos fortuitos, sino patrones sistemáticos originados por sesgos cognitivos (sesgo de optimismo) y la complejidad no lineal de los sistemas.
- El estudio empírico de Bent Flyvbjerg y Alexander Budzier (Universidad de Oxford / McKinsey and Company): En la mayor investigación empírica jamás realizada—analizando 5.400 proyectos de software y TI en corporaciones globales públicas y privadas (publicada en la Harvard Business Review)—los investigadores descubrieron realidades contundentes:
• Sobrecoste medio: Los proyectos de TI superan su presupuesto inicial en un promedio del +45%.
• Retraso de cronograma: Los proyectos sufren una desviación temporal media del +7%.
• Déficit en entrega de valor: Los proyectos entregan en promedio un -56% menos de valor de negocio que lo prometido en los casos de negocio iniciales.
• El riesgo de cola ancha de los «Cisnes Negros» (Black Swans): A diferencia de la ingeniería física, donde las variaciones siguen una distribución normal, los proyectos de software presentan una distribución de cola pesada (fat-tail). Exactamente el 17% de los proyectos de TI experimentan sobrecostes superiores al 200%, con desviaciones de tiempo mayores al 70%. En situaciones extremas, estos desastres amenazan la solvencia de la empresa (como la quiebra de Kmart provocada por el colapso de su sistema logístico de 1.400 M$, o los 192 M$ en pérdidas sufridas por Levi Strauss durante la implantación de su ERP SAP). - Los informes CHAOS de The Standish Group (25 años de datos empíricos): Tras analizar más de 50.000 proyectos de software, Standish Group demuestra que el tamaño del proyecto es el principal predictor del fracaso financiero. Los proyectos con presupuestos inferiores a 1 millón de dólares alcanzan una tasa de éxito del 76% (entregados en plazo, presupuesto y con alcance funcional), mientras que los megaproyectos superiores a 10 millones de dólares tienen éxito en plazo y costo en menos del 10% de los casos.
2. Ingeniería presupuestaria: línea base del PMBOK y método EVM
Para mitigar la volatilidad de los costos, la gestión profesional de proyectos de TI se estructura en torno al marco estandarizado por el Project Management Institute (PMI PMBOK® Guide, 7.ª edición). Un presupuesto profesional no es una cifra estática, sino una jerarquía financiera estratificada con responsabilidades de gobernanza diferenciadas.
A. Construcción jerárquica del presupuesto de un proyecto TI
Un presupuesto riguroso se estructura de forma ascendente:
- Estimación de costos por actividad: Cálculo de los costos directos de personal (horas de desarrolladores, arquitectos, QA, ingenieros DevOps) y costos externos (entornos cloud de staging, licencias de desarrollo).
- Paquetes de trabajo de la estructura WBS: Agrupación de actividades en entregables tangibles (ej.: «Pasarela de autenticación OAuth 2.0», «Migración del esquema PostgreSQL»).
- Cuentas de control (Control Accounts): Puntos de gestión donde se integran alcance, costo y cronograma para comparar el desempeño con el valor ganado.
- Reserva de contingencia (Contingency Reserve - Riesgos identificados): Fondo financiero cuantificado a partir de la matriz de riesgos del proyecto. Cubre incertidumbres identificadas (demoras en la integración de APIs externas, fluctuaciones cambiarias en licencias SaaS). La reserva de contingencia forma parte de la línea base aprobada y la gestiona directamente el director de proyecto de TI.
- Línea base de costos (Cost Baseline / PMB): El presupuesto escalonado en el tiempo aprobado formalmente (Paquetes WBS + Reserva de contingencia) que actúa como contrato para supervisar el rendimiento financiero.
- Reserva de gestión (Management Reserve - Imprevistos no identificados): Fondo ejecutivo destinado a eventos totalmente imprevistos fuera del alcance inicial (cambios regulatorios repentinos como DORA o RGPD, quiebra de un proveedor tecnológico crítico). La reserva de gestión está bajo el control exclusivo del patrocinador ejecutivo o comité de dirección; el director de proyecto no puede utilizarla sin autorización formal.
Presupuesto total del proyecto = Línea base de costos + Reserva de gestión
B. Técnicas matemáticas de estimación de costos
Los directores de proyecto disponen de tres metodologías principales según el grado de madurez del proyecto:
- Estimación análoga: Uso de costos reales de proyectos históricos similares. Rápida pero con amplio margen de incertidumbre (-25% a +75% en etapas tempranas).
- Estimación paramétrica (COCOMO II y Puntos de Función): Modelado algorítmico que correlaciona datos históricos con inductores de volumen (costo por historia de usuario, costo por endpoint de API).
- Estimación por tres valores / PERT (Distribución Beta): Mitiga el sesgo de optimismo combinando tres supuestos: Optimista (O), Más probable (M) y Pesimista (P):
• Costo esperado:E = (O + 4M + P) / 6
• Desviación estándar:σ = (P - O) / 6
• Permite formular intervalos de confianza estadística (68,2% de probabilidad de que el costo real se sitúe dentro deE ± 1σ; 95,4% dentro deE ± 2σ).
C. Gestión del Valor Ganado (Earned Value Management - EVM)
El estándar EVM (norma ANSI/EIA-748) ofrece telemetría financiera en tiempo real comparando el presupuesto del trabajo planificado con el gasto económico real. Se basa en tres magnitudes:
- Valor planificado (Planned Value - PV): El presupuesto aprobado asignado al trabajo programado para una fecha determinada:
PV = % de avance planificado × BAC(Budget at Completion). - Costo real (Actual Cost - AC): El costo económico total efectivamente incurrido para realizar el trabajo durante dicho periodo.
- Valor ganado (Earned Value - EV): El valor presupuestario del trabajo realmente ejecutado:
EV = % de avance real × BAC.
A partir de estos valores se derivan las variaciones e índices de rendimiento:
- Variación del costo (Cost Variance - CV):
CV = EV - AC. Un valor negativo indica sobrecoste. - Índice de desempeño del costo (Cost Performance Index - CPI):
CPI = EV / AC. Un CPI de 0,85 indica que el proyecto solo produce 0,85 € de software por cada euro gastado. - Estimación a la conclusión (Estimate at Completion - EAC): Proyección del costo total final según el rendimiento actual:
EAC = BAC / CPI.
La regla empírica del 15%: Investigaciones de la Defense Acquisition University (DAU) y el PMI demuestran que una vez alcanzado el 15% o 20% de avance, el CPI acumulado de un proyecto de TI se estabiliza de forma definitiva. Estadísticamente, un proyecto con un CPI de 0,80 en el Sprint 4 casi nunca se recuperará a 1,0 sin recortar sustancialmente el alcance funcional. Los gestores que ignoran esta ley empírica y confían en recuperar el presupuesto en fases posteriores abocan el proyecto al fracaso financiero.
3. Modelos contemporáneos: CapEx/OpEx, FinOps y portafolios ágiles
Los sistemas presupuestarios clásicos fueron diseñados en los años 80 para servidores físicos y centros de datos propios. La computación cloud, los microservicios y los equipos ágiles exigen un replanteamiento de la gobernanza de costos.
A. Transformación de CapEx a OpEx y Cloud FinOps
Tradicionalmente, la infraestructura de TI se contabilizaba como gasto de capital (CapEx): los servidores físicos y las licencias de bases de datos se adquirían inicialmente y se amortizaban linealmente a lo largo de 3 a 5 años en los balances contables, permitiendo al director financiero prever las amortizaciones.
En las arquitecturas cloud (AWS, Scaleway, Azure), la infraestructura pasa a ser gasto operativo (OpEx): el cómputo, el almacenamiento y la red se facturan bajo demanda al segundo. Aunque el modelo OpEx elimina la barrera del desembolso inicial, introduce volatilidad: una consulta SQL mal indexada o un bucle de funciones serverless puede generar decenas de miles de dólares en sobrecostes durante un solo fin de semana.
Para mitigar este riesgo, las organizaciones adoptan el marco Cloud FinOps (FinOps Foundation):
- 1. Informar (Inform): Visibilidad total mediante el etiquetado sistemático (tagging) de recursos. Cada máquina virtual, bucket S3 o base de datos debe incluir etiquetas de metadatos:
CostCenter,ApplicationID,EnvironmentyOwnerSquad. Esto permite habilitar el Showback (paneles que muestran a cada equipo su consumo financiero diario). - 2. Optimizar (Optimize): Eliminación sistemática del desperdicio: apagado de entornos de desarrollo en fines de semana, redimensionamiento de instancias sobreaprovisionadas y adquisición de compromisos de uso (Savings Plans) para cargas de trabajo continuas.
- 3. Operar (Operate): Integración de la economía unitaria en los rituales de desarrollo. En lugar de limitarse a un techo presupuestario arbitrario, los equipos miden el costo unitario cloud (ej.: costo cloud por transacción bancaria procesada o por usuario activo diario). Si el volumen de transacciones se triplica y la factura cloud solo aumenta un 40%, el costo unitario ha mejorado: la arquitectura es más eficiente.
B. Lean Portfolio Management (SAFe / LPM) y Beyond Budgeting
El ciclo anual tradicional de presupuestación—denominado frecuentemente «teatro presupuestario»—adolece de graves ineficiencias estructurales:
- Los equipos dedican meses cada otoño a elaborar planes de negocio teóricos con previsiones financieras a tres años vista.
- Los departamentos incurren en gasto superfluo a fin de año para evitar reducciones presupuestarias en el ejercicio siguiente.
- El capital queda bloqueado en proyectos rígidos, impidiendo redirigir fondos cuando el mercado cambia.
El modelo Beyond Budgeting (Bjarte Bogsnes, Jeremy Hope) y el marco Lean Portfolio Management (LPM / SAFe) resuelven este problema transformando la unidad de financiación: las organizaciones dejan de financiar proyectos temporales y pasan a financiar flujos de valor (Value Streams) permanentes.
En este paradigma:
- Financiación de equipos estables: Los equipos multidisciplinares permanecen unidos de forma indefinida. El trabajo se lleva a los equipos existentes, en lugar de crear y disolver equipos transitorios al compás de proyectos cerrados.
- Presupuestación participativa: Los directores de portafolio y líderes de negocio revisan trimestralmente la asignación de capacidad basándose en objetivos estratégicos (OKRs) y valor validado.
- Límites presupuestarios ágiles (Lean Budget Guardrails):
• Distribución por horizontes: Horizonte 1 (sistemas base de ingresos actuales: 60-70%), Horizonte 2 (iniciativas de crecimiento emergente: 20-25%), Horizonte 3 (innovación y experimentación I+D: 5-10%).
• Asignación de capacidad equilibrada: Garantizar que la capacidad del equipo se reparta entre nuevas funcionalidades de negocio (60%), habilitadores de arquitectura y reducción de deuda técnica (25%), y mantenimiento/seguridad (15%).
4. Modelos reales en la industria: casos corporativos documentados
La tabla siguiente compara las características operativas, la gobernanza y los perfiles de riesgo de los principales marcos presupuestarios contemporáneos:
| Modelo de gobernanza | Unidad de financiación y Filosofía | Frecuencia e Instancias de decisión | Control de riesgos y Flexibilidad | Métricas financieras clave | Organizaciones y Casos de referencia |
|---|---|---|---|---|---|
| 1. Estándar clásico PMBOK / Prince2 | Financiación de proyectos temporales estructurados en WBS; compromiso con el triángulo Costo-Tiempo-Alcance. | Ciclo anual de asignación presupuestaria; comités de dirección y control formal de cambios (CCB). | Baja agilidad; alto riesgo de costos hundidos (sunk costs) si los requisitos iniciales divergen de la realidad. | Earned Value Management (EVM): CPI, SPI, EAC, variación presupuestaria a la finalización (VAC). | Banca corporativa tradicional, sector defensa, administraciones públicas bajo licitaciones rígidas. |
| 2. Lean Portfolio Management (SAFe / LPM) | Financiación de flujos de valor (Value Streams) permanentes; asignación de capacidad a equipos estables. | Revisiones trimestrales (QBR / PI Planning); reasignaciones presupuestarias mediante procesos participativos. | Altísima adaptabilidad; capacidad de pivotar sin penalizaciones contractuales; enfoque en valor entregado. | Costo por punto de historia, ROI por Epic empresarial, flujo de entrega, cumplimiento de Guardrails. | ING Group (transformación a tribus ágiles), Bosch, Lego, Deutsche Telekom. |
| 3. Technology Business Management (TBM v4.0) | Transparencia total del costo total de propiedad (TCO); asignación del libro mayor a servicios de negocio. | Supervisión mensual y trimestral continua; conciliación analítica entre el CIO y el departamento financiero (CFO). | Control estricto de costos operativos; erradicación del Shadow IT y duplicidades de licencias de software. | Costo unitario por servicio entregado, ratio Run vs. Grow, absorción de costos de infraestructura por producto. | Capital One (migración 100% datacenter a AWS), Gobierno Federal de EE. UU. (OMB M-19-16). |
| 4. Cloud FinOps y Economía unitaria | Responsabilidad financiera directa de los equipos de ingeniería sobre el gasto variable en cloud (OpEx). | Telemetría en tiempo real (diaria); revisiones conjuntas en sprints; alarmas automáticas ante anomalías. | Máxima agilidad; detección inmediata de ineficiencias (instancias sobredimensionadas, storage huérfano). | Costo cloud por transacción / usuario activo, porcentaje de instancias reservadas, tasa de desperdicio. | Netflix (telemetría de microservicios), Amazon (AWS), Spotify, Airbnb. |
| 5. Modelo por fases ágiles en el sector público | Desembolso secuencial en fases estrictas y condicionadas (Discovery → Alpha → Beta → Live). | Evaluaciones formales de fase (Gate Reviews); cancelación fulminante si no se demuestra la viabilidad técnica. | Riesgo financiero acotado a pequeñas partidas iniciales; prevención de fracasos millonarios en software. | Costo de validación temprana, tasa de adopción real, volumen de capital hundido evitado. | UK Government Digital Service (GDS), France Travail, NHS Digital. |
A. Technology Business Management (TBM) — Capital One y Gobierno de EE. UU.
El estándar Technology Business Management (TBM) fue concebido para eliminar la barrera de comunicación entre el CIO y el CFO. La contabilidad tradicional clasifica el gasto por naturalezas (nóminas, proveedores, licencias), lo que no refleja el costo real de los servicios entregados. TBM estructura una taxonomía que conecta el libro mayor con las torres tecnológicas y las capacidades de negocio.
- La transición 100% cloud de Capital One: Como primer gran banco de EE. UU. en cerrar todos sus centros de datos para operar completamente en AWS cloud, la gestión de la variabilidad de costos fue prioritaria. Capital One implantó la taxonomía TBM en miles de microservicios. Los directores de producto conocen con exactitud el costo de infraestructura por aprobación de tarjeta de crédito o transacción comercial, fomentando la eficiencia arquitectónica.
- Mandato federal OMB M-19-16 (FITARA) en EE. UU.: La Oficina de Gestión y Presupuesto de la Casa Blanca (OMB) exige a todas las agencias civiles federales adoptar el marco TBM. Administrando más de 90.000 millones de dólares en gasto anual de TI, organismos como la Administración de Servicios Generales (GSA) utilizan TBM para comparar costos unitarios de hardware, consolidar licencias duplicadas y justificar inversiones ante el Congreso.
B. Financiación de flujos de valor y revisiones trimestrales — ING Group
El grupo financiero internacional ING transformó su organización tecnológica adoptando un modelo ágil a gran escala («One Way of Working»).
ING erradicó las solicitudes presupuestarias anuales de 100 páginas. En su lugar, el banco financia tribus y squads permanentes asignados a flujos de valor (Hipotecas, Pagos Digitales, Financiación de Empresas). La gobernanza económica se canaliza a través de Quarterly Business Reviews (QBR) :
- Cada 90 días, las tribus evalúan los resultados obtenidos frente a los objetivos clave (OKRs).
- Si una funcionalidad demuestra valor para el usuario, se mantiene o amplía su capacidad.
- Si una hipótesis fracasa, su financiación se reorienta en el siguiente trimestre sin las penalizaciones contractuales ni los costos de reestructuración propios de la cancelación de un proyecto tradicional.
C. Economía unitaria y gobernanza automatizada — Netflix y Amazon
Al administrar arquitecturas cloud de escala global, Netflix y Amazon (AWS) sustituyen los techos presupuestarios fijos por la economía unitaria y el gobierno automatizado.
- Higiene cloud automatizada: Netflix desarrolló bots de gobernanza de código abierto (como Janitor Monkey) que exploran continuamente las cuentas cloud para detectar y eliminar volúmenes huérfanos, instancias de prueba olvidadas y snapshots obsoletos tras avisos automáticos, recuperando decenas de millones de dólares al año.
- Responsabilidad sobre métricas unitarias: Los ingenieros disponen de telemetría de costos en tiempo real. El presupuesto se gestiona mediante el costo cloud por hora de streaming. Si el gasto aumenta porque el consumo global de los suscriptores se incrementa, la desviación es aprobada de inmediato. Si el costo por hora se dispara sin aumento de audiencia, los equipos son notificados al instante para optimizar el código.
D. Modelo de fases ágiles en el sector público — UK Government Digital Service (GDS)
Para evitar fiascos millonarios históricos en el sector público (como el programa NPfIT de la sanidad británica que consumió miles de millones de libras en contratos rescindidos), el Government Digital Service (GDS) británico estableció el Service Standard y un esquema de desembolso por fases condicionadas:
- Fase Discovery (30.000 a 50.000 £; 4 a 8 semanas): Presupuesto exploratorio mínimo para validar las necesidades del usuario y la viabilidad técnica. Si la necesidad no se confirma, el proyecto se cancela de inmediato sin comprometer capital en desarrollo de software.
- Fase Alpha (100.000 a 250.000 £; 8 a 12 semanas): Financiación acotada para crear un prototipo desechable que pruebe los supuestos técnicos críticos (latencia, seguridad, rendimiento).
- Fase Beta: La asignación de fondos a gran escala solo se produce tras superar una evaluación formal independiente de servicio que examina arquitectura, accesibilidad y métricas de usuario.
- Fase Live: Financiación operativa continua orientada al costo unitario por trámite digital completado.
5. Lista de verificación de gobernanza para directores de proyectos TI
Sintetizando la investigación empírica y los modelos corporativos descritos, los directores de proyectos TI, arquitectos y directores de delivery deben aplicar cinco reglas prácticas:
- Separar con rigor la reserva de contingencia de la reserva de gestión: Nunca concentre todos los fondos de reserva en una partida indiferenciada. Asigne la contingencia al director de proyecto para absorber riesgos identificados de la matriz, y reserve la gestión al patrocinador ejecutivo para virajes estratégicos mayores.
- Vigilar la regla del 15% del método EVM: Supervise semanalmente el índice de desempeño de costos (
CPI = EV / AC). Si el CPI cae por debajo de 0,90 al llegar al 15% o 20% de avance, descarte promesas de recuperación milagrosa y recorte alcance mediante priorización MoSCoW antes de agotar los fondos. - Imponer el etiquetado FinOps desde el Sprint 1: Prohíba cualquier despliegue en cloud que carezca de etiquetas obligatorias:
CostCenter,ProjectID,OwneryEnvironment. El gasto en cloud no asignado es el principal causante de sobrecostes operativos en producción. - Sustituir las estimaciones anuales por ciclos de valor de 90 días: Adopte revisiones trimestrielles de negocio (QBR). Vincule el desembolso presupuestario a la entrega de software funcional verificable en lugar de hitos teóricos de cronogramas Gantt.
- Calcular el Costo Total de Propiedad (TCO) con la regla 70/30: Proyecte siempre el costo operativo (MCO) futuro del producto. Si un proyecto de software de 2 M€ genera un costo recurrente no presupuestado de 400.000 €/año en licencias, mantenimiento y cloud, creará un déficit operativo que anulará su retorno sobre la inversión.
Transparencia IA
Este artículo ha sido estructurado y redactado por Pierre Henriet con apoyo de herramientas de IA para síntesis documental. Todos los análisis, conclusiones y aprendizajes son verificados por el autor.
¿Planeando una evolución en sus sistemas de información?
Hablemos de sus desafíos de alineación estratégica, cumplimiento o despliegue.
Comments (0)