1.1: Fundamentos de Gestión de Proyectos- Principios y Prácticas

Nada perdura sino el cambio.
Heráclito, 535 — 475 a.C.

Objetivos

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

• Definir términos relacionados con la gestión de proyectos
• Discutir dos cualidades esenciales de los buenos gerentes de proyecto
• Explicar la diferencia entre orden geométrico y vivo
• Definir “resultado del proyecto”, “éxito del proyecto” y “sostenibilidad” en el contexto del ciclo de vida completo de un proyecto
• Identificar cuatro roles de un gerente de proyecto
• Proporcionar una introducción básica a Lean, incluyendo los seis principios de Lean
• Explicar los fundamentos del desarrollo de software ágil, incluyendo sprints e historias de productos

Las grandes ideas en esta lección

• El pensamiento del orden vivo reconoce que un sistema de cosas está siempre en proceso de rehacerse a sí mismo, y que un sistema siempre está —en algún nivel— en un estado de incertidumbre. En la gestión de proyectos, esto sugiere que los proyectos ocurren en entornos dinámicos, y que los eventos inesperados deben considerarse parte del ciclo de vida del proyecto. Es fundamentalmente adaptativo.
• Los gestores de proyectos idealizan tradicionalmente el orden geométrico más prescriptivo, en el que una etapa conduce necesariamente a la siguiente etapa. Es un componente esencial de la gestión de proyectos, pero cuando se basa exclusivamente en el pensamiento de orden geométrico puede llevar a resultados ineficientes e ineficaces.
• Lean thinking se enfoca en eliminar los desechos. En la gestión de proyectos, Lean thinking proporciona una manera de enfocarse en la definición de valor del cliente, que es la única definición que importa.

1.1 Gestión Técnica de Proyectos en el Mundo Moderno

Para obtener un resumen completo de las últimas estadísticas sobre gestión de proyectos, consulte el informe anual Pulso de la Profesión del Instituto de Gestión de Proyectos. Puedes leer la versión 2018 del reporte aquí: PMI Pulso de la Profesión 2018

Los proyectos son por definición efímeros: van y vienen, dependiendo de las necesidades de una organización, y eventualmente llegan a su fin. De acuerdo con el Cambridge English Dictionary, un proyecto es “una pieza de obra o actividad planificada que se completa a lo largo de un periodo de tiempo y que pretende lograr un objetivo particular” (2018). La naturaleza fugaz de los proyectos significa que las organizaciones con un dominio de gestión de proyectos menos que óptimo a menudo no desarrollan procesos sistemáticos para administrarlos. Una vez que se completa un proyecto, todos siguen adelante, preparándose para el siguiente, con apenas una mirada hacia atrás a lo que funcionó y lo que no funcionó en el antiguo proyecto. En otras palabras, estas organizaciones carecen de un enfoque coherente para la gestión de proyectos — “la aplicación de procesos, métodos, conocimientos, habilidades y experiencia para lograr los objetivos del proyecto” (Association for Project Management n.d.). Esta falta de un enfoque sistemático es especialmente problemática en los campos técnicos, lo que lleva a una tasa extremadamente alta de fallas para proyectos técnicos en muchas industrias.

Una búsqueda rápida en la web sobre la tasa de éxito de proyectos técnicos ofrece algunos datos y cifras reveladoras. Dependiendo del estudio que leas, los proyectos fracasan a tasas entre 20 y 80 por ciento. Y echarle más dinero al problema no ayuda. En efecto, cuanto mayor sea el presupuesto de un proyecto, más probable es que falle (Mieritz 2012). Un estudio encontró que los proyectos de TI con presupuestos superiores a 15 millones de dólares son fiascos de gestión de proyectos: “En promedio, los grandes proyectos de TI ejecutan 45 por ciento sobre el presupuesto y 7 por ciento a lo largo del tiempo” (Bloch, Blumberg y Laartz 2012). El veredicto es aún más aleccionador para los megaproyectos industriales, es decir, para proyectos industriales que cuestan más de mil millones de dólares. Según Edward W. Merrow, “Al sector de producción de petróleo y gas le va peor; 78 por ciento de los megaproyectos en este sector industrial se clasifican como fallas” (2011, 49).

¿Cómo pueden las organizaciones encontrar la salida de este pantano? Al crear una cultura de gestión sistemática y profesional de proyectos que valore las habilidades discutidas a lo largo de este libro. La investigación muestra consistentemente que las organizaciones que implementan técnicas y procesos técnicos de gestión de proyectos obtienen una rica recompensa en éxitos de proyectos. Este libro se enfoca en desarrollar un enfoque de gestión técnica de proyectos que sea flexible, adaptable y abierto a nuevos aprendizajes. Proporciona muchas sugerencias prácticas pero no entra en métodos específicos en detalle. Para obtener orientación sobre las tuercas y tornillos de la gestión de proyectos, consulte Gestión de proyectos: El proceso gerencial, de Erik W. Larson y Clifford Gray.

Este video de 2.5 minutos del Instituto de Gestión de Proyectos describe las ventajas cosechadas por una institución financiera que creó una Oficina de Gestión de Proyectos (PMO) formal para administrar todos sus proyectos de TI:

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

Ganador del Premio PMO del Año 2015 — Navy Federal Credit Union

1.2 Sé un erizo y un zorro

Orden vivo, algo de historia

Aunque Henri Bergson fue el primer pensador en usar el término “orden vivo”, la idea de que la vida es un proceso continuo de cambio impredecible tiene raíces antiguas. Los fragmentos que quedan de la obra del filósofo griego presocrático, Heráclito, aportan profundos conocimientos sobre esta idea. Redujo la naturaleza siempre cambiante del universo a este sencillo dicho: “Ningún hombre pisa nunca el mismo río dos veces”. Según Heráclito, la naturaleza se encuentra en constante estado de cambio. En efecto, el cambio es la única constante en la que un ser humano puede confiar. Los pensadores religiosos han reconocido desde hace tiempo que el cambio en nuestras vidas es inevitable e inevitable. Por ejemplo, la idea de impermanencia es un componente clave del budismo. La Biblia, en Eclesiastés 9:11 señala la inutilidad de luchar contra lo inevitable:

Otra vez vi que bajo el sol la carrera no es al veloz, ni la batalla a los fuertes, ni pan a los sabios, ni riquezas a los inteligentes, ni favor a los que tienen conocimiento, sino que el tiempo y el azar los superan a todos.

A medida que la revolución científica se afianzó en el pensamiento occidental, esta comprensión del orden vivo pasó a la clandestinidad, solo para resurgir en la obra de pensadores y artistas de principios del siglo XX como Bergson, en reacción a la Primera Guerra Mundial y al industrialismo generalizado.

En su libro Mastering the Leadership Role in Project Management: Practices that Deliver Remarkable Results, Alexander Laufer explica dos cualidades esenciales de un director de proyecto, basándose en la metáfora del erizo y del zorro que hizo famosa el filósofo Isaías Berlín:

El zorro es una criatura astuta y creativa, capaz de idear una miríada de estrategias complejas para ataques colados contra el erizo. El erizo es una criatura dolorosamente lenta con una agenda diaria muy sencilla: buscar comida y mantener su hogar. Todos los días el zorro espera al erizo mientras planea atacarlo. Cuando el erizo siente el peligro, reacciona de la misma manera simple, pero poderosa, todos los días: se enrolla en una bolita perfecta con una esfera de púas afiladas apuntando hacia afuera en todas las direcciones. Después el zorro se retira mientras empieza a planear su nueva línea de ataque para el día siguiente. (Laufer 2012, 220)

La ventaja del zorro es que su compleja comprensión del mundo le permite probar muchas posibilidades, adaptando estrategias y tácticas en respuesta a la situación actual. Los erizos tienen una gran estrategia que les permite simplificar toda la experiencia en “un único concepto general que unifica y guía todo lo que hacen”. Como verás en la Lección 2, donde discutimos la estrategia organizacional, el enfoque erizo es preferible a la hora de tomar decisiones a largo plazo sobre el futuro de una organización. Pero cuando se trata de la gestión de proyectos, ambas estrategias son poderosas, y ambas pueden ser efectivas, dependiendo de tu situación. Laufer sostiene que los gerentes exitosos “se comportan tanto como erizos como zorros, aunque colocan al erizo en el asiento del conductor”.

A lo largo de este curso, tomaremos un enfoque similar a un zorro para la gestión técnica de proyectos manteniendo la mente abierta y explorando las muchas líneas de ataque disponibles en un proyecto en particular. Pero también pondremos un énfasis similar a un erizo en algunos principios básicos, en particular los principios básicos de la gestión de proyectos Lean. Al mismo tiempo, todas nuestras discusiones se basarán en la distinción entre los dos enfoques fundamentales de la gestión de proyectos: el enfoque tradicional, o de orden geométrico, y el enfoque de orden vivo más adaptable.

1.3 Dos Tipos de Orden: Vivo y Geométrico

En su libro de 1907 Evolución Creativa, el filósofo francés Henri Bergson investigó la naturaleza de la creatividad humana y su relación con el orden. Según Bergson, por “orden” generalmente nos referimos a una relación mecanicista, predeterminada, lineal entre las cosas. El evento A conduce al Evento B; el Evento B conduce al Evento C; el Evento C conduce al Evento D; y así sucesivamente, sin posibilidad de variación o adaptación. También tendemos a considerar la creatividad como algo que surge solo en un estado de trastorno, es decir, cuando ningún tipo de orden es evidente. El artista librepensante es un estereotipo fundado en esta forma de pensar. Pero Bergson argumentó que el trastorno que asociamos con la creatividad es realmente solo un tipo de orden diferente (222-224).

Nuevamente, recurrimos a Alexander Laufer, quien ha sacado algunas ideas poderosas sobre la gestión de proyectos a partir de la obra de Bergson, que resume de la siguiente manera:

Bergson afirmó que no existe tal cosa como el desorden, sino más bien dos tipos de orden: el orden geométrico y el orden vivo. Mientras que en” orden geométrico” Bergson se relacionó con el concepto tradicional de orden, en” orden vivo” se refirió a fenómenos como la creatividad de un individuo, una obra de arte, o el desorden en mi oficina. (2012, 214)

A lo largo de este libro examinaremos y compararemos el orden geométrico con el orden vivo, con el objetivo de desarrollar un enfoque creativo, realista y funcional para la gestión de proyectos.

Cualidades de Vida y Orden Geométrico

En la gestión de proyectos, el orden geométrico se alinea con el pensamiento gerencial tradicional. Este concepto de orden se asocia con relaciones predecibles entre las etapas de desarrollo, como las relaciones que se muestran en la Figura 1-1, con una etapa que necesariamente conduce a la siguiente.

Figura 1-1: El orden geométrico es predecible, con una etapa que conduce a la siguiente

Los gerentes de proyectos tradicionalmente idealizan una progresión de proyecto tan ordenada. En efecto, es la fuerza impulsora del enfoque orientado a procesos para la gestión de proyectos en la que tienden a enfocarse organizaciones como el Instituto de Gestión de Proyectos. Es un componente esencial de la gestión de proyectos, y los gerentes de proyectos inexpertos deben comenzar por dominar un enfoque geométrico de su trabajo. Sin embargo, cuando se confía exclusivamente en el pensamiento de orden geométrico puede conducir a resultados ineficientes e ineficaces.

Por el contrario, el pensamiento del orden vivo reconoce que un sistema de cosas siempre está en proceso de rehacerse a sí mismo, y que un sistema siempre está —en algún nivel— en un estado de incertidumbre. En la gestión de proyectos, esto sugiere que los proyectos ocurren en entornos dinámicos, y que los eventos inesperados deben considerarse parte del ciclo de vida de un proyecto complejo. Esto es algo que los gerentes de proyectos experimentados aprenden a lo largo del tiempo. Pero incluso los gerentes de proyectos inexpertos pueden tratar de incorporar una comprensión del orden vital en su trabajo.

La Figura 1-2 ilustra las características del orden vivo y geométrico. Ten en cuenta que un proyecto puede tener cualidades de ambos.

Figura 1-2: Características del orden vivo y del orden geométrico

Podría ser llamado a usar métodos de orden geométrico en una situación y métodos de orden vivo en otra. Por ejemplo, preparar un pronóstico del tiempo en un día típico en San Diego, donde el clima varía poco de un día a otro, es una tarea de orden geométrico. Por el contrario, preparar un pronóstico del tiempo para la costa de Florida con un huracán que se espera que golpee la costa cinco días en el futuro es un proyecto de orden vivo. A menudo la etapa de planeación ocurre en orden vivo. Entonces, a medida que comienzas a aprender más sobre el proyecto y qué esperar, la ejecución avanza en orden geométrico. Pero cuando sucede algo inesperado, de repente podrías volver a sumergirte en el orden vivo. Hay que estar preparado para ir y venir entre técnicas geométricas y de orden vivo, adaptándose a la situación según sea necesario.

Los procesos tradicionales de gestión de proyectos se basan en la presunción de que un proyecto puede planificarse hasta el más mínimo detalle, y que una vez completada la fase de planeación, el trabajo del gerente de proyecto es ejecutar el proyecto de acuerdo con ese plan, sin sorpresas. La realidad del mundo moderno es bastante diferente. En su libro de 1991, Managing as a Performing Art: New Ideas for a World of Chaotic Change Permanent, Peter Vaill argumentó que las organizaciones actuales operan en realidad en un estado de “aguas blancas permanentes”. Alexander Laufer describe el argumento de Vaill de la siguiente manera:

Al usar la metáfora de “aguas blancas permanentes”, Vaill llama nuestra atención sobre el hecho de que el entorno externo de los proyectos contemporáneos está lleno de sorpresas, tiende a producir problemas novedosos, es “desordenado” y mal estructurado. (2012, 214)

A lo largo de este libro, nos centraremos en formas de gestionar proyectos técnicos en un mundo permanente de aguas blancas.

Predecir lo impredecible

Orden Geométrico, Algo de Historia

El orden geométrico es producto de la Revolución Científica. A partir de mediados de 1500, los humanos aprovecharon el poder del pensamiento sistemático para lograr grandes saltos hacia adelante en matemáticas, física, biología y muchas otras áreas de estudio. Pensadores de numerosos países contribuyeron a los avances que hicieron posible la ciencia moderna, pero quizás el más importante fue Isaac Newton, quien modeló un universo basado en leyes sistemáticas e inmutables cuyos efectos podrían predecirse con precisión mediante ecuaciones matemáticas.

Los grandes logros humanos de los últimos cinco siglos no podrían haber ocurrido sin este tipo de pensamiento sistemático. La vida moderna tal como la conocemos no existiría sin ella. Sin embargo, como gerentes de proyectos, cuya principal preocupación es planificar proyectos que se llevan a cabo a lo largo del tiempo, necesitamos comprender los límites de nuestra capacidad para predecir el futuro en un mundo en constante cambio.

Cualquier cosa que involucre a seres humanos haciendo cualquier cosa a lo largo de un periodo de tiempo, con recursos limitados, implica cierta cantidad de imprevisibilidad. Esto significa que los proyectos son inevitablemente moldeados por el orden vivo. Podrías pensar que tienes un buen manejo sobre qué esperar de tus compañeros de trabajo y partes interesadas del proyecto a lo largo del transcurso de un proyecto, pero a menudo los rasgos que podrías considerar más predecibles resultan ser completamente poco confiables.

No hace mucho, esta realización sacudió el campo de la economía, que se fundó en el supuesto de que los humanos eran totalmente predecibles en su tendencia a tomar decisiones que potenciaran su bienestar financiero. En su trabajo pionero en el campo de la economía del comportamiento, Richard H. Thaler demostró que la idea supuestamente irrefutable de que las personas actúan racionalmente en su propio interés es discutible en el mejor de los casos, y probablemente falsa (Knee 2015). Y sin embargo, los economistas sistemáticamente se niegan a tomar en cuenta la falta de fiabilidad de su precepto básico. Según Thaler, “Los economistas descuentan cualquier factor que no influya en el pensamiento de una persona racional. Estas cosas son supuestamente irrelevantes. Pero desafortunadamente para la teoría, muchos factores supuestamente irrelevantes sí importan” (2015).

Thaler continúa argumentando que “a menos que seas Spock”, cosas supuestamente irrelevantes, como cómo te sientes al ahorrar para la jubilación, pueden tener efectos mucho más profundos en tu comportamiento económico que el mero interés propio (2015). Los gerentes de proyectos exitosos tienen éxito, en parte, porque nunca ignoran el poder de cosas supuestamente irrelevantes para afectar los resultados del proyecto. Ya que podemos asumir con seguridad que la gran mayoría de tus futuros compañeros de equipo no serán vulcanos, probablemente también deberías asumir que cosas supuestamente irrelevantes terminarán teniendo efectos imprevistos en los proyectos que manejas. Nunca se sabe lo que el orden vivo le lanzará a medida que se desarrolle un proyecto.

Eso no quiere decir que, como gerente de proyecto, puedas prescindir de las expectativas de orden geométrico. Todo lo contrario. Debido a que se trata de un libro sobre gestión técnica de proyectos, nuestro pensamiento necesariamente se ocupará del orden geométrico. Después de todo, los proyectos técnicos involucran productos y servicios técnicos cuyo desempeño se rige por leyes predecibles. La gravedad siempre funciona de la misma manera, por lo que los ingenieros tienen que tomarlo en cuenta. Los procesadores de computadora más recientes solo pueden funcionar tan rápido en el entorno actual, por lo que los desarrolladores de software también tienen que tenerlo en cuenta.

No obstante, hay que protegerse contra la tendencia a pensar que debido a que los productos y servicios técnicos son ellos mismos predecibles, los proyectos requeridos para producirlos serán igualmente predecibles. Ese simplemente no es el caso. Debido a que se trata de un libro sobre gestión, un esfuerzo que involucra a personas realizando tareas a lo largo del tiempo, nuestro pensamiento estará profundamente arraigado en el orden vivo.

1.4 El ciclo de vida y el orden de vida de un proyecto

Cuando abres los ojos a la naturaleza siempre cambiante del orden vivo, puedes comenzar a apreciar el potencial de cambio inherente a lo largo del ciclo de vida de un proyecto. Lo mismo ocurre con el resultado de un proyecto, ya sea un edificio, un nuevo teléfono inteligente o un software para maquinaria agrícola. El producto, o resultado, de un proyecto es creado, mantenido, adaptado, actualizado y demolido/retirado por diversos proyectos durante su vida útil. Cada uno de estos proyectos está sujeto a la incertidumbre del orden vivo, magnificando la dificultad de predecir cómo será el resultado de un proyecto en el futuro, y si efectivamente resultará adecuado para su propósito previsto. Esto, a su vez, complica la fase de planeación de cualquier proyecto, particularmente para cosas que en última instancia se juzgan por la facilidad con la que se puede desmontar y desechar, o reciclar y reutilizar.

Por ejemplo, la Figura 1-3 muestra el ciclo de vida de un edificio. La primera etapa, la etapa de fabricación, es el dominio del director del proyecto que supervisa la construcción del edificio. Una vez que el edificio está completo, el director del proyecto pasa a otro trabajo, pero el edificio, por supuesto, acaba de comenzar su vida funcional. Durante las etapas de operación/uso/cambio, los ocupantes del edificio se benefician o sufren las decisiones del gerente de proyecto a lo largo de la etapa de toma. A continuación viene la etapa de jubilación/reutilización, en la que probablemente el edificio será demolido y se construirá algo más en su lugar. En ese punto, todo el ciclo de vida comienza de nuevo. La facilidad con que se desarrollan estas etapas depende, al menos en parte, de las elecciones que haga el director del proyecto durante la etapa de elaboración. Solo entendiendo estas etapas posteriores se puede entender adecuadamente la verdadera naturaleza de un proyecto y tomar decisiones que aseguren que produzca algo de valor duradero.

Figura 1-3: El producto, o resultado, de un proyecto es creado, mantenido, adaptado, actualizado y demolido/retirado por diversos proyectos durante su vida

En el desarrollo de software, los periodos de tiempo entre etapas son más cortos que en la construcción. Al igual que en la construcción, la etapa de operación es, con mucho, la parte más costoso del proceso del ciclo de vida. Sin embargo, cuando un producto de software continúa utilizándose más allá de su vida operativa diseñada, los costos operativos pueden aumentar a tasas aceleradas. En cualquier industria, pensar en el ciclo de vida del resultado de un proyecto cambia la forma en que piensas sobre las métricas del proyecto. Como se muestra en la Figura 1-4, lo que parece una buena elección desde dentro de los límites limitados de la etapa de elaboración puede parecer una tontería cuando se ve desde la perspectiva más amplia del ciclo de vida completo.

Figura 1-4: Cada etapa del ciclo de vida plantea nuevas preguntas sobre el éxito del proyecto inicial en etapa de elaboración

Resultado del Proyecto y Éxito del Proyecto

En su sentido más estricto, el término resultado del proyecto se refiere a la producción medible de un proyecto en términos de alcance, costo, cronograma, calidad y otros temas como la seguridad. En un sentido más amplio, el término también se refiere al impacto que tiene un proyecto en comparación con sus metas más grandes. En este sentido, tomamos la perspectiva comunitaria, tomando en cuenta, por ejemplo, el potencial de uso múltiple del proyecto y su eventual reurbanización. Por ejemplo, en el sentido más estricto, el resultado deseado del proyecto de una arena deportiva propuesta podría ser una instalación cubierta multiusos construida de acuerdo con el alcance planificado, costo, horario, etc. Sin embargo, en un sentido más amplio, el resultado deseado del proyecto podría ser la remodelación y revitalización del área circundante.

Para una mirada humorística a las muchas formas en que los actores del proyecto pueden definir el éxito del proyecto, consulte “Lo que el cliente quería” — Arek Fressadi

El término éxito del proyecto se refiere al grado en que un proyecto se hace bien, con las partes interesadas que tienen diferentes definiciones de éxito a lo largo del tiempo, dependiendo de sus perspectivas. En otras palabras, la evaluación del éxito de un proyecto es un juicio subjetivo; diferentes grupos de interés tendrán diferentes ideas iniciales sobre el éxito general de un proyecto en función de sus propias expectativas y objetivos. Para complicar las cosas, con el tiempo, es probable que las partes interesadas revisen sus ideas sobre el éxito del proyecto para tener en cuenta nueva información sobre cómo funciona realmente el resultado del proyecto en el mundo real. La definición cambiante del éxito del proyecto es especialmente importante a tener en cuenta a lo largo de proyectos disruptivos como remodelaciones de viviendas y reconstrucciones viales. Por ejemplo, los viajeros pueden tener una opinión extremadamente baja de una construcción de intercambio cuando están sufriendo las frustraciones de los respaldos y desvíos del tráfico. Más tarde, cuando se complete el intercambio y el tráfico fluya más rápido que nunca, es probable que califiquen muy alto el éxito general del proyecto. En el mundo de los productos de consumo, los clientes que buscan un nuevo dispositivo inalámbrico podrían basar su idea del éxito del proyecto en la facilidad de uso y confiabilidad, mientras que la compañía que produce el dispositivo podría calificar el éxito del proyecto en función del número de unidades vendidas. En tanto, la industria en su conjunto solo podría calificar el proyecto como un éxito si establece un nuevo estándar técnico.

Si limitas tu perspectiva a la etapa de creación, es fácil pensar que los términos “resultado del proyecto” y “éxito del proyecto” son sinónimos. Por ejemplo, supongamos que está contratado para construir una casa de eficiencia energética de acuerdo con los estándares de Leadership in Energy & Environmental Design (LEED). Si, al final de la etapa de creación, ves que tu equipo completó la estructura a tiempo y dentro del presupuesto, con todas las características LEED especificadas, entonces probablemente considerarías ese resultado un éxito. Pero a medida que la casa entra en la etapa Operación/Uso/Cambio, la información sobre el uso de energía de la casa podría cambiar tus ideas sobre el éxito o el fracaso del proyecto. Si de hecho las características LEED no funcionan como se esperaba, entonces probablemente calificaría el éxito general del proyecto bastante bajo. Quizás lo más importante es que el dueño de la casa sería poco probable que considerara la casa un éxito. Y dependiendo de las estimaciones de longevidad y los factores externos en constante cambio, la vida útil de la casa también podría ser significativamente diferente a la proyectada originalmente.

En pocas palabras, el éxito del proyecto se define haciendo bien el proyecto y cumpliendo los objetivos definidos. El resultado del proyecto también abarca si usted y su equipo hicieron lo correcto. Es importante considerar tanto en múltiples niveles, para tareas individuales, para el proyecto en general y para el impacto del proyecto a lo largo de su vida útil. En todos los casos, necesitamos pensar ampliamente en los factores que contribuyen al éxito o fracaso de un proyecto. Corremos el riesgo de perder valor duradero si dibujamos una cerca demasiado apretada alrededor de los límites que consideramos al planificar y evaluar el éxito del proyecto.

Sustentabilidad y orden de vida

El gerente de proyecto ideal tiene empatía por las personas que estarán usando y modificando el proyecto terminado en el futuro, incluso con las personas que finalmente lo demolerán o reciclarán. Idealmente, esto significa incorporar materiales que finalmente puedan reciclarse. De hecho, en la Unión Europea, los fabricantes de automóviles están obligados por ley a reducir al 5% los residuos no reciclables generados por un vehículo al final de su vida útil (ELV). Esta forma de pensar requiere una visión más complicada del ciclo de vida de un producto, como se muestra en la Figura 1-5 (Kanari, Pineau y Shallari 2003).

Figura 1-5: El ciclo de vida del producto puede incluir en última instancia el reciclaje de porciones del producto (Fuente: “Reciclaje de vehículos al final de su vida útil en la Unión Europea”, N. Kanari, J.-L. Pineau, y S. Shallari, The Member Journal of the Minerals, Metals & Materials Society www.tms.org/pubs/journals/jom... nari-0308.html. Copyright 2003 por The Minerals, Metals & Materials Society. Usado con permiso.)

Los esfuerzos de sustentabilidad inspirados en el reconocimiento de las realidades del orden vivo están muy avanzados en la industria de la construcción. Como ha argumentado Lance Hosey, arquitecto de Washington, la construcción sustentable significa, entre otras cosas, crear edificios que puedan desmontarse fácilmente, minimizando la disrupción y contaminación inherentes al proceso de demolición (2005). Los desarrolladores de software, también, pueden desarrollar software sustentable, por ejemplo, escribiendo código que se ejecuta incluso en hardware obsoleto, minimizando así la cantidad de equipos informáticos que terminan en los vertederos (Green Wiki 2015).

Además de ser diseñado de manera sostenible, el software también tiene el potencial de promover otros esfuerzos de sustentabilidad, como se discute en el informe Software Acelera el Desarrollo Sustentable, publicado por la organización sin fines de lucro Business for Social Responsibility (2008). David Pagenkopf, director de Desarrollo e Integración de Aplicaciones en UW-Madison, tiene esto que decir sobre sustentabilidad y diseño de software:

El uso de técnicas de virtualización ha eliminado en gran medida el hardware como factor material en el diseño de software. El tema más importante en la sostenibilidad del software es seleccionar los lenguajes de software, las herramientas y la arquitectura de diseño que garanticen que el software se pueda mantener durante tantos años como sea posible. Uno de los mejores ejemplos es escribir software que funciona completamente en un navegador web, que luego puede funcionar en múltiples plataformas. Aún mejor es escribir software usando un diseño receptivo que se ajusta automáticamente al dispositivo final del usuario (por ejemplo, teléfono móvil, tableta o computadora portátil/computadora de escritorio) para presentar la mejor interfaz posible al usuario. (pers. comm., 25 de agosto de 2015)

Los productos de consumo están sujetos a una variedad cada vez mayor de expectativas de sustentabilidad. Como escribió Bryan Burrough en el New York Times, Wal-Mart redujo “el tamaño del empaque en sus líneas de producción, ahorrando a la compañía un estimado de $3.4 mil millones al año... mientras reducía la basura” (Burrough 2011). A lo largo de una década de esfuerzo se han traducido en iniciativas de sustentabilidad que “están teniendo un impacto real hoy en día. La compañía ha utilizado estratégicamente su escala a su favor para promulgar cambios dentro y fuera de la organización” (Atamian 2017).

1.5 Cuatro roles de un gerente de proyecto

Entonces, ¿qué significa todo esto hablar de cambio e imprevisibilidad, prácticamente hablando, para un gerente de proyectos de la vida real? A lo largo de este libro, estaremos investigando formas de acomodar las realidades del orden vivo en las tareas diarias asociadas a la gestión técnica de proyectos. Por ejemplo, en la Lección 6, hablaremos sobre la planificación pull, una forma de planeación adaptativa y recursiva que prioriza la actualización periódica para reflejar las condiciones actuales. Pero por ahora, hablemos de algunos principios generales para una gestión exitosa de proyectos en un mundo de orden vivo.

En un artículo para MIT Sloan Management Review, Alexander Laufer, Edward Hoffman, Jeffrey Russell y Scott Cameron muestran cómo los gerentes de proyectos exitosos combinan métodos de gestión tradicionales con enfoques más nuevos y más flexibles para lograr mejores resultados (2015). Su investigación muestra que los gerentes de proyectos exitosos adoptan estos cuatro roles vitales:

1. Desarrollar la colaboración entre los participantes del proyecto: “La mayoría de los proyectos se caracterizan por una incompatibilidad inherente: las diversas partes del proyecto están vagamente acopladas, mientras que las tareas mismas están estrechamente acopladas. Cuando los eventos inesperados afectan a una tarea, muchas otras tareas interdependientes se ven afectadas rápidamente. Sin embargo, la responsabilidad directa de estas tareas se distribuye entre diversos partidos poco acoplados, quienes no pueden coordinar sus acciones y dar una respuesta oportuna. El éxito del proyecto, por lo tanto, requiere tanto interdependencia como confianza entre las distintas partes” (Laufer et al. 2015, 46).
2. Integre la planificación con el aprendizaje: “Los gerentes de proyectos que enfrentan eventos inesperados emplean un enfoque de 'onda rodante' para la planificación. Al reconocer que los compromisos firmes no se pueden hacer sobre la base de información volátil, desarrollan planes en oleadas a medida que el proyecto se desarrolla y la información se vuelve más confiable. Con sus equipos, desarrollan planes detallados a corto plazo con compromisos firmes a la vez que preparan planes tentativos a largo plazo con menos detalles” (Laufer et al. 2015, 46).
3. Prevenir interrupciones importantes: Los gerentes de proyectos exitosos “nunca dejan de esperar sorpresas, a pesar de que pueden afectar cambios importantes de remediación solo unas pocas veces durante un proyecto. Están constantemente anticipando interrupciones y manteniendo la flexibilidad para responder proactivamente... Cuando el cambio es inevitable, un gerente de proyecto exitoso actúa lo antes posible, ya que es más fácil enfrentar una amenaza antes de que llegue a un estado en toda regla” (Laufer et al. 2015, 47).
4. Mantener el impulso hacia adelante: “Cuando eventos inesperados afectan a una tarea, muchas otras tareas interdependientes también pueden verse rápidamente impactadas. Así, resolver problemas tan pronto como emergen es vital para mantener el progreso laboral” (Laufer et al. 2015, 48).

Adoptar estos cuatro roles te pondrá en el camino hacia la entrega de más valor en tus proyectos, con menos desperdicio, que también es el objetivo tanto de la gestión de proyectos Lean como de la gestión de proyectos ágil.

1.6 Lean: Eliminando los desechos en el orden vital

La administración tradicional de proyectos de orden geométrica suele ser ineficiente, lo que lleva a perder tiempo, dinero, recursos y mano de obra. Por el contrario, Lean es un modelo de negocio y filosofía de gestión de proyectos que ofrece un medio para agilizar proyectos al tiempo que permite la flexibilidad necesaria para hacer frente a eventos inesperados. Basado en ideas y prácticas desarrolladas en Toyota después de la Segunda Guerra Mundial, enfatiza la creación de valor para el cliente al tiempo que elimina los desechos a través del flujo eficiente de trabajo de una fase de un proyecto a otra.

Más que nada, Lean es una forma de pensar. En su libro esencial sobre el tema, James P. Womack y Daniel T. Jones describen el pensamiento Lean de la siguiente manera:

Proporciona una manera de especificar valor, alinear acciones de creación de valor en la mejor secuencia, realizar estas actividades sin interrupción cada vez que alguien las solicite y realizarlas cada vez de manera más efectiva. En resumen, el pensamiento Lean es Lean porque proporciona una manera de hacer más y más con cada vez menos, menos esfuerzo humano, menos equipo, menos tiempo y menos espacio, mientras se acerca cada vez más para brindar a los clientes exactamente lo que quieren. (2003, 15)

Estaremos discutiendo Lean extensamente a lo largo de este libro. Para comenzar aquí, nos centraremos en dos ideas fundamentales de Lean: valor y desperdicio.

Valor

En la conversación ordinaria, “valor” es un término genérico que se refiere al valor general o utilidad de algo. Pero en Lean, el valor solo es significativo “cuando se expresa en términos de un producto específico (un bien o un servicio, y a menudo ambos a la vez) que satisface las necesidades del cliente a un precio específico en un momento específico” (Womack y Jones, 16). En otras palabras, el valor es definido por el cliente, no por el fabricante, el contratista o el proveedor de servicios, y definitivamente no por el ingeniero responsable de diseñar el producto.

Entrega Integrada de Proyectos

Al leer sobre la gestión de proyectos y Lean, es posible que te encuentres con el término entrega integrada de proyectos (IPD). Inspirado en el pensamiento Lean, IPD es un medio para alinear contractualmente a los stakeholders en un proyecto de construcción de una manera que enfatiza la estrecha colaboración, con el objetivo de entregar valor según lo definido por el cliente. Una característica de IPD es un tipo de contrato conocido como acuerdo multipartito, que explica el papel de cada participante en el proyecto.

Se desarrolló una metodología relacionada, entrega integrada de productos, como reacción contra el enfoque silo-ed para el desarrollo de productos, en el que el equipo de diseño diseñó un producto, y luego “lo arrojó sobre la pared” al equipo de fabricación, que tuvo que averiguar cómo construir el producto sin insumos en su diseño. El enfoque más colaborativo del desarrollo integrado de productos mejora el tiempo de comercialización, al tiempo que fomenta la innovación.

Esto suena simple, pero puede ser un concepto difícil de abrazar para los ingenieros, con toda su experiencia técnica. En su libro, Womack y Jones incluyen un capítulo sobre Porsche, que sufrió un colapso de ventas a mediados de la década de 1980 en gran parte porque sus ingenieros de clase mundial se habían cegado a la definición de valor de sus clientes:

Se afirmó que los diseños con más complejidad producidos con maquinaria cada vez más compleja eran justo lo que el cliente quería y justo lo que el proceso de producción necesitaba... A menudo se hizo evidente que las sólidas funciones técnicas y los expertos técnicos altamente capacitados que lideraban las firmas alemanas obtuvieron su sentido del valor, su convicción de que estaban haciendo un trabajo de primer orden, al seguir adelante con refinamientos y complejidades que no interesaban a nadie más que a los expertos ellos mismos... Las dudas sobre los productos propuestos a menudo se contrarrestaban con afirmaciones de que “el cliente lo querrá una vez que lo expliquemos”, mientras que las fallas recientes del producto a menudo se explicaban como instancias en las que “los clientes no eran lo suficientemente sofisticados como para comprender los méritos del producto”. (2003, 17)

Este es solo un ejemplo de los tipos de ideas preconcebidas que pueden distorsionar la comprensión de una empresa del valor que supuestamente está produciendo en beneficio del cliente. Womack y Jones ofrecen estudios de casos en profundidad que detallan las fuerzas que pueden impedir que una empresa entienda lo que realmente quieren sus clientes:

La definición de valor está sesgada en todas partes por el poder de organizaciones preexistentes, tecnologías y activos no depreciados, junto con el pensamiento obsoleto sobre las economías de escala. Los gerentes de todo el mundo suelen decir: “Este producto es lo que sabemos producir usando activos que ya compramos, así que si los clientes no responden ajustaremos el precio o agregaremos campanas y silbatos”. Lo que deberían estar haciendo en cambio es fundamentalmente repensar el valor desde la perspectiva del cliente. (2003, 17-18)

Para dar el salto al pensamiento Lean, es necesario comprender completamente la naturaleza del valor, por lo que volveremos a esta idea a lo largo de este libro. También hay que entender su contrario: el desperdicio. Todo el objetivo de Lean es maximizar el valor y eliminar el desperdicio.

Residuos

Según el Lean Lexicon, el desperdicio ^[1] es “Cualquier actividad que consuma recursos pero no cree valor para el cliente” (Lean Enterprise Institute 2014). Identificar residuos puede ser tan difícil para los nuevos pensadores Lean como identificar el valor.

Taiichi Ohno, el ejecutivo de Toyota que fue pionero en el enfoque en el desperdicio y el valor que ahora llamamos Lean, identificó siete formas de desechos. Se pueden encontrar innumerables explicaciones de los siete desechos en libros y artículos. Lo siguiente está adaptado de “7 Residuos” - Herramientas de Fabricación Lean :

• Transporte: Mover personas, maquinaria o materiales más lejos de lo que realmente es necesario. Una gran cantidad de desechos de transporte son necesarios por diseños de fábrica deficientes, tamaños de lote grandes y ubicaciones de almacenamiento distantes, solo por nombrar algunas causas.
• Inventario: acumulación de existencias debido, por ejemplo, a una mala planificación o al tiempo requerido para cambiar la maquinaria de un proceso a otro.
• Movimiento: Cualquier movimiento de humanos o equipo que no incremente el valor de un producto o servicio. Los ejemplos incluyen doblar y llegar necesarios por una estación de trabajo mal diseñada, o por áreas de almacenamiento mal organizadas.
• Esperando: Humanos o máquinas de pie inactivos. Puede ser causado por largos cambios, procesos mal coordinados, o la necesidad de reelaborar piezas defectuosas, entre otras cosas.
• Sobreproducción: Creando más de lo que se puede usar o vender en un tiempo razonable. Esto se considera la peor forma de desperdicio, porque “oscurece todos los demás problemas dentro de sus procesos” (Lean Manufacturing Tools n.d.). Más adelante en este libro, hablaremos sobre cómo evitar esta forma de desperdicio a través de técnicas Lean como la planificación pull.
• Sobreprocesamiento: Hacer más de lo útil o necesario desde el punto de vista del cliente. La sobreingeniería en Porsche, descrita por Womack y Jones, es un claro ejemplo de sobreprocesamiento. Un ejemplo más mundano podría ser un restaurante que usa queso importado caro en las pizzas, cuando los clientes preferirían la mozzarella nacional.
• Defectos: Tiempo y esfuerzo necesarios para corregir piezas defectuosas o servicios mal prestados. Esto es lo que piensa la mayoría de la gente cuando se le pide que identifique los desechos. Pero puede ser difícil medir con precisión los costos asociados con los defectos, que pueden incluir “costos asociados con la resolución de problemas, materiales, reelaboración, reprogramación de materiales, configuraciones, transporte, papeleo, mayores tiempos de entrega, fallas en la entrega y clientes potencialmente perdidos” (Lean Manufacturing Tools).

Otra forma de pensar sobre los residuos es enfocarse en la facilidad con la que se pueden eliminar. Cuando se mira de esa manera, se divide en dos tipos:

• Residuos tipo uno: Crea “ningún valor pero es inevitable con las tecnologías actuales y los activos de producción” (Lean Enterprise Institute 2014). Este tipo de residuos es necesario pero podría ser eliminado en el futuro. Un ejemplo de desechos de tipo uno podrían ser las inspecciones de rutina necesarias para garantizar que una parte en particular cumpla con las normas de seguridad gubernamentales. Si bien es necesario, tales inspecciones en realidad no proporcionan valor desde el punto de vista del cliente, y posiblemente podrían eliminarse si la pieza en sí fue eliminada del dispositivo, o si fue rediseñada.
• Tipo dos residuos: No crea valor y se puede eliminar inmediatamente. Por ejemplo, el tiempo y esfuerzo requeridos para transportar un horno microondas recién hecho a la máquina de envasado es un desperdicio que podría eliminarse moviendo la máquina de envasado.

Este blog proporciona algunos ejemplos de la vida real de las siete formas de desechos en una variedad de industrias: “Ejemplos reales de los 7 desechos de Lean” — KainExus

En la gestión de proyectos, un ejemplo de residuo tipo uno podría ser una auditoría necesaria para medir el desempeño del trabajo contratado o un producto prometido frente a un conjunto de requisitos acordados. Desde la perspectiva del cliente, dicha auditoría no agrega ningún valor, pero es necesario para asegurar la finalización exitosa del proyecto. Un residuo tipo dos que a menudo se ve en la gestión de proyectos son las constantes solicitudes de actualizaciones de estado. Los nuevos gerentes de proyectos que aún no han construido confianza con su equipo a veces sucumben a esta forma de desechos mientras intentan microgestionar todas las tareas. Las actualizaciones programadas regularmente y las expectativas de escalada para desafíos inesperados ayudan a eliminar este tipo de desechos dos en la gestión de proyectos.

Seis principios Lean

Los seis principios en el corazón del pensamiento Lean son: especificar el valor, identificar el flujo de valores, fluir, tirar, perfección y respeto por las personas. Aprenderás más sobre estas ideas, y cómo se relacionan con la gestión técnica de proyectos, a lo largo de este libro. Te los explicaremos brevemente aquí, para darte una base para trabajar. La mayoría de los ejemplos de esta lección se extraen de la manufactura, donde Lean comenzó. Pero tenga en cuenta que el pensamiento Lean ha sido ampliamente adoptado en industrias tan diversas como la construcción y la atención médica.

1. 1. Identificar valor: Como se explicó anteriormente, el valor solo puede ser definido por el cliente. Como gerente de proyectos, tienes que empezar por aprender cuál es esa definición, idealmente hablando directamente con el cliente. No obstante, puede encontrar que los clientes “solo saben pedir alguna variante de lo que ya están obteniendo” (Womack y Jones 2003, 31). Esto significa que identificar el valor a menudo implica hacer preguntas de sondeo diseñadas para obtener una definición de valor de clientes que quizás no hayan tenido la oportunidad de pensarlo por sí mismos. A menudo, las mejores preguntas para empezar son: ¿Qué problema quieres resolver? ¿Qué aspecto tiene el éxito?
   2. Mapear el flujo de valor: El flujo de valor es “todas las acciones, tanto creadoras de valor como no creadoras de valor, necesarias para llevar un producto desde el concepto” hasta la entrega (Lean Enterprise Institute 2014). En cualquier industria, la gran mayoría de las actividades en el flujo de valor no crean valor y, por lo tanto, son residuos. Las empresas que intentan analizar el flujo de valor de un producto en particular suelen tener que mirar mucho más allá de sus propias premisas, teniendo en cuenta todo lo que implica llevar un producto al mercado. Por ejemplo, la corriente de valor para un nuevo tipo de pan podría comenzar con el agua subterránea utilizada para regar granjas de trigo en Nebraska. Al observar las corrientes de valor desde una perspectiva de gestión de proyectos, el objetivo es comprender todos los aspectos del proyecto, incluyendo la iniciación, la planificación, la ejecución, el monitoreo y el control y la liquidación.

      Lote y cola: Lo opuesto al flujo

      Supongamos que configura un sistema de lotes y colas para hornear, glasear, decorar y boxear cien pasteles de cumpleaños en una panadería. A medida que horneas los pasteles, necesitas idear una buena solución de almacenamiento, para que se mantengan frescos hasta que estés listo para congelarlos. Después de que todos los pasteles estén helados y te muevas al escalón de decoración, es posible que encuentres que las decoraciones no se pegan al glaseado. Si acabaras de hornear, esmerilado y decorado un pastel, habrías descubierto y resuelto este problema antes de que se convirtiera en un defecto que afectaba a todos los pasteles. Pero como ya has horneado y esmerilado todos los pasteles, ahora estás en la posición de tener que comprar nuevas decoraciones que se pegarán al glaseado ya en el pastel. Un problema similar podría surgir con las cajas. Podrías tener cien pasteles esmerilados y decorados, listos para ser encajonados, y luego descubrir que no caben en las cajas que pediste. En tanto, los pasteles se están volviendo rancios, y pronto podrían volverse incomercializables.

   3. Flujo continuo: Según Womack y Jones, la mayoría de la gente tiende a pensar que la forma más eficiente de completar cualquier proyecto de varios pasos es dividirlo en lotes, realizando el primer paso en todos los materiales disponibles y dejando los resultados a un lado hasta que todos los materiales hayan sido procesados. Después de que se haya completado todo el lote, luego pasa al siguiente paso, procesando todo el lote, y así sucesivamente, a través de todos los pasos. Este enfoque, conocido como batch y cola, puede ser útil en muchas situaciones, pero a menudo es tremendamente ineficiente y puede conducir a defectos que no se detectan hasta muchos pasos en el proceso (Womack y Jones 2003, 22). Para evitar los problemas asociados con la producción por lotes y colas, Lean enfatiza el flujo continuo de un paso a otro, con lotes pequeños que pueden ser procesados inmediatamente por los trabajadores en el siguiente paso. El verdadero flujo continuo, que reduce drásticamente el tiempo de producción, solo es posible después de haber eliminado el desperdicio de pasos sin creación de valor, y luego reorganizado los pasos restantes para que se desplieguen uno tras otro. No es un objetivo realista en todas las industrias, pero a menudo se pueden lograr algunos beneficios del flujo moviendo maquinaria y reubicando personal. En la gestión de proyectos, el flujo puede convertirse en un problema durante la programación. Por ejemplo, un equipo de proyecto podría cometer el error de trabajar en un horario innecesariamente detallado con bloques de tiempo demasiado discretos, planificando tareas para un proyecto de varios años en horas. Entonces, después de perder todo este tiempo en un horario poco realista, el equipo podría no revisar y actualizar el progreso real a medida que avanza el proyecto. Esta falta de flujo puede presentar riesgos reales para el éxito general del proyecto. Por el contrario, los gerentes de proyectos de pensamiento Lean entienden que un horario es un documento vivo y que, a lo largo de un proyecto, necesitarán abordar los cambios en el orden vital (tanto positivos como negativos), permitiendo un verdadero flujo a lo largo de la vida del proyecto.
   4. Pull: Para entender el significado de pull, primero hay que entender el significado de empujar. Los sistemas de producción tradicionales se consideran sistemas push, con trabajos dictados por programas de producción que a veces están vinculados a pronósticos precisos de la demanda de los clientes, pero a menudo no lo son. Un sistema de empuje fácilmente resulta en el desperdicio de la sobreproducción. Mark Graban ofrece algunos ejemplos:
      • Un restaurante de comida rápida haciendo comida y almacenándola bajo lámparas de calor (parte de ella se tira).
      • Un fabricante de automóviles que construye un exceso de autos o camiones y obliga a los concesionarios a llevarlos.
      • La Casa de la Moneda de Estados Unidos produce monedas en dólares que superan con creces la demanda
      • Fabricantes de computadoras que construyen productos y los envían a minoristas para sentarse en las repisas. (2014)

      Por el contrario, un sistema de extracción construye productos y utiliza materiales basados en la demanda real de los clientes, la forma en que una tienda de sándwiches podría hacer su sándwich de pavo y guacamole favorito después de pedirlo. En realidad, la mayoría de los sistemas utilizan una combinación de producción de tracción y empuje. Por ejemplo, maquillar tu sándwich en el acto es una actividad de pull, pero la tienda probablemente habría practicado la producción push ordenando previamente pavo y guacamole de acuerdo con pronósticos de demanda de los clientes.

      Estos ejemplos simplifican enormemente el concepto Lean de pull. En la práctica, especialmente en fábricas gigantes o en sitios de construcción, es mucho más complejo. Pero el principio básico de reducción de residuos es siempre el mismo: “nadie upstream debería producir un bien o servicio hasta que el cliente downstream lo solicite” (Womack y Jones 2003, 67).

      Esta excelente entrada de blog utiliza un ejemplo de un puesto de concesión para ilustrar la forma en que un sistema de extracción evita los desechos de inventario y sobreproducción al mantener a mano solo pequeñas cantidades de materiales, reemplazando los artículos tal como se usan:
      Lean Blitz Consulting — “Toyota Way Principle #3: “Pull” Sistemas”

      Traducir el concepto de pull a la gestión de proyectos puede ser difícil pero arroja resultados poderosos. El equipo comienza con el punto final, el objetivo final del proyecto, y lleva las actividades hacia adelante, describiendo lo que se debe hacer en cada paso del camino. Esto difiere mucho de la gestión de proyectos estándar, que comienza desde el principio, construyendo un cronograma que asume que las tareas anteriores están completamente terminadas antes de que el equipo comience en las siguientes tareas. Por el contrario, en un horario Lean, se superponen más tareas. En una presentación sobre la planificación de proyectos para el diseño de una línea de transmisión, Kristine Engel explica que, en un cronograma de extracción, “las 'tareas posteriores' pueden comenzar antes de que terminen las tareas 'anteriores'”, y que algunas “tareas de refinamiento del diseño pueden superponerse con el proceso de licitación laboral o incluso con la construcción, lo que refleja la realidad de proyectos de utilidad.” A pesar de esta fluidez, el equipo es capaz de rastrear el progreso comparando las horas facturadas con el presupuesto. Todo el sistema se basa en la “comunicación regular con el cliente para revisar los objetivos a corto plazo en relación con el cronograma completo del proyecto” (Engel 2017).

   5. Perfección: Los profesionales experimentados de Lean testifican que, a medida que mejora en la identificación de la definición de valor del cliente, se vuelve más preciso al identificar cada paso en el flujo de valor. Como resultado, se reduce el desperdicio de actividad sin valor agregado, mejorando así el flujo. A medida que adquieras experiencia, empezarás a ver oportunidades de mejoras Lean en todas partes. Es como levantar pesas: cuanto más levantas, más podrás levantar. Cuantos más residuos elimines, más residuos podrás eliminar. Según Jones y Womack, esto sucede porque
      

      los cuatro principios iniciales interactúan entre sí en un círculo virtuoso. Obtener valor para fluir más rápido siempre expone muda oculta [residuos] en el flujo de valor. Y cuanto más se tira, más se revelan los impedimentos para fluir para que puedan ser removidos. Los equipos de productos dedicados en diálogo directo con los clientes siempre encuentran formas de especificar el valor con mayor precisión y, a menudo, también aprenden formas de mejorar el flujo y la extracción. (2003, 25)

   6. Respeto a las personas: Por encima de todo, Lean requiere una comunicación constante entre todas las partes interesadas. Implementar los primeros cinco principios de Lean solo es posible cuando todos los miembros del equipo se respetan y escuchan entre sí, comparten ideas, aceptan sugerencias y colaboran para resolver problemas y eliminar el desperdicio. El respeto por las personas no se trata de ser amable, se trata de comprender que no puedes resolver los problemas por tu cuenta, y que en cambio necesitas involucrarte sincera y honestamente con tus compañeros de trabajo. A veces eso significa desafiarlos y ofrecerles críticas. Siempre significa estar dispuesto a admitir cuando te equivocas.

Empuje y tire

Este video de dos minutos explica la diferencia entre la producción push y pull:

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

1.7 Ágil: Retroalimentación rápida en orden de vida

Lean se desarrolló originalmente en el mundo de la manufactura pero ha sido adoptado en muchas industrias. En el mundo del desarrollo de software, una metodología relacionada, Ágil, es cada vez más popular. Es esencialmente una versión de TI de Lean. Aunque Agile tenía sus raíces en el desarrollo de software, las empresas también han expandido su uso a una variedad de tipos de proyectos, incluyendo desarrollo de productos, proyectos de capital y proyectos de servicios.

Los muchos sabores de Agile incluyen:

1. 1. • Agile Scrum: Diseñado para completar proyectos complejos, como se describe en ScrumGuides, Scrum es la forma más utilizada de Agile. Cuando la gente habla de Agile, suelen estar hablando de Scrum.
      • Programación Extrema: Destaca ciclos de desarrollo cortos con lanzamientos frecuentes de software para evaluación, después de lo cual comienza un nuevo ciclo de desarrollo. Puedes leer más sobre programación extrema en “Programación extrema: una introducción suave”
      • Desarrollo rápido de productos: enfatiza “actividades simultáneas y coordinadas por equipos multifuncionales, esforzándose por transiciones suaves entre fases para el tiempo de comercialización más rápido” (ORC International: Expert Advisory Services). Puede leer más sobre Desarrollo rápido de productos en esta “Introducción al desarrollo rápido de productos”.

Otra Forma de Ágil

Los hackatones, otro tipo de experiencia Ágil, son eventos de varios días en los que los desarrolladores de software trabajan en una solución a un problema específico con el objetivo de generar una serie de ideas y/o prototipos innovadores. Los hackatones son similares a los sprints ágiles, pero normalmente implican una colaboración más intensiva, con participantes reunidos en un solo lugar y dividiéndose en equipos. Originados como una forma para que cualquiera se involucre en la creación de software de código abierto, los hackatones ahora son comunes en los campus universitarios y en el mundo corporativo. Para obtener información sobre los próximos hackatones, consulte este sitio dedicado al tema: HackerEarth.

Todas las formas de Agile enfatizan un enfoque iterativo para el desarrollo de productos, con las especificaciones del proyecto evolucionando junto con la noción del cliente de los requisitos de software. Un proyecto comienza con una conversación entre el desarrollador y el propietario del producto sobre lo que el cliente quiere que haga el software. En la terminología Scrum, el cliente es el propietario del producto, y las características que el propietario del producto quiere en el software se conocen como historias de productos.

Con una descripción de las historias de productos en la mano, el desarrollador de Agile se pone a trabajar, creando piezas de software que abordan historias de productos individuales. Después de un ciclo de desarrollo de una a dos semanas (conocido en Scrum como sprint) la desarrolladora entrega el nuevo software al propietario del producto para que pueda probarlo y hacer sugerencias de mejora. El desarrollador inicia entonces otro sprint, incorporando esas sugerencias en una nueva iteración. Después de cada sprint, el propietario del producto tiene la oportunidad de redirigir al equipo a nuevas historias de productos, o de revisar la comprensión del equipo de las historias de productos existentes. A través de estas interacciones repetidas, que proporcionan retroalimentación rápida y enfocada, el desarrollador y el propietario del producto se concentran en una aplicación de software que hace lo que el propietario del producto necesita que haga. Si el tiempo y el dinero son escasos, como suelen ser, el propietario del producto tiene oportunidades regulares de tomar decisiones sobre qué historias de productos son las más importantes y cuáles se pueden prescindir de si es necesario.

El desarrollo ágil es esencialmente un proceso de aprendizaje a través del cual el desarrollador y el propietario del producto crean una comprensión compartida de cuántas características pueden crear, dado el tiempo y el dinero asignados. Es en gran medida un enfoque de orden vivo para la gestión de proyectos, en el sentido de que las primeras etapas implican cierta ambigüedad y muchas incógnitas. Según Robert Merrill, analista de negocios sénior de la Universidad de Wisconsin-Madison, y coach de Agile, “Agile es una forma de administrar proyectos ante la imprevisibilidad y las limitaciones, a menudo muy rígidas limitaciones de tiempo y presupuesto. La retroalimentación rápida permite al equipo crear el mejor software posible dentro de las limitaciones dadas” (2017).

Al igual que Lean, Ágil será un tema recurrente a lo largo de este libro. Para comenzar a aprender sobre Agile por su cuenta, consulte lo siguiente:

1. 1. • En 2001 un grupo de desarrolladores de software publicó el Manifiesto Ágil en el que esbozaron los 12 principios del desarrollo de software Ágil. Puedes leer todo el manifiesto aquí: “Principios detrás del Manifiesto Ágil”.
      • A Gentle Introduction to Agile, una entrada de blog de Eric Bruno
      • “¿Qué es el Desarrollo Ágil? ” un video de 4,5 minutos.
      • “Agile Product Ownership in a Nutshell”, un video de 15:51 minutos sobre desarrollo de software.

Agile: un nuevo tipo de ingeniería

En su fascinante conferencia “Real Software Engineering”, Glenn Vanderburg presenta la historia de la ingeniería de software (2011). Explica cómo los primeros desarrolladores de software tendían a pensar en la ingeniería de software en términos que les resultaban familiares a partir de la ingeniería estructural, porque eso es lo que pensaban que significaba el término ingeniería. Vanderburg aboga por una nueva y simple definición de ingeniería: lo que sea que funcione.

La historia nos dice que lo que solía llamarse ingeniería de software en realidad tenía poco que ver con la ingeniería, porque los llamados “proyectos de ingeniería de software” estaban plagados de desechos, reelaboración y fallas. En otras palabras, no funcionó. Según Vanderburg, Ágil es la única forma real de ingeniería de software. Es fundamentalmente diferente de la ingeniería estructural, en parte porque permite realizar pruebas instantáneas y esencialmente libres, algo que es imposible al construir planos o puentes. Además, mientras que otros tipos de ingeniería generalmente implican modelar algo durante un largo período de semanas o meses, y luego obtener comentarios, también durante semanas o meses, los desarrolladores de Agile reciben retroalimentación en diferentes escalas de tiempo. Para bloques de código individuales, pueden obtener comentarios importantes en minutos u horas simplemente compartiéndolos con otro desarrollador o con el cliente. Para partes más grandes del proyecto, como las pruebas de aceptación o el lanzamiento de nuevas funciones, obtener comentarios es más costoso y se lleva a cabo durante semanas o meses.

La razón principal por la que la retroalimentación y las pruebas en Agile difieren tanto de otros tipos de ingeniería es que el código fuente es en sí mismo el modelo. Al escribir código, los desarrolladores de Agile crean tanto el modelo comprobable como el producto final al mismo tiempo. En palabras de Vanderburg: “Los procesos ágiles son motores de retroalimentación económicos y ajustados a los costos”.

~Consejos prácticos

1. 1. • Esté preparado para utilizar técnicas geométricas y de orden vivo: Los proyectos a menudo se conciben y planifican en orden geométrico, con la suposición ingenua de eventos que se desarrollan de manera predecible. Entonces la realidad golpea, y se ejecutan en medio de las incertidumbres del orden vivo. Sin embargo, eventualmente, a medida que se desarrollan los proyectos, y empiezas a aprender qué esperar, pueden volverse más geométricos. Esté preparado para ir y venir entre técnicas geométricas y de orden vivo, adaptándose a la situación según sea necesario.
      • Cuando trabaje en orden geométrico, concéntrese en lo siguiente:
        • Definir el éxito del proyecto.
        • Establecer un cronograma del proyecto.
        • Asegurar que el proyecto entregue los resultados especificados.
        • Constantemente revisa tu progreso con el cronograma del proyecto.
        • Revisar regularmente los costos con el presupuesto del proyecto.
        • Haga una pausa periódica para asegurarse de que el proyecto realmente se esté desarrollando en orden geométrico y no haya cambiado al orden vivo.
      • Al trabajar en orden de vida, siga las buenas prácticas geométricas cuando sea apropiado, pero también concéntrese en lo siguiente:
        • Garantizar que todas las partes interesadas comprendan el valor compartido del proyecto y se comprometan a lograrlo.
        • Incorpore todas las formas útiles de comunicación para asegurarse de que las partes interesadas del proyecto comprendan lo que sucede en cada etapa del proyecto.
        • Enfócate en actividades que generen valor y eliminen las actividades derrochadoras.
        • Esté preparado para responder a eventos cambiantes, manteniéndose ágil y adaptable.
      • Tómese el tiempo para identificar el contexto único y cambiante de un proyecto: el contexto de un proyecto, el entorno cotidiano y el fondo organizacional más amplio en el que se desarrolla un proyecto, rara vez es el mismo de un proyecto a otro y puede cambiar a lo largo del transcurso del proyecto. Al identificar el contexto único de cada proyecto, y las muchas formas en que podría cambiar, reducirá sus posibilidades de hacer suposiciones que podrían resultar equivocadas.

~Resumen

1. 1. • Los proyectos se desarrollan en contextos únicos y cambiantes que requieren un enfoque flexible y adaptable.
      • Las organizaciones suelen concebir proyectos en la impredecible agitación del orden vivo y luego intentan ejecutarlos en el orden geométrico más sistemático, planificando cada paso hasta el último detalle. Los gerentes de proyectos exitosos nunca pierden de vista el impredecible y permanente mundo de aguas bravas en el que realmente se desarrollan los proyectos.
      • Entender que el ciclo de vida de un proyecto implica algo más que la etapa de elaboración ampliará su comprensión del “éxito del proyecto”.
      • La gestión de proyectos Lean se enfoca en maximizar el valor y eliminar los desechos.
      • Las estrategias ágiles de gestión de proyectos fomentan la flexibilidad requerida en el orden de vida.

~Glosario

1. 1. • Ágil: una metodología de gestión de proyectos que enfatiza un enfoque iterativo para el desarrollo de productos, con las especificaciones del proyecto evolucionando junto con la noción del cliente de los requisitos de software. Hay muchos sabores de Agile, pero el más utilizado es Scrum.
      • economía del comportamiento —Según Oxforddictionaries.com, “un método de análisis económico que aplica percepciones psicológicas al comportamiento humano para explicar la toma de decisiones económicas”.
      • orden geométrico —Un tipo de orden identificado por el filósofo francés Henri Bergson que se caracteriza por el desarrollo lineal, causa y efecto claros y eventos predecibles.
      • entrega integrada de proyectos (IPD): un medio de alinear contractualmente a los actores involucrados en un proyecto de construcción de manera que enfatice la estrecha colaboración, con el objetivo de entregar valor según lo definido por el cliente. IPD se inspira en Lean y se basa en un tipo de contrato conocido como acuerdo multipartito, que explica el papel de cada participante en el proyecto.
      • Lean —Un modelo de negocio y filosofía de gestión de proyectos que ofrece un medio para agilizar proyectos al tiempo que permite la flexibilidad necesaria para hacer frente a eventos inesperados. Destaca la eliminación de residuos a través del flujo eficiente de trabajo de una fase de un proyecto a otra.
      • orden vivo —Un tipo de orden identificado por el filósofo francés Henri Bergson que se caracteriza por cambios rápidos y eventos impredecibles.
      • proyecto — Una “pieza de obra planificada o actividad que se completa a lo largo de un período de tiempo y destinada a lograr un objetivo particular” (Cambridge English Dictionary 2018).
      • resultado del proyecto —En su sentido más estricto, el resultado medible de un proyecto, ya sea un edificio, una aplicación de software o una parte de un avión de combate. En un sentido más amplio, el impacto que tiene un proyecto en comparación con sus metas más grandes.
      • éxito del proyecto —El grado en que un proyecto se hace bien. La evaluación del éxito del proyecto por parte de las partes interesadas es un juicio subjetivo, que varía según su perspectiva, y normalmente cambia con el tiempo.
      • gestión de proyectos —La “aplicación de procesos, métodos, conocimientos, habilidades y experiencia para lograr los objetivos del proyecto” (Asociación para la Gestión de Proyectos 2018).
      • valor —En la conversación ordinaria, un término genérico que se refiere al valor general o utilidad de algo. Pero en Lean, el valor solo es significativo “cuando se expresa en términos de un producto específico (un bien o un servicio, y a menudo ambos a la vez) que satisface las necesidades del cliente a un precio específico en un momento específico” (Womack y Jones 2003, 16). En otras palabras, el valor es definido por el cliente.

~Recursos adicionales

1. 1. • La Guía de Habilitadores Lean para la Gestión de Programas de Ingeniería, publicada por la Comunidad de Práctica Conjunta MIT PMI INCOSE sobre Lean en la Gestión de Programas (2012).
      • La gestión como arte escénico: nuevas ideas para un mundo de cambio caótico, de Peter B. Vaill (1989). En este libro Vaill introduce el término “aguas bravas permanentes”.
      • Las memorias de Richard Thaler sobre su vida y obra en el campo de la economía del comportamiento: El mal comportamiento: La creación de la economía conductual (2015).
      • La clásica introducción a Lean: The Toyota Way: 14 principios de gestión del fabricante más grande del mundo, de Jeffrey Liker (2004).

~Referencias

Asociación para la Gestión de Proyectos. n.d. “¿Qué es la gestión de proyectos?” apm.org. Accedido el 15 de junio de 2018. https://www.apm.org.uk/resources/wha...ct-management/.

Atamian, Luna. 2017. “¿Por qué Walmart es líder en sustentabilidad?” Huffington Post, 14 de diciembre. https://www.huffingtonpost.com/entry...b00caf3d59eae8.

Bergson, Henri. 1911. “Evolución Creativa”. Proyecto Gutenberg. Accedido el 15 de junio de 2018. http://www.gutenberg.org/files/26163... -h/26163-h.htm.

Bloch, Michael, Sven Blumberg, y Jürgen Laartz. 2012. “Entregando Proyectos de TI a Gran Escala a Tiempo, Presupuesto y Valor”. McKinsey&Empresa. Octubre. Consultado el 4 de agosto de 2016. http://www.mckinsey.com/business-fun...t-and-on-value.

Burrough, Bryan. 2011. “Detrás de la ecologización de Wal-Mart”. New York Times, 14 de mayo. http://www.nytimes.com/2011/05/15/bu...helf.html? _r=0.

Negocios para la Responsabilidad Social. 2008. “El Software Acelera el Desarrollo Sustentable”. bsr.org. http://www.bsr.org/reports/BSR_Softw...evelopment.pdf.

Diccionario Cambridge English. 2018. “proyecto”. Diccionario Cambridge. Accedido 12 de mayo de 2018. https://dictionary.cambridge.org/us/...nglish/project.

Engel, Kristine. 2017. “Planeación de Proyectos para Diseño de Línea de Transmisión”. Presentación en PowerPoint para clase de Gestión Técnica de Proyectos, Universidad de Wisconsin-Madison, 12 de octubre.

Graban, Marcos. 2014. “#Lean: Aclarar Push, Pull y Flow en un Hospital; el Paciente “Tira”.” Blog Lean de Mark Graban. 24 de febrero. https://www.leanblog.org/2014/02/flo...in-a-hospital/.

Wiki Verde. 2015. “Desarrollo de Código Sustentable”. Wiki Verde. 9 de junio. http://green.wikia.com/wiki/Sustaina...de_development.

Hosey, Lance. 2005. “Maneras más constructivas de construir una ciudad”. The Washington Post, 9 de enero. www.washingtonpost.com/wp-dyn... -2005Jan7.html.

Kanari, N., J.L. Pineau, y S. Shallari. 2003. “El reciclaje de vehículos al final de su vida útil en la Unión Europea”. Revista de la Sociedad de Minerales, Metales y Materiales, agosto. Consultado junio 9, 2015. www.tms.org/pubs/journals/jom... nari-0308.html.

Rodilla, Jonathan A. 2015. “En 'portarse mal', un profesor de economía no tiene miedo de atacar a los suyos”. New York Times, 5 de mayo. http://www.nytimes.com/2015/05/06/bu...aler.html? _r=1.

Larson, Erik W., y Clifford F. Gray. 2011. Gestión de Proyectos: El Proceso Directivo, Sexta Edición. Nueva York: McGraw-Hill Education.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, Edward J. Hoffman, Jeffrey S. Russell, y Scott W. Cameron. 2015. “Lo que hacen los gerentes de proyectos exitosos”. MIT Sloan Management Review, Primavera: 43-51. http://sloanreview.mit.edu/article/w...t-managers-do/.

Lean Enterprise Institute. 2014. Lean Lexicon, Quinta Edición. Editado por Chet Marchwinski. Cambridge, MA: Lean Enterprise Institute.

Lean Manufacturing Tools. n.d. “Residuos de Defectos; causas, síntomas, ejemplos y soluciones”. Herramientas Lean Manufacturing. Accedido el 11 de noviembre de 2017. http://leanmanufacturingtools.org/12...and-solutions/.

—. n.d. “Residuos de la sobreproducción; causas, síntomas, ejemplos y soluciones”. Herramientas Lean Manufacturing. Accedido el 11 de noviembre de 2017. http://leanmanufacturingtools.org/11...and-solutions/.

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

Merrow, Edward W. 2011. Megaproyectos Industriales: Conceptos, Estrategias y Prácticas para el Éxito. Hoboken, Nueva Jersey: John Wiley & Sons, Inc.

Mieritz, Lars. 2012. “Encuesta de Gartner muestra por qué fallan los proyectos”. Así es como se ve bien. 10 de junio. https://thisiswhatgoodlookslike.com/...projects-fail/.

ORC International: Expert Advisory Services. n.d. Rapid Product Development Experts. Consultado el 9 de septiembre de 2016. http://www.orcexperts.com/experts.as...ct+development.

Pagenkopf, David. 2018. “Correo electrónico sobre sustentabilidad y diseño de software”.

Thaler, Richard H. 2015. “A menos que seas Spock, las cosas irrelevantes importan en el comportamiento económico”. New York Times, 8 de mayo. http://www.nytimes.com/2015/05/10/up...abt=0002&abg=0.

Vanderburg, Glenn. 2011. “Lone Star Ruby Conference 2010 Real Software Engineering por Glenn Vanderburg.” Publicado el 24 de octubre de 2011. Video de YouTube, 51:56. https://www.youtube.com/watch?v=NP9A...ature=youtu.be

Womack, James P., y Daniel T. Jones. 2003. Lean Thinking: Desterrar los residuos y crear riqueza en su corporación, revisado y actualizado. Nueva York: Prensa Libre.

---

1. En un guiño a los orígenes de Lean, la palabra japonesa para residuos, muda se usa a menudo en publicaciones sobre Lean.