Démocratisation des méthodologies de projet en Francestatic.iquesta.com/fichiers/theses/Informatique/democratisation... · Amiet Cindy Exia.Cesi 2010 Démocratisation des méthodologies

Démocratisation des méthodologies de projet en France

Démocratisation des méthodologies de projet en France Page 0

Démocratisation des méthodologies de projet en France En quoi les méthodologies de projet peuvent, de manière complémentaire, améliorer la gestion d’un service et des projets informatiques ? 30/05/2010 Exia.Cesi Cindy Amiet

Amiet Cindy Exia.Cesi 2010


Sommaire

I) PREAMBULE .................................................................................................................................. 2

II) INTRODUCTION ............................................................................................................................. 3

III) ETAT DES LIEUX ............................................................................................................................. 5

1) EN FRANCE VS L’INTERNATIONAL : LES ENTREPRISES GRANDS COMPTES ....................................................... 5

2) PROBLEMES RENCONTRES ................................................................................................................. 8

IV) UN BESOIN DE CHANGEMENT ..................................................................................................... 11

1) LA PRISE DE CONSCIENCE : L’IMPASSE DES DSI .................................................................................... 11

2) EXPERIENCE D’UN SERVICE .............................................................................................................. 15

V) APPORTS DES METHODOLOGIES DE PROJET ............................................................................... 18

1) DEUX METHODOLOGIES : CMMI ET PMI ........................................................................................... 18

2) CORRELATION ENTRE LES PRATIQUES CMMI ET LES PROCESSUS PMI® ...................................................... 21

3) PARAMETRES DE MISE EN PLACE ....................................................................................................... 25

VI) EXPERIMENTATION ET PERSPECTIVES ......................................................................................... 27

1) UN TERRAIN D’EXPERIMENTATION .................................................................................................... 27

2) PERSPECTIVES : AUTRES METHODOLOGIES .......................................................................................... 31

VII) CONCLUSION ............................................................................................................................... 32

VIII) GLOSSAIRE .............................................................................................................................. 33

IX) BIBLIOGRAPHIE ........................................................................................................................... 34

X) ANNEXES ..................................................................................................................................... 36

1) ENQUETE D’UN CHEF DE PROJET SUR LES METHODOLOGIES DE PROJET ....................................................... 36

2) MATRICE PMI® ........................................................................................................................... 38



I) Préambule Actuellement en troisième cycle Architecture en management des systèmes

d’informations, j’ai effectué mon cursus complet de cinq ans dans le centre Exia.Cesi.

J’ai tout d’abord obtenu le diplôme d’Analyste programmeur (Bac +2) puis de

Responsable en ingénierie des logiciels (Bac +4). Les quatre années ont été validées par

plusieurs stages en entreprise, lors desquels j’ai principalement été responsable des projets

qu’on m’a confiés, en effectuant l’analyse fonctionnelle et technique puis les

développements ainsi que l’intégration dans les systèmes d’information existants.

Mon dernier stage a débouché sur un CDD en parallèle de mes études, étant donné

que le projet consistait en la mise en place d’un progiciel de gestion adapté à une entreprise

de location et de services financiers. Au cours de mes différents contrats chez eux, j’ai

procédé à l’analyse métier, technique et financière du projet, puis au vu de l’ampleur des

développements, j’ai demandé à être assistée par des développeurs. J’ai alors pris en main la

gestion du projet dans son ensemble, sans avoir de réelle formation au préalable, bien que

mon cursus m’ait permis d’avoir des notions en pilotage de projet. J’ai alors compris la

nécessité d’avoir en main une méthodologie de projet, permettant de structurer chaque

phase et fournissant des outils et techniques pour chacune d’entre elles.

J’ai donc effectué ma cinquième année au sein du même centre, afin de préciser mes

aptitudes à la gestion de projet et ainsi justifier d’une première expérience ainsi que de

connaissances en méthodologies. Cette année de formation a comme fil rouge la

méthodologie PMI®, qui nous a été enseignée par un expert certifié PMP®.

Le but du dernier stage est de valider l’application de cette méthodologie au sein d’une

entreprise. Je participe alors à la mise en place de bonnes pratiques et suis confrontée aux

mêmes problèmes rencontrés dans tous les projets : la résistance au changement !

Suite à ces différentes expériences professionnelles, j’ai décidé de présenter une thèse

sur les méthodologies de projet en France, afin de compléter mes connaissances dans ce

vaste sujet et de présenter une corrélation entre deux méthodologies qui me semblent être

les plus bénéfiques dans les entreprises et le contexte d’aujourd’hui : CMMI et PMI®.

Par la suite, je souhaite me spécialiser dans la gestion de projet de développements

informatiques mettant en œuvre des processus qualité, puis créer ma propre structure dans

ce domaine.

« L'homme n'est rien d'autre que son projet, il n'existe que dans la mesure où il se réalise. »

Jean-Paul SARTRE



II) Introduction "En décrétant le changement, l'immobilisme s'est mis en marche, et je ne sais plus comment l'arrêter."

Edgar FAURE, Déclaration en tant que Ministre de l'Education, 1968

Contexte

Au début des années 1980, un constat a été effectué sur des projets informatiques du

Département de la défense des Etats-Unis : seulement 2% avaient été utilisés tels que livrés

et 50% n’avaient pas été utilisés avec succès. A partir de là ont été mises en place des

méthodes pour évaluer les capacités des prestataires engagés pour ce type de projets,

permettant de choisir la maîtrise d’œuvre sur des indicateurs fondés. Les entreprises nord-

américaines ont été les premières à les appliquer, suivies des entreprises indiennes puis

européennes.

Aujourd’hui, les outils de gestion sont de plus en plus impliqués dans les services

administratifs et financiers ainsi que dans l’aide à la décision. Au sein des PME, leur mise en

place en interne est de plus en plus fréquente, suite à un trop grand nombre de pertes dues

à l’utilisation d’outils externes et génériques. Ces outils se doivent alors de répondre au

mieux aux besoins fonctionnels et stratégiques, c’est pourquoi ils nécessitent une gestion

plus claire et surtout suivie.

Que ces outils soient mis en place en interne ou choisis sur le marché, ils demandent

une mobilisation, souvent de longue durée, de ressources humaines et budgétaires. C’est

pourquoi les responsables de services doivent justifier de leurs besoins auprès de la

direction.

Depuis une dizaine d’années, on remarque une instauration progressive de différentes

méthodologies de projet au sein des entreprises grands comptes, principalement les sociétés

de services et d’intégration logicielle. On y retrouve les méthodes AGILE, avec Scrum ou

Lean, CMMI ou encore PMI®. Elles apportent toutes un aspect qualité, managérial ou

organisationnel et sont le plus souvent complémentaires. En effet, une fois une de ces

méthodologie intégrée, les besoins de résultats deviennent plus précis et certains

responsables préfèrent adapter leur application en fonction.

Problématiques

Ces constatations montrent une détermination des entreprises françaises à contrôler

leur gestion de projets informatiques à l’aide de bonnes pratiques, tout en se certifiant. Cela

leur permet non seulement de rester crédibles auprès des clients et utilisateurs, mais aussi

d’assurer une stabilité sur le long terme de leur service et du suivi de leurs projets.

Si les entreprises sont aujourd’hui convaincues par ces méthodologies de projet,

pourquoi se sont-elles démocratisées si tard en France ?



Malgré de multiples preuves de leurs bénéfices, leur application au sein des services

n’est pas encore chose faite. Les managers informatiques ressentent pourtant ce besoin,

pourquoi sont-ils de plus en plus concernés par ces méthodologies ?

Objectifs

Cette thèse est destinée à montrer l’apport de deux méthodologies de projet prisées

et naturellement complémentaires.

J’exposerai dans un premier temps un état des lieux des entreprises françaises,

permettant d’amener dans un deuxième temps à la prise de conscience des directeurs de

systèmes d’informations. Afin d’étayer mes propos, j’utiliserai l’expérience d’un service

d’intégration logicielle avec l’exemple d’un projet qui a été abandonné, non pas pour des

raisons stratégiques mais réellement par manque de méthodes. Cet exemple sera complété

par différents témoignages de personnels directement intéressés par ces méthodes de

gestion de projet : le directeur du système d’information et le responsable qualité.

Dans un troisième temps, j’établirai une corrélation entre les deux méthodologies de

projet CMMI et PMI®. Elle sera complétée d’une parole d’expert senior CMMI, qui a bien

voulu répondre à une interview sur les apports de ces bonnes pratiques lors de ses

différentes expériences de mise en place de cette méthodologie. Afin de prouver leur

complémentarité, je les ai mises en œuvre en les adaptant à un projet de développement au

sein du service cité précédemment.

Plusieurs méthodologies existent, c’est pourquoi, afin de ne pas limiter les possibilités

aux deux que j’ai expérimentées lors de mon séjour en entreprise, j’ai souhaité identifier les

apports possibles des autres, peut-être plus adaptées au service que j’ai intégré. Je les

présenterai dans la dernière partie.

Limites et méthodologie

Le cadre de cette thèse est limité au fonctionnement des entreprises grands comptes

en France, en se concentrant sur la gestion de leur service informatique et de leurs projets.

Etant donné la récente prise de conscience des directeurs de systèmes d’informations, ce

mémoire prend en compte les éléments et évolutions depuis 2003. Le contenu de ce

document se base principalement sur des articles de presse (01net, Journaldunet, BPM

Channel et blogs de DSI), sur les guides (officiels ou non) des méthodologies étudiées et sur

plusieurs témoignages d’experts et de professionnels.



III) Etat des lieux Avant de juger la réussite des projets informatiques, il faut préciser sur quels critères

nous devons les évaluer. Un projet pourra être considéré comme un succès s’il est effectué

dans les temps, que les budgets sont respectés et qu’il correspond aux spécifications

définies au départ.

1) En France vs l’international : les entreprises grands comptes

Depuis 2003, les constats internationaux révèlent des chiffres alarmants pour les

projets au sein des SSII1, dont les échecs répétitifs sont bel et bien prouvés. On parle même

d’exception pour un projet réussi. En effet, non seulement les objectifs fonctionnels sont

rarement atteints, mais les délais de mise en place sont tels que les budgets sont largement

dépassés.

D’après une étude réalisée par Standish Group2, le taux de réussite des projets en 2004

était seulement de 30%, 50% étaient livrés mais au moins un des critères n’était pas

respecté et 20% pouvaient être qualifiés d’échec (abandonnés, obsolètes ou jamais utilisés).

Les entreprises françaises spécialisées dans le pilotage de projets informatiques

expliquaient en 2003 que ce problème était dû au « boum » des demandes d’intégration,

entraînant les offres logicielles à se diversifier et les termes métier à se démultiplier, menant

ce monde à une complexification des systèmes informatiques que les gros acteurs n’ont pas

su gérer.

Bien que les chiffres diffusés soient de meilleur augure, les entreprises considèrent-

elles le succès d’un projet de la même manière ? Prennent-elles toutes les mêmes

paramètres et critères en compte ? On remarquera que ce n’est pas toujours le cas. Les

projets informatiques ont leur fidèle réputation d’être des gouffres financiers et ceci sur une

longue durée. Les mentalités ayant évoluées, les clients et utilisateurs s’attendent à un

dépassement des budgets et délais, donc les entreprises y portent moins d’attention.

Gezinus Hidding3 explique dans un article sur le site InfoBoom4 que le respect des

spécifications fonctionnelles est plus important que le dépassement des délais. On peut

même observer que pour certains projets, l’aspect budgétaire est à peine suivi, pouvant

impliquer des remises en question au cours du projet ou des dépassements conséquents du

budget ou des délais sans réelles justifications.

1 SSII : société de services. Dans ce document, les SSII citées ne seront que des grands comptes.

2 Standish Group est une société américaine effectuant des enquêtes et des rapports sur le management

de projets informatiques. L’étude est disponible à l’adresse suivante :

http://www.cs.nmt.edu/~cs328/reading/Standish.pdf

3 Gezinus Hidding est professeur dans une université de management à Chicago

4 Article datant de février 2010 : http://www.theinfoboom.com/fr/pov/expert/réduire-le-taux-déchec-

des-projets-it-grâce-à-un-leadership-à-valeur-ajoutée-change-leade?from=search

http://www.cs.nmt.edu/~cs328/reading/Standish.pdf

http://www.theinfoboom.com/fr/pov/expert/r%C3%A9duire-le-taux-d%C3%A9chec-des-projets-it-gr%C3%A2ce-%C3%A0-un-leadership-%C3%A0-valeur-ajout%C3%A9e-change-leade?from=search

http://www.theinfoboom.com/fr/pov/expert/r%C3%A9duire-le-taux-d%C3%A9chec-des-projets-it-gr%C3%A2ce-%C3%A0-un-leadership-%C3%A0-valeur-ajout%C3%A9e-change-leade?from=search



Nous pouvons tout de même constater depuis ces dernières années une belle

évolution dans certains pays, notamment en Inde, où la plupart des projets sont une réelle

réussite. Cette observation se démontre grâce à une augmentation du chiffre d’affaires des

SSII indiennes et à une confiance accrue des entreprises internationales, comme Steria, dont

le président directeur général affirme en 2008 que « Certains projets informatiques sont

réalisés à hauteur de 70 % par nos ingénieurs en Inde car le taux de réussite des projets

informatiques menés par la SSII indienne est élevé »1.

En 2008, le constat a quelque peu évolué. IBM publie une étude réalisée auprès de

1500 directeurs informatiques qui révèle que les projets menés à l’aide de méthodologies

structurées augmentent leur taux de réussite jusqu’à 50%.

Un autre point permettant de mesurer l’état des projets informatiques est la

satisfaction des utilisateurs.

Pour tout acteur d’un service informatique, la satisfaction du demandeur, qu’il soit

utilisateur ou client2, est le but premier. Or, on constate3 que la plupart ne sont pas satisfaits

du service rendu. Pourquoi ?

Différentes raisons peuvent expliquer ce mécontentement. D’une part, le manque de

communication de la part du service auprès des utilisateurs provoque un questionnement

constant sur l’avancement du projet ou la compréhension des besoins fonctionnels. D’autre

part, les utilisateurs ont du mal à concevoir le fait que la mise en place d’un outil

informatique ne soit pas un système « tout automatisé ». Or, pour les traitements

complexes, même les solutions les plus optimisées demandent une action de la part de

l’utilisateur, ce qui provoque une sorte de frustration dans son attente d’automatisation.

De plus, il est fréquent que les utilisateurs se créent des outils complémentaires à

l’aide de logiciels bureautiques courants, afin de pallier à l’écart fonctionnel de la solution

face à son besoin réel. D’après une publication de 2008 sur le site bestpractices-si, cette

précision est une des réponses au problème des enquêtes de satisfaction utilisateurs, qui ne

sont pas toujours significatives.4

1 Article datant de 2008 concernant la nouvelle stratégie de développement de l’entreprise Steria suite à

une baisse des demandes de services informatiques : http://www.jdf.com/analyse-

financiere/2008/09/13/04012-20080913ARTHBD00149-steria-peut-tirer-son-epingle-du-jeu-dans-un-contexte-

difficile.php

2 Deux notions bien distinctes : dans le cas d’un service informatique interne, l’utilisateur est également

interne à la société, il n’achète pas le produit. Dans le cas d’une société de service, le client est celui qui achète

le produit et il est également utilisateur.

3 Constatation effectuée à partir de plusieurs articles sur http://www.bpm-channel.com

4 http://www.bestpractices-si.fr/index.php?option=com_content&task=view&id=42&Itemid=73

http://www.jdf.com/analyse-financiere/2008/09/13/04012-20080913ARTHBD00149-steria-peut-tirer-son-epingle-du-jeu-dans-un-contexte-difficile.php



http://www.bpm-channel.com/

http://www.bestpractices-si.fr/index.php?option=com_content&task=view&id=42&Itemid=73



Nous verrons en détail les problèmes rencontrés avec les utilisateurs plus loin dans ce

développement.

Suite à tous ces constats effectués par les entreprises françaises, les SSII ont décidé de

structurer leurs services et principalement leur pilotage de projets. Ces démarches étant

généralement longues et bien qu’elles aient été lancées pour la plupart en 2003, les

bénéfices ne sont pas encore visibles chez toutes les entreprises. D’après un article datant

de mai 2006, la majorité des SSII avaient comme objectif l’atteinte du niveau 3. Nous

retrouvons des exceptions au sein des entreprises grands comptes ayant anticipé cette

évolution vers le management par processus, comme IBM France, certifié niveau 5 en

novembre 20051 (niveau optimal de la certification CMMI, qui demande une démarche

d’amélioration constante de ses processus).

L’entreprise Standish Group mène régulièrement des enquêtes sur la gestion des

projets et en ressort des taux de réussite généraux. Bien que leurs enquêtes soient

controversées par certains acteurs2, leurs résultats sont tout de même parlants. Ci-dessous

un graphe représentant l’évolution des taux de réussite et d’échecs des projets

informatiques en France3 dans le temps.

On remarque sur ce graphe une baisse du taux d’échec et une remontée du taux de

réussite jusqu’en 2006, moment où les différents taux s’équilibrent. Si la tendance s’est

inversée, c’est principalement dû au contexte économique et malheureusement les

entreprises avaient fait des coupes de budget aux mauvais endroits.

1 Source IBM http://costkiller.net/actu/actu-IBM-CMMI5-niveau-CMMI-5-evaluation-activites-

developpement-maintenance-applications-logicielles.0512.htm

2 Méthodes d’enquête controversées car ne sont pas publiées. Certains estiment donc qu’elles ne sont

pas fiables.

3 Données récupérées des enquêtes de Standish Group reprises et commentées dans un document

hollandais de focus sur le management de projet http://www.few.vu.nl/~x/chaos/chaos.pdf.

0%

10%

20%

30%

40%

50%

60%

1995 2000 2004 2006 2009

Evolution des taux de succès des projets

Succès

Mitigés

Echec

http://costkiller.net/actu/actu-IBM-CMMI5-niveau-CMMI-5-evaluation-activites-developpement-maintenance-applications-logicielles.0512.htm

http://costkiller.net/actu/actu-IBM-CMMI5-niveau-CMMI-5-evaluation-activites-developpement-maintenance-applications-logicielles.0512.htm

http://www.few.vu.nl/~x/chaos/chaos.pdf



Nous pouvons en conclure qu’en ce qui concerne la qualité logicielle (réussite des

projets, satisfaction clients), trois secteurs géographiques ressortent aujourd’hui : les Etats-

Unis, l’Europe et l’Inde. Les Etats-Unis mettent en place différents outils de gestion de

projets et sont actifs dans ces démarches, mais chacun adapte ces pratiques en fonction de

son environnement. Il en résulte que les écarts de taux de réussite d’une entreprise à l’autre

sont encore importants, notamment en France, où ces taux restent bas. Les entreprises

françaises ont aujourd’hui été devancées par les entreprises indiennes ou nord-américaines

en ce qui concerne la qualité de gestion des projets informatiques, amenant rapidement à la

délocalisation des prestations de développement logiciel.

2) Problèmes rencontrés

« La perfection des moyens et la confusion des buts semblent caractériser notre époque. »

Albert EINSTEIN

Nous sommes dans une période où les entreprises sont apprenantes, les évolutions

organisationnelles et techniques sont constantes, il faut donc répondre à ces changements

tout en gardant une stabilité au sein des services.

La plupart des méthodologies de projet sont développées aux Etats-Unis par des

instituts spécialisés dans la recherche, ce qui prouve un désir et un besoin certain d’évoluer

sur la gestion par les processus. Cela devrait leur permettre d’avoir un temps d’avance sur

leur mise en place, or nous pouvons observer que ce ne sont pas forcément les mieux

positionnés en matière de maturité.

Pourquoi les projets les plus stratégiques sont ceux qui connaissent le plus d’échecs ?

Deux causes, deux responsables : le changement non assuré, des acteurs peu impliqués ;

direction absente et utilisateurs indisposés à accepter cette évolution.

Gestion du changement

L’évolution d’une solution informatique peut être vivement attendue, comme elle peut

sembler inutile.

Elle sera attendue par les utilisateurs soutenant une automatisation maximale de leurs

tâches et qui expriment alors des besoins en surabondance. Ils attendent alors un

changement radical de leur outil de gestion et des performances identiques aux gros

systèmes, que le service informatique ne pourra pas satisfaire à 100%. Ce dernier se

retrouve donc face à un dilemme de recadrage des besoins sans devoir procéder à des

coupures franches. Une fois livrée, la solution ne correspond pas aux attentes des

utilisateurs et demandera un effort accentué pour leur formation et leur adaptation.

Elle semblera inutile si l’application actuelle répond aux besoins des utilisateurs. En

effet, en modifiant les habitudes des utilisateurs, nous touchons à leur confort de travail,

provoquant la plupart du temps une réticence vis-à-vis du nouveau système. Si les raisons de



cette évolution ne sont pas clairement exprimées aux utilisateurs, ils resteront dans

l’incompréhension (« Pourquoi changer ? ») et ne seront pas disposés à s’adapter à la

solution fournie.

Dans les deux cas, des utilisateurs non préparés au changement deviennent des

utilisateurs insatisfaits potentiels.

L’erreur principale des entreprises jusqu’à ces dernières années, a été de subir le

changement, ou de ne l’appliquer qu’à la qualité ou aux principes d’administration, sans

prendre en compte un autre facteur important : le manque de maturité des utilisateurs.

Philippe RIGAIL présente les raisons de ce dilemme sur son site web en définissant l’étape

cruciale d’un projet informatique : « De l’expression à l’analyse des besoins dans les systèmes

d’information »1. Bien que publié en 2001, on observe que cet article reste d’actualité

lorsque des études sont encore effectuées en 2010 pour prouver que la gestion du

changement est la clé de réussite des projets2.

Nous pouvons conclure avec certitude que gérer le changement n’est pas seulement

bénéfique pour le projet en cours, mais apporte également une facilité de communication

pour les projets à venir et augmente ainsi la satisfaction des utilisateurs. Les entreprises

doivent alors miser sur un échange constant entre le service informatique et les utilisateurs

finals pour s’assurer de la réussite de leurs projets.

En parallèle, les pratiques de gestion de projet conseillent la mise en place de gestion

du changement et pour cela proposent des directives afin d’atteindre des objectifs

d’adaptation plus certains.

Manque d’expérience

Un autre problème majeur qui accentue l’échec des projets est une mauvaise

intégration des compétences au niveau du pilotage de projets.

Les ingénieurs techniques sont souvent promus en tant que chef de projet grâce à une

libération de ce poste suite à un départ à la retraite ou imprévu. L’avantage de ces situations

est que l’ingénieur technique est plus capable de déterminer les délais de développement ou

de mettre en place une architecture technique adaptée aux besoins de la solution.

L’inconvénient est, justement, leur expertise technique. Ils manquent généralement de

formation au pilotage de projet et ne l’initialiseront pas de la même manière qu’un

informaticien doté de la double compétence technique-management.

1 Article publié dans la revue La Valeur http://www.formes-et-technologies.com/publications.html#ch3

2 Société Audaxis http://www.audaxis.com/Actualites/La-gestion-du-changement-cle-de-reussite-d-un-

projet-ERP

http://www.formes-et-technologies.com/publications.html#ch3

http://www.audaxis.com/Actualites/La-gestion-du-changement-cle-de-reussite-d-un-projet-ERP




Comme le précise Nathan Y. HATTAB lors de son interview1, l’inexpérience du chef de

projet entraîne une imprécision du contenu et des limites du projet lors de l’établissement

des spécifications, amenant le projet à un dérapage budgétaire ou dans le temps, voire à un

échec. L’expert pensera à la solution technique et non à l’aspect métier, l’empêchant de

garder une vision d’ensemble sur le projet et ainsi prévoir et anticiper les risques.

Un bon développeur n’est pas nécessairement un bon chef de projet. Le problème

s’amplifie en inversant la phrase : un chef de projet doit être un bon développeur, afin

d’anticiper les délais, de suivre l’avancement technique du projet et d’obtenir le respect des

développeurs. De plus, ce sont le plus souvent les meilleurs développeurs qui sont amenés à

devenir chefs de projet, alors qu’ils ne souhaitent pas forcément être confrontés à toutes les

problématiques liées à leur nouveau poste.

Etre développeur et être chef de projet ne demandent pas les mêmes compétences, et

là encore, les entreprises doivent prendre une décision stratégique et non « personnelle »

dans le choix de leurs chefs de projet, car nous rencontrons très vite des exemples illustrant

le principe de Peter : « Dans une hiérarchie, tout employé a tendance à s’élever à son niveau

d’incompétence. ».

C’est alors que tout employé promu à un poste de chef de projet doit être formé aux

bonnes pratiques de gestion de projet, afin de balayer tous les domaines auxquels son poste

est rattaché.

Un échange sur le forum du site developpez.net développe cette problématique avec

différents témoignages de professionnels et expérimentés, dans lequel il ressort

effectivement que dans la plupart des entreprises, les développeurs deviennent chefs de

projet malgré eux (parfois même ne sont pas techniciens à la base), ou simplement par fierté

d’intitulé de poste (« consultant, chef de projet, architecte » sont des termes plus gratifiant

que « développeur informatique »).

Pour conclure ce point concernant le décalage des compétences, je citerai Nathan

HATTAB : « La certification des chefs de projets informatiques sera un symptôme révélateur

de la maturité des métiers de l’informatique et des systèmes d’information ».

1 Interview de Nathan Y. HATTAB, consultant en systèmes d’information :

http://www.afai.asso.fr/index.php?m=76




IV) Un besoin de changement

1) La prise de conscience : L’impasse des DSI

« Nous avons choisi de faire de la qualité parce que la chance est devenue trop chère »

Cédric FOULON – PMP - Evaluateur CMMI - Certifié ITIL

On a pu constater dans le chapitre précédent que l’insatisfaction des utilisateurs était

souvent due à un dérapage des fonctionnalités attendues. L’échec des projets est également

évalué sur les dépassements de délais ou de budgets. Pourquoi parle-t-on de manque de

crédibilité des DSI dans les entreprises françaises ?

On peut considérer qu’un projet se construit en quatre étapes avec les utilisateurs :

l’avant-projet, l’exécution, la vérification du contenu et l’après-projet. En impliquant les

utilisateurs finals lors de ces étapes, le risque de dérapage est moins grand. Or, aujourd’hui,

les reporting des projets sont principalement effectués en interne, les utilisateurs manquent

de visibilité sur les décisions d’implémentation des fonctionnalités, sur l’avancement du

projet et sur l’utilisation finale des solutions. Comme expliqué précédemment, la gestion du

changement n’est pas toujours assurée, provoquant alors des demandes de nouvelles

fonctionnalités à la volée ou des redéveloppements non prévus.

Lors du 12ème Salon des Solutions et Améliorations des performances en 2005

(SisQual1), le problème du mécontentement des utilisateurs est posé par la société ADELI. Il

en ressort principalement des problèmes de communication : incompréhension des

documents qu’ils doivent valider, manque de visibilité au cours de la vie du projet pour les

utilisateurs et pour la direction ou encore l’absence de suivi des processus qualité.

Dans une interview faite par Bernard Paquin en décembre 2009, Alain Gresse,

directeur informatique, explique que la mise en place d’une gestion du changement n’a pas

seulement permis une réussite accrue de leurs projets, mais également de « sortir le service

informatique de sa cave »2, se rapprocher des autres services et ainsi mieux comprendre les

besoins exprimés.

En ce qui concerne le périmètre fonctionnel des projets, prenons en exemple les

projets ERP. On peut constater des écarts significatifs entre les livrables attendus au

lancement du projet et ceux constatés à la fin, prouvant bien que le périmètre a évolué lors

1 Compte rendu de la présentation accessible via ftp : ftp://ftp2.adeli.org/adeli/lalettre/l61p6.pdf

2 Interview d’Alain Gresse par Bernard Paquin est disponible à l’adresse suivante :

http://www.paperjam.lu/archives/2010/01/1112_Techno_Alter_Domus/index.html

ftp://ftp2.adeli.org/adeli/lalettre/l61p6.pdf




de la mise en place. Ci-dessous une source de erp-infos.com1 qui montre la progression des

livrables et de leurs état au cours de la vie d’un projet spécifique jusqu’à une certaine date.

Les zones colorées permettent de visualiser facilement les écarts entre chaque états :

planifié, en cours de développement, en attente de validation (développé mais non testé),

sous réserve de validation (modifications à apporter) et validé. Leur épaisseur apporte des

informations complémentaires sur l’avancement du projet. Par exemple, l’épaississement de

la zone « Attente de validation » analysée en parallèle d’une faible croissance des livrables

validés, permet de déduire que le projet avance lentement et prend du retard. De plus, si on

compare le nombre de livrables planifiés au début du projet et le nombre validés à la date

arrêtée, on remarque bien un accroissement significatif des livrables attendus.

Cela démontre les manques de cadrages fonctionnels des projets tout au long de leur

cycle de vie, ce qui aura systématiquement des impacts sur leur planification et donc sur

leurs coûts.

La communication est un aspect sur lequel les directeurs de systèmes d’information

ont réagi du fait de dérapages trop fréquents des projets. Il leur faut maintenant intégrer

cette notion à leur service, leur permettant de s’assurer d’une équipe communicante auprès

des utilisateurs, tout en gardant le recul que demande leur place de DSI.

Afin que le service suive les instructions de communication sur le projet avec les

utilisateurs, le DSI devra s’appuyer sur des méthodes concrètes et qui ont été prouvées

comme bénéfiques.

Dans la plupart des entreprises grands comptes, la direction ne s’adresse jamais

directement au personnel informatique, certains même les dénigrent et sous-estiment les

1 http://www.erp-infos.com/info_article/m/976/des-methodes-et-des-outils-pour-assurer-la-reussite-

des-projets.html#top_article

http://www.erp-infos.com/info_article/m/976/des-methodes-et-des-outils-pour-assurer-la-reussite-des-projets.html#top_article

http://www.erp-infos.com/info_article/m/976/des-methodes-et-des-outils-pour-assurer-la-reussite-des-projets.html#top_article



problèmes qu’ils rencontrent. Le DSI doit avoir le rôle d’intermédiaire « tampon » entre son

service et la direction en remontant les différentes informations concernant les projets. Pour

cela, il doit obtenir des données concrètes de ses chefs de projet (durée, budget) et avoir

une visibilité sur le long terme afin de défendre ses projets et surtout son service.

Le contexte économique a principalement eu des impacts négatifs, notamment des

réductions de ressources humaines et financières, amenant à un ralentissement des projets

et donc une insatisfaction des clients. Le problème est que, par manque de budget, la

Direction n’autorise pas le déblocage de ressources s’il n’a pas accès à des justifications et

des données valables pour lui permettre d’évaluer les coûts et bénéfices monétaires des

projets.

De plus, il est bien connu que les projets informatiques dépassent les budgets prévus

pour différentes raisons. D’une part, l’initiateur du projet estimera les coûts à la baisse pour

s’assurer qu’il sera accepté. D’autre part, le budget est estimé pour un périmètre défini du

projet, qui a souvent tendance à être modifié au cours de sa mise en place, donc le budget

dérape également. Enfin, les chefs de projet manquent souvent de méthodologie et ne

remarquent pas toujours la dérive des coûts, la Direction est alors prévenue au dernier

moment et doit négocier pour obtenir une augmentation du budget alloué.

En reprenant l’exemple des ERP, on observe un pourcentage élevé en écarts de budget

et de délais. Une étude effectuée entre 2005 et 20101, sur un panel très large d’entreprises

(toutes les tailles et tous les continents), constate qu’en Europe, 57% des projets ERP

prennent plus de temps que prévu et 54% coûtent plus cher que prévu. En plus d’avoir la

réputation d’être un gouffre financier pour les entreprises, le retour sur investissement de

l’installation d’un ERP est difficilement mesurable, ou n’est pas calculé du tout par les DSI,

pour les raisons citées précédemment.

1 Article de février 2010 traitant des ERP : http://www.erp-infos.com/info_article/m/920/2010-erp-

report-du-panorama-consulting-group.html#top_article

http://www.erp-infos.com/info_article/m/920/2010-erp-report-du-panorama-consulting-group.html#top_article

http://www.erp-infos.com/info_article/m/920/2010-erp-report-du-panorama-consulting-group.html#top_article



Ci-dessous les résultats d’un autre point de l’étude réalisée, permettant de visualiser

les bénéfices de deux types de solutions : les ERP traditionnels et le SaaS1.

En moyenne, les deux solutions consomment le même budget du chiffre d’affaires et

satisfont la direction au même degré, à hauteur de 50%, pour une atteinte des objectifs

d’utilisation bien différente (20% d’écart). Quant au respect du budget, la solution ERP

traditionnelle reste la mieux placée avec 40% des projets restant dans le cadre de ce qui a

été planifié, contre 30% pour les projets SaaS.

Ces chiffres, bien qu’alarmants, se sont améliorés par rapport à l’étude de 2008, ceci

grâce au contexte économique qui a obligé les entreprises à mieux suivre les processus de

mise en place et donc réduire les retards et augmentations de budgets.

Pour cela, il a fallu instaurer des indicateurs et des tableaux de bord réguliers afin

d’obtenir des données concrètes sur l’avancement des projets. La Direction, à l’aide de ces

justifications plus précises acceptera plus facilement le lancement de projets ou l’attribution

de ressources.

Depuis 2003, les SSII françaises prennent conscience de leur retard sur les entreprises

indiennes, déjà à de hauts niveaux de maturité, et agissent activement dans l’application des

méthodologies de projet, notamment CMMI dans les services informatiques.

La DSI se doit donc d’assurer d’une part la satisfaction des utilisateurs en ouvrant le

service informatique aux autres pôles de l’entreprise, et d’autre part crédibiliser ses besoins

1 SaaS : Software As A Service. Solution proposant de s’abonner à un service plutôt que d’acheter une

licence, solutions full-web. Les clients ne paient pas pour posséder le logiciel mais pour l’utiliser

(http://fr.wikipedia.org)

http://fr.wikipedia.org/



et ses choix auprès de la direction. C’est pour ces raisons que, ces dernières années, les

méthodologies de projet se démocratisent dans les entreprises françaises.

2) Expérience d’un service

Le service informatique au sein duquel j’ai pu expérimenter l’apport des

méthodologies de projet met en place CMMI depuis deux ans. Ils souhaitent se certifier

niveau 2 à la fin de l’année.

Avant CMMI : interviews

Comment était organisé ce service avant cette décision ? Pour répondre à cette

question, j’ai interviewé le DSI et le responsable qualité1, les chefs de projet ont répondu à

une enquête publiée sur le web à l’adresse suivante http://www.mon-enquete-

enligne.fr/index.php?sid=69745&lang=fr.

Le DSI était à l’époque responsable du service développement, le responsable qualité

était chef de projet et avait principalement des tâches de développeur. Ils appelaient « chef

de projet » celui qui mettait en place la solution : recueil des besoins, développement et

livraison. Le responsable du service avait la place d’un directeur de projet, il était garant de

tous les projets lancés.

Il en ressort que, jusqu’à ce que les bonnes pratiques commencent à être mises en

place, les projets étaient suivis à l’aveuglette, bien que des outils de gestion de temps

étaient déjà utilisés. « Lorsque les utilisateurs avaient une demande ? Ils me la faisaient à la

machine à café » répond le DSI avec un peu de sarcasme, ils n’étaient ensuite en rien

impliqués dans le suivi du projet et finalement « ne découvraient une partie de ce qu’ils

avaient demandé qu’une fois la solution livrée » (responsable qualité).

Les projets n’étant ni chiffrés, ni cadrés, les utilisateurs pouvaient compléter leur

demande à leur bon vouloir. Le cycle de vie des projets à ce moment là est décrit par le DSI

de la manière suivante : « on fait, on voit, on ajuste ».

Lorsque je leur demande quels étaient les écarts qui ressortaient le plus, les deux me

répondent « on ne cadrait pas les projets, on ne faisait pas d’enquête utilisateurs, on ne

pouvait pas savoir s’il existait des écarts ». En précisant alors ma question sur le nombre de

projets abandonnés, la réponse est plus précise avec des exemples de projets qui ont été

abandonnés, après deux ou six mois de spécifications. On en arrive à la conclusion d’un

projet abandonné sur 37 lancés. Mais ce chiffre n’est pas significatif, il faudrait pouvoir

mesurer le temps perdu sur la redéfinition des besoins, les redéveloppements, le débogage

ou la refonte complète d’une solution qui semblait pourtant répondre aux attentes des

utilisateurs finals pour se rendre compte des écarts réels.

1 Les rôles cités des acteurs sont actuels. Avant CMMI, ils occupaient une autre place.

http://www.mon-enquete-enligne.fr/index.php?sid=69745&lang=fr

http://www.mon-enquete-enligne.fr/index.php?sid=69745&lang=fr



Il y a trois ans, le responsable de service a été promu en tant que DSI. Il était conscient

qu’il y avait urgence de faire évoluer leur gestion de projet et de l’amener à être plus

structurée. C’est alors qu’il s’est renseigné sur les différentes méthodologies existantes et en

a conclu que CMMI était une des plus ordonnée et surtout la plus souple lors de son

application. Pour le responsable qualité, il en ressort que cette décision a été prise pour la

satisfaction du client et de la direction : réduction des coûts et des délais grâce au chiffrage

et à l’optimisation des tâches.

Transition du service : Exemple d’un projet

Un projet qui a été abandonné en cours de développement prouve différents

problèmes lors du pilotage de ce projet. Celui que je prendrais comme exemple est un projet

qui a pourtant été le projet pilote de la mise en place des bonnes pratiques CMMI au sein du

service. Il fait ressortir d’autres points qui mènent les projets à l’échec que je développerai

dans ce chapitre.

Ce projet date de 2008 et concernait le service Paie. Une application devait être

développée en interne pour remplacer un outil créé par une utilisatrice sous le logiciel

Microsoft Access®. Les interlocuteurs DSI ont alors suivi les bonnes pratiques conseillées par

l’accompagnateur sénior CMMI. Le chef de projet a étudié l’existant et recueilli les besoins

auprès des utilisateurs concernés. Avec son développeur, ils ont mené plusieurs réunions

auprès des utilisateurs afin de valider les livrables attendus pour le projet et ont rédigé un

document contenant les spécifications fonctionnelles.

Lors de la validation des spécifications avec l’utilisateur, l’équipe a pris conscience que

le périmètre du projet n’était pas correctement défini et ce qui devait être repris à iso-

fonctionnalités n’avait pas été ciblé par rapport à l’objectif principal. Cette réunion a duré

beaucoup plus de temps que prévu, pour finalement aboutir sur le fait que les spécifications

étaient à redéfinir.

De plus, ils ont été confrontés à une résistance au changement catégorique de

l’utilisateur clé. En effet, ce dernier étant celui qui avait mis en place la solution temporaire

pour pallier au manque d’outil de gestion de la paie, il ne trouvait pas de corrélation entre la

nouvelle solution et l’existante. Bien que l’équipe projet ait travaillé sur les maquettes en

prenant soin de garder le même esprit, il n’a pas accepté la volonté du service de faire

évoluer son outil.

Le projet a été planifié sur deux mois. Les allers-retours de validation des spécifications

prenant du temps, l’équipe a pris la décision de commencer les développements. Les délais

se sont étirés jusqu’à six mois calendaires1, sans arriver à aucun accord, la direction a donc

décidé d’arrêter ce projet qui n’aboutirait manifestement à rien.

1 Ne pas confondre 6 mois hommes et 6 mois calendaires. L’équipe travaillait en parallèle sur d’autres

projets.



En tout, 37 jours ont été consommés sur ce projet, dont 17 de développement.

Aujourd’hui, le projet n’a toujours pas été relancé et le service paie continue à utiliser

l’outil Access®. La DSI prépare le changement différemment, en intégrant l’évolution de

l’outil au sein d’autres projets, par exemple la génération de documents à partir de l’outil

principal de gestion est une de ses fonctionnalités phares. Bien que ce nouveau projet

concerne cet utilisateur, il ne s’implique toujours pas dans la mise en place.

Le problème rencontré sur ce projet ne vient pas directement du service informatique,

mais de l’utilisateur clé. La résistance au changement reste quelque chose à prévoir et gérer,

surtout quand les personnes concernées sont connues pour ne pas s’impliquer dans les

projets.

Il y a donc eu un manquement de l’équipe au niveau de l’analyse des parties prenantes

et la manière de communiquer sur le contenu et ce qu’ils pouvaient apporter au bon

déroulement du projet, étape qui était manifestement nécessaire.

Nous pouvons conclure de cette expérience que, bien qu’en suivant des bonnes

pratiques, les projets n’aboutissent pas forcément et la notion humaine est primordiale dans

les démarches de lancement d’un projet.



V) Apports des méthodologies de projet

1) Deux méthodologies : CMMI et PMI

Qu’est-ce que CMMI ?

CMM, Capability Maturity Model, est un guide de bonnes pratiques qui a été créé en

1984 aux Etats-Unis dans le but d’améliorer et optimiser les processus mis en œuvre dans

leurs équipes de développement logiciel. Afin de prendre en compte les aspects systèmes et

intégration logiciels, il a évolué en CMMi (Capability Maturity Model Integrated) en 2000.

Nous en sommes aujourd’hui à la version 1.2. CMMI certifie un service.

Ce modèle est divisé en cinq niveaux de maturité (initial, discipliné, ajusté, géré,

optimisé) et concerne tous les aspects du cycle de vie d’un projet. Ils permettent de définir

des processus communs et renouvelables pour accomplir les tâches de gestion de projet.

Les processus CMMI sont regroupés en trois constellations1 : acquisition,

développement et services et comportent seize processus communs. Ci-dessous un schéma

représentant la répartition par constellation des 36 processus qui composent ce modèle:

Chaque constellation est subdivisée en vingt-deux domaines de processus, chacun

constitue un faisceau de pratiques liées et qui, une fois mises en application collectivement,

satisfont à un ensemble d’objectifs considérés comme importants pour l’amélioration de ce

domaine.

1 Constellation : terme spécifique CMMI représentant une catégorie pour les domaines de processus

Commun: 16 processus

Services : 8 processus

Acquisition : 6 processus

Développement : 6 processus



Sur ce schéma, une représentation des

différents niveaux du modèle CMMI. Les

niveaux en majuscules sont les composants

requis pour l’application des bonnes

pratiques.

Ces objectifs peuvent être spécifiques

(unique et requis pour satisfaire au

domaine de processus) ou génériques

(s’applique à différents domaines de

processus). Les objectifs sont réalisés grâce

à des pratiques spécifiques ou génériques,

qui sont des composants attendus

permettant de satisfaire à un ou des

objectifs.

La démarche CMMI peut s’aborder de deux manières différentes : représentation

étagée et représentation continue. La différence se situe là où seront évalués les processus.

La représentation étagée emploie des niveaux de maturité, qui seront évalués sur

l’application des domaines de processus. La représentation continue recourt à des niveaux

d’aptitude évalués sur les objectifs et pratiques spécifiques et requis.

On retrouve dans le tableau ci-dessous les domaines de processus par niveaux.

Niveau 2 Gestion de projet définie et appliquée

Gestion des exigences Planification de projet Suivi et surveillance du projet Management de la sous-traitance Assurance qualité Gestion de la configuration

Niveau 3 Processus étendus à l’ensemble de l’organisation

Gestion des risques Programmes de formation Management des processus (organisation des projets) Gestion logicielle intégrée (intégration des produits) Ingénierie logicielle (mise en place technique) Coordination (revue de pairs, tests, validation)

Niveau 4 Processus établis et maintenus

Report de la performance (mesures)

Niveau 5 Amélioration continue

Innovation de l’organisation et technologies Causes déterminées et défauts rétablis

DOMAINE DE

PROCESSUS

OBJECTIFS

SPÉCIFIQUES

PRATIQUES

SPÉCIFIQUES

Produits d'activité

Sous pratiques

Objectifs génériques

Pratiques génériques



Qu’est ce que PMI® ?

PMI® est l’acronyme de Project Management Institute. C’est une association

professionnelle fondée en 1969. Ce consensus international a rédigé un référentiel, le

PMBOK® (Project Management Body Of Knowledge), contenant les meilleures pratiques de

gestion de projet. On parle alors de la méthodologie PMI®. La certification PMI® est délivrée

à une personne.

Le PMBOK® (4ème édition en 2008) définit les fondamentaux du management de projet,

entres autres : les différentes structures organisationnelles, où se situe la gestion de projet

dans une entreprise, ce qu’elle est et le rôle que doit tenir le chef de projet au sein de son

équipe. Il établit également des règles de savoir-vivre et de savoir-être qui doivent être

respectées sous peine de risquer de perdre sa certification.

Ce référentiel enseigne principalement que la gestion de projet est divisée en 42

processus, répartis dans une matrice sur la base de neuf domaines de connaissances et cinq

groupes de processus qui sont :

Domaines de

connaissance

Intégration, contenu, délais, coûts, qualité, ressources humaines,

communication, risques, approvisionnements

Groupes de

processus

Initialisation (2 processus), planification (20 processus), exécution (8

processus), surveillance et maîtrise (10 processus), clôture (2 processus)

Vous trouverez la matrice complète en annexe.

Chaque processus comporte un ensemble d’entrées (ce qui agit sur le processus ou ce

qui est nécessaire pour mener le travail), d’outils et techniques (la manière de faire le travail)

et de sorties (ce qui est créé : documents, livrables, planning et le produit du projet).

Les sorties d’un processus sont généralement les entrées d’un autre, permettant de

mener le cycle de vie du projet de manière structurée. Ci-dessous un cycle de vie type

représenté par les groupes de processus PMI® (source : PMBOK®).

•Entrées p1

•Outils et techniques p1

Processes p1

•Entrées p2

•Outils et techniques p2

•Sorties p2

Processus p2

Sorties p1



Le nuage représente l’association entre les processus d’exécution et de surveillance et

maîtrise, ces deux groupes de processus étant indissociables dans la pratique, il existe un

retour constant lors de demandes de modifications sur le livrable en cours de mise en place.

2) Corrélation entre les pratiques CMMI et les processus PMI®

CMMI et PMI® sont les deux normes les plus en vue en terme de qualité logicielle. Ces

méthodologies ne dictent pas un chemin type à adopter, mais offrent des bonnes pratiques

de management et de suivi de projet. Comme le précise Dave Nielsen dans son article

« CMM and the PMBOK »1, personne n’a établi de référentiel corrélant CMMI et PMI®, c’est

ce que je souhaite développer dans la partie qui suit. Par souci de clarté, la corrélation se

fera à partir de processus PMI® et seront définis dans un tableau ceux pour lesquels il existe

un rapprochement possible.

Le niveau 1 est la base de toute entreprise de développement logiciel et le PMBOK®

demande un minimum de mise en place de gestion de projet, il n’y aura donc pas matière à

établir de corrélations. Nous ne pouvons établir de rapprochement qu’à partir du niveau 2

de CMMI.

Les niveaux 4 et 5 définissent comment maintenir et améliorer les processus mis en

place. PMI® ne concerne pas cet aspect de CMMI, mais seulement l’aspect pilotage, ils ne

sont donc pas à corréler avec les processus PMI®. Nous trouverons dans ce tableau les

pratiques CMMI de niveaux 2 et 3 ayant une corrélation avec PMI®.

Les codes utilisés dans le tableau sont les suivants : - DP : domaine de processus

1 Article disponible à http://www.pmhut.com/cmm-and-the-pmbok, traduit et interprété en français par

Michel Operto http://dantotsupm.wordpress.com/2010/04/12/cmmi-et-le-pmbok/

InitialisationDéfinir un nouveau projet ou

phase

PlanificationEtablir le contenu et les tâches

requises pour atteindre les objectifs

Mise en oeuvre d'un planning

ExécutionMise en oeuvre du travail

planifié

Surveillance & maîtrise

Vérifier, revoir et réguler l'avancement et les

performances

ClôtureFinaliser toutes les activités pour clore formellement le

projet ou phase

Anomalies

http://www.pmhut.com/cmm-and-the-pmbok

http://dantotsupm.wordpress.com/2010/04/12/cmmi-et-le-pmbok/



- SP : pratique spécifique - SG : pratique générique

Processus PMI® Corrélation CMMI Produits communs

Recueillir les

exigences

Identifier les parties

prenantes

DP : Gestion des exigences (REQM),

SP : Obtenir une compréhension et

un engagement sur les exigences.

Niveau 2

Ensemble des exigences suite

à une analyse par rapport

aux critères, liste des

fournisseurs d’exigences

appropriés

Développer le plan

de management

DP Planification de projet (PP) niveau

2. Permet de rassembler dans un

même plan les estimations, les

ressources, les engagements,

l’échéancier et l’analyse des risques

De plus, ce processus comprend,

tout comme pour PMI®, différentes

pratiques :

DP : Gestion de la configuration (CM)

niveau 2, Gestion des exigences pour

la SP Gérer les modifications aux

exigences niveau 2, Mesure et

analyse pour la SG Aligner les

activités de mesure et d’analyse

niveau 2

Sortie : Plan projet

Sorties subsidiaires :

Documentation des

exigences et des décisions

aux exigences

Matrice de traçabilité et

système de suivi des

exigences

Indicateurs de performance

(délais, coûts, qualité)

Définir le contenu DP Solution technique (TS), SG

Sélectionner les solutions de

composants de produit niveau 3.

Cette pratique est spécifique à un

projet de développement.

Le contenu concernera la

solution technique mise en

place.

Définir les activités DP Solution technique (TS), SG Faire

la conception : comment concevoir le

produit et analyser le « make-or-

buy ». Cette pratique est également

spécifique à un projet de

développement. Niveau 3.

Sorties : contenu du projet

(solutions possibles,

maquettes, relations avec les

exigences, données

techniques, manuels

utilisateur, …)

Planifier les risques

Identifier, analyser

et prévoir une

réponse aux risques

DP Gestion des risques (RSKM)

niveau 3.

Sorties : Plan de

management des

risques contenant la liste des

sources, des catégories, leur

priorisation et exigences




d’évaluation ; plan

d’atténuation, réponses aux

risques

Planifier la qualité DP Définition du processus

organisationnel, qui demande de

mettre en place une ligne

directionnelle de travail sous un

processus homogène dans toute

l’organisation.

Sorties : processus

standards, description des

cycles de vie adaptés aux

situations

Groupe de

processus :

Exécution

DP Gestion de projet intégrée (IPM +

IPPD) a comme but de maintenir le

projet et l’implication des parties

prenantes. Les pratiques demandent

de suivre l’exécution avec les plans

comme base, gérer les parties

prenantes, constituer l’équipe projet

et assurer la collaboration

Niveau 3.

Entrées : actifs

organisationnels, plan projet

et autres plans

Sorties : mises à jour des

actifs organisationnels, plans

intégrés, disponibilités et

attributions des ressources,

produits d’activité

Vérifier le contenu DP Validation et Vérification niveau

3. Propose des pratiques pour se

préparer à la validation en

établissant l’environnement et les

procédures de validation avant de la

réaliser pour ensuite analyser les

résultats.

Entrées : contenu du projet

(spécifications et exigences)

Sorties : environnement de

tests, procédures, critères,

résultats et rapports

Revues par les pairs.

Contrôler le contenu

Contrôler les coûts

Reporter la

performance

DP Mesure et analyse (MA), SG

Fournir des résultats de mesure

Les pratiques permettront d’analyser

les indicateurs définis

précédemment et de les

communiquer aux parties prenantes

concernées.

Niveau 2

Entrée des processus : plan

projet

Sorties : résultat des tests du

produit, analyse des résultats

et conseils pour

l’interprétation

Surveiller le travail

sur le projet

DP Surveillance et contrôle (PMC)

Toutes les pratiques englobent les 4

Entrée des processus : plan

projet, plan d’assurance

qualité, plan de gestion des




Surveiller les risques

Exécuter les

modifications

processus PMI® cités. En effet, ce

domaine de processus permettra de

surveiller le projet dans sa globalité :

délais, risques et modifications tout

en prenant en compte le plan qualité

Niveau 2

risques

Sorties : performances du

projet, écarts, surveillance

des risques, revues de projet,

actions correctives à mener

Exécuter le contrôle

qualité

DP Assurance qualité processus et

produit (PPQA)

Ce domaine de processus définit

comment évaluer des processus et

des produits et les communiquer

Niveau 2

Entrée : plan d’assurance

qualité

Sorties : rapports

d’évaluation, actions

correctives

Groupe de

processus :

Approvisionnements

DP : Gestion des accords avec les

fournisseurs (SAM)

Niveau 2

Liste des types d’acquisitions

pour les produits et

composants

Planifier et établir les

contrats et accords

Rapports d’activité des

fournisseurs

Résultats des tests

d’acceptation

Les domaines de processus faisant partie de la constellation CMMI Gestion des

processus (à partir du niveau 3), proposent de planifier, mettre en œuvre et déployer des

améliorations aux processus standards définis au sein de la structure (Focalisation sur le

processus organisationnel) ou encore de former les services impliqués dans la mise en place

des bonnes pratiques (Formation organisationnelle). Ces pratiques sont englobées dans tous

les processus du PMBOK® qui ont comme entrée et sortie systématiques les actifs

organisationnels de la structure. Ces domaines de processus sont donc transversaux à la

matrice PMI®.

Les domaines de processus CMMI non adaptables à PMI® ne sont pas listés. Ces deux

méthodologies n’ont pas les mêmes objectifs et sont complémentaires. Par exemple, nous

retrouverons un domaine de processus CMMI de niveau 3, Analyse et prise de décision, qui

implique de documenter les lignes directrices de prise de décision et des solutions possibles.

Ce domaine concerne une fonction de support, ce qui ne fait pas partie du contexte de la

méthodologie PMI®.



3) Paramètres de mise en place Paramètres généraux (adaptabilité, coûts, délais)

La méthodologie CMMI permet une flexibilité d’adaptation, d’une part par sa division

en constellations permettant de sélectionner quel domaine du service ou de la structure on

souhaite faire évoluer, d’autre part par ses deux représentations qui permettent d’adopter

son propre rythme d’avancement.

Quant à la méthodologie PMI®, elle ne certifie pas un service mais une personne.

L’expert pourra alors adapter l’application de cette méthode en fonction du service dans

lequel il est intégré et aux types de projets qui lui sont confiés.

Là où réside la différence entre les entreprises grands comptes et les PME est dans

l’impact qu’auront les coûts de cette mise en place et le retour sur investissement une fois

CMMI mis en place. Un programme d’amélioration CMMI peut demander un effort de 1 à

5% du budget pour le service concerné. Pour les SSII grands comptes, cet effort sera bien

plus amorti car mieux distribué, alors que dans les PME, il sera plus localisé et donc paraîtra

comme un investissement bien plus important. Les experts et consultants CMMI parlent

d’une mise en place sur 18 mois pour un seul niveau à un coût d’environ 1500€ par an et par

personne.1

Selon une étude de 2006, le retour sur investissement est, quant à lui, réellement

bénéfique car il peut atteindre un ratio de 4:1 en moyenne sur 2 à 5 ans, en termes de coûts,

de délais, de productivité (35%) et de qualité (39% de réduction des défauts post-

installation).2 En comparant ce retour sur investissement avec les données de dépassement

de budget sur les projets informatiques (189% de l’estimation initiale), il ressort de façon

évidente que le coût de mise en place de méthodologies de projet est rapidement

rentabilisé.

Bien que les DSI aient conscience d’un besoin fort de ces méthodologies, la direction

n’a pas toujours les données nécessaires pour accepter de les mettre en place. On se

confronte alors au même problème que pour l’attribution des ressources et de la baisse des

budgets accordés aux projets informatiques.

Résistance au changement

Quelle que soit la méthodologie adoptée, comme pour tous projets, la résistance au

changement est une contrainte non négligeable. Plus elle vient de la « haute » hiérarchie,

plus elle aura un impact fort. D’après une enquête que j’ai effectuée auprès d’experts CMMI,

il ressort que la Direction n’est pas assez impliquée dans la mise en place de bonnes

1 Selon une FAQ d’un site d’expert http://www.qprime.fr/faq/index.php et un article de 01net

http://www.01net.com/article/246136.html

2 Etude de Diane L. Gibson, Dennis R. Goldenson et Keith Kost à l’adresse suivante

http://www.sei.cmu.edu/reports/06tr004.pdf

http://www.qprime.fr/faq/index.php

http://www.01net.com/article/246136.html




pratiques, amenant à une démotivation des équipes vis-à-vis du programme d’amélioration

entamé.

L’accompagnateur CMMI de la structure dans laquelle je travaille insiste sur ce fait :

« Le problème majeur réside dans une implication insuffisante de la Direction. Souvent, ce

sont des organisations qui cherchent le niveau pour une raison d’enjeu commercial. Elles

n’ont pas pris conscience qu’une évolution de processus doit être fortement accompagnée

par la Direction. ».

Cela vient certainement du fait qu’ils manquent de recul sur ces méthodes et pensent

que seul le service doit être actif pour une réussite du projet. N’ayant également pas de

retour sur les bénéfices engendrés, ils n’en comprennent donc pas l’intérêt principal :

augmenter la productivité et la satisfaction du client. Il faut donc axer son intervention sur la

Direction et prioriser des indicateurs relevant de leur domaine de compétence

Mais les intervenants CMMI n’ont, la plupart du temps, qu’un rôle d’accompagnateur

et ne peuvent donc pas s’impliquer dans le bon déroulement de l’application des pratiques.

Cela serait pourtant une solution pour permettre aux directions autre que celle du service

informatique de prendre conscience des besoins en méthodologie de pilotage de projet. Les

différentes réponses aux enquêtes mettent en avant que si ces derniers étaient moins

« mous », les projets d’amélioration échoueraient certainement moins.

Nous pouvons en conclure que la résistance au changement dans ce genre de projet ne

concerne pas seulement les acteurs directs mais également la Direction. Malgré

l’intervention d’experts dans les programmes d’évolution, ils ne restent que spectateurs de

l’application des pratiques enseignées, l’amélioration ne peut donc venir que d’une prise de

conscience interne.



VI) Expérimentation et perspectives

1) Un terrain d’expérimentation

Ce chapitre permet de citer un projet auquel on a adapté PMI® sur des pratiques

CMMI. L’exemple présentera surtout les points suivants : quelles pratiques CMMI et PMI®

ont été mises en place ? Comment ont-elles été adaptées ?

Le service dans lequel j’ai effectué mon expérimentation met en place depuis peu

certaines des pratiques CMMI, ce qui a bouleversé leurs méthodes de travail. Une fois le

service intégré, j’ai souhaité leur faire aborder ce qu’ils considéraient être des contraintes en

une méthode simplement structurée et leur permettant de simplifier leur organisation et

leur suivi.

Le projet pris en exemple ici est un de ceux qui servira de projet pilote à mon objectif

d’intégration des méthodes : leurs pratiques CMMI définies à l’aide de PMI®.

Les pratiques CMMI

Tout projet est défini sur un cycle de vie. Avant son lancement, il existe une phase

d’avant-projet, qui permet de le chiffrer de manière macro et ainsi d’obtenir un accord de la

part du comité de projet.

Une fois le projet accordé par rapport au budget et aux ressources nécessaires, un chef

de projet est nommé pour démarrer l’étude fonctionnelle : expression des besoins,

spécifications fonctionnelles, maquettes et planification des délais.

Au cours du développement, plusieurs documents sont suivis : une revue de pairs

(documentation technique), le suivi de la configuration (mise à jour d’un fichier commun) et,

si un contrôle de l’assurance qualité est planifié, les résultats de cet audit seront classés dans

le dossier du projet.

Un tableau de bord est mis à jour chaque semaine afin d’être présenté en réunion, où

sont conviés tous les chefs de projet, le DSI et le responsable qualité. Au cours de ces

réunions sont abordés les problèmes rencontrés lors des développements, avec les

utilisateurs ou au moment de la livraison. Des solutions peuvent être apportées après avoir

discuté en commun des impacts possibles sur les autres projets ou le système

d’informations.

On aborde ensuite une phase de tests, qui sont effectués par le chef de projet en

environnement de développement, puis de correctifs sur un des lots ou le projet dans son

intégralité.

Une fois qu’il ne ressort plus que des bugs mineurs et si le projet atteint son échéance,

la livraison en lots peut être effectuée. Elle sera suivie d’une formation de l’utilisateur, à qui

sera délivré un manuel d’utilisation.



Une fois le procès verbal de réception signé, une enquête de satisfaction du

déroulement du projet est envoyée à l’utilisateur (gestion du projet, réponse aux attentes,

communication avec le SI, …). Le projet et sa documentation peuvent être archivés.

Ci-dessous le déroulement d’un projet tel qu’exécuté dans le service. Les chevrons

principaux représentent les phases, les autres détaillent ces phases en livrables et actions à

mener au cours du projet.

En modélisant ce cycle de vie, on remarque qu’il correspond de très près à la

modélisation des groupes de processus PMI®.

Un projet expérimenté

Le projet que j’ai pu expérimenter en tant que chef de projet au sein de cette structure

est un projet purement stratégique, ce qui m’a permis de mettre en avant les activités PMI®.

Afin de mener à bien ce projet, j’ai rapproché leur adaptation des bonnes pratiques

CMMI (livrables, actions) aux processus PMI® comme décrit dans le tableau suivant. Seules

les phases que j’ai entamées y sont représentées.

Les phases CMMI (colonne 1) correspondent à celles du cycle de vie du projet et les

documents (colonne 2) à des résultats d’actions à mener. En dessous de chacune des

corrélations avec PMI® (colonnes 3 et 4), une courte explication de ce rapprochement est

donnée.



Phase CMMI Document CMMI Processus PMI® Document PMI®

Avant projet Expression des besoins

Initialisation Charte de projet

L’expression des besoins est le document qui formalise la demande du projet et qui est validé après divers échanges entre l’utilisateur et le SI. La charte de projet est le document qui autorise formellement le projet et qui documente les exigences initiales.

Cadrage Référentiel des exigences

Planification / Contenu : Recueillir les exigences

Documentation des exigences

Le référentiel des exigences constitue le point de départ de la définition du contenu du projet et liste les exigences, permettant de lister les besoins nécessaires des parties prenantes.

Cadrage Dossier de spécifications générales

Planification / Contenu : Définir le contenu, la structure de découpage

Enoncé du contenu du projet

Le Dossier de spécifications générales contient, tout comme l’énoncé du contenu du projet, une description complète du contenu du projet, les livrables nécessaires à la réussite du projet, le WBS1 et les aspects fonctionnels et techniques.

Cadrage Feuille de chiffrage Planification / Délais : Définir et séquencer les activités

Enoncé du contenu du projet

La feuille de chiffrage permet de lister les activités et de déterminer leur durée, permettant par la suite de planifier le projet dans un outil spécifique. PMI® prévoit cela dans l’énoncé du contenu du projet.

Planification WBS Planification / Contenu : Créer la structure de découpage du projet

Référence de base du contenu

Le WBS est intégré au dossier de spécifications générales dans l’organisation du service et à la référence de base du contenu pour PMI®. Il permet de subdiviser les livrables et le travail du projet en composants plus petits et plus faciles à maîtriser.

Planification Plan projet Planification / Intégration : Développer le plan de management du projet

Plan de management du projet

Le plan projet correspond au plan de management du projet consiste à documenter les actions nécessaires à la définition, préparation, intégration et coordination de tous les plans subsidiaires, y compris la gestion de la configuration

Apports sur le projet

1 WBS : structure de découpage du projet



Ce projet concerne le pointage des heures effectuées par du personnel vacataire, les

utilisateurs impliqués font partie de la direction, des services ressources humaines et paie.

Une analyse plus poussée des parties prenantes était donc nécessaire pour communiquer de

façon constructive sur leurs besoins. Ce processus n’étant pas formalisé au sein du service, il

n’existait aucun historique sur leurs échanges lors de précédents projets. J’ai donc procédé à

cette analyse et établit un registre des parties prenantes contenant les rôles, le degré

d’implication de chacun et les points qui me semblaient importants sur la manière de les

aborder. Nous avons alors pu prévoir une réunion qui a mené à différent échanges et un

accord.

Après avoir appliqué la phase de cadrage concernant les besoins et exigences, j’ai

procédé à la planification. Pour cette phase, les pratiques internes définissent qu’il faut

découper le projet en lots, puis planifier dans un outil mis en place en interne. Ceci fait, je

me suis rendu compte qu’avec les différents projets que je gérais en parallèle, je n’avais pas

assez de recul sur l’avancement du projet, exceptée une liste de tâche comprenant leur

durée. Sous les conseils d’une chef de projet, j’ai donc utilisé un outil open-source de

planification afin d’établir un échéancier.

Aujourd’hui les développements ont commencé, le périmètre semble clair pour le

développeur, il manque seulement certains documents concernant les actifs

organisationnels techniques.

Je ne peux aujourd’hui pas aller plus loin dans l’analyse, le projet n’étant avancé qu’à

30% de son développement.

Apports sur le service

De l’expérience de ce projet, bien que peu avancé, nous pouvons tout de même en

tirer les conclusions suivantes :

- Le registre des parties prenantes doit être systématiquement complété pour

permettre aux différents acteurs du projet de communiquer de manière

constructive

- Le dossier des spécifications générales ne devrait pas contenir l’intégralité du

contenu du projet, certaines parties comme l’aspect technique devraient être

séparées de l’aspect fonctionnel, afin de permettre à toute personne non-

informaticienne de valider ce dossier après y avoir réellement porté de l’intérêt.

C’est pour cela qu’il faut bien cibler les moyens de communication et les

implications de chacune des parties prenantes

- Lister les activités et les chiffrer ne suffit pas pour le bon suivi du projet, un outil de

planification (outils conseillés dans le PMBOK®) est nécessaire pour s’assurer de la

visibilité totale des projets mis en place en parallèle.



2) Perspectives : Autres méthodologies

Il existe d’autres méthodologies qui sont aujourd’hui plus appliquées dans les

entreprises, dont les méthodes Agiles avec Scrum et Extreme Programming ou encore Lean,

basée sur le principe Agile. Ces méthodes sont principalement axées autour du bénéfice de

l’utilisateur.

Les méthodes Agiles ont comme valeur principale de mettre en avant les personnes

avant les processus, demandant alors une réactivité au changement plus poussées que les

autres méthodes, notamment dans les petites équipes, qui doivent alors agir collectivement.

La méthode Scrum fait référence au rugby : lors d’une faute en cours de jeu, il doit avoir lieu

une reprise qui permet de remettre l’équipe sur le bon rail à l’aide d’un effort collectif. La

méthode Extreme Programming demande un fonctionnement en binôme et un cycle court

et itératif. La gestion des projets est également collective et les développeurs s’attribuent

eux-mêmes leurs tâches, après une analyse d’un premier scénario définit par le client final.

L’interview effectuée auprès du DSI m’a permis de comprendre pourquoi il avait choisi

CMMI : pour sa flexibilité d’adaptation, mais surtout pour les contraintes qu’elles imposent

aux demandeurs, contrairement aux méthodes Agiles, qui nécessitent trop de proximité

avec le client.

En effet, après plusieurs années d’expérience où l’utilisateur final faisait des demandes

peu explicites et ne se rendait ensuite plus disponible pour l’équipe de développement lors

de la définition de leurs besoins, ils ont décidé de ne plus laisser autant de liberté aux

utilisateurs et ainsi de cadrer leurs demandes. Le niveau 2 de CMMI a donc été leur décision

finale pour pallier à ce problème de demandes excessives.

On retrouve sur plusieurs sites web, notamment sur le blog de Claude Aubry, où un

article est consacré à l’association de CMMI avec la méthode Scrum1, qu’il n’est pas conseillé

d’associer ces deux méthodologies bien opposées dans leurs principes : une permet d’avoir

des bénéfices sur le long terme, alors que l’autre met en avant la satisfaction client mais

obtient des bénéfices au sein de l’équipe à court terme seulement.

Nous pouvons par contre retrouver une méthodologie qui regroupe CMMI et PMI® : la

méthode OPM3, pour Organizational Project Management Maturity Model. Elle a été

développée par le consensus PMI® et représente son propre modèle de maturité structuré.

Même s’il contient les mêmes niveaux que CMMI, le contexte de ce référentiel est la gestion

de projet organisationnelle alors que CMMI est axé sur la gestion des projets de systèmes et

logiciels.

1 Blog « Scrum, Agilité et Rock’n’Roll… » dont l’article à l’adresse suivante

http://www.aubryconseil.com/post/Scrum-CMMI,-niveau-2,-niveau-5




VII) Conclusion Pour conclure, je dirais que les entreprises européennes sont en retard sur la mise en

place de méthodologies de projets, mais après une forte prise de conscience grâce à une

ouverture sur les entreprises indiennes ou nord-américaines, elles sont en cours de mutation

d’un point de vue de la qualité de leurs services. Je doute pourtant encore beaucoup de la

compréhension des DSI sur les méthodologies de projet et leur bénéfice réel.

Pour la mise en place de CMMI, les témoignages parlent de 18 mois par niveau. Il est

vrai qu’en prenant ces témoignages au premier degré, on parlera de 6 ans pour être au

meilleur niveau de CMMI. Il faut donc garder en tête que ce n’est qu’un guide de bonnes

pratiques et il ne s’agit pas d’être le « meilleur », bien que certains ne le mettent en place

que pour une image commerciale.

Or, la gestion de projet par processus doit réellement devenir un principe

incontournable et devrait être pris en compte tout au long du cycle de vie du projet. Cela

permettrait aux entreprises de voir les bénéfices plus rapidement et éviter aux équipes de

dériver des bonnes pratiques. C’est pourquoi le rôle des accompagnateurs est primordial

dans la réponse qu’ils apporteront aux structures dans lesquelles ils interviennent, afin

d’optimiser la qualité des développements à l’aide d’un programme d’amélioration adapté.

Il faut alors prendre conscience que piloter la qualité d’un projet en continu permet de

s’améliorer sur le court et le long terme, tant que les services apprennent de leurs erreurs. Il

y aura alors un bénéfice notable sur les impacts techniques, humains et financiers.

On retrouve un large choix de méthodologie, qui se complètent, s’imbriquent ou se

ressemblent. La méthodologie PMI® regroupe, comme Agile, plusieurs référentiels. On y

retrouvera OPM3 par exemple, qui propose un modèle de maturité (tel CMMI) plus léger et

adapté au PMBOK®.

Tout au long du développement de cette thèse, j’ai remarqué sur différents sites et

blogs que les termes utilisés pour définir les projets informatiques (en 2003 ou en 2010)

étaient très souvent extrêmes et négatifs. Bien que la plupart des experts aient pris

conscience que ce manque de pilotage de la qualité affectait directement les ressources de

l’entreprise, ils n’apportent pas de critiques réellement constructives. D’autres experts

publient des articles au cours de l’année 2010 en se basant sur des chiffres de 2004, qui ont

pourtant évolué ! Faut-il alors se demander si eux-mêmes, critiquant l’immobilisme des

entreprises ou la lourdeur des pratiques (d’ailleurs prouvées comme adaptables) sur

d’anciennes bases, n’ont pas également besoin d’ouvrir leur esprit à de nouvelles

perspectives… Comme le dit Friedrich NIETZSCHE :

« Aussitôt qu'on nous montre quelque chose d'ancien dans une innovation, nous sommes apaisés »

Friedrich NIETZSCHE



VIII) Glossaire Ce glossaire définit les termes spécifiques utilisés dans le document et reprend les

définitions déjà annotées en bas de page.

- Projet : Un projet est un effort temporaire entrepris pour créer un produit, un

service ou un résultat unique. Un projet est temporaire, il a un début fini et une fin

définie

- Processus : Ensemble d'activités corrélées ou interactives qui transforme des

éléments d'entrée en éléments de sortie

- Livrables : Produits ou composants du projet créés par les processus et comportant

une échéance de livraison

- ERP : Enterprise Resource Planning, progiciel de gestion intégrée

- SaaS : Software As A Service. Solution proposant de s’abonner à un service plutôt

que d’acheter une licence, solutions full-web. Les clients ne paient pas pour

posséder le logiciel mais pour l’utiliser

- DSI : Directeur du système d’information

- CMMI : Capacity Maturity Model Integration

- PMI® : Project Management Institute

- PMBOK® : Project Management Body Of Knowledge

- SSII : Société de Services en Ingénierie Informatique



IX) Bibliographie Cette bibliographie reprend les sites principaux utilisés lors de mes recherches. Tous

ceux que je cite dans le développement sont annotés en bas de page.

Général

- Document de présentation de la société Acadys, société suisse de management de

projet : http://www.project-management.ch/pages/DocumentsSoireesDebat/SD06-

01-25.pdf. Ce document m’a guidé tout au long du développement de cette thèse.

Satisfaction utilisateurs

- Article web montrant que la satisfaction des utilisateurs peut-être due à une

mauvaise connaissance de l’outil mis en place. http://www.e-

marketing.fr/Marketing-Magazine/Article/Intranet-une-visibilite-encore-floue-10833-

1.htm

Gestion du changement

- Article traitant de la gestion du changement ou l’art de prendre en compte la

dimension humaine http://www.jrcoaching.fr/coaching/gestion-du-changement.php

- La gestion du changement est la clé de la réussite d’un projet ERP

http://www.audaxis.com/Actualites/La-gestion-du-changement-cle-de-reussite-d-un-

projet-ERP

- Article du site La documentation française, de Pascal CHARPENTIER avec comme axe

principal un pilier des formes de management : La gestion du changement dans les

organisations, qui souligne qu’elle est aussi importante que le fondement du projet

lors d’une modification assez radicale des systèmes de gestion.

- Interview d’Alain GRESSE datant d’octobre 2009 concernant l’évolution des services

de son entreprise Alter Domus vers le conseil en conduite de changement : « La

gestion du changement représente 80% du succès d'un projet informatique »


- Interview de Nathan Y. HATTAB expliquant l’échec des projets informatiques

« Pourquoi tant de projets informatiques échouent ? ». Cette publication ne

comporte pas de dates, je considère donc qu’une partie n’est pas exploitable dans ce

contexte, mais le contenu relativement complet cadre avec l’état des lieux effectué

sur les problèmes rencontrés. L’interview se trouve à l’adresse suivante :


- http://www.webzinemaker.com/admi/m9/page.php3?num_web=3648&rubr=4&id=

246593

Manque d’expérience des CDP

http://www.project-management.ch/pages/DocumentsSoireesDebat/SD06-01-25.pdf

http://www.project-management.ch/pages/DocumentsSoireesDebat/SD06-01-25.pdf

http://www.e-marketing.fr/Marketing-Magazine/Article/Intranet-une-visibilite-encore-floue-10833-1.htm



http://www.jrcoaching.fr/coaching/gestion-du-changement.php





http://www.webzinemaker.com/admi/m9/page.php3?num_web=3648&rubr=4&id=246593

http://www.webzinemaker.com/admi/m9/page.php3?num_web=3648&rubr=4&id=246593



- Echanges à l’adresse http://www.developpez.net/forums/d829864/general-

developpement/conception/methodes/gestion-projet/pourquoi-sacharner-mettre-

meilleurs-developpeurs-gestion-projet/

- Article assez radical sur codingly.com http://codingly.com/2008/12/29/degage-sale-

programmeur/

L’impasse des DSI

- Compte-rendu de la présentation du 12ème salon des Solutions et Amélioration des

Performances par la société ADELI ftp://ftp2.adeli.org/adeli/lalettre/l61p6.pdf

Méthodologies

- PMBOK® 4th Edition - ANSI

- Support de formation de M. Rodriguez

- CMMI 2ème édition, version 1.2 – PEARSON Education

- Site spécialisé dans le management de projet http://www.12manage.com

- Corrélation des méthodologies :

o http://www.aubryconseil.com/post/Scrum-CMMI,-niveau-2,-niveau-5

o http://www.pmhut.com/cmm-and-the-pmbok

- ROI des méthodologies http://www.sei.cmu.edu/reports/06tr004.pdf

http://www.developpez.net/forums/d829864/general-developpement/conception/methodes/gestion-projet/pourquoi-sacharner-mettre-meilleurs-developpeurs-gestion-projet/



http://codingly.com/2008/12/29/degage-sale-programmeur/

http://codingly.com/2008/12/29/degage-sale-programmeur/

ftp://ftp2.adeli.org/adeli/lalettre/l61p6.pdf

http://www.12manage.com/


http://www.pmhut.com/cmm-and-the-pmbok




X) Annexes

1) Enquête d’un chef de projet sur les méthodologies de projet

1. Quel est votre parcours ?

Ecole d'ingénieur généraliste, option TIC, 6 ans en SSI (en tant que développeur) et 4 ans en

tant que chef de projet

2. Aujourd’hui, votre activité principale consiste en quoi ?

La gestion de projets informatiques (étude, specs, planif, suivi, formation, rédaction de docs

utilisateurs)

3. Avez-vous participé à la mise en place de méthodologies de projet ? Pas vraiment. Au départ les décisions étaient imposées. Ensuite expliquées mais pas de

demande de participation active de la part des chefs de projet.

Un accompagnement (1 à 2j en tout) qui ressemblait plus à un audit...une formation de 1 à

2j sur les outils.

4. Si oui, lesquelles ?

CMMI

5. Comment gériez-vous vos projets avant la mise en place de cette méthodologie ?

Planif faite, refaite, re-refaite, puis re-re-refaite par le CDP1 (puis le DSI) régulièrement...

Causes : retards et prise en compte en urgence de nouveaux projets pas prévus...

Un suivi au fil de l'eau avec le développeur. Peu de formalisation.

Pour le reste :

Réunions avec le client, réalisation d'une maquette, puis développements avec des

changements constants, présentation du projet une fois fini, souvent des changements à

réaliser, documentation utilisateur.

6. Comment avez-vous vécu ce changement ?

Pas évident du fait qu'on nous impose sans nous expliquer. Quand on a fait bac+5, on

s'attendrait à être plus impliqué (mode collaboratif, pas directif ET pseudo délégatif) !

7. Avez-vous compris pourquoi la décision de mettre en place des bonnes pratiques a été prise et maintenue ?

Oui, mais pas tout de suite. il a fallu prendre conscience de ce qui se faisait "ailleurs", de

suivre une formation pour comprendre le pourquoi du comment, les problématiques...

8. Vous êtes-vous senti à l’aise avec ces pratiques ?

Non, car on nous impose de produire des documents sans nous expliquer à quoi cela doit/va

servir, de donner des chiffres sans savoir connaître leur utilité (du coup, on ne sait pas bien

"comment" remplir les informations demandées).

On n’a jamais eu de retour sur le fond : On a produit un doc. Personne ne nous a dit si c'est

ce qui était attendu... car personne ne l'a lu... cf "adapté à la cuisine, on nous donne des

renseignements sur comment le cuisinier s'y est pris, mais on ne sait rien sur le contenu de

l'assiette". Là c'est pareil.

Trop de nouvelles choses à intégrer d'un coup.... Trop de changements sur les modèles à

utiliser et sur la nature des docs à produire (quels docs?) au départ malgré la décision de

1 CDP : chef de projet



garder les mêmes versions des outils... au sein d'un cycle interne.

9. Quels bénéfices sur votre gestion de projet avez-vous remarqué une fois les pratiques prises en main ?

Pouvoir mieux quantifier l'avancement, mieux suivre le projet à l’aide de quelques

indicateurs, poser des limites pour éviter un dérapage total des projets. Mais si les

développeurs ne jouent pas le jeu, on a l'impression de tout suivre dans le brouillard, de

faire des mesures avec une marge d'erreur de 50% (température mesurée : 23,4° +- 10°!!!).

je n’ai pas encore pris en main tous les outils et ni à finir le cadrage avant le début des

développements... Mais j'espère que ça donnera quelque chose sur le prochain projet,

maintenant que les pratiques sont mieux prises en main.

10. Sur les projets en général ?

Pas de bénéfices immédiats.

On peut quand même constater moins de changements de cap sur les développements à

faire, c'est plus documenté.

Le problème est que les petits projets qui ont un impacte sur le contenu de projets qu'on

vient de mettre en place sont sans docs...--> docs obsolètes

11. Les utilisateurs / clients ont-ils ressenti un changement sur le suivi et l’accompagnement dans vos projets ?

Pour beaucoup, ces processus réduisent la souplesse, causent une augmentation des délais

pour un nouveau projet, voire un refus de le réaliser faute de moyens (ce qui peut être

justifié de notre côté).

Je ne suis pas sûre qu'ils en voient encore les aspects positifs. Pour eux, tout est plus long,

plus compliqué... Ils ont du mal à exprimer ses besoins, donc s'ils s'aperçoivent en cours de

projet qu'il y a des choses à modifier, on leur dit que ce sera pris en compte dans un 2ème

lot... Une incompréhension de plus.

12. L’intégration de nouvelles compétences a-t-elle été facilitée par la suite ?

Oui un peu. Moins de culture de l'oral, plus de docs. D'où une plus grande autonomie

possible des nouveaux à leur arrivée.

Démocratisation des méthodologies de projet en France


2) Matrice PMI® Initialisation

(2 processus) Planification (20 processus)

Exécution (8 processus)

Surveillance & maîtrise (10 processus)

Clôture (2 processus)

4. Intégration 4.1 Develop project charter

4.2. Develop project management plan

4.3 Direct & manage project execution

4.4 Monitor & control project work 4.5 Perform integrated change control

4.6 Close project or phase

5. Contenu 5.1 Recueillir les exigences 5.2 Définir le contenu 5.3 Créer la structure de découpage du projet

5.4 Verify scope 5.5 Control scope

6. Délais 6.1 Define activities 6.2 Sequence activities 6.3 Estimate Activity Resources 6.4 Estimate activity duration 6.5 Develop schedule

6.6 Control schedule

7. Coûts 7.1 Estimate costs 7.2 Determine budget

7.3 Control costs

8. Qualité 8.1 Plan quality 8.2 Perform quality assurance

8.3 Perform quality control

9. Ressources humaines 9.1 Develop human resources plan

9.2 Acquire project team 9.3 Develop project team 9.4 Manage project team

10. Communications 10.1 Identify stakeholders

10.2 Plan communications 10.3 Distribute information 10.4 Manage stakeholders expectations

10.5 Report performance

11. Risques 11.1 Plan risk management 11.2 Identify risks 11.3 Perform qualitative risk analysis 11.4 Perform quantitative risk analysis 11.5 Plan risk responses

11.6 Monitor & control risks

12. Approvisionnement 12.1 Plan procurements 12.2 Conduct procurements 12.3 Administer procurements

12.4 Close procurements

Retour