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

LAS BASES DE PROGRAMACIÓN ¿QUÉ SON?

bases-de-programacion

Por: Felix Soto Morales

Este documento, conocido en inglés como BOS (Basis of Schedule) es el documento más importante para conocer cómo ha sido diseñado el cronograma del proyecto.

Generalmente, es presentado al cliente al igual que un entregable.  Ya que no hay consenso en la forma de presentar este documento, luego de muchas veces de hacerlo para mis clientes, puedo decir que hay capítulos que son repetitivos. Menciono a continuación los más comunes:

Estrategia de ejecución y suposiciones

Debemos describir brevemente si el proyecto será una ejecución agresiva o fast-track.

Describir la estrategia de los contratos y principalmente hacer la descripción de los trabajos por zona o especialidad.

Fechas claves del proyecto

Colocar aquí una tabla con los hitos más importantes del proyecto y sus fechas de ocurrencia.

El Camino Crítico

Hacer la descripción de las actividades que están dentro del camino crítico.  El cliente debe lograr comprender el camino más largo que ha resultado del cálculo del software.

Algunos clientes exigen la explicación de un segundo o tercer camino crítico.  Deje que el software los calcule.

Calendarios y días festivos

Cite los diferentes calendarios añadidos al proyecto.  Es habitual utilizar un calendario para las actividades de ingeniería y otro para las actividades dentro de la etapa de construcción.  Mencionar también los días festivos considerados.

Estructura de código

Describir el código de WBS del proyecto y también el código de las actividades que servirán para los reportes.

Si le han dado alguna inteligencia en el código de identificador de las actividades, lo deberán explicar en este capítulo.

Métricas

Añadir aquí las cantidades que fueron utilizadas para calcular la duración de las actividades.

Restricciones

Si han puesto restricciones en algunas actividades, describir las razones y cómo afectan éstas a la lógica entre las actividades.

Análisis de riesgos

Siempre considero este capítulo, pero si estás haciendo la BOS por primera vez, te recomiendo que lo dejes.

Se trata de añadir las oportunidades y amenazas y cómo éstas afectan a la duración del proyecto.

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

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

SOY PROGRAMADOR… ¿DEBERÍA CERTIFICAR?

programador, certificación de un programador

Es o no importante la certificación para un programador?

Por: Felix Soto Morales

Mi vida educativa y profesional siempre fue marcada por un lema “Aprendes, sabes, entonces lo haces BIEN”.  Traducción simple: “el que sabe, sabe y punto”.  Siguiendo ese dicho durante años en mi mente, siempre me bastó tratar de ser muy bueno en lo que hago sin importarme si tenía o no títulos, diplomas, certificados, etc.  Tan es así, que hasta hace poco no tenía la más mínima idea de donde estaba mi Título otorgado por la Universidad de la que egresé tras cinco años de estudio.  Tampoco tengo ningún certificado de cuanto curso tomé para aprender.  Si alguien me refutaba simplemente ponía el ejemplo : “¿Acaso necesitas tener un certificado para hablar inglés?  Si lo hablas bien, ¿alguien te va a pedir un certificado?” Y claro, es un buen argumento.

Ahora déjenme relatar la importancia de certificarse, llevando el ejemplo a lo que actualmente me dedico.  Como leen líneas arriba, tengo dos certificados importantes en lo que se refiere a consultoría de productos Oracle Primavera.  Hace un par de años, cuando no tenía estos certificados ¿sabía lo mismo?, ¿trabaja en lo mismo?, ¿cobraba lo mismo?.  Las respuestas a esas preguntas son SÍ, SÍ y NO.  Efectivamente, antes cobraba menos, en todo caso no me sentía muy seguro de cobrar lo que cobro ahora.  Los certificados no son sólo un reconocimiento de la entidad que lo emite, sino también ante la sociedad en que nos movemos, pero sobre todo un reconocimiento para nosotros mismos, para sentirnos mejores y para motivarnos.  Creo que ese papelito sirve para darnos cuenta de lo que valemos (laboralmente hablando).

En algunas ocasiones mis alumnos me dicen que quieren obtener mis certificados, lo que les contesto es que lean bien; éstos son para consultores que implementarán Primavera en empresas.  Si quieres ser consultor, bienvenida la competencia; pero si eres un programador que trabaja en una empresa, los certificados que te corresponden y que deberías tener alguno de ellos, son: el PSP Planning & Scheduling Professional, otorgado por el AACE (Asociation for the Advancement of Cost Engineering), un instituto de gran prestigio; o el PMI-SP otorgado por el PMI Project Management Institute que no necesita presentación.  Ambos reconocen al que tiene habilidades en las herramientas de programación más allá del software utilizado.

¿Tienes dudas sobre a cuál aplicar? En un próximo post te explicaré las ventajas y desventajas  entre uno y otro certificado.

PLANNER O SCHEDULER?

article written by felix soto

Planner o Scheduler?

Por: Felix Soto Morales

De los 19 de años que tengo en el mundo de la construcción siempre he escuchado en los diferentes proyectos de muchas empresas constructoras el término planner para referirse a la persona del staff del proyecto que se dedica a elaborar y actualizar el cronograma del proyecto (usualmente Primavera). Y en realidad, este es más bien un scheduler.

Los planner son las personas que tienen en cuenta los objetivos del proyecto y son capaces de identificar cuáles son las actividades necesarias para completarlo (es la parte pensante). Y con actividades no me refiero sólo a las constructivas, sino a qué equipos serán utilizados, qué tecnología, qué fuerza laboral, dónde adquirir los materiales o equipos más relevantes, mejoras de metodologías de trabajo  y un largo etc. ¿Hay realmente un solo planner en el proyecto? Pues no. Empieza a contar: el gerente del proyecto, el jefe de proyecto, el jefe de área, el capataz o jefe de grupo y muchos otros (incluyendo al scheduler) están haciendo constantemente trabajos de planificación.

Ahora bien, el scheduler es la persona que analiza la ruta crítica, coloca restricciones, ve los efectos de los calendarios, prueba la lógica, nivela el cronograma, reporta avance, dibuja las curvas S y los histogramas y otro largo etc. Por supuesto un Scheduler también hace planeamiento, es decir es normalmente también un planner. Sin embargo un planner puede no ser scheduler.

Cuando se busca trabajo en este rubro en el extranjero se suele colocar “planner/scheduler” para buscar la posición de programador. Si colocan solo “planner”, obtendrán resultados de trabajos que no necesariamente están buscando.

Ya lo saben, la próxima vez que busquen un planner, no se confundan y digan que necesitan un scheduler o si lo quieren en español: un programador.