Un comercial cierra un proyecto. La fecha de arranque queda fijada en el contrato antes de que nadie compruebe si hay equipo disponible. Delivery se entera el mismo día que el cliente. El argumento que sostiene esto es siempre el mismo: la disponibilidad no importa, se lanza el primer hito de facturación y la ejecución se resuelve después. La pregunta de rigor en ese momento es simple: ¿qué ocurre cuando facturar y poder ejecutar dejan de ser la misma decisión? Ocurre que Delivery hereda un compromiso que no ha firmado, y el coste de esa desconexión lo paga siempre quien ejecuta, nunca quien vende.
Cómo evitar facturar proyectos sin capacidad de ejecución
Este caso, que he visto varias veces a lo largo de mi carrera, siempre he encuentrado dos señales que se repiten. El contrato se firma con fecha de inicio ya fijada, antes de consultar disponibilidad real. Y no existe ningún checkpoint formal entre el cierre comercial y el arranque del proyecto — el paso de una fase a otra es automático.
En el equipo, las señales son igual de claras. Delivery se entera de la fecha de arranque el mismo día que el cliente, sin margen de reacción. Y los recursos que se asignan al nuevo proyecto están, en la práctica, comprometidos en otros proyectos activos — nadie ha liberado capacidad ni se ha comprobado la disponibilidad.
En el negocio, el patrón termina de cerrarse. El primer hito de facturación se dispara con el kickoff con el cliente. Y cuando llega el segundo hito, el retraso ya es visible para el cliente — ya no es un problema interno, se ha convertido en un problema de credibilidad.
La mecánica de fondo no es un fallo de comunicación, es un fallo de incentivos. A quien vende se le mide por cerrar y facturar, no por lo que pasa después del cierre. Delivery no tiene autoridad de veto sobre una fecha que otro ha comprometido en su nombre. Y la frase que resuelve esa tensión por parte de la Dirección — la disponibilidad no importa, ya lo vas haciendo como puedas — no es un comentario aislado: es la política no escrita que sustituye al procedimiento que debería existir y no existe.
El impacto en negocio se mueve en tres palancas.
- Reasignar recursos sin plan retrasa proyectos que ya estaban en marcha, y ese retraso rara vez se documenta como coste del nuevo cierre.
- La confianza del cliente se erosiona cuando el segundo hito llega tarde — el problema deja de ser interno en el momento en que él lo nota.
- Y el equipo entra en modo bombero de forma recurrente, lo que degrada la calidad de entrega en todos los proyectos a la vez, no solo en el nuevo.
Hay tres umbrales que marcan cuándo esto deja de ser tolerable y permisible.
- Si el contrato fija fecha de arranque sin confirmación explícita de Delivery, el contrato se para antes de firmar.
- Si el primer hito de facturación se dispara sin que el equipo esté asignado y confirmado, se escala a Delivery Manager antes de facturar, no después.
- Y si reasignar recursos implica retrasar un proyecto activo, ese retraso se documenta y se comunica antes de aceptar el nuevo compromiso, no cuando ya ha ocurrido.
El método de intervención que puedes seguir es rápido con este contexto.
- Puedes parar la facturación del primer hito hasta confirmar el equipo.
- Puedes facturar igualmente y aceptar el retraso documentado en otros proyectos.
- Renegociar las fechas con el cliente antes de arrancar.
Yo recomendaría para la facturación, aunque siendo consciente que esta posibilidad no siempre es posible, por lo que, lo más aceptable es renegociar las fechas con el cliente y así te evitas de problemas futuros. Eso si, documenta toda la problemática que encuentras para ocasiones futuras.
Piensa que hoy aceptas que el equipo comercial comprometa fechas sin consultar capacidad, porque cerrar rápido parece más rentable que parar a comprobar. Lo que cortas hoy es facturar el primer hito sin que Delivery haya confirmado el equipo. El coste real de no actuar no es un proyecto retrasado — es que cada cierre nuevo se convierte en una apuesta sobre la espalda de tu equipo, y tarde o temprano alguien deja de aguantarla.
Te propongo para esta semana:
- Define que es Delivery quién firma la disponibilidad del equipo antes de facturar el primer hito.
- Exige que toda oferta con fecha de inicio incluya confirmación de disponibilidad real, no estimada.
- Pregúntate: la próxima vez que llegue un cierre con fecha ya fijada, ¿tienes autoridad para pararlo, o solo para ejecutarlo?