Pues haciendo una recapitulación del avance que hemos tenido en materia de administración de proyectos en los últimos años, he encontrado cambios importantes en el Mercado que debemos considerar. El primero de ellos es la irrupción tan fuerte que han tenido las metodologías ágiles en la administración de proyectos de muchos tipos en los negocios. Seguidamente algunos otros elementos interesantes como la simplificación de los conceptos de PM[1] y el enfoque a las personas y los procesos, cambios que si esta familiarizado con la certificación PMP le van a ser comunes.
Ahora bien, en la práctica hay que saber cuál metodología aplicar para cuál necesidad; me gusta en lo personal hablar del término “metodología” por cuanto resume algo que para cualquier persona puede ser muy importante, y es el “cómo”. El “cómo” es la secuencia lógica de pasos que usamos para hacer algo, generalmente supeditado a un objetivo de proyecto.
En el mercado de negocios existen muchos cómos, algunos se mantienen más vigentes que nunca, tales como Seis Sigma o el PM Bok, otros van de salida como los conceptos de la re-ingeniería, y también otros van camino a su consagración en el Olimpo de las nuevas maneras de resolver necesidades en los negocios, en esta clasificación están las metodologías ágiles.
[1] Project Management o Administración de Proyectos
Hace un tiempo atrás he estado estudiando más a detalle una cuestión particular, y es ¿dónde convergen las tecnologías ágiles y las metodologías Seis Sigma? El portal web www.proyectosaguiles.org define las llamadas “metodologías ágiles” como un proceso en el que se aplican de manera regular un conjunto de buenas prácticas para trabajar colaborativamente, en equipo, y obtener el mejor resultado posible de un proyecto. Estas prácticas se apoyan unas a otras y su selección tiene origen en un estudio de la manera de trabajar de equipos altamente productivos.
Algunas cualidades que tienen son:
- Fuerte enfoque a proyectos de desarrollos informáticos.
- Un enfoque a proyectos de un tamaño significativo.
- Una necesidad explicita de enfoque al cliente.
- La Jerga de Scrum es eminentemente de informáticos.
Por otro lado, si analizamos SEIS SIGMA como tal vemos elementos tales como:
- Fuerte enfoque estadístico.
- Versátil, desde proyecto chico a proyecto grande.
- Enfoque fuerte al cliente.
- Se adecua más para que otras disciplinas lo asimilen.
Estos puntos anteriores son fundamentales, porque lo que busco es definir un marco común entre scrum-framework y Six Sigma. La justificación de este artículo se basa en que primero que todo, muchas personas tienen curiosidad por saber qué es eso de las metodologías ágiles, segundo han escuchado que permiten avanzar más rápido con la tarea. Por otra parte, hay que tomar en cuenta, que muchos ya tenemos algunos años utilizando Seis Sigma, esto implica que si lo hemos hecho bien, podemos contar en nuestro currículo con exitosos proyectos que hablen de nuestra valía como profesionales certificados, sin embargo tenemos el “gusanillo” de poder mejorar lo que de por sí ya es una metodología enfocada a la mejora continua.
He de decir, que efectivamente hay cuestiones importantes en SCRUM que pueden aplicarse, este primer artículo va en función de tomar elementos de SCRUM y adicionárselos a Seis Sigma para hacerlo más potente, posteriormente estaré desarrollando algún material en el otro camino, Seis Sigma a SCRUM.
SCRUM, como usted sabe, es una de las vertientes más reconocidas de las metodologías ágiles. Tiene ya varios años en el mercado y fue constituido en el 2001 por varios entusiastas desarrolladores liderados en ese entonces por Kent Beck. Los principios establecidos para constituir la metodología Agile se basó en 12 principios fuertemente orientados a cambiar la forma en que se desarrollaba software. Hasta ese momento los desarrollos más comunes eran los conocidos como los desarrollos “cascada” los cuales, veían de un principio a un fin el desarrollo de un software, de una forma lineal, entregando al cliente el fruto de ese trabajo hasta una validación final. Agile vino a cambiar muchos de éstos paradigmas de desarrollo, entre ellos incorporó la figura de un “product owner” el cual se encarga de sentarse con el cliente y estar totalmente claro y consciente de que es lo que quiere, siendo su defensor y siendo el representante del mismo ante los desarrolladores. Segundo, instituyó la figura del “sprint”. Como usted sabe, la palabra en inglés sprint significa en español “carrera corta”. Lo interesante del “sprint” es que visualiza algo que es muy común en los proyectos de cualquier tipo, y es que para llegar a un fin último pasamos por una serie de fines intermedios, que incluso podrían ser funcionales al cliente y servir de validación para saber si estamos cumpliendo la idea del cliente que nos contrató. Hay muchos otros conceptos de SCRUM, pero me quiero enfocar en ese par por el momento.
En gestión de proyectos Seis Sigma estamos muy acostumbrados a los ejercicios de Voz del cliente. Ese ejercicio que permite antes de iniciar un proyecto preguntarle al cliente qué es lo que quiere y cómo es que lo quiere, donde por lo general definimos aspectos críticos para la calidad de lo que requiere nuestro cliente, y nos dice entre otras cosas como satisfacerlo, cuales aspectos son más prioritarios para el cliente e incluso, cuáles cuestiones visualizamos nosotros como equipo de diseño y que realmente pueden no ser tan valiosas para el cliente.
Herramientas clásicas como las encuestas, el modelo Kano, el QFD (Despliegue de la función de Calidad) entre otros son útiles en esta fase de escuchar la VOC (voz del cliente) y nos permite, retrospectivamente al final, también realizar ese análisis de sensibilidad entre lo hecho y lo que se quería. Ahora bien, si analizamos bien el papel del product owner y la VOC considero que hay similitudes importantes e incluso ganancias netas al respecto, veámoslo:
Sin embargo, ya vemos que hay similitudes interesantes entre estos dos temas, el más valioso para mi persona es la Voz del Cliente Activa que se genera. Una cuestión que tradicionalmente falla en los proyectos Seis Sigma es mantener el foco en lo que quiere el cliente, realizamos el ejercicio perfectamente al inicio del proyecto pero fallamos en mantener nuestros esfuerzos de diseño en precisamente eso que quiere el cliente. Es aquí donde SCRUM le da una dosis de “esteroides” al VOC del Seis Sigma, haciendo la voz del cliente una constante en todo el proyecto, por lo tanto: ¿qué debemos hacer? pensar en que en el equipo de proyecto exista el rol del product owner para contar con un referente en voz del cliente que nos permita mantener un alineamiento de las necesidades explícitas y hasta implícitas del cliente.
Hay algunas otras cosas que hace este product owner sin embargo se pueden satisfacer bajo otras cuestiones imperantes en los proyectos Seis Sigma. Algunas de ellas son el mantener el tema de las partes interesadas claro, mapeado y vigente. Otra vez volvemos al mismo tema, en proyectos Seis Sigma hablamos de que debemos generar estrategia para que los stakeholders estén comunicados, monitoreados y sobre todo tomados en cuenta (no por nada son los que tienen interés de una u otra forma en nuestra iniciativa de mejora), sin embargo, hacer este análisis generalmente recae en la tarea de la fase de “DEFINIR” y hasta ahí. Con un product owner siendo parte del equipo, podemos tener garantía que los stakeholders se les está tomando en cuenta y que se les mantiene un proceso constante de retroalimentación, y lo que en proyectos SCRUM son clientes finales, en Seis Sigma serían nuestros muy importantes stake holders.
Stake holders = clientes finales
Ahora bien, vamos a tratar una de las características más brillantes del SCRUM, el Sprint. Ya introdujimos el concepto del Sprint que implica en definir períodos cortos de tiempo en el que el equipo de desarrollo trabajará enfocado en objetivos intermedios de proyectos, esto es lo que se conoce como el Spring Backlog.
El Sprint Backlog es una planificación táctica del trabajo a realizar del Spring que corresponda. Puesto en palabras sencillas, vamos a definir un listado de tareas que vamos a realizar durante el spring para lograr generar un producto intermedio en nuestro proyecto, por ejemplo en informática podría ser realizar un diseño de una base de datos a través de una tabla relacional, para poder saber cómo comunicar entre capturas de datos cada grupo de datos con todos los demás datos contenidos en la base del software. En Seis Sigma hacemos algo muy similar a esto, tenemos las etapas del DMAIC o el DMADV. Como usted sabe cada etapa implica realizar tareas que tienen un fin muy bien establecido. Por ejemplo, cuando realizamos la etapa de MEDIR, queremos determinar los factores que inciden en nuestro problema o necesidad, queremos medirlos para saber el estado actual de los mismos y queremos saber cómo tratar la información ya sea estadísticamente o como un ejercicio de análisis cualitativo. Por lo tanto, a semejanza de un Spring Backlog podríamos definir que adecuaremos cada etapa del proyecto Seis Sigma a través de un Spring y la definición de lo que hacemos en equipo con la guía del Black Belt o el Green Belt sería específicamente las tareas de la etapa DMAIC o DMADV, siendo esta un tipo de Spring Backlog. Lo interesante de adicionar el concepto del Spring a cada etapa DMAIC o DMADV radica en que podríamos lograr rapidez y una alta orientación de lo que hacemos a lo que quiere el cliente (no olvide que por ahí anda nuestro flamante product owner). Considero que lo anterior es una clara adición de robustez al proyecto Seis Sigma, por cuanto en las etapas a muchos Black Belts y Green Belts les cuesta ver la importancia de avanzar rápido y avanzar bien, siendo muchas veces esto señal de atrasos importantes de la fecha de término del proyecto. También, las etapas del DMAIC y el DMADV muchas veces no se pueden ver como “cascadas” o sea, como una secuencia de pasos que se realiza y al final es obtenido un producto. Si analizamos problemas complejos, las etapas de ANALIZAR pueden ser cíclicas muchas veces, porque la complejidad de las causas del problema nos obliga a realizar varios ciclos de diagnósticos. La etapa de MEDICIÓN es también cíclica en muchos casos porque nuestras primeras apuestas de datos a recopilar y analizar simplemente pueden no ser lo suficientemente buenas para concluir causas raíz e incluso en IMPLEMENTAR y CONTROL si no se dan los resultados puede requerir realizar varias iteraciones de los mismos hasta que contemos con los resultados esperados.
Con la adición del concepto de Sprint logramos impregnar a la etapa Seis Sigma de ese sentido de urgencia primeramente, el de terminar la etapa en un tiempo definido pero sobre todo el de terminar demostrándole al cliente que vamos bien, disminuyendo la incertidumbre hacia el resultado final y logrando cumplir los plazos establecidos, respetando el hecho que los proyectos Seis Sigma pocas veces son secuencias tipo cascada, sino mas bien ciclos dentro de las mismas etapas.
Por lo tanto, como ustedes observarán, podemos contar con adiciones importantes entre gestión de proyectos por metodologías ágiles y el uso de nuestro querido y robusto Seis Sigma. Las cuestiones que aquí hablamos pueden tal vez no parecerle tan innovadoras, incluso tal vez, hasta como yo, algunas las hemos deducido de nuestra experiencia práctica de PMs, sin embargo, también pueden ser muy novedosas para colegas que estén adentrándose en este mundo de la administración de proyectos. Otro detalle: SCRUM ha sido desde hace ya varios años, terreno exclusivo de los informáticos, aquí estamos tratando de hacer un enfoque hacia proyectos de mejora continua de situaciones de negocio de cualquier tipo, obviamente se necesita más desarrollo, pero por el momento el concebir a un product owner como uno más de nuestro equipo de proyecto de mejora continua y el de gestionar nuestras etapas de proyecto DMAIC o DMADV a través del concepto del Spring y del Spring Backlog puede ser la clave de que sus proyectos estén a tiempo y en la calidad de lo que su cliente quiere.
En nuestra próxima entrega hablaremos de la conformación de los equipos de mejora tomando en cuenta las metodologías ágiles, y sobre todo qué pasa entre el rol del líder de proyecto tipo Black Belt o Green Belt y el SCRUM Master, que es la figura clave de SCRUM; mucha suerte en sus proyectos.
