Para Tom DeMarco en su libro «Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency» (traducción libre): «Si identificas cualquier proyecto como libre de riesgos, o incluso relativamente libre de riesgo, cancélalo. Vas a necesitar los recursos y el plazo para hacer algo transformacional».
Desde mi punto de vista, DeMarco trata de poner sobre la mesa la importancia de tener en cuenta los riesgos que se presentan en un proyecto de desarrollo de software y que van más allá de un análisis superficial del mismo.
Claro que hay proyectos con menos riesgos y donde se prevé una cierta estabilidad que facilite la gestión del proyecto, el trabajo de las personas y las relaciones entre los diferentes implicados, pero también lo es que la incertidumbre es una variable inherente en los proyectos de desarrollo de software y que se pueden producir situaciones que en un plazo corto de tiempo requieran hacer adaptaciones y ajustes sobre el proyecto y ahí es donde pueden aparecer problemas que afecten de manera sensible al mismo, entre otras cosas porque no se suele ir muy sobrado ni de presupuesto ni de tiempo y si el producto además se encuentra en producción, la presión que se recibe se incrementa considerablemente.
Es cierto que hay incertidumbre y circunstancias que no son sencillas de ser previstas pero también lo es que sí hay otras que pueden ser previsibles a corto, medio y largo plazo y ahí es donde entra la gestión de riesgos en los proyectos de desarrollo de software, en la capacidad de identificarlos y de tomar medidas o no en función del impacto del riesgo, del coste de las medidas, de la probabilidad de su ocurrencia, etc…
La identificación de riesgos debería comenzar desde incluso la etapa de conceptualización o definición del proyecto porque lo mismo, tras un análisis de los mismos se decide que lo mejor es no realizar el proyecto, buscar otras alternativas, plantearse alcances, presupuestos y plazos más realistas, etc…