Le paradoxe du projet (gouvernemental)

Publié le 7 mars 2018 en Croissance économique et développement

Les gouvernements ont été à l'avant-garde de l'innovation en matière de gestion de projet, comme le montre cette infographie sur le jour J publiée par Étoiles et rayures. Et pourtant, il y a de nombreux échecs dans la mise en œuvre de logiciels d'entreprise dans les administrations publiques.

Échecs des projets gouvernementaux

La plupart des gouvernements exigent que les prestataires utilisent les meilleures pratiques en matière de gestion de projet, conformément à la Corpus de connaissances en matière de gestion de projet (PMBOK) de la Institut de gestion de projet. Les entreprises d'intégration de systèmes ont des pratiques strictes en matière de gestion de projet. Les gouvernements emploient souvent des chefs de projet certifiés.

Je pensais que nous avions vu le zénith des échecs des logiciels d'entreprise et des ERP du ministère américain de la défense, avec 4 projets sur 13 coûtant entre 200% et 1050% des budgets initiaux. C'était jusqu'à ce que le "Système de rémunération Phoenix" au sein du gouvernement du CanadaLe système de gestion de l'information est une version personnalisée d'Oracle PeopleSoft, mise en œuvre par IBM. Macleans explique la situation actuelle dans la vidéo ci-dessous :

Le paradoxe de la gestion de projet

Pourquoi les "meilleures pratiques" de gestion de projet fonctionnent-elles dans certains contextes et pas dans d'autres ? Pourquoi les géants de l'internet utilisent-ils des méthodologies agiles ?
La gestion de projet traditionnelle part du principe que les projets sont compliqués, mais prévisibles. La construction d'un pont, par exemple, peut être compliquée et nécessiter des compétences techniques en matière d'ingénierie. Les ingénieurs comprennent la résistance des matériaux, la manière de construire dans différentes conditions de sol et de gérer les changements de température. L'avancement du projet peut être prédit sur la base de projets similaires. Bien entendu, les progrès réels sont très faciles à observer.
Les mises en œuvre de logiciels d'entreprise sont complexes. Les projets de planification des ressources gouvernementales (PRG) sont transformationnels. Des experts en finances, en ressources humaines ou en passation de marchés publics sont nécessaires. Il en va de même pour les experts en informatique. Les utilisateurs ont besoin d'une formation spéciale. (Les utilisateurs de Bridge n'ont pas besoin d'une nouvelle formation). Plus important encore, les projets GRP transformer et automatiser les processus qui provoquent une forte résistance au changement.
Ce que l'on peut prédire des projets de logiciels d'entreprise gouvernementaux, c'est qu'ils sont très imprévisibles. Les fournisseurs se conforment souvent aux exigences documentées du gouvernement, comme IBM l'a fait avec le système de paye Phoenix. Pourtant, les systèmes ne répondent pas aux exigences initiales. Cela s'explique en partie par le fait que la gestion de projet traditionnelle au sein du gouvernement se concentre sur la documentation en tant que substitut aux exigences réelles. Et les contrats, plutôt que les besoins des utilisateurs, sont primordiaux.

Modèles de paradoxe

De nombreux clients gouvernementaux insistent pour suivre des processus en cascade très structurés. FreeBalance, l'un des rares fabricants de logiciels d'entreprise à mettre en œuvre des logiciels pour ses clients, a découvert de nombreux modèles qui entraînent des risques :

• Ancrage: Les implémentations de logiciels sont souvent ancrées dans la solution existante. Les utilisateurs veulent quelque chose de familier. Cependant, les systèmes existants sont souvent truffés d'inefficacités et d'erreurs. Les logiciels sont souvent personnalisés pour suivre des processus obsolètes. Les décideurs du projet s'ancrent dans les processus "tels quels". Des rapports inutiles sont créés. La qualité de l'information ne s'améliore souvent pas. Les personnalisations entraînent davantage d'erreurs. Bien sûr, tout cela est un peu étrange si l'on considère que le but de l'acquisition d'un nouveau système est de pallier les déficiences de l'ancien.
• Documentation: La gestion de projet traditionnelle permet de créer des pages et des pages de documentation détaillée. Chaque étape nécessite une documentation que les décideurs doivent approuver. Plus la documentation est abondante, plus il est difficile pour les décideurs de visualiser à quoi ressemblera le système final. Par exemple, la plupart des méthodes de formulation des spécifications sont très difficiles à comprendre pour la plupart des gens. Facile pour les ingénieurs en logiciel. Cela entraîne des retards. De nombreux retards.
• Contrats: Le résultat souhaité par les entreprises d'intégration de systèmes est de respecter les obligations contractuelles. Les dépassements de coûts et les modifications de calendrier ne posent pas de problème tant que le gouvernement paie. La documentation, les contrats et les modifications de contrats redéfinissent le succès en partant des objectifs initiaux du gouvernement pour aboutir au respect du contrat. C'est pourquoi les entreprises d'intégration de systèmes sont payées même lorsque les utilisateurs ne sont pas satisfaits.
• Résistance au changement: Les gens voient la construction d'un pont en cours. Il en va tout autrement pour les logiciels. De nombreux projets attendent l'approbation de la documentation complète avant de procéder à la personnalisation et à la configuration. Cela entraîne une résistance accrue au changement. Les utilisateurs, les membres de l'équipe gouvernementale chargée du projet et les décideurs sont déconnectés de la mise en œuvre. On suppose que le projet ne se déroule pas bien parce qu'il n'y a rien à montrer.
• L'équipe Bloat: Le besoin de négociateurs de contrats, de rédacteurs de documentation et d'explicateurs entraîne une augmentation de la taille des équipes. Cela peut sembler une bonne chose pour ceux qui n'ont pas lu la Mois de l'homme mythiquepublié pour la première fois dans les années 1970. Les problèmes de coordination et de communication deviennent exponentiels.

Nous avons réalisé une évaluation des projets de mise en œuvre de FreeBalance, des projets ERP dans l'administration et des bonnes pratiques agiles. Notre méthodologie a été mise à jour pour devenir A-i³+qM (accéléré, intégré, itératif, axé sur la mise en œuvre, gestion de la qualité) :

• Accéléré en éliminant le plus grand nombre possible de processus en cascade qui conduisent à des problèmes de projet. Il s'agit notamment de la documentation inutile et des plans de projet détaillés, au profit d'ateliers et d'étapes de processus courtes. La taille des équipes est réduite afin de faciliter la communication avec les clients et de réduire les frais de coordination.
• Intégré par le biais d'une méthodologie unique pour soutenir le développement et la mise en œuvre des services. Cette méthodologie est intégrée aux exigences du client par le biais des processus centrés sur le client. Cela permet d'assurer la transparence entre le personnel du client, les responsables de la mise en œuvre et l'équipe de développement. Les équipes de mise en œuvre et de développement de produits sont intégrées selon les pratiques DevOps.
• Itératif d'être réactif aux changements des clients et de la mise en œuvre en utilisant des phases. La méthodologie s'appuie sur le meilleur des méthodes éprouvées de développement de logiciels et de services "allégés", avec des ateliers, des itérations courtes, des récits d'utilisateurs, des jalons et la possibilité de montrer les progrès accomplis. Ces techniques sont étendues au-delà de l'organisation de développement aux services de mise en œuvre, ce qui permet de tirer parti des gains de productivité et de la capacité à réagir aux exigences des clients.
• Axé sur la mise en œuvre avec des modèles de bonnes pratiques et des processus de gestion de programme éprouvés. Cette méthodologie est axée sur la réussite de la mise en œuvre par le client, plutôt que sur une version logicielle qui atteint des objectifs internes ou arbitraires. La mise en œuvre et le développement du produit sont gérés par un bureau de gestion de programme.
• Qualité L'approche de FreeBalance garantit que le logiciel est publié et pris en charge conformément aux bonnes pratiques des produits commerciaux sur étagère (COTS) avec des tests d'unité, de système, de stress et de régression. La qualité est intégrée à la mise en œuvre, FreeBalance effectuant des tests basés sur les environnements des clients.

A-i³+qM reconnaît les déficiences des processus traditionnels de gestion de projet dans la mise en œuvre des PRG. Et les modèles d'échec.

• Ancrage: Les aspirations deviennent le point d'ancrage. Des ateliers sont organisés après le lancement du projet. Les équipes de projet du gouvernement sont formées au logiciel FreeBalance pour montrer ce qui pourrait être. Nos collaborateurs sont des experts en matière de gestion des finances publiques, de gestion de la fonction publique, de planification du budget de l'État, de passation de marchés, etc. Nous savons comment les finances publiques fonctionnent et devraient fonctionner. Nous nous concentrons sur la manière dont notre logiciel peut être configuré pour répondre aux problèmes qui doivent être résolus.
• Documentation: Le FreeBalance Accountability Suite est massivement configurable. Cela signifie que nous pouvons modifier rapidement les règles de gestion, le flux de travail, la langue et les données sans avoir à coder. Il s'agit d'une approche massivement sans code. Les utilisateurs peuvent voir si les exigences sont satisfaites. Il n'est pas nécessaire de produire des quantités massives de documentation.
• Contrats: Les contrats sont importants pour FreeBalance. En tant qu'entreprise sociale, nous nous efforçons de rendre les mises en œuvre financièrement viables pour les gouvernements. Et nous sommes incités à fournir ce qui est demandé, aussi vite que possible, afin d'être payés aussi vite que possible.
• Résistance au changement: La résistance au changement commence à s'estomper grâce à la démonstration des progrès réalisés dans l'amélioration des configurations logicielles. Cela ne veut pas dire que les ateliers et les démonstrations éliminent toute résistance au changement. La méthodologie est davantage axée sur la gestion du changement que sur la gestion de projet générique.
• L'équipe Bloat: Notre approche permet d'optimiser la taille des équipes. Nous rencontrons souvent des gouvernements ou des professionnels de l'intégration de systèmes qui sont familiers avec la taille des équipes pour des projets ERP ou des projets développés sur mesure. L'empreinte de la personnalisation est beaucoup plus petite pour les projets FreeBalance.