La brecha del dimensionamiento: por qué los proyectos B2B se desvían antes de la primera línea de código

Cuando un proyecto de tecnología corporativo enfrenta sobrecostos o retrasos críticos, la tentación habitual es atribuir la falla a la fase de implementación. Se señalan fricciones metodológicas en los sprints, rotación de perfiles especializados, dependencias técnicas imprevistas o dificultades de integración con infraestructuras heredadas. Sin embargo, un análisis riguroso del ciclo de vida de las soluciones revela un patrón constante: la mayor parte de las desviaciones operativas y financieras no nacen en el código, sino en la mesa de preventa donde se concibió y dimensionó la propuesta original.

El dimensionamiento de soluciones tecnológicas en entornos B2B representa el punto de contacto más delicado entre la expectativa comercial y la viabilidad técnica. En esta etapa preliminar, los equipos deben traducir requerimientos a menudo ambiguos en compromisos contractuales de alcance, tiempo y costo. Cuando esta transición carece de un marco metodológico estructurado, el resultado suele ser una estimación optimista que erosiona los márgenes y compromete la entrega.

—

1. La evidencia detrás de la desviación temprana

La brecha entre la estimación inicial y la realidad operativa está documentada de forma exhaustiva en la literatura de ingeniería y gestión empresarial. En una investigación de referencia desarrollada por McKinsey & Company en colaboración con el Centro BT para la Gestión de Grandes Programas de la Universidad de Oxford, se analizaron más de 5.400 proyectos de TI a escala global. El estudio concluyó que, en la muestra de grandes proyectos de TI analizada, el sobrecosto promedio fue de 45%, mientras que el valor entregado resultó ser en promedio un 56% inferior al proyectado inicialmente. Más crítico aún: un 17% de las iniciativas examinadas sufrieron desvíos de tal magnitud que llegaron a comprometer la estabilidad financiera de la organización contratante.

Estas cifras ponen de manifiesto que la incertidumbre en proyectos complejos no se resuelve con intuición individual. Cuando un equipo de preventa elabora una matriz de esfuerzo calculando días-hombre sobre la base de impresiones subjetivas del consultor de turno, introduce un margen de error acumulativo. La presión por presentar una oferta competitiva en plazos comerciales reducidos suele forzar recortes arbitrarios en las horas de arquitectura, pruebas o gestión de cambios, asumiendo escenarios ideales que rara vez se materializan en el terreno productivo.

—

2. Los tres sesgos críticos del dimensionamiento empírico

Para corregir la distorsión en la estimación de preventa, es indispensable identificar los mecanismos estructurales que generan el desajuste:

• Sesgo de comprensión superficial del requerimiento: En las fases iniciales de preventa, el cliente expresa necesidades en términos de negocio o dolores operativos ("requerimos automatizar la conciliación de datos entre sucursales"). Si el arquitecto de soluciones no descompone esa declaración en flujos funcionales, tipos de transacción y entidades de datos, la estimación tenderá a considerar únicamente el camino feliz, omitiendo reglas de excepción, validaciones complejas y casos límite.
• Falta de trazabilidad y memoria técnica: En muchas organizaciones de servicios y consultoría de TI, los dimensionamientos se realizan en hojas de cálculo aisladas que residen en computadores personales. No existe un registro auditable de los supuestos adoptados ni de la parametrización técnica utilizada. Cuando la oportunidad comercial se gana meses después, el equipo de entrega recibe una cifra global de horas sin el contexto arquitectónico que la fundamentó, obligándolo a renegociar el alcance o absorber sobrecostos ocultos.
• Presión de cierre vs. rigor técnico: El proceso de preventa convive con una tensión permanente entre la velocidad exigida por el ciclo de ventas y la exhaustividad que demanda la arquitectura de software. En ausencia de reglas estandarizadas de dimensionamiento, la negociación comercial tiende a ajustar el precio reduciendo el esfuerzo técnico estimado, sin recortar proporcionalmente las funcionalidades prometidas.

—

3. Del juicio intuitivo a la medición funcional estructurada


La respuesta de la ingeniería de software frente a la dispersión de las estimaciones ha sido el desarrollo de normas técnicas que independizan el tamaño funcional del esfuerzo humano. El estándar internacional ISO/IEC 20926:2009, ratificado por la Organización Internacional de Normalización y la Comisión Electrotécnica Internacional, define el método de Medición del Tamaño Funcional (FSM) promovido por el Grupo Internacional de Usuarios de Puntos de Función (IFPUG).

El principio central de esta norma es cuantificar el software desde la perspectiva del usuario, analizando dos componentes fundamentales:
1. Las funciones de datos: archivos lógicos internos y archivos de interfaz externa manipulados por la aplicación.
2. Las funciones transaccionales: entradas externas, salidas externas y consultas externas ejecutadas por los usuarios o sistemas adyacentes.

Al descomponer una solución en unidades de tamaño funcional estandarizadas, el dimensionamiento deja de ser una opinión subjetiva y se convierte en una métrica auditable. Dos arquitectos que apliquen la misma norma sobre un conjunto claro de requerimientos llegarán a magnitudes dimensionales comparables. Aunque el método IFPUG tradicionalmente requería especificaciones funcionales muy detalladas, su principio subyacente sigue siendo la referencia obligada: medir el alcance por su estructura observable y no por el tiempo que alguien cree que tardará en construirlo.

—

4. Prácticas aplicadas para cerrar la brecha en preventa


Para los líderes de preventa y arquitectos que enfrentan licitaciones y estructuraciones complejas en el mercado actual, la aplicación de estos conceptos no exige adoptar burocracias pesadas, sino establecer controles sistemáticos en el flujo de diseño:

• Establecer un descubrimiento funcional estandarizado: Antes de colocar cifras en una propuesta, es necesario formalizar una sesión de descubrimiento donde se mapeen entidades, integraciones y volúmenes de datos. La ambigüedad no resuelta en el descubrimiento debe registrarse formalmente como supuesto de alcance o riesgo de costo.
• Separar el dimensionamiento técnico del pricing comercial: El dimensionamiento debe reflejar con honestidad la complejidad técnica y el esfuerzo operativo real. El margen comercial, los descuentos estratégicos o las condiciones de financiamiento corresponden a la capa de pricing y estrategia de negocio. Mezclar ambos niveles distorsiona la métrica base y oculta la rentabilidad real de la cuenta.
• Auditar y versionar cada matriz de solución: Toda propuesta técnica debe acompañarse de su matriz de supuestos, niveles de servicio considerados y dependencias tecnológicas explícitas. Si el cliente modifica una condición de entrega o una interfaz externa durante la negociación, la matriz debe actualizarse y versionarse formalmente, asegurando que el equipo de operaciones reciba un modelo coherente con lo firmado.

—

5. Reflexión final: estructura como base de la confianza

En el desarrollo de negocios tecnológicos, la precisión en el dimensionamiento no es un ejercicio académico ni una limitación burocrática; es la garantía fundamental de sostenibilidad para el proveedor y de valor real para el cliente. Cuando una preventa se construye con rigor metodológico, supuestos documentados y trazabilidad técnica, la solución no solo gana credibilidad comercial, sino que asegura una entrega predecible. La profesionalización de la preventa comienza reconociendo que dimensionar con estructura es la decisión más rentable que puede tomar un equipo de tecnología.

Fuentes

• ISO/IEC 20926:2009 – Software and systems engineering — Software measurement — IFPUG functional size measurement method
• Delivering large-scale IT projects on time, on budget, and on value – McKinsey & Company

Imagen: ThisIsEngineering en Pexels.