Méthodes agiles et projets BI

Tout le monde est maintenant à peu près convaincu que les anciennes méthodes de gestion de projet (cycle traditionnel - analyse, conception, développement, tests, livraisons - le tout durant entre 6 mois et 2 ans) ne sont plus adaptées aux contraintes économiques des entreprises et sont sources de dépassement de budget et de délai, et surtout de conflits.
La bonne manière de travailler semble être de :

• prévoir une liste de fonctionnalités (backlog) et d'estimer le budget correspondant
• définir des sous ensembles de ces fonctionnalités, avec un cycle de livraisons fréquent (qq semaines)
  => l'utilisateur peut concrétiser son besoin et réagir rapidement
  => on décide de modifier certaines fonctionnalités, d'en ajouter ou d'en retrancher
  => on ré-estime le budget et le planning
  si il dépasse ce qui était prévu (ce qui est majoritairement le cas), on a 2 choix : 
• conserver le budget initial => il faut enlever d'autres fonctionnalités ou les retarder (les placer sur le budget de l'année suivante)
• accroître le budget (c'est souvent la première solution qui est choisie)
• industrialiser les développements et les livraisons pour que les livraisons ne soient pas chronophages mais de qualité

Ces méthodes commencent à se répandre de plus en plus dans les services informatiques des entreprises, les sociétés de services, et de manière moins visible chez les éditeurs (bien que les nouvelles applications web aient tendance à suivre ce rythme élevé de livraisons fréquentes, initié par Google depuis qq années).

Il me semble que les projets concernant le décisionnel, qui souffrent d'une réputation de projets lourds et coûteux, auraient tout intérêt à rapidement adopter ces méthodes, d'autant que les nouveau outils BI me semblent plus adaptés (cf. l'article sur ce sujet : Les nouveaux outils de pilotage de l'entreprise).

De la même manière que pour les projets de développement classiques, la rigueur dans la conception et le développement, l'outillage et l'industrialisation des développements et des livraisons sont les conditions du succès.

Prenons un projet "classique" décisionnel :

• des besoins identifiés avec les utilisateurs : comment les valider si ce n'est en leur mettant sous les yeux un tableau de bord affichant les indicateurs
  => identifier le domaine fonctionnel prioritaire (en général celui qui va faire gagner rapidement de l'argent à l'entreprise) et dans ce domaine les indicateurs critiques (idem)
  => construire le modèle de données
  => identifier les données source
  => construire l'alimentation
  => construire le tableau de bord, les rapports
  => les montrer aux utilisateurs
• Réactions, retours des utilisateurs : 2 cas :
• nouveaux indicateurs, nouveaux axes d'analyse
  => rebelote : analyse des données sources, modif du schéma du datawarehouse, modif des alimentations, modif des tableaux de bord
• détail supplémentaire dans les tableaux ou ajout de donnée déjà présente dans les tables du datawarehouse : la modif peut même se faire "en live" avec l'utilisateur

Tout ceci, bien outillé, normé, industrialisé, peut se faire rapidement, je dirais même plus rapidement qu'un projet classique car 

• les modèles de données décisionnels sont plus simples que les modèles des applis transactionnelles
• le "code source" est structuré par les outils et on peut en général rapidement identifier les impacts d'une modification   

Il est évident que pour livrer le plus rapidement possible quelque chose de concret aux utilisateurs, il est préférable de s'appuyer sur des modèles déjà conçus, voire de s'appuyer sur des tableaux de bord déjà développés pour la phase d'identification des besoins des utilisateurs, sur lesquels ils vont pouvoir concrétiser leurs idées et réagir.

Cela fait aussi l'objet d'un article récent sur le blog : Un outil décisionnel disponible en quelques semaines ?
Et c'est le principe de base du pack Performance, dédié aux métiers de la supply chain : http://www.6it.fr/static9/pack-performance.htm