Pendant des décennies, la plupart des chefs de projet étaient responsables de projets traditionnels avec une analyse de rentabilité et un énoncé des travaux bien définis.
On enseignait aux chefs de projet en classe de ne pas commencer les phases de planification et d’exécution d’un projet tant que les exigences n’étaient pas comprises et acceptées par toutes les parties, y compris les parties prenantes.
On pensait qu’avoir des exigences bien définies minimisait le besoin d’une gestion des risques détaillée et tendait à minimiser la complexité du projet. Les entreprises ont créé une méthodologie unique pour gérer les projets. Il existait des formulaires, des directives, des modèles et des listes de contrôle pour les activités de gestion des risques, mais ils étaient tous basés sur l’utilisation dans des projets traditionnels avec des exigences bien définies.
La performance de la gestion de projet était mesurée par « l’obéissance » à la méthodologie unique, même si le projet n’était pas un succès partiel ou complet. L’excellence en gestion de projet était définie par l’utilisation continue de quatre composantes, à savoir :
Lire Aussi: Courte vidéo sur l'anticipation et la demande effective
- La méthodologie unique
- Autres actifs de processus organisationnels soutenant la méthodologie
- Lancement du projet à l’aide d’un énoncé des travaux bien défini
- Hypothèses, contraintes et attentes réalistes
La capacité à gérer efficacement les risques, l’incertitude et la complexité n’était généralement pas l’une des caractéristiques critiques car l’excellence était mesurée uniquement par rapport à la performance de projets traditionnels qui étaient évidents.
La plupart des dirigeants étaient réticents à faire confiance aux chefs de projet et craignaient que les chefs de projet ne prennent des décisions qui étaient réservées aux niveaux supérieurs de la direction.
Par conséquent, l’utilisation d’une méthodologie unique pour tous les projets traditionnels minimisait quelque peu les risques et fournissait à la haute direction un commandement et un contrôle efficaces depuis le dernier étage du bâtiment.
Lire Aussi: Organizational Structure and Design: Theoretical Perspectives
Les chefs de projet étaient autorisés à prendre certaines décisions liées à la complexité du risque technique, mais la plupart des décisions ayant un impact sur la complexité du risque commercial étaient prises par les commanditaires du projet.
Les projets stratégiques ou complexes, et comportant beaucoup de risques, sont devenus de plus en plus importants pour les dirigeants au tournant du siècle. Les projets stratégiques, en particulier ceux impliquant l’innovation, étaient une nécessité pour pérenniser l’entreprise.
Malheureusement, ces projets étaient le plus souvent confiés aux responsables fonctionnels, car la direction générale leur faisait davantage confiance qu’aux chefs de projet. Les responsables fonctionnels avaient la liberté d’utiliser les outils et techniques qu’ils souhaitaient pour gérer la complexité de leurs projets.
Lire Aussi: Ralph Stacey's Complexity Theory and Organizational Change
Aucune restriction n’était imposée aux responsables fonctionnels et, de ce fait, il n’existait souvent aucune directive ni norme sur la manière de gérer les complexités des projets non traditionnels tels que les projets stratégiques ou d’innovation.
Au fur et à mesure que la gestion de projet évoluait, des publications ont commencé à apparaître, discutant des meilleures pratiques et des leçons tirées de l’utilisation efficace de la gestion de projet. Les dirigeants ont commencé à se demander si les chefs de projet étaient mieux adaptés pour gérer des projets non traditionnels et stratégiques que les responsables fonctionnels.
Plusieurs raisons expliquent le recours aux chefs de projet plutôt qu’aux responsables fonctionnels.
- Premièrement, les responsables fonctionnels recevaient des primes de fin d’année en fonction des performances de leur groupe fonctionnel. En tant que tel, ils affectaient leurs employés les plus qualifiés aux projets à court terme qui avaient un impact sur leurs primes, ce qui pouvait avoir un impact défavorable sur les projets stratégiques qui ne disposaient désormais plus des ressources avec les compétences requises.
- Deuxièmement, les responsables fonctionnels dissimulaient certaines des complexités de leurs projets de peur que cela n’affecte leurs primes ou, pire encore, n’incite les dirigeants à microgérer leurs projets.
Au tournant du siècle, les projets non traditionnels et stratégiques, en raison de leur importance croissante, sont devenus la responsabilité des chefs de projet. Ce qui est devenu évident presque immédiatement, c’est que l’approche unique ne pouvait pas être utilisée sur la plupart des projets non traditionnels. Certaines des différences critiques entre ces deux types de projets sont présentées dans le tableau 1.
Des articles ont commencé à paraître, affirmant que plusieurs méthodologies ou cadres, tels qu’une approche Agile ou Scrum, devraient être utilisés et pourraient être adaptés aux besoins de chaque projet plutôt que de forcer le projet à utiliser une approche unique qui pourrait être inappropriée.
Les entreprises ont compris les changements qui se produisaient et ont vite réalisé que tous les projets pouvaient avoir différents niveaux de complexité et que des pratiques efficaces de gestion des risques pouvaient devenir le domaine de connaissances le plus important pour les futurs chefs de projet.
Les chefs de projet, ayant désormais une compréhension beaucoup plus approfondie et plus claire de la situation, pouvaient prendre des décisions plus efficaces. Davantage de confiance était accordée aux chefs de projet, et ils ne pouvaient pas se fier uniquement aux commanditaires du projet ou aux comités de gouvernance du projet pour analyser la complexité de chaque situation et prendre les décisions appropriées. Comprendre les risques, l’incertitude et la complexité était devenu un atout intellectuel essentiel pour les chefs de projet, ainsi que l’utilisation de méthodologies flexibles.
TABLEAU 1. DIFFÉRENCES ENTRE LES PROJETS TRADITIONNELS ET NON TRADITIONNELS
Facteur Projet traditionnel Projet non traditionnel ou stratégique Analyse de rentabilité Généralement bien définie Peut ne pas exister au début du projet et peut être sujette à modification tout au long du projet Énoncé des travaux Généralement bien défini Peut ne pas exister ; peut n’avoir que des objectifs stratégiques avec lesquels travailler. L’énoncé des travaux peut changer tout au long du projet WBS Peut être développé pour l’ensemble du projet Peut n’être connu que pour le travail nécessaire pour les prochaines semaines et sujet à modification EVMS Plutôt utile Peut avoir une utilisation limitée en fonction du nombre d’inconnues et de l’introduction de contraintes concurrentes Spécifications Généralement connues Peuvent ne pas exister Calendrier Connu Inconnu et possiblement sujet à des changements continus Coût Connu Inconnu au départ et peut être sujet à des changements continus Risques Généralement connus et peuvent être quantifiés Peuvent être inconnus et sujets à l’apparition de nouveaux risques sans avertissement Complexité Connue avec un certain degré de confiance Peut ne pas être connue et est sujette à modification