Il existe peu d'études publiques sur la prévision des coûts et délais de mise en place de progiciels; et pourtant les éditeurs et les intégrateurs ont aujourd'hui une bonne précision sur les devis qu'ils fournissent à leurs clients. Leur approche, fondée sur une démarche analytique et paramétrique, est spécialisée par progiciel (liste des activités de la WBS, clases de paramètres et fonction de calcul associées). Elle possède de plus le redoutable défaut de rester confidentielle.

Seul, à ma connaissance, le Software Engineering Institute entretient un travail constant et public sur ce domaine, dénommé l’initiative CBC (COTS Based Systems Initiative). Dans ce cadre, a été  publié un rapport “A Process for COTS Software Product Evaluation “, accessible gratuitement et décrivant une approche raisonnable de l’estimation des progiciels.  N’y cherchez pas un abaque simple à utiliser ou une méthode de calcul « presse bouton », mais plutôt une démarche raisonnée.

Il existait un modèle adapté de COCOMO et appelé COCOTS qui voulait fournir une solution de calcul ; cette approche n’est plus « maintenue » aujourd’hui.

Certainement pas un miracle, les recettes s’en sont perdues. L’auditeur peut par contre apporter un concours important aux parties prenantes du projet :

- Un état des lieux complet et synthétique, distinguant clairement les causes structurelles des problèmes et leurs raisons conjoncturelles, sans avoir besoin de désigner des responsabilités (des coupables !)

- Un raisonnement comparatif et justifié sur les axes de solution envisageables, avoir le droit de ne fermer a priori aucune porte, y compris l’arrêt, la réorientation ou la redynamisation du projet.

- Et surtout une capacité à expliquer et faire entendre à différents niveaux, y compris aux acteurs impliqués et à leur hiérarchie.

Les trois conditions fondamentales d’une bonne opération d’externalisation :

- Donner au partenaire (la société choisie) les moyens d’être un bon professionnel : réussir un appel d’offre détaillé et rapide, mettre en place des processus internes clairs et efficaces (demandes, réception, coopération, suivi)

- Négocier un contrat solide et motivant : un mécanisme d’évolutions bien dimensionné, des objectifs Qualité utiles reposant sur des indicateurs simples et pertinents, des moyens de management opérationnels et pouvant gérer facilement les évolutions continues.

- S’investir sur l’opération : le plan de travail des ressources internes sur la phase de transition, une appropriation des nouveaux processus par la conduite du changement en interne, le temps et les outils pour manager le contractant.

Identifier les risques n’est pas, à proprement parler, une tâche d’un projet (i.e. Effort identifié dans la WBS, situé dans le temps du projet par rapport aux autres tâches), mais une activité associée à la conclusion de tâches, telle que préparation ou revues d’un élément déterminant du projet (Plan projet, Cahier des charges, Spécifications, Dossier d’architecture, Plan de validation, de déploiement,…) ou une activité régulière des réunions de conduite opérationnelles du projet.

Evaluer un risque, demande par contre, un temps alloué, de une heure à 0,5 jour par risque. La définition des moyens de maîtrise du risque peut aller de la simple re-planification des tâches Projet à l’étude complète d’un plan, y compris sous ses aspects techniques et coûts. Le suivi du risque est une activité de même nature que l’identification (et non une tâche).

En synthèse, gérer les risques représente un effort faible, que l’on peut estimer en moyenne à un jour par risque. Les projets qui ne gèrent pas leurs risques investissent un effort différent à la résolution de leurs problèmes : crises, retards, surcoûts,… Mais on peut toujours prendre le risque de n’avoir aucun problème !

Le standard de référence du Plan Projet est l’IEEE Std 1058-1998, « IEEE Standard for Software Project Management Plans ». Un Plan projet décrit les livrables du projet, les processus techniques et de gestion, les ressources du projet et les autres plans nécessaires à la réalisation du projet. Son but est de permettre à tous de travailler dans la même direction en expliquant les règles et particularités du projet. C’est donc, avant tout, un outil de communication, et éventuellement une base de contrôle.

La norme ISO 10005:2005 « Lignes directrices pour les plans qualité » décrit les plans qualité élaborés pour un processus, un produit, un projet ou un contrat et pour toute catégorie de produits (matériels, logiciels, produits issus de processus à caractère continu et services). Elle donne un cadre générique en précisant les dispositions à mettre en œuvre pour des actions spécifiques telles qu’un projet, en conformité avec une démarche qualité globale dans l’entreprise ou l’unité opérationnelle.

Les deux documents visent les mêmes objectifs et ne doivent donc pas se superposer ; le référentiel du contexte de réalisation du projet implique le choix de l’un ou de l’autre pour une finalité fondamentalement identique.