Tabla Comparativa de la Triple Restricción (Alcance, Tiempo y Presupuesto) y su Compatibilidad para Contratos Ágiles

Hola a todos

Desde hace un tiempo tenía este pendiente, estas fichas técnicas y tabla comparativa de la triple restricción (alcance, tiempo y presupuesto) en un contrato y como esta puede ser usada para entornos de contratación ágil.

Tipo de contrato		Afinidad con Ágil
Alcance =fijo   Tiempo= fijo Presupuesto= fijo		baja
Ejemplos
Alcance= 70 funcionalidades Tiempo= 3 meses Presupuesto= 100.000 dólares		Alcance= 2000 funcionalidades Tiempo= 18 meses Presupuesto= 3.000.000 dólares
Recomendación para Ejecución Ágil	Riesgos		Notas Generales
- Realizar contratos pequeños (reducen riesgos de estimación y de insatisfacción del cliente) - Contratar por tiempos máximos de 3 meses, ojalá menos. - Lograr software funcionando y probado en el ambiente más cercano a producción en cada contrato - Priorice* las funcionalidades al momento de construirlas.	Es muy probable que la estimación este mal hecha y no se logre a construir las funcionalidades pactadas, en el tiempo y presupuesto determinado. Entre más grande el proyecto o iniciativa peor será este impacto.		- Un alcance fijo no es buena práctica en un mundo VUCA(1). - Si el alcance es fijo, es poco o nada compatible con ágil, debido a que no está abierto al cambio.

Tipo de contrato		Afinidad con Ágil
Alcance =fijo   Tiempo= fijo Presupuesto=Variable		Media-baja
Ejemplos
Alcance= 70 funcionalidades Tiempo= 3 meses Presupuesto= lo que cueste		Alcance= 2000 funcionalidades Tiempo= 18 meses Presupuesto= lo que cueste
Recomendación para Ejecución Ágil	Riesgos		Notas Generales
- Realizar contratos pequeños (reducen riesgos de estimación y de insatisfacción del cliente) - Contratar por tiempos máximos de 3 meses, ojalá menos - Lograr software funcionando y probado en el ambiente más cercano a producción en cada contrato - Priorice* las funcionalidades al momento de construirlas. - Priorice* las funcionalidades al momento de construirlas.	Es muy probable que la estimación este mal hecha y no se logre a construir las funcionalidades pactadas, tiempo determinado Entre más grande el proyecto o iniciativa peor será este impacto		- Un alcance fijo no es buena práctica en un mundo VUCA. - Si el alcance es fijo, es poco o nada compatible con ágil, debido a que no está abierto al cambio. - Es posible que por contar con presupuesto ilimitado trate de cerrarse el proyecto o iniciativa por fuerza bruta, pero es probable que "ni todo el dinero del mundo" ni los recursos alcancen a cerrarlo en la fecha pactada

Tipo de contrato		Afinidad con Ágil
Alcance =fijo   Tiempo=Variable Presupuesto=fijo		Media-baja
Ejemplos
Alcance= 70 funcionalidades Tiempo= lo que se demore Presupuesto= 100.000 dólares		Alcance= 2000 funcionalidades Tiempo= lo que se demore Presupuesto= 3.000.000 dólares
Recomendación para Ejecución Ágil	Riesgos		Notas Generales
Realizar contratos pequeños (reducen riesgos de estimación y de insatisfacción del cliente) - Contratar por tiempos máximos de 3 meses, ojalá menos - Lograr software funcionando y probado en el ambiente más cercano a producción en cada contrato - Priorice* las funcionalidades al momento de construirlas.	Es muy probable que la estimación este mal hecha y no se logre a construir las funcionalidades pactadas, en el presupuesto pactado. Entre más grande el proyecto o iniciativa peor será este impacto		- Un alcance fijo no es buena práctica en un mundo VUCA. - Si el alcance es fijo, es poco o nada compatible con ágil, debido a que no está abierto al cambio.

Tipo de contrato		Afinidad con Ágil
Alcance =fijo   Tiempo= variable Presupuesto=variable		Media-alta
Ejemplos
Alcance= 70 funcionalidades Tiempo= lo que se demore Presupuesto=lo que cueste		Alcance= 2000 funcionalidades Tiempo= lo que se demore Presupuesto=lo que cueste
Recomendación para Ejecución Ágil	Riesgos		Notas Generales
- Realizar contratos pequeños (reducen riesgos de estimación y de insatisfacción del cliente) - Contratar por tiempos máximos de 3 meses, ojalá menos. - Lograr software funcionando y probado en el ambiente más cercano a producción en cada contrato - Priorice* las funcionalidades al momento de construirlas.	-Posiblemente no se logre resolver el problema pues el alcance fijo no garantiza que se construya lo que resuelve el problema		'- Un alcance fijo no es buena práctica en un mundo VUCA. - Si el alcance es fijo, es poco o nada compatible con ágil, debido a que no está abierto al cambio.

Tipo de contrato		Afinidad con Ágil
Alcance =variable   Tiempo= fijo Presupuesto=fijo		Alta-baja
Ejemplos
Alcance= - Lo de mayor valor - Lo que resuelva el problema de negocio Tiempo= 3 meses Presupuesto= 100.000 dólares		Alcance= - Lo de mayor valor - Lo que resuelva el problema de negocio Tiempo= 18 meses Presupuesto= 3.000.000 dólares
Recomendación para Ejecución Ágil	Riesgos		Notas Generales
-Se requiere involucramiento del area usuaria o del cliente que va a usar la solucion para que valide constantemente la construcción del alcance. - Tenga una versión temprana del producto (MVP-Miínimo Producto Viable), con la minima cantidad de alcance,  lo antes posible que valide si vale la pena seguir construyendo el producto - Pacte releases de software funcionando. - Ojalá esos releases sean máximo cada tres meses - Lograr software funcionando y probado en el ambiente más cercano a producción en release - Priorice* las funcionalidades al momento de construirlas, de forma que si se acaba el tiempo o el presupuesto, construyó lo de mayor valor primero	-Posiblemente no se logre resolver el problema con esas dos restricciones		-La priorización por valor y las entregas tempranas permitirán reducir el riesgo del producto por parte de los usuarios - Se sugiere tener mentalidad de inversionista y no de gestión de costos en este enfoque, de forma que se pueda finalizar o continuar invirtiendo en función de la generación de ROI

Tipo de contrato		Afinidad con Ágil
Alcance = variable Tiempo= variable Presupuesto=fijo		Alta-media
Ejemplos
Alcance= - Lo de mayor valor - Lo que resuelva el problema de negocio Tiempo= Lo que se demore Presupuesto= 100.000 dólares		Alcance= - Lo de mayor valor - Lo que resuelva el problema de negocio Tiempo= Lo que se demore Presupuesto= 3.000.000 dólares
Recomendación para Ejecución Ágil	Riesgos		Notas Generales
-Se requiere involucramiento del area usuaria o del cliente que va a usar la solución para que valide constantemente la construcción del alcance. - Tenga una versión temprana del producto (MVP-Miínimo Producto Viable), con la minima cantidad de alcance,  lo antes posible que valide si vale la pena seguir construyendo el producto - Pacte releases de software funcionando. - Ojalá esos releases sean máximo cada tres meses - Lograr software funcionando y probado en el ambiente más cercano a producción en release - Priorice* las funcionalidades al momento de construirlas, de forma que si se acaba el presupuesto, construyo lo de mayor valor primero	-Es posible que no se logre resolver el problema con esa restricción		-La priorización por valor y las entregas tempranas permitirán reducir el riesgo del producto por parte de los usuarios. - Se sugiere tener mentalidad de inversionista y no de gestión de costos en este enfoque, de forma que se pueda finalizar o continuar invirtiendo en función de la generación de ROI

Tipo de contrato		Afinidad con Ágil
Alcance =variable Tiempo= fijo Presupuesto=variable		Alta-media
Ejemplos
Alcance= - Lo de mayor valor - Lo que resuelva el problema de negocio Tiempo= 3 meses Presupuesto= lo que cueste		Alcance= - Lo de mayor valor - Lo que resuelva el problema de negocio Tiempo= 18 meses Presupuesto= lo que cueste
Recomendación para Ejecución Ágil	Riesgos		Notas Generales
-Se requiere involucramiento del area usuaria o del cliente que va a usar la solucion para que valide constantemente la construcción del alcance. - Tenga una versión temprana del producto (MVP-Miínimo Producto Viable), con la minima cantidad de alcance,  lo antes posible que valide si vale la pena seguir construyendo el producto - Pacte releases de software funcionando. - Ojalá esos releases sean máximo cada tres meses - Lograr software funcionando y probado en el ambiente más cercano a producción en release - Priorice* las funcionalidades al momento de construirlas, de forma que si se acaba el el tiempo, construyo lo de mayor valor primero	-Es posible que no se logre resolver el problema con esa restricción. Es posible que como se cuentan con presupuesto sin restricciones, se trate de cerrar el proyecto o iniciativa en la fecha pactada, pero ni aun así se logre el objetivo		-La priorización por valor y las entregas tempranas permitirán reducir el riesgo del producto por parte de los usuarios. - Se sugiere tener mentalidad de inversionista y no de gestión de costos en este enfoque, de forma que se pueda finalizar o continuar invirtiendo en función de la generación de ROI

Tipo de contrato		Afinidad con Ágil
Alcance =variable   Tiempo= variable Presupuesto=variable		Alta-alta
Ejemplos
Alcance= - Lo de mayor valor - Lo que resuelva el problema de negocio Tiempo= lo que se demore Presupuesto= lo que cueste		Alcance= - Lo de mayor valor - Lo que resuelva el problema de negocio Tiempo= lo que se demore Presupuesto= lo que cueste
Recomendación para Ejecución Ágil	Riesgos		Notas Generales
-Se requiere involucramiento del area usuaria o del cliente que va a usar la solucion para que valide constantemente la construcción del alcance. - Tenga una versión temprana del producto (MVP-Miínimo Producto Viable), con la minima cantidad de alcance,  lo antes posible que valide si vale la pena seguir construyendo el producto - Pacte releases de software funcionando. - Ojalá esos releases sean máximo cada tres meses - Lograr software funcionando y probado en el ambiente más cercano a producción en release - Priorice* constantemente las funcionalidades al momento de construirlas, que se garantice el mayor impacto	- No realizar una ejecución ágil del proyecto o iniciativa		-La priorización por valor y las entregas tempranas permitirán reducir el riesgo del producto por parte de los usuarios. - Se sugiere tener mentalidad de inversionista y no de gestión de costos en este enfoque, de forma que se pueda finalizar o continuar invirtiendo en función de la generación de ROI

* Se sugiere emplear la técnica de WSJF - weighted shortest job first

Puedes descargar en formato PDF aquí

Como siempre, bienvenida la retroalimentación

Saludos Ágiles

Jorge Abad.


Notas, Aclaraciones, Comentarios, Referencias y  Observaciones.

1. VUCA es un acrónimo utilizado para describir o reflejar la volatilidad, incertidumbre (uncertainty en inglés), complejidad y ambigüedad de condiciones y situaciones. Más información en  https://es.wikipedia.org/wiki/VUCA