10 razones por las que falla un proyecto de BI

¿A alguien se le ocurre no mirar el plano de una vivienda antes de que comiencen a construirla? ¿Un ingeniero de caminos aceptaría el cambio de un puente, cuando ya están terminando las obras? Si tienes claro que la respuesta es no, es hora de plantearse por qué esto sí ocurre a menudo con los proyectos software.

Un fallo en la fase inicial de todo proyecto Business Intelligence (BI), la fase de captura de requisitos, puede condicionar el éxito del proyecto y la futura utilidad del producto. Estas son las 10 razones por las que un proyecto BI puede empezar mal y cómo evitarlo:

¿Análisis? A mí no me pongas de eso

El primer error grave que puede surgir es que en la planificación no se considere o se infravalore el tiempo a invertir en esta fase. Todo proyecto de BI tiene que asumir que un porcentaje importante del proyecto debe estar asignado a la captura de requisitos. No es exagerado decir que la captura de requisitos y el análisis pueden conllevar un 30% del esfuerzo del proyecto.

¡Contad! Tenemos todo el tiempo del mundo

En la mayoría de proyectos de Business Intelligence, cuando se comienza la fase de requisitos, el presupuesto ya está cerrado, lo que indica que no puede crecer indefinidamente. Muchos proyectos no finalizan bien porque crece desmesuradamente el alcance de lo inicialmente acordado.

Hay algo que es obvio, una buena medida del tamaño del proyecto va a ser el tiempo que nos cueste contarlo. El número de sesiones de captura de requisitos debería venir limitado en el alcance del proyecto: “vamos a desarrollarte el proyecto de BI que seas capaz de contarme adecuadamente en 7 sesiones de captura de requisitos”. Desde luego, este mensaje hará que las sesiones sean más productivas.

Con las manos en los bolsillos

un error habitual es que las sesiones no se preparen adecuadamente y que, en el momento de la reunión, no se tenga muy claro lo que se necesita. Las reuniones de requisitos de un proyecto Business Intelligence NO son el punto adecuado para redefinir un modelo de negocio. Si no tenemos claro nuestro propio modelo de negocio, debemos aclararlo internamente y acudir a la captura de requisitos con las ideas claras.

Reuniones multitudinarias

Las reuniones donde muchos usuarios discuten por el alcance final del proyecto suelen confundir al analista y hacen que la sesión de captura de requisitos se alargue más de lo necesario. Lo idóneo es escoger al mejor interlocutor para que lleve la idea del proyecto, previamente consensuada con el resto de usuarios/departamentos de la organización.

Rienda suelta

Muchas sesiones acaban sin ser productivas porque no se dirigen adecuadamente. Dentro de un ambiente cordial, un participante debe adquirir el rol de “moderador” y redireccionar la reunión hacia los objetivos cuando alguien se desvíe innecesariamente. Un orden del día puede ayudar mucho a concentrarnos en los puntos a tratar.

Las curiosidades

A menudo se pierde mucho tiempo valioso contando las curiosidades, las excepciones de la lógica de negocio. Lo anecdótico, lo que nunca pasa pero una vez pasó en el 2003, no suele ser importante. Es preferible invertir tiempo en contar los problemas que con más probabilidad va a tener que resolver la solución de BI. No significa que lo específico no tenga que ser tenido nunca en cuenta, pero se debe resolver cuando nos hayamos asegurado de que el sistema aporta resultados a nuestros problemas más habituales. La regla debe ser: contar las cosas de las más habituales a las más específicas, hasta donde el contrato permita (recordad el segundo de los consejos).

Sesión continua

El analista no puede asistir a una reunión de requisitos sin haber consolidado lo hablado en la anterior. Se debe buscar una correcta alternancia entre las horas de la propia sesión (más de 4 horas no suelen ser productivas) y el trabajo de oficina donde pongamos en orden las notas, las transformemos en conceptos (entidades, características, procesos) y los documentemos. Esta documentación inicial tiene que sentar las bases sobre las que hablar en las siguientes sesiones.

El teléfono roto

Es un grave error dar por hecho que todo lo que se ha hablado en una reunión ha sido bien expresado por el usuario y ha sido bien comprendido por el analista. La única forma de verificar esto por ambas partes son los documentos, la palabra escrita. Aunque sea una labor pesada, es muy importante que los usuarios lean los resultados de las sesiones anteriores plasmadas en un documento, una especie de acta, para verificar que ambas partes entienden lo mismo.

Lo entenderé cuando vea la aplicación

Uno de los mayores errores que se puede cometer en un proyecto es obviar el análisis y solicitar los cambios cuando la aplicación está en construcción. El documento de análisis debe tener un carácter contractual y es antes de la firma de este documento cuando se deben solicitar todos los cambios y resolver todas las posibles indefiniciones. Sobre el papel es más fácil cambiar el diseño o la lógica de una aplicación BI, sobre un proyecto empezado no es tan sencillo. Aunque a veces resulte una medida severa, no se debería empezar un desarrollo hasta que el análisis esté aprobado por todas las partes.

Quiero hacer un cambio…es que en el análisis no me di cuenta

Los cambios se deben minimizar una vez haya comenzado la construcción del sistema BI. Cada cambio con el proyecto en construcción es una incertidumbre añadida y tiende a desequilibrar el diseño global establecido. Los cambios en fases tardías tienden a acabar siendo parches sobre el diseño original.

Recordad que la inversión en la fase de análisis tiene que dar como resultado un documento que especifique de forma clara, concisa y sin ambigüedades el futuro proyecto, para que usuarios y equipo de desarrollo entiendan lo mismo y sean capaces de hablar en los mismos términos.

Artículo redactado por Pablo Gallardo