Por qué una mala definición del proyecto le cuesta más que el desarrollo mismo
- Por Amparo Silva | Amsoft
Introducción
Uno de los patrones más recurrentes y costosos en los proyectos de desarrollo de software en Chile y en el mundo es el siguiente: una empresa identifica una necesidad tecnológica, convoca proveedores, recibe propuestas, aprueba un presupuesto y da inicio al proyecto. Varios meses después, el sistema se entrega técnicamente completo, cumple con todo lo que se especificó, pero no resuelve el problema que originó la iniciativa. Los plazos se extendieron, el presupuesto se desbordó y el equipo interno que debía usar la solución la adopta con dificultad o directamente no la adopta. ¿Qué falló? En la mayoría de los casos, no fue la ejecución del desarrollo. Fue la definición del problema que se quería resolver.
Según estudios del Project Management Institute, más de la mitad de los proyectos no logra cumplir sus metas de alcance, tiempo y presupuesto, y las causas más frecuentes están vinculadas a problemas que ocurren antes de que el desarrollo comience: objetivos mal definidos, supuestos no declarados e interlocutores equivocados en la etapa de definición. Y aunque estas cifras circulan en la industria desde hace años, las organizaciones siguen subestimando el valor de una buena definición antes de contratar desarrollo.
Este artículo analiza por qué ocurre esto, cuáles son los errores más comunes en esa etapa, y qué condiciones concretas permiten que un proyecto tecnológico tenga éxito desde antes de que se escriba la primera línea de código.
1. El problema de fondo: describir soluciones en lugar de problemas
1.1 Cuando el "qué" reemplaza al "por qué"
El error más frecuente y al mismo tiempo más difícil de detectar en la definición de un proyecto tecnológico es llegar al proveedor con una solución ya decidida en lugar de con un problema claramente articulado. Una empresa que dice “necesitamos una aplicación móvil para gestionar los pedidos de nuestros clientes” ya tomó una decisión tecnológica sin haber explorado si esa es la mejor manera de resolver su problema de fondo. Quizás el problema real es que los pedidos llegan por múltiples canales y no tienen trazabilidad. Quizás la solución más efectiva y económica es integrar los canales existentes antes de construir algo nuevo. Quizás la aplicación móvil es la respuesta correcta, pero para un segmento específico de clientes y no para todos.
Cuando el cliente describe una solución en lugar de un problema, el proveedor tiene dos opciones: cuestionar la premisa y arriesgarse a perder la propuesta, o aceptarla y construir exactamente lo que se pidió, aunque no sea lo que se necesita. La mayoría de los proveedores, bajo la presión de ganar el proyecto, optan por la segunda. El resultado es un sistema que funciona perfectamente para el problema equivocado.
1.2 El costo de los supuestos no declarados
Asociado a este problema está el de los supuestos implícitos: aquellas condiciones que el cliente da por sentadas y el proveedor desconoce. Un gerente de operaciones que solicita un sistema de gestión de turnos sabe que la empresa tiene tres turnos rotativos, que algunos empleados trabajan en más de un local, y que el sistema debe integrarse con el software de nómina actual. Para él, estos son detalles evidentes que no necesitan explicarse. Para el proveedor, son variables críticas que definen por completo la complejidad del proyecto.
Cuando estos supuestos no se declaran explícitamente en la etapa de definición, emergen durante el desarrollo como “cambios de alcance”. Cada uno de esos cambios tiene un costo: tiempo adicional, replanificación, tensiones en la relación cliente-proveedor y, en muchos casos, decisiones de arquitectura que deben rehacerse porque se tomaron sin esa información. Según datos de Flowlu (2025), el 44% de los proyectos fracasa por falta de alineación entre los objetivos del negocio, y el 80% de las organizaciones reporta dedicar al menos la mitad de su tiempo a retrabajo, gran parte del cual tiene su origen en supuestos que nunca se discutieron.
2. El interlocutor equivocado: cuando quien define no conoce el negocio
2.1 El analista técnico versus el tomador de decisión de negocio
Otro patrón recurrente es la delegación de la definición del proyecto a perfiles técnicos o analistas que conocen bien los sistemas existentes, pero no tienen la visión completa del negocio que debe servir la solución. Esto ocurre con frecuencia cuando la solicitud se origina en la gerencia, pero la elaboración del documento de requerimientos se delega al equipo de TI interno o a analistas de procesos que trabajan en los niveles operativos.
El resultado es un documento técnicamente detallado —lleno de flujos de proceso, campos de formulario y reglas de validación— pero que no captura las preguntas de fondo que el tomador de decisión de negocio necesita que el sistema responda. ¿Qué problema operacional se está resolviendo? ¿Cuál es el impacto esperado en los resultados? ¿Qué decisiones de negocio facilitará este sistema que hoy son difíciles de tomar? ¿Qué pasará si la solución no funciona como se espera? Estas preguntas requieren la participación de alguien con autoridad y visión de negocio, no solo con conocimiento de los procesos actuales.
El Standish Group, en su histórico análisis sobre el fracaso de proyectos de software, identificó la “escasa participación de los usuarios” y la “falta de soporte ejecutivo” como dos de las tres principales causas de fracaso. Décadas después, esos mismos factores siguen apareciendo en los estudios más recientes. La Universidad de la Rioja, en su análisis de los problemas que persisten en la gestión de proyectos entre 2007 y 2021, concluyó que los problemas relacionados con la mala definición de requerimientos o del alcance son los únicos que no desaparecen con el tiempo: se mantienen como causa principal de fracaso independientemente de qué metodología se adopte.
2.2 La trampa de los requerimientos funcionales sin contexto estratégico
Existe una distinción fundamental que muchas definiciones de proyecto ignoran: la diferencia entre requerimientos funcionales y objetivos de negocio. Un requerimiento funcional describe qué debe hacer el sistema: “el sistema debe permitir al usuario crear una orden de compra y asignarla a un proveedor”. Un objetivo de negocio describe qué problema debe resolver: “reducir el tiempo del ciclo de compras de 12 días a 5 días para mejorar la rotación de inventario”.
Cuando la definición del proyecto solo captura requerimientos funcionales sin conectarlos con objetivos de negocio, el proveedor construye exactamente lo especificado, pero no tiene criterio para priorizar, para proponer mejoras o para advertir cuando una decisión técnica va en contra del resultado esperado. El proyecto se convierte en una ejecución mecánica de una lista de funcionalidades, sin el diálogo estratégico que diferencia a un buen desarrollo de uno que simplemente cumple el contrato.
3. Los síntomas de una mala definición y sus costos reales
3.1 Los cambios de alcance: el síntoma más visible
El síntoma más evidente de una definición insuficiente es la proliferación de cambios de alcance durante el desarrollo. Cada vez que el cliente dice “necesitamos agregar esto que no estaba en el alcance original”, está pagando dos veces por algo que debería haberse definido desde el inicio: una vez en el tiempo y el costo del cambio durante el proyecto, y otra en la complejidad adicional que ese cambio introduce en la arquitectura del sistema.
Los cambios de alcance no son necesariamente malos: los proyectos más exitosos los gestionan con naturalidad. El problema es cuando los cambios no son ajustes menores sino correcciones a supuestos erróneos de base, o cuando surgen porque quien aprobó el proyecto no era quien realmente conocía los requerimientos del negocio. En esos casos, el cambio de alcance no es una evolución del proyecto sino una señal de que la definición original estaba equivocada.
3.2 El proyecto entregado que nadie usa
El costo más invisible y al mismo tiempo más alto de una mala definición es el de los sistemas que se entregan completos pero que los usuarios no adoptan o no utilizan como se esperaba. Según el análisis de UNIR (2024) sobre las causas de fracaso en proyectos de TI, una razón persistente es que se presta demasiada atención a la tecnología y muy poca a las necesidades y reacciones de los usuarios finales. Un sistema puede ser técnicamente impecable y aun así no resolver el problema para el que fue construido, simplemente porque las personas que deben usarlo no fueron consideradas en la etapa de definición.
Este costo es difícil de medir porque no aparece en el presupuesto del proyecto sino en la productividad perdida, en los procesos que siguen haciéndose manualmente en paralelo al sistema, y en la frustración del equipo que tuvo que usar algo que no se ajusta a su realidad. Es el tipo de fracaso que raramente genera un reclamo formal al proveedor, porque el sistema “técnicamente funciona”, pero que erosiona la confianza en las inversiones tecnológicas y hace más difícil justificar el siguiente proyecto.
4. Las condiciones para una buena definición
4.1 Partir del problema, no de la solución
El primer principio de una buena definición es resistir la tentación de llegar al proveedor con la solución ya resuelta. Esto requiere un ejercicio de distancia: antes de decidir qué tecnología se necesita, articular con claridad cuál es el problema de negocio que se quiere resolver, cuál es su impacto actual en los resultados, qué ocurriría si no se resuelve y cuál sería la señal concreta de que la solución funcionó. Estas preguntas no tienen respuesta técnica: las debe responder alguien con visión y autoridad de negocio.
Un buen proveedor tecnológico debería cuestionar la solución que se le presenta si tiene razones para pensar que no es la más adecuada para el problema real. Esta conversación, aunque puede generar incomodidad al inicio, es la que distingue a un proveedor que busca construir una relación de largo plazo de uno que simplemente ejecuta lo que se le pide. Si el proveedor nunca cuestiona nada, eso en sí mismo es una señal de alerta.
Un buen proveedor tecnológico debería cuestionar la solución que se le presenta si tiene razones para pensar que no es la más adecuada para el problema real. Esta conversación, aunque puede generar incomodidad al inicio, es la que distingue a un proveedor que busca construir una relación de largo plazo de uno que simplemente ejecuta lo que se le pide. Si el proveedor nunca cuestiona nada, eso en sí mismo es una señal de alerta.
4.2 Los interlocutores correctos en la mesa correcta
Una buena definición requiere la participación activa de al menos tres tipos de interlocutores: quien tiene la visión de negocio y puede articular el problema estratégico, quien conoce los procesos operativos en detalle y puede describir cómo funciona el trabajo en la práctica, y quien tiene la autoridad para tomar decisiones y aprobar compromisos. Cuando alguno de estos roles falta, la definición queda incompleta por alguno de sus flancos: estratégico, operacional o ejecutivo.
La participación del tomador de decisión no significa que deba dedicar semanas a reuniones de levantamiento de requerimientos. Significa que debe estar disponible para validar los supuestos de fondo, resolver las preguntas que no tienen respuesta en el nivel operativo, y alinear al equipo en torno a los objetivos que la solución debe alcanzar. Según el Project Management Institute, los proyectos que cuentan con patrocinadores ejecutivos activos tienen una tasa de éxito significativamente mayor que aquellos que carecen de ese respaldo.
4.3 Documentar los supuestos tanto como los requerimientos
Un aspecto frecuentemente descuidado en la definición de proyectos tecnológicos es la documentación explícita de los supuestos: aquellas condiciones que se dan por ciertas y sobre las cuales se basa la solución. Si el proyecto asume que el sistema actual de nómina tiene una API de integración, ese supuesto debe quedar escrito. Si asume que los usuarios tendrán conectividad a internet estable en sus puntos de trabajo, también. Si asume que el proceso actual continuará funcionando de la misma manera durante la implementación, igualmente.
Hacer explícitos los supuestos cumple dos funciones: primero, obliga a verificarlos antes de que el proyecto comience, evitando sorpresas costosas durante el desarrollo. Segundo, genera un registro que permite entender qué cambió cuando aparecen imprevistos durante la ejecución, distinguiendo entre cambios de alcance legítimos y consecuencias de supuestos que resultaron incorrectos.
5. El rol del proveedor en una buena definición
5.1 La consultoría previa al desarrollo no es un gasto, es una inversión
Muchas organizaciones, especialmente las de tamaño mediano, perciben la etapa de definición como un trámite previo al desarrollo que debería ser rápida y de bajo costo. Esta percepción es costosa: el tiempo que se ahorra en la definición se paga con intereses durante el desarrollo, en forma de cambios de alcance, replanificaciones y, en los peores casos, proyectos que deben rehacerse desde cero.
Un proveedor maduro de desarrollo de software debería proponer un proceso de definición estructurado como parte de su metodología, no como un extra opcional. Ese proceso incluye sesiones de trabajo con los interlocutores correctos, validación de los supuestos críticos, identificación de los riesgos de definición, y una propuesta técnica que conecte explícitamente las decisiones de arquitectura con los objetivos de negocio. El costo de esa etapa es siempre menor que el costo de corregir durante el desarrollo lo que no se definió correctamente al inicio.
5.2 Conocer el negocio del cliente como condición de calidad
La capacidad de un proveedor para hacer las preguntas correctas durante la etapa de definición depende directamente de cuánto conoce el negocio del cliente. Un proveedor que solo conoce tecnología puede ejecutar bien lo que se especifica, pero no puede aportar criterio sobre si lo que se especifica es lo correcto. Un proveedor que entiende el contexto del negocio —la industria, los procesos clave, las restricciones operacionales, los objetivos de mediano plazo— puede hacer exactamente esa contribución: cuestionar supuestos, proponer alternativas y anticipar consecuencias no previstas.
Esta dimensión consultiva del proveedor tecnológico es especialmente valiosa en la etapa de definición, donde las decisiones que se toman tienen el mayor impacto sobre el resultado final del proyecto. Según los estudios del Standish Group analizados por la UNIR, los errores que se cometen en las fases de estudios y análisis son el origen del 56% de los defectos que terminan afectando a los proyectos de software, frente al 7% que se origina en la escritura del código. Dicho de otra manera: la mayoría de los problemas de un proyecto de desarrollo no ocurren durante el desarrollo.
Conclusión
La calidad de un proyecto de desarrollo de software se decide mucho antes de que comience el desarrollo. Los problemas que emergen a mitad de un proyecto —los cambios de alcance, los sobrecostos, los plazos extendidos y los sistemas que nadie termina usando— tienen casi siempre su origen en una etapa de definición que no fue suficientemente rigurosa, que no contó con los interlocutores correctos, o que describió soluciones en lugar de problemas.
Invertir tiempo y atención en la definición no es un lujo ni una formalidad: es la condición más importante para que un proyecto tecnológico genere el valor que justificó su aprobación. Las organizaciones que lo entienden no solo obtienen mejores proyectos: construyen una relación de trabajo con sus proveedores basada en objetivos compartidos y no en la gestión de conflictos sobre el alcance.
¿Cómo puede Amsoft ayudarte en este camino?
En Amsoft incorporamos una etapa estructurada de definición como parte de nuestra metodología de trabajo. Antes de proponer una solución técnica, invertimos en entender el problema de negocio que el cliente necesita resolver: qué ocurre hoy, cuál es el impacto de ese problema, qué condiciones debe cumplir la solución para considerarse exitosa, y cuáles son los supuestos que deben verificarse antes de comenzar el desarrollo.
Nuestro equipo combina experiencia técnica con comprensión del contexto de negocio de nuestros clientes. Eso nos permite hacer las preguntas que un proveedor puramente técnico no haría, identificar cuando la solución propuesta no es la más adecuada para el problema real, y construir propuestas que conectan las decisiones de arquitectura con los objetivos que el cliente necesita alcanzar.
Contáctanos antes de tener un documento de requerimientos listo. La conversación más valiosa es la que ocurre cuando todavía hay tiempo de definir bien el problema.
Este artículo fue elaborado por Amparo Silva, miembro del equipo de Amsoft, comprometida con la innovación y la excelencia en el ámbito tecnológico.
Referencias
- Fluidwave. (2025, diciembre). Por qué fracasan los proyectos: 10 razones críticas y cómo evitarlas en 2025. https://fluidwave.com/es/blog/why-projects-fail
- Flowlu. (2025). Estadísticas de Gestión de Proyectos: Las 33 Estadísticas Más Importantes para 2025. https://www.flowlu.com/es/blog/project-management/estadisticas-de-gestion-de-proyectos/
- UNIR. (2024, noviembre). Qué problemas pueden surgir en la gestión de proyectos y cómo solucionarlos. https://www.unir.net/revista/ingenieria/problemas-gestion-proyectos-soluciones/
- Especialidades ELITEED. (2025, marzo). ¿Por qué fracasan los proyectos? Claves para una evaluación efectiva con software. https://especializacioneseliteed.com/por-que-fracasan-los-proyectos-claves-para-una-evaluacion-efectiva-con-software/
- ADEN Business School. (2025, febrero). Por qué fracasan las empresas que subestiman el PMI. https://www.aden.org/business-magazine/pmi-las-empresas-que-subestiman-el-project-management-fracasan-un-67-mas-en-sus-proyectos/
- Visure Solutions. (2025, mayo). ¿Qué es la gestión de requisitos? https://visuresolutions.com/es/alm-guide/requirements-management/