miércoles, septiembre 21, 2011

Lean Project Management

Gestión de proyectos magra, (es la traducción de Google para Lean Project Management), es la adaptación completa de otro concepto de magro, como la construcción lean , lean manufacturing, y el pensamiento lean en el contexto de la gestión de proyectos. Gestión de proyectos delgado, (magro) tiene muchas ideas en común con otros conceptos lean, pero el principio fundamental de la gestión de proyectos magra es ofrecer más valor con menos residuos, en el contexto del proyecto.

Y es así, primero fueron los conceptos de “lean manufacturing” que vienen directo de calidad total y Seis Sigma hacia la industria manufacturera, al igual que “lean construction” que viene a mejorar los procesos de la construcción. Cuando se está en el proceso de implantación del pensamiento lean, inclusive llegamos a hablar de “Lean design”, (Diseño magro, sin desperdicio), y Lean Chain, (Cadena de suministro sin desperdicio). Por lo tanto y sin dudas, llega también a la gestión de proyectos, donde el análisis y el aprendizaje en el proceso son fundamentales para “hacer las cosas mejor cada vez”, sobre todo si se trabaja con un portafolio de proyectos diversos, con diversos recursos.

El pasado martes estuve de taller. Nos visita en Venezuela, el Econ. Pablo Lledó, quien cuenta con postgrados en gerencia de proyectos, dirección de proyectos, y negocios internacionales. Es autor de numerosos libros entre los cuales encontramos aquellos destinados a hacer mejor las cosas en la dirección de proyectos. Con ese apellido, pensé me iba a encontrar con un catalán, pero Pablo es de Medoza, Argentina, en la misma América Latina

Empezando el Taller-conferencia sobre lean, nos aclara que el conocimiento de punta hoy en día, es un paso mas allá de lean, es la “gerencia ágil” (Voy a averiguar más, para el próximo post).
Según Pablo, son 5 los principios del pensamiento lean, aplicado a la gerencia de proyectos. (un poco en mis propias palabras para poder recordar, y un poco como un storyteller, y para agregarle valor a la revisión que Pablo eventualmente, le hará a este post):

1. Especificar con precisión las actividades de la cadena de valor de cada proyecto. Se trata de identificar las actividades necesarias y concatenadas, para que de forma continua, en tiempo y con recursos determinados, podamos desarrollar un producto, así como aquellas que no le agregan valor, pero son requeridas para que el proyecto fluya e identificar la “grasa” o aquellas actividades desperdicio que carecen de valor alguno y que su eliminación no ocasionará falla alguna.

2. Identificar el flujo de valor. Va concatenada a la anterior. Se entienden las precedencias, los requisitos, las restricciones y sirve para “hacer una nueva limpieza” y dejar magro el proceso. Se trata de analizar cada actividad y asociarle el recurso exacto que va a necesitar para su ejecución.

3. Permitir que la cadena de valor de los proyectos pueda fluir sin interrupción alguna. Una organización lean, que realiza sus propios proyectos, debe aprender a trabajar en forma transversal, mas por procesos de valor, que como departamentos, que lo que hace es agregarle cosas al sistema, sin tener una visión holística del proceso. Trabajar por departamentos implica necesariamente trabajar en organizaciones matriciales por proyectos donde los recursos son determinados por las necesidades del producto final y según la “voz del cliente”. Se trata de encontrar las barreras del flujo del conocimiento y emprender acciones para realizar los cambios culturales que se ameriten. Trabajar en forma holística o sistémica, vendrá a representar la comprensión de la ubicación de cada quien en el proceso de valor, de manera que permita que las cosas sucedan y hagan que todo fluya para alcanzar las metas.

4. Permitirle al cliente que extraiga el valor al proyecto. La definición del alcance del proyecto se debe realizar siempre con el cliente ya sea interno o externo. Los parámetros, perspectiva y punto de vista, deben ser tomados en cuenta a la hora de estructurar, fases y recursos. El gerente de proyectos, deberá conciliar y establecer la relación ganar-ganar, sobre todo si entiende que los aprendizajes posteriores serán el mayor valor ganado para la organización primaria. En un proyecto lean, el cliente podrá estar en el equipo de trabajo y opinar sobre los procesos de valor para ayudar a mantenerlo ágil.

5. Buscar la mejora continua y la perfección. La mejora continua efectivamente nos viene desde calidad total y ha quedado escrito en los manifiestos mas importantes como ISO 9000, la norma ISO 10006 sobre gestión de proyectos, el PMBoK del PMI para la gestión de proyectos, y todo lo que tiene que ver con el pensamiento lean. De calidad, nos llega el ciclo más conocido por los gestores de proyectos, que es el PDCA, (Plan, do, check, act), que no es más que el aprendizaje continuo, producto de decidir qué hacer, y luego hacerlo. No siendo suficiente estas dos, se requiere su revisión, seguimiento y control, para poder tomar las acciones correctivas y retomar el rumbo planificado.

El PMIBoK en su última versión 2008, ha modificado el modelo de los procesos internos de cada fase establecida, para pasar de 5 procesos a 6, al incorporar el seguimiento a la planificación y ejecución de un proyecto para obtener el producto deseado. (Un poco al final, de PDCA)

Pablo, por su parte, predica la filosofía lean, y no tiene ni un gramo de grasa. ¡Buen ejemplo!

jueves, septiembre 08, 2011

Ciclos, Procesos y Sistemas (aproximación a un capítulo)

¿Un sistema no es un ciclo?



Cuando hacemos un proyecto, a veces nos esforzamos en llamar a cada cosa por su nombre. Pero el caso es que dependiendo de las personas y del tipo de proyecto, nos hemos acostumbrado a usar distintos nombres al mismo proceso, o peor, le damos dos o más nombres al mismo caso. Así pasa con la palabra “Proyecto”. Entendemos que el proyecto como sustantivo significa un grupo de actividades que se realizan con recursos estimados para obtener un producto único. Sin embargo, los talleres de arquitectura suelen llamar también “Proyecto” a la fase de las ingenierías conceptual, básica y de detalles de una edificación, que en su caso concluye con la entrega de los planos, cómputos, cálculos, y especificaciones técnicas; es decir todo lo que se requiere para pasar a la fase de ejecución o construcción.


Por lo tanto es necesario, que podamos contar con un glosario de términos que aclaren el uso y significado de cada término. Lo malo es que según la fuente o según la disciplina, seguimos llamando gatos a los perros y viceversa. Voy a tratar de hacer un esfuerzo para que podamos seguir en la disciplina de generación de lecciones aprendidas a través de la práctica, en definir los términos que coinciden al menos, en la ejecución de proyectos de construcción y de manufactura, y aunque casi todo el origen de los términos vengan de la práctica del desarrollo de proyectos de ingeniería de sistemas.

Según la descripción inicial y que usaremos con mucha frecuencia en los textos sucesivos, hemos tratado de definir el término proyecto. Que tenga un inicio y un fin, al obtener un producto único y en algunos casos irrepetible, nos diferenciamos del término proceso. Porque proyecto está definido en el tiempo, tiene un inicio y un fin y generalmente existe alguna transformación de algo en otra cosa. Los procesos también transforman productos o materias primas en objetos, pero no son finitos sino recurrentes. Los procesos a diferencia de los proyectos, son actividades iterativas y recurrentes que producen ciertos y determinados productos o servicios. Así, y como para hacer la primera diferenciación, un proyecto termina con el producto, los procesos de ejecución de ese producto produciendo bienes y servicios, serán los procesos de producción.
Sin embargo, en el desarrollo de un proyecto, dividido o no en fases o sub proyectos menores, ocurres también procesos internos. Los procesos internos de una fase de un proyecto, tienden al igual que el proyecto entero, en transformar insumos en productos terminados que serán insumos para la fase subsiguiente o un producto final. Los procesos de una fase, según ISO (ISO: 10.006, 2003), al igual que el Project Management Body of Knowledge (PMBoK,2008), son los procesos de inicio y fin y los iterativos internos que siempre son planificar, ejecutar y controlar. Con el impacto de los ciclos de calidad total y su famoso PDCA, Plan, Do , Check, Act, (Planificar, hacer, verificar y actuar), los procesos de la versión 2008 se adecúan a esta filosofía, siendo ahora procesos de planificación, ejecución, verificación y adecuación.

No es más que hacer un plan y ejecutarlo, cosa que no es suficiente. Se requiere que los gerentes revisen nuevamente lo contemplado en la planificación y se realice los ajustes correspondientes en caso de observar desviaciones al plan original.
Hasta los momentos hemos definido a Proyecto, Procesos, y ciclos. Los ciclos no son procesos, no son proyectos, aunque los procesos pueden ser cíclicos como el caso del PDCA. Se supone que en cada ciclo, la información debería llegar nuevamente a la fase de planificación; es por eso que el década 80 y 90 lo llamaron el Ciclo de Calidad Total.

Según wikipedia (2011), los ciclos tendrían las siguienes significados:
• Ciclo: repetición de cualquier fenómeno periódico o cuasiperiódico, en que transcurrido un cierto tiempo el estado del sistema o algunas magnitudes del mismo vuelven a una configuración anterior
• procesos que siempre siguen las mismas fases en el mismo orden

En tal caso usamos para la definición de ciclos, con referencia al “estado del sistema” lo que lo hace un poco más complejo de entender pues se adiciona al diccionario de términos la palabra “Sistema”. Peter Senge en su tradicional libro “La Quinta Disciplina” y posteriormente con “Escuelas que Aprenden”, (2002), ha desarrollado ampliamente el significado, y aun mas, su importancia llegando a postular la necesidad de estudiar por modelado de sistemas en las escuelas y universidades para ayudar a la comprensión del mundo.

En el año 2004, me encontraba siendo designado para un cargo académico en la Universidad Metropolitana en Caracas. El cargo era de Jefe de Departamento, un cargo que en una transformación administrativa habría de diferenciarse del Director de Escuela de las Ingenierías, básicamente porque estaría a cargo del pool docente, mientras que los directores estarían a cargo de los contenidos curriculares. La Facultad de Ingeniería fue dividida en cuatro partes o áreas de conocimiento, Ciencias y Técnicas de la Construcción, Energética, Gestión de la tecnología, y Procesos y Sistemas. Este último, ya con su propio nombre, ha de reconocer que procesos y sistemas no son lo mismo y habrían de comportarse de manera distinta. (Hoy en día le pregunté al Jefe de P&S cuál es la diferencia y me contestó que “un sistema son procesos relacionados entre sí con una función u objetivo. Los sistemas manejan procesos pero como son recursivos, los procesos tienen también sistemas”)

Resulta que pasado el tiempo y en trabajo colaborativo y transversal como recomienda la gerencia moderna, tuvimos que manejar procesos académicos comunes. Fue una fase muy difícil pues nos encontrábamos de repente en discusiones largas e improductivas. En la teoría de paradigmas, comprendí, que no teníamos el mismo y entonces decidí “pensar en sistemas”. En su biblioteca tenía un libro llamado “Introducción al pensamiento Sistémico”, (O¨Connor, 1998). Debo reconocer que pensando en sistemas, logramos que los procesos comunes se desarrollaran con total éxito, es más, llegamos a ser sin lugar a dudas, un EAD, (Equipo de alto desempeño).
Ahora bien, para los efectos de la presente reflexión, ¿qué son sistemas y el pensamiento sistémico, para efectos de la gerencia de proyectos y la gestión posterior del conocimiento derivado?

Un sistema es en términos generales como un objeto compuesto por componentes que de alguna forma se relacionan entre sí. Para los estudiosos de sistemas como forma de conocimiento, los sistemas son “entidades cuya existencia y funciones se mantienen como un todo por la interacción de sus partes. El pensamiento sistémico contempla el todo y las partes, así como las conexiones entre las partes, y estudia el todo para poder comprender las partes. Una serie de partes que no están conectadas no son un sistema sino un montón” (O´connors, 1998). ¿Y por qué es tan importante el estudio en sistemas? Por que el individuo mismo es un sistema que interactúa permanentemente en un mundo de sistemas.

“Los sistemas tienen propiedades emergentes que no se encuentran en las partes que los componen. No se puede predecir las propiedades de un sistema entero dividiéndolo y analizando sus partes” (O`connors, 1998). De esta aseveración y de su comprensión es que también podemos desarrollar la visión holística de los sistemas, cuando podemos decir que siempre el sistema funcionando y sus propiedades emergentes, pesará más, en términos filosóficos, que la suma de sus partes. La comprensión de los sistemas entrega sin lugar a dudas, un conocimiento superior a quien lo analiza. La vida es una propiedad emergente de la suma de las piezas de un ser vivo, el arcoíris es una propiedad del sistema humedad y sol, la música misma es una propiedad emergente de un instrumento y su ejecutor, junto con el oído que lo escucha.
Uno de los principales aportes del pensamiento sistémico, es el modelo de realimentación en círculos (Senge y O`connors). Pensar en bucles o en círculos facilita el modelaje sobre todo si pretendemos elaborar un modelo de aprendizaje continuo y de lecciones aprendidas en proyectos. En sistemas, los bucles de realimentación modelan a sistemas en equilibrio o sistemas funcionando y compensando sus cambios internos. Cuando modelamos el sistema de agua hirviendo, lo hacemos a través de un bucle de compensación. Al abrir el chorro, nos quemamos las manos y abrimos la fría y cerramos un poco la caliente; al estar más fría bajamos la fría y subimos la caliente, hasta que el sistema alcance el equilibrio.

Los procesos por definición serían lineales, pues su modelo es las Entradas, la Transformación, y las Salidas o productos. Sin embargo, y mediante el uso del pensamiento sistémico en círculo y hasta con bucles de realimentación, podemos transformar teóricamente el modelo lineal, al incorporar en el proceso, cualquiera que sea, la noción , descrita anteriormente o el aprendizaje del ciclo. Al agregar a un proceso,, el “aprendizaje posterior” para realimentar a la fase inicial, se transforma automáticamente en un ciclo de calidad y aprendizaje continuo. Es por eso, y como propuesta del siguiente texto, es entender los procesos como sistemas de aprendizaje continuo.
Los proyectos y su Ciclo de Vida, se subdividen en Procesos de realimentación o Ciclos de Aprendizaje Continuo, los procesos cuentan con herramientas que usamos para recolectar información, hacer seguimiento o acometer acciones de corrección del flujo tal como si fuese un sistema.

Los procesos, entendidos como ciclos de realimentación y aprendizaje, son subdivididos en los nueve ciclos de la literatura en proyectos, mas el décimo ciclo, que hace que los procesos se transformen en sistemas: el Conocimiento.