Avant-propos

Un projet...
Plus que le rire cest peut-tre la vritable sparation entre lhomme et lanimal...
Quest ce quun projet sinon une volont commune darriver un rsultat dans
un temps dtermin ? Associez-y la possibilit de mesurer ce rsultat, le risque que
reprsente cette activit, ne serait-ce que de ne pas aboutir, et le fait quil faut des
comptences multiples, vous aurez une vue presque parfaite de ce quest un projet.
Tout ce qui nest pas une activit rcurrente, habituelle, sans risque est un projet.
Comme le risque, le projet cest la vie tel point que dans linconscient collectif,
faire des projets est toujours peru positivement car cest progresser quelle que soit
la nature de cette progression. loppos, rester statique est traduit dans un autre
adage populaire : qui ne progresse pas rgresse . Rien dtonnant donc pour une
organisation que grer ou participer des projets soit peru plus positivement que le
fait de raliser une activit rcurrente. Alors que cette activit rcurrente est souvent
la seule source de revenus, elle est moins glorifiante que le projet. Le projet est un
devenir, l o lactivit rcurrente permet de recueillir les fruits du labeur.
Un projet est une volont damliorer un tat connu et peru comme perfectible,
il est porteur davenir.

Remerciements

Un livre technique ddi une mthode connue semble devoir tre un simple
travail de traduction au sens de lauteur de cette mthode. Il nen est rien, il sagit
de toute lexprience de lauteur forge au contact et souvent en confrontation avec
dautres expriences. Je remercie globalement tous ceux qui mont permis dacqurir
cette exprience et plus prcisment ceux qui mont conseill et surtout support lors
de cette nouvelle exprience. Je veux citer surtout mes confrres, relecteurs, critiques
et nanmoins amis :
Julian Casson qui, par ses remarques judicieuses, a permis ce livre de rester
abordable ;
Philippe Binder, conseil et sponsor, sans quil le sache toujours, de ce projet ;
Nicolas de Champris dont lacuit de jugement est avre ;
Mickal Davila, dont la curiosit a permis denrichir le contenu ;
et Barthlmy Perrin, dont le dynamisme et lcoute ont permis aux ides dveloppes de rester pertinentes.
Pour reprendre Antoine de Saint Exupry : Voici mon secret. Il est trs simple :
on ne voit bien quavec le cur. Lessentiel est invisible pour les yeux.

Table des matires

Avant-propos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

III

Remerciements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

IV

Dunod Toute reproduction non autorise est un dlit.

Premire partie Grer un projet selon PRINCE2

Chapitre 1 Quest-ce que PRINCE2 ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.1

Origine de PRINCE2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2

Prcautions de lecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2.1

Exemples de difficults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2.2

Convention de syntaxe et dfinitions pralables . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2.3

Focus sur le vocabulaire PRINCE2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Chapitre 2 Pourquoi une mthode ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.1

De la thorie du Chaos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2

Le CHAOS Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.3

Identification dun Projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.4

La ncessit dune mthode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

2.4.1

Les contraintes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

2.4.2

La viabilit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

2.4.3

La prparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

2.4.4

Rendre des comptes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

VI

La methode PRINCE2

Chapitre 3 Que propose PRINCE2 ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

3.1

Structure de PRINCE2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

3.2

Les paramtres de rgulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15

3.2.1

Six paramtres dlimitant un projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15

3.2.2

Mesurer les risques et les bnfices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16

3.3

Pourquoi adopter PRINCE2 ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

3.4

Ce qui nest pas trait par PRINCE2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19

Chapitre 4 Les principes PRINCE2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21

4.1

Caractristiques des principes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21

4.2

Principe 1 : Justification continue pour lentreprise . . . . . . . . . . . . . . . . . . . . . . . .

22

4.3

Principe 2 : Leons tires de lexprience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

4.4

Principe 3 : Rles et responsabilits dfinis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

4.5

Principe 4 : Management par squences (de management) . . . . . . . . . . . . . . . . .

25

4.6

Principe 5 : Management par exception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

4.6.1

Sur les cots et dlais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

4.6.2

Sur la qualit et le primtre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

4.6.3

Sur les risques et les bnfices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

4.7

Principe 6 : Focalisation sur le produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

4.8

Principe 7 : Adaptation lenvironnement de projet . . . . . . . . . . . . . . . . . . . . . .

28

4.9

Relations entre thmes et principes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

Chapitre 5 Le projet PRINCE2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

5.1

Les phases du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

5.2

Le prprojet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32

5.3

Les squences de livraison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

34

5.4

La dernire squence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

35

Chapitre 6 Avant le projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

39

6.1

39

Thme : Cas dAffaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.1.1

Responsabilits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

41

Table des matires

6.2

Thme : Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43

6.2.1

Les trois intrts du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43

6.2.2

LEntreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43

6.2.3

LUtilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

44

6.2.4

Le Fournisseur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

45

6.2.5

La Direction de lEntreprise ou du Programme . . . . . . . . . . . . . . . . . . . . . . . . . . . .

45

6.2.6

Les niveaux de lOrganisation PRINCE2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

45

6.2.7

Les diffrents acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

47

6.2.8

De limportance relative du Chef de Projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

53

Processus : laborer un projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

55

6.3

6.3.1

Les activits du Processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

57

6.4

Le dmarrage du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

63

6.5

Thme : Qualit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

64

6.5.1

Le modle du client au client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

65

6.5.2

Planification et Contrle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

66

6.5.3

Technique de revue qualit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

69

6.5.4

LAssurance Qualit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

70

Thme : Changement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

73

6.6

6.6.1

La Gestion des Incidences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

75

6.6.2

La Matrise des Changements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

76

6.6.3

La Gestion de la Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

78

Thme : Risque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

86

6.7
Dunod Toute reproduction non autorise est un dlit.

VII

6.7.1

La Gestion des Risques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

87

6.7.2

Le Budget de Risque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

97

Processus : Initialiser un projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

100

6.8

6.8.1

Les activits du Processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

101

Chapitre 7 En cours de Projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

111

7.1

111

Thme : Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.1.1

La planification base sur le produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

113

7.1.2

Les sept tapes essentielles proposes par PRINCE2 . . . . . . . . . . . . . . . . . . . . . . .

113

7.1.3

Les diffrents plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

115

VIII

7.2

La methode PRINCE2

Thme : Progression. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

119

7.2.1

Les tolrances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

119

7.2.2

Dcoupage de la squence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

122

7.2.3

Dimensionnement de la squence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

123

7.2.4

Outils de contrle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

124

7.2.5

Techniques dvaluation de la progression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

125

Processus : Contrler une squence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

126

7.3

7.3.1

Groupe 1 : Les Lots de Travaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

128

7.3.2

Groupe 2 : Le reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

129

7.3.3

Groupe 3 : Le suivi et la gestion des vnements . . . . . . . . . . . . . . . . . . . . . . . . . .

130

7.4

Processus : Grer la livraison des produits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

134

7.5

Processus : Grer la limite dune squence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

137

7.5.1
7.6

Grer une limite de squence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

138

Processus : Diriger un projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

142

7.6.1

Autoriser lInitialisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

143

7.6.2

Autoriser le Projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

144

7.6.3

Autoriser le Plan de Squence ou dException . . . . . . . . . . . . . . . . . . . . . . . . . . . .

144

7.6.4

Donner les directives appropries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

144

7.6.5

Autoriser la clture du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

145

Chapitre 8 La fin du Projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

147

8.1

147

Processus : Clore le projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.1.1

Prparer la clture planifie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

148

8.1.2

Prparer la clture prmature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

149

8.1.3

Remettre les produits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

149

8.1.4

valuer le projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

150

8.1.5

Recommander la clture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

150

Chapitre 9 Ladaptation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

153

9.1

154

Adaptation des Thmes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9.1.1

Le Cas dAffaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

154

9.1.2

LOrganisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

155

9.1.3

La Qualit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

155

9.1.4

Les Plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

156

Table des matires

IX

9.1.5

Les Risques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

157

9.1.6

Les Changements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

157

9.1.7

La Progression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

157

9.2

Adaptation des Processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

157

9.3

Adaptation des Produits de Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

158

Chapitre 10 Un projet PRINCE2 est-il protg du chaos ? . . . . . . . . . . . . . . . . . . .

161

Dunod Toute reproduction non autorise est un dlit.

Deuxime partie Passer sa certification PRINCE2

Chapitre 11 Questionnaire pour la certification Fondamental . . . . . . . . . . . . . .

167

11.1 Questionnaire Fondamental . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

167

11.2 Rponses au Questionnaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

177

Chapitre 12 Questionnaire pour la certification Praticien . . . . . . . . . . . . . . . . .

181

12.1 Scnario Optimum SA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

181

12.1.1 Logistique et Maintenance - LMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

183

12.1.2 Commercial et Clientle - COC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

184

12.1.3 Administration et Finance - AFI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

184

12.1.4 Ressources Humaines - REH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

184

12.1.5 Service Juridique SJU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

184

12.1.6 Relation Publique REP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

184

12.1.7 Stratgie et Marketing - SMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

184

12.1.8 Technologie dInformation et de Communication - TIC . . . . . . . . . . . . . . . . . . . .

185

12.2 Structure organisationnelle dun POP dOPTIMUM SA . . . . . . . . . . . . . . . . . . .

185

12.3 Structure organisationnelle IT de chaque POP . . . . . . . . . . . . . . . . . . . . . . . . . . . .

187

12.4 Systmes dinformation dOPTIMUM SA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

188

12.5 Constat, Proccupations et contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

189

12.5.1 Constat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

189

12.5.2 Proccupations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

189

12.5.3 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

190

12.6 Informations complmentaires aux questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

191

12.6.1 Complment la question 3 : Description de Produit de Projet . . . . . . . . . . . . . .

191

12.6.2 Complment la question 3 : Stratgie Qualit . . . . . . . . . . . . . . . . . . . . . . . . . . .

192

La methode PRINCE2

12.6.3 Complment la question 4 : Plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

192

12.6.4 Complment la question 5 : un des Lots de Travaux de la squence 2 . . . . . . .

193

12.6.5 Complment la question 6 : Stratgie des Risques . . . . . . . . . . . . . . . . . . . . . . . .

194

12.6.6 Complment la question 7 : Changement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

195

12.6.7 Complment la question 8 : Stratgie de Communication . . . . . . . . . . . . . . . . .

195

12.7 Questionnaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

197

12.7.1 Question 1 : Cas dAffaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

197

12.7.2 Question 2 : Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

199

12.7.3 Question 3 : Qualit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

201

12.7.4 Question 4 : Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

203

12.7.5 Question 5 : Progression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

204

12.7.6 Question 6 : Risque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

206

12.7.7 Question 7 : Changement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

207

12.7.8 Question 8 : laborer un Projet / Initialiser un Projet . . . . . . . . . . . . . . . . . . . . . .

209

12.8 Rponses au Cas OPTIMUM SA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

211

12.8.1 Question 1 : Cas dAffaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

211

12.8.2 Question 2 : Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

212

12.8.3 Question 3 : Qualit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

213

12.8.4 Question 4 : Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

215

12.8.5 Question 5 : Progression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

215

12.8.6 Question 6 : Risque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

216

12.8.7 Question 7 : Changement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

217

12.8.8 Question 8 : laborer un Projet / Initialiser un Projet . . . . . . . . . . . . . . . . . . . . . .

218

A NNEXES
Annexe A Formulaires de produits de management . . . . . . . . . . . . . . . . . . . . . . . . . . .

223

Annexe B Relations de PRINCE2 avec dautres rfrentiels mthodologiques .

275

Annexe C Mthodes de planification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

285

Annexe D Introduction aux techniques destimation . . . . . . . . . . . . . . . . . . . . . . . . .

289

Table des matires

XI

Annexe E Quelques techniques de base. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

293

Glossaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

297

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

313

PREMIRE PARTIE

Grer un projet selon

PRINCE2
Lensemble des chapitres de cette premire partie est centr sur la faon dont la
mthode PRINCE2 conseille de grer un projet, quelle que soit sa nature.
Ces chapitres dcrivent donc la mthode telle quelle est, mais aussi prcisent
quelques concepts qui ne sont pas explicites en eux-mmes.

1
Quest-ce que PRINCE2 ?

Objectif

Dunod Toute reproduction non autorise est un dlit.

PRINCE2 est une mthode non exclusive largement utilise dans plus de 150 pays
travers le monde. De par son approche novatrice et fiable, cette mthode est considre comme la meilleure mthode de gestion de projet, et plus de 20 000 organisations
en bnficient dj. Cela est d en grande partie au fait que PRINCE2 est vritablement gnrique et adaptable nimporte quel type de projet, indpendamment de sa
dimension, de lorganisation qui le supporte, de sa localisation gographique ou de la
culture qui le met en uvre.
Les paragraphes qui suivent prsentent la gense de cette mthode et les quelques
difficults de lecture lies cette gense.

1.1 ORIGINE DE PRINCE2

PRINCE2, acronyme de PRoject IN Controlled Environments est une mthode dveloppe sous le contrle de lOGC, Office of Government Commerce, dont le premier
propritaire a t le CCTA (Central Computer and Telecomunications Agency) et qui
appartient actuellement au Cabinet Office.
La mthode PRINCE2, drive de la mthode PROMPTII, a t publie en 1996
en tant que mthode de projet gnrique.
En 2006, la mthode a t revue pour ladapter lenvironnement, rendre la
mthode plus simple et lintgrer aux autres mthodes de lOGC.
En juin 2010, la suite dune rorganisation du gouvernement du Royaume-Uni,
lensemble des rfrentiels a t transfr au Cabinet Office.

Chapitre 1. Quest-ce que PRINCE2 ?

Le Cabinet Office prsente dautres rfrentiels que PRINCE2. Ces rfrentiels

proposent des conseils pratiques, adaptables et efficaces, tirs dexpriences russies
mais aussi de retour dexprience dchecs cuisants. Rduites leurs lments essentiels,
les expriences traduites dans ces rfrentiels peuvent tre appliques tout type
dentreprise et dorganisation. Ces rfrentiels ont contribu amliorer les processus
et les oprations pour les organisations de toutes tailles y compris les petites
entreprises, les organismes du secteur public et des grandes entreprises internationales.
Le portefeuille de rfrentiels ainsi constitu prsente un large ventail des
meilleures pratiques de gestion. Des informations complmentaires peuvent tre
trouves en visitant les sites Web des produits spcifiques ci-dessous :
PRojects IN Controlled Environments (PRINCE2) for project management,
Managing Successful Programmes (MSP) for program management,
Management of Risk (M_o_R) for risk management,
IT Service Management (ITIL) for IT service management,
Management of Portfolios (MoPTM ) for portfolio management,
Management of Value (MoVTM ) for value management,
Portfolio, Program and Project Offices (P3O),
Portfolio, program and project management maturity model (P3M3).

Ces rfrentiels sont complmentaires, soit parce quils apportent des prcisions
sur diffrents aspects, soit parce quils participent la gouvernance globale dune
organisation.

1.2 PRCAUTIONS DE LECTURE

PRINCE2 tant une mthode dorigine anglo-saxonne, rdige intgralement en
anglais, il est parfois difficile de traduire lesprit de la mthode par des mots quivalents
dune autre langue.
Dans ce livre, il nest pas question de reprendre la traduction en franais de
louvrage qui fait rfrence, et qui par ailleurs est de trs bonne qualit, mais dclairer
le lecteur quant des termes abusivement traduits ou par dfinition diversement
interprtables. Quand des termes anglais sont plus appropris, car passs dans le
langage courant professionnel, ils sont sciemment utiliss ou indiqus dans ce livre.

1.2.1 Exemples de difficults

La traduction de Business Case par Cas dAffaire semblait inutile car Cas
dAffaire est un nologisme : pour preuve, sur la toile, part les sites plus ou moins
ddis PRINCE2 et quelques sites anglophones dont la traduction est douteuse,
cette expression nexiste pas. Dossier commercial aurait certainement t plus
proche, bien que trop connot commerce . Vouloir traduire ce terme est quivalent
vouloir traduire marketing : cela est inutile et source de confusion.

1.2 Prcautions de lecture

Lutilisation des deux termes avancement et progression , qui dans le langage

courant sont synonymes, peut engendrer une confusion. Dans la version de 2005, les
traductions de Highlight Report et Checkpoint Report taient rapport de
point clef et rapport de point de contrle . Dans la version de 2009 (celle dont
il est question dans cet ouvrage), les traductions sont respectivement Rapport de
Progression et Rapport dAvancement . Il aurait t plus astucieux, quitte ne
pas traduire mot mot, dutiliser par exemple Rapport au COPIL et Rapport au
Chef de Projet , ou Rapport de Squence et Rapport de Lot de Travaux .
Les leons tires de lexprience sont habituellement nommes Retours dExprience dans le langage courant professionnel, avec comme diminutif REX .
Stage a t traduit par squence et non par phase ou tapes , certainement pour viter la confusion avec les phases du projet (prprojet, initialisation,
ralisation et clture). De plus, la lettre S en dbut de mot permet de ne pas
confondre avec Projet et Phase dans les acronymes des noms de processus ( DP ,
EP , IP ) qui ne sont pas utiliss dans ce livre, mais souvent dans dautres
ouvrages.
La critique est facile, mais lart de la bonne traduction est plus complexe. De plus,
les socits ou organisations franaises ne se sont pas bouscules pour aider Andy
Murray, auteur principal, crire louvrage de rfrence.
Remercions les auteurs de ne pas avoir reproduit un pige que lon retrouve par
exemple dans ITIL, qui sous le terme de problme dsigne ce qui nen est pas
un dans le langage courant, mais qui ressemblerait simplement une cause dun
incident . Le rfrentiel CMMI a dailleurs intelligemment franchi lobstacle en
utilisant la terminologie Analyse Causale ce qui semble parfaitement clair et
reprsentatif du sujet.

Dunod Toute reproduction non autorise est un dlit.

Afin de conserver un vocabulaire commun et en usage lors des certifications, nous

utiliserons la traduction officielle, en compltant lide sous-jacente lorsque cela parat
ncessaire.
Dans le cadre de ladaptation de la mthode, les auteurs recommandent dadapter
le vocabulaire aux us et coutumes de lorganisation adoptant PRINCE2, facilitant
ainsi lemploi de PRINCE2.

1.2.2 Convention de syntaxe et dfinitions pralables

Pour aider la lecture, des conventions ont t utilises et certaines dfinitions
pralables sont ncessaires.
Les noms ou groupe de mots dsignant des objets spcifiques la mthode
PRINCE2, ou pour lesquels il est intressant dattirer lattention du lecteur, ont une
capitale en premire lettre des noms, par exemple : le produit Expos de projet ou le
processus Initialiser le projet.
La premire occurrence de ces objets est en caractres gras pour marquer le
caractre important de la syntaxe de lobjet ainsi dsign.

Chapitre 1. Quest-ce que PRINCE2 ?

En italique figure le texte qui est extrait directement de louvrage Russir le

management de projet avec PRINCE2 ou dautres ouvrages conus sous lgide du
Cabinet Office. Les autres citations dauteurs sont simplement places entre guillemets.

1.2.3 Focus sur le vocabulaire PRINCE2

La notion de produit est trs importante pour PRINCE2, le Produit de Projet (ou
les Produits de Projet) est ce que le projet doit livrer au final, que ce soit un pont,
une application ou un immeuble. Un Produit dsigne tout livrable ou composant que
le projet doit fournir, cest un constituant du Produit de Projet, comme un pilier de
pont, une pice dune application informatique ou les fondations de limmeuble. Les
Produits de Management ne sont pas des composants des Produits, ils permettent le
projet, ce sont des documentations, des enregistrements, des rapports, des outils ou
des instances. Enfin les Produits Spcialistes dsignent les produits techniques crs
par les quipes de ralisation.
Une Squence dsigne une tape identifie de la vie du projet. Une Squence
technique correspond au temps consacr pour raliser les produits de la squence en
question, la Squence de Management recouvre une plusieurs Squences technique,
elle correspond la vision quont les responsables du projet.
LAcceptation dun produit dsigne la validation et la ratification du Produit de
Projet, alors que lApprobation ne concerne quun ou plusieurs produits.
Le terme Qualit recouvre un concept diffrent de ce que son qualificatif suggre.
Un objet de qualit dsigne dans le langage courant quelque chose de bien, de bon, de
beau, alors quil se rfre ici uniquement aux caractristiques techniques dun produit.
Ces caractristiques doivent tre mesurables pour que lon puisse les valider.
La Surveillance dsigne les activits ncessaires pour vrifier que des tches
ou processus sont en cours, alors que le Contrle sattache plus gnralement la
vrification des rsultats de ce que ces tches fournissent.
Bien que souvent employ, le terme Prioris nexiste pas dans la langue franaise.
Il signifie donner une priorit.
On dsigne par le nom Organisation, lentreprise ou ltablissement client dont va
dpendre le projet. PRINCE2 suppose que le projet est mandat par une organisation
(client) nomme de faon gnrique Entreprise ou par un Programme qui peut tre
compris comme un ensemble de projets.
Bien que parfaitement synonymes, les termes de Progression et dAvancement
doivent tre considrs de faon particulire dans PRINCE2 lorsquils sont associs
un Rapport, car ils dsignent alors un change dinformations entre des niveaux
hirarchiques diffrents.
Le terme Assurance doit tre pris sous deux acceptations. Il dsigne soit les
activits ncessaires pour sassurer de quelque chose, soit lentit responsable de ces
activits.

2
Pourquoi une mthode ?

Objectif

Dunod Toute reproduction non autorise est un dlit.

De nombreuses tudes statistiques montrent que les projets sont loin dobtenir les
rsultats escompts lorsquils arrivent terme et que les budgets dorigine ont souvent
t dpasss.
Parmi ces tudes, celles du Standish Group font rfrence. Elles se basent parfois sur
une thorie du chaos qui rsume ce que ressentent les acteurs dun projet.
Les chapitres suivants prsentent ces thmes, sachant que les donnes du Standish Group serviront de fil conducteur cet ouvrage afin dapprcier la mthode
PRINCE2.

2.1 DE LA THORIE DU CHAOS

Selon Wikipedia : La thorie du chaos traite des systmes dynamiques rigoureusement dterministes, mais qui prsentent un phnomne fondamental dinstabilit
appel - sensibilit aux conditions initiales - qui, modulant une proprit supplmentaire de rcurrence, les rend non prdictibles en pratique long terme.
La thorie du chaos est ne dtudes menes par le grand scientifique mconnu
Henri Poincar, pre de la physique moderne, contemporain des Curie, Rutherford ou
Langevin et dont certains prtendent quil est le vritable gniteur de thorie de la
relativit restreinte.
Cette thorie scientifique du chaos, qui sapplique des phnomnes physiques,
pourrait tre reprise au compte de nos projets, souvent imprdictibles, complexes et
prsentant une sensibilit aux conditions initiales incertaines. Ceci tend prouver

Chapitre 2. Pourquoi une mthode ?

que certains phnomnes sont imprdictibles car par trop instables et que lentropie
latente universelle tend nous dcourager de toute tentative de prdiction.

2.2 LE CHAOS REPORT

Pas tonnant que ce nom de Chaos Report ait t donn une tude mene depuis
la fin des annes 1970 par le Standish Group, tude qui porte sur lanalyse des causes
dchec de projets informatiques et leur progression danne en anne. Il ny a pas de
quoi tre fier, car mme si les chiffres sont contestables dans leur analyse, les rsultats
semblent prouver que seulement 37 % des projets informatiques sont totalement
russis. Encore faudrait-il analyser ces chiffres en sachant que plus de 90 % des projets
sarrtent et redmarrent une plusieurs fois avant daboutir.
Tableau 2.1 volution de la russite des projets informatiques

Russi
Dgrad
Annul

1994
16 %
53 %
31 %

1996
27 %
33 %
40 %

1998
26 %
46 %
28 %

2000
28 %
49 %
23 %

2002
34 %
51 %
15 %

2004
29 %
53 %
18 %

2006
35 %
46 %
19 %

2009
32 %
44 %
24 %

Les enqutes ralises par le Standish Group sont aussi exhaustives que possible. Les
rsultats sont bass sur des campagnes de recherche et des entretiens avec des cadres
informatiques. Lchantillon comprenait des grandes, moyennes et petites entreprises
de secteurs majeurs, comme la banque, la finance, lindustrie, le commerce de dtail et
de gros, la sant, lassurance, les services, les organismes locaux, tatiques et fdraux.
Lchantillon total tait de 365 entreprises et a concern 8 380 applications (donnes
1995).
Dans le cadre du Chaos Report, les projets ont t classs selon trois types :
Projet russi : le projet est termin dans les temps et respecte le budget et le

primtre initial ;
Projet dgrad : le projet est termin et oprationnel, mais dpasse le budget et

le dlai initial, et est moindre primtre ;

Projet annul : le projet est annul en cours de dveloppement.
Laspect le plus intressant de ltude est de dcouvrir pourquoi les projets chouent
en gnral. Cest un excellent retour dexprience. Pour ce faire, le Standish Group
a interrog des cadres informatiques afin quils donnent leur opinion concernant les
raisons dterminant la russite des projets.
Les quatre principales raisons permettant un projet daboutir sont :
la participation des utilisateurs,
lappui des dirigeants,
un nonc clair des exigences
et une planification adquate.

2.3 Identification dun Projet

Sans eux, le risque dchec augmente de faon spectaculaire.

Dautres facteurs sont mis en avant le tableau suivant.
Tableau 2.2 Les diffrents facteurs de russite dun projet
1
2
3
4
5
6
7
8
9
10
11

Facteurs de russite du projet

Implication des utilisateurs
Soutien des Responsables oprationnels
nonc clair des exigences
Planification adquate
Attentes ralistes
Jalons de projet plus rapprochs
Comptences de lquipe
Proprit du produit
Vision et objectifs clairs
quipe ddie et travail fourni
Autres

% Rponses
15,90
13,90
13,00
9,60
8,20
7,70
7,20
5,30
2,90
2,40
13,90

Cumul en %
15,90
29,80
42,80
52,40
60,60
68,30
75,50
80,80
83,70
86,10
100,00

Connaissant ces chiffres, essayer de palier par une mthodologie tout ou partie
des facteurs de risque, cest tenter de rduire le risque dchec du projet en lui-mme.
Sachant quen la matire comme dans dautres, le risque zro nexiste pas.
Tout au long de cet ouvrage consacr PRINCE2, les concepts de la mthode sont
mis en relation avec ces facteurs de russite afin de vrifier en quoi cette mthode de
gestion de projet rpond ces facteurs de risque.

2.3 IDENTIFICATION DUN PROJET

Dunod Toute reproduction non autorise est un dlit.

Nous lavons vu, tout peut tre sujet projet, mais tout nest pas projet. Pour cerner
ce qui pourrait tre un projet, le mieux est de rechercher les caractristiques qui le
distinguent des oprations courantes.
Le Changement : sans changement apport, il ny a pas de projet et lactivit
dploye ne sera quune activit dans la continuit des oprations courantes, rcurrentes, certainement gnratrice de plus de valeur pour lentreprise, mais sans apport
de renouveau. Cest souvent ce caractre qui fait lattrait dun projet.
LUnicit : aucun projet ne ressemble un autre. Un autre projet rassemblera
dautres quipes une date diffrente dans un contexte particulier. Mme semblables,
tous les projets sont diffrents.
LInter-fonctionnalit : le changement est toujours le fruit dune collaboration
dacteurs dhorizons diffrents qui tous concourent au succs du projet. Ceci dans le
meilleur des cas, car en ralit, cette disparit de formation, de culture et souvent
dintrt provoque des tensions prjudiciables au projet. linverse, considrons que le
caractre multidisciplinaire dun projet apporte une richesse quil y a lieu dexploiter :
cette richesse est dans tous les cas indispensable pour obtenir un rsultat accompli.

10

Chapitre 2. Pourquoi une mthode ?

Laspect temporaire : un projet sinscrit dans le temps, il est temporaire, possde un

dbut et, esprons-le, une fin dfinie, qui lui donneront dailleurs ce caractre unique.
Lincertitude : beaucoup plus que les oprations courantes, tout projet prsente au
moins un risque, ne serait-ce que de ne pas aboutir, ou linverse, darriver concrtiser
ce pour quoi il a t fait. Tant il est vrai que cette incertitude que lon nomme risque
prsente la fois un volet Menace, mais galement un aspect Opportunit.
La gestion des projets nest pas une science nouvelle, et son association avec
la gestion des risques non plus selon Luc de Clapiers, Marquis de Vauvenargue au
XVIII e sicle, La science des projets consiste prvenir les difficults de lexcution.

2.4 LA NCESSIT DUNE MTHODE

Le tout nest pas de faire des projets au sens positif et populaire du terme, encore
faut-il les raliser. Cest ce moment que les ennuis commencent, car passer du rve,
de la projection, la ralit est souvent difficile, voire impossible. Les raisons de cette
difficult sont multiples. Simples humains, souvent nous ne disposons pas de ressources
(au sens de moyens) infinies. Disposerions-nous de ces ressources, que nos capacits
(savoir-faire) seraient coup sr limites.

2.4.1 Les contraintes

En cela vous trouvez les premires limites dun projet, mais galement les premires
questions se poser avant dentreprendre tout projet : avons-nous les ressources et les
capacits pour le mener bien ?
La premire question que nous allons nous poser concerne donc la faisabilit du
projet en prenant en compte nos forces, tout en gardant lesprit que le jeu doit
en valoir la chandelle . Autrement dit, que les bnfices escompts gnrs par le
projet restent suprieurs aux efforts fournir. Entendez par Bnfice tout ce que peut
engendrer le projet, pas seulement lintrt pcuniaire, ni un simple rapport entre ce
qui est dpens et ce qui est obtenu, mais galement parfois une obligation lgale,
une contrainte rglementaire, une dcision stratgique laquelle lentreprise doit
rpondre.

2.4.2 La viabilit
Des vnements extrieurs peuvent, au cours du projet, affecter ce bnfice et rendre
caduc le projet en lui-mme. Ce constat permet de se rendre compte que ce qui
pourrait ntre peru que comme une question initiale est en fait une question qui
doit rester omniprsente lesprit des personnes concernes par le projet. Le type de
dmarche rcurrente quimplique une mthode permet dviter des dpenses inutiles
dans des projets qui ne livreront que de pitres bnfices, si jamais ils aboutissent.
Laissons le soin chacun dillustrer par ses propres exemples la ncessit de ce qui
prcde, les projets non aboutis sont nombreux, toutes les tudes montrent quavec

2.4 La ncessit dune mthode

11

un peu de discernement ces projets auraient d tre arrts temps et peut-tre mme
ne pas tre commencs.
Une fois personnellement convaincu que le projet est ralisable et porteur de
bnfice, il nous faut aussi convaincre des partenaires qui peuvent tre rticents aux
changements. Pour les convaincre, nous allons devoir leur communiquer les lments
qui prnent la ncessit de raliser le projet, leur exposer le plus clairement possible
les arguments qui nous font penser que le projet est porteur de bnfice, mais aussi
ralisable. Cet argumentaire doit saccompagner de rponses aux questions comment,
avec quoi et avec qui se fera le projet, permettant ainsi ces partenaires de se projeter
dans le projet et dtre convaincus quil est viable.

2.4.3 La prparation
90 % de la russite est dans la prparation, ce ne sont pas les sportifs de haut niveau
ni mme les joggeurs du dimanche qui contrediront cela. Avant de mettre en uvre
les ressources et moyens ncessaires au projet, encore faut-il les identifier et tre en
mesure de les rquisitionner. Rarement nous partmes 500 pour arriver 3 000 au
port , ce serait plutt linverse. Et ce nest pas le dnombrement des forces qui en fait
la force, mais leur organisation, leur prparation et leur dtermination.

Dunod Toute reproduction non autorise est un dlit.

Identifier ces ressources (moyens) et aptitudes (savoir-faire) ne suffit pas si leur

concours au projet nest pas clairement dfini. En dautres termes, insuffler la volont
de participer au projet et clarifier les redevabilits et interactions de chacun
est, sinon indispensable, du moins ncessaire. Il sagit dorganiser dans le temps les
diffrents produits et tches accomplir aprs les avoir dfinis, et faire partager
cette vision du futur. Cette activit se concrtise souvent par un plan de bataille,
de btiment, de voyage... ou par le renoncement, au regard de tous les obstacles
surmonter.
Cette phase est primordiale car elle garantit quavant de commencer raliser
le projet, nous allons nous assurer que nous matrisons suffisamment les ressources
et les savoir-faire pour le mener bien. Il nest bien entendu pas question de tout
matriser, cest une utopie, mais au moins de nous doter des outils et de la conviction
que nos chances de russite sont maximales. Cette phase permet galement de se doter
des moyens ncessaires pour rpondre aux objections plus ou moins positives de nos
partenaires, des concerns et des associs au projet.

2.4.4 Rendre des comptes

Dots de moyens et convaincus de notre savoir-faire, nous allons pouvoir concrtement passer aux ralisations ncessaires au projet. Parce que nous sommes en
quelque sorte sponsoriss par ceux qui nous ont financs, appuys ou seulement
encourags, nous devons leur rendre des comptes. Savoir leur communiquer que
le projet reste viable, quil progresse et apporte mme dj des amliorations, ne
serait-ce que la certitude que nous sommes sur le bon chemin est indispensable car ces
sponsors doivent continuer nous supporter , cest--dire continuer nous apporter

12

Chapitre 2. Pourquoi une mthode ?

conseils et prconisations. Ils peuvent aussi ventuellement nous informer de ce quils

apprennent ou savent de ce qui pourrait impacter le projet. Mais ces sponsors ne sont
pas notre disposition, si nous voulons les intresser, il faut organiser des runions de
compte rendu des moments pendant lesquels ils seront disponibles.
Reprenez les quelques paragraphes qui prcdent, traduisez-les dans votre langage
et dans les termes de votre mtier, utilisez votre bon sens, et vous aurez la mthode que
vous recherchez. Cest ce quont fait les auteurs de la mthode PRINCE2, en fixant
un vocabulaire commun une mthode logique et universelle de gestion de projet
prenant en compte son environnement.
Selon Maurice Blondel, Lavenir ne se prvoit pas, il se prpare .

3
Que propose PRINCE2 ?

Objectif
PRINCE2 sappuie sur trois concepts importants, les principes, les thmes et les
processus. En nombre restreint, ils permettent de structurer la dmarche de gestion
de projet de faon simple et pragmatique.
Ce chapitre introduit ces trois concepts, dtaills dans les chapitres suivants, et les
raisons qui conduisent ladoption de PRINCE2.

Dunod Toute reproduction non autorise est un dlit.

3.1 STRUCTURE DE PRINCE2

linverse de nombreux rfrentiels qui ont multipli le nombre de leurs processus
ces dernires annes (20, 30, plus de 40 processus pour certains), PRINCE2 dans sa
version de 2009 a rduit sept le nombre de ses processus pour clarifier sa dmarche
projet. Soyons-leur reconnaissants, tant il est vrai que faire compliqu est simple,
rendre accessible est un exercice difficile. Comme la crit Anton Tchekhov : La
brivet est sur du talent .
Les processus suivent le phasage de tout projet, soit le pr-projet, le dmarrage de
projet, la ralisation et enfin la fin du projet, et mettent en avant les activits souvent
rcurrentes mener pour faire progresser le projet.
Les auteurs de PRINCE2 ont introduit de faon intelligente des principes et
des thmes pour complter ces processus en expliquant ce qutaient pour eux
les fondamentaux de la gestion de projet (les Principes) et donnant un clairage
particulier sur ce qui pouvait concourir cette activit (les Thmes).

14

Chapitre 3. Que propose PRINCE2 ?

Les principes servent expliquer ce qui est intangible sur un projet PRINCE2.
Tout projet se rclamant de la mthode PRINCE2 se doit de respecter ces principes.
Ladoption de ces principes est indispensable toute organisation qui voudrait
grer des projets laide de la mthode PRINCE2. linverse, ne pas adopter ces
principes engendre inluctablement des interprtations prjudiciables et revient
manquer de la rigueur ncessaire prne par cette mthode.
Les thmes abordent certains aspects essentiels de la gestion de projet. Ils sont
adaptables et fournissent les bases des disciplines essentielles de la gestion de projet,
comme la planification, la gestion de la qualit ou celle des risques. Mais ils fournissent
galement un clairage particulier sur certains aspects de la gestion de projet, comme le
Cas dAffaire, lOrganisation, la prise en compte des vnements tels les Changements
en cours de projet ou le contrle de la Progression.
Les thmes sont les suivant :
le Cas dAffaire,
lOrganisation,
la Qualit,
les Plans,
les Risques,
les Changements,
la Progression.

Parce quun projet est dpendant de son environnement, il est ncessaire de le

prendre en compte, cest--dire dadapter le projet cet environnement. Comprenez
adapter lutilisation de la mthode PRINCE2 aux particularits du projet en temps
que tel (taille, risque, complexit, etc.), mais galement ce qui est extrieur au projet
mais qui peut limpacter (mtier, culture, maturit, etc.).

Figure 3.1 Processus, Thmes et Principes.

(Figure 1.2 Managing Successful Projects with PRINCE2 2009 Edition).
Crown copyright 2009 Reproduced under licence from OGC.