Proyectos de alto riesgo

Uno de los problemas más frecuentes vinculados a fracasos en proyectos TIC, particularmente dentro del Estado, es cuando estos se abordan utilizando algún esquema de externalización; es un mal diseño del proyecto y fundamentalmente de los procesos licitatorios que lo acompañan.

Es muy frecuente en esos casos encontrarse con bases y términos de referencia mal diseñados, en los cuales los problemas más habituales son:

• Objetivos y alcances poco claros, esta área de las bases es fundamental y la que entrega el marco referencial de lo requerido, su ámbito y áreas que se espera cubra el proyecto.

• Producto y entregables no especificados del todo. Cuando existen productos claros el proveedor puede dimensionar esfuerzo y validar su oferta, esto es particularmente cierto en el caso de servicios (implantaciones, consultorías y asesorías, desarrollos de software, etc.). Es importante que el comprador no se entusiasme pidiendo más de lo razonable por el presupuesto asignado.

• Tiempos, con mucha frecuencia se observan bases en las cuales se expresa la urgencia del comprador de tener terminado el proyecto pero se olvida que el desarrollo de un proyecto TIC como cualquier otro requiere de sus tiempos. Creo que un dicho que aplica en estos casos es nueve mujeres no gestan una guagua en un mes y el problema no se resuelven poniendo equipos de trabajo más grandes como lo esperan algunos compradores.

• Presupuestos que no dicen relación con los productos/servicios requeridos, ya sea por desconocimiento o bien por no realizar un estudio acabado de costos.

Como una manera de graficar esto, quiero mencionar sólo dos ejemplos de procesos licitatorios recientes en los cuales se produce algunas de las situaciones señaladas anteriormente.

Ejemplo Nº 1: Evaluación diagnóstica del soporte tecnológico para la gestión de recursos humanos en Servicios Públicos.

Presupuesto asignado: $ 30.000.000 (aproximadamente 1.634 UF o 55.587 dólares)

Realizando una estimación rápida de recursos sobre la base de los objetivos y alcances y considerando unos 180 servicios públicos potenciales para la evalución, los recursos destinados para la referida evaluación es de 9 UF’s por servicio, si consideramos el siguiente esfuerzo por actividad a realizar

(a) Preparación de entrevista/pauta = 30 minutos
(b) Realización de entrevista de levantamiento = 2 horas
(c) Evaluación de antecedentes = 2 horas
(d) Informe final = 2 horas

Lo que corresponde a 6.5 horas-hombre por institución, lo que algunos de ustedes me dirán es un número ridículamente bajo, el valor de la hora-hombre estimada por el servicio público para realizar el diagnóstico es de 1.38 UF/hora-hombre, esto sin considerar ningún otro costo, recordemos que muchos de los servicios públicos están en regiones por lo que al valor anteriomente estimado hay que restarle costos de traslado y estadía.

Ejemplo Nº 2: Desarrollo de un sistema en ambiente web con múltiples usuarios de gran transaccionalidad, los objetivos específicos son: “Diseñar e implementar un sistema de información basado en servicios de Internet, que permita rescatar, almacenar y gestionar los documentos electrónicos, de forma tal que permita al Servicio Público cumplir con su rol” (se han omitido los nombre de instituciones y aquellos detalles que permitan identificarla pero la idea central del objetivo se mantiene)

Presupuesto asignado: $ 12.000.000 (aproximadamente 654 UF o 22.195 dólares)
Tiempo: 16 semanas

Considerando los valores de obtenido en una reciente licitación de desarrollo de software realizada por la Dirección de Compras Públicas, los valores jornada de un equipo de desarrollo estándar compuesto por (0.3 jefe de proyecto, 1 analista, 3 programadores y 1 especialista en QA) los valores obtenidos es de 11 UF/día por equipo de desarrollo, lo anterior significa que el sistema en cuestión para desarrollarse debiera hacerse en 59,4 jornadas.

Si el proyecto tiene asignada 16 semanas esto equivale a 80 jornadas (16*5) el presupuesto es insuficiente.

Por otro lado las bases son absolutamente elementales para describir el problema y claramente llevarán a confusión a quien quiera analizar el requerimiento.

Lo peor de todo es que muy probablemente para ambos casos existirán proveedores que se presenten y finalmente lo que tendremos son dos proyectos en que expectativas y resultados no coincidirán, presentando un potencial de fracaso al menos utilizando la definición de proyecto exitoso (cumplimiento de plazos, recursos y los productos requeridos originalmente) y la probabilidad de tener al final del camino dos proyectos fracasados es alta

Es de esperar que algún día aprendamos la lección!!