CÓMO DISTINGUIR DE VERDAD LA LÓGICA DURA/BLANDA EN TU CRONOGRAMA

Por: Felix Soto Morales

Para mucha gente no es muy importante diferenciar entre la lógica dura y blanda a la hora de planificar sus cronogramas, aunque está muy recomendado en el PMBOK  del PMI y el TCM del AACE.  Déjenme explicar brevemente los conceptos a fin de profundizar en el tema que les traigo hoy.

Lógica Dura

Se trata de la lógica obligatoria, ya sea contractual o física.  Por ejemplo, al construir una columna todo el mundo sabe que el encofrado viene antes del hormigón, eso es una condición física y tal vez el planner pondrá una relación Finish-to-Start para representarlo en su cronograma.  La lógica contractual –por otra parte– se deriva del contrato en sí y muchas veces es un requerimiento del owner.  Digamos que el cliente quiere terminar un área específica antes que otra, esa necesidad se convierte en obligatoria, por lo que el contratista deberá seguir obligatoriamente esa secuencia de trabajo.

Ambas lógicas –física y contractual– son consideradas como duras u obligatorias, una porque sería imposible hacerlo de otra manera; y la otra porque es una necesidad del owner.

Lógica Blanda

Algunas veces conocida como lógica preferencial o discrecional.  Este es el tipo de lógica realizada por la mano del planner/scheduler.  Por ejemplo, después de cumplir con los requisitos del contrato en el cronograma, el contratista decide trabajar dos edificios en paralelo para darle un mejor uso a la grúa que es cara.  Sólo un edificio tiene fecha límite en el contrato, pero en vez de construir uno después del otro, él prefiere hacerlos al mismo tiempo.  Esa es la lógica discrecional o también llamada lógica blanda.

¿Es importante distinguir entre ellas?

Por supuesto que sí!, como planner prefiero evitar la lógica blanda lo más posible en la ruta crítica, pues con ella esa ruta podría cambiar fácilmente ya que durante los trabajos muchas decisiones pueden llevarnos a realizarlos de una manera diferente, porque nunca fue obligatorio hacerlo de un modo específico.

Desde el punto de vista del analista de programación forense, imagina que estás a punto de realizar una metodología Collapsed-As-Built, para demostrar un reclamo de extensión de plazo y escoges este método porque tal vez no tenías una línea base  con la que trabajar; entonces, una de las partes más difíciles para tí, como experto,  será retroceder en el tiempo sin ninguna idea de cómo estaban las relaciones originales en las actividades. Podemos deducir las físicas y las contractuales, pero  ¿qué pasa con las discrecionales? ¿Tendrás una voz que te diga al oído cómo sucedieron las cosas? ¿Los registros tendrán los suficientes detalles como para contarte la historia en esos casos?  Quizás no.

Una solución para tí

Por supuesto no es tan simple como poner notas o utilizar un campo definido por el usuario en tu cronograma de P6, eso no funciona, al menos para mí.  Hace algún tiempo empecé a usar Asta Powerproject al darme cuenta de que muchos expertos estaban migrando a esta herramienta. En Asta encontré la función que estaba buscando y procedo a mostrárselas:

El Paso 1 muestra los tipos de relación configuradas antes de iniciar la programación:

En el Paso 2, procedes a programar considerando el tipo de vínculo apropiado asignado a cada relación entre actividades.

En el Paso 3 sólo disfruta de los beneficios de haber distinguido todos los tipos de relación.

Arriba, muestro una relación contractual en azul, dos relaciones discrecionales en celeste y el resto son físicas en negro.

Como revisor de cronograma puedes desactivar la lógica dura para observar sólo la blanda y analizar qué es lo que el scheduler/planner/contratista ha escogido como ruta a seguir y dependerá de tí el aceptar, rechazar o sugerir algo nuevo para estas lógicas.

Con esto, el owner puede recibir un cronograma más transparente del contratista; o el analista forense podría tener una gran ayuda para realizar su metodología forense. Diferenciar los tipos de relación ayuda al equipo del proyecto a tener un cronograma más comprensible.

¿Crees que esto puede ser útil en tu empleo?

Síguenos en: Facebook, LinkedIn, YouTube

Nuestra web: www. metacontrol.com.pe/articles.html  & Blog

 

 

 

 

Advertisements

LA HOLGURA DE LA RUTA CRÍTICA… ¿?

Por: Felix Soto Morales

“Las tareas que conforman la ruta crítica

tienen holgura cero”

Esa fue una de las primeras cosas que aprendí durante mi entrenamiento en planificación en la empresa donde ingresé a laborar allá a principios de los años 90. Y realmente creo que nadie pondría en duda ese axioma.

Pero ¿qué tal si te digo que a veces ciertas tareas contenidas en la ruta crítica pueden tener holgura? Seguramente pensarás: “Felix ya quemó cerebro”, “Su post sobre la extinción de Primavera lo dejó mal”.

Nada de eso, la facilidad que nos dan los software para modelar cronogramas que se acerquen cada vez más al modelo real de trabajo, muchas veces pueden hacer aparecer situaciones que talvez nos creen cierta dificultan de comprensión.

Te pongo un ejemplo concreto de lo que te puede suceder al trabajar con múltiples calendarios. A continuación he modelado una malla muy simple de cinco tareas.

En este caso, la ruta crítica pasa por las tareas A, B y E. Y también tenemos una ruta alterna no crítica que pasa por C, D y E.  Sin embargo, en la ruta principal (A-B-E) la tarea A tiene holgura, por lo que no se muestra en rojo.

Por si lo estás pensando, la malla de arriba no tiene ninguna restricción impuesta. Entonces ¿cómo es posible que una tarea de la ruta crítica (A) tenga holgura? La respuesta es: múltiples calendarios.

A continuación develo que las tareas B y C están sujetas a un calendario en donde hay dos semanas continuas de días no laborables, al cual he llamado “Frozen”.

La tarea A puede trabajar durante la etapa “frozen” pero como la tarea B no puede, entonces es postergada hasta el final de ese periodo, dándole una holgura de cinco días a la actividad A.  Es así que tenemos una ruta crítica con holgura; y en cronogramas complejos esto puede pasar a menudo y tal vez no te estés dando cuenta.

Por otro lado, abajo se puede apreciar que la ruta C-D-E, no debería ser un problema en cuanto a criticidad se refiere, siendo que la tarea D tiene aun 11 días de holgura.  Sin embargo al ver a C, (expuesta al calendario frozen) vemos que en realidad sólo hay un día de holgura.

En el cuadro de abajo he aumentado la duración de la tarea C en tres días, es decir a ocho días laborables:

El resultado es que los 11 días de holgura que poseía la tarea D se consumieron con tan sólo aumentar tres días en su ruta.  Por lo tanto, la nueva ruta crítica pasó a ser C-D-E.

Entonces, los efectos de los múltiples calendarios pueden llegar a confundirte.

Estas situaciones pueden suceder cuando utilizamos múltiples calendarios o también restricciones en un cronograma, pero no por eso debemos dejar de usarlos, ya que éstos nos ayudan a modelar el cronograma de trabajo de forma más cercana a la realidad. Sólo debes estar atento a lo que sucede en el cálculo y saber explicarlo.

Eso es todo, la próxima vez que veas que en tu cronograma ha desaparecido parte de la ruta crítica, no te asustes, respira hondo, sigue la ruta crítica con calma y encontrarás la explicación.

Síguenos en: Facebook, Linkedin, YouTube

Nuestra web: www. metacontrol.com.pe/articles.html  y nuestro Blog

 

ASTA POWERPROJECT – PROGRAMANDO CON METRADOS

¿Alguna vez quisiste utilizar los metrados o cantidades de las tareas en tus cronogramas? Asta Powerproject es el único software que te permite hacerlo. Descubre cómo en el siguiente video:

Para más vídeos visita nuestro canal de YouTube

Síguenos en Facebook para estar enterado de todas las novedades en control de proyectos, ingeniería y construcción.

AS LATE AS POSSIBLE ¿ES REALMENTE UNA RESTRICCIÓN?

alap

Por: Felix Soto Morales

Cuando a los planificadores se les enseña a programar cronogramas de proyectos con algún software, suelen aprender que “hay que evitar el uso de restricciones”.  Es una regla que todos los schedulers hemos escuchado alguna vez.

En mis clases, me gusta más decir que uno debe minimizar el uso de restricciones; sin embargo, cuando hay la necesidad de usarlas, pues debes hacerlo.  No es para nada malo usarlas.  El problema es que con el aumento del uso de restricciones, la malla (la red de actividades entrelazadas entre sí por relaciones lógicas) empieza a tener cada vez menos lógica.  Y es que las restricciones limitan la lógica, ya que colocas una fecha en donde la actividad iniciará o terminará debido a un evento externo del alcance de nuestro proyecto o debido a un evento que no podemos controlar.  Ejemplo: la entrega de la fabricación de un modular realizada por un proveedor externo. 

Para el ejemplo expuesto, se suele colocar un hito “entrega de modular” con una restricción del tipo Finish On (Debe finalizar en), que luego se enlaza con el montaje de dicho modular, obras sanitarias, etcétera.  Entonces, se ha colocado un fecha externa, que no es producto del cálculo desde ninguna actividad predecesora, en otras palabras “no hay lógica”.  Por supuesto, estoy usando la terminología coloquial… ¡Claro que tiene lógica!

El hecho es que las restricciones cambian los cálculos de inicio o fin de las actividades porque se les coloca una fecha externa impuesta y este cambio hace que la lógica entre las actividades se altere en mayor o menor medida.  Mucho ojo, dependiendo de la restricción, se puede romper o no la lógica de las actividades.

Pero, ¿qué hay de los tipos de “restricción” que nunca alteran la lógica del cronograma?  De hecho son dos tipos:  el primero, es el que da título a este post, la “restricción” As Late As Possible (ALAP) o Tan Tarde Como Sea Posible.

Esta mal llamada restricción se puede colocar en las actividades sin la necesidad de determinar una fecha.  Lo que hace esta imposición es colocar las fechas de la actividad hasta lo mas tardío posible, en otras palabras, hasta que su holgura libre se haga Cero.

Este tipo de imposición es muy usada por los programadores cuando quieren postergar adrede una actividad, pero sin afectar la lógica del cronograma.  Son realizadas sobre actividades poco importantes (actividades no críticas).  Entiéndase por poco importante a las actividades que no están en el camino crítico del proyecto.  Tiene que ser así, dado que si estuvieran en la ruta crítica, sería en vano colocarle esta imposición, ¿cierto?

Te propongo un par de ejemplos de uso:

  1. Por temas de flujo de caja decides retrasar una actividad que tiene holgura y mucho costo.
  2. Postergas la fabricación de tanques hasta poco antes de montarlos.  La actividad que precede al montaje es la cimentación de las bases de los tanques y también la fabricación, sin embargo la ruta más larga pasa por las bases.  Puedes fabricar los tanques mucho antes y almacenarlos o hacerlos justo antes de montarlos.

La fechas van a cambiar colocando la imposición “ALAP” pero no restringe nada.  Las actividades que tengan la imposición ALAP se mueven “libremente” dentro de su holgura. Por lo tanto, realmente NO son restricciones.  Si reprogramas y la holgura de las actividades se hace menor, entonces su capacidad de moverse también será menor.  En las otras restricciones, una vez que colocas la fecha, hagas lo que hagas, la programación se moverá debido a esa fecha de restricción.

A partir de ahora, te pido que dejes de llamar restricciones a las imposiciones “As Late As Possible” y las uses como una técnica de programación saludable, sin ningún problema.

Te comento que algunas veces me han rechazado cronogramas por presentar algunas imposiciones ALAP, pero lo han hecho por desconocimiento, porque se han pegado a la regla estricta de evitar el uso de restricciones.  En el 99% de los casos, los convenzo con una simple conversación, pero en alguna oportunidad me han mostrado los estándares de la empresa y he tenido que cambiarlo todo aún cuando sé que están equivocados.  C´est la vie!

Es un conocimiento adquirido tras años de experiencia planificando proyectos, pero si todavía lo dudas, mejor te muestro la segunda restricción que no necesita de colocación de la fecha.

Se trata de la restricción As Soon As Possible (ASAP).  Estoy seguro de que has escuchado este término muchas veces, pero ¿sabías que también es una imposición?

En algunos softwares la colocan -en la mayoría no-, porque es la posición estándar o por default de la actividad.  Y claro, todos queremos que nuestro proyecto acabe ASAP o Lo Más Temprano Posible, esa es la razón por la que ni siquiera se menciona, de hecho esta implícita. Pero ASAP también es una “restricción” en los software de programación.  Para nosotros, a partir de ahora, que sea una imposición.

¿Dirías que las actividades que programas en su estado por default, es decir ASAP, tienen restricción?  No lo creo.  Entonces por qué llamarías restricción a la posición tardía o ALAP, si tampoco no restringe nada.

Deseo que esta información te pueda servir mucho en tu trabajo.

ASTA POWERPROJECT – DIBUJA TU PROYECTO Y LISTO

Te presentamos Asta Powerproject, una herramienta de planificación poderosa y fácil de usar. Muy empleada en Europa y Asia y muy pronto el nuevo estándar de planificación en las Américas.

Asta Powerproject te permite relacionar las actividades automáticamente, tal cual las dibujaste.

Mira el siguiente video y descubre lo fácil que es utilizar este software

¿Quieres saber más acerca de este software?

¿Necesitas una presentación personal para tu empresa?

No dudes en contactarnos en nuestra web,

envíanos un correo a: jluna@metacontrol.com.pe

o llámanos a los teléfonos: +511 6735216, +51 965393894

Con mucho gusto atenderemos todas tus consultas

PROGRAMACIÓN EN PROYECTOS LINEALES

Autor: Ing. Felix Soto Morales

Autor: Ing. Felix Soto Morales

Por: Felix Soto Morales

Los últimos ocho años los he dedicado a promover la mejora en los estándares de control de proyectos de las empresas.  Así me gano la vida.

Por eso, cuando hace ya algunos años oí hablar por primera vez de softwares para programación de proyectos lineales, como pueden ser: líneas de transmisión, carreteras, tuberías, edificios, etcétera; los miré, los estudié y los probé; sin embargo, nunca llegué a darles la importancia necesaria, ya que no tenían mucha promoción.

De hecho, este tipo de software sigue en desarrollo en el mundo y poco a poco se está consolidando.

Como súper usuario del Método de Ruta Crítica (Critical Path Method o CPM), con el uso de Primavera P6 lo dejé de lado.  No fue sino hasta el año pasado, que pude ser testigo del despegue de dos softwares en particular para la programación de proyectos lineales.

Cuando he visitado empresas constructoras de carreteras, he visto cómo tratan de aplicar a sus proyectos el CPM, ya sea en Microsoft Project o en Primavera.  Otras empresas emplean efectivamente cartas de lectura Tiempo–Locación o Líneas de Balance.  Aunque debo decir que estas últimas son hechas en Excel o incluso son dibujadas en Autocad, lo cual hace muy dificultoso su seguimiento o actualización.

¿Qué es un diagrama Tiempo-Locación?

Este gráfico es muy usado en la industria de la construcción para programar recursos cuyas actividades son repetitivas y se dan a lo largo de un espacio.

grafico LocationEjemplo: tender cables de transmisión durante varios kms.

Observen que el eje X contiene la localización, la cual puede ser referida en kms, pisos, Nº de torre, etc; dependiendo de lo que se evalúa.

El eje Y representa el tiempo.

Tratemos de darle una interpretación al gráfico mostrado:

Este proyecto se ejecuta desde el kilómetro 0 hasta el 80 y tengo 90 días para ejecutarlo.  Tengo tres actividades: La actividad 1 se realiza durante los 80 kilómetros y dura 30 días.  La actividad 2 también se realiza durante los 80 kms. y tiene una duración de 60 días.  Por último, la actividad 3 se realiza durante todo el trayecto y dura 30 días.

¿Puedes deducir que la velocidad de las actividades 1 y 3 son iguales y que la actividad 2 es más lenta?, ¿Qué pasaría si la actividad 1 se atrasa?.  Su pendiente subiría y podría cruzarse con la actividad 2, lo cual no podemos permitir, ya que en este tipo de proyectos no podemos tener cruce de actividades.

¿Te das cuenta de la importancia del espacio o locación para este tipo de proyectos? Recuerda: es lineal y no deberían confluir muchos recursos.  ¿Te imaginas trabajando todas las especialidades en un mismo piso en la construcción de un rascacielos?

Observen ahora cómo puede verse la planificación de un proyecto lineal repetitivo en un software CPM como Primavera o Microsoft Project.

Cuadro actividades¿Podrás ver los cruces?, ¿podrás ver claramente los efectos de que una cuadrilla se atrase? ¿cuántas páginas de impresión tendrá tu cronograma?, ¿podrías decidir de antemano cuándo disminuir gente para desacelerar una cuadrilla, de manera que no haya cruces?, ¿puedes planificar el mantenimiento de tus equipos, para que no afecte el tiempo de entrega de tu proyecto?, ¿puedes ver la desaceleración que produciría trabajar en temporada de lluvia?

Te deseo la mejor de las suertes… pero me inclino por el gráfico de Tiempo-Locación (T-L).

Sin embargo, el gráfico de Tiempo-Locación debe ser actualizado y es ahí donde el Excel o un dibujo bonito en Autocad pasa de ser sencillo a convertirse en una verdadera pesadilla.

Es por la actualización que se sugiere el uso de un software sofisticado.

En un siguiente artículo hablaremos en detalle de un software para programación de proyectos lineales que viene ganando más mercado en el mundo, a medida que muestra su confiabilidad.  Su nombre: TILOS.

Espero que este post haya sido de su agrado y aprovecho para invitarlo a seguir uno de mis cursos en UDEMY: Tilos-Programación de proyectos lineales, utilizando el código de cupón: Solo20Tilos, el costo del curso será de tan sólo USD 20.00, nada mal para comenzar a especializarse.

Más artículos en: www. metacontrol.com.pe/articles.html