El patrón se repite con una regularidad que ya no me sorprende. Una organización decide profesionalizar la gestión de proyectos, evalúa herramientas durante semanas, elige Jira, paga las licencias y organiza una capacitación de dos horas. Tres meses después, la mitad del equipo volvió a la planilla compartida y las decisiones importantes se toman por WhatsApp.
La conclusión que suele sacarse es que Jira era demasiado complejo. Casi nunca es así. Lo que falló no fue la herramienta, fue la implementación, y la diferencia importa porque la segunda sí se puede gestionar.
Implementar una herramienta de gestión es un proyecto. Tiene alcance, stakeholders, resistencia al cambio y riesgos identificables. La mayoría de las organizaciones lo trata como una compra.
El síntoma que aparece primero
Antes de que nadie declare el fracaso, hay una señal temprana y muy fácil de detectar: empieza a existir una fuente de verdad paralela.
Alguien arma una planilla “solo para el seguimiento del cliente”. Otro mantiene su propia lista porque el tablero “está desactualizado”. El reporte mensual se prepara a mano en lugar de salir de la herramienta.
Cuando eso aparece, la herramienta ya perdió. No porque la gente sea reticente, sino porque la planilla les está resolviendo algo que el tablero no. Vale la pena averiguar qué es antes de insistir con la capacitación.
Definí qué pregunta tiene que responder el tablero
El error más común de configuración es empezar por la estructura: proyectos, épicas, tipos de issue, workflows. Es empezar por el final.
La pregunta previa es más aburrida y más útil: ¿qué necesita saber cada persona, y cada cuánto?
En la práctica, las audiencias suelen ser tres y quieren cosas distintas:
- El equipo necesita saber qué le toca hacer hoy y qué lo está bloqueando.
- El PM necesita ver desvíos antes de que sean irreversibles.
- La dirección necesita saber si el proyecto llega, cuánto cuesta y qué riesgos hay abiertos.
Si configurás Jira sin haber respondido esas tres preguntas, vas a terminar con un tablero que registra tareas pero no informa nada. Es exactamente el escenario donde alguien abre una planilla en paralelo para armar el reporte de dirección.
Esta parte no se resuelve dentro de la herramienta. Se resuelve en una conversación de una hora con las personas que van a mirar el tablero.
Empezá con el flujo mínimo, no con el ideal
Hay una tentación fuerte al configurar: modelar el proceso completo tal como debería ser. Estados intermedios, aprobaciones, campos obligatorios, automatizaciones.
El problema es que cada estado adicional es una decisión más que alguien tiene que tomar cada vez que toca una tarea. Y las decisiones cuestan.
Arrancá con tres o cuatro estados. Por hacer, en curso, en revisión, hecho. Suena insuficiente y lo es, deliberadamente. Agregá complejidad recién cuando el equipo la pida, porque en ese momento vas a tener dos cosas que hoy no tenés: la certeza de que el estado hace falta de verdad, y a alguien que lo va a defender.
Los campos obligatorios merecen mención aparte. Cada campo obligatorio que agregás es fricción en el momento exacto en que la persona quiere registrar algo rápido. Si un campo es obligatorio y nadie lo consulta después, es puro costo.
Alguien tiene que ser dueño de la herramienta
Esto se saltea siempre y es el que más caro sale.
Una herramienta de gestión se degrada sola. Se acumulan proyectos viejos sin archivar, tareas sin dueño, etiquetas creadas por seis personas distintas para la misma cosa, permisos que nadie revisó. A los seis meses, buscar algo es más lento que preguntar.
Tiene que haber una persona responsable de la configuración, los permisos y la limpieza periódica. No es automáticamente el PM del proyecto, y en equipos grandes conviene que no lo sea: el PM tiene incentivos de corto plazo (que su proyecto avance) que chocan con el mantenimiento de largo plazo.
Es un rol chico, unas pocas horas al mes, pero tiene que estar asignado a un nombre.
Migrá un proyecto, no todos
La migración simultánea de toda la cartera es la forma más eficiente de que la herramienta quede asociada al caos.
Elegí un proyecto piloto y elegilo con criterio. El mejor candidato no es el proyecto más importante ni el más grande: es uno con un equipo dispuesto, un plazo de al menos dos meses por delante y un líder que quiera que funcione. Vas a necesitar un caso de éxito interno más de lo que vas a necesitar cobertura.
Durante el piloto, lo que estás probando no es Jira. Es tu configuración. Vas a descubrir que hay estados que sobran, campos que faltan y reportes que no salen como esperabas. Mejor descubrirlo en un proyecto que en doce.
Medí adopción, no cumplimiento
Acá hay una distinción que cambia las decisiones que tomás después.
Cumplimiento es que la gente cargue las tareas. Es fácil de medir y es una métrica engañosa, porque se puede cumplir vaciando el contenido: tareas genéricas, actualizaciones masivas quince minutos antes de la reunión de estado.
Adopción es que la herramienta se use para decidir. Algunos indicadores que sí sirven:
- Qué proporción de las tareas se actualiza dentro de las 48 horas del cambio real, no el día de la reunión.
- Cuántas discusiones del proyecto quedaron registradas en el ticket en vez de perderse en un chat.
- Si alguien, en una reunión, abre el tablero para responder una pregunta en lugar de responder de memoria.
Ese último es el mejor termómetro que conozco. El día que alguien que no sos vos abre el tablero para resolver una discusión, la herramienta está adoptada.
Qué hacer cuando el equipo vuelve a Excel
Va a pasar, al menos parcialmente. La respuesta instintiva es prohibir la planilla. Casi nunca funciona y además desperdicia información valiosa.
La planilla sobrevive porque hace algo mejor. Suele ser una de tres cosas: una vista consolidada que en Jira requiere demasiados clics, un cálculo que la herramienta no hace de forma nativa, o simplemente velocidad de carga para alguien que trabaja con volumen.
Averiguá cuál de las tres es y decidí explícitamente. A veces se resuelve con un dashboard bien armado. A veces conviene aceptar que esa planilla se queda y definir cómo se sincroniza. Lo que no funciona es dejar el conflicto sin resolver y confiar en que se acomode.
Para llevar
- La configuración es la parte fácil. Si el proyecto de implementación no contempla gestión del cambio, un dueño asignado y un piloto acotado, la herramienta se abandona sin importar cuán bien configurada esté.
- Empezá por las preguntas, no por la estructura. Un tablero que no responde lo que la dirección pregunta genera una planilla paralela en menos de un trimestre.
- La adopción se mide por decisiones, no por tareas cargadas. El indicador real es si alguien abre el tablero para resolver una discusión.
Si estás por implementar una herramienta o ya tenés una que el equipo dejó de usar, el diagnóstico suele tardar menos de lo que uno espera: casi siempre el problema está en una de estas seis decisiones.
¿Estás implementando una herramienta de gestión o tenés una que el equipo dejó de usar? Escribime a [email protected] o por WhatsApp y lo vemos juntos.
Si todavía estás definiendo si Jira es la herramienta adecuada para tu contexto, empezá por Jira para gestión de proyectos: guía práctica. Si estás comparando opciones, leé ClickUp, Trello y Monday: cuál elegir, Notion vs ClickUp: cuál elegir para tu equipo y alternativas a Microsoft Project.
Cada dos semanas mando una edición con herramientas, criterios y casos reales de gestión de proyectos e IA aplicada. Suscribite gratis a PM & IA aplicada. También publico contenido en video en @ValeriaYashanPM.