Plan del proyecto y cronograma: qué contiene cada uno y quién lo lee

Pide "el plan" a cuatro personas de un proyecto y puede que dos abran un diagrama de Gantt mientras las otras dos reenvían un documento con el alcance y el presupuesto. El diagrama muestra cuándo se hace el trabajo. El documento dice en qué consiste el trabajo y quién puede cambiarlo. Los problemas llegan con la primera solicitud de cambio, cuando solo existe uno de los dos.

Esta guía pone el plan del proyecto junto al cronograma del proyecto. Una tabla muestra qué va en cada uno y quién lo lee. Después, un congreso de clientes de un día sigue una única solicitud de cambio, contada en días por el cronograma y decidida según las reglas del plan.

Plan del proyecto y cronograma: qué es cada uno#

El plan del proyecto es el documento acordado que establece el alcance del proyecto y las reglas para gestionarlo, incluido quién puede cambiarlas. Su contrapartida, el cronograma del proyecto, modela ese plan y da a cada tarea sus fechas y dependencias^[1]. Sin un plan escrito, un cambio que añade 4 días de trabajo y consume el último día libre antes de una fecha fijada por contrato puede aprobarse sin que nadie tenga asignada la responsabilidad de aceptarlo. Si lo que falta es el cronograma, el mismo cambio parece gratuito, porque nada cuenta los días que consume.

El orden entre ambos lo establece la Government Accountability Office (GAO) de Estados Unidos. Su Schedule Assessment Guide (GAO-16-89G) indica que la estrategia global de ejecución se documenta en el plan del proyecto, que define, entre otras cosas, el alcance y la estructura de desglose del trabajo, y que la programación es un proceso distinto que sigue a la planificación^[1]. En palabras de la GAO, el cronograma es "esencialmente un modelo del plan del proyecto"^[1].

La NASA trata el plan como un acuerdo. Según la NPR 7120.5F, el plan del proyecto se acuerda entre el director del proyecto, el director del programa, el Center Director y el Mission Directorate Associate Administrator, y su plantilla incluye un resumen del cronograma maestro integrado en una sección Schedule Baseline^[2].

Quién necesita un plan y un cronograma, y cuándo#

Nuestra recomendación: redactar un plan a partir de tres personas o cuatro semanas de trabajo, una vez acordados el objetivo y el alcance y antes de cerrar el cronograma, porque el alcance decide qué tareas existen. Con dos personas, el alcance cabe en una conversación. La tercera persona es la primera que no la oyó, y cuatro semanas bastan para que llegue una solicitud de cambio con el trabajo ya en marcha.

Prescinde de él con dos personas trabajando dos semanas sobre un alcance fijado por contrato. El contrato ya hace el papel del plan.

El director del proyecto redacta el plan con el patrocinador y construye el cronograma con quienes hacen el trabajo. Los lectores son distintos:

• El patrocinador acuerda el plan antes de empezar y vuelve a las exclusiones y a la regla de cambios cada vez que llega una solicitud.
• Un equipo de 3 a 8 personas lee el cronograma cada semana; por encima de 8, cada responsable de subequipo lee su propia rama.
• Los proveedores reciben su parte y nada más. El catering del ejemplo necesita una sola fecha, el día 22, cuando llega el número de asistentes.

Nuestra regla práctica para la extensión: media página de plan cubre a tres personas durante un mes, y de una a tres páginas cubren hasta unas 8 personas y 6 meses. Por encima de 8 personas el equipo suele dividirse en subequipos, y cada responsable necesita por escrito su parte del alcance. Pasados 6 meses, el registro de cambios por sí solo ya no cabe en un párrafo.

Una vez acordado el plan, construye el cronograma a partir de la estructura de desglose del trabajo (EDT), como muestra la guía de la EDT y cómo convertirla en un cronograma. El cronograma cambia con cada registro de avance, mientras que el plan solo se revisa cuando cambian el alcance o el equipo.

Qué va en el plan, qué va en el cronograma y quién lee cada uno#

El plan contiene el alcance y las reglas y lo lee el patrocinador; el cronograma contiene las tareas y sus fechas y lo lee el equipo cada semana.

La GAO espera que los cronogramas los elabore el equipo del proyecto, incluidos los responsables de cada área de trabajo^[1]. Por eso la fila "Quién lo redacta" nombra a quienes hacen el trabajo como coautores del cronograma.

Lee primero la fila de la solicitud de cambio. Una solicitud necesita respuesta de las dos columnas antes de que nadie pueda decir que sí, y en el ejemplo siguiente el cronograma aporta el número de días mientras el plan nombra a quien decide. Los retrasos se miden frente a las fechas de la línea base, y la guía práctica de línea base y desviaciones explica cómo interpretarlos.

Un ejemplo práctico: un congreso de clientes#

Una tercera sala de ponencias solicitada el día 8 añade 4 días de trabajo a este congreso y lleva su hito "sede lista" del día 25 al día 26, el único día libre antes del evento.

Una empresa de software organiza un congreso de un día para 300 clientes. El contrato con la sede fija la fecha: el evento es el día 27. El equipo del proyecto lo forman el director del proyecto y dos personas, una coordinadora de eventos y un asistente de marketing, y el director comercial es el patrocinador. El cronograma tiene dos caminos que confluyen en el montaje; todas las dependencias son fin-inicio y las duraciones están en días laborables.

El camino A dura 5 + 15 + 2 = 22 días y es la ruta crítica. El camino B dura 12 + 4 + 3 = 19. Así que el montaje ocupa los días 23 a 25 y el día 26 queda libre.

Conviene distinguir dos términos. Holgura significa aquí holgura total, el tiempo que una actividad puede retrasarse sin afectar a la fecha de fin^[1]; el camino B tiene 22 − 19 = 3 días. Margen es el tiempo libre entre el hito "sede lista" y la fecha fija del evento: 1 día, el día 26.

El plan ocupa una página y fija dos reglas. Cualquier cambio de alcance necesita la aprobación del patrocinador, sea cual sea su efecto en las fechas. Un cambio de fechas o de método que no toca el alcance y se mantiene dentro de la holgura lo decide el director del proyecto, y queda anotado en el registro de cambios.

El día 8, con "Contratar a los ponentes" todavía en curso, el patrocinador pide una tercera sala de ponencias: cuatro ponentes más y una tercera sala. La coordinadora de eventos, que ha contratado a todos los ponentes hasta ahora, estima 4 días más de trabajo. Poco más se mueve. El número de asistentes para el catering sigue en 300 porque asiste la misma gente, la imprenta presupuesta los mismos 3 días para un programa más largo y el equipo de montaje confirma que una tercera sala sigue cabiendo en 3 días. El alquiler de la sala cuesta dinero y no tiempo, así que el cronograma no puede reflejarlo.

El camino B pasa a 16 + 4 + 3 = 23 días frente a los 22 del camino A. El montaje se desplaza a los días 24 a 26 y la ruta crítica pasa a ser B. La holgura absorbe 3 de los 4 días adicionales, y el cuarto ocupa el día 26, dejando el margen a cero.

La fecha del evento se mantiene, pero la decisión corresponde al patrocinador, porque el plan le asigna todo cambio de alcance. El director del proyecto le presenta tres opciones:

1. Aceptar la sala y llevar la última semana con margen cero.
2. Repartir las nuevas contrataciones. El asistente de marketing contrata a dos de los cuatro nuevos ponentes los días 9 y 10. La coordinadora se queda con los otros dos, ambos directivos de empresas socias con los que ya ha negociado antes, y los contrata los días 13 y 14, cuando terminan las contrataciones originales el día 12. "Contratar a los ponentes" termina entonces el día 14 y el camino B dura 14 + 4 + 3 = 21 días. El día 26 sigue libre, con 1 día de holgura en B.
3. Rechazarla.

La opción 2 tiene un límite. Mantiene libre el día 26 solo mientras el asistente pueda empezar como tarde el día 14: dos días empezados el día 14 terminan el día 15, el camino B pasa a 15 + 4 + 3 = 22 días, igual que el camino A, y el margen se conserva sin holgura en B.

Nuestra recomendación: enviar al patrocinador el coste de una solicitud en días y en dinero el mismo día en que llega, con las opciones, en cinco líneas o menos, aunque la fecha se mantenga. Una solicitud que consume el último día libre hace que cualquier retraso posterior de un día caiga directamente sobre el evento.

El patrocinador elige la opción 2.

El día 10, uno de los dos ponentes del asistente declina y encontrar un sustituto lleva hasta el día 11. Siguen viniendo cuatro ponentes nuevos, así que el alcance no cambia, y el trabajo del asistente sigue terminando antes que el de la coordinadora el día 14. El director del proyecto lo anota en el registro de cambios sin volver al patrocinador.

En el cronograma original, un retraso en la impresión habría sido el mismo tipo de decisión. Una imprenta saturada que desplaza el trabajo de los días 17–19 a los días 19–21 hace terminar el camino B el día 21, el montaje sigue empezando el día 23 y el margen no se toca, así que el director del proyecto lo anota por su cuenta.

Por qué un diagrama de Gantt no es un plan#

Un diagrama de Gantt no puede ser el plan porque solo muestra el trabajo ya programado: las tareas como barras en un calendario, con las dependencias entre ellas (la guía del diagrama de Gantt explica cómo leerlo). Cuatro cosas que contiene un plan no tienen sitio en él:

• Las exclusiones. El trabajo fuera del alcance no tiene barra, y una barra que falta es idéntica a un trabajo en el que nadie ha pensado todavía.
• La regla de aprobación.
• El motivo de una fecha. El día 27 puede aparecer como fecha límite del proyecto, pero el contrato con la sede que la hace inamovible no aparece en ninguna parte, así que quien lo lee no distingue una fecha fija de un objetivo.
• Los costes que no consumen tiempo, como el alquiler de la tercera sala.

La GAO señala la misma carencia desde el lado del cronograma: su buena práctica sobre líneas base pide un documento de soporte que detalle las reglas básicas y los supuestos del cronograma y justifique sus restricciones y desfases^[1].

Pensemos en una persona de producción que se incorpora al congreso en la semana 3 y recibe solo el diagrama de Gantt. Ve siete tareas y un hito "sede lista" al final del día 25, con la fecha del evento marcada como fecha límite del proyecto el día 27, un día libre después. Un proveedor le ofrece un fotomatón que necesita medio día de montaje y, como nada en el diagrama indica si las incorporaciones entran en el alcance, acepta, de modo que el montaje invade el día 26. Nadie avisa al patrocinador. La regla que cubría el caso, "cualquier cambio de alcance necesita la aprobación del patrocinador", estaba en un plan que nadie le había enviado.

Cómo redactar el plan y construir el cronograma a partir de él#

Seis pasos llevan un proyecto de un objetivo acordado a un cronograma con línea base, y cada uno tiene un resultado que comprobar antes del siguiente.

1. Escribe el objetivo y la fecha fija en una sola frase. Para el congreso: "Un congreso de un día para 300 clientes el día 27, fecha fijada por el contrato con la sede".
2. Enumera lo que queda fuera del alcance y nombra a quien aprueba los cambios. El patrocinador acepta ambas cosas por escrito antes de estimar ninguna tarea; basta con responder a un correo.
3. Descompón el alcance en entregables. Resultado: una EDT cuyos paquetes de trabajo cubren todo el alcance, cada uno con un responsable.
4. Convierte cada paquete de trabajo en tareas con duraciones y dependencias. Las estimaciones las dan quienes hacen el trabajo, y la guía sobre cómo estimar la duración de las tareas explica los métodos. Obtienes una red con una ruta crítica y una fecha de fin.
5. Compara el fin con la fecha fija. En el congreso el margen era de 1 día. Un margen negativo te devuelve al paso 2 para recortar alcance o pedir una fecha posterior, porque la GAO deja claro que el trabajo debe planificarse antes de poder programar las actividades^[1].
6. Guarda la línea base y copia sus hitos en el plan. La GAO llama a la línea base cronograma objetivo y la somete a un proceso de control de la configuración^[1], lo que en un proyecto pequeño significa que solo cambia a través de la regla de cambios del paso 2. Una línea del plan recoge entonces los hitos y el margen. Envía el plan junto con el cronograma a quien se incorpore después de la reunión de lanzamiento.

Errores habituales al confundir el plan y el cronograma#

El error que corregiríamos primero es el cronograma que circula como si fuera el plan, porque el día que llega una solicitud nadie puede demostrar qué incluía el encargo. Cinco patrones a vigilar:

• El cronograma que circula como si fuera el plan. El día 8 nadie puede demostrar si una tercera sala estuvo alguna vez en el encargo, y la discusión se zanja de memoria.
• Cada cambio hecho dos veces, porque la lista de tareas se pegó en el documento del plan; tras la primera actualización de avance, una de las copias está mal.
• Un archivo .mpp importado de 140 tareas cuya fila resumen superior se llama "Alcance": agrupa tareas, y no hay ninguna exclusión escrita en ningún sitio.
• Secciones que nadie abre. Elimina cualquier sección del plan que no se haya consultado ni una vez entre el lanzamiento y el cierre.
• Ningún responsable nombrado para los cambios, así que cada solicitud acaba en manos de quien habló con el equipo en último lugar.

Lo que cada documento no puede hacer#

Un plan no puede comprobar su propia fecha límite; solo el cronograma puede. En el congreso, el camino A necesita 22 días antes de que pueda empezar el montaje, y un contrato que prometiera el evento para el día 20 se habría leído perfectamente en un plan sin cronograma detrás.

Un cronograma no ve el trabajo que nadie incluyó en el alcance. La impresión de acreditaciones que nunca se puso por escrito no tiene barra ni holgura. La ruta crítica se calcula como si las acreditaciones fueran a imprimirse solas.

Planificar por etapas mantiene el orden entre ambos. La GAO admite la planificación por etapas a medida que los interesados conocen más detalles, un enfoque conocido como planificación gradual (rolling wave planning), y afirma que en ningún caso la planificación debe ser simultánea a la programación^[1]. En un proyecto planificado por oleadas, el alcance de cada oleada se pone por escrito antes de que sus tareas reciban fechas.

El formato breve tiene un techo. Nuestra regla práctica: en cuanto un contrato o un regulador exige un documento de plan independiente, como un plan de seguridad, el plan del proyecto se convierte en un índice que remite a él. La sección 3 de la plantilla de plan de proyecto de la NASA, sobre los planes de control del proyecto, tiene 29 subsecciones, entre ellas el Risk Management Plan (3.3) y el Configuration Management Plan (3.16)^[2].

Cómo hacerlo en Planitude#

Construye el cronograma en el diagrama de Gantt con dependencias e hitos, y fija la fecha límite del proyecto para que el fin previsto se compare con ella. Para no empezar desde cero, parte de una de las 13 plantillas, que ya incluyen dependencias e hitos; entre ellas hay un evento y una mudanza de oficina. También puedes guardar un proyecto propio como plantilla.

Comprueba el resultado en la pestaña Resumen. Compara el fin previsto con la fecha límite o con la línea base y muestra el avance planificado frente al real, con los hitos que vencen en los próximos 14 días en una lista aparte. Planitude guarda la línea base automáticamente con la primera actualización de avance, de modo que los retrasos se miden frente a las fechas originales. Si el cronograma ya existe en Microsoft Project, importa el archivo .mpp.

Planitude no tiene un documento de plan. Guarda las exclusiones y la regla de cambios en un documento compartido y pega su enlace en las notas del hito "sede lista", donde lo encontrará cualquiera que abra el cronograma.

Preguntas frecuentes#