Comment réussir la gestion de projet

2. Comment faire ?

a. Prendre en compte les tendances du marché

Le marché des solutions de gestion de projets et de portefeuilles de projets se caractérise par plusieurs tendances : d’abord, une intégration des solutions dans une logique de PPM (Project Portoflio Management) qui facilite les arbitrages et la gestion des risques. Ensuite, une intégration avec les outils de CRM, pour les relations avec les clients internes. Enfin, l’émergence de solutions qui s’apparentent à des « ERP de gestion de projet », avec des fonctionnalités de facturation et de suivi financier, des modèles et des métriques prêts à l’emploi. Enfin, une intégration avec les plateformes mobiles, par exemple pour le suivi du temps passé et la collaboration.

b. Cartographier les projets

La cartographie des projets permet, non seulement d’identifier le nombre de projets mais également, de les classer par taille, durée et en fonction des spécificités des environnements techniques, de la nature des ressources qui y sont associées, de la taille des équipes et de leur répartition géographique.

c. Hiérarchiser les projets

Pour le Cigref, qui avait organisé, en 2014, un atelier sur la fonction SI face au défi du numérique, « Nous allons probablement vers une bicéphalie entre des modes projets spécifiques pour les applications front office, très agiles et proches du client final, et des modes projets sur les infrastructures et les applications back office, répondant à des cycles plus longs. »

D’où la nécessité de hiérarchiser les projets en fonction de ces objectifs et de leurs conséquences sur le client final. Cela revient, notamment, à évaluer les éléments-clés des projets et les facteurs-clés de succès : vision, périmètre, planification, modes de pilotage et de gouvernance, relations entre la DSI et les métiers, environnements techniques, profil des équipes de développement…

D’après Gartner, la gestion de projets doit clairement distinguer ceux qui doivent être livrés rapidement de ceux qui peuvent attendre. Trois bonnes pratiques permettent aux DSI de se placer dans une telle position :

• Déterminer, pour chaque projet, dans quelle catégorie il doit être classé : les projets liés à l’innovation et à la différentiation par rapport aux concurrents doivent être finalisés le plus rapidement.
• Privilégier la création de valeur business comme indicateur de réussite d’un projet.
• Séparer la gestion de portefeuille de projets et la gouvernance, avec des responsabilités différentes entre ceux qui réalisent le projet et ceux qui le financent.

d. Prendre en compte les spécificités des projets cloud et Big Data

Les projets liés à des problématiques de cloud et de Big Data nécessitent de former les équipes projet, avec l’intégration de multicompétences, d’associer un éventuel apport d’expertise externe et de porter une attention particulière aux plans de migration et d’intégration. 80 % des entreprises françaises affirmaient, en 2015, manquer de compétences en interne pour mener à bien des projets de Big Data, selon une étude de Markess International.

D’après IDC, 56 % des DSI européens ont des difficultés à trouver le personnel pour gérer les projets cloud. De même, les nouveaux projets gagneraient à être pensés en mode « cloud d’abord ». Pour les projets Big Data, les problématiques de création de valeur pour le client final, de qualité des données, de leurs sources et de leur intégration, prennent une importance particulière.

e. Travailler le business case

Le business case de projet SI est le document de synthèse qui regroupe l’ensemble des éléments-clés nécessaires à la prise de décision et au déroulement du projet. Un business case doit contenir au moins trois éléments.

D’abord, l’étude d’opportunité qui précise, en particulier, les enjeux stratégiques, les objectifs assignés au projet et les résultats attendus en termes de création de valeur, de productivité, de réduction de coûts… Ensuite, un business case regroupe les solutions envisagées et les différents scénarios possibles pour répondre aux besoins définis par les porteurs du projet. Enfin, le business case aborde les aspects financiers.

f. Distinguer les types de projets et adapter le pilotage

La gestion de projet constitue une activité de management à part entière, mais elle peut également s’inscrire dans un cadre plus large. Elle ne se limite pas à la gestion des seuls projets : des projets complexes peuvent ainsi fréquemment impliquer plusieurs projets ou sous-projets dépendants les uns des autres, et il faut alors gérer également les interactions et les possibles arbitrages qui en résultent, que ceux-ci portent sur les ressources, les plannings ou les budgets.

La gestion de portefeuilles de projets consiste à piloter l’ensemble des projets d’une organisation ou d’une entité. Il s’agit, dans ce cas, de s’assurer que ces projets sont, et restent, alignés sur la stratégie de l’organisation : cela implique de soumettre les projets candidats à des processus d’arbitrage et de sélection pour choisir les plus pertinents, mais aussi de vérifier régulièrement si les projets en cours sont toujours adaptés aux objectifs de l’entreprise, quitte à les interrompre si ce n’est plus le cas.

La gestion de programmes consiste à gérer des ensembles de projets adressant un même objectif et convient notamment pour piloter des transformations plus importantes.

Gartner identifie cinq catégories de programmes, dans le cadre des stratégies de gestion de portefeuilles de projets et, pour chacun, les modes de pilotage et de gouvernance sont différents :

• Les programmes « bottom-up », qui sont de petits projets assemblés en fonction de leurs interdépendances.
• Les programmes orientés changement, caractérisés par des besoins significatifs d’évolution.
• Les programmes réglementaires.
• Les programmes orientés business.
• Les programmes de transformation, qui sous-tendent ,des évolutions majeures dans les business modèles, l’organisation et les offres.

g. Créer un PMO

Un PMO (Project Management Office) a pour but de gérer les portefeuilles de projets dans tous leurs aspects (budgétaires, organisationnels, techniques…), avec une vision globale et des outils adaptés, pour le suivi budgétaire, les tableaux de bord, le reporting, la gestion de portefeuille. Cette entité, plutôt réservée aux organisations d’une certaine taille ayant un volume de projets difficilement gérables avec un tableur, ne se substitue pas aux chefs de projet.

Au sein d’un PMO, plusieurs critères d’évaluation des projets peuvent être privilégiés : l’atteinte des objectifs, la satisfaction des utilisateurs, l’alignement du portefeuille de projets sur la stratégie, l’allocation optimale des ressources…

h. Privilégier les méthodes agiles

Les méthodes agiles constituent une alternative aux rigidités de l’approche traditionnelle de conduite de projet. Elles conjuguent approche incrémentale et mode de travail collaboratif. Le principe consiste à découper un projet en plusieurs étapes. Pour chaque itération, une version minimale du projet est développée, puis soumise, dans sa version intermédiaire, pour validation.

Chaque itération est un mini projet en soi et, au terme de la dernière itération, on obtient le produit final. Cette démarche présente plusieurs avantages : une communication de meilleure qualité au sein des équipes, une visibilité sur les projets, une évaluation en continu de la qualité, une anticipation des risques et une meilleure maîtrise des coûts.

i. S’inspirer des référentiels existants

Il existe plusieurs référentiels dont on peut s’inspirer, pas nécessairement pour les appliquer en tant que tels, mais afin d’y trouver des éléments utiles pour professionnaliser la démarche de gestion de projet. On pourra notamment se référer à PMBok (processus et domaines de connaissances), Prince2 (rôles, processus et techniques de gestion de projets), P30 (gestion de projets, de programmes et de portefeuilles), ou OPM3 (modèle de maturité). Les principes et l’intérêt de ces référentiels ont été analysés dans l’ouvrage « Best Practices revues et corrigées ».

j. Tirer parti de ses échecs et appliquer les règles de bon sens

Rita Gunther McGrath, professeur à la Columbia Business School (Cf. Best Practices SI, n° 70) suggère de transformer les échecs, souvent tabous, en opportunités, en appliquant plusieurs principes : décider des critères caractérisant le succès et l’échec avant de lancer une initiative, agir rapidement pour échouer vite, limiter les risques de pertes pour subir des échecs à faible coût, bâtir une culture de l’échec intelligent, formaliser et partager ce que l’on apprend.

Il convient également d’appliquer quelques règles de bon sens, par exemple, considérer que tout projet doit avoir une fin, qu’il doit aboutir à un gain en fonction de l’investissement, de toujours savoir pourquoi on lance un projet, d’en comprendre la finalité et de le piloter en continu. De même, on évitera de considérer, par exemple, que pour délivrer un projet à temps, il suffit d’augmenter le nombre de chefs de projet, que les surcoûts d’un projet ne dépendent pas de sa taille ou que d’affecter des individus sur plusieurs projets à la fois permet de lisser la charge et de supprimer les temps morts…

3. Les points d’attention

a. Prendre en compte la spécificité des projets IT

Les projets IT, comparés à d’autres types de projets, par exemple dans les domaines de l’ingénierie ou du BTP, ont des caractéristiques qui les rendent beaucoup plus difficiles à gérer. Dans leur ouvrage sur Le management des contrats (Editions Eyrolles), Alain Brunet et Franck César, rappellent les particularités des projets IT :

• Tout semble possible, car les projets IT ne sont pas soumis aux lois de la physique, comme les projets de génie civil.
• Ils ont une complexité difficile à évaluer, en comparaison des projets d’ingénierie.
• Ils possèdent des entrées et des livrables « invisibles », car intangibles.
• Ils ont une dépendance forte vis-à-vis de l’expertise des parties prenantes.
• Ils sont souvent conçus pour accompagner des changements ,organisationnels.
• L’argument selon lequel chaque projet est unique est invoqué plus que de coutume.
• Ils sont sensibles à la loi de Brooks, selon laquelle ajouter des ressources à un projet en retard ne fait qu’accentuer ce retard.
• Le coût de développement ne reflète pas toujours la criticité métier.

b. Contrôler le Shadow IT

Selon une étude Canopy-Atos, 37 % des managers des entreprises françaises, américaines et britanniques, estiment que l’incapacité de leur DSI à autoriser des projets pilotes et à lancer de nouveaux produits rapidement et dans les délais serait, en majeure partie, à l’origine d’investissements massifs en matière de Shadow IT. En fonction du positionnement du DSI, des relations avec les métiers et de la stratégie de transformation numérique, un contrôle plus ou moins strict du Shadow IT peut s’avérer nécessaire.

c. Maîtriser les compétences

Dans son ouvrage Staying the course as a CIO (Editions Wiley), Jonathan Mitchell estime qu’il est « plus facile de grimper l’Everest que de mener des projets IT, la proportion de ceux qui arrivent au sommet est plus importante. » De fait, le métier de chef de projet s’avère particulièrement difficile, surtout dans des organisations complexes.

« On crée des postes de chef de projet pour tout et n’importe quoi. Les dirigeants semblent croire qu’il suffit de donner le titre de chef pour qu’une personne le soit, que changer l’organigramme c’est changer l’organisation. C’est bien sûr faux », rappelle le sociologue François Dupuy, dans son ouvrage La faillite de la pensée managériale (Éditions du Seuil). Il convient, en particulier, de surveiller les travers des chefs de projet, résumés par Joseph Gabay dans son ouvrage sur la maîtrise d’ouvrage des projets informatiques (Dunod) :

• Sombrer dans le conservatisme.
• Réinventer des solutions qui existent déjà.
• Être trop procédurier.
• Diluer la responsabilité de prise de décision et entretenir un climat d’indécision permanent.
• Rester dans un modèle trop théorique et individualiste.
• Considérer que les méthodes sont des lourdeurs.
• Donner trop peu de place à la responsabilisation individuelle.
• Faire une course sans fin pour atteindre des résultats.
• Trop déléguer sans s’impliquer.
• Élaborer un système de contrôle trop pesant, être trop autoritaire et ne pas communiquer.

d. Prévoir la gestion de crise

Complexité, dépendance entre les éléments, changements trop fréquents, technologies non maîtrisées : les raisons ne manquent pas pour qu’un projet, ou un grand projet de transformation, dégénère en situation de crise. En amont, cela suppose d’avoir anticipé la probabilité d’occurrence et la nature des risques. On distinguera plusieurs niveaux de risques, selon leurs causes et leurs conséquences.

Pour réduire les risques, plusieurs approches sont recommandées. Les consultants du cabinet Oliver Wyman suggèrent quatre pistes :

• Établir un diagnostic exhaustif des problèmes à régler, quelle qu’en soit la nature, en évitant de « plonger trop vite dans l’action » au risque d’oublier des éléments importants.
• Décider de l’ordre des priorités et arbitrer entre satisfaire le client à tout prix, stopper l’hémorragie des coûts ou la non qualité. En principe, on ne peut gérer plusieurs priorités simultanément. C’est au top management d’établir ces priorités, de les communiquer aux équipes et d’allouer les ressources correspondantes.
• Mettre en place une gouvernance opérationnelle claire, rigoureuse et, surtout, s’y tenir (pilotage, réunions de travail, séances d’information…), de manière à ne pas passer en « mode panique ».
• Élaborer un « thermomètre fiable », avec des indicateurs pertinents, qui servira de base à la communication et aux échanges entre les parties prenantes.

e. Savoir arrêter un projet

« Nous ne connaissons jamais d’échecs de nos projets IT, nous avons simplement des succès extrêmement coûteux » : l’opinion d’un DSI d’un groupe pharmaceutique, cité par Jonathan Mitchell, dans son ouvrage Staying the course as a CIO, résume bien le paradoxe auquel est confronté tout chef de projet.

Faut-il arrêter un projet lorsque l’on s’aperçoit qu’il sera un échec, ou faut-il continuer à investir en espérant redresser la situation ? Il n’y a évidemment pas de réponse unique à cette question… On peut néanmoins limiter les risques de dérive. Les consultants de McKinsey ont établi une check-list de la prise de décision, qui permet de limiter les biais, en se posant six questions :

• Les facteurs qui permettraient que le projet dépasse ses objectifs ont-ils été considérés ?
• Les hypothèses ont-elles été comparées à des projets similaires menés hors de l’entreprise ?
• Les hypothèses ont-elles été comparées à des projets similaires menés au sein de l’entreprise ?
• Le processus de décision rassemble-t-il des personnes ayant une diversité de points de vue ?
• L’équipe qui doit prendre la décision a-t-elle été confrontée à des personnes qui ne sont pas a priori d’accord ?
• Au moins une solution alternative a-t-elle été envisagée ?

Selon le nombre de « oui » aux questions, quatre stratégies peuvent être envisagées : mener le projet, le suspendre, le reconsidérer ou le soumettre à un stress-test.