top of page

Uso de Agile y Scrum para ayudar a la resolución de restricciones y 'Preparación' de LPS



Los problemas de planificación en la construcción se aceptan y se relacionan principalmente con el enfoque de gestión en el control; la planificación no concebida como un diseño de sistema; se descuida la planificación a nivel de la tripulación; rendimiento del sistema de planificación no medido; y fallas de planificación no analizadas para identificar y actuar sobre las causas raíz [3, 5, 7, 8]. Un concepto clave en Lean Construction es la provisión de un flujo de trabajo confiable para los equipos de trabajo para reducir la incertidumbre en el proceso de entrega [1] y la función de anticipación dentro del Last Planner® System (LPS) funciona de manera proactiva para reducir esta incertidumbre. En relación con la 'preparación', el Benchmark 2020 establece:

'…implica preparar las tareas programadas y volver a planificar cuando algunas tareas programadas no se pueden preparar…. “preparar” se realiza identificando y eliminando cualquier restricción restante en las tareas programadas en el período de anticipación, luego dividiendo las tareas programadas en operaciones y diseñando esas operaciones. Si no se pueden eliminar las restricciones, la tarea se reprograma para una fecha posterior cuando se hayan eliminado las restricciones.'

El Benchmark 2020 define una restricción como "algo que se interpone en el camino de que una tarea sea ejecutable o sólida". Las restricciones típicas en las tareas de construcción son la finalización del diseño o el trabajo de requisitos previos, la disponibilidad de materiales, información y directivas. La detección de tareas para la preparación está evaluando el estado de sus limitaciones; eliminar restricciones hace que una tarea suene. Por lo tanto, se deduce que la identificación y gestión de restricciones efectivas es posiblemente la función más crítica de LPS y en la preparación para el flujo. Deseo mostrar algunos ejemplos que he encontrado recientemente.


Ejemplo 1:


El equipo había estado planteando restricciones, pero los datos gráficos ilustrados no tenían suficiente tiempo para su análisis y rectificación efectivos. La Figura 1 ilustra cómo el 91% de las restricciones se plantearon dentro de los 7 días posteriores a la fecha de resolución necesaria. La Figura 2 presenta el resultado de esto con solo el 25% de las restricciones resueltas dentro de los 7 días requeridos y el 72% de las restricciones resueltas tarde.



El problema a resolver era doble: en primer lugar, las limitaciones debían identificarse antes y, en segundo lugar, debían priorizarse, asegurando que las personas siempre estuvieran trabajando para resolver las más urgentes en secuencia de prioridad.



El marco Scrum ayudó en el proceso de resolución mediante:

  • priorización de las restricciones de mayor valor

  • asegurarse de que la persona correcta estaba trabajando en esas restricciones

  • limitar el cambio de contexto centrándose en uno a la vez

  • asegurando equipos más pequeños con menos rutas de comunicación

  • puntos de contacto diarios y tableros virtuales en lugar de reuniones de restricción semanales únicas (lanzamientos pequeños y regulares en lugar de un solo lanzamiento semanal)

  • flujo suave y consistente de eliminaciones de restricciones

La progresión con el marco Scrum se ilustra en la figura 3 con el tiempo promedio de resolución de restricciones que se reduce de 17 días a 3,2 días y el 95 % se resuelve en 7 días.


Ejemplo 2:


El punto de referencia de 2020 (página 28) establece; 'La responsabilidad de eliminar las restricciones se distribuye en todo el equipo.' La Figura 4 ilustra una instantánea de 42 restricciones abiertas distribuidas en 32 propietarios diferentes en un solo proyecto.

Tradicionalmente, en los proyectos se realizaba semanalmente una reunión de restricciones, inmediatamente después del recorrido de preparación del sitio. Las restricciones recién identificadas se registrarían en una hoja de cálculo de Excel con los propietarios y las fechas necesarias asignadas. Las columnas se pueden filtrar y las restricciones se envían por correo electrónico a los propietarios para su atención. En el caso de la figura 4, son 42 restricciones comunicadas a 32 propietarios diferentes y 32 correos electrónicos para ser recogidos, leídos y accionados. Aquí es donde existe el problema de la latencia de decisión y donde el control del proceso deja al equipo del proyecto en el sitio. Como observamos en la figura 5, dos personas en el correo electrónico es un método de comunicación mucho más frío e ineficaz que dos personas en una pizarra o en una videollamada.

Refiriéndose al principio ágil n.º 6: 'El método más eficiente y efectivo para transmitir información a un equipo de desarrollo y dentro de él es una conversación cara a cara'. [4] Por supuesto, en 2022 ahora tenemos plataformas de comunicación virtual que casi crean la experiencia 'cara a cara'. La solución utilizada para mejorar el problema de la latencia de decisión en el ejemplo 2 fue crear un tablero Scrum virtual y durante tres sesiones semanales programadas de una hora, el facilitador podía entrar y salir con cada propietario de restricción y progresar solo en las restricciones de prioridad. Esto requería que los 32 propietarios de restricciones mantuvieran el espacio de una hora libre si era posible y solo estarían en línea en la llamada durante unos minutos cuando se les llamara. Este proceso contribuyó a mejorar la duración de la resolución de restricciones, como se ilustra en la figura 3,


Estos ejemplos ilustran cómo una mentalidad de crecimiento y la aplicación de un pensamiento ágil a través del marco Scrum pueden complementar el proceso de preparación y resolución de restricciones de LPS.

 

REFERENCIAS.

[1] Ballard, G. (2020) El último sistema planificador. En: Lean Construction, pp.45-53. Routledge.

[2] Ballard, G. y Tommelein, I. (2021) 2020 'Valor de referencia del proceso actual para el sistema Last Planner de planificación y control de proyectos'.

[3] Daniel, E. y Pasquire, C. (2017) Enfoque de despeje de ruta del sistema Last Planner (LPS-PCA): un enfoque para guiar; clientes, contratistas principales y subcontratistas en la implementación de la LPS.

[4] Fowler, M. y Highsmith, J. (2001) El manifiesto ágil. Desarrollo de software, vol. 9, número 8, págs. 28-35.

[5] Hamzeh, F., Ballard, G. y Tommelein, I. (2009) ¿Se aplica el último sistema de planificación al diseño? En: Actas de la 17ª conferencia anual del Grupo Internacional para la Construcción Esbelta, Taipei, Taiwán, pp. 167-176.

[6] McCarthy, J. y Monk, A. (1994) Midiendo la calidad de la comunicación mediada por computadora. Comportamiento y tecnología de la información, vol. 13, edición. 5, págs. 311-319.

[7] Mossman, A. (2013) Last Planner: 5+ 1 conversaciones cruciales y colaborativas para la entrega predecible de diseño y construcción. The Change Business Ltd., Reino Unido

[8] Power, W., Sinnott, D. y Lynch, P. (2021) 'Evaluación de la eficacia de un facilitador del sistema de último planificador dedicado para mejorar la productividad de la construcción'. Economía de la construcción y edificación, vol. 21, No.3, pp.142-158.

ACERCA DEL AUTOR.

William Power es un profesional experimentado en gestión de la construcción con más de 30 años de experiencia en la entrega de proyectos en todos los sectores, incluidos los servicios públicos residenciales, comerciales, farmacéuticos, de ciencias de la vida, marinos, de infraestructura, subterráneos y aéreos. William, titular de una Licenciatura con honores en Gestión de la Construcción y una Maestría con honores en Negocios en Práctica Lean, actualmente está realizando una investigación doctoral en Mejora Continua en la Entrega de Proyectos de Construcción en SETU, Irlanda.


TRANSCRIPCIÓN: Areli Álvarez Lean Construction México®

114 visualizaciones

Comments


  • Facebook
  • Twitter
  • YouTube
bottom of page