Cronograma y Programación de un Proyecto

Este elemento es una ampliación de los cursos y guías de Lawi. Ofrece hechos, comentarios y análisis sobre la programación de proyectos. Puede ser de interés consultar lo siguiente:

• Glosario de Gestión de Proyectos
• Estructura de Desglose del Trabajo (EDT)
• Rol y Funciones de los Gestores de Proyectos
• El Arte de la Gestión de Proyectos
• Planificación Operativa
• Planificación Estratégica para el desarrollo de Audiencias
• Planificación Estratégica de Negocios
• Glosario de Gestión Cuantitativa Empresarial
• Análisis Estratégico
• El Proceso o Etapas de la Gestión de Proyectos
• Análisis de Negocios
• Planificación de la Empresa

Programación del Trabajo en Gestión de Proyectos

Esta sección se ocupará de la programación del trabajo en gestión de proyectos

Una de las principales características que distingue la gestión de proyectos de la gestión general es la especial atención que se presta a la programación. El Dr. J. M. Juran dice que un proyecto es un problema programado para su solución.

La gestión de proyectos no es sólo programación.

Por desgracia, algunas personas piensan que la gestión de proyectos no es más que programación, y esto es incorrecto. La programación es sólo una de las herramientas utilizadas para gestionar los trabajos y no debe considerarse la principal.

Hoy en día, la gente tiende a adquirir software de programación, del que hay abundancia, y piensa que eso les convertirá en gestores de proyectos instantáneos. Pronto descubren que esa idea es errónea. De hecho, es casi imposible utilizar el software con eficacia a menos que se entienda la gestión de proyectos (y la metodología de programación en particular).

Sugerencia: Sea cual sea el software de programación que elija, reciba formación profesional sobre cómo utilizarlo.

Tengo una sugerencia sobre el software. Sea cual sea el que elija, obtenga formación profesional sobre cómo utilizarlo. En los primeros días de los ordenadores personales, había una diferencia bastante significativa entre el software de gama baja y el de gama alta que estaba disponible. Los paquetes de gama baja eran bastante fáciles de usar, mientras que los de gama alta no lo eran. La brecha entre el software de gama baja y el de gama alta se ha cerrado hasta el punto de que esto ya no es cierto. Ahora todos son difíciles de usar, y los materiales de formación (tutoriales y manuales) que vienen con el software no suelen ser muy buenos. Además, es difícil encontrar tiempo para trabajar a través de un tutorial sin ser interrumpido varias veces, lo que significa que el autoaprendizaje es difícil. La forma más eficaz es asistir a una clase.

Compruebe los conocimientos del instructor sobre gestión de proyectos antes de elegir qué clase tomar. Algunas de las personas que las imparten saben muy poco sobre la gestión de proyectos en sí y, cuando usted tenga preguntas, no sabrán responderlas.

Debe esperar pasar de dos a tres días de clase para llegar a ser realmente competente con el software. Aun así, se trata de una buena inversión, teniendo en cuenta el tiempo que el software puede ahorrarle a largo plazo.

Breve historia de la programación

Hasta aproximadamente 1958, la única herramienta para programar proyectos era el diagrama de barras. Dado que Henry Gantt desarrolló un sistema de notación completo para mostrar el progreso con diagramas de barras, a menudo se denominan diagramas de Gantt. Son sencillos de construir y de leer y siguen siendo la mejor herramienta para comunicar a los miembros del equipo lo que tienen que hacer en unos plazos determinados. Los diagramas de flechas suelen ser demasiado complicados para algunos equipos. No obstante, a menudo resulta útil mostrar un diagrama de flechas a las personas que realizan el trabajo para que comprendan las interdependencias y por qué es importante que completen determinadas tareas a tiempo.

Los diagramas de barras tienen un grave inconveniente: Es muy difícil determinar el impacto de un retraso en una tarea sobre el resto del proyecto (por ejemplo, si la tarea A se retrasa, es difícil saber cómo afectará al resto del trabajo). La razón es que el diagrama de barras (en su formato original) no mostraba las interdependencias del trabajo. (Los programas informáticos actuales sí muestran los vínculos entre las barras, lo que facilita su lectura. El nombre actual de este gráfico de barras es cronograma de ruta crítica).

Para superar este problema, a finales de los años 50 y principios de los 60 se desarrollaron dos métodos de programación que utilizan diagramas de flechas para captar las relaciones secuenciales y paralelas entre las actividades del proyecto. Uno de estos métodos, desarrollado por DuPont, se denomina Método del Camino Crítico (MPC), y el otro es la ya comentada Técnica de Evaluación y Revisión de Programas (PERT). Aunque se ha convertido en costumbre llamar PERT a todos los diagramas de flechas, en sentido estricto el método PERT hace uso de técnicas de probabilidad, mientras que el CPM no. En otras palabras, con PERT es posible calcular la probabilidad de que una actividad se complete en un tiempo determinado, mientras que eso no es posible con CPM.

CPM: Método del camino crítico

PERT: Técnica de evaluación y revisión de programas

Diagramas de red

Para mostrar la secuencia en la que se realiza el trabajo, se utilizan diagramas en que la tarea A se realiza antes que la B, mientras que la tarea C se realiza en paralelo con ellas.

El grafo de la mitad inferior utiliza la notación de actividad sobre flecha, en la que las flechas representan el trabajo que se realiza y los círculos representan eventos. Un evento es binario; es decir, o se ha producido o no se ha producido. Una actividad, en cambio, puede completarse parcialmente. Tenga en cuenta que se trata de un uso especial de la palabra “acontecimiento”. Hablamos de un partido de fútbol como un acontecimiento, aunque abarque un periodo de tiempo. Sin embargo, en la terminología de la programación, un evento es un punto específico en el tiempo en el que algo acaba de empezar o acaba de terminar.

La red de la mitad superior del diagrama de flechas utiliza la notación de actividad sobre nodo, que muestra el trabajo como una caja o nodo, y las flechas muestran la secuencia en la que se realiza el trabajo. Los eventos no se muestran en las redes de actividad sobre nodo a menos que sean hitos, es decir, puntos del proyecto en los que se completan partes importantes del trabajo.

¿Por qué dos formas de diagramas? Probablemente sea una tiranía para confundir a los no iniciados. En realidad, ocurre simplemente que los esquemas fueron desarrollados por diferentes profesionales.

¿Es uno mejor que el otro? No. Ambos obtienen los mismos resultados a la hora de saber cuándo se debe completar el trabajo. Ambas formas se siguen utilizando, aunque la actividad en nodos se usa un poco más que la otra, simplemente porque gran parte del software de los ordenadores personales actuales está programado para utilizar la notación de nodos.

¿Cuál es la ventaja de utilizar el CPM o el PERT? La principal ventaja es que puede saber si es posible cumplir una fecha importante de finalización del proyecto, y también puede saber exactamente cuándo deben terminarse las distintas tareas para cumplir ese plazo. Además, puede saber qué tareas tienen cierto margen de maniobra y cuáles no. De hecho, tanto el CPM como el PERT determinan el camino crítico, que se define como la serie más larga de actividades (que no pueden realizarse en paralelo) y que, por tanto, rige lo pronto que puede completarse el proyecto.

El camino crítico es el camino más largo a través de la red de un proyecto. Como no tiene holgura, todas las actividades del camino crítico deben completarse según lo programado, o la fecha final empezará a deslizarse: un día por cada día que se retrase una actividad crítica.

La razón de la programación

Naturalmente, la razón principal para programar un proyecto es garantizar que se pueda cumplir la fecha límite. La mayoría de los proyectos tienen un plazo impuesto. Además, dado que el método del camino crítico ayuda a identificar qué actividades determinarán la fecha final, también ayuda a orientar cómo debe gestionarse el proyecto.

Sin embargo, es fácil dejarse llevar por la programación y pasar todo el tiempo actualizando, revisando, etc. El software de programación que se utiliza hoy en día debe considerarse una herramienta, y los gestores no deben convertirse en esclavos de ella.

También es muy fácil crear planificaciones que parecen buenas sobre el papel pero que no funcionan en la práctica. La razón principal suele ser que no se dispone de recursos para hacer el trabajo cuando toca. De hecho, a menos que la asignación de recursos se gestione adecuadamente, los calendarios son prácticamente inútiles. Afortunadamente, el software de programación actual gestiona la asignación de recursos bastante bien, pero dejamos la discusión de los métodos utilizados para los manuales de software. En este libro, nos limitamos a examinar cómo se utilizan las redes para mostrarnos dónde tenemos que gestionar.

A menudo me dicen que el alcance y las prioridades cambian tan a menudo en una organización determinada que no tiene sentido dedicar tiempo a encontrar rutas críticas. Merece la pena considerar dos puntos en este sentido. Uno es que si el alcance cambia a menudo en un proyecto, no se está dedicando suficiente tiempo a la definición y planificación previas. Los cambios de alcance suelen producirse porque se olvida algo. Prestar más atención a lo que se está haciendo al principio suele reducir la fluencia del alcance.

En segundo lugar, si las prioridades cambian a menudo, es que la dirección no tiene las cosas claras. Por lo general, la organización está intentando abordar demasiado trabajo para los recursos disponibles. Todos tenemos listas de deseos de cosas que queremos hacer personalmente, pero tenemos que dejar algunas de ellas en suspenso hasta que dispongamos de tiempo, dinero o ambos. Lo mismo ocurre con las organizaciones. La experiencia demuestra que cuando hay individuos trabajando en muchos proyectos, la productividad se resiente. Una empresa descubrió, a modo de ejemplo, que cuando dejó de tener a personas trabajando en múltiples proyectos, ¡la productividad de los empleados se duplicó! Evidentemente, eso es muy significativo.

Una empresa descubrió que cuando dejó de tener a personas trabajando en múltiples proyectos, la productividad de los trabajadores se duplicó.

¿Qué tiene que ver el CPM con esto? Saber dónde se encuentra el camino crítico en un proyecto le permite determinar el impacto en el proyecto de un cambio de alcance o de prioridad. Sabrá qué actividades se verán más afectadas y qué habrá que hacer para recuperar el tiempo perdido. Además, los gestores pueden tomar decisiones con conocimiento de causa cuando usted puede indicarles el impacto de los cambios en el proyecto. Así pues, el CPM puede ser una herramienta inestimable cuando se utiliza correctamente.

Definiciones de los Términos de la Red

Véase, en este contexto:

• ACTIVIDAD: Una actividad siempre consume tiempo y también puede consumir recursos. Algunos ejemplos son el papeleo, las negociaciones laborales, las operaciones de maquinaria y los plazos de entrega de piezas o equipos comprados.
• CRÍTICO: Una actividad o acontecimiento crítico es aquel que debe realizarse en un plazo determinado, sin tener ningún tipo de latitud (holgura o flotación).
• CAMINO CRÍTICO: El camino crítico es el camino más largo a través de una red y determina la finalización más temprana del trabajo del proyecto.
• EVENTOS: Los puntos de inicio y fin de las actividades se conocen como eventos. Un evento es un punto específico en el tiempo. Los eventos suelen denotarse gráficamente mediante un círculo y pueden llevar nomenclatura de identidad (por ejemplo, palabras, números, códigos alfanuméricos).
• HITO: Un hito es un acontecimiento que representa un punto de especial significación en un proyecto. Normalmente, se trata de la finalización de una fase importante del trabajo. Las revisiones del proyecto suelen realizarse en los hitos.
• RED: Las redes se denominan diagramas de flechas. Proporcionan una representación gráfica de un plan de proyecto que muestra las relaciones de las actividades.

Construcción de un diagrama de flechas

Como se señaló en relación con la estructura de desglose del trabajo o EDT (ver más detalles en otro lado), antes de programar el trabajo en el proyecto debe elaborarse una estructura de desglose del trabajo (EDT). Además, una estructura de desglose del trabajo puede contener de dos a veinte niveles. Para ilustrar cómo se construye un cronograma a partir de una estructura de desglose del trabajo, consideremos un trabajo sencillo de mantenimiento del jardín alrededor de una casa.

En el caso de esta estructura de desglose del trabajo, lo adecuado es programar las tareas en el nivel más bajo. Sin embargo, esto no siempre es así. A veces, el trabajo se desglosa hasta el nivel 6, pero sólo se introducen en la programación las actividades hasta el nivel 5. La razón es que es posible que no pueda mantener las tareas del Nivel 6 en el calendario. Es decir, no se puede gestionar tan ajustadamente. Así que programe a un nivel que pueda gestionar. Esto sigue la regla general de que nunca debe planificar (o programar) con más detalle del que puede gestionar. Algunos proyectos, como la revisión de un gran generador eléctrico, se programan en incrementos de horas. Otros se programan en días, mientras que algunos grandes trabajos de construcción se programan al mes más cercano.

Si bien planificar con demasiado detalle es indeseable, si planifica con demasiado poco detalle, mejor no molestarse. Como ejemplo práctico, un directivo me dijo que su personal quería crear calendarios en los que aparecieran tareas con duraciones de 26 semanas. Protestó porque el personal nunca completaría esos calendarios a tiempo. Los sobrecargarían, argumentó.

Lo que quería decir era que hay mucha seguridad en una tarea de 26 semanas. Cuando llega la fecha de inicio, si la persona que realiza la tarea está ocupada, puede decir: “Siempre puedo recuperar un día en una actividad de 26 semanas. Empezaré mañana”. Esto continúa hasta que se da cuenta de que se ha retrasado demasiado. Entonces se produce una gran avalancha de actividad mientras intenta terminar a tiempo. Todo el trabajo se ha retrasado hasta el final del plazo de 26 semanas.

Una buena regla general a seguir es que ninguna tarea debe tener una duración muy superior a cuatro o seis semanas. Una tarea de 26 semanas probablemente pueda dividirse en cinco o seis subtareas. Un plan de este tipo suele evitar que la gente se cargue de trabajo.

Hay dos formas de elaborar un calendario. Una es empezar por el final y trabajar hacia atrás hasta llegar al principio. El segundo método consiste en empezar por el principio y trabajar hacia el final. Normalmente, es más fácil empezar por el principio.

El primer paso es decidir qué se puede hacer primero. A veces, varias tareas pueden empezar al mismo tiempo. En ese caso, basta con dibujarlas una al lado de la otra y empezar a trabajar desde ahí. A veces hacen falta varias iteraciones antes de poder elaborar completamente la secuenciación.

Puede pensarse que este pequeño proyecto tiene tres fases: preparación, ejecución y limpieza. Hay tres tareas de preparación: recoger la basura, poner gasolina en el equipo y sacar la podadora de setos. Las tareas de limpieza incluyen embolsar la hierba, agrupar los recortes y llevar la basura al vertedero.

Al hacer este diagrama de programación, he seguido una regla de programación, que consiste en diagramar lo que es lógicamente posible, y luego ocuparse de las limitaciones de recursos. Para un proyecto de jardinería, si no tengo a nadie que me ayude, entonces realmente no puede haber caminos paralelos. Por otro lado, si puedo conseguir ayuda de la familia o de los jóvenes del vecindario, entonces los caminos paralelos son posibles, así que esta regla dice que adelante y programe como si fuera posible conseguir ayuda. Esto es especialmente importante de recordar en un entorno laboral, o nunca conseguirá organizar un horario. Se preocupará de quién estará disponible para hacer el trabajo y acabará en parálisis por análisis.

Los calendarios deben elaborarse de acuerdo con lo que es lógicamente posible, y la asignación de recursos debe hacerse más tarde. Así se obtendrá el calendario óptimo.

Otra regla es mantener todos los tiempos en los mismos incrementos. No mezcle horas y minutos: programe todo en minutos y luego conviértalo a horas y minutos como último paso. Para este horario, simplemente he mantenido todo en minutos.

Basado en la experiencia de varios autores, mis opiniones, perspectivas y recomendaciones se expresarán a continuación (o en otros lugares de esta plataforma, respecto a las características en 2026 o antes, y el futuro de esta cuestión):

Otra regla es mantener todas las horas en los mismos incrementos.

Le sugiero que dibuje su red en papel y compruebe su coherencia lógica antes de introducir nada en un programa informático de programación. Si la red tiene errores lógicos, el ordenador sólo le dará un resultado de entrada/salida de basura, pero parecerá impresionante, al haber salido de un ordenador.

También es importante recordar que no suele haber una solución única para un problema de red. Es decir, puede que otra persona dibuje el diagrama de flechas de forma un poco diferente a como lo ha hecho usted. Puede que haya partes del diagrama que deban hacerse en un orden determinado, pero a menudo hay flexibilidad. Por ejemplo, no puede entregar papeles hasta que no los haya impreso, por lo que si el diagrama mostrara esa secuencia, sería incorrecto. La conclusión es que no existe una única solución correcta, pero se puede decir que un diagrama es erróneo si viola la lógica.

Es difícil saber si una red es absolutamente correcta, pero puede decirse que es errónea si viola la lógica.

La red para el proyecto del patio podría complicarse mucho más. Podría tener borde delantero de acera y borde trasero de acera. Podría hablar de podar alrededor de los árboles tanto en la parte delantera como en la trasera, etcétera. Pero no es necesario complicarlo tanto. Normalmente no intentamos plasmar exactamente cómo haremos el trabajo, sólo lo esencial.

El siguiente paso es calcular cuánto tiempo llevará hacer el trabajo. Las estimaciones de tiempo para cada tarea se realizan utilizando el historial, teniendo en cuenta cuánto tiempo ha llevado cada actividad en el pasado. Recuerde, no obstante, que la estimación sólo es válida para el individuo que va a realizar la tarea. Si mi hija, que tiene 16 años, corta el césped utilizando un cortacésped de empuje, probablemente tardará menos tiempo que si mi hijo, que sólo tiene 12 años, realiza la misma tarea. En relación con la elaboración de un cronograma viable (véase en esta plataforma digital), vemos cómo encontrar el camino crítico a través de la red para poder saber cuánto tardarán las cosas.

Puntos Clave

Los aspectos principales a recordar son los siguientes:

• La gestión de proyectos no es sólo programar.
• Los diagramas de flechas permiten evaluar el impacto de un deslizamiento en un proyecto más fácilmente que con los diagramas de Gantt.
• Programe con un nivel de detalle que se pueda gestionar.
• No debe programarse ninguna tarea con una duración muy superior a cuatro o seis semanas. Subdivida las tareas más largas para lograr este objetivo. Las tareas de software e ingeniería deben dividirse aún más, hasta alcanzar duraciones no superiores a una o tres semanas.

Vía de Programación en el Contexto del Mercado de Trabajo

En relación a las relaciones laborales españolas, vía de programación ha sido definido [1] de la siguiente forma: Vía de Programación: Bajo este epígrafe se incluyen las distintas vías o modalidades de programación y ejecución que constituyen los sistemas operativos de funcionamiento que se utilizan habitualmente. Se consideran las siguientes:

• Cursos directos.
• Cursos en Centros Colaboradores.
• Cursos de Entes Locales y Provinciales.
• Cursos en Empresas con compromiso de contratación.
• Cursos de Contratos Programa.

Recursos

Notas y Referencias

1. SPEE

Véase También

• Organización del Trabajo
• Trabajo Nocturno
• Trabajo en Equipo
• Trabajo en Cadena
• Trabajo Compartido
• Trabajo
• Ritmo de Trabajo
• Productividad del Trabajo
• Jornada de Trabajo
• Comunicación Pública
• Comunicación Organizativa
• Comunicación del Equipo Médico
• Comunicación del Equipo
• Beneficios del Trabajo en Equipo
• Trabajo por Turnos
• Trabajo en Pantalla
• Trabajo Dominical
• Trabajo Clandestino
• Trabajo a Tiempo Parcial

Condiciones y Organización del Trabajo, Factores de Producción, Fordismo, Formación Profesional, Fuerza de Trabajo, Organización del Trabajo, Relaciones Laborales, Taylorismo, Trabajo, Trabajo y Empleo

▷ Esperamos que haya sido de utilidad. Si conoces a alguien que pueda estar interesado en este tema, por favor comparte con él/ella este contenido. Es la mejor forma de ayudar al Proyecto Lawi.