Los compradores de software deberían aprender gestión de riesgos

Sigo encontrándome en mi trabajo diario con empresas que pretenden comprar grandes proyectos de desarrollo de software de una vez, con alcance y precio fijo. Aún en contextos donde ni ellos mismos tienen claro todo el proyecto y no han logrado internamente todos los compromisos requeridos para realmente fijar un alcance. 

Fantasean con la idea de trasladar todo el riesgo al proveedor contratado. Entiendo que el razonamiento es "si alguien lo acepta, listo, ahora sólo tengo que presionar para que se cumpla el contrato".

No importa mucho si la idea fue del departamento de TI, del de Compras o de algún otro lado. Lo que importa es que es incorrecta, el riesgo también es suyo.

Y esto se debe a que si luego

• Si el proveedor pide renegociar el contrato, ustedes tendrán un problema.
• Si el proveedor cancela el proyecto, ustedes tendrán un problema.
• Si el proveedor pide recortar alcance, ustedes tendrán un problema.
• Si el proveedor pide cambiar las fechas, ustedes tendrán un problema.
• Si el proveedor hace lo que puede y se arrastra a lo largo del proyecto, ustedes tendrán un problema (porque ese proveedor no querrá trabajar más allí).
• En definitiva, si quieren poner el riesgo todo del lado del proveedor, ustedes tendrán un problema.

Mi consejo: probar contratando cosas más chicas, más acotadas, más cercanas y planificables.

Una forma es pensar scrum y partir el riesgo en partes. Y ¿por qué usar un enfoque scrum disminuiría el riesgo? Bueno.. léanlo del propio Jeff Sutherland en el post titulado How Scrum Manages Risk. Les dejo una frase de los comentarios del post citado que me parece genial:

“Risk management is project management for adults”, Tim Lister

Seguimos pensando..