Gestión de proyectos en Excel: cuándo alcanza y cuándo no

Excel (o Google Sheets) es una herramienta de cálculo que también puede listar trabajo. Eso basta en un conjunto chico de casos, y negarlo es snobismo de software:

• Un proyecto con un dueño que actualiza él mismo: freelance, internamente “Juan lleva el lanzamiento”.
• Listas cortas (menos de ~80 filas) sin dependencias fuertes entre sí.
• Un presupuesto simple: plan vs. real, unas categorías, un TOTAL.
• Una matriz RACI de una página, que se arma una vez y se consulta.
• Un informe puntual para alguien que solo abre Excel: el sponsor que quiere ver fechas en una grilla, no en un tablero.

En esos casos la hoja gana porque ya está abierta. El error no es usarla: es seguir usándola cuando el archivo se convirtió en el sistema operativo del equipo.

Casi todos los tutoriales de “gestión de proyectos excel” venden las mismas cuatro construcciones. Sirven distinto:

• Lista de tareas + fechas. Columnas: tarea, dueño, inicio, fin, estado, % . Es lo más honesto que puedes hacer en una hoja. El % a mano miente pronto; el estado (no iniciado / en curso / hecho) miente menos.
• Gantt con barras condicionales. Una fecha de inicio, una duración, y celdas que se pintan si caen en el rango. Se ve bien en una captura. No calcula holgura ni mueve solos los sucesores cuando una tarea se atrasa.
• Kanban en columnas. Cada columna es un estado; cada fila, una tarjeta. Funciona para ti solo. En Sheets, dos personas moviendo la misma fila es un choque; en un .xlsx enviado por correo, es un fantasma.
• RACI y presupuesto. Acá Excel es fuerte. Una grilla de letras y una hoja de SUMIF no necesitan un motor de flujo. El techo aparece cuando el RACI vive en un archivo distinto al de las tareas y nadie lo abre.

Puedes copiar cualquiera de esas grillas desde plantillas de gestión de proyectos. La plantilla no decide si Excel te alcanza: lo decide quién la toca y cada cuánto.

No esperes a que el archivo pese 12 MB. Estas señales bastan para cambiar de herramienta — o, al menos, para dejar de pretender que la hoja es el sistema:

No es que Excel “no sirva para proyectos”. Es que falla de formas predecibles cuando lo usas como si fuera un gestor:

1. Infierno de versiones. Adjunto de correo + OneDrive + “te lo mandé anoche”. Cada copia es una verdad. Sheets reduce esto, no lo elimina: pestañas duplicadas y filtros personales hacen el mismo daño.
2. Sin límites WIP. Una columna “En curso” acepta infinitas filas. El equipo empieza más de lo que termina. Un tablero con límite WIP te frena; una hoja no.
3. Sin historial de conversación útil. Los comentarios de celda no son un hilo de tarea. A los tres meses no sabes por qué la fecha del hito 3 saltó dos semanas.
4. Una persona como cuello de botella. María entiende el BUSCARV, el formato condicional y qué pestaña no hay que tocar. Si María está enferma, el sistema está enfermo.
5. Fórmulas que se rompen en silencio. Insertas una fila, el rango del SUM no la incluye, el semáforo sigue verde. Excel no te avisa que el modelo dejó de modelar.

Estos fallos se agravan cuando gestionas varios proyectos a la vez: un archivo por proyecto, o una mega-hoja con 12 pestañas, son dos maneras de perder el portafolio. Excel no tiene “capacidad compartida”; tiene celdas.

Un Gantt en Excel es un gráfico de barras apiladas o una franja de celdas pintadas. Muestra un plan. No es un motor de calendario. La diferencia se nota el día en que una tarea de 3 días se atrasa y deberías ver qué más se mueve.

La ruta crítica pide predecesoras, duraciones y recálculo. En Excel puedes simularlo con una columna de “sucesor” y algo de max() entre fechas. Lo haces una vez, con 12 tareas, y funciona. Con 60 tareas, dos caminos paralelos y un recurso compartido, el modelo se vuelve un segundo proyecto: mantener la hoja.

Si el valor del Gantt es “el cliente quiere ver barras”, genéralo para esa reunión y tira la copia. Si el valor es “saber qué no se puede atrasar”, no lo busques en formato condicional.

El kanban-en-sheets se ve así: columnas Por hacer / En curso / Hecho, o una sola lista con una columna Estado y un filtro. Para una persona, es un tablero pobre y suficiente. Para un equipo, faltan tres cosas que no son “vistas bonitas”:

• Un límite visible de trabajo en curso que impida arrastrar la fila 16.
• Un dueño claro por tarjeta sin pelearse por la misma celda.
• Un rastro de cuándo salió de “en curso”, no un color que alguien pintó a mano.

Puedes fingir el límite WIP con un CONTAR.SI en rojo cuando hay más de 3 filas en curso. Nadie lo respeta porque la hoja no bloquea el movimiento: solo se pone colorada, como el semáforo que aprendiste a ignorar. El método no vive en la herramienta, pero la herramienta puede hacer más fácil incumplirlo.

No migres “todo”. Migra lo que la hoja ya no sostiene:

1. Deja en Excel (o Sheets) presupuesto, RACI estático y exportaciones puntuales para quien solo abre hojas.
2. Mueve tareas, estados, comentarios y dueños a un tablero con un solo lugar de verdad. Una herramienta dedicada —de las herramientas gratis de gestión de proyectos, o una de pago— existe para eso, no para reemplazar tu SUMIF.
3. Congela el .xlsx viejo como archivo, no como sistema. Un “solo lectura” explícito evita que alguien siga cargando horas ahí dos meses después.

La prueba de que era momento: si esta semana perdiste más de media hora reconstruyendo “cuál es la última versión” o explicando una fórmula, ya no estás gestionando el proyecto — estás gestionando el archivo.

Cuando la hoja te quede chica, el siguiente paso es un gestor de proyectos, no un Excel más sofisticado. Un archivo con más pestañas no arregla versiones, WIP ni comentarios. Si quieres un tablero local-first (no una hoja disfrazada), Hito es esa categoría: proyectos y checklists en tu equipo, sin pretender ser Excel.