Firmaste el contrato para un nuevo proyecto y empiezas a trabajar.

Y aquí es donde la mayoría comete el error de abrir Power BI el lunes por la mañana y ponerse a conectar lo primero que le compartieron.

Hay una asimetría que conviene entender bien: casi todo lo que sale mal en un proyecto de datos tiene su origen en una decisión que no se tomó en la primera semana. Los accesos que llegaron tarde. El responsable que nunca se designó. La métrica que cada área entendía distinto. El canal de comunicación que terminó siendo un grupo con once personas.

Nada de eso explota en la semana uno. Explota en la semana cuatro, cuando ya no hay margen para corregirlo sin costo.

La buena noticia es que blindar un proyecto es barato. Media jornada bien invertida. Y es la única etapa en la que todavía puedes poner condiciones sin que suene a queja.

Esta es la primera decisión y la más subestimada. Como mínimo necesitas cinco perfiles, aunque algunos entren solo unos minutos:

El patrocinador, que es quien firmó y quien quiere el resultado. Aunque solo esté quince minutos, su presencia legitima el proyecto frente a todos los demás.

El responsable directo, la persona con la que vas a trabajar todos los días y que puede tomar decisiones sobre el contenido.

Quien conoce los datos, que casi nunca es el mismo que el anterior. Suele ser operativo o el contador que arma los reportes hoy a mano.

Alguien de sistemas, si existe. Si no lo invitas al inicio, lo vas a necesitar en el peor momento posible.

Un representante del usuario final, si es distinto del patrocinador. Es el perfil que más se olvida y el que determina si el tablero se usará.

Si el cliente propone hacerlo solo con una persona, acéptalo, pero pide los nombres de los demás y agenda conversaciones cortas por separado en los primeros días.

Antes de hablar de datos, la pregunta es esta: “si dentro de tres meses este proyecto fue un éxito, ¿qué está pasando en la empresa que hoy no pasa? Y si pudieras ponerle un número, ¿cuál sería?”.

La respuesta debe caber en una frase, ser observable y tener un número. Por ejemplo: el cierre financiero pasa de doce a un día hábil. U otro ejemplo como: los doce gerentes de sucursal abren su tablero al menos una vez por semana.

Definiciones como “tener mejor visibilidad” o “modernizar los reportes” suenan bien y no sirven, porque no se pueden evaluar. Y lo que no se puede evaluar no se puede declarar exitoso.

Escribe esa frase en el acta de arranque y ponla en el encabezado de todos tus reportes de avance. Es tu ancla cuando alguien quiera agregar algo que no contribuye a ella.

Aquí está la causa número uno de atrasos en proyectos de datos, y es completamente prevenible.

No preguntes “¿me pueden dar los accesos?”. Construye la tabla en vivo durante la reunión y sal con ella llena:

Tres reglas sobre esta tabla. Cada acceso tiene nombre y apellido: “TI” no es un responsable, “Jorge de TI” sí lo es. Cada acceso tiene fecha, y esa fecha se conecta con la cláusula de tu contrato que dice que los plazos corren desde que los accesos están disponibles. Y el estado se revisa en cada reporte de avance, porque un acceso pendiente es un riesgo activo.

Una jugada que funciona muy bien: manda la lista de accesos antes de la reunión, no después. El cliente llega con la mitad resuelta y la reunión se convierte en una revisión en vez de una solicitud. Ese detalle suele adelantar el proyecto una semana completa.

Este acuerdo evita el 80% de la fricción cotidiana. Se propone, no se pregunta:

•    Un solo canal para el proyecto. Lo que llegue por otro lado se traslada ahí.

•    Un solo punto de contacto. Las solicitudes de otras áreas pasan por esa persona. Sin esto terminas con cuatro personas pidiéndote cosas contradictorias.

•    Cadencia fija: una reunión semanal de veinte o treinta minutos, mismo día y misma hora, aunque no haya nada urgente. Es más eficiente que diez interrupciones.

•    Tiempos de respuesta de ambos lados. Tú respondes en menos de 24 horas hábiles; el cliente también. Este acuerdo tiene que ser explícitamente bidireccional.

•    Horario de trabajo declarado. Si no lo dices al inicio, el mensaje del domingo se vuelve norma.

•    Cómo se piden los cambios. Menciona con naturalidad que cualquier cosa fuera de lo acordado se cotiza en una orden de cambio. Decirlo cuando nadie está pidiendo nada es fácil; decirlo cuando ya te lo pidieron suena defensivo.

 

Los cronogramas detallados impresionan y nadie los abre. Para proyectos de este tamaño funciona mejor un plan de una página con cuatro columnas:

 

La tercera columna es la que casi nadie incluye y la más importante. Hace visible que el proyecto es un trabajo conjunto, y prepara el terreno para cuando haya que decir, sin conflicto, que el atraso vino de su lado.

La cuarta columna es la que sostiene la confianza: el cliente sabe que cada semana va a ver algo concreto, no solo recibir un correo que diga “vamos avanzando”.

Al terminar la reunión, envía un documento de una página con: objetivo y definición de éxito, alcance resumido, exclusiones, roles y responsables, calendario con hitos, tabla de accesos, reglas de trabajo y riesgos identificados. Pide confirmación por escrito.

Es la misma lógica que aplica en toda la relación comercial: quien documenta, controla.

•    Reunión de arranque realizada con las personas correctas

•    Acta enviada y confirmada por escrito

•    Definición de éxito escrita, medible y aceptada

•    Tabla de accesos con responsable y fecha por línea

•    Al menos un acceso real probado, no solo prometido

•    Muestra real de datos recibida y abierta

•    Canal de comunicación acordado

•    Reunión semanal agendada como recurrente en ambos calendarios

•    Espacios de trabajo creados, separando desarrollo de producción

•    Anticipo cobrado

•    Primeros tres riesgos identificados y comunicados

 

Ese último punto merece una nota, porque parece contraintuitivo. Nombrar riesgos en la semana uno se siente como anticipar problemas. Hace exactamente lo contrario: un proveedor que dice “el riesgo principal es que el catálogo de productos tiene duplicados y eso puede afectar el cálculo de margen” proyecta control, no inseguridad. Y cuando el riesgo se materializa, ya estaba nombrado y no sorprende a nadie.

Un proyecto técnicamente impecable con comunicación errática se percibe como un mal proyecto. Uno técnicamente correcto con comunicación excelente se percibe como excepcional. No es justo, pero es cómo funciona la percepción de servicio.

Y hay algo más de fondo. Un arranque documentado, un reporte semanal puntual y una tabla de accesos con fechas no requieren habilidad técnica extraordinaria. Requieren método. Pero desde afuera, el método se percibe como experiencia y como seriedad.

Esa percepción es, al final, lo que hace que un cliente te recomiende, te vuelva a contratar y deje de discutir tu precio.

¿Quieres convertirte en freelancer o consultor con Power BI?

Accede a nuestro programa de www.datdata.com/freelancer

Ver esta publicación en Instagram

Una publicación compartida por datdata | Power BI (@datdata)