1.6: Planeación de Proyectos

Al prepararme para la batalla, siempre he encontrado que los planes son inútiles pero la planeación es indispensable.
—Dwight D. Eisenhower, Presidente de los Estados Unidos (1953-1961), Comandante Supremo de las Fuerzas Aliadas en Europa (1943-1945)

Objetivos

Después de leer este capítulo, podrás

• Describir el enfoque de orden vital para la planeación de proyectos
• Explicar y distinguir entre la planificación push y pull
• Describir el enfoque ágil para la planeación de proyectos
• Explicar la relación entre sustentabilidad y mejora continua
• Discutir temas relacionados con planes de contingencia

Las grandes ideas en esta lección

• La incertidumbre es una característica permanente del trabajo de un líder de proyecto.
• En el orden vital, la planeación es un ejercicio de aprendizaje, colaboración y adaptación en el que los miembros del equipo están listos para alterar el plan en cualquier momento para abordar las condiciones cambiantes.
• La planificación del orden de vida se ejemplifica con la planificación pull, en la que los planificadores comienzan identificando el estado final deseado, y luego trabajan hacia atrás para planificar actividades que logren ese objetivo.

6.1 Una nueva forma de pensar sobre la planeación

La definición de planeación de Merriam Webster es “el acto o proceso de hacer un plan para lograr o hacer algo”. Esto sugiere que el objetivo final de la planeación es el propio plan. También se presume que una vez que se ha formulado un plan, sólo es necesario seguir el plan para lograr el resultado deseado. Eso está bien para una conversación ordinaria. Pero cuando comenzamos a pensar en la planificación de proyectos de orden vivo, surge una comprensión más expansiva de la naturaleza de la planificación. En orden de vida, la planeación es un proceso que prepara al equipo del proyecto para responder a los eventos a medida que realmente se desarrollan. El objetivo de la planeación es desarrollar estrategias para mangage

• Cambios en el alcance
• Horario
• Costo
• Calidad
• Recursos
• Comunicación
• Riesgo
• Adquisiciones
• Participación de las partes interesadas

La planeación da como resultado un plan, pero el plan no es un fin en sí mismo. Más bien, un plan es un marco estratégico para la programación y ejecución de un proyecto. Solo es útil si incluye la información que los miembros del equipo requieren para comenzar a avanzar. Y solo sigue siendo útil si los miembros del equipo modifican el plan a medida que aprenden lo siguiente sobre el proyecto:

• Restricciones clave como el cronograma, el costo y los requisitos funcionales.
• Información sobre problemas del sistema del proyecto, como el flujo de trabajo y los hitos, que proporcionan una visión amplia del proyecto en su conjunto.
• Planes de chequeos periódicos que permitan a los participantes y líderes reevaluar el proyecto y sus supuestos originales.

Planear es aceptar incertidumbre

Los planificadores de orden geométricos acérrimos adoptan un enfoque determinista, trabajando bajo la falsa noción de que una vez que todos están de acuerdo en un plan, el plan mismo determina lo que viene después. En efecto, es tentador pensar que puedes concretar cada detalle al inicio de un proyecto y luego ponerte en marcha sin mirar atrás. Pero los planificadores efectivos del orden vital entienden que, especialmente al principio de un proyecto, estos detalles son casi siempre provisionales y sujetos a cambios. Así, los planificadores efectivos del orden de vida están listos para alterar sus planes en respuesta a lo que aprenden en condiciones cambiantes. También entienden que el contexto en el que se desarrolla un proyecto tiene diferentes niveles de detalle y variabilidad, con potencialmente miles de decisiones tomadas a lo largo del ciclo de vida del proyecto. La Figura 6.1 muestra los círculos de contexto en expansión que rodean una tarea individual dentro de un proyecto. Cada círculo agrega su propia variabilidad e incertidumbre a un proyecto.

Figura 6.1: Cada círculo de contexto agrega su propia variabilidad e incertidumbre a un proyecto.

Como explicaron Alexander Laufer y Gregory Howell en un artículo para Project Management Journal, el trabajo de un líder de proyecto se funda en la incertidumbre (1993). La incertidumbre no es un estado excepcional en un proceso de trabajo por lo demás predecible, argumentan. En cambio, es una característica permanente del trabajo moderno. Además, cuanto más largo sea el tiempo entre la planeación y la implementación, mayor será la incertidumbre en torno a las actividades individuales. Naturalmente, cuanto mayor sea la incertidumbre en un proyecto, más difícil será planificar, y menos efectivos serán los planes para articular acciones y resultados. Por último, enfatizan que ninguna cantidad de planeación puede eliminar la variabilidad intrínseca al trabajo de un proyecto complejo.

Planeación para la complejidad

Alexander Laufer y Gregory Howell recuerdan que la variabilidad intrínseca al trabajo de un proyecto complejo no puede ser eliminada por la planeación (1993). Pero, ¿qué es exactamente un proyecto complejo? ¿Todos los proyectos difíciles son complejos? En una entrada de blog para Team Gantt, Tera Simon explica: “Un proyecto complejo no es necesariamente un proyecto difícil. Los proyectos pueden ser difíciles por razones como el costo o el rendimiento, pero esto no significa automáticamente que el proyecto sea complejo. La complejidad se refiere a proyectos que incluyen ambigüedad o incertidumbre. Están rodeados de imprevisibilidad” (2016).

Ejemplos de proyectos complejos van desde megaproyectos como Big Dig de Boston, hasta empresas más enfocadas como el desarrollo de software para una tecnología médica que aún no es funcional y que será utilizada por personas en entornos de atención médica cambiantes. Un proyecto verdaderamente complejo tendría algunas de las siguientes características:

• • Incertidumbre respecto al objetivo final del proyecto.
  • Limitaciones ambiguamente definidas o cambiantes.
  • Tecnologías nuevas o insuficientes.
  • La necesidad de soluciones nuevas, previamente no probadas.
  • Un elenco grande y cambiante de actores de muchas disciplinas.
  • Un contexto en evolución que involucra, por ejemplo, restricciones climáticas o geológicas impredecibles, transiciones políticas y trastornos económicos.

Si te interesa una investigación más teórica sobre la idea de complejidad, lee sobre el framework Cynefin, que es una herramienta de toma de decisiones diseñada para ayudar a los gerentes a dar sentido a la complejidad. Creado por David Snowden y Mary E. Boone, el marco Cynefin permite a los líderes “ver las cosas desde nuevos puntos de vista, asimilar conceptos complejos y abordar problemas y oportunidades del mundo real”. Se enfoca en identificar el tipo de situación en la que estás operando (simple, complicada, compleja o caótica) y luego tomar decisiones apropiadas a ese contexto.

Para los gerentes de proyectos técnicos, la visión más útil del marco es la distinción entre proyectos complicados y complejos. Snowden y Boone discuten esta idea en un artículo para Harvard Business Review:

En un contexto complicado, al menos existe una respuesta correcta. En un contexto complejo, sin embargo, las respuestas correctas no pueden ser descubiertas. Es como la diferencia entre, digamos, un Ferrari y la selva brasileña. Los ferraris son máquinas complicadas, pero un mecánico experto puede desarmar una y volver a montarla sin cambiar nada. El auto está estático, y el conjunto es la suma de sus partes. La selva tropical, por otra parte, está en constante flujo —una especie se extingue, cambian los patrones climáticos, un proyecto agrícola redirige una fuente de agua— y el conjunto es mucho más que la suma de sus partes. Este es el reino de las “incógnitas desconocidas”, y es el dominio al que se ha desplazado gran parte de los negocios contemporáneos. (2007)

Lectura adicional

• El artículo de Snowden y Boone sobre el marco Cynefin describe el espectro completo de la complejidad del proyecto e incluye enlaces a más información: https://hbr.org/2007/11/a-leaders-fr...ecision-making.
• La publicación de Tera Simon sobre proyectos complejos describe las habilidades que necesitas para abordar proyectos complejos: https://www.teamgantt.com/blog/tackl...mplex-projects.
• Este post de Kathleen B. Hass describe una variedad de proyectos complejos e introduce una nueva disciplina de gestión de proyectos, la gestión de proyectos complejos: https://www.projecttimes.com/article...ts-part-1.html

Planear es aprender

En orden de vida, es útil pensar en un proyecto como una actividad de desarrollo del conocimiento . La Planeación de Proyectos , entonces, es el proceso continuo de incorporar nuevos conocimientos a un plan de proyecto. Al inicio de proyectos altamente complejos o desconocidos, es posible que sepas poco o nada sobre cómo lograr el resultado deseado. Al final, sabes muchísimo más. Cuanto más aprenda, mayor será su capacidad para afinar el plan para lograr el resultado deseado del proyecto. Esto significa que un plan adquirirá detalles a medida que avanzas. Es importante resistir la tentación de incluir detalles sobre factores que aún no entiendes completamente porque esos detalles seguramente resultarán equivocados. Tenga cuidado de no planificar con un nivel de precisión que exceda su comprensión de los muchos factores que podrían afectar al proyecto.

Cuando te comprometes con este enfoque adaptativo a la planeación, puedes tratar la planificación de proyectos de una manera fundamentalmente diferente. En lugar de preguntar constantemente: “¿Cómo puedo dirigir mi proyecto de nuevo al plan original?” puedes preguntar: “¿Cómo puedo usar este nuevo conocimiento para refinar mi plan y mejorar la probabilidad de éxito del proyecto?” Cuando aprendes algo, encuentras un contratiempo o tienes éxito, puedes tratar esa experiencia como otro punto de datos para incorporarlo al proceso de planeación en curso. Es una información que no tenías antes, que luego puedes usar para mejorar tu plan general del proyecto en tu viaje hacia el resultado del proyecto.

Un proyecto es una actividad de desarrollo del conocimiento.

Una vez que hayas aceptado la inevitable transición de un estado de ignorancia a un estado de descubrimiento, comenzarás a cuestionar la posibilidad de certeza en la planeación del proyecto. Una buena regla general es que si estás seguro de lo que depara el futuro para tu proyecto, probablemente estés equivocado o en realidad no necesites un plan de proyecto; una simple lista de tareas puede funcionar. Esto es especialmente cierto en campos donde el trabajo ocurre en diferentes ubicaciones, bajo circunstancias cambiantes, a menudo impredecibles. Como demostraron Dora Cohenca-Zall, Alexander Laufer y otros en sus investigaciones sobre planeación de proyectos de construcción, “los altos niveles de incertidumbre son la regla más que la excepción” (1994). Como comentamos en la Lección 1, los proyectos modernos se desarrollan en lo que Peter Vaill llama un estado de “aguas bravas permanentes” (Laufer 2012). Simplemente no es posible prever todos los problemas que puedan surgir a lo largo de la vida de un proyecto.

El objetivo final de la planificación de proyectos es una estrategia bien pensada que tenga suficiente flexibilidad para adaptarse a las circunstancias en desarrollo. Los propios planificadores deben involucrarse continuamente en lo que los psicólogos llaman reencuadre cognitivo, lo que significa reconsiderar eventos y hechos para verlos de una nueva manera. Sólo entonces podrán adaptarse a las circunstancias cambiantes a lo largo de la vida del proyecto.

Planeación es Adaptación y Colaboración

El objetivo de un plan de proyecto es explicar quién crea qué, cómo lo crean y con qué propósito. En otras palabras, un plan de proyecto es una herramienta de colaboración. El proceso de planeación es en sí mismo un ejercicio colaborativo que suele ser la primera prueba de la capacidad de un líder de equipo para generar confianza entre los miembros y aprovechar las múltiples perspectivas que ofrece un equipo diverso. El éxito en la planeación requiere de todas las habilidades y técnicas de trabajo en equipo a su disposición, que, como se discutió en la Lección 5, incluye prometedor confiable, inteligencia emocional, una perspectiva realista y buenas habilidades de comunicación. Cuantos más miembros del equipo confíen entre sí, más dispuestos estarán a asumir los tipos de riesgos requeridos para adaptarse a las circunstancias cambiantes.

En Becoming a Project Leader, Alexander Laufer, Terry Little, Jeffrey Russell y Bruce Maas cuentan historias sobre gerentes de proyectos que navegaron por proyectos volátiles y complicados al fomentar la adaptación y la colaboración (2018). Estos gerentes exitosos combinaron cuatro estrategias esenciales:

• Planificación evolutiva: Un enfoque basado en el aprendizaje para la planificación de proyectos que presume que el equipo del proyecto ampliará su conocimiento del proyecto a medida que se desarrolla.
• Agilidad de respuesta: Acción rápida para resolver problemas a medida que se desarrolla un proyecto, combinada con una comunicación clara y actualizada.
• Resiliencia proactiva: Desafiando “el status quo, proactiva y selectivamente” para prevenir posibles problemas.
• Trabajo en equipo colaborativo: Fomentar el trabajo en equipo flexible, receptivo e interactivo.

En Convertirse en un líder de proyecto, Alexander Laufer, Terry Little, Jeffrey Russell y Bruce Maas explican el valor de un enfoque de onda rodante para la planificación en situaciones volátiles en las que es difícil hacer compromisos firmes. Los gerentes de proyectos exitosos desarrollan planes “en oleadas a medida que el proyecto se desarrolla y la información se vuelve más confiable”. Este enfoque implica combinar “planes detallados a corto plazo” con planes de 90 días, de mediano plazo y planes maestros más generales que cubren la duración del proyecto:

Este estilo de planeación no implica que las decisiones deban ser arbitrariamente “pospuestas para más tarde”. Más bien, se trata de un acto de separación deliberada de aquellos aspectos de planeación sobre los que se puede actuar más oportunamente en el futuro. Al aplicar este enfoque, se evitan dos situaciones extremas. El primero es la preparación de planes demasiado detallados demasiado pronto, lo que puede llevar a una rápida obsolescencia porque algunas decisiones se basan en información proporcionada por conjeturas inteligentes más que en datos confiables. La otra situación extrema es retrasar la planeación hasta que toda la información esté completa y estable. En ambos casos, la efectividad del proyecto se verá afectada. Se pueden tomar decisiones oportunas y firmes únicamente adoptando el estilo de planeación que brinde mayor detalle en la etapa apropiada del proyecto. (18-19)

6.2 El enfoque del orden geométrico: empujar

El enfoque tradicional de orden geométrico de la planificación se basa en la idea de que, con suficiente investigación y previsión, los planificadores pueden prever la mayoría de las eventualidades. En otras palabras, los planificadores de orden geométrico asumen que es posible conocer todo, o casi todo, sobre un proyecto antes de que comience. Debido a que los planificadores asumen que tendrán poca necesidad de ajustarse a medida que se desarrolle el proyecto, la planificación del orden geométrico supone una progresión lineal de actividades secuenciales y predecibles. Cada participante tiene un lugar específico en un orden jerárquico y secuencial.

La planificación geométrica del orden funciona bien para actividades sencillas y predecibles que son fáciles de repetir, como colocar nuevas tuberías de alcantarillado. Tiende a enfocarse en optimizar las actividades individuales, presumiendo que cada actividad ocurre según lo programado. El problema con esta forma de pensar es que lleva a los planificadores a desconocer la incertidumbre asociada a las actividades que dependen entre sí, por ejemplo, supongamos que está diseñando un producto para un mercado exterior y estalla una guerra comercial, colocando una gran tarifa en tu producto, haciéndolo mucho más caro. En ese caso necesitarías repensar tu producto, sus mercados potenciales, y tal vez dónde se fabrica.

El término plan de empuje se utiliza para describir un plan de proyecto fundado en un supuesto de principios de orden geométrico. Una vez que el plan esté completo, se asume que el trabajo se desarrollará en consecuencia, dando como resultado un resultado predeterminado del proyecto. (Ver Figura 6-2.) Una vez que se pone en marcha un plan de empuje, las partes interesadas tienden a enfocarse en mantener las partes del plan avanzando. El término push se utilizó por primera vez en la manufactura para describir un sistema en el que “la producción se basa en un plan de producción proyectado y donde la información fluye de la gerencia al mercado, la misma dirección en la que fluyen los materiales” (BusinessDictionary n.d.).

Figura 6-2: Una vez que se pone en marcha un plan de empuje, las partes interesadas tienden a enfocarse en mantener las partes del plan avanzando.

Un sistema push generalmente se construye alrededor de pronósticos de la demanda de los clientes, lo que puede o no ser correcto. Sin embargo, una vez que se pone en marcha un plan de empuje, la demanda real del producto final es menos preocupante durante la producción que la necesidad de mantener las partes del plan avanzando. Un plan push puede ser apropiado donde el tipo de proyecto y las actividades a realizar son bien conocidas y muy similares a proyectos anteriores. También es apropiado a la hora de producir una mercancía para un público general. En construcción y manufactura, el objetivo final de la planificación push es producir un producto con el menor costo posible. En un proyecto de plan de empuje, los subcontratistas se enfocan en completar su trabajo a tiempo y dentro del presupuesto, para que puedan terminar su trabajo y pasar a otro proyecto. Se construye alrededor de pronósticos de disponibilidad de mano de obra (ver Figura 6- 3), que en realidad son difíciles de predecir y a menudo son erróneos. Mientras tanto, los gerentes suelen ser juzgados por su capacidad para cumplir con el programa de producción predefinido. De esta manera, el interés propio individual impulsa un proyecto de empuje hacia adelante, con una consideración limitada por un proyecto en el que se gestiona el flujo de trabajo y se evita el desperdicio mediante la colaboración y la coordinación.

Figura 6-3: La planificación push se construye alrededor de pronósticos de disponibilidad de mano de obra, lo que puede ser incorrecto. (Adaptado de una imagen de David Thomack.)

A veces encontrará que la planificación push se conoce como make-to-stock—la idea es que un sistema de fabricación push procesa grandes lotes de artículos al ritmo más rápido posible, basado en pronósticos de demanda, y luego los mueve “al siguiente proceso descendente o al almacenamiento” (Plex 2017). Esa es una forma simplista de pensar sobre el empuje, pero es una buena manera de empezar a comprender la idea básica. Para ello, aquí hay algunos ejemplos simplificados de sistemas push:

• Libros de texto que se imprimen y envían a un almacén, donde esperan pedidos de librerías que podrían o no necesitarlos. El total depende en parte de los pronósticos de ventas de la demanda estudiantil y en parte del menor número de libros que el impresor esté dispuesto a imprimir.
• Sal de acera que se fabrica y envía a ferreterías en San Luis. La misma cantidad se envía cada año, incluso durante un invierno excepcionalmente cálido en el que la temperatura nunca va por debajo del punto de congelación.

Para un ejemplo humorístico pero informativo de una planificación de empuje extremadamente mala, vea la famosa escena de envoltura de chocolate de I Love Lucy, en la que las pobres Lucy y Ethel intentan mantenerse al día con una cinta transportadora cada vez más rápida:

Un elemento de YouTube ha sido excluido de esta versión del texto. Puedes verlo en línea aquí: pb.libretexts.org/web1/? p=76

Se pueden encontrar ejemplos más complicados de planificación push en todas las industrias, incluida la fabricación, el desarrollo de productos, la atención médica y la construcción. Puede identificar un sistema push observando los diversos procesos en un sistema en particular e identificando qué desencadena un proceso particular para comenzar a trabajar. En un sistema push, un proceso ascendente es responsable de impulsar el trabajo al siguiente proceso descendente. Por ejemplo, en un hospital, el servicio de urgencias podría empujar a un paciente recién llegado río abajo, al piso de cirugía para esperar un procedimiento (Ver Figura 6-4.) Si el piso de cirugía no tiene camas disponibles, el paciente tendrá que esperar en el servicio de urgencias hasta que se abra una. En este entorno de empuje, donde “la transición del trabajo es responsabilidad del proceso aguas arriba (es decir, previo)”, corresponde al personal de emergencia manejar la situación, asegurando finalmente que el paciente efectivamente obtenga un lugar aguas abajo en el piso de cirugía (Institute for Healthcare Improvement n.d.).

Figura 6-4: Flujo de pacientes en un entorno hospitalario de empuje.

Un sistema push carece de cualquier límite explícito sobre la cantidad de trabajo que puede estar en proceso en el sistema en cualquier momento (Hopp y Spearman 2004, 142). Una vez que comienza el trabajo, se supone que debe continuar, sin tener en cuenta los retrasos debidos a errores, disponibilidad de recursos y otros problemas. Así, cuando surgen problemas, el sistema se ralentiza a un rastreo o se detiene por completo porque carece de los mecanismos incorporados para evaluar y mejorar el flujo que se encuentran en las metodologías Lean y otras metodologías de orden vivo.

En el desarrollo de software, el ejemplo clásico de planeación push es el modelo de cascada, ilustrado en la Figura 6-5. En su forma más pura, el modelo de cascada concibe el desarrollo de software como un conjunto de pasos discretos y secuenciales. Presume un resultado del proyecto altamente predecible, con poca o ninguna oportunidad de ajustes a medida que se desarrolla el proyecto. En efecto, una vez que el proyecto llega a la etapa de prueba, los costos y otras consideraciones hacen casi imposible retroceder y alterar el plan original.

Figura 6-5: Modelo cascada de desarrollo de software.

Las muchas variaciones de la planificación push son fundamentalmente atractivas porque presumen que el mundo opera de acuerdo con un conjunto de reglas prescritas. Después de todo, como nos enseñó Isaac Newton, vivimos en un mundo donde las leyes de la física producen resultados predecibles. Si se le cae un balón de fútbol, ya sabe que va a golpear el suelo. Si lo lanzas, sabes que viajará por el aire. En otras palabras, estamos conectados para pensar que una planeación cuidadosa puede producir resultados predecibles. Pero esa forma de pensar estática y de orden geométrico no refleja adecuadamente la realidad de la planeación moderna de proyectos. Debemos tomar en cuenta el orden vivo.

Modelo Cascada: Algo de Historia

El modelo Waterfall fue introducido por primera vez por Winston W. Royce, en un artículo de 1970 titulado “Managing the Development of Large Software Systems”. Royce describió un proceso de desarrollo ideal, en el que los desarrolladores se dedicaron a una planificación detallada al comienzo del proyecto y luego escribieron el código para que coincidiera con las especificaciones minuciosas, produciendo un resultado predecible. Pero Royce no estaba recomendando esto como una forma realista de desarrollar software. De hecho, la frase inmediatamente posterior a su diagrama de cascada dice: “Creo en este concepto, pero la implementación descrita anteriormente es arriesgada e invita al fracaso” (Royce). Para su consternación, su descripción del método de cascada excesivamente simplista arrasó el mundo del desarrollo de software de las décadas de 1970 y 1980 como un incendio forestal. Para una narración cautivadora de la historia del método de la cascada, vea este video de Glen Vanderburg, a partir de las 9:00:

“Real Software Engineering — Glenn Vanderberg, Lone Star Ruby Conference 2010.”

Un elemento de YouTube ha sido excluido de esta versión del texto. Puedes verlo en línea aquí: pb.libretexts.org/web1/? p=76

6.3 El enfoque del orden vital: Planeación de extracción

La planeación pull es la aplicación práctica del enfoque de orden vivo a la planeación de proyectos. Es colaborativo, flexible y recursivo, y es especialmente adecuado para proyectos altamente complejos en los que los interesados tienen que adaptarse a la nueva información. Se presume un grupo de trabajadores que coordinan regularmente, actualizando su plan para reflejar las condiciones actuales. Se enfoca en producir tanto como realmente se pueda completar y no más. El objetivo final de la planificación pull es crear el mejor valor posible.

El pensamiento detrás del tirón se originó en 1948 con Taiichi Ohno, conocido como el “padre del Sistema de Producción Toyota”, lo que a su vez llevó a Lean y Agile. Al vivir en el Japón posterior a la Segunda Guerra Mundial, donde la escasez de alimentos era un problema frecuente, Ohno se inspiró en los supermercados estadounidenses, con su capacidad aparentemente mágica para proporcionar lo que los clientes quisieran, cuando lo querían:

El pensamiento pull viene antes de la programación de pull

En la lección 7, aprenderá a crear horarios de extracción, que generalmente son creados por un grupo de partes interesadas que colaboran colocando notas Post-it multicolores en una tabla de planificación del tamaño de una pared. Es bueno saber cómo crear horarios de extracción, pero antes de que puedas hacerlo, necesitas comprender los fundamentos del pull thinking discutidos en esta lección. Para la mayoría de las personas, el pull thinking es una forma completamente nueva de ver la planificación de proyectos. La programación de pull es la implementación práctica del pull thinking. Una vez que comprendes los conceptos esenciales del pull thinking, el proceso de crear un horario de extracción es algo que puedes aprender haciendo.

Desde el supermercado tuvimos la idea de ver el proceso anterior en una línea de producción como una especie de tienda. El proceso posterior (cliente) va al proceso anterior (supermercado) para adquirir las piezas necesarias (commodities) en el momento y en la cantidad necesaria. El proceso anterior produce inmediatamente la cantidad que acaba de tomar (reabastecer los estantes). (Ohno 1988, 26)

Un sistema de extracción a veces se conoce como “make-to-order”, lo que sugiere que un cliente realiza un pedido, momento en el que toda la instalación de producción se pone en marcha para crear el artículo requerido para cumplir con ese pedido. Esa es una versión muy simplificada de pull, pero es un punto de partida útil. Estos dos ejemplos de cadena de suministro ilustran esta versión elemental de pull:

• Un estudiante ordena un libro de texto en línea, una sola copia del cual luego se imprime y se envía directamente al estudiante.
• Un cliente de una tienda de pintura pone los últimos tres contenedores de imprimación en su carrito, lo que incita al empleado de la tienda a reabastecer el contenedor de imprimación.

En realidad, el concepto de “cliente” significa más en tirón que solo el usuario final. En un sistema de extracción, un proceso aguas abajo es el cliente del proceso anterior, ascendente. Esto es lo que esto significaría en un sitio de construcción:

Todo el trabajo se realiza al tirón del cliente. Por lo que el electricista está completando su desbaste en la pared para que el drywaller, su cliente, pueda comenzar de pie como roca. El drywaller está colgando roca para que su cliente, el pintor, pueda comenzar a trabajar. Al trabajar hacia atrás desde un hito del proyecto... nos aseguramos de que todo el trabajo se incorpore al plan. El resultado es que el trabajo ocurre en el momento adecuado, no sólo cuando puede. (Lemke 2016)

La planificación de extracción es un concepto clave en Lean, que valora el flujo continuo de trabajo sin las inevitables paradas y arranques (es decir, residuos) que caracterizan la planificación push. Como se ilustra en la Figura 6-6, la planificación de extracción elimina los pasos innecesarios, ahorrando hasta un tercio del tiempo requerido para completar un proyecto similar diseñado de acuerdo con un plan de empuje tradicional.

Figura 6-6: La planificación de extracción elimina el desperdicio al eliminar pasos innecesarios. (Fuente: John Nelson)

En el pensamiento Lean, la planificación es un proceso fluido y en tiempo real. Para ser un planificador eficaz de proyectos Lean, es necesario comprender que el orden vital sigue evolucionando. La planeación ya no consiste en comunicar y reforzar un plan estático formal y predefinido a todos los miembros del equipo. Se trata de darle a cada miembro del equipo una forma de pensar sobre el proyecto y un proceso para incorporar nuevos conocimientos al plan, con opciones regulares para restablecer el plan a medida que se desarrolla el proyecto.

6.4 Distinguir entre empujar y tirar

En la planeación pull, comienzas por identificar el estado final deseado del proyecto, que es el valor que quieres crear. Entonces trabajas hacia atrás para determinar la forma más eficiente (menos derrochadora) de llegar allí. Esto es similar a una tripulación de kayakistas que caminan hasta el fondo de un tramo de rápidos y miran hacia atrás para formular un plan para atravesarlos. Después de eso, pueden regresar al inicio de las aguas bravas e intentar navegar por los rápidos con un mejor sentido de los retos que se avecinan.

La mejor manera de comprender la naturaleza de un sistema de tracción es compararlo con empujar. Como ejemplo sencillo, supongamos que está planeando unas vacaciones europeas. Si estuvieras tomando un enfoque de planificación push, comenzarías a hacer una lista de todos los sitios recomendados en los países que visitarás. El resultado sería un horario que destina todo el tiempo disponible a los distintos destinos. Tal plan de vacaciones es esencialmente una lista de verificación de cosas que hacer o ver. Por el contrario, un enfoque de extracción estaría completamente enfocado en cómo quieres sentirte de camino a casa, es decir, el valor que quieres que cree el viaje. Podrías revisar la misma lista de posibles sitios y actividades, pero tus decisiones sobre cuáles incluir en tu plan dependerán de cómo quieras sentirte cuando termine el viaje.

La Figura 6-7 ilustra los inicios de un plan de extracción para dos posibles tipos de vacaciones, una que te deja descansado y otra que te deja sintiéndote vigorizado por nuevas experiencias. Al igual que con todos los planes de pull, el secreto es comenzar por el final. ¿Cómo quieres sentirte de camino a casa? Entonces, como se muestra en la Figura 6-8, puedes agregar actividades a tu plan que aseguren que termines sintiéndote así. Como puedes ver, las Notas Post-it se utilizan en ambas figuras. Si bien hay muchos programas de programación y planificación para elegir, Post-it Notes, una opción de muy baja tecnología, se utilizan ampliamente en la programación pull porque son fáciles de mover, alentando así al planificador a probar nuevas ideas.

Figura 6-7: En la planificación de extracción, comienza con el estado final deseado

Figura 6-8: Después de identificar el estado final deseado, puede planificar las actividades que resultarán en ese estado final.

Planeación de extracción en acción

Para una introducción más extensa a la planificación de extracción, vea este video de una hora, producido por los autores de este libro, que utiliza la planificación de unas vacaciones como una forma de explicar conceptos esenciales de planificación de extracción.

Un elemento de YouTube ha sido excluido de esta versión del texto. Puedes verlo en línea aquí: pb.libretexts.org/web1/? p=76

A medida que aprendas a identificar push and pull en el trabajo en varios entornos, comenzarás a ver cómo las organizaciones usan uno u otro, o combinan ambos enfoques para lograr sus metas. El hecho es que “en el mundo real, no hay sistemas puros de push o pure pull” (Hopp y Spearman 2004, 143). También descubrirás que los conceptos de empujar y tirar se utilizan para enfatizar diferentes preocupaciones en diferentes contextos.

Por ejemplo, considere cómo se utilizan los términos en el mundo de la gestión de la cadena de suministro, que engloba “todas las actividades que deben realizarse para poner el producto adecuado en manos del consumidor adecuado en la cantidad y en el momento adecuado, desde la extracción de materias primas hasta la compra del consumidor” (Mays Business School n.d.). En la gestión de la cadena de suministro, los expertos en empuje/tracción a menudo hablan del límite entre una porción de empuje de un sistema y la porción de tracción (Sehgal 2009). Como en el siguiente ejemplo, el límite entre push y pull generalmente surge después de que un producto ha sido fabricado en un entorno push, basado en pronósticos generales de la demanda del consumidor, y almacenado hasta que las solicitudes específicas de clientes específicos llevan el producto al mercado:

Un fabricante de alimentos puede hacer sopa de champiñones que marca de varias maneras, su propia etiqueta más las de varias cadenas de supermercados. El fabricante tiene una buena idea de la cantidad de sopa que necesitan cada mes. Están menos seguros, sin embargo, de cómo empaquetarlo para satisfacer la demanda. Como resultado, es probable que opten por producir en masa la sopa de champiñones y la inventariarán en latas sin etiquetar hasta que se materialicen los pedidos. Entonces pueden etiquetar rápidamente las latas y enviarlas cuando los clientes hagan sus pedidos. (McGinley 2016)

Pero no dejes que estas aplicaciones más especializadas de los conceptos de empujar y tirar te distraigan del significado fundamental de tirar. Sea cual sea tu área de especialización, nunca te equivocarás aplicando un poco de pull thinking a un nuevo proyecto. ¿Cuál es el estado final deseado del proyecto? ¿Qué valor quieres que cree el proyecto? Lo más importante, ¿cómo colaborará con los grupos de interés del proyecto para lograrlo?

Pull Hablar en Público

Matthew David Potter, estudiante de Maestría en Administración de Ingeniería en la Universidad de Wisconsin-Madison, señaló que, al trabajar en una presentación de clase, trató de enfocarse en lo que sería útil para sus compañeros de estudios, en lugar de en lo que quería incluir. En otras palabras, como todos los buenos comunicadores, se centró en las necesidades de su público. Más tarde, se dio cuenta de que enfocarse en la audiencia es en realidad una forma de pensar pull, comenzando en el estado final deseado, y luego averiguar cómo lograrlo.

Resume su experiencia de la siguiente manera:

• Si comienza por el final (cliente), identifica los tres puntos clave (valor) y luego vuelve a extraer ese valor a medida que crea las diapositivas (flujo y flujo de valor), el resultado final es mucho más ajustado. Adoptar ese enfoque me animó a cortar información que podría ser interesante para mí, pero que no fue crítica para hacer mis puntos principales (desperdicio).
• Por el contrario, el enfoque de empuje geométrico comienza con la identificación de toda la información que quieres compartir, seguido de la creación de diapositivas para cada punto importante, y luego una lucha para atarlo todo y de alguna manera editarlo para mantener la presentación bajo el límite de tiempo prescrito (pers. comm., 15 de junio de 2018).

6.5 Pull y Ágil

Ágil al Rescate

Los muchos problemas asociados con el despliegue del sitio web HealthCare.gov en 2013 se pueden rastrear a un intento de utilizar un modelo de desarrollo en cascada para un proyecto vasto y complicado. El proyecto fue rescatado por un equipo de desarrolladores Agile, muchos de los cuales esencialmente ofrecieron su tiempo como voluntarios para poner en marcha el sistema. Puedes leerlo todo aquí: “El equipo de trauma de Obama: cómo un grupo improbable de magos de alta tecnología revivió el problemático sitio web HealthCare.gov de Obama”.

El desarrollo ágil de software enfatiza un enfoque iterativo de la planeación. Mientras que el enfoque tradicional de cascada para el desarrollo de software supone pocos cambios en el proyecto después de que se hayan formulado los requisitos de software, Agile está diseñado específicamente para permitir que los participantes del proyecto se adapten a las circunstancias cambiantes, la más importante de las cuales suele ser la del cliente. noción evolutiva de los requisitos de software. En lugar de planear todo el proyecto al principio, los planificadores de proyectos Agile se enfocan en crear iteraciones aceleradas y evolutivas del producto en carreras de desarrollo de una a dos semanas.

A diferencia de la gestión de proyectos tradicional, que supone un comienzo bien definido para un proyecto, con tareas desplegadas hasta el final bien definido, la gestión de proyectos ágil tiene un flujo iterativo y circular. El motor que impulsa este flujo es una retroalimentación continua de los propietarios del producto sobre qué tan bien el software satisface sus necesidades. A medida que el software comienza a tomar forma, se pide continuamente a los propietarios de productos que tomen decisiones

sobre qué características valoran más y cuáles podrían prescindirse para cumplir con el presupuesto y el calendario del proyecto. Esto significa que, en el desarrollo ágil, la planeación no termina hasta que termina el proyecto. La previsibilidad surge si le das tiempo para que emerja de forma natural y te elude si intentas forzarla demasiado pronto. Uno de los dones de Agile es que se autocalibra. Una vez que ejecutas algunos sprints, comienza a surgir una tasa real de progreso, calibrada para el equipo particular, patrocinador, tecnología y requisitos. (Merrill 2017)

A medida que el software crece cada vez más importante en muchos tipos de productos, es probable que Agile, con sus ciclos de retroalimentación rápida y revisiones, se vuelva más común en el desarrollo de productos, incluso entre los grandes fabricantes como John Deere. Los ciclos de desarrollo ágil producen software de trabajo más rápido, lo que facilita la obtención de comentarios del marketing y de los clientes al principio del ciclo de vida del desarrollo del producto. La ingeniería ágil, como se llama esta nueva forma de desarrollo de productos, anima a los equipos a aprender sobre su producto y realizar mejoras más rápido de lo que podrían con el desarrollo tradicional de productos. En una entrada de blog para FormLabs, un fabricante de impresoras 3D de alta gama, Joris Peels escribe,

Aprender del fracaso a través de prototipos ayuda a las empresas a construir rápidamente mejores productos. Al validar suposiciones y recopilar datos, estos productos se realizan de una manera más precisa y probatoria.

Con métodos tradicionales, los equipos elaboran minuciosamente mapas del mundo y luego pasan meses planeando una posible ruta a través de este mundo imaginado. Sólo entonces tienen un producto y realmente saben dónde están parados. Con Agile Engineering, los productos emergen en la primera semana de desarrollo de productos. Los equipos partieron y revisan su brújula a menudo. (2016)

6.6 Sustentabilidad: Planificación para la Mejora Continua

La mejora continua es “un método para identificar oportunidades para agilizar el trabajo y reducir el desperdicio” (LeanKit n.d.). Conocido en Lean como kaizen (japonés para mejorar), la mejora continua es un concepto clave en Lean y Agile, pero es una fuerza motivadora en todo tipo de organizaciones. Para incorporar completamente la mejora continua a la filosofía de tu organización, necesitas integrarla en proyectos, comenzando con la fase de planeación. En efecto, el mismo proceso de planeación es en sí mismo una actividad de mejora continua porque implica mirar hacia el futuro y pensar en cómo hacer las cosas mejor.

La mejora continua es un concepto importante para las organizaciones que buscan realizar cambios sistemáticos de sustentabilidad, y para proyectos individuales relacionados con la sustentabilidad. Esto es especialmente cierto para los proyectos que se desarrollan durante un largo período de tiempo porque las nuevas tecnologías de sustentabilidad podrían estar disponibles durante el transcurso del proyecto. Según Bill Wallace, autor de Becoming Part of the Solution: The Engineer's Guide to Sustainable Development , los programas de mejora continua dedicados a amplificar los esfuerzos de sustentabilidad de una empresa deben incluir lo siguiente:

Evaluación basal. La firma debe determinar su impacto ambiental y social actual. Esto debe hacerse definiendo primero el alcance de las actividades de la firma y evaluando los impactos de esas actividades contra los estándares de desempeño existentes, normas, u otras firmas comparativas...

Establecer objetivos de mejora. Con base en los resultados de la evaluación de línea base, la firma debe idear un conjunto integral de objetivos de mejora. Los objetivos deben ser medibles frente a los indicadores establecidos. Horarios... también deben establecerse...

Implementación. Una vez establecidos los objetivos y los cronogramas, la firma deberá idear programas para su implementación y asignar fondos suficientes para lograr los objetivos. Deben generarse informes regulares de desempeño sustentable y enviarse a la alta dirección... Los informes también deben contener una evaluación de los desarrollos tecnológicos que podrían cambiar las prácticas actuales.

Revisión y revisión. La firma debe programar revisiones periódicas... para verificar el progreso con los objetivos y planes y ver cómo se gastaron los fondos del programa. Con base en el desempeño del programa, las expectativas de los clientes, los nuevos puntos de referencia, las nuevas tecnologías, el desempeño de toda la empresa u otras variables, los objetivos deben revisarse y revisarse en consecuencia. (2005, 95)

6.7 Una palabra sobre planes de contingencia

Cuidado con la Falacia de Planeación

Según este interesante y entretenido podcast, los humanos están genéticamente cableados para el optimismo. Esto nos hace dolorosamente susceptibles a la falacia de planeación, un sesgo cognitivo que nos hace pensar que podemos terminar proyectos más rápido, y por menos dinero, de lo que en realidad es realista: “He aquí por qué todos tus proyectos siempre llegan tarde — y qué hacer al respecto (Freakonomics Podcast). ”

Además de crear el plan del proyecto, es necesario crear un plan de contingencia, que es un plan para abordar posibles obstáculos clave para el éxito del proyecto. Un plan de contingencia define caminos alternos para el proyecto en caso de que se realicen diversos riesgos. Un plan de contingencia normalmente incluye un fondo de contingencia, que es una cantidad de recursos reservados para cubrir costos imprevistos. Los planes de contingencia y los fondos son necesarios porque incluso el planificador de proyectos más experimentado a veces sucumbe al optimismo excesivo, asumiendo que todo irá bien y que todos los recursos estarán disponibles cuando sea necesario. Además, no importa cuán minuciosamente planifiques un proyecto, inevitablemente perderás al menos algunos problemas pequeños.

Ejemplos de temas que podrían requerir el uso de un fondo de contingencia:

• Estimaciones iniciales inadecuadas
• Artículos pequeños no cubiertos en la planificación
• Errores en las estimaciones iniciales
• Pequeñas desviaciones debido a retrasos inevitables

Tenga en cuenta que un fondo de contingencia no está diseñado para gestionar grandes desviaciones o cambios de alcance.

Una forma sencilla y efectiva de planeación de contingencia es reservar un fondo de contingencia consistente en un porcentaje fijo de todos los recursos (tiempo, dinero, personas) además de los montos que se detallan en el presupuesto final. El diez por ciento es una cantidad típica, pero que puede variar dependiendo del tamaño y tipo de proyecto, así como del tipo de industria. Por ejemplo, este conjunto de pautas de contingencia, creado por la Universidad Estatal de Arizona para proyectos de construcción de campus, muestra una gama de porcentajes de contingencia: “Directrices de contingencia de proyectos”. Asimismo, el Departamento de Energía de Estados Unidos describe aquí un enfoque de porcentaje fijo para la planeación de contingencia: “Contingencia”.

Una de las principales dificultades de la planeación de contingencia es lograr que la gente se ponga de acuerdo sobre exactamente qué es y qué no está cubierto por un fondo de contingencia, y cómo se aplica en circunstancias específicas. Se ha realizado una considerable cantidad de investigaciones sobre este tema, pero aún no hay un consenso claro. Por esa razón, antes de lanzar un proyecto importante, sería prudente investigar los entresijos de la planificación de contingencia en su organización en particular, y en su industria en general.

La planificación de contingencias está estrechamente relacionada con la gestión de riesgos, lo cual se discute en la Lección 8. Cuando estás trabajando en proyectos pequeños de complejidad limitada, probablemente puedas asumir que un plan de contingencia de porcentaje fijo cubrirá la mayoría de los riesgos. Sin embargo, para proyectos altamente complejos y técnicamente desafiantes, es importante distinguir entre contingencias genéricas de planeación presupuestaria (usando un porcentaje fijo) y el modelado más sofisticado del riesgo de incertidumbre.

~Consejos prácticos

• Usa el nivel de detalle adecuado: Un plan de proyecto necesita ser presentado en el nivel correcto, con los detalles suficientes. Un plan de muy alto nivel con un mínimo detalle no será significativo para todos los interesados. Por otro lado, un plan de proyecto extremadamente complejo con detalles innecesarios y un sinfín de listas de tareas puede ser tan difícil de actualizar que la gente a menudo simplemente descuidará hacerlo. En ese punto, tal plan se vuelve peor que inútil. Como regla general, un plan de proyecto necesita entre 15-50 actividades. Eso ayudará a garantizar que un plan sea lo suficientemente detallado como para actuar pero lo suficientemente manejable como para mantenerse actualizado. Luego puede usar subplanes para desglosar las tareas con más detalle.
• Prepárate para adaptar tu plan para reflejar realidades cambiantes: Al planear un proyecto, nunca asumas que estás tratando de alcanzar un objetivo fijo. En la gran mayoría de los proyectos, el objetivo realmente se mueve. Necesitas ser flexible y adaptar tu plan según sea necesario.
• Planificar con el nivel adecuado de precisión: Tenga cuidado de no planificar con un nivel de precisión que exceda su comprensión de los muchos factores que podrían afectar al proyecto. Hacerlo genera dos veces residuos: primero en el proceso de planeación, y luego en la etapa de ejecución cuando encuentras que el plan necesita ser revisado para reflejar la realidad de la situación. Puedes estar seguro de que tu planeación implica un nivel de precisión poco realista si, por ejemplo, da como resultado una estimación como $380,275,465.47. Ese nivel de precisión implica un nivel de precisión que no existe en el mundo real. Es más útil decir que un proyecto de este tipo vale en algún lugar del rango de 350 a 400 millones de dólares.
• Utilice la tecnología de programación como una de las muchas herramientas de planificación: Utilice herramientas tecnológicas, como el software de gestión de proyectos, a las que todas las partes interesadas comprendan y sepan acceder. Pero no cometas el error de pensar que crear un horario es lo mismo que planear el proyecto. Un horario es solo un aspecto de un plan de proyecto.
• Mantenga su ojo en el éxito: A lo largo del proceso de planeación, mantenga un enfoque claro en la definición del éxito del proyecto.
• Reúna a todos para planificar: Si tu equipo está repartido en múltiples ubicaciones geográficas, trata de que todos se reúnan en un solo lugar durante al menos parte de la fase de planificación. Esto puede ayudar en gran medida a aclarar los malentendidos causados por correos electrónicos mal redactados o conferencias telefónicas en las que algunas partes interesadas podrían dominar más que otras.
• Piensa de manera integral sobre tu plan de proyecto: Un buen plan de proyecto toca cada elemento del proyecto. Este video de 3.5 minutos brinda una visión general rápida de las cosas en las que pensar al planear un proyecto: “¿Qué entra en un plan de proyecto? ”

~Resumen

• En orden vivo, un plan no es un fin en sí mismo, sino un marco estratégico para la programación y ejecución de un proyecto. Es útil pensar en un proyecto como una actividad de desarrollo del conocimiento. La planeación de proyectos, entonces, es el proceso continuo de incorporar nuevos conocimientos a un plan de proyecto. Un plan de proyecto es una herramienta de colaboración, y el proceso de planeación es en sí mismo un ejercicio colaborativo que suele ser la primera prueba de la capacidad de un líder de equipo para generar confianza entre los miembros y aprovechar las múltiples perspectivas que ofrece un equipo diverso.
• La planificación del orden geométrico supone una progresión lineal de actividades secuenciales y predecibles. El término plan de empuje se utiliza para describir un plan de proyecto fundado en un supuesto de principios de orden geométrico.
• La planeación pull es la aplicación práctica del enfoque de orden vivo a la planeación de proyectos. Es colaborativo, flexible y recursivo, y es especialmente adecuado para proyectos altamente complejos en los que los interesados tienen que adaptarse a la nueva información. Se presume un grupo colaborativo de trabajadores que coordinan regularmente, actualizando su plan para reflejar las condiciones actuales. Se enfoca en producir tanto como realmente se pueda completar y no más.
• Agile adopta un enfoque de pull planning para el desarrollo de software. Es iterativo y supone una adaptación constante en respuesta a la noción evolutiva del cliente de los requisitos de software.
• La mejora continua, un concepto clave en Lean y Agile, es una idea importante para las organizaciones que buscan realizar cambios sistemáticos de sustentabilidad, y para proyectos individuales preocupados por la sustentabilidad.
• Además de crear un plan de proyecto, es necesario crear un plan de contingencia que aborde los resultados no detallados en el plan del proyecto.

~Glosario

• Ingeniería ágil: una nueva forma de desarrollo de productos que hace uso de los ciclos interactivos de retroalimentación rápida y revisiones implementadas por primera vez en el desarrollo de software Agile. Alienta a los equipos a aprender sobre su producto y realizar mejoras más rápido de lo que podrían con el desarrollo tradicional de productos.
• reencuadre cognitivo —El proceso de reconsiderar eventos y hechos para verlos de una nueva manera.
• plan de contingencia —Un plan para una ruta alternativa al éxito del proyecto que se pueda implementar si surge un obstáculo para el progreso.
• fondo de contingencia —Recursos reservados para cubrir costos imprevistos.
• plan —Un marco estratégico para la programación y ejecución de un proyecto. En la planeación tradicional de proyectos de orden geométrico, un plan presume que los eventos se desarrollarán de manera predecible, con poca necesidad de actualizar el plan. En la planeación de proyectos de orden vivo, el plan es siempre provisional y sujeto a cambios.
• sesgo de planeación —Un sesgo cognitivo que nos hace pensar que podemos terminar proyectos más rápido, y por menos dinero, de lo que en realidad es realista.
• planeación de proyectos —En la planeación de proyectos de orden geométrico tradicional, el proceso de formulación del plan que guiará el resto del proyecto. En la planeación de proyectos de orden vital, la “planeación de proyectos” también se refiere al proceso continuo de incorporación de nuevos conocimientos al plan inicial del proyecto.
• pull planning —Planeación de proyectos que da cuenta de la naturaleza impredecible y siempre cambiante del orden vivo. Los planificadores de extracción comienzan en el estado final deseado del proyecto, trabajando hacia atrás para determinar la forma más eficiente (menos derrochadora) de lograr el resultado deseado. Para ser efectiva, la planeación pull requiere de un grupo colaborativo de trabajadores que coordinen regularmente, actualizando su plan para reflejar las condiciones actuales.
• programa de extracción: un programa que normalmente consiste en notas adhesivas codificadas por colores que se pueden quitar o reposicionar según sea necesario. Esto también se puede replicar en varios programas de software diferentes. La clave es comenzar con el objetivo final y luego trabajar hacia atrás para determinar las tareas que se requieren para lograr ese objetivo.
• planificación de empuje —Planeación de proyectos que presume que los eventos se desarrollarán en un orden geométrico predecible. La planificación de empuje se basa en pronósticos de gestión de la demanda de los clientes, con gran énfasis puesto en la necesidad de mantener las partes del plan avanzando. Los gerentes y subcontratistas se enfocan en sus partes individuales del proyecto, con una consideración limitada para administrar el flujo de trabajo y prevenir el desperdicio a través de la colaboración y la coordinación
• gestión de la cadena de suministro —Todas las “actividades que deben realizarse para que el producto adecuado llegue a las manos del consumidor adecuado en la cantidad y en el momento adecuado, desde la extracción de materias primas hasta la compra del consumidor” (Mays Business School n.d.).
• modelo en cascada: un modelo de plan de empuje utilizado para software que divide el proceso de desarrollo en un conjunto de pasos discretos y secuenciales. Presume un resultado predecible del proyecto, con poca o ninguna oportunidad de ajustes a medida que se desarrolla el proyecto.

Recursos adicionales

• Este video de una hora, producido por los autores de este libro, utiliza la planificación de unas vacaciones como una forma de explicar conceptos esenciales de planeación de pull: https://go.wisc.edu/livingpm.
• Glosario del Lean Construction Institute, con definiciones de “push” y “pull”: “push” y “pull” Definiciones.
• En este libro, Peter Vaill introduce el término “aguas bravas permanentes:” Managing as a Performing Art: New Ideas for a World of Caotic Change (1989).
• En este video, los participantes del taller construyen dos casas con bloques de plástico, la primera siguiendo un plan de empuje tradicional y la segunda empleando los elementos de la planeación pull: “Pull Planning Workshop: San Diego Mesa College”. No te sorprenderá saber que las casas de planeación de tracción se completaron más rápidamente, con más cooperación y mayor satisfacción general entre los miembros del equipo.

Referencias

BusinessDictionary. n.d. “Sistema Push”. BusinessDictionary. Accedido el 1 de julio de 2018. http://www.businessdictionary.com/de...sh-system.html.

Cohenca-Zall, Dora, Alexander Laufer, Aviad Shapira, y Gregory A. Howell. 1994. “Proceso de Planeación durante la Construcción”. Revista de Ingeniería y Gestión de la Construcción, Septiembre: 561-578. tx.technion.ac.il/~AviShap/du... n-Planning.pdf.

Hopp, Wallace J., y Mark L. Spearman. 2004. “Tirar o no tirar: ¿cuál es la pregunta?” Gestión de Operaciones de Manufactura y Servicios 133-148.

Instituto para el Mejoramiento de la Salud. n.d. “Utilizar Sistemas Pull para Mejorar el Flujo”. ihi.org. Accedido julio 1, 2018. www.IHI.org/Resources/Pages/c... llSystems.aspx.

Laufer, Alexander. 2012. Dominar el papel de liderazgo en la gestión de proyectos: prácticas que ofrecen resultados notables. Upper Saddle River: FT Press.

Laufer, Alexander, Terry Little, Jeffrey Russell, y Bruce Maas. 2018. Convertirse en Líder de Proyectos: Combinando Planificación, Agilidad, Resiliencia y Colaboración para Entregar Proyectos Exitosos Nueva York: Palgrave Macmillan.

LeanKit. n.d. “¿Qué es la Mejora Continua?” LeanKit. Accedido el 1 de julio de 2018. https://leankit.com/learn/kanban/con...s-improvement/.

Lemke, Klaus. 2016. “3 Ruas Simples para una Planeación Eficaz de Pull”. LeanProject. 15 de diciembre. http://www.leanproject.com/news/3-si...pull-planning/.

Mays Business School. n.d. “¿Qué es la Gestión de la Cadena de Suministro?” Escuela de Negocios Mays, Universidad A&M de Texas. Accedido el 1 de julio de 2018. http://mays.tamu.edu/department-of-i...in-management/.

McGinley, Bill. 2016. “Cómo Determinar Cuándo Usar Programación de Producción Push o Pull”. Carpedia. 24 de octubre. http://carpedia.com/blog/determine-u...on-scheduling/.

Merrill, Robert, entrevista de Ann Shaffer. 2017. Analista Senior de Negocios, Universidad de Wisconsin-Madison (2 de octubre).

Ohno, Taiichi. 1988. Sistema de Producción Toyota: Más allá de la Producción a Gran Escala. Cambridge, MA: Prensa de productividad.

Peelings, Joris. 2016. “Por qué la ingeniería ágil es el futuro del diseño de productos”. FormLabs. 7 de marzo. Accedido 5 2017, octubre. https://formlabs.com/blog/agile-engi...t-development/.

Plex. 2017. “Fabricación Push vs Pull: ¿un sistema Kanban Pull es adecuado para su empresa?” Semana de la Industria, 28 de julio. http://www.industryweek.com/cloud-co...t-your-company.

Royce, W.W. 1987. “Gestionar el desarrollo de grandes sistemas de software: Conceptos y Técnicas”. ICSE '87 Actas de la 9ª conferencia internacional de Ingeniería de Software. Monterey: IEEE Computer Society Press. 328-338.

Sehgal, Vivek. 2009. “¿Empujar o tirar?” Reflexiones de la Cadena de Suministro. 7 de octubre. http://www.supplychainmusings.com/20...h-or-pull.html.

Simon, Tera. 2016. 5 habilidades valiosas que necesitas para abordar proyectos complejos como un profesional. 5 de diciembre. Accedido 10 2019, septiembre. https://www.teamgantt.com/blog/tackl...mplex-projects.

Snowden, David J., y Mary E. Boone. 2007. “Un Marco de Líder para la Toma de Decisiones”. Harvard Business Review. https://hbr.org/2007/11/a-leaders-fr...ecision-making.

Thomack, David. 2018. “Introducción al Lean y la Entrega de Proyectos”. Videoconferencia para CEE 498: Gestión de la Construcción. Universidad de Wisconsin-Madison, Facultad de Ingeniería, 20 de abril.

Thomsen, Chuck, Joel Darrington, Dennis Dunne y Will Lichtig. n.d. “Gestión de la entrega integrada de proyectos”. LeanConstruction.org. Accedido el 26 de septiembre de 2018. https://www.leanconstruction.org/wp-...Delivery_1.pdf.

Wallace, Bill. 2005. Formar parte de la solución: La Guía de Ingenieros para el Desarrollo Sustentable. Washington, D.C.: Consejo Americano de Empresas de Ingeniería.