Photo par Gabriel Sollmann sur Unsplash

Conscient ou inconscient ?

En fait, il n'y a rien de pire pour les parties prenantes telles que les donneurs d'ordre ou les clients que de ne pas savoir ce qui se passe dans le projet, quel est son état actuel et comment il va évoluer, ou que de nombreuses belles paroles soient prononcées sans qu'il soit possible de vérifier les résultats obtenus.

Je ne vois que rarement des projets qui sont délibérément tenus secrets pendant un certain temps. Cela peut être le cas pour des projets de restructuration, où différents scénarios sont envisagés et où le secret doit permettre d'éviter temporairement une confusion et des rumeurs inutiles dans l'organisation. Mais attention, on ne peut pas ne pas communiquer. Là aussi, un minimum de transparence est utile. Dans de nombreux cas, les rumeurs sont plus nombreuses lorsque quelque chose est secret.

De plus, il existe des projets où la transparence est volontairement maintenue à un niveau bas, afin d'éviter un contrôle et une direction prétendument "extérieurs". Personnellement, je ne pense pas que ce soit une bonne idée. En effet, les projets n'ont pas de but en soi, mais sont réalisés pour des mandants et des clients avec lesquels une communication digne de confiance doit être pratiquée. Et la transparence crée la confiance ! Dans la plupart des projets, le manque de transparence n'est pas un acte délibéré, mais une conséquence de la complexité et de l'agitation du projet, qui témoigne souvent d'une certaine surcharge en temps ou en compétences. La transparence ne fait pas totalement défaut, mais elle est généralement insuffisante.

Comment créer de la transparence ?

Le problème du manque ou de l'absence de transparence est la complexité d'un projet. Tout est lié d'une manière ou d'une autre. Par exemple, si une décision nécessaire n'est pas prise dans un certain délai par le comité de pilotage du projet, cela entraîne des retards dans le projet. Les retards ont des répercussions sur la disponibilité des collaborateurs ; le cas échéant, de nouveaux collaborateurs doivent remplacer les anciens, ce qui entraîne un surcroît de travail. Si aucun remplaçant n'est disponible en interne, il faut faire appel à des spécialistes externes, ce qui entraîne un surcroît de travail pour l'achat et l'intégration, et donc des coûts supplémentaires pour le projet. Les dépendances sont très importantes dans un projet et peuvent conduire à une multitude de problèmes.

Je crée de la transparence principalement en utilisant des structures (également appelées structure de projet ou Work Breakdown Structures WBS). Il me semble que les structures sont passées à l'arrière-plan, surtout dans le monde agile, bien que Scrum, SAFe et autres utilisent également des structures claires. Les structures réduisent la complexité et se concentrent sur un sujet plus petit. C'est pourquoi les livres dans les bibliothèques, par exemple, ne sont pas seulement classés par ordre alphabétique, mais aussi par thèmes. Les structures peuvent être représentées de manière hiérarchique ou sous forme de matrice et de réseaux, et complétées par des regroupements et des relations. Dans ce contexte, les structures ne sont pas une division ou un éclatement du projet, ce qui n'est pas possible en raison de l'interdépendance et des dépendances internes au projet mentionnées ci-dessus. Les structures sont des points de vue et des affectations sur le projet.

Je recommande de ne pas réinventer la roue, mais de recourir à des références éprouvées pour les structures. Je fais la distinction entre la gestion de projet (PM) et le développement de produits. Si rien d'autre n'est spécifié, j'utilise personnellement pour le premier la méthodologie PM PMI PMBOK-Guide. Pendant de nombreuses années, j'ai utilisé les dix "Knowledge Areas" comme structure principale. Avec la dernière édition du guide PMBOK, la septième, ces domaines de connaissances ont été transformés en 2021 en domaines de performance de projet (Project Performance Domains), ce qui me convient encore mieux. Il s'agit de

• Groupes d'intérêt (stakeholders)
• Équipe
• Approche de développement et cycle de vie (Development Approach and Life Cycle)
• Planification (Planning)
• Travail de projet (Project Work)
• Livraison (Delivery)
• Mesure (Measurement)
• Incertitudes (Uncertainty)

Mais les anciennes Knowledge Areas continuent à avoir leur place. Bien entendu, les structures d'autres méthodes de gestion de projets peuvent également être utilisées. Outre le fait qu'une méthode a fait ses preuves, elle me donne l'assurance qu'avec cette structure, j'obtiendrai dans le projet aussi bien un équilibre thématique qu'une exhaustivité. Avec une méthode connue de tous, je peux partir du principe que les groupes d'intérêt comprennent et acceptent également les structures.

Dans le processus de développement de produits, j'utilise toujours en premier lieu la structure des résultats (structure du produit) dans l'esprit du SEL, puis j'intègre les étapes/tâches du processus. J'obtiens ainsi une approche axée sur les résultats, où l'on définit d'abord ce qui doit être atteint, puis comment on peut l'atteindre. Malheureusement, il y a encore des projets qui sont structurés à l'inverse selon les phases de développement du projet (p. ex. design, build, test), ce qui pose toujours des problèmes.

En principe, la structure appliquée ne doit pas elle-même être trop compliquée, dans l'esprit d'Albert Einstein : "Aussi simple que possible, mais pas plus simple".

Comment appliquer ces structures ?

Une fois qu'une structure adaptée au projet a été initialement trouvée et mise en place, le projet est piloté par cette structure. Seule l'utilisation cohérente et répétée de la structure dans le projet permet d'obtenir la transparence et l'habitude souhaitées et d'instaurer la confiance. J'observe souvent que des structures ont certes été mises en place, mais qu'elles se diluent au cours du projet, que de nouvelles sont ajoutées et que d'autres sont supprimées. Cela conduit à un mélange de différentes structures, ce qui nuit à la transparence. J'utilise autant que possible la structure (principale) choisie dans l'ensemble du projet. Chaque élément de structure comprend de nombreuses sous-structures qui peuvent ensuite être adaptées aux besoins spécifiques. Je planifie et dirige donc le projet selon cette structure et je communique dans le cadre de cette structure. Un rapport mensuel sur l'état du projet, par exemple, est conçu exactement selon cette structure. Le cockpit du projet est également structuré de la même manière.

Il est recommandé de vérifier après la mise en œuvre, puis de temps en temps, si les structures sont vraiment comprises et acceptées et si elles sont toujours adaptées au projet, qui peut aussi évoluer. Dans ce cas, elles devraient être adaptées au sein de la méthodologie. Mais cela ne devrait pas être trop fréquent ni trop important, car les structures sont un élément fondamental du projet, où les changements peuvent avoir de grandes conséquences et entraîner des confusions.

Cela représente tout de même beaucoup de travail et d'efforts pour le chef de projet, ce qui n'est malheureusement pas toujours perçu comme tel de l'extérieur. Cela ne vient pas tout seul, et doit être appliqué et entretenu activement. Mais c'est un très bon investissement, qui en vaut la peine.

Les structures de projet vont toujours de pair avec les données de projet. Toutes les données du projet doivent s'aligner sur la structure, c'est-à-dire être affectées aux éléments de la structure. Un outil de gestion de projet avec une base de données centrale est très utile à cet égard. Cela permet d'accorder à tout moment au projet différentes vues sur l'ensemble du projet et sur toutes les données du projet. En cas d'utilisation de documents individuels (par exemple pour les coûts, le planning, les ressources), la génération de vues globales est incomparablement plus compliquée, inefficace et parfois même impossible. Inversement, un tel outil de gestion de projets est beaucoup moins utile si une structure appropriée n'est pas définie dans le projet.

Conclusion

Malgré les structures, il y a et il y aura toujours des problèmes dans le projet. Toutefois, la transparence créée par les structures permet d'identifier les problèmes à un stade précoce, d'en déterminer les causes et donc de les traiter et de les résoudre durablement. Comme nous l'avons mentionné, la transparence dans un projet crée la confiance auprès des groupes d'intérêt - dans et autour du projet. La confiance garantit une collaboration bien meilleure et plus constructive, ce qui procure également plus de plaisir à tous les participants et conduit finalement à de meilleurs résultats.