Preparar un briefing para proyecto de datos

Hemos visto proyectos de datos que empiezan con un briefing de 40 páginas y proyectos que empiezan con un correo de dos líneas. Ninguno de los dos extremos funciona. El primero tarda tanto en redactarse que cuando termina el contexto ya ha cambiado. El segundo obliga a abrir una cadena de reuniones, aclaraciones y supuestos que retrasa el arranque antes de haber tocado un solo dato.

Un briefing útil no es un documento técnico ni un pliego cerrado. Es una forma de explicar el problema de negocio, el contexto operativo y las restricciones mínimas para que un equipo pueda proponerte el formato correcto: discovery, piloto o proyecto de producción. Si el briefing está bien hecho, acelera. Si está mal, encarece, confunde y te hace comparar propuestas que no parten del mismo problema.

¿Qué debe contener un briefing eficaz?

Después de revisar muchos briefings buenos, mediocres y claramente problemáticos, hay un patrón sencillo: los útiles no intentan responderlo todo. Solo dejan claro lo necesario para que la siguiente conversación sea concreta.

1. 1El problema de negocio, no la solución técnica. «Perdemos dos días cada semana consolidando datos» es un buen punto de partida. «Queremos montar un data lake con X herramienta» no lo es.
2. 2Quién sufre hoy el problema y cómo lo gestiona. Qué perfiles están implicados, qué hacen a mano y qué fricción genera.
3. 3Qué sistemas o fuentes intervienen. No hace falta un inventario perfecto, pero sí una foto razonable del ecosistema.
4. 4Qué decisión quieres mejorar. Sin esta parte, el proyecto se convierte en actividad técnica sin impacto claro.
5. 5Quién puede desbloquear y validar. Un proyecto sin owner interno se ralentiza desde el principio.
6. 6Qué restricciones ya conoces. Plazos, presupuesto orientativo, requisitos de seguridad, dependencia de terceros, ventanas de implantación.
7. 7Cómo sabrás si ha merecido la pena. No hace falta una tesis, pero sí una referencia concreta para juzgar el resultado.

Briefing mínimo viable

Si hoy mismo tuvieras que enviar un briefing y no sabes por dónde empezar, no hace falta un documento largo. Hace falta un briefing mínimo viable que permita a la otra parte entender si está ante un problema de reporting, automatización, IA, calidad de datos o simplemente de definición interna.

Con esa base ya se puede abrir una conversación útil. No perfecta, útil. El briefing no tiene que sustituir un diagnóstico; tiene que hacer posible ese diagnóstico sin empezar desde cero.

Qué sobra en un briefing (y retrasa el proyecto)

Hay contenido que parece demostrar madurez, pero que en la práctica solo mete ruido o condiciona mal el análisis.

• Prescribir tecnología demasiado pronto. Si el briefing ya viene con stack, arquitectura y herramientas cerradas, corres el riesgo de resolver mal el problema correcto.
• Incluir todo lo que existe en la empresa. Un briefing no es un inventario completo ni un mapa corporativo exhaustivo.
• Mezclar deseos de futuro con necesidades inmediatas. «Ya que hacemos esto, también podríamos…» es el origen de muchas propuestas infladas.
• Ocultar restricciones por miedo a encarecer la propuesta. En realidad ocurre lo contrario: salen más tarde y encarecen más.
• Pedir precisión total sobre cosas que aún nadie puede saber. Si no conoces la calidad exacta del dato o el nivel de acceso a un sistema, dilo.

Red flags del sponsor o del cliente antes de pedir propuesta

Hay señales que conviene detectar antes de pedir presupuesto porque suelen anticipar semanas de desgaste.

• No existe un sponsor que asuma prioridad, criterio y validación.
• El problema cambia según quién lo explique en cada reunión.
• Se pide propuesta cerrada sin saber todavía qué datos hay ni qué decisión se quiere mejorar.
• La organización busca que el proveedor piense por completo el proyecto, pero no reserva tiempo interno para responder y validar.
• Se espera que el briefing resuelva conflictos entre áreas que aún no se han hablado internamente.

Si además todavía no tienes claro el formato de colaboración, ayuda mucho revisar antes cómo elegir un partner de datos e IA, porque muchas fricciones no están en el documento sino en expectativas mal alineadas sobre método, alcance y responsabilidades.

Cómo evitar que el briefing se convierta en un bloqueo

El problema más frecuente no es un mal briefing: es un briefing que nunca se termina. La búsqueda del documento perfecto bloquea decisiones que podrían haberse tomado con un 70% de claridad y una buena conversación posterior.

1. 1Pon una fecha de cierre corta para el primer borrador. Una semana suele ser más que suficiente para tener una base decente.
2. 2Acepta escribir «no lo sabemos todavía» cuando sea verdad. Es mejor que rellenar huecos con suposiciones débiles.
3. 3Pide feedback temprano. Las preguntas que genera el borrador son más valiosas que seguir afinándolo a solas.
4. 4No metas a veinte personas a editar el documento. Cuantas más manos intervienen sin owner claro, más ambiguo se vuelve.
5. 5Usa el briefing para abrir la siguiente fase, no para cerrarla toda.

Ejemplo anonimizado: de un problema difuso a un briefing que sí permite presupuestar

Una empresa industrial quería «usar IA para mejorar operaciones». Ese era literalmente el punto de partida. Cuando se rascaba un poco, aparecían tres problemas distintos: reporting lento, planificación reactiva e incidencias mal documentadas. Con ese nivel de indefinición era imposible pedir una propuesta comparable.

Lo que desbloqueó la situación no fue añadir más páginas, sino concretar cuatro cosas: qué equipo sufría más el problema, qué decisión se estaba tomando tarde, qué sistemas contenían la información relevante y quién iba a validar. El briefing final quedó reducido a un problema principal, dos fuentes de datos, un owner operativo y un criterio claro para juzgar si convenía discovery, piloto o ejecución.

Qué pasa después del briefing

El briefing no es el final de la definición. Es el principio de una conversación mejor. A partir de ahí, lo habitual es pasar a una fase corta de diagnóstico o discovery donde se validan fuentes, calidad de datos, restricciones técnicas y secuencia de trabajo.

Cuando esa conversación se hace bien, es mucho más fácil decidir si lo siguiente es un discovery, un piloto de IA o una ejecución directa. En nuestro caso, ese paso está más cerca de una consultoría estratégica que de una reunión comercial genérica.

Y cuando ya tienes el problema razonablemente acotado, también tiene sentido comparar formatos y rangos en nuestra página de precios orientativos de consultoría de datos e IA, para no convertir el presupuesto en la primera conversación sobre el proyecto.

Quién debería revisar el briefing antes de enviarlo

No hace falta montar un comité. Pero sí conviene que el briefing pase, como mínimo, por tres miradas distintas antes de salir: negocio, operación y sistemas. Esa revisión rápida evita dos problemas muy comunes: que el documento esté bien redactado pero mal aterrizado, o que describa un problema real sin aclarar dónde están los datos ni quién podrá validarlo.

• Sponsor de negocio: confirma que el problema y la prioridad están bien formulados.
• Responsable operativo: valida que el proceso actual está descrito de forma creíble y que no faltan excepciones importantes.
• Perfil técnico o funcional cercano a los sistemas: ayuda a no prometer accesos, integraciones o calidad de datos que todavía no existen.

Si no puedes reunir esas tres perspectivas, no pasa nada. Lo importante es dejar claras las suposiciones y las zonas grises. Un briefing honesto con dudas explícitas es mucho más útil que uno aparentemente completo que da por hecho cosas que luego no se sostienen.

Plantilla rápida para salir hoy con un briefing usable

1. 1Problema principal: qué está pasando hoy y por qué importa.
2. 2Equipo afectado: quién dedica tiempo, revisa o sufre el cuello de botella.
3. 3Proceso actual: cómo se hace ahora y qué parte es manual o frágil.
4. 4Sistemas y datos: de dónde sale la información y qué dudas hay sobre acceso o calidad.
5. 5Decisión a mejorar: qué quieres decidir antes, mejor o con menos fricción.
6. 6Owner interno: quién valida, prioriza y desbloquea.
7. 7Restricciones: plazo, seguridad, dependencia de terceros, ventanas de implantación, presupuesto orientativo.
8. 8Siguiente paso deseado: discovery, piloto, propuesta o proyecto.

Para más contexto, puedes consultar la informe de McKinsey sobre empresas data-driven.