Je me demande si les experts en gestion de projet pensent qu'une bonne documentation aurait empêché Othello de tuer Desdémone. Othello, en colère, aurait-il consulté l'épais classeur qui attestait de l'amour et de la fidélité de Desdémone ? Shakespeare est allé au cœur de la tragédie : la communication informelle de Iago.
Pourtant, l'étendue de la documentation est devenue une "meilleure pratique" dans la mise en œuvre des technologies de l'information au sein de l'administration. Les approbations sont retardées parce que la documentation à l'appui n'est pas suffisamment lourde. Il me semble que de nombreux observateurs attribuent à l'absence de documentation, ou à la précision de la documentation, un grand nombre de problèmes liés aux technologies de l'information et aux systèmes d'information. Les échecs de l'ERP dans les administrations publiques. Ce billet développe une défaut de documentation décrit dans mes articles de l'année dernière : Le paradoxe des projets gouvernementaux et La fortune scandaleuse des processus en cascade dans l'administration publique. Il introduit également une approche agile de la documentation de projet, basée sur les risques.
Quelle est la raison d'être d'une documentation détaillée sur le projet ?
La documentation de projet pour la mise en œuvre de logiciels complexes a une longue tradition. Elle est souvent considérée comme une solution au problème fréquemment rencontré dans l'administration : les logiciels d'entreprise ne suivent pas les processus requis. L'idée est qu'une articulation approfondie des processus actuels ("en l'état") garantira que le logiciel qui en résultera répondra aux besoins opérationnels. De plus, une analyse approfondie de ces processus permettra d'identifier ce qui doit être modifié ("fit-gap") pour décrire pleinement une situation améliorée ("to-be").
Pour ce faire, les entreprises d'intégration de systèmes doivent souvent s'asseoir avec les experts en processus du gouvernement dans le cadre d'exercices complexes de cartographie des processus. Ces entreprises reprocheront souvent aux experts gouvernementaux de ne pas avoir pleinement défini les processus lorsqu'il s'agit d'un exercice de cartographie des processus. les mises en œuvre échouent.
Quel est le contexte de la documentation en tant que solution ?
J'ai l'impression que la cérémonie de conformité de la documentation est plus susceptible de conduire à l'échec du projet qu'à sa réussite. L'articulation détaillée du "tel quel" est à peu près aussi utile pour faire fonctionner les systèmes que les meubles cassés du rayon "tel quel" d'Ikea le sont pour l'ameublement d'une maison. Ce n'est pas pour rien que les systèmes doivent être remplacés. Les processus d'entreprise "à venir" sont donc sur le chemin critique. Une approche plus cohérente est nécessaire.
Que se passe-t-il pendant la longue phase de découverte et de documentation du processus "en l'état" ?
- La résistance au changement augmente parce que les parties prenantes et les utilisateurs ne voient aucun progrès, les forces opposées au changement ont le temps de saboter le projet
- "En l'état" entraîne "à venir" parce que la première série de documents devient le point d'ancrage conceptuel, d'autant plus que la résistance au changement augmente
- Code trop personnalisé le champ d'application, le temps et les coûts de mise à niveau futurs qui augmente parce que les parties prenantes exigent que le nouveau système se comporte comme l'ancien.
- La réalité est rarement documentée parce que les fonctionnaires décrivent rarement les solutions de contournement utilisées dans les systèmes actuels, les pratiques non conformes telles que la séparation des tâches non respectée, ou la manière dont les systèmes sont réellement utilisés, par exemple pour enregistrer des transactions qui ont déjà eu lieu
- Ce qui est artificiel devient évangile en raison des limites des systèmes précédents, les experts gouvernementaux concluent que des structures artificielles telles que la séparation des classifications budgétaires et des classifications comptables, la séparation des systèmes exécutif et ministériel, ou des méthodes étranges de gestion des engagements ou de la trésorerie sont en quelque sorte naturelles.
- L'important est caché les pages de documentation et la traçabilité entre les processus, les configurations et les personnalisations deviennent difficiles
La quantité de la documentation l'emporte souvent sur sa qualité, car la quantité fournit la première preuve viscérale que l'équipe de projet a fait quelque chose. Mais, comme l'a répondu l'un de mes professeurs d'université à la question de savoir quelle devait être la longueur d'une dissertation : "20 pages, mais si vous avez le temps, faites-en 12" : "20 pages, mais si vous avez le temps, faites-en 12.
Comment améliorer la qualité de la documentation d'un projet en réduisant la quantité de documents ?
La transparence des projets ne doit attendre personne. Mais j'ai l'impression que l'on considère qu'il ne s'est rien passé tant que cela n'a pas été documenté. Peu importe que l'arbre qui est tombé dans la forêt ait fait du bruit ou non. Dans le domaine des logiciels d'entreprise gouvernementaux, l'arbre n'est tombé que s'il a été documenté. Pourquoi les parties prenantes devraient-elles attendre si longtemps pour savoir si quelque chose s'est produit, ou est en train de se produire ?
A fondé sur le risque Il est nécessaire d'adopter une approche plus globale de la gestion de projet.
C'est là que les processus et les techniques agiles sont les plus efficaces : ils permettent de montrer l'état d'avancement des projets presque en temps réel. Les processus agiles peuvent utiliser des tableaux kanban, scrum ou scrumban pour montrer les progrès, les choses à faire, les priorités et l'attribution des tâches. L'écart entre les histoires d'utilisateurs réelles et estimées permet de prévoir l'achèvement des étapes bien mieux que les diagrammes de GANTT traditionnels. Les équipes de projet n'ont pas besoin de documenter l'état d'avancement ou de prendre des photos du tableau. Les quantités de tâches non achevées alertent les équipes de projet. Les problèmes deviennent visibles.
Ces problèmes doivent être documentés et les parties prenantes doivent être alertées afin que des décisions puissent être prises. Ce n'est pas pour rien que les régimes de veille stratégique se sont concentrés sur les rapports d'exception à l'intention des principales parties prenantes. Il est grand temps d'intégrer les rapports d'exception dans la documentation. Et de disposer d'un système d'alerte précoce. Les parties prenantes comprendront que l'alerte par courrier électronique est essentielle et qu'il ne s'agit pas simplement d'un autre ensemble de documents mis à jour dans le cadre d'un projet.
Comment la documentation d'un projet peut-elle varier en fonction du contexte ?
La mentalité de documentation dans les projets gouvernementaux est rarement basée sur le risque. Il est de moins en moins rentable de tout documenter. Pourtant, c'est le cas dans de nombreux contrats publics où l'approbation finale est subordonnée à des tests complets d'acceptation par l'utilisateur qui incluent la documentation du projet. Cela rend les procédures de test encore plus complexes. Nous avons mis au point un méthode différente que nous recommandons à tout gouvernement cherchant à mettre en œuvre des logiciels commerciaux, y compris ceux de FreeBalance :
- Ancrer le projet différemmentLes projets de formation : commencer par former le personnel du projet gouvernemental au nouveau logiciel COTS en montrant comment les objectifs "à être" du gouvernement peuvent être atteints et comment le logiciel COTS répond aux exigences d'une manière différente de celle conçue dans le projet précédent.
- Séparer la configuration de la personnalisationles changements de configuration en atelier avec le personnel du projet gouvernemental et les utilisateurs finaux, avec approbation de la configuration lorsque cela est démontré, tandis que la personnalisation du code suit des processus agiles
- Personnalisation basée sur le risque et la valeuridentifier et documenter les risques coûts-avantages de toute initiative de personnalisation afin d'améliorer la prise de décision concernant le projet
- Documentation agileles prototypes et les story-boards sont utilisés et documentés pour obtenir l'approbation de la personnalisation, plutôt que de s'en remettre à la documentation traditionnelle
- Tests agilesles tests de configuration tout au long de la mise en œuvre réduisent la charge des tests d'acceptation finaux qui seront davantage axés sur le risque : la personnalisation, où la qualité de la documentation est d'une importance cruciale.
Comment cette approche agile résout-elle la tragédie de la documentation de projet ?
- La résistance au changement diminue parce que les parties prenantes et les utilisateurs voient les progrès de la configuration et que les ateliers démontrent la volonté de prendre en compte l'avis des utilisateurs
- Le projet est piloté par le "futur". parce que les itérations se concentrent sur les objectifs du gouvernement
- Personnalisation contenue parce que toutes les fonctionnalités du logiciel COTS sont explorées par rapport aux objectifs "à atteindre", et la personnalisation comme exception est entièrement documenté
- La réalité est intégrée parce que le personnel gouvernemental décrit les pratiques au cours d'ateliers de configuration et que les experts des fournisseurs (ce qui suppose que le fournisseur comprend le domaine) expliquent les raisons des changements de pratiques
- Ce qui est artificiel devient rationnel parce que le logiciel COTS n'impose pas ces contraintes, en supposant que le logiciel a été effectivement conçu
- Ce qui est important est visible moins de pages de documentation avec une traçabilité efficace et l'utilisation de tableaux agiles pour fournir des rapports sur l'état d'avancement des travaux.