SOUTHERN PERU EXPLOTA NUEVAS HERRAMIENTAS DE GESTIÓN DE PROYECTOS CON POWERPROJECT

Image

Haz clic en la imagen para ver el PDF

Advertisements

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

 

 

 

 

HOW TO REALLY DISTINGUISH HARD/SOFT LOGIC IN YOUR SCHEDULE

By: Felix Soto Morales

Not too many people see the importance to differentiate between hard and soft logic when scheduling their programmes, although it is well referenced into PMI´s PMBOK and AACE´s TCM.  Let me explain the concepts in short in order to get deep into the subject I want to deliver.

Hard Logic

It is about mandatory logic either contractual or physical. For example, when building a column, everybody knows that formwork comes before pouring concrete, that is a physical condition, and maybe the planner will put a Finish-to-Start link to depict it into the schedule. The contractual logic on the other hand is derived from the contract itself and many times it is a demand from the owner; let’s say the client wants an specific area done before the other one, that need becomes mandatory so the contractor must follow that sequence of work, in other words it is mandatory.

Both, physical and contractual logics are considered as Hard or Mandatory logic, one because it would be impossible to do it some other way and the other because it is an owner necessity.

Soft Logic

Sometimes referred as preferential or discretionary logic.  These are the kind of logic touched by the hand of the planner/scheduler.  For example, after accomplish with contract requirements on the schedule, a contractor decides to work on two buildings in parallel because they will give a better usage to their expensive crane, only one building has a contract deadline, but instead building one after another, they prefer to do them at the same time. That is a discretional or called soft logic.

Is it important to distinguish among them?

Yes of course, as a planner I prefer to avoid much soft logic in the critical path, if so, that path will be easy influenced to be changed because during the work, decisions could lead us any other way just because it was never mandatory to follow that way.

From the forensic schedule analyst point of view, imagine you are about to perform a Collapsed-As-Built methodology in order to demonstrate an extension of time claim, and you chose this method because maybe you didn’t have a baseline to work with, then one of the most difficult part to you as an expert could be going backwards in time without any clue how the original link was in the tasks.  We can deduct contractual and physical ones but, what about the discretional ones?  Will you have a voice whispering how things happened? Will records have detail enough to tell you the story in these cases? Maybe they won’t.

A solution for you

Of course it’s not that simple as to put notes or use a user defined field on your P6 schedule, that doesn’t work, at least for me.  Some time ago I started to use Asta Powerproject because I started to realize many experts had changed to this tool.  In Asta I have found the feature I was looking for and I proceed to show you:

Step 1 shows the types of links I had configured before starting to schedule

On the Step 2 you schedule but considering the proper type of link assigned to each relationship between activities.

The Step 3 is to enjoy with the benefits of having distinguished all types of links

Above, I show one contractual link in blue, two discretionary links in sky-blue and the remaining are the physical ones in black.

Now, as a peer reviewer you can turn off hard logic to see only soft logic in order to analyse what the scheduler/planner/contractor has chosen as a path to follow, and it will depend on you to accept, reject or suggest something new for these logics.

With this, the owner could see a more transparent schedule coming from the contractor or the forensic analyst could have a huge help in order to perform his forensic methodology. Differentiating links types could help us in having a more comprehensible schedule for the project team.

Do you think this could be useful in your job?

Follow us: Facebook, Linkedin, YouTube

Our web: www. metacontrol.com.pe/articles.html 

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

 

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.

ACERCA DE VALOR GANADO

valor-ganado

Por: Felix Soto Morales

La aplicación de la Teoría de Valor Ganado para el control de proyectos es bien difundida en todo el mundo, ésta se basa en el control de tres parámetros:  la performance, el plazo y los costos del proyecto.

Buscar información en la internet de esta teoría es muy sencillo así como su aprendizaje.  La mayoría de empresas usa índices CPI o SPI para reportar el estado o salud del proyecto en un punto dado de medición.  Sin embargo, -y menciono esto basado en el gran número de empresas que he podido visitar- no aplica la teoría completa de la técnica de Valor Ganado.

Para mí, EVM consiste en dos partes bien diferenciadas:

¿Cómo está mi proyecto? Esta parte de la técnica es aplicada por las empresas sin problemas, involucra recolección de datos, análisis y presentación de los mismos en dashboards a veces muy bien elaborados y vistosos.

¿Cómo finalizará mi proyecto? Aquí hacemos el rol de un Nostradamus del siglo XXI e intentamos predecir cómo acabará el proyecto, dado el estatus identificado en la primera etapa del análisis de Valor Ganado.

En esta última etapa de predicción de datos, es cuando muchas empresas dejan la técnica para iniciar su propia metodología, muchas veces nacidas de forma empírica.  Y ¿eso está mal?  Por supuesto que no.  Pero me pregunto ¿por qué no confiamos en esta parte de la técnica como lo hacemos con la primera?

¿Será que cuando hay datos 100% reales, podemos seguir una teoría al pie de la letra, pero cuando encontramos incertidumbre o datos que no son 100% comprobables, decidimos dejar la teoría para buscar nuestros propios caminos?  Sinceramente, no lo sé.

La técnica de predecir con Valor Ganado es sencilla y bastante confiable, hasta donde la he aplicado.  Sin embargo, su extrema sencillez hace que a veces no podamos explicar los resultados y no nos sintamos tan seguros a la hora de reportarlos.

A continuación explico cómo se predice con la técnica de valor ganado una vez obtenidos los datos de la primera etapa (recolección de datos y análisis):

La pregunta del millón de los gerentes de proyectos es: ¿Cuánto será el costo real de mi proyecto?  Al inicio del proyecto se tiene un presupuesto.  Éste, por sus siglas en inglés se llama Budget at Completion o BAC.  Es también llamado el valor planeado total del proyecto o PV.  A medida que el proyecto progresa, todos lo supuestos tomados para hacer el presupuesto son validados o descartados, por tanto se producen variaciones.

Se debe hacer entonces un nuevo estimado del costo total del proyecto.  Este estimado toma en cuenta las condiciones actuales del proyecto y toda la experiencia acumulada a la fecha.  Este nuevo estimado se llama Estimate at Completion (EAC) o Estimado al fin de proyecto.  El EAC responde pues a la pregunta del millón.  Incluye todo el dinero gastado a la fecha (AC-Costo Actual) y el estimado de lo que queda por gastar (ETC) Estimate to Complete.

Entonces,   EAC= AC + ETC

Como el costo actual (AC) es inamovible, es el ETC sobre el cual podemos obtener resultados diferentes o con incertidumbre; sin embargo, la técnica del valor ganado es clara en hallar los diferentes ETCs que podemos obtener.  A continuación, los cuatro métodos mayormente usados (aunque existen otros):

Método 1

Considera que cualquier costo ocurrido para completar las tareas del proyecto son un caso aislado y no se piensa que tenga que ver nada con la performance futura.  Por lo tanto, pensamos que lo que queda por hacer debería ir acorde con lo presupuestado originalmente.

ETC1 = BAC – EV (donde EV es el valor ganado a la fecha).

Método 2

Considera que lo ocurrido hasta la fecha explica muy bien el escenario futuro.  De esta manera, procedemos a extrapolar la tendencia.

ETC2 = (BAC – EV) / CPI

Si el CPI ha sido malo (menor a 1), obtendremos valores por encima del presupuesto original y diremos que estamos mal en dichas partidas o en todo el proyecto según sea el caso, si el CPI es mayor a 1, obtendremos valores de ahorro.

Método 3

Involucra al plazo como componente base de los cálculos de proyección.  Así, si el proyecto está atrasado, será necesario un esfuerzo de aceleración para acabar a tiempo.  Esta aceleración costará dinero, por lo tanto se utilizará el índice SPI.  Si el proyecto está adelantado (SPI mayor a 1) significaría un ahorro, gracias a que se generaría menores costos al ahorrar tiempo.

ETC3 = (BAC – EV) / (CPI * SPI)

Método 4

Cuando no nos convence ninguno de los métodos anteriores podemos recurrir a generar un nuevo estimado completamente de cero, esto es común cuando se ha producido una aceleración del proyecto, hay cambios de alcance, el proyecto no se ha comportado en absoluto como pensamos originalmente, se ha cambiado los procesos constructivos, etc.

ETC4 = Nuevo estimado para el saldo del trabajo. (No hay fórmulas)

El equipo del proyecto usa cualquiera de los métodos que cree más apropiado para estimar el costo del trabajo que queda por hacer.

Siglas utilizadas en este post:

BAC: Budget at completion o presupuesto original o línea base

EAC: Estimate at Completion o Estimado a fin de proyecto

ETC: Estimate to Complete o Estimado del saldo

PV: Planned Value o Valor planeado

EV: Earned Value o Valor Ganado

AC: Actual Cost o costo actual

CPI: Cost Performance Index o Indice de Performance de Costo

SPI: Schedule Performance Index o Indice de Performance de Plazo.

ACTIVITY ID – INTELLIGENCE IN SCHEDULES

activity-id

By: Felix Soto Morales

Several months ago, I started to write these posts (articles or however you might call them) in order to help people involved in Project Controls to improve their jobs in the construction sector, which is the one I am involved into.  Sharing knowledge is one of the things I really enjoy.  I didn’t know this, months ago.

I realized during these months that english speakers are more interested in these technical topics than spanish speakers. This is why -and in spite of my limited english (IELTS average 7, not too bad really)- I have decided to start writing my posts in english.  I wish this don’t represent a problem for our friends who have enjoyed the posts in spanish until today.

Now let’s get into this week’s topic: The use or not of intelligent activity IDs.

First of all, what is to give intelligence to an activity ID?

The identifier of the activity could be a number or group of characters alphanumeric or not. We say there is no intelligence for example in the table below:

activity-id-1

Notice that in this list, the activity ID is just a sequence of numbers, the increment could be 1 or 10, but still without meaning for the schedule.  It tells us nothing.

Now, let’s make a little but significant change:

activity-id-2

Although the logic and the structure of the schedule is the same (same finish date, logic, constraints, critical path, etc.); now, it is possible to understand through the activity ID what it is about.

In this case for example, the first three digits means the phase of the project:

ENG for Engineering

PRO for Procurement

CON for Construction

COM for Commissioning

The next three digits have a meaning also and they refers to the speciality:

ARC for Architectural

CIV for Civil

MEC for Mechanical

GEN for General

The next digits don’t have any meaning in the activity ID, they are just numbers sequenced.

But… How is this helpful?

The view or layout most used when presenting schedules is -with no doubt- the grouping by WBS.  Sometimes, when the schedulers want to point out something else, they use activity codes in order to have other alternatives for grouping.  For example, if your WBS structure that does not contain speciality, you can add an activity code called “speciality” and add their values to each activity and then group.  However, sometimes the layout requires a “clean” presentation, with no much grouping as could be one for analyze the critical path or grouping for activities to do each week.  In these cases, is important to identify and recognize the activity, and having a good ID is beneficial.

Another use for well defined Activity IDs, for me, is when I’m tracing the logic of activities, I prefer to use the network view (sometimes called Pert view) where you can only view the “box” that represent the activity.  It becomes easy to trace the logic in this layout especially when you recognize the activity very well.

activity-id-frame-3

Finally, remember the importance of the activity IDs in most softwares, it is unique, it is the index from which all the other data join: start and finish dates, durations, costs, logic, calendars and so on.  This ID becomes the “security social number” of the activity and every thing is related to it. Having intelligence in the ID is not mandatory but very helpful.

Thank you so much, and take a look at our website for other posts or tutorials.