lundi 24 septembre 2012

L'évaluation des coûts des projets, une compétence oubliée?


En faisant un peu de ménage dans mon bureau je suis tombé sur un vieux support de formation en "Gestion de projets informatiques" de Cap Sesa Institute (avant de rajouter Gemini et Sogeti dans son nom, mais déjà avec l'as de pique comme logo). Un séminaire de 3 jours au Sofitel Paris du 18 au 20 Juin 1990. Pas tout jeune.

Je l'ai feuilleté machinalement quand j'ai réalisé qu'après les préliminaires sur ce qu'est un projet, plus du tiers du support traite de l'évaluation de la réalisation et du chiffrage des projets. Le reste sur l'organisation des équipes.

Je fonce sur Google trouver des programmes de formation en gestion de projet sur 3 jours, et mon intuition se confirme, en 2012 il n'y a presque rien sur l'évaluation des coûts et de la réalisation. Tout porte aujourd'hui sur l'organisation, les équipes, la motivation, la conduite des changements, le suivi budgétaire... bref, sur la mise en œuvre et pas sur la préparation.

C'est vrai que la presse informatique de l'époque était échaudée par des dérapages de grands projets comme celui de l'US Air Force estimé à $1,5 millions, contractualisé à $400.000 (ils sont forts ces acheteurs!) et qui a terminé à $3,7 millions. En cause, la concurrence entre sociétés prêtes à tout pour remporter des marchés prestigieux, l'oubli de tout ce qui n'était pas indispensable... comme la documentation (sic!) et surtout l'inexpérience pour évaluer et piloter ces projets.
Les années 1990 c'est aussi la publication du rapport célèbre, « The Chaos Report », publié par le Standish Group, qui établissait que le taux d'échecs des projets observé aux États-Unis entre 30 et 40 % selon la taille des entreprises.

Dans un tel contexte, les méthodologies et l'estimation des projets était quelque chose d'essentielle et figurait en bonne place dans toutes les formations de jeunes chefs de projets.
On y apprenait :
  • le mythe de l'homme mois de Frédéric Brooks, expert en génie logiciel, dont il reste de nos jours le célèbre adage: "on ne fait pas un enfant avec 9 femmes pendant 1 mois" et la fameuse Loi de Brooks " Ajouter des ressources humaines à un projet en retard sur les prévisions ne fait qu'accentuer ce retard"...

  • la précision sur les estimations qui dépend de la phase (on estime avec moins de précision dans les phases amont par rapport à après la conception). D'où l'importance de faire de la réévaluation des estimations au fur et à mesure de l'avancement du projet. Aujourd'hui je vois passer beaucoup d'estimation de projets, peu prennent du recul sur la précision de l'estimation, voire nombreuses maximisent l'estimation pour y intégrer la marge d'erreur de la précision (on dit "avoir du gras, non?")

  • et surtout les nombreuses méthodes d'évaluation de l'époque, dont peu sont encore utilisées systématiquement. Elles sont classées par type :
  1. Le modèle algorithmique qui repose sur l'hypothèse que le coût est fonction d'un certain nombre de variables,

  2. Le jugement d'expert, ou de plusieurs et la recherche d'un consensus quand les chiffres sont ensuite partagés entre experts. Une très belle application de l'intelligence collective et des réseaux sociaux d'entreprise que je n'ai pas encore rencontrée,

  3. L'analogie ou la référence a des projets comparables, ce qui suppose d'avoir une base de données de ces projets et surtout d'avoir effectué un retour d'expérience à la fin des projets pour comparer avec le réalisé... pas avec le prévisionnel.

  4. La loi de parkinson exprimée en 1958 bien avant les projets informatiques dans les entreprises qui dit que le coût est fonction des ressources disponibles et donc que le travail s’étale de façon à occuper le temps disponible pour son achèvement !
    Pas faux dans certains cas et je suis un partisan du corollaire qui consiste a dire qu'avec moins de ressources on a des équipes plus "créatives" pour trouver des solutions plus simples... Les plus branchés parleront du "design to cost" et ceux qui s'intéressent à la théorie de l'évolution des espèces et à Darwin y retrouveront des analogies. Combien on est prêt à y mettre (ROI, délais...)? Qu'est-ce qu'on peut faire pour ce prix là?

  5. La meilleure offre qui est la seule démarche généralisée qu'il reste en 2012 et dont on connait les limites. Avec ses travers quand on oubli que la qualité de l'évaluation repose sur la réelle mise en concurrence e sur la non communication de son budget. Que penser des chefs de projets qui pour chiffrer un projet demandent une offre à une seule société de service, pressés par les délais...

  6. La méthode globale ou "top down". On estime le coût global, avec des experts par exemple, puis on applique des ratios de décomposition pour chacune des phases. Cela permet ensuite en fonction des ressources disponibles d'en faire le calendrier. Ex. une conception de ne doit pas coûter plus de 30% d'un projet par exemple.

  7. Les méthodes analytiques ou "bottom up", qui estiment individuellement chaque composant de façon détaillée, puis le coût global pas agrégation. C'est une démarche que l'on rencontre encore de nos jours dans les équipes projets plus chevronnées. Les fameux "points de fonctions d'Albrecht" l'unité d’œuvre fonctionnelle couplée à l'évaluation de la complexité de réalisation et à des ratios en fonction des technologies employés et déterminés par retour d'expérience de projets précédents.
    Et qui se souvient encore de la méthode COCOMO pour "Constructive Cost Model" dont l'ouvrage de référence a été publié en 1981?

En bref, une matière riche qui avait même ses règles d'or. Je vous en livre quatre:
  • Eviter de deviner : prendre le temps de réfléchir , ne jamais répondre sans avoir étudier la situation calmement
  • Prévoir du temps pour l'estimation et la planifier
  • Utiliser des données de projets précédents
  • Prendre l'avis des développeurs qui vont effectivement effectuer le travail
En 2012, l'évaluation des projets ne me semble plus une discipline aussi bien maîtrisée par la majorité des chefs de projets. On parle beaucoup de coûts en euros mais peu en unités d’œuvre. Et parfois on est même prêt accepter que ça coûte cher si c'est livré rapidement... ça ne vous rappelle pas une règle qui dit l'inverse ;-)

L'évaluation des projets n’intéresserait-elle plus que les responsables des risques dans les SSII, au point de ne figurer qu'en version très allégée dans les programmes de formation?

C'est vrai que c'est un peu la fin des grands projets, du moins les entreprises hésitent à les engager et les préparent peut être mieux. Et puis avec les progiciels d'abord puis le SaaS maintenant, ont a réduit la part de développement spécifiques qui rendaient incontournables ces méthodes. Enfin le développement des approches agiles qui visent aussi a réduire l'effet tunnel et donc finalement à maitriser l'évaluation en la concentrant sur quelques fonctions à chaque round.

Mais développement logiciel ou pas, les projets et leur complexité restent. L'estimation précise de leur réalisation doit toujours être appréciée. Et je ne sais pas pour vous mais ce vieux manuel me fait prendre conscience qu'on est quand même moins au point que nos anciens.

Qu'est-ce que vous en pensez?
Quelle est votre expérience sur le sujet?


NB: Et pour les collectionneurs ou les nostalgiques qui voudraient ce collector de 1990 et la méthode Expert de Sogeti complète dans son coffret d'origine de 1985... dites le moi je les mettrai sur eBay ;-)

SHARE THIS

2 commentaires: