Integrando el Scrum a la planificación de Proyectos por Cadena Crítica

1. Introducción

¿Sería posible optimizar la Planificación de Proyectos por Cadena Crítica (CCPM) integrando a su estructura los principios del SCRUM? El gran reto dentro de la administración de proyectos es afrontar las planificaciones poco realistas, muchas veces por la ausencia de comunicación.  

Otra limitación en la gestión de proyectos es la deficiente optimización de los recursos, ya sea por la ausencia de una estrategia constructiva o por la falta de controles de calidad y seguimiento continuo en la ejecución de los proyectos. Estos y otros factores adversos como los subcontratos y el mal manejo de los suplidores son causas recurrentes de retrasos en los proyectos.

La industria de la construcción en la República Dominicana es un ejemplo tangible de tales fallas donde el gerente de proyecto tiene que atravesar por muchos inconvenientes para lograr concluirlo antes del plazo otorgado y dentro del presupuesto. Existen numerosos ejemplos y casos de proyectos reincidentes en malas prácticas, algunas tan sorprendentes como el no celebrar reuniones de seguimiento continuo en la ejecución del plan, otras, como la falta de comunicación o variación en el alcance del proyecto.

El propósito de este artículo académico es exponer los lineamientos para la integración del SCRUM en la estructura del CCPM y lograr una reingeniería de procesos en la administración de proyectos que permita abordar el manejo de los equipos multidisciplinarios para mejorar el desempeño y la productividad de los equipos de trabajo acortando los tiempos de ejecución. Este artículo tiene tres objetivos. 

El primer objetivo es identificar los principios del CCPM y el SCRUM en la gestión de proyectos, la cual puede ser definida como la disciplina del planteamiento, la organización, la motivación, y el control de los recursos con el propósito de alcanzar uno o varios objetivos (Wikipedia, 2014). 

El segundo objetivo es construir un análisis comparativo entre el CCPM y el SCRUM. Debido al planteamiento y los objetivos que persigue cada método, el establecer similitudes y diferencias es una opción para determinar cuáles procedimientos son favorables para optimizar el método de Planificación de Proyectos por Cadena Crítica (CCPM).

El tercer objetivo es presentar los resultados obtenidos al aplicar la nueva estructura metodológica en una simulación. Sin embargo, cabe destacar que fue necesario plantearlo de esta manera, ya que ninguna empresa habría de confiar sus recursos económicos, materiales, tecnológicos, humano y de tiempo para ejecutar un planteamiento atípico, por no ser una metodología tradicional. La naturaleza misma del planteamiento es un nuevo paradigma para la administración de proyectos. 

Debido a las complejidades que caracterizan los proyectos de ingeniería, si no se toman las medidas correctivas y oportunas conforme a las situaciones y eventos que surjan, se exteriorizarán fenómenos no deseados que darán al traste con los objetivos generales del proyecto.

2. Antecedentes y marco teórico

En esta sección se identifican los elementos esenciales para la planificación mediante CCPM y el SCRUM con una descripción sobre el modo de implementación y sus respectivas medidas de control. El primer desafío para la gestión de proyectos es alcanzar las metas del proyecto, y los objetivos dentro de las limitaciones conocidas. Las limitantes o restricciones primarias son el alcance, el tiempo, la calidad y el presupuesto. El desafío secundario y el más ambicioso de todos es optimizar la asignación de recursos de las entradas necesarias e integrarlas para alcanzar los objetivos predefinidos.

Este planteamiento es apropiado en proyectos donde no hay buena comprensión de los objetivos, donde no se documenta el progreso del mismo respecto al plan. Muchas complicaciones se originan porque no se actualizan los registros o no celebran reuniones periódicas, lo que imposibilita tomar medidas correctivas a tiempo. Elaborar y ejecutar un plan de comunicaciones va a resultar determinante para que el proyecto alcance los objetivos y resultados esperados.

Entre las razones de una comunicación defectuosa destacan: no definir con claridad el público objetivo, o no circunscribirse a él adecuadamente; diseñar un gran plan de comunicaciones que no se sigue, o que la comunicación no la lleve a cabo la persona adecuada (Pacelli, 2004).

La integración del equipo de dirección y su desarrollo como tal es de vital importancia para lograr los objetivos de la ejecución (Miranda, 2010). Los diversos aspectos del proceso deben ser inspeccionados con la frecuencia suficiente como para que las variaciones inaceptables en los procesos puedan ser detectadas (Schwaber, 2004). Las principales causas de fracaso de los proyectos son la insuficiente gestión del riesgo, una pobre definición del alcance del proyecto, falta de objetividad en las metas establecidas, la falta de margen de reacción y fallos de comunicación. Asimismo, las tres claves del éxito de un proyecto son: 1) involucrar a los participantes, 2) definir los objetivos de forma clara y precisa y 3) desarrollar e implementar una metodología (Online Business School, 2014).

La figura 1muestra una interpretación del informe CHAOS del año 2012 para los proyectos. En esta se representan los proyectos exitosos o acertados con un 39 %, aquellos entregados a tiempo, dentro del presupuesto, con las características y funciones requeridas; con un 43 % los proyectos fallidos, por entregar con retraso, por encima del presupuesto o con menos características o funciones requeridas, y el 18 % restante fueron proyectos deficientes, aquellos proyectos cancelados antes de finalizar o entregado y nunca utilizado (The Standish Group International, 2013).

2.1. La Cadena Crítica (CCPM)

La gestión de proyectos por cadena crítica (CCPM en sus siglas en inglés) es un método de planeamiento y gestión de la realización de proyectos que trata con las incertidumbres intrínsecas de la gestión. Tiene en cuenta la disponibilidad limitada de los recursos (físicos, habilidades humanas, gestión y capacidad) necesarios para llevar a cabo el proyecto (Wikipedia, 2014).

El Dr. Eliyahu Goldratt creador de la Teoría de Restricciones y la Administración de Proyectos por Cadena Crítica, reconoció que el personal humano es quien planea y ejecuta proyectos, no los programas de computador. Su metodología de “Cadena Crítica” se basa en la naturaleza humana y en lo que sucede cuando la disciplina de administración de proyectos se aplica al personal de trabajo. Goldratt nos dice que, a menos que seamos cuidadosos, muchas veces obtenemos lo opuesto a lo esperado (Netconsul, 2009). Goldratt descubrió que es habitual el hecho de que los proyectos se alarguen hasta su plazo máximo. Esto provoca que sea más plausible el sufrir retrasos ocasionados por otras circunstancias cuyo origen está fuera del control del administrador del proyecto (Online Business School, 2014).

Este método revolucionó el modo de administración y programación de los proyectos, porque supera las limitaciones del método Camino Crítico. Tiene en cuenta el incorrecto manejo de la incertidumbre que hace que la mayoría de los proyectos no se terminen en el tiempo esperado, con el costo esperado y con la calidad deseada. Una demora en la disponibilidad de los recursos puede retrasar un programa, tanto como un incumplimiento en las tareas pendientes.

El plan del proyecto debe someterse a una nivelación de recursos, y la secuencia más importante de tareas limitadas por recursos es considerada la cadena crítica. En algunos casos, como cuando se administran subproyectos tercerizados, se recomienda usar un enfoque simplificado sin la nivelación de recursos (Wikipedia, 2014). Un error común es intentar dar cuenta de la tarea de manera individual, causa común de variación mediante la adición de tiempo de contingencia en cada estimación (The TameFlow Chronologist, 2012).

En términos más simples, la estimación de cada pequeña tarea se amortigua con cierto margen de protección. Notablemente, la principal razón por la que esto sucede es debido a los aspectos psicológicos que están involucrados y no a causa de las pruebas fácticas. CCPM recorta los tiempos de cada tarea individual en un 50 % (The TameFlow Chronologist, 2012).

2.1.1. Teoría de las restricciones (TOC)

Theory of Constraints por sus sigla TOC. Trata a las organizaciones en forma sistémica y holística, teniendo en cuenta las leyes naturales que gobiernan cualquier entorno. El creador, Eliyahu M. Goldratt, sentó las bases en su libro “La Meta” subtitulado “Un proceso de mejora continua” (Wikilibros, 2013).

En la figura 2se hace una interpretación de la gestión de proyectos por cadena crítica.

La clave de la Teoría de las Restricciones es que la operación de cualquier sistema complejo (empresa) consiste en una gran cadena de recursos interdependientes (máquinas, equipos, centros de trabajo, instalaciones, materiales), pero solo unos pocos de ellos (cuellos de botella) restringen o condicionan la salida de toda la producción (Santos, 2012). 

Reconocer esta interdependencia y el papel clave de los cuellos de botella es el punto de partida para las empresas que adoptan TOC como filosofía, y de allí a de subordinarse todo el sistema para crear las soluciones simples y compresibles por todos para sus problemas complejos (Santos, 2012).

El proyecto debe de estar orientado a una meta; es un sistema abierto ya que requiere de entradas externas, es dinámico porque un proyecto no se comporta como un sistema lineal y debido a la complejidad del proyecto debe considerarse debidamente la incertidumbre y los requerimientos técnicos y de negocios.

Para aplicar La Teoría de las Restricciones (TOC) dos factores fundamentales deben identificarse al inicio de los proyectos: 1) Que tenga una estructura jerárquica–piramidal y 2) Que la disposición organizacional conlleve una sucesión de actividades en cadena. El rendimiento de cualquier cadena estará siempre determinado por la resistencia de su eslabón más débil. Conocida como limitaciones del sistema o restricciones (elementos que impiden al sistema alcanzar la meta). La TOC se centra, fundamentalmente, en la búsqueda del flujo perfecto de bienes o servicios a través de una cadena de valor balanceada, coordinada y sincronizada de estaciones de trabajo, logrando así bajar los costos de operación, reducir los inventarios y aumentar las ventas (Moreno, 2013).

El cuello de botella es la estación de trabajo más lenta, y es lógico pensar que a la entrada de esta se formará una cola de elementos tangibles para ser procesados, la cantidad de elementos presentes en esta fila es directamente proporcional a la velocidad de las estaciones anteriores al cuello de botella (Moreno, 2013).

Goldratt planteó cinco pasos a seguir para implementar la metodología de la cadena crítica. Estos cinco pasos son (Moreno, 2013):

1. Identificar las restricciones del sistema: una restricción es una variable que condiciona un curso de acción. Pueden existir distintos tipos de restricciones, siendo las más comunes las de tipo físico: maquinarias, materia prima, mano de obra, etc.

2. Explotar las restricciones del sistema: implica buscar la forma de obtener la mayor producción posible de la restricción.

3. Subordinar todo a la restricción anterior: todo el esquema debe funcionar al ritmo que marca la restricción (tambor).

4. Elevar las restricciones del sistema: implica encarar un programa de mejoramiento del nivel de actividad de la restricción.

5. Si en las etapas previas se elimina una restricción, volver al paso uno: para trabajar en forma permanente con las nuevas restricciones que se manifiesten.

2.1.2. Sistema DBR

Es la herramienta más conocida que ha desarrollado Goldratt. El origen de este nombre se remonta a la analogía utilizada en el libro “La Meta” para describir un sistema con dependencias y fluctuaciones estadísticas. La analogía era una descripción de una excursión de boy scouts. El tambor es el boy scout con el ritmo más lento que dicta la velocidad para los demás, el amortiguador y la cuerda son medios adicionales para asegurar que todos los boy scouts marchen aproximadamente al ritmo del más lento. Es importante destacar que DBR es un método de planificación, no un método de control y en cierta medida deja espacio para la variación interna y externa de la incertidumbre en el entorno de producción. Pero como con cualquier otro tipo de plan, no se puede anticipar y adaptarse a todos los posibles problemas que puedan interrumpir el flujo de trabajo a través del proceso (Santos, 2012).

La manera de aplicar la Teoría de las Restricciones en las empresas industriales está sujeto al método (tambor-amortiguador-cuerda) quien establece los medios para la sincronización de un proceso de fabricación subordinado a la restricción del sistema.

El método de la cadena crítica identifica una serie de tiempos de protección y tolerancias que asignamos a una tarea las cuales son inducidos por el comportamiento humano, dichos tiempos se basan en dos teorías: el síndrome del estudiante y la ley de Parkinson (quees.info, 2013). 

Un buffer es una actividad ficticia, asociada a una actividad real y con una duración determinada, que se añade en un punto concreto del cronograma del proyecto al objeto de tener en cuenta posibles desviaciones (temporales) de las actividades (Universitat Politècnica de Catalunya, 2012).

Un buffer es una protección contra la incertidumbre. La protección es agregada y puede tomar la forma de tiempo, stock (inventario), capacidad, espacio o dinero. Los buffers están estratégicamente localizados para proteger el sistema de los atrasos y el descontrol (Sullivan, 2012).

La estimación de los tamaños de los buffers de un proyecto es uno de los puntos más espinosos de la planificación, por cuanto es muy difícil establecer reglas generales. Solo la experiencia o la comparación con casos similares permitirán realizar una valoración correcta —ni optimista ni pesimista— (Universitat Politècnica de Catalunya, 2012). 

La figura 3 representa una correcta gestión del buffer para un proyecto que consta de tres actividades; en dicho proyecto, los tiempos reducidos para las apreciaciones individuales de cada actividad se agrupan al final de la red de actividades del proyecto y se recorta a la mitad.

La desviación estimada de una actividad deberá ser mayor cuanto mayor sea el margen de seguridad que queramos establecer. Por ejemplo, una certidumbre del 80 % supone establecer una desviación en cada actividad del 40 % (Universitat Politècnica de Catalunya, 2012).

El margen de resguardo considerado en cada actividad se hace para protegerse ante la incertidumbre. Es importante destacar que este margen de protección asignado a cada actividad frecuentemente alcanza a tener una duración promedio igual al tiempo que dure la actividad, para una probabilidad efectiva de un 95 %. Ver representación del buffer o margen de protección en la figura 4.

La figura 5 representa el síndrome del estudiante y la ley de Parkinson; fenómenos conductuales muy notables en el factor humano al desempeñar una tarea en comparación con su estimación. Según la ley de Parkinson, la actividad (sombreada en color azul) se dilata hasta consumir el tiempo planificado de ejecución. Por el contrario, el síndrome del estudiante produce un máximo estrés, ya que la actividad tiene un inicio tardío (sombreado en color gris), se consume todo el tiempo hasta agotar el buffer del proyecto (color amarillo) y cuando se inicia la actividad (color verde) ya es demasiado tarde para cumplir con los plazos de entrega y los requerimientos exigidos. Como resultado, es imposible alcanzar la calidad esperada, se solicita extensión en los plazos, se hace entrega incompleta y cada imprevisto se vuelve inmanejable.

Buffer burn rate. El buffer burn rate (tasa de consumo del buffer) es una medida global de la tasa en que el buffer está siendo consumido por el proyecto a la fecha. El uso del buffer burn rate es usado para responder las preguntas ¿Es satisfactorio el progreso general del proyecto? ¿Cuál es el estado actual de proyecto? Una tasa de consumo del buffer equivalente a 1 o menor, es bueno. La primera medida del estado del proyecto es el porcentaje de la cadena crítica completado y la tercera métrica es la tasa de consumo del buffer del proyecto (Sullivan, 2012).

Cuando la tasa de consumo del buffer es menor que 1.0, el estado del proyecto se indica en verde. Si la razón de consumo del buffer es aproximadamente 1.0, el estado del proyecto se muestra en amarillo. Pero si dicha tasa es algo mayor que 1, el estado del proyecto se indicará en rojo. El director de proyecto es responsable de determinar la región correspondiente a la zona amarilla (Sullivan, 2012).

Un diagrama de estado de proyectos es una gráfica que refleja el estado de avance o retraso de uno o más proyectos. En el eje horizontal se indican los porcentajes consumidos al buffer del proyecto; y en el eje vertical, los porcentajes de avance en la cadena crítica. Los colores verde, amarillo y rojo sirven para alertar sobre el estado del proyecto (antes del tiempo, dentro del tiempo y retraso). Ver diagrama con

2.2. Estructura del SCRUM

Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas prácticas para trabajar colaborativamente, en equipo, y obtener el mejor resultado posible de un proyecto. Estas prácticas se apoyan unas a otras y su selección tiene origen en un estudio de la manera de trabajar de equipos altamente productivos (Proyectos Ágiles, 2008). Scrum está especialmente indicado para proyectos en entornos complejos, donde se necesita obtener resultados pronto, donde los requisitos son cambiantes o poco definidos, donde la innovación, la competitividad, la flexibilidad y la productividad son fundamentales (Proyectos Ágiles, 2008).

Scrum también se utiliza para resolver situaciones en las que no se está entregando al cliente lo que necesita, cuando las entregas se alargan demasiado, los costes se disparan o la calidad no es aceptable, cuando se necesita capacidad de reacción ante la competencia, cuando la moral de los equipos es baja y la rotación alta, cuando es necesario identificar y solucionar ineficiencias sistemáticamente o cuando se quiere trabajar utilizando un proceso especializado en el desarrollo de producto (Proyectos Ágiles, 2008).

Muchos de los fracasos de los equipos de desarrollo de aplicaciones son porque no cuentan con metodologías ni procesos que permitan cumplir con las expectativas de calidad, tiempo y alcance a costos razonables. Se estima que al menos el 15 % de los proyectos de IS (Information System) son entregados cumpliendo con todos los requerimientos iniciales y en la fecha previamente establecida. Lo que sucede habitualmente es que los proyectos se extienden en el mayor de los casos, entre el 30 % a 120 % del estimado en principio. El problema central está en la aplicación de metodologías convencionales que no van acorde ni se ajustarán a los tiempos trazados por su manera de implementación. Las metodologías tradicionales como lo son el modelo en cascada y espiral están basadas en la validez de este supuesto y por consiguiente están diseñados para determinar todos los requerimientos en la primera etapa y no están preparadas para afrontar los cambios constantes, razón principal de las extensiones de tiempo (Vásquez, 2012).

 llevó a poner en práctica el Scrum en su compañía, Advanced Development Methods. Por aquel tiempo Jeff Sutherland desarrolló una aproximación similar en Easel Corporation y fue el primero en denominarla Scrum. En 1995 Schwaber y Sutherland, durante el Object-Oriented Programming Systems, Languages, and Applications (OOPSLA) desarrollado en Austin, presentaron en paralelo una serie de artículos describiendo Scrum, siendo esta la primera aparición pública de la metodología. Durante los años siguientes, Schwaber y Sutherland, colaboraron para consolidar los artículos antes mencionados, así como sus experiencias y el conjunto de mejores prácticas de la industria que conforman lo que ahora se le conoce como Scrum. En 2001, Schwaber y Mike Beedle describieron la metodología en el libro Agile Software Development with Scrum (Rodrygo, 2010).

El Scrum, a pesar de tener una serie de pasos para llegar a un resultado, no se considera un método, sino más bien un conjunto de disciplinas no imperativas para mejorar los resultados a través del seguimiento periódico a las tareas que se ejecutan durante un ciclo de tiempo. Scrum no es un proceso fijo, ni un método ni muchos menos una práctica. Es el conjunto de principios que los métodos, para el desarrollo ágil, tienen en común. Scrum se refiere al modo de pensar, las convicciones y las preferencias expresadas en el manifiesto de desarrollo ágil (Verheyen, 2013). Un conjunto de prácticas y disciplinas no llega a la categoría de método y un método prevalece por encima de la disciplina, y es por esta razón que el CCPM por ser un método, absorbe al Scrum y no al contrario. (González, 2014).

2.2.1. Características

Scrum es un modelo de referencia que define un conjunto de prácticas y roles, y que puede tomarse como punto de partida para definir el proceso de desarrollo que se ejecutará durante un proyecto. Los roles principales en Scrum son el Scrum Master, que mantiene los procesos y trabaja de forma similar al director de proyecto, el Product Owner, que representa a los stakeholders (interesados externos o internos), y el Team que incluye a los desarrolladores (Wikipedia, 2014).

Durante cada sprint, un periodo entre una y cuatro semanas (la magnitud es definida por el equipo), el equipo crea un incremento potencialmente entregable (utilizable). El conjunto de características que forma parte de cada sprint viene del Product Backlog, que es un conjunto de requisitos de alto nivel priorizados que definen el trabajo a realizar. Los elementos del Product Backlog, que forman parte del sprint, se determinan durante la reunión de Sprint Planning. Durante esta reunión, el Product Owner identifica los elementos del Product Backlog que quiere ver completados y los hace del conocimiento del equipo. Entonces, el equipo determina la cantidad de ese trabajo que puede comprometerse a completar durante el siguiente sprint. Durante el sprint, nadie puede cambiar el Sprint Backlog, lo que significa que los requisitos están congelados durante este tiempo (Wikipedia, 2014).

Las características más marcadas que se logran notar en Scrum serían: gestión regular de las expectativas del cliente, resultados anticipados, flexibilidad y adaptación, retorno de inversión, mitigación de riesgos, productividad y calidad, alineamiento entre cliente y equipo, por último, equipo motivado (Wikipedia, 2014). Existen varias implementaciones de sistemas para gestionar el proceso de Scrum, que van desde notas amarillas “post-it” y pizarras hasta paquetes de software. Una de las mayores ventajas de Scrum es que es muy fácil de aprender, y requiere muy poco esfuerzo para comenzarse a utilizar. 

En 1993 se realizó el primer Scrum para desarrollo de software. Desde 1995 miles de proyectos en todo el mundo han utilizado Scrum para el desarrollo de productos, tanto en empresas pequeñas, “startups” con tan solo tres personas desarrollando un producto, como en multinacionales (Proyectos Ágiles, 2008).

2.2.2. Scrum técnico

Al abordar pragmáticamente las implementaciones más flexibles de Scrum se pueden adoptar dos tácticas diferentes para mantener un avance continuo en el proyecto: 1. Incremento iterativo: basado en pulsos de tiempo prefijado (timeboxing), y 2. Incremento continuo: basado en el mantenimiento de un flujo continuo, no marcado por pulsos o sprints. Al usar Scrum técnico se trabaja con sprints, y por tanto con incremento iterativo. En un desarrollo iterativo e incremental el proyecto se planifica en diversos bloques temporales (en el caso de Scrum de un mes o hasta de dos semanas, si así se necesita) llamados iteraciones. Ver diagrama del ciclo iterativo Scrum representado en la figura 8.

La pieza clave es el sprint. Se denomina sprint a cada ciclo o iteración de trabajo que produce una parte del producto terminada y funcionalmente operativa —incremento— (Palacio, 2014).

En cada iteración el equipo evoluciona el producto (entrega incremental) a partir de los resultados completados en las iteraciones anteriores, añadiendo nuevos objetivos/requisitos o mejorando los que ya fueron completados. Un aspecto fundamental para guiar el desarrollo iterativo e incremental es la priorización de los objetivos/requisitos en función del valor que aportan al cliente (Proyectos Ágiles, 2008).

Los requerimientos Ágiles son representados como “Historias de Usuario” (User stories), las cuales son una pequeña descripción del requerimiento del usuario, en un lenguaje lo más aproximado a su jerga diaria. Se hace un énfasis muy fuerte a que este tipo de comunicación esté orientada al usuario final y que sea fácil de entender. Estas historias definen alcances fáciles de identificar para poder efectuar planes iterativos para definición, revisión y confirmación de los mismos (Velázquez, 2012).

2.2.3. Graficando el estado del proyecto

Burndown chart es una gráfica mostrada públicamente que mide la cantidad de requisitos en el Backlog del proyecto pendientes al comienzo de cada Sprint. Dibujando una línea que conecte los puntos de todos los Sprints completados, podremos ver el progreso del proyecto. Lo normal es que esta línea sea descendente (en casos en los que todo va bien, en el sentido de que los requisitos están bien definidos desde el principio y no varían nunca) hasta llegar al eje horizontal, momento en el cual el proyecto se ha terminado. Si durante el proceso se añaden nuevos requisitos la recta tendrá pendiente ascendente en determinados segmentos, y si se modifican algunos requisitos la pendiente variará o incluso valdrá cero en algunos tramos (EcuRed, 2014).

 El diagrama de Burndown es útil para saber el tiempo que falta para completar el trabajo. Normalmente se utiliza para conocer cuánto falta para terminar las historias comprometidas en un sprint (Romeu, 2013). Un gráfico de trabajo pendiente a lo largo del tiempo muestra la velocidad a la que se está completando los objetivos/requisitos. Permite extrapolar si el Equipo podrá completar el trabajo en el tiempo estimado (Proyectos Ágiles, 2008). Es una representación gráfica del trabajo por hacer en un proyecto en el tiempo. Por lo general, el trabajo remanente (o backlog) se muestra en el eje vertical y el tiempo en el eje horizontal. Representa una serie temporal del trabajo pendiente. Este diagrama es útil para predecir cuándo se completará todo el trabajo (Wikipedia, 2013).

La figura 9 representa un diagrama de tiempo transcurrido, con los avances de obra para una iteración completa. Este muestra la serie temporal del esfuerzo remanente para cada uno de los 30 días hábiles en un sprint o iteración de un mes. La línea de color verde indica lo planificado, en rojo el progreso real del proyecto y en naranja las deficiencias; sombreando los avances o retrasos con un patrón rayado en ángulo.

Otro recurso aplicado en el Scrum es el tablero o mural de trabajo (taskboard). Una de las grandes virtudes de Scrum es la transparencia, la habilidad de mostrar lo que sucede en todo momento, ya sea bueno o malo. Para conseguirlo, una de las herramientas que utilizamos es el taskboard, el cual podemos comparar como el espejo del trabajo diario del equipo. Es un elemento visible físicamente por todo el mundo y que muestra información relevante relacionada con el proyecto y el equipo (albertcumplido, 2013).

Características de un mural físico de trabajo o taskboard

1. El tablero de trabajo está definido por cuatro (4) columnas. La columna uno (no planificada), contienen las historias de usuario (pequeña descripción de los requerimientos del usuario); la columna dos contiene las historias que aún no han dado inicio; en la columna tres están contenidas todas las historias en progreso; y, finalmente, la columna cuatro, muestra todas las historias completadas
2. El tablero solo contiene las historias de usuario planificadas para el sprint que se encuentra en proceso.
3. Las historias de usuario deben ordenarse según prioridad, iniciando arriba con la de mayor prioridad y terminando abajo con la de menor.
4. Cada actividad o tarea (historia de usuario) está representada sobre una pegatina de color (post-it) y también contiene el nombre del responsable de la tarea.
5. Otra información importante que contiene el tablero de trabajo es el gráfico de las horas pendientes del sprint según estimación (diagrama de tiempo transcurrido o burndown chart).
6. En él se refleja cualquier otra información necesaria que ayude en la ejecución del trabajo. Asimismo, sirve para visualizar el flujo de trabajo, lo que permite distinguir aspectos a mejorar dentro del proceso.
7. Como cada tarea (historia de usuario) presente en el tablero contiene el nombre del equipo responsable, nos permite visualizar qué hace cada miembro del equipo.
8. El tablero de trabajo nos permite identificar posibles cuellos de botella.

3. Metodología de la investigación 

Hasta el momento, junio de 2019, no se pudo identificar ningún estudio de investigación que profundice sobre la aplicación eficaz del CCPM integrando el Scrum. Cabe destacar que existen diversos foros de internet en los que se ha tratado este tópico, en cuyos participantes se refleja el deseo y la estimulación de encontrar el modo de implementarlos juntos en un mismo proyecto, por conocer los beneficios de ambas metodologías de manera aisladas, aunque no han encontrado el medio de introducir una dentro de la otra.

La investigación es de tipo descriptiva, llamada también investigaciones diagnósticas. Consiste, fundamentalmente, en caracterizar un fenómeno o situación concreta indicando sus rasgos más peculiares o diferenciadores. El objetivo de la investigación descriptiva se basa en llegar a conocer las situaciones, costumbres y actitudes predominantes a través de la descripción exacta de las actividades, objetos, procesos y personas (Morales, 2009).

El propósito es describir situaciones y eventos; esto es, decir cómo es y cómo se manifiesta determinado fenómeno. De modo que, en esta investigación se identificaron los fundamentos del CCPM y del SCRUM, se analizaron las similitudes y diferencias entre ambas para concluir con el aporte, el planteamiento de la nueva fusión metodológica CCPM+SCRUM. La información se obtuvo substancialmente de la recopilación bibliográfica y el internet. En vista de que no hay ningún antecedente sobre este planteamiento, esta investigación suponía ser una investigación de tipo exploratoria; pero debido al amplio conocimiento y a la suficiente documentación sobre ambas metodologías, se optó por realizar una investigación de tipo descriptiva. Se seleccionó un caso que permita aplicar la nueva estructura metodológica, basado en la simulación de un proyecto de ingeniería. En ella se empleó la observación y el análisis de los resultados para emitir una conclusión sobre el pragmatismo de la nueva estructura metodológica, pero primero se realizó un análisis de las fuentes bibliográficas.

El procedimiento para la investigación descriptiva fue el siguiente:

1. Examinar las características del problema escogido.
2. Elegir los temas y las fuentes apropiados.
3. Seleccionar o elaborar técnicas para la recolección de datos.
4. Establecer categorías precisas, a fin de clasificar los datos que permitan manifestar semejanzas, diferencias y relaciones significativas.
5. Verificar la validez de las técnicas empleadas para la recolección de datos.
6. Realizar observaciones objetivas y exactas.
7. Describir, analizar e interpretar los datos obtenidos, en términos claros y precisos.

Se obtuvo una conclusión gráfica para representar la planificación y programación de un proyecto, cuyos hallazgos y experiencia en el desarrollo del proceso investigativo son presentados en la sección de resultados y conclusiones, aportando además recomendaciones del propio criterio que muy bien pronosticarían el éxito de cualquier proyecto, si se ponen en prácticas.

3.1. Referencias del caso aplicado

Basado en las investigaci ones realizadas y buscando estratégicamente las herramientas necesarias para dar solución a las problemáticas planteadas, se propuso crear una nueva estructura metodológica para la planificación y gestión de proyectos de ingeniería civil, cuyos fundamentos son el CCPM y Scrum.

La intención es crear un proyecto de ingeniería simulado, apegado a la realidad en donde la nueva estructura planteada se aplique de manera práctica, que sea objetiva y tenga el menor sesgo posible. La idea de una simulación surge por la imposibilidad que existe de poner en práctica dicho planteamiento en un proyecto real, ya que primeramente vivimos en una cultura donde los estándares tienen un protagónico tan enraizado que han llegado a convertirse en paradigmas que impiden el surgimiento de nuevas ideas, conceptos y planteamientos; y segundo, porque nuestra sociedad sufre de una parálisis paradigmática, por lo que se mantiene todo el tiempo en la zona de confort, rehusándose al cambio. Lo anterior da origen a una entropía negativa que les impide buscar nuevas herramientas, materiales, metodologías y formas de optimizar procesos. 

Cabe destacar que no es posible aplicar de manera real este planteamiento, ya que ningún empresario o empresa ha de confiar sus recursos tanto económicos, materiales, tecnológico, humano y de tiempo para ejecutar un proyecto con un trazado atípico, y que por la naturaleza misma del planteamiento no es una metodología tradicional, sino más bien novedosa, pues establecería nuevos paradigmas en la administración de proyectos. El referido planteamiento es nuevo, podrían entender que no les ofrece garantía de que dicha metodología reduciría los retrasos, los sobrecostos y muchos fallos en los procesos, aun cuando en realidad, generaría un ahorro significativo en tiempo y materiales, por ende, de dinero; aumentaría de manera exponencial la productividad de los trabajadores incrementando considerablemente la rentabilidad del proyecto, lo que produce un mayor valor a los ingresos del promotor o inversionista.

Es necesario el planteamiento de esta simulación y es oportuno aclarar que es científicamente aceptable, con el mismo peso de valor que si se realizara un estudio de campo real, ya que ambas herramientas (CCPM y Scrum) a estudiar, han sido examinadas por separado, y han demostrado científicamente que dan resultados por sí solas, de forma independiente. Así, si se estudian ambas por separado y se extrae lo mejor de Scrum para implantarlo en la Cadena Crítica, creando una nueva estructura metodológica, indudablemente el resultado será positivo.

El objetivo es aportar una mejora considerable en la administración de proyectos por Cadena Crítica para conocer o transformar hechos económicos en la gestión de proyectos de ingeniería, pero es lamentable que aún no se hayan creado políticas o lineamientos orientados a tales metas, tampoco los fundamentos legales ni incentivos para fomentar el desarrollo de nuevas investigaciones en materia de procesos para la industria de la construcción, así como la búsqueda de nuevas tecnologías, nuevos materiales y procedimientos para optimizar los recursos empleados y los ingresos percibidos producto de la inversión.

Para el siguiente caso (proyecto habitacional de tipo multifamiliar– multinivel) se utilizaron varios métodos para recolectar las informaciones necesarias. Referente a los planos y los presupuestos del proyecto se utilizó el método de recolección secundaria. Respecto a los datos de rendimientos de vaciado de hormigón mediante el sistema de formaletas, se aplicó el método de recolección primaria.

En múltiples ocasiones se realizaron visitas a proyectos de construcción en desarrollo, similares, con amplias experiencias en el uso de formaletas. En ellos, se entrevistaron de forma libre y personalmente a ingenieros residentes, encargados de programación y gerente de proyectos, estimulándolos a conversar sobres sus estrategias y operaciones en general, así como también de la producción y los sistemas de control de calidad.

3.2. Variables en la selección del caso

Para la selección de la muestra, la principal consideración que se tomó en cuenta fueron aquellos proyectos donde sean necesario los equipos multidisciplinarios, ya que el talento humano es esencial en la aplicación tanto del método de la cadena crítica como el desarrollo ágil con Scrum.

La población considerada fueron los edificios de tipología habitacional o de apartamentos multiniveles. Como muestra, se eligió un edificio multifamiliar en desarrollo en la República Dominicana, con densidad media y una terminación de tipo económica. La edificación consta de 4 niveles con 3 apartamentos en cada nivel; en total, doce unidades habitacionales —de tres dormitorios, sala, cocina–comedor, balcón y zona de lavado—. El área en metros cuadrados por apartamentos es de 65m².

Otro criterio estimado para la selección fue la adaptación al cambio y la flexibilidad en la programación de actividades dentro del proyecto, ya que en la estructura de Scrum se valora la capacidad y el talento por encima de las jerarquías y los trabajos son realizados en equipos; igualmente en Cadena Crítica se considera la conducta del ser humano ante la responsabilidad de ejecutar una tarea, por lo que ambos están fundamentalmente orientados al quehacer humano.

Se puede definir un equipo multidisciplinar como un conjunto de personas, con diferentes formaciones académicas y experiencias profesionales, que operan en conjunto, durante un tiempo determinado, abocados a resolver un problema complejo, es decir tienen un objetivo común. Cada individuo es consciente de su papel y del papel de los demás, trabajan en conjunto bajo la dirección de un coordinador (Wikipedia, 2015).

De acuerdo a Wikipedia, 2015; La composición de equipos multidisciplinares es muy variada, tanto en número de disciplinas involucradas como en el número de miembros de cada especialidad. En el comienzo de una actividad, al planificar la misma, siguiendo uno de los esquemas conocido, como por ejemplo la metodología del ((marco lógico)) u otra semejante, se define cómo estará formado el equipo de personal destinado a afrontar el problema.

La variable población corresponde a la muestra escogida para el caso. A juicio de los investigadores, se eligió un proyecto habitacional multinivel por ser la tipología constructiva más común en la industria de la construcción dominicana, debido a la alta demanda. 

La adaptación al cambio y la flexibilidad en la programación de actividades del proyecto están relacionados con la facilidad que tienen los mismos para afrontar los cambios. Es la capacidad para adaptarse, modificando, si fuera necesario, su propia conducta para alcanzar determinados objetivos cuando surgen dificultades, nueva información o cambios del medio, ya sean del entorno exterior, de la propia organización, del cliente, o de los requerimientos del trabajo en sí (Universidad de Cádiz, 2016). 

Todas estas variables fueron consideradas después de recolectar y ser analizadas enfáticamente todas las informaciones en el marco teórico conceptual de la investigación.

3.3. Construcción con formaletas  

Los sistemas de encofrado son fundamentales para la construcción de vivienda. Son uno de los principales factores para el rendimiento constructivo del proyecto e influyen directamente en la apariencia y calidad de la superficie. Las principales funciones de la formaleta son dar al concreto la forma proyectada en el diseño, proveer estabilidad cuando el concreto se encuentra en estado fresco y asegurar la protección y la correcta colocación tanto del acero de refuerzo como de las instalaciones y sus accesorios; proteger al concreto en su edad temprana de golpes que puedan ocasionar problemas de resistencia, de la influencia de temperaturas externas y de la pérdida de agua, conservando la pasta. Las formaletas para sistemas industrializados pueden ser de diversos materiales: acero, aluminio, madera e incluso, plástico. Dependiendo de esto podrán utilizarse hasta en 1.500 ciclos con un adecuado almacenaje y mantenimiento, así como la técnica utilizada para el desencofrado. Esto genera competitividad en costos, y lo convierte en un sistema eficiente y de alto rendimiento en las construcciones. Se fabrican mediante procesos y equipos industriales con altos estándares de calidad (Silva, 2013).

Los sistemas de formaletas metálicas como el mostrado en la figura 10, están concebidos y diseñados para la producción de viviendas en serie, esencialmente para los proyectos habitaciones de tipo multipisos.

Entre las principales características de este sistema se encuentran: 1. que están conformados por paneles de diferentes materiales. Son marcos de acero con bastidores de madera, acero, aluminio y ahora los de base de plástico, que unidos entre sí encofran la totalidad de cualquier proyecto, formando un molde que reproduce cualquier tipo de vivienda en cada vaciado que se realice; 2. el tamaño de sus piezas permite manejarlos de forma manual, sin ayuda de grúa, favoreciendo ahorros en la inversión de equipos de producción; 3. pueden operar en cualquier topografía, sin importar curvas o desniveles; y 4. pueden producir el 100 % de una vivienda cada 24 horas, con un grupo reducido de operarios que se capacitan rápidamente durante las primeras semanas de construcción (Silva, 2013).

Para este caso en particular, el equipo multidisciplinar lo conforman el arquitecto, el ingeniero estructural, ingeniero geotécnico (de suelo), ingeniero hidráulico (sanitario), ingeniero eléctrico, una brigada topográfica, el director del proyecto (gerente), ingeniero de costos, ingeniero encargado de programación, ingeniero residente (de obra). La especialización que conforman este equipo multidisciplinar dependerá del tipo de proyecto a desarrollar

4. Planificando el CCPM+SCRUM

La clave principal para integrar el Scrum en la Planificación de Proyectos por Cadena Crítica (CCPM) son las reuniones de seguimiento y mejora continua a los procesos. El planteamiento fundamental de esta fusión metodológica es lograr implementar intrínsecamente en la Cadena Crítica, los sprints de seguimientos que han hecho del Scrum una herramienta tan exitosa para el cumplimiento de los proyectos en la fecha planificada y con la calidad requerida. Estos procedimientos serán un complemento a la Cadena Crítica para hacerla aún mejor, optimizándola. Estas resoluciones proceden del análisis realizado a cada metodología en las que se consideraron dos aspectos básicos para definir cuáles procesos se implementarían o no; concluyendo que:

1. La esencia fundamental de la Cadena Crítica es la administración del tiempo en los proyectos, eliminando las holguras y convirtiendo en críticas todas las actividades (planteamiento basado en el síndrome del estudiante y la ley de Parkinson).

2. El Scrum es excelente en la administración por resultados y su éxito deriva de las reuniones de seguimiento que se ejecutan durante todo el desarrollo del proyecto, produciendo una mejora continua que permite aumentar la calidad de los procesos y eliminar las limitaciones en el momento en que se presentan. Estas reuniones de seguimiento del Scrum son los Sprint Planning Meeting, el Daily Scrum, el Sprint Review y el Sprint Retrospective.

Estos sprints del Scrum, se deberán indicar en una red como actividades que consumen tiempo y recurso, pero que serán valiosas para el seguimiento en la ejecución de proyecto y lograr la mejora continua del mismo. Esta red se dispuso conjuntamente a las demás redes luego de aplicar la red de soluciones a las limitaciones de recursos. También fue necesario plantear su ubicación después de la solución a las limitaciones, porque no sería razonable introducir reuniones calendario a una red que aún no es definitiva, estando sujeta a variación, respecto a las soluciones requeridas por las limitaciones manifestadas.

4.1. Utilidad de los Sprints en el CCPM

Las reuniones de ciclos (sprints meetings) son reuniones calendario planificadas categóricamente para evaluar todos los aspectos críticos y fundamentales del proyecto durante su ejecución. 

Durante la aplicación del proyecto es necesario ejecutar una serie de reuniones de inicio y cierre de ciclos donde se analizan informaciones precisas para garantizar el éxito del mismo. La planificación y programación de las actividades, los controles de calidad, las documentaciones del proyecto, los rendimientos, las herramientas, los suplidores, el almacén de suministros, los subcontratistas, los ingenieros residentes, así como los obreros son todos factores críticos importante implicados en el desarrollo el proyecto.

Las reuniones sprints que son programadas en la cadena crítica del proyecto, tienen el propósito de dar seguimiento continuo a las planificaciones semanales y mensuales. En ellas se tratan aspectos operativos, de una manera ágil. De igual forma, se presentan informes semanales y mensuales con lo acontecido en el proyecto a la fecha, las limitaciones y los aciertos, entre otros factores. Igualmente se responden tres interrogantes: 1. ¿Qué he hecho?, 2. ¿Qué voy a hacer hoy? y 3. ¿Qué ayuda necesito? El gerente del proyecto tiene la responsabilidad de eliminar cualquier obstáculo encontrado a la fecha.

Estos encuentros al inicio y cierre de ciclos, tienen otros beneficios favorables como fijar los objetivos del sprint próximo y cuáles serán las tareas necesarias para alcanzarlos. Cabe destacar que en estas reuniones siempre deben quedar claros las necesidades e intereses del cliente. Nos permite analizar e inspeccionar el incremento generado durante el sprint que ha finalizado. El sprint review es una oportunidad para adaptar nuevas directrices estratégicas (Verheyen, 2013). En ella el equipo realiza autoanálisis sobre su forma de trabajar, e identifica fortalezas y puntos débiles. El objetivo es consolidar y afianzar las primeras, y planificar acciones de mejora sobre los segundos (Palacio, 2014).

Las reuniones “retrospectivas” realizadas de forma periódica por el equipo para mejorar la forma de trabajo, se consideran cada vez más un componente del marco técnico de Scrum, si bien no es una reunión para seguimiento de la evolución del producto, si lo es para mejora del marco de trabajo. Además, permiten que todo el equipo y los involucrados tengan conocimiento al día sobre el estado del proyecto mediante las actualizaciones de las gráficas de estimación de trabajos pendientes y los diagramas de flujo acumulativo (con la definición del entregable). Como parte de la mejora continua, el Scrum team conviene en preservar, ajustar, experimentar y mejorar para el próximo sprint (Verheyen, 2013).

5. Comparaciones entre CCPM y SCRUM 

Al analizar ambas estructuras metodológicas se determinaron tanto los aspectos y características semejantes como las diferencias entre el CCPM y el SCRUM.

Entre las similitudes se encuentra:

• Las dos herramientas son bastantes útiles en la gestión de proyectos.
• Ambas inician con una lista de actividades correctamente ordenada en el orden en que esperan ejecutarse con las ideas, características y conceptos para cada tarea.
• El capital de mayor valor es el recurso humano, por estar fundamentado esencialmente en el quehacer humano.
• No son algoritmos matemáticos.
• Se ajustan a entornos multidisciplinarios.
• Se trazan objetivos y metas alcanzables.
• Requieren inspección y adaptación constante.
• Para ambas, es de gran importancia la efectiva coordinación entre los equipos de trabajos.

Las diferencias que resaltan son:

• CCPM es excelente para la administración del tiempo en la gestión de proyecto (reducción de los tiempos), mientras el Scrum se enfoca en la administración por resultados (seguimiento a los procesos para la mejora continua).
• CCPM crea amortiguadores con los tiempos de protección y Scrum amortigua con la funcionalidad del producto.
• En CCPM, todo el margen de protección o buffer de amortiguamiento se le asigna al proyecto (no a la tarea). Scrum prefiere armar el proyecto rápidamente, inspeccionar y luego adaptar porque ve que no es posible tratar de comprender todas las implicaciones al principio.
• CCPM es un método, pero Scrum no. Scrum es un conjunto de disciplinas para buenas prácticas.
• En CCPM se trabaja ordenado con una planificación y bajo una estructura jerárquica centralizada. El Scrum es adaptable a entornos desordenados, basado en el empirismo y la incertidumbre. Descarta las estructuras jerárquicas y descentraliza la estructura del proyecto confiando en la autoorganización de los equipos (prevalecen las capacidades por encima de las jerarquías).
• CCPM está orientado a los procesos, herramientas, documentación, relaciones contractuales (cumplimiento a un plan preestablecido) y el Scrum se desarrolla en las interacciones, la colaboración con el cliente y es capaz de adaptarse rápidamente al cambio.
• Las mejoras continuas en CCPM se miden con análisis de indicadores centrados en las métricas de los procesos, pero las mejoras del Scrum se consolidan en las retrospectivas (reuniones) basadas en la percepción del equipo. 

6. Fusión metodológica CCPM+SCRUM

A continuación, se describe paso a paso el procedimiento de cómo debe aplicarse correctamente la nueva estructura metodológica CCPM+SCRUM. Los pasos para seguir son los siguientes:

1. Red de actividades a tiempo estándar

Mediante esta red, se representan de manera gráfica todas las actividades que componen la totalidad del proyecto, destacando sus eventos y secuencias. Es posible apreciar las interrelaciones entre las actividades. Se acentúa el camino crítico (ruta más larga en términos de tiempo para concluir el proyecto) con una flecha más gruesa y de color rojo, Para indicar el inicio y fin de un evento (figura 11).

2. Red de barras a tiempo estándar

En esta red, se eliminan los nodos (indicativos de inicio y fin de cada evento) presentes en la anterior red. Asimismo, se cambian las flechas por barras (en ambos casos para indicar la duración de cada actividad), pero en esencia se mantienen cinco (5) aspectos similares a la red de actividades a tiempo estándar; 1. representa todas las actividades que componen el proyecto, 2. se identifican todos los eventos, 3. se destacan las secuencias, 4. muestra las interrelaciones entre una actividad y otra, y 5. predomina la cadena crítica (cuyo nombre en la red previa es conocido como camino crítico) ahora representado en barras de color rojo (figura 12).

3. Red de barras con tiempos Goldratt

Esta red está básicamente fundamentada en los análisis realizados por Goldratt sobre el síndrome del estudiante donde los tiempos de cada actividad son reducidos a un 50 %, conocido como tiempos Goldratt. Esta red tiene la particularidad de que a cada actividad se le asigna la mitad de su tiempo identificando, tiempo que le será recortado a dicha actividad (figura 13).

4. Red de barras con buffers en procesos

Red de barra ya con los tiempos Goldratt acortados al 50 %, mismos tiempos identificados en la red anterior. Se insertan de los buffers (amortiguadores o tiempos de protección) al final de cada proceso; dichos buffers son un resultado del 50 % de la totalidad de los tiempos reducidos en cada proceso (figura 14).

5. Red indicando las limitaciones de recursos

Se identifican las actividades que tienen los recursos humanos o materiales limitados, donde varias actividades planificadas para ejecutarse en una misma fecha, pero con diferentes recursos, no puedan ejecutarse a la vez por circunstancia adversa (poco personal para tales actividades, o recursos materiales incompletos en obra al momento de iniciar la actividad, quizás el equipo o maquinaria no estén disponibles. Se identifican las actividades que tienen limitaciones marcándolas con un color o patrón que la acentúen, en este caso están marcadas con un patrón sólido de color rojo (figura 15).

6. Red con soluciones a las limitaciones de recursos

Plantea soluciones a las limitaciones. Muestra nuevas secuencias y la variación de los tiempos de inicio y fin para las actividades afectadas, y la nueva duración del proyecto, si las actividades subordinadas intervienen en la cadena crítica (figura 16).

7. Red indicando las reuniones–sprints semanales

Hay dos nuevas informaciones, 1. las reuniones o sprints semanales, cuya finalidad es llevar un seguimiento periódico a los objetivos planteados en la planificación. Se crea un ciclo de trabajo semanal que inicia con una reunión de planificación de objetivos específicos, metas y estrategias y concluye con una reunión de evaluación y medición de resultados; y 2. aparece la escala de tiempo calendario sobre la escala gráfica del tiempo (días). En la CCPM, esta información aparece en el último paso, pero en fusión CCPM+SCRUM, es necesario introducirla aquí por las previsiones los sprints semanales (al inicio o fin de ciclo) por identificarse con las fechas calendario (figura 17).

8. Red indicando las reuniones–sprints mensuales

Indica las reuniones mensuales de retrospectivas, cuya finalidad es la de verificar los objetivos generales del proyecto. Aquí se identifican los cambios y ajustes que fueren necesarios implementar. La finalidad es comprobar el avance del proyecto, medir los objetivos generales y generar una retroalimentación sobre aspectos del trabajo tan importante como lo es la tecnología, aspectos sociales, estrategias implementadas y la calidad de lo ejecutado, etc. El principal objetivo es establecer las buenas prácticas, saber en qué etapa del sprint se debe mejorar y que otras habilidades resultarían útiles o necesarias implementar para aprender, mejorar la experiencia y desarrollar un mejor proyecto (figura 18).

9. Red con regiones del buffer para gestión del consumo

Las regiones de buffer del proyecto son una codificación por color para medir el avance o retraso del proyecto. El buffer se fracciona en tres segmentos coloreados en verde, amarillo y rojo para indicar el estatus del proyecto; siendo el color verde un indicativo de que el proyecto presenta variaciones esperadas y no hay que tomar ninguna acción fuera de lo planificado, el color amarillo indica una variación normal pero en este caso ya se debe preparar un plan de acción para llevar el proyecto dentro de la fecha, y el color rojo indica una variación anormal y se necesita actuar inmediatamente para evitar incumplimientos con la fecha de entrega y también evitar sobrecostos (figura 19).

10. Red indicando la iniciación tardía de los procesos

Indica todas las actividades con las fechas más tardías para iniciarlas y sus secuencias, lo que le permite eliminar, definitivamente, todas las holguras de los procesos hasta convertirlas en críticas. Goldratt lo plantea así, según sus estudios en los planteamientos del síndrome del estudiante y la ley de Parkinson. Se representa la iniciación tardía con una flecha que inicia en la fecha más temprana para empezar la actividad hasta la fecha de iniciación más tardía y sobre la flecha se especifica el número de iniciación tardía y la cantidad de días tardíos para empezar el proceso (figura 20).

11. Red indicando la calendarización y las alarmas de actividades

Última red del proceso dentro del CCPM. Se visualizan todas las actividades y eventos con sus secuencias, interrelaciones, con la cadena crítica claramente identificada, las soluciones a las limitaciones encontradas y la indicación de las iniciaciones tardías para cada actividad. En esta nueva red se muestran las alarmas de provisiones, son muy valiosas el considerarlas para que los suministros para cada una de las actividades lleguen a obra antes de iniciar la actividad que requiere dicho recurso.

Algunas previsiones por considerar serían el tiempo para la adquisición de materiales e insumos, los pagos y desembolsos a suplidores, contratistas y obreros, así como cualquier otro hito o evento que sea primordial para la ejecución sin demoras del proyecto. Todas estas alarmas de provisiones se deben extraer de las políticas de pagos y desembolsos del proyecto, documento previamente elaborado para llevar el control de costos, gastos y otros recursos, con el objetivo de mantener la ejecución del proyecto en su tiempo justo sin contratiempos ni retrasos (figura 21).

Como nota importante es necesario aclarar que los pasos para la aplicación de la Cadena Crítica en un proyecto de ingeniería, empleando las gráficas de redes, fueron extraídos de la asignatura “Seminario de la Construcción” que se imparte en el postgrado en Administración de la Construcción que ofrece el INTEC. (González, 2014).

7. Inicio y cierre de proyectos 

Las reuniones se utilizan para discutir y abordar los asuntos pertinentes del proyecto durante la dirección y gestión del trabajo del proyecto. Los asistentes a las reuniones pueden incluir al director del proyecto, al equipo del proyecto y a los interesados adecuados, involucrados o afectados por los asuntos tratados. Cada asistente debería tener un rol establecido, de modo que se asegure la participación adecuada. Suele haber reuniones de tres tipos: 1. De intercambio de información, 2. Tormenta de ideas, evaluación de opciones o diseño, y 3. De toma de decisiones (Project Management Institute, 2013).

El PMI plantea como una buena práctica que los tipos de reuniones no deben mezclarse. Las reuniones deben prepararse con una agenda bien definida, con un propósito, con un objetivo y con un marco temporal y deben ser adecuadamente documentadas con actas de reunión y lista de acciones a realizar. Las actas de reuniones deben ser almacenadas como se indique en el plan para la dirección del proyecto. Las reuniones son más eficaces cuando todos los participantes pueden intervenir cara a cara en el mismo lugar. Se pueden realizar reuniones virtuales usando herramientas de audio y videoconferencia, pero generalmente requieren una preparación y una organización adicional para conseguir la misma eficacia que la de una reunión cara a cara (Project Management Institute, 2013).

7.1. Reunión de inicio del proyecto

El límite de un proyecto se define como el momento en que se autoriza el inicio o la finalización de un proyecto o de una fase de un proyecto. La reunión de inicio está compuesta por aquellos procesos realizados para definir un nuevo proyecto o una nueva fase de un proyecto existente al obtener la autorización para iniciar el proyecto o fase.

Dentro del ámbito de los procesos de inicio es donde se define el alcance inicial y se comprometen los recursos financieros iniciales. Además, se identifican los interesados internos y externos que van a participar y ejercer alguna influencia sobre el resultado global del proyecto. Finalmente, si aún no hubiera sido designado, se elegirá el director del proyecto. Esta información se registra en el acta de constitución del proyecto y en el registro de interesados (Project Management Institute, 2013).

El acta de constitución del proyecto es un documento emitido por el iniciador del proyecto o patrocinador que autoriza formalmente la existencia de un proyecto y confiere al director del proyecto la autoridad para asignar los recursos de la organización a las actividades del proyecto. En el momento en que se aprueba el acta de constitución del proyecto, este se considera oficialmente autorizado (Project Management Institute, 2013). Al emitirse el acta, es importante verificar que el proyecto se corresponda con la dirección estratégica de la organización que lo realiza.

7.2. Reunión de cierre del proyecto

Una fase importante en la vida de un proyecto de construcción es el cierre administrativo, ya sea que se produzca después de haber alcanzado los objetivos o que haya terminado por otras razones. La tercera edición de la guía del PMBOK plantea que “El proceso Cerrar Proyecto supone realizar la parte de cierre del proyecto del plan de gestión del proyecto” (2004, p. 100). En los proyectos de múltiples fases, el proceso de cierre concluye las partes del alcance del proyecto y las actividades conexas programadas para una fase determinada. Este proceso incluye la finalización de todas las actividades realizadas en todos los grupos de procesos de gestión de proyectos para clausurar formalmente el proyecto o una fase del proyecto, y transferir el proyecto terminado o cancelado según corresponda.

Cada fase del proyecto se debe cerrar correctamente para asegurar que no se pierdan informaciones importantes y útiles (PMI, 2007). En esta reunión los promotores o clientes reciben formalmente el proyecto para tomar posesión de dicho activo una vez finalizado e iniciar la fase operativa. En el acta se deben registrar todos los pormenores y detalles de la reunión de clausura y se levantará el registro de los interesados presentes en dicha reunión.

La información histórica y la proveniente de lecciones aprendidas se transfieren a la base de conocimientos para su utilización en futuros proyectos o fases. Esto puede incluir información sobre incidentes y riesgos, así como sobre técnicas que funcionaron bien y que pueden aplicarse en proyectos futuros (Project Management Institute, 2013). Tanto los archivos del proyecto, los documentos de cierre del proyecto o fase y la información histórica se consideran parte de los activos de los procesos de la organización (figura 22).

Se entiende por archivos del proyecto, a toda la documentación resultante de las actividades del proyecto, por ejemplo, el plan para la dirección del proyecto, el alcance, el costo, el cronograma y el calendario del proyecto, los registros de riesgos y otros registros, la documentación de la gestión de cambios, las acciones planificadas de respuesta a los riesgos y el impacto de los riesgos.

La información histórica y la proveniente de lecciones aprendidas se transfieren a la base de conocimientos de lecciones aprendidas para su utilización en futuros proyectos o fases. Esto puede incluir información sobre incidentes y riesgos, así como sobre técnicas que funcionaron bien y que pueden aplicarse en proyectos futuros (Project Management Institute, 2013).

Para el procedimiento del cierre administrativo, además del documento de aceptación formal firmados por el cliente, muchos proyectos de construcción poseen otras informaciones requeridas por las instancias gubernamentales para ser preparadas, ejecutadas y distribuidas. La acción formal de aceptación final y cierre será guiada, en casi todos los casos, por documentos contractuales suministrados bajo las cuales se construyó el proyecto (Project Management Institute, 2007).

8. Investigaciones futuras, conclusiones y recomendaciones finales

En cualquier proyecto con numerosos alcances indefinidos en su fase inicial, deberán esforzarse en las actividades para el refinamiento del alcance antes de realizar cualquier compromiso concreto. Una vez se tengan las respuestas a todas las inquietudes, se puede comenzar a estimar la cantidad de trabajo que se tiene pendiente, los tipos de recursos necesarios para ejecutar el trabajo, y cuanto tiempo podría tomarle al equipo para lograrlo. Tanto la estructura Ágil como la Cadena Crítica deben abordar la problemática del esclarecimiento del alcance, y ambas requieren la aplicación del buffer para contrarrestar las incertidumbres inherentes del proyecto (Fortezza Consulting, 2014).

Aunque la filosofía del Scrum plantea su fácil adaptación a trabajos desordenados sin ninguna programación previa, todo buen practicante Ágil sabe que necesita realizar una buena planificación (importancia de los sprint planning meeting en el Scrum). Incluso, aun cuando se estiman modificaciones futuras del alcance durante la ejecución de este, se deben agotar los recursos suficientes para definir con claridad la visión global del proyecto a desarrollar y conocerse el alcance (requerimientos) lo suficiente como para que el equipo de trabajo se mantenga siempre en la dirección correcta.

El Product Lifecycle Management (PLM), traducido al español como gestión del ciclo de vida de productos, sería una magnífica línea de investigación, cuya metodología tiene excelentes procesos que serían muy beneficiosos para CCPM+SCRUM. Según (Wikipedia, 2018): “El ciclo de vida de un producto pasa por varias fases, involucra a muchas disciplinas profesionales y requiere muchas habilidades, herramientas y procesos; tales elementos son muy comunes al CCPM y al Scrum.”

Las ventajas más importantes que ofrece el CCPM+SCRUM son los reducidos tiempos de producción, productos con mayor calidad, menores costos de producción y ahorros al evitar retrasos. También, CCPM+SCRUM proporciona una estructura completa para optimizar los recursos que fluyen para el desarrollo de los proyectos.

No es viable ceñirse a la práctica exclusiva de un método en particular, porque una destreza no responde de forma similar para solucionar todos los casos. Se recomienda como buena práctica, adoptar de las metodologías ágiles, aquellos aspectos que mejor se adapten a cada proyecto u organización. Al orientar futuras investigaciones, deberán prevalecer siempre como objetivos esenciales; 1. que el recurso humano aumente la calidad y rapidez de respuesta ante un problema y 2. una amplia reducción de costos que permita un mayor margen de utilidad. En todo caso, el éxito de la estructura CCPM+SCRUM dependerá de la correcta gestión de los recursos.

De manera puntual se debe enfatizar que entre la Cadena Crítica y el Scrum existe una gran diferencia que no se debe obviar; y a pesar de tantas similitudes mencionadas, está claro que la Cadena Crítica es un método para la programación y administración de proyectos, pero el Scrum es una estructura o más bien un conjunto de principios y disciplinas encaminadas al logro de objetivos basados en la administración por resultados, dando seguimiento continuo al cumplimiento de las metas.

Entendiendo que un método es el modo ordenado de proceder para llegar a un resultado o fin determinado, especialmente, para descubrir la verdad y sistematizar los conocimientos (Farlex, Inc., 2009).

Podría tomar algún tiempo aceptar que Scrum no necesita ser planificado o diseñado, ni tampoco concebido antes de que una transformación pueda arrancar. Scrum incorpora respuestas, soluciones e ideas competitivas que surgen durante la realización del proyecto (Verheyen, 2013).

En Scrum se improvisa día a día según las circunstancias, contrario a la Cadena Crítica que aborda la planificación desde el primer instante, tanto así que analiza la respuesta del ser humano ante la responsabilidad de ejecutar ciertas tareas anticipándose a los retrasos por incumplimientos, basados en el síndrome del estudiante y la ley de Parkinson. Implementar Scrum con tantos aspectos ambiguos en el campo de los softwares, podría estar bien pero no para el campo de la construcción, por tener implicaciones de riesgos (pérdidas humanas) tan altos. Continuamente se utilizan maquinarias, equipos, herramientas y materiales, para actividades que tienen altos riesgos de accidente; el factor riesgo se debe gestionar en la planificación, ya que pondría en peligro la salud, la seguridad y la vida de muchas personas de no considerarse. Por esta razón es tan importante la estrategia constructiva o planificación en los proyectos de construcción, además de las grandes pérdidas económicas que suponen los accidentes y las costosas partidas presupuestadas en el mejor de los casos (si se compara con el valor incalculable de la pérdida de vidas humanas), si ocurriesen retrasos o trabajos mal ejecutados.

Pese a que el CCPM en los proyectos reduce las causas de no cumplimiento, eliminando las holguras para que concluyan dentro del tiempo programado y con el costo esperado, el Scrum viene a introducir un proceso de mejora continua en la Cadena Crítica, integrando las reuniones–sprints semanales y mensuales.

El proceso de mejora continua es una actitud general que debe ser la base para asegurar la estabilización del proceso y la posibilidad de mejora. Algunas de las herramientas utilizadas incluyen las acciones correctivas, preventivas y el análisis de la satisfacción en los miembros o clientes (Wikipedia, 2015). Estas mejoras se logran con el seguimiento continuo que proporcionan las reuniones semanales (establecer y coordinar prioridades de la semana para evaluar el avance del proyecto) y mensuales (retroalimentación para el refinamiento del entorno de trabajo y procesos de optimización).

La nueva estructura CCPM+SCRUM impacta positivamente en los recursos humanos, sobre todo en los equipos multidisciplinarios de desarrollo, convirtiendo los entornos de trabajos en ambientes dinámicos. Algunos principios y valores de la estructura ágil, a implementar son:

1. El gerente se convierta en facilitador antes que un controlador, mantener siempre el respeto, la claridad y la buena comunicación con el personal obrero y el equipo multidisciplinario. 
2. Desarrollar los equipos autoorganizados y multidisciplinares para que se vuelvan funcionales y productivos, mejorando la capacidad del equipo.
3. Introducir un proceso de mejoras en la que se pueda inspeccionar y adaptar.
4. Servir mejor a los requisitos competitivos.
5. Ajustar las funcionalidades, prioridades y requerimientos en cada ciclo (semanal o mensual).
6. Eliminar todo obstáculo o impedimento que se presente.
7. Crear una retroalimentación en ciclos (tiempos) cortos y de manera continua.

Finalmente, se recomienda enfáticamente

1. Implementar un plan de gestión de la comunicación. Dentro de CCPM+SCRUM se debe diseñar y habilitar diferentes canales de comunicación que ayude con la actualización continua del estatus del proyecto y las eventualidades que se presenten, lo que permite corregir las deviaciones a tiempo.

2. Implementar el taskboard o tablero de trabajo. Aunque se tenga mucha capacidad y muchos años de experiencia, el uso del taskboard es favorable porque ayuda a visualizar e identificar con mayor facilidad, muchos de los factores adversos que pudieran surgir mientras transcurre el proyecto.

3. Que CCPM+SCRUM implemente controles de calidad más rigurosos. Esto ayuda a reducir las probabilidades de desviación en el proyecto. El tener control de calidad más efectivo contribuirá en la buena ejecución de las tareas.

4. Crear hábitos o disciplinas para aplicar las buenas prácticas. El ser humano tiende a planificar todo, pero no se apega al plan. Si se sigue rigurosamente el plan, aumentará significativamente el éxito de los proyectos.

5. Diseñar formularios y plantillas. Sería realmente grandioso el uso de estas herramientas durante los sprints y todo el proyecto para el control de ejecución de tareas y los trabajos en progreso.