Trop de projets, trop peu de temps : le fardeau des entreprises modernes

Dans les arcanes des entreprises modernes, une réalité insidieuse prend racine : la surabondance des projets. Prises dans l'accélération du monde et en recherche d'innovation concurrentielle, les entreprises se lancent dans une multitude de projets et cette frénésie d'activité semble être devenue le lot quotidien de nombreux collaborateurs. Loin d'être anecdotique, cette situation a des conséquences néfastes, menaçant le bien-être et la performance des individus, des collectifs et des organisations dans leur ensemble.

Les symptômes habituels d'un problème latent

En tant que lecteur, peut-être vous reconnaissez-vous dans ce tableau et ces symptômes vous paraissent malheureusement familiers :

• un sentiment d'urgence permanent et des changements de priorité perturbants et douloureux
• une difficulté à faire avancer ses projets et l'allongement des Time to Market
• une complexité croissante du SI, avec des couplages en cascade et de la dette technique, rendant chaque évolution plus difficile.
• une non-qualité qui augmente : on met dans la main des utilisateurs des choses souvent mal finies.
• les solutions IT proposées ne répondent pas forcément aux vrais problématiques des utilisateurs, insatisfaits.
• des relations tendues entre équipes, exacerbées par des priorités divergentes.
• des efforts de synchronisation énormes pour maintenir une cohérence fragile.
• des individus constamment submergés et des équipes fatiguées

Ces symptômes ne sont pas anodins. Ils ont des répercussions à plusieurs niveaux :

• Sur le plan individuel, ils affectent le bien-être et la santé mentale des employés, pouvant les conduire jusqu’au burn-out.
• Au niveau collectif, ils compromettent la cohésion d'équipe et la collaboration et entretiennent le fossé entre métier et IT.
• Sur le plan organisationnel, ils entraînent une inefficacité opérationnelle et une perte de compétitivité.

Mais quel lien avec la surabondance des projets me direz-vous ? Prenons l'exemple d'un projet X dans une enseigne d'e-commerce. Initié en grande pompe par le Comité de Direction, une équipe pluridisciplinaire autonome motivée est constituée motivée. Mais le projet peine à avancer : les développements back-end, notamment liés à la comptabilité, stagnent. En effet, un membre du CoDir souhaitant voir avancer un sujet Y, réquisitionne en marge des processus officiels un des équipiers back pour avancer sur son sujet. Résultat : l'équipier jongle entre deux projets, sous l'eau, incapable de contribuer efficacement au projet X. Celui-ci prend du retard et les relations dans l'équipe se tendent. Cet exemple simple illustre l'absence d'alignement et de congruence multi-projets et ses conséquences individuelles et collectives. C'est comme si nous cherchions à jongler non pas seulement avec 3 ou 4 balles mais avec une vingtaine. Enm plus des balles que nous avons déjà, nous lançons d'autres balles pour être sûr de les voir atterrir dans un futur plus ou moins lointain. Et nous ne jonglons pas seuls, mais devons faire passer les balles à d'autres équipes… qui ont déjà leurs propres balles à gérer. Ainsi, en plus de nous concentrer sur les balles au-dessus de nous, nous devons réceptionner d'autres balles, voire ramasser celles qui finissent par terre. A force de multiplier le nombre de balles en l'air, l'exercice simple et efficace se transforme en numéro d'équilibriste débordé.

Les causes profondes de cette surcharge : pourquoi tant de projets ?

La surabondance des projets découle de plusieurs facteurs. Sur le plan individuel, nous avons chacun une aspiration à bien faire, souvent exacerbée par la culture de la performance et du "toujours plus" : socialement et culturellement, le progrès et les résultats croissants sont glorifiés. Au niveau projet, chaque initiative semble justifiée localement, mais dans l'ensemble, cette accumulation devient contre-productive. Il est facile de démarrer de nouveaux sujets alors qu'il est difficile de dire non et de les reporter, perpétuant ainsi le cycle infernal. En tant que consultant, combien de fois ai-je entendu des clients reconnaître : "On ne sait pas dire non !". Vous avez aussi cette impression dans votre entreprise ? Ceci découle notamment d'une pression du court terme : les résultats trimestriels priment souvent sur les impacts à plus long terme. Et aussi d'une certaine peur du vide : les managers ont peur de ne pas occuper suffisamment leurs équipes. C’est aussi caractéristique d'une relation client/fournisseur entre techs et métiers, plutôt qu’une relation de partenariat. Notre expérience nous montre que ces barrières sont à la fois courantes, bien ancrées, mais pas insurmontables.

Une prise de conscience et un changement de perspective nécessaires

Il est impératif de prendre conscience de la problématique et d'amorcer plusieurs changements :

• déjà commencer par reconnaître le coût et l'inefficacité de la surcharge de travail et chercher à rendre visible la parallélisation et ses impacts. Combien de "balles en l'air" avons-nous simultanément ? Quels projets tournent au ralenti ? Les personnes critiques sont-elles effectivement disponibles à 100%, notamment sur les projets stratégiques ? Ca parait évident, mais on observe que c'est en fait rarement le cas.
• S'engager dans un premier temps à "vider la baignoire" et à ne pas lancer de nouveaux projets (ou en tout cas le minimiser) tant que ceux en cours ne sont pas achevés. Quels sont les projets qui peuvent être rapidement terminés et ainsi libérer de la capacité ? Mais aussi et surtout, parmi l'ensemble des projets, quels sont ceux que l'on veut voir finir en priorité ?
• Encourager le dialogue et la prise de décision collective entre les différents acteurs impliqués de bout en bout, pour garantir que le choix des projets se fasse sur des critères clairs et partagés.
• Chercher dans un second temps lors du lancement des projets à se mettre en capacité de les dérouler de manière dense et fluide. Dense parce qu'on y met pas toute la capacité nécessaire. Fluide, parce qu'étant donnée la capacité, on exécute sans obstacles ni attentes. On ne lance donc les projets que si l'on est capable de garantir leur achèvement rapide et efficace ! Il est plus judicieux de reporter un projet que de le lancer dans des conditions défavorables et de le voir s'éterniser.

Pour amorcer ces changements, le premier pas est déjà de rendre la parallélisation visible et de rendre ses impacts visibles. Comment faire ça ? Voici 2 exemples de situations.

Un premier exemple au département solution "S"

Voici un premier exemple. Il provient de notre travail avec un éditeur du domaine médical. Le département solution est constitué de 25 à 35 équipes agiles, relativement stables et qui évoluent selon un pattern "grow & split". Ces équipes multidisciplinaires travaillent à la fois sur des produits ou composants distincts et découplés, mais aussi souvent sur des programmes transverses impliquant plusieurs équipes. A l'échelle de tout le département, l'ensemble des équipes travaillent sur 380 sujets en parallèle, depuis le discovery jusqu'aux projets en cours de déploiement client.

| fig 1. évolution de la part de vélocité de chaque équipe, en vert: consacrée au programme ; en rouge: consacrée à d'autres sujets.
| fig 2. évolution théorique des efforts en considérant la vélocité moyenne de chaque équipe.
| Pour mettre en relief l'inefficacité due au multiplexage, nous nous intéressons ici à un programme impliquant 3 équipes.

• La fig. 1 montre a posteriori quelle part (en vert) de leur vélocité elles ont consacré au programme qui nous intéresse. On constate en rouge qu'une bonne partie de leurs efforts a été consacrée à d'autres sujets.
• La fig. 2 montre ce qui se serait passé si - tout en travaillant à leur vélocité moyenne - les équipes s'étaient focalisées sur le programme. On constate que leurs durées respectives de contribution au programme passe de 24, 42 et 24 semaines à 10, 11 et 7 semaines respectivement.

Selon le potentiel de travail en parallèle ou au contraire séquentiel entre les équipes, ce programme qui s'est étalé sur 48 semaines aurait pu prendre entre 11 et 20 semaines. On constate un potentiel de densification et donc une amélioration du lead time de ce programme compris entre x2 et x4 !

Un second exemple à la DSI "B"

Notre second exemple concerne une grosse DSI de 2800 personnes, avec 744 projets en cours, dont 63 projets "stratégiques" ! Nous avons pris un échantillon représentatif de 3 projets récemment terminés et relativement courts. Étant donné l'absence d´équipes pluridisciplinaires stables, nous ne disposions pas de données de débit par équipe. Nous avons alors regardé pour ces 3 projets les imputations de leurs contributeurs. Nous avons ainsi pu examiner 4 éléments :

• l'évolution au cours du projet de la somme des jours imputés par l'ensemble des acteurs (ici sur le projet Jaune en Fig.3)
• la distribution du nombre de jours par semaines imputés (ici sur 3 projets bleu, rouge et jaune en Fig.5)
• l'évolution au cours du temps du nombre de projets simultanés sur lesquels ont imputé l'ensemble des contributeurs (ici, toujours le projet Jaune en Fig.6)
• et l'évolution au cours du temps du nombre de projets simultanés sur lesquels ont imputé les contributeurs "critiques" (toujours le projet Jaune en Fig.7). Par contributeurs critiques, on entend ici les contributeurs qui ont le plus contribué au projet, dont la contribution n'est pas compressible et qui vont contraindre la durée du projet. En l'occurrence les principaux devs, analystes et chef de projet.

fig 3. évolution de la somme des efforts	fig 4. efforts densifiés
fig 5. distribution des jours imputés par projet
fig 6. évolution du nombre de projets par personne	fig 7. évolution du nombre de projets pour les personnes critiques.

Que constate-t-on ?

• en fig 3. le projet Jaune prend 39 semaines, avec pendant une longue période moins de 2j par semaine au total qui lui sont consacrés. Il faut attendre la 22eme semaine avant que n'y soient consacrés plus de 10j.h au total, soit 2 ETP.
• La fig.4 présente une répartition des efforts qui aurait été densifiée : les sommes des efforts est similaire pour chaque phase du projet, mais les contributeurs clés sont intervenus de manière focalisée, 5j par semaine, sans ralentissement ni interruption. Le projet en question passerait ainsi d'une durée de 39 semaines à une durée de 10 semaines. La capacité ainsi libérée en amont pourrait ainsi être consacrée à d'autres projets plus prioritaires.
• Les fig. 5, 6 et 7 viennent expliquer la situation actuelle constatée en fig.1. En effet, en fig.3, on constate que la plupart du temps passé par les contributeurs est entre ¼ j et 2j par semaine. Et sur le projet jaune par exemple, personne n'a jamais contribué à temps plein et seulement 1 fois 4j par semaine.
• De la même façon sur la fig. 6, on voit au cours du temps le nombre important de projets sur lesquels les contributeurs du projet Jaune sont intervenus en parallèle. C'est même le cas en fig. 7 avec les contributeurs clés (ceux dont la contribution est la plus volumineuse et qui va contraindre la durée minimale du projet), qui doivent couramment intervenir sur 2, 3 ou 4 projets dans la même semaine.

Dans ces deux exemples, on constate un impact important de la multiplication du nombre de projets en parallèle : les projets s'étalent dans le temps et leur durée est ainsi couramment multipliée par 3-4. Comme en témoignent quelques verbatims, les acteurs en charge du delivery avaient déjà largement conscience de leur situation actuelle :

"On a la pression : faut se démerder pour tout faire ! "

"On a une saturation des équipes mais pour l'instant, on cherche à faire plaisir à tous les métiers en même temps"

On touche là au noeud du problème ! Si l'intention de faire plaisir est louable, on aboutit bien à l'exact contraire : les projets s'allongent, les métiers en ont marre d'attendre, quitte à avoir recours à du shadow IT pour résoudre leurs problèmes. L'attente est trop longue donc on lance des projets pour répondre aux impatiences légitimes. Le cercle vicieux est amorcé. Au moins ces constats concrets leur ont permis à la fois de réaliser l'ampleur du problème, de pouvoir en parler de manière factuelle et surtout de ne plus l'envisager comme une fatalité.

"On jongle sur trop de sujets en parallèle, il faut diminuer le nombre de balles en l'air !"

"Il faut avoir le moins de choses possibles dans les tuyaux pour être plus réactif. Il faut commencer à vider la baignoire".

Ces métaphores du jongleur qui sature ou de la baignoire qui déborde sont ainsi revenues dans les discours car illustrant bien leurs problématiques. Au point que dans un cas, le "travail sur les balles en l'air" est venu désigner le rituel mensuel de suivi tactique de la roadmap mis en place.

Comment agir dans une situation avec une multitude de sujets déjà lancés ?

Nous conseillons de commencer par mettre en place un kanban pour rendre visible l'en-cours : ces fameuses "balles en l'air". Utilisé lors de rituels transverses, ce support de management visuel (physique ou numérique) va permettre de gérer le flux de manière de plus en plus tirée plutôt que poussée. Dans nos deux exemples, les acteurs ont entrepris un "vidage de la baignoire". Mais, une fois que l'on a réalisé qu'il faut chercher à densifier les projets, vaut-il mieux lancer des projets "densifiés" by-design ou finir des projets en cours ? Comme le dit la formule lean "Stop Starting, Start Finishing". Il vaut mieux commencer par finir les projets relativement faciles et importants à finir et "mettre le paquet" dessus, quitte à mettre d'autres projets en standby. Mais en tout cas, arrêter les projets qui tournent au ralenti. Il faut alors s'assurer que les personnes clés restent pleinement concentrées sur le sujet et ne sont pas distraites par d'autres sujets. Cela pose donc forcément la question de quels projets finir. Ce n'est pas anodin, la question passe de "quels projets lancer ?"... à "quels projets finir ?" Ce qui nécessite de revisiter et de clarifier les priorités. Entre tous ces projets "P1" ou "P0", lesquels sont les plus importants à finir : lesquels peuvent le moins attendre ? Nous n'allons pas forcément développer le sujet ici, mais la capacité étant limitée et souvent allouée de manière partagée entre plusieurs domaines métiers distincts, il est important de pouvoir comparer des choux et des carottes et réaliser des arbitrages concertés. Pas seulement entre acteurs du delivery, mais de manière conjointe entre IT et métier ! Plutôt que des escalades, il faut privilégier et faciliter des ateliers de priorisation parfois difficiles où les différentes parties prenantes croisent leurs perspectives et où l'on fait ressortir des critères partagés. La durée cumulée du projet, la charge de reste à faire ainsi que le "coût de l'attente" (Cost of Delay) sont ainsi des éléments clés pour identifier les projets prioritaires à finir. Commence alors une période où l'on va chercher à finir ces projets et ainsi libérer de la capacité à faire, amorçant ainsi un cercle vertueux. Cependant, notre expérience nous montre qu'il faut faire preuve d'un peu de patience car on ne va pas avoir de gains immédiats. Un réel sponsoring du leadership est nécessaire pendant cette période transitoire pour soutenir l'initiative car on lance le minimum de projets et on ne constate pas immédiatement une réduction de leur durée. Certains projets moins prioritaires ont été suspendus et continuent à durer, mais d'autres projets vont pouvoir se finir plus rapidement. Finalement, les efforts paient, puisque dans un des cas cités nous avons mesuré après 6 mois une réduction de 30% du lead time médian.

Conclusion

Nous avons vu que le sentiment d'urgence permanent, les changements de priorité perturbants, les relations tendues entre équipes et les individus constamment submergés sont des symptômes malheureusement fréquents mais habituels de la surabondance de projets. Face aux nombreuses ambitions, il est difficile de dire non et d'éviter de lancer un projet à chaque demande ! Pourtant l'impact est mécanique : lancer des projets en parallèle conduit à allonger leur durée, souvent x4 ! Ceci est tout sauf une fatalité. Après avoir factualisé et démontré l'impact du multiplexage, on peut amorcer une démarche de Lean Portfolio Management. Cela commence par rendre visible l'ensemble de l'encours dans un kanban partagé à l'ensemble des acteurs. Puis de commencer à “vider la baignoire” en limitant le lancement de nouveaux projets et en finissant des projets bien avancés pour enclencher une dynamique vertueuse. C'est le début du chemin...