Tan cerca, Tan lejos. Una Comparación entre el Agile Inception y el Acta de Constitución del Proyecto (Project Charter) del PMBok

Hola a todos

Desde hace un tiempo me debía a mí mismo y a ustedes la escritura de este post, pues en numerosas ocasiones durante los entrenamientos de Scrum o Gerencia de Ágil de Proyectos he hecho esta comparación, y es bueno dejarla plasmada para ayudar mejor a la ilustración de lo que quiero decir.

Los Dos Mundos, el Predictivo y el Ágil

Dentro de los 47 procesos de la gerencia de proyectos del PMBoK (versión 5) existe el primer proceso llamado “4.1 Desarrollar el Acta de Constitución del Proyecto” (este proceso pertenece a los procesos de inicio) que cuenta básicamente con los siguientes aspectos

·         Objetivo

o   “Es el proceso de desarrollar un documento que autoriza formalmente la existencia de un proyecto y confiere al director del proyecto la autoridad para asignar los recursos de la organización a las actividades del proyecto”(1)

·         Entradas

o   Enunciado del trabajo del proyecto

o   Caso de Negocio

o   Acuerdos

o   Factores ambientales de la empresa

o   Activos de los procesos de la organización

·         Herramientas y Técnicas

o   Juicio de Expertos

o   Técnicas de Facilitación(2)

·         Salidas

o   Acta de constitución del proyecto

Y sugiere documentar los siguientes aspectos (1):

·         El propósito o la justificación del proyecto,

·         Los objetivos medibles del proyecto y los criterios de éxito asociados,

·         Los requisitos de alto nivel,

·         Los supuestos y las restricciones,

·         La descripción de alto nivel del proyecto y sus límites,

·         Los riesgos de alto nivel,

·         El resumen del cronograma de hitos,

·         El resumen del presupuesto,

·         La lista de interesados,

·         Los requisitos de aprobación del proyecto (es decir, en qué consiste el éxito del proyecto, quién decide si el proyecto tiene éxito y quién firma la aprobación del proyecto),

·         El director del proyecto asignado, su responsabilidad y su nivel de autoridad

·         El nombre y el nivel de autoridad del patrocinador o de quienes autorizan el acta de constitución del proyecto.

Para mayor ilustración sugiero leer este articulo del PMI Colombia (Acta de Constitución del Proyecto) y este excelente ejemplo (Ejemplo Acta de inicio del Proyecto)

Ahora, si realizamos los talleres de Agile Inception (Inicio Ágil – en español) como los sugieren:

·         The Agile Samurai: How Agile Masters Deliver Great Software (Pragmatic Programmers) de Jonathan Rasmussone (clic aquí)

·         Inceptions. Starting a Software Project de Enrique Comba Riepenhausen (clic aquí)

Encontramos que sugieren en un taller de 2 a 3 días obtener lo siguiente

·         Quién está en el Salón o Taller

·         Las reglas de Juego del taller

·         Por qué estamos aquí (en este taller)

·         Crear el Elevator Pitch

·         Diseñar la caja de producto

·         Crear el Product Backlog Board(3)(4)

·         Crear la lista de No

·         Encontrar tu comunidad

·         Que te mantiene despierto en la noche

·         Muestra la solución

·         Darle una personalidad a la solución

·         Mostrar el flujo

·         Story Mapping (Plan de Releases)

·         Qué vamos a obtener (Restricciones, Prioridades, Beneficios)

·         Cuánto va a costar y cuánto nos va a tomar

Y si comparamos ambos

Realizando la comparación de ambos, se tienen muchas coincidencias:

Agile Inception	Acta de Constitución del Proyecto (PMBoK)
·         Quién está en el Salón o Taller ·         Las reglas de Juego del taller	·         Aplica parcialmente, no siempre es un taller.
·         Por qué estamos aquí (en este taller) ·         Crear el Elevator Pitch	·         El propósito o la justificación del proyecto,
·         Diseñar la caja de producto ·         Product Backlog Board	·         Los objetivos medibles del proyecto y los criterios de éxito asociados, ·         Los requisitos de alto nivel, ·         Los requisitos de aprobación del proyecto (es decir, en qué consiste el éxito del proyecto, quién decide si el proyecto tiene éxito y quién firma la aprobación del proyecto -  esta última parte no corresponde a un inception - ),
·         Crear la lista de No	·         Los supuestos y las restricciones, ·         La descripción de alto nivel del proyecto y sus límites,
·         Encontrar tu comunidad	·         La lista de interesados,
·         Que te mantiene despierto en la noche	·         Los riesgos de alto nivel
·         Muestra la solución ·         Darle una personalidad a la solución ·         Mostrar el flujo	·         La descripción de alto nivel del proyecto y sus límites,
·         Story Mapping (Plan de Releases)	·         El resumen del cronograma de hitos,
·         Que vamos a obtener (Restricciones, Prioridades)	·         Los supuestos y las restricciones,
·         Cuánto va a costar y cuánto nos va a tomar (estos valores son aproximados, nunca cerrados)	·         El resumen del presupuesto,
·         No aplica	·         El director del proyecto asignado, su responsabilidad y su nivel de autoridad
·         No aplica	·         El nombre y el nivel de autoridad del patrocinador o de quienes autorizan el acta de constitución del proyecto.

¿Entonces en dónde radica la diferencia?

En esencia, se observa que es lo mismo para ambos tipos de iniciativas (predictiva o ágil), aún más el PMBoK sugiere que sean talleres facilitados y no dudo que algunos gerentes de proyecto lo hagan así, pero lo que si es cierto es que en Agile es necesario (por no decir obligatorio) que sea un taller y que se maximice la comunicación cara a cara como lo sugiere el manifiesto ágil y sus principios (5) para garantizar el éxito de lo que se va a realizar.

Adicional en proyectos tradicionales (en los cuales la planeación predictiva es ideal):

-          Construcción de edificios

-          Construcción de puentes

-          Construcción de carreteras

-          Ampliaciones de fábricas

-          Construcción de barcos

Se hace hasta lo imposible por cerrar el alcance y no dejar lugar a la incertidumbre, pues el costo de los cambios es altísimo (¿o no creen que un dos nuevos carriles en la carretera o 2 pisos más en el edificio, fuera de afectarán gravemente los planes, cambiará el diseño de temas importantes?), cosa muy distinta en desarrollo ágil donde el software es más maleable y  donde somos tenemos una arquitectura base sobre la que podemos evolucionar.

Para cerrar esta pequeña comparación, les comparto esta tabla en donde presento las principales diferencias de ambos enfoques:

	Agile Inception	Acta de Constitución del Proyecto (PMBoK)
Propósito principal	No es el objetivo del Inception, esto debe ser resuelto antes.	Autoriza formalmente la existencia de un proyecto
	No tiene como objetivo entregar Autoridad.	confiere al director del proyecto la autoridad para asignar los recursos de la organización a las actividades del proyecto
	Es un taller que permite a los interesados y al posible Product Owner(PO): ·         Entender la idea que se tiene a un nivel más profundo ·         Identificar las posibles dificultades del proyecto ·         Decidir si se continuará o no con el mismo ·         Proporciona al PO y a sus Interesados información suficiente para guiar al equipo de desarrollo en la construcción del producto	No corresponde a su objetivo primordial
Respecto al alcance	Se busca tener una primera versión u hoja de ruta sobre las cuales realizaremos la construcción del producto mínimo viable (MVP - http://www.lecciones-aprendidas.info/search/label/mvp ) y seguiremos creciendo incrementalmente hasta que construyamos el producto que requiere el negocio.	Se centra en esbozar el alcance va a detallar y gestionar en las siguientes grupos procesos de la gerencia de proyectos: ·         Planeación ·         Ejecución ·         seguimiento y control ·         y cierre
Transparencia	Esta información queda disponible al lado del equipo del proyecto para que sirva como radiador de información y le sirva para tomar decisiones	Muchas veces no es un taller, se comparte con el equipo y los interesados del proyecto, pero no se garantiza que todos la conozcan aunque se sugiere que todos la dominen.

Hasta acá esta corta comparación, los invito a profundizar en estos links

-          Webinar- Agile Inceptions - http://www.lecciones-aprendidas.info/2016/08/inceptions-con-lucho-salazar.html

-          Story Mapping - http://www.lecciones-aprendidas.info/2016/06/user-story-map-mapas-de-historias-de.html

-          EDT Ágil - http://www.lecciones-aprendidas.info/2016/07/hola-todos-cuando-desde-la-gerencia-de.html

-          Sprint Cero o Agile Inception

o   http://www.lecciones-aprendidas.info/search/label/inception

o   http://www.lecciones-aprendidas.info/search/label/sprint%20cero

-          Colección de entregables generados en un Inception

o   http://www.lecciones-aprendidas.info/search/label/product%20backlog%20board

Bienvenidos sus comentarios y feedback.

Saludos Ágiles, 

Jorge Abad        

Notas, aclaraciones, referencias

1.       Guía de los Fundamentos para la Dirección de Proyectos. Guía del PMBoK Quinta Edición.

2.       Se enumeran entre varias posibles actividades: la tormenta de ideas, resolución de conflictos, gestión de reuniones para realizar la obtención de este entregable.

3.       Aunque no Corresponde a una propuesta de Agile Samurai o Inceptions, es ampliamente usado y recomendable para este proceso

4.       Ejemplos del Product Backlog Board - http://www.lecciones-aprendidas.info/search/label/product%20backlog%20board

5.       http://agilemanifesto.org/iso/es/principles.html - “Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.”,  “El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.”

Diferencia entre Valor de Negocio (Ágil) y Valor según el PMI

Una de las técnicas que tiene el PMI en el PMBoK para hacer seguimiento del avance del proyectos es la Técnica del Valor Ganado (earned value method  -EVM -) y esta consiste (de una forma muy básica) determinar cuanto alcance hemos logrado con respecto la linea base planteada de costos, o sea:

• Imaginémonos un proyecto donde planteamos que al 75% del tiempo del proyecto, el valor del alcance logrado era de $100.000.0000, pero si para esa fecha el valor de alcance logrado es de $60.000.000, este último valor corresponde al VALOR GANADO a la fecha..

Lo triste es que si con  estos $60.000.000 y 75% del tiempo del cronograma  el equipo del proyecto se la pasó haciendo:

• documentación, 
• prototipos, 
• tablas paramétricas
• funcionalidades que no correspondían al core del negocio, 

Lo que hicieron pudo pudo haber sido "muy bueno - funcionar muy bien - ", "muy bonito" pero sino lograron avanzar en lo realmente importante de poco o  nada sirve.  (se cancela el proyecto por alguna razón externa extraña y ese tiempo y dinero invertido no aportaron a su propósito dentro del negocio del cliente)

En las metodologías ágiles nos enfocamos en el valor de negocio, o sea en las funcionalidades que permiten al cliente poner a funcionar su negocio lo antes posible (buscando cumplir siempre con el principio de pareto : 20% de las funcionalidades que aportan al 80% del negocio), documentando solamente lo realmente importante y aplazando funcionalidades:

• nice to have (seria lindo / chévere que hiciera..)
• o ya que...
• "ya que" estamos haciendo esto.. hagamos aquello
• que solo van a hacer usadas por una persona cada año (o similar) y que se obtienen con query a base de datos
• Programar casos que en el proceso de negocio nunca se presentarán o que se resuelven diciendo "el sistema no soporta esta funcionalidad." o si se dá el caso miraremos si lo hacemos en una próxima versión.
• que emulan al excel, perfectamente pudiendo exportar a excel y allí realizar el tratamiento de datos adecuado (he visto muchos sistemas así.. ¿¿¿ustedes no??? )

Por lo tanto VALOR DE NEGOCIO y VALOR según el PMI son distintos.

Y lo que sería más sensato llamar a la técnica del valor ganado(EVM), mejor como "TÉCNICA ALCANCE COMPRADO/LOGRADO", pues quizás ese alcance comprado/logrado sea o no sea de valor para el negocio y los índices de avance SPI, Y CPI servirán para determinar cuanto estamos cumpliendo con el plan, pero no realmente cuanto valor estamos generando para nuestro cliente.


Nota:
Para una mayor precisión sobre el tema sugiero leer el Chaos Manifesto del 2013, del Standish Group( http://versionone.com/assets/img/files/ChaosManifesto2013.pdf ) el cual cito textualmente:  "Our analysis suggests that 20% of features are used often and 50% of features are hardly ever or never used. The gray area is about 30%, where features and functions get used sometimes or infrequently. The task of requirements gathering, selecting, and implementing is the most difficult in developing custom applications. In summary, there is no doubt that focusing on the 20% of the features that give you 80% of the value will maximize the investment in software development and improve overall user satisfaction. After all, there is never enough time or money to do everything. The natural expectation is for executives and stakeholders to want it all and want it all now. Therefore, reducing scope and not doing 100% of the features and functions is not only a valid strategy, but a prudent one. "

Lean Thinking, Dirección de Proyectos usando PMBOK y aportes a la gestión de proyectos informáticos

Hola a todos

Presentó el trabajo realizado por uno de mis alumnos (Juan Felipe Arango Aguirre) de la materia Gestión de Proyectos informáticos que dicto en la Universidad Eafit en Medellín.

Para ver el artículo haga clic aquí