Por qué contratar sólo la conceptualización

Al principio de un proyecto complejo no es fácil estimar
el tamaño del mismo

Muchas veces los gerentes presurosos de resolver un problema de gestión se avocan a formular un proyecto de transformación, de creación o mejora, de un servicio de información existente. El proyecto requiere recursos y numerosas veces la contratación de un ente externo para su desarrollo. Suena razonable contratar pues, con el debido proceso, una organización que lleve a cabo las cuatro etapas naturales del ciclo de vida: Definición, Diseño, Desarrollo e Implementación. Si no se realizan las cuatro, la solución no entrará en producción. Sin embargo, el contratar las cuatro puede ser un problema que conduzca una parálisis peligrosa del proyecto, que puede correr el riesgo de quedar inconcluso. ¿Por qué?

El primer riesgo en un proyecto es el que planteamos la semana pasada: que el mismo se inicie sin una visión compartida entre los desarrolladores y los futuros usuarios y contratantes de la solución. Por ello, independientemente de que su tamaño sea grande o pequeño, es clave asegurar la visión compartida al inicio.

Pero el problema al que nos referimos hoy es otro: Incluso arrancando con una visión compartida, un proyecto puede ir mal, si por sus características, su tamaño, es decir, el esfuerzo que se requiere para realizarlo, es mucho más grande del que se estimó. En ese caso en algún momento será evidente que el proyecto no converge, que los lapsos de tiempo se excedieron, incluso significativamente, y sin embargo, el fin no se ve cerca.

Uno podría pensar que el problema tiene que ver con la inexperiencia de los desarrolladores en la construcción del tipo particular de soluciones acometidas, y hay veces esto es lo que ocurre, sobre todo si la comunicación entre desarrolladores y contrapartes no es fluida. Pero el problema el problema estructural en estos casos es el que nace en una estimación de tamaño inadecuada porque se hace en forma muy temprana, cuando no se tiene consciencia real de la magnitud del proyecto, de la cantidad de relaciones que implica, de los numerosos casos de uso que hay que atender, del complejo modelo de información que hay que construir, de la cantidad de salidas diferentes, de la cantidad de comunidades que hay que tomar en cuenta, etc. Este tipo de error se expresa incluso en procesos licitatorios con aspectos formales muy bien realizados.

El aprendizaje que las organizaciones, instituciones y desarrolladores de soluciones deben tener de este tipo de experiencias, es que aún cuando haya mucho interés en la realización integral de un proyecto, no es conveniente hacer contrataciones integrales a no ser que haya evidencias claras para suponer que el tamaño es efectivamente estimable con una adecuada precisión, o que se haga un acuerdo razonable para el manejo de eventuales imponderables, por ejemplo, a través de una especificación de horas que pueden eventualmente imputarse en forma adicional.

El asunto es estar consciente que sólo se tiene una idea justificada del tamaño del esfuerzo requerido después de realizar la conceptualización de la solución. Antes puede haber muchos aspectos ocultos en la formulación intuida del problema y de la solución.

Otro punto importante en el ciclo de vida de un proyecto es la validación del tamaño estimado después del diseño o modelado de la solución. Efectivamente, en ese momento hay que explícitamente revisar y eventualmente alertar y/o corregir las estimaciones de tiempos de desarrollo.

Puede notarse que todo lo conversado hoy es independiente de la calidad de la formulación del proyecto a ejecutar. Incluso un proyecto bien formulado (en términos formales) puede ser insuficiente para asegurar el éxito cuando se va a contratar. Si la complejidad es real, puede no resultar conveniente (para ninguna de las partes) hacerlo en forma completa. Sólo se debe contratar hasta la implementación cuando sea muy claro lo que se quiere y el tamaño de cada etapa pueda estimarse razonablemente. En proyectos complejos lo mejor es contratar sólo el paso inicial: la conceptualización de la solución, porque sólo después de su realización es cuando realmente se puede tener una idea relativamente confiable del tamaño de la solución.