Por qué los proyectos de software se desvían del presupuesto (y cómo evitarlo)
Que un proyecto de software termine costando más de lo previsto es tan habitual que muchas veces se da por sentado. Pero los desvíos tienen causas identificables, y la mayoría se pueden anticipar antes de empezar a construir.
Equipo Eudaimonia4 min de lectura
Un presupuesto de software es una estimación hecha con la información disponible en un momento dado. El problema no es que cambie, sino que cambie por motivos que nadie había considerado: una integración que resultó más compleja, una funcionalidad que se entendía distinto en cada área, un sistema externo que no tenía ambiente de pruebas.
El desvío empieza mucho antes de que cambie el número del presupuesto. Suele aparecer cuando dos personas creen haber acordado la misma funcionalidad, pero imaginan trabajos distintos. Por eso conviene mirar primero qué se estimó y qué quedó fuera.
Las causas más frecuentes
Un alcance que no estaba realmente definido
«Un módulo de gestión de turnos» puede significar una agenda simple o un sistema con múltiples profesionales, sedes, reprogramaciones, recordatorios, listas de espera e integración con obras sociales. Si no se pregunta qué ocurre ante una cancelación o una ausencia, cada área completa el alcance con su propia versión. La estimación puede quedar atada a la más simple.
Solo se estimó el camino feliz
La operación principal suele ser la parte más fácil de construir. Las cancelaciones, las devoluciones, los errores de pago, los permisos por rol y los casos límite son los que multiplican el esfuerzo. Si no se relevaron antes, aparecen durante el desarrollo como "cambios".
Integraciones subestimadas
Conectar con un ERP, una pasarela de pagos o un sistema heredado rara vez es tan directo como sugiere la documentación. Formatos distintos, límites de uso, falta de ambientes de prueba, tiempos de otro proveedor y manejo de errores y reintentos agregan trabajo que suele aparecer después de cerrar la estimación inicial.
Dependencias que nadie controla
Accesos que tardan semanas en llegar, definiciones que dependen de un área que no participa del proyecto, contenidos o datos que tiene que proveer el cliente. Cada una de estas dependencias puede frenar al equipo aunque la estimación técnica haya sido correcta.
Todo lo que no es programar
QA, ambientes, despliegues, migración de datos, documentación, capacitación, seguridad y ajustes posteriores al lanzamiento. Son partes necesarias de cualquier producto que va a producción y a menudo quedan fuera del cálculo inicial.
Cambios de prioridad sin gestión
Que el alcance cambie durante el proyecto es normal y muchas veces es buena señal: se aprendió algo. El problema aparece cuando se suman funcionalidades sin revisar qué se posterga, cuánto impacta en el plan y quién decide.
Cómo estimar mejor
Definir antes de estimar: una etapa de discovery con flujos, casos de uso y escenarios alternativos permite estimar sobre algo concreto y no sobre una descripción general.
Estimar en rangos: decir «cuesta X» sugiere una precisión que en esta etapa nadie tiene. Decir «entre X e Y, si se cumplen estos supuestos» muestra el margen real y le da a quien decide algo concreto para evaluar.
Hacer explícitos los supuestos: "la API del ERP permite consultar stock en tiempo real", "el cliente provee los contenidos". Si un supuesto no se cumple, está claro por qué cambia la estimación.
Validar temprano lo más incierto: una prueba de concepto de la integración más compleja o de la funcionalidad técnicamente más riesgosa reduce la incertidumbre de todo el presupuesto.
Incluir todo el trabajo: QA, ambientes, despliegue, migración y estabilización posterior al lanzamiento forman parte del proyecto.
Cómo mantener el control durante el proyecto
Construir por etapas: entregas incrementales, cada una con valor propio, permiten medir el avance real y ajustar el plan con información en lugar de suposiciones.
Priorizar con un criterio compartido: cuando aparece algo nuevo, la pregunta no es solo si se puede hacer, sino qué se posterga para hacerlo.
Gestionar las dependencias como parte del plan: identificar quién tiene que proveer cada acceso, dato o definición, y para cuándo.
Hacer visible el avance: demos periódicas con el producto funcionando son más confiables que cualquier porcentaje de avance reportado.
Revisar la estimación en cada etapa: con lo aprendido, el rango se achica. Si se desplaza, conviene saberlo lo antes posible.
Si el módulo de turnos necesita ahora recordatorios y lista de espera, la conversación no debería limitarse a cuánto cuesta sumarlos. También hay que decidir si reemplazan otra función de la primera versión, quién aprueba el cambio y qué pasa con la fecha de entrega.
Preguntas para hacerle a cualquier presupuesto
¿Sobre qué definición funcional se hizo la estimación? ¿Está escrita?
¿Qué escenarios alternativos y excepciones contempla?
¿Qué integraciones incluye y qué se sabe de cada sistema externo?
¿Qué supuestos, si no se cumplen, cambian el número?
¿Incluye QA, ambientes, despliegue, migración de datos y estabilización?
¿Cómo se va a gestionar un cambio de alcance durante el proyecto?
Un presupuesto que responde bien estas preguntas no garantiza que no haya cambios, pero sí que los cambios van a ser visibles, explicables y gestionables.
Un presupuesto útil deja visibles sus límites. Así, cuando cambia el alcance, se puede discutir una decisión concreta en lugar de intentar explicar el desvío al final.
A software budget is an estimate based on the information available at a particular time. The problem is not that it changes, but that it changes for reasons nobody considered: an integration turns out to be more complex, different departments understand a feature differently, or an external system has no test environment.
An overrun begins long before the budget number changes. It often starts when two people think they agreed on the same feature but have different work in mind. That is why it helps to examine what was estimated and what was left out.
The most common causes
Scope that was never fully defined
“An appointment management module” could mean a simple calendar or a system with multiple professionals and locations, rescheduling, reminders, waiting lists, and health insurer integrations. If nobody asks what happens after a cancellation or a no-show, each department fills in the gaps with its own assumptions. The estimate may reflect only the simplest version.
Only the happy path was estimated
The main transaction is usually the easiest part to build. Cancellations, returns, payment failures, role-based permissions, and edge cases multiply the effort. If they were not identified beforehand, they appear during development as “changes.”
Underestimated integrations
Connecting to an ERP, payment gateway, or legacy system is rarely as straightforward as the documentation suggests. Different data formats, usage limits, missing test environments, another vendor’s timelines, error handling, and retries add work that often becomes visible only after the initial estimate is approved.
Dependencies nobody controls
Access credentials that take weeks to arrive, decisions owned by a department outside the project, or content and data the client must provide: any of these can block the team even when the technical estimate was accurate.
Everything beyond coding
QA, environments, deployments, data migration, documentation, training, security, and adjustments after launch are all necessary for a production product. They are often missing from the initial calculation.
Priority changes without a process
Scope changes during a project are normal and often show that the team has learned something. Trouble starts when features are added without reviewing what will be postponed, how the plan is affected, and who makes the decision.
How to estimate more accurately
Define before estimating: a discovery phase that maps flows, use cases, and alternative scenarios makes it possible to estimate something concrete instead of a broad description.
Estimate in ranges: saying “it costs X” suggests a precision nobody has at this stage. “Between X and Y, if these assumptions hold” makes the uncertainty visible and gives decision makers something useful to evaluate.
State assumptions explicitly: “the ERP API supports real-time stock queries” or “the client supplies the content.” If an assumption fails, the reason for a revised estimate is clear.
Validate the biggest uncertainties early: a proof of concept for the most complex integration or riskiest feature reduces uncertainty across the entire budget.
Include all the work: QA, environments, deployment, migration, and post-launch stabilization belong in the project plan.
How to stay in control during the project
Build in stages: incremental releases, each valuable on its own, let the team measure real progress and adjust the plan with evidence.
Prioritize using shared criteria: when a new request appears, ask not only whether it can be done, but what will be postponed to make room for it.
Manage dependencies as part of the plan: identify who must provide each access, dataset, or decision, and by when.
Make progress visible: regular demos of working software are more reliable than any reported percentage complete.
Revisit the estimate at each stage: as the team learns, the range narrows. If it shifts, everyone should know as early as possible.
If the appointment module now needs reminders and a waiting list, the conversation should go beyond their cost. The team must also decide whether they replace another first-release feature, who approves the change, and how the delivery date is affected.
Questions to ask about any budget
What functional definition was the estimate based on? Is it documented?
Which alternative scenarios and exceptions does it cover?
Which integrations are included, and what is known about each external system?
Which assumptions would change the estimate if they prove false?
Does it include QA, environments, deployment, data migration, and stabilization?
How will scope changes be handled during the project?
A budget that answers these questions does not guarantee that nothing will change. It does make changes visible, explainable, and manageable.
A useful budget shows its boundaries clearly. Then, when scope changes, the team can discuss a specific decision instead of trying to explain the overrun at the end.
Diseño y construcción de productos digitales
¿Estás pensando en construir un producto digital?
Te ayudamos a definir el alcance, validar la idea y construir un producto preparado para crecer.
Qué es la etapa de discovery en un proyecto de software, para qué sirve, cómo se trabaja y qué entregables concretos deberías tener antes de empezar a desarrollar.
Cómo Eudaimonia desarrolló Llamando al Doctor, una plataforma de telemedicina integrada con AWS para conectar a pacientes y médicos mediante videollamadas.
