by Frank Lecarpentier | 15 Juil 2014 | Pilotage opérationnel : la méthode Agile
L’enquête du Standish Group nous apprend que les clients estiment que seulement 14% des projets en méthode classique réussissent. Sur quoi se basent-ils pour affirmer qu’un projet est une réussite ou pas ? Est-ce l’avis des intégrateurs et des cabinets de conseil ? Suffit-il que « ça tourne ! » pour être satisfait ?
À la base il faudrait que les trois acteurs d’un projet informatique que sont le client, l’intégrateur et le cabinet de conseil aient la même vision du succès du projet et donc le même objectif à atteindre. Or ce n’est pas le cas, tout simplement parce que leurs intérêts sont différents.
Les intérêts des trois acteurs d’un projet informatique
Le client souhaite un système opérationnel et pour cela, sa contrainte majeure est l’appropriation des outils et des méthodes par les utilisateurs. Il va donc être confronté au-delà du projet en lui-même à l’avis des utilisateurs, seuls juges finalement.
L’intégrateur peut vendre des licences logicielles, du matériel informatique et des prestations. Il souhaite avoir au travers du projet une référence client qu’il pourra citer sans risquer une contre-publicité. Il estime donc que le projet est un succès s’il atteint l’objectif du délai et du budget. En effet, il n’a aucun intérêt à bloquer ses consultants sur un projet qui n’en finit pas, car cela crée un conflit avec son client (négociation d’avenants au contrat) et l’empêche de conclure de nouvelles affaires. Il est doublement pénalisé par la saturation de ses consultants car la marge sur le projet diminue ainsi que son chiffre d’affaires puisqu’il ne peut s’engager sur de nouveaux clients. On notera qu’il ne juge pas de l’intérêt ou non pour le client de la solution livrée. Il se cantonne à livrer une solution logicielle conforme aux besoins exprimés en phase de conception.
Le cabinet de conseil est souvent prescrit par les intégrateurs, dont il se doit d’être indépendant, auprès de ses clients. Parfois, ce sont ses clients eux-mêmes qui le prescrivent. C’est donc un réseau d’affaires qui lui permettront de progresser. Il n’a par conséquent aucun intérêt à ce que le projet soit vécu comme un échec pour qui que ce soit. Il a donc un rôle central et déterminant dans l’atteinte du succès. La recommandation du cabinet de conseil est de replacer le projet informatique dans une dimension de projet d’entreprise quand celui-ci touche les processus. En effet dans ce cas l’organisation, les règles de gestion et les modes de travail sont impactés. C’est pourquoi la vision du succès d’un projet informatique pour le cabinet de conseil est avant tout une recherche de performance, de bénéfices clients.
La performance du projet, pour Strateg-it, est une recette complexe alliant qualitatif et quantitatif
- Atteindre un résultat (budget, délais respectés pour un périmètre projet défini)
- S’adapter (+ vite)
- Pérenniser (+ longtemps)
- Se différencier (compétitivité)
- Donner confiance (maîtrise des risques)
- Augmenter le volume de marge (retour sur investissement)
- …
Strateg-it cartographie les enjeux des projets, en déterminant le plus précisément possible les leviers de création de valeurs liés au projet. La mise en place d’un système de mesure et d’information de la création de valeur permet pendant le projet d’orienter les décisions du comité de pilotage.La méthode agile accélère les cycles de livraison. Par conséquent les utilisateurs s’approprient les outils et les méthodes dès la première itération (sprint).
Pour le client, cet aspect est donc en grande partie résolu.
Le respect du budget et des délais est également moins critique. Le principe de développement itératif est d’avancer pas à pas. On planifie finement le sprint en cours. On ne perd pas de temps pour élaborer un planning détaillé à long terme totalement hypothétique. On conservera une vision globale des délais du projet d’un point de vue macroscopique.
De même, le budget en mode agile est très souvent une ressource et non une contrainte. On contrôle la bonne utilisation du budget tout au long du projet et de ses réalisations.
La méthode agile concentrera donc les acteurs beaucoup plus sur les bénéfices client qui priorisent leurs actions.
by Frank Lecarpentier | 10 Juil 2014 | Pilotage opérationnel : la méthode Agile
Règle numéro 1 : la gouvernance agile
L’atteinte des objectifs de réussite du projet est pilotée par un comité restreint capable d’affecter des priorités et de prendre les décisions.
Règle numéro 2 : l’adaptabilité de l’équipe projet
Mettre en place une revue quotidienne de l’avancement et profiter des disponibilités et des compétences des personnes du groupe projet AGILE sans frein contractuel à cela. Ainsi, la traditionnelle dichotomie entre maîtrise d’œuvre et maîtrise d’ouvrage, qui freine considérablement les projets, est à proscrire.
Règle numéro 3 : la construction itérative orientée bénéfices client
Cette règle consiste à réagir au changement plutôt que suivre un plan. Pour satisfaire le besoin du client, la méthode agile implique celui-ci au plus tôt et offre la souplesse de revenir sur des réalisations qui, à l’épreuve du terrain, s’avèrent imparfaites.
Règle numéro 4 : l’amélioration continue de l’efficacité du projet AGILE
En fin de sprint, il est primordial de faire une revue des points positifs et négatifs. Cet échange permet d’améliorer la répartition des rôles pour le sprint suivant, l’implication du client à sa juste mesure, la qualité des livrables et la gestion du temps.
Règle numéro 5 : collaborer plutôt que négocier
Pour des raisons d’efficacité le contrat ne doit pas figer l’organisation du projet dans une posture ne permettant pas l’agilité requise.
Cette règle est possible à condition de définir contractuellement les principes de la collaboration :
1) le budget devient une ressource et n’est plus une contrainte, voire un objectif à atteindre
2) les modifications de périmètre durant le projet sont une clause contractuelle souple. Le contrat prévoit donc que l’on ne peut pas tout prévoir au début.
Règle numéro 6 : obtenir des résultats tangibles, opérationnels tout au long du projet
Cette règle implique que les bénéfices clients du projet soient au cœur de la priorisation des réalisations.
Les fournisseurs doivent s’impliquer dans cette démarche en s’engageant sur les moyens fournis. Leur engagement de résultats n’est pas jugé par le client à l’issue du projet mais bien après chaque sprint.
by Frank Lecarpentier | 5 Juil 2014 | Pilotage opérationnel : la méthode Agile
Les méthodes classiques de gestion de projet sont des phases séquentielles où il faut valider l’étape précédente pour passer à la suivante, la dernière étape étant la livraison du projet.
Ces étapes en « cascade », imposent :
1) le recueil des besoins et la conception en début de projet
2) une période de développement plus ou moins longue
3) des tests et une recette en dernière partie de projet
Quelle que soit l’expérience du chef de projet et de son équipe, cette méthode conduit très largement à des déceptions tout au moins !
Elle est basée sur l’utopie que le client est capable de décrire son besoin parfaitement du premier coup et de façon très détaillée.
La réalité est bien évidemment toute autre, avec son lot d’incertitudes :
- il est naturel d’expérimenter pour construire, d’où le besoin d’itérations, de tâtonnements
- les besoins évoluent au cours du temps, rien n’est figé
Les sociétés de services en informatique continuent de proposer des contrats au forfait suivant la méthode classique car cela de mon point de vue, leur permet de sécuriser leur développement et donc leur facturation. Il est plus aisé pour l’équipe projet de s’opposer aux demandes non prévues du client en brandissant un document contractuel validé. Cette méthode fait basculer en sa faveur le pouvoir de décision dans la mesure où le client aura payé tout au long du projet des prestations sans mise en production.
À l’inverse, la méthode agile oppose une approche itérative et incrémentale où le système livré s’enrichit progressivement pour atteindre le niveau de satisfaction requis, par priorité de gains attendus.
Le détail de comparaison des deux méthodes est largement traité sur internet. Si aujourd’hui, on s’accorde à dire que les projets en mode classique sont souvent problématiques, il n’en reste pas moins que c’est bien cette méthode qui est la plus utilisée en France. La raison à cela se trouve dans une logique de séparation des obligations contractuelles, maîtrise d’œuvre/maîtrise d’ouvrage et d’une certaine défiance des partenaires qui se traduit par des contrats très rigides.
Cycle projet Classique-Agile
Source : Standish Group 2011
