Nivelación de recursos en diagramas de Gantt: una guía práctica para corregir la asignación de recursos

La asignación de recursos consiste en asignar una persona, un rol o un activo específico a una tarea. Responde a una pregunta: ¿quién la realizará? La nivelación de recursos se produce cuando, al detectarse un conflicto en dicha asignación, se ajusta el cronograma (fechas de inicio, duración y orden de las tareas) para que la asignación sea viable. Responde a otra pregunta: ¿cuándo se puede llevar a cabo esto de forma realista, considerando quién la realizará y sus demás compromisos?

A ambos conceptos se les trata como si fueran lo mismo constantemente, razón por la cual muchos planes de proyecto permanecen incumplidos más tiempo del debido. La asignación sin nivelación produce un diagrama de Gantt que asigna el trabajo correctamente, pero lo programa de forma imposible. La nivelación sin una asignación clara no tiene nada con lo que ajustarse desde el principio.

Un término relacionado que merece una definición precisa, dado que aparece constantemente en esta conversación, es el diagrama de carga de recursos (a veces llamado diagrama de recursos o histograma de recursos). Mientras que un diagrama de Gantt representa las tareas en función del tiempo, un diagrama de carga de recursos representa el total de horas asignadas a una persona o rol en función de su capacidad disponible, día a día o semana a semana. La sobreasignación se muestra como una barra que cruza por encima de la línea del 100 % de capacidad. El diagrama de Gantt indica lo que está programado. El diagrama de carga de recursos indica si las personas responsables de ese cronograma pueden realmente llevarlo a cabo. La nivelación es la disciplina que concilia ambos.

Entre los recursos comunes que suelen requerir este tipo de reconciliación se incluyen personas específicas como un ingeniero o diseñador, roles como cualquier desarrollador backend disponible, especialistas compartidos como un administrador de bases de datos que da soporte a cinco proyectos simultáneamente, recursos físicos como un banco de pruebas o laboratorio compartido, y recursos con presupuesto limitado como un contratista con un número fijo de horas al mes. El mecanismo de nivelación es el mismo para todos ellos: se identifica dónde la demanda supera la disponibilidad y, a continuación, se decide qué medidas tomar.

La diferencia entre un horario que parece adecuado y un horario que realmente funciona se manifiesta de manera distinta según la perspectiva.

Los gestores de proyectos suelen elaborar un cronograma tarea por tarea, gestionan correctamente las dependencias y asignan tareas a personas específicas sin comprobar la carga de trabajo total de cada persona en todos los demás proyectos en los que participa. Este proceso se solapa en gran medida con la gestión diaria de tareas de los gestores que ya tienen que lidiar con múltiples fechas de entrega. El caos se desata cuando dos de esos compromisos vencen en la misma semana.

(PMO) experimentan esto a escala de cartera. El diagrama de Gantt de cada proyecto individual puede parecer perfectamente correcto de forma aislada. La sobreasignación solo se hace visible al analizar varios proyectos a cargo de la misma persona, que es precisamente el punto de inflexión donde la planificación de un solo proyecto da paso a la gestión de proyectos empresariales, y una vista de un solo proyecto en un diagrama de Gantt nunca se diseñó para mostrar eso.

Los directores de tecnología y los líderes de ingeniería se enfrentan a una versión del mismo problema: la hoja de ruta coincide con el calendario de tareas de soporte de producción no planificadas, respuesta a incidentes y revisión de código. Los ingenieros se comprometen con el trabajo de los sprints y el de la hoja de ruta al mismo tiempo, y la capacidad sobre la que se construyó la hoja de ruta se esfuma silenciosamente.

Los directores y consejeros delegados suelen ver los costes indirectos: retrasos en los plazos, sobrecostes y desgaste de equipos sobrecargados de trabajo, a menudo sin una forma sencilla de identificar la causa. Precisamente estos son los resultados que la gestión de riesgos rigurosa en el software de gestión de proyectos pretende detectar con antelación, en lugar de cuando ya se ha incumplido un plazo.

Nota para el profesional

La nivelación de recursos suele ser necesaria cuando la primera versión de un cronograma deja de ser realista. Se termina de asignar el trabajo y, de repente, se descubre que la misma persona debe realizar tres tareas distintas en la misma semana. En ese momento, solo hay unas pocas opciones viables: redistribuir el trabajo, cambiar a quien lo realiza, aumentar la capacidad o aceptar que un hito posterior debe modificarse. Tomar esa decisión de forma deliberada, en lugar de por accidente tres semanas después, es precisamente lo que implica la nivelación. No cambia la cantidad de trabajo existente, sino que hace que el cronograma refleje lo que el equipo realmente puede entregar.

Investigaciones independientes confirman la magnitud de esta brecha. En el estudio Wellington State of Project Management, la gestión de recursos se menciona repetidamente como uno de los procesos más difíciles de institucionalizar para las organizaciones, junto con la obtención de beneficios y la priorización, a pesar de ser una de las áreas que genera mayor valor cuando se realiza correctamente. Esto coincide con lo que se observa en la mayoría de las retrospectivas de las PMO: el plan no se equivocaba en cuanto al trabajo en sí, sino en cuanto a quién podía realizarlo y cuándo.

No todos los cronogramas necesitan una nivelación activa cada semana, pero algunas señales indican de manera confiable que es hora de ejecutar el proceso en lugar de esperar que el conflicto se resuelva por sí solo:

Asignación superior al 100%

Una persona muestra una asignación superior al 100 por ciento en el mismo período de tiempo, en todas las tareas en las que participa, no solo dentro de un proyecto.

Recursos críticos compartidos

Un especialista compartido participa en la ruta crítica de más de un proyecto al mismo tiempo.

Plazos antes de la contratación de personal

Los plazos se fijaron antes de que se confirmara la plantilla, y ahora deben ajustarse al número de empleados que realmente existen.

La capacidad no está clara

Llega una nueva solicitud y nadie puede decir, sin consultar manualmente varias hojas de cálculo o herramientas, si el equipo tiene espacio para ella.

Reajuste repetido de la línea base

El calendario se ha revisado más de una vez por la misma razón fundamental: alguien tenía una reserva duplicada y nadie se dio cuenta hasta que se pasó la fecha.

Elabore el cronograma en función de las dependencias, no de las personas

Defina la lista de tareas, duraciones y dependencias (fin-inicio, inicio-inicio, etc.) antes de asignar las tareas, utilizando técnicas estándar de planificación de proyectos para mantener una secuencia realista. Establezca una secuencia lógica y una ruta crítica adecuadas mediante estimaciones de esfuerzo razonables. Esto le proporcionará un cronograma de proyecto para probar la asignación de recursos, en lugar de elaborar el plan y tomar las decisiones de personal simultáneamente.

Asignar recursos, con nombre o basados ​​en roles

Al inicio de la planificación, es común saber que se necesitan dos desarrolladores backend y un ingeniero de control de calidad antes de saber quiénes serán exactamente. Esto es perfectamente normal. Los roles predefinidos pueden y deben programarse y clasificarse de la misma manera que los empleados con nombre, de modo que las carencias de capacidad se detecten incluso antes de considerar la contratación o la reasignación.

Sobreasignación de superficie con un gráfico de carga de recursos

Consulta el diagrama de asignación de recursos o el mapa de calor de la carga de trabajo junto al diagrama de Gantt. Los periodos en los que las horas asignadas superan la capacidad disponible suelen estar marcados con un color diferente o con una advertencia, de modo que el conflicto se visualiza inmediatamente en lugar de quedar oculto en una lista de tareas que, de otro modo, tendrías que leer línea por línea.

Resolver el conflicto deliberadamente

Una vez que se puede ver el conflicto, hay varias opciones reales, y parte del trabajo consiste en elegir la correcta en lugar de la más fácil:

• Retrasar o reordenar una tarea no crítica que tenga holgura, de modo que no afecte a la fecha de finalización.
• Divide la tarea de manera que la persona complete una parte del trabajo ahora y el resto más tarde.
• Añadir un segundo recurso para acortar la duración, pero utilizarlo con precaución, ya que esto puede afectar a la calidad o a los costes de coordinación.
• Si las habilidades requeridas son realmente transferibles, sustituya a la persona o el rol por otro.
• Ajusta el alcance o acepta que es necesario modificar un hito y comunícalo con anticipación, en lugar de hacerlo en la próxima reunión de seguimiento.

Vuelva a comprobar la ruta crítica después de cada cambio

Un cambio de nivelación en una tarea no crítica es prácticamente gratuito. Un cambio que afecte a una tarea en la ruta crítica modifica la fecha de finalización, y las partes interesadas deben ser informadas de ello en el momento en que ocurre, no descubrirlo semanas después, cuando la fecha de entrega ya se ha retrasado discretamente.

Renivelar continuamente, no una sola vez

Considera la nivelación como un hábito permanente vinculado a cualquier nueva solicitud, cambio de alcance o cambio de personal, y no como un ejercicio puntual realizado al inicio y olvidado. Un cronograma que era realista en la primera semana puede volverse irreal en el momento en que un nuevo proyecto se asigna al mismo recurso compartido en la sexta semana.

El término “planificación de recursos” tiene distintos significados según quién lo formule, y confundir las cuatro preguntas que se presentan a continuación es una de las razones más comunes por las que los equipos terminan comprando o desarrollando una solución para el problema equivocado. También conviene diferenciarlo de la distinción clásica entre gestión de programas y gestión de proyectos, que se centra en el alcance a nivel de cartera, en lugar de en un cronograma específico.

• Visibilidad de la capacidad: ¿contamos con el personal y las habilidades suficientes para asumir nuevos proyectos, independientemente de cualquier cronograma específico? Esta suele ser una pregunta que se plantea la Oficina de Gestión de Proyectos (PMO) o el responsable de recursos, incluso antes de que se apruebe un nuevo proyecto, y es precisamente en lo que se basan las herramientas especializadas de planificación de capacidad
• Equilibrio de la carga de trabajo: dadas las tareas ya existentes, ¿se distribuye la carga de manera uniforme o hay una persona o rol sobrecargado mientras otro permanece inactivo? Esta es la pregunta diaria de un gerente que dirige un equipo con varios proyectos simultáneos.
• Nivelación de recursos: dado un cronograma específico con dependencias reales, ajustar las fechas y la secuencia para que las tareas sean físicamente posibles. Esta es la pregunta del director del proyecto, planteada frente a un diagrama de Gantt en tiempo real.
• Planificación de escenarios hipotéticos: antes de comprometerse con algo, analice cómo un nuevo proyecto, una contratación postergada o la partida de un miembro del equipo modificarían el panorama, sin alterar el plan actual. Esta suele ser la pregunta que un ejecutivo o director de la Oficina de Gestión de Proyectos (PMO) se plantea antes de aprobar un cambio.

Un CTO que evalúa una herramienta para determinar su capacidad de ingeniería generalmente pregunta sobre el equilibrio de la carga de trabajo entre la hoja de ruta y la carga de soporte. Una PMO que estandariza procesos para veinte gerentes de proyecto generalmente pregunta sobre la visibilidad de la capacidad a nivel de cartera. Un gerente de proyecto que dirige una única entrega pregunta sobre la nivelación, sin más. Identificar cuál de estos cuatro problemas se intenta resolver antes de comparar software ahorra mucho tiempo de evaluación.

• La asignación de recursos se realiza según la disponibilidad de los usuarios, independientemente de sus habilidades. Esto resuelve el problema de la sobreasignación, pero a menudo introduce nuevos riesgos de calidad, ya que el recurso sustituto puede carecer del contexto o la experiencia necesarios para la tarea.
• Nivelación sin revisar la ruta crítica. Se corrige la sobreasignación, pero la corrección retrasa silenciosamente la fecha de finalización, y nadie se da cuenta hasta que el plazo ya está en riesgo.
• Tratar la nivelación como un ejercicio inicial único en lugar de una disciplina continua vinculada a cada nueva solicitud o cambio de personal.
• Ignorar los calendarios, los días festivos, los permisos planificados, los horarios de medio tiempo y las diferencias horarias modifican la capacidad real disponible, y un gráfico de asignación de recursos basado en una semana laboral plana de 40 horas no reflejará la realidad de casi todos los miembros de un equipo distribuido.
• Omitir el conflicto en el registro de riesgos. La sobreasignación es un riesgo de entrega como cualquier otro, y los equipos que gestionan los registros RAID de forma consistente, haciendo un seguimiento junto con otros riesgos, supuestos, problemas y dependencias, tienden a detectarlo antes que los equipos que solo consultan el diagrama de Gantt.
• Suponer que la nivelación genera capacidad productiva de la nada no añade horas a la semana de nadie. Revela la realidad de las horas que ya existen, razón por la cual el horario resultante es más fiable, aunque resulte menos conveniente.

Los mecanismos descritos anteriormente se aplican independientemente del software que se utilice. La diferencia radica en la cantidad de trabajo que se realiza automáticamente y la cantidad que aún depende de que alguien compare manualmente una lista de tareas con una hoja de cálculo aparte. A continuación, se explica cómo Celoxis aborda cada parte del proceso.

Un diagrama de Gantt interactivo con programación automática. Cuando cambia una dependencia o una fecha en Celoxis, el cronograma se recalcula y la ruta crítica se actualiza automáticamente, de modo que un cambio en la nivelación muestra su efecto real en la fecha de finalización de inmediato, en lugar de tener que recalcularlo manualmente. El diagrama de Gantt funciona como una superficie de planificación dinámica para múltiples proyectos interdependientes, no como una imagen estática que se actualiza cada vez que algo cambia.

Asignación de recursos según habilidades, disponibilidad y prioridad. Las asignaciones tienen en cuenta los calendarios de recursos, incluidos los días festivos, los horarios de medio tiempo y las zonas horarias, por lo que el gráfico de carga de recursos refleja las horas reales disponibles en lugar de una semana teórica de 40 horas. Este tema se trata con mayor detalle en nuestra guía sobre las funciones del software de gestión de recursos.

Una vista de la carga de trabajo entre proyectos. Dado que la sobreasignación suele manifestarse en varios proyectos en lugar de en un único plan, Celoxis ofrece a las PMO una vista de la carga de trabajo que abarca toda la cartera, precisamente la capa que un diagrama de Gantt de un solo proyecto no puede proporcionar por sí solo. Analizamos por qué esto es especialmente importante para las PMO en este artículo sobre gestión de recursos para PMO.

Asignación de personal por roles y provisional antes de la contratación definitiva. En las primeras etapas de la planificación, cuando se sabe que se necesitan dos desarrolladores y un ingeniero de control de calidad, pero aún no se conocen sus perfiles, esta brecha debe ser visible en comparación con la capacidad real, del mismo modo que lo sería una asignación específica. Esto permite tomar decisiones sobre la nivelación y la dotación de personal antes de que comience el reclutamiento, y no después de que una contratación no se concrete. Nuestra guía sobre software de planificación de recursos aborda este patrón con mayor detalle.

Comparación entre lo planificado y lo real. Las herramientas de planificación de capacidad que comparan el esfuerzo planificado con el esfuerzo registrado ayudan a confirmar si un cronograma nivelado resultó ser realista, un dato que vale la pena monitorear como uno de los KPI de gestión de proyectos, y que contribuye directamente a la gestión del valor ganado y a la siguiente ronda de planificación, en lugar de repetir el mismo error de estimación.

Nota importante: dado que Celoxis integra la planificación, la gestión de recursos y la elaboración de informes de cartera en una sola plataforma, los equipos que migran desde una herramienta sencilla basada únicamente en diagramas de Gantt suelen dedicar la primera o segunda semana a configurar calendarios, roles y permisos para adaptarlos a su forma de trabajar. La incorporación guiada forma parte de cada prueba, y la mayoría de los equipos están completamente operativos en cuestión de días, no de semanas.

Para que quede claro el alcance: el objetivo es una correcta nivelación y asignación de recursos, no una lista de funcionalidades más extensa. Si su problema se limita al cronograma de un solo proyecto, el diagrama de Gantt y las vistas de recursos mencionadas anteriormente son la parte relevante de Celoxis. Si se extiende a la gestión de docenas de proyectos con recursos compartidos e informes a nivel de cartera, es ahí donde la capacidad más amplia de gestión de cartera de proyectos cobra relevancia, y nuestra de herramientas PPM es un buen siguiente paso, pero conviene evaluarla individualmente en lugar de asumir que la necesita desde el primer día.

Ya sea que seas un PMO que estandariza herramientas, un CTO que intenta solucionar la falta de claridad en la capacidad de ingeniería o un director que aprueba una compra, estas son las preguntas que vale la pena hacer directamente a cualquier de herramientas de planificación de recursos y capacidad , idealmente con tus propios datos de proyecto en lugar de una demostración pregrabada:

¿Muestra la sobreasignación en todos los proyectos en los que participa una persona, y no solo dentro de un plan específico?

¿Es posible asignar marcadores de posición basados ​​en roles antes de nombrar o contratar a una persona específica?

Cuando se resuelve un conflicto, ¿se recalculan automáticamente la ruta crítica y la fecha de finalización?

¿Es posible simular un cambio hipotético, como un nuevo proyecto o una contratación retrasada, sin alterar el cronograma actual?

¿Puedes comparar el esfuerzo planificado con el esfuerzo real registrado para comprobar si las decisiones de nivelación anteriores se mantuvieron vigentes?

¿Cuánto tiempo tarda realmente un gestor de proyectos en aprender la vista de recursos, probada con su propio proyecto durante una prueba en lugar de una demostración de ventas preestablecida?

Si aún estás elaborando tu lista de opciones, nuestro resumen más amplio de herramientas de gestión de proyectos de TI y nuestra comparativa de software de gestión de proyectos son puntos de partida útiles antes de centrarte específicamente en la nivelación de recursos.