Cómo Presentar un Proyecto de Software a la Junta Directiva

Un proyecto de software se aprueba o se cae en los primeros tres minutos de la presentación, y casi nunca por razones técnicas. Se cae porque el comité no logra ubicar la inversión frente a una alternativa concreta ni frente al costo de no hacer nada. La arquitectura, el framework y el cronograma importan mucho en la ejecución y casi nada en la aprobación.

Esta guía ordena el caso de negocio en seis pasos, en el orden en que un comité directivo procesa la información: primero el problema en cifras, después la alternativa, después el dinero, y solo al final el cómo.

1. Abre con el costo de no hacer nada

La primera lámina no es tu propuesta: es lo que la empresa está pagando hoy por seguir igual. Ese número existe siempre, aunque nadie lo haya sumado. Se compone de horas de personas haciendo trabajo manual, licencias de sistemas que se solapan, errores que se corrigen a mano, clientes que se pierden por tiempos de respuesta y decisiones que se toman sin datos.

Ponlo en dinero anual. Si veinte personas dedican una hora diaria a conciliar información entre dos sistemas, eso son unas 4,800 horas al año — un costo perfectamente calculable con el valor hora cargado de esa nómina. Un comité que ve primero ese número evalúa tu propuesta contra una referencia; uno que ve primero tu presupuesto la evalúa contra cero.

2. Define el problema con una métrica, no con un adjetivo

"El sistema actual es lento y obsoleto" no es un problema de negocio: es una opinión técnica. "El cierre contable toma once días hábiles y el sector opera en cuatro" sí lo es, porque tiene una unidad, una línea base y un objetivo.

Elige una métrica principal y a lo sumo dos de apoyo. Las que mejor funcionan ante un comité son las que tocan caja o riesgo: días de cierre, costo por transacción procesada, tasa de error, tiempo de respuesta al cliente, horas-persona por mes, exposición ante una sanción regulatoria. Si no logras escribir el problema como una métrica con línea base, todavía no está listo para ir a comité.

3. Presenta el TCO, no la cotización

Este es el paso donde se rompe la credibilidad de más proyectos. La cotización de un proveedor cubre la construcción; el comité aprueba una salida de caja que además incluye mantenimiento, infraestructura, servicios de terceros y adopción interna. La cifra de construcción suele ser entre el 40% y el 60% del total a cinco años.

Lleva la tabla completa: construcción, mantenimiento anual (10%–15% para un sitio corporativo, 15%–20% para una aplicación de negocio, 20%–25% para una app móvil, 25%–35% para una plataforma crítica), infraestructura y terceros, y el tiempo de tu propia gente. El método completo está en costo total de propiedad del software.

Un comité perdona un número grande. No perdona un número que crece después de aprobado.

4. Muestra tres escenarios, no uno

Presentar una sola opción convierte la reunión en un sí o un no. Presentar tres la convierte en una decisión, que es lo que un comité directivo sabe hacer:

Escenario	Alcance	Inversión	Qué resuelve
Mínimo	Solo el proceso crítico	$	Detiene la pérdida principal
Recomendado	Proceso crítico + integraciones	$$	Resuelve el problema y habilita lo siguiente
Ampliado	Plataforma completa	$$$	Resuelve y se adelanta a 24 meses

Marca cuál recomiendas y por qué. La recomendación no debilita la presentación: la enfoca. Y el escenario mínimo es tu red de seguridad — si el presupuesto está apretado, sales con algo aprobado en vez de con nada.

5. Pon el retorno en el horizonte correcto

El retorno de un proyecto de software rara vez llega en el año fiscal en curso, y prometerlo ahí es la forma más rápida de perder credibilidad en el año dos.

Sé explícito con la curva: en qué mes entra en producción, en qué mes empiezan los beneficios, en qué mes se cruza el punto de equilibrio. Para un proyecto de automatización interna el retorno suele empezar entre el mes 4 y el 8 después de la salida a producción; para un producto digital orientado a ingresos, más tarde y con más incertidumbre. El método de cálculo aplicado a un caso concreto está en cómo calcular el ROI de una app móvil.

Si el retorno depende de supuestos —que el 40% de los clientes migre al canal propio, que el equipo de operaciones reduzca dos horas diarias—, escríbelos como supuestos. Un comité acepta supuestos declarados; detecta y castiga los supuestos disfrazados de proyección.

6. Cierra con riesgos y con lo que pides exactamente

Una presentación sin riesgos no parece segura: parece incompleta. Nombra los tres principales con su mitigación concreta —dependencia del proveedor, adopción interna, integración con el sistema heredado— y cómo se controla cada uno.

Y termina con la petición exacta: monto, plazo de decisión y qué desbloquea. "Solicitamos aprobación de $85,000 USD para la fase 1, con decisión antes del 15 de octubre para arrancar en noviembre y salir a producción en el primer trimestre." Una presentación que termina en "quedo atento a comentarios" no tiene cierre y suele volver a agenda dos veces más.

Los cinco errores que más aprobaciones cuestan

• Empezar por la tecnología. El framework, la nube y la arquitectura son respuestas a preguntas que el comité aún no hizo.
• Un solo escenario. Convierte una decisión en un ultimátum.
• Retorno prometido dentro del año fiscal. Casi nunca ocurre y quema la credibilidad para el siguiente proyecto.
• Omitir el mantenimiento. Es la partida que reaparece en el año 2 y hace ver el caso original como incompleto.
• No cuantificar el statu quo. Sin él, cualquier inversión compite contra cero, y cero siempre gana.

Preguntas frecuentes

¿Cuánto debe durar la presentación de un proyecto de software a un comité? Entre diez y quince minutos de exposición, con el caso completo en un documento de una a dos páginas como anexo. La decisión se toma sobre la conversación posterior, no sobre las láminas.

¿Qué cifras pide siempre un comité directivo? Inversión total a cinco años, salida de caja por año, mes de punto de equilibrio, costo de no hacer nada y los tres riesgos principales con su mitigación. Si llevas esas cinco, tienes la conversación cubierta.

¿Conviene llevar al proveedor a la presentación? No a la de aprobación. El caso de negocio lo defiende quien responde por el resultado dentro de la empresa. Al proveedor conviene tenerlo para la sesión técnica posterior, cuando ya hay presupuesto y las preguntas son de ejecución.

¿Cómo justifico un proyecto cuyo beneficio no es monetario? Traduciéndolo a riesgo evitado. Cumplimiento normativo, continuidad operativa y seguridad se presentan como exposición: cuánto costaría la sanción, la caída o la fuga de datos, y con qué probabilidad. Es el mismo ejercicio que ordena la inversión en seguridad cibernética para PYMEs.

¿Qué hago si el comité pide recortar el presupuesto a la mitad? Ofreces el escenario mínimo que ya llevabas preparado, con su alcance real y lo que deja sin resolver. Lo que no conviene es aceptar el mismo alcance con la mitad del presupuesto: eso no reduce el costo, lo traslada al año siguiente en forma de deuda técnica y retrabajo.

Lleva el caso completo, no solo la cotización

La diferencia entre un proyecto aprobado y uno aplazado casi nunca está en la calidad técnica de la propuesta, sino en si el comité pudo verla como una decisión de negocio con números completos. En BigBoc entregamos propuestas pensadas para esa conversación: alcance, supuestos explícitos, rango de mantenimiento anual y estimación de infraestructura, para empresas de Colombia y Latinoamérica en React, Next.js, Node.js e inteligencia artificial.

¿Tienes que defender un proyecto y necesitas las cifras completas? Solicita tu cotización gratuita en bigboc.com/cotizacion y recibe una propuesta con alcance, tiempos y costos en menos de 24 horas. ¿Prefieres discutir el caso antes? Escríbenos por el formulario de contacto.