Que devient la gestion de portefeuille de projets dans un monde agile ?

From Transitionagile

A co-rédiger avec JF Jago suite à nos premiers échanges

le 14/09/10. Discussion JIDUP / JAGO

Objet : monter une conf. sur l'agilité au niveau du portfolio… Pré-requis :

 * lire l'entreprise agile de Barrand et aller le voir à Geneve le 28/09
 * lire cmmi : maturity model
 * lire PMI portfolio mgt et OPM3
 * chercher sur forums linkedin viadeo
 * interviewer des orgas 100% agiles et non mono-produit
 * interviewer des Directeurs de TMA sur large périmètre applicatif (des dizaines d'applications)

Quel modèle de gouvernance et portfolio management dans un environnement agile ?

Toutes les organisations ne sont pas à considérer dans un même cadre d'analyse en matière de gestion de portefeuille de projet.

Il existe plusieurs types d'organisations publiques et privées travaillant sur de multiples projets.

  1. les sociétés de prestations de services : leur portefeuille de projet correspond à leur carnet de commande + le pipe probabilisé.
  2. les éditeurs de solutions : leur portefeuille de projets rassemble des programmes d'évolution de leurs différentes solutions, contenant chacun plusieurs projets, auxquels il faut ajouter les projets clients (mise en oeuvre, paramétrages, devs spécifiques)
  3. les "clients finaux" pour qui l'informatique est une fonction support à valeur ajoutée : leurs portefeuilles rassemblent programmes et projets d'évolution de leur SI. Plus ces organisations sont anciennes, plus le poids de leur passé est visible au niveau de la sédimentation de leur existant (leg) et de leur pratiques et cultures de gestion de projet / gestion des opérations.
  4. les "pure players" internet : modèle encore différent même s'il se rapproche des éditeurs de logiciels. Leur métier est de faire évoluer leur service en ligne qui s'apparente à un logiciel avec des fonctionnalités et des bases de contenus en accès web. Ex, les comparateurs de prix comme Kelkoo, PriceRunner, les moteurs de recherche comme Kelkoo, les éditeurs de plate-formes logicielles de publicité en ligne comme ValueClick, RealMedia... On pourrait penser qu'ils n'ont pas les problématiques des éditeurs classiques d'installation client mais ils doivent s'intégrer dans des environnements externes, travaillent sur de la syndication... chaque nouveau client ou partenaire implique comme pour un éditeur des travaux spécifiques.

Au-delà des divergences du cadre d'analyse, toutes les organisations n'ont pas la même maturité dans la structuration et la gestion de leurs portefeuilles de projets. Voici à grandes mailles une structuration grossière des niveaux de maturité des organisations en la matière (comparer à OPM3, CMMI, COBIT)

  1. maturité 0 : le portfolio management non mature environnt cnamts / mcc / coup…
  2. maturité 1 : projets connus, recensés, ressources affectées
  3. maturité 2 : pipe structuré, lancement projet par projet, pas de vision transverse
  4. maturité 3 : filtre transverse distinct du filtre unitaire / revue régulière de l'alignement et contribution stratégique mais Value = cost… Orga classique en temps partiel trop de projets de front. Même ce stade 3 est insatisfaisant : lourd niveau process (donc coûteux en ressources de pf mg, en délai de parking…, pas de vraie notion de valeur, trop de projets de front, pas d'exigence suffisante sur la valeur des fonctions, un coût prohibitif pour des fonctions sans valeur… Donc un frein à la stratégie. Et si l'agilité nous ouvrait de nouvelles perspectives ? Quel serait alors le modèle de portfolio mgt à mettre en oeuvre ? Comment ne pas retomber dans la lourdeur des processus ? Comment rester dans l'esprit agile (cf manifeste agile)?
  5. maturité 4 ?? Quel modèle de gestion de portefeuille en environnement agile définir pour exploser la puissance de frappe au service de la stratégie d'entreprise ?


En quoi l'agile changerait-il la gestion de portefeuille de projets ?

Tout d'abord, parce que la notion de projet change...

  • l'agile ne dispose pas d'une vision globale des stories au lancement (coût global…-)
  • l'agile a un début mais pas de fin : on enchaine les itérations pour améliorer, compléter le produit… donc on gère un produit dans le temps plus qu'un projet puis une maintenance… Donc on gère un portfolio de produits et de demandes de maintenance évolutive plus qu'un portefeuille de projets. La maille est bcp plus fine. Le portefeuille est-il pilotable au niveau de la story comme on le fait pour le sprint ?
  • du coup, si on veut conserver la notion de projet (d'évolution), le "projet" devient le sprint ou la release (qui ont un début, une fin, un périmètre, une qualité attendue, un délai et des ressources budgétées avec des compétences définies). Le programme devient l'ensemble des sprints ou releases et suit la roadmap définie.

Rappel du manifeste en 4 principes en particulier l'agile dit les relations humaines (confiance etc) plus que les process et outils… voir mot de kik piney sur twitter

on dit distingue portefeuille et projet par ce jeu de mots :

  • portfolio = faire les bons projets
  • projet : faire le projets bien... mais c'est centré projet… or en agile, on est centré produit et on dit plutôt que l'objectif d'un projet, c'est de : faire les bonnes fonctions / répondre aux bonnes stories (prioritaires et à valeur confirmée)... Donc le jeu de mots ne fonctionne plus. Et on revient dans la même logique qu'au niveau supérieur (portfolio / faire les bons projets)


en agile, ...

  • on travail full time : cela réduit le conflit de gestion de ressources au niveau opérationnel, réduit la procrastination mais aussi réduit le nombre de projets traitables en parallèle
  • on fait du kanban naturellement (on prend story après story, puis tâche après tâche (spec, dev, intégration et tests, qualif et validation, production) sur les différents stades du kanban : à faire / en cours / terminé) cela évite l'effet tunnel, le changement d'orientation stratégique,... On n'arrêtera jamais un projet en cours (sprint ou release) mais on peut l'arrêter ou le suspendre temporairement si un projet (qqes sprints / releases) plus prioritaire nécessite les ressources.
  • du lean (au sens amélioration continue) aussi ; cela réduit de fait le gaspillage, améliore la progression, l'efficience, la motivation… donc la productivité (donc 1 € en agile apporte + de valeur stratégique qu'un euro en traditionnel).


L'agile est viral… et se répand en tâche d'huile… l'essayer c'est l'adopter. en agile, le PO priorise les stories. Dans le schéma classique souvent on ne le fait pas, il n'y a pas d'analyse de la valeur véritable ; on parle de méthodes de priorisation comme le Moscow dans le référentiel du PMI mais est-il vraiment appliqué et par qui ?
En matière de gestion de portefeuille de projets, il existe plusieurs modèles de référence à étudier et des retours d'expérience :

  1. Que dit le PMI sur le portfolio mgt et l'OPM3 (modèles de maturité)  ?
  2. Que dit le CMMI sur le CMM (maturity model) ?
  3. Que dit le COBIT sur la gouvernance ?
  4. Comment se gère un portefeuille de demandes en TMA ?
  5. Comment font les organisations full agile ou largement agiles et multi-produits ? Ex. les éditeurs comme CEGID, FERMAT, ST MICRO, CHU de Grenoble
  6. Comment font les organisations qui gèrent des centaines de projets en prestations au forfait (en utilisant les mêmes experts vendus sur plusieurs projets de front) => ATOS,
  7. Comment les organisations classiques (MCC, INTERPOL, CNAMTS, GDF,...).

Aujourd'hui, le modèle se cherche. L'histoire est à écrire... par vous et nous. Suggestion :

  • Jean-François : ton expérience à Agile Marseille : expliquer la gestion de portefeuille sur 4 équipes agiles... Gestion au sprint. Limites : changer d'équipe à chaque sprint casserait la vélocité. D'autre part, dans ce cas, il y a un "super PO" qui peut prioriser et affecter les ressources entre 4 équipes => il a une responsabilité d'ensemble sur ces équipes. Donc plusieurs idées se dégagent :
  1. . ne pas remettre en cause les affectations de ressources à tous les sprints mais à toutes les releases= > donc on retient qu'un projet = une release (on sait estimer le délai, les charges et la valeur attendue sur la release).
  2. . Du coup, il faudrait que tous les projets d'une organisation aient le même rythme (sprint par ex 3 sem, release = 4 itérations par ex.).
  3. . Enfin, il ne faut pas gérer tous les projets d'une organisation en un seul niveau car il est impossible ou du moins cornélien de prioriser plus d'une centaine de projets entre eux sans décomposer la problématique (par ex par contribution stratégique).


Ebauche de solution : Décomposer la centaine de projets candidats en différents portefeuilles servant chacun une finalité stratégique majoritaire, chaque portfolio manager ayant la responsabilité de prioriser (par ex entre 10 projet au lieu de 100). Ainsi, le modèle pourrait s'énnoncer comme suit dans une logique bottom-up (et ce point est encore un changement par rapport à l'existant où l'on raisonne top down et en bloc projet / versus bottom up et à la story) :

  1. les stories sont priorisées par le PO dans chaque projet,
  2. les 10 projets de chaque portefeuille (avec leurs stories à valeur ajoutée mises en valeur) sont comparés et priorisés par les portfolio managers qui répartissent les ressources en % entre les projets en fonction de la valeur apportée (contribution stratégique, rustinage urgent...) et dans une logique kanban (pas plus de tant de projets / d'équipes en simultané et à temps plein
  3. les 10 portfolio managers vont eux-même négocier un tantième des ressources de l'organisation en défendant la valeur (et non le budget) de leur portefeuille devant le comité stratégique des systèmes d'information. Et ceci sur un rythme trimestriel correspondant aux releases (4 x 3 semaines = 3 mois +/- epsilon). Sur ce point là, il y a encore un changement puisque dans le monde traditionnel (ex. PMI, Prince 2...), l'alignement stratégique est fait tous les trois ans (schéma directeur) puis réactualisé à la marge (20%) tous les ans... puis "optimisé" chaque trimestre (réallocations tactiques selon les retards ou avances de projets, selon la sur ou sous-consommation, selon les effets de taquets en cas de retard d'un projet d'un programme sur les autres projets du programme).
Personal tools