Firmo una oferta y, dos semanas después, alguien de mi equipo le pregunta al cliente qué es exactamente lo que hemos vendido. Esta escena ocurre más de lo que nos gustaría admitir. La oferta se ha cerrado con cuidado — condiciones negociadas línea a línea, alcance discutido durante semanas — y ese cuidado desaparece en el instante en que el cliente firma. Nadie deja la documentación en su sitio ni se comparte con quien tiene que leerla antes de la primera reunión de ejecución. El coste no es solo el tiempo perdido reconstruyendo lo que ya estaba escrito: es que el cliente empieza el proyecto sospechando que su proveedor no controla lo que promete.
La pregunta que me hago no es si esto va a repetirse otra vez. Sé que sí. La pregunta es quién, en la organización, tiene autoridad real para impedir que un proyecto arranque sin que todo el equipo tenga el alcance claro. En la mayoría de las pymes de servicios IT, la respuesta es nadie.
Kickoff: cómo evitar errores de alcance en proyectos IT
Un kickoff arranca sin que se haya verificado el alcance porque no existe una persona con autoridad formal para pararlo. Y lo que no tiene dueño no se hace.
Cómo lo reconozco
Si no se sigue el procedimiento apropiado por parte de todos los comerciales, localizar la oferta firmada de un proyecto depende de a quién le preguntes. No está en el mismo directorio ni con el mismo nombre según quién lo haya subido. Con este contexto, el responsable de proyecto se entera del alcance real en la misma llamada en la que el cliente lo menciona, no antes.
Es habitual en este contexto que más de una persona del equipo acabe preguntando al cliente los mismos datos en la misma semana, porque nadie centralizó la respuesta la primera vez. Y nadie confirma por escrito que delivery ha leído el alcance antes de fijar fecha con el cliente.
Hay otras dos señales que ya no son internas, sino que llegan al cliente directamente: te corrige sobre lo que ha comprado, en vez de al revés. Y en fase de ejecución se repiten, sin facturar, horas de trabajo que el cliente ya pagó durante la venta.
Por qué pasa
No es que a nadie le importe todo este esfuerzo. Es que no existe una puerta entre el cierre comercial y el arranque de delivery: un punto del proceso donde alguien tenga que decir sí o no antes de que el trabajo empiece. La autoridad para exigir esa comprobación no aparece sola por tener el título de PM. En cualquier marco serio de gestión de proyectos, esa autoridad nace de un documento — el que constituye el proyecto y designa a quien puede tomar esas decisiones —, no del cargo. Si nadie ha puesto ese mandato por escrito, el PM no tiene autoridad para frenar nada, por mucha experiencia que tenga. Y sin mandato explícito, cada uno interpreta que frenar un kickoff no es su trabajo.
Esto impacta en la organización porque cada hora que el equipo dedica a reconstruir lo que ya estaba en la oferta es tiempo que no se factura y que sí se paga en nómina. Cada vez que el cliente tiene que explicarte tu propio trabajo, se lleva una imagen de desorden que, por muy bien que lo hagas después, no borra del todo. Y esa imagen pesa en la siguiente negociación: renovar o ampliar con un proveedor que no controlaba lo vendido cuesta más esfuerzo comercial, no menos.
El problema se hace evidente cuando:
- Más de una persona del equipo pregunta al cliente lo mismo en la misma semana.
- El PM no puede confirmar en menos de cinco minutos dónde está la documentación de una oferta firmada.
- Ha pasado más de una vez en el último trimestre.
- El cliente ha comentado, aunque sea de pasada, que el equipo de trabajo no tiene claro qué se ha acordado.
Todo esto se puede prevenir.
- Haciendo un chequeo manual del PM como puerta de entrada al kickoff, con un checklist mínimo de tres campos — alcance, condiciones, contacto del cliente —, rápido de implantar, pero dependiente de disciplina humana.
- Haciendo un kickoff interno formal antes del kickoff con el cliente, con más peso de coordinación y mayor coste de tiempo, útil cuando el equipo ya es grande o hay varios proyectos en paralelo.
- Automatizando la verificación de carpetas y nomenclatura, fiable a medio plazo, pero exige normalizar antes las convenciones de nombre: no sirve como primer paso.
En un primer paso, te recomiendo que empieces por el chequeo manual, ya cuando todo se estandarice, podrás automatizarlo, pero inicialmente vamos a lo seguro. Eso sí, deberías nombrar por escrito quién tiene autoridad para frenar un kickoff: PM o sponsor, según el Project Charter de cada proyecto.
Para simplificar todo este escenario, te propongo que fijes una convención de nombres de archivos y ubicación única para todas las ofertas firmadas, sin excepciones. Exige también confirmación por escrito de que delivery ha leído el alcance antes de que se fije la fecha con el cliente.
Te propongo que esta semana hagas lo siguiente:
- Define por escrito quién tiene autoridad para frenar un kickoff: PM o sponsor.
- Crea la carpeta única y el nombre de archivo estándar para toda oferta firmada.
- El PM revisa esa carpeta antes de fijar fecha de kickoff con el cliente.
¿Cuánto tiempo más vas a dejar que sea el cliente quien te avise de que tu propio equipo no sabe qué le vendiste?