3 leviers pour la gestion de votre portefeuille de projets SI & digitaux

L'essentiel

Il est naturel de penser que généraliser les méthodes agiles à la plupart des échelons de l’entreprise, et en particulier au niveau des équipes opérationnelles, est une étape nécessaire avant de pouvoir envisager d’étendre ces méthodes à la gestion de portefeuille.

Toutes les organisations n’ont pas ce niveau de maturité, pour autant elles ont toutes à gagner à gérer un portefeuille de manière agile, a fortiori en temps de crise. Ne pas maîtriser son portefeuille de projets (absence d’indicateur, portefeuille mal connu…), c’est courir le risque d’arbitrer dans la panique à partir d’éléments peu rationnels lorsque les difficultés surviennent. A l’inverse, une gestion de portefeuille agile permet de dégager des opportunités dans les périodes difficiles, en interrompant ou en faisant évoluer des projets, et même d’anticiper la reprise.

Il est crucial pour la plupart des organisations de rendre leur portefeuille de projets plus dynamique et plus adaptable, quel que soit leur niveau de maturité en termes d’agilité. Nous pensons qu’un tel objectif peut être atteint en se concentrant sur trois axes d’évolution de la gestion de portefeuille, sans nécessairement lancer un projet majeur de transformation agile.

« Equipes SI et digitales : exigez de vos métiers qu’ils arbitrent ! »

Organisez la gestion de portefeuille à l’échelle d’une chaîne de valeur

Il existe plusieurs manières de découper son portefeuille, c’est-à-dire de décider sur quel périmètre cohérent on choisit de regrouper différents projets. On observe souvent des portefeuilles organisés par métiers et administrés centralement par une fonction SI ou digitale (i.e. un portefeuille marketing, un portefeuille cœur de métier A, un portefeuille cœur de métier B, un portefeuille RH et finance, etc.).

Ces découpages paraissent intuitifs mais posent néanmoins plusieurs problèmes :
▪ Les DSI et équipes digitales sont positionnées comme arbitres de demandes concurrentes alors qu’elles n’ont pas la légitimité pour départager des métiers qui ont tous des besoins cruciaux et urgents.
▪ La mutualisation et le partage des ressources, nécessairement contraintes, est complexe.
▪ En silotant par métier, l’innovation et les projets transverses ne sont pas encouragés.

Découper des portefeuilles par chaîne de valeur

Une approche alternative consiste à rassembler les projets et initiatives IT et digitales au sein de chaînes de valeur métier. Il s’agit d’un enchaînement d’étapes qui concourent à créer de la valeur (celle-ci peut prendre plusieurs formes : un produit ou un service à destination d’un utilisateur final par exemple). Un exemple classique de chaîne de valeur est l’obtention d’un prêt : la demande de prêt va en effet devoir suivre un certain nombre d’étapes (demande auprès de la banque, évaluation du dossier, choix d’assurance, mise à disposition des fonds…). En termes de gestion de portefeuille, ce découpage permet de raisonner sur un ensemble de projets qui participent à un objectif commun et ainsi de faciliter les arbitrages, bien que chaque projet puisse relever de périmètres métiers différents et être exécuté opérationnellement par des directions ou des entités différentes.

En termes budgétaires, cette approche induit des changements significatifs puisque les enveloppes dédiées aux investissements IT sont attribuées non plus à l’échelle d’un projet, d’une direction ou d’une équipe, mais bien pour l’ensemble d’une chaîne de valeur, qui arbitre ensuite entre les projets qui la composent. Si nous poussons le raisonnement, nous pouvons même aller jusqu’à considérer que le budget de la DSI n’est finalement que la somme des budgets que l’entreprise alloue à chacune des chaînes de valeur pour mener des projets technologiques^[1].

Selon votre organisation, il peut être pertinent d’adopter ce nouveau découpage^[2] pour une chaîne de valeur « test » qui s’y prête particulièrement bien : faible nombre d’étapes, périmètre facilement détourable, pratiques et compétences qui faciliteront l’adoption…

Prendre en compte la nature du parc technologique sous-jacent à la chaîne de valeur

Une fois qu’une ou plusieurs chaînes de valeur métier ont été identifiées, il est important d’y associer les systèmes, applications et équipes qui supportent les différentes étapes de cette chaîne de valeur. A travers eux, nous pouvons identifier les projets et initiatives SI et digitales qui constituent les briques fondamentales du portefeuille de projets. 

Selon la nature des applications en question, une approche de gestion agile du portefeuille apporte cependant plus ou moins de bénéfices : il ne s’agit pas de vouloir faire de l’agile à tout prix, mais plutôt à bon escient et lorsque ces méthodes apportent le plus de valeur.

Nous proposons ainsi la classification suivante :

• Les « plateformes cœur » ou core platforms, qui subissent peu d’évolutions et qui seront donc assez peu présentes dans le portefeuille projet, en dehors de projets d’ampleur (un projet de migration SAP vers S4/HANA par exemple)^[3]. Ces projets sont souvent complexes et posent des problématiques spécifiques qui ne se sont pas traitées dans cet article.
• Les systèmes ou applications « dynamiques » : des produits technologiques en cours de construction ou qui sont sujets à de fréquentes évolutions. Une gestion de portefeuille Lean / agile est particulièrement pertinente pour ces systèmes.
• Les systèmes hybrides, qui seront à étudier au cas par cas pour déterminer si une gestion de portefeuille agile est pertinente pour ces projets.

Au sein d’une chaîne de valeur et selon la répartition de vos applications parmi ces trois catégories, votre organisation aura plus ou moins intérêt à agiliser sa gestion de portefeuille. Nous défendons une approche graduelle : il s’agit de rendre agile en priorité ce qui peut l’être.

Une fois cette structuration adoptée, il est temps d’aborder le sujet de l’arbitrage et de la priorisation au sein d’une chaîne de valeur.

« Mieux vaut un projet mort qu’un projet mort-vivant »

Encourager ou stopper des projets grâce à une gestion structurée et objective du portefeuille

Par leur complexité, les portefeuilles de projets technologiques sont souvent difficilement lisibles et source d’incompréhension lorsque vient le temps des arbitrages. La segmentation par chaînes de valeur permet d’homogénéiser, de clarifier le portefeuille, et de faciliter leur lecture. Toutefois, les arbitrages sont la plupart du temps rendus de manière empirique lors de l’élaboration budgétaire et, au cours de l’année, sont souvent perçus comme opaques. Ceci peut provoquer de la frustration pour bien des parties prenantes.

Par ailleurs, nous observons que ce type de pratique fait reposer la connaissance du portefeuille sur quelques personnes clés qui ont la capacité de retracer l’historique des arbitrages d’une année à l’autre. Cherchant à pallier le risque inhérent de perte de connaissance, ces organisations ont souvent recours à des prestations externes régulières, afin de documenter le portefeuille.

Structurer efficacement son portefeuille : prioriser en relatif via des critères objectifs

Nous avons la conviction qu’il est nécessaire d’abandonner l’idée de disposer de règles absolues pour prioriser les projets pour au contraire être en capacité de positionner les projets les uns par rapport aux autres. L’idée est de disposer d’un cadre commun d’analyse^[4] des projets (valeur, complexité, coût à ne pas faire, durée de payback…) qui soit le plus objectif possible en s’appuyant par exemple sur des données tangibles (durée, coût, nombre de flux, nombre d’utilisateurs…). Un tel criblage permet de reprioriser en continu les projets en fonction du contexte et parfois envisager d’en arrêter certains.

Oser stopper des projets efficacement : 2 clés pour s’en sortir

Il existe toutefois une véritable difficulté, d’ordre culturel et organisationnel, à arrêter un projet : crainte de devoir porter la responsabilité de l’échec, frustration des équipes, biais cognitifs qui rendent difficile la marche arrière une fois que des efforts ont été engagés^[5]…. Pourtant, il est bénéfique d’arrêter tôt un projet qui ne tient pas ses promesses. De nombreux projets IT tentaculaires sont des échecs retentissants^[6] qu’il aurait été judicieux d’arrêter à temps.

Pour faciliter cette prise de décision souvent douloureuse, il est possible de mettre en place différentes méthodes pour objectiver l’arrêt d’un projet et ainsi le rendre davantage acceptable :

• Le meilleur moyen est encore de ne pas le lancer. Nous conseillons aux organisations de systématiser la pratique de business case (ou dossier d’opportunité), et ce très rapidement après l’émergence de l’idée ! Cette étude permet de s’assurer que les projets pour lesquels on engagera un effort de cadrage souvent significatif^[7] dégageront effectivement de la valeur. Si vous avez commencé à implémenter SAFe dans votre organisation, vous pouvez par exemple vous inspirer du canevas « Lean Business Case » qui aide à formaliser efficacement la valeur attendue d’un projet^[8]. Pour certains projets, une bonne méthode pour appuyer le business case est de pouvoir rapidement tester des hypothèses clés à l’aide d’un POC^[9]: en 15 jours, il est possible de développer un prototype et de le mettre entre les mains d’un utilisateur pour valider la pertinence d’une idée. 
  Toutes ces pratiques permettent notamment de rationaliser les efforts engagés avant même que les projets commencent, et libèrent de la capacité précédemment utilisée dans des cadrages hasardeux.
• Enfin, il nous paraît crucial de définir dès l’étude d’opportunité des règles claires d’interruption du projet au cas où celui-ci ne donnerait pas satisfaction. Il peut s’agir de garde-fous budgétaires ou temporels à ne pas franchir, d’hypothèses non validées qui remettent le projet en cause ou encore de KPIs non satisfaisants (chiffre d’affaire généré, satisfaction utilisateur, NPS^[10]…). L’objectif est d’aligner en amont les acteurs d’une initiative autour des raisons objectives qui conduiraient à remettre en cause le projet tel que défini initialement. Si le projet ne donne pas satisfaction au regard des règles définies au départ, il faudra envisager son arrêt ou le faire pivoter (par exemple, en changeant le périmètre ou les objectifs du projet). Nous avons la conviction que lorsque les règles sont définies collectivement en amont, leur acceptabilité est bien meilleure.

Nous disposons maintenant de critères de priorisation, de validation et d’arrêt des projets au sein d’une chaîne de valeur. Il s’agit désormais d’animer et de faire vivre de manière pérenne la gestion du portefeuille.

« Imposez votre rythme plutôt que courir après celui des autres »

Ancrez la vie de votre portefeuille dans ses réalités

Le rythme de gestion du portefeuille de projets technologiques est la plupart du temps dicté par des contraintes externes, notamment le processus de construction budgétaire. Ce dernier impose à l’ensemble de l’organisation une logique comptable et fiscale dont il est primordial de tenir compte mais qui ne devrait pas être le prisme d’analyse premier. En effet, la réalité de nombreux projets technologiques dépasse largement les contraintes calendaires d’une année fiscale ou d’un réestimé trimestriel.

La gestion budgétaire par année fiscale est une dimension qui ne peut néanmoins être écartée mais qui doit incomber au contrôle de gestion SI. Celui-ci trouvera une nouvelle posture de conseiller et de réconciliateur entre la finance et la réalité des projets technologiques pluriannuels. Cela permet également de pallier certains comportements contre-productifs, qui consistent à sécuriser des budgets sous forme d’enveloppe tout au long de l’année, puis de tout consommer à marche forcée en fin d’année afin de justifier la demande de ce même budget l’année suivante.

Une fois cette contrainte d’année fiscale remise dans les mains du contrôle de gestion, la définition du rythme de gestion du portefeuille de projet doit revenir à l’essence même des objets qu’il administre.

Un projet technologique est par nature un sujet complexe et à fort risque d’échec, comme nous l’avons déjà mentionné plus haut. Nous avons la conviction qu’une des solutions pour diminuer les risques liés à cette complexité est de permettre la collégialité et l’interdisciplinarité lors de l’instruction des projets.

Pour réaliser ce pari de l’intelligence collective, il est nécessaire de mettre en place des instances qui doivent concilier deux exigences a priori contradictoires :

• Favoriser la discussion, et ainsi permettre la recherche d’idées nouvelles, le croisement des expertises, ou encore une meilleure identification des dépendances.
• S’assurer de garder une gestion de portefeuille efficace puisque la multiplication des parties prenantes peut conduire à une certaine inertie.

Pour répondre à ce défi, les organisations déploient différentes stratégies. Certaines s’appuient principalement sur des échanges informels fréquents, qui ont su prouver leur efficacité bien que cela soit parfois au détriment de la collégialité. D’autres s’appuient sur d’abondants comités aux nombreux participants et perdent en agilité.

Nous conseillons de mettre en place des instances régulières avec un nombre de participants restreint mais bien choisis, représentants de toutes les strates d’une fonction SI ou digitale (représentant métier, gestionnaire de portefeuille, architecte, production applicative et infrastructure…). Au sein de ce comité récurrent, et en fonction de l’ordre du jour, des porteurs de projets^[11] viendront exposer leurs demandes ou faire un point sur l’avancement du projet. L’objectif est de discuter avec les métiers des priorités et des projets en cours, de résoudre certaines difficultés et d’arbitrer si besoin avec tous les acteurs du vertical technologique propre à la chaîne de valeur.

Les modalités précises d’animation de ces instances sont à adapter selon votre organisation et la nature des projets en cours : poker planning, méthode MosCow, utilisation de Kanban, WSJF… Nous suggérons toutefois que certains outils soient partagés d’un portefeuille à l’autre, en particulier lorsqu’il s’agit d’estimer la valeur des projets, ceci pour assurer un pilotage global des différents portefeuilles.

Par ailleurs, désigner un Portfolio Manager, point de contact privilégié et animateur des travaux sur un portefeuille donné, permet également de gagner en efficacité.

Enfin, il nous paraît important de faire le pari de la subsidiarité en donnant de l’autonomie et un pouvoir de décision aux participants de ces instances. Les représentants métier, les portfolio managers et leurs relais (product owner, product manager, responsables d’application…) sont les acteurs incontournables d’une gestion de portefeuille agile réussie. Ils sont les plus compétents sur leur périmètre, il est donc intéressant de leur donner de l’autonomie, en particulier pour gérer les plus petits objets du portefeuille (c’est-à-dire les demandes d’évolutions par exemple).

Conclusion

Les transformations proposées dans cet article constituent une première étape pour introduire de l’agilité dans la gestion de votre portefeuille de projets. Elles sont d’autant plus pertinentes si l’on considère que l’avenir des grands projets et programmes IT est de laisser de plus en plus de place à des organisations produit.

« Agiliser » le portefeuille est une bonne chose, se diriger vers un « delivery model » agile à l’échelle est la prochaine étape que la plupart des organisations devront amorcer dans les prochaines années. Chez KPMG, nous sommes mobilisés pour accompagner nos clients à relever ce défi.